Conceptos de la SMF

Esta sección presenta los términos y las definiciones dentro de la estructura de la SMF. Estos términos se utilizan en toda la documentación. Para incorporar los conceptos de la SMF, resulta esencial comprender estos términos.

Servicio SMF

La unidad fundamental de administración en la estructura de la SMF es la instancia de servicio. Cada servicio SMF tiene el potencial de tener varias versiones de él configuradas. Asimismo, varias instancias de la misma versión se pueden ejecutar en un único sistema. Una instancia es una configuración específica de un servicio. Un servidor web es un servicio. Un daemon de servidor web específico que está configurado para recibir en el puerto 80 es una instancia. Cada una de las instancias del servicio de servidor web puede tener diferentes requisitos de configuración. El servicio tiene requisitos de configuración en todo el sistema, pero cada instancia puede sustituir requisitos específicos, según sea necesario. Varias instancias de un único servicio se gestionan como objetos secundarios del objeto de servicio.

Los servicios no sólo son la representación de servicios de sistemas de larga ejecución estándar, como in.dhcpd o nfsd. Los servicios también representan varias entidades del sistema que incluyen aplicaciones ISV. Además, un servicio puede representar menos entidades tradicionales, como las siguientes:

• Un dispositivo de red físico

• Una dirección IP configurada

• Información de configuración de núcleo

• Hitos que corresponden al estado init del sistema, como el nivel de ejecución de multiusuario

Genéricamente, un servicio es una entidad que proporciona una lista de capacidades para aplicaciones y otros servicios, locales y remotos. Un servicio depende de una lista implícita y explícitamente declarada de servicios locales.

Un hito es un tipo especial de servicio. Los servicios de hitos representan un nivel de disponibilidad de sistema. Por ejemplo, los niveles de ejecución están representados por hitos en la SMF. Además, los hitos se pueden utilizar para indicar la disponibilidad de un grupo de servicios, como svc:/milestone/name-services:default para los servicios de nombres o svc:/milestone/config:default para el servicio sysconfig.

Dependencias de SMF

Las dependencias definen las relaciones entre servicios. Estas relaciones proporcionan una precisa contención de fallos reiniciando únicamente los servicios que son afectados directamente por un fallo, en lugar de reiniciar todos los servicios. Las dependencias también proporcionan un proceso de inicialización escalable y reproducible. Por último, la definición de dependencias precisas permite que el inicio del sistema aproveche máquinas modernas y altamente paralelas porque todos servicios independientes se pueden iniciar en paralelo.

El comportamiento de reinicio de un servicio es definido por el atributo restart_on para cada dependencia. Un servicio se puede configurar para que se detenga si el servicio del cual depende se detiene debido a un error u otra razón, o se refresca. Una vez que este proceso detiene un servicio, dicho servicio se reinicia automáticamente tan pronto como se inicia el servicio del cual depende. Por ejemplo, el servicio ssh tiene una dependencia en el servicio network/ipfilter. El atributo restart_on está definido como error, lo que significa que el servicio ssh se detendrá y se reiniciará automáticamente si el servicio network/ipfilter se detiene debido a un error. El servicio ssh no se detendrá si otros tipos de eventos se detectan.

Identificadores de servicios

Cada instancia de servicio se denomina con un identificador de recurso de gestión de fallos o FMRI. El FMRI incluye el nombre del servicio y el de la instancia. Por ejemplo, el FMRI del servicio rlogin es svc:/network/login:rlogin, donde network/login identifica el servicio y rlogin identifica la instancia del servicio.

Los formatos equivalentes para un FMRI son los siguientes:

• svc://localhost/system/system-log:default

• svc:/system/system-log:default

• system/system-log:default

Además, muchos comandos SMF pueden utilizar un nombre abreviado de instancia o servicio, cuando no hay ninguna ambigüedad. Por ejemplo, system-log se puede utilizar directamente en lugar de usar formatos más largos. Consulte las páginas del comando man del comando SMF, como svcadm(1M) o svcs(1) para obtener instrucciones sobre qué formatos FMRI son adecuados.

Los nombres de servicio incluyen prefijos para ayudar a identificar el objetivo de cada servicio. Estos prefijos incluyen nombres, como application, device, milestone, network o system. El prefijo site está reservado para personalizaciones específicas del sitio, y los servicios que utilizan este prefijo no se incluyen en una versión de Oracle Solaris.

