Red Hat Summit3.5.3. Creación de archivos de unidad personalizados
Hay varios casos de uso para crear archivos de unidad desde cero: podría ejecutar un demonio personalizado, crear una segunda instancia de algún servicio existente (como en Crear una segunda instancia del servicio sshd), o importar un script de init de SysV (más en Convertir scripts de init de SysV en archivos de unidad). Por otro lado, si sólo pretende modificar o ampliar el comportamiento de una unidad existente, utilice las instrucciones de Modificar archivos de unidad existentes. El siguiente procedimiento describe el proceso general de creación de un servicio personalizado.
Procedimiento
-
Prepare el archivo ejecutable con el servicio personalizado. Puede ser un script creado a medida o un ejecutable entregado por un proveedor de software. Si es necesario, prepara un archivo PID para mantener un PID constante para el proceso principal del servicio personalizado. También es posible incluir archivos de entorno para almacenar variables de shell para el servicio. Asegúrese de que el script fuente es ejecutable (ejecutando el
chmod a x) y no es interactivo. Cree un archivo de unidad en el directorio
/etc/systemd/system/y asegúrese de que tiene los permisos correctos. Ejecute comoroot:touch /etc/systemd/system/name.servicechmod 664 /etc/systemd/system/name.serviceSustituya name por el nombre del servicio a crear. Tenga en cuenta que no es necesario que el archivo sea ejecutable.
Abra el archivo
name.servicecreado en el paso anterior y añada las opciones de configuración del servicio. Hay una variedad de opciones que se pueden utilizar dependiendo del tipo de servicio que se desea crear, ver Estructura del archivo de la unidad. El siguiente es un ejemplo de configuración de unidad para un servicio relacionado con la red:[Unit] Description=service_description After=network.target [Service] ExecStart=path_to_executable Type=forking PIDFile=path_to_pidfile [Install] WantedBy=default.target
Dónde:
-
service_description es una descripción informativa que se muestra en los archivos de registro del diario y en la salida del comando
systemctl status. -
el ajuste
Aftergarantiza que el servicio se inicie sólo después de que la red esté en funcionamiento. Añade una lista separada por espacios de otros servicios u objetivos relevantes. - path_to_executable representa la ruta del ejecutable del servicio real.
-
Type=forkingse utiliza para los demonios que hacen la llamada al sistema fork. El proceso principal del servicio se crea con el PID especificado en path_to_pidfile. Encuentra otros tipos de inicio en Tabla 3.10, “Opciones importantes de la sección [Servicio]”. -
WantedByestablece el objetivo o los objetivos con los que debe iniciarse el servicio. Piensa en estos objetivos como un reemplazo del antiguo concepto de niveles de ejecución.
-
service_description es una descripción informativa que se muestra en los archivos de registro del diario y en la salida del comando
Notificar a systemd que existe un nuevo
name.servicearchivo existe ejecutando el siguiente comando comoroot:systemctl daemon-reloadsystemctl start name.serviceAvisoEjecute siempre el comando
systemctl daemon-reloaddespués de crear nuevos archivos de unidad o de modificar los existentes. De lo contrario, los comandossystemctl startosystemctl enablepodrían fallar debido a un desajuste entre los estados de systemd y los archivos de unidad de servicio reales en el disco. Tenga en cuenta que en sistemas con un gran número de unidades esto puede llevar mucho tiempo, ya que el estado de cada unidad tiene que ser serializado y posteriormente deserializado durante la recarga.
3.5.3.1. Creación de un archivo de unidad personalizado utilizando la segunda instancia del servicio sshd
Los administradores de sistemas a menudo necesitan configurar y ejecutar múltiples instancias de un servicio. Esto se hace creando copias de los archivos de configuración del servicio original y modificando ciertos parámetros para evitar conflictos con la instancia primaria del servicio. El siguiente procedimiento muestra cómo crear una segunda instancia del servicio sshd.
Procedimiento
Cree una copia del archivo
sshd_configque será utilizado por el segundo demonio:# cp /etc/ssh/sshd{,-segundo}_configEdite el archivo
sshd-second_configcreado en el paso anterior para asignar un número de puerto y un archivo PID diferentes al segundo demonio:Port 22220 PidFile /var/run/sshd-second.pid
Consulte la página del manual
sshd_config(5) para obtener más información sobre las opcionesPortyPidFile. Asegúrese de que el puerto elegido no está siendo utilizado por ningún otro servicio. El archivo PID no tiene que existir antes de ejecutar el servicio, se genera automáticamente al iniciar el servicio.Cree una copia del archivo de unidad systemd para el servicio
sshd:# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
Altere el
sshd-second.servicecreado en el paso anterior como sigue:Modificar la opción
Description:Descripción=Demonio de segunda instancia del servidor OpenSSH
Añade sshd.service a los servicios especificados en la opción
After, para que la segunda instancia se inicie sólo después de que la primera ya se haya iniciado:After=syslog.target network.target auditd.service sshd.service
- La primera instancia de sshd incluye la generación de claves, por lo tanto, elimine la línea ExecStartPre=/usr/sbin/sshd-keygen.
Añade el parámetro
-f /etc/ssh/sshd-second_configal comandosshd, para que se utilice el archivo de configuración alternativo:ExecStart=/usr/sbin/sshd -D -f /etc/sshd-second_config $OPTIONS
Después de las modificaciones anteriores, el sshd-second.service debería tener el siguiente aspecto:
[Unit] Description=OpenSSH server second instance daemon After=syslog.target network.target auditd.service sshd.service [Service] EnvironmentFile=/etc/sysconfig/sshd ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target
Si utiliza SELinux, añada el puerto para la segunda instancia de sshd a los puertos SSH, de lo contrario la segunda instancia de sshd será rechazada para enlazar con el puerto:
# semanage port -a -t ssh_port_t -p tcp 22220
Habilitar sshd-second.service, para que se inicie automáticamente al arrancar:
# systemctl enable sshd-second.service
-
Compruebe si el servicio sshd-second.service se está ejecutando mediante el comando
systemctl status. Verifique si el puerto está habilitado correctamente conectándose al servicio:
$
ssh -p 22220 user@serverSi el firewall está en uso, asegúrese de que está configurado adecuadamente para permitir las conexiones a la segunda instancia de sshd.
