El sistema de parcheado

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:~#