Las secuencias de comandos init.d heredadas también están representadas con FMRI que empiezan con lrc, en lugar de svc, por ejemplo, lrc:/etc/rc2_d/S47pppd. Las horas de inicio iniciales del servicio heredado durante el inicio del sistema se muestran mediante el comando svcs. Sin embargo, no puede administrar estos servicios con SMF.

Durante la implementación inicial del sistema, los servicios que se indican en /etc/inetd.conf se convierten automáticamente en servicios SMF. Los FMRI de estos servicios son ligeramente diferentes. La sintaxis de un servicio inetd convertido es la siguiente:

network/service-name/protocol

Además, la sintaxis de un servicio convertido que utiliza el protocolo RPC es:

network/rpc-service-name/rpc_protocol

Donde nombre_servicio es el nombre definido en /etc/inetd.conf y protocolo es el protocolo para el servicio. El comando inetconv se puede utilizar para convertir entradas inetd.conf después de la implementación inicial del sistema.

Estados de servicio

El comando svcs muestra el estado, la hora de inicio y el FMRI de instancias de servicio. El estado de cada servicio es uno de los siguientes:

• degraded: la instancia de servicio está habilitada, pero se está ejecutando a una capacidad limitada.

• disabled: la instancia de servicio no está habilitada y no se está ejecutando.

• legacy_run: el servicio heredado no está gestionado por SMF, pero el servicio se puede observar. Este estado sólo es utilizado por servicios heredados.

• maintenance: la instancia de servicio ha encontrado un error que debe ser resuelto por el administrador.

• offline: la instancia de servicio está habilitada, pero el servicio aún no está en ejecución o disponible para ejecutarse.

• online: la instancia de servicio está habilitada y se ha iniciado correctamente.

• uninitialized: este estado es el estado inicial para todos los servicios antes de que se lea su configuración.

Un asterisco “*” se agrega al estado de las instancias en transición. Un signo de interrogación “?” se muestra si el estado está ausente o no se reconoce.

Manifiestos de la SMF

Un manifiesto SMF es un archivo XML que describe un servicio y un conjunto de instancias. Los manifiestos se importan para cargar las propiedades de ese servicio y sus instancias en el depósito de configuración de servicios. Consulte la página del comando man service_bundle(4) para obtener una descripción completa del contenido de un manifiesto SMF.

La ubicación preferida para los manifiestos es /lib/svc/manifest. Los manifiestos almacenados allí serán importados y actualizados por el servicio svc:/system/early-manifest-import:default durante el proceso de inicio antes de que comience cualquier servicio. La ejecución temprana del proceso de importación garantiza que el depósito contendrá información de los manifiestos más actuales antes de que los servicios se inicien. En otro momento, puede importar información desde estos manifiestos mediante la ejecución de este comando: svcadm restart manifest-import. /var/svc/manifest permanece disponible por motivos de compatibilidad, pero los manifiestos ubicados allí no se importan ni se actualizan hasta que el servicio svc:/system/manifest-import:default se ejecuta.

No realice ningún cambio en los manifiestos proporcionados por Oracle o proveedores de software de terceros. No edite directamente los manifiestos de /lib/svc/manifest y /var/svc/manifest, ya que las personalizaciones se perderán al actualizar. En su lugar, cree un perfil de sitio para personalizar el servicio o utilice el comando svccfg o inetadm para manipular las propiedades directamente. Los directorios /lib/svc/manifest/site y /var/svc/manifest/site también se reservan para uso específico del sitio. La versión de Oracle Solaris no entregará manifiestos a estos directorios.

En Oracle Solaris 11, varios manifiestos se pueden utilizar para describir un único servicio. Esto puede ser útil, por ejemplo, para definir una nueva instancia de un servicio sin modificar el manifiesto existente del servicio. Si la misma propiedad para el mismo servicio o instancia es definida por varios manifiestos, la SMF no puede determinar el valor que se debe utilizar. Cuando se detecta este tipo de conflicto, la instancia se coloca en el estado de mantenimiento.

Perfiles de la SMF

Un perfil SMF es un archivo XML que permite la personalización de servicios e instancias entregados por el sistema. Los perfiles están disponibles para la personalización mediante un archivo en lugar de un conjunto de secuencias de comandos o para la personalización de la configuración en el momento de la implementación o la instalación.

