Gerentes de paquetes no root

51

De mi investigación, me parece notar que todos los administradores de paquetes insisten en ser utilizados como usuarios privilegiados y deben instalarse en ellos /.

Por lo general, lo que me gusta hacer es crear una cuenta de usar y tirar, compilar algún software e instalar $HOMEpara esa cuenta. Puedo probar una variedad de configuraciones y luego, cuando termine, simplemente destruya la cuenta.

Sin embargo, compilar software se vuelve tedioso.

Mi experiencia realmente se limita a yum, pero no entiendo por qué no podría colocar un archivo de repositorio ~/etc/yum.repos.dy hacer que instale todo en una cuenta doméstica.

¿Hay alguna razón por la cual los administradores de paquetes se deben utilizar como usuarios privilegiados para instalar software?

elmt
fuente

Respuestas:

35

Los paquetes binarios se compilan con el supuesto de que se instalarán en ubicaciones específicas en /. Esto no siempre se cambia fácilmente, y se necesitaría un esfuerzo adicional de control de calidad (¡lo cual es bastante difícil en primer lugar!) Para determinar si los archivos binarios específicos son o no reubicables.

Hasta cierto punto, puede usar cosas como fakechroot para crear un sistema completo en un subdirectorio como usuario no root, pero esto es tedioso y frágil.

Tendrás mejor suerte con los paquetes fuente. Gentoo Prefix y Roboless GoboLinux son dos administradores de paquetes que pueden instalarse en /ubicaciones que no son y pueden ser utilizados por personas que no sean rootusuarios.

efímero
fuente
3
Añadiría que hay 2 tipos de reubicación. El paquete puede suponer que siempre está en cierto lugar u otras cosas están en ciertos lugares (como /bin) o puede suponer que está instalado en el lugar especificado por --prefix. Mientras que el último puede ser evitado por esos proyectos, el primero requiere parches en el código fuente.
Maciej Piechotka
Otra opción a la Gentoo Prefix, Rootless y Nix es pkgsrc . Proviene de NetBSD pero funciona en una variedad de plataformas.
Michael Ekstrand
2
Los paquetes binarios se compilan con el supuesto de que se instalarán en ubicaciones específicas en/ Esto suena como un requisito que podría estar justificado quizás hace 30 años, pero no ahora. ¿No es, por ejemplo, el envprograma destinado a resolver este tipo de problemas? Si no, es fácil crear un esquema para configurar cualquier binario para buscar otros binarios en ubicaciones específicas.
Piotr Dobrogost
1
@PiotrDobrogost hasta cierto punto sí, hasta cierto punto no. Por ejemplo, no hay una variable de entorno para /etco (según mi conocimiento) /usr/lib/<packagename>/o /usr/libexec/<packagename>/. /usr/sharepuede ser cambiado por las variables XDG que se han lanzado en algún momento de este siglo y no necesariamente se adoptan para programas más antiguos.
Maciej Piechotka
28

Hay un proyecto de administrador de paquetes, Nix, con una idea fundamental interesante (un administrador de paquetes " funcional "), que también admite una operación por usuario:

Soporte multiusuario

A partir de la versión 0.11, Nix tiene soporte para múltiples usuarios. Esto significa que los usuarios sin privilegios pueden instalar software de forma segura. Cada usuario puede tener un perfil diferente, un conjunto de paquetes en la tienda Nix que aparecen en la RUTA del usuario. Si un usuario instala un paquete que otro usuario ya ha instalado anteriormente, el paquete no se compilará ni descargará por segunda vez. Al mismo tiempo, no es posible que un usuario inyecte un caballo de Troya en un paquete que pueda ser utilizado por otro usuario.

UNA NOTA QUE QUIERO AGREGAR: Nix debe ser utilizable en un sistema tipo Unix de su elección (por ejemplo, una distribución de Linux).

También hay una gran colección de paquetes asociados que se pueden instalar con el administrador de paquetes de Nix, Nixpkgs, creados para varias plataformas :

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

y una distribución asociada-- NixOS :

NixOS es una distribución de Linux basada en Nix. Utiliza Nix no solo para la gestión de paquetes, sino también para gestionar la configuración del sistema (por ejemplo, para crear archivos de configuración en / etc). Esto significa, entre otras cosas, que es posible revertir fácilmente toda la configuración del sistema a un estado anterior. Además, los usuarios pueden instalar software sin privilegios de root. Lee mas…

y un sistema de construcción "continuo" asociado: Hydra .

imz - Ivan Zakharyaschev
fuente
44
Buen resumen Recientemente se anunció GNU Guix. Gestor de paquetes GNU basado en nix. savannah.gnu.org/forum/forum.php?forum_id=7436
Davorak
2
@Davorak ¿Cuáles son las diferencias entre nixy guix. Como ahora estoy realmente usando nixpara mi trabajo, quiero saber si podría considerar guixcomo otra implementación de la herramienta que necesito. ¿Puedo leer un resumen de las diferencias en alguna parte? Tal vez, ¿podría incluso escribir una respuesta con tal resumen aquí, anunciando una solución alternativa más?
imz - Ivan Zakharyaschev
6

En primer lugar, se debe a dependencias. Algunos paquetes pueden no ser instalados por el usuario, como PolicyKit. Por lo tanto, requeriría una carga adicional para el empaquetador que dona su tiempo libre y, por lo general, la instalación del programa es tan fácil como escribir sudo(estación de usuario único) o administrador molesto.

