Gerenciadores de pacotes não raiz

51

De minha pesquisa, pareço perceber que todos os gerenciadores de pacotes insistem em serem usados ​​como usuários privilegiados e devem ser instalados /.

Normalmente, o que eu gosto de fazer é criar uma conta descartável, compilar algum software e instalar $HOMEnessa conta. Posso experimentar várias configurações e, quando terminar, apenas destrua a conta.

No entanto, compilar software se torna tedioso.

Minha experiência é realmente apenas limitada a yum, mas não entendo por que não seria possível soltar um arquivo de repo ~/etc/yum.repos.de fazer com que yum instalasse tudo em uma conta doméstica.

Existe alguma razão pela qual os gerenciadores de pacotes devem ser usados ​​como um usuário privado para instalar o software?

olmo
fonte

Respostas:

35

Pacotes binários são compilados com a suposição de que eles serão instalados em locais específicos no /. Isso nem sempre é facilmente alterado e seria necessário um esforço adicional de controle de qualidade (o que é bastante difícil em primeiro lugar!) Para determinar se os binários específicos são ou não realocáveis.

Até certo ponto, você pode usar coisas como fakechroot para criar um sistema inteiro em um subdiretório como um usuário não raiz, mas isso é tedioso e frágil.

Você terá mais sorte com os pacotes fonte. Gentoo Prefix e Rootless GoboLinux são gerenciadores de pacotes que podem ser instalados em /locais não locais e podem ser utilizados por não rootusuários.

efémero
fonte
3
Eu acrescentaria que existem 2 tipos de relocabilidade. O pacote pode assumir que ele está sempre em determinado lugar ou outras coisas em determinados lugares (como /bin) ou pode assumir que ele está instalado no local especificado pelo --prefix. Embora o último possa ser contornado por esses projetos, o primeiro requer correções no código fonte.
Maciej Piechotka
Outra opção no prefixo do Gentoo, Rootless e Nix é o pkgsrc . Ele vem do NetBSD, mas funciona em uma variedade de plataformas.
Michael Ekstrand
2
Pacotes binários são compilados com a suposição de que eles serão instalados em locais específicos em/ Isso soa como um requisito que poderia ser justificado talvez 30 anos atrás, mas não agora. Por exemplo, o envprograma não pretende solucionar esse tipo de problema? Caso contrário, é fácil criar um esquema para configurar qualquer binário para procurar outros binários em locais específicos.
Piotr Dobrogost
11
@PiotrDobrogost até certo ponto sim, até certo ponto não. Por exemplo, não há variável de ambiente para /etcou (de acordo com o meu conhecimento) /usr/lib/<packagename>/ou /usr/libexec/<packagename>/. /usr/sharepode ser alterado por variáveis ​​XDG que foram lançadas em algum momento deste século e não são necessariamente adotadas para programas mais antigos.
Maciej Piechotka 28/08/2015
28

Há um projeto de gerenciador de pacotes - Nix - com uma ideia fundamental interessante (um gerenciador de pacotes " funcional "), que também suporta uma operação por usuário:

Suporte multiusuário

A partir da versão 0.11, o Nix possui suporte para vários usuários. Isso significa que usuários sem privilégios podem instalar software com segurança. Cada usuário pode ter um perfil diferente, um conjunto de pacotes na loja Nix que aparecem no PATH do usuário. Se um usuário instalar um pacote que outro usuário já tenha instalado anteriormente, o pacote não será criado ou baixado uma segunda vez. Ao mesmo tempo, não é possível que um usuário injete um cavalo de Tróia em um pacote que possa ser usado por outro usuário.

UMA NOTA QUE EU QUERO ADICIONAR: Nix deve ser utilizável em um sistema semelhante ao Unix de sua escolha (por exemplo, uma distribuição Linux).

Também há uma grande coleção de pacotes associados que podem ser instalados com o gerenciador de pacotes Nix - Nixpkgs --built para várias plataformas :

  • GNU / Linux no x86 de 32 e 64 bits (i686-linux e x86_64-linux)
  • Mac OS X (i686-darwin e x86_64-darwin)
  • FreeBSD (i686-freebsd e x86_64-freebsd)
  • OpenBSD (i686-openbsd)
  • Windows / Cygwin (i686-cygwin),