Todas las configuraciones se pueden personalizar mediante un perfil, incluida la adición de instancias para servicios suministrados por el sistema.

Las personalizaciones locales se deben colocar en archivos denominados con un sufijo .xml en el directorio /etc/svc/profile/site. Todas las personalizaciones en este directorio se aplican cuando el sistema se inicia o cuando el comando svcadm restart manifest-import se ejecuta.

Al igual que con los manifiestos, cualquier definición conflictiva entre archivos en /etc/svc/profile/site se trata como conflicto, y las instancias afectadas se colocan en el estado de mantenimiento.

Un perfil del sistema también se aplica durante la instalación. Los cambios en el perfil del sistema en /etc/svc/profile/generic.xml son rara vez necesarios. Consulte la página del comando man smf_bootstrap(5) para obtener más información.

Para obtener más información sobre el uso de perfiles, consulte Cómo aplicar un perfil de la SMF.

Depósito de configuración de servicios

El depósito de configuración de servicios almacena información de configuración persistente, así como datos de tiempo de ejecución de la SMF para los servicios. El depósito se distribuye entre la memoria local y los archivos locales. El depósito de configuración de servicios sólo se puede manipular o consultar mediante interfaces de la SMF. Para obtener más información sobre la manipulación y el acceso al depósito, consulte las páginas del comando man svccfg(1M) y svcprop(1). El daemon de depósito de configuración de servicios se cubre en la página del comando man svc.configd(1M). La biblioteca de configuración de servicios se documenta en la página del comando man libscf(3LIB).

Las propiedades en el depósito se pueden definir en el servicio o la instancia. Las propiedades que se establecen en el servicio son compartidas por todas las instancias de dicho servicio. Las propiedades que se establecen en la instancia son utilizadas sólo por esa instancia y pueden reemplazar propiedades en el servicio.

El comando svccfg ofrece una vista sin formato de propiedades, y es preciso en cuanto a si las propiedades se establecen en el servicio o la instancia. Si ve un servicio mediante el comando svccfg, no puede ver propiedades de la instancia. Si ve la instancia en su lugar, no puede ver las propiedades del servicio. El comando svcprop ofrece una vista compuesta de la instancia, donde las propiedades de la instancia y las propiedades del servicio se combinan en un único espacio de nombre de propiedad. Cuando las instancias del servicio se inician, la vista compuesta de sus propiedades se utiliza.

Todos los cambios de configuración de SMF se pueden registrar mediante la estructura de auditoría de Oracle Solaris. Consulte Configuración del servicio de auditoría (mapa de tareas) de Administración de Oracle Solaris: servicios de seguridad para obtener más información.

Copias de seguridad del depósito de la SMF

La SMF realiza automáticamente las siguientes copias de seguridad del depósito:

• La copia de seguridad del inicio se realiza inmediatamente antes de realizar el primer cambio en el depósito durante cada inicio del sistema.

• Las copias de seguridad de manifest_import se producen después de que svc:/system/early-manifest-import:default o svc:/system/manifest-import:default se completa si el servicio importó nuevos manifiestos o ejecutó secuencias de comandos de actualización.

Cuatro copias de seguridad de cada tipo son mantenidas por el sistema. El sistema elimina la copia de seguridad más antigua, cuando es necesario. Las copias de seguridad se almacenan como /etc/svc/repository-tipo-AAAAMMDD_HHMMSS, donde AAAAMMDD (año, mes, día) y HHMMSS (hora, minuto, segundo), son la fecha y la hora cuando la copia de seguridad se realizó. Tenga en cuenta que el formato de hora se basa en un reloj de 24 h.

Puede restaurar el depósito desde estas copias de seguridad si se produce un error. Para ello, utilice el comando /lib/svc/bin/restore_repository. Para obtener más información, consulte Cómo reparar un depósito dañado.

Instantáneas de la SMF

Los datos en el depósito de configuración de servicios incluyen instantáneas, así como una configuración que se puede editar. Los datos sobre cada instancia de servicio se almacenan en las instantáneas. Las instantáneas estándar son las siguientes:

• initial: se realiza en la primera importación del manifiesto.

• running: se realiza cuando svcadm refresh se ejecuta.