Hay opciones para instalar en $ HOME

  • Los 'gestores de paquetes' primitivos del lenguaje generalmente lo admiten fuera de la caja (como gema para Ruby o cabal para Haskell) o con pequeños ajustes (olvidé el nombre para python)
  • Bien viejo ./configure --prefix=$HOME/sandbox --enable-cool-feature && make all install(o variaciones como jhbuild).
  • Hubo un programa para instalar en $ HOME hace unos años. Sin embargo, no puedo encontrarlo, supongo que casi nadie lo usó ya que los instalaron ellos mismos o molestaron a los administradores.
Maciej Piechotka
fuente
1
Realmente no veo cómo este es un argumento convincente. El hecho de que un paquete no funcione, ya que no se invoca como raíz, no significa que la idea no sea factible. Se espera que PolicyKit no funcione para este tipo de situación. Hay muchos otros paquetes que se pueden instalar sin privilegios de root. Soy consciente de los administradores de paquetes de software (Python es EasyInstall), pero no son aplicables globalmente como lo son yum o apt-get. ¿Alguien sabe el nombre del programa al que se refiere Maciej?
elmt
1
@elmt: Posiblemente estibar , que pueden interesarle todos modos (pero es una herramienta, no una fuente de paquetes).
Gilles 'SO- deja de ser malvado'
@Gilles: No, tenía GUI y estaba destinado a ser 'simple'. Supongo que la dirección actual es más sináptica / paquete de paquetes.
Maciej Piechotka
6

Uso JuJu, que básicamente permite tener una distribución de Linux realmente pequeña (que contiene solo el administrador de paquetes) dentro de su directorio $ HOME / .juju.

Permite tener su sistema personalizado dentro del directorio de inicio accesible a través de proot y, por lo tanto, puede instalar cualquier paquete sin privilegios de root. Se ejecutará correctamente en todas las distribuciones principales de Linux, la única limitación es que JuJu puede ejecutarse en el núcleo de Linux con la versión mínima recomendada 2.6.32.

usuario967489
fuente
4

Otro con un modelo bastante diferente es 0install . Se basa en la idea de que realmente no instala paquetes, sino que simplemente los ejecuta desde un espacio de nombres global que descarga, compila si es necesario y almacena en caché el software que desea utilizar.

Michael Ekstrand
fuente
4

Si está bien compilando desde el origen y resolviendo dependencias usted mismo, principalmente desea que el administrador de paquetes maneje las operaciones de despliegue / despliegue / actualización, es posible que desee echar un vistazo a GNU Stow o al XStow algo mejorado . Con ellos, organiza la instalación en un directorio separado (generalmente debajo $PREFIX/stow) y luego almacena enlaces simbólicos al software desde su prefijo real. Esto facilita la eliminación del software por completo. Lo uso con éxito para administrar mi software personalizado instalado en mi universidad.

Michael Ekstrand
fuente
3

Mi experiencia se limita a yum, pero no entiendo por qué no podría dejar un archivo de repositorio en ~ / etc / yum.repos.d y hacer que yum instale todo en una cuenta doméstica.

Los principales administradores de paquetes de Linux ven el mundo como lo haría un administrador de sistemas ... donde la máquina es una sola entidad. Esto le permite obtener respuestas a preguntas como "qué erratas pendientes se aplican al sistema X" y "cómo difieren el sistema X y el sistema Y". Esto también le permite a yum tener "un historial" que se puede usar, tener versiones rpmdb y hacer cosas como "yum --security update", etc.

Hay algunos administradores de paquetes, como zero-install, que intentan ver el mundo como lo haría un usuario ... es decir. lo que las aplicaciones de hacer que tienen acceso.

Puede pensar que el último es un mejor modelo, pero IMNSHO hay una razón por la que no ha oído hablar de la instalación cero pero sí de yum.

James Antill
fuente
2

Hay un nuevo chico en el bloque: " JuNest ( Jailed User NEST): la distribución basada en Arch Linux que se ejecuta en cualquier distribución de Linux sin acceso a la raíz". @ https://github.com/fsquillace/junest Advantage es que no introduce un nuevo tipo de formato de paquete, así que después de una instalación muy fácil (mínimo: aproximadamente 320M), el repositorio completo de Arch Linux (más de 13000 paquetes ATM) está a su alcance.

eMPee584
fuente
1

Las herramientas utilizadas por Slackware, específicamente installpkg, pueden. Desde la página del 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.

Sin embargo, no conozco ninguna de las mejores interfaces que puedan hacer esto (por ejemplo slapt-get, hasta donde yo sé, no pueden hacer esto). Teóricamente, deberías poder usar alias installpkgpara installpkg --root ~/Apps, sin embargo, creo que la mayoría de las interfaces requieren que se ejecute root, lo que frustra el punto.

nuevo123456
fuente
1

Sugeriría http://linuxbrew.sh/

Básicamente es una bifurcación de brebaje para macOS y tiene binarios precompilados para su uso ...

Especialmente bueno para manejar versiones anteriores de gcc.

Si realmente desea instalar a mano, una guía útil es http://www.linuxfromscratch.org/

Haozeke
fuente
0

Yum necesita escribir en la base de datos, que es propia de root. Debido a esto, no puede usarlo como un usuario normal.

Puede intentar descomprimir archivos rpm (rpm2cpio package.rpm | cpio -idmv) dentro de un directorio de su elección.

Pero cuando ejecute su programa, deberá modificar LD_LIBRARY_PATH para cargar las bibliotecas dependientes. Además, esto no se encargará de ninguna dependencia.

Ejemplo:

# 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)

Lo anterior no tiene ninguna biblioteca dependiente, de lo contrario, tendría que usar algo como:

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