#4sysadmins

Inicio » LPIC-1 Capítulo 7

LPIC-1 Capítulo 7

EN ESTE CAPÍTULO SE ABARCAN LOS SIGUIENTES OBJETIVOS DEL EXAMEN:

  • 107.1: Administrar cuentas de usuarios y grupos, y los archivos del sistema relacionados (5)
  • 108.2: El registro del sistema (3)
  • 107.2: Automatizar las tareas de administración del sistema mediante la programación de tareas (4)

 

Administrar el sistema

Sobre usuarios y grupos

Usuarios

Linux nos permite dar casi cualquier nombre a una cuenta de usuario. Las reglas mas “liberales” sobre nombres de usuario nos permiten usar caracteres en minúsculas y mayúsculas (para Linux, Andrea, andrEa y andrea serán cuentas diferentes)  , tener una longitud de hasta 32 caracteres y usar algunos caracteres especiales como el guión bajo (_), el punto (.) o el signo del dólar ($) al final del nombre. Se recomienda que las cuentas de usuarios comiencen con una letra, aunque se pueden emplear números incluso caracteres de puntuación como el ‘.‘ y el ‘_‘. Algunas utilidades usadas para la creación de cuentas de usuarios son mas restrictivas, por lo que nos podemos encontrar problemas a la hora de crear un nombre con espacios, mas de 8 caracteres o incluso que no nos permitan comenzar el nombre con caracteres especiales, números o incluso usar letras mayúsculas.

Nota: Si empleamos como primer caracter para el nombre de la cuenta el ‘.’ (punto) tendremos que tener en cuenta que el directorio home del usuario aparecerá como oculto bajo /home

Cada usuario que creemos en el sistema tendrá una línea que lo identifique en el archivo /etc/passwd y su correspondiente contraseña encriptada más algunas características de la cuenta en el archivo /etc/shadow.

Podemos ver los usuarios logueados en el sistema a través del comando finger.

Nota: El comando finger está en desuso por su alto riesgo de inseguridad. Existen otros comandos como who o w con los que podemos ver los usuarios logueados en el sistema

 

Sobre el archivo /etc/passwd

El formato de /etc/passwd es el siguiente: usuario:x:UID:GID:nombrecompleto:directoriohome:consola

nebul4ck:x:1000:1000:Gonzalo Sánchez,695-235-526:/home/nebul4ck:/bin/bash

El segundo campo ‘x‘ indica que la contraseña no se almacena en este archivo, si no que se encuentra encriptada en /etc/shadow. Los campos tercero y cuarto indican el UID (ID de usuario) y GID (ID del grupo principal del usuario) del usuario. El quinto campo es utilizado para proveer información acerca del usuario, como su nombre y teléfono en nuestra línea de ejemplo. Este campo no es un requisito para la creación de un usuario, es  por ello que con frecuencia lo encontremos vacío. Si un campo no tiene valor, aún así deberá de ser definido por dos puntos ‘:‘ tal que así:

nebul4ck:x:1000:1000::/home/nebul4ck:/bin/bash

Por último el sexto campo, cuyo objetivo es ejecutar un comando. La mayoría de las veces se utiliza este campo con dos objetivos principales:

  • Ejecutar un shell para el usuario, bash en nuestro ejemplo
  • Negar el acceso de sesión a un usuario. Esto es utilizado normalmente para cuentas del sistema a las que no se le tiene permitido iniciar sesión como por ejemplo ‘daemon‘, ‘man‘, ‘nobody‘… Esto se suele conseguir de dos formas distintas. Si despliegas el contenido del archivo /etc/passwd podrás observar que existen líneas que poseen como sexto campo el comando /usr/sbin/nologin mientras que otros (hablamos de valores diferentes a una consola) tienen como valor /bin/false. Ambos niegan el acceso a la cuenta, la diferencia es que el comando nologin en realidad ‘te permite acceder a la cuenta‘ pero acto seguido te muestra un mensaje diciendo que el usuario no tiene permitido el acceso y te expulsa. Esta opción suele ser la preferida por el hecho de mostrar como poco un mensaje. /bin/false es un binario que finaliza directamente devolviendo el código de retorno ‘1’, por lo que tras escribir la contraseña lo único que notaremos será un pequeño parpadeo en la pantalla y de nuevo estaremos ante el prompt pidiéndonos unas credenciales o bien en el prompt del usuario en el que nos encontrábamos antes de ejecutar la orden ‘su – nuevousuario‘, estudiaremos los comandos su y sudo en otra sección de este mismo capítulo.

 

Sobre el uso de UID y GID

Todos los archivos y directorio que cree el usuario, así como cualquier programa ejecutado por él, se asociarán a su UID y GID.

Algunas distribuciones dan como primer UID y GID el identificador 1000 y otras el 500. Si tenemos un usuario con UID y GID 1000 unicamente y creamos otro, este tomará por defecto el UID y GID 1001 y así secuencialmente, a menos que indiquemos nosotros mismos el UID y GID mediante opciones de la utilidad de creación de cuentas, al igual que usando estas, podremos seleccionar la consola, directorio home principal y nombre o comentario que nosotros decidamos. Linux sigue el rastro de los usuarios y grupos por sus respectivos UID y GID en vez de por sus nombres, por lo que accederá a /etc/passwd o /etc/group (veremos el formato de este archivo en el apartado de grupos) para localizar el número asociado al nombre. El primer centenar de ID de usuarios y grupos (0-99) suelen reservarse para uso del sistema, como por ejemplo para cuentas como root (0), daemon (1), bin (2), mail (8), etc..

Importante: Los ID de cuentas del sistema suelen variar de una distribución a otra, menos el UID y GID de root, que siempre será 0. Deberemos de prestar especial atención a esto, ya que un intruso podría crear una cuenta con UID 0 para obtener privilegios de root. Si detecta una cuenta sospechosa en su archivo /etc/passwd con un UID 0, es probable que su sistema esté comprometido.

