La consola web de RHEL es una interfaz basada en la web de Red Hat Enterprise Linux 8 diseñada para gestionar y supervisar su sistema local, así como los servidores Linux ubicados en su entorno de red.

La consola web de RHEL le permite una amplia gama de tareas de administración, incluyendo

La consola web de RHEL utiliza las mismas APIs del sistema que en un terminal, y las acciones realizadas en un terminal se reflejan inmediatamente en la consola web de RHEL.

Puede supervisar los registros de los sistemas en el entorno de la red, así como su rendimiento, mostrado en forma de gráficos. Además, puedes cambiar la configuración directamente en la consola web o a través del terminal.

Para acceder a la consola web de RHEL 8, primero hay que habilitar el servicio cockpit.socket.

Red Hat Enterprise Linux 8 incluye la consola web de RHEL 8 instalada por defecto en muchas variantes de instalación. Si este no es el caso en su sistema, instale el paquete cockpit antes de habilitar el servicio cockpit.socket.

Siga los pasos de este procedimiento para acceder por primera vez a la consola web de RHEL utilizando un nombre de usuario y una contraseña del sistema.

Después de la autenticación exitosa, se abre la interfaz de la consola web de RHEL.

Es posible conectarse a la interfaz de su consola web desde cualquier sistema operativo cliente y también desde teléfonos móviles o tabletas.

Si su sistema forma parte de un dominio de gestión de identidades (IdM) con una configuración de contraseña de un solo uso (OTP) habilitada, puede utilizar una OTP para iniciar sesión en la consola web de RHEL.

Puede utilizar la consola web para reiniciar un sistema RHEL al que esté conectada la consola web.

Puede utilizar la consola web para apagar un sistema RHEL al que esté conectada la consola web.

Puede establecer una zona horaria y sincronizar la hora del sistema con un servidor de Protocolo de Tiempo de Red (NTP).

Puede utilizar la consola web para unir el sistema Red Hat Enterprise Linux 8 al dominio de gestión de identidades (IdM).

Desactivar el Multi Threading Simultáneo (SMT) en caso de ataques que abusen del SMT de la CPU. Desactivar SMT puede mitigar las vulnerabilidades de seguridad, como L1TF o MDS.

Tras el reinicio del sistema, la CPU deja de utilizar el SMT.

A veces, las empresas o los organismos necesitan mostrar una advertencia de que el uso del ordenador es para fines legales, que el usuario está sujeto a vigilancia y que se perseguirá a quien lo traspase. La advertencia debe ser visible antes de iniciar la sesión. De manera similar a SSH, la consola web puede mostrar opcionalmente el contenido de un archivo de banner en la pantalla de inicio de sesión. Para habilitar los banners en las sesiones de la consola web, es necesario modificar el archivo /etc/cockpit/cockpit.conf. Tenga en cuenta que el archivo no es necesario y puede que tenga que crearlo manualmente.

Por defecto, no hay ningún tiempo de espera establecido en la interfaz de la consola web. Si desea habilitar un tiempo de espera en su sistema, puede hacerlo modificando el archivo de configuración /etc/cockpit/cockpit.conf. Tenga en cuenta que el archivo no es necesario y puede que tenga que crearlo manualmente.

El nombre de host identifica el sistema. Por defecto, el nombre de host se establece en localhost, pero puede cambiarlo.

Un nombre de host consta de dos partes:

Un nombre de host con un nombre de dominio adjunto se denomina nombre de dominio completo (FQDN). Por ejemplo: mymachine.example.com.

Los nombres de los hosts se almacenan en el archivo /etc/hostname.

Puede configurar un nombre de host bonito en la consola web de RHEL. El nombre de host bonito es un nombre de host con letras mayúsculas, espacios, etc.

El nombre bonito del host se muestra en la consola web, pero no tiene por qué corresponder con el nombre del host.

Este procedimiento establece el nombre de host real o el nombre de host bonito en la consola web.

El paquete cockpit forma parte de Red Hat Enterprise Linux 8 por defecto. Para poder utilizar aplicaciones complementarias debe instalarlas por separado.

La siguiente tabla enumera las aplicaciones complementarias disponibles para la consola web de RHEL 8.

Red Hat Enterprise Linux 8 proporciona varios perfiles de rendimiento que optimizan el sistema para las siguientes tareas:

El servicio tuned optimiza las opciones del sistema para ajustarse al perfil seleccionado.

En la consola web, puedes establecer qué perfil de rendimiento utiliza tu sistema.

Este procedimiento utiliza la consola web para optimizar el rendimiento del sistema para una tarea seleccionada.

RHEL System Roles es una colección de roles y módulos de Ansible. RHEL System Roles proporciona una interfaz de configuración para gestionar de forma remota varios sistemas RHEL. La interfaz permite gestionar las configuraciones del sistema en varias versiones de RHEL, así como adoptar nuevas versiones principales.

En Red Hat Enterprise Linux 8, la interfaz consta actualmente de los siguientes roles:

Todos estos roles son proporcionados por el paquete rhel-system-roles disponible en el repositorio AppStream.

Puede encontrar los siguientes términos en esta documentación:

El siguiente procedimiento describe cómo aplicar un rol particular.

