systemd es el sistema init y gestor de servicios que impulsa prácticamente todas las distribuciones Linux modernas, incluyendo Ubuntu, Debian, Fedora, CentOS y Arch Linux. Reemplazó al tradicional sistema SysVinit para proporcionar inicio paralelo de servicios, gestión de dependencias, activación bajo demanda y registro centralizado. Ya sea que administres un solo servidor o una flota de máquinas en producción, comprender systemd es esencial para la administración efectiva de Linux. Esta guía cubre los comandos de systemctl, archivos de unidad personalizados, temporizadores, gestión del journal, análisis de arranque y control de recursos con cgroups.

Requisitos Previos

Antes de comenzar, asegúrate de tener:

  • Ubuntu Server 20.04, 22.04 o 24.04 (o cualquier distribución basada en systemd)
  • Acceso a terminal con privilegios sudo
  • Familiaridad básica con la línea de comandos de Linux
  • Un editor de texto (nano, vim o tu preferencia)

¿Qué es systemd?

systemd es un gestor de sistema y servicios para Linux. Se ejecuta como PID 1 — el primer proceso iniciado por el kernel — y es responsable de arrancar todo el espacio de usuario, gestionar servicios durante todo su ciclo de vida y apagar el sistema de forma limpia.

Los componentes principales de systemd incluyen:

  • systemctl — la herramienta principal de línea de comandos para controlar servicios e inspeccionar el estado del sistema
  • journald — un sistema de registro estructurado que recopila registros de todos los servicios, el kernel y el arranque temprano
  • systemd-analyze — una herramienta para perfilar y optimizar el rendimiento del arranque
  • systemd-resolved — un servicio de resolución DNS
  • systemd-networkd — un gestor de configuración de red
  • systemd-logind — un gestor de inicio de sesión y sesiones
  • systemd-tmpfiles — una herramienta para gestionar archivos y directorios temporales

Verifica que tu sistema ejecuta systemd:

systemctl --version

Salida esperada:

systemd 252 (252.22-1ubuntu1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT ...

Verifica el estado general del sistema:

systemctl status

Esto muestra un árbol de servicios en ejecución, sus PIDs y uso de memoria.

systemd vs SysVinit

Comprender qué cambió respecto a SysVinit ayuda a aclarar por qué systemd funciona como lo hace:

CaracterísticaSysVinitsystemd
Definición de servicioScripts de shell en /etc/init.d/Archivos de unidad declarativos en /etc/systemd/system/
Orden de inicioSecuencial (uno tras otro)Paralelo (basado en dependencias)
Manejo de dependenciasManual con scripts de nivel de ejecuciónAutomático con Requires, After, Wants
Rastreo de procesosArchivos PID (poco confiable)cgroups (rastreo a nivel de kernel)
Registrosyslog / archivos de registro separadosjournald (journal binario estructurado)
Activación bajo demandaNo incorporadoActivación por socket, activación D-Bus
Control de recursosNingunocgroups (límites de CPU, memoria, E/S)
Objetivos de arranqueNiveles de ejecución (0-6)Targets (multi-user.target, graphical.target)

La ventaja clave de systemd es la fiabilidad: rastrea procesos mediante cgroups para siempre saber qué procesos pertenecen a un servicio, incluso si bifurcan. Los archivos PID utilizados por SysVinit eran una fuente común de estado obsoleto y fallos en la gestión de servicios.

Gestión de Servicios con systemctl

systemctl es el comando que usarás con más frecuencia. Se comunica con el gestor de systemd para controlar servicios, inspeccionar su estado y administrar su comportamiento de arranque.

Iniciar y Detener Servicios

# Iniciar un servicio
sudo systemctl start nginx

# Detener un servicio
sudo systemctl stop nginx

# Reiniciar un servicio (detener y luego iniciar)
sudo systemctl restart nginx

# Recargar configuración sin reiniciar (si es compatible)
sudo systemctl reload nginx

# Recargar o reiniciar (recargar si es compatible, de lo contrario reiniciar)
sudo systemctl reload-or-restart nginx

Verificar el Estado del Servicio

sudo systemctl status nginx

Ejemplo de salida:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2026-01-29 10:15:30 UTC; 2h ago
       Docs: man:nginx(8)
   Main PID: 1241 (nginx)
      Tasks: 3 (limit: 4647)
     Memory: 8.2M
        CPU: 52ms
     CGroup: /system.slice/nginx.service
             ├─1241 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1242 "nginx: worker process"
             └─1243 "nginx: worker process"

Campos clave:

  • Loaded — si el archivo de unidad está cargado y dónde se encuentra
  • Active — el estado actual (active, inactive, failed)
  • Main PID — el identificador de proceso principal del servicio
  • CGroup — todos los procesos que pertenecen a este servicio

Habilitar y Deshabilitar Servicios

Habilitar un servicio significa que se iniciará automáticamente en el arranque. Deshabilitar elimina este comportamiento.

# Habilitar un servicio para iniciar en el arranque
sudo systemctl enable nginx

# Deshabilitar un servicio del inicio en el arranque
sudo systemctl disable nginx

# Habilitar e iniciar en un solo comando
sudo systemctl enable --now nginx

# Deshabilitar y detener en un solo comando
sudo systemctl disable --now nginx

Verificar el Estado de Habilitación

systemctl is-enabled nginx
# Salida: enabled

systemctl is-active nginx
# Salida: active

systemctl is-failed nginx
# Salida: active (no ha fallado)

Listar Servicios

# Listar todos los servicios activos
systemctl list-units --type=service

# Listar todos los servicios (incluyendo inactivos)
systemctl list-units --type=service --all

# Listar servicios habilitados
systemctl list-unit-files --type=service --state=enabled

# Listar servicios fallidos
systemctl list-units --type=service --state=failed

Comprender los Archivos de Unidad

systemd gestiona todo a través de archivos de unidad — archivos de configuración declarativos que describen servicios, puntos de montaje, dispositivos, sockets, temporizadores y más.

Tipos de Unidad

Tipo de UnidadExtensiónPropósito
Service.serviceGestiona un demonio o proceso de ejecución única
Timer.timerPrograma la activación de servicios (reemplazo de cron)
Socket.socketGestiona la activación basada en sockets
Mount.mountGestiona puntos de montaje del sistema de archivos
Target.targetAgrupa unidades para sincronización
Path.pathMonitorea rutas del sistema de archivos en busca de cambios
Slice.sliceGestiona particiones de recursos de cgroups
Device.deviceGestiona nodos de dispositivos del kernel

Ubicaciones de Archivos de Unidad

Los archivos de unidad se cargan desde múltiples directorios con precedencia específica:

DirectorioPropósitoPrioridad
/etc/systemd/system/Sobrecargas del administrador localMás alta
/run/systemd/system/Unidades de tiempo de ejecución (no persistentes)Media
/lib/systemd/system/Unidades proporcionadas por la distribuciónMás baja

Siempre crea o modifica unidades en /etc/systemd/system/. Nunca edites archivos en /lib/systemd/system/ directamente, ya que las actualizaciones de paquetes sobrescribirán tus cambios.

Inspeccionar Archivos de Unidad

# Ver el archivo de unidad completo de un servicio
systemctl cat nginx.service

# Mostrar todas las propiedades de un servicio (configuración efectiva)
systemctl show nginx.service

# Mostrar una propiedad específica
systemctl show nginx.service -p MainPID
systemctl show nginx.service -p ActiveState

# Listar todas las dependencias de un servicio
systemctl list-dependencies nginx.service

Crear Unidades de Servicio Personalizadas

Una de las habilidades más prácticas de systemd es escribir tus propios archivos de unidad de servicio. Esto te permite gestionar cualquier aplicación — desde un servidor Node.js hasta un binario Go o un script Python — como un servicio del sistema.

Unidad de Servicio Básica

Crea un archivo en /etc/systemd/system/myapp.service:

[Unit]
Description=My Custom Application
Documentation=https://example.com/docs
After=network.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/bin/myapp --config /etc/myapp/config.yaml
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
SyslogIdentifier=myapp

[Install]
WantedBy=multi-user.target

Desglose de Secciones

[Unit] — metadatos y dependencias:

  • Description — descripción legible mostrada en la salida de estado
  • Documentation — URL para documentación
  • After — iniciar esta unidad después de las unidades listadas
  • Wants — dependencia débil (no falla si la dependencia falla)
  • Requires — dependencia fuerte (falla si la dependencia falla)

[Service] — comportamiento del servicio:

  • Type — cómo systemd determina que el servicio está listo (simple, forking, oneshot, notify, idle)
  • User / Group — ejecutar el servicio como este usuario/grupo
  • WorkingDirectory — establecer el directorio de trabajo
  • ExecStart — el comando para iniciar el servicio
  • ExecStartPre — comandos a ejecutar antes del proceso principal
  • ExecStartPost — comandos a ejecutar después de que el proceso principal inicie
  • ExecStop — el comando para detener el servicio (por defecto SIGTERM)
  • ExecReload — el comando para recargar la configuración
  • Restart — cuándo reiniciar (no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, always)
  • RestartSec — tiempo de espera antes de reiniciar

[Install] — comportamiento de instalación:

  • WantedBy — el target que debe incluir este servicio (usualmente multi-user.target)

Tipos de Servicio Explicados

# Simple (predeterminado): ExecStart es el proceso principal
Type=simple

# Forking: el proceso bifurca y el padre sale (demonios tradicionales)
Type=forking
PIDFile=/run/myapp.pid

# Oneshot: el proceso se ejecuta hasta completarse y luego sale
Type=oneshot
RemainAfterExit=yes

# Notify: el proceso envía una notificación cuando está listo
Type=notify

# Idle: como simple pero espera hasta que todos los trabajos sean despachados
Type=idle

Activar el Servicio

Después de crear o modificar un archivo de unidad, recarga el demonio de systemd y gestiona el servicio:

# Recargar systemd para leer archivos de unidad nuevos/modificados
sudo systemctl daemon-reload

# Iniciar el servicio
sudo systemctl start myapp

# Verificar el estado
sudo systemctl status myapp

# Habilitar en el arranque
sudo systemctl enable myapp

Sobrescribir Unidades Existentes

En lugar de editar archivos de unidad proporcionados por el proveedor, usa sobrecargas drop-in:

# Crear un directorio y archivo de sobrecarga
sudo systemctl edit nginx.service

Esto abre un editor para /etc/systemd/system/nginx.service.d/override.conf. Agrega solo las directivas que deseas cambiar:

[Service]
LimitNOFILE=65535

Para ver la configuración efectiva después de las sobrecargas:

systemctl cat nginx.service

Temporizadores de systemd

Los temporizadores de systemd son un reemplazo moderno para las tareas cron. Ofrecen programación persistente (recuperando ejecuciones perdidas), registro por temporizador e integración con el control de recursos de cgroups.

Estructura de la Unidad de Temporizador

Un temporizador requiere dos archivos: una unidad .timer y una unidad .service correspondiente con el mismo nombre.

Crea /etc/systemd/system/backup.timer:

[Unit]
Description=Run backup every day at 2:00 AM

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true
RandomizedDelaySec=300

[Install]
WantedBy=timers.target

Crea /etc/systemd/system/backup.service:

[Unit]
Description=System Backup Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
User=root
StandardOutput=journal
StandardError=journal

Tipos de Temporizador

Basados en calendario (OnCalendar):

# Todos los días a medianoche
OnCalendar=daily

# Todos los lunes a las 3 AM
OnCalendar=Mon *-*-* 03:00:00

# Cada 6 horas
OnCalendar=*-*-* 00/6:00:00

# Primer día de cada mes
OnCalendar=*-*-01 00:00:00

# Cada 15 minutos
OnCalendar=*-*-* *:00/15:00

Monótonos (relativos a un evento):

# 5 minutos después del arranque
OnBootSec=5min

# 1 hora después de que el temporizador se active
OnActiveSec=1h

# 30 minutos después de que la última ejecución se complete
OnUnitActiveSec=30min

Gestionar Temporizadores

# Recargar, habilitar e iniciar el temporizador
sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

# Listar todos los temporizadores activos
systemctl list-timers --all

# Verificar el estado del temporizador
systemctl status backup.timer

# Probar el servicio asociado manualmente
sudo systemctl start backup.service

Verificar Expresiones de Calendario

Usa systemd-analyze calendar para probar tus expresiones de temporizador:

systemd-analyze calendar "Mon *-*-* 03:00:00"

Salida:

  Original form: Mon *-*-* 03:00:00
Normalized form: Mon *-*-* 03:00:00
    Next elapse: Mon 2026-02-02 03:00:00 UTC
       (in UTC): Mon 2026-02-02 03:00:00 UTC
       From now: 3 days left

Gestión de Journal y Registros con journalctl

journald es el componente de registro de systemd. Recopila registros de todos los servicios, el kernel y el proceso de arranque temprano en un journal binario estructurado que soporta búsquedas rápidas, filtrado y exportación.

Uso Básico de journalctl

# Ver todos los registros (más antiguos primero)
journalctl

# Ver las entradas más recientes (más nuevas primero)
journalctl -r

# Seguir registros en tiempo real
journalctl -f

# Mostrar registros desde el último arranque
journalctl -b

# Mostrar registros del arranque anterior
journalctl -b -1

Filtrar por Servicio

# Registros de un servicio específico
journalctl -u nginx.service

# Seguir un servicio específico en tiempo real
journalctl -u nginx.service -f

# Registros de múltiples servicios
journalctl -u nginx.service -u php-fpm.service

Filtrar por Tiempo

# Registros desde un tiempo específico
journalctl --since "2026-01-29 10:00:00"

# Registros en un rango de tiempo
journalctl --since "2026-01-29 10:00:00" --until "2026-01-29 12:00:00"

# Registros de la última hora
journalctl --since "1 hour ago"

# Registros de hoy
journalctl --since today

Filtrar por Prioridad

journalctl soporta niveles de prioridad de syslog:

# Mostrar solo errores y superiores
journalctl -p err

# Mostrar advertencias y superiores
journalctl -p warning

# Mostrar críticos y superiores
journalctl -p crit
Nivel de PrioridadPalabra ClaveNumérico
Emergenciaemerg0
Alertaalert1
Críticocrit2
Errorerr3
Advertenciawarning4
Avisonotice5
Informacióninfo6
Depuracióndebug7

Formatos de Salida

# Salida JSON (para análisis)
journalctl -u nginx.service -o json-pretty

# Salida corta con marcas de tiempo precisas
journalctl -u nginx.service -o short-precise

# Salida detallada con todos los campos
journalctl -u nginx.service -o verbose

Gestionar el Tamaño del Journal

# Verificar el uso actual de disco
journalctl --disk-usage

# Retener solo las últimas 2 semanas de registros
sudo journalctl --vacuum-time=2weeks

# Limitar el tamaño del journal a 500 MB
sudo journalctl --vacuum-size=500M

# Eliminar journals archivados
sudo journalctl --rotate
sudo journalctl --vacuum-time=1s

Para configuración persistente, edita /etc/systemd/journald.conf:

[Journal]
SystemMaxUse=500M
SystemMaxFileSize=50M
MaxRetentionSec=2week

Luego reinicia journald:

sudo systemctl restart systemd-journald

Análisis del Rendimiento de Arranque

systemd proporciona herramientas integradas para medir y optimizar los tiempos de arranque.

Tiempo Total de Arranque

systemd-analyze

Salida:

Startup finished in 3.245s (kernel) + 8.712s (userspace) = 11.957s
graphical.target reached after 8.510s in userspace.

Desglose Servicio por Servicio

# Listar servicios ordenados por tiempo de inicio
systemd-analyze blame

Salida:

5.012s NetworkManager-wait-online.service
1.234s snapd.service
  892ms docker.service
  456ms nginx.service
  234ms ssh.service
  ...

Cadena Crítica

La cadena crítica muestra la secuencia de unidades que determinó el tiempo total de arranque:

systemd-analyze critical-chain

Salida:

graphical.target @8.510s
└─multi-user.target @8.508s
  └─nginx.service @8.052s +456ms
    └─network-online.target @8.050s
      └─NetworkManager-wait-online.service @3.038s +5.012s
        └─NetworkManager.service @2.890s +145ms
          └─basic.target @2.880s

Gráfico de Arranque SVG

Genera una línea temporal visual del proceso de arranque:

systemd-analyze plot > boot-chart.svg

Abre el archivo SVG en un navegador web para ver una representación gráfica detallada de los tiempos de inicio de servicios y dependencias.

Identificar Servicios Lentos

# Encontrar servicios que son lentos al iniciar
systemd-analyze blame | head -20

# Verificar si un servicio específico retrasa el arranque
systemd-analyze critical-chain nginx.service

Estrategias comunes de optimización del arranque:

  • Deshabilitar servicios que no necesitas (sudo systemctl disable nombre_del_servicio)
  • Enmascarar servicios que nunca quieres ejecutar (sudo systemctl mask nombre_del_servicio)
  • Investigar NetworkManager-wait-online.service (una fuente común de retraso en el arranque)
  • Usar activación por socket para servicios que no se necesitan inmediatamente

Control de Recursos con Cgroups

systemd utiliza los grupos de control de Linux (cgroups) para gestionar y limitar los recursos disponibles para cada servicio. Esto evita que un servicio con mal comportamiento consuma todos los recursos del sistema.

Ver el Uso Actual de Recursos

# Mostrar uso de recursos por slice
systemd-cgtop

Establecer Límites de Memoria

Agrega directivas de recursos a la sección [Service] de un archivo de unidad:

[Service]
MemoryMax=512M
MemoryHigh=400M
  • MemoryMax — límite duro; el OOM killer interviene si se excede
  • MemoryHigh — límite suave; el kernel limita el servicio cuando se excede

Establecer Límites de CPU

[Service]
CPUQuota=50%
CPUWeight=100
  • CPUQuota — limita el servicio a un porcentaje de un solo núcleo de CPU (200% = dos núcleos)
  • CPUWeight — peso relativo para la distribución de tiempo de CPU (predeterminado es 100)

Establecer Límites de E/S

[Service]
IOWeight=50
IOReadBandwidthMax=/dev/sda 10M
IOWriteBandwidthMax=/dev/sda 5M

Aplicar Límites en Tiempo de Ejecución

Puedes aplicar límites de recursos temporalmente sin modificar archivos de unidad:

# Limitar memoria para un servicio en ejecución
sudo systemctl set-property nginx.service MemoryMax=512M

# Limitar CPU para un servicio en ejecución
sudo systemctl set-property nginx.service CPUQuota=50%

# Hacer el cambio persistente
sudo systemctl set-property nginx.service MemoryMax=512M --runtime=false

Ver Límites Efectivos

systemctl show nginx.service -p MemoryMax -p CPUQuota -p IOWeight

Referencia de Comandos systemctl

ComandoDescripción
systemctl start <unidad>Iniciar una unidad
systemctl stop <unidad>Detener una unidad
systemctl restart <unidad>Reiniciar una unidad
systemctl reload <unidad>Recargar configuración de la unidad
systemctl enable <unidad>Habilitar unidad en el arranque
systemctl disable <unidad>Deshabilitar unidad en el arranque
systemctl enable --now <unidad>Habilitar e iniciar inmediatamente
systemctl status <unidad>Mostrar estado de la unidad
systemctl is-active <unidad>Verificar si la unidad está en ejecución
systemctl is-enabled <unidad>Verificar si la unidad está habilitada
systemctl is-failed <unidad>Verificar si la unidad ha fallado
systemctl list-unitsListar todas las unidades cargadas
systemctl list-unit-filesListar todos los archivos de unidad
systemctl list-timersListar temporizadores activos
systemctl daemon-reloadRecargar cambios en archivos de unidad
systemctl cat <unidad>Mostrar contenido del archivo de unidad
systemctl show <unidad>Mostrar todas las propiedades de la unidad
systemctl edit <unidad>Crear sobrecarga drop-in
systemctl mask <unidad>Evitar que la unidad se inicie
systemctl unmask <unidad>Eliminar máscara de la unidad
systemctl list-dependencies <unidad>Mostrar dependencias de la unidad
systemctl set-property <unidad> <clave>=<val>Establecer propiedad en tiempo de ejecución
journalctl -u <unidad>Ver registros de la unidad
journalctl -u <unidad> -fSeguir registros de la unidad
systemd-analyze blameMostrar tiempo de arranque por servicio
systemd-analyze critical-chainMostrar ruta crítica de arranque

Resolución de Problemas en Servicios Fallidos

Cuando un servicio falla, sigue este enfoque sistemático para diagnosticar y resolver el problema.

Paso 1: Verificar el Estado

sudo systemctl status myapp.service

Busca la línea Active. Estados comunes:

  • active (running) — el servicio se ejecuta normalmente
  • inactive (dead) — el servicio está detenido
  • failed — el servicio se detuvo inesperadamente o falló al iniciar
  • activating (auto-restart) — el servicio se está reiniciando

Paso 2: Leer los Registros

# Registros completos del servicio
journalctl -u myapp.service --no-pager

# Últimas 50 líneas
journalctl -u myapp.service -n 50

# Solo errores
journalctl -u myapp.service -p err

Paso 3: Validar el Archivo de Unidad

# Verificar errores de sintaxis
systemd-analyze verify /etc/systemd/system/myapp.service

Paso 4: Probar el Comando Manualmente

Ejecuta el comando ExecStart manualmente como el usuario del servicio para ver si la aplicación funciona:

sudo -u myapp /opt/myapp/bin/myapp --config /etc/myapp/config.yaml

Paso 5: Verificar Problemas Comunes

Errores de permisos:

# Verificar que el binario es ejecutable
ls -la /opt/myapp/bin/myapp

# Verificar que el usuario existe
id myapp

# Verificar permisos del directorio
ls -la /opt/myapp/

Dependencias faltantes:

# Verificar bibliotecas compartidas faltantes
ldd /opt/myapp/bin/myapp

Conflictos de puertos:

# Verificar si el puerto ya está en uso
ss -tlnp | grep :8080

Paso 6: Restablecer un Servicio Fallido

# Restablecer el estado de fallo
sudo systemctl reset-failed myapp.service

# Intentar iniciar nuevamente
sudo systemctl start myapp.service

Patrones de Error Comunes

SíntomaCausa ProbableSolución
code=exited, status=203/EXECBinario no encontrado o no ejecutableVerificar la ruta de ExecStart y permisos
code=exited, status=217/USEREl usuario del servicio no existeCrear el usuario con useradd
code=exited, status=200/CHDIRWorkingDirectory no existeCrear el directorio
code=exited, status=1/FAILUREError de la aplicaciónVerificar registros con journalctl
El servicio sigue reiniciandoBucle de fallosVerificar RestartSec, revisar registros de la aplicación
code=killed, signal=KILLOOM killerAumentar MemoryMax u optimizar la aplicación

Resumen

systemd es la columna vertebral de la gestión de servicios en sistemas Linux modernos. Proporciona un enfoque unificado y declarativo para gestionar servicios, programar tareas, controlar recursos y analizar el comportamiento del sistema. Dominar systemctl, archivos de unidad, temporizadores y journalctl te da control completo sobre cómo operan tus servidores Linux.

Puntos clave:

  • Usa systemctl para todas las tareas de gestión de servicios: iniciar, detener, habilitar, deshabilitar y verificar estado
  • Escribe archivos de unidad personalizados en /etc/systemd/system/ para gestionar tus propias aplicaciones como servicios del sistema
  • Reemplaza las tareas cron con temporizadores de systemd para programación persistente, registro por tarea y control de recursos
  • Usa journalctl para filtrado potente de registros por servicio, rango de tiempo y nivel de prioridad
  • Perfila el rendimiento del arranque con systemd-analyze y deshabilita servicios innecesarios para acelerar el inicio
  • Aplica límites de recursos con cgroups (MemoryMax, CPUQuota) para evitar que los servicios agoten el sistema
  • Usa sobrecargas drop-in (systemctl edit) en lugar de modificar archivos de unidad del proveedor

Para un enfoque más amplio sobre la seguridad de tus servidores Linux, consulta nuestra Lista de Verificación de Seguridad para Servidores Linux y Guía de Configuración del Firewall UFW.