LinuxParty

SU y SUDO

Tanto el programa su como el programa sudo nos permiten ejecutar ordenes con privilegios de root o en el caso de su, ingresar al sistema con la cuenta de otro usuario. Dicho esto, las situaciones típicas para usar estos comandos serán para el caso de su:

1. Estamos logueados con nuestro usuario estándar y necesitamos ejecutar una o varias tareas como root, ya sean ejecutar binarios, modificar archivos crearlos o eliminarlo
2. Estamos con un usuario cualquiera, incluido root, y nos vemos en la necesidad de pasarnos a otro usuario

Para el uso de sudo, tendremos que vernos en la necesidad de obtener privilegios de root de forma temporal para realizar tareas administrativas.

El nombre de su deriva de la abreviatura SuperUser o en otros casos leeremos que viene de Substitute User. El nombre de sudo es la abreviatura del Inglés Substitute User do.

Ambos comandos nos facilitan o simplifican la tarea de tener que salir de nuestra sesión y volver a iniciar con la de un determinado usuario incluido root. Imaginemos que estamos con nuestro usuario estándar y necesitamos modificar el archivo /etc/passwd para el que solo root tiene permisos de escritura. Sin tener la posibilidad de ejecución de estos dos comandos deberíamos de salir de la sesión y volver a loguearnos con los credenciales de root, pero se nos facilita la tarea con tan solo escribir $ su - y posteriormente editar el archivo, bastará escribir # exit para volver a nuestra sesión anterior o bien ejecutar el comando de edición directamente tras sudo, tal que así: $ sudo vi /etc/passwd

Para ambos comandos existen algunas peculiaridades. Por ejemplo podríamos haber ejecutado ‘su‘ sin el guión ‘-‘ pero de hacerlo así, habríamos accedido a la cuenta de root, sin ejecutar sus archivos de configuración de pérfil y sin cambiar de directorio de trabajo al directorio de trabajo por defecto de root (/root). Si pasamos de una cuenta de usuario a otra, ya sea a la cuenta root o a la cuenta de otro usuario estándar necesitaremos introducir su contraseña, solo root podrá acceder mediante ‘su‘ a cualquier cuenta del sistema sin precisar de la contraseña de la cuenta de usuario a la que se mueve. Para el caso de ‘sudo‘ necesitaremos que nuestro usuario estándar cuente con el derecho de poder ejecutar sudo y además de editar el archivo, es decir, los permisos de quien usa sudo y como lo hará se definen en el archivo /etc/sudoers. Una línea demasiado permisiva de este archivo sería:

%sudo ALL=(ALL:ALL) ALL

Esta línea indica que cualquier usuario perteneciente al grupo sudo podrá ejecutar cualquier comando de root bajo la utilidad sudo.

Hablaremos sobre este archivo en el capítulo destinado a la seguridad (Capítulo – 10)

Nota: El comando su -c <comando> suele ser muy utilizado en scripts de inicio de servicios para iniciar un servicio bajo el nombre de otro usuario.

Monitorizar el sistema mediante sus archivos de registro

Linux mantiene archivos de registros (logfiles) a los que se reportan sucesos relevante sobre el funcionamiento del sistema, ya sea como del propio kernel o de servicios de red que se encuentran ejecutados de forma permanente en segundo plano (demonios). Estos archivos de registros son especialmente útiles para detectar fallas en el sistema, o incluso prever estas mediante la monitorización de archivos claves o concretos de un servicio. Una de las obligadas tareas que tiene un administrador de sistemas es precisamente revisar estos archivos de registro periódicamente para poder anticiparse a problemas venideros o por ejemplo conocer las causas de porque un servicio no se ejecuta de forma correcta.