La precisión en la medición del tiempo es importante por varias razones. En Red Hat Enterprise Linux, el mantenimiento de la hora está garantizado por el protocolo NTP, que está implementado por un demonio que se ejecuta en el espacio de usuario. El demonio del espacio de usuario actualiza el reloj del sistema que se ejecuta en el kernel. El reloj del sistema puede mantener la hora utilizando varias fuentes de reloj.

Red Hat Enterprise Linux 8 utiliza el demonio chronyd para implementar NTP. chronyd está disponible en el paquete chrony paquete. Para más información, consulte Uso de la suite chrony para configurar NTP.

La configuración regional de todo el sistema se almacena en el archivo /etc/locale.conf, que el demonio systemd lee al inicio del sistema. Cada servicio o usuario hereda la configuración regional configurada en /etc/locale.conf, a menos que los programas individuales o los usuarios individuales la anulen.

Esta sección describe cómo gestionar la configuración regional del sistema.

La configuración de la disposición del teclado controla la disposición utilizada en la consola de texto y en las interfaces gráficas de usuario.

Esta sección describe cómo cambiar el idioma del sistema utilizando la GUI del escritorio.

Siga los pasos de este procedimiento para configurar su red y su nombre de host.

Este procedimiento describe la adición de una conexión Ethernet con la siguiente configuración utilizando la utilidad nmcli:

La aplicación nmtui proporciona una interfaz de usuario de texto para NetworkManager. Este procedimiento describe cómo añadir un nuevo perfil de conexión.

En la consola web, el menú Red le permite:

Figura 1.1. Gestión de la red en la consola web de RHEL 8

Puede configurar las conexiones de red en varias máquinas de destino utilizando el rol network.

El rol network permite configurar los siguientes tipos de interfaces:

Las conexiones de red necesarias para cada host se proporcionan como una lista dentro de la variable network_connections.

El siguiente ejemplo muestra cómo aplicar el rol network para asegurar que existe una conexión Ethernet con los parámetros requeridos:

# SPDX-License-Identifier: BSD-3-Clause
---
- hosts: network-test
  vars:
    network_connections:

      # Create one ethernet profile and activate it.
      # The profile uses automatic IP addressing
      # and is tied to the interface by MAC address.
      - name: prod1
        state: up
        type: ethernet
        autoconnect: yes
        mac: "00:00:5e:00:53:00"
        mtu: 1450

  roles:
    - rhel-system-roles.network

Para más información sobre la aplicación de un rol de sistema, consulte Introducción a los roles de sistema de RHEL.

Utilice el siguiente procedimiento para registrar su sistema si no lo ha registrado ya durante el proceso de instalación.

Siga los siguientes pasos para registrar un Red Hat Enterprise Linux recién instalado mediante la consola web de RHEL 8.

En este punto, su sistema Red Hat Enterprise Linux 8 ha sido registrado con éxito.

Siga los pasos de este procedimiento para registrar su sistema con su cuenta de Red Hat.

Siga los pasos de este procedimiento para registrar su sistema con una clave de activación. Puede obtener la clave de activación del administrador de su organización.

Puede determinar qué servicios se activan o desactivan en el momento del arranque ya durante el proceso de instalación. También puede activar o desactivar un servicio en un sistema operativo instalado.

Esta sección describe los pasos para activar o desactivar esos servicios en un sistema operativo ya instalado:

# systemctl unmask service_name

Esta sección describe cómo puede también habilitar o deshabilitar un servicio usando la consola web. Puedes gestionar los objetivos systemd, los servicios, los sockets, los temporizadores y las rutas. También puede comprobar el estado del servicio, iniciar o detener servicios, habilitarlos o deshabilitarlos.

Un cortafuegos es un sistema de seguridad de red que supervisa y controla el tráfico de red entrante y saliente según las reglas de seguridad configuradas. Un cortafuegos suele establecer una barrera entre una red interna segura de confianza y otra red externa.

El servicio firewalld, que proporciona un cortafuegos en Red Hat Enterprise Linux, se activa automáticamente durante la instalación.

Security-Enhanced Linux (SELinux) es una capa adicional de seguridad del sistema que determina qué procesos pueden acceder a qué archivos, directorios y puertos. Estos permisos se definen en las políticas de SELinux. Una política es un conjunto de reglas que guían el motor de seguridad de SELinux.

Esta sección proporciona una visión general de las cuentas de usuario y los grupos. A continuación se presentan los diferentes tipos de cuentas de usuario:

Esta sección describe las herramientas básicas de la línea de comandos para gestionar las cuentas y los grupos de usuarios.

Con las cuentas de usuario que se muestran en la consola web de RHEL se puede:

La consola web de RHEL muestra todas las cuentas de usuario ubicadas en el sistema. Por lo tanto, puede ver al menos una cuenta de usuario justo después del primer inicio de sesión en la consola web.

Después de iniciar sesión en la consola web de RHEL, puede realizar las siguientes operaciones:

Siga los siguientes pasos para añadir cuentas de usuario al sistema y establecer los derechos de administración de las cuentas a través de la consola web de RHEL.

