smf
From Genunix
Introducción a SMF
The Service Management Facility (SMF)
Solaris 10 incorpora un nuevo sistema de gestión del arranque que ofrece nuevas posibilidades y optimiza el arranque del sistema, este nuevo componente se llama SMF (Service Management Facility) y forma parte de una nueva infraestructura que viene a sustituir al clásico inicio secuencial de Unix System V. Esta nueva infraestructura permite arrancar los servicios de forma paralela acorde a sus relaciones de dependencia. Una vez arrancado el sistema el administrador puede observar, deshabilitar, arrancar y parar servicios de una manera sencilla y eficiente.
Características de SMF:
- Ofrece los mecanismos para establecer relaciones de dependencia entre servicios. Un servicio no arranca hasta que estén correctamente arrancadas sus dependencias.
- Repositorio que contiene toda la información referente a la configuración del servicio, modos de arranque, parada, reinicio y el estado en el que se encuentra.
- Log con información de eventos de cada servicio.
- Cambios de niveles de ejecución a mono usuario, red, mantenimiento etc..
Beneficios de SMF:
- Los servicios al ser objetos pueden ser vistos y gestionados con sencillos comandos de administración.
- Se puede definir que SMF monitorice un proceso del servicio y tomar acciones si detecta que el proceso a muerto o hay un fallo hardware.
- Delegar en otros usuarios el poder arrancar o parar servicios de esta forma no necesitamos utilidades como sudo o la cuenta de root.
Un servicio definido en SMF no tiene por que estar necesariamente asociado a un proceso que se este ejecutando en el sistema, un servicio puede ser el estado de un dispositivo, de una tarjeta de red o de un sistema de ficheros.
Repositorio (Repository SMF)
Es la pieza principal y en el se almacena la configuración de cada servicio tanto en local como en memoria. También contiene el procedimiento para parar, arrancar y verificar un servicio. Cuando un servicio se ha iniciado correctamente en el arranque del sistema es guardada una foto de la configuración de dicho servicio con el objetivo de saber cual es la configuración correcta en caso de tener que restaurar el servicio.
SMF Restarters: svc.startd
Es el proceso que permite reiniciar un servicio en caso de fallo, para ello consulta el repositorio para identificar el método definido para reiniciar el servicio y hacerlo respetando las dependencias establecidas. Si hemos definido dependencias para un servicio y una de estas falla SMF Restarters solucionará el problema con la dependencia para restaurar el servicio.
SMF Service Instances
Un servicio puede estar compuesto a su vez por otra serie de servicios a los que se denominan instancias. Un ejemplo seria un servidor web Apache con el servicio web escuchando por el puerto 80, otro seguro por el 443 y un tercero por el 8080. Para gestionar el servicio deberíamos crear el servicio web con tres instancias.
Componentes de un servicio SMF
Un servicio en SMF esta formado por un conjunto de componentes que interactúan entre si. Veamos cada uno de estos componentes:
SMF manifiest: es un fichero XML en el que se definen las características de un servicio o una instancia del servicio. Los ficheros XML con las propiedades de los servicios se almacenan en /var/svc/manifest. Estos ficheros son cargados en el repositorio SMF. Methods: los métodos son usados por el restarter para interactuar con el servicio y puede ser un fichero ejecutable: un script o una palabra clave. Se utilizan para definir los métodos de arranque, parada o reinicio de un servicio. Los métodos son almacenados en /lib/svc/method. Service Log Files: es un servicio que escribe un log con todo los datos sucesos sobre un servicio, los logs se encuentran en /var/svc/log. Service Identifiers : cada servicio y cada instancia de servicio tienen un nombre con el que identificarse con “Fault Management Resource Identifier (FMRI)” en el que se especifica como actuar en caso de fallo en el sistema.
Estados de un servicio SMF
Los servicios pueden tener varios estados en los que podemos ver si el servicio esta parado, arrancado, degradado o en mantenimiento. Anteriormente se utilizaba el comando “ps –ef” para ver si un servicio estaba arrancado, ahora podemos utilizar los comandos de SMF para ver el estado del servicio además de poder continuar haciéndolo con el comando “ps –ef” para buscar el proceso. Estados en los se puede encontrar un servicio SMF:
- online: la instancia del servicio esta disponible y se esta ejecutando correctamente.
- offline: la instancia del servicio esta disponible pero no esta ejecutandose.
- disabled: la instancia del servicio no esta disponible y no esta ejecutándose.
- maintenance: la instancia del servicio tiene un error y esta siendo resuelto por el administrador.
- degraded: la instancia del servicio esta disponible pero esta funcionando al límite de su capacidad.
- ininitialized: este es el estado inicial de todos los servicios antes de iniciar su ejecución.
- legacy_run: este estado solo se utiliza para guardar la compatibilidad con los viejos niveles de arranque y nos índica que el estado en el que se encuentran. Los niveles de arranque solo pueden ser observados con SMF son se pueden editar.
Dependencias
Cuando definimos un servicio podemos definir dependencias, estableciendo que no arranque el servidor Apache hasta que no este arrancado el sistema en multiusuario (run level 3) y la bbdd MYSQL iniciada. Para cada servicio podemos establecer desde ninguna a varias dependencias.
Veamos las propiedades que podemos definir para las dependencias:
- require_all: todos los servicios de la dependencia deben estar online (arrancados) antes de iniciar el servicio.
- require_any: es suficiente con que uno de los servicios de la dependencia se ejecute para que el servicio se inicie.
- optional_all: si los servicios de la dependencia están disponibles y pueden ejecutarse deben estar online o degraded antes de la ejecución del servicio. Si están en mantenimiento el servicio no arrancara.
- exclude_all: significa que no todos los servicios de la dependencia deben estar corriendo para hincar el servicio.
Proceso de arranque con SMF
En arranque de Solaris se realiza como en versiones anteriores y el proceso init continua siendo el primer proceso del sistema leyendo fichero /etc/initab.
initab contiene la siguiente entrada:
smf::sysinit:/lib/svc/bin/svc.startd >/dev/msglog 2<>/dev/msglog </dev/console
Dicha entrada ejecuta el proceso svc.startd que inicia el proceso svc.configd que es el encargado de conectar con el repositorio SMF que reside en /etc/svc/repository.db. El repositorio tiene la propiedad de auto recuperarse si se producen daños ya que siempre mantiene una copia de respaldo.
Los primeros errores producidos durante la ejecución de SMF bien del repositorio o con problemas de inicio de un servicio se escriben en el directorio /etc/svc/volatile (montado en memoria) ya que todavía no esta montado o disponible “/var”, una vez sea accesible “/var” los logs son escritos en la ruta predeterminada “/var/svc/log”.
Milestone Services
Con la llegada de SMF también se ha redefinido la forma de poner la máquina en diferentes niveles de ejecución. Los niveles de ejecución mas conocidos son sigle user y multi user. Ahora se les denomina milestone. Milestone no es más que un servicio especial de SMF que agrupa las dependencias necesarias para establecer un nivel de ejecución. Se han añadido dos nuevos niéveles de ejecución: none que no ejecuta ningún servicio y all en el que se ejecutan todos los servicios disponibles.
Las equivalencias al sistema tradicional son las reflejadas en la siguiente tabla:
SMF Milestone Run Level Run Level milestone single-user S milestone multi-user 2 milestone multi-user-server 3 milestone all 3 milestone none No existe
Para pasar de un nivel de ejecución a otro podemos realizarlo sin problemas de la manera tradicional con el comando init y el número del nivel de ejecución al que queremos pasar o con el comando svcadm de la siguiente forma:
Pasar a single-user:
# svcadm milestone single-user A multi-user # svcadm milestone multi-user A multi-user-server # svcadm milestone multi-user-server
Para averiguar en que Runlevel esta ejecutándose el sistema lanzamos el siguiente comando:
# svcprop svc:/system/svc/restarter:default | grep -i milestone options_ovr/milestone astring svc:/milestone/multi-user-server:default
Podemos ver que el sistema se encuentra en el nivel de ejecución multi-user-server. Si la ejecución del comando no muestra nada en pantalla significa que estemos en el nivel de ejecución all.
Un milestone es un servicio tiene definidas dependencias de otros servicios, por ejemplo el servicio multi-user depende de los servicios de red. Obervando las dependencias de cada nivel de ejecución podemos averiguar que servicios ejecuta el milestone multi-user.
Para ello ejecutamos el comando svcs –d servicio para ver sus dependencias.
Para ver las dependencias del milestone multi-user ejecutamos:
bash-3.00# svcs -d milestone/multi-user STATE STIME FMRI disabled 12:52:37 svc:/system/auditd:default disabled 12:52:37 svc:/application/print/server:default disabled 12:52:37 svc:/network/ntp:default disabled 12:52:39 svc:/system/mdmonitor:default disabled 12:52:39 svc:/system/rcap:default online 12:52:42 svc:/milestone/name-services:default online 12:52:54 svc:/system/rmtmpfiles:default online 12:52:55 svc:/system/power:default online 12:52:55 svc:/system/name-service-cache:default online 12:53:01 svc:/milestone/single-user:default online 12:53:04 svc:/system/filesystem/local:default online 12:53:04 svc:/system/cron:default online 12:53:06 svc:/network/rpc/bind:default online 12:53:09 svc:/platform/i86pc/kdmconfig:default online 12:53:09 svc:/milestone/sysconfig:default online 12:53:10 svc:/network/inetd:default online 12:53:11 svc:/system/utmp:default online 12:53:24 svc:/network/nfs/client:default online 12:53:25 svc:/system/filesystem/autofs:default online 12:53:26 svc:/system/system-log:default online 12:53:26 svc:/system/system-log:default online 12:53:26 svc:/network/smtp:sendmail
Como se puede ver el número de servicios que ejecuta multi-server es muy superior al single-user que no requiere de tantos servicios como podemos ver en el ejemplo:
bash-3.00# svcs -d milestone/single-user
STATE STIME FMRI disabled 12:52:32
svc:/system/metainit:default online 12:52:39
svc:/network/loopback:default online 12:52:48
svc:/milestone/network:default online 12:52:49
svc:/system/identity:node online 12:52:51
svc:/system/keymap:default online 12:52:52
svc:/system/filesystem/minimal:default online 12:52:54
svc:/system/cryptosvc:default online 12:52:55
svc:/system/sysevent:default online 12:52:56
svc:/milestone/devices:default
online 12:53:00 svc:/system/manifest-import:default
Gestión de los servicios con SMF
A continuación vamos a ver los comandos que tiene SMF para la monitorizar el estado de los servicios, obtener información de un servicio y como parar o arrancar servicios. El conjunto de comandos que nos permite la administración de SMF son:
- svcs: Proporciona información sobre el estado de un servicio y sus dependencias:
- svcadm: Permite realizar acciones administrativas como cambiar el estado de un servicio.
- svccfg: Tiene la función de crear nuevos servicios a partir de un fichero xml y modificar las propiedades de un servicio.
- svcprop: Obtenemos y cambiamos valores de la bbdd sobre un servicio.
Obtener información de los servicios (svcs)
Los servicios SMF están organizados en grupos con los siguientes nombres:
Application: Contiene los servicios asociados con aplicaciones. Device: Usado para las dependencias Milestone: Equivalente a los niveles de ejecución SVR4 Network: Todos los servicios del antiguo inetd.conf Platform: Servicios específicos de la plataforma. System: Servicios independientes de la plataforma Site:Sin uso, reservado para uso futuro.
El siguiente ejemplo muestra el grupo al que pertenece el servicio de telnet:
# svcs –a | grep telnet disabled Dec_28 svc:/network/telnet:default
Como se puede observar pertenece a /network
Ver el estado de un servicio
Para ver el estado todos los servicios recurrimos al comando svcs que en ejemplo lo ejecutamos con la opción –a para que muestre todos los servicios independientemente de su estado.
# svcs –a STATE STIME FMRI legacy_run 10:10:30 lrc:/etc/rcS_d/S50sk98sol legacy_run 10:10:31 lrc:/etc/rcS_d/S51installupdates legacy_run 10:10:55 lrc:/etc/rc2_d/S10lu legacy_run 10:10:56 lrc:/etc/rc2_d/S20sysetup legacy_run 10:10:56 lrc:/etc/rc2_d/S40llc2 legacy_run 10:10:56 lrc:/etc/rc2_d/S42ncakmod legacy_run 10:10:56 lrc:/etc/rc2_d/S47pppd legacy_run 10:10:56 lrc:/etc/rc2_d/S70uucp legacy_run 10:10:56 lrc:/etc/rc2_d/S72autoinstall legacy_run 10:10:59 lrc:/etc/rc2_d/S73cachefs_daemon legacy_run 10:10:59 lrc:/etc/rc2_d/S81dodatadm_udaplt ……….. online 10:10:49 svc:/network/ftp:default online 10:10:49 svc:/network/finger:default online 10:10:50 svc:/network/ssh:default online 10:10:50 svc:/system/dumpadm:default online 10:10:51 svc:/system/system-log:default online 10:10:51 svc:/network/login:rlogin online 10:10:51 svc:/network/shell:default online 10:10:52 svc:/network/rpc-100235_1/rpc_ticotsord:default online 10:10:53 svc:/network/smtp:sendmail
En el ejemplo podemos observar el servicio legacy_run utilizado para guardar la compatibilidad con las practicas administrativas de versiones anteriores de Solaris. Del servicio legacy_run solo se puede consultar su estado y no podemos realizar cambios sobre el.
Si añadimos un servicio de la forma tradicional con un script en el directorio ined.d y el enlace en el rc* correspondiente funcionara con normalidad viéndolo en el SMF como un servicio legacy_run .
En Solaris 10 no es recomendable seguir utilizando el viejo sistema para añadir servicios al arranque debiendo utilizar SMF. También podemos observar que los servicios tradicionales como ftp y ssh están en estado online.
Ver las dependencias de un servicio
Para ver las dependencias de un servicio, es decir que servicios tienen que estar arrancados para que pueda ejecutarse utilizamos el comando svcs con la opción –d. Veamos el ejemplo:
# svcs -d svc:/network/http:apache2 STATE STIME FMRI online 10:10:12 svc:/milestone/network:default online 10:10:33 svc:/system/filesystem/local:default online 10:10:48 svc:/system/filesystem/autofs:default
Vemos que para que pueda ejecutarse el servicio web Apache 2 necesitamos que estén levantados los servicios network, y filesystem.
Procesos asociados a un servicio
Para averiguar que procesos están asociados a un servicio ejecutamos el comando svcs con la opción –p . El resultado de la ejecuión produce la siguiente salida:
# svcs -p svc:/network/smtp:sendmail
STATE STIME FMRI
online 10:10:53 svc:/network/smtp:sendmail
10:10:54 334 sendmail
10:10:54 341 sendmail
Poodemos ver los pid asociados al servicio sendmail aunque podemos averiguarlo tambien de la forma tradicional con la orden ps -ef | grep sendmail.
Obtener información detallada de un servicio
SMF puede aportar información detallada de un servicio como su nombre, si esta habilitado, su propio estado y las dependencias. Ejecutamos svcs con el parámetro –l :
# svcs -l svc:/network/http:apache2 fmri svc:/network/http:apache2 nombre Apache 2 HTTP server habilitada Falso estado disabled next_state none state_time Thu Dec 28 10:10:08 2006 reiniciador svc:/system/svc/restarter:default dependency require_all/error svc:/milestone/network:default (online) dependency require_all/none svc:/system/filesystem/local:default (online) dependency optional_all/error svc:/system/filesystem/autofs:default (online)
Diagnostico de fallos
SMF con el comando svcs puede aportarnos información sobre la causa de porque un servicio no puede arrancar, para ellos utilizamos el comando svcs con el parámetro –x. Para este ejemplo hemos deshabilitado manualmente el servicio de apache. Veamos el resultado del diagnostico:
# svcs -x svc:/network/http:apache2 svc:/network/http:apache2 (Apache 2 HTTP server) Estado: disabled desde Thu Dec 28 10:10:08 2006 Motivo: Un administrador lo ha inhabilitado. Consulte: http://sun.com/msg/SMF-8000-05 Consulte: httpd(8) Impacto: Este servicio no está funcionando.
La salida del comando nos indica que el servicio fue parado por un administrador, en que momento lo hizo y el impacto sobre el servicio. También nos remite a una url de Sun donde se nos amplia información sobre la causa por la que no esta arrancado el servicio. Sea cual sea el error siempre nos dará una url para obtener información que nos ayude a diagnosticar y solucionar el problema.
Parada de un servicio
Para parar un servicio utilizamos el comando svcadm con los parámetros disable y –t seguido del nombre de servicio:
svcadm disable -t svc:/network/http:apache2
Verificamos que ha parado con el comando svcs –p el cual nos indicara que el proceso esta en disable y que no hay procesos de apache2 ejecutándose. El resultado es el siguiente:
# svcs -p svc:/network/http:apache2
STATE STIME FMRI
disabled 12:20:21 svc:/network/http:apache2
ps -ef | grep -i apache2
root 1549 1444 0 12:22:51 pts/4 0:00 grep -i apache2
La opción –t estipula que es una para temporal si olvidamos poner el parámetro –t en el próximo arranque de la máquina el servicio no arrancara quedando en disable.
Arrancar un servicio
Para arrancar un servicio utilizamos el comando svcadm con los parámetros enable y –t seguido del nombre de servicio:
# svcadm enable -t svc:/network/http:apache2
Y verificamos que ha arrancado correctamente:
# svcs -p svc:/network/http:apache2
STATE STIME FMRI
online 12:31:23 svc:/network/http:apache2
12:31:23 1559 httpd
12:31:24 1560 httpd
12:31:24 1561 httpd
12:31:24 1562 httpd
12:31:24 1563 httpd
12:31:24 1564 httpd
Tal como podemos ver en la figura 3.3 el servicio ha arrancado correctamente y podemos ver todos los pid de los procesos en ejecución.
Reiniciar un servicio
Hasta el momento si queríamos reiniciar un servicio como por ejemplo ssh acudíamos a ejecutar:
/etc/init.d/sshd stop; /etc/init.d/sshd start
Ahora ejecutamos el comando svcs con la opción restart :
# svcadm restart svc:/network/http:apache2
Y verificamos que los procesos han cambiado de pid:
# svcs -p svc:/network/http:apache2
STATE STIME FMRI
online 12:37:27 svc:/network/http:apache2
12:37:27 1577 httpd
12:37:28 1578 httpd
12:37:28 1579 httpd
12:37:28 1580 httpd
12:37:28 1581 httpd
12:37:28 1582 httpd
Ver la configuración de un servicio
Si deseamos saber los valores de las propiedades de un servicio disponemos del comando svcprop que extrae dicha información del repositorio. Como ejemplo vamos a averiguar que método esta definido para arrancar el servicio apache2. Ejecutamos primeramente el comando svcprop y el nombre del servicio para obtener una lista de las propiedades definidas:
# svcprop svc:/network/http:apache2 httpd/ssl boolean false httpd/stability astring Evolving network/entities fmri svc:/milestone/network:default network/grouping astring require_all ……. …….. general/entity_stability astring Evolving start/exec astring /lib/svc/method/http-apache2\ start start/timeout_seconds count 60 start/type astring method stop/exec astring /lib/svc/method/http-apache2\ stop stop/timeout_seconds count 60 stop/type astring method refresh/exec astring /lib/svc/method/http-apache2\ refresh refresh/timeout_seconds count 60 refresh/type ………… ……….. restarter/state_timestamp time 1167305847.133954000 general_ovr/enabled boolean true restarter_actions/restart integer
Podemos ver una lista con todas las propiedades del servicio, para nuestro ejemplo nos centramos en la línea que pone:
start/exec astring /lib/svc/method/http-apache2\ start
Esta línea muestra el fichero que ejecuta el arranque del apache 2 que es /lib/svc/method/http-apache2 pasándole el parámetro start. Podemos ver el contenido del scritp realizando un more sobre /lib/svc/method/http-apache2. Si queremos obtener datos formateados sobre una de las propiedades ejecutamos:
svcprop –p nombredelapropiedad nombredelservicio
En la figura 3.5 muestra la información sobre los valores de la propiedad start/exec y start/timeout_seconds .
# svcprop -p start/exec svc:/network/http:apache2 /lib/svc/method/http-apache2\ start # svcprop -p start/timeout_seconds svc:/network/http:apache2 60 #
inetd como servicio SMF
El proceso inetd ha sido migrado completamente como un servicio SMF, ya no es necesario editar el fichero /etc/inet/inetd.conf para establecer valores o habilitar y deshabilitar servicio como telnet, ftp, tftp etc.. Si deshabilitamos un servicio como telnet ya no es necesario reiniciar con el comando kill el proceso inet.d.
Ver servicios de inetd
Para ver todos los servicios del proceso inetd y el estado en el que se encuentran ejecutamos el comando inetadm y pulsamos intro:
# inetadm ENABLED STATE FMRI enabled online svc:/application/x11/xfs:default enabled online svc:/application/font/stfsloader:default enabled offline svc:/application/print/rfc1179:default enabled online svc:/network/rpc/mdcomm:default enabled online svc:/network/rpc/meta:default enabled online svc:/network/rpc/metamed:default enabled online svc:/network/rpc/metamh:default enabled online svc:/network/rpc/gss:default ………… ………….. enabled online svc:/network/ftp:default disabled disabled svc:/network/comsat:default enabled online svc:/network/finger:default disabled disabled svc:/network/login:eklogin disabled disabled svc:/network/login:klogin enabled online svc:/network/login:rlogin disabled disabled svc:/network/shell:kshell disabled disabled svc:/network/talk:default
Deshabilitar un servicio inetd
Al ser un servicio mas de SMF recurrimos al comando svcadm y el parámetro disable. Ejemplo para no permitir conexiones telnet:
Con la opción –t se volverá a habilitar el servicio al reiniciar la máquina:
# svcadm disable –t svc:/network/telnet:default
Sin la opción –t el cambio es permanente:
# svcadm disable svc:/network/telnet:default
Ver el valor de un servicio inetd
En versiones anteriores si queríamos cambiar un valor al servicio ftp editábamos la línea y cambiamos los valores en el propio fichero. Con SMF es mas sencillo ya las propiedades están almacenadas en el repositorio. Antes de utilizar SMF editábamos la siguiente línea de inetd.conf:
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a
Para conocer el valor que tiene un servicio ejecutamos el comando:
inetadm –l nombredelservicio
Ejemplo de la ejecución para ver los valores del servicio ftp:
#inetadm -l ftp
SCOPE NAME=VALUE
name="ftp"
endpoint_type="stream"
proto="tcp6"
isrpc=FALSE
wait=FALSE
exec="/usr/sbin/in.ftpd -a"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE
Cambiar un valor de un servicio inet.d
Para cambiar un valor de los servicios inet.d utilizamos el comando inetadm de la siguiente forma:
inetadm –m nombreservicio parametroacambiar=nuevovalor
La ejecución del comando para cambiar el valor wait=FALSE del servicio ftp a valor wait=TRUE seria:
inetadm -m ftp wait=TRUE
y lo verificamos con:
# inetadm -l ftp
SCOPE NAME=VALUE
name="ftp"
endpoint_type="stream"
proto="tcp6"
isrpc=FALSE
wait=TRUE
exec="/usr/sbin/in.ftpd -a"
user="root"
default bind_addr=""
default bind_fail_max=-1
default bind_fail_interval=-1
default max_con_rate=-1
default max_copies=-1
default con_rate_offline=-1
default failrate_cnt=40
default failrate_interval=60
default inherit_env=TRUE
default tcp_trace=FALSE
default tcp_wrappers=FALSE
Cambios en inetd.conf
El fichero /etc/inet/inetd.conf no puede sufrir cambios ya que toda la gestión recae sobre SMF pero en caso de producirse un cambio voluntario o por una aplicación el sistema nos alertara en /adm/messages que el fichero ha sido modificado para que el administrador determine su naturaleza.
Dec 28 17:11:11 aulaunix inetd[1737]: [ID 702911 daemon.warning] Configuration file /etc/inet/inetd.conf has been modified since inetconv was last run. "inetconv -i /etc/inet/inetd.conf" must be run to apply any changes to the SMF
Convertir un servicio de inetd.conf a SMF
En Solaris 10 se han migrado todos los demonios del fichero /etc/inet/inetd.conf, pero si necesitamos añadir posteriormente un servicio contamos con la utilidad inetconv. El procedimiento es el siguiente:
1* Creamos los directorio temporales:
a. /tmp/nuevoservicio b. /tmp/destinoXML
2* Creamos en el directorio /tmp/nuevoservicio un fichero llamado migracion.conf que contenga el nuevo demonio del servicio usando la sintaxis del fichero /etc/inetd.conf. Para nuestro ejemplo hemos creado el fichero con la siguiente línea:
tftp dgram udp6 wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot
3* Ejecutamos el comando:
# inetconv -i /tmp/nuevoservicio/migracion.conf -n -o /tmp/destinoXML
4* En el directorio /tmp/destinoXML encontraremos un nuevo fichero con extensión .XML al que le ha dado el nombre de tftp-udp6.xml para ser cargado en el repositorio. 5* Cargamos la nueva configuración en el repositorio con el comando svcconfig.
Ejecutamos el comando:
# svccfg import /tmp/destinoXML/tftp-udp6.xml
Verificamos que ha sido cargado con:
# svcs -a | grep -i tftp online 12:39:09 svc:/network/tftp/udp6:default
Ya podemos gestionar el servicio svc:/network/tftp como un servicio mas de SMF.
Crear un nuevo servicio SMF
Para crear un nuevo servicio SMF debemos definir un nuevo SMF manifiest que es fichero XML que contiene los métodos para arrancar, parar, reiniciar, definición de dependencias, documentación etc.. Recordemos que los servicios SMF están organizados en grupos con los siguientes nombres:
Application: Contiene los servicios asociados con aplicaciones.
Device: Usado para dispositivos.
Milestone: Equivalente a los niveles de ejecución SVR4.
Network:Todos los servicios del antiguo inetd.conf.
Platform: Servicios específicos de la plataforma.
System: Servicios independientes de la plataforma.
Site: Sin uso, reservado para uso futuro.
Para crear un servicio SMF debemos de seguir los siguientes pasos:
1. Establecer el grupo y el nombre para el servicio
2. Definir las dependencias
3. Definir instancias y los métodos de arranque, parada y reinicio.
4. Ubicación de la documentación
5. Crear el fichero XML
6. Cargar el fichero XML en el repositorio
Vamos a proceder a crear un nuevo servicio SMF de un servidor web de Sun Microsystems: Sun ONE Web Server 6 para ello recopilamos la siguiente información:
- Vamos a crear el servicio dentro del grupo Application y a su vez dentro de un nuevo subgrupo definido por nosotros llamado servidoresweb y finalmente el identificador del servicio AulaUnix que se corresponde con el servidor web Sun One. Quedando se la siguiente forma: /application/servidoresweb/AulaUnix.
- Definimos como dependencia el nivel de ejecución 3 o multi-user-server.
- Los scripts de arranque, parada y reinicio son:
- /software/binarios/webserversunone/https-aulaunix.aulaunix.org/start
- /software/binarios/webserversunone/https-aulaunix.aulaunix.org/stop
- /software/binarios/webserversunone/https-aulaunix.aulaunix.org/restart
- La documentación la ubicamos en /software/documentacion
Creación del XML
En el ejemplo de la figura 3.6 podemos ver un XML completo en el que se define el servicio /application/servidoresweb/AulaUnix. Veamos las partes mas importantes:
En la primera parte del XML vemos que se han creado los comentarios sobre el servicio y se ha definido un identificador:
<service_bundle type='manifest' name='SunOneWebAulaunix'>
Este identificador debe ser único y podemos personalizar el texto acorde al servicio que vamos a dar de alta. En el siguiente se establece a que grupo pertenece y se define un subgrupo para albergar los servidores web:
<service name='application/servidoresweb/AulaUnix'
type='service' version='1'>
El nombre definido con name= será el que nos muestre el comando svcs cuando verifiquemos el estado del servicio. Debe ser un nombre sencillo y que permita identificar los servicios de forma practica. En este caso hemos optado por organizar todos los servidores web por debajo de servidoresweb. La propiedad de la figura 3.6 create_default_instance nos permite dos valores false y true con los que indicamos que el servicio se inicie o se detenga con las paradas y arranques del sistema. Anteriormente esto lo hacíamos con los scripts dentro del run revel correspondient pondiendo la S deltante del nombre para arrancar o la K para parar el servicio.
<create_default_instance enabled='false' />
Con <single_instance/> estamos definiendo una sola instancia, un servicio puede estar compuesto a su vez por otra serie de servicios a los que se denominan instancias. Un ejemplo seria un servidor web Apache con el servicio web escuchando por el puerto 80, otro seguro por el 443 y un tercero por el 8080. Para gestionar el servicio deberíamos crear el servicio web con tres instancias. Para nuestro ejemplo solo vamos el servicio con una sola instancia. Tenemos que crear las dependencias para que solo arranque el servicio si están funcionando correctamente todos los servicios del nivel de ejecución 3. Podemos crear tantas dependencias como sean necesarias haciendo referencia al nombre del servicio:
<dependency name='multi-user-server' type='service' grouping='require_all' restart_on='none'> <service_fmri value='svc:/milestone/multi-user-server' /> </dependency>
Ya hemos definido las dependencias y ahora vamos a crear los métodos para arrancar, reiniciar y parar. Como vemos en el ejemplo de la figura 3.6 con la opción name= establecemos el valor start para arrancar, stop para parar y restart para reiniciar. Los métodos definidos se ejecutaran cuando llamemos al comando svcadm de la siguiente forma:
svcs Método svcadm enable nombredelservicio start svcadm disable nombredelservicio stop svcadm restart nombredelservicio restart
El valor de exec= contiene la ruta absoluta al script o binario que se ejecutara y con time timeout_seconds definimos los segundos que esperara SMF como limite para el arranque:
<exec_method type='method' name='start' exec='/software/binarios/webserversunone/https-aulaunix.aulaunix.org/start' timeout_seconds='30' > </exec_method>
Ya tenemos creados los métodos y nos queda definir la información sobre la documentación del servicio en la etiqueta <documentation> donde establecemos el valor para manpage title con el titulo de la documentación y del valor manpath con el path absoluto del lugar donde se encuentra la máquina.
<documentation>
<manpage title='Documentos Web Server' section='1M' manpath='/software/documentacion' /> </documentation>
Importando el servicio en XML a SMF
Ya tenemos creado el fichero XML y nos queda cargarlo en el repositorio para poder ser gestionado. La carga en el repositorio la realizamos con el comando svccfg ejecutando la siguiente sentencia:
svccfg -v import fichero.xml
# svccfg -v import aulaunix.xml
svccfg: Tomando captura "previous" de svc:/application/servidoresweb/AulaUnix:default. svccfg: Actualización de propiedades de svc:/application/servidoresweb/AulaUnix de acuerdo con la instancia "default". svccfg: svc:/application/servidoresweb/AulaUnix: Actualizando propiedad "tm_man_Documentos_Web_Server/manpath". svccfg: Tomando captura "last-import" para svc:/application/servidoresweb/AulaUnix:default. svccfg: svc:/application/servidoresweb/AulaUnix:default actualizado. svccfg: Importación finalizada con éxito.
Y verificamos que ha cargado correctamente ejecutando:
#svcs -l svc:/application/servidoresweb/AulaUnix fmri svc:/application/servidoresweb/AulaUnix:default nombre Servicio SMF de ejemplo sobre SunONE habilitada Falso estado disabled next_state none state_time Tue Jan 02 17:56:41 2007 reiniciador svc:/system/svc/restarter:default dependency require_all/none svc:/milestone/multi-user-server (online)
Podemos ver las propiedades correctamente, el nombre es svc:/application/servidoresweb/AulaUnix tal como hemos definido en el XML y su estado es disabled.. El servicio ya esta disponible para gestionarlo con SMF. Verificamos el método start arrancando el servidor web con el comando svcadm:
# svcadm enable svc:/application/servidoresweb/AulaUnix
# svcs | grep -i aula
online 10:41:16 svc:/application/servidoresweb/AulaUnix:default
# svcs -p svc:/application/servidoresweb/AulaUnix:default
STATE STIME FMRI
online 10:41:16 svc:/application/servidoresweb/AulaUnix:default
10:41:06 3986 webservd-wdog
10:41:06 3987 webservd
10:41:07 3988 webservd
Podemos verificar el servidor web con ps –ef o ejecutando el comando svcs –p que nos mostrara los procesos y su pid asociados al servicio.
Modificar y eliminar un servicio SMF
Para modificar las propiedades de un servicio SMF es suficiente con modificar el fichero XML con los nuevos datos y realizar la importación al repositorio con el comando svccfg:
# svccfg -v import aulaunix.xml
Para eliminar un servicio del repositorio ejecutamos la orden:
svcfg delete nombredelservicio:
# svccfg delete svc:/application/servidoresweb/AulaUnix # svcs -a | grep -i aula #
Muestra el XML completo del ejemplo que hemos seguido:
<?xml version='1.0'?> <!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> <service_bundle type='manifest' name='SunOneWebAulaunix'> <service name='application/servidoresweb/AulaUnix' type='service' version='1'> <create_default_instance enabled='false' /> <single_instance/> <dependency name='multi-user-server' type='service' grouping='require_all' restart_on='none'> <service_fmri value='svc:/milestone/multi-user-server' /> </dependency> <exec_method type='method' name='start' exec='/software/binarios/webserversunone/https-aulaunix.aulaunix.org/start' timeout_seconds='30' > </exec_method> <exec_method type='method' name='stop' exec='/software/binarios/webserversunone/https-aulaunix.aulaunix.org/stop' timeout_seconds='60' /> <exec_method type='method' name='restart' exec='/software/binarios/webserversunone/https-aulaunix.aulaunix.org/restart' timeout_seconds='120'> </exec_method> <stability value='Unstable' /> <template> <common_name> <loctext xml:lang='C'> Servicio SMF de ejemplo sobre SunONE </loctext> </common_name> <documentation> <manpage title='Documentos Web Server' section='1M' manpath='/software/documentacion' /> </documentation> </template> </service> </service_bundle>
Delegar la gestión de SMF a otros usuarios
En algún momento puede surgir la necesidad de delegar la gestión de un servicio a otro usuario del sistema para poder arrancar, parar y reiniciar servicios. En nuestro ejemplo vamos a dar permisos al usuario aulaunix para que pueda gestionar el servidor web. El primer paso es añadir al servicio el atributo value_authorization utilizando el comando svcprop:
svccfg -s /application/servidoresweb/AulaUnix setprop general/value_authorization = astring: solaris.smf.manage
Ahora añadimos al fichero /etc/user_attr la siguiente línea y grabamos los cambios:
aulaunix::::type=normal;auths=solaris.smf.manage
Con estos dos pasos el usuario aulaunix ya puede gestionar el servicio web:
# su - aulaunix bash-3.00$ /usr/sbin/svcadm disable /application/servidoresweb/AulaUnix bash-3.00$ /usr/sbin/svcadm enable /application/servidoresweb/AulaUnix
Si deseamos quitarle los permisos para que no pueda continuar gestionando el servicio ejecutamos el comando svcprop para eliminar la propiedad value_authorization:
#svccfg -s /application/servidoresweb/AulaUnix delprop general/action_authorization
