Apéndice G Requisitos de empaquetado SVR4 adicionales (referencia)

Este apéndice está dirigido a administradores de sistema que deban utilizar el programa JumpStart personalizado o la Modernización automática de Solaris para instalar o eliminar paquetes, especialmente de otras empresas. El seguimiento de estos requisitos de empaquetado hace que una instalación JumpStart personalizada deje de ser interactiva y evita modificar el sistema que actualmente se ejecuta para poder modernizarlo con la Modernización automática de Solaris.

Información general sobre requisitos de empaquetado

En las siguientes referencias de documentación se ofrece información general acerca de requisitos de empaquetado.

• Para que el programa JumpStart personalizado y la Modernización automática de Solaris funcionen correctamente, los paquetes deben cumplir los requisitos de empaquetado SVR4. Application Packaging Developer's Guide proporciona información más específica sobre requisitos de empaquetado y definiciones terminológicas. Consulte con especial atención el capítulo:“Advanced Package Creation Techniques” in Application Packaging Developer's Guide

• Para obtener información básica acerca de la adición y eliminación de paquetes y sobre el archivo de administración de instalación, consulte “Managing Software (Overview)” in System Administration Guide: Basic Administration. Consulte, asimismo, las páginas de comando man pertinentes.

• Para obtener información detallada sobe los comandos a los que se hace referencia en este apéndice, consulte las páginas de comando man dircmp(1), fssnap(1M), ps(1) o truss(1).

La Tabla G–1 enumera la información que hace referencia a la Modernización automática de Solaris o al programa JumpStart personalizado en este documento.

Requisitos de entorno de arranque inactivo para el programa JumpStart personalizado y la Modernización automática de Solaris

Un entorno de arranque inactivo es una copia del sistema operativo, no el sistema actualmente en ejecución. Un paquete que lo vayan a utilizar la Modernización automática de Solaris o el programa JumpStart personalizado debe cumplir los siguientes requisitos:

• Permitir una instalación JumpStart personalizada o una modernización sin interacción del usuario

• No modificar el sistema actualmente en ejecución, lo cual es necesario para utilizar la Modernización automática de Solaris

En la lista siguiente se enumeran los requisitos para la compatibilidad con un entorno de arranque inactivo.

• Para que la instalación de un sistema operativo sea satisfactoria, los paquetes deben reconocer y respetar correctamente los especificadores de entorno de arranque inactivo.

  Los paquetes pueden incluir rutas absolutas en su archivo pkgmap (mapa del paquete). Si dichos archivos existen, están escritos de forma relativa a la opción -R del comando pkgadd. Los paquetes que contienen tanto rutas absolutas como relativas (reubicables) se pueden instalar también en una raíz alternativa (/). $PKG_INSTALL_ROOT se antepone tanto a los archivos absolutos como a los reubicables, de forma que todas las rutas se determinen correctamente cuando se utilice el comando pkgadd para la instalación.

• Los paquetes instalados mediante el comando pkgadd -R o los que se eliminen mediante el comando pkgrm -R no deben modificar el sistema actualmente en ejecución.

  Las secuencias de procedimiento incluidas en los paquetes que se instalen con el comando pkgadd -R o que se eliminen con el comando pkgrm -R no deben modificar el sistema actualmente en ejecución. Todas las secuencias de instalación utilizadas deben hacer referencia a los directorios o archivos con el prefijo indicado por la variable $PKG_INSTALL_ROOT. El paquete debe escribir todos los directorios y archivos con el prefijo $PKG_INSTALL_ROOT. El paquete no debe eliminar directorios sin un prefijo $PKG_INSTALL_ROOT. La Tabla G–2 proporciona ejemplos de sintaxis correcta para las secuencias.

  Tabla G–2 Ejemplos de sintaxis en secuencias de instalación

  Tipo de secuencia	Sintaxis correcta	Sintaxis incorrecta
  Fragmentos de sentencias “if” en el shell Bourne	if [ -f ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf ] ; then	if [ -f /etc/myproduct.conf ] ; \ then
  Eliminar un archivo	/bin/rm -f ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf	/bin/rm -f /etc/myproduct.conf
  Cambiar un archivo	echo "test=no"> ${PKG_INSTALL_ROOT}\ /etc/myproduct.conf	echo "test=no"> \ /etc/myproduct.conf

Información general acerca de las diferencias entre $PKG_INSTALL_ROOT y $BASEDIR