kdump es un servicio que proporciona un mecanismo de volcado de fallos. El servicio permite guardar el contenido de la memoria del sistema para su posterior análisis. kdump utiliza la llamada al sistema kexec para arrancar en el segundo núcleo (un capture kernel) sin reiniciar; y luego captura el contenido de la memoria del núcleo accidentado (un crash dump o un vmcore) y lo guarda. El segundo núcleo reside en una parte reservada de la memoria del sistema.

El procedimiento siguiente le muestra cómo utilizar la pestaña Kernel Dump en la interfaz de la consola web de Red Hat Enterprise Linux para configurar la cantidad de memoria que se reserva para el kernel kdump. El procedimiento también describe cómo especificar la ubicación de destino del archivo de volcado de vmcore y cómo probar su configuración.

RHEL System Roles es una colección de roles y módulos de Ansible que proporcionan una interfaz de configuración consistente para gestionar remotamente múltiples sistemas RHEL. El rol kdump le permite configurar los parámetros básicos de volcado del kernel en varios sistemas.

El siguiente ejemplo de libro de jugadas muestra cómo aplicar el rol de sistema kdump para establecer la ubicación de los archivos de volcado de fallos:

---
- hosts: kdump-test
  vars:
    kdump_path: /var/crash
  roles:
    - rhel-system-roles.kdump

Siga los siguientes pasos para instalar los paquetes para utilizar la utilidad Relax-and-Recover (ReaR), crear un sistema de rescate, configurar y generar una copia de seguridad.

Los dos servicios siguientes gestionan los mensajes de syslog:

El demonio systemd-journald recoge los mensajes de varias fuentes y los reenvía a Rsyslog para su posterior procesamiento. El demonio systemd-journald recoge mensajes de las siguientes fuentes:

El servicio Rsyslog clasifica los mensajes de syslog por tipo y prioridad y los escribe en los archivos del directorio /var/log. El directorio /var/log almacena de forma persistente los mensajes de registro.

Los siguientes subdirectorios bajo el directorio /var/log almacenan los mensajes de syslog.

Siga los pasos de este procedimiento para inspeccionar los archivos de registro utilizando la consola web.

Figura 1.2. Inspección de los archivos de registro en la consola web de RHEL 8

El Diario es un componente de systemd que ayuda a ver y gestionar los archivos de registro. Aborda los problemas relacionados con el registro tradicional, estrechamente integrado con el resto del sistema, y soporta varias tecnologías de registro y gestión de acceso para los archivos de registro.

Puede utilizar el comando journalctl para ver los mensajes en el diario del sistema utilizando la línea de comandos, por ejemplo:

$ journalctl -b | grep kvm
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00
May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock
...

La siguiente sección describe cómo utilizar el Portal del Cliente de Red Hat para obtener ayuda.

El comando sosreport recoge detalles de configuración, información del sistema e información de diagnóstico de un sistema Red Hat Enterprise Linux.

La siguiente sección describe cómo utilizar el comando sosreport para producir informes para sus casos de soporte.

Tenga en cuenta que puede filtrar los resultados añadiendo expresiones globales como argumentos. Consulte Sección 2.3.6, “Especificación de expresiones globales en la entrada de yum” para obtener más detalles.

Tenga en cuenta que puede filtrar los resultados pasando el ID o el nombre de los repositorios como argumentos o añadiendo expresiones globales. Consulte Sección 2.3.6, “Especificación de expresiones globales en la entrada de yum” para obtener más detalles.

Tenga en cuenta que puede filtrar los resultados añadiendo expresiones globales como argumentos. Consulte Sección 2.3.6, “Especificación de expresiones globales en la entrada de yum” para obtener más detalles.

Tenga en cuenta que puede filtrar los resultados añadiendo expresiones globales como argumentos. Consulte Sección 2.7.4, “Especificación de expresiones globales en la entrada de yum” para obtener más detalles.

los comandosyum permiten filtrar los resultados añadiendo uno o más glob expressions como argumentos. Las expresiones globales deben escaparse cuando se pasan como argumentos al comando yum. Para asegurarse de que las expresiones globales se pasen a yum como es debido, utilice uno de los siguientes métodos:

Tenga en cuenta que puede optimizar la búsqueda de paquetes definiendo explícitamente cómo analizar el argumento. Consulte Sección 2.4.3, “Especificación de un nombre de paquete en la entrada de yum” para obtener más detalles.

Para optimizar el proceso de instalación y eliminación, puede añadir los sufijos -n, -na, o -nerva a los comandos yum install y yum remove para definir explícitamente cómo analizar un argumento:

Para comprobar y descargar las actualizaciones de los paquetes de forma automática y periódica, puede utilizar la herramienta DNF Automatic que proporciona el paquete dnf-automatic.

DNF Automatic es una interfaz de línea de comandos alternativa a yum que es adecuada para la ejecución automática y regular utilizando temporizadores systemd, trabajos cron y otras herramientas similares.

DNF Automatic sincroniza los metadatos de los paquetes según sea necesario y luego comprueba si hay actualizaciones disponibles. Después, la herramienta puede realizar una de las siguientes acciones dependiendo de cómo se configure:

El resultado de la operación se comunica a través de un mecanismo seleccionado, como la salida estándar o el correo electrónico.

# systemctl enable dnf-automatic-download.timer

