SMF The Service Management Facility

Transcripción

1 SMF The Service Management Facility David Galán Ortiz. < Spain OpenSolaris Users Groups > <OrangeBooks> USE IMPROVE EVANGELIZE

2 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

3 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 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

4 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

5 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

6 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 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

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

8 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 (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 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

9 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

10 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 milestone multi-user 2 milestone multi-user-server 3 milestone all 3 S 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

11 # 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 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

12 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 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

13 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

14 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.. 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 _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. 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/ 14

15 STATE 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 10:10:53 svc:/network/smtp:sendmail 10:10: sendmail 10:10: 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/ fmri svc:/network/ nombre Apache 2 HTTP server habilitada Falso 15

16 estado disabled next_state none state_time Thu Dec 28 10:10: reiniciador svc:/system/svc/restarter:default dependency require_all/error svc:/milestone/network:default () dependency require_all/none svc:/system/filesystem/local:default () dependency optional_all/error svc:/system/filesystem/autofs:default () 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/ svc:/network/ (Apache 2 HTTP server) Estado: disabled desde Thu Dec 28 10:10: Motivo: Un administrador lo ha inhabilitado. Consulte: 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

17 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/ 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/ STATE disabled STIME FMRI 12:20:21 svc:/network/ ps -ef grep -i apache2 root :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/ Y verificamos que ha arrancado correctamente: # # svcs -p svc:/network/ STATE STIME FMRI 12:31:23 svc:/network/ 12:31: httpd 12:31: httpd 12:31: httpd 17

18 12:31: httpd 12:31: httpd 12:31: 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/ Y verificamos que los procesos han cambiado de pid: # svcs -p svc:/network/ STATE STIME FMRI 12:37:27 svc:/network/ 12:37: httpd 12:37: httpd 12:37: httpd 12:37: httpd 12:37: httpd 12:37: httpd Ver la configuración de un servicio 18

19 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/ 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 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

20 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/ /lib/svc/method/http-apache2\ start # svcprop -p start/timeout_seconds svc:/network/ 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

21 ENABLED STATE FMRI enabled svc:/application/x11/xfs:default enabled svc:/application/font/stfsloader:default enabled offline svc:/application/print/rfc1179:default enabled svc:/network/rpc/mdcomm:default enabled svc:/network/rpc/meta:default enabled svc:/network/rpc/metamed:default enabled svc:/network/rpc/metamh:default enabled svc:/network/rpc/gss:default.. enabled svc:/network/ftp:default disabled disabled svc:/network/comsat:default enabled svc:/network/finger:default disabled disabled svc:/network/login:eklogin disabled disabled svc:/network/login:klogin enabled 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

22 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

23 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

24 Dec 28 17:11:11 aulaunix inetd[1737]: [ID 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

25 Ejecutamos el comando: # svccfg import /tmp/destinoxml/tftp-udp6.xml Verificamos que ha sido cargado con: # svcs -a grep -i tftp 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

26 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 o o /software/binarios/webserversunone/httpsaulaunix.aulaunix.org/start /software/binarios/webserversunone/httpsaulaunix.aulaunix.org/stop /software/binarios/webserversunone/httpsaulaunix.aulaunix.org/restart La documentación la ubicamos en /software/documentacion Creación del XML 26

27 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