Crons, Syslogs, Daemons, Tarballs
Estas palabras, que se encuentran en el léxico de un administrador de sistemas UNIX, no quieren decir otra cosa que:
- Crons: Procesos periodicos
- Syslogs: Trazas del sistema
- Daemons: Servicios del sistema
- Tarballs: Archivar antes de comprimir
- Dump/Restore: Backups
- Administrative Tools: Herramientas para no iniciados ;)
Procesos periódicos (crons)
El demonio cron es la herramienta por defecto en los sistemas UNIX para ejecutar comandos con un horario planificado.
El cron lee sus ficheros de configuración, en los que se indican los comandos a ejecutar (con sh) y las horas a las que han de ser invocados, ficheros de configuración que son conocidos como los crontab (cron tables).
Lo único que hay que aprender de estos ficheros es que se editan con cron -e y la sintaxis que se utiliza para indicar las horas.
Por ejemplo supongamos que a las 8 menos 10 de la mañana queremos ejecutar un script antes de que empiecen a llegar nuestros usuarios (iniciar algún proceso importante del sistema) y escribir las trazas en un fichero de trazas.
# Minuto Hora Dia Mes Mes Dia Semana Comando # (0-59) (0-23) (1-31) (1-12) (0-6) 50 07 * * 1-5 /opt/scripts/script.sh >> /var/log/scripts/script.log
Las horas se especificarían con la siguiente sintaxis:
- Un asterisco (*) significa todos, desde el primero hasta el último.
- Se permiten rangos de valores separados por un guión, por ejemplo 8-11 en las horas indica que se ejecute algo a las 8, 9, 10 y 11.
- Se permiten listas de valores separadas por comas, por ejemplo, "1,2,5,9" o "0-4,8-12".
El sexto campo es el comando a ejecutar. Por defecto será ejecutado por la Bourne Shell, por lo tanto cuidado con la sintaxis de las redirecciones. Hay que tener cuidado con el carácter % porque si no se escapa (con el carácter "\") nos causaría una nueva línea. También hay que tener cuidado con las variables de entorno: No se van a expandir las que se definen cuando nos logamos (como $HOME, etc).
El sexto campo es el comando a ejecutar. Por defecto será ejecutado por la Bourne Shell, por lo tanto cuidado con la sintaxis de las redirecciones. Hay que tener cuidado con el carácter % porque si no se escapa (con el carácter "\") nos causaría una nueva línea. También hay que tener cuidado con las variables de entorno: No se van a expandir las que se definen cuando nos logamos (como $HOME, etc).
Algunos usos típicos de cron incluyen:
- Limpieza de filesystems de ficheros sin usar
- Lanzar backups
- Iniciar servicios del sistema
- Mandar mensajes de exceso de cuota en disco
Bibliografia:
Trazas del sistema (syslog)
Existe un demonio de sistema llamado syslogd responsable de escribir las trazas del sistema. Su fichero de configuración es /etc/syslogd conf y existen llamadas al sistema para escribir al syslog y un comando de usuario en algunos sistemas llamado logger que puede mandar entradas desde la shell (ctrl-d para terminar).
Se puede configurar syslogd para que haga cosas distintas a las que establece el sistema por defecto, no es muy habitual pero puede hacerse.
La siguiente tabla incluye una lista de los ficheros de trazas más frecuentes en los UNIX más habituales. Específicamente, incluye qué ficheros hay que archivar, resumir o truncar periódicamente, qué programa los crea, la frecuencia de limpieza que se podría considerar razonable y una descripción.
La ubicación de los ficheros suelen ser relativos a /var/adm, /var/log o /var/log/syslog.
De todos ellos el más famoso es /var/adm/messages o /var/log/syslog.
En ciertos sistemas operativos hay facilidades de reporting de error particulares. AIX por ejemplo tiene el comando errpt. Como superusuario haremos errpt -a para ver los últimos errores reportados. El sistema de log de AIX tiene su propia configuración.
Daemons
Los daemons de UNIX son procesos que se ejecutan en el sistema sin intervención del usuario.
Ya hemos visto que crond es el demonio que se encarga de los trabajos programados con el comando cron. La otra variante es atd que se encarga de los programados con el comando at.
En Linux hay una serie de procesos asociados a threads del kernel que empiezan casi todos por k y terminan por d, siendo fácil identificarlos por tanto. Tienen nombres como kblockd, kswapd,klogd, kjournald... etc.
Uno de los más importantes es inetd es el demonio que se encarga de controlar los servicios de red. Su fichero de configuración inetd.conf dice qué servicios de red van a estar disponibles. Un fichero interesante relacionado es /etc/services, en el que se definen los puertos asociados.
portmap se encarga de mapear la configuración de las aplicaciones que se comunican por RPC, como el NFS, con la configuración TCP/IP.
Para el servicio de NFS tenemos los servicios rpc.nfsd y rpc.mountd, que se encargan respectivamente de aceptar las peticiones de servicio de fichero y de consumo del mismo. En la variante del automount, se tienen amd y automountd. Para bloqueo de los ficheros existen los procesos rpc.lockd y rpc.statd.
lpd es el servicio de impresión. En las máquinas Linux podemos encontrar una variante que se llama cupsd.
Si tenemos que servir ficheros de UNIX a máquinas Windows suele instalarse SAMBA y los daemon correspondientes se llaman smbd y nmbd.
En el caso de que tengamos servicios de NIS (centralización de ficheros clave en /etc como passwd, groups, services) encontraremos iniciados servicios con nombres como ypbind (si somos clientes), ypserv (si somos servidores) o rpc.ypxfrd (que transfiere los mapas de los servidores maestro a los esclavos).
Si nuestra máquina es servidor de correo (que la mayoría de los sistemas UNIX lo son por defecto, aunque no vengan configurados de forma especial) encontraremos corriendo el sendmail, smtpd, popd y/o imapd.
Lo que siempre tendríamos que tener por seguridad es sshd para que nuestros usuarios se conecten, siendo in.rlogind, in.rtelnetd e in.rshd lo que escucharía las peticiones de rlogin, telnet y rsh respectivamente, en el caso de sistemas configurados sin la seguridad habitual necesaria para que las passwords no viajen en claro por la red.
Otros servicios que suelen venir en un sistema UNIX corriendo como daemons son ftpd (para el FTP), dhcpd (para la resolución dinámica de IPs), talkd (para que chateemos con otros UNIX), rsyncd (para ejecutar peticiones de rsync), snmpd (para poder conectarnos por consolas de management remoto) o ntpd (para sincronización de relojes).
Muchos sistemas operativos vienen con estos servicios y luego el técnico de sistemas decide que no los necesita y los desactiva, o bien necesita que operen de una forma más especializada y los sustituye por software especializado gratuito o comercial.
Para el final he dejado un daemon con bastante fama, que es httpd. En UNIX es ubicuo el servidor web de Apache. Instalarlo y configurarlo dan para un curso entero.
Bibliografía:
Herramientas de ayuda al administrador
Todos los sistemas modernos cuentan con herramientas visuales de administración tipo panel de control que permiten la administración de aspectos seleccionados del sistema. Esto está bien en momentos de prisa, pero para ser un administrador de primera hay que saber cómo funciona el sistema y esto sólo se puede hacer si se saben exactamente los ficheros, comandos y sobre todo los conceptos relacionados con cada aspecto de la administración del sistema. Cuando el sistema se estropea, se espera de nosotros que seamos capaces de funcionar sin herramientas. Además si sabemos los comandos podremos hacer scripts sobre ellos. Por último, las herramientas son tan específicas que si nos aprendemos la de un sistema operativo no nos servirá nada para otro.
- En Solaris estaba disponible el admintool hasta que en Solaris 10 llegó SMC.
- En HP-UX el nombre de la herramienta es sam.
- En AIX, tenemos a smit. Este es de los mejores.
- En Linux tenemos proyectos comunes (por ejemplo, linuxconf) o proyectos concretos por distribución (por ejemplo YaST de SuSE)
Un administrador multiplataforma tiene como mejor ayuda lo que se conoce como piedra rosetta del administrador, o un conjunto de scripts que le "aíslen" un poco de la variedad de comandos.
Bibliografía
Empaquetar ficheros en UNIX (tar)
Todo usuario de UNIX debe saber utilizar el comando tar, pues es frecuente que el software venga empaquetado en ese formato, o que para hacernos una copia de seguridad de nuestros archivos necesitemos empaquetarlos de ese modo.
La palabra "tar" viene de "tape archive" y es que cuando se empaquetaban los ficheros para llevárselos del sistema lo que se hacía era meterlos en cintas. Se utilizaba mucho para backups.
Ahora normalmente los backups no se hacen con tar, sino que tar se usa para llevarnos parte de los ficheros a otro sistema, empaquetando a archivo y desempaquetando de archivo. El paquete resultante (fichero tar o en inglés tarball) se comprime con otra utilidad como gzip (no viene en el sistema en muchas máquinas pero suele instalarse) de forma que el resultado suele ser un fichero nombre.tar.gz
La forma de realizar el archivo es el siguiente:
$ cd /home/usuario/midirectorio
$ tar -cvf ../melollevo.tar *
$ gzip -9 ../melollevo.tar
El resultado será un archivo llamado /home/usuario/midirectorio/melollevo.tar.gz
Si lo queremos expandir en otro sistema o en otro directorio
$ gunzip melollevo.tar.gz
$ mkdir dirdestino
$ cd dirdestino
$ tar -xvf melollevo.tar
Si estamos seguros de que nuestro sistema destino no tiene gzip, podemos usar la utilidad compress y el resultado sería un fichero nombre.tar.Z.
Copias de seguridad de sistemas de ficheros (dump/restore)
Todo sistema en un entorno no personal (e incluso en uno personal también) debe entrar en un ciclo de backups con precauciones crecientes según la criticidad de la información.
En UNIX los backups suelen hacerse por filesystems, es decir, se vuelcan los distintos sistemas de ficheros en el dispositivo de backup para poder recuperarlos por separado. Los backups pueden hacerse con la utilidad dump/restore del sistema (en Solaris ufsdump/ufsrestore) o con software específico comprado a tal efecto.
En un sistema UNIX pueden ocurrir tres tipos de catástrofe:
1) Se daña el root filesystem (/) o parte esencial de él que impide arrancar ni siquiera en modo monousuario, o parte indeterminada de dicho filesystem.
2) Se daña otro filesystem del sistema (/usr, /var) o un fichero concreto del root filesystem que no impide el arranque.
3) Se daña un filesystem de software (/opt) o de usuario.
En el caso de Solaris:
1) Arrancamos de CD y restauramos encima del root filesystem. Podría ser incluso necesario realizar la creación de los filesystems con los comandos newfs y format y aplicar el filesystem check (fsck)
2) Arrancamos en modo monousuario y restauramos el fichero completo del root filesystem o el filesystem deteriorado. Si el filesystem entero o un disco completo se fueron al garete, necesitaremos format y fsck.
3) Arrancamos normalmente, si se ha fastidiado todo el filesystem tenemos trabajo de creación y restaurado, pero si se trata de un accidente parcial, restauramos en directorio aparte si es que hay sitio, y dejamos que el usuario coja los ficheros que le faltan o se los ponemos nosotros en su sitio.
No sólo hemos de ser capaces de entender la mecánica de volcado y restaurado sino que también tenemos que saber un poco de la tecnología de las cintas. Hay dispositivos rewind y norewind (para backup utilizamos las norewind) y en el nombre de dispositivo viene indicado tanto esto como su modo de compresión /dev/rmt/1cbn
Para muestra un botón
#!/bin/ksh # @(#)FileDescription: Backup Script |
Como podemos ver en los comentarios, para restaurar algo del directorio /home, tendríamos que ejecutar el comando:
|
También podemos tener que usar el comando rmt para manejar la cinta. Dentro de este comando, los subcomandos fsf y bsf nos sirven para ir y venir del registro (1, 2, 3, 4, 5 en nuestro ejemplo).
No hay comentarios:
Publicar un comentario