$PKG_INSTALL_ROOT es la ubicación del sistema de archivos raíz (/) del equipo al que se va a agregar el paquete. Ésta se adjunta al argumento de -R del comando pkgadd. Por ejemplo, si se ejecuta el siguiente comando, $PKG_INSTALL_ROOT se convierte en /a durante la instalación del paquete.

# pkgadd -R /a SUNWvxvm

$BASEDIR señala al directorio base reubicable en el que se instalan los objetos de paquete reubicables. Sólo se instalan aquí los objetos reubicables. Los objetos no reubicables (aquéllos con rutas absolutas en el archivo pkgmap) se instalan siempre de forma relativa al entorno de arranque inactivo (/), pero no relativa al $BASEDIR vigente. Si un paquete no contiene objetos reubicables, se denomina paquete absoluto (o no reubicable) y $BASEDIR no está definida, ni está disponible para las secuencias de procedimientos de paquetes.

Por ejemplo, supongamos que el archivo pkgmap de un paquete tiene dos entradas:

1 f none sbin/ls 0555 root sys 3541 12322 1002918510
1 f none /sbin/ls2 0555 root sys 3541 12322 2342423332

El archivo pkginfo tiene una especificación para $BASEDIR:

BASEDIR=/opt

Si este paquete se instala con el siguiente comando, ls se instala en /a/opt/sbin/ls, pero ls2 se instala como /a/sbin/ls2.

# pkgadd -R /a SUNWtest

Compatibilidad con entornos de arranque inactivos para la Modernización automática de Solaris

Al crear un entorno de arranque nuevo con la Modernización automática de Solaris, siga estas directrices para evitar posibles problemas.

• Las secuencias de procedimientos de paquetes deben ser independientes del actual sistema operativo activo. Las secuencias de procedimiento definen acciones que tienen lugar en instantes específicos durante la instalación o eliminación de paquetes. Se pueden crear cuatro secuencias de procedimiento con estos nombres predefinidos:preinstall, postinstall, preremove y postremove. Las secuencias de procedimiento de paquetes deben ser independientes del actual sistema operativo activo porque la Modernización automática de Solaris puede cambiar a un entorno de arranque inactivo.

  • Estas secuencias no deben iniciar ni parar ningún proceso, ni depender de la salida de comandos, como ps o truss, que dependen del sistema operativo y transmiten información acerca del sistema actualmente en ejecución.

  • Las secuencias de procedimiento pueden utilizar libremente comandos UNIX, como expr, cp y ls, y otros comandos que faciliten la elaboración de secuencias de shell. Sin embargo, el entorno de arranque inactivo no se debe modificar, salvo según se indica en las reglas de la sección Requisitos de entorno de arranque inactivo para el programa JumpStart personalizado y la Modernización automática de Solaris.

  • Todas las secuencias deben escribirse en el shell Bourne (/bin/sh). Éste es el intérprete que el comando pkgadd emplea para ejecutar las secuencias de procedimiento.

  • Las secuencias de procedimiento de los paquetes no deben llamar a comandos agregados en la versión 2.6 o posterior. Por ejemplo, las secuencias de procedimiento de paquetes no pueden llamar al comando pgrep. Desde la versión 2.6, se han agregado características adicionales a muchos de los comandos. Las secuencias de procedimiento de paquetes no deben utilizar opciones de comando que no existían en la versión 2.6. Por ejemplo, la opción -f del comando umount se agregó en la versión Solaris 7. Para comprobar si un comando u opción específicos se admiten en la versión Solaris 2.6, consulte Solaris 2.6 Reference Manual AnswerBook en http://docs.sun.com.

• Todos los paquetes deben pasar la validación de pkgchk. Una vez creado un paquete, y antes de instalarlo, se debe verificar mediante el siguiente comando.

  # pkgchk -d nombre_directorio nombre_paquete

  nombre_directorio

  Especifica el nombre del directorio en el que reside el paquete.

  nombre_paquete

  Especifica el nombre del paquete.

  Por ejemplo, si un paquete existe en /export/SUNWvxvm, deberá emitir el comando siguiente:

  # pkgchk -d /export SUNWvxvm

  No se debe mostrar ningún error.

  Una vez creado un paquete, se debe probar mediante su instalación en una ubicación de entorno de arranque inactivo empleando la opción -R nombre_directorio con el comando pkgadd. Una vez instalado un paquete se debe verificar su corrección mediante el comando pkgchk, como en este ejemplo.

  # pkgadd -d . -R /a SUNWvxvm # pkgchk -R /a SUNWvxvm

  No se debe mostrar ningún error.

• Asimismo, los paquetes no deben ejecutar comandos incorporados en el propio paquete. El motivo es mantener la compatibilidad con clientes sin disco y evitar la ejecución de comandos que puedan necesitar bibliotecas compartidas que aún no se han instalado.

Los mencionados requisitos de creación, modificación y supresión de archivos se pueden verificar mediante diversos comandos. Por ejemplo, los comandos dircmp o fssnap se pueden usar para verificar el comportamiento adecuado de los paquetes. Asimismo, el comando ps se puede utilizar para verificar la compatibilidad con daemons, empleándolo para asegurarse de que el paquete no inicia ni detiene ningún daemon. Los comandos truss, pkgadd -v y pkgrm pueden usarse para comprobar la compatibilidad de la instalación del paquete en tiempo de ejecución, pero es posible que no funcionen en todas las situaciones. En el ejemplo siguiente, el comando truss prescinde de todos los accesos de sólo lectura o que no sean a $TEMPDIR y muestra únicamente aquellos accesos que no son de sólo lectura a rutas ubicadas fuera del entorno de arranque inactivo especificado.

# TEMPDIR=/a; export TEMPDIR
# truss -t open /usr/sbin/pkgadd -R ${TEMPDIR} SUNWvxvm \
2>&1> /dev/null | grep -v O_RDONLY | grep -v \
'open("'${TEMPDIR}

Para obtener información detallada acerca de los comandos a los que se hace referencia en esta sección, consulte las páginas de comando man dircmp(1), fssnap(1M), ps(1), truss(1), pkgadd(1M), pkgchk(1M) o pkgrm(1M).

Compatibilidad con modernización con el programa JumpStart personalizado

La compatibilidad con el programa JumpStart personalizado garantiza que los paquetes se pueden agregar y eliminar formando parte de las utilidades tradicionales de instalación de Solaris, que son:

• El programa JumpStart personalizado

• El programa suninstall de Solaris

• El método de instalación Solaris Web Start

La compatibilidad con el programa JumpStart personalizado garantiza, asimismo, que el paquete puede participar en las modernizaciones de Solaris. Para que la instalación sea compatible con el programa JumpStart personalizado, un paquete debe cumplir, asimismo, los requisitos de entorno de arranque inactivo indicados en Requisitos de entorno de arranque inactivo para el programa JumpStart personalizado y la Modernización automática de Solaris.

Para poder utilizar el programa JumpStart personalizado de forma eficaz, los paquetes se deben poder agregar o eliminar sin solicitar ninguna información al usuario. Para impedir la interacción con el usuario, configure un nuevo archivo de administración con el comando pkgadd y la opción -a. Ésta define un archivo de administración de instalación para usarlo en lugar del predeterminado. El uso del archivo predeterminado podría hacer que se solicite información al usuario. Se puede crear un archivo de administración que indique al comando pkgadd que haga caso omiso de las comprobaciones e instale el paquete sin confirmación por parte del usuario. Para obtener más detalles, consulte las páginas de comando man admin(4) o pkgadd(1M).

En los ejemplos siguientes se indica cómo usar el archivo de administración de pkgadd.

• Si no se proporciona un archivo de administración, pkgadd usa /var/sadm/install/admin/default. El uso de este archivo puede tener como consecuencia la interacción con el usuario.

  # pkgadd

• Si en la línea de comandos se incluye un archivo de administración relativo, pkgadd busca el nombre del mismo en /var/sadm/install/admin y lo utiliza. En este ejemplo, el archivo de administración relativo se denomina nocheck, y pkgadd busca /var/sadm/install/admin/nocheck .

  # pkgadd -a nocheck

• Si se proporciona un archivo absoluto, pkgadd lo usa. En este ejemplo, pkgadd busca en /tmp el archivo de administración nocheck.

  # pkgadd -a /tmp/nocheck

A continuación se indica un ejemplo de archivo de administración de instalación con la utilidad pkgadd que apenas precisa interaccionar con el usuario. A menos que el paquete necesite un espacio mayor del disponible en el sistema la utilidad pkgadd usa este archivo e instala el paquete sin solicitar más información al usuario.

mail=
instance=overwrite
partial=nocheck
runlevel=nocheck
idepend=nocheck
space=ask
setuid=nocheck
confiict=nocheck
action=nocheck
basedir=default