El sistema operativo (SO) Solaris se suministra e instala con paquetes SVR4. Los paquetes contienen uno o varios archivos de instalación junto con información de configuración específica de cada paquete. La información específica de los paquetes define los atributos de los objetos. Esta información describe además cómo y dónde deben instalarse los paquetes. El paquete también contiene, por lo general, scripts de pre y postinstalación que garantizan la distribución correcta de los archivos.
Los parches actualizan los paquetes instalados para agregar, actualizar o eliminar información de uno o varios archivos del sistema. Los parches en sí constan físicamente de paquetes breves junto con una serie de scripts pre post-parche y scripts de acción de clase.
Un paquete breve es una versión reducida de un paquete ordinario. Los paquetes breves sólo distribuyen los archivos objeto de actualización.
Los scripts de acción de clase definen un conjunto de acciones que deben ejecutarse durante la instalación o retirada de paquetes o parches.
Sí, los parches de Solaris 10 sirven para cualquier versión de Solaris.
Cada versión comercial tiene un conjunto de parches. Por ejemplo, la versión comercial de Solaris 8 cuenta con un conjunto de parches para Solaris 8, la de Solaris 10 tiene su conjunto de parches para Solaris 10, y así sucesivamente.
El conjunto de parches de cada versión incluye a todas las variantes de una versión comercial. Por ejemplo, la versión 3/05 de Solaris 10 es la primera versión comercial de Solaris 10. A esta versión siguen una serie de variantes como Solaris 10 1/06, Solaris 10 6/06, etc. El conjunto de parches es válido para todas ellas. El mismo parche de Solaris 10 puede aplicarse a las versiones 3/05, 1/06, 6/06, etc. de Solaris 10.
No se pueden utilizar parches entre versiones comerciales de Solaris. Por ejemplo, no puede aplicar un parche de Solaris 10 a una versión de Solaris 9.
Algunos clientes desean actualizar el sistema mediante la instalación de todos los parches publicados desde la instalación de la versión en su sistema. Los parches que se publican tras la distribución general de una versión, como la 1/06 de Solaris 10, contienen tanto las funciones como las soluciones de defectos para la versión 1/06 de Solaris 10.
La respuesta es no. Puede obtener una parte de una versión posterior con los parches correspondientes, pero ello no garantiza la actualización de toda la versión.
Una versión de Solaris, como la 6/06 de Solaris 10, contiene parches del código existente y paquetes nuevos. Cualquier modificación del código existente, incluidos cambios de funcionalidad, se suministra en parches. Si utiliza parches del mismo nivel que una versión o superior, como Solaris 10 6/06, obtendrá todas las soluciones de defectos del código existente contenido en la versión. Puede que también obtenga algunas funciones nuevas contenidas en sus totalidad en los parches.
Aunque los parches pueden contener objetos nuevos, las funciones de importancia suelen formar parte de paquetes nuevos. Por lo general, estos paquetes nuevos solo pueden obtenerse mediante la actualización de la imagen de versión Solaris. Por tanto, no es posible conseguir las mismas funciones de una versión nueva, como Solaris 10 6/06, mediante la simple aplicación de parches.
El tiempo de instalación varía según una serie de factores:
El tamaño de los actuales clústeres de parches recomendados puede ser considerable y algunos parches, como el de núcleo, tienden a crecer. Por ejemplo, el parche de núcleo de Solaris 10 11/06, 118833-36, ocupa unos 136 MB. El parche de núcleo de Solaris 10 8/07, 120011-10, ocupa unos 166 MB. Los parches de grandes dimensiones tardan más en instalarse.
En los sistemas sin zonas globales, el funcionamiento de los parches se lleva a cabo en la actualidad de forma secuencial (una cada vez) en cada zona.
Sun está trabajando para mejorar este aspecto. Consulte CR 6318693.
Tradicionalmente la intención siempre ha sido evitar la creación de parches grandes y poco manejables mediante el suministro de un parche por cada "componente" de software. Por ejemplo, se podría recibir un parche UFS para el subsistema UFS o uno libc para la biblioteca libc.
Estos límites se difuminan cuando las soluciones de defectos, y en particular los cambios, afectan al código de distintos subsistemas del sistema operativo. El resultado es la posibilidad de aparición de dependencias que fuercen la agrupación de uno o más parches para garantizar la consistencia del cambio aplicado.
En ocasiones la dependencia es "leve" y los parches pueden mantenerse separados, con una simple nota en el archivo LÉAME de parches que advierta de la posible necesidad de instalar varios parches para que la solución sea completa. Una dependencia leve supone una solución o función incompleta, pero ello no tiene por qué alterar la consistencia del estado del sistema.
Nota: para obtener más información sobre las dependencias entre parches (leves e importantes), lea el artículo sobre Sun BluePrints Solaris Patch Management Recommended Strategy (pdf) y consulte el apartado sobre interrelaciones entre parches.
La primera es que evitar la creación de grandes parches conduce al aumento del número de parches más pequeños.
Además, la cartera de software de Sun contiene una gran cantidad de productos y algunos, Solaris en particular, pueden verse afectados por una serie de parches distintos pensados para diferentes subsistemas del producto.
El archivo LÉAME especifica los parches que deben instalarse en modo de usuario único. Aunque las herramientas del parche no imponen el empleo del modo de usuario único, deben respetarse las instrucciones del archivo LÉAME. La aplicación de parches en modo de usuario único garantiza la latencia del sistema. Es importante reducir al mínimo la actividad del sistema. Algunos parches actualizan componentes del sistema de utilización común. El modo de usuario único mantiene la estabilidad del sistema y reduce la posibilidad de uso de estos componentes durante su actualización.
El modo de usuario único es esencial en parches de sistema, como el de núcleo. Si aplica un parche de núcleo en modo de multiusuario, aumentará de forma considerable el riesgo de inconsistencia del sistema.
Sí, debe hacerlo si utilizó el modo de usuario único para aplicar el parche. Las propiedades del parche se aplican tanto en la instalación como en la retirada de parches. Los cambios realizados en el sistema tienen idéntica importancia con independencia del sentido en que se realicen (instalación o retirada).
Podría pensarse que basta con cambiar el nivel de ejecución con el comando init S. No obstante, en la práctica no existe garantía de que todos los procesos y aplicaciones que se ejecutan en un sistema se cierren al utilizar este método para cambiar de modo multiusuario a usuario único. Las aplicaciones de otros fabricantes son especialmente sensibles a ello. El comando init no consigue el grado de latencia del sistema deseable para los parches que requieren instalación en modo de usuario único. Por tanto, si el archivo LÉAME del parche especifica la instalación en modo de usuario único, Sun recomienda encarecidamente iniciar el sistema en modo de usuario único para trabajar con el parche.
Se trata de un problema conocido y, por lo general, debido a la no habilitación de sistemas de archivo de zona global en el modo de usuario único. Éste es un ejemplo de mensaje de error que puede aparecer:
Preparing checklist for non-global zone check...
Checking non-global zones...
ERROR: unable to boot zone: problem running on zone :
error 1 zoneadm: zone 'myzone': can't stat /zones/full1/root: No such file or
directory
zoneadm: zone 'myzone': call to zoneadmd failed
Can not boot non-global zone myzone
Solución: para garantizar la habilitación de todos los sistemas de archivo locales, ejecute el comando mountall -l antes de instalar los parches.
Sun está trabajando en la solución de este problema.
El archivo LÉAME de algunos parches especifica la necesidad de reiniciar el sistema tras la instalación o la retirada del parche. Si no está seguro de las presentes instrucciones, consulte el archivo patchinfo en el directorio superior del parche. Las instrucciones de reinicio se explican con detalle en él. Esta petición de reinicio puede contener dos instrucciones de reinicio:
La primera es un "reinicio tras" la aplicación del parche, para ver la solución aplicada. Esta instrucción carece de restricciones temporales, pues no es más que un recordatorio de que algunos de los cambios no se activarán hasta que se reinicie el sistema.
La segunda instrucción es un "reinicio inmediato" tras la aplicación del parche. El reinicio debe realizarse en breve, puesto que el sistema se encuentra en un estado inconsistente y es preciso el reinicio para estabilizarlo. Por tanto, el sistema debe reiniciarse cuanto antes, preferiblemente antes de finalizar las operaciones con parches.
Por ejemplo, un parche puede incorporar nuevo código binario al núcleo y una biblioteca libc nueva. Tras la instalación del nuevo código binario del núcleo en el disco, los archivos binarios siguen "inactivos", puesto que se cargan la siguiente vez que se inicie el sistema. Por otro lado, puede que la biblioteca libc contenga interfaces o cambios de comportamiento que dependan del núcleo nuevo. Sin embargo, la libc nueva podría vincularse y ejecutarse en cualquier momento tras su instalación en el sistema de archivos. Esta discrepancia de versiones es causa posible de una inconsistencia en el estado del sistema que, en potencia, podría dar pie a problemas serios.
No. Si un parche requiere el reinicio, no puede evitarlo. Tarde o temprano tendrá que reiniciar el sistema para activar los cambios que introdujo el parche. Sin embargo, puede utilizar un par de estrategias para posponer el cambio hasta una ocasión más propicia.
Un método es el empleo de Solaris Live Upgrade, que permite la instalación de parches con el sistema en producción. Puede evitar los modos de usuario único y multiusuario. Basta con reiniciar en el entorno objeto del parche en una ocasión más propicia.
Nota: en la actualidad, Solaris Live Upgrade no funciona demasiado bien con sistemas de archivos raíz (/) encapsulados Veritas. El sistema de archivos raíz (/) puede ser un volumen Veritas Volume Manager (VxVM). Si se configuran volúmenes VxVM en el sistema, el comando lucreate puede crear un entorno de inicio nuevo. Cuando se copian los datos al entorno de inicio nuevo, se pierde la configuración del sistema de archivos Veritas y se crea un sistema de archivos UFS en el entorno nuevo.
Otra posibilidad con ventajas parecidas a las de Solaris Live Upgrade es la utilización de volúmenes RAID-1 (duplicación de discos) con Solaris Volume Manager. En este caso puede dividir el duplicado, habilitar el duplicado del sistema de archivos raíz (/) y aplicar los parches a la copia con el comando patchadd -R. La opción -R permite especificar una ubicación de raíz alternativa. El modificador -R suele utilizarse en equipos cliente sin disco, pero también puede emplearse para posponer un reinicio.