# systemctl start dnf-automatic-download.timer

# systemctl enable dnf-automatic-install.timer

# systemctl start dnf-automatic-install.timer

# systemctl enable dnf-automatic-notifyonly.timer

# systemctl start dnf-automatic-notifyonly.timer

# systemctl enable dnf-automatic.timer

# systemctl start dnf-automatic.timer

Tenga en cuenta que puede optimizar la búsqueda de paquetes definiendo explícitamente cómo analizar el argumento. Consulte Sección 2.6.3, “Especificación de un nombre de paquete en la entrada de yum” para obtener más detalles.

Para optimizar el proceso de instalación y eliminación, puede añadir los sufijos -n, -na, o -nerva a los comandos yum install y yum remove para definir explícitamente cómo analizar un argumento:

Tenga en cuenta que puede filtrar los resultados añadiendo expresiones globales como argumentos. Consulte Sección 2.7.4, “Especificación de expresiones globales en la entrada de yum” para obtener más detalles.

los comandosyum permiten filtrar los resultados añadiendo uno o más glob expressions como argumentos. Las expresiones globales deben escaparse cuando se pasan como argumentos al comando yum. Para asegurarse de que las expresiones globales se pasen a yum como es debido, utilice uno de los siguientes métodos:

Tenga en cuenta que el comando yum history undo sólo revierte los pasos que se realizaron durante la transacción. Si la transacción instaló un nuevo paquete, el comando yum history undo lo desinstala. Si la transacción desinstaló un paquete, el comando yum history undo lo reinstala. yum history undo también intenta degradar todos los paquetes actualizados a sus versiones anteriores, si los paquetes más antiguos aún están disponibles.

Tenga en cuenta que el comando yum history redo sólo repite los pasos que se realizaron durante la transacción.

los comandosyum permiten filtrar los resultados añadiendo uno o más glob expressions como argumentos. Las expresiones globales deben escaparse cuando se pasan como argumentos al comando yum. Para asegurarse de que las expresiones globales se pasen a yum como es debido, utilice uno de los siguientes métodos:

El archivo de configuración /etc/yum.conf contiene las secciones [repository] donde repository es un ID de repositorio único. Las secciones [repository] secciones le permiten definir repositorios yum repositorios individuales.

Para una lista completa de las opciones [repository] opciones, consulte la sección [repository] OPTIONS de la página del manual yum.conf(5).

Para definir un nuevo repositorio, puede:

El archivo de configuración /etc/yum.conf contiene una sección [main]. Los pares clave-valor de esta sección afectan a cómo yum opera y trata los repositorios.

Puede añadir opciones adicionales en el apartado [main] en /etc/yum.conf.

Para obtener una lista completa de las opciones disponibles en [main], consulte la sección [main] OPTIONS de la página del manual yum.conf(5).

yum proporciona plug-ins que amplían y mejoran su funcionamiento. Algunos complementos se instalan por defecto.

La siguiente sección describe cómo activar, configurar y desactivar yum plug-ins.

El sistema systemd y el gestor de servicios proporcionan las siguientes características principales:

El sistema systemd y el gestor de servicios están diseñados para ser mayormente compatibles con SysV init y Upstart. Los siguientes son los cambios de compatibilidad más notables con respecto al sistema Red Hat Enterprise Linux 6 que utilizaba SysV init:

Para una lista detallada de los cambios de compatibilidad introducidos con systemdconsulte el Manual de planificación de la migración para Red Hat Enterprise Linux 7.

Para listar todas las unidades de servicio cargadas actualmente, escriba lo siguiente en un prompt del shell:

systemctl list-units --type service

Para cada archivo de unidad de servicio, este comando muestra su nombre completo (UNIT) seguido de una nota sobre si el archivo de unidad ha sido cargado (LOAD), su estado de activación de archivo de unidad de alto nivel (ACTIVE) y de bajo nivel (SUB), y una breve descripción (DESCRIPTION).

Por defecto, el comando systemctl list-units sólo muestra las unidades activas. Si desea listar todas las unidades cargadas independientemente de su estado, ejecute este comando con la opción de línea de comandos --all o -a:

systemctl list-units --type service --all

También puede listar todas las unidades de servicio disponibles para ver si están habilitadas. Para ello, escriba:

systemctl list-unit-files --type service

Para cada unidad de servicio, este comando muestra su nombre completo (UNIT FILE) seguido de información sobre si la unidad de servicio está habilitada o no (STATE). Para obtener información sobre cómo determinar el estado de las unidades de servicio individuales, consulte Visualización del estado del servicio.

$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
…​
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'

$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
…​
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

Para mostrar información detallada sobre una unidad de servicio que corresponde a un servicio del sistema, escriba lo siguiente en un prompt del shell:

systemctl status name.service

Sustituya name por el nombre de la unidad de servicio que desea inspeccionar (por ejemplo, gdm). Este comando muestra el nombre de la unidad de servicio seleccionada seguido de su breve descripción, uno o más campos descritos en Tabla 3.5, “Información de la unidad de servicio disponible”, y si es ejecutado por el usuario root, también las entradas de registro más recientes.

Para verificar únicamente que una unidad de servicio en particular se está ejecutando, ejecute el siguiente comando:

