SYSTEMD

Grupo: VSP Jacobo Fiaño Rodríguez jacobo.fiano1@udc.es Emilio Martínez Varela emilio.martinez.varela@udc.es Sergio Piñeiro Bermúdez sergio.pineiro@udc.es Samuel Santos Espido samuel.santos@udc.es Vanesa Sánchez Pardal vanesa.sanchez.pardal@udc.es

Índice

Introducción a Systemd ............................................................................................ 2

Ventajas y desventajas ....................................................................................................3

Adopción .........................................................................................................................4

Introducción a la configuración de Systemd.............................................................. 4

Instalación .......................................................................................................................5

Configuración de arranque ...............................................................................................5

Configuración ..................................................................................................................6 Identificador de la máquina ................................................................................................................ 6 Nombre del equipo ............................................................................................................................. 6 Idioma del sistema .............................................................................................................................. 6 Fecha y hora ........................................................................................................................................ 8 Inicio de sesión .................................................................................................................................... 9 Sistema .............................................................................................................................................. 10 Modos de ahorro de energía ............................................................................................................. 11 Cargar módulos automáticamente ................................................................................................... 12 Conexión de red ................................................................................................................................ 12 Archivos de registro........................................................................................................................... 15

Registros ................................................................................................................17

Registros de log en Systemd ........................................................................................... 17

Opciones de filtrado ...................................................................................................... 18

Puntos de montaje..................................................................................................19

Montaje con systemd .................................................................................................... 19

Fichero de unidad .mount .............................................................................................. 21

Montar Discos con Systemd ........................................................................................... 21

Ficheros de unidad .automount ..................................................................................... 22

UNITS1 ...................................................................................................................23

Introducción a UNITS1 ................................................................................................... 23

Tipos de UNITS .............................................................................................................. 23

Estados ......................................................................................................................... 24

UNIT FILES ..................................................................................................................... 25

Nuestra UNIT ................................................................................................................. 27

Conclusión ..............................................................................................................29

Introducción a Systemd

Systemd es un gestor de arranque y de servicios para Linux desarrollado principalmente por Lennart Poettering. Systemd es compatible con scripts Sysv o init. A diferencia de initscripts el gestor de inicio default en ArchLinux utiliza un método de paralelización agresiva que hace uso de los procesadores modernos multinúcleo para iniciar procesos y demonios en paralelo real y así tener una gestión de inicio más rápida y limpia. Además de realizar paralelización de procesos también hace lo siguiente:

- Usa Dbus y Sockets para activar servicios - Puede ejecutar daemons por demanda - Optimiza el uso de recursos utilizando cgroups - Soporta snapshots y restauración del sistema a un punto definido - Administra puntos de montaje y montaje de unidades de almacenamiento

Systemd es un entorno capaz de manejar, dentro de la misma herramienta, cada una de las partes en las que se divide un sistema GNU/Linux con su propia administración y lógica. Estas partes son los servicios o daemons que corren ciertos programas de fondo, los puntos de montaje con permisos y usuarios, así como dbus, los sockets que escuchan protocolos y órdenes. Systemd trabaja con unidades, un archivo que contiene información acerca de un servicio, un socket, un punto de montaje o de automontaje, un swap o simplemente un punto de inicio de una aplicación o script iniciada por systemd. La sintaxis está inspirada en la especificación de los archivos .desktops utilizados para lanzar las aplicaciones de cualquiera de los programas de cualquier escritorio Linux.

Arquitectura de Systemd

Ventajas y desventajas

Entre las ventajas de systemd se encuentra:

- Hace que los procesos de arranque sean mucho más sencillos, eliminando la necesidad de satisfacer dependencias (sysvinit) gracias a D-Bus, su activación de socket y la integración de udev.

- Systemd es muy rápido (tarda aproximadamente 1 segundo para arrancar). Para reducir el tiempo de inicio del sistema, los objetivos de systemd son:

- Iniciar la menor cantidad de procesos posible. - Iniciar tantos procesos como sea posible en paralelo.

Nótese que no fue diseñado con la velocidad en mente, pero haciendo sus cosas correctamente evita cualquier retraso incurrido por el proceso de arranque.

- Systemd utiliza los cgroups de Linux para rastrear y administrar el ciclo de vida del proceso y así completar la tarea de seguimiento. Al detener el servicio y consultar cgroups, systemd puede garantizar que se encuentren todos los procesos relevantes, deteniendo así el servicio limpiamente.

- Extiende las funciones del registro del sistema de muchas maneras con la herramienta journald y este puede ser integrado perfectamente con el demonio de rsyslog.

- La puesta en marcha y el monitoreo de servicios centralizado de systemd facilitan mucho la configuración de alta disponibilidad con software como un marcapasos.

Por otra parte, sus desventajas son las siguientes:

- No es portátil. Mantener un sistema con systemd y otros inits es más trabajo ya que se necesita configurar ambos y no se puede usar solo un script de sysv.

- Los archivos de la herramienta journald se almacenan como binarios por ende deben de ser consultados utilizando “journalctl”, esto es un problema ya que archivos muy grandes pueden causar caídas en sistemas de recursos limitados y para más inri esto los vuelve altamente corruptibles.

- Todos los demonios están muy agrupados e integrados, lo que dificulta la sustitución por alternativas más ligeras o cómodas para ciertos usuarios, además de que no ofrece la capacidad para crear su propio motor de políticas de cgroup.

- Controla muchas cosas, al seguir la filosofía UNIX se asegura que haga una sola cosa y la haga bien, el problema se da cuando el software hace varias cosas ya que hay que revisar minuciosamente el error, dónde está y verificar por qué está fallando.

