Linux Avanzado Tema 5: Comandos Administrativos Registro del sistema Acerca de los registros Muchos procesos y servidores bajo un sistema Linux anexan información de estado variable a "archivos de registro." Estos archivos de registro a menudo están localizados en el directorio /var/log/ y frecuentemente comienzan con una marca de tiempo indicando cuando ocurrió el evento descrito. Pero, para bien o para mal, no existe una consistencia real en cuanto al formato preciso de los archivos de registro. La única característica confiable es que los archivos de registro de Linux son simples archivos ASCII, y contienen solo un "evento" por línea de archivo. A menudo (pero no siempre) los archivos de registro contienen un conjunto, relativamente consistente, de campos de datos delimitados por espacios o por pestañas. Algunos procesos, especialmente los servicios de Internet, controlan la escritura de los archivos de registro dentro de su propio proceso. En el fondo, escribir a un archivo de registro son solo datos anexados a un control de archivo abierto. Pero muchos programas (especialmente los daemons y los trabajos cron usan el syslog API estándar para permitir que los daemons syslogd o klogd controlen el proceso de registro específico.

Análisis de chivos de registro La forma exacta de cómo realizar el análisis de un archivo de registro dependerá mucho del formato específico que tome. Para los archivos de registro con formato de tabla normal, herramientas tales como cortet, separe, cabeza, y cola seguramente serán útiles. Para todos los archivos de registro, grep es una excelente herramienta para hallar y filtrar contenidos de interés. Para tareas de procesamiento más complejas, probablemente se considere sed, awk, perl o python como herramientas opcionales. Para una buena introducción a muchas de las herramientas de procesamiento de texto, que probablemente se utilicen en el proceso y análisis de archivos de registro, ver el tutorial developerWorks de IBM de David en las utilidades de procesamiento de textos GNU. También existen distintas buenas herramientas de mayor nivel para trabajar con archivos de registro, pero estas herramientas son generalmente utilidades de distribución específica y/o no estándar (pero a menudo de Software Libre).

Registrar con syslogd y klogd El klogd daemon intercepta y registra mensajes kernel de Linux. En general, klogd utiliza las capacidades más generales de syslogd, pero en casos especiales puede registrar mensajes directamente a un archivo. El syslogd daemon general provee registro para muchos programas. Cada mensaje registrado contiene al menos un campo de tiempo y de nombre de host y generalmente un campo de nombre del programa. El comportamiento específico del syslogd está controlado por el archivo de configuración /etc/syslog.conf. Los mensajes de aplicaciones (incluyendo los de kernel) pueden ser registrados a archivos, que generalmente se encuentran bajo /var/log/ o en forma remota sobre el socket de red.

Configuración del /etc/syslog.conf El archivo /etc/syslog.conf contiene un conjunto de reglas, una por línea. Se deberán ignorar las líneas vacías y las líneas que comienzan con un "#". Cada regla consiste en dos campos separados por espacios en blanco, un campo selector y un campo de acción. El selector, a su vez, contiene uno de varios pares de facilidades separadas por puntos/prioritarios. Una facilidad es un subsistema que intenta registrar mensajes y puede tener valores (puede no distinguir mayúsculas de minúsculas): auth,authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, security, syslog, user, uu cp y local0 hasta local7.

1

Las prioridades tienen un orden específico y el hecho de coincidir con una determinada prioridad significa "ésta o una más alta" a menos que se inicie con un "=" (o "!="). Las prioridades son, en orden ascendente: debug, info, notice, warning o warn,err o error, crit, alert, emerg o panic (algunos nombre tienen sinónimos). none significa que no se indica una prioridad. Ambas facilidades y prioridades pueden aceptar el comodín "*". Hay múltiples facilidades que pueden ser separadas por una coma y múltiples selectores que pueden ser separados por un punto y coma. Por ejemplo: # from /etc/syslog.conf # all kernel mesages kern.* -/var/log/kern.log # `catch-all' logfile *.=info;*.=notice;*.=warn;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none -/var/log/messages # Emergencies are sent to everybody logged in *.emerg *

Configuración de un registro remoto Para habilitar el registro remoto de mensajes syslogd (en realidad mensajes de aplicación controlados por syslogd), se debe primero habilitar el servicio "syslog" tanto en las máquinas de escucha como en las de envío. Para ello, se debe agregar una línea a cada archivo de configuración /etc/services que contenga algo como: syslog 514/UDP

Para configurar el syslogd (de envío) local para que pueda enviar mensajes a un host remoto, se especifica una facilidad y una prioridad normal pero se indica una acción comenzando con un símbolo "@" para el host de destino. Un host se puede configurar de la manera habitual, ya sea con /etc/hosts o vía DNS (no se necesita tenerlo ya resuelto al momento de lanzar syslogd por primera vez). Por ejemplo: # from /etc/syslog.conf # log all critical messages to master.example.com *.crit @master.example.com # log all mail messages except info level to mail.example.com mail.*;mail.!=info @mail.example.com

Rotación de archivos de registro Frecuentemente no es deseable dejar crecer ciertos archivos de registro de forma descontrolada. La utilidad logrotate se puede utilizar para archivar información registrada con anterioridad. Usualmente, logrotate se ejecuta como un trabajo cron(programador de tareas a intervalos de tiempo predeterminados), por lo general siempre en forma diaria. logrotate permite una rotación automática, compresión, eliminación, y envío de archivos de registro. Cada archivo de registro puede ser controlado en forma diaria, semanal, mensual o sólo cuando crece de manera desmesurada. El comportamiento de logrotate se controla mediante el archivo de configuración /etc/logrotate.conf (o algún otro archivo especificado). El archivo de configuración puede contener tanto opciones globales como opciones de archivos específicos. Generalmente, los registros archivados se guardan por un período de tiempo finito y se les da nombres de copias de seguridad secuenciales. Por ejemplo, tengo un sistema que contiene los siguientes archivos debido a su calendario de rotación. -rw-r----- 1 root adm 4135 2005-08-10 04:00 /var/log/syslog -rw-r----- 1 root adm 6022 2005-08-09 07:36 /var/log/syslog.0 -rw-r----- 1 root adm 883 2005-08-08 07:35 /var/log/syslog.1.gz -rw-r----- 1 root adm 931 2005-08-07 07:35 /var/log/syslog.2.gz -rw-r----- 1 root adm 888 2005-08-06 07:35 /var/log/syslog.3.gz -rw-r----- 1 root adm 9494 2005-08-05 07:35 /var/log/syslog.4.gz -rw-r----- 1 root adm 8931 2005-08-04 07:35 /var/log/syslog.5.gz

2

Empaquetamiento de software En el principio era el En realidad, para distribuir software personalizado en Linux, se requiere mucho menos de lo que se cree. Linux tiene un estándar bastante claro en cuanto a la ubicación de archivos de distintos tipos e instalar software personalizado, en el fondo, no implica mucho más que ubicar los archivos correctos en el lugar correcto. La herramienta Linux tar (que significa "tape archive [archivo de almacenamiento de cinta]" a pesar de que no necesita y generalmente no utiliza cintas) es perfectamente adecuada para crear un archivo de almacenamiento de archivos con las ubicaciones de los sistemas de archivos especificadas. Para la distribución, generalmente es deseable comprimir un archivo de almacenamiento tar con gzip (GNU ZIP) (o bzip2). Para más información sobre estas utilidades ver la sección final de este tutorial en la copia de seguridad. Generalmente se denomina a un archivo de almacenamiento comprimido tar con las extensiones .tar.gz o .tgz (o .tar.bz2). Las primeras distribuciones Linux, y algunas de las actuales, tales como Slackware, usan simplemente tarballs como mecanismo de distribución. Para una distribución personalizada de software interno de la empresa a sistemas Linux mantenidos centralmente, continúa siendo el método más sencillo.

Formatos de archivos de almacenamiento personalizados Muchos lenguajes de programación y otras herramientas vienen con sistemas de distribución personalizados que son neutrales entre las distribuciones Linux y, generalmente, entre sistemas operativos totalmente diferentes. Python tiene sus herramientas distutils y formatos de archivo de almacenamiento; Perl tiene archivos de almacenamiento CPAN; Java tiene archivos .jar; Ruby (lenguaje de programación) tiene gems. Muchas aplicaciones no idiomáticas tienen un sistema estándar para distribuir los complementos, u otras mejoras, también a una base de aplicación. Si bien se puede usar perfectamente un formato de paquete como DEB o RPM para, por ejemplo, distribuir un paquete Python, en general tiene más sentido seguir los estándares de empaquetamiento de la herramienta para la cual se creó el paquete. Por supuesto, para utilidades y aplicaciones a nivel sistema o para la mayoría de las aplicaciones userland compiladas, ese estándar equivale a los estándares de empaquetamiento de distribución Linux. Pero para las herramientas personalizadas escritas en lenguajes de programación específicos, algo diferente podría promover una más simple reutilización de las herramientas en todas las distribuciones y plataformas (ya sea que los destinatarios elegidos sean usuarios internos de la empresa o externos).

Los “dos grandes” de los formatos de paquetes Existen dos formatos de paquetes principales utilizados por las distribuciones Linux: Redhat Package Manager (RPM) y Debian (DEB). Ambas son similares en cuanto al propósito pero difieren en sus detalles. En general, los dos son un formato para un archivo de almacenamiento de archivos “mejorado”. Las mejoras aportadas por estos formatos de paquete incluyen anotaciones para números de versión, dependencias de una aplicación sobre otras aplicaciones o bibliotecas, descripciones de herramientas empaquetadas de legibilidad humana, y un mecanismo general para gestionar la instalación, actualización y desinstalación de herramientas empaquetadas. Bajo los archivos DEB, el archivo de configuración anidado control contiene la mayor parte de los metadatos del paquete. Para los archivos RPM, el archivo spec es el que juega este rol. Todos los detalles de la creación de buenos paquetes, en cualquiera de los formatos, va más allá de este tutorial, de todas formas esbozaremos aquí los fundamentos básicos.

">¿Qué hay dentro de un archivo .deb? Un paquete DEB se crea con la herramienta de archivos de almacenamiento, y primo de tar, ar (o mediante alguna herramienta de mayor nivel que utilice ar). Por lo tanto podemos usar ar solo para ver que hay realmente dentro de un archivo .deb file. Normalmente se usarían herramientas de

3

mayor nivel tales como dpkg, dpkg-deb o apt-get para de hecho trabajar con un paquete DEB. Por ejemplo: % ar tv unzip_5.51-2ubuntu1.1_i386.deb rw-r--r-- 0/0 4 Aug 1 07:23 2005 debian-binary rw-r--r-- 0/0 1007 Aug 1 07:23 2005 control.tar.gz rw-r--r-- 0/0 133475 Aug 1 07:23 2005 data.tar.gz

El archivo debian-binario simplemente contiene la versión DEB (actualmente 2.0). El tarball data.tar.gz contiene en realidad los archivos de aplicación; ejecutables, documentación, páginas del manual, archivos de configuración, etc. El control.tar.gz tarball es el más interesante desde una perspectiva de empaquetamiento. Veamos el ejemplo de paquete DEB elegido: % tar tvfz control.tar.gz drwxr-xr-x root/root 0 2005-08-01 07:23:43 ./ -rw-r--r-- root/root 970 2005-08-01 07:23:43 ./md5sums -rw-r--r-- root/root 593 2005-08-01 07:23:43 ./control

Como es de esperar, md5sums contiene hashes cifrados de todos los archivos distribuidos con fines de verificación. El archivocontrol es do nde se aloja la metadata. En algunos casos también se podría encontrar o desear incluir scripts llamadospostinst y prerm en control.tar.gz para, realizar los determinados y respectivos pasos luego de la instalación o antes de la remoción.

Creación de un archive de control DEB Los scripts de instalación pueden hacer todo lo que podría hacer un script shell. (para hacerse una idea ver algunos ejemplos en paquetes existentes). Pero esos scritps son opcionales y, a menudo, no necesarios o incluidos. Lo que se requiere para un paquete .deb es su archivo de control. El formato de este archivo contiene varios campos de metadata que se ilustra mejor por medio de un ejemplo: % cat control Package: unzip Version: 5.51-2ubuntu1.1 Section: utils Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.2.ds1-4) Suggests: zip Conflicts: unzip-crypt (