Una particularidad común de todos los sistemas de registro y los archivos en los que se acumula la información es que crecen, de hecho pueden crecer tanto que dejen el sistema operativo ‘no operativo‘ dependiendo de donde se estén guardando estos archivos. Por ejemplo si tenemos una partición ‘/‘ (raíz) en la que se encuentra el directorio /var y bajo este lo normal es encontrar los archivos de registro (/var/log/*) puede hacer que el espacio asignado para la partición raíz se llene impidiendo incluso el acceso de nuevos usuarios al sistema o trabajando de una forma extraña. Por ello el administrador del sistema está obligado a definir una política de seguridad ante tal problema. La política que se implemente estará definida de acuerdo al esfuerzo de administración que conlleve o a la importancia que la organización le preste a tal problema, entre otras. Algunas de las políticas suelen ser:

• No almacenar archivos de registro. Evidentemente esta opción es muy poco recomendable, aunque evidentemente se establecerá o no, en función de la criticidad del sistema.
• Resetear los archivos periódicamente. Puede ser una medida a corto plazo contra el llenado de espacio de un disco o partición, pero a largo plazo puede ser desastrosa, ya que no contaremos con los archivos de registro que quizás necesitemos en función del tiempo que haya pasado.
• Rotar los archivos en función del tiempo transcurrido. Esta suele ser una de las medidas mas adoptadas por administradores de sistemas. Es una política configurable desde los propios archivos de configuración del sistema de registro que estemos usando. Una vez rotado el archivo, el antiguo es comprimido (ahorrando espacio en disco) y quizás llegue el momento en el que sea automáticamente eliminado dependiendo del tiempo de rotación y cantidad de archivos rotados almacenados en el disco que hayamos definidos. Algunos sistemas de registro como Journal comprimen directamente los archivos de registros.
• Almacenar los archivos de registro. Si disponemos de una unidad externa de almacenamiento o partición destinada a copias de seguridad, podemos guardar nuestros archivos de registro en dicha unidad y acceder a ellos cuando fuese necesario.

Nota: Podemos jugar con las opciones de rotar y almacenar para encontrar una solución definitiva.

Existen diferentes sistemas de registro para Linux. Vamos a estudiar el demonio syslogd, syslog-ng (syslog de nueva generación), rsyslog y Journal

Syslog

Es un sistema que procura centralizar el manejo de los registros de eventos que generan los diversos programas que corren bajo un sistema Linux. Por un lado facilita a los desarrolladores de aplicaciones la generación y el manejo de mensajes a registrar, y por otro lado facilita a los administradores de sistema el manejo de forma centralizada de los mensajes provenientes de diferentes aplicaciones. Syslog clasifica los mensajes por origen e importancia, y los envía a diferentes destinos como pueden ser archivos, la terminal  o eventualmente a un comando que lo reenvíe a direcciones de correo electrónico o paginador.
Syslog permite manejar mensajes originados en diferentes sistemas de la red.

Los componentes más importantes de syslog son:

• syslogd: el daemon que recibe los mensajes y los almacena de acuerdo a la configuración del archivo /etc/syslogd.conf
• openlog(), syslog() y closelog(): rutinas de la biblioteca C estándar para permitir la comunicación entre syslog y el programa.
• logger: comando de usuario para agregar un mensaje a un archivo de registro

Instalación y configuración de syslogd

El demonio syslogd es uno de los primeros que se lanza cuando el sistema se incia, para comenzar a recibir mensaje desde los diferentes servicios de red y registrarlos en sus respectivos archivos de registro de acuerdo con lo especificado en su archivo de configuración.

En ocasiones se suelen confundir o comparar los demonios syslogd y klogd, este ultimo registra los eventos del kernel. Ambos demonios son instalados mediante el mismo paquete sysklogd desde los repositorios oficiales.

Una vez tengamos instalado el sistema de registro tendremos que configurarlo, esto como mencionamos anteriormente lo haremos desde el archivo de configuración /etc/syslogd.conf. Este archivo tiene un formato sencillo pero ofrece un gran potencial. Las líneas adoptan la siguiente forma:

recurso.prioridad acción

En algunos documentos, libros, wikis, etc… podremos leer facility.level en vez de su traducción recurso.prioridad, al final ambos identifican a un selector. Es decir un selector estará formado por un recurso que no es mas que el código del tipo de programa que generó el mensaje y la prioridad, que será igualmente un código que identifique la importancia que tendrá ese mensaje. El campo acción decide el que se hará con todos los mensajes que se identifiquen con un determinado selector (recurso.prioridad).

Vamos a ver los posibles valores de cada campo y seguidamente expondremos un ejemplo para ver esto de una forma mas clara.

• recurso: Suelen ser valores prefijados por el sistema e identifican a uno o varios servicios como auth (mensajes relacionado con la seguridad), mark (reservado para uso interno), mail, cron, daemon, lpr, ftp, news, syslog, uucp y desde local0 hasta local7 (usados con cierta libertad por el usuario para diferentes aplicaciones). No todos los recursos se encuentran  aquí enumerado. Si quisiéramos especificar mas de un recurso para una prioridad y acción concreta en una sola línea del archivo se utila el caracter ‘,‘ (coma) y si queremos definir todos los recursos para una prioridad y acción ‘*‘ (asterísco)
• prioridad: Con este campo seleccionaremos que mensajes queremos incluir en uno u otro archivo de registro para uno o varios recursos. Los códigos de prioridad, listados de menor a mayor prioridad son: debug, info, notice, warning (warn), err (error), crit, alert y emerg o panic (este último en desuso, al igual que warn y error). La prioridad debug registra la mayor parte de la información (pensado para depurar programas) y en el extremo opuesto emerg, que registrará los mensajes para problemas muy serios. Un aspecto importante a tener en cuenta es saber que mensajes serán guardados en los archivos de registro. Todos los mensajes emitidos por los recursos se acompañan de un código de prioridad, y serán registrados por defecto siempre y cuando el código sea igual o superior (esto es modificable) al indicado en el archivo de configuración para ese determinado recurso. A continuación veremos esto con un ejemplo.
• Acción: Existen varias opciones para este campo, la mas utilizada es la de guardar los registros en un archivo, el cual deberá de estar creado de antemano y bastará con indicar el path completo. Podemos enviar los registros al demonio syslogd de otra máquina escribiendo ‘@<nombre máquina o IP>‘ o reenviar a la terminal de un usuario siempre y cuando este esté logueado indicando como acción un archivo de dispositivo de consola (/dev/console). En esta última opción podremos separar diferentes usuarios con el caracter ‘,‘ o marcar a todos con un asterisco ‘*‘. Algunos sistemas permiten enviar el mensaje a la entrada estándar de un comando mediante un pipe ‘|‘.

Los espacios entre los selectores (recurso.prioridad) y la acción suelen ser tabulaciones. Vamos a clarificar con algunos ejemplos las situaciones descrita en los puntos anteriores.

• Registrar todos los mensajes (*) del recurso mail al archivo /var/log/mail:

mail.*        /var/log/mail

• Enviar solo los mensajes con prioridad notice para los recursos news y mail a la consola principal del sistema:

news,mail.=notice        /dev/console

Nota: Podemos separar varios recursos son ‘,‘. Si en el archivo de configuración existe también la entrada del ejemplo anterior, los mensajes de mail para prioridad notice serán enviados a la consola y registrados en /var/log/mail. Podríamos haber cambiado /dev/console por ‘*‘ (asterisco) para enviar los mensajes a todas las consolas de modo texto abiertas en el sistema.

• Registrar todos los mensajes con prioridad crit o superior (es decir; crit, alert y emerg) del recurso daemon en /var/log/error y los mensajes con prioridad warn o menor (es decir; warn, notice, info y debug) para el recurso lpr en /var/log/lpr-info. Si queremos especificar los mensajes con prioridad igual o menor a una determinada prioridad lo haremos con el caracter de admiración ‘!‘:

daemon.crit        /var/log/error
lpr.!warn        /var/log/lpr-info

• Ahora vamos a ver como manejar diferentes mensajes según su prioridad para un recurso con acciones diferentes. En este ejemplo vamos a enviar con la primera línea todos los mensajes generados por el kernel al archivo /var/log/kernel, con la segunda línea indicaremos que además de registrarse en el archivo, aquellos que tengan una prioridad crit o superior se enviarán a syslogd de otro sistema (el otro sistema tiene que estar configurado para tal fin) y además esos mismos mensajes también serán impresos por terminal gracias a la tercera línea. Por último haremos que todos los mensajes comprendidos entre la prioridad info y err, además de ser enviados al archivo /var/log/kernel gracias a la primera línea, serán escritos en el archivo /var/log/kernel-info:

kern.*        /var/log/kernel
kern.crit        @unamaquina.enundominio.es
kern.crit        /dev/console
kern.info;kern.!err        /var/log/kernel-info

Nota: Vemos como hemos seleccionado dos selectores separados por el caracter ‘;’ para ser comprendidos por una misma acción

Añadir registros manualmente

Cuando mencionamos anteriormente los componentes mas importantes de syslog vimos que logger es la herramienta que nos permite crear registros de forma manual.

$ logger ejemplo del funcionamiento de logger

El resultado sería seguramente una entrada en el archivo /var/log/message con el siguiente contenido:

Feb 11 18:02:27 LiMinCinn nebul4ck: ejemplo del funcionamiento de logger

Rotar archivos de registro

La rotación del registro se controla a través del archivo /etc/logrotate.conf en el que se suele incluir la referencia a los archivos bajo /etc/logrotate.d/. Las entradas de estos archivos le indican al sistema si debe rotar los registros a intervalos fijos o cuando estos almacenen un tamaño concreto. Cuando un registro rota, se renombra y dependiendo de la configuración se comprimirá o no, se creará uno nuevo e incluso puede que se borre el archivo de registro comprimido mas antiguo de los existentes.

Para rotar archivos de registros necesitaremos tener instalado el paquete logrotate, tener una buena configuración y ser lanzado periódicamente, algo de lo que se encargará cron o en su defecto (ya que esta tarea es ejecutada por las noches y la mayoría de los pc de usuario duermen en estas horas) anacron, pero de esto hablaremos en las próximas secciones.

Cuando se invoca logrotate este consulta su archivo de configuración (o archivos en caso de que este referencie a otros como /etc/logrotate.d/*) y actuará en función de los ajustes que en él o ellos encuentre. Un archivo de configuración para logrotate podría tener el siguiente aspecto:

# Rotar los archivos de registro de forma semanal
weekly
# Usar el grupo syslog por defecto
su root syslog
# Conservar los registros antiguos durante 4 semanas
rotate 4
# Crear nuevos archivos de registro tras la rotación
create
# Comprimir los archivos de registros antiguos
compress
# Incluir configuraciones para archivos de registros de servicios específicos
include /etc/logrotate.d
# Algunas otras opciones
notifempty
nomail
noolddir
# Rotar archivos de registro para wtmp el cual no está controlado por un archivo de 
# configuración individual
/var/log/wtmp {
       missingok
       monthly
       create 0664 root utmp
       rotate 1
}

Si se especifica la inclusión de archivos de configuración bajo /etc/logrotate.d significará que habrá servicios que configuren sus propios archivos de registro de los que además serán los propietarios. Algunos de los servicios que tienen tal comportamiento podrían ser: apt, aptitude, yum,  dpkg, samba, ufw y upstart. A continuación pondremos uno de estos archivos a modo de ejemplo.

El archivo de configuración para samba incluye dos servicios: smbd y nmbd ambos con sus respectivos archivos de configuración bajo el directorio /var/log/samba y con su propia configuración.

Algunas de las características mas importante de los archivos de configuración individuales para logrotate están contemplados en la imagen anterior, aun así vamos a nombrar algunos mas.

• Nomenclatura de los archivos rotados: Por defecto a los archivos rotados se le asigna un digito como extensión al nombre del archivo por ejemplo: smbd.log.3 (indica que este archivo a rotado un total de tres veces). Podemos cambiar este comportamiento con la opción dateext
• Opciones de compresión: Definida en nuestro ejemplo con la palabra compress. Por defecto se comprimen con gzip, si queremos usar por ejemplo bzip podemos definirlo así: compresscmd bzip2 e indicar opciones del comando, como la tasa de compresión con compressoptions
• Crear un nuevo archivo de registro tras la rotación: Podemos hacer que se cree un nuevo archivo con la opción copytruncate que lo que realmente hace es copiar el archivo antiguo y vaciar su contenido, o por ejemplo pasar un usuario propietario y unos permisos (esto no siempre funciona): create 644 samba samba
• Opciones temporales: Con daily, weekly y monthly provocaremos que los registros roten diariamente, semanalmente o mensualmente respectivamente.
• Opciones de tamaño: Si no queremos rotar en función del tiempo podremos hacerlo especificando un tamaño máximo de archivo de registro, por defecto el valor es en bytes aunque podemos cambiar esto con los sufijos k o M. size 100k para que el archivo rote cuando haya llegado al tamaño de 100Kilobytes
• Opciones de rotación: Con rotate ‘número‘ indicaremos cuantos archivos de registros antiguos queremos conservar. Si indicamos rotate 3, tendremos smbd.1.gz, smbd.2.gz y smbd.3.gz. Cuando el que actualmente está registrando los mensajes llegue a su tamaño de cota o al tiempo límite de rotación pasará a llamarse smbd.1.gz y smbd.3.gz será eliminado. Los otros dos archivos pasarán del 1 al 2 y el otro del 2 al 3.
• Opciones de correo: Utilizando mail ‘dircorreo‘ podremos enviar el archivo que rota por correo electrónico. Con nomail no enviaremos ningún correo.
• Scripts: Las palabras claves prerotate y postrotate indican que se ejecute una acción (comando) antes o después de haber rotado un archivo de registro. En nuestra imagen tenemos el ejemplo. Para finalizar la ejecución de los comandos lo haremos con endscript.

Revisar el contenido de los archivos de registro

Para revisar un archivo de registro primero deberemos de encontrar el archivo y luego buscar la información deseada dentro de este. Lo normal es que los archivos de registro se guarden bajo el directorio /var/log, que a su vez como hemos visto en el ejemplo de samba puede haber un directorio para un servicio concreto y dentro de este encontremos el archivo de registro. Utilizaremos normalmente las herramientas cat, tail y head, o los paginadores less y more.

La mayoría de mensajes enviados por el sistema suelen guardarse en el archivo /var/log/messages, archivo que podremos desplegar con el comando dmesg. Otros archivos de registros importantes son auth.log, utmp, wtmp y lastlog. Linux mantiene un registro en los archivos utmp y lastlog sobre información de los usuarios como por ejemplo si un usuario está logueado en el sistema, en que terminal y desde cuando. Estos archivos son actualizados en cada login y logout guardando además esta información en el archivo wtmp que mantendrá entonces un histórico sobre los inicios de sesión de los usuarios. Al ser una archivo que va creciendo deberemos de tenerlo contemplado en la configuración de logrotate.
Estos archivos están en formato binario pero podrán ser desplegados con los comandos who, w y lastlog. El comando who desplegará el contenido del archivo utmp por lo que veremos los registros de los usuarios actualmente dentro del sistema, en que terminales se encuentran (pts/<número>, si iniciaron una terminal virtual desde el entorno gráfico o tty<número> si se lanzó la consola al inicio de sesión. Podremos ver también la terminal actual con el comando tty) y la hora de inicio de sus sesiones. El comando w se comporta de la misma manera pero nos ofrece algo mas de información como por ejemplo el display utilizado. Si queremos desplegar el contenido del archivo de registro lastlog bastará con invocar a lastlog, el cual depslegará una lista de todos los usuarios de /etc/passwd mostrando su último inicio de sesión (para los usuarios nunca logueados aparecerá: Never logged in). Para desplegar el contenido del archivo wtmp (histórico de login y logout de usuarios) pasaremos como parámetro el nombre del archivo wtmp al comando who:

 $ who /var/log/wtmp

o bien utilizando directamente el comando last o lastb para ver el histórico de logueos e incluso logueos fallidos, respectivamente.

Nota: Los comandos w, who, last y lastb nos muestran como mínimo el usuario, la terminal, el display y la hora de inicio. El comando w además muestra la carga del sistema y el número de usuarios conectados. who y last muestra además la fecha.

La ubicación de estos archivos varía de un sistema a otro. El archivo utmp habitualmente está en el directorio /etc o /var/run, el archivo wtmp suele estar en /var/log o /var/adm al igual que el archivo lastlog.

Una vez identificado el archivo de registro necesitado podremos desplegar su contenido con uno de los paginadores conocidos (more o less), buscando contenido específico con grep, o tail y head que podrán sernos igualmente útiles y si queremos dejar monitorizando un archivo de registro específico ya sabemos que la opción -f de tail nos permite tal acción.

Existen herramientas avanzadas de análisis del registro como Logcheck que forma parte del paquete Sentry Tools o Whatlogh

Syslog-ng

Syslog-ng (Syslog de nueva generación) es una implementación del antiguo syslog en la que se mejoran algunos aspectos como la capacidad de filtrado mediante contenido, su flexibilidad de configuración, uso de TCP en lugar de UDP y la opción de crear túneles de conexión cifrada bajo SSL/TLS.

El funcionamiento de syslog-ng es básicamente como el de syslog, es decir, los mensajes generados por una fuente ‘source‘ son enviados a una dirección ‘destination‘ a través de una serie de filtros ‘filter‘ basados en el contenido. Source, filter y destination forman el logpath cuyo equivalente en syslog sería el Selector (recurso.prioridad) + Acción. El archivo de configuración de syslog-ng es /etc/syslog-ng/syslog-ng.conf. No obstante como en otros servicios Linux, contamos con un directorio en el que almacenar diferentes configuraciones individuales para determinados servicios, en este caso para separar los distintos filtros y plantillas para el procesamiento de reglas.

Antes de pasar al archivo de configuración vamos a ver los distintos ‘source‘ y ‘destination‘ así como la manera de poder filtrar los mensajes.

Para filtrar los mensajes podremos usar los siguientes filtros:

• facility: Servicio que origina el log. Al igual que con syslog pueden ser algunos como kern, user, mail, lpr, daemon, etc…
• level/priority: Prioridad del mensaje. Las mismas que para syslog. none (no envía mensajes), debug, info, notice, warning, err, crit, alert y emerg.
• program: Filtrará los mensajes de aquellos programas que coincidan con una expresión regular dada.
• host: Filtra los mensajes de aquellos ordenadores cuyo nombre coincida con una expresión regular dada.
• filter: Con este filtro podremos invocar a otro filtro.
• match: Aplica una expresión regular

Los destinos serán los que especifiquen a donde y como serán enviados los mensajes.

Logpath: Source, filter y Destination

No vamos a entrar en muchos detalles del archivo de configuración, pero si que conoceremos los detalles básicos que nos permitirán leer el archivo con cierta claridad. Lo primero a tener en cuenta es saber que el archivo syslog-ng.conf definirá unas opciones de orden general. Un ejemplo:

options {
    sync (0);
    stats (0);
    chain_hostnames(no);
    create_dirs (yes);
    dir_perm(0755);
    dns_cache(yes);
    keep_hostname(yes);
    log_fifo_size(2048);
    long_hostnames(no);
    perm(0644);
    time_reopen (10);
    use_dns(yes);
};

Una vez especificadas las opciones generales casi a gusto de consumidor, tendremos que definir las fuentes de las que queremos obtener mensajes, los filtros y los destinos. Existe una sintaxis concreta para definir una fuente y es la siguiente:

source <identificador> { source-driver_1(parámetros); source-driver_2(parámetros); ... };

Algunos ejemplos de fuentes podrían ser:

• Permitir que las aplicaciones se comuniquen con el sistema de logs. Linux utiliza unix-stream:

source src { unix-stream("/dev/log"); internal(); };

Nota: Con internal estamos diciendo que solo filtre mensajes de nuestra propia máquina.

• Permitir que el kernel muestres sus mensajes:

source kernsrc { file("/proc/kmsg"); };

Nota: Podríamos haber unido ambas líneas en una sola y utilizar el driver de fuente pipe en vez de file. La diferencia es que la pipe abre el archivo en modo de lectura-escritura por lo que puede suponer una vulnerabilidad.

source src { unix-stream("/dev/log"); internal(); pipe("/proc/kmsg"); };

• Otras definiciones de fuentes podrían ser:

source s_net { udp(); };

source s_net { tcp(); };

source s_apache_ssl_access {
 file("/var/log/apache2/ssl_access.log" follow_freq(1) flags(no-parse));
};

Al igual que las fuentes, los filtros y destinos tienen su propia sintaxis.

La sintaxis para los filtros es la siguiente:

filter <identifier> { expression; };

y algunos ejemplos son:

• Filtrar mensajes para el recurso auth:

filter f_auth { facility(auth); };

• Filtrar mensajes que vayan desde la prioridad info a warning y no incluya para estas prioridades los recursos mail y news:

filter f_messages { level(info..warning) and not facility(mail, news); };

Para definir un destino utilizaremos la siguiente sintaxis:

destination <identifier> {destination-driver(params); destination-driver(params); ... };

Y algunos ejemplos de destinos son:

destination authlog { file("/var/log/auth.log"); };

destination console { usertty("root"); };

destination remote_server { udp("10.0.0.2" port(514)); };

Ahora que ya conocemos como definir un recurso, un filtro y un destino vamos a formar el logpath que los conectará para formar un ‘objeto’ concreto. La sintaxis de LogPath se va a ver claramente con el siguiente ejemplo:

log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };

Cuando tengamos listo el archivo de configuración reiniciaremos syslog-ng de acuerdo al sistema de inicialización que tengamos ejecutándose es decir, service (o script SysV), initctl (Upstart) o systemctl (systemd).

Rsyslog

Rsyslog es el remplazo de syslog-ng en muchas distribuciones por defecto. Es un eficiente y rápido sistema de procesamiento de registros del sistema que ofrece un diseño modular y niveles de seguridad que lo hacen ideal para muchos programas modernos. Suele incorporarse en las distribuciones mas modernas (aquellas que aun no implementan systemd) como sistema de registro por defecto al ser suficientemente versátil y robusto para ser utilizado tanto en entornos empresariales como sistemas de escritorio. rsyslog mantiene compatibilidad con sysklog. Es posible utilizar el archivo de configuración syslog.conf para una configuración básica de rsyslog, pero no al revés, debido a que rsyslog implementa mejoras en su archivo de configuración que hacen posible por ejemplo crear plantillas que permitan almacenar los registros en BBDD Mysql (MariaDB) o Postgresql, seleccionar un formato específico de mensajes, crear archivos de nombre dinámico para almacenar los registros de un programa, etc…

Nota: rsyslog usa logrotate para su rotación de archivos.

El archivo de configuración principal de rsyslog es /etc/rsyslog.conf y por regla general suele tener una estructura básica compuesta de las siguientes secciones:

• Configuración global: Establece las propiedades globales del demonio rsyslog como el tamaño de la cola de mensajes ($MainMessageQueueSize) o la carga de módulos externos ($ModLoad). Cada línea contiene una propiedad de rsyslog y debe comenzar con el siglo del dólar ‘$‘.
• Plantillas: Usadas para dar formato a los mensajes de salida o por ejemplo crear nombres de archivos de registro dinámicos en función de unas reglas definidas.
• Canales de salida: Son un nuevo concepto introducido en rsyslog que permiten definir una serie de propiedades específicas para uno o varios registros. Primero se define un canal y luego este es usado para la salida de un selector. La sintaxis de un canal es parecida a:

$canal de salida <nombre>,<nombre-archivo>,<tamaño-máximo>,<comando-tamaño-máximo>

Donde:

- nombre: nombre del canal de salida

- nombre-archivo: nombre del archivo de registro

- tamaño-máximo: tamaño máximo para el archivo de salida

- comando-tamaño-máximo: nos permite ejecutar un comando cuando el archivo haya alcanzado el tamaño máximo. El comando va acompañado de un parámetro separado por un espacio

Para llamar a un canal de salida se usa una sintaxis como por ejemplo

*.* :omfile:$micanal

• Reglas (Selector + Acción): Las reglas definen en gran parte el comportamiento de los mensajes de registros. La sintaxis y sus opciones son las ya estudiadas anteriormente en syslog.

El archivo de configuración rsyslog es complejo y permite una gran variedad de acciones adicionales a syslog, no obstante podremos hacer funcionar un sistema de registro rsyslog, prácticamente con el formato del archivo de configuración syslog.conf

Un ejemplo de rsyslog.conf podría ser:

# /etc/rsyslog.conf Archivo de configuración para rsyslog.
# Podremos encontrar la definición de las reglas por defecto en 
# /etc/rsyslog.d/50-default.conf

#### MODULES ####
$ModLoad imuxsock # Proporciona soporte para el sistema de registro local
$ModLoad imklog # Soporte para el registro del kernel
# Si descomentamos las 2 siguientes líneas estaremos dando soporte al registro
# de log remoto por UDP.
#$ModLoad imudp
#$UDPServerRun 514
# Recepción de registro remoto pero por TCP
#$ModLoad imtcp
#$InputTCPServerRun 514
# Habilitar los "non-kernel facility klog messages"
$KLogPermitNonKernelFacility on

#### GLOBAL DIRECTIVES ####
#
# Usar el formato tradicional de timestamp.
# Para habilitar los timestamp de gran precisión, descomenta la siguiente línea.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
# Filtrar los mensajes duplicados
$RepeatedMsgReduction on
#
# Setear los permisos por defecto para todos los archivos de registro.
#
$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup syslog
#
# Directorio de trabajo para las colas rsyslog
#
$WorkDirectory /var/spool/rsyslog
#
# Incluir los archivos de configuración de /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

Journal

Desde la incorporación del sistema de inicialización systemd en las principales distribuciones de Linux como Red Hat y CentOS 7 y a las que le seguirán Debian, Ubuntu y derivadas, no es necesario el sistema de registro syslog, ya que systemd incorpora su propio sistema de registro llamado journal, aún así en algunas distribuciones de Linux coexisten ambos sistemas de registros, algo que es compatible y veremos a continuación.

journal recopila una serie de mensajes a partir de una serie de fuentes como:

• Los mensajes del kernel vía Kmsg
• Los mensajes básicos de syslog proporcionados por las llamadas de la librería libc de syslog
• Mensajes del sistema estructurados, proporcionados por la API nativa de journal
• Mensajes que provienen de la salida estándar (stdout) y salida de error (stderr) de los diferentes servicios
• Registros de auditorias entregados mediante el subsistema de auditoría.

Por defecto el registro de journal es volatil, es decir perderemos los datos una vez el sistema haya sido reiniciado. Este aspecto de jounal así como muchos otros pueden ser configurables desde sus archivos de configuración.

Configurando Journal

Journal es implementado mediante la unidad systemd-journald.service.

Los archivos de configuración de journal son leídos en el siguiente orden de preferencia: /etc/systemd/journald.conf, /etc/systemd/journald.conf.d/.conf, /run/systemd/journald.conf.d/.conf y /usr/lib/systemd/journald.conf.d/*.conf. Los parámetros y opciones que configuremos en estos archivos serán los que determinen el funcionamiento de systemd-journald.service.

Cuando se instala journald, por defecto sus paquetes y archivos se instalan sobre /usr/lib/systemd pero serán los archivos de /etc/ los que use el administrador del sistema para sobreescribir los del paquete de origen, es decir, estos tienen preferencia sobre el resto. Los archivos de estos directorios (incluidos los de /run/systemd/) están ordenados por orden alfabético por lo que si una misma opción con diferente valor es indicada en diferentes archivos, será el valor del último archivo el que tome journald. Se recomienda (al igual que en muchos archivos de configuración *.conf.d de Linux) prefijar los nombres de los archivos con dos dígitos y un guión para mantener de forma mas sencilla el orden de los archivos de configuración, algo como 20-archivo.conf. Para deshabilitar un archivo de configuración, basta con que el administrador del sistema cree un enlace simbólico hacia /dev/null con el nombre del archivo a deshabilitar en el directorio /etc/systemd/journald/

Opciones para la configuración de journald

Opciones de disco:

• storage: El valor por defecto para esta opción en la mayoría de las distribuciones es ‘auto‘ que provocará que el log sea guardado de forma no persistente en /run/systemd/journal. Podremos cambiar este comportamiento con la opción ‘persistent‘ que hará que el registro se guarde de forma persistente en /var/log/journal/. No obstante si este directorio no existe está opción quedará invalidada y el registro continuará guardándose de forma no persistente en /run/systemd/journal. Aun existiendo el directorio /var/log/journal/ podemos hacer que los registros sean volatiles con la opción ‘volatile‘ o incluso no guardarlos con ‘none‘.
• compress: Esta opción nos permitirá comprimir los registros. Es una característica por defecto de journal y es por ello que journal utiliza su propia herramienta de visualización (descomprimidos en tiempo real) para ver los registros.
• RateLimitBurst y RateLimitInterval: Estas opciones permiten definir el número máximo de mensajes a guardar de cada servicio en un intervalo de tiempo dado (respectivamente). En caso de que el número de mensajes sobrepase el límite, estos no serán guardados pero podremos ver el número de mensajes perdidos mediante un registro automático, algo que nos permitirá ajustar mejor el número de mensajes por intervalo de tiempo. Si indicamos los valores 0 para estas opciones estaremos eliminando el límite de mensajes por intervalo de tiempo.
• SystemMaxUse, SystemKeepFree y SystemMaxFileSize: Definirán en gran medida el uso del disco destinado a el almacenamiento de registros del sistema.
• RuntimeMaxUse, RuntimeKeepFree y RuntimeMaxFileSize: Son idénticos a los anteriores pero cuando se está usando un registro volatil. Es decir afecta al uso de la memoria RAM.

Rotación y sincronización de registro:

• MaxFileSec: Definir un tamaño para realizar una rotación del archivo de registro
• MaxRetentionSec: Tiempo máximo de almacenamiento para archivos de registros antiguos
• SyncIntervalSec: Tiempo de espera antes de sincronizar los archivos de registro con el disco. Por defecto 5 min y solo se aplicará a las prioridades debug, info, notice, warning y err

Compatibilidad con syslog y wall:

• Si tenemos activado syslog y wall podremos redirigir los mensajes a estos demonios con opciones como ForwardToSyslog (reenvía a syslog), ForwardToKMsg, ForwardToConsole (reenvía a la consola principal) y ForwardToWall (reenvía a la consola de todos los usuarios logueados en el sistema), y además controlar los mensajes por nivel con MaxLevelStore, MaxLevelSyslog, MaxLevelKMsg, MaxLevelConsole, MaxLevelWall.

Nota: La compatibilidad con syslog se proporciona a través del socket /run/systemd/journal/syslog por donde pasan todos los mensajes. Tendremos que asociar syslog a este socket y no a /var/log.

Visualizando los logs

Cuando usamos un sistema de registro como syslog, rsyslog o syslog-ng, acostumbrábamos a visualizar el contenido de los registros con herramientas como cat, head, tail, more o less, esto es porque el contenido es guardado en texto plano. Esto ha cambiado con journal. Como comentábamos anteriormente journal guarda sus registro en formato comprimido por lo que necesitaremos usar la herramienta que el mismo sistema de registro nos proporciona, llamada journalctl. Para invocar jounalctl deberemos de contar en la mayoría de los casos con un usuario con privilegios, ya sea perteneciendo a un grupo específico del sistema o con permisos a través de sudo.

Para visualizar todos los registros del sistema ordenados por fecha bastará con invocar a journalctl sin parámetro alguno. Journalctl cuenta con un sistema de filtrado por campos que nos permitirá ajustar mucho mejor la salida para dar caza a registros concretos. Para acceder a estos ‘campos’ utilizaremos algunas de las siguientes opciones.

• Mostrar los mensajes del arranque actual:

journalctl -b

journalctl -b 0

• Mostrar los mensajes del arranque anterior o incluso del anterior al anterior (y sucesivos):

journalctl -b -1

journalctl -b -2
...

• Mostrar los mensajes de error de un arranque anterior:

journalctl -b -p err

• Mostrar los mensajes de un binario concreto:

journalctl /usr/bin/<binario>

• Mostrar los mensajes de un proceso concreto:

journalctl _PID=<proceso>

• Mostrar todos los mensajes para un servicio concreto:

journalctl _SYSTEMD_UNIT=httpd.service

• Mostrar todos los mensajes de unidades que contengan un patrón específico:

journalctl -u <patrón>

• Ver el búfer circular del kernel:

journalctl _TRANSPORT=kernel

• Usar operadores AND (espacio) y OR (+) para filtrar mensajes:

journalctl _SYSTEMD_UNIT=httpd.service + -u http _PID=3412

• Mostrar registros para un dispositivo específico:

journalctl /dev/sdb

• Podremos especificar un intervalo de tiempo con los parámetros -since y -until. El intervalo puede ser especificado de manera explicita para días como ‘yesterday‘, ‘today‘ o ‘tomorrow‘, o indicando la fecha mediante el formato “YYYY-MM-DD hh:mm:ss“

Ejecutar tareas automáticamente en el futuro

Con Linux podremos crear tareas para que sean ejecutadas en un futuro. Para ello contamos con la utilidad cron, estrechamente relacionada con at. La diferencia entre ambas es que cron nos permite ejecutar tareas de forma periódicas mientras at es utilizada para ejecutar un comando en un momento dado de forma exclusiva. Las tareas cron relacionadas con la administración del sistema suelen ejecutarse en horarios en los que la mayoría de ordenadores clientes o de escritorio suelen estar apagado. Esto se programa así para evitar una sobrecarga en el sistema a horas en los que quizás el usuario este trabajando. En servidores donde el apagado total del sistema es infrecuente este mecanismo funciona de forma efectiva, pero para solucionar el problema con los ordenadores de escritorio se implementó anacron, el cual se asegura de que las tareas de sistema programas por cron sean ejecutadas eficientemente cuando el ordenador del cliente es encendido, mas concretamente cuando el demonio anacron es ejecutado.

Cron

El demonio cron parece que está ‘dormido‘ en nuestro sistema y que solo es ‘despertado‘ en un momento concreto especificado en algunos de sus archivos de configuración para ejecutar una tarea concreta y luego volver a su estado de ‘descanso‘. Pero lo que en realidad hace cron es comprobar cada minuto los archivos de los directorios /var/spool/cron y /etc/cron.d/ además del archivo /etc/crontab, ejecutando los comandos especificados en estos archivos, siempre y cuando la hora de comprobación coincida con alguna de las que posee las tareas configuradas.

Existen dos tipos de tareas cron: las tareas cron del sistema y tareas del usuario. Las tareas cron del sistema se ejecutan como root y por lo general llevan a cabo tareas de mantenimiento del sistema, como por ejemplo eliminar antiguos archivos temporales del directorio /tmp, rotación de archivos de registro, etc. En cambio las tareas cron del usuario ejecutan ciertos programas que el usuario quiere ejecutar de forma regular. Es posible crear tareas de usuario que sean ejecutadas por root, por ejemplo si fuese necesario ejecutar ciertos comandos en momentos no contemplados por las tareas del sistema.

Advertencia: Las tareas cron se ejecutan de forma automática y sin supervisión, por lo que no se recomienda ejecutar programas o scripts interactivos.

Formato para la definición de tareas cron

Existen diferentes formas de crear una tarea cron, pero por lo general el formato de la tarea tendrá la siguiente sintaxis.

min  hora  diadelmes  mes  diadelasemana  [usuario]  /ruta/al/script

• Minutos: 0 – 59
• Horas: 0 – 23
• Día del mes: 1 – 31
• Mes: 1 – 12 o Ene, Feb, Mar, etc.
• Día de la semana: 0 – 7 (tanto el 0 como el 7 pertenecen al Domingo, por lo que podríamos concretar con 1 – 7) o Lun, Mar, Mie, etc.
• Usuario: Las tareas cron de usuarios no incluyen la especificación del nombre de usuario en esta línea. No obstante suele ser corriente encontrarlo en tareas cron del sistema, donde el encargado de dicha ejecución es root.
• Programa: Es el binario o script que vamos a ejectar el cual realizará las funciones pertinentes. Puede contener varios comandos o cadenas de ellos acompañado de directorios como en el caso de tareas cron de sistema.

Una vez que conocemos la sintaxis para definir una tarea, será necesario conocer algunos ‘trucos’ para especificar rangos o momentos concretos, por ejemplo:

• Un asterisco ‘*‘ coincide con todos los valores posibles.

30 * * * 1 root /usr/sbin/<programa>

Esta tarea se ejecutará todos los días Lunes de todos los meses del año en el minuto 30 de cada hora.

• Un asterisco ‘*‘ y una barra inclinada ‘/‘ precediendo a un dato indica un valor escalonado

*/30 * * * 1 root /usr/sbin/<programa>

Esta tarea se ejecutará cada 30 minutos. La diferencia con la anterior es que esta se ejecutará 2 veces en una hora, mientras que la anterior solo cuando sea el minuto 30′ de cualquier hora.

• Una lista separada por comas (0,6,12,18) coincide con cualquiera de los valores especificados

30 0,4,8,12,16,20 * * 1 root /usr/sbin/<script>

Ejecutará en el minuto 30′ de las 12, 4 y 8 AM y 12,16,20 PM la tarea especificada.

• Dos valores separados por un guión ‘-‘ indican un rango en el que los valores de los extremos son incluidos.

15 16-22 * * * /home/nebul4ck/bin/script

Se ejecutará la tarea del usuario nebul4ck los minutos 15′ de las horas 16,17,18,29,20,21 y 22

Crear tareas cron del sistema

Una vez que conocemos los archivos de configuración de cron y el formato para definir una tarea, vamos a aprender a programar una tarea cron del sistema.

Lo primero es saber que el archivo /etc/crontab es el encargado de las tareas del sistema, suele comenzar con algunas líneas donde se definen variables como $PATH y $MAILTO y a continuación una serie de líneas que invocarán determinadas tareas. La mayoría de las distribuciones incluyen tareas cron del sistema que se ejecutan cada hora (hourly), día(daily), semana(weekly) y mes(monthly). La forma en la que Linux ejecuta estas tareas se simplifica enormemente con el uso de comandos como run-parts, cronloop o una utilidad similar y unos directorios en los que se encuentran los script a ejecutar. Lo que hacen estos comandos es ordenar que se ejecuten todos los scripts que se encuentren dentro del directorio especificado, de esta manera no tendremos que crear una línea por cada script/tarea a ejecutar.

17 * * * * root cd / && run-parts --report /etc/cron.hourly

Esta línea llegada las 17:00 se desplazará como root al directorio raíz y desde allí ejecutará el comando run-parts el cual a su vez ejecutará todos los scripts que se encuentren dentro del directorio /etc/cron.hourly

Entonces si sabemos que todos los script, por ejemplo bajo el directorio /etc/cron.daily o /etc/cron.d/daily van a ser ejecutados diariamente, podremos crear nuestro propio script y copiarlo dentro de este directorio, así nos aseguraremos* que root ejecutará la tarea de forma diaria.

(*) En realidad seguro no hay nada, pues dependiendo de la hora de ejecución puede que la tarea se ejecute o no, ya que muchos sistemas, sobre todos los de escritorio suelen apagarse por las noches, así que quizás una tarea programada para ejecutarse diariamente a las 5:00 AM nunca llegue a ejecutarse si el ordenador a esta hora siempre esta apagado. Para solucionar esto se implemento Anacron, una utilidad que veremos en la próxima sección.

Advertencia: El propietario de los directorios que almacenen tareas cron del sistema debe ser root y solo este debe de tener permisos para escribir en dichos directorios.

Importante: Antes de enviar un script como tarea cron se recomienda encarecidamente que sea probado, de lo contrario puede que verse ante un sistema no funcional tras la ejecución de este.

Crear tareas cron de usuario

En la sección anterior hemos aprendido a crear tareas cron del sistema y para ello hemos hecho uso del archivo /etc/crontab. Tenemos que dejar claro que cuando nos refiramos al archivo de configuración de tareas cron del sistema deberemos de indicar la ruta completa ya que existe un programa con el mismo nombre ‘crontab‘ con el que podremos mantener los archivos de configuración de tareas cron del usuario y además también nos podemos referir como crontab a los archivos de configuración de tareas cron de los usuarios, para el que deberemos entonces de nombrar la ruta completa (al igual que con el archivo de configuración de tareas cron del sistema) cuyo path será alguno de estos: /var/spool/cron/, /var/spool/cron/crontabs o /var/spool/crontabs y recibirá el nombre del usuario.

Dicho esto vamos a crear una tarea cron de usuario, que ya sabemos entonces que deberemos de utilizar la herramienta crontab cuya sintaxis es la siguiente:

crontab [-u usuario] [-l | -e | -r] [archivo]

Si no proporcionamos el parámetro -u <usuario> modificaremos el archivo de configuración de tareas de usuario del usuario desde el que es invocado el comando. De lo contrario si queremos modificar el archivo cron de otro usuario, algo que deberemos de hacer como root, tendremos que especificar la opción -u. Si queremos listar el contenido del archivo cron del usuario empleamos -l, -r elimina y -e edita el archivo. Para editar se empleará un editor de texto predeterminado que podremos modificar cambiando el valor de la variable $VISUAL o $EDITOR.

Advertencia: Si creamos una tarea con ‘$ crontab -e‘ tendremos que tener en cuenta que los archivos cron de usuario serán creado automáticamente bajo los directorios /var/spool/cron, /var/spool/crontabs o /var/spool/cron/tabs con el nombre del usuario y que se recomienda no volver a modificar a mano si no con el propio comando crontab.

La forma anterior es una manera rápida de editar el archivo cron del usuario creando así tareas cron. Pero también podremos crear nosotros mismos un archivo en nuestro directorio home (por ejemplo) con el mismos formato que tiene el archivo /etc/crontab, es decir un comando precedido de los cinco campos de dígitos o comodines para indicar el momento de ejecución de la tarea y si es necesario, las primeras líneas del archivo en las que se definían ciertas variables de entorno. Una vez creado el archivo se lo pasaremos como argumento al comando crontab.

$ crontab -u <usuario> mi-archivo-cron

Nota: Recordar que si estamos instalando una tarea para nuestro propio usuario con el que además estamos logueado en el sistema, no será necesario el parámetro -u

Restringir el acceso a cron

El acceso al recurso cron se puede restringir de varias maneras:

• Permisos de ejecución: Podremos modificar los permisos de ejecución para cron y crontab, de manera que solo puedan ser ejecutados por usuarios pertenecientes a un determinado grupo como por ejemplo cron.
• Lista de usuarios permitidos: El archivo /etc/cron.allow contiene una lista de los usuarios a los que se permite el acceso a cron. Si este archivo está presente, sólo podrán utilizar cron aquellos usuarios cuyos nombres figuren en el archivo.
• Lista de usuarios rechazados: El archivo /etc/cron.deny contiene una lista de usuarios que tienen denegado el acceso a cron.

Anacron

En sistemas que se apagan con frecuencia, como portátiles o PC personales, es frecuente que las tareas cron del sistema no se ejecuten nunca, sobre todo aquellas que son ejecutadas a altas horas de la madrugada. Un comportamiento como este (no ejecutarse dichas tareas) podría derivar en problemas graves como el llenado de una partición a causa del no-borrado de archivos bajo /tmp, saturar los archivos de registro, u otros problemas. Por ello se implementó el uso de anacron, concebido como suplemento de cron, con el fin de asegurar que las tareas de mantenimiento regular se ejecuten a intervalos razonables. De hecho anacron se utiliza en algunas distribuciones para ejecutar tareas cron, por lo que el efecto es tomar el control de las obligaciones de cron*.

(*) Anacron mide sus intervalos de tiempo en días por lo que no servirá para ejecutar tareas cron que se ejecuten con intervalos de horas. Por consiguiente no deberíamos de eliminar las tareas cron de sistema.

Anacron guarda un registro de los programas que se deberían de ejecutar y la frecuencia en días con la que deberían de hacerlo. Cuando se ejecuta, anacron comprueba en su configuración (/etc/anacrontab) que programas deben de ejecutarse y determina si ha transcurrido un periodo superior al intervalo de ejecución. Si el periodo ha sido superado, anacron ejecutará el programa. De este modo se podrán reconfigurar las tareas cron normales de su sistema como tareas anacron con la seguridad de que se ejecutarán incluso en sistemas que se apagan con regularidad durante largos periodos de tiempo.

Configuración de anacron

El archivo de configuración de anacron consta de tres tipos de líneas: líneas de comentarios (comienzan con #), asignaciones de variables de entorno (SHELL=/bin/bash) y líneas de definición de tareas, las cuales están formadas por cuatro campos:

periodo retardo identificador comando

• El periodo es la frecuencia en días con la que se debe de ejecutar el comando.
• El retardo es el periodo en minutos que transcurre entre el inicio de anacron y el momento en que se ejecuta el comando. Esta función está pensada para evitar que el sistema de sobrecargue si anacron tiene pendiente de ejecutar muchas tareas a su inicio.
• El identificador identifica al comando.
• El comando es el programa a ejecutar seguido opcionalmente de los parámetros que pudiera recibir.

Nota: La variable PATH es particularmente importante si algún script invoca programas sin especificar sus rutas completas.

Un archivo anacron podría tener el siguiente aspecto:

# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root
# These replace cron's entries
1 5 cron.daily run-parts --report /etc/cron.daily
7 10 cron.weekly run-parts --report /etc/cron.weekly
@monthly 15 cron.monthly run-parts --report /etc/cron.monthly

Invocar a anacron

Para que todo lo anterior funcione obviamente hay que invocar a anacron que suele hacerse de dos maneras:

• Mediante un script de inicio: Puede crear un sencillo script de inicio SysV que ejecute anacron desde su modo de ejecución normal o colocar la llamada a anacron en un script de inicio local como /etc/rc.d/rc.local (Fedora y Red Hat) o /etc/boot.d/boot.local (Suse). Esto es preferible en sistemas que se apagan e inician con frecuencia, como portátiles o sistemas de escritorio.
• Mediante una tarea cron en /etc/crontab que remplace a las entradas normales de las tareas cron de su sistema. Esto puede presentar los mismos problemas que cron, es decir, que el PC este apagado cuando sea el momento de ejecutar anacron, pero podremos sino  invocar a anacron mas de una vez al día, por ejemplo, una vez cada seis horas asegurándonos que se ejecutará durante una típica jornada diaria de ocho horas.

Importante: Independientemente de como ejecute anacron, asegúrese de desactivar de cron cualquier tarea que sea controlada ahora por anacron, de lo contrario esta tarea será ejecutada dos veces en el caso de que el PC se encuentre encendido cuando cron ejecute sus tareas.

At

El programa at nos permite ejecutar una sola vez un único comando en un momento futuro determinado, útil cuando el uso de cron o anacron suponen un despliegue excesivo. El comando at depende del demonio atd por lo que tendremos que asegurarnos de que atd está ejecutándose en segundo plano. Dependiendo del sistema de inicialización que tengamos podremos ejecutarlo de una u otra manera, pero seguramente dependa de un script de inicio que tendremos que ajustar o iniciar con nuestro runlevel o target por defecto.

En su uso normal at recibe como única opción una hora, aunque como casi siempre este comportamiento es configurable mediante otras opciones. La hora puede adoptar varias formas:

• Una hora del día pasada con el formato HH:MM donde ademas podemos añadirle AM o PM para utilizar el formato de 12 horas. Si la hora marcada ya ha pasado, el comando se ejecutará al día siguiente.
• Las siguientes palabras pueden ser utilizada para ejecutar un comando a las 12 PM ‘noon‘, a las 00:00 ‘midnight‘, a las 16:00 o 04:00 PM ‘teatime‘, el día de hoy ‘today‘ o el día de mañana ‘tomorrow‘
• Un determinado día: Si especificamos un día querrá decir que estamos planificando una tarea para ser ejecutada con mas de 24 horas de antelación. Deberemos de añadir el día tras la hora tal que así; ‘hh:mm MMDDYY‘, ‘hh:mm MM/DD/YY‘ o ‘hh:mm DD.MM.YY‘
• Concretar un futuro específico: Por ejemplo, queremos ejecutar una tarea dentro de 3 horas, independientemente de la hora actual. Usaremos la palabra now (ahora) y le sumamos las horas que deberán de transcurrir: ‘now + 3‘. Igualmente podemos indicar que a partir de ahora (now) espere por ejemplo hasta el próximo Sábado y reinicie ‘at now sat reboot‘

Cuando ejecutemos el comando at con su hora (no importa el formato utilizado), el programa responderá con su propio prompt

 at >

Podremos utilizar el prompt de at como si de bash se tratara, es decir escribiremos los comandos que queremos ejecutar, con la diferencia que no serán ejecutados en el momento si no cuando sea la hora especificada. Una vez hayamos terminado de escribir comandos finalizaremos con la combinación de teclas Control+D. Podremos realizar la misma función pero pasando un archivo con los comandos en vez de escribirlos en el prompt. Un ejemplo de esto podría ser:

at -f comandos teatime

Algunos programas que ofrecen soporte a at son:

• atq: Enumera las tareas pendientes. Es igual que at -l
• atrm: Elimina una tarea de la cola. Es igual que at -d
• batch: Interesante en equipos que suelen tener indices de carga elevados. batch funciona de modo muy similar a at, pero solo ejecuta las tareas cuando el nivel de carga del sistema baja de 0,8. Igual a at -b

Restringir el acceso a at

Podemos implementar restricciones en el uso de at al igual que hacíamos con cron. Los archivos /etc/at.allow y /etc/at.deny funcional de manera análoga a los archivos de restricciones de cron. Si ninguno de los 2 archivos existe solo root podrá ejecutar at. La lista de usuarios permitido concederá derecho de ejecución de at a aquellos usuarios cuyo nombre aparezca en la lista y de la misma forma serán denegados aquellos que estén en la lista de usuarios denegados (/etc/at.deny)

Comandos Capítulo 7

• Comandos para crear y eliminar usuarios y grupos
• Comandos para modificar cuentas de usuarios y grupos
• Comandos para obtener información sobre cuentas de usuarios y grupos
• Comando para listar las variables de entorno: env
• Comandos relacionados con el registro del sistema y los logfiles
• Comandos para la programación de tareas

Curso LPIC-1 400 Capítulo 7 por nebul4ck se distribuye bajo una Licencia Creative Commons Atribución-NoComercial-CompartirIgual 4.0 Internacional.

Puede contratar ExtreHost para temas profesionales con sus servidores. No lo dude, contáctenos.

Whatsapp