A la hora de hablar de actualizaciones en Linux debemos distinguir entre la
actualización del núcleo del operativo y la de las diferentes aplicaciones
del sistema. Esta última no es en ningún momento algo tan estándar como
lo pueda ser en Unices comerciales como Solaris o AIX debido a que no hay un
único modelo de Linux en el mercado, sino que existen diferentes clones de
este operativo, y a pesar de que todos son `Linux' en cada uno de ellos se
trabaja de forma diferente. Por contra, si lo que se va a actualizar es el
núcleo de Linux en cualquiera de ellos se procede de la misma forma, ya que
el kernel es común a todas las distribuciones. Vamos a hablar primero
brevemente de los diferentes métodos de actualización de aplicaciones en
función del Linux utilizado y después comentaremos aspectos de
actualización y parcheado del núcleo.
En Red Hat, y en todos los Linux basados en esta distribución (Mandrake,
Caldera...) el software se suele descargar precompilado desde Internet
en un formato especial denominado RPM (Red Hat Package Manager),
que permite al administrador de un sistema instalar y desinstalar programas,
así como verificar versiones del software instalado en la
máquina; podemos encontrar una extensa descripción de este formato en
[Bai97], aunque la idea más elemental acerca del mismo es que se trata
de un sistema de gestión (instalación, actualización, borrado...) de
software capaz de hacer comprobaciones de dependencia entre paquetes,
ejecutar programas de pre y postinstalación y detectar y solventar cierto tipo
de conflictos entre diferentes paquetes o diferentes versiones del mismo.
Actualizar versiones de software mediante rpm es una tarea
sencilla: normalmente el administrador no tiene más que ejecutar `rpm
-U', orden
que se encargará de instalar la nueva versión y eliminar la antigua (si
existe); es equivalente a ejecutar primero una instalación (`rpm -i')
del paquete actualizado y después un borrado (`rpm -e') de la
versión anteriormente instalada en la máquina. Lo más habitual es ver en
primer lugar
la versión concreta de un paquete soft instalado en la máquina,
mediante `rpm -q' (`rpm -qa' nos mostrará un listado de todos y
cada uno de los paquetes instalados):
rosita:~# rpm -q libpcap
libpcap-0.4-10
rosita:~#
Tras esto podemos conseguir una versión actualizada (el paquete en formato
RPM del software que nos interese) e instalarla mediante las
órdenes vistas anteriormente:
rosita:~# ls -l libpcap-0.4-19.i386.rpm
-rw-r--r-- 1 root root 56554 Feb 18 03:54 libpcap-0.4-19.i386.rpm
rosita:~# rpm -U libpcap-0.4-19.i386.rpm
rosita:~# rpm -q libpcap
libpcap-0.4-19
rosita:~#
Por su parte, en Debian y derivados, la actualización de software se
puede llevar a cabo mediante `dpkg', que permite instalar, configurar y
eliminar paquetes; no obstante, su uso - al menos de forma
directa - hoy en día es poco habitual debido a la existencia de otra
herramienta denominada APT (Advanced Package Tool),
posiblemente el mecanismo de instalación y actualización de software
más cómodo de cuantos existen en Linux. La principal interfaz entre este
sistema y el usuario es `apt-get', herramienta de línea de
órdenes cuyo funcionamiento se basa especialmente en el fichero /etc/apt/sources.list, que como su nombre indica es un registro de las fuentes
desde las que se pueden obtener paquetes actualizados.
Los paquetes de software en Debian suelen tener un nombre finalizado
en `.deb', que realmente es un `.ar' con algunas modificaciones;
para obtener un listado actualizado de los paquetes disponibles en las
diferentes ubicaciones indicadas en /etc/apt/sources.list no tenemos
más que ejecutar la orden `apt-get update' (algo recomendable cada vez
que se modifique el fichero de fuentes), que conectará a cada una
de dichas ubicaciones y descargará la lista de paquetes actualizados; esta
orden no instala esos paquetes, por lo que a continuación deberemos ejecutar
`apt-get install' o, directamente `apt-get upgrade' para actualizar
las versiones del software ya instalado:
rosita:~# apt-get upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
rosita:~#
Tanto Red Hat como Debian proporcionan mecanismos para verificar - hasta
cierto punto - la integridad de cada paquete instalado; realmente, más que
la integridad, podríamos hablar de las modificaciones sufridas por
archivos instalados a partir de un paquete con respecto a los originales (qué
ficheros han sido modificados desde la instalación), ya que no se trata de
comprobaciones de integridad que nos permitan decir si un paquete ha sido
troyanizado o no, sino simples verificaciones de presencia de ficheros
modificados. Como casi siempre, para comprobar realmente la autenticidad del
software debemos recurrir a funciones resumen tipo MD5.
El Linux más arcaico (pero no por ello el peor, ni mucho menos) a
la hora de actualizar software es Slackware; en esta distribución de
Linux el formato de paquete es sin duda el más estándar de todos: el
software se distribuye en ficheros .tgz, que no son más que
archivos .tar.gz compatibles con cualquier Unix, con unas pequeñas
modificaciones para poderlos instalar mediante installpkg, un sencillo
shellscript. En cualquier caso, ni siquiera suele ser necesaria esta
utilidad para instalar ficheros .tgz: es suficiente con desempaquetarlos
y descomprimirlos desde el directorio raíz de la máquina.
En Slackware podemos utilizar el comando upgradepkg para actualizar un
paquete de software determinado; esta orden no es más que otro shellscript que instala el paquete nuevo y
elimina los ficheros de la versión antigua que no existan en la nueva. Sin
embargo, entre los administradores de Slackware - me incluyo en el grupo - es
mucho más habitual descargar el código fuente de la aplicación a
actualizar, compilarlo e instalarlo por encima de la versión antigua (o
eliminar esta primero, de forma manual).
En cuanto al kernel de Linux y su actualización, como antes hemos
comentado, si lo que queremos es actualizar o parchear el
núcleo del sistema operativo la forma de hacerlo ya no es tan dependiente de
la versión de Linux utilizada. Para actualizar la versión del kernel
tenemos dos opciones: o descargamos el código fuente de la nueva versión,
de forma completamente independiente de la que tengamos en estos momentos, o
descargamos un parche que al ser aplicado nos modificará el código
instalado ya en nuestro sistema para convertirlo en la nueva versión; en ambos
casos debemos compilar y arrancar con la imagen generada si queremos que el
sistema quede actualizado.
Si hemos descargado un nuevo kernel completo (generalmente un fichero
.tar.gz) no tenemos más que descomprimirlo, desempaquetarlo y
compilarlo para generar una nueva imagen con el nuevo núcleo; evidentemente
no vamos a entrar ahora en como configurar o compilar el kernel de Linux:
para eso hay excelentes documentos disponibles en la red.
Más interesante es la aplicación de parches al código fuente, bien para
incrementar la versión del núcleo, como ya hemos dicho, o bien para aplicar
una modificación `no oficial' distribuida como parche; en este último caso
- cada vez menos utilizado, debido al desarrollo de los módulos cargables
en tiempo de ejecución - hemos de tener cuidado, ya que al aplicar un parche
no oficial es muy probable que si posteriormente deseamos incrementar la
versión de nuestro kernel también mediante parcheado del código,
este último no funcione correctamente.
Lo más habitual es que cualquier parche para el código fuente del
núcleo, tanto oficial como `no oficial', se distribuya como un simple fichero
de texto (en muchos casos comprimido con gzip) que contiene las diferencias
entre el código actual y el modificado, generadas con diff; podemos
verificarlo simplemente echando un vistazo al fichero que acabamos de descargar:
luisa:/usr/src# gzip -dc patch-2.2.14.gz|head -4
diff -u --recursive --new-file v2.2.13/linux/CREDITS linux/CREDITS
--- v2.2.13/linux/CREDITS Tue Jan 4 11:24:09 2000
+++ linux/CREDITS Tue Jan 4 10:12:10 2000
@@ -137,12 +137,9 @@
luisa:/usr/src#
Si este es nuestro caso, para aplicar el parche no tenemos más que utilizar
la orden `patch':
luisa:/usr/src# gzip -dc patch-2.2.14.gz | /usr/bin/patch -p0
Si el proceso ha sido correcto, el código fuente que en nuestro ejemplo antes
correspondía al núcleo 2.2.13 ahora corresponde al 2.2.14; como antes,
no tenemos más que recompilar ese código y arrancar con la imagen generada
para que nuestro kernel sea el nuevo:
luisa:~# uname -a
Linux luisa 2.2.14 #9 Sat Dec 30 03:34:32 CET 2000 i686 unknown
luisa:~#
© 2002 Antonio Villalón Huerta
