|
Director de sesión en el aula - GNU/Linux & UNIXProfesor Alejandro de la Torre |
|
Otros
términos: free software, código
abierto, sofware libre.
El administrador de sistemas debe comprender que bajo estas cuatro denominaciones se reúnen varias cosas:
En este gráfico, "Gestor de paquetes" es cualquier herramienta que gestione el software contenido en el repositorio y haga todo lo que necesita un administrador de sistemas. Existen multitud de gestores de paquetes que funcionan tanto en la línea de órdenes de una shell como en entornos gráficos pero sea cual sea la herramienta, en última instancia, estarán utilizando el conjunto de comandos básicos proporcionados por el propio formato, son las respectivas familias de comandos rpm, dpkg, emerge, pacman. Normalmente, una u otra familia está disponible por defecto en la distribución GNU/Linux que usemos, consultar las páginas de manual para los detalles.
RPM y DPKG los de mayor implantación
A partir de este punto vamos a tratar sólo los subsistemas de gestión de software más implantados, dígase RPM y DPKG. Entre las herramientas que ambos proporcionan hay que destacar los front-end específicos: En el caso de repositorios DPKG contamos con la familia de herramientas apt, y en el caso de RPM con dnf. Ambas permiten una gestión inteligente y muy potente del software desde la línea de órdenes. Estas herramientas deben ser las principales referencias del administrador de sistema. A continuación se muestra una tabla con las tareas más comunes con ellas:
Tarea |
con APT |
con YUM |
Actualiza el índice local de los repositorios de referencia. |
apt update |
dnf |
Instala un paquete y todas sus dependencias. |
apt install <paquete> |
dnf install <paquete> |
Elimina un paquete. |
apt remove <paquete> |
dnf remove <paquete> |
Actualiza un paquete a su versión más reciente. |
apt upgrade <paquete> |
dnf update <paquete> |
Para terminar con este apartado de "Trabajando con repositorios" se mencionan los nombres de herramientas de cursor o gráficas que hacen el mismo trabajo que APT y DNF pero de una forma más cómoda y vistosa. Para repositorios Debian: dselect (ncurses), aptitude (ncurses) synaptic (GUI). Para repositorios RPM: pirut (GUI), pup (GUI), yumex (GUI), kyum (GUI).
alien es una herramienta que convierte un paquete deb en rpm y viceversa. Muy útil.
Trabajar con repositorios es la opción más práctica cuando de gestionar el software de un sistema GNU/Linux-Unix se trata pero limita en lo siguiente:
Las versiones de los paquetes disponibles son invariables, así como la compilación y estructuración de los mismos, digamos que cuando se libera una determinada versión de una distribución va acompañada de repositorios de software cerrados (foto fija en el momento de su lanzamiento). El mantenimiento de estos repositorios consiste en reparar errores conocidos y aplicar parches de seguridad, pero no en sumar mejoras y nuevas funcionalidades experimentadas por la versión original del software allí contenido.
El software disponible está limitado a la decisión de los creadores de la distro, podría darse el caso de necesitar en nuestro sistema un determinado aplicativo y NO TENERLO en el repositorio.
Para salvar estas limitaciones, el administrador del sistema debe recurrir al CODIGO FUENTE.
Trabajar con el código fuente permite instalar software en cualquier sistema, sea cual se su arquitectura, no dependemos de los repositorios ni de la distro que tengamos, en contrapartida, es más laborioso, requiere de un conocimiento técnico más amplio y capacidad de resolver situaciones que detienen el proceso (p.e. resolver una dependencia no documentada), en resumen, independencia + últimas versiones + catálogo de software completo a precio de trabajo y conocimiento.
Antes de proceder con el código fuente el sistemas tiene que estar dotado de las herramientas y los complementos que necesita este procedimiento, a saber:
Compilador C (o del lenguaje en el que esté construido el código fuente).
Librerías básicas C (API de los programas GNU).
Librerías de cabeceras de Linux (API del Kernel).
Librerías de desarrollo de terceros (API de productos - BBDD, servicios).
Resuelto y verificado lo anterior el procedimiento a seguir se describe a continuación. Son pasos obligatorios, no se puede saltar ninguno. Para ilustrar cada paso se irán realizando con las fuentes del proyecto ProFTPD.
1.- Obtención del código fuente descargándolo de la red: Lo habitual es que los constructores lo proporcionen en servidores HTTP o FTP en forma de meta-paquetes comprimidos: <archivo>.tar.gz, <archivo>.tar.Z, <archivo>.tar.bz2
2.- Verificar la descarga comparando
las claves md5, sha o pgp. Los desarrolladores suelen
proporcionar uno o más de estos tres métodos. Ejemplo
de uso con md5: md5sum -c
fichero_con_los_pares.md5sum (se ejecuta después de
descargar el tarball y la propuesta md5sum del
constructor)
3.- Descomprimir el meta-paquete:
4.- Desempaquetar el meta-paquete:
tar -xvf <archivo>.tar
5.- Lectura de la "documentación rápida", disponible normalmente en los archivos README o INSTALL.
6.- Configuración: ./configure
7.- Compilación: make
8.- Instalación: make install
9.- Ejecución
- Con objeto de consolidar el procedimiento anterior se repitrá con la fuente del producto apache web server. En este caso el alumo se encontrará con la necesidad de resolver dependencias, para ello, instalará lo que necesite desde los repositorios de la distro.
- Es necesario utilizar comandos básicos (dpkg o rpm).
- No se resuelven dependencias. Sólo se avisa y el administrador se ocupa de arreglarlo.
- La instalación de un paquete aislado SÍ genera información sobre la base de datos local (dpkgdb - rpmdb).
- apt-get -f install resuelve dependencias provocadas por dpkg -i.
- yum install <paquete>.rpm hace las veces del rpm -i resolviendo dependencias.
Cada vez cobran más fuerza los sistemas de gestión de paquetes independiente de las distribuciones. Con estos sistemas se puede instalar cualquier programa y librería con el mismo archivo y procedimiento, ya estuviéramos en Gentoo, Slackware o Lubuntu. Hay varios sistemas, los más relevantes en la actualidad son estos:
- Snap
- Son contenedores de soluciones finales. Contienen el aplicativo propio de la función que se se desea instalar, las dependencias y las librerias (API,s). Son indpendientes de la distribución dónde se instalen ya que funcionan como células de sólo lectura una vez ubicadas. Necesitan de la instalación previa de las herramientas snap desde el REPOSITORIO de la distribución (snap tool, snapd daemon y lo que pueda aparecer en el futuro).
- AppImage
- Flatpak