En los sistemas HP-UX la gestión de software, tanto paquetes como parches, se puede llevar a cabo de una forma sencilla mediante la familia de comandos sw: swinstall, swlist, swremove...; a este sistema de gestión se le denomina SD-UX (Software Distributor HP-UX), y a pesar de estar basado en una tecnología distribuida cliente-servidor permite únicamente la gestión en la máquina local. Para obtener más información sobre el funcionamiento de SD-UX es recomendable consultar [HP96].
Igual que sucedía en AIX, HP-UX posee una terminología propia para referirse a los diferentes objetos del Software Distributor. El objeto más pequeño manejado por SD-UX es el fileset, que no es más que un subconjunto de los diferentes ficheros que forman un producto, que a su vez es un conjunto de filesets estructurado de cierta forma, en el que se incluyen scripts de control para facilitar su manejo como un único objeto. HP-UX suele manejar sus parches a nivel de producto: un parche es un producto que puede estar formado por diferentes filesets, aunque lo más normal es que lo esté por uno solo; si no fuera así, y descargáramos un parche formado por varios filesets, es recomendable instalar todos como un único producto: aunque SD-UX permite el manejo de parches a nivel de filesets individuales, aplicar sólo algunos de ellos puede provocar que la vulnerabilidad que el parche ha de solucionar permanezca en el sistema ([HP00a].
El siguiente nivel de software es el bundle, un objeto manejado por SD-UX que agrupa diferentes productos y filesets relacionados entre sí, consiguiendo de esta forma una gestión de software más cómoda: por ejemplo, podemos utilizar bundles de parches para actualizar nuestro sistema, sin necesidad de descargar e instalar cada uno de esos parches de forma individual. Por último, en SD-UX se introduce el concepto de depot, un almacén de software en forma de directorio, cinta, CD-ROM o fichero único, que permite la instalación local o remota de sus contenidos: por ejemplo, el directorio /var/adm/sw/products/ puede ser considerado un depot, que a su vez contiene productos en forma de subdirectorios, que a su vez contienen filesets también en forma de subdirectorio, como veremos en el próximo ejemplo; mediante la orden swcopy podemos crear nuestros propios depots, que nos facilitarán la tarea de gestionar el software de diferentes sistemas.
Todo el software instalado en una máquina queda registrado en un catálogo denominado IPD (Installed Products Database), que se encuentra en el directorio /var/adm/sw/products/. Por ejemplo, para obtener un listado de los filesets instalados en la máquina relacionados con el producto accounting, junto a la versión de los mismos podemos utilizar la orden swlist o simplemente consultar la IPD con comandos como ls o cat (por supuesto, la primera forma es la recomendable):
marta:/# swlist -l fileset Accounting
# Initializing...
# Contacting target "marta"...
#
# Target: marta:/
#
# Accounting B.10.20 Accounting
Accounting.ACCOUNTNG B.10.20
Accounting.ACCT-ENG-A-MAN B.10.20
marta:/# cd /var/adm/sw/products/Accounting
marta:/var/adm/sw/products/Accounting/# ls
ACCOUNTNG ACCT-ENG-A-MAN pfiles
marta:/var/adm/sw/products/Accounting/# grep ^revision ACC*/INDEX
ACCOUNTNG/INDEX:revision B.10.20
ACCT-ENG-A-MAN/INDEX:revision B.10.20
marta:/var/adm/sw/products/Accounting/#
Como hemos dicho, también mediante la orden swlist podemos obtener un listado de los parches aplicados a nuestro sistema HP-UX a nivel de aplicación; de nuevo, podríamos conseguir esta información accediendo directamente a /var/adm/sw/products/:
marta:/# swlist -l fileset -a patch_state |grep PH|grep -v ^\#|head -3
PHCO_10124.PHCO_10124
PHCO_10175.PHCO_10175
PHCO_10272.PHCO_10272
marta:/#
Para obtener los parches aplicados al núcleo del sistema operativo podemos utilizar la orden `what' sobre el kernel de HP-UX:
marta:/# what /stand/vmunix|grep PH |head -2
PATCH_10.20: tty_pty.o 1.13.112.5 98/01/13 PHNE_13800
PATCH_10.20: mux2.o 1.8.112.5 98/01/13 PHNE_13800
marta:/#
Todos los parches oficiales de HP-UX (tanto a nivel de núcleo como de aplicación) se identifican por cuatro letras que definen el tipo de parche, seguidas de un número y separados ambos por un subrayado: por ejemplo, como acabamos de ver, el nombre de un parche puede ser PHNE/SMALL>_13800. Actualmente existen cuatro tipos de parches definidos por Hewlett-Packard: comandos y librerías (PHCO), kernel (PHKL), red (PHNE) y subsistemas (PHSS); todos los parches comienzan con la denominación común PH (patch HP-UX), y el número que los identifica es único, independientemente del tipo de parche.
Hewlett-Packard distribuye cada cuatro meses sus parches oficiales en CDROMs o cintas, denominados Support Plus; también a través de Internet podemos descargar actualizaciones y parches en la dirección http://www.itrc.hp.com/##, que nos indicará la URL adecuada a la que debemos dirigirnos en función de nuestra ubicación geográfica (Europa, América...). A diferencia de lo que sucede con otros fabricantes, en el caso de Hewlett-Packard es necesario estar registrado para acceder a sus parches, pero este registro es completamente gratuito.
Cuando descargamos un parche para HP-UX obtenemos un único fichero que no es más que un shellscript, y para instalarlo evidentemente lo primero que tenemos que hacer es ejecutar dicho archivo; esto generará un par de ficheros con el nombre del parche correspondiente y extensiones .text y .depot respectivamente13.2: el primero de ellos contiene información sobre el parche (nombre, plataformas, instrucciones de instalación...), mientras que el segundo es un archivo con formato TAR que podremos instalar mediante la orden swinstall. Si por ejemplo queremos instalar el parche PHNE/SMALL>_12492 ejecutaremos una orden similar a la siguiente:
marta:/# swinstall -x autoreboot=true -x match_target=true \
-s ./PHNE_12492.depot 2>&1 >/dev/null
marta:/#
La opción que más nos interesa de swinstall es sin duda `-s', que especifica la ubicación del archivo .depot en el sistema de ficheros; la opción `-x autoreboot=true' no indica obligatoriamente un reinicio del sistema, sino que simplemente lo permite: cada parche de HP-UX `sabe' si para instalarse correctamente es necesario reiniciar el operativo (nosotros lo podemos saber simplemente leyendo el fichero .text que hemos generado anteriormente), y si el reboot es necesario con esta opción indicamos que se lleve a cabo automáticamente, algo útil en instalaciones automáticas pero que puede ser crítico en algunas ocasiones.
Una vez instalado el parche correspondiente es recomendable ejecutar swverify; esta orden verifica que la información registrada en la IPD de HP-UX (dependencias, integridad de archivos...) se corresponde con la que se encuentra en los ficheros y directorios del sistema. Podemos verificar todos los registros de software (productos y parches) mediante el comodín `', o bien únicamente el parche que acabamos de instalar; aparte de mostrarse en la consola o terminal desde la que se ejecute, el resultado de la ejecución de esta orden se guardará en el fichero de log correspondiente, dentro del directorio /var/adm/sw/:
marta:/# swverify PHNE_12492
= 12/11/01 03:23:34 MET BEGIN swverify SESSION
(non-interactive)
* Session started for user "root@marta".
* Beginning Selection
* Target connection succeeded for "marta:/".
* Software selections:
PHNE_12492.PHNE_12492,l=/,r=B.10.00.00.AA,\
a=HP-UX_B.10.20_700/800,v=HP:/
* Selection succeeded.
* Beginning Analysis
* Session selections have been saved in the file
"/.sw/sessions/swverify.last".
* The analysis phase succeeded for "marta:/".
* Verification succeeded.
NOTE: More information may be found in the agent logfile (location
is marta:/var/adm/sw/swagent.log).
= 12/11/01 03:23:40 MET END swverify SESSION (non-interactive)
marta:/#
Antes de finalizar este punto es necesario recordar que siempre, antes de cualquier actualización del sistema o de la aplicación de cualquier tipo de parche, es imprescindible hacer una copia de seguridad completa de todos los sistemas de ficheros; esto es algo que se recomienda en todos los procedimientos de instalación de parches oficiales de Hewlett-Packard, y que nos puede ayudar a devolver al sistema a un estado operativo ante cualquier mínimo problema durante una actualización.
