Linux Professional Institute
          Learning Logo.
Pasar al contenido principal
  • Inicio
    • Todos los recursos
    • LPI Learning Materials
    • Conviértete en colaborador
    • Publishing Partners
    • Conviértase en un Publishing Partner
    • Acerca de nosotros
    • FAQ
    • Colaboradores
    • Contáctenos
  • LPI.org
108.2 Lección 2

Tema 105: Shells y scripts
105.1 Customize and use the shell environment
  • 105.1 Lección 1
  • 105.1 Lección 2
  • 105.1 Lección 3
105.2 Personalización y escritura de scripts sencillos
  • 105.2 Lección 1
  • 105.2 Lección 2
Tema 106: Interfaces de usuario y escritorios
106.1 Instalar y configurar X11
  • 106.1 Lección 1
106.2 Escritorios gráficos
  • 106.2 Lección 1
106.3 Accesibilidad
  • 106.3 Lección 1
Tema 107: Tareas administrativas
107.1 Administrar cuentas de usuario y de grupo y los archivos de sistema relacionados con ellas
  • 107.1 Lección 1
  • 107.1 Lección 2
107.2 Automatizar tareas administrativas del sistema mediante la programación de trabajos
  • 107.2 Lección 1
  • 107.2 Lección 2
107.3 Localización e internacionalización
  • 107.3 Lección 1
Tema 108: Servicios esenciales del sistema
108.1 Mantener la hora del sistema
  • 108.1 Lección 1
  • 108.1 Lección 2
108.2 Registros del sistema
  • 108.2 Lección 1
  • 108.2 Lección 2
108.3 Conceptos básicos del Agente de Transferencia de Correo
  • 108.3 Lección 1
108.4 Gestión de la impresión y de las impresoras
  • 108.4 Lección 1
Tema 109: Fundamentos de redes
109.1 Fundamentos de los protocolos de Internet
  • Muy pronto...
109.2 Configuración de red persistente
  • Muy pronto...
109.3 Resolución de problemas básicos de red
  • Muy pronto...
109.4 Configuración DNS en el lado del cliente
  • Muy pronto...
Tema 110: Seguridad
110.1 Tareas de administración de seguridad
  • Muy pronto...
110.2 Configuración de la seguridad del sistema
  • Muy pronto...
110.3 Protección de datos mediante cifrado
  • Muy pronto...
  1. Tema 108: Servicios esenciales del sistema
  2. 108.2 Registros del sistema
  3. 108.2 Lección 2

108.2 Lección 2

Certificación:

LPIC-1

Versión:

5.0

Tema:

108 Servicios Esenciales del Sistema

Objetivo:

108.2 Registros del sistema

Lección:

2 de 2

Introducción

Con la adopción generalizada de systemd por parte de las principales distribuciones, el demonio del journal (systemd-journald) se ha convertido en el servicio de registro estándar. En esta lección discutiremos cómo opera y cómo puedes usarlo para hacer un gran número de cosas: consultarlo, filtrar su información por diferentes criterios, configurar su almacenamiento y tamaño, borrar datos viejos, recuperar sus datos desde un sistema de rescate o una copia del sistema de archivos y - por último pero no menos importante - entender su interacción con rsyslogd.

Fundamentos de systemd

Introducido por primera vez en Fedora, systemd ha sustituido progresivamente a SysV Init como gestor de sistemas y servicios de hecho en la mayoría de las principales distribuciones de Linux. Entre sus puntos fuertes están los siguientes:

  • Facilidad de configuración: Archivos de unidad en comparación a los scripts SysV Init.

  • Gestión versátil: Además de demonios y procesos, también gestiona dispositivos, sockets y puntos de montaje.

  • Compatibilidad con SysV Init y Upstart.

  • Carga paralela durante el arranque: los servicios se cargan en paralelo, en lugar de que Sysv Init los cargue secuencialmente.

  • Cuenta con un servicio de registro llamado journal que presenta las siguientes ventajas:

    • Centraliza todos los registros en un solo lugar.

    • No requiere rotación de registros.

    • Los registros pueden ser deshabilitados, cargados en RAM o hechos persistentes.

Unidades y objetivos

systemd opera sobre unidades (units). Una unidad es cualquier recurso que systemd puede gestionar (por ejemplo, red, bluetooth, etc.). Las unidades, a su vez, se rigen por ficheros de unidades. Estos son archivos de texto plano que se ubican en /lib/systemd/system e incluyen los ajustes de configuración — en forma de secciones y directivas — para un recurso particular a ser gestionado. Hay varios tipos de unidades: service, mount, automount, swap, timer, device, socket, path, timer, snapshot, slice, scope y target. Así cada nombre de archivo de unidad sigue el patrón <nombre_de_recurso>.<tipo_de_unidad> (por ejemplo, reboot.service).

Un objetivo (target) es un tipo especial de unidad que se asemeja a los clásicos runlevels de SysV Init. Esto se debe a que una unidad target reúne varios recursos para representar un estado particular del sistema (por ejemplo, graphical.target es similar a runlevel 5, etc.). Para comprobar el objetivo actual de su sistema, utilice el comando systemctl get-default:

carol@debian:~$ systemctl get-default
graphical.target

Por otro lado, los objetivos y los niveles de ejecución se diferencian en que los primeros se incluyen mutuamente, mientras que los segundos no. Así, un objetivo puede hacer que aparezcan otros objetivos, lo que no es posible con los niveles de ejecución.

Note

Una explicación de cómo funcionan las unidades systemd está fuera del alcance de este tema.

The System Journal: systemd-journald

systemd-journald es el servicio del sistema que se encarga de recibir información de registro de diversas fuentes: mensajes del kernel, mensajes simples y estructurados del sistema, la salida estándar y error estándar de los servicios, así como los registros de auditoría del subsistema del kernel (para más detalles, consulte la página del manual de systemd-journald). Su misión es la de crear y mantener un diario estructurado e indexado.

Su archivo de configuración es /etc/systemd/journald.conf y — como con cualquier otro servicio — puedes usar el comando systemctl para iniciarlo, reiniciarlo, pararlo o simplemente comprobar su estado:

root@debian:~# systemctl status systemd-journald
 systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
   Active: active (running) since Sat 2019-10-12 13:43:06 CEST; 5min ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 178 (systemd-journal)
   Status: "Processing requests..."
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-journald.service
           └─178 /lib/systemd/systemd-journald
(...)

Los archivos de configuración del tipo journal.conf.d/*.conf — que pueden incluir configuraciones específicas de los paquetes — también son posibles (consulte la página del manual de journald.conf para saber más). Si se activa, el diario puede almacenarse de forma persistente en el disco o de forma volátil en un sistema de archivos basado en la memoria RAM. El diario no es un archivo de texto plano, es binario. Por lo tanto, no puede utilizar herramientas de análisis de texto como less o more para leer su contenido; en su lugar se utiliza el comando journalctl.

Consultando el contenido de journal

journalctl es la utilidad que se emplea para consultar el journal en systemd. Tienes que ser root o usar sudo para invocarlo. Si se consulta sin opciones, imprimirá todo el diario cronológicamente (con las entradas más antiguas listadas primero):

root@debian:~# journalctl
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:19:46 CEST. --
Oct 12 13:43:06 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (...)
Oct 12 13:43:06 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=b6be6117-5226-4a8a-bade-2db35ccf4cf4 ro qu
(...)

Puede realizar consultas más específicas utilizando una serie de opciones:

-r

Los mensajes del journal se imprimirán en orden inverso:

root@debian:~# journalctl -r
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:30:30 CEST. --
Oct 12 14:30:30 debian sudo[1356]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:30:30 debian sudo[1356]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -r
Oct 12 14:19:53 debian sudo[1348]: pam_unix(sudo:session): session closed for user root
(...)
-f

Imprimirá los mensajes más recientes del journal y seguirá imprimiendo las nuevas entradas a medida que se añadan a este, de forma similar a tail -f:

root@debian:~# journalctl -f
-- Logs begin at Sat 2019-10-12 13:43:06 CEST. --
(...)
Oct 12 14:44:42 debian sudo[1356]: pam_unix(sudo:session): session closed for user root
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)

(...)
-e

Saltará al final del journal para que las últimas entradas sean visibles dentro del localizador:

root@debian:~# journalctl -e
(...)
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:45:57 debian sudo[1375]: pam_unix(sudo:session): session closed for user root
Oct 12 14:48:39 debian sudo[1378]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -e
Oct 12 14:48:39 debian sudo[1378]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
-n <value>, --lines=<value>

Imprimirá el valor de las líneas más recientes (si no se especifica <valor>, por defecto sera 10):

root@debian:~# journalctl -n 5
(...)
Oct 12 14:44:44 debian sudo[1375]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -f
Oct 12 14:44:44 debian sudo[1375]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 14:45:57 debian sudo[1375]: pam_unix(sudo:session): session closed for user root
Oct 12 14:48:39 debian sudo[1378]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/journalctl -e
Oct 12 14:48:39 debian sudo[1378]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
-k, --dmesg

Equivale a utilizar el comando dmesg:

root@debian:~# journalctl -k
-- Logs begin at Sat 2019-10-12 13:43:06 CEST, end at Sat 2019-10-12 14:53:20 CEST. --
Oct 12 13:43:06 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18
Oct 12 13:43:06 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID=b6be6117-5226-4a8a-bade-2db35ccf4cf4 ro qu
Oct 12 13:43:06 debian kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Oct 12 13:43:06 debian kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
(...)
Navegar y buscar a traves del Journal

Puede navegar por la salida de journal con:

  • PageUp, PageDown y las teclas de flecha para moverse hacia arriba, abajo, izquierda y derecha.

  • > Para ir al final de la salida.

  • < Para ir al principio de la salida.

Puede buscar cadenas tanto hacia adelante como hacia atrás desde la posición de la vista actual:

  • Búsqueda hacia delante: Pulse / e introduzca la cadena a buscar, luego pulse Enter.

  • Búsqueda hacia atrás: Pulse ? e introduzca la cadena a buscar, luego pulse Enter.

Para navegar por las coincidencias en las búsquedas, utilice N para ir a la siguiente ocurrencia y Shift+N para ir a la anterior.

Filtrar los datos de journal

El journal permite filtrar los datos del registro por diferentes criterios:

Número de arranque
--list-boots

Enumera todos los arranques disponibles. La salida consta de tres columnas; la primera especifica el número de arranque (0 se refiere al arranque actual, -1 es el anterior, -2 el anterior al anterior y así sucesivamente); la segunda columna es el ID del arranque; la tercera muestra las marcas de tiempo:

root@debian:~# journalctl --list-boots
 0 83df3e8653474ea5aed19b41cdb45b78 Sat 2019-10-12 18:55:41 CEST—Sat 2019-10-12 19:02:24 CEST
-b, --boot

Muestra todos los mensajes del arranque actual. Para ver los mensajes de registro de los arranques anteriores, sólo tiene que añadir un parámetro de desplazamiento como se ha explicado anteriormente. Por ejemplo, para que se impriman los mensajes del arranque anterior, escribirá journalctl -b -1. Recuerde, sin embargo, que para recuperar la información de los registros anteriores, la persistencia del diario debe estar habilitada (aprenderá cómo hacerlo en la siguiente sección):

root@debian:~# journalctl -b -1
La especificación del ID de arranque no tiene efecto, no se ha encontrado ningún diario persistente.
Prioridad
-p

Curiosamente, también se puede filtrar por gravedad/prioridad con la opción -p:

root@debian:~# journalctl -b -0 -p err
-- No entries --

Journal nos informa que — hasta ahora — no ha habido ningún mensaje con una prioridad de error (o superior) desde el arranque actual. Nota: -b -0 puede omitirse cuando se refiere al arranque actual.

Note

Consulte el tema anterior para obtener una lista completa de todas las severidades (también conocidas como prioridades) de syslog.

Intervalo de tiempo

Puede hacer que journalctl imprima sólo los mensajes registrados dentro de un marco de tiempo específico utilizando las opciones --since y --until. La especificación de la fecha debe seguir el formato AAAA-MM-DD HH:MM:SS. Se asumirá que es medianoche si se omite el componente de tiempo. Del mismo modo, si se omite la fecha, se asume el día actual. Por ejemplo, para ver los mensajes registrados desde las 19:00 hasta las 19:01, se escribirá:

root@debian:~# journalctl --since "19:00:00" --until "19:01:00"
-- Logs begin at Sat 2019-10-12 18:55:41 CEST, end at Sat 2019-10-12 20:10:50 CEST. --
Oct 12 19:00:14 debian systemd[1]: Started Run anacron jobs.
Oct 12 19:00:14 debian anacron[1057]: Anacron 2.3 started on 2019-10-12
Oct 12 19:00:14 debian anacron[1057]: Normal exit (0 jobs run)
Oct 12 19:00:14 debian systemd[1]: anacron.timer: Adding 2min 47.988096s random time.

Del mismo modo, puede utilizar una especificación de tiempo ligeramente diferente: "integer time-unit ago". Por lo tanto, para ver los mensajes registrados hace dos minutos escribirá sudo journalctl --since "2 minutes ago". También es posible utilizar + y - para especificar tiempos relativos a la hora actual, por lo que --since "-2 minutos" y --since "2 minutes ago" son

Además de las expresiones numéricas, puede especificar una serie de palabras clave:

yesterday

A partir de la medianoche del día anterior al día actual.

today

A partir de la medianoche del día actual.

tomorrow

A partir de la medianoche del día siguiente al día actual.

now

La hora actual.

Veamos todos los mensajes desde la pasada medianoche hasta hoy a las 21:00 horas:

root@debian:~# journalctl --since "today" --until "21:00:00"
-- Logs begin at Sat 2019-10-12 20:45:29 CEST, end at Sat 2019-10-12 21:06:15 CEST. --
Oct 12 20:45:29 debian sudo[1416]:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/bin/systemctl r
Oct 12 20:45:29 debian sudo[1416]: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Oct 12 20:45:29 debian systemd[1]: Stopped Flush Journal to Persistent Storage.
(...)
Note

Para saber más sobre las diferentes sintaxis de las especificaciones de tiempo, consulte la página del manual systemd.time.

Programa

Para ver los mensajes de journal relacionados con un ejecutable específico se utiliza la siguiente sintaxis journalctl /ruta/al/ejecutable:

root@debian:~# journalctl /usr/sbin/sshd
-- Logs begin at Sat 2019-10-12 20:45:29 CEST, end at Sat 2019-10-12 21:54:49 CEST. --
Oct 12 21:16:28 debian sshd[1569]: Accepted password for carol from 192.168.1.65 port 34050 ssh2
Oct 12 21:16:28 debian sshd[1569]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Oct 12 21:16:54 debian sshd[1590]: Accepted password for carol from 192.168.1.65 port 34052 ssh2
Oct 12 21:16:54 debian sshd[1590]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Unidad

Recuerda que una unidad es cualquier recurso manejado por systemd y también puedes filtrar por ellos.

-u

Muestra mensajes sobre una unidad específica:

root@debian:~# journalctl -u ssh.service
-- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 12:22:59 CEST. --
Oct 13 10:51:00 debian systemd[1]: Starting OpenBSD Secure Shell server...
Oct 13 10:51:00 debian sshd[409]: Server listening on 0.0.0.0 port 22.
Oct 13 10:51:00 debian sshd[409]: Server listening on :: port 22.
(...)
Note

Para imprimir todas las unidades cargadas y activas, utilice systemctl list-units; para ver todos los archivos de unidad instalados utilice systemctl list-unit-files.

Campos

El journal también se puede filtrar por campos específicos mediante cualquiera de las siguientes sintaxis:

  • <field-name>=<value>

  • _<field-name>=<value>_

  • __<field-name>=<value>

    PRIORITY=

    Uno de los ocho posibles valores de prioridad de syslog formateado como una cadena decimal:

    root@debian:~# journalctl PRIORITY=3
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:30:50 CEST. --
    Oct 13 10:51:00 debian avahi-daemon[314]: chroot.c: open() failed: No such file or directory

    Observe cómo podría haber conseguido la misma salida utilizando el comando sudo journalctl -p err que vimos anteriormente.

    SYSLOG_FACILITY=

    Cualquiera de los posibles números de código de instalación formateados como una cadena decimal. Por ejemplo, para ver todos los mensajes de nivel de usuario:

    root@debian:~# journalctl SYSLOG_FACILITY=1
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:42:52 CEST. --
    Oct 13 10:50:59 debian mtp-probe[227]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1"
    Oct 13 10:50:59 debian mtp-probe[227]: bus: 1, device: 2 was not an MTP device
    Oct 13 10:50:59 debian mtp-probe[238]: checking bus 1, device 2: "/sys/devices/pci0000:00/0000:00:06.0/usb1/1-1"
    Oct 13 10:50:59 debian mtp-probe[238]: bus: 1, device: 2 was not an MTP device
    _PID=

    Muestra los mensajes producidos por un ID de proceso específico. Para ver todos los mensajes producidos por systemd, se debe escribir:

    root@debian:~# journalctl _PID=1
    -- Logs begin at Sun 2019-10-13 10:50:59 CEST, end at Sun 2019-10-13 14:50:15 CEST. --
    Oct 13 10:50:59 debian systemd[1]: Mounted Debug File System.
    Oct 13 10:50:59 debian systemd[1]: Mounted POSIX Message Queue File System.
    Oct 13 10:50:59 debian systemd[1]: Mounted Huge Pages File System.
    Oct 13 10:50:59 debian systemd[1]: Started Remount Root and Kernel File Systems.
    Oct 13 10:50:59 debian systemd[1]: Starting Flush Journal to Persistent Storage...
    (...)
    _BOOT_ID

    Basándose en su ID de arranque, se pueden distinguir los mensajes de un arranque específico, por ejemplo: sudo journalctl _BOOT_ID=83df3e8653474ea5aed19b41cdb45b78.

    _TRANSPORT

    Mostrar los mensajes recibidos de un transporte específico. Los valores posibles son: audit (subsistema de auditoría del kernel), driver (generado internamente), syslog (socket syslog), journal (protocolo de diario nativo), stdout (salida estándar o error estándar de los servicios), kernel (buffer de anillo del kernel --lo mismo que dmesg, journalctl -k o journalctl --dmesg):

    root@debian:~# journalctl _TRANSPORT=journal
    -- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:46:36 CEST. --
    Oct 13 20:19:58 debian systemd[1]: Started Create list of required static device nodes for the current kernel.
    Oct 13 20:19:58 debian systemd[1]: Starting Create Static Device Nodes in /dev...
    Oct 13 20:19:58 debian systemd[1]: Started Create Static Device Nodes in /dev.
    Oct 13 20:19:58 debian systemd[1]: Starting udev Kernel Device Manager...
    (...)
Combinando campos

Los campos no son mutuamente excluyentes, por lo que puede utilizar más de uno en la misma consulta. Sin embargo, sólo se mostrarán los mensajes que coincidan con el valor de ambos campos simultáneamente:

root@debian:~# journalctl PRIORITY=3 SYSLOG_FACILITY=0
-- No entries --
root@debian:~# journalctl PRIORITY=4 SYSLOG_FACILITY=0
-- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:21:55 CEST. --
Oct 13 20:19:58 debian kernel: acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration (...)

A menos que utilice el separador + para combinar dos expresiones a la manera de un OR lógico:

root@debian:~# journalctl PRIORITY=3 + SYSLOG_FACILITY=0
-- Logs begin at Sun 2019-10-13 20:19:58 CEST, end at Sun 2019-10-13 20:24:02 CEST. --
Oct 13 20:19:58 debian kernel: Linux version 4.9.0-9-amd64 (debian-kernel@lists.debian.org) (...9
Oct 13 20:19:58 debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.9.0-9-amd64 root=UUID= (...)
(...)

Por otro lado, puede proporcionar dos valores para el mismo campo y se mostrarán todas las entradas que coincidan con cualquiera de los dos valores:

root@debian:~# journalctl PRIORITY=1
-- Logs begin at Sun 2019-10-13 17:16:24 CEST, end at Sun 2019-10-13 17:30:14 CEST. --
-- No entries --
root@debian:~# journalctl PRIORITY=1 PRIORITY=3
-- Logs begin at Sun 2019-10-13 17:16:24 CEST, end at Sun 2019-10-13 17:32:12 CEST. --
Oct 13 17:16:27 debian connmand[459]: __connman_inet_get_pnp_nameservers: Cannot read /pro
Oct 13 17:16:27 debian connmand[459]: The name net.connman.vpn was not provided by any .se
Note

Los campos de journal se encuentran en cualquiera de las siguientes categorías: “Campos de diario del usuario”, “Campos de diario de confianza”, “Campos de diario del núcleo”, “Campos en nombre de un programa diferente” y "Campos de dirección`". Para más información sobre este tema -incluyendo una lista completa de campos --vea la página man de systemd.journal-fields(7).

Entradas manuales en el diario del sistema: systemd-cat

Al igual que el comando logger se utiliza para enviar mensajes desde la línea de comandos al registro del sistema (como vimos en la lección anterior), el comando systemd-cat tiene un propósito similar -pero más completo- con el diario del sistema. Nos permite enviar la entrada estándar (stdin), la salida (stdout) y el error (stderr) al diario.

Si se invoca sin parámetros, enviará todo lo que lea de stdin al diario. Una vez que haya terminado, pulse Ctrl+C:.

carol@debian:~$ systemd-cat
This line goes into the journal.
^C

Si se le pasa la salida de un comando canalizado, ésta se enviará también al diario:

carol@debian:~$ echo "And so does this line." | systemd-cat

Si va seguido de un comando, la salida de ese comando también se enviará al diario, junto con stderr (si lo hay):

carol@debian:~$ systemd-cat echo "And so does this line too."

También existe la posibilidad de especificar un nivel de prioridad con la opción -p:

carol@debian:~$ systemd-cat -p emerg echo "This is not a real emergency."

Consulte la página man de systemd-cat para conocer sus otras opciones.

Para ver las últimas cuatro líneas del diario utilice:

carol@debian:~$ journalctl -n 4
(...)
-- Logs begin at Sun 2019-10-20 13:43:54 CEST. --
Nov 13 23:14:39 debian cat[1997]: This line goes into the journal.
Nov 13 23:19:16 debian cat[2027]: And so does this line.
Nov 13 23:23:21 debian echo[2030]: And so does this line too.
Nov 13 23:26:48 debian echo[2034]: This is not a real emergency.
Note

Las entradas con un nivel de prioridad de emergencia se imprimirán en negrita roja en la mayoría de los sistemas.

Almacenamiento persistente del diario

Como se ha mencionado anteriormente, tiene tres opciones en cuanto a la ubicación del diario:

  • El registro en el diario puede ser desactivado por completo (aunque la redirección a otras instalaciones como la consola sigue siendo posible).

  • Mantenerlo en memoria -lo que lo hace volátil- y deshacerse de los registros con cada reinicio del sistema. En este escenario, el directorio /run/log/journal será creado y utilizado.

  • Hacerlo persistente para que escriba los registros en el disco. En este caso, los mensajes de registro irán al directorio /var/log/journal.

El comportamiento por defecto es el siguiente: si /var/log/journal/ no existe, los registros se guardarán de forma volátil en un directorio en /run/log/journal/ y — por tanto — se perderán al reiniciar. El nombre del directorio — el /etc/machine-id  — es una cadena hexadecimal de 32 caracteres en minúsculas terminada en una nueva línea:

carol@debian:~$ ls /run/log/journal/8821e1fdf176445697223244d1dfbd73/
system.journal

Si intentas leerlo con less recibirás una advertencia, así que en su lugar utiliza el comando journalctl:

root@debian:~# less /run/log/journal/9a32ba45ce44423a97d6397918de1fa5/system.journal
"/run/log/journal/9a32ba45ce44423a97d6397918de1fa5/system.journal" may be a binary file.  See it anyway?
root@debian:~# journalctl
-- Logs begin at Sat 2019-10-05 21:26:38 CEST, end at Sat 2019-10-05 21:31:27 CEST. --
(...)
Oct 05 21:26:44 debian systemd-journald[1712]: Runtime journal (/run/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 4.9M, max 39.5M, 34.6M free.
Oct 05 21:26:44 debian systemd[1]: Started Journal Service.
(...)

Si /var/log/journal/ existe, los registros se almacenarán allí de forma persistente. Si se elimina este directorio, systemd-journald no lo recreará, sino que escribirá en /run/log/journal. Tan pronto como creemos /var/log/journal/ de nuevo y reiniciemos el demonio, el registro persistente se restablecerá:

root@debian:~# mkdir /var/log/journal/
root@debian:~# systemctl restart systemd-journald
root@debian:~# journalctl
(...)
Oct 05 21:33:49 debian systemd-journald[1712]: Received SIGTERM from PID 1 (systemd).
Oct 05 21:33:49 debian systemd[1]: Stopped Journal Service.
Oct 05 21:33:49 debian systemd[1]: Starting Journal Service...
Oct 05 21:33:49 debian systemd-journald[1768]: Journal started
Oct 05 21:33:49 debian systemd-journald[1768]: System journal (/var/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 8.0M, max 1.1G, 1.1G free.
Oct 05 21:33:49 debian systemd[1]: Started Journal Service.
Oct 05 21:33:49 debian systemd[1]: Starting Flush Journal to Persistent Storage...
(...)
Note

Por defecto, habrá archivos de diario específicos para cada usuario conectado, ubicados en /var/log/journal/, por lo que — junto con los archivos system.journal  — también encontrará archivos del tipo user-1000.journal.

Además de lo que acabamos de mencionar, la forma en que el demonio del diario se ocupa del almacenamiento de registros puede cambiarse después de la instalación ajustando su archivo de configuración: /etc/systemd/journald.conf. La opción clave es Storage= y puede tener los siguientes valores:

Storage=volatile

Los datos del registro se almacenarán exclusivamente en la memoria — en /run/log/journal/. Si no está presente, se creará el directorio.

Storage=persistent

Por defecto, los datos de registro se almacenarán en el disco -en /var/log/journal/- con un retorno a la memoria (/run/log/journal/) durante las primeras etapas de arranque y si el disco no es escribible. Ambos directorios se crearán si es necesario.

Storage=auto

auto es similar a persistent, pero en este caso el directorio /var/log/journal no se creara si no fuese necesario. Esta es la opción por defecto.

Storage=none

Todos los datos de registro serán descartados. Sin embargo, el reenvío a otros objetivos como la consola, el buffer de registro del kernel o un socket syslog sigue siendo posible.

Por ejemplo, para que systemd-journald cree /var/log/journal/ y cambie al almacenamiento persistente, debes editar /etc/systemd/journald.conf y establecer Storage=persistent, guardar el archivo y reiniciar el demonio con sudo systemctl restart systemd-journald. Para asegurarte de que el reinicio ha sido perfecto, siempre puedes comprobar el estado del demonio:

root@debian:~# systemctl status systemd-journald
 systemd-journald.service - Journal Service
   Loaded: loaded (/lib/systemd/system/systemd-journald.service; static; vendor preset: enabled)
   Active: active (running) since Wed 2019-10-09 10:03:40 CEST; 2s ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 1872 (systemd-journal)
   Status: "Processing requests..."
    Tasks: 1 (limit: 3558)
   Memory: 1.1M
   CGroup: /system.slice/systemd-journald.service
           └─1872 /lib/systemd/systemd-journald

Oct 09 10:03:40 debian10 systemd-journald[1872]: Journal started
Oct 09 10:03:40 debian10 systemd-journald[1872]: System journal (/var/log/journal/9a32ba45ce44423a97d6397918de1fa5) is 8.0M, max 1.2G, 1.2G free.
Note

Los archivos del diario en /var/log/journal/<machine-id>/ o /run/log/journal/<machine-id>/ tienen el sufijo .journal (por ejemplo, system.journal). Sin embargo, si se encuentra que están corruptos o el demonio se detiene de forma poco limpia, se renombrarán añadiendo ~ (por ejemplo, system.journal~) y el demonio empezará a escribir en un archivo nuevo y limpio.

Eliminación de datos antiguos del diario: Tamaño del diario

Los registros se guardan en archivos de diario cuyos nombres terminan en .journal o .journal~ y se encuentran en el directorio apropiado (/run/log/journal o /var/log/journal según se haya configurado). Para comprobar cuánto espacio de disco ocupan actualmente los archivos de diario (tanto los archivados como los activos), utilice el parámetro --disk-usage:

root@debian:~# journalctl --disk-usage
Los diarios archivados y activos ocupan 24,0M en el sistema de archivos.

Los registros de systemd ocupan por defecto un máximo del 10% del tamaño del sistema de archivos donde se almacenan. Por ejemplo, en un sistema de archivos de 1GB no ocuparán más de 100MB. Una vez alcanzado este límite, los registros antiguos empezarán a desaparecer para mantenerse cerca de este valor.

Sin embargo, la aplicación del límite de tamaño de los archivos de diario almacenados puede gestionarse ajustando una serie de opciones de configuración en /etc/systemd/journald.conf. Estas opciones se dividen en dos categorías dependiendo del tipo de sistema de archivos utilizado: persistente (/var/log/journal) o en memoria (/run/log/journal). La primera utiliza opciones que llevan como prefijo la palabra System y sólo se aplicarán si el registro persistente está correctamente habilitado y una vez que el sistema haya arrancado por completo. Los nombres de las opciones de la segunda comienzan con la palabra Runtime y se aplicarán en los siguientes escenarios:

SystemMaxUse=, RuntimeMaxUse=

Controlan la cantidad de espacio en disco que puede ocupar el diario. Por defecto es el 10% del tamaño del sistema de archivos, pero puede modificarse (por ejemplo, SystemMaxUse=500M) siempre que no supere un máximo de 4GiB.

SystemKeepFree=, RuntimeKeepFree=

Controlan la cantidad de espacio en disco que debe quedar libre para otros usuarios. Por defecto es el 15% del tamaño del sistema de archivos, pero puede modificarse (por ejemplo, SystemKeepFree=500M) siempre que no supere un máximo de 4GiB.

En cuanto a la precedencia de *MaxUse y *KeepFree, systemd-journald satisfará ambos valores utilizando el menor de los dos. Asimismo, tenga en cuenta que sólo se eliminan los ficheros de diario archivados (en contraposición a los activos).

SystemMaxFileSize=, RuntimeMaxFileSize=

Controlan el tamaño máximo al que pueden crecer los archivos individuales del diario. El valor por defecto es 1/8 de *MaxUse. La reducción de tamaño se realiza de forma sincrónica y los valores pueden especificarse en bytes o utilizando K, M, G, T, P, E para Kibibytes, Mebibytes, Gibibyte, Tebibytes, Pebibytes y Exbibytes, respectivamente.

SystemMaxFiles=, RuntimeMaxFiles=

Establecen el número máximo de ficheros de diario individuales y archivados a almacenar (los ficheros de diario activos no se ven afectados). El valor predeterminado es 100.

Además del borrado y la rotación de los mensajes de registro basados en el tamaño, systemd-journald también permite criterios basados en el tiempo utilizando las dos opciones siguientes: MaxRetentionSec= y MaxFileSec=. Consulte la página de manual de journald.conf para más información sobre estas y otras opciones.

Note

Siempre que modifiques el comportamiento por defecto de systemd-journald descomentando y editando opciones en /etc/systemd/journald.conf, debes reiniciar el demonio para que los cambios surtan efecto.

Limpiando el Journal

Puede limpiar manualmente los ficheros de diario archivados en cualquier momento con cualquiera de las tres opciones siguientes:

--vacuum-time=

Esta opción basada en el tiempo eliminará todos los mensajes de los archivos de diario con una marca de tiempo más antigua que el marco temporal especificado. Los valores deben escribirse con cualquiera de los siguientes sufijos s, m, h, días (o d), meses, semanas (o w) y años (o y). Por ejemplo, para eliminar todos los mensajes de los ficheros de diario archivados que tengan más de un mes de antigüedad:

root@debian:~# journalctl --vacuum-time=1m
Deleted archived journal /var/log/journal/7203088f20394d9c8b252b64a0171e08/system@27dd08376f71405a91794e632ede97ed-0000000000000001-00059475764d46d6.journal (16.0M).
Deleted archived journal /var/log/journal/7203088f20394d9c8b252b64a0171e08/user-1000@e7020d80d3af42f0bc31592b39647e9c-000000000000008e-00059479df9677c8.journal (8.0M).
--vacuum-size=

Esta opción basada en el tamaño borrará los ficheros de diario archivados hasta que ocupen un valor inferior al tamaño especificado. Los valores deben escribirse con cualquiera de los siguientes sufijos: K, M, G o T. Por ejemplo, para eliminar los ficheros de diario archivados hasta que estén por debajo de 100 Mebibits:

root@debian:~# journalctl --vacuum-size=100M
Vacuuming done, freed 0B of archived journals from /run/log/journal/9a32ba45ce44423a97d6397918de1fa5.
--vacuum-files=

Esta opción se encargará de que no queden más ficheros de diario archivados que el número especificado. El valor es un número entero. Por ejemplo, para limitar el número de ficheros de diario archivados a 10:

root@debian:~# journalctl --vacuum-files=10
Vacuuming done, freed 0B of archived journals from /run/log/journal/9a32ba45ce44423a97d6397918de1fa5.

La aspiración sólo elimina los archivos del diario archivados. Si quiere deshacerse de todo (incluidos los archivos de diario activos), debe utilizar una señal (SIGUSR2) que solicite la rotación inmediata de los archivos de diario con la opción --rotate. Otras señales importantes pueden ser invocadas con las siguientes opciones:

--flush (SIGUSR1)

Solicita el volcado de los archivos del diario desde /run/ a /var/ para que el diario sea persistente. Requiere que el registro persistente esté habilitado y que /var/ esté montado.

--sync (SIGRTMIN+1)

Se utiliza para solicitar que todos los datos de registro no escritos se escriban en el disco.

Note

Para comprobar la consistencia interna del archivo del diario, utilice journalctl con la opción --verify. Verá una barra de progreso mientras se realiza la comprobación y se mostrará cualquier posible problema.

Recuperación de datos del diario de un sistema de rescate

Como administrador del sistema, puede encontrarse en una situación en la que necesite acceder a los archivos del diario en el disco duro de una máquina defectuosa a través de un sistema de rescate (un CD de arranque o una llave USB que contenga una distribución de Linux en vivo).

journalctl busca los archivos del diario en /var/log/journal/<machine-id>/. Debido a que los ID de las máquinas en los sistemas de rescate y en los sistemas defectuosos serán diferentes, debe utilizar la siguiente opción:

-D </path/to/dir>, --directory=</path/to/dir>

Con esta opción, especificamos una ruta de directorio donde journalctl buscará los archivos del diario en lugar de las ubicaciones por defecto del tiempo de ejecución y del sistema.

Por lo tanto, es necesario que monte el rootfs del sistema defectuoso (/dev/sda1) en el sistema de archivos en modo rescate y proceda a leer los archivos del diario así:

root@debian:~# journalctl -D /media/carol/faulty.system/var/log/journal/
-- Logs begin at Sun 2019-10-20 12:30:45 CEST, end at Sun 2019-10-20 12:32:57 CEST. --
oct 20 12:30:45 suse-server kernel: Linux version 4.12.14-lp151.28.16-default (geeko@buildhost) (...)
oct 20 12:30:45 suse-server kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-4.12.14-lp151.28.16-default root=UUID=7570f67f-4a08-448e-aa09-168769cb9289 splash=>
oct 20 12:30:45 suse-server kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
oct 20 12:30:45 suse-server kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
(...)

Otras opciones que pueden ser útiles en este escenario son:

-m, --merge

Combina las entradas de todos los diarios disponibles en /var/log/journal, incluidos los remotos.

--file

Mostrará las entradas de un archivo específico, por ejemplo: journalctl --file /var/log/journal/64319965bda04dfa81d3bc4e7919814a/user-1000.journal.

--root

Se pasa como argumento una ruta de directorio que significa el directorio raíz. journalctl buscará allí los archivos del diario (por ejemplo, journalctl --root /faulty.system/).

Consulte la página de manual de journalctl para obtener más información.

Reenvío de datos de registro a un demonio syslog tradicional

Los datos de registro del diario pueden ponerse a disposición de un demonio syslog tradicional:

  • Reenvío de mensajes al fichero socket /run/systemd/journal/syslog para que lo lea syslogd. Esta facilidad se activa con la opción ForwardToSyslog=yes.

  • Tener un demonio syslog que se comporte como journalctl, por lo tanto leyendo los mensajes de registro directamente de los archivos del diario. En este caso, la opción relevante es la de Storage; debe tener un valor distinto de none.

Note

Asimismo, puedes reenviar los mensajes de registro a otros destinos con las siguientes opciones: ForwardToKMsg (buffer de registro del kernel — kmsg), ForwardToConsole (la consola del sistema) o ForwardToWall (todos los usuarios conectados a través de wall). Para más información, consulte la página man de journald.conf.

Ejercicios guiados

  1. Asumiendo que eres root, completa la tabla con el comando journalctl apropiado:

    Propósito Comando

    Imprimir entradas del kernel


    Imprimir los mensajes del segundo arranque empezando por el principio del diario


    Imprimir los mensajes del segundo arranque comenzando por el final del diario


    Imprimir los mensajes más recientes del diario y seguir vigilando los nuevos


    Imprime sólo los mensajes nuevos desde ahora, y actualiza la salida continuamente


    Imprime los mensajes del arranque anterior con prioridad de advertencia y en orden inverso


  2. El comportamiento del demonio del diario en relación con el almacenamiento está controlado principalmente por el valor de la opción Storage en /etc/systemd/journald.conf. Indique qué comportamiento está relacionado con qué valor en la siguiente tabla:

    Comportamiento Almacenamiento=automático Almacenamiento=ninguno Almacenamiento=persistente Almacenamiento=volátil

    Los datos del registro se desechan pero es posible el reenvío.





    Una vez que el sistema ha arrancado, los datos de registro se almacenarán en /var/log/journal. Si no está presente, se creará el directorio.





    Una vez arrancado el sistema, los datos de registro se almacenarán en /var/log/journal. Si no está presente, el directorio no se creará.





    Los datos de registro se almacenarán en /var/run/journal pero no existiran después de los reinicios.





  3. Como ha aprendido, el diario se puede vaciar manualmente en función del tiempo, el tamaño y el número de archivos. Complete las siguientes tareas utilizando journalctl y las opciones apropiadas:

    • Compruebe cuánto espacio de disco ocupan los archivos del diario:


    • Reducir la cantidad de espacio reservado para los ficheros de diario archivados y fijarlo en 200MiB:


    • Vuelva a comprobar el espacio en disco y explique los resultados:


Ejercicios de exploración

  1. ¿Qué opciones deberías modificar en /etc/systemd/journald.conf para que los mensajes sean reenviados a /dev/tty5? ¿Qué valores deberían tener las opciones?



  2. Proporcione el filtro correcto journalctl para imprimir lo siguiente:

    Propósito Filtro + Valor

    Imprimir los mensajes de un usuario específico


    Imprimir mensajes de un host llamado debian


    Imprimir mensajes de un grupo específico


    Imprime los mensajes que pertenecen a root


    Basado en la ruta del ejecutable, imprime los mensajes de sudo


    Basado en el nombre del comando, imprime los mensajes de sudo


  3. Al filtrar por prioridad, los registros con una prioridad superior a la indicada también se incluirán en el listado; por ejemplo, el comando journalctl -p err imprimirá los mensajes de error, crítico, alerta y emergencia. Sin embargo, puedes hacer que journalctl muestre sólo un rango específico. ¿Qué comando usarías para que journalctl imprima sólo los mensajes de los niveles de prioridad warning, error y critical?


  4. Los niveles de prioridad también se pueden especificar numéricamente. Vuelva a escribir el comando del ejercicio anterior utilizando la representación numérica de los niveles de prioridad:


Resumen

En esta lección aprendió:

  • Las ventajas de utilizar systemd como gestor de sistemas y servicios.

  • Los fundamentos de las unidades y objetivos de systemd.

  • De donde systemd-journald obtiene los datos de registro.

  • Las opciones que puedes pasar a systemctl para controlar systemd-journald: start, status, restart y stop.

  • Donde se encuentra el archivo de configuración del diario — /etc/systemd/journald.conf  — y sus principales opciones.

  • Como consultar el diario de forma general y para datos específicos mediante el uso de filtros.

  • Como navegar y buscar en el diario.

  • Como tratar el almacenamiento de los archivos del diario: en memoria o en disco.

  • Como desactivar el diario por completo.

  • Como comprobar el espacio de disco ocupado por el diario, aplicar límites de tamaño a los archivos del diario almacenados y limpiar manualmente los archivos del diario archivados (vacumming).

  • Como recuperar los datos del diario desde un sistema de rescate.

  • Como reenviar los datos de registro a un demonio syslog tradicional.

Comandos usados en esta lección:

systemctl

Controla el sistema systemd y el gestor de servicios.

journalctl

Consultar el diario systemd.

ls

Lista el contenido de un directorio.

less

Ver el contenido del archivo.

mkdir

Hacer directorios.

Respuestas a los ejercicios guiados

  1. Asumiendo que eres root, completa la tabla con el comando journalctl apropiado:

    Propósito Comando

    Imprimir entradas del kernel

    journalctl -k o journalctl --dmesg

    Imprimir los mensajes del segundo arranque empezando por el principio del diario

    journalctl -b 2

    Imprimir los mensajes del segundo arranque comenzando por el final del diario

    journalctl -b -2 -r or journalctl -r -b -2

    Imprimir los mensajes más recientes del diario y seguir vigilando los nuevos

    journalctl -f

    Imprime sólo los mensajes nuevos desde ahora, y actualiza la salida continuamente

    journalctl --since "now" -f

    Imprime los mensajes del arranque anterior con prioridad de advertencia y en orden inverso

    journalctl -b -1 -p warning -r

  2. El comportamiento del demonio del diario en relación con el almacenamiento está controlado principalmente por el valor de la opción Storage en /etc/systemd/journald.conf. Indique qué comportamiento está relacionado con qué valor en la siguiente tabla:

    Comportamiento Almacenamiento=automático Almacenamiento=ninguno Almacenamiento=persistente Almacenamiento=volátil

    Los datos del registro se desechan pero es posible el reenvío.


    x



    Una vez que el sistema ha arrancado, los datos de registro se almacenarán en /var/log/journal. Si no está presente, se creará el directorio.



    x


    Una vez arrancado el sistema, los datos de registro se almacenarán en /var/log/journal. Si no está presente, el directorio no se creará.

    x




    Los datos de registro se almacenarán en /var/run/journal pero no existiran después de los reinicios.




    x

  3. Como ha aprendido, el diario se puede vaciar manualmente en función del tiempo, el tamaño y el número de archivos. Complete las siguientes tareas utilizando journalctl y las opciones apropiadas:

    • Compruebe cuánto espacio de disco ocupan los archivos del diario:

      journalctl --disk-usage
    • Reducir la cantidad de espacio reservado para los ficheros de diario archivados y fijarlo en 200MiB:

      journalctl --vacuum-size=200M
    • Vuelve a comprobar el espacio en disco y explique los resultados:

      journalctl --disk-usage

      No hay correlación porque --disk-usage muestra el espacio ocupado tanto por los ficheros de diario activos como por los archivados, mientras que --vacuum-size sólo se aplica a los ficheros archivados.

Respuestas a los ejercicios de exploración

  1. ¿Qué opciones deberías modificar en /etc/systemd/journald.conf para que los mensajes sean reenviados a /dev/tty5? ¿Qué valores deberían tener las opciones?

    ForwardToConsole=yes
    TTYPath=/dev/tty5
  2. Proporcione el filtro correcto journalctl para imprimir lo siguiente:

    Propósito Filtro + Valor

    Imprimir los mensajes de un usuario específico

    _ID=<user-id>

    Imprimir mensajes de un host llamado debian

    _HOSTNAME=debian

    Imprimir mensajes de un grupo específico

    _UID=<group-id>

    Imprime los mensajes que pertenecen a root

    _UID=0

    Basado en la ruta del ejecutable, imprime los mensajes de sudo

    _EXE=/usr/bin/sudo

    Basado en el nombre del comando, imprime los mensajes de sudo

    _COMM=sudo

  3. Al filtrar por prioridad, los registros con una prioridad superior a la indicada también se incluirán en el listado; por ejemplo, el comando journalctl -p err imprimirá los mensajes de error, crítico, alerta y emergencia. Sin embargo, puedes hacer que journalctl muestre sólo un rango específico. ¿Qué comando usarías para que journalctl imprima sólo los mensajes de los niveles de prioridad warning, error y critical?

    journalctl -p warning..crit
  4. Los niveles de prioridad también se pueden especificar numéricamente. Vuelva a escribir el comando del ejercicio anterior utilizando la representación numérica de los niveles de prioridad:

    journalctl -p 4..2

© 2020 Linux Professional Insitute Inc. Todos los derechos reservados. Visite el sitio web de Learning Materials: https://asir.sudo.es/docnux/learning.lpi.org
Este trabajo está registrado bajo la Licencia Internacional Creative Commons Attribution-NonCommercial-NoDerivatives 4.0

Siguiente lección

108.3 Conceptos básicos del Agente de Transferencia de Correo (108.3 Lección 1)

Leer la próxima lección

© 2020 Linux Professional Insitute Inc. Todos los derechos reservados. Visite el sitio web de Learning Materials: https://asir.sudo.es/docnux/learning.lpi.org
Este trabajo está registrado bajo la Licencia Internacional Creative Commons Attribution-NonCommercial-NoDerivatives 4.0

LPI es una organización sin fines de lucro.

Linux Professional Institute (LPI) es la organización global de certificación y apoyo académico para profesionales de código abierto. Con más de 200,000 titulares de certificación, es el primer y más grande organismo de certificación no comercial del mundo para Linux y Open Source. LPI cuenta con profesionales certificados en más de 180 países, realiza exámenes en varios idiomas y tiene cientos de socios de capacitación.

Nuestro propósito es hacer que las oportunidades económicas y creativas estén disponibles para todos, haciendo que el conocimiento de código abierto y la certificación sea universalmente accesible.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Contáctenos
  • Política de privacidad y cookies

¿Detecta un error o desea ayudar a mejorar esta página? Por favor háznoslo saber.

© Copyright 1999-2020 The Linux Professional Institute Inc. Todos los derechos reservados.