e uma distribuição associada-- NixOS :

NixOS é uma distribuição Linux baseada no Nix. Ele usa o Nix não apenas para gerenciamento de pacotes, mas também para gerenciar a configuração do sistema (por exemplo, para criar arquivos de configuração em / etc). Isso significa, entre outras coisas, que é possível reverter facilmente toda a configuração do sistema para um estado anterior. Além disso, os usuários podem instalar software sem privilégios de root. Consulte Mais informação…

e um sistema de construção "contínuo" associado - Hydra .

imz - Ivan Zakharyaschev
fonte
4
Bom resumo. Recentemente, o GNU Guix foi anunciado. Gerenciador de pacotes GNU baseado em nix. savannah.gnu.org/forum/forum.php?forum_id=7436
Davorak 29/11
2
@ Davorak Quais são as diferenças entre nixe guix. Como agora estou realmente usando nixmeu trabalho, quero saber se posso considerar guixoutra implementação da ferramenta necessária. Posso ler um resumo das diferenças em algum lugar? Talvez você possa até escrever uma resposta com esse resumo aqui, anunciando mais uma solução alternativa?
IMZ - Ivan Zakharyaschev
6

Primeiro de tudo, é devido a dependências. Alguns pacotes podem não ser instalados pelo PolicyKit, como o usuário. Portanto, seria necessário um encargo adicional para o empacotador que doar seu tempo livre e geralmente instalar o programa é tão fácil quanto digitar sudo(estação de usuário único) ou administrador persistente.

Existem opções para instalação no $ HOME

  • Os 'gerenciadores de pacotes' primitivos da linguagem geralmente o suportam imediatamente (como gem para Ruby ou cabal para Haskell) ou com pequenos ajustes (esqueci o nome de python)
  • Boa idade ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(ou variedades como jhbuild).
  • Havia um programa para instalar no $ HOME alguns anos atrás. No entanto, não consigo encontrá-lo - acho que quase ninguém o usou, pois eles próprios os instalaram ou importunaram os administradores.
