CURSO DESDE 0 DE GNU/LINUX. Versión 2.

Entrega 33. Administración de servicios (I).

		% How's my lovemaking? 		

Unmatched '. 

Introducción.

Vamos a ver en esta serie de entregas cómo se administran los servicios en Linux. Un servicio es una función específica que realiza la máquina, como un servidor de base de datos, un servidor http o un servidor ftp.

Estos servicios están atendidos por demonios. Un demonio es un proceso en segundo plano que está a la espera de peticiones para realizar una tarea. También se les suele llamar deamon. Según la wikipedia, el origen de la palabra daemon (demonio) se encuentra en la antigua Grecia y la figura del daimon, un espíritu interior, equivalente a un "ángel protector" que guiaba y protegía a los hombres, pero según otras fuentes la palabra daemon viene de los “Day-monitor” de MULTICS. Comenzaron a llamarse en UNIX “daymons”, y en la zona de EEUU donde se trabajaba con UNIX se pronunciaba de la misma forma que “daemon”.

Un demonio puede atender varios servicios, e incluso puede darse el caso que un servicio es dado por varios demonios, pero lo normal va a ser siempre un demonio por servicio.

Pero, podéis pensar que si no vais a destinar vuestra máquina a ningún tipo de servidor, ¿para qué me sirven estas entregas? Es fácil, los servicios no sólo son para servidores como he puesto como ejemplo anteriormente, hay multitud de servicios como “samba” para las redes de Microsoft, los de sonido para que escuches tu música, cups para que puedas imprimir y muchísimos más.

No nos centraremos en cómo se configuran cada uno de ellos en esta serie, sino que vamos a aprender cómo arrancarlos, pararlos, reiniciarlos, que arranquen automáticamente, que nunca arranquen, etc...

Esto, por si aún no le has encontrado la utilidad inmediata, te puede servir para optimizar los recursos de tu sistema, ya que un servicio que no se usa es un gasto tonto de cpu y un posible agujero de seguridad, así que mejor pararlo y santas pascuas.

Cada vez que instalamos un nuevo servicio en nuestra distribución favorita se nos instalarán los scripts necesarios de arranque y parada necesarios, incluso ya se habrán configurado de forma óptima para que no tengas que tocar nada. Por ello, aún no es necesario que sepamos escribir un script para configurarlo nosotros mismos, cosa que además se nos escapa a los conocimientos vistos en el curso. Con lo que aquí veamos tendremos mucho juego.

Las dos grandes vertientes.

En cuanto hablamos de la administración de servicios en Unix, y por consiguiente de Linux, existen dos grandes familias o vertientes: System V y BSD, su forma de organizar los runleves (que veremos más adelante) y el arranque y parada de servicios son muy diferentes.

Linux bebe de ambas corrientes, y no sólo en cuanto a administración de servicios se refiere, por lo que unas distribuciones usarán el sistema de scripts de System V como son Debian, Red hat, Suse, Mandriva... y otras usarán el sistema de scripts BSD, no estoy seguro pero creo que Gentoo y Slackware usan este sistema. o por lo menos antes sí que lo usaban.

En System V tenemos un script de control por daemon y en BSD tenemos un gran fichero por runlevel que arranca el sistema y pone en marcha los servicios. Muchos opinan que el sistema de scripts de System V es mucho mejor para uso diario que el sistema BSD, entre los que me incluyo. Según mi experiencia, los basados en System V son la inmensa mayoría y no tengo ni una Gentoo ni una Slackware instalada, con lo que sólo vamos a ver System V.

Antes de nada, los runlevels.

Que aún os queda un poquito de tostón, aunque este es importante y nos mete en faena, así que prestad atención.

Los runlevels en UNIX son estados del sistema donde se determinan qué demonios están activos y qué demonios están parados, algo así como los perfiles de uso de nuestras máquinas.

Según el Linux Standar Base, LSB para los amigos, y la tradición manda (ya sabemos que las tradiciones mandan más que los estándares), los runlevels son los siguientes:

0. Parar y/o apagar el ordenador.

1. Modo monousuario.

2. Multiusuario sin red.

3. Multiusuario con red.

4. No se usa.

5. Multiusuario con red y entorno gráfico (El que todos solemos usar por defecto).

6. Reiniciar la máquina.

Pero como no vivimos en un mundo perfecto y cada distribución los modifica según le viene en gana, esto puede no ceñirse a la realidad de nuestra distribución y es aquí donde debemos investigar.

Y es aquí donde debemos visualizar un fichero de configuración muy importante, '/etc/inittab':

Sólo he dejado lo que nos interesa del fichero en cuestión, ya que puede ser muy largo y no es el momento aún de aprender a usarlo.

Para empezar mi distribución es una Debian Etch, en las vuestras es normal que cambie pero hay que buscar lo mismo siempre, sea cual sea. Lo primero que buscamos es 'id:2:initdefault:' que nos va a indicar el runlevel por defecto, y esto nos lo dice 'initdefault' y el '2' en este caso es el runlevel por defecto.