• start: se realiza en el último inicio correcto.

El servicio SMF siempre se ejecuta con la instantánea running. Esta instantánea se crea automáticamente si no existe.

El comando svccfg se utiliza para cambiar valores de propiedades actuales. Esos valores se hacen visibles para el servicio cuando el comando svcadm se ejecuta para integrar esos valores en la instantánea en ejecución. El comando svccfg también se puede utilizar para ver configuraciones de instancias en otra instantánea o revertir a ellas.

Capas administrativas de SMF

En Oracle Solaris 11, la información que registra el origen de propiedades, grupos de propiedades, instancias y servicios se ha agregado al depósito de configuración de servicios. Esta información permite a los usuarios determinar qué datos son personalizaciones administrativas y qué datos se entregaron con el software.

Para ayudar a identificar el origen de una entidad, se definen las siguientes capas:

• La capa admin incluye los cambios realizados usando los comandos SMF o llamando a la API libscf(3LIB).

• La capa site-profile incluye los valores de los archivos en el directorio /etc/svc/profile/site o en los perfiles heredados /etc/svc/profile/site.xml y /var/svc/profile/site.xml.

• La capa system-profile incluye los valores de las ubicaciones de perfil de sistema: /etc/svc/profile/generic.xml y /etc/svc/profile/platform.xml.

• La capa manifest incluye los valores de un directorio de manifiesto de sistema: /lib/svc/manifest o /var/svc/manifest.

Para mantener la compatibilidad con clientes existentes que esperan una sola propiedad por nombre de propiedad, así como para crear una política de sustituciones, las capas tienen un comportamiento simple de sustitución. La capa admin tiene prioridad. Si una propiedad tiene un valor en la capa admin, dicho valor es el valor utilizado por el servicio. Si no lo tiene, se usa la capa site-profile, luego la capa system-profile y, finalmente, la capa manifest. Este comportamiento permite que las personalizaciones locales tengan prioridad sobre los valores que se proporcionan durante la instalación del sistema.

Estas capas son gestionadas automáticamente por el sistema. Los cambios directos realizados por un administrador en el depósito sólo aparecen en la capa admin. Las demás capas se cambian sólo colocando o eliminando archivos en ubicaciones estándar. Cuando una propiedad se coloca en el depósito debido al contenido del archivo, la información acerca de dicha propiedad incluye el nombre del archivo de donde provino el contenido.

Un administrador no puede modificar las capas inferiores directamente utilizando llamadas svccfg o libscf. Cuando se utiliza el comando svccfg delete, svccfg delpg o svccfg delprop, la entidad se enmascara en lugar de eliminarse por completo. Normalmente, los usuarios no pueden ver la entidad eliminada, pero las entidades enmascaradas se pueden explorar explícitamente mediante el comando svccfg listcust y se pueden desenmascarar mediante el comando svccfg delcust, si lo desea.

El comando svccfg listprop tiene opciones para habilitar la exploración de estas capas. Por ejemplo, svccfg listprop -l all imprime todas las capas y los valores en cada capa. Además, el comando svccfg listcust se puede utilizar para enumerar sólo las personalizaciones.

Registro de errores del servicio SMF

La información específica del servicio, incluidos los errores que el servicio o sus métodos emiten, así como la información sobre acciones de habilitación, horas de inicio, etc., se registran en archivos individuales para cada instancia de servicio en /var/svc/log. Para determinar el nombre del archivo de registro de un servicio, ejecute el comando svcs -x servicio.

De manera predeterminada, la SMF escribe mensajes de registro en el programa syslog y la consola únicamente si la intervención administrativa es necesaria, por ejemplo, si un servicio entra en estado de mantenimiento. Hay otras opciones disponibles, pero se utilizan pocas veces. Consulte la página del comando man svc.startd(1M) para conocer otras configuraciones posibles.

Además, para el registro de errores, el servicio SMF se puede configurar para que le notifique cuando se produce un evento FMA o cuando los servicios pasan al estado de servicio o salen de él. Estas notificaciones pueden utilizar el protocolo simple de administración de red (SNMP) o el protocolo simple de transferencia de correo (SMTP). Consulte Cómo configurar notificaciones por correo electrónico de eventos de transición de SMF para obtener información sobre la configuración de notificaciones SMF.