systemctl is-active name.service

Del mismo modo, para determinar si una determinada unidad de servicio está habilitada, escriba:

systemctl is-enabled name.service

Tenga en cuenta que tanto systemctl is-active como systemctl is-enabled devuelven un estado de salida de 0 si la unidad de servicio especificada se está ejecutando o está habilitada. Para obtener información sobre cómo listar todas las unidades de servicio cargadas actualmente, consulte Listado de servicios.

# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno…​
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r…​

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

Para iniciar una unidad de servicio que corresponde a un servicio del sistema, escriba lo siguiente en un indicador del shell como root:

systemctl start name.service

Sustituya name por el nombre de la unidad de servicio que desea iniciar (por ejemplo, gdm). Este comando inicia la unidad de servicio seleccionada en la sesión actual. Para obtener información sobre cómo activar una unidad de servicio para que se inicie en el momento del arranque, consulte Activación de un servicio. Para obtener información sobre cómo determinar el estado de una determinada unidad de servicio, consulte Visualización del estado del servicio.

# systemctl start httpd.service

Para detener una unidad de servicio que corresponde a un servicio del sistema, escriba lo siguiente en un indicador del shell como root:

systemctl stop name.service

Sustituya name por el nombre de la unidad de servicio que desea detener (por ejemplo, bluetooth). Este comando detiene la unidad de servicio seleccionada en la sesión actual. Para obtener información sobre cómo desactivar una unidad de servicio y evitar que se inicie en el momento del arranque, consulte Desactivación de un servicio. Para obtener información sobre cómo determinar el estado de una determinada unidad de servicio, consulte Visualización del estado del servicio.

# systemctl stop bluetooth.service

Para reiniciar una unidad de servicio que corresponde a un servicio del sistema, escriba lo siguiente en un indicador del shell como root:

systemctl restart name.service

Sustituya name por el nombre de la unidad de servicio que desea reiniciar (por ejemplo, httpd). Este comando detiene la unidad de servicio seleccionada en la sesión actual y la reinicia inmediatamente. Es importante destacar que si la unidad de servicio seleccionada no está en funcionamiento, este comando también la inicia. Para indicar systemd que reinicie una unidad de servicio sólo si el servicio correspondiente ya se está ejecutando, ejecute el siguiente comando como root:

systemctl try-restart name.service

Algunos servicios del sistema también permiten recargar su configuración sin interrumpir su ejecución. Para ello, escriba como root:

systemctl reload name.service

Tenga en cuenta que los servicios del sistema que no soportan esta función ignoran este comando por completo. Por comodidad, el comando systemctl también admite los comandos reload-or-restart y reload-or-try-restart que reinician dichos servicios en su lugar. Para obtener información sobre cómo determinar el estado de una determinada unidad de servicio, consulte Visualización del estado del servicio.

# systemctl reload httpd.service

Para configurar una unidad de servicio que corresponda a un servicio del sistema para que se inicie automáticamente en el momento del arranque, escriba lo siguiente en un indicador del shell como root:

systemctl enable name.service

Sustituya name por el nombre de la unidad de servicio que desea activar (por ejemplo, httpd). Este comando lee la sección [Install] de la unidad de servicio seleccionada y crea los enlaces simbólicos apropiados al archivo /usr/lib/systemd/system/name.service en el directorio /etc/systemd/system/ y sus subdirectorios. Sin embargo, este comando no reescribe los enlaces que ya existen. Si quiere asegurarse de que los enlaces simbólicos se vuelven a crear, utilice el siguiente comando como root:

systemctl reenable name.service

Este comando desactiva la unidad de servicio seleccionada y la vuelve a activar inmediatamente. Para obtener información sobre cómo determinar si una determinada unidad de servicio está habilitada para iniciarse en el momento del arranque, consulte Visualización del estado del servicio. Para obtener información sobre cómo iniciar un servicio en la sesión actual, consulte Iniciar un servicio.

# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

Para evitar que una unidad de servicio que corresponde a un servicio del sistema se inicie automáticamente en el momento del arranque, escriba lo siguiente en un indicador del shell como root:

systemctl disable name.service

Sustituya name por el nombre de la unidad de servicio que desea desactivar (por ejemplo, bluetooth). Este comando lee la sección [Install] de la unidad de servicio seleccionada y elimina los enlaces simbólicos apropiados al archivo /usr/lib/systemd/system/name.service del directorio /etc/systemd/system/ y sus subdirectorios. Además, puedes enmascarar cualquier unidad de servicio para evitar que sea iniciada manualmente o por otro servicio. Para ello, ejecute el siguiente comando como root:

systemctl mask name.service

Este comando sustituye el archivo /etc/systemd/system/name.service con un enlace simbólico a /dev/null, haciendo que el archivo de la unidad real sea inaccesible para systemd. Para revertir esta acción y desenmascarar una unidad de servicio, escriba como root:

systemctl unmask name.service

Para obtener información sobre cómo determinar si una determinada unidad de servicio está habilitada para iniciarse en el momento del arranque, consulte Visualización del estado del servicio. Para obtener información sobre cómo detener un servicio en la sesión actual, consulte Detener un servicio.

# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