Lo siguiente que busco es una explicación en los comentarios, todo lo que vaya detrás de '#' es un comentario, es la explicación de los runlevels, ya veis lo diferente que es en Debian de lo que se supone que es lo estándar. Pero vamos, que de esto no se libra casi ninguna como podéis observar en este enlace: http://en.wikipedia.org/wiki/Runlevel#Standard_runlevels .

No en todas las distribuciones va a venir en el '/etc/inittab/' una explicación en los comentarios, así que en esos casos tendréis que tirar de documentación o de google como todo hijo de vecino.

Con esto ya tenemos o deberíamos tener claro qué scripts y para qué ' perfil de uso' vamos a tocar, y lo más importante, no tocar donde no debemos y mandarlo todo al carajo. Y vosotros no querréis cargaros algo, ¿verdad?

Pero ... ¿Dónde se encuentra lo que vamos o debemos tocar?.

“Ande andará”, como dirían Cruz y Raya, pues esto también puede cambiar de unas distribuciones a otras, pero no preocuparse es fácil de encontrar.

Vamos a tener un directorio con todos los scripts de servicios y un directorio por cada runlevel con enlaces simbólicos a este primero siguiendo unas reglas que veremos a su tiempo, ahora estamos buscando cuáles son.

Según System V, el primer directorio que buscamos 'init.d' , y se llama así en todas, debe de estar en '/etc/rc.d/init.d', pero según la LSB debe de estar en '/etc/init.d', y en mi caso Debian los tiene en este último sitio. De cualquier forma, siempre debéis buscar un directorio llamado 'init.d' dentro de '/etc' o algún subdirectorio suyo.

Los directorios con enlaces simbólicos por cada runlevel tienen la siguiente forma 'rcX.d' donde 'X' es el número de runlevel que estamos buscando. En Debian están en '/etc/' directamente ('/etc/rc0.d','/etc/rc1.d'....), pero también los podéis encontrar en otras distribuciones bajo '/etc/rc.d/'.

Así que ya sabéis, buscad y localizad que no es nada difícil.

Preparados, listos, ¡YA!

Vamos a empezar a usar los scripts de 'init.d', y si sois como yo que tengo tanto KDE como GNOME en mi ordenador podréis seguir al pie de la letra el ejemplo, aunque este es válido para cualquier otro script.

Cada uno de estos escritorios usa gestor de sesión propio, KDE usa 'kdm' y GNOME usa 'dgm', y están tal cual con esos nombres dentro de 'init.d'. En mi caso, Debian sólo me instalaba GNOME con su 'gdm' y luego yo instalé KDE. Como 'gdm' no me gusta instalé además 'kdm' que es mi preferido. Pero 'gdm' seguía arrancado y lo paré. Vamos a ver cómo sería:

Lo primero es que no nos vale con ejecutarlo y punto, tenemos una serie de parámetros, esto es, órdenes que darle, y suelen ser 5:

1. start. Para comenzar el servicio.

2. stop. Para parar el servicio.

3. restart. Para reinicializar el servicio.

4. reload. Para que el servicio cargue de nuevo la configuración.

5. force-reload. Para obligar al servicio que cargue la configuración de nuevo.

Los dos primeros siempre van a estar en cualquier script, el tercero es rarísimo que no esté, y los dos últimos puede que estén o no, e incluso puede darse la posibilidad de que algún script implemente algún parámetro más.

1 y 2 no necesitan explicación ninguna, 3 internamente suele estar implementado como primero haz 2 y luego haz 1, pero en algunos casos hay que hacer otras cosas de por medio para reiniciar el servicio sin problema.

4 lo que normalmente hace es decirle al servicio que lea de nuevo los ficheros de configuración y los aplique, esto no es siempre posible sin pararlo y en ese caso se utilizaría 5, al obligarlo puede que se produzcan rechazos de peticiones o que peticiones no finalicen correctamente durante el proceso.

A que ya lo vas pillando, pues te vas a quedar de momento con las ganas de seguir porque se acaba el espacio de esta entrega. Si no estás seguro de lo que haces o vas a hacer, espera a la entrega de la próxima semana.

Despedida.

Puede que esta entrega tenga mucha paja, pero para mí es la diferencia entre saber hacer las cosas y saber lo que se hace, así que paciencia. Hasta la próxima semana y cuidado con los empachos navideños.

Agradecimientos:

· Revisión del documento: karuchi (Carolina García).

Página oficial y dominio de mi propiedad http://matados2k.es

Matados'2k Usuario y moderador de foro.noticias3d.com

Matados'2k Usuario y moderador de www.sinuh.org

,

matados2k (arroba) gmail (punto) com

Sólo los usuarios registrados pueden escribir comentarios.
Por favor valídate o regístrate.

Powered by AkoComment 2.0!