Como instalar pacotes no Linux ou Solaris em caminhos não padrão?

Question

Por "caminho padrão", quero dizer " /usr/local " ou outros caminhos gerenciados por root ("caminhos do sistema").

Eu tenho que instalar muitos pacotes de aplicativos (por isso, quero dizer: svn , httpd , git , perl , python , ...) em alguns Linux (RedHat) ou Solaris (10, em zonas locais ) servidores.

Mas:

• esses servidores gerenciam muitos aplicativos diferentes (às vezes usando diferentes versões de svn ou perl ou ...)
• Eu não sou administrador nesses servidores (sem sudo root para mim)

Eu tentei usar, por exemplo, no Solaris, pkgadd -R para tentar instalar pacotes pré-compilados em um caminho personalizado (ou seja, dentro do homedir de um usuário específico, em vez de no caminho padrão normal de /usr/local/... ), mas os pacotes pré-compilados já vêm com referências a outros recursos em /usr/... :

Um ldd /path/to/local/installed/packages mostrará muitas dependências para os caminhos system :

ldd /home/myuser/usr/local/git
  libz.so => /usr/local/lib/libz.so
  libiconv.so.2 => /usr/local/lib/libiconv.so.2
  libsocket.so.1 => /usr/local/libsocket.so.1
  ...

Isso não funcionará, porque:

• No Solaris, não tenho como escrever nada sobre /usr , que só pode ser gravado na região global, não em uma região local.
• No Solaris ou no Linux, eu não sou root de qualquer maneira, portanto, não consigo escrever nada no caminho do sistema.
• Eu não gerencio as atualizações nesses servidores, portanto, se qualquer biblioteca for alterada, ela poderá interromper muitos dos meus serviços instalados.

O que você recomendaria fazer para instalar de forma isolada diferentes "serviços" em um mesmo servidor (Linux ou Solaris) , cada um potencialmente exigindo sua própria versão de (perl, python ...?

Eu proponho uma solução abaixo, mas se você tiver outras alternativas, eu estou interessado.

    

Answer 1

A única solução que encontrei até agora:

• compatível com a instalação de vários aplicativos ( como não raiz ),
• permitindo que cada aplicativo tenha seu próprio conjunto de dependências (com possíveis versões diferentes usadas de um conjunto de dependências para outro)

é:

recompile tudo

(e por tudo, quero dizer até mesmo gcc se necessário, já que o /usr/swf/bin/gcc instalado por padrão em nossos servidores Solaris é ainda mais antigo que o pré-requisito gcc 3.4.6)

Todas as versões usadas nesta recompilação global são provenientes de sunfreeware , que detalha todas as dependências necessárias e fornecerá um link para as fontes de cada pacote.
Isso funciona tanto no Linux quanto no Solaris.

Cada fonte de pacote é baixada, compilada e instalada em $HOME/usr/local (ou seja, não em um caminho do sistema).
A chave é ter um .bashrc (por exemplo) que irá alterar o $ PATH para não ter nenhum /usr/bin ou /usr/local/bin , mas apenas $HOME/usr/local/bin .

Encontrei ao longo do tempo várias vantagens :

• As bibliotecas em /usr podem mudar, o que terá 0 impacto nos vários serviços atualmente em execução (porque todos eles foram compilados em seu próprio conjunto de dependências instalado em $HOME/usr/local )
• O usuário não-root que executa um aplicativo compilado é praticamente root em seu próprio ambiente, e esse usuário pode ativar / desativar / atualizar / recompilar qualquer elemento dentro de $HOME/usr/local
• É fácil criar um novo diretório no $HOME e compilar novamente todas as dependências para testar uma atualização de um determinado aplicativo. Você pode acabar com várias versões de um mesmo pacote e testar / alternar de uma versão para outra.
• Você controla as opções de compilação, e é muito fácil compilar um Apache Httpd com todos módulos ativados nele se você quiser (ao contrário de um pacote pré-compilado onde você pega o que obtém ).

As principais desvantagens são:

• Qualquer compilação completa pode levar tempo (até 1 hora no Linux, 3 a 4 horas no Solaris).
  Mas nem sempre é necessário recompilar tudo.
• As opções de compilação são diferentes para cada pacote e podem ser bastante complexas para serem configuradas corretamente
• As variáveis de ambiente ( LDFLAGS , CFLAGS , CPPFLAGS , LD_LIBRARY_PATH ) podem ser difíceis de configurar com os valores corretos
• Se você não tem um script capaz de extrair para você as dependências certas e lançar as compilações, isso significa: processo manual , que é um empecilho.
  (Eu estou no processo de fazer esse script e publicarei no GitHub)

Answer 2

Existe uma opção para configurar um ambiente chroot para todos os serviços e instalar esses pacotes sob isso. Certamente invoca algum inchaço em que você é obrigado a basicamente replicar muitas bibliotecas em ambiente chroot. Mas ele isola seus serviços de todos os outros e vice-versa e dá a você controle total (tipo raiz) sobre o ambiente.

Isso ainda requer acesso root para configurar e acessar o ambiente chroot.

O acesso subsequente pode ser gerenciado usando, por exemplo, SSH:

link

    

Answer 3

No Solaris, você pode definir o RPATH usando a palavra mágica $ ORIGIN. Por exemplo, se você tiver o seguinte layout, poderá definir o RPATH como '$ ORIGIN /../ lib' no RPATH dos seus binários, passando o sinalizador -R para o vinculador.

/usr/local/bin/foo
/usr/local/lib/libfoo.so.1

No entanto, não funcionará se o layout for especificado pelo usuário. Por exemplo, o usuário pode configurar bindir para / usr / local / bin / sparcv9 e libdir para / usr / local / lib / sparcv9. Neste caso, a configuração deve ser $ ORIGIN /../../ lib / sparcv9.

Tradicionalmente, todos os binários compilados para o Solaris usam o RPATH codificado, o que os torna não relocáveis.

Uma outra coisa a considerar pode ser crle , que permite configurar o vinculador dinâmico.