SMF The Service Management Facility David Galรกn Ortiz. www.opensolarisblog.org < Spain OpenSolaris Users Groups >
<OrangeBooks>
USE
IMPROVE
EVANGELIZE
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
Spain OpenSolaris Users Group
Licencia Esta obra está bajo una licencia Reconocimiento-NoComercialSinObraDerivada-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
Spain OpenSolaris Users Group
The Service Management 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
Spain OpenSolaris Users Group
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
Spain OpenSolaris Users Group
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
Spain OpenSolaris Users Group
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
Spain OpenSolaris Users Group
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
Spain OpenSolaris Users Group
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”.
boot
Init (pid 1)
bbdd configuraci ón SMF
init lee /etc/inittab
svc.startd
svc.confif.d
svc:/platform svc:/site svc:/milestone svc:/system svc:/network Figura 3.1 Milestone Services 9
Spain OpenSolaris Users Group
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: 10
Spain OpenSolaris Users Group
# 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 disabled disabled disabled disabled disabled online online online online online online online online online online online online online online online online online
STIME FMRI 12:52:37 svc:/system/auditd:default 12:52:37 svc:/application/print/server:default 12:52:37 svc:/network/ntp:default 12:52:39 svc:/system/mdmonitor:default 12:52:39 svc:/system/rcap:default 12:52:42 svc:/milestone/name-services:default 12:52:54 svc:/system/rmtmpfiles:default 12:52:55 svc:/system/power:default 12:52:55 svc:/system/name-service-cache:default 12:53:01 svc:/milestone/single-user:default 12:53:04 svc:/system/filesystem/local:default 12:53:04 svc:/system/cron:default 12:53:06 svc:/network/rpc/bind:default 12:53:09 svc:/platform/i86pc/kdmconfig:default 12:53:09 svc:/milestone/sysconfig:default 12:53:10 svc:/network/inetd:default 12:53:11 svc:/system/utmp:default 12:53:24 svc:/network/nfs/client:default 12:53:25 svc:/system/filesystem/autofs:default 12:53:26 svc:/system/system-log:default 12:53:26 svc:/system/system-log:default 12:53:26 svc:/network/smtp:sendmail
11
Spain OpenSolaris Users Group
Como se puede ver el número de servicios que ejecuta multiserver 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 disabled online online online online online online online online online
STIME FMRI 12:52:32 svc:/system/metainit:default 12:52:39 svc:/network/loopback:default 12:52:48 svc:/milestone/network:default 12:52:49 svc:/system/identity:node 12:52:51 svc:/system/keymap:default 12:52:52 svc:/system/filesystem/minimal:default 12:52:54 svc:/system/cryptosvc:default 12:52:55 svc:/system/sysevent:default 12:52:56 svc:/milestone/devices:default 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
Spain OpenSolaris Users Group
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 legacy_run legacy_run legacy_run legacy_run
STIME FMRI 10:10:30 lrc:/etc/rcS_d/S50sk98sol 10:10:31 lrc:/etc/rcS_d/S51installupdates 10:10:55 lrc:/etc/rc2_d/S10lu 10:10:56 lrc:/etc/rc2_d/S20sysetup 13
Spain OpenSolaris Users Group
legacy_run legacy_run legacy_run legacy_run legacy_run legacy_run legacy_run ……….. online online online online online online online online online
10:10:56 lrc:/etc/rc2_d/S40llc2 10:10:56 lrc:/etc/rc2_d/S42ncakmod 10:10:56 lrc:/etc/rc2_d/S47pppd 10:10:56 lrc:/etc/rc2_d/S70uucp 10:10:56 lrc:/etc/rc2_d/S72autoinstall 10:10:59 lrc:/etc/rc2_d/S73cachefs_daemon 10:10:59 lrc:/etc/rc2_d/S81dodatadm_udaplt 10:10:49 svc:/network/ftp:default 10:10:49 svc:/network/finger:default 10:10:50 svc:/network/ssh:default 10:10:50 svc:/system/dumpadm:default 10:10:51 svc:/system/system-log:default 10:10:51 svc:/network/login:rlogin 10:10:51 svc:/network/shell:default 10:10:52 svc:/network/rpc-100235_1/rpc_ticotsord:default 10:10:53 svc:/network/smtp:sendmail
Figura 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
Spain OpenSolaris Users Group
STATE online online online
STIME FMRI 10:10:12 svc:/milestone/network:default 10:10:33 svc:/system/filesystem/local:default 10:10:48 svc:/system/filesystem/autofs:default
Figura 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:sendmail STATE STIME FMRI online 10:10:53 svc:/network/smtp:sendmail 10:10:54 334 sendmail 10:10:54 341 sendmail
Figura 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:apache2 fmri svc:/network/http:apache2 nombre Apache 2 HTTP server habilitada Falso 15
Spain OpenSolaris Users Group
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. Cambios de estado de un servicio (svcadm).
Parada de un servicio
16
Spain OpenSolaris Users Group
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 disabled
STIME FMRI 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 17
Spain OpenSolaris Users Group
12:31:24 12:31:24 12:31:24
1562 httpd 1563 httpd 1564 httpd
Figura 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: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
18
Spain OpenSolaris Users Group
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
Figura 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
Spain OpenSolaris Users Group
ver el contenido del scritp realizando un more sobre /lib/svc/method/httpapache2. 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 #
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
Spain OpenSolaris Users Group
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: 21
Spain OpenSolaris Users Group
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
22
Spain OpenSolaris Users Group
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.
23
Spain OpenSolaris Users Group
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
Spain OpenSolaris Users Group
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 servicio mas de SMF.
svc:/network/tftp como un
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.
pasos:
Para crear un servicio SMF debemos de seguir los siguientes 1. Establecer el grupo y el nombre para el servicio 2. Definir las dependencias 25
Spain OpenSolaris Users Group
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/httpsaulaunix.aulaunix.org/start o /software/binarios/webserversunone/httpsaulaunix.aulaunix.org/stop o /software/binarios/webserversunone/httpsaulaunix.aulaunix.org/restart
La documentación /software/documentacion
la
ubicamos
en
Creación del XML
26
Spain OpenSolaris Users Group
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' />
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
Spain OpenSolaris Users Group
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>
28
Spain OpenSolaris Users Group
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 29
Spain OpenSolaris Users Group
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: 30
Spain OpenSolaris Users Group
# 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"> <!-XML de ejemplo de ejemplo creado por David Galan dgalan@aulaunix.org www.aulaunix.org wikilaris.aulaunix.org blog.aulaunix.org --> <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/httpsaulaunix.aulaunix.org/start' timeout_seconds='30' > </exec_method> <exec_method 31
Spain OpenSolaris Users Group
type='method' name='stop' exec='/software/binarios/webserversunone/httpsaulaunix.aulaunix.org/stop' timeout_seconds='60' /> <exec_method type='method' name='restart' exec='/software/binarios/webserversunone/httpsaulaunix.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
Spain OpenSolaris Users Group
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
33
Spain OpenSolaris Users Group
34