En systemdexisten dependencias positivas y negativas entre los servicios. El inicio de un servicio particular puede requerir el inicio de uno o más servicios (dependencia positiva) o la detención de uno o más servicios (dependencia negativa).

Cuando se intenta iniciar un nuevo servicio systemd resuelve todas las dependencias automáticamente. Tenga en cuenta que esto se hace sin notificación explícita al usuario. Si ya se está ejecutando un servicio, y se intenta iniciar otro servicio con una dependencia negativa, el primer servicio se detiene automáticamente.

Por ejemplo, si está ejecutando el servicio postfix, y trata de iniciar el servicio sendmail, systemd primero detiene automáticamente postfix, porque estos dos servicios entran en conflicto y no pueden ejecutarse en el mismo puerto.

Las versiones anteriores de Red Hat Enterprise Linux se distribuían con SysV init o Upstart, e implementaban un conjunto predefinido de niveles de ejecución que representaban modos específicos de operación. Estos niveles de ejecución estaban numerados del 0 al 6 y eran definidos por una selección de servicios del sistema que se ejecutaban cuando un nivel de ejecución particular era habilitado por el administrador del sistema. A partir de Red Hat Enterprise Linux 7, el concepto de niveles de ejecución ha sido reemplazado por los objetivos de systemd.

Red Hat Enterprise Linux 7 fue distribuido con un número de objetivos predefinidos que son más o menos similares al conjunto estándar de niveles de ejecución de las versiones anteriores. Por razones de compatibilidad, también proporciona alias para estos objetivos que se asignan directamente a los niveles de ejecución SysV.

La siguiente tabla proporciona una lista completa de los niveles de ejecución de SysV y sus correspondientes objetivos de systemd:

La siguiente tabla compara los comandos SysV init con systemctl. Utilice la utilidad systemctl para ver, cambiar o configurar los objetivos de systemd:

La unidad de destino por defecto está representada por el archivo /etc/systemd/system/default.target.

Por defecto, el comando systemctl list-units sólo muestra las unidades activas.

La unidad de destino por defecto está representada por el archivo /etc/systemd/system/default.target. El siguiente procedimiento describe cómo cambiar el objetivo por defecto utilizando el comando systemctl:

El siguiente procedimiento describe cómo cambiar el destino por defecto creando un enlace simbólico al mismo.

Este procedimiento explica cómo cambiar la unidad de destino en la sesión actual utilizando el comando systemctl.

Sustituya multi-user por el nombre de la unidad de destino que desee utilizar por defecto.

Rescue mode proporciona un cómodo entorno de usuario único y permite reparar el sistema en situaciones en las que no puede completar un proceso de arranque normal. En el modo de rescate, el sistema intenta montar todos los sistemas de archivos locales e iniciar algunos servicios importantes del sistema, pero no activa las interfaces de red ni permite que haya más usuarios conectados al sistema al mismo tiempo.

Emergency mode proporciona el entorno más mínimo posible y permite reparar el sistema incluso en situaciones en las que el sistema no puede entrar en modo de rescate. En el modo de emergencia, el sistema monta el sistema de archivos raíz sólo para lectura, no intenta montar ningún otro sistema de archivos local, no activa las interfaces de red y sólo inicia unos pocos servicios esenciales.

La utilidad systemctl proporciona comandos para apagar el sistema, sin embargo el comando tradicional shutdown también es soportado. Aunque el comando shutdown llamará a la utilidad systemctl para realizar el apagado, tiene la ventaja de que también admite un argumento de tiempo. Esto es particularmente útil para el mantenimiento programado y para dar más tiempo a los usuarios para reaccionar al aviso de que se ha programado un cierre del sistema. La opción de cancelar el apagado también puede ser una ventaja.

Uso de los comandos systemctl

Para apagar el sistema y desconectar la máquina, escriba lo siguiente en un prompt del shell como root:

systemctl poweroff

Para apagar y detener el sistema sin apagar la máquina, ejecute el siguiente comando como root:

systemctl halt

Por defecto, la ejecución de cualquiera de estos comandos hace que systemd envíe un mensaje informativo a todos los usuarios que estén conectados al sistema. Para evitar systemd el envío de este mensaje, ejecute el comando seleccionado con la opción de línea de comandos --no-wall, por ejemplo:

systemctl --no-wall poweroff

Utilizar el comando de apagado

Para apagar el sistema y desconectar la máquina a una hora determinada, utilice un comando con el siguiente formato como root:

shutdown --poweroff hh:mm

Donde hh:mm es la hora en formato de reloj de 24 horas. El archivo /run/nologin se crea 5 minutos antes de que se apague el sistema para evitar nuevos inicios de sesión. Cuando se utiliza un argumento de tiempo, se puede añadir al comando un mensaje opcional, el wall message.

Para apagar y detener el sistema después de un retraso, sin apagar la máquina, utilice un comando con el siguiente formato como root:

apagado --halt m

Donde m es el tiempo de retraso en minutos. La palabra clave now es un alias de 0.

El usuario de root puede cancelar un cierre pendiente de la siguiente manera:

shutdown -c

Consulte la página del manual shutdown(8) para conocer otras opciones de comandos.

