Admisión de la reubicación en un entorno heterogéneo
El concepto original tras la creación de paquetes de System V ha supuesto una arquitectura por sistema. El concepto de un servidor no representa una función en el diseño. Ahora, por supuesto, un único servidor puede ofrecer compatibilidad para diversas arquitecturas, lo cual significa que puede haber varias copias del mismo software en un servidor, cada una para una arquitectura diferente. Mientras que los paquetes de Solaris se retiran dentro de los límites recomendados del sistema de archivos (por ejemplo, / y /usr), con bases de datos de productos en el servidor, así como cada cliente, no todas las instalaciones tienen por qué admitir esta división. Determinadas implementaciones admiten una estructura completamente diferente e implican una base de datos de productos habitual. Mientras que dirigir a los clientes a diferentes versiones es algo sencillo, la instalación de paquetes de System V en diversos directorios base puede presentar problemas para el administrador.
Cuando diseña el paquete, también debe tener en cuenta los métodos habituales que los administradores usan para introducir nuevas versiones de software. Los administradores buscan con frecuencia instalar y probar la última versión, de forma paralela a la versión actualmente instalada. El procedimiento implica la instalación de la nueva versión en un directorio base diferente de la versión actual y la orientación de un determinado número de clientes que no sean fundamentales a la nueva versión como prueba. A medida que crece la confianza el administrador redirige cada vez más clientes a la nueva versión. Finalmente, el administrador conserva la versión anterior sólo para emergencias y después, finalmente, la suprime.
Lo que esto significa es que los paquetes destinados a sistemas heterogéneos modernos deben admitir la reubicación total, en el sentido de que el administrador pueda colocarlos en un lugar razonable del sistema de archivos y ver todavía todas sus funciones. Solaris 2.5 y las versiones compatibles ofrecen diversas herramientas que permiten varias arquitecturas y versiones para realizar la instalación sin problemas en el mismo sistema. Solaris 2.4 y las versiones compatibles también admiten la reubicación completa pero la ejecución de la tarea no es tan sencilla.
Aproximación tradicional
Paquetes reubicables
System V ABI implica que la intención original del paquete reubicable era facilitar la instalación del paquete al administrador. En estos momentos, la necesidad de paquetes reubicables va mucho más allá. La comodidad no es la única cuestión; es muy probable que durante la instalación ya haya instalado un producto de software activo en el directorio predeterminado. Un paquete que no esté diseñado para lidiar con esta situación sobrescribe el producto existente o no consigue instalarse. Sin embargo, un paquete diseñado para gestionar diversas arquitecturas y versiones puede instalarse sin problemas y ofrecer al administrador una amplia gama de opciones que sean totalmente compatibles con las tradiciones administrativas existentes.
En algunos aspectos, el problema de varias arquitecturas y el de varias versiones es el mismo. Debe ser posible instalar una variante del paquete existente junto a otras variantes, así como dirigir a los clientes o los consumidores autónomos de sistemas de archivos exportados a una de esas variantes, sin que las funciones se vean comprometidas. Mientras Sun ha establecido métodos para lidiar con varias arquitecturas en un servidor, es posible que el administrador no pueda seguir esas recomendaciones. Todos los paquetes deben ser capaces de cumplir con los deseos razonables de los administradores respecto a la instalación.
Ejemplo: paquete reubicable tradicional
Este ejemplo muestra el aspecto que puede tener un paquete reubicable tradicional. Este paquete se debe ubicar en /opt/SUNWstuf, y los archivos pkginfo y pkgmap pueden tener este aspecto.
El archivo pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
El archivo pkgmap
: 1 1758 1 d none SUNWstuf 0775 root bin 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
Este método se conoce como tradicional porque cada objeto del paquete se instala en el directorio base definido por el parámetro BASEDIR del archivo pkginfo. Por ejemplo, el primer objeto del archivo pkgmap se instala como directorio /opt/SUNWstuf.
Paquetes absolutos
Un paquete absoluto es el que se instala en un sistema de archivos raíz concreto (/). Estos paquetes son difíciles de gestionar desde el punto de vista de varias versiones y arquitecturas. Como norma general, todos los paquetes deben ser reubicables. Sin embargo, hay muy buenos motivos para incluir elementos absolutos en un paquete reubicable.
Ejemplo: paquete absoluto tradicional
Si el paquete SUNWstuf fuera absoluto, el parámetro BASEDIR no se debería definir en el archivo pkginfo, y el archivo pkgmap tendría este aspecto.
El archivo pkgmap
: 1 1758 1 d none /opt ? ? ? 1 d none /opt/SUNWstuf 0775 root bin 1 d none /opt/SUNWstuf/EZstuf 0775 root bin 1 f none /opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none /opt/SUNWstuf/HRDstuf 0775 root bin 1 f none /opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none /opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
En este ejemplo, si el administrador ha especificado un directorio base alternativo durante la instalación, el comando pkgadd lo ignoraría. Este paquete siempre se instala en el directorio /opt/SUNWstuf del sistema de destino.
El argumento -R del comando pkgadd funciona según lo esperado. Por ejemplo,
pkgadd -d . -R /export/opt/client3 SUNWstuf |
instala los objetos en /export/opt/client3/opt/SUNWstuf, pero esto es lo más cerca que puede estar este paquete de ser reubicable.
Observe el uso del signo de interrogación (?) para el directorio /opt en el archivo pkgmap. Indica que los atributos existentes no se deben cambiar. No significa “crear el directorio con atributos predeterminados” aunque en determinadas circunstancias esto pueda ocurrir. Cualquier directorio que sea específico del nuevo paquete debe especificar todos los atributos de forma explícita.
Paquetes compuestos
Un paquete que contenga objetos reubicables es un paquete reubicable. Esto puede llegar a ser confuso porque un paquete reubicable puede contener rutas absolutas en su archivo pkgmap. El uso de una entrada raíz (/) en un archivo pkgmap puede mejorar los aspectos reubicables del paquete. Los paquetes que tienen entradas raíz y reubicables reciben el nombre de paquetes compuestos.
Ejemplo: solución tradicional
Suponga que un objeto del paquete SUNWstuf es una secuencia de comandos de inicio que se ejecuta en el nivel de ejecución 2. El archivo /etc/rc2.d/S70dostuf se debe instalar como parte del paquete, pero no se puede colocar en el directorio base. Si se supone que un paquete reubicable es la única solución, los archivos pkginfo y pkgmap podrían tener este aspecto.
El archivo pkginfo
# pkginfo file PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/ VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none PSTAMP=hubert990707141632 |
El archivo pkgmap
: 1 1758 1 d none opt/SUNWstuf/EZstuf 0775 root bin 1 f none opt/SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none opt/SUNWstuf/HRDstuf 0775 root bin 1 f none opt/SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none opt/SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none etc ? ? ? 1 d none etc/rc2.d ? ? ? 1 f none etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 |
No hay mucha diferencia entre esta aproximación y la de un paquete absoluto. En realidad, resultaría mejor como paquete absoluto: si el administrador proporcionara un directorio base alternativo para este paquete, no funcionaría.
De hecho, sólo un archivo de este paquete debe estar relacionado con la raíz; el resto se puede mover a cualquier lugar. La forma de solucionar este problema mediante el uso de un paquete compuesto se trata a lo largo de esta sección.
Más allá de la tradición
La aproximación que se describe en esta sección no se aplica a todos los paquetes, pero mejora el rendimiento durante la instalación en un entorno heterogéneo. Sólo una pequeña parte se aplica a los paquetes que se han entregado como parte del sistema operativo Solaris (paquetes integrados); sin embargo, los paquetes no integrados pueden practicar una creación de paquetes no tradicional.
El motivo que se esconde tras el fomento de los paquetes reubicables es apoyar a este requisito:
Cuando un paquete se agrega o se suprime, los comportamientos deseables existentes de los productos de software instalados quedarán sin cambios.
Los paquetes no integrados deben residir en /opt para asegurar que el nuevo paquete no interfiera con productos existentes.
Otra mirada a los paquetes compuestos
Hay dos normas que seguir a la hora de construir un paquete compuesto funcional:
-
Establecer el directorio base según donde va la amplia mayoría de los objetos del paquete.
-
Si un objeto del paquete va a un directorio común que no es el directorio base (por ejemplo, /etc), especifíquelo como nombre de ruta absoluta en el archivo prototype.
En otras palabras: puesto que "reubicable" significa que el objeto se puede instalar en cualquier lugar y que siga funcionando, ninguna secuencia de comandos de inicio ejecutada por init en el tiempo del inicio se puede considerar reubicable. Mientras no haya nada incorrecto en la especificación de /etc/passwd como ruta relativa en el paquete entregado, sólo hay un lugar al que puede ir.
Cómo conseguir que los nombres de rutas absolutas tengan el aspecto de reubicables
Si va a construir un paquete compuesto, las rutas absolutas deben funcionar de forma que no interfieran en el software instalado existente. Un paquete que se puede incluir por completo en /opt evita este problema porque no hay archivos en la ruta. Cuando un archivo de /etc se incluye en el paquete, debe asegurarse de que los nombres de la ruta absoluta se comportan del mismo modo que se espera de los nombres de rutas relativa. Observe los dos ejemplos siguientes.
Ejemplo: modificación de un archivo
Descripción
Se agrega una entrada a una tabla, o bien el objeto es una tabla nueva que probablemente modificarán otros programas o paquetes.
Implementación
Defina el objeto como tipo de archivo e y perteneciente a la clase build, awk o sed. La secuencia de comandos que ejecuta esta tarea debe suprimirse igual de eficazmente que cuando se agrega.
Ejemplo
Se debe agregar una entrada al archivo /etc/vfstab en apoyo del nuevo disco duro de estado sólido.
La entrada del archivo pkgmap podría ser
1 e sed /etc/vfstab ? ? ? |
La secuencia de comandos request pregunta al operador si el paquete debe modificar el archivo /etc/vfstab. Si el operador responde “no”, la secuencia de comandos de solicitud imprimirá las instrucciones para hacer el trabajo manualmente y ejecutará
echo "CLASSES=none" >> $1 |
Si el operador responde "sí" se ejecuta
echo "CLASSES=none sed" >> $1 |
que activa la secuencia de comandos de acción de clase que realizará las modificaciones necesarias. La clase sed significa que el archivo de paquete /etc/vfstab es un programa sed que contiene las operaciones de instalación y eliminación para el archivo con el mismo nombre en el sistema de destino.
Ejemplo: creación de un nuevo archivo
Descripción
El objeto es un archivo completamente nuevo que no es probable que se modifique posteriormente, o bien sustituye a un archivo propiedad de otro paquete.
Implementación
Defina el objeto del paquete como tipo de archivo f e instálelo mediante una secuencia de comandos de acción de clase capaz de deshacer el cambio.
Ejemplo
Se precisa un archivo completamente nuevo en /etc para proporcionar la información necesaria con el fin de que se pueda admitir el disco duro de estado sólido, que recibe el nombre de /etc/shdisk.conf . La entrada del archivo pkgmap podría tener este aspecto:
. . . 1 f newetc /etc/shdisk.conf . . . |
La secuencia de comandos de acción de clase i.newetc es responsable de la instalación de éste y otros archivos que deben ir en /etc. Hace comprobaciones para asegurarse de que no haya otro archivo allí. Si no hay, simplemente copiará el archivo nuevo en su lugar. Si ya hay un archivo en su lugar, hará una copia de seguridad de él antes de instalar el archivo nuevo. La secuencia de comandos r.newetc suprime estos archivos y restaura los originales, si fuera necesario. Aquí se encuentra el fragmento clave de la secuencia de comandos de instalación.
# i.newetc
while read src dst; do
if [ -f $dst ]; then
dstfile=`basename $dst`
cp $dst $PKGSAV/$dstfile
fi
cp $src $dst
done
if [ "${1}" = "ENDOFCLASS" ]; then
cd $PKGSAV
tar cf SAVE.newetc .
$INST_DATADIR/$PKG/install/squish SAVE.newetc
fi
|
Observe que esta secuencia de comandos usa la variable de entorno PKGSAV para almacenar una copia de seguridad del archivo que se debe sustituir. Cuando el argumento ENDOFCLASS pasa a la secuencia de comandos, se trata del comando pkgadd que informa a la secuencia de comandos de que éstas son las últimas entradas de esta clase; en ese momento la secuencia de comandos archiva y comprime los archivos que se guardaron mediante un programa de compresión privado almacenado en el directorio de instalación del paquete.
Mientras el uso de la variable de entorno PKGSAV, no es fiable durante la actualización de un paquete; si el paquete no se actualiza (mediante un parche, por ejemplo) el archivo de copia de seguridad es seguro. La siguiente secuencia de comandos de eliminación incluye un código para gestionar los demás problemas: el hecho de que versiones más antiguas del comando pkgrm no pasen a las secuencias de comandos la ruta correcta a la variable de entorno PKGSAV.
La secuencia de comandos de eliminación podría tener este aspecto.
# r.newetc
# make sure we have the correct PKGSAV
if [ -d $PKG_INSTALL_ROOT$PKGSAV ]; then
PKGSAV="$PKG_INSTALL_ROOT$PKGSAV"
fi
# find the unsquish program
UNSQUISH_CMD=`dirname $0`/unsquish
while read file; do
rm $file
done
if [ "${1}" = ENDOFCLASS ]; then
if [ -f $PKGSAV/SAVE.newetc.sq ]; then
$UNSQUISH_CMD $PKGSAV/SAVE.newetc
fi
if [ -f $PKGSAV/SAVE.newetc ]; then
targetdir=dirname $file # get the right directory
cd $targetdir
tar xf $PKGSAV/SAVE.newetc
rm $PKGSAV/SAVE.newetc
fi
fi
|
Esta secuencia de comandos usa un algoritmo desinstalado privado (unsquish) que se encuentra en el directorio de instalación de la base de datos del paquete. Esto se hace de manera automática mediante el comando pkgadd en el tiempo de la instalación. Todas las secuencias de comandos que no estén específicamente reconocidas como de sólo instalación por parte del comando pkgadd quedan en este directorio para que lo pueda usar el comando pkgrm. No puede determinar dónde se encuentra ese directorio, pero puede confiar en que está completamente disponible y que contiene todas las secuencias de comandos de instalación y los archivos de información adecuados para el paquete. Esta secuencia de comandos busca el directorio por virtud del hecho de que se garantiza la ejecución de la secuencia de comandos de acción de clase a partir del directorio que contiene el programa unsquish.
Tenga en cuenta, asimismo, que esta secuencia de comandos no sólo supone que el directorio de destino sea /etc. Puede que en realidad sea /export/root/client2/etc. El directorio correcto se puede construir de una de estas dos formas.
-
Use la construcción ${PKG_INSTALL_ROOT}/etc, o bien.
-
Tome el nombre de directorio de un archivo aprobado por el comando pkgadd (lo que esta secuencia de comandos hace).
Mediante el uso de esta aproximación para cada objeto absoluto del paquete, puede estar seguro que el comportamiento deseable actual permanece sin cambios o al menos es recuperable.
Ejemplo: un paquete compuesto
Éste es un ejemplo de los archivos pkginfo y pkgmap para un paquete compuesto.
El archivo pkginfo
PKG=SUNWstuf NAME=software stuff ARCH=sparc VERSION=1.0.0,REV=1.0.5 CATEGORY=application DESC=a set of utilities that do stuff BASEDIR=/opt VENDOR=Sun Microsystems, Inc. HOTLINE=Please contact your local service provider EMAIL= MAXINST=1000 CLASSES=none daemon PSTAMP=hubert990707141632 |
El archivo pkgmap
: 1 1758 1 d none SUNWstuf/EZstuf 0775 root bin 1 f none SUNWstuf/EZstuf/dirdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/usrdel 0555 bin bin 40 773 751310229 1 f none SUNWstuf/EZstuf/filedel 0555 bin bin 40 773 751310229 1 d none SUNWstuf/HRDstuf 0775 root bin 1 f none SUNWstuf/HRDstuf/mksmart 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mktall 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkcute 0555 bin bin 40 773 751310229 1 f none SUNWstuf/HRDstuf/mkeasy 0555 bin bin 40 773 751310229 1 d none /etc ? ? ? 1 d none /etc/rc2.d ? ? ? 1 e daemon /etc/rc2.d/S70dostuf 0744 root sys 450 223443 1 i i.daemon 509 39560 752978103 1 i pkginfo 348 28411 760740163 1 i postinstall 323 26475 751309908 1 i postremove 402 33179 751309945 1 i preinstall 321 26254 751310019 1 i preremove 320 26114 751309865 1 i r.daemon 320 24573 742152591 |
Mientras S70dostuf pertenece a la clase daemon, los directorios que llevan hasta él (que ya estén en posición en el tiempo de la instalación) pertenecen a la clase none. Incluso si los directorios eran exclusivos para este paquete, debe dejarlos en la clase none. El motivo es que los directorios se deben crear en primer lugar y después suprimir; siempre ocurre así en el caso de la clase none. El comando pkgadd crea directorios; no se copian del paquete y no se pasan a una secuencia de comandos de acción de clase que se deba crear. En su lugar, los crea el comando pkgadd antes de que llame a la secuencia de comandos de acción de clase de instalación; el comando pkgrm suprime directorios después de terminar de suprimir la secuencia de comandos de acción de clase.
Significa que si un directorio de una clase especial contiene objetos de la clase none, cuando el comando pkgrm intenta suprimir el directorio, se produce un error porque el directorio no estará vacío en ese momento. Si se va a insertar un objeto de clase none en un directorio de alguna clase especial, ese directorio no existirá a tiempo de aceptar el objeto. El comando pkgadd creará el directorio de forma paralela a la instalación del objeto y puede que no sea capaz de sincronizar los atributos de ese directorio cuando finalmente vea la definición pkgmap.
Nota –
Al asignar un directorio a una clase, recuerde siempre el orden de creación y eliminación.
- © 2010, Oracle Corporation and/or its affiliates