Maciej Piechotka
fonte
11
Realmente não vejo como esse argumento é convincente. Só porque um pacote não funciona, pois não é chamado como root, não significa que a ideia não seja viável. Espera-se que o PolicyKit não funcione para esse tipo de situação. Existem muitos outros pacotes que podem ser instalados sem privilégios de root. Eu conheço os gerenciadores de pacotes de software (o Python é o EasyInstall), mas eles não são aplicáveis ​​globalmente como o yum ou o apt-get. Alguém sabe o nome do programa ao qual Maciej está se referindo?
elmt
11
@elmt: Possivelmente arrumar , o que pode lhe interessar de qualquer maneira (mas é uma ferramenta, não uma fonte de pacote).
Gilles 'SO- stop be evil' (
@ Gilles: Não - tinha GUI e era para ser 'simples'. Eu acho que a direção atual é mais do synaptic / packagekit.
Maciej Piechotka
6

Eu uso o JuJu, que basicamente permite ter uma distribuição linux realmente minúscula (contendo apenas o gerenciador de pacotes) dentro do diretório $ HOME / .juju.

Ele permite que seu sistema personalizado dentro do diretório inicial seja acessível via proot e, portanto, você pode instalar qualquer pacote sem privilégios de root. Ele será executado corretamente em todas as principais distribuições Linux, a única limitação é que o JuJu pode ser executado no kernel Linux com a versão mínima recomendada 2.6.32.

user967489
fonte
4

Outro com um modelo bastante diferente é o 0install . É baseado na idéia de que você realmente não instala pacotes, mas apenas os executa a partir de um espaço de nomes global que baixa, compila, se necessário, e armazena em cache o software que você deseja usar.

Michael Ekstrand
fonte
4

Se você está bem com a compilação a partir da origem e a resolução de dependências, querendo principalmente que o gerenciador de pacotes lide com as operações de implantação / remoção da implementação / atualização, você pode dar uma olhada no GNU Stow ou no XStow um pouco aprimorado . Com eles, você prepara a instalação para um diretório separado (normalmente abaixo $PREFIX/stow) e, em seguida, armazena links simbólicos para o software a partir do seu prefixo real. Isso facilita a remoção completa do software. Uso-o com êxito para gerenciar meu software instalado na minha universidade.

Michael Ekstrand
fonte
3

Minha experiência é realmente limitada ao yum, mas não entendo por que não seria possível soltar um arquivo de repo em ~ / etc / yum.repos.d e fazer com que o yum instalasse tudo em uma conta doméstica.

Os principais gerenciadores de pacotes do Linux veem o mundo como um administrador de sistemas ... onde a máquina é uma entidade única. Isso permite que você obtenha respostas para perguntas como "quais erratas pendentes se aplicam ao sistema X" e "como o sistema X e o sistema Y diferem". Isso também permite que o yum tenha "um histórico" que seja utilizável, tenha versões rpmdb e faça coisas como "yum --security update" etc.

Existem alguns gerenciadores de pacotes, como a instalação zero, que tentam ver o mundo como um usuário faria ... ie. o que aplicações fazer eu ter acesso.

Você pode pensar que o posterior é um modelo melhor, mas IMNSHO há um motivo pelo qual você nunca ouviu falar de instalação zero, mas ouviu falar do yum.

James Antill
fonte
2

Há um garoto novo no bloco: " JuNest ( Jailed User NEST) - a distribuição baseada no Arch Linux que roda em qualquer distribuição Linux sem acesso root." @ https://github.com/fsquillace/junest O Advantage é que ele não introduz um novo tipo de formato de pacote; portanto, após uma instalação muito fácil (no mínimo: cerca de 320 milhões), o repositório completo do Arch Linux (mais de 13.000 pacotes ATM) está ao seu alcance.

eMPee584
fonte
1

As ferramentas usadas pelo Slackware, especificamente installpkg, podem. Na página do manual:

--root /otherroot
       Install using a location other than / (the default) as the root of the 
       filesystem to install on. In the example given, use /otherroot instead.
       Setting the ROOT environment variable does the same thing.

No entanto, eu não conheço nenhuma das melhores interfaces que são capazes de fazer isso (por exemplo slapt-get, tanto quanto eu sei, não é possível). Teoricamente, você deve ser capaz de criar um alias installpkgpara installpkg --root ~/Apps- no entanto, acho que a maioria dos frontends exige root para executar, o que derrota o ponto.

new123456
fonte
1

Eu sugiro http://linuxbrew.sh/

É basicamente uma bifurcação para o macOS e possui binários pré-compilados para uso ...

Especialmente bom para lidar com versões mais antigas do gcc.

Se você realmente deseja instalar manualmente, um guia útil é http://www.linuxfromscratch.org/

HaoZeke
fonte
0

O Yum precisa gravar no banco de dados, que é próprio da raiz. Por isso, você não pode usá-lo como um usuário normal.

Você pode tentar descompactar arquivos rpm (rpm2cpio package.rpm | cpio -idmv) dentro de um diretório de sua escolha.

Porém, quando você executar o seu programa, precisará modificar o LD_LIBRARY_PATH para carregar as bibliotecas dependentes. Além disso, isso não cuidará de nenhuma dependência.

Exemplo:

# mkdir new_root
# cd new_root
# wget ftp://mirror.switch.ch/pool/4/mirror/centos/6.7/os/x86_64/Packages/vim-enhanced-7.4.629-5.el6.x86_64.rpm
# rpm2cpio vim-enhanced-7.4.629-5.el6.x86_64.rpm | cpio -idmv
# ./usr/bin/vim -version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jul 24 2015 02:23:23)

O acima não tem bibliotecas dependentes, caso contrário você teria que usar algo como:

export LD_LIBRARY_PATH=./usr/lib ./usr/bin/program
cristi
fonte