| Omitir V�nculos de navegaci�n | |
| Salir de la Vista de impresi�n | |
|
Páginas del comando man de Image Packaging System Oracle Solaris 11 Information Library (Español) |
| Omitir V�nculos de navegaci�n | |
| Salir de la Vista de impresi�n | |
|
|
Páginas del comando man de Image Packaging System Oracle Solaris 11 Information Library (Español) |
- Image Packaging System
El sistema de empaquetado de imágenes, pkg(5), es una estructura que facilita la administración del ciclo de vida del software (instalación, actualización y eliminación). El sistema de empaquetado de imágenes administra el software en unidades de paquetes, que son recopilaciones de acciones, definidas por un conjunto de pares de clave y valor y, posiblemente, una carga útil de datos. En muchos casos, las acciones son archivos que se encuentran en un sistema de archivos, pero también representan otros objetos instalables, como controladores, servicios y usuarios.
Cada paquete es representado por un identificador de recursos de gestión de errores (FMRI) con el esquema pkg:. El FMRI completo de un paquete está compuesto por el esquema, un editor, el nombre del paquete y una cadena de versión con el formato siguiente:
pkg://solaris/system/library/c++-runtime@0.5.11,5.11-0.174.0.0.0.0.0:20110921T190358Z
solaris es el editor. system/library/c++-runtime es el nombre del paquete. Si bien el espacio de nombres es jerárquico y tiene una profundidad arbitraria, no se aplica una contención; el nombre es básicamente arbitrario. La información del editor es opcional, pero debe estar precedida por pkg:// si está presente. Si un FMRI incluye al editor a menudo se lo denomina "completo". Si la información del editor no está presente, el nombre del paquete debe estar precedido por pkg:/.
A menudo los clientes de empaquetado permiten que el esquema de un FMRI se omita si no contiene información del editor. Por ejemplo, pkg:/system/library/c++-runtime se puede escribir como system/library/c++-runtime. Si el esquema se omite, los clientes también permiten la omisión de todos los componentes de un nombre de paquete excepto el último para favorecer la coincidencia. Por ejemplo, system/library/c++-runtime se podría escribir como library/c++-runtime o c++-runtime, que coincidiría con los paquetes denominados c++-runtime o con los nombres de paquetes que finalicen en /c++-runtime.
Un nombre de editor identifica a una persona, un grupo de personas o una organización como el origen de uno o varios paquetes. Para evitar conflictos entre nombres de editores y ayudar a identificar al editor, se aconseja utilizar como nombre de editor un nombre de dominio que represente a la entidad que publica los paquetes.
La versión se indica a continuación del nombre del paquete, separada por un signo arroba (@). La versión consta de cuatro secuencias de números, separados por puntuación. Los elementos de las tres primeras secuencias están separados por puntos, y las secuencias tienen una longitud arbitraria. No se permiten ceros al principio de los componentes de la versión (por ejemplo, 01.1 o 1.01). Se permiten ceros a la derecha (por ejemplo, 1,10).
La primera parte de la versión es la versión del componente. Para los componentes estrictamente ligados al sistema operativo, éste suele ser el valor de uname -r para esa versión del sistema operativo. Para un componente con su propio ciclo de desarrollo, esta secuencia es un número de versión separado por puntos, como 2.4.10.
La segunda parte de la versión, que si está presente debe estar precedida por una coma (,), es la versión de generación. La versión de generación especifica en qué versión del sistema operativo se generó el contenido del paquete, lo cual proporciona una limitación mínima respecto de la versión del sistema operativo en la que se puede esperar que el contenido se ejecute correctamente.
La tercera parte de la versión, que si está presente debe estar precedida por un guión (-), es la versión de ramificación. La versión de ramificación es un componente de versión que proporciona información específica del proveedor. La versión de ramificación puede aumentar cuando se cambian los metadatos de empaquetado, independientemente de la versión de componente. La versión de ramificación puede incluir un número de generación u otra información.
La cuarta parte de la versión, que si está presente debe estar precedida por dos puntos (:), es un indicador de fecha y hora. El indicador de fecha y hora indica cuándo se publicó el paquete.
Al realizar comparaciones entre versiones, no se considera ningún componente de la versión completa a menos que los componentes de la izquierda sean iguales. Por lo tanto, “4.3-1” es mayor que “4.2-7” porque “4.3” es mayor que “4.2”, y “4.3-3” es mayor que “4.3-1” porque “3” es mayor que “1”.
Muchas partes del sistema, cuando corresponde, abrevian los FMRI cuando los muestran y aceptan entradas en formatos más cortos para reducir el volumen de información que se muestra o se requiere. Normalmente, el esquema, el editor, la versión de generación, y el indicador de fecha y hora se pueden omitir. A veces se puede omitir toda la información de versión.
Las acciones representan los objetos instalables en un sistema. Las acciones se describen en el manifiesto de un paquete. Cada acción consta básicamente de su nombre y un atributo clave. Juntos, estos hacen referencia a un objeto exclusivo como se desprende un historial de versiones. Las acciones pueden tener otros atributos. Algunos atributos son interpretados directamente por el sistema de empaquetado. Otros atributos pueden ser útiles sólo para el administrador del sistema o el usuario final.
Las acciones tienen una representación textual simple:
action_name attribute1=value1 attribute2=value2 ...
Los nombres de los atributos no pueden incluir espacios en blanco, comillas ni signos de igual (=). Todos los caracteres que aparecen después del primer signo de igual pertenecen al valor. Los valores pueden incluir todos estos, aunque los espacios deben aparecer entre en comillas simples o dobles. A las comillas simples no es necesario aplicarles caracteres de escape dentro de una cadena que está entre comillas dobles, y a las comillas dobles no es necesario aplicarles caracteres de escape dentro de una cadena que está entre comillas simples. Una comilla puede estar precedida por una barra diagonal inversa (\) para evitar la terminación de la cadena citada. Una barra diagonal inversa se puede escapar con una barra diagonal inversa.
Los atributos pueden ser nombrados más de una vez con múltiples valores. Se tratan como listas desordenadas.
Las acciones con muchos atributos pueden crear líneas largas en un archivo de manifiesto. Estas líneas se pueden ajustar terminando cada línea incompleta con una barra diagonal inversa. Tenga en cuenta que este carácter de continuación se debe colocar entre los pares de atributo y valor. Ni los atributos ni sus valores ni la combinación se puede dividir.
Los atributos mencionados a continuación no abarcan la totalidad del conjunto. De hecho, los atributos que se pueden conectar a una acción son arbitrarios, y los conjuntos estándar de atributos son fáciles de aumentar para incorporar futuros desarrollos.
Determinados atributos de acción generan que se ejecuten operaciones adicionales fuera del contexto de empaquetado. Estos atributos se documentan en la sección “Activadores” a continuación.
La acción file representa un archivo normal. La acción file hace referencia a una carga útil y tiene cuatro atributos estándar:
La ruta del sistema de archivos donde se instala el archivo. Se·trata·del atributo clave de la acción file.
Los permisos de acceso (en formato numérico) del archivo. Estos son sólo algunos permisos simples, no son listas de control de acceso (ACL).
El nombre del usuario que posee el archivo.
El nombre del grupo que posee el archivo.
La carga útil es un atributo posicional desde el punto de vista de que no tiene nombre. Es la primera palabra después del nombre de acción. En un manifiesto publicado, es el hash SHA-1 del contenido del archivo. Si está presente en un manifiesto que aún tiene que ser publicado, representa la ruta donde se puede encontrar la carga útil. Consulte pkgsend(1). El atributo hash se puede utilizar en lugar del atributo posicional, si el valor incluye un signo igual. Ambos se pueden utilizar en la misma acción. Sin embargo, los hashes deben ser idénticos.
Entre los otros atributos se incluyen:
Esto especifica que el contenido del archivo no se debe sobrescribir en la actualización si se determina que el contenido ha cambiado desde la instalación o la última actualización del archivo. En las instalaciones iniciales, si se detecta un archivo existente, el archivo se recupera (se almacena en /var/pkg/lost+found).
Si el valor de preserve es renameold, el archivo existente es renombrado con la extensión .old y el archivo nuevo se coloca en su lugar.
Si el valor de preserve es renamenew, el archivo existente no se modifica y el archivo nuevo se instala con la extensión .new.
Si el valor de preserve es legacy, este archivo no se instala para las instalaciones iniciales de paquete. En las actualizaciones, cualquier archivo existente es renombrado con la extensión .legacy y el archivo nuevo se coloca en su lugar.
Si el valor de preserve es true (o un valor que no figura en la lista anterior, como strawberry), el archivo existente no se modifica y el archivo nuevo no se instala.
Especifica si la acción permite que otros paquetes entreguen un archivo en la misma ubicación o si entregan un archivo destinado a superponerse a otro. Esta funcionalidad está destinada únicamente para su uso con archivos de configuración que no participan en ningún autoensamblaje (por ejemplo, /etc/motd ) y que se pueden sobrescribir de manera segura.
Si overlay no se especifica, varios paquetes no pueden entregar archivos en la misma ubicación.
Si el valor de overlay es allow, otro paquete puede entregar un archivo en la misma ubicación. Este valor no tiene efecto, a menos que también se establezca el atributo preserve.
Si el valor de overlay es true, el archivo entregado por la acción sobrescribe cualquier otra acción que haya especificado allow. Los cambios realizados en el archivo instalado se conservan en función del valor del atributo preserve del archivo que se superpone. Durante la eliminación, el contenido del archivo se conserva si la acción que se está superponiendo aún está instalada, independientemente de si se especificó el atributo preserve. Sólo una acción puede superponer a otra, y los atributos mode, owner y group deben coincidir.
Los archivos también se pueden “probar” y, en función del tipo, pueden tener atributos adicionales. Para los archivos ELF, se reconocen los siguientes atributos:
La arquitectura del archivo ELF. Ésta es la salida de uname -p en la arquitectura para la que se crea el archivo.
Este es 32 o 64.
Este es el hash de las secciones ELF “interesantes” del archivo. Estas son las secciones que se asignan en la memoria cuando se carga el archivo binario. Estas son las únicas secciones que es necesario considerar al determinar si el comportamiento ejecutable de dos archivos binarios diferirá.
Este atributo se utiliza para manejar archivos editables que se mueven de un paquete a otro, desde un lugar a otro, o ambos. La forma que adopta es el nombre del paquete de origen, seguido de dos puntos y la ruta original del archivo. Cualquier archivo que se suprime se registra con su paquete y ruta, o con el valor del atributo original_name, si se especifica. Cualquier archivo editable que se instale que tenga el conjunto de atributos original_name utiliza el archivo con ese nombre si se suprime como parte de la misma operación de empaquetado.
Este atributo se utiliza para los archivos con etiquetas editables que se deben revertir como un conjunto. Se pueden especificar diversos valores revert-tag. El archivo vuelve al estado definido en el manifiesto cuando pkg revert se invoca con cualquiera de esas etiquetas especificadas. Consulte pkg(1).
La acción dir es similar a la acción file en que representa un objeto del sistema de archivos. La acción dir representa un directorio en lugar de un archivo normal. La acción dir tiene los mismos cuatro atributos estándar que la acción file, y path es el atributo clave.
Los directorios se cuentan como referencia en IPS. Cuando el último paquete que explícita o implícitamente hace referencia a un directorio ya no lo hace, ese directorio se elimina. Si ese directorio contiene objetos del sistema de archivos desempaquetados, los elementos se mueven a $IMAGE_META/lost+found. Consulte la sección “Archivos” para obtener más información sobre $IMAGE_META.
Para mover el contenido desempaquetado a un directorio nuevo, el atributo siguiente podría ser útil:
Esto nombra un directorio de elementos recuperados. Un directorio con dicho atributo hereda en el momento de su creación el contenido del directorio recuperado, si existe.
La acción link representa un vínculo simbólico. La acción link tiene los siguientes atributos estándar:
La ruta del sistema de archivos donde se instala el enlace simbólico. Se trata de un atributo clave de la acción link.
El destino del enlace simbólico. El objeto del sistema de archivos en el que se resuelve el enlace.
Especifica la entrada en el espacio de nombre de mediación compartido por todas las rutas que participan en un grupo de mediación determinado (por ejemplo, python). La mediación de enlace se puede realizar en función de mediator-version y/o mediator-implementation. Todos los enlaces mediados para un nombre de ruta determinado deben especificar el mismo mediator. Sin embargo, no todas las versiones e implementaciones de mediator necesitan proporcionar un enlace a una ruta determinada. Si una mediación no proporciona un enlace, el enlace se elimina cuando se selecciona esa mediación. Un mediator, en combinación con una versión y/o implementación específica representa una mediación que se puede seleccionar para ser utilizada por el sistema de empaquetado.
Especifica la versión (expresada como una secuencia de números enteros no negativos separados por puntos) de la interfaz descrita por el atributo mediator. Este atributo es necesario si se especifica mediator y no se especifica mediator-implementation. Un administrador del sistema local puede establecer la versión que se va a utilizar explícitamente. El valor especificado, por lo general, debe coincidir con la versión del paquete que entrega el enlace (por ejemplo, runtime/python-26 debe usar mediator-version=2.6), aunque esto no es necesario.
Especifica la implementación del mediador para utilizar además de mediator-version, o en su lugar. No se considera que las cadenas de implementación estén ordenadas y una cadena es seleccionada de manera arbitraria por pkg (5) si un administrador del sistema no la especifica explícitamente.
El valor puede ser una cadena de tamaño arbitrario, compuesta por caracteres alfanuméricos y espacios. Si la implementación en sí puede estar versionada o está versionada, la versión se debe especificar al final de la cadena, después de una @ (y se debe expresar como una secuencia de números enteros no negativos separados por puntos). Si existen varias versiones de una implementación, de manera predeterminada, se selecciona la implementación con el versión superior.
Si en un sistema se instala sólo una instancia de un enlace de mediación de implementación en una ruta determinada, esa instancia se elegirá automáticamente. Si se instalan futuros enlaces a la ruta, el enlace no se cambia a menos que se aplique un proveedor, un sitio o una sustitución local, o si uno de los enlaces tiene una mediación de versión.
Al resolver conflictos en enlaces mediados, pkg(5) normalmente elige el enlace con el mayor valor de mediator-version o, si no es posible, según mediator-implementation. Este atributo se utiliza para especificar una sustitución para el proceso normal de resolución de conflictos.
Si no se especifica este atributo, se aplica la lógica de selección de mediador predeterminado.
Si el valor es vendor, se prefiere el enlace a aquellos que no tienen mediator-priority especificado.
Si el valor es site se prefiere el enlace a los que tienen un valor de vendor o que no tienen mediator-priority especificado.
Un administrador del sistema local puede anular la lógica de selección descrita anteriormente.
La acción hardlink representa un enlace físico. Tiene los mismos atributos que la acción link, y path también es su atributo clave.
La acción driver representa un controlador de dispositivos. La acción driver no hace referencia a una carga útil. Los archivos de controlador se deben instalar como acciones file. Se reconocen los siguientes atributos (consulte add_drv(1M) para obtener más información):
El nombre del controlador. Suele ser, aunque no siempre, el nombre de archivo del binario de controlador. Este es el atributo clave de la acción driver.
Esto representa un alias para el controlador. Un controlador determinado puede tener más de un atributo alias. No se requieren reglas de comillas especiales.
Esto representa una clase de controlador. Un controlador determinado puede tener más de un atributo class.
Esto representa los permisos del sistema de archivos para los nodos de dispositivo del controlador.
Esto representa los permisos del sistema de archivos para los nodos menores del controlador clon de este controlador.
Esta opción especifica la política de seguridad adicional para el dispositivo. Un controlador determinado puede tener más de un atributo policy, pero no puede haber una especificación de dispositivo menor en más de un atributo.
Especifica los privilegios utilizados por el controlador. Un controlador determinado puede tener más de un atributo privs.
Especifica una entrada en /etc/devlink.tab. El valor es la línea exacta para entrar en el archivo, con tabuladores indicados mediante \t. Consulte devlinks(1M) para obtener más información. Un controlador determinado puede tener más de un atributo devlink.
La acción depend representa una dependencia entre paquetes. Un paquete puede depender de otro porque el primero requiere la funcionalidad del segundo para que la funcionalidad del primero funcione o, incluso, se instale. Las dependencias pueden ser opcionales. Si una dependencia no se cumple en el momento de la instalación, el sistema de empaquetado intenta instalar o actualizar el paquete dependiente a una versión lo suficientemente nueva, sujeta a otras restricciones.
Se reconocen los atributos siguientes:
El FMRI que representa el paquete dependiente. Este es el atributo clave de la acción dependency. El valor fmri no debe incluir el editor. Se asume que el nombre del paquete está completo. Las dependencias de tipo require-any pueden tener varios atributos fmri. Una versión es opcional en el valor fmri, aunque para algunos tipos de dependencias, un fmri sin ninguna versión no tiene ningún significado.
El tipo de dependencia.
Si el valor es require, la dependencia es necesaria y debe tener una versión igual o mayor a la versión especificada en el atributo fmri. Si no se especifica la versión, cualquier versión satisface la dependencia. Un paquete no se puede instalar si alguna de las dependencias necesarias no se puede satisfacer.
Si el valor es optional, la dependencia, si está presente, debe estar en el nivel de versión especificado o superior.
Si el valor es exclude, el paquete contenedor no se puede instalar si la dependencia está presente en el nivel de versión especificado o superior. Si no se especifica ninguna versión, el paquete dependiente no se puede instalar simultáneamente con el paquete que especifica la dependencia.
Si el valor es incorporate, la dependencia es opcional, pero la versión del paquete dependiente es restringida. Consulte “Restricciones y congelación” a continuación.
Si el valor es require-any cualquiera de los múltiples paquetes dependientes especificados mediante múltiples atributos fmri puede satisfacer la dependencia siguiendo las mismas reglas que el tipo de dependencia require.
Si el valor es conditional, la dependencia sólo se necesita si el paquete definido por el atributo predicate está presente en el sistema.
Si el valor es origin, la dependencia, si está presente, debe ser de un valor especificado o mejor en la imagen que se va a modificar antes de la instalación. Si el valor del atributo root-image es true, la dependencia debe estar presente en la imagen con raíz en / para poder instalar este paquete.
Si el valor es group, la dependencia es necesaria, a menos que el paquete esté en la lista de imágenes para evitar. Tenga en cuenta que los paquetes obsoletos de manera silenciosa satisfacen la dependencia de grupo. Consulte el subcomando avoid en pkg(1).
Si el valor es parent y la imagen no es una imagen secundaria, la dependencia se omite. Si la imagen es una imagen secundaria, se requiere que la dependencia esté presente en la imagen principal. La versión del paquete coincidente para una dependencia de parent es la misma que se usó para las dependencias de incorporate.
El FMRI que representa el predicado para las dependencias de conditional.
Tiene efecto únicamente para las dependencias de origin como se mencionó anteriormente.
La acción license representa una licencia u otro archivo de información asociado con el contenido del paquete. Un paquete puede entregar licencias, renuncias de responsabilidad u otras pautas para el instalador del paquete para el uso de la acción license.
La carga útil de la acción license se entrega en el directorio de metadatos de imágenes relacionado con el paquete y sólo debe contener datos de texto legibles para el usuario. No debe contener HTML ni ningún otro tipo de marca. Por medio de los atributos, las acciones license pueden indicar a los clientes que la carga útil relacionada se debe mostrar y/o requiere aceptación. El método visualización y/o aceptación queda a discreción de los clientes.
Se reconocen los atributos siguientes:
Se trata de un atributo clave de la acción license. Este atributo aporta una descripción significativa de la licencia para ayudar a los usuarios a determinar el contenido sin leer el texto de la licencia. Estos son algunos ejemplos de valores:
Aviso de Copyright de ABC Co.
Licencia personalizada de ABC Co.
Licencia común de desarrollo y distribución 1.0 (CDDL)
Licencia pública general de GNU 2.0 (GPL)
Sólo Licencia pública general de GNU 2.0 (GPL)
Licencia de MIT
Licencia pública de Mozilla 1.1 (MPL)
Licencia BSD simplificada
El valor de license debe ser único en un paquete. Se recomienda incluir la versión de la licencia en la descripción, como se mostró anteriormente en varios ejemplos. Si un paquete tiene un código bajo varias licencias, utilice varias acciones de license. La longitud del valor del atributo de la licencia no debe tener más de 64 caracteres.
Cuando es true, esta licencia debe ser aceptada por un usuario antes de que el paquete relacionado se pueda instalar o actualizar. La omisión de este atributo es equivalente a false. El método de aceptación (interactivo o basado en configuración, por ejemplo) queda a discreción de los clientes.
Cuando es true, los clientes deben mostrar la carga útil de la acción durante las operaciones de empaquetado. La omisión de este valor es equivalente a false. Este atributo no se debe utilizar para avisos de copyright, sólo para licencias reales u otro material que se deba mostrar durante las operaciones. El método de visualización queda a discreción de los clientes.
La acción legacy representa los datos del paquete utilizados por un sistema de empaquetado heredado. Los atributos asociados con esta acción se agregan a las bases de datos del sistema heredado, con el fin de que las herramientas que consultan dichas bases de datos puedan funcionar como si los paquetes heredados estuviesen instalados realmente. En particular, esto debería ser suficiente para convencer al sistema heredado de que el paquete nombrada por el atributo pkg está instalado en el sistema, para que el paquete se pueda utilizar para satisfacer las dependencias.
Se reconocen los siguientes atributos, nombrados de acuerdo con los parámetros de pkginfo(4):
El valor para el parámetro CATEGORY. El valor predeterminado es system.
El valor para el parámetro DESC.
El valor para el parámetro HOTLINE.
El valor para el parámetro NAME. El valor predeterminado es none provided.
La abreviación para el paquete que se está instalando. El valor predeterminado es el nombre del FMRI del paquete. Se trata de un atributo clave de la acción legacy.
El valor del parámetro VENDOR.
El valor del parámetro VERSION. El valor predeterminado es la versión del FMRI del paquete.
La acción set representa un atributo de nivel de paquete, o metadatos, como la descripción del paquete.
Se reconocen los atributos siguientes:
El nombre del atributo.
El valor especificado para el atributo.
La acción set puede entregar cualquier metadato que elija el autor del paquete. Sin embargo, existen varios nombres de atributos bien definidos que tienen un significado específico para el sistema de empaquetado.
Consulte “Versiones e identificadores de recursos de gestión de errores de paquetes” en la sección “Descripción”.
Uno o varios tokens que un cliente pkg(5) puede utilizar para clasificar el paquete. El valor debe contar con un esquema (como “org.opensolaris.category.2008” o “org.acm.class.1998”) y la clasificación real, como “Applications/Games”, separados por dos puntos (:).
Una descripción detallada del contenido y la funcionalidad del paquete, en general, aproximadamente un párrafo de longitud.
Cuando es true, el paquete se marca como obsoleto. Es posible que un paquete obsoleto no tenga más acciones que las de definición, y no se debe marcar como cambiado de nombre.
Cuando es true, se ha cambiado el nombre del paquete. En el paquete también debe haber una o varias acciones depend que se refieran a la versiones de paquete en las que este paquete se ha cambiado de nombre. Un paquete no se puede marcar como cambiado de nombre y como obsoleto, pero puede tener cualquier cantidad de acciones de definición.
Una descripción breve, de una línea, del paquete.
La acción group define un grupo de UNIX como se define en group(4). Las contraseñas de grupo no se admiten. Los grupos definidos con esta acción inicialmente no tienen lista de usuarios. Con la acción user se pueden agregar usuarios. Se reconocen los atributos siguientes:
El valor para el nombre del grupo.
El identificador numérico único del grupo. El valor predeterminado es el primer grupo libre inferior a 100.
La acción user define un usuario UNIX según lo definido en los archivos /etc/passwd, /etc/shadow, /etc/group y /etc/ftpd/ftpusers. Los usuarios definidos con este atributo tienen entradas agregadas en los correspondientes archivos.
Se reconocen los atributos siguientes:
El nombre único del usuario.
La contraseña cifrada del usuario. El valor predeterminado es *LK* . Consulte shadow(4).
El UID único del usuario. El valor predeterminado es el primer valor libre inferior a 100.
El nombre del grupo principal del usuario. Se debe encontrar en /etc/group.
El valor del campo gcos en /etc/passwd. El valor predeterminado es username.
El directorio principal del usuario. El valor predeterminado es /.
El shell predeterminado del usuario. El valor predeterminado está vacío.
Los grupos secundarios a los que pertenece el usuario. Consulte group(4).
Se puede establecer en true o false. El valor predeterminado de true indica que el usuario se puede conectar por medio de FTP. Consulte ftpusers(4).
El número de días entre el 1 de Enero de 1970 y la fecha en que la contraseña se modificó por última vez. El valor predeterminado está vacío. Consulte shadow(4).
El número mínimo de días necesarios entre cambios de contraseña. Este campo se debe definir en 0 o más para habilitar la antigüedad de la contraseña. El valor predeterminado está vacío. Consulte shadow(4).
El número máximo de días durante los que la contraseña es válida. El valor predeterminado está vacío. Consulte shadow(4).
Indica cuántos días antes de que caduque la contraseña se debe advertir al usuario. Consulte shadow(4).
El número de días de inactividad permitidos para ese usuario. Se calcula por equipo. La información del último inicio de sesión se toma del archivo lastlog del equipo. Consulte shadow(4).
Una fecha absoluta expresada como el número de días desde UNIX Epoch (1 de enero de 1970). Cuando se alcanza este número, ya no se puede iniciar sesión. Por ejemplo, el valor de caducidad 13514 especifica la caducidad del inicio de sesión para el 1 de enero de 2007. Consulte shadow(4).
Se establece como vacío. Consulte shadow(4).
En algunos contextos, puede ser apropiado ejecutar operaciones adicionales antes o después de la introducción de una acción determinada. Por lo general, estas operaciones adicionales sólo se necesitan en una imagen de sistema activo, y son específicas del sistema operativo. Cuando varias acciones involucradas en la instalación o eliminación de un paquete tienen los mismos activadores, la operación correspondiente a la presencia del activador se ejecuta una vez para esa instalación o eliminación.
Si los activadores se especifican incorrectamente se pueden producir errores en la instalación del paquete, si el activador no se puede determinar una manera de realizar una instalación segura.
Se definen los siguientes activadores:
Se puede establecer en true o false. Si se instala o actualiza una acción con este activador establecido en true durante la instalación de un paquete, se puede anunciar que la transacción de empaquetado requiere un reinicio. Es posible que determinadas implementaciones de cliente requieran pasos adicionales, como realizar toda la operación de paquete con un clon de la imagen, en caso de que la imagen sea la imagen del sistema activo.
Cada uno de estos activadores toma el valor de un FMRI de una instancia de servicio en la cual funcionará durante la instalación o la eliminación de paquetes. El activador disable_fmri hace que el FMRI determinado se desactive antes de la eliminación de la acción, mediante el subcomando disable de svcadm(1M). Los activadores refresh_fmri y restart_fmri hacen que el FMRI determinado se refresque o se reinicie después de la instalación, la actualización o la eliminación de la acción, según los respectivos subcomandos de svcadm(1M). Por último, el activador suspend_fmri hace que el FMRI determinado se desactive temporalmente antes de la fase de instalación de la acción y, luego, se active una vez finalizada dicha fase.
El valor puede incluir un modelo que coincida con varias instancias de servicio. Sin embargo, debe hacerlo explícitamente con un modelo glob aceptado por svcs(1), en lugar de hacerlo implícitamente sin indicar ninguna instancia.
Cuando un paquete se pasa a una versión nueva, o cuando se agrega o elimina del sistema, la selección de la versión o la posibilidad de la eliminación se determina mediante una variedad de restricciones impuestas al paquete. Dichas restricciones pueden ser definidas por otros paquetes mediante dependencias o por el administrador mediante congelaciones.
La forma más común de restricción es la dependencia require, como se describió anteriormente en “Acciones de dependencia”. Dicha restricción impide que el paquete pase a una versión anterior o se elimine.
La mayoría de las partes del sistema operativo están encapsuladas en paquetes denominados incorporaciones. Estos paquetes principalmente ofrecen restricciones representadas mediante la dependencia incorporate.
Como se describió anteriormente, un paquete incorporado no necesita estar presente en el sistema, pero si lo está, especifica la versión mínima de inclusión y la versión máxima de exclusión. Por ejemplo, si el FMRI dependiente tiene una versión 1.4.3, ninguna versión anterior a 1.4.3 satisfaría la dependencia, y tampoco lo haría ninguna versión posterior o igual a 1.4.4. Sin embargo, las versiones que simplemente ampliaron la secuencia separada por puntos, como 1.4.3.7, estarían permitidas.
Las incorporaciones se utilizan para forzar a partes del sistema a actualizarse de manera sincronizada. Para algunos componentes, como la biblioteca de C y el núcleo, éste es un requisito básico. Para otros, como un componente simple del espacio de usuario en el que nada más tiene una dependencia, se utiliza la actualización sincronizada simplemente para proporcionar un conjunto de versiones de paquete conocido y probado al que una versión concreta de la incorporación pueda hacer referencia.
Dado que una incorporación es simplemente un paquete, se puede eliminar y, por lo tanto, todas las restricciones impuestas por ella se flexibilizan. Sin embargo, muchas de las incorporaciones impartidas por Oracle Solaris son requeridas por los paquetes que incorpora porque la flexibilidad mencionada no ofrecería seguridad.
Si se intenta realizar una actualización de un paquete a una versión que no está permitida por una incorporación instalada, no se intentará encontrar una versión más reciente de la incorporación para satisfacer la solicitud, por el contrario, se producirá un error. Si se debe mover la restricción y la incorporación que la especifica no se puede eliminar, la incorporación se debe actualizar a una versión que especifique una versión deseada de la restricción. Si se actualiza una incorporación, también se deben actualizar todos los paquetes que no satisfagan las restricciones impartidas por la nueva versión.
Un administrador del sistema puede restringir una paquete mediante el comando pkg freeze. Si no se proporciona ninguna versión, el paquete nombrado se restringe a la versión instalada en el sistema. Si se proporciona un paquete versionado, esta congelación o restricción administrativa actúa como si se instalara una dependencia de incorporación en la que el atributo fmri tuviera el valor de la versión de paquete proporcionada.
Una inmovilización nunca es levantada automáticamente por el sistema de empaquetado. Para flexibilizar una restricción, utilice el comando pkg unfreeze.
Como se explicó anteriormente, un editor es simplemente un nombre que utilizan los clientes de paquetes para identificar al proveedor de paquetes. Los editores pueden distribuir los paquetes mediante depósitos de paquetes y/o archivos de paquetes. Actualmente el sistema de paquetes admite dos tipos de depósitos: depósitos de origen y depósitos de reflejo.
Un origen es un depósito de paquetes que contiene todos los metadatos (como catálogos, manifiestos e índices de búsqueda) y el contenido (archivos) de uno o varios paquetes. Si se configuran varios orígenes para un editor determinado en una imagen, la API del cliente del paquete intenta seleccionar el mejor origen del cual recuperar los datos del paquete. Éste es el tipo de depósito más común y se crea implícitamente cuando se utiliza pkgsend o pkgrecv en un depósito de paquetes.
Un reflejo es un depósito de paquetes que sólo incluye el contenido del paquete (archivos). Si se configura uno o varios reflejos para un editor determinado en una imagen, la API del cliente prefiere los reflejos para la recuperación del contenido de los paquete e intenta seleccionar el mejor reflejo del cual recuperar el contenido de los paquetes. Si el reflejo es inaccesible, no tiene el contenido requerido o se ralentiza, la API del cliente recupera el contenido de cualquier depósito de origen configurado. La finalidad de los reflejos es el uso compartido de contenido entre un conjunto confiable de clientes mediante la funcionalidad de reflejo dinámica de pkg.depotd(1M). Los reflejos también tienen la finalidad de autenticar el acceso a los metadatos del paquete y distribuir el contenido del paquete sin autenticación. Por ejemplo, un cliente puede estar configurado con un origen https que requiere un par de clave y certificado SSL para acceder, y con un reflejo http que proporciona el contenido del paquete. De esta manera, únicamente los clientes autorizados pueden instalar o actualizar los paquetes, mientras se evitan los costos generales de autenticación para la recuperación del contenido del paquete. Un reflejo se puede crear eliminando todos los subdirectorios de un depósito excepto los nombrados file y sus directorios principales. Un depósito de origen también se puede proporcionar como un reflejo mediante el uso del modo de reflejo de pkg.depotd(1M).
El software puede tener componentes que son opcionales y componentes que son mutuamente excluyentes. Algunos ejemplos de componentes opcionales son las configuraciones regionales y la documentación. Algunos ejemplos de componentes mutuamente excluyentes son SPARC o x86, y archivos binarios de depuración y no depuración.
En IPS, los componentes opcionales se denominan facetas y los componentes mutuamente excluyentes se denominan variantes. Las facetas y variantes se especifican como etiquetas en acciones de paquetes. Cada etiqueta de faceta y variante tiene un nombre y un valor. Una sola acción puede tener varias etiquetas de facetas y variantes. Los ejemplos de componentes con varias etiquetas de facetas y variantes incluyen un archivo de encabezado específico de arquitectura utilizado por desarrolladores, o un componente que sólo es para una zona global SPARC.
Un ejemplo de una etiqueta de variante es variant.arch=sparc. Un ejemplo de una etiqueta de faceta es facet.devel=true. Por lo general, se hace referencia a las facetas y las variantes sin el inicio facet. ni variant..
Las facetas y las variantes son propiedades especiales de la imagen y no se pueden establecer en paquetes individuales. Para ver los valores actuales de las facetas y las variantes definidas en la imagen, use los comandos pkg facet y pkg variant, como se muestra en la página del comando man pkg(1). Para modificar los valores de las facetas y las variantes definidas en la imagen, use los comandos pkg change-facet y pkg change-variant.
Las facetas son booleanas: sólo se pueden establecer en true (activadas) o false (desactivadas). De manera predeterminada, se considera que todas las facetas están establecidas en true, en la imagen. Una etiqueta de faceta en una acción sólo debe tener el valor true; los demás valores tienen comportamiento indefinido. Una faceta establecida en la imagen puede ser una faceta completa, como doc.man, o un patrón, como locale.*. Esto resulta de gran utilidad cuando se desea desactivar una parte del espacio de nombre de la faceta, y cuando se desean activar solamente facetas individuales en él. Por ejemplo, puede desactivar todas las configuraciones regionales y luego puede activar sólo una o dos configuraciones regionales específicas, como se muestra en el siguiente ejemplo:
# pkg change-facet locale.*=false [output about packages being updated] # pkg change-facet locale.en_US=true [output about packages being updated]
La mayoría de las variantes pueden tener cualquier cantidad de valores. Por ejemplo, la variante arch se puede establecer en i386, sparc, ppc o arm, o en cualquier arquitectura que la distribución admita. (Sólo i386 y sparc se utilizan en Oracle Solaris). La excepción son las variantes debug. Las variantes debug sólo se pueden definir en true o false; los demás valores tienen un comportamiento indefinido. Si la acción de un archivo tiene versiones de depuración y de no depuración, ambas versiones deben tener la variante debug aplicable explícitamente establecida, como se muestra en el siguiente ejemplo:
file group=sys mode=0644 overlay=allow owner=root \ path=etc/motd pkg.csize=115 pkg.size=103 preserve=true \ variant.debug.osnet=true file group=sys mode=0644 overlay=allow owner=root \ path=etc/motd pkg.csize=68 pkg.size=48 preserve=true \ variant.debug.osnet=false
El valor de la variante se debe definir en la imagen para que un paquete que usa la variante se instale. Las variantes arch y zone son definidas por el programa que crea la imagen e instala su contenido inicial. De manera predeterminada, las variantes debug.* son false en la imagen.
Las facetas y las variantes establecidas en la imagen afectan la instalación de una acción concreta.
Las acciones sin etiquetas de facetas o variantes siempre se instalan.
Se instalan las acciones con etiquetas de facetas, a menos que todas las facetas o los patrones de facetas que coinciden con las etiquetas estén establecidos en false, en la imagen. Si alguna faceta está establecida en true o no está establecida de forma explícita (true es el valor predeterminado), se instala la acción.
Las acciones con etiquetas de variantes se instalan sólo si los valores de todas las etiquetas de variantes son los mismos que los definidos en la imagen.
Las acciones con etiquetas de facetas y variantes se instalan si tanto las facetas como las variantes permiten que la acción se instale.
Puede crear sus propias etiquetas de facetas y variantes. Las siguientes etiquetas se utilizan con frecuencia en Oracle solaris.
|
A continuación, se muestran algunos ejemplos de las etiquetas de facetas que se utilizan en Oracle Solaris:
facet.devel facet.doc facet.doc.html facet.doc.info facet.doc.man facet.doc.pdf facet.locale.de facet.locale.en_GB facet.locale.en_US facet.locale.fr facet.locale.ja_JP facet.locale.zh_CN
Las políticas de imagen se definen mediante las propiedades de la imagen con valores booleanos. Consulte "Propiedades de la imagen" en la página del comando man pkg(1) para obtener descripciones de las propiedades flush-content-cache-on-success y send-uuid, e información sobre cómo ver y modificar sus valores.
Dado que las imágenes pkg(5) se pueden ubicar arbitrariamente en un sistema de archivos más grande, se utiliza el token $IMAGE_ROOT para distinguir las rutas relacionadas. Para una instalación de sistema típica, $IMAGE_ROOT es equivalente a /.
Directorio de metadatos para una imagen completa o parcial.
Directorio de metadatos para una imagen de usuario.
En los metadatos de una imagen en particular, ciertos archivos y directorios pueden contener información útil durante la reparación y la recuperación. El token $IMAGE_META se utiliza para hacer referencia al directorio de nivel superior que contiene los metadatos. $IMAGE_META generalmente es una de las dos rutas especificadas anteriormente.
Ubicación de los archivos y directorios conflictivos movidos durante una operación de paquetes.
Contiene un directorio para cada editor. Cada directorio almacena los metadatos específicos de un editor.
Otras rutas dentro de la jerarquía de directorios de $IMAGE_META son privadas y están sujetas a cambios.
Consulte attributes(5) para ver descripciones de los atributos siguientes:
|
pkg(1), pkgsend(1), pkg.depotd(1m), pkg.sysrepo(1m), svcs(1), svcadm(1M)
http://hub.opensolaris.org/bin/view/Project+pkg/
|