info:cursos:pue:ethical-hacker:extras:sincara-systemd

Diferències

Ací es mostren les diferències entre la revisió seleccionada i la versió actual de la pàgina.

Enllaç a la visualització de la comparació

Ambdós costats versió prèvia Revisió prèvia
Següent revisió		 Revisió prèvia
info:cursos:pue:ethical-hacker:extras:sincara-systemd [27/02/2025 02:11] – [Componentes principales] mateinfo:cursos:pue:ethical-hacker:extras:sincara-systemd [28/02/2025 03:51] (actual) – [Logs] admin
Línia 164: Línia 164:
     * Esto hace que sea fácil cambiar entre implementaciones de unidades estándar y personalizadas.     * Esto hace que sea fácil cambiar entre implementaciones de unidades estándar y personalizadas.
  
 +== Estados de las Unidades
 +  * Hay cinco estados en los que puede estar una unidad: **inactive**, **activating**, **activate**, **deactivating** o **failed**. 
 +    * Por defecto, las unidades son **inactive**. 
 +    * Cuando systemd inicia una unidad, el estado cambia a **activating** 
 +    * y una vez que finaliza el inicio se marca como **active**.
 +    * Luego permanece en este estado hasta que se detiene, ya sea por sí mismo (por ejemplo, si el ejecutable de un servicio finaliza) o si systemd le indica que se detenga. Luego, el estado cambia a **deactivating**, seguido de **inactive** una vez que finaliza el apagado. 
 +    * Y si algo sale mal, el estado es **failed**.
 +  * 🇬🇧 https://seb.jambor.dev/posts/systemd-by-example-part-2-dependencies/ - Estados de las unidades
 +
 +== Archivos de configuración
 +  * Orden de preferencia de directorios, de menor a mayor prioridad:
 +    * ** /usr/lib/systemd/system/<unit>** - Directorio original donde se instalan por defecto las units. No debemos tocar nada en este directorio, porque se machaca en cada actualización.
 +    * **/run/systemd/system/<unit>** - Es donde están las runtime units, es decir, unidades durante el tiempo de ejecución. Si queremos cambiar algo del fichero de configuración de forma temporal, hasta que se reinicie el sistema, lo copiamos a esta localización y lo editamos. Pero al estar en /run se pierde al rebotar. Si lo quiero hacer persistente, lo meto en /etc
 +    * **/etc/systemd/system/<unit>** -  Directorio con mayor preferencia, pero puede existir o no. Copio aquí el fichero de configuración de la unit, y de esta forma es persistente lo que yo cambie en el.
 +    * **Comandos relacionados**
 +      * ''tree /etc/systemd/system'' # Para ver el árbol de ficheros y directorios
 +      * ''systemd-analyze unit-paths'' # Vemos todos los directorios implicados
 +      * ''systemctl edit %%--%%full <unit>'' # Editamos el fichero de configuración, creándolo automáticamente en /etc/systemd/system/<unit>
 +      * ''systemctl cat <unit>'' # Vemos todos los ficheros que aplican a la configuración
 +      * ''systemd-delta [<unit>]'' # se puede utilizar para identificar y comparar ficheros de configuración que se anulan unos a otros. Es decir, es una utilidad interesante para detectar conflictos con la configuración de systemd, y el orden de precedencia entre los distintos directorios anteriormente nombrados.
 +    * **Drop-in files**: Si queremos añadir un fichero que solo modifique algún parámetro en concreto, lo podemos hacer con el siguiente comando:
 +      * ''systemctl edit <unit> %%--%%drop-in=<nombre>'' # Esto crea un fichero llamado /etc/systemd/system/<unit>/<nombre>.conf. Si no se especifica nombre, se crea con el nombre por defecto **override.conf**
 +      * ''systemctl set-property <unit> CPUShares=1024'' # Con esto me crea un Drop-in file automáticamente
 +
 +== Creación de tus propias unidades
 +  * Puedes agregar tus propios servicios para ejecutar acciones o scripts creando ficheros con extensión **.service**. 
 +  * Todas las opciones dentro de las unidades, se explican en ''man systemd.exec''
 +  * ''cat /usr/lib/systemd/system/cups.service'' # Vemos el fichero principal de configuración
 +  * <code properties>
 +[Unit]
 +Description=CUPS Scheduler
 +Documentation=man:cupsd(8)
 +After=network.target nss-user-lookup.target nslcd.service
 +Requires=cups.socket
 +
 +[Service]
 +ExecStart=/usr/sbin/cupsd -l
 +Type=notify
 +Restart=on-failure
 +
 +[Install]
 +Also=cups.socket cups.path
 +WantedBy=printer.target multi-user.target
 +</code>
 +=== Secciones dentro de los ficheros de configuración
 +  * **[Unit]**: Define directivas específicas de la definición de la unit
 +  * **[Install]**: Define directivas de gestión de units estableciendo relaciones en aspectos como, por ejemplo, la relación de la unit con targets asociados
 +  * **[Service]**: Define directivas específicas de un service
 +    * Type
 +      * **Type=simple** (default): El servicio se inicia inmediatamente. El proceso no debe bifurcarse. No utilice este tipo si otros servicios necesitan ser ordenados en este servicio, a menos que esté activado por socket.
 +      * **Type=idle**: SystemD retrasará la ejecución del binario del servicio hasta que todos los trabajos hayan terminado. Aparte de eso el comportamiento es muy similar a Type=simple.
 +      * **Type=notify**: Idéntico a Type=simple, pero con la estipulación de que el demonio enviará una señal a SystemD cuando esté listo. La implementación de referencia para esta notificación la proporciona libsystemd-daemon.so.
 +      * **Type=oneshot**: Esto es útil para scripts que hacen un solo trabajo y luego salen. Es posible que desee establecer RemainAfterExit=yes también para que SystemD siga considerando el servicio como activo después de que el proceso haya salido. Establecer RemainAfterExit=yes es apropiado para las unidades que cambian el estado del sistema (por ejemplo, montar alguna partición).
 +      * **Type=forking**: SystemD considera el servicio iniciado una vez que el proceso se bifurca y el padre ha finalizado. Para demonios clásicos, utilice este tipo a menos que sepa que no es necesario. Debe especificar también PIDFile= para que SystemD pueda realizar un seguimiento del proceso principal.
 +      * **Type=dbus**: El servicio se considera listo cuando el BusName especificado aparece en el bus de sistema de DBus.
 +  * **[Socket]**: Define directivas de configuración de sockets asociados a services
 +  * **[Mount]** y **[Automount]**: Define directivas para puntos de montaje
 +  * **[Swap]**: Directivas que definen y habilitan espacios de intercambio para páginas de memoria virtual anónimas
 +  * **[Timer]**: Definición y gestión de eventos temporales
 +  * **[Path]**: Monitorización del sistema de archivos
 +  * **[Slice]**: Gestión de asignación de recursos a los procesos (CGroups)
 +
 +=== Particularidades de configuración
 +  * Si en la sección **ExecStart** el binario empieza con un "-", significa que **SystemD** ignorará el código de salida del comando. Este prefijo, y otros, aparece en la Tabla 2 dentro de: ''man systemd.service''
 +  * Si en la sección **EnvironmentFile** el fichero empieza con un "-", significa que si no existe dicho fichero, no se intenta leer y no da error. Esto aparece en ''man systemd.exec''
 +
 +=== Ficheros y entorno
 +  * ''systemd-delta cups.service'' # Vemos si hay algún fichero de configuración que modifique el principal
 +  * ''systemctl cat cups.service'' # Vemos todos los ficheros que aplican a la configuración
 +  * ''systemctl edit %%--%%full cups.service'' # Editamos el fichero de configuración, creándolo automáticamente en **/etc/systemd/system/cups.service**
 +    * ''export SYSTEMD_EDITOR=/usr/bin/vim'' # Para usar el vim en vez del nano que usa por defecto
 +  * ''systemctl show cups.service'' # Mostramos todas las variable que afectan la unidad
 +  * ''systemctl daemon-reload'' # Comando para indicarle a **SystemD** que hemos tocado un fichero de configuración **por nuestra cuenta** y que relea y aplique los cambios de todos los ficheros de configuración.
 +
 +=== Dependencias
 +  * ''systemctl list-dependencies cups.service'' # Vemos el árbol de dependencias de esta unidad
 +  * ''systemd-analyze critical-chain cups.service'' # Vemos en el árbol de dependencias de esta unidad, cuanto tarda el elemento más lento de cada nivel
 +
 +== Entorno
 +  * ''systemctl show-environment''            # Ver las variables de entorno que usa SystemD
 +  * ''localectl''                             # Para ver el idioma local, y el teclado
 +  * ''localectl set-locale LANG=es_US.UTF-8'' # Para cambiar el idioma local
 +  * https://systemd.io/ENVIRONMENT/ - Variables de entorno
 +
 +== Targets
 +  * **Target = runlevel**: SystemD llama targets a los runlevels de SysV, y existen equivalencias entre ambos sistemas. Se pueden ver referenciadas en los ficheros de configuración de unidades en el campo WantedBy=. 
 +    * 0 = **shutdown.target**, **poweroff.target**
 +    * **halt.target** para el sistema, pero no apaga el hardware
 +    * S = **emergency.target**
 +    * 1 = **rescue.target**
 +    * 3 = **multi-user.target**
 +    * 5 = **graphical.target**
 +    * 6 = **reboot.target**
 +    * **default.target** es un link a **multi-user.target** o **graphical.target**
 +      * ''ls -l /etc/systemd/system/default.target'' # Este link es usado por SystemD como target por defecto
 +    * También existen desde **runlevel0.target** a **runlevel6.target**
 +  * ''systemctl list-units -t target %%--%%all'' # Para ver todos los targets disponibles
 +  * ''systemctl list-dependencies graphical.target'' | grep target # Para ver las dependencias de las unidades tipo target
 +  * ''systemctl get-default'' # Ver el target por defecto actual
 +  * ''systemctl set-default multi-user.target'' # Configurar el modo multi-usuario por defecto
 +  * ''systemctl isolate multi-user.target'' # Cambiar al modo multi-usuario (3)
 +
 +== Sockets
 +  * Para cada unidad de tipo socket, debe existir una unidad de tipo servicio correspondiente
 +  * Opciones
 +    * **ListenStream**: dirección de escucha para el stream (puede ser un puerto, ruta del socket o una dirección IPv4 o IPv6 junto con el puerto).
 +    * **Accept**: si es true, la instancia del servicio se lanza por cada conexión; si es false, la encargada de gestionar todas las conexiones es una instancia.
 +    * **MaxConnections**: es el número máximo de conexiones para un servicio
 +    * **Service**: servicio que activa el socket (por defecto es el servicio que tiene el mismo nombre).
 +  * ''man systemd.socket'' # 
 +    * https://www.man7.org/linux/man-pages/man5/systemd.socket.5.html
 +  * ''systemctl list-sockets'' # Lista todos los sockets
 +  * ''alias sockets=%%'systemctl --no-pager -t socket --state=running'%%'' # Lista los activos
 +  * https://www.linux.com/training-tutorials/end-road-systemds-socket-units/
 +
 +== Timers
 +  * Para cada archivo **.timer**, existe un archivo **.service** coincidente (por ejemplo, foo.timer y foo.service). 
 +    * El archivo **.timer** activa y controla el archivo **.service**. 
 +    * El archivo **.service** no requiere una sección **[Install]** ya que son las unidades de temporizador las que se activan. 
 +    * Si es necesario, es posible controlar una unidad con un nombre diferente usando la opción Unit= en la sección [Timer] del archivo temporizador.
 +  * ''systemctl list-timers'' Para listar los "timers" de SystemD
 +  * ''journalctl -b -u .timer'' # Para ver los timers ejecutados desde el arranque del sistema
 +  * Si un temporizador se **desincroniza**, puede ayudar eliminar su archivo  **stamp-*** en **/var/lib/systemd/timers** (o** ~/.local/share/systemd/** en caso de temporizadores de usuario). Estos son archivos vacios que marcan la última vez que se ejecutó cada temporizador. Si se eliminan, se reconstruirán en el próximo inicio de su temporizador.
 +  * Frecuencias con el parámetro OnCalendar (funciona igual que el cron)
 +    * **Realtime timers** (a.k.a. wallclock timers) **Temporizadores en tiempo real** (también conocido como «wallclock timers») se activan con un evento del calendario, de la misma manera que lo hacen los cronjobs. La opción OnCalendar= se utiliza para definirlos.
 +      * DayOfWeek   Year-Month-Day   Hour:Minute:Second
 +        * Con el DayOfWeek siendo opcional. Los operadores ''*'', ''/'' y '','' tienen el mismo significado que los usados para los trabajos de cron, mientras que puede usar ''..'' entre dos valores para indicar un rango
 +        * ~ indica el último día del mes
 +        * OnCalendar=Mon -*-10..27 05:30:00
 +      * minutely # Cada minuto
 +      * hourly    # cada hora al comienzo de la hora.
 +      * daily       # una vez al día a medianoche.
 +      * weekly   # una vez a la semana a medianoche del lunes.
 +      * monthly # una vez al mes a la medianoche del primer día del mes.
 +      * yearly    # una vez al año a medianoche del primer día de enero.
 +      * quarterly # trimestral
 +      * semiannually # semianual
 +      * ''man 7 systemd.time''
 +      * ''systemd-analyze calendar weekly''
 +      * ''systemd-analyze calendar "Mon,Tue -*-01..04 12:00:00"''
 +    * Monotonic timers - Temporizadores monotónicos se activan después de un intervalo de tiempo condicionado a un punto de inicio variable. Se detienen si el equipo está temporalmente suspendido o apagado. Hay varios temporizadores monotónicos diferentes
 +      * **OnActiveSec**= Defines a timer relative to the moment the timer unit itself is activated.
 +      * **OnBootSec**= Defines a timer relative to when the machine was booted up. In containers, for the system manager instance, this is mapped to OnStartupSec=, making both equivalent.
 +      * **OnStartupSec**= Defines a timer relative to when the service manager was first started. For system timer units this is very similar to OnBootSec= as the system service manager is generally started very early at boot. It's primarily useful when configured in units running in the per-user service manager, as the user service manager is generally started on first login only, not already during boot.
 +      * **OnUnitActiveSec**= Defines a timer relative to when the unit the timer unit is activating was last activated.
 +      * **nUnitInactiveSec**= Defines a timer relative to when the unit the timer unit is activating was last deactivated.
 +  * ''systemctl enable my.timer''
 +  * ''systemctl start my.timer''
 +  * ''systemctl status my.timer''
 +  * Puede cambiar la frecuencia de su trabajo programado, modificando el valor OnCalendar y luego escribiendo el comando systemctl daemon-reload
 +  * Ejemplos
 +    * <code properties /usr/lib/systemd/system/plocate-updatedb.timer>[Unit]
 +Description=Update the plocate database daily
 +
 +[Timer]
 +OnCalendar=daily
 +RandomizedDelaySec=1h
 +AccuracySec=6h
 +Persistent=true
 +
 +[Install]
 +WantedBy=timers.target
 +</code>
 +    * <code properties /usr/lib/systemd/system/plocate-updatedb.service>[Unit]
 +Description=Update the plocate database
 +ConditionACPower=true
 +
 +[Service]
 +Type=oneshot
 +ExecStart=/usr/sbin/updatedb
 +LimitNOFILE=131072
 +IOSchedulingClass=idle
 +
 +PrivateTmp=true
 +PrivateDevices=true
 +PrivateNetwork=true
 +</code>
 +  * Unidades .timer transitorias (equivalentes a at)
 +    * ''systemd-run %%--on-calendar='2019-10-06 11:30'%% date''
 +    * ''systemd-run %%--on-active="2m" ./foo.sh%%''
 +    * ''man 1 systemd-run''
 +  * Información sobre los timers
 +    * https://wiki.archlinux.org/title/Systemd_(Espa%C3%B1ol)/Timers_(Espa%C3%B1ol%29 - Timers
 +    * ''man 5 systemd.timer''
 +
 +== Mount
 +  * **/etc/fstab**
 +    * El script systemd-fstab-generator(8) traduce todas las entradas presentes en /etc/fstab en unidades de systemd, esto se realiza en el momento del arranque y cada vez que se vuelve a cargar la configuración del gestor del sistema. 
 +    * En un disco particionado con GPT, el script systemd-gpt-auto-generator(8) montará particiones siguiendo la  especificación de particiones detectables , por lo tanto, las mismas se pueden omitir de fstab.
 +  * El nombre del unit file guarda relación con el punto de montaje del sistema de archivos. Si el punto de montaje es **/mnt/backups**, el nombre del unit file debe de ser mnt-backups.mount.
 +  * ''man 5 systemd.mount'' #
 +  * ''man 1 systemd-mount'' #
 +  * ''systemctl -t mount'' #
 +  * https://manuais.iessanclemente.net/index.php/Gesti%C3%B3n_de_Puntos_de_Montaje - Gestión de Puntos de Montaje
 +  * https://wiki.archlinux.org/title/Systemd_(Espa%C3%B1ol)#Montaje - Mount Units
 +
 +== Automount
 +  * Los automounts en systemd son un tipo de unidad que permite montar automáticamente sistemas de archivos en un directorio determinado cuando este es accedido por primera vez, y desmontarlos cuando ya no son necesarios.
 +  * Para cada automount en systemd es necesario tener un mount correspondiente.
 +    * ''man 5 systemd.automount'' # 
 +    * ''systemctl -t automount'' # 
 +    * ''systemctl list-automounts'' # 
 +    * ''systemctl cat proc-sys-fs-binfmt_misc.automount'' # 
 +
 +MATE EXTRA: [[https://community.hetzner.com/tutorials/automount-filesystems-with-systemd]]
 +
 +== PATH
 +  * https://www.linux.com/topic/desktop/systemd-services-monitoring-files-and-directories/ - Systemd Services: Monitoring Files and Directories
 +  * systemctl list-paths #
 +
 +
 +== Temporales
 +  * Hay varios servicios que crean o borran ficheros o directorios:
 +    * systemd-tmpfiles-clean.service
 +    * systemd-tmpfiles-setup-dev.service
 +    * systemd-tmpfiles-setup.service
 +      * systemctl cat systemd-tmpfiles-setup.service # Para su configuración
 +== Configuración
 +  * Los archivos de configuración se almacenan en los siguientes directorios:
 +    * /usr/lib/tmpfiles.d/
 +    * /run/tmpfiles.d/
 +    * /etc/tmpfiles.d/
 +  * Los archivos de configuración se proporcionan normalmente junto con los archivos de servicio, y reciben su nombre en el estilo /usr/lib/tmpfiles.d/**programa**.conf
 +  * ''cat /usr/lib/tmpfiles.d/tmp.conf'' # Vemos el contenido de tmp.conf
 +    * q /tmp     1777 root root 10d
 +    * q /var/tmp 1777 root root 30d
 +  * ''systemd-tmpfiles %%--cat-config%%'' # Vemos la configuración de TODOS los ficheros
 +  * Para ver la sintaxis de la creación, borrado o gestión de los temporales:
 +    * 🇬🇧 https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html - Página man
 +    * man 5 tmpfiles.d # Para verlo en local
 +  * Si hacemos un cambio en algún fichero, no lo va a ver hasta que rebotemos el sistema, o hasta que ejecutemos los siguientes comandos:
 +    * ''systemd-tmpfiles %%--create%%'' # Crea los temporales especificados
 +    * ''systemd-tmpfiles %%--remove%%'' # Borra los temporales especificados
 +    * ''systemd-tmpfiles %%--clean%%''  # Vacía el contenido de los temporales especificados
 +    * Es posible especificar las tres opciones juntas en una sola orden. En ese caso, ''%%--create%%'' siempre es lo que se ejecuta lo último.
 +  * Los usuarios pueden tener sus propios ficheros temporales, definidos en el siguiente directorio:
 +    * **~/.config/user-tmpfiles.d/** 
 +    * ''systemd-tmpfiles %%--user --create%%'' # Para gestionar sus propios temporales
 +    * ''systemd-tmpfiles %%--user --cat-config%%'' # Para verlos
 +  * Uso
 +    * ''df -t tmpfs -h'' # Para ver los sistemas de ficheros de tipo **tmpfs** montados en memoria
 +    * ''journalctl -b -u systemd-tmpfiles'' # Para ver los logs
 +    * ''systemctl cat systemd-tmpfiles-clean.timer'' # Se ejecuta una vez al día, y 15 minutos después de arrancar
 +  * Información general
 +    * https://wiki.archlinux.org/title/Systemd_(Espa%C3%B1ol)#Archivos_temporales
 +    * https://wiki.archlinux.org/title/Tmpfs_(Espa%C3%B1ol)
 +    * https://mastering-linux.com/engineer/systemd#managing-temporary-files
 +    * 🇬🇧 https://www.baeldung.com/linux/systemd-tmpfiles-configure-temporary-files
 +
 +== Seguridad, monitorización, análisis
 +  * https://www.linuxjournal.com/content/systemd-service-strengthening - Systemd Service Hardening con el comando systemd-analyze security
 +  * 🇬🇧 https://0pointer.de/blog/projects/security.html - Explicación de algunas de las características de seguridad
 +  * 🇬🇧 https://github.com/tim-seoss/rest-server/commit/76d995edfc45b7ed913c1125c3a95f626841276e - Ejemplo de mejora de la seguridad de un comando
 +
 +=== Arranque
 +  * ''systemd-analyze plot > graph1.svg ; eog graph1.svg'' # Crea un gráfico de todo el arranque del sistema, y lo visualiza con la app gráfica eog
 +  * ''systemd-analyze blame | less'' # Lo mismo, pero en modo texto, aunque no muestra dependencias ni paralelismo. Ordena la salida por tiempo que tarda cada componente en estar disponible, para poder ver a quien culpar (blame) en caso de retardo
 +  * ''systemd-analyze dot %%'avahi-daemon.'%%'' | dot -Tsvg > avahi.svg ; eog avahi.svg # Para ver las dependencias de un componente concreto en modo gráfico
 +  * ''systemd-analyze critical-chain'' # Muestra el árbol de dependencias de targets y de los servicios que bloquean la activación de cada target
 +  * 🇬🇧 https://www.thegeekdiary.com/systemd-analyze-command-examples-in-linux/ - Info
 +
 +=== Monitorización
 +  * ''systemctl status'' # Estado general de SystemD, mostrando todos los procesos lanzados con sus PIDs
 +  * ''systemctl %%--no-page --state=failed%%'' # Para ver si alguna unidad ha fallado
 +  * ''systemctl %%--no-page%%'' # Para ver todas las unidades lanzadas, ordenadas por tipo
 +
 +=== Logs
 +== journalctl
 +  * https://atareao.es/tutorial/trabajando-con-systemd/journalctl-y-logs-en-systemd/ - Buen resumen
 +  * https://www.solvetic.com/tutoriales/article/4051-administrar-logs-eventos-systemd-journalctl-linux/ - Cómo hacer persistentes los logs con journalctl, si no están almacenando
 +  * Ejemplos de comandos:
 +    * journalctl -u ruiz-tapiador.service # Mensajes generados por el servicio y por SystemD
 +      * journalctl UNIT=ruiz-tapiador.service # Mensajes generados por SystemD (arranque del servicio, parada, etc...)
 +      * journalctl _SYSTEMD_UNIT=ruiz-tapiador.service # Mensajes generados por el propio servicio (problemas al cargar algo, errores..)
 +    * journalctl -p emerg..err # Mensajes con prioridad entre emerg y err
 +      * journalctl -p 0..4    # Mensajes con prioridad entre emerg y err
 +      * journalctl -p 4       # Mensajes con prioridad entre emerg y err
 +      * journalctl -p 4..4    # Mensajes con prioridad err
 +      * Colores de las prioridades:
 +        * 3-0 - rojo
 +        * 4 - amarillo
 +        * 5 - blanco en negrita
 +        * 6 - blanco
 +        * 7 - gris
 +      * 
  • info/cursos/pue/ethical-hacker/extras/sincara-systemd.1740651113.txt.gz
  • Darrera modificació: 27/02/2025 02:11
  • per mate