Vamos esclarecer todas as pastas bin e sbin (do padrão de hierarquia do sistema de arquivos):
/biné para binários em nível de sistema/sbiné para outros binários de nível de sistema principalmente para o gerenciador de inicialização e administradores de sistema/usr/biné para binários não essenciais/usr/sbin- é aqui que começa a bagunça - não são ferramentas essenciais para administradores de sistema? O que isso significa? Para experimentos?/usr/local/bin- nenhuma palavra sobre esta pasta/usr/local/sbin- programas de administração de sistema instalados localmente. De novo? Que tal/usr/sbin?
Portanto, a questão é: por que existem tantos diretórios e quais são os significados /usr/sbinde /usr/local/sbine /usr/local/bin?
Muitos programas são distribuídos através de arquivos e temos que construí-los a partir do código-fonte. Geralmente eles têm makefile, então é bem fácil. Este processo envolve a criação de arquivos em usr/local/lib, usr/local/bin... usr/local/whatever sem criar pastas específicas para um determinado programa.
Por que é tão?
Acho que não está certo porque se precisarmos remover o programa teremos que deletar manualmente todos os seus arquivos se o criador do programa não cuidar disso.
Responder1
1. Estrutura de diretório
Isto deve ser abordado noPadrão de hierarquia do sistema de arquivos (2.3 PDF)
/bin/ Binários de comando essenciais que precisam estar disponíveis no modo de usuário único;
para todos os usuários, por exemplo, cat, ls, cp
/sbin/ Binários essenciais do sistema, por exemplo, init, ip, mount.
/usr/bin/ Binários de comando não essenciais (não necessários no modo de usuário único);
para todos os usuários
/usr/sbin/ Binários de sistema não essenciais, por exemplo, daemons para vários serviços de rede.
/usr/local/ Hierarquia terciária para dados locais, específica para este host.
Normalmente tem outros subdiretórios, por exemplo, bin/, lib/, share/
2. Instalação
Eu uso um gerenciador de pacotes sempre que possível (por exemplo, yum ou apt-get). Isso é possível para um grande número de aplicativos; em alguns casos, pode ser necessário adicionar um repositório. Minha segunda opção seriam pacotes de nível inferior, como RPMs, e compilar a partir do código-fonte seria meu último recurso (mas algumas pessoas preferem isso).
Alguns gerenciadores de pacotes podem instalar a partir de RPMs (por exemplo yum install oddity.rpm)
Se você estiver compilando a partir do código-fonte, provavelmente não será um grande passo criar seu próprio pacote para que o instalador do sistema saiba o que você fez.
Então seu problema se reduz a, por exemployum remove packagename
A alternativa é manter uma boa documentação sobre todas as atividades realizadas pelo administrador do sistema (de qualquer maneira, mantenho um diário em um arquivo de texto)
Responder2
As coisas em todos os diretórios */sbin tendem a ser úteis apenas para administradores de sistema. Você pode mantê-los fora do seu PATH se for um usuário normal.
Os diferentes diretórios não fazem muito sentido se você tiver uma única máquina Unix em um único disco, mas fazem mais sentido se você tiver um sistema grande e partições diferentes. Lembre-se de que muitos desses hábitos foram criados nas décadas de 80 e 90, quando os sistemas eram um pouco diferentes.
/sbintende a sermuitopequeno. Esses são utilitários de que você precisa quando está realmente cansado. Você colocaria isso em uma partição raiz mínima com/root e/lib. As coisas em /sbin costumavam ser todas vinculadas estaticamente, pois se sua partição /usr estiver com mangueira, qualquer aplicativo vinculado dinamicamente será inútil. fsck está aqui e vinculado estaticamente. Se você depende de /usr, obviamente não pode fsck /usr/. Claro, se a partição raiz estiver bloqueada, você estará muito ferrado. É por isso que esta é uma partição tão pequena - diminua as chances de um bloco de disco defeituoso usando poucos blocos aqui.
/usr/sbinbinários são ferramentas gerais de administração de sistemas onde você pode pelo menos entrar no modo de usuário único e montar todos os seus volumes. Eles podem ser vinculados dinamicamente.
As partições separadas para /sbin (bem, /sbin em /partição) e /usr também fazem mais sentido quando você lembra que o backup era muito caro tanto em tempo quanto em fita. Se eles estivessem em partições separadas, você poderia agendá-los de forma diferente.
/usr/localpode ser um sistema de arquivos de rede. Portanto, ferramentas de administração de sistemas escritas localmente que podem ser compartilhadas entre muitas máquinas às vezes vão para /usr/local/sbin. Obviamente, nenhum utilitário de correção de rede pode ir até lá.
Novamente, muitas coisas faziam mais sentido em máquinas grandes em um ambiente de rede em máquinas gerenciadas com vários volumes, e menos em uma máquina Linux em uma única partição raiz.
Responder3
Você realmente deveria fazer com que sua segunda pergunta fosse uma pergunta separada aqui no Superusuário. Não tem relação com o primeiro.
Sim, ter arquivos por todo lado é uma droga. É por isso que existem muitas soluções de embalagem. A RedHat criou o RPM que é usado em todos os lugares. Solaris tinha seu formato de pacote. O HP/UX tinha o deles, e há o apt e muitos outros formatos de pacote. Mantenha as coisas nos lugares certos (/usr/bin, /usr/lib) conforme apropriado, mas permita fácil adição e remoção.
Para a fonte, costumava haver ferramentas que permitiam configurar e instalar em um subdiretório de /usr/local e manipulariam links simbólicos para /usr/local/bin para você. Devido à ampla proliferação de ferramentas de pacotes, isso é menos necessário e esqueci seus nomes.
Algumas pessoas gostam de instalar em /opt/nome do pacotee mantenha tudo junto lá. O bom: tudo está em um diretório e a desinstalação é rm -rf /opt/packagename. As desvantagens disso são ter que adicionar /opt/packagename/bin ao PATH de todos e o fato de que as pessoas geralmente não colocam /opt em uma partição separada e você preenche a partição raiz.
Responder4
Para responder à sua segunda pergunta:
Normalmente os programas são distribuídos com um chamadogerenciador de pacotes. Um gerenciador de pacotes geralmente busca pacotes binários (software compilado para uma determinada plataforma) e os lança em diretórios (há alguns que baixam o código-fonte, compilam-no em sua máquina e instalam-no). Assim, o gerenciador de pacotes sabe onde estão os arquivos pertencentes a determinado “programa” (pacote), e quando você deseja remover o pacote, o gerenciador de pacotes se encarrega de limpar tudo.
Mesmo quando você compila o código-fonte sozinho com
make
e instale-o com
make install
você geralmente pode fazer
make uninstall
que exclui os arquivos do sistema de arquivos.