smf the service management facility - páginas...

USE IMPROVE EVANGELIZE

SMFThe Service Management FacilityDavid Galán Ortiz.www.opensolarisblog.org

<OrangeBooks>

< Spain OpenSolaris Users Groups >

Spain OpenSolaris Users Group

LICENCIA.................................................................................................................3

REFERENCIAS .............................................................................................................3

THE SERVICE MANAGEMENT FACILITY (SMF)...........................................4

INTRODUCCIÓN A SMF................................................................................................4 Repositorio (Repository SMF)...........................................................................5 SMF Restarters: svc.startd ...............................................................................6 SMF Service Instances.......................................................................................6 Componentes de un servicio SMF.....................................................................6 Estados de un servicio SMF...............................................................................7 Dependencias.....................................................................................................8

PROCESO DE ARRANQUE CON SMF................................................................................8 MILESTONE SERVICES .................................................................................................9 GESTIÓN DE LOS SERVICIOS CON SMF..........................................................................12

Ver el estado de un servicio.............................................................................13 Ver las dependencias de un servicio................................................................14 Procesos asociados a un servicio:...................................................................15 Obtener información detallada de un servicio................................................15 Diagnostico de fallos.......................................................................................16 Parada de un servicio .....................................................................................16 Arrancar un servicio........................................................................................17 Reiniciar un servicio........................................................................................18 Ver la configuración de un servicio.................................................................18

INETD COMO SERVICIO SMF........................................................................................20 Ver servicios de inetd.......................................................................................20 Deshabilitar un servicio inetd..........................................................................21 Ver el valor de un servicio inetd......................................................................21 Cambiar un valor de un servicio inet.d...........................................................22 Cambios en inetd.conf......................................................................................23 Convertir un servicio de inetd.conf a SMF .....................................................24

CREAR UN NUEVO SERVICIO SMF................................................................................25 Creación del XML............................................................................................26 Importando el servicio en XML a SMF .........................................................29 Modificar y eliminar un servicio SMF.............................................................30

DELEGAR LA GESTIÓN DE SMF A OTROS USUARIOS........................................................32

2


Licencia

Esta obra está bajo una licencia Reconocimiento-NoComercial-SinObraDerivada-2.5 España de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-nd/2.5/es o envíe una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.Usted es libre de:

- Copiar, distribuir y comunicar públicamente la obra.

Bajo las condiciones siguientes:

- Reconocimiento. Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador.

- No comercial. No puede utilizar esta obra para fines comerciales.

- Compartir bajo la misma licencia. Si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

- Al reutilizar o distribuir la obra, tiene que dejar bien claro los términos de la licencia de esta obra.

Alguna de estas condiciones puede no aplicarse si se obtiene el permiso del titular de los derechos de autor.

Referencias

Todos los nombres propios de programas, sistemas operativos, equipos hardware, etc., que aparecen en este libro son marcas registradas de sus respectivas compañías u organizaciones.

3


The Service Manage-ment Facility (SMF)

Introducción a 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:

4


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)

5


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.

6


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.

uninitialized: 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

7


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. (ver figura 3.1)

8


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

Figura 3.1

Milestone Services

9

boot

Init (pid 1)

init lee

/etc/inittab

svc.startd svc.confif.d

bbdd

configuración SMF

svc:/platform

svc:/site

svc:/milestone

svc:/system

svc:/network


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 Levelmilestone single-user Smilestone multi-user 2milestone multi-user-server 3milestone all 3milestone 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-userA multi-user

# svcadm milestone multi-userA multi-user-server

# svcadm milestone multi-user-server

Para averiguar en que Runlevel esta ejecutándose el sistema lanzamos el siguiente comando:

10