Se pueden crear varios cuentas de usuario y grupos con los mismos UID y GID, siendo estas, cuentas totalmente diferentes, por lo que existirá una entrada en /etc/passwd y /etc/group para cada una de ellas, con diferentes contraseñas, directorios principales, etc… No obstante, Linux tratará a estas cuentas de la misma manera en lo referente a los permisos de archivos, ya que estos son aplicados a los UID y GID, por lo que debería de evitar crear varios usuarios o grupos de compartan ID.

Reutilizar un número ID puede provocar problemas si no elimina los archivos del antiguo usuario ya que el nuevo usuario se convertirá en el propietario de los archivos del anterior.

Los límites de numeración de cuentas se definen en el archivo /etc/login.defs con las entradas UID_MIN y UID_MAX

 

Sobre el archivo /etc/shadow

Como comentábamos anteriormente el archivo /etc/shadow contiene la contraseña encriptada del usuario y algunos otros parámetros configurables con la utilidad chage, passwd, useradd o usermod que veremos en apartados posteriores.

Vamos a estudiar este archivo mediante una línea de ejemplo:

nebul4ck:$8$km3ZmQpk9mJLlq3bVGU6ssPwa:15988:0:-1:7:-1:-1:
  • Nombre de usuario: El nombre de usuario enlaza las entradas de este archivo con las de /etc/passwd.
  • Contraseña: Formato encriptado. Un asterisco ‘*‘ o signo de admiración ‘!‘ al comienzo de este campo denota una cuenta sin contraseña, por lo que esta se encontrará bloqueada. Si eliminamos este signo se desbloqueará la cuenta y se restaurará la contraseña original.
  • Ultimo cambio de contraseña: Fecha en la que se realizó el último cambio de contraseña. Se identifica por el número de días transcurridos desde el 1 de Enero de 1970, 15988 en nuestro ejemplo.
  • Días que han de pasar para permitir un cambio de contraseña: Es el número de días que han de pasar para que se pueda cambiar la contraseña. En nuestro ejemplo un 0, que indica que cualquier día será bueno para cambiar la contraseña e incluso cambiarla varias veces al día.
  • Periodo de días tras el cual habrá que modificar la contraseña: Es el número de días que deberán de pasar desde que se cambió la contraseña hasta que se requiera un nuevo cambio. En nuestro ejemplo se indica un -1 (equivalente a 99999) que normalmente indica que se ha desactivado esta función.
  • Avisar con antelación de la necesidad de cambiar la contraseña: En nuestro ejemplo se nos avisará 7 días antes de que nuestra contraseña nos caduque. 7 suele ser un número muy común en este campo, indica una semana antes.
  • Días que pasarán entre la caducidad de la contraseña y la desactivación de la cuenta:  Cuando una cuenta se desactiva (bloquea) por que su contraseña a caducado el usuario no podrá usar su cuenta, por ello se ofrece un plazo en días en los cuales el usuario podrá cambiar su contraseña justo después de acceder a la cuenta (siempre que se encuentre dentro del plazo), de lo contrarío la contraseña anterior será eliminada y será el administrador quien tenga que volver a activar dicha cuenta.
  • Fecha de caducidad: Esta fecha se expresa de la misma manera que la fecha del último cambio de contraseña es decir los días transcurridos desde el 1 de Enero de 1970 hasta el día en que la cuenta caducará.
  • Indicador especial: Este campo no suele usarse por lo que en nuestro ejemplo lo tenemos vacío
nombre:contraseña:último-cambio:cambiar-pass-no-antes-de:cambiar-contraseña:días-de-aviso:periodo-de-gracia:caducidad:indicador

Nota: Cuando hablemos sobre la modificaciones de las cuentas de usuario veremos que es posible modificarlas a través de los archivos /etc/passwd y /etc/shadow, pero se recomienda que las modificaciones se hagan con las utilidades destinadas a tal fin como son passwd, chage, usermod,etc…

Advertencia: El archivo /etc/shadow se suele almacenar con permisos mas restrictivos (600) que los usados en /etc/passwd (644) evitando de esta manera que los usuarios distintos a root lean el archivo y obtengan la lista de contraseñas encriptadas.

 

Grupos

Los grupos son medios para organizar colecciones de cuentas. Un grupo puede ser el grupo principal de uno o varios usuarios y además contener a mas usuarios aunque para estos no sea el grupo principal. La pertenencia a los grupos se controla mediante el archivo /etc/group, el cual contiene una lista de grupos y los miembros que pertenecen a cada uno de ellos. Podemos comprobar a que grupos pertenecemos y otras características de la cuenta como los ID de usuario y grupos con el comando id o bien listar todos los grupos a los que pertenecemos con el comando groups. El comando groups no indicará cual es nuestro grupo primario ni los GID, simplemente desplegará una lista con todo aquel grupo del que formamos parte.

Cuando un archivo es creado se le asigna un grupo que será el grupo principal del usuario que ha creado o ejecutado el archivo/directorio o el programa en cuestión. Sin embargo, para ejecutar programas o crear archivos con un grupo distinto al grupo primario del usuario creador, este deberá de ejecutar el comando newgrp para cambiar la pertenencia del grupo principal al nuevo grupo. Para que esto sea posible el usuario debe de pertenecer antes al nuevo grupo o si el nuevo grupo tiene definida una contraseña de grupo esto no será necesario, pero si que el usuario podrá convertirse en miembro temporal del grupo siempre y cuando conozca dicha password que será solicitada tras la ejecución de newgrp.

Nota: En algunas distribuciones no se permite la modificación temporal del grupo principal aún conociendo la password del grupo (este recibirá un mensaje del tipo “access denied“), a menos que previamente el usuario pertenezca al grupo.

Ejemplo de newgrp:

Supongamos que el usuario ‘dante‘ tiene como grupo principal ‘dante‘ y que además pertenece a otros grupos, entre ellos al grupo ‘sistemas‘, y quiere cambiar a este último para que nuevos archivos sean creados con el GID del grupo sistemas y además ejecutar unos programas bajo los permisos asignados al grupo.

$ newgrp sistemas

Una vez ejecutado este comando el nuevo grupo principal para dante será sistemas y los archivos creados se asociarán a este.

Debemos de conocer algunas peculiaridades del uso del comando newgrp:

  • El cambio al nuevo grupo principal es temporal, es decir, al iniciar una nueva sesión o cerrar y abrir una terminal, volveremos a tener nuestro grupo principal por defecto.
  • Cuando ejecutamos newgrp veremos los efectos a la hora de crear archivos o ejecutar programas, pero no si desplegamos el contenido de /etc/passwd o /etc/group para los cuales nuestro grupo principal seguirá siendo el que teníamos por defecto.
  • Si hemos ejecutado newgrp para pasarnos a otro grupo temporalmente y queremos volver a nuestro grupo de origen sin cerrar sesión e iniciar nueva sesión bastará con volver a ejecutar newgrp sin argumento alguno

 

Configurar cuentas de usuario

En esta sección del capítulo vamos a repasar las herramientas con las que podremos crear, modificar y eliminar cuentas de usuario. Linux posee herramientas GUI para tal fin, pero las que vamos a estudiar son las que están basada en modo texto, ya que son mas flexibles y por ello nos permitirán realizar una configuración mas detallada. Como veremos en las próximas secciones las cuentas de usuarios y grupos pueden ser creados mediante comandos destinados a tal fin, o bien editando una serie de archivos de forma manual. En la sección de creación de cuentas de usuarios y grupos hablaremos sobre las herramientas destinadas a estas tareas ya que son la forma conveniente de hacerlo. No obstante en la sección “Modificando cuentas de usuarios y grupos directamente desde archivos de configuración” estudiaremos como hacerlo de tal forma.

 

Creando cuentas de usuarios

Cuando creamos una cuenta de usuario en el sistema realmente lo que se está haciendo de forma automática es lo siguiente:

  • Crear una línea de identificación y especificación de ciertas características de la cuenta en el archivo /etc/passwd
  • Crear una contraseña con el comando passwd. Esto suele hacerse de forma manual (por seguridad) tras crear la cuenta y lo que hace es añadir una contraseña encriptada en el archivo /etc/shadow
  • Se crea una línea en /etc/group para identificar al grupo primario del usuario
  • Se crea un directorio /home/<usuario> en el que se copian una serie de archivos de configuración de perfil desde el directorio /etc/skel

Todo lo automatizado o configurable del comando destinado a crear un usuario useradd, es definido en el archivo de configuración /etc/default/useradd y por otra parte el comportamiento de una cuenta viene determinado por /etc/login.defs por lo que ambos ficheros son de importancia cuando se crea o administra una cuenta de usuario. Veremos que existen en algunas distribuciones una interfaz sencilla llamadas adduser la cual se configura en otros archivos independientes.

Para crear cuentas de usuarios utilizaremos la utilidad de bajo nivel useradd, para la cual existe en muchas distribuciones (como por ejemplo las derivadas de Debian) una interfaz mas sencilla denominada adduser que automáticamente selecciona valores basados en la línea de comandos y en el archivo de configuración /etc/adduser.conf,  como por ejemplo el ID de usuario y grupo, la creación de un directorio personal (/home/usuario), ejecución de un script personalizado y algunas otras funcionalidades.

En este caso, aunque la herramienta que abarca el examen es useradd, vamos a estudiar también adduser.

Cuando invocamos a useradd es su forma mas simple, es decir con tan solo el nombre de login de usuario como parámetro no crearemos ningún directorio home, los UID y GID serán definidos por defecto, no asignaremos un shell, ni tampoco añadiremos información complementaria como su nombre o teléfono. Esto no quita que la cuenta tenga unas característica o comportamiento determinado como por ejemplo un directorio mail a utilizar (/var/mail), un valor de variable PATH predeterminado para la cuenta, una umask, valores de UID/GID mínimos y máximos, los intento de login fallidos, el TIMEOUT para el login, método de encriptación para la clave (SHA512 por defecto) cuando esta es creada con el comando passwd, y algunos otros muchos parámetros incluso relacionados con los grupos que son definidos por variables en el archivo /etc/login.defs.

En cambio si utilizamos el comando useradd con parámetros para crear shell o directorio home, este se basará en los valores de unas determinadas variables definidas en el archivo /etc/default/useradd. Podremos ver los valores de estas variables con la opción -D de este comando e incluso modificarlas.

Estudiaremos la sintaxis y opciones de ambos comandos en el apartado de comandos de este mismo capítulo, pero mencionaremos algunos ejemplos para ir familiarizándonos con ellos.

  • Crear un usuario con useradd sin utilizar parámetros y opciones adicionales:
$sudo useradd cursolpi

La línea que se generará en el archivo /etc/passwd tendrá el siguiente aspecto:

cursolpi:x:1007:1007::/home/cursolpi:
  • Crear un usuario prácticamente al detalle utilizando el mismo comando useradd:
sudo useradd -d /home/cursolpi -m -c "Usuario para curso LPIC-1" -e 2015-04-20 -u 1024 -g 1001 -G 1002,104 -s /bin/bash -p norecomendedado cursolpi

Lo que hace este comando es crear con ‘-m‘ el directorio indicado por el parámetro ‘-d‘, con un comentario ‘-c‘, indicando que la cuenta expire ‘-e‘ en una fecha determinada, se asigna un UID y GID específico y además se le hace miembro de otros dos grupos ‘-G‘, utilizará el shell bash y para acceder a su cuenta necesitará su nombre de usuario ‘cursolpi‘ y su contraseña ‘norecomendado‘.

Advertencia: Como medida de seguridad no se recomienda utilizar el parámetro -p <contraseña> desde la línea de comandos. Es preferible crear la cuenta y a continuación utilizar el comando passwd para tal fin

Ahora la nueva línea del archivo /etc/passwd tendrá el siguiente aspecto:

cursolpi:x:1024:1001:Usuario para curso LPIC-1:/home/cursolpi:/bin/bash
  • Crear un usuario con los valores por defectos configurados en /etc/adduser.conf con el comando adduser que desplegará unas líneas que servirán para que interactuemos con la utilidad:

adduser

Tras esto la línea creada para este nuevo usuario en el archivo /etc/passwd tendrá el siguiente aspecto:

dottore:x:1007:1007:Patricio Calamonte,12,666-666-666,:/home/dottore:/bin/bash

Nota: La utilidad adduser nos permite además crear grupos pasándole el parámetro –group, pero mejor utilizar las herramientas destinadas a la creación de grupos.

 

Implementar  contraseñas shadow y crear una o varias contraseñas.

Las distribuciones  actuales traen por defecto la implementación de contraseñas shadow, esto no es mas que una forma de implementar algo mas de seguridad para guardar las contraseñas de nuestros usuarios. En versiones anteriores de distribuciones las contraseñas solían guardarse de forma encriptada en el campo de contraseñas del archivo /etc/passwd. Esto tenía la vulnerabilidad de que cualquier usuario podía leer el archivo y con ello la contraseña encriptada. Si desplegamos el contenido de nuestro archivo /etc/passwd lo mas normal será tener una :x: en el campo de contraseña, esto indica que tenemos implementado contraseñas shadow, con lo que estas serán guardadas en el archivo /etc/shadow el cual solo puede ser leído por root. No obstante podemos implementar o igualmente dejar de utilizar estas contraseñas con los comandos pwconv y pwunconv respectivamente. Si usamos el comando pwconv lo que hará será copiar el campo de contraseña de /etc/passwd en el campo de contraseña de /etc/shadow y añadir el caracter x en dicho campo de /etc/passwd. El uso de pwunconv realizará la acción inversa.

Tengamos o no implementado contraseñas shadow en nuestro sistema, podremos usar el comando passwd o gpasswd para crear contraseñas de cuentas de usuario o grupos respectivamente. Además tenemos la opción de contraseñas para múltiples cuentas de una sola vez, gracias al comando chpasswd que leerá desde su entrada estándar una lista de usuario:contraseña (una por cada línea).

El comando passwd nos permite pasar una serie de opciones. El uso de la opción -p <contraseña> establece una contraseña desde línea de comando algo que es desaconsejado, mejor crear la cuenta y posteriormente asignar una contraseña con ‘$ sudo passwd cursolpi‘. Los usuarios normales pueden utilizar passwd para cambiar sus contraseñas, pero muchos de sus parámetros como -l, -u, -f y -d solo los puede utilizar root. Un usuario corriente podrá cambiar su contraseña simplemente invocando a la utilidad passwd sin ningún parámetro. Como medida de seguridad se le preguntará por la antigua contraseña antes de proceder al cambio. Solo root puede especificar tras la orden passwd el nombre del usuario al que se le va a crear/modificar la contraseña.

Nota: Hay que tener en cuenta a la hora de crear/modificar la contraseña que Linux distingue entre mayúsculas y minúscula.

Como comentábamos anteriormente, cabe la posibilidad de cambiar la contraseña a varios usuarios de una misma vez mediante el comando chpasswd que solo root podrá ejecutar. chpasswd lee de la entrada estándar una serie de líneas cada cual debe estar formada por un usuario y una contraseña (en texto plano) separado por dos puntos ‘:‘ (usuario:contraseña). Será chpasswd a través de PAM quien codifique las contraseñas, aunque este comportamiento puede ser cambiado mediante las opciones -e, -c o -m del comando, algo que no es recomendado. Este comando suele utilizarse en sistemas que contienen multitud de cuentas de usuarios donde realizar la tarea de cambiar contraseñas una a una resulta tedioso.

 

Crear grupos

Al igual que ocurre con la herramienta de creación de cuentas de usuario, para los grupos disponemos de la utilidad de bajo nivel groupadd y la interfaz sencilla para algunas distribuciones addgroup. Lo normal en el momento de crear un grupo es pasar como argumento el propio nombre del grupo al  comando groupadd. El sistema le asignará el GID que cree conveniente, normalmente sumándole 1 al último GID existente.

La interfaz de creación de grupos addgroup funciona de una forma similar, es decir bastará con pasar como argumento el nombre del grupo. Será el archivo /etc/adduser.conf el que predetermine la funcionalidad del comando addgroup.

  • Creando un grupo con groupadd:
$ sudo groupadd -g 1003 -o -r -p vulnerable newbie

Con estos parámetros estaremos actuando de una forma ‘imprudente‘, pero servirá para nombrar algunas opciones importantes. Por ejemplo como ya vimos, pasar el parámetro -p seguido de la password no es lo aconsejable. Ya existe un grupo con el ID 1003 en el sistema, pero con -o le estaremos indicando a la utilidad que cree el grupo ‘newbie‘ compartiendo GID con el grupo ya existente, es decir, existirán 2 grupos con diferentes nombres pero mismo GID. La opción -r indica que será un grupo del sistema, en realidad no es algo muy grave porque simplemente estaremos diciendo que use uno de los GID reservados (normalmente del 0-99) para grupos del sistema, aún así no es aconsejable crear un grupo ‘ordinario‘ de esta forma.

 

Modificar cuentas de usuarios

Tanto las cuentas de usuarios como los grupos pueden ser modificados de varias maneras, bien editando directamente los archivos /etc/passwd, /etc/group, /etc/shadow y /etc/gshadow (forma menos aconsejable) o la modificación mediante herramientas destinadas a tal fin con las que evitaremos errores típicos. Un error al editar el archivo /etc/shadow suele ser el no tener en cuenta los años bisiestos a la hora de contar el número de días que hay desde el 1 de Enero de 1970 hasta el día en el que queremos que una contraseña caduque.

Además de estas dos formas, podremos personalizar los entornos de las cuentas de usuarios a través de sus archivos propios de configuración (~/.profile, ~/.bashrc o ~/.bash_profile) o los archivos de configuración global para cuentas como /etc/profile y /etc/bash.bashrc.

 

Modificando las cuentas de usuarios y grupos directamente desde los archivos de configuración

En apartados anteriores describimos los formatos de los archivos /etc/passwd, /etc/shadow y /etc/group. Conociendo los formatos, podremos modificarlos mediante un editor de texto e indicar en cada uno de sus respectivos campos aquellos valores con los que queramos que las cuentas sean configuradas.

Ala hora de modificar estos archivos directamente habrá que tener en cuenta por ejemplo la creación de una cuenta encriptada, siempre será mejor utilizar la utilidad passwd para tal fin. No es aconsejable editar manualmente de forma general el archivo /etc/shadow ya que contiene campos demasiado específicos que podremos configurar de forma mas segura con herramientas como passwd, useradd o usermod.

Los archivos /etc/passwd y /etc/group son mas fácil de configurar que /etc/shadow, aun así volvemos a hacer hincapié en el uso de herramientas de línea de comandos o GUI. No obstante si hemos decidido finalmente crear o modificar usuarios y grupos desde sus archivos de configuración deberemos de tener en cuenta una serie de aspectos:

  • Hacer una copia de seguridad de los archivos a editar. Si metemos la pata durante la edición, lo mejor será tener una copia del archivo original.
  • En el archivo /etc/passwd deberemos de dejar en blanco el campo de la contraseña para posteriormente generarla con el comando passwd.
  •  Será importante mantener la secuencia de los identificadores de usuarios y grupo en los campos UID y GID. Para ello podremos ver el número ID asignado al último usuario y grupo que creamos y sumarle +1.
  • Una vez generada la línea que identifica a un usuario en el archivo /etc/passwd, guardaremos el archivo, generaremos la clave, y entonces crearemos el directorio /home, en el que copiaremos el contenido del directorio esqueleto (/etc/skel) del cual hablaremos mas adelante. A continuación le cambiaremos los permisos a este mediante el comando chown para que el nuevo usuario pueda acceder al sistema ya que de no tener permisos para acceder a su directorio no se le permitirá el acceso al sistema.
  • Por último antes de que el usuario acceda al sistema deberemos de crear su grupo principal, añadiendo en el archivo /etc/group su correspondiente línea, a menos que hayamos indicado un grupo principal en /etc/passwd ya existente.

 

Modificando las cuentas de usuarios desde la línea de comandos

Las dos herramientas por excelencia para la modificación de cuentas de usuario ya creadas son usermod y chage.

Con el comando usermod podremos modificar características de una cuenta como por ejemplo cambiar el directorio principal de un usuario -d y además mover todo el contenido del antiguo directorio al nuevo -m. Otra de las funciones que nos facilita usermod es el cambio del nombre de acceso del usuario (incluso el nombre de root podrá ser cambiado), esto será posible gracias a su parámetro -l. Si hemos modificado el nombre del login para un usuario, tendremos que tener en cuenta que los nombres de su directorio principal y de existir el de mail no serán automodificados por lo que deberemos de renombrarlos nosotros. Del mismo modo que el comando passwd, nos permite bloquear y desbloquear una cuenta (en realidad bloquea la contraseña) podremos hacerlo con los parámetros -L y -U respectivamente.

Podemos también modificar los valores UID y GID de una cuenta, pero de hacerlo es muy importante saber que cuando cambiamos a un nuevo identificador, los archivos ya existente no cambiarán por lo que es posible que el usuario o incluso los usuarios pertenecientes al grupo dejen de tener acceso a estos. En este caso podremos recurrir a la utilidad find para localizar archivos en el sistema con un determinado UID y GID y ejecutar el comando chown para cambiarlos al nuevo usuario.

$ sudo find / -uid 1001 -gid 1001 -exec chown nebul4ck

Importante: Cambiar las características de una cuenta mientras el usuario está dentro del sistema puede tener consecuencias desagradables, en particular con el uso de los parámetros -d y -m de usermod. Algo a tener en cuenta por ejemplo cuando se cambian opciones como la consola por defecto de un usuario, es que este cambio no tendrá efectos hasta que el usuario salga y vuelva a entrar.

Nota: Con el comando usermod también podremos modificar características de los grupos. Esto lo veremos en la sección de grupos.

Las cuentas de Linux se pueden configurar para que caduquen automáticamente. Será el comando chage el que nos permita modificar ciertos parámetros relacionados con la caducidad. Una cuenta de usuario podrá caducar siempre y cuando se cumpla alguna de las siguientes condiciones:

  • La cuenta está configurada para cambiar la contraseña cada cierto tiempo y esta, tras pasar el tiempo especificado e incluso un tiempo de gracia, no ha sido modificada.
  • La fecha del sistema ha sobrepasado un tiempo predeterminado.

Con la utilidad chage podremos hacer cosas como mostrar la información sobre el periodo de caducidad de la cuenta y la contraseña -l, definir el tiempo mínimo en días para poder volver a cambiar la contraseña -m (0 indica que puede cambiar la contraseña varias veces al día, 1 que puedes cambiarla una vez al día, 2 que podrás hacerlo 1 vez cada 2 días y así…) o por lo contrario establecer un periodo máximo entre cambios de contraseñas -M.

Nota: Si el usuario cambia una contraseña antes de la fecha límite, el contador se reinicializará, por lo que dispondremos nuevamente del margen de tiempo, por ejemplo, si hemos dado 30 días como tope entre cambios de contraseña, si al día que hace 25 modifico la contraseña, contaremos nuevamente con 30 días para volver a realizar el cambio y no con 5 días.

Otras opciones útiles para gestionar la caducidad pueden ser:

  • Definir la fecha del último día en que se cambió de contraseña, que aunque este valor lo controla Linux de forma automática, podremos alterarlo con -d AAAA/MM/DD o con el número de días transcurrido desde el 1 de Enero de 1970
  • Podremos definir la fecha de caducidad absoluta de una cuenta con el parámetro -E 2015/09/21, con el número de días transcurridos desde el 1 de Enero de 1970 o incluso que no caduque nunca pasándole como argumento al parámetro -1 en vez de una fecha o días.
  • Si antes de que caduque una cuenta definitivamente queremos disponer de un “periodo de gracia” comprendido entre el día en que caducó la contraseña y el día en que la cuenta será bloqueada podremos hacerlo con el parámetro -I díasdeinactivo. Una cuenta con contraseña caducada pero que aún no ha sido bloqueada pedirá al usuario que cambie la contraseña justo después de acceder a esta.
  • Una cuenta podrá pasar varios días en estado inactivo tras haber caducado una contraseña e incluso podrá llegar a bloquearse definitivamente si el periodo de gracia se termina. Para evitar esto lo mejor será definir un número de días previos a la caducidad de la cuenta para que seamos informados y poder modificar nuestra contraseña y evitar el bloqueo, por ejemplo -W 7 nos avisará desde el modo consola una semana antes de que nuestra cuenta caduque. Los usuarios que estén en modo Gui no serán avisados.

Normalmente solo root puede utilizar el comando chage, la única excepción es cuando se emplea la opción -l, que permite a los usuarios consultar la información de caducidad de su propia cuenta.

Para terminar con la modificaciones de cuentas de usuario, nombrar el comando chsh el cual nos permitirá cambiar el shell con el que inicia la cuenta de usuario y el comando chfn que permite cambiar la información (comentarios -c) del usuario.

 

Modificar grupos

Como ya comentábamos anteriormente las características de las cuentas de usuarios y los grupos pueden modificarse con utilidades destinadas a ello, o bien modificando directamente sus archivos de configuración. Para la modificación de grupos mediante utilidades además de la herramienta usermod disponemos también de otras como groupmod y gpasswd que serán las que se cubran en esta sección del tema “Sobre usuarios y grupos“.

Con el comando groupmod podremos modificar los parámetros de un grupo ya existente. Su sintaxis es bastante clara y sencilla al igual que sus opciones.

Sintaxis del comando groupmod:

groupmod [opciones] grupo

Básicamente las opciones de groupmod nos permitirán seleccionar un GID concreto para el grupo con su opción -g o –gid e incluso elegir uno ya existente con la opción -o:

$ sudo groupmod -go 1004 migrupo

Cambiar el nombre del grupo:

$ sudo groupmod -n nuevogrupo miantiguogrupo

Asignar una password con su opción -p (se desaconseja utilizar esta opción):

$ sudo groupmod -p mipasswd

La password podremos crearla mejor con el equivalente a passwd que es en este caso gpasswd, simplemente pasando como argumento al comando gpasswd la contraseña deseada. Como ya vimos en secciones anteriores esta contraseña además de implementar seguridad a la hora de agregar usuarios al grupo, permitía que un usuario que no es miembro de un grupo pudiese pasar a tener a este como grupo principal de forma temporal con el comando newgrp, aunque también se comentó que esto no funcionaba en todas las distribuciones de Linux. Podremos eliminar la password de un grupo con la opción -r de gpasswd. El comando gpasswd además de permitirnos crear o eliminar una contraseña de grupo nos permite realizar otras personalizaciones en los grupos con opciones como -a y -d que añadirá o eliminará respectivamente un usuario al grupo. Podremos agregar mas de un usuario al grupo, es decir crear una lista de miembros de grupo con la opción -M. Por último si queremos implementar algo mas de seguridad al grupo, a parte de tener una contraseña, sería bueno que el grupo fuera administrado por uno o varios usuarios, algo que conseguiremos con la opción -A. Con -R podremos restringir el acceso al grupo de forma temporal (newgrp) solo los usuarios que conozcan la password podrán acceder al grupo. Si la opción -R es definida la contraseña del grupo será seteada con el signo de admiración ‘!‘.

Algo muy común en la administración de grupos es el añadir miembros a un grupo. A continuación vamos a nombrar diferentes formas de hacerlo.

  • Añadir un usuario que ya existe a un grupo que también existe:
$ sudo adduser <usuario> <grupo>
  • Añadir un usuario que ya existe a un grupo que también existe. Es similar al comando anterior y además es el que deberemos de acostumbrar a usar:
$ sudo gpasswd -a <usuario> <grupo>
  • Añadir a uno o varios grupos existentes usuarios de nueva creación:
$ adduser | useradd [opciones de creación de usuario] -G grupo1,grupo2,grupoN...
  • Añadir un usuario que ya existe a uno o varios grupos a la vez:
$ sudo usermod -G grupo1,grupo2,grupoN <usuario>

Nota: En este ultimo caso deberemos de especificar la lista de todos los grupos a los que ya pertenece el usuario además de los nuevos grupos de los que queremos que forme parte. De no especificar todos sus grupos anteriores, aquel que no indiquemos será eliminado, por lo que este comando también nos puede servir para eliminar a un usuario de uno o varios grupos.

  • Acabamos de ver en la nota anterior como eliminar a un usuario de uno o varios grupos, pero la mejor forma de hacerlo es la siguiente:
$ sudo gpasswd -d <usuario> <grupo>
  • O igualmente con la interfaz para userdel de algunas distribuciones Debian:
$ sudo deluser <usuario> <grupo>

 

Eliminar cuentas de usuario

Eliminar una cuenta de usuario no es complicado, pero deberemos de estar atentos para no dejar rastros de los usuarios, como son sus archivos o directorios creados, cuentas de correo, directorio home, etc… Si no queremos eliminar todo su contenido deberemos de hacer algo con él, para evitar que nuevos usuarios creados en el sistema puedan adoptar su UID (algo que a menos que se fuerce no suele ser muy normal) y tengan acceso completo a todos los archivos. A continuación vamos a ver como eliminar una cuenta de usuario y ver que hacer con todo aquello que queremos o no conservar.

Para eliminar cuentas disponemos de la utilidad userdel y de su interfaz sencilla deluser (en teoría solo para algunas distribuciones Debian). Ambas herramientas son sencillas de utilizar por lo que vamos a explicar el funcionamiento de de las dos.

  • Eliminar la cuenta de usuario de e.torres eliminando a demás su directorio /home y con ello todos los archivos en él creados, además de su directorio mail.
$ sudo userdel -r e.torres
  • La misma acción pero mas agresiva (eliminará no solo el directorio home del usuario, si no cualquier archivo con su UID en el sistema) podremos realizarla con deluser y su opción –remove-all-files o –remove-home si queremos dejar intacto todo archivo creado por el usuario fuera de su directorio home
$ sudo deluser --remove-all-files e.torres

Nota: Ambos comandos aceptan la opción -f con la que podremos eliminar un usuario que se encuentre dentro del sistema e incluso al mismísimo root.

  • Si queremos eliminar un usuario con userdel y dejar intactos sus archivos bastará con no pasar la opción -r
  • En este caso el comando deluser ofrece una ventaja importante y es que nos permite realizar copias de seguridad que por defecto se crearán en el directorio raíz /nomusuario.tar.gz o /nomusuario.bz2 (opción –backup) o incluso redirigir la copia a un directorio concreto con –backup-to <directorio>

Nota: deluser nos permite eliminar un grupo (no el primario de un usuario) con su opción –group y podemos asegurarnos de que eliminamos un grupo que se encuentra vacío si lo comprobamos antes con la opción –only-if-empty

Una vez eliminada la cuenta con userdel -r podremos comprobar con el comando find / -uid <UID> si el usuario a dejado rastro por algún directorio del sistema y eliminarlos o decidir que hacer con ellos.

Algunos servidores entre los que destaca Samba, guardan su propia lista de usuarios. Si emplea un servidor de este tipo, es preferible eliminar la entrada del usuario de la lista de usuarios del servidor al eliminar la cuenta principal del usuario. En el caso de Samba esto se suele hacer editando manualmente el archivo smbpasswd, que suele encontrase en /etc/, /etc/samba o /etc/samba.d y eliminar la línea correspondiente al usuario en cuestión o bien utilizando el comando smbpasswd y su opción -x

 

Eliminar grupos

Los grupos se eliminan con el comando groupdel o como siempre dependiendo de la distribución podremos usar su interfaz sencilla delgroup e incluso deluser –group. Igualmente podremos eliminar un grupo editando el archivo /etc/group y /etc/gshadow si el grupo tiene contraseña. El comando groupdel verifica si el grupo es el grupo primario de algún usuario, en tal caso rehusará eliminarlo; tendrá que cambiar primero el grupo primario del usuario o borrar su cuenta. Como ocurre al eliminar las cuentas de usuario, puede que existan archivos y directorios en el sistema con el GID del grupo, lo mejor será buscarlos con find y modificar el grupo con chown.

 

Poner a punto entornos de sistemas y usuarios

Como ya comentamos al inicio del tema de creación de usuarios, los entornos de tipo texto de los usuarios se controlan a través de los archivos de configuración de la consola. En bash estos archivos son /etc/profile, /etc/bash, /etc/bash.bashrc, ~/.profile~/.bash_profile y ~/.bashrc.

Los archivos de /etc son archivos de configuración global, los del directorio principal de los usuarios afectan a las cuentas de los usuarios de manera individual y son copiados en el en home a la hora de crear la cuenta. Estos archivos controlan las distintas opciones de bash, incluyendo las variables de entorno. Podemos ver todas las variables de entorno definidas para una cuenta concreta ejecutando la orden env.

Bash mantiene algunas variables de entorno automáticamente como PWD, por lo que no debería intentar definirla en un script de configuración adicional. La modificación de los archivos de configuración de bash solo afectan a bash por lo que si un usuario no utiliza una consola en modo texto o usa otro shell distinto de bash definir las variables de entorno en archivos de configuración de bash no le será de ayuda.

 

Algo de información extra

Truco para recuperar la contraseña de root

Existen varias formas de hacerse con el control de root incluso cuando hemos sido olvidadizos y no recordamos la contraseña de nuestro superusuario. Vamos a explicar una forma sencilla pero eficaz de acceder a root sin saber su contraseña. Para esto necesitaremos un LiveCD o herramientas de rescate como SystemRescueCd, otro usuario en el sistema y además conocer la contraseña de este. Suponiendo que contamos con lo anterior, comenzaremos iniciando con el sistema de recuperación de emergencia y localizaremos el archivo /etc/shadow. De este archivo copiaremos la contraseña encriptada del otro usuario y la pegaremos en el campo de contraseña de root. A continuación podremos iniciar con root y teclear la contraseña del usuario. Una vez dentro se recomienda cambiarla con el comando passwd.

En una situación en la que ni siquiera contamos con otro usuario podremos vaciar el campo de contraseña de root para dejar el sistema si password. Una vez que accedamos lo mejor será crear una nueva contraseña.

 

Sobre los archivos esqueletos

Proporcionan un conjunto central de archivos de configuración que deben estar presentes en los directorios principales de los usuarios cuando estos se creen. Proporcionan un punto de partida para que los usuarios modifiquen sus archivos de consola y características de su perfil (~/.bashrc) e incluso algunas aplicaciones de terceros pueden exigir que definamos ciertas variables en alguno de estos archivos para su correcto funcionamiento (normalmente en ~/.profile o ~/.bash_profile), otros son usado para guardar los últimos comandos usados en la consola (~/.bash_history) o realizar tareas al finalizar la sesión en una terminal, como puede ser limpiar la pantalla y mostrar el prompt de nuevo (~/.bash_logout).

Nota: El archivo ~/.bashrc es ejecutado cuando invocamos un shell desde consola por lo que ajustará la configuración para este nuevo shell mientras que el archivo ~/.bash_profile o ~/.profile es ejecutado cuando el usuario inicia sesión por lo que será quién controle la configuración principal del shell de inicio del usuario. La configuración de estos archivos solo afectan a bash.

Podremos añadir al directorio /etc/skel archivos de configuración, de presentación (tipo README) e incluso un árbol de directorios.

 

Bases de datos de cuentas de red

Muchas redes emplean bases de datos de cuentas de red como por ejemplo NIS (Network Information System, Sistema de información de la red), su predecesor NIS+, LDAP (Lightweight Directory Access Protocol, Protocolo Ligero de Acceso a Directorios), dominios de Kerberos, dominios de Windows NT4.0 o dominios de Directorio Activo de Windows (AD).

Todos estos sistemas tienen como función principal trasladar la gestión de la base de datos de las cuentas de usuarios a un mismo servidor centralizado. La ventaja de estos sistemas es que administradores y usuarios no tienen por que preocuparse de la gestión individual de cada cuenta. El uso de estos sistemas o semejantes implica que la mayoría de las cuentas no aparecerán en /etc/passwd, /etc/group, /etc/shadow o /etc/gshadow y digo la mayoría porque siempre estarán como mínimo las cuentas del sistema local (daemon, man, mail o incluso la de algún usuario no perteneciente al dominio pero que tiene una cuenta concreta en el sistema local).

Implementar un sistema de este tipo suele ser complejo. Entre otras cosas deberemos de instalar el software apropiado, modificar el archivo /etc/nsswitch.conf y los archivos de configuración PAM (Pluggable Authentication Module, Módulo de autenticación conectable) de /etc/pam.d.

Tras implementar un sistema de autenticación basado en red, el comportamiento de utilidades como passwd o usermod quizás dejen de sernos útiles para crear estas cuentas de dominio.

 

Conclusiones sobre la administración de usuarios y grupos en Linux

Durante las secciones relacionadas con la creación, modificación y eliminación de cuentas de usuarios y grupos hemos estudiado algunos comandos y formas destinadas de realizar estas tareas. Hemos vistos comandos y sus similares en algunas distribuciones y hemos desaconsejado formas de realizar tareas de mantenimiento de usuarios de forma manual. A continuación vamos a ver un listado de las herramientas ‘estándar‘ para realizar el mantenimiento de usuarios y grupos y posteriormente las opcionales que funcionarán solo para algunas distribuciones.

Herramientas estándar:

  • Crear, Eliminar y Modificar usuario: useradd, userdel y (usermod, chage, passwd, chpasswd, chfn y chsh), respectivamente.
  • Crear, Eliminar y Modificar grupos: groupadd, groupdel y (groupmod y gpasswd), respectivamente
  • Añadir o Eliminar usuarios a un grupo: gpasswd -a ó gpasswd -d
  • Cambiar a grupo principal temporal: newgrp

Nota: El comportamiento de estos comandos puede ser modificado a través de lo archivos de configuración /etc/login.defs y /etc/default/useradd

Símiles de las herramientas estándar:

Nota: Son válidas solo en algunas distribuciones y pueden cambiar el comportamiento de una a otra distribución.

  • Crear y Eliminar usuarios: adduser y deluser
  • Crear y Eliminar grupos: (addgroup ó adduser –group) y (delgroup ó deluser –group), respectivamente.
  • Añadir y Eliminar usuarios a un grupo: adduser <usuario> <grupo> y deluser <usuario> <grupo>

Nota: Estos comandos suelen ser mas sencillos de utilizar, puesto que llevan configuradas opciones para pasar pocos argumentos por línea de comando y realizar muchos cambios e incluso son interactivo, es decir se realizan una serie de preguntas sobre el usuario cuando este es creado. Los archivo de configuración para estas herramientas son /etc/adduser.conf y /etc/deluser.conf aunque pueden existir otros como /usr/local/sbin/adduser.local o /usr/local/sbin/deluser.local que de existir serán ejecutados tras crear o eliminar las cuentas.

Como último de los comandos para la administración de grupos y usuarios estudiados en este tema mencionaremos el comando getent el cual nos permite imprimir por pantalla (o redireccionar a un archivo) el contenido de las bases de datos de gestión de usuarios como lo son /etc/passwd, /etc/group y /etc/shadow;

getent passwd | group | shadow

ademas de permitirnos ver el contenido de otros archivos como /etc/hosts, los servicios con su puerto y protocolo, los protocolos o redes;

getent hosts | services | protocols | networks

Nota: Estos últimos serán estudiados mas a fondo en el “Capítulo 8 – Configuración básica de redes

 

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, yumdpkg, samba, ufw y upstart. A continuación pondremos uno de estos archivos a modo de ejemplo.

logrotate

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 rotatenú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 ‘sourceson 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.

Algunos de los source desde los que podremos reenviar los mensajes de registro son: tuberías ‘pipe’, archivos ‘file‘, ‘internal‘ (solo escucha los mensajes de la máquina local), o los protocolos TCP y UDP.

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

 

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

Anuncios

2 comentarios

  1. […] y uso básico de SQL de la guía de estudios para LPIC-1 400, así como la creación de usuarios Capítulo 7 – Administrar el sistema y el uso de comandos como gzip y tar Capítulo 4 – Fylesystem y Administrar […]

    Me gusta

Deja un comentario, Gracias!

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: