Forma recomendada de instalar o software em / usr / local - use sudo ou chown?

Question

Gostaria de instalar o software da origem (por exemplo, repositórios do GitHub de terceiros) em minha máquina. Geralmente / usr / local / bin e / usr / local / src são para software não específico de distribuição, certo?

Assumir a posse de / usr / local parece arriscado: qualquer coisa que execute com meus privilégios pode fazer alterações nefastas em executáveis em / usr / local / bin ou em fontes em / usr / local / src.

Mas a alternativa, construir e instalar como root ( sudo ), não faz sentido para mim. O GitHub avisa sobre a execução de git como root. Mesmo se eu copiei as fontes de um local repo em outro lugar, eu teria que executar make e make install como sudo , o que significa que o software que estou instalando poderia seqüestrar o resto da minha máquina.

Eu poderia colocar tudo em / home, mas isso parece uma desculpa - não é isso que / usr / local é para ?

    

Answer 1

Não assuma a propriedade de /usr/local . Use sudo para o software instalar . Mas use sua própria conta para construir .

git clone …    # or tar -x or …
cd …
./configure
make
sudo make install

Por que não assumir a propriedade de /usr/local ? Você pregou isto. Isso permitiria que qualquer programa em execução na sua conta fosse escrito lá. Contra um programa malicioso, você perdeu mesmo - infectar uma conta local é o grande passo, escalar para o root não é difícil (por exemplo, pegando carona na próxima vez que você executar sudo ). Mas contra um programa mal configurado, é melhor não ter bits graváveis nos diretórios do sistema.

Quanto à escolha entre /usr/local e seu diretório pessoal: seu diretório pessoal é para itens que você deseja apenas para sua conta, /usr/local é para itens instalados em todo o sistema.

    

Answer 2

Abordagens

Existem 2 abordagens para esta solução.

1. /usr/local/{src,bin} é para software personalizado criado pelo Administrador do Sistema, ou seja, root , caso em que sudo ou su - sempre deve ser usado, tornando essa questão um ponto discutível.
2. Instale atualizações binárias pré-compiladas, ou seja, aquelas encontradas no mecanismo de gerenciamento de pacotes de distribuição, mas versões não suportadas em /opt . Também neste caso, feito pelo administrador do sistema.

Raciocínio

Em ambos os casos, o software instalado nesses locais não é suportado pela sua distribuição e, portanto, requer privilégios de root para substituir ações potencialmente perigosas. Além disso, /usr/local/src não é onde a fonte é compilada. É onde a fonte é armazenada. Lembrar esses dois itens garante que coisas como Usando o gerenciador de janelas Awesome no CentOS 7 não aconteça.

Não se confunda

Se você deseja apenas atualizar o software que já está instalado, faça isso usando o método preferido para adicionar software de teste à sua distribuição. Alguns dos principais métodos:

• Arch Based - O AUR , também conhecido como Arch User Repository
• Baseada em Debian - O PPA , também conhecido como Arquivo Pessoal de Pacotes
• Redhat Based - O EPEL , também conhecido como um repositório de terceiros

Answer 3

A maioria dos sistemas de compilação honra --prefix=$path , em que /usr/local geralmente é o padrão.

Então normalmente você constrói + test + install, onde a etapa do build + test pode ocorrer em qualquer lugar que você tenha permissão de escrita + a etapa de instalação é normalmente ...

sudo make install (instala em --prefix )

Uma maneira de configurar seu ambiente de compilação é ter um diretório de compilação com um subdiretório work + attic.

Meu ambiente de criação é ...

/smartbuild/work - onde os pacotes são compilados (a partir do tarball ou do git / svn / etc)
/smartbuild/attic - onde o tarballs é armazenado em cache (portanto, reconstrói ignorar o download do tarball)