Para reiniciar el sistema, ejecute el siguiente comando como root:

systemctl reboot

Por defecto, este comando hace que systemd envíe un mensaje informativo a todos los usuarios que están actualmente conectados al sistema. Para evitar systemd el envío de este mensaje, ejecute este comando con la opción de línea de comandos --no-wall:

systemctl --no-wall reboot

Para suspender el sistema, escriba lo siguiente en un prompt del shell como root:

systemctl suspend

Este comando guarda el estado del sistema en la RAM y, con la excepción del módulo RAM, apaga la mayoría de los dispositivos de la máquina. Cuando se vuelve a encender la máquina, el sistema restaura su estado desde la RAM sin tener que arrancar de nuevo. Como el estado del sistema se guarda en la RAM y no en el disco duro, restaurar el sistema desde el modo de suspensión es significativamente más rápido que restaurarlo desde la hibernación, pero como consecuencia, un estado de sistema suspendido también es vulnerable a los cortes de energía.

Para obtener información sobre cómo hibernar el sistema, consulte Sección 3.4.4, “Hibernación del sistema”.

Para hibernar el sistema, escriba lo siguiente en un indicador del shell como root:

systemctl hibernate

Este comando guarda el estado del sistema en el disco duro y apaga la máquina. Cuando se vuelve a encender la máquina, el sistema restaura su estado a partir de los datos guardados sin tener que arrancar de nuevo. Como el estado del sistema se guarda en el disco duro y no en la RAM, la máquina no tiene que mantener la energía eléctrica en el módulo de RAM, pero como consecuencia, restaurar el sistema desde la hibernación es significativamente más lento que restaurarlo desde el modo de suspensión.

Para hibernar y suspender el sistema, ejecute el siguiente comando como root:

systemctl hybrid-sleep

Para obtener información sobre cómo suspender el sistema, consulte Sección 3.4.3, “Suspender el sistema”.

Un archivo de unidad contiene directivas de configuración que describen la unidad y definen su comportamiento. Varios comandos de systemctl trabajan con archivos de unidad en segundo plano. Para realizar ajustes más finos, el administrador del sistema debe editar o crear archivos de unidad manualmente. Tabla 3.1, “Ubicación de los archivos de la unidad Systemd” enumera tres directorios principales donde se almacenan los archivos de unidad en el sistema, el directorio /etc/systemd/system/ está reservado para los archivos de unidad creados o personalizados por el administrador del sistema.

Los nombres de los archivos de las unidades tienen la siguiente forma:

unit_nametype_extension

Aquí, unit_name representa el nombre de la unidad y type_extension identifica el tipo de unidad, véase Tabla 3.2, “Tipos de unidades systemd disponibles” para una lista completa de tipos de unidad. Por ejemplo, normalmente hay sshd.service así como sshd.socket unidad presente en su sistema.

Los archivos de unidad pueden complementarse con un directorio para archivos de configuración adicionales. Por ejemplo, para añadir opciones de configuración personalizadas a sshd.service, cree el archivo sshd.service.d/custom.conf e inserte allí las directivas adicionales. Para obtener más información sobre los directorios de configuración, consulte Modificación de los archivos de unidad existentes.

También se pueden crear los directorios sshd.service.wants/ y sshd.service.requires/. Estos directorios contienen enlaces simbólicos a archivos de unidad que son dependencias del servicio sshd. Los enlaces simbólicos se crean automáticamente durante la instalación según las opciones de archivos de unidad [Install] o en tiempo de ejecución según las opciones [Unit]. También es posible crear estos directorios y enlaces simbólicos manualmente. Para más detalles sobre las opciones [Install] y [Unit], consulte las tablas siguientes.

Muchas de las opciones de los archivos de unidad pueden establecerse mediante las denominadas unit specifiers, cadenas comodín que se sustituyen dinámicamente por parámetros de unidad cuando se carga el archivo de unidad. Esto permite la creación de archivos de unidad genéricos que sirven como plantillas para generar unidades instanciadas. Para más detalles, véase Trabajar con unidades instanciadas.

Los archivos unitarios suelen constar de tres secciones:

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.

Antes de dedicar tiempo a convertir un script de init de SysV a un archivo de unidad, asegúrese de que la conversión no se haya hecho ya en otro lugar. Todos los servicios centrales instalados en Red Hat Enterprise Linux vienen con archivos de unidad por defecto, y lo mismo se aplica a muchos paquetes de software de terceros.

Convertir un script de init en un archivo de unidad requiere analizar el script y extraer la información necesaria del mismo. A partir de estos datos se puede crear un archivo de unidad. Como los scripts de init pueden variar enormemente según el tipo de servicio, es posible que tenga que emplear más opciones de configuración para la conversión que las que se describen en este capítulo. Tenga en cuenta que algunos niveles de personalización que estaban disponibles con los scripts init ya no son soportados por las unidades systemd.

La mayor parte de la información necesaria para la conversión se proporciona en la cabecera del script. El siguiente ejemplo muestra la sección inicial del script init utilizado para iniciar el servicio postfix en Red Hat Enterprise Linux 6:

