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 se podría estar ejecutando varias veces en un sistema con configuraciones ligeramente diferentes. Estas distintas configuraciones se denominan instancias de servicio. Cada instancia es una configuración específica de un servicio. Por ejemplo, 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 la 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 se reserva para las personalizaciones específicas del sitio, lo que significa que un servicio denominado svc:/site/service-name nunca entrará en conflicto con servicios proporcionados en una versión de Oracle Solaris.

Las secuencias de comandos init.d antiguas 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 service-name es el nombre definido en /etc/inetd.conf y protocol 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á activada, pero se está ejecutando a una capacidad limitada.

• disabled: la instancia de servicio no está activada 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á activada, pero el servicio aún no está en ejecución o disponible para ejecutarse.

• online: la instancia de servicio está activada 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 repositorio 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 de la SMF. Asimismo, consulte la página del comando man svcbundle(1M) para obtener una descripción de una herramienta que facilita la creación de manifiestos.

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 repositorio 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 la instancia svc:/filesystem/minimal:default esté en línea, lo que indica que /var está montado.

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 en la misma capa administrativa 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. Consulte Capas administrativas de la SMF para obtener más información sobre las capas.

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.

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 un 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.

Repositorio de configuración de servicios

El repositorio 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 repositorio se distribuye entre la memoria local y los archivos locales. El repositorio 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 repositorio, consulte las páginas del comando man svccfg(1M) y svcprop(1). El daemon de repositorio de configuración de servicios se trata 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 repositorio 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 11.1: servicios de seguridad para obtener más información.

Capas administrativas de la SMF

En Oracle Solaris 11, la información que registra el origen de propiedades, grupos de propiedades, instancias y servicios se ha agregado al repositorio 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 antiguos /etc/svc/profile/site.xml y /var/svc/profile/site.xml.

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

• La capa manifest incluye los valores de un directorio de manifiesto del 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 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 repositorio 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 repositorio 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 mediante llamadas svccfg o libscf. Cuando se utiliza el comando svccfg delete, svccfg delpg o svccfg delprop, la entidad se enmascara en lugar de suprimirse por completo. Normalmente, los usuarios no pueden ver la entidad suprimida, 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. La exploración de las entidades con máscara permite que los administradores vean cómo se vería la configuración después de quitar la máscara y puedan realizar cambios, si es necesario, sin dañar el sistema que se está ejecutando.

El comando svccfg listprop tiene opciones para activar 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.

Copias de seguridad del repositorio de la SMF

La SMF realiza automáticamente las siguientes copias de seguridad del repositorio:

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

• Las copias de seguridad de manifest_import se producen después de que se completa svc:/system/early-manifest-import:default o svc:/system/manifest-import:default 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 suprime la copia de seguridad más antigua, cuando es necesario. Las copias de seguridad se almacenan como /etc/svc/repository-type- YYYYMMDD_HHMMSWS, donde YYYYMMDD (año, mes, día) y HHMMSS (hora, minuto, segundo) son la fecha y la hora de cuando se realizó la copia de seguridad. Tenga en cuenta que el formato de hora se basa en un reloj de 24 h.

Puede restaurar el repositorio 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 repositorio dañado.

Instantáneas de la SMF

Los datos en el repositorio 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 los 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 volver a ella.

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 activació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 service.

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 posibles configuraciones.

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 de eventos de transición de la SMF para obtener información sobre la configuración de notificaciones de la SMF.