Este capítulo ofrece casos prácticos para mostrar situaciones de creación de paquetes como la instalación de objetos de forma condicional, la especificación en el tiempo de ejecución de cuántos archivos se deben crear y la modificación de un archivo de datos durante la instalación y la eliminación de paquetes.
Cada caso práctico comienza por una descripción, seguida de una lista de las técnicas de creación de paquetes utilizadas, una descripción narrativa de la aproximación utilizada a la hora de usar esas técnicas, así como secuencias de comandos y archivos de ejemplo asociados al caso práctico.
A continuación puede ver una lista de los casos prácticos de este capítulo:
Creación de un archivo durante la instalación y cómo guardarlo durante la eliminación
Modificación de un archivo mediante secuencias de comandos de acción de clase y clases estándar
Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall
Instalación y eliminación de un controlador con secuencias de comandos de procedimientos
Instalación de un controlador mediante las secuencias de comandos de procedimientos y la clase sed
El paquete de este caso práctico tiene tres tipos de objetos. El administrador puede elegir cuál de los tres tipos se debe instalar y dónde ubicar los objetos en la máquina de instalación.
Este caso práctico muestra las técnicas siguientes:
El uso de nombres de ruta paramétricos (variables en nombres de ruta de objetos) que se usan para establecer varios directorios base
Para obtener información sobre nombres de ruta paramétricos, consulte Nombres de rutas paramétricos.
Uso de una secuencia de comandos request para solicitar entrada de información del administrador
Para obtener información sobre secuencias de comandos request, consulte Escritura de una secuencia de comandos request.
Configuración de valores condicionales para un parámetro de instalación.
Para configurar la instalación selectiva en este caso práctico, debe completar las tareas siguientes:
Defina una clase para cada tipo de objeto que se pueda instalar.
En este caso práctico, los tres tipos de objetos son paquetes ejecutables, páginas de comando man y ejecutables emacs. Cada tipo tiene su propia clase: bin, man y emacs, respectivamente. Observe que en el archivo prototype todos los archivos de objetos pertenecen a una de estas tres clases.
Inicialice el parámetro CLASSES en el archivo pkginfo con el valor de nulo.
Normalmente, cuando define una clase, debe enumerar esa clase del parámetro CLASSES en el archivo pkginfo. De lo contrario, no se instalan objetos en esa clase. Para este caso práctico, el parámetro se configura inicialmente con el valor nulo, lo cual significa que no se instalarán objetos. La secuencia de comandos request cambiará el parámetro CLASSES, de acuerdo con las opciones del administrador. De este modo, el parámetro CLASSES se configura sólo en estos tipos de objetos que el administrador desea instalar.
Por lo general, es una buena idea configurar los parámetros con un valor predeterminado. Si este paquete tuviese componentes comunes a los tres tipos de objetos, podría asignarlos a la clase none, y después configurar el parámetro CLASSES igual a none.
Inserte nombres de ruta paramétricos en el archivo prototype.
La secuencia de comandos request configura estas variables de entorno con el valor que el administrador proporciona. Posteriormente, el comando pkgadd resuelve estas variables de entorno en el tiempo de la instalación y sabe dónde instalar el paquete.
Las tres variables de entorno usadas en este ejemplo se configuran con el valor predeterminado en el archivo pkginfo y sirven a los fines siguientes:
$NCMPBIN define la ubicación de los ejecutables de objetos
$NCMPMAN define la ubicación de las páginas de comando man
$EMACS define la ubicación de los ejecutables emacs
El archivo prototype de ejemplo muestra cómo definir los nombres de ruta de objeto con variables.
Cree una secuencia de comandos request para preguntar al administrador qué partes del paquete se deben instalar y dónde se deben colocar.
La secuencia de comandos request para este paquete hace al administrador dos preguntas:
¿Se debe instalar esta parte del paquete?
Si la respuesta es sí, el nombre de clase adecuado se agrega al parámetro CLASSES. Por ejemplo, si el administrador elige instalar las páginas de comando man asociadas a este paquete, la clase man se agrega al parámetro CLASSES.
Si es así, ¿dónde se debe colocar esta parte del paquete?
La variable de entorno adecuada se configura con la respuesta a esta pregunta. En el ejemplo de la página de comando man, la variable $NCMPMAN se configura con el valor de la respuesta.
Estas dos preguntas se repiten para cada uno de los tres tipos de objetos.
Al final de la secuencia de comandos request, los parámetros quedan disponibles para el entorno de instalación para el comando pkgadd y otras secuencias de comandos de creación de paquetes. Para ello, la secuencia de comandos request escribe estas definiciones en el archivo proporcionado por la utilidad de llamadas. Para este caso práctico no se proporcionan otras secuencias de comandos.
Al consultar la secuencia de comandos request para este caso práctico, tenga en cuenta que las preguntas se generan mediante las herramientas de validación de datos ckyorn y ckpath. Para obtener más información sobre estas herramientas, consulte ckyorn(1) y ckpath(1).
PKG=ncmp NAME=NCMP Utilities CATEGORY=application, tools BASEDIR=/ ARCH=SPARC VERSION=RELEASE 1.0, Issue 1.0 CLASSES="" NCMPBIN=/bin NCMPMAN=/usr/man EMACS=/usr/emacs |
i pkginfo i request x bin $NCMPBIN 0755 root other f bin $NCMPBIN/dired=/usr/ncmp/bin/dired 0755 root other f bin $NCMPBIN/less=/usr/ncmp/bin/less 0755 root other f bin $NCMPBIN/ttype=/usr/ncmp/bin/ttype 0755 root other f emacs $NCMPBIN/emacs=/usr/ncmp/bin/emacs 0755 root other x emacs $EMACS 0755 root other f emacs $EMACS/ansii=/usr/ncmp/lib/emacs/macros/ansii 0644 root other f emacs $EMACS/box=/usr/ncmp/lib/emacs/macros/box 0644 root other f emacs $EMACS/crypt=/usr/ncmp/lib/emacs/macros/crypt 0644 root other f emacs $EMACS/draw=/usr/ncmp/lib/emacs/macros/draw 0644 root other f emacs $EMACS/mail=/usr/ncmp/lib/emacs/macros/mail 0644 root other f emacs $NCMPMAN/man1/emacs.1=/usr/ncmp/man/man1/emacs.1 0644 root other d man $NCMPMAN 0755 root other d man $NCMPMAN/man1 0755 root other f man $NCMPMAN/man1/dired.1=/usr/ncmp/man/man1/dired.1 0644 root other f man $NCMPMAN/man1/ttype.1=/usr/ncmp/man/man1/ttype.1 0644 root other f man $NCMPMAN/man1/less.1=/usr/ncmp/man/man1/less.1 0644 inixmr other |
trap 'exit 3' 15 # determine if and where general executables should be placed ans=`ckyorn -d y \ -p "Should executables included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES bin" NCMPBIN=`ckpath -d /usr/ncmp/bin -aoy \ -p "Where should executables be installed" ` || exit $? fi # determine if emacs editor should be installed, and if it should # where should the associated macros be placed ans=`ckyorn -d y \ -p "Should emacs editor included in this package be installed" ` || exit $? if [ "$ans" = y ] then CLASSES="$CLASSES emacs" EMACS=`ckpath -d /usr/ncmp/lib/emacs -aoy \ -p "Where should emacs macros be installed" ` || exit $? fi |
Tenga en cuenta que una secuencia de comandos request puede salir sin dejar archivos en el sistema de archivos. En el caso de instalaciones en versiones de Solaris anteriores a 2.5 y versiones compatibles (donde no se pueda usar una secuencia de comandos checkinstall) la secuencia de comandos request es el lugar correcto para probar el sistema de archivos del modo necesario para asegurar que la instalación será satisfactoria. Cuando la secuencia de comandos request se termina con el código 1, la instalación se cerrará correctamente.
Estos archivos de ejemplo muestran el uso de rutas paramétricas para establecer varios directorios base. Sin embargo, el método preferido implica el uso del parámetro BASEDIR que se administra y se valida mediante el comando pkgadd. Siempre que se usen varios directorios base, tenga un cuidado especial en proporcionarlos para la instalación de varias versiones y arquitecturas de la misma plataforma.
Este caso práctico crea un archivo de base de datos en el tiempo de la instalación y guarda una copia de la base de datos cuando el paquete se suprime.
Este caso práctico muestra las técnicas siguientes:
Uso de clases y secuencias de comandos de acción de clase para llevar a cabo acciones especiales en diferentes conjuntos de objetos
Para obtener más información, consulte Escritura de secuencias de comandos de acción de clase.
El uso del archivo space para informar al comando pkgadd que se necesita espacio extra para instalar este paquete adecuadamente
Para obtener más información sobre el archivo space, consulte Reserva del espacio adicional en un sistema de destino.
Uso del comando installf para instalar un archivo que no se ha definido en los archivos prototype y pkgmap.
Para crear un archivo de base de datos en la instalación y guardar una copia tras la eliminación de este caso práctico, debe completar las tareas siguientes:
Defina tres clases.
El paquete de este caso práctico precisa que las tres clases siguientes se definan en el parámetro CLASSES:
La clase estándar de none, que contiene un conjunto de procesos que pertenecen al subdirectorio bin.
La clase admin, que contiene un archivo ejecutable config y un directorio que contiene archivos de datos.
La clase cfgdata, que contiene un directorio.
Convierta al paquete en reubicable colectivamente.
Observe que en el archivo prototype ninguno de los nombres de ruta comienza por una barra inclinada o una variable de entorno. Esto indica que son reubicables colectivamente.
Calcule la cantidad de espacio que el archivo de base de datos necesita y cree un archivo space que entregar con el paquete. Este archivo avisa al comando pkgadd que el paquete necesita espacio extra y especifica cuánto.
Cree una secuencia de comandos de acción de clase para la clase admin (i.admin).
La secuencia de comandos de ejemplo inicializa una base de datos mediante archivos de datos que pertenecen a la clase admin. Para llevar a cabo esta tarea, hace lo siguiente:
Copia del archivo de datos de origen en el destino adecuado
Crea un archivo vacío con el nombre config.data y lo asigna a una clase de cfgdata
Ejecuta el comando bin/config (entregado con el paquete y ya instalado) para rellenar el archivo de base de datos config.data mediante los archivos de datos que pertenecen a la clase admin
Ejecuta el comando installf -f para terminar la instalación de config.data
No se precisa una acción especial para la clase admin en el tiempo de la eliminación por lo que no se crea una secuencia de comandos de acción de clase de eliminación. Esto significa que todos los archivos y directorios de la clase admin se suprimen del sistema.
Cree una secuencia de comandos de acción de clase de eliminación para la clase cfgdata (r.cfgdata).
La secuencia de comandos de eliminación hace una copia del archivo de la base de datos antes de que se suprima. No se precisa una acción especial para esta clase en el tiempo de la instalación, por lo que no se necesita una secuencia de comandos de acción de clase de instalación.
Recuerde que la entrada de información a una secuencia de comandos de eliminación es una lista de nombres de ruta que suprimir. Los nombres de ruta siempre aparecen en orden alfabético inverso. Esta secuencia de comandos de eliminación copia archivos en el directorio llamado $PKGSAV. Cuando todos los nombres de ruta se han procesado, la secuencia de comandos vuelve y suprime todos los directorios y archivos asociados a la clase cfgdata.
La salida de esta secuencia de comandos de eliminación es copiar config.data en $PKGSAV y después suprimir el archivo config.data y el directorio de datos.
PKG=krazy NAME=KrAzY Applications CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1 CLASSES=none cfgdata admin |
i pkginfo i request i i.admin i r.cfgdata d none bin 555 root sys f none bin/process1 555 root other f none bin/process2 555 root other f none bin/process3 555 root other f admin bin/config 500 root sys d admin cfg 555 root sys f admin cfg/datafile1 444 root sys f admin cfg/datafile2 444 root sys f admin cfg/datafile3 444 root sys f admin cfg/datafile4 444 root sys d cfgdata data 555 root sys |
# extra space required by config data which is # dynamically loaded onto the system data 500 1 |
# PKGINST parameter provided by installation service # BASEDIR parameter provided by installation service while read src dest do cp $src $dest || exit 2 done # if this is the last time this script will be executed # during the installation, do additional processing here. if [ "$1" = ENDOFCLASS ] then # our config process will create a data file based on any changes # made by installing files in this class; make sure the data file # is in class `cfgdata' so special rules can apply to it during # package removal. installf -c cfgdata $PKGINST $BASEDIR/data/config.data f 444 root sys || exit 2 $BASEDIR/bin/config > $BASEDIR/data/config.data || exit 2 installf -f -c cfgdata $PKGINST || exit 2 fi exit 0 |
Esto ilustra una instancia poco común en la que installf es adecuado en una secuencia de comandos de acción de clase. Debido a que se ha usado un archivo space para reservar espacio en un sistema de archivos específico, este nuevo archivo se puede agregar de forma segura aunque no se incluya en el archivo pkgmap.
# the product manager for this package has suggested that # the configuration data is so valuable that it should be # backed up to $PKGSAV before it is removed! while read path do # path names appear in reverse lexical order. mv $path $PKGSAV || exit 2 rm -f $path || exit 2 done exit 0 |
El paquete de este caso práctico usa archivos de información optativos para definir dependencias y compatibilidades de paquetes, así como para presentar un mensaje de copyright durante la instalación.
Este caso práctico muestra las técnicas siguientes:
Uso del archivo copyright
Uso del archivo compver
Uso del archivo depend
Para obtener más información sobre estos archivos, consulte Creación de archivos de información.
Para cumplir los requisitos de la descripción debe:
Crear un archivo copyright.
Un archivo copyright contiene el texto ASCII de un mensaje de copyright. El mensaje que se muestra en el archivo de ejemplo aparece en la pantalla durante la instalación del paquete.
Crear un archivo compver.
El archivo pkginfo que aparece en la figura siguiente define la versión de este paquete como 3.0. El archivo compver define la versión 3.0 como compatible con las versiones 2.3, 2.2, 2.1, 2.1.1, 2.1.3 y 1.7.
Crear un archivo depend.
Los archivos enumerados en un archivo depend ya deben estar instalados en el sistema cuando se instala un paquete. El archivo de ejemplo tiene 11 paquetes que ya deben estar en el sistema en el tiempo de la instalación.
PKG=case3 NAME=Case Study #3 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 3.0 CLASSES=none |
Copyright (c) 1999 company_name All Rights Reserved. THIS PACKAGE CONTAINS UNPUBLISHED PROPRIETARY SOURCE CODE OF company_name. The copyright notice above does not evidence any actual or intended publication of such source code |
Version 3.0 Version 2.3 Version 2.2 Version 2.1 Version 2.1.1 Version 2.1.3 Version 1.7 |
P acu Advanced C Utilities Issue 4 Version 1 P cc C Programming Language Issue 4 Version 1 P dfm Directory and File Management Utilities P ed Editing Utilities P esg Extended Software Generation Utilities Issue 4 Version 1 P graph Graphics Utilities P rfs Remote File Sharing Utilities Issue 1 Version 1 P rx Remote Execution Utilities P sgs Software Generation Utilities Issue 4 Version 1 P shell Shell Programming Utilities P sys System Header Files Release 3.1 |
Este caso práctico modifica un archivo durante la instalación del paquete mediante secuencias de comandos de acción de clase y clases estándar. Usa uno de los tres métodos de modificación. Los otros dos métodos se describen en Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall y Modificación de un archivo mediante la clase build. El archivo modificado es /etc/inittab .
Este caso práctico muestra cómo usar secuencias de comandos de acción de clase de instalación y eliminación. Para obtener más información, consulte Escritura de secuencias de comandos de acción de clase.
Para modificar /etc/inittab durante la instalación, mediante secuencias de comandos de acción de clase y clases, debe completar las tareas siguientes:
Crear una clase.
Cree una clase llamada inittab . Debe proporcionar una secuencia de comandos de acción de clase de instalación y eliminación para esta clase. Defina la clase inittab en el parámetro CLASSES del archivo pkginfo.
Crear un archivo inittab.
Este archivo contiene la información para la entrada que desea agregar a /etc/inittab . Observe en la figura del archivo prototype que inittab forma parte de la clase inittab y que tiene un tipo de archivo de e para editar.
Crear una secuencia de comandos de acción de clase de instalación (i.inittab).
Recuerde que las secuencias de comandos de acción de clase deben producir los mismos resultados cada vez que se ejecutan. La secuencia de comandos de acción de clase ejecuta estos pasos:
Comprueba si la entrada se ha agregado anteriormente
Si es así, suprime las versiones anteriores de la entrada
Modifica el archivo inittab y agrega líneas de comentarios para que sepa de dónde procede la entrada
Mueve el archivo temporal a /etc/inittab
Ejecuta el comando init q cuando recibe el indicador ENDOFCLASS
Tenga en cuenta que el comando init q se puede ejecutar mediante esta secuencia de comandos de instalación. Esta aproximación no necesita una secuencia de comandos de postinstall de una línea.
Crear una secuencia de comandos de acción de clase de eliminación (r.inittab).
La secuencia de comandos de eliminación es muy parecida a la de instalación. La información agregada por la secuencia de comandos de instalación se suprime y se ejecuta el comando init q.
Este caso práctico es más complicado que el siguiente; consulte Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall. En lugar de proporcionar dos archivos se necesitan tres; el archivo /etc/inittab entregado es simplemente un marcador de posición que contiene un fragmento de la entrada que se va a insertar. Ésta se podría haber colocado en el archivo i.inittab, a excepción de que el comando pkgadd debe tener un archivo para pasar al archivo i.inittab. Asimismo, el procedimiento de eliminación debe colocarse en un archivo aparte (r.inittab). Mientras este método funcione bien, es mejor reservarlo para casos que impliquen instalaciones muy complicadas de varios archivos. Consulte Modificación de archivos crontab durante la instalación.
El programa sed usado en Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall admite varias instancias de paquetes, ya que el comentario del final de la entrada inittab se basa en la instancia del paquete. El caso práctico de Modificación de un archivo mediante la clase build muestra una aproximación más simplificada para la modificación de /etc/inittab durante la instalación.
PKG=case5 NAME=Case Study #5 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=inittab |
i pkginfo i i.inittab i r.inittab e inittab /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 sed -e "s/$/#$PKGINST" $src >> /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done if [ "$1" = ENDOFCLASS ] then /sbin/init q || exit 2 fi exit 0 |
# PKGINST parameter provided by installation service while read src dest do # remove all entries from the table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" $dest > /tmp/$$itab || exit 2 mv /tmp/$$itab $dest || exit 2 done /sbin/init q || exit 2 exit 0 |
rb:023456:wait:/usr/robot/bin/setup |
Este caso práctico modifica un archivo que existe en la máquina de instalación durante la instalación del paquete. Usa uno de los tres métodos de modificación. Los otros dos métodos se describen en Modificación de un archivo mediante secuencias de comandos de acción de clase y clases estándar y Modificación de un archivo mediante la clase build. El archivo modificado es /etc/inittab.
Este caso práctico muestra las técnicas siguientes:
Uso de la clase sed
Para obtener más información sobre la clase sed, consulte Secuencia de comandos de clase sed.
Uso de una secuencia de comandos postinstall
Para obtener más información sobre esta secuencia de comandos, consulte Escritura de secuencias de comandos de procedimientos.
Para modificar /etc/inittab en el tiempo de la instalación mediante la clase sed, debe completar las tareas siguientes:
Agregue la secuencia de comandos de clase sed al archivo prototype.
El nombre de una secuencia de comandos debe ser el mismo que el del archivo que se modificará. En este caso, el archivo que se debe modificar es /etc/inittab y por lo tanto la secuencia de comandos sed debe recibir el nombre de /etc/inittab. No hay requisitos para el modo, propietario y grupo de una secuencia de comandos sed (se representa en el ejemplo de prototype mediante signos de interrogación). El tipo de archivo de la secuencia de comandos sed debe ser e (para indicar que es modificable).
Configure el parámetro CLASSES para que incluya la clase sed.
Tal como se muestra en el archivo de ejemplo, sed es la única clase que se instala. Sin embargo, puede ser cualquier número de clases.
Crear una secuencia de comandos de acción de clase sed.
El paquete no puede entregar una copia de /etc/inittab que tenga el aspecto que necesite, ya que /etc/inittab es un archivo dinámico y no tiene forma de saber el aspecto que tendrá en el tiempo de la instalación del paquete. Sin embargo, el uso de una secuencia de comandos sed permite modificar el archivo /etc/inittab durante la instalación del paquete.
Crear una secuencia de comandos postinstall.
Debe ejecutar el comando init q para informar al sistema de que /etc/inittab se ha modificado. El único lugar en que puede ejecutar dicha acción en este ejemplo es en una secuencia de comandos postinstall. Si mira a la secuencia de comandos postinstall de ejemplo, verá que su única finalidad es ejecutar el comando init q.
Esta aproximación a la modificación de /etc/inittab durante la instalación tiene un inconveniente: debe entregar una secuencia de comandos completa (la secuencia de comandos postinstall) simplemente para ejecutar el comando init q.
PKG=case4 NAME=Case Study #4 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=sed |
i pkginfo i postinstall e sed /etc/inittab ? ? ? |
!remove # remove all entries from the table that are associated # with this package, though not necessarily just # with this package instance /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d !install # remove any previous entry added to the table # for this particular change /^[^:]*:[^:]*:[^:]*:[^#]*#ROBOT$/d # add the needed entry at the end of the table; # sed(1) does not properly interpret the '$a' # construct if you previously deleted the last # line, so the command # $a\ # rb:023456:wait:/usr/robot/bin/setup #ROBOT # will not work here if the file already contained # the modification. Instead, you will settle for # inserting the entry before the last line! $i\ rb:023456:wait:/usr/robot/bin/setup #ROBOT |
# make init re-read inittab /sbin/init q || exit 2 exit 0 |
Este caso práctico modifica un archivo que existe en la máquina de instalación durante la instalación del paquete. Usa uno de los tres métodos de modificación. Los otros dos métodos se describen en Modificación de un archivo mediante secuencias de comandos de acción de clase y clases estándar y Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall. El archivo modificado es /etc/inittab.
En este caso práctico se muestra cómo usar la clase build. Para obtener más información sobre la clase build, consulte Secuencia de comandos de clase build.
Esta aproximación a la modificación de /etc/inittab usa la clase build. Una secuencia de comandos de clase build se ejecuta como secuencia de comandos de shell y su salida se convierte en la nueva versión del archivo que se está ejecutando. En otras palabras, el archivo de datos /etc/inittab que se entrega con este paquete se ejecutará y la salida de dicha ejecución se convertirá en /etc/inittab.
La secuencia de comandos de clase build se ejecuta durante la instalación y la eliminación del paquete. El argumento install se pasa al archivo si se ejecuta en el tiempo de la instalación. Observe en la secuencia de comandos de clase build de ejemplo que las acciones de instalación se definen mediante la prueba para este argumento.
Para editar /etc/inittab mediante la clase build, debe completar las tareas siguientes:
Definir el archivo build en el archivo prototype.
La entrada para el archivo build en el archivo prototype debe colocarla en la clase build y definir su tipo de archivo como e. Asegúrese de que el parámetro CLASSES del archivo pkginfo se define como build.
Crear la secuencia de comandos de clase build.
La secuencia de comandos de clase build de ejemplo ejecuta los procesos siguientes:
Edita el archivo /etc/inittab para suprimir los cambios en este paquete. Observe que el nombre de archivo /etc/inittab no es modificable en el comando sed.
Si se está instalando el paquete, agrega la nueva línea al final de /etc/inittab. Se incluye una etiqueta de comentario en esta nueva entrada para describir de dónde viene dicha entrada.
Ejecuta el comando init q.
Esta solución reconduce los inconvenientes descritos en los casos prácticos de Modificación de un archivo mediante secuencias de comandos de acción de clase y clases estándar y Modificación de un archivo mediante la clase sed y una secuencia de comandos postinstall. Sólo se necesita un archivo corto (más allá de los archivos pkginfo y prototype). El archivo funciona con varias instancias de un paquete debido a que se usa el parámetro PKGINST y no se requiere una secuencia de comandos postinstall, ya que el comando init q se puede ejecutar desde la secuencia de comandos de clase build.
PKG=case6 NAME=Case Study #6 CATEGORY=applications BASEDIR=/opt ARCH=SPARC VERSION=Version 1d05 CLASSES=build |
i pkginfo e build /etc/inittab ? ? ? |
# PKGINST parameter provided by installation service # remove all entries from the existing table that # are associated with this PKGINST sed -e "/^[^:]*:[^:]*:[^:]*:[^#]*#$PKGINST$/d" /etc/inittab || exit 2 if [ "$1" = install ] then # add the following entry to the table echo "rb:023456:wait:/usr/robot/bin/setup #$PKGINST" || exit 2 fi /sbin/init q || exit 2 exit 0 |
Este caso práctico modifica los archivos crontab durante la instalación del paquete.
Este caso práctico muestra las técnicas siguientes:
Uso de secuencias de comandos de acción de clase y clases
Para obtener más información, consulte Escritura de secuencias de comandos de acción de clase.
Uso del comando crontab en una secuencia de comandos de acción de clase.
El modo más eficaz de modificar más de un archivo durante la instalación es definir una clase y ofrecer una secuencia de comandos de acción de clase. Si se ha servido de la aproximación a la clase build, debe entregar una secuencia de comandos de clase build para cada archivo crontab modificado. La definición de una clase cron proporciona una aproximación más general. Para editar los archivos crontab con esta aproximación, debe:
Definir los archivos crontab que se van a modificar en el archivo prototype.
Cree una entrada en el archivo prototype para cada archivo crontab que se modificará. Defina la clase como cron y el tipo de archivo como e para cada archivo. Use el nombre real del archivo que se va a modificar.
Crear los archivos crontab para el paquete.
Estos archivos contienen la información que desea agregar a los archivos crontab existentes del mismo nombre.
Crear una secuencia de comandos de acción de clase de instalación para la clase cron.
La secuencia de comandos i.cron de ejemplo ejecuta los procesos siguientes:
Determina el ID de usuario (UID).
La secuencia de comandos i.cron configura la variable usuario con el nombre base de la secuencia de comandos de clase cron que se está procesando. Ese nombre es el UID. Por ejemplo, el nombre base de /var/spool/cron/crontabs/root es raíz, además del UID.
Ejecuta crontab mediante el UID y la opción -l.
El uso de la opción -l indica a crontab que envíe el contenido del archivo crontab del usuario definido a la salida estándar.
Dirige la salida del comando crontab a una secuencia de comandos sed que suprime las entradas anteriores agregadas con esta técnica de instalación.
Coloca la salida modificada en un archivo temporal.
Agrega el archivo de datos del UID raíz (que se entregó con el paquete) al archivo temporal y agrega una etiqueta para que sepa de dónde vienen estas entradas.
Ejecuta crontab con el mismo UID y le entrega el archivo temporal como entrada de información.
Crear una secuencia de comandos de acción de clase de eliminación para la clase cron.
La secuencia de comandos r.cron es la misma que la secuencia de comandos de instalación excepto que no hay procesos para agregar información al archivo crontab.
Estos procesos se llevan a cabo para cada archivo en la clase cron.
Un superusuario ejecuta las secuencias de comandos i.cron y r.cron que se describen a continuación. La modificación del archivo crontab de otro usuario puede tener resultados imprevistos. Si fuera necesario, cambie la entrada siguiente de cada secuencia de comandos:
crontab $user < /tmp/$$crontab ||
hasta
su $user -c "crontab /tmp/$$crontab" ||
PKG=case7 NAME=Case Study #7 CATEGORY=application BASEDIR=/opt ARCH=SPARC VERSION=Version 1.0 CLASSES=cron |
i pkginfo i i.cron i r.cron e cron /var/spool/cron/crontabs/root ? ? ? e cron /var/spool/cron/crontabs/sys ? ? ? |
# PKGINST parameter provided by installation service while read src dest do user=`basename $dest` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 sed -e "s/$/#$PKGINST/" $src >> /tmp/$$crontab || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit 0 |
# PKGINST parameter provided by installation service while read path do user=`basename $path` || exit 2 (crontab -l $user | sed -e "/#$PKGINST$/d" > /tmp/$$crontab) || exit 2 crontab $user < /tmp/$$crontab || exit 2 rm -f /tmp/$$crontab done exit |
41,1,21 * * * * /usr/lib/uucp/uudemon.hour > /dev/null 45 23 * * * ulimit 5000; /usr/bin/su uucp -c "/usr/lib/uucp/uudemon.cleanup" > /dev/null 2>&1 11,31,51 * * * * /usr/lib/uucp/uudemon.poll > /dev/null |
0 * * * 0-6 /usr/lib/sa/sa1 20,40 8-17 * * 1-5 /usr/lib/sa/sa1 5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A |
Si la modificación de un grupo de archivos aumenta el tamaño total del archivo en más de 10K, proporcione un archivo space para que el comando pkgadd pueda permitir este aumento. Para obtener más información sobre el archivo space, consulte Reserva del espacio adicional en un sistema de destino.
Este paquete instala un controlador.
Este caso práctico muestra las técnicas siguientes:
Instalación y carga de un controlador con una secuencia de comandos postinstall
Descarga de un controlador con una secuencia de comandos preremove
Para obtener más información sobre estas secuencias de comandos, consulte Escritura de secuencias de comandos de procedimientos.
Crear una secuencia de comandos request.
La secuencia de comandos request determina dónde el administrador desea que se instalen los objetos del controlador: pregunta al administrador y asigna la respuesta al parámetro $KERNDIR.
La secuencia de comandos termina con una rutina para hacer que los dos parámetros CLASSES y KERNDIR estén disponibles en el entorno de instalación y la secuencia de comandos postinstall.
Crear una secuencia de comandos postinstall.
La secuencia de comandos postinstall lleva a cabo, de hecho, la instalación del controlador. Se ejecuta después de que los dos archivos buffer y buffer.conf se hayan instalado. El archivo postinstall mostrado en este ejemplo lleva a cabo las acciones siguientes:
Usa el comando add_drv para cargar el controlador en el sistema.
Crea un vínculo para el dispositivo mediante el comando installf.
Termina la instalación mediante el comando installf -f.
Crea una secuencia de comandos preremove.
La secuencia de comandos preremove usa el comando rem_drv para descargar el controlador del sistema y después suprime el vínculo /dev/buffer0 .
PKG=bufdev NAME=Buffer Device CATEGORY=system BASEDIR=/ ARCH=INTEL VERSION=Software Issue #19 CLASSES=none |
Para instalar un controlador en el tiempo de la instalación, debe incluir los archivos de configuración y objetos para el controlador en el archivo prototype.
En este ejemplo, el módulo ejecutable del controlador recibe el nombre de buffer; el comando add_drv funciona en este archivo. El núcleo usa el archivo de configuración, buffer.conf, para ayudar a configurar el controlador.
i pkginfo i request i postinstall i preremove f none $KERNDIR/buffer 444 root root f none $KERNDIR/buffer.conf 444 root root |
Si mira al archivo prototype de este ejemplo, puede observar lo siguiente:
Puesto que no se necesita un tratamiento especial para los objetos de paquete, puede colocarlos en la clase none estándar. El parámetro CLASSES se configura con el valor none en el archivo pkginfo.
Los nombres de ruta de buffer y buffer.conf comienzan por la variable $KERNDIR. Esta variable se configura en la secuencia de comandos request y permite al administrador decidir dónde se deben instalar los archivos del controlador. El directorio predeterminado es /kernel/drv.
Hay una entrada para la secuencia de comandos postinstall (la secuencia de comandos que ejecutará la instalación del controlador).
trap 'exit 3' 15 # determine where driver object should be placed; location # must be an absolute path name that is an existing directory KERNDIR=`ckpath -aoy -d /kernel/drv -p \ “Where do you want the driver object installed”` || exit $? # make parameters available to installation service, and # so to any other packaging scripts cat >$1 <<! CLASSES='$CLASSES' KERNDIR='$KERNDIR' ! exit 0 |
# KERNDIR parameter provided by `request' script err_code=1 # an error is considered fatal # Load the module into the system cd $KERNDIR add_drv -m '* 0666 root sys' buffer || exit $err_code # Create a /dev entry for the character node installf $PKGINST /dev/buffer0=/devices/eisa/buffer*:0 s installf -f $PKGINST |
err_code=1 # an error is considered fatal # Unload the driver rem_drv buffer || exit $err_code # remove /dev file removef $PKGINST /dev/buffer0 ; rm /dev/buffer0 removef -f $PKGINST |
En este caso práctico se describe cómo instalar un controlador mediante las secuencias de comandos de procedimientos y la clase sed. También es diferente del caso práctico anterior (consulte Instalación y eliminación de un controlador con secuencias de comandos de procedimientos) porque este paquete se compone de objetos absolutos y reubicables.
Este caso práctico muestra las técnicas siguientes:
Construcción de un archivo prototype con objetos reubicables y absolutos.
Para obtener más información sobre la construcción de un archivo prototype, consulte Creación de un archivo prototype.
Uso de una secuencia de comandos postinstall
Para obtener más información sobre esta secuencia de comandos, consulte Escritura de secuencias de comandos de procedimientos.
Uso de una secuencia de comandos preremove.
Para obtener más información sobre esta secuencia de comandos, consulte Escritura de secuencias de comandos de procedimientos.
Uso de un archivo copyright
Para obtener más información sobre este archivo, consulte Escritura de un mensaje de copyright.
Crear un archivo prototype que contenga objetos de paquetes reubicables y absolutos.
Puede ver todos los detalles en El archivo prototype.
Agregue la secuencia de comandos de clase sed al archivo prototype.
El nombre de una secuencia de comandos debe ser el mismo que el del archivo que se modificará. En este caso, el archivo que se debe modificar es /etc/devlink.tab y por lo tanto la secuencia de comandos sed recibe el nombre de /etc/devlink.tab. No hay requisitos para el modo, propietario y grupo de una secuencia de comandos sed (se representa en el ejemplo de prototype mediante signos de interrogación). El tipo de archivo de la secuencia de comandos sed debe ser e (para indicar que es modificable).
Configure el parámetro CLASSES para que incluya la clase sed.
Crear una secuencia de comandos de acción de clase sed ( /etc/devlink.tab ).
Crear una secuencia de comandos postinstall.
La secuencia de comandos postinstall necesita ejecutar el comando add_drv para agregar el controlador de dispositivos al sistema.
Crear una secuencia de comandos preremove.
La secuencia de comandos preremove necesita ejecutar el comando rem_drv para suprimir el controlador de dispositivos del sistema, antes del paquete que se va a suprimir.
Crear un archivo copyright.
Un archivo copyright contiene el texto ASCII de un mensaje de copyright. El mensaje que se muestra en el archivo de ejemplo aparece en la pantalla durante la instalación del paquete.
PKG=SUNWsst NAME=Simple SCSI Target Driver VERSION=1 CATEGORY=system ARCH=sparc VENDOR=Sun Microsystems BASEDIR=/opt CLASSES=sed |
Por ejemplo, este caso práctico usa la distribucion jerárquica de los objetos de paquete que se muestran en la figura siguiente.
Los objetos el paquete se instalan en los mismos lugares que en el directorio pkg superior. Los módulos del controlador (sst y sst.conf) se instalan en /usr/kernel/drv y el archivo de inclusión se instala en /usr/include/sys/scsi/targets. Los archivos sst, sst.conf y sst_def.h son objetos absolutos. El programa de prueba, sstest.c, y su directorio SUNWsst, son reubicables; su ubicación de instalación se configura mediante el parámetro BASEDIR.
Los demás componentes del paquete (todos los archivos de control) se encuentran en el directorio superior del paquete en la máquina de desarrollo, excepto la secuencia de comandos de clase sed. Éste recibe el nombre de devlink.tab después del archivo al que modifica, y se sitúa en etc, el directorio que contiene el archivo devlink.tab real.
En el directorio pkg, ejecute el comando pkgproto del modo siguiente:
find usr SUNWsst -print | pkgproto > prototype |
La salida del comando anterior tiene este aspecto:
d none usr 0775 pms mts d none usr/include 0775 pms mts d none usr/include/sys 0775 pms mts d none usr/include/sys/scsi 0775 pms mts d none usr/include/sys/scsi/targets 0775 pms mts f none usr/include/sys/scsi/targets/sst_def.h 0444 pms mts d none usr/kernel 0775 pms mts d none usr/kernel/drv 0775 pms mts f none usr/kernel/drv/sst 0664 pms mts f none usr/kernel/drv/sst.conf 0444 pms mts d none SUNWsst 0775 pms mts f none SUNWsst/sstest.c 0664 pms mts |
Este archivo prototype aún no está completo. Para completar este archivo, necesita hacer las modificaciones siguientes:
Inserte las entradas para los archivos de control (tipo de archivo i), ya que tienen un formato diferente de los demás objetos del paquete.
Suprima entradas de los directorios que ya existen en el sistema de destino.
Cambie el permiso de acceso y la propiedad de cada entrada.
Anteponga una barra oblicua a los objetos de paquetes absolutos.
Éste es el archivo prototype final:
i pkginfo i postinstall i preremove i copyright e sed /etc/devlink.tab ? ? ? f none /usr/include/sys/scsi/targets/sst_def.h 0644 bin bin f none /usr/kernel/drv/sst 0755 root sys f none /usr/kernel/drv/sst.conf 0644 root sys d none SUNWsst 0775 root sys f none SUNWsst/sstest.c 0664 root sys |
Los signos de interrogación en la entrada para la secuencia de comandos sed indican que los permisos de acceso y la propiedad del archivo existente en la maquina de instalación no se deben cambiar.
En el ejemplo de controlador, se utiliza una secuencia de comandos de clase sed con el fin de agregar una entrada para el controlador en el archivo /etc/devlink.tab. El comando devlinks utiliza este archivo para crear vínculos simbólicos de /dev en /devices. Ésta es la secuencia de comandos sed:
# sed class script to modify /etc/devlink.tab !install /name=sst;/d $i\ type=ddi_pseudo;name=sst;minor=character rsst\\A1 !remove /name=sst;/d |
El comando pkgrm no ejecuta la parte de eliminación de la secuencia de comandos. Puede que necesite agregar una línea a la secuencia de comandos preremove para ejecutar directamente sed con el fin de suprimir la entrada del archivo /etc/devlink.tab.
En este ejemplo, todo lo que necesita hacer la secuencia de comandos es ejecutar el comando add_drv.
# Postinstallation script for SUNWsst # This does not apply to a client. if [$PKG_INSTALL_ROOT = "/" -o -z $PKG_INSTALL_ROOT]; then SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/add_drv sst STATUS=$? BASEDIR=$SAVEBASE; export BASEDIR if [ $STATUS -eq 0 ] then exit 20 else exit 2 fi else echo "This cannot be installed onto a client." exit 2 fi |
El comando add_drv usa el parámetro BASEDIR, de forma que la secuencia de comandos debe anular la configuración de BASEDIR antes de ejecutar el comando y restaurarla después.
Una de las acciones del comando add_drv es ejecutar devlinks que usa la entrada situada en /etc/devlink.tab por la secuencia de comandos de clase sed para crear las entradas /dev para el controlador.
El código de salida de la secuencia de comandos postinstall es importante. El código de salida 20 comunica al comando pkgadd que indique al usuario que debe reiniciar el sistema (necesario después de instalar un controlador); el código de salida 2 comunica al comando pkgadd que indique al usuario que la instalación ha fallado de manera parcial.
En el caso de este ejemplo de controlador, suprime los vínculos en /dev y ejecuta el comando rem_drv en el controlador.
# Pre removal script for the sst driver echo “Removing /dev entries” /usr/bin/rm -f /dev/rsst* echo “Deinstalling driver from the kernel” SAVEBASE=$BASEDIR BASEDIR=””; export BASEDIR /usr/sbin/rem_drv sst BASEDIR=$SAVEBASE; export BASEDIR exit |
La secuencia de comandos suprime por sí misma las entradas de /dev; el comando rem_drv suprime las entradas /devices.
Éste es un archivo ASCII simple que contiene el texto de un aviso de copyright. El aviso se muestra al comienzo de la instalación del paquete, exactamente como aparece en el archivo.
Copyright (c) 1999 Drivers-R-Us, Inc. 10 Device Drive, Thebus, IO 80586 All rights reserved. This product and related documentation is protected by copyright and distributed under licenses restricting its use, copying, distribution and decompilation. No part of this product or related documentation may be reproduced in any form by any means without prior written authorization of Drivers-R-Us and its licensors, if any. |