!/bin/bash # postfix Postfix Mail Transfer Agent # chkconfig: 2345 80 30 # description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # processname: master # pidfile: /var/spool/postfix/pid/master.pid # config: /etc/postfix/main.cf # config: /etc/postfix/master.cf  BEGIN INIT INFO # Provides: postfix MTA # Required-Start: $local_fs $network $remote_fs # Required-Stop: $local_fs $network $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start and stop postfix # Description: Postfix is a Mail Transport Agent, which is the program that moves mail from one machine to another. # END INIT INFO

En el ejemplo anterior, sólo las líneas que comienzan con # chkconfig y # description son obligatorias, por lo que es posible que no encuentre el resto en diferentes archivos init. El texto encerrado entre las líneas BEGIN INIT INFO y END INIT INFO se llama Linux Standard Base (LSB) header. Si se especifica, las cabeceras LSB contienen directivas que definen la descripción del servicio, las dependencias y los niveles de ejecución por defecto. Lo que sigue es un resumen de las tareas analíticas destinadas a recopilar los datos necesarios para un nuevo archivo de unidad. Se utiliza como ejemplo el script init de postfix.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

Los servicios instalados en el sistema vienen con archivos de unidad por defecto que se almacenan en el directorio /usr/lib/systemd/system/. Los administradores del sistema no deben modificar estos archivos directamente, por lo que cualquier personalización debe limitarse a los archivos de configuración en el directorio /etc/systemd/system/.

Es posible instanciar múltiples unidades desde un único archivo de configuración de plantilla en tiempo de ejecución. El carácter "@" se utiliza para marcar la plantilla y asociar las unidades con ella. Las unidades instanciadas pueden iniciarse desde otro archivo de unidades (utilizando las opciones Requires o Wants ), o con el comando systemctl start. Las unidades de servicio instanciadas se nombran de la siguiente manera:

template_name@instance_name.service

Donde template_name representa el nombre del archivo de configuración de la plantilla. Sustituya instance_name por el nombre de la instancia de la unidad. Varias instancias pueden apuntar al mismo archivo de plantilla con opciones de configuración comunes para todas las instancias de la unidad. El nombre de la unidad de plantilla tiene la forma de:

unit_name@.service

Por ejemplo, la siguiente configuración de Wants en un archivo de unidad:

Wants=getty@ttyA.service getty@ttyB.service

primero hace que systemd busque las unidades de servicio dadas. Si no se encuentran tales unidades, la parte entre "@" y el sufijo de tipo se ignora y systemd busca el archivo getty@.service, lee la configuración de éste y arranca los servicios.

Por ejemplo, la plantilla getty@.service contiene las siguientes directivas:

[Unit]
Description=Getty on %I
…​
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
…​

Cuando se instancian getty@ttyA.service y getty@ttyB.service desde la plantilla anterior, Description= se resuelve como Getty on ttyA y Getty on ttyB.

Para examinar el rendimiento del arranque del sistema, puede utilizar el comando systemd-analyze. Este comando tiene muchas opciones disponibles. Sin embargo, esta sección cubre sólo las seleccionadas que pueden ser importantes para el ajuste de systemd con el fin de acortar el tiempo de arranque.

Para obtener una lista completa y una descripción detallada de todas las opciones, consulte la página man systemd-analyze.

$ systemctl list-unit-files --state=enabled

Analizar el tiempo total de arranque

$ systemd-analyze

Analizar el tiempo de inicialización de la unidad

$ systemd-analyze blame

La salida enumera las unidades en orden descendente según el tiempo que tardaron en inicializarse durante el último arranque con éxito.

Identificación de unidades críticas

$ systemd-analyze critical-chain

La salida destaca las unidades que ralentizan críticamente el arranque con el color rojo.

Figura 3.1. La salida del comando systemd-analyze critical-chain

Si el tiempo de arranque de tu sistema es largo, puedes acortarlo deshabilitando algunos de los servicios habilitados por defecto en el arranque.

Para listar estos servicios, ejecute:

$ systemctl list-unit-files --state=enabled

Para desactivar un servicio, ejecute:

# systemctl disable service_name

Sin embargo, ciertos servicios deben permanecer activados para que su sistema operativo sea seguro y funcione de la manera que usted necesita.

Puede utilizar la tabla siguiente como una guía para seleccionar los servicios que puede deshabilitar de forma segura. La tabla enumera todos los servicios habilitados por defecto en una instalación mínima de Red Hat Enterprise Linux 8, y para cada servicio indica si este servicio puede ser deshabilitado de forma segura.

La tabla también proporciona más información sobre las circunstancias en las que se puede desactivar el servicio, o la razón por la que no se debe desactivar el servicio.

Para encontrar más información sobre un servicio, puede ejecutar uno de los siguientes comandos:

$ systemctl cat <nombre_del_servicio>

$ systemctl help <nombre_servicio>

El comando systemctl cat proporciona el contenido del archivo de servicio ubicado en /usr/lib/systemd/system/<service>, así como todas las anulaciones aplicables. Los overrides aplicables incluyen los overrides de los archivos de unidad del archivo /etc/systemd/system/<service> o los archivos drop-in de un directorio correspondiente de unit.type.d.

Para más información sobre los archivos drop-in, consulte la página man systemd.unit.

El comando systemctl help muestra la página man del servicio en cuestión.