# svcprop svc:/system/svc/restarter:default | grep -i milestoneoptions_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 FMRIdisabled 12:52:37 svc:/system/auditd:defaultdisabled 12:52:37 svc:/application/print/server:defaultdisabled 12:52:37 svc:/network/ntp:defaultdisabled 12:52:39 svc:/system/mdmonitor:defaultdisabled 12:52:39 svc:/system/rcap:defaultonline 12:52:42 svc:/milestone/name-services:defaultonline 12:52:54 svc:/system/rmtmpfiles:defaultonline 12:52:55 svc:/system/power:defaultonline 12:52:55 svc:/system/name-service-cache:defaultonline 12:53:01 svc:/milestone/single-user:defaultonline 12:53:04 svc:/system/filesystem/local:defaultonline 12:53:04 svc:/system/cron:defaultonline 12:53:06 svc:/network/rpc/bind:defaultonline 12:53:09 svc:/platform/i86pc/kdmconfig:defaultonline 12:53:09 svc:/milestone/sysconfig:defaultonline 12:53:10 svc:/network/inetd:defaultonline 12:53:11 svc:/system/utmp:defaultonline 12:53:24 svc:/network/nfs/client:defaultonline 12:53:25 svc:/system/filesystem/autofs:defaultonline 12:53:26 svc:/system/system-log:defaultonline 12:53:26 svc:/system/system-log:defaultonline 12:53:26 svc:/network/smtp:sendmail

11


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 FMRIdisabled 12:52:32 svc:/system/metainit:defaultonline 12:52:39 svc:/network/loopback:defaultonline 12:52:48 svc:/milestone/network:defaultonline 12:52:49 svc:/system/identity:nodeonline 12:52:51 svc:/system/keymap:defaultonline 12:52:52 svc:/system/filesystem/minimal:defaultonline 12:52:54 svc:/system/cryptosvc:defaultonline 12:52:55 svc:/system/sysevent:defaultonline 12:52:56 svc:/milestone/devices:defaultonline 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.

12


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 telnetdisabled 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 FMRIlegacy_run 10:10:30 lrc:/etc/rcS_d/S50sk98sollegacy_run 10:10:31 lrc:/etc/rcS_d/S51installupdateslegacy_run 10:10:55 lrc:/etc/rc2_d/S10lulegacy_run 10:10:56 lrc:/etc/rc2_d/S20sysetup

13


legacy_run 10:10:56 lrc:/etc/rc2_d/S40llc2legacy_run 10:10:56 lrc:/etc/rc2_d/S42ncakmodlegacy_run 10:10:56 lrc:/etc/rc2_d/S47pppdlegacy_run 10:10:56 lrc:/etc/rc2_d/S70uucplegacy_run 10:10:56 lrc:/etc/rc2_d/S72autoinstalllegacy_run 10:10:59 lrc:/etc/rc2_d/S73cachefs_daemonlegacy_run 10:10:59 lrc:/etc/rc2_d/S81dodatadm_udaplt………..online 10:10:49 svc:/network/ftp:defaultonline 10:10:49 svc:/network/finger:defaultonline 10:10:50 svc:/network/ssh:defaultonline 10:10:50 svc:/system/dumpadm:defaultonline 10:10:51 svc:/system/system-log:defaultonline 10:10:51 svc:/network/login:rloginonline 10:10:51 svc:/network/shell:defaultonline 10:10:52 svc:/network/rpc-100235_1/rpc_ticotsord:defaultonline 10:10:53 svc:/network/smtp:sendmailFigura pepe.pepe

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

14


STATE STIME FMRIonline 10:10:12 svc:/milestone/network:defaultonline 10:10:33 svc:/system/filesystem/local:defaultonline 10:10:48 svc:/system/filesystem/autofs:defaultFigura 3.2

En el ejemplo de la figura 3.2 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:sendmailSTATE STIME FMRIonline 10:10:53 svc:/network/smtp:sendmail 10:10:54 334 sendmail 10:10:54 341 sendmailFigura 3.3

En el ejemplo de la figura 3.3 podemos 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:apache2fmri svc:/network/http:apache2nombre Apache 2 HTTP serverhabilitada Falso

15


estado disablednext_state nonestate_time Thu Dec 28 10:10:08 2006reiniciador svc:/system/svc/restarter:defaultdependency 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:apache2svc:/network/http:apache2 (Apache 2 HTTP server) Estado: disabled desde Thu Dec 28 10:10:08 2006Motivo: 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.

Cambios de estado de un servicio (svcadm).

Parada de un servicio

16


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 FMRIdisabled 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:apache2STATE STIME FMRIonline 12:31:23 svc:/network/http:apache2 12:31:23 1559 httpd 12:31:24 1560 httpd 12:31:24 1561 httpd

17


12:31:24 1562 httpd 12:31:24 1563 httpd 12:31:24 1564 httpdFigura 3.3

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:apache2STATE STIME FMRIonline 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

18


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 falsehttpd/stability astring Evolvingnetwork/entities fmri svc:/milestone/network:defaultnetwork/grouping astring require_all…….……..general/entity_stability astring Evolvingstart/exec astring /lib/svc/method/http-apache2\ startstart/timeout_seconds count 60start/type astring methodstop/exec astring /lib/svc/method/http-apache2\ stopstop/timeout_seconds count 60stop/type astring methodrefresh/exec astring /lib/svc/method/http-apache2\ refreshrefresh/timeout_seconds count 60refresh/type …………………..restarter/state_timestamp time 1167305847.133954000general_ovr/enabled boolean truerestarter_actions/restart integerFigura 3.4

En el ejemplo de la figura 3.4 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

19


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:apache260#Figura 3.5

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

20


ENABLED STATE FMRIenabled online svc:/application/x11/xfs:defaultenabled online svc:/application/font/stfsloader:defaultenabled offline svc:/application/print/rfc1179:defaultenabled online svc:/network/rpc/mdcomm:defaultenabled online svc:/network/rpc/meta:defaultenabled online svc:/network/rpc/metamed:defaultenabled online svc:/network/rpc/metamh:defaultenabled online svc:/network/rpc/gss:default……………………..enabled online svc:/network/ftp:defaultdisabled disabled svc:/network/comsat:defaultenabled online svc:/network/finger:defaultdisabled disabled svc:/network/login:eklogindisabled disabled svc:/network/login:kloginenabled online svc:/network/login:rlogindisabled disabled svc:/network/shell:kshelldisabled 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:

21


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=-1default bind_fail_interval=-1default max_con_rate=-1default max_copies=-1default con_rate_offline=-1default failrate_cnt=40default failrate_interval=60default inherit_env=TRUEdefault tcp_trace=FALSEdefault 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

22


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 ftpSCOPE 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=-1default bind_fail_interval=-1default max_con_rate=-1default max_copies=-1default con_rate_offline=-1default failrate_cnt=40default failrate_interval=60default inherit_env=TRUEdefault tcp_trace=FALSEdefault 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.

23


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.

24


Ejecutamos el comando:

# svccfg import /tmp/destinoXML/tftp-udp6.xml

Verificamos que ha sido cargado con:

# svcs -a | grep -i tftponline 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

25


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:

o /software/binarios/webserversunone/https-aulaunix.aulaunix.org/start

o /software/binarios/webserversunone/https-aulaunix.aulaunix.org/stop

o /software/binarios/webserversunone/https-aulaunix.aulaunix.org/restart

La documentación la ubicamos en /software/documentacion

Creación del XML

26


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:

<servicename='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' />Figura 3.6

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

27


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_methodtype='method'name='start'exec='/software/binarios/webserversunone/https-aulaunix.aulaunix.org/start'timeout_seconds='30' ></exec_method>

28


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:defaultnombre Servicio SMF de ejemplo sobre SunONEhabilitada Falso

29


estado disablednext_state nonestate_time Tue Jan 02 17:56:41 2007reiniciador svc:/system/svc/restarter:defaultdependency 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 aulaonline 10:41:16 svc:/application/servidoresweb/AulaUnix:default

# svcs -p svc:/application/servidoresweb/AulaUnix:defaultSTATE STIME FMRIonline 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:

30

# svccfg delete svc:/application/servidoresweb/AulaUnix# svcs -a | grep -i aula#

La figura 3.6 muestra el XML completo del ejemplo que hemos seguido, puedes encontrar el fichero para descargarlo en: www.aulaunix.org/ejemplos

<?xml version='1.0'?><!DOCTYPE service_bundle SYSTEM

"/usr/share/lib/xml/dtd/service_bundle.dtd.1">

<service_bundle type='manifest' name='SunOneWebAulaunix'>

<servicename='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_methodtype='method'name='start'exec='/software/binarios/webserversunone/https-

aulaunix.aulaunix.org/start'timeout_seconds='30' >

</exec_method>

<exec_method

31


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>

Figura 3.6

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:

32


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_authoriza-tion

33


34

smf the service management facility - páginas...

Documents