Adopción

En mayo de 2011, Fedora se convirtió en la primera distribución principal de Linux en habilitar systemd por defecto.

Distribuciones en las que systemd está habilitado de forma predeterminada:

● Debian GNU/Linux desde la versión 8 "Jessie".

● Fedora 15 y superior.

● Frugalware 1.5 y superior.

● Mageia desde la versión 2.

● Mandriva 2011.

● openSUSE 12.1 y superior.

● Arch Linux desde octubre de 2012.

● Siduction desde diciembre de 2013.

● Red Hat Enterprise Linux desde la versión 7, CentOS 7 desde julio de 2014.

● Ubuntu a partir de su versión 15.04 (abril de 2015).

Distribuciones en las que systemd está disponible:

● Gentoo ofrece paquetes systemd como elementos no soportados oficialmente.

Introducción a la configuración de Systemd

El proceso de configuración puede variar dependiendo del sistema operativo, así que en caso de querer aplicarlo a otros sistemas operativos estad atentos a las posibles diferencias que puedan existir, esta guía intenta ser genérica para facilitar su utilización.

Antes comenzar la explicación sobre la configuración vamos a introducir los comandos básicos que se utilizan en systemd:

- systemctl: es el comando utilizado para controlar los módulos de systemd y monitorizar su desempeño.

- hostnamectl: administra el nombre del equipo. - localectl: administra el idioma y formatos de texto. - datetimectl: administra la fecha y hora del sistema. - loginctl: controla el estado de los inicios de sesión. - journalctl: controla el diario de los eventos registrados del sistema.

Instalación

Para instalar systemd (en caso de que no venga ya instalado en nuestro sistema operativo) debemos descargar e instalar el paquete correspondiente, que es el siguiente: “systemd”. Comprobar que tengamos todo el sistema actualizado para evitar posibles fallos o incompatibilidades. Recalcar el hecho de que es para un caso en el que no tengamos systemd instalado, como las distribuciones “Gentoo” que dan esta posibilidad.

Configuración de arranque

Al igual que en el apartado anterior los cambios descritos a continuación solo tienen sentido si no teníamos instalado systemd y lo instalamos a posteriori, para así poder arrancar el sistema con systemd directamente. Tenemos que cambiar el “init” de la línea de arranque de nuestro kernel en el grub para poder arrancar systemd. El proceso varía según si es grub 1 o 2, para eso tenemos los pasos a seguir desglosados:

Para grub 1 abrimos el archivo “/boot/grub/grub.conf” y lo agregamos de la siguiente forma:

title= Con systemd root (hd0,0) kernel /vmlinuz root=/dev/sda2 init=/usr/lib/systemd/system Si a pesar de cambiar esto siguiese sin funcionar, cambiar “init” por “real_init”. En el caso de grub 2 abrimos el archivo “/etc/default/grub” y agregamos del siguiente modo: GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd" Finalmente, solo nos queda actualizar el grub con el siguiente comando “grub-mkconfig -o /boot/grub/grub.cfg”. Actualizar Systemd nos permite actualizarlo durante el tiempo de ejecución (sin necesidad de reiniciar la máquina), para ello usaremos “systemctl daemon-reexec” cuando hayamos instalado una actualización para no tener la necesidad de reiniciar la máquina.

Configuración

Systemd soporta algunos archivos de configuración para ajustar ciertos detalles básicos del sistema, a continuación, mostraremos algunos de ellos. Las capturas de los ejemplos han sido realizadas desde una máquina virtual con Debian 10.

Identificador de la máquina

Crearle un identificador a la máquina nos permitirá que funcione el “journaling” (el sistema de registro diario), esto se puede realizar simplemente con el comando “systemd-machine-id-setup”. Podemos observar la id de nuestra máquina en el archivo “/etc/machine-id”. Esto en caso de que no tengamos ya un identificador.

Contenido del fichero “/etc/machine-id”

Nombre del equipo

Para establecer el nombre del equipo tenemos que crear, o en caso de que ya exista editar, el fichero “/etc/hostname” y lo que tenemos que hacer es simplemente introducir el nombre deseado para nuestro equipo. Estas acciones se encargan de llevarlas a cabo “systemd-hostnamed.service”.

También disponemos de un comando para realizar esta acción en tiempo de ejecución que es “hostnamectl set-hostname <NOMBRE_DESEADO>”. También puede usarse para consultarse el nombre actual e información relacionada con “hostnamectl status”.

Contenido del fichero “/etc/hostname” y resultado del comando “hostnamectl”

Idioma del sistema

Se encarga de la configuración del idioma de todo el sistema, es leído al inicio en una etapa temprana del arranque. Se trata del fichero “/etc/locale.conf”.

El formato de este archivo es una lista separada por saltos de línea de asignaciones de variables compatibles con el entorno. A continuación, mostraremos unos ejemplos de dichas variables que se pueden usar en este archivo además del LANG básico:

- LANGUAGE: idioma del sistema. - LC_NUMERIC: valores numéricos no monetarios. - LC_TIME: formato utilizado para la fecha y hora. - LC_COLLATE: rige las reglas que se utilizan clasificar expresiones y en las

expresiones regulares. - LC_CTYPE: determina la interpretación de bytes a secuencias de caracteres. - LC_IDENTIFICATION: cambia la configuración relacionada con los metadatos del

locale. - LC_PAPER: cambia la interpretación de las dimensiones estándar de un papel. - LC_MONETARY: el formato de los valores monetarios, - LC_MESSAGES: idioma en el que se muestran los mensajes. - LC_NAME: formatos utilizados para referirse a las personas. - LC_ADDRESS: cambia la forma de describir los formatos utilizados en las

ubicaciones o localizaciones geográficas. - LC_TELEPHONE: formato de los servicios telefónicos. - LC_MEASUREMENT: formato de las unidades métricas. - LC_ALL: constituye todas las categorías anteriores.

Las configuraciones del “/etc/locale.conf” son para todo el sistema y son heredadas por cada servicio o usuario, a menos que individualmente se decida no establecerlas de forma intencionada. Dependiendo del sistema operativo es posible verificar otros archivos de configuración para obtener la configuración regional, esto solamente a modo de respaldo. Este archivo suele ser creado y actualizado por systemd-locale.service. En caso de querer modificarle algún parámetro también podemos usar el comando “localectl” en la línea de comandos, que también sirve para ver la configuración actual.

Contenido del fichero “/etc/locale.conf” y resultado del comando “localectl”

Fecha y hora

La fecha y hora del sistema se pueden administrar con el comando timedatectl que maneja ese aspecto además del servicio de sincronización de la hora. Tenemos diferentes comandos para usar y modificar varios apartados (siempre tenemos la posibilidad de usar “datetimectl –help” para verlos todos):

- datetimectl status: para mostrar la configuración actual. - datetimectl set-time [TIME]: cambia la hora del sistema por la introducida. - datetimectl set-timezone [TIMEZONE]: establece una zona horaria. - datetimectl set-ntp [BOOL]: si se le pasa un true como argumento activa la

sincronización horaria y en caso de un false la desactiva. - datetimectl set-local-rtc [BOOL]: si se le pasa un “0” mantendrá el rtc (real time

clock) en hora universal, si se le pasa un “1” será en hora local.

Resultado del comando “timedatectl”

En cuanto al servicio de la red NTP para la sincronización tenemos el fichero “/etc/systemd/timesyncd.conf” que se encarga de configurar ciertos aspectos de la sincronización. Tiene una única sección “[Time]” con las siguientes opciones:

- NTP: una lista separada por espacios con las IPs o nombres de los servidores NTP. - FallBackNTP: una lista separada por espacios con las IPs o nombres de los

servidores NTP de reserva. - RootDistanceMaxSec: la distancia máxima aceptable con el servidor NTP para

que el tiempo requerido para recibir los paquetes no sea muy elevado y nos reste precisión.

- PollIntervalMinSec, PollIntervalMaxSec: los intervalos de sondeo mínimo y máximo para mensajes NTP.

- ConnectionRetrySec: especifica el retraso mínimo antes de intentar contactar con un nuevo servidor NTP.

Contenido del fichero “/etc/systemd/timesyncd.conf”

Inicio de sesión

El servicio encargado de administrar los inicios de sesión de los usuarios es systemd-logind. Para su configuración nos iremos al fichero “/etc/systemd/logind.conf”, que contiene una única sección llamada “[Login]” que contiene distintas opciones de configuración:

- HandlePowerKey, HandleSuspendKey, HandleHibernateKey, HandleLidSwitch, HandleLidSwitchExternalPower, HandleLidSwitchDocked y HandleRebootKey: todas estas opciones controlan como “logind” manejará la alimentación del sistema, las teclas de encendido y suspensión, y la tapa en caso de tener. Disponemos de varias opciones para asignarle como “poweroff”, “reboot”, “ignore”, “halt”, “suspend”, “hibernate”…

- NAutoVTs: toma un número entero y configura cuantos terminales virtuales asignar.

- SessionsMax: controla el número máximo de sesiones de usuario simultáneas a administrar. El valor predeterminado es 8192 (8K).

- KillUserProcesses: recibe un booleano y configura si los procesos de un usuario deben eliminarse cuando el usuario cierra sesión.

- IdleAction: configura la acción a realizar cuando el sistema está inactivo, tiene varias opciones “poweroff”, “reboot”, “ignore”, “halt”, “suspend”, “hibernate”… El valor predeterminado es “ignore”.

Estos son solo algunos de las opciones disponibles para aplicar los cambios usaremos “systemctl enable systemd-logind.service” y “systemctl start systemd-logind.service” y en caso de que ya esté iniciado “systemctl restart systemd-logind.service”. También podemos usar “loginctl” para controlar el estado del sistema de inicio de sesión, como listar las sesiones actuales “loginctl list-sessions” o la lista de usuarios actuales “loginctl list-users”.

Contenido del fichero “/etc/systemd/logind.conf” y resultado de los comandos “loginctl list-sessions” y “loginctl list-users”

Sistema

Para la configuración general del sistema tenemos los archivos “/etc/systemd/system.conf” y “/etc/systemd/user.conf”, ambos ficheros contienen prácticamente lo mismo que es la configuración que controlan algunas de las operaciones básicas del administrador. Cuando se ejecuta como instancia del sistema systemd lee el archivo “system.conf” en caso de que haya algún problema leyendo dicho archivo leería el “user.conf”. Solamente hay una sección llamada “[Manager]” que contiene las siguientes opciones entre otras:

- LogLevel, LogTarget, LogColor, LogLocation, DumpCore=yes, CrashShell=no, ShowStatus=yes, CrashChVT=1, DefaultStandardOutput=journal, DefaultStandardError=inherit: todas estas son opciones básicas del administrador que pueden ser anuladas mediante argumentos en la línea de comandos.

- CPUAffinity: configura la afinidad inicial de la CPU para el proceso “init”. Coge una lista de índices o rangos de la CPU separada por espacios.

- CtrlAltDelBurstAction: define que acción se desencadena si se pulse el botón Ctrl+Alt+Delete más de 7 veces en menos de 2 segundos. Se le puede asignar: “reboot-force”, “poweroff-force”, “reboot-inmediate”, “poweroff-inmediate” o “none”. La opción por defecto es “reboot-force”.

Contenido del fichero “/etc/systemd/system.conf”

Modos de ahorro de energía

Tenemos el archivo “/etc/systemd/sleep.conf” que se configura el funcionamiento de “systemd-sleep” que se encarga de los modos de ahorro de energía:

- Suspender: estado de bajo consumo de energía, en el que el sistema operativo está pausado y la pérdida total de energía puede suponer la pérdida de datos. Es rápido para entrar y salir.

- Hibernar: estado de bajo consumo de energía, en el que el sistema operativo está pausado y la pérdida total de energía no resulta en la pérdida de datos. Es lento para entrar y salir.

- Sueño-híbrido: estado de bajo consumo de energía, en el que el sistema operativo está pausado y puede ser lento para entrar, pero la pérdida total de energía no resulta en la pérdida de datos, aunque en ese caso puede resultar lento para salir.

- Suspender-después-hibernar: estado de bajo consumo de energía, en el que el sistema se suspende inicialmente y si pasado el tiempo establecido en “HibernateDelaySec” se pasa a modo hibernación.

Tiene una única sección “[Sleep]” que contiene las siguientes opciones: - AllowSuspend, AllowHibernation, AllowSuspendThenHibernate y

AllowHybridSleep : estos botones sirven para deshabilitar diferentes modos, ya que por defecto están activados

- SuspendMode, HibernateMode y HybridSleepMode: se introduce un string que será escrito en /sys/power/disk.

- SuspendState, HibernateState y HybridSleepState: se introduce un string que será escrito en /sys/power/state.

- HibernateDelaySec: especifica la cantidad de tiempo que pasa el sistema en modo suspensión antes de que se pase automáticamente a modo hibernación.

Contenido del fichero “/etc/systemd/sleep.conf”

Cargar módulos automáticamente

Para configurar los módulos que se cargarán automáticamente en el sistema tenemos que irnos al “/etc/modules-load.d”. Al arrancar la máquina se carga cada archivo que contiene una lista de módulos. El formato de cada archivo es una lista de módulos separados por una coma y un salto de línea, le podemos poner el nombre que queramos al archivo con la salvedad de que acabe en “.conf”. Se pueden agrupar por programa, servicio o por preferencias personales, un ejemplo sería los módulos de virtualbox.conf:

/etc/modules-load.d/virtualbox.conf

vboxdrv vboxnetflt vboxnetadp vboxpci

Conexión de red

Tenemos dos herramientas para administrar las conexiones de red, la primera será “systemd-networkd”, para usarla crearemos un archivo “.network” en “/etc/systemd/network” que se compone de un campo “[Match]” y uno “[Network]” principalmente.

En “[Match]” podemos encontrarnos entre muchas otras las siguientes opciones:

- Name: nombre del dispositivo. - MacAddress: lista de direcciones de hardware separadas por espacios en blanco

y delimitadas por dos puntos, puntos o comas. - Host: coincide con el nombre o ID de la máquina.

Solo se aplica el primero que se encuentre en orden léxico, todos los demás se ignoran. En “[Network]” tenemos las siguientes opciones de configuración entre muchas otras:

- Description: un texto a modo de información. - DHCP: habilita la compatibilidad con DHCP, acepta los argumentos “yes”, “no”,

“ipv4” o “ipv6”, el valor por defecto es “no”. - DHCPServer: si se establece “yes” se iniciará el servidor de DHCP. - LinkLocalAddressing: habilita la autoconfiguración de la dirección local de enlace. - Address: una dirección IPV4 o IPV6 estática. - Gateway: dirección de la puerta de enlace. - DNS: dirección del servidor de DNS.

Un ejemplo de una interfaz de red con una IP estática y otra configurada por DHCP sería:

Contenido del fichero “/etc/systemd/network/10-ip-static.network” y “/etc/systemd/network/50-dhcp.network”

A continuación, usaríamos “systemctl enable systemd-networkd.service” y “systemctl start systemd-networkd.service” o en caso de ya estar iniciado “systemctl restart systemd-networkd.service”. Hay que tener en cuenta que system-networkd no actualiza el “resolv.conf” para administrar la configuración DNS por lo que hay que sustituirlo por un enlace simbólico, configurar y activar “/etc/systemd/resolved.conf”. El archivo “resolved.conf” consiste en una única sección [Resolve] que puede tener algunas de las siguientes opciones:

- DNS: una lista con las direcciones IP de los servidores de DNS. - FallbackDNS: una lista con las IPs de los servidores de respaldo. - DNSSEC: recibe un booleano si es verdadero activa DNSSEC para validar las

peticiones DNS lo cual añade una penalización en el tiempo de búsqueda, si es falso estará desactivado.

- Caché: recibe un booleano si es verdadero guardará las traducciones realizadas en caché para no volver a buscarlas en caso de que se solicite la misma dirección mientras siga siendo válida, si es falso estará desactivado.

Contenido del fichero “/etc/systemd/resolved.conf”

ln -snf /etc/systemd/resolved.conf /etc/resolv.conf systemctl enable systemd-resolved.service systemctl start systemd-resolved.service También tenemos el archivo de configuración “/etc/systemd/networkd.conf” que se encarga de los parámetros globales de la red, actualmente del DHCP Unique Identifier (DUID). En su sección “[DHCP]” podemos configurar las siguientes opciones:

- DUIDType: especifica como debe ser generado el DUID, hay tres opciones “vendor”, “uuid” y “link-layer-time”.

- DUIDRawData: especifica el valor DUID como una única cadena hexadecimal, terminada en un salto de línea y separada por “:”.

Contenido del fichero “/etc/systemd/networkd.conf”

La segunda herramienta que tenemos es “NetworkManager”, que usaremos el fichero “/etc/network/interfaces” para las interfaces de red, tendrá este formato:

Contenido del fichero “/etc/network/interfaces.d/setup” Después de configurar las interfaces usaremos el comando “systemctl enable NetworkManager” y “systemctl start NetworkManager” o en caso de ya tener iniciado el servicio “systemctl restart NetworkManager” para aplicar los cambios activando el servicio de “NetworkManger”. Para el DNS usaremos el archivo “/etc/resolv.conf” que contiene las direcciones IP de los servidores de nombres con este formato:

Contenido del fichero “/etc/resolv.conf”

Archivos de registro

Systemd tiene su propia forma de manejar los registros sin utilizar los típicos sistemas de registro externos de syslog y rsyslog. Los mensajes se pueden leer con “journalctl”, aun así, es posible configurar systemd de modo que use alguna herramienta externa para que se encargue del manejo de los registros. El servicio de registro integrado de systemd escribe mensajes de registro en un formato binario seguro. Los registros se leen mediante el comando “journalctl”, que es un ejecutable independiente del servicio de registro “systemd-journald”.

El archivo para configurar el “systemd-journald.service” está en “/etc/systemd/journald.conf” en el cual podemos activar diferentes opciones en la única sección que hay “[Journal]”, sobre cómo se guardan los eventos registrados en el sistema por defecto (ya que luego podemos crear ficheros de configuración para aplicar efectos concretos a servicios seleccionados):

- Storage: controla dónde almacenar los datos del diario. - Compress: puede tomar un valor booleano, si está activado los datos que

superen el tamaño predeterminado (512 bytes) serán comprimidos antes de ser escritos en el sistema de archivos. También podemos establecer el umbral nosotros mismos.

- ForwardToSyslog, ForwardToKMsg, ForwardToConsole y ForwardToWall: controla si los mensajes de los eventos del diario se redirigen al syslog tradicional, al búfer de registro del kernel, a la consola del sistema o como mensaje de pared a todos los usuarios conectados, respectivamente en ese orden.

- SystemMaxFileSize y RuntimeMaxFileSize: controla el tamaño máximo de los archivos de diario individuales, esto influye en la granularidad en el que el espacio en disco está disponible a través de la rotación, es decir, la eliminación de archivos históricos.

- MaxFileSec: el tiempo máximo para almacenar entradas en un mismo archivo de diario antes de pasar al siguiente.

Para transferir el registro de eventos a otra herramienta externa tenemos dos métodos. El primero consiste en activar la opción “ForwardToSyslog” que si está activada permitirá a syslog leerlos. El segundo método consistiría en que la herramienta externa leyese directamente los archivos de registro, de manera similar a como se comporta “journalctl”. Este método solo es posible si se almacenan los archivos, por lo que si tenemos activada la opción “Storage=none” no será posible. Cabe destacar que el segundo método es el que es habitualmente empleado por las herramientas externas como syslog, por lo que es relevante comprobar los valores asociados a “Storage” y a “ForwardToSyslog”.

Contenido del fichero “/etc/systemd/journald.conf” Cuando se utiliza “systemd-journald.service” de systemd para el registro, que suele ser el valor predeterminado para los sistemas que ejecutan systemd, los usuarios estándar que ejecutan el comando journalctl no podrán ver los registros del sistema, solo los suyos propios. Para ver los registros del sistema como una cuenta no root, los usuarios deben estar en uno de los siguientes tres grupos de usuarios para poder ver los registros del sistema: “systemd-journal”, “adm” o “wheel”. El método más simple para permitir que un usuario estándar vea los registros es usar el grupo “systemd-journal”. Agregue un usuario ejecutando el siguiente comando donde “samu” es el nombre de usuario deseado:

Añadir al usuario “samu” al grupo “systemd-journal” y mostrar que pertenece a dicho grupo después

Los registros del sistema ahora se pueden leer ejecutando “journalctl –system”, para los usuarios agregados con el comando anterior. Si se usa “journalctl” se mostrarán todos los registros desde la entrada más antigua recopilada.

Registros mostrados al usar el comando “journalctl” desde el usuario “samu”

Registros

Registros de log en Systemd

Con systemd existe una gestión centralizada de logs de servicio y kernel a través de la herramienta “journalctl”. Esta herramienta almacena e indexa todos estos logs para permitir al administrador del sistema gestionarlos desde un único punto.

Este servicio recibe información de log desde la siguiente lista de fuentes:

● Mensajes de log del Kernel, vía kmsg

● Mensajes simples del sistema de log, vía las llamadas a libc (syslog)

● Los logs enviados a través del API del sistema Journal.

● Salidas de log estándar y de errores de los servicios.

● Logs de auditoria generados desde el subsistema de auditoria del Kernel

Por defecto el servicio de Journal guarda los datos en archivos binarios bajo la carpeta “/run/log/journal” y estos datos no son persistentes y son almacenados hasta el reinicio del sistema. Para hacer los datos no volátiles podemos modificar el parámetro “Storage” en el fichero “/etc/systemd/journald.conf” o simplemente creando el directorio “/var/log/journal” y posteriormente reiniciando el sistema.

La forma más básica de ejecutar el comando es directamente sin argumentos, lo que presentará los logs genéricos del sistema operativo es decir lo que vemos desde “/var/log/messages” o “/var/log/syslog”.

Podemos filtrar por una fecha determinada para evitar tener que paginar hasta el final:

user:[~]:journalctl --since='2021-01-01 00:00' --until '09:00'

user:[~]:journalctl --since 'yesterday' --until '00:00'

La paginación se hace a través del comando “less”, por lo que todos los atajos de teclado usados en “less” son válidos en “journalctl”.

Se puede limitar el número de entradas de log a mostrar por STDOUT, en el siguiente ejemplo se mostrarían 10 entradas de log:

user:[~]: journalctl -n 10

Opciones de filtrado

Las opciones de filtrado son muy potentes, pues permiten, además de hacerlo por fecha, filtrar por PID, nombre del programa en ejecución, servicio, UID de usuario, etc. Cómo, por ejemplo:

Logs de arranque “/boot”

user:[~]: journalctl -b

Logs de kernel

user:[~]: journalctl -k

Logs de un servicio de systemd

user:[~]: journalctl -u sshd.service

user:[~]: journalctl -f -u apache

user:[~]: journalctl _SYSTEMD_UNIT=avahi-daemon.service

Logs de un PID específico

user:[~]: journalctl _PID=11111

Logs de un usuario (UID)

user:[~]: journalctl _UID=1000

Logs de un programa

user:[~]: journalctl _COMM=dhclient

Logs en formato JSON

user:[~]: journalctl -o json-pretty

Logs por prioridad/severidad de syslog

user:[~]: journalctl -p 2

Combinar varios filtros

user:[~]: journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

user:[~]: journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=28097

Puntos de montaje

Montaje con systemd

Entre todas las grandes funcionalidades que systemd engloba una de ellas es la definición de cómo se deben montar las particiones de disco o cualquier sistema de ficheros de los dispositivos de bloque. Con SysV la definición de cómo montar los sistemas de ficheros se realizaba en el fichero “/etc/fstab”, en el cual se indicaba el uuid de la partición, el punto de montaje, el tipo de sistema de ficheros y más opciones adicionales. Con la llegada de systemd esto cambia a realizarse en los llamados ficheros de unidad, de los que existen diversos tipos. En el caso del montaje de sistemas de ficheros, estos archivos llevan el sufijo .mount. Aun así, systemd ofrece cierta compatibilidad con el anterior método ya que para cada línea definida en el fichero “/etc/fstab” se crea dinámicamente su correspondiente fichero de unidad .mount encargado de montar la partición indicada. Por ejemplo, en esta imagen podemos ver el contenido del fichero citado previamente de nuestra segunda máquina de las prácticas de ASO. En esta podemos ver como se define el montaje de las particiones que contienen el directorio home, el directorio raíz, el directorio ESP y el swap.

Si usamos el comando “systemctl list-unit-files --type=mount” podemos ver todos los ficheros de unidad de tipo .mount y entre ellos podemos diferenciar, por ejemplo, los creados dinámicamente a partir de las entradas mostradas en la imagen anterior, como por ejemplo el home.mount.

Si vemos el contenido del fichero “home.mount” podemos ver en la documentación la página del manual de “systemd-fstab-generator”, el encargado de hacer la conversión del fichero “/etc/fstab” en los ficheros de unidad, el path a dicho fichero, y una serie de dependencias de la unidad. Dentro de la sección “[Mount]” podemos ver las directivas where que indica donde montar la partición, la directiva what, que contiene un link simbólico identificado por la uuid de la partición y la directica type, que indica el tipo de sistema de ficheros.

Fichero de unidad .mount

Los ficheros de unidad mount deben nombrarse siempre como el punto de montaje que controlan, por ejemplo, en las imágenes anteriores veíamos como el fichero .mount que controlaba el punto de montaje “/boot/efi” se llamaba “boot-efi.mount”. La configuración general se realiza de la misma manera que en el resto de los ficheros de unidad en las secciones “[Unit]” y “[Install]2, la configuración específica de estos ficheros se realiza en la sección “[Mount]”, en ella podemos configurar diferentes opciones como:

● What: opción obligatoria que contiene la ruta absoluta al dispositivo a montar.

● Where: opción obligatoria que contiene la ruta absoluta al punto de montaje, debe

coincidir con el nombre del fichero unidad.

● Type: string con el tipo de sistema de ficheros.

● Options: lista de opciones de montaje, este campo es opcional.

● SloppyOptiones: boolean que indica que el análisis de las opciones descritas en el

anterior campo es relajado, por lo que permite opciones desconocidas (si el valor es

true).

● LazyUnmount: boolean que indica la separación del sistema de ficheros y la limpieza de

todas sus referencias a la hora de hacer el desmontaje.

● ReadWriteOnly: boolean que indica que, en caso de que un punto de montaje que deba

montarse en modo read-write falle, se intentará en modo read-only (si es falso).

● ForceUnmount: fuerza el desmontaje en caso de que el NFS sea inalcanzable.

● DirectoryMode: especifica el modo de acceso cuando se están creando los directorios.

● TimeoutSec: establece el tiempo máximo que puede durar el montaje.

Montar Discos con Systemd

Tras ver la sintaxis de este fichero vamos a ver un ejemplo , si queremos montar un nuevo disco de tipo ext4 en el directorio “/mnt/discoB”, los pasos necesarios serían: 1.En el directorio “/etc/systemd/system” debemos crear el fichero “mnt-discoB .mount” que definirá la unidad.

[Unit] Description=Montaje del nuevo disco [Mount] What=/dev/sdb Where=/mnt/discoB Type=ext4 Options=defaults

2.Una vez creado el fichero podemos o bien reiniciar el sistema o reiniciar el demonio con el comando “systemctl daemon-reload” para que systemd detecte la nueva unidad 3.Una vez detectada la iniciamos con el comando “systemctl start discoB.mout”

4.Por último, si queremos montar el disco cada vez que se arranque la máquina podemos hacerlo con el comando “systemctl enable discoB.mount”

Ficheros de unidad .automount

Estos tipos de ficheros de unidad son similares a los ficheros .mount, la forma de nombrarlos sigue la misma regla que los anteriores. Para cada fichero de unidad .automount debe existir su correspondiente fichero .mount, el cual será activado una vez que se acceda al path indicado por el fichero. Por ejemplo, si accedemos al directorio “/home/user1” y existe una unidad automount “home-user1.automount” activa, la unidad mount home-user1.mount será activada. Los principales usos de este tipo de unidades son para realizar el montaje por demanda, montando solo aquellos sistemas a los que se quiere acceder, o bien para realizar el montaje en paralelo. Es por este último objetivo por el cual no se debe configurar en la sección “[Unit]” las dependencias “After” o “Requires”, ya que formaría un ciclo y rompería el paralelismo. Al igual que el resto de los ficheros .unit la configuración global se hace en las secciones “[Unit]” e “[Install]” y la configuración específica en la sección “[Automount]”, donde podemos configurar los siguientes parámetros:

- Where: path absoluto al directorio al punto de automontaje. - DirectoryMode: especifica el modo de acceso al crear los directorios de puntos

automount. - TimeoutIdleSec: activa un timeout para desmontar la unidad.

UNITS1

Introducción a UNITS1

Una unit o unidad en systemd referencia a cualquier recurso que el sistema sabe manejar y operar. Estos recursos son definidos mediante los ficheros de configuración de unidades, unit files. Existen diferentes categorías de unidades dependiendo de los tipos de recursos que describen. La convención de nombrado de las unidades que se establece es: nombre_de_la_unit.tipo_de_unit. A continuación, se detallan los distintos tipos de units que existen:

Tipos de UNITS

.service : describe cómo se maneja un servicio o aplicación en un servidor. .socket : describe un socket IPC o un buffer FIFO que systemd utiliza para realizar una activación por sockets. .device : describe un dispositivo designado por udev o el sistema de archivos sysfs. .mount : define un punto de montaje que será manejado por systemd. .automount : configura un punto de montaje que será montado automáticamente. .swap : describe un espacio de swap en el sistema. .target : agrupa unidades según sus dependencias para proveer puntos de sincronización a otras agrupaciones de unidades en el arranque o en el cambio de estado. .path : define una ruta para poder usar la activación por ruta (una actividad se activa cuando la ruta alcanza un estado concreto). .time : se refiere a un temporizador que se utilizará para activar otra unidad. .snapshot : permite reconstruir el estado del sistema actual después de realizar cambios. .slice : se relacionan con los nodos de control de grupos de Linux, permitiendo que un recurso se asigne a algunos procesos asociados a un determinado slice. .scope : se crean automáticamente a partir de la información recibida por las interfaces de tipo bus. Como se puede apreciar, systemd maneja varias unidades, aunque algunas son usadas como métodos de activación para otras unidades.

Estados

Estas unidades contendrán diferentes estados. Los estados más frecuentes en los que nos podemos encontrar las unidades son:

ESTADO SIGNIFICADO

disable Unidad no configurada para que comience en el arranque.

enabled Unidad que comenzará cuando se arranque la máquina.

masked Unidad desactivada y la cual no podrá ser activada por otra unidad.

indirect Unidad deshabilitada que puede ser habilitada indirectamente por otra unidad.

linked Unidad que está disponible a través de un link simbólico.

bad Unidad con algún tipo de problema con systemd.

generated Unidad generada dinámicamente por su generador.

Para ver información relacionada con las unidades, podremos utilizar el comando “systemctl”. Podemos consultar: Lista de todas las unidades del sistema: systemctl list-unit-files Podremos añadir “--type=” para filtrar por tipo de unidad o incluso “--state=” para filtrar por el estado de la unidad. También podemos ver el unit file de una unidad con: systemctl cat nombre_unidad El estado de una unidad con: systemctl status nombre_unidad Y las dependencias que tiene con otras unidades: systemctl list-dependencies nombre_unidad

UNIT FILES

Llegados a este punto, vamos a ver cómo es la estructura de un fichero de unidad, unit file, donde se define la unit. Estos ficheros tienen una estructura interna organizada en secciones. Estas secciones se denotan con un nombre encapsulado en corchetes. Dentro de las secciones se especifican diferentes directivas de la forma clave-valor, algo así:

[Nombre_sección] Directiva1=valor Directiva2=valor ...

Las distintas secciones que se pueden especificar son: ● Sección [Unit] : Donde se indicarán metadatos relacionados con la unidad y también la relación de dicha unidad con otras unidades. Algunas directivas que se pueden usar son:

- Description : describe el nombre de la unidad y su función básica.

- Documentation : describe dónde se podrá obtener más información sobre la unidad.

- Requires : lista las unidades de las que depende esencialmente la unidad (tienen

que estar activas sino la unidad fallará).

- Before : las unidades listadas en esta directiva no podrán comenzar hasta que la unidad que estamos definiendo se marque como empezada.

- After : la unidad que estamos definiendo no podrá comenzar hasta que las unidades que indiquemos en esta directiva comiencen.

- Conflicts : lista las unidades que no podrán ejecutarse al mismo tiempo que la

unidad que estamos definiendo. Existen más directivas en esta sección como pueden ser: Condition, Assert, BindsTo, Wants ...

● Sección [Tipo_unidad] : Esta sección es específica del correspondiente tipo de servicio de la unidad. Los tipos de unidad que pueden especificar esta sección son: service, socket, mount, automount, swap, path, timer y slice. El resto de los tipos no tendrán esta sección. Nosotros nos vamos a centrar en las unidades de tipo service. Vamos a ver algunas de las directivas más destacadas de esta sección que se configurarían en una unidad de tipo service: [Service] -> Sería el nombre de la sección.

- Type : se indica el tipo de servicio, el cual podrá ser: simple, forking, oneshot, dbus, notify o idle.

- ExecStart : especifica la ruta y los argumentos del comando que se ejecutará para

iniciar el proceso.

- ExecStartPre : indica comandos adicionales que pueden ser ejecutados antes de que el proceso principal comience.

- ExecStartPost : indica comandos adicionales que pueden ser ejecutados después

de que el proceso principal se pare.

- Restart : indica las circunstancias sobre las cuales systemd podrá intentar reiniciar el servicio. Pueden ser valores como “always”, “on-success” …

Existen también otras directivas que son dependientes del tipo de servicio que se indique en la directiva type. ● Sección [Install] : Esta se corresponde con la última sección, la cual determina el comportamiento de las unidades si son marcadas como “enabled” o “disabled”. Algunas de las directivas más destacadas son:

- WantedBy : especifica cómo una unidad puede ser establecida como “enabled”. Permite indicar una relación con otras unidades.

- Alias : permite establecer la unidad como “enabled” mediante el uso de otro

nombre.

- Also : permite establecer un conjunto de unidades a “enabled” o a “disabled”. Otras directivas son: DefaultInstance, RequiredBy …

Nuestra UNIT

Para aclarar más estos conceptos, vamos a realizar la creación de una unit. Vamos a crear una unit de tipo service que se ejecute al iniciar el sistema. El sistema que escogemos es Linux Fedora que instalamos en la práctica 2 en una partición de 13 Gb. Lo que queremos es que una vez se encienda la máquina, comprueba el almacenamiento del sistema y nos escriba en un fichero si nos debemos de preocupar por la capacidad que nos queda disponible.

1. Creamos un ejecutable en Python que va a ser el programa que ejecute el servicio:

#!/usr/bin/python3 import shutil f = open("/home/user001/Desktop/ALERT_STORAGE.txt", "w") total, used, free = shutil.disk_usage("/") #si tiene menos de 1gb de almacenamiento disponible if free<2**30: f.write("ALERTA! Espacio disponible: %.2f GB\n" % (free/2**30)) eles: f.write("Tienes suficiente espacio: %.2f GB\n" % (free/2**30)) f.close()

Lo guardamos como: /usr/bin/storage_alert Le damos permisos de ejecución: chmod 777 /usr/bin/storage_alert

2. Creamos la unit file en el directorio /lib/systemd/system :

Vamos a llamar a la unidad: storage_alert.service. Por lo cual, creamos el fichero storage_alert.service e introducimos la siguiente definición de unit file: [Unit] Description=Storage Alert creates a .txt with relevant storage advertisements. After=runlevel5.target //para que comience después del target gráfico

[Service] ExecStart=/usr/bin/storage_alert //el comando que se ejecuta [Install] WantedBy=runlevel5.target //si lo establecemos como enabled queremos que se ejecute cuando se active el target gráfico

3. Activamos el servicio. Primero recargamos el demonio de los servicios para que detecte el nuevo servicio añadido. Para eso, ejecutamos: systemctl daemon-reload Luego habilitamos el servicio para que se ejecute en el arranque: systemctl enable storage_alert Y por último lo activamos: systemctl start storage_alert Nota: Para que funcione es necesario deshabilitar SELinux porque si no bloquea la lectura de nuestra unit. Para ello vamos a “/etc/sysconfig/selinux” y ponemos “SELINUX=disabled” y reiniciamos.

Conclusión

La filosofía KISS implica que un software debe ser lo más simple posible y muy estable. Esto va en línea con la filosofía UNIX de que un software sirva para una única función. Y todo ello en un contexto de software libre con código abierto que otorgue al usuario libertad y control en su propio sistema y software, pudiendo modificarlo y variar tanto como quiera o necesite, si es que tiene los conocimientos para hacerlo. Systemd funciona con el kernel Linux, y punto. No es compatible con otros kernels. Esto es algo negativo de por sí. Sin embargo, este nivel de dependencia respecto al kernel puede ser considerado el punto de partida para el control sobre todo del ecosistema GNU/Linux, y también tiene otras implicaciones: el nivel de unidad entre el kernel Linux y systemd es tal que systemd es incompatible con versiones diferentes del kernel. Systemd no es simple ni cumple una única función, es un programa muy complejo formado por diversos demonios que no se limitan a las funciones de init. Está absorbiendo cada vez más funciones, procesos y demonios. Por ejemplo, el control de energía, manejo de puntos de montaje, encriptación de discos, configuración de red... . Otro problema es el manejo de journal, un sistema de registro de incidencias que permite solucionar fácilmente fallos del sistema. Systemd ha modificado la forma en que trabaja respecto a opciones anteriores, haciéndola más compleja. Maneja journal mediante código binario fácilmente corruptible, además de otras problemáticas. Por lo que concluimos que a pesar de las múltiples ventajas que tiene el systemd, si el público objetivo es alguien con una mentalidad UNIX esta no es la mejor opción, ya que nos limita mucho nuestro trabajo y posibilidades.