Sincronización de tiempo en Linux: NTP, Chrony y systemd-timesyncd

La mayoría de las personas están al tanto del tiempo. Nos levantamos a tiempo para cumplir con nuestros rituales matutinos y salir al trabajo, hacer una pausa para el almuerzo, cumplir con los plazos del proyecto, celebrar cumpleaños y festividades, abordar un avión y así sucesivamente.

Además, algunos de nosotros estamos obsesionados con el tiempo. Mi reloj funciona con energía solar y obtiene la hora exacta del Instituto Nacional de Estándares y Tecnología (NIST) en Fort Collins, Colorado, a través de una estación de radio de onda larga. WWVBLas señales de tiempo se sincronizan con relojes atómicos también ubicados en Fort Collins. Mi Fitbit se sincroniza con mi teléfono, que a su vez se sincroniza con un servidor NTP, que finalmente se sincroniza con los relojes atómicos.

Los dispositivos también llevan la cuenta del tiempo.

Hay muchas razones por las que nuestros dispositivos y computadoras necesitan una hora exacta. Por ejemplo, en el sector bancario, en los mercados de valores y en otras empresas financieras, las transacciones deben ejecutarse en el orden adecuado, y los diferentes secuencias temporales exactas son cruciales para esto.

Nuestros teléfonos, tabletas, automóviles, sistemas GPS y computadoras requieren un ajuste preciso de la hora y la fecha. Quiero que el reloj en el escritorio de mi computadora muestre la hora correcta. Quiero que en mi calendario local las recordatorios aparezcan a la hora adecuada. La hora correcta también garantiza que las tareas cron y systemd se ejecuten en el momento adecuado.

La fecha y la hora también son importantes para el registro, por lo que es un poco más fácil encontrar ciertos registros basándose en la fecha y la hora. Por ejemplo, una vez trabajé en DevOps (en ese entonces no se le llamaba así) y estaba configurando un sistema de correo electrónico en Carolina del Norte. Antes manejábamos más de 20 millones de correos al día. Rastrear correos electrónicos a través de una serie de servidores o determinar la secuencia exacta de eventos usando archivos de registro en hosts geográficamente distribuidos puede ser mucho más fácil si las computadoras relevantes están sincronizadas en el tiempo.

El tiempo es uno, pero hay muchos relojes.

Los hosts de Linux deben tener en cuenta que hay un tiempo del sistema y un tiempo RTC. RTC (Real Time Clock — reloj de tiempo real) es un nombre algo extraño y no muy preciso para los relojes de hardware.

Los relojes de hardware funcionan continuamente, incluso cuando la computadora está apagada, utilizando la batería en la placa base del sistema. La función principal del RTC es almacenar la hora cuando no hay conexión con un servidor de tiempo. En los tiempos en que no se podía conectar a un servidor de tiempo a través de Internet, cada computadora necesitaba tener un reloj interno preciso. Los sistemas operativos debían consultar el RTC al inicio, y el usuario tenía que establecer manualmente la hora del sistema usando la interfaz de configuración de hardware del BIOS para asegurarse de que fuera correcta.

Los relojes de hardware no comprenden el concepto de zonas horarias; el RTC solo almacena la hora, no la zona horaria ni el desplazamiento de UTC (Tiempo Universal Coordinado, que también se conoce como GMT o Tiempo Medio de Greenwich). Puede configurar el RTC utilizando una herramienta de la que hablaré más adelante en este artículo.

La hora del sistema es el tiempo que el sistema operativo muestra en el reloj GUI en su escritorio, en la salida del comando date, en las marcas de tiempo de los registros. También se refiere a la hora de creación, modificación y apertura de archivos.

En la página man para rtc hay una descripción completa del RTC y los relojes del sistema.

¿Qué pasa con NTP?

Las computadoras en todo el mundo utilizan NTP (Protocolo de Tiempo de Red) para sincronizar su hora con relojes de referencia estándar a través de Internet utilizando una jerarquía de servidores NTP. Los servidores de tiempo principales están en el nivel 1 y están conectados directamente a varios servicios nacionales de tiempo en el nivel 0 a través de satélites, radio o incluso módems a través de líneas telefónicas. Los servicios de tiempo en el nivel 0 pueden ser relojes atómicos, un receptor de radio ajustado a señales transmitidas por relojes atómicos, o un receptor GPS que utiliza señales horarias de alta precisión transmitidas por satélites GPS.

En la gran mayoría de los servidores de referencia, hay miles de servidores NTP de stratum 2 públicos disponibles para todos. Muchas organizaciones y usuarios (incluyéndome a mí) que tienen muchos hosts que requieren un servidor NTP prefieren instalar sus propios servidores de tiempo, por lo que solo un host local se conecta a stratum 2 o 3. Luego, configuran los nodos restantes en la red para usar el servidor de tiempo local. En el caso de mi red doméstica, este es un servidor de nivel 3.

Diversas implementaciones de NTP

La implementación original de NTP es ntpd. Luego se unieron otras dos versiones más nuevas, chronyd y systemd-timesyncd. Las tres sincronizan el tiempo del host local con un servidor de tiempo NTP. El servicio systemd-timesyncd no es tan confiable como chronyd, pero es suficiente para la mayoría de los propósitos. Si el RTC no está sincronizado, puede corregir gradualmente el tiempo del sistema para sincronizarse con el servidor NTP cuando el tiempo del sistema local presenta un ligero desajuste. El servicio systemd-timesync no puede ser utilizado como un servidor de tiempo.

Chrony es una implementación de NTP que contiene dos programas: el demonio chronyd y una interfaz de línea de comandos llamada chronyc. Chrony tiene algunas funciones que en muchos casos son simplemente imprescindibles:

• Chrony puede sincronizarse con un servidor de tiempo mucho más rápido que el viejo servicio ntpd. Esto es bueno para laptops o computadoras de escritorio que no están encendidas todo el tiempo.
• Puede compensar las fluctuaciones en las frecuencias del reloj, por ejemplo, cuando el host entra en modo de suspensión o se despierta, o cuando la frecuencia cambia debido a un salto repentino que reduce las frecuencias de reloj bajo cargas bajas.
• Resuelve problemas de tiempo relacionados con conexiones de red inestables o congestión de la red.
• Regula las latencias de la red.
• Después de la sincronización inicial del tiempo, Chrony nunca detiene el reloj. Esto proporciona intervalos de tiempo estables y consistentes para muchos servicios y aplicaciones del sistema.
• Chrony puede funcionar incluso sin conexión a la red. En este caso, el host local o el servidor pueden actualizarse manualmente.
• Chrony puede actuar como un servidor NTP.

Una vez más: NTP es un protocolo que puede implementarse en un host Linux utilizando Chrony o systemd-timesyncd.

Los paquetes RPM de NTP, Chrony y systemd-timesyncd están disponibles en los repositorios estándar de Fedora. RPM systemd-udev es un gestor de eventos del núcleo, que en Fedora se instala por defecto, pero no es obligatorio usar.

Puedes instalar los tres y cambiar entre ellos, pero eso solo creará molestias innecesarias. Por lo tanto, es mejor no hacerlo. Las versiones modernas de Fedora, CentOS y RHEL han pasado a Chrony como la implementación estándar, además de tener systemd-timesyncd. Creo que Chrony funciona bien, ofrece una mejor interfaz que el servicio NTP, proporciona mucha más información y mejora el control, lo que sin duda gustará a los administradores del sistema.

Desactivación de servicios NTP

Es posible que en tu host ya se esté ejecutando un servicio NTP. Si es así, necesitarás desactivarlo antes de cambiar a otra cosa. Tenía chronyd en ejecución, así que utilicé los siguientes comandos para detenerlo y desactivarlo. Ejecuta los comandos correspondientes para cualquier demonio NTP que estés utilizando en tu host:

[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#

Verifica que el servicio esté detenido y desactivado:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - Cliente/servidor NTP
     Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Verificación del estado antes de iniciar

El estado de sincronización del sistema permite determinar si el servicio NTP está en ejecución. Dado que aún no has iniciado NTP, el comando timesync-status lo indicará:

[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.

Una consulta directa del estado proporciona información importante. Por ejemplo, el comando timedatectl sin argumentos o parámetros ejecuta por defecto la subcomando status:

[root@testvm1 ~]# timedatectl status
           Hora local: Vie 2020-05-15 08:43:10 EDT  
           Hora universal: Vie 2020-05-15 12:43:10 UTC  
                 Hora RTC: Vie 2020-05-15 08:43:08      
                Zona horaria: America/New_York (EDT, -0400)
Reloj del sistema sincronizado: no                          
              Servicio NTP: inactivo                    
          RTC en TZ local: sí                    

Advertencia: El sistema está configurado para leer la hora RTC en la zona horaria local.
         Este modo no puede ser completamente soportado. Creará varios problemas
         con los cambios de zona horaria y ajustes de horario de verano. La hora RTC
         nunca se actualiza; depende de instalaciones externas para mantenerla.
         Si es posible, use RTC en UTC llamando a
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Así obtendrá la hora local para su host, la hora UTC y la hora RTC. En este caso, la hora del sistema está configurada en la zona horaria America / New_York (TZ), el RTC está establecido en la hora en la zona horaria local, y el servicio NTP no está activo. La hora del RTC ha comenzado a desviarse un poco de la hora del sistema. Esto es normal para sistemas cuyos relojes no han sido sincronizados. La cantidad de desviación en el host depende del tiempo transcurrido desde la última sincronización del sistema.

También recibimos una advertencia sobre el uso de la hora local para el RTC; esto se refiere a cambios en la zona horaria y configuraciones de horario de verano. Si la computadora está apagada en el momento en que deben realizarse los cambios, la hora RTC no cambiará. Pero para servidores u otros hosts que funcionan las 24 horas, esto no es un problema. Además, cualquier servicio que proporcione sincronización NTP ajustará la hora del host aún en la fase inicial de arranque, por lo que después de que finalice el arranque, la hora será correcta de nuevo.

Configuración de la zona horaria

Por lo general, se especifica la zona horaria durante el procedimiento de instalación, y no hay necesidad de cambiarla posteriormente. Sin embargo, hay casos en los que es necesario cambiar la zona horaria. Hay varias herramientas que pueden ayudar. Para determinar la zona horaria local, Linux utiliza archivos de zonas horarias. Estos archivos se encuentran en el directorio /usr/share/zoneinfo. Por defecto, para mi zona horaria, el sistema establece esto: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Pero no necesita conocer tales detalles para cambiar la zona horaria.

Lo principal es conocer el nombre oficial de la zona horaria de su ubicación y el comando correspondiente. Supongamos que desea cambiar la zona horaria a Los Ángeles:

[root@testvm2 ~]# timedatectl list-timezones | column

America/La_Paz                  Europe/Budapest
America/Lima                    Europe/Chisinau
America/Los_Angeles             Europe/Copenhagen
America/Maceio                  Europe/Dublin
America/Managua                 Europe/Gibraltar
America/Manaus                  Europe/Helsinki

Ahora puedes establecer la zona horaria. Usé el comando date para verificar los cambios, pero también puedes usar timedatectl:

[root@testvm2 ~]# date
Mar 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Mar 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#

Ahora puedes cambiar la zona horaria de tu host a la hora local.

systemd-timesyncd

El demonio systemd timesync proporciona una implementación de NTP que es fácil de manejar en el contexto de systemd. Se instala por defecto en Fedora y Ubuntu. Sin embargo, solo se inicia por defecto en Ubuntu. No estoy seguro acerca de otras distribuciones. Puedes verificar por ti mismo:

[root@testvm1 ~]# systemctl status systemd-timesyncd

Configuración de systemd-timesyncd

El archivo de configuración para systemd-timesyncd es /etc/systemd/timesyncd.conf. Es un archivo simple con menos opciones habilitadas que los antiguos servicios NTP y chronyd. Este es el contenido de este archivo (sin cambios adicionales) en mi máquina virtual con Fedora:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

La única sección que contiene, además de los comentarios, es [Time]. Todas las demás líneas están comentadas. Estos son los valores predeterminados que no necesitan ser cambiados (a menos que tengas razones para hacerlo). Si no tienes un servidor de tiempo NTP definido en la línea NTP =, Fedora utiliza por defecto un servidor de tiempo de respaldo de Fedora. Normalmente añado mi servidor de tiempo:

NTP=myntpserver

Iniciando timesync

Puedes iniciar y activar systemd-timesyncd así:

[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Se creó un enlace simbólico /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Se creó un enlace simbólico /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service → /usr/lib/systemd/system/systemd-timesyncd.service.
[root@testvm2 ~]# systemctl start systemd-timesyncd.service
[root@testvm2 ~]#

Configuración de relojes de hardware

Así es como se ve la situación después de iniciar timesyncd:

[root@testvm2 systemd]# timedatectl
               Hora local: Sab 2020-05-16 14:34:54 EDT  
           Hora universal: Sab 2020-05-16 18:34:54 UTC  
                 Hora RTC: Sab 2020-05-16 14:34:53      
              Zona horaria: America/New_York (EDT, -0400)
Reloj del sistema sincronizado: sí                          
              Servicio NTP: activo                      
          RTC en TZ local: no    

Inicialmente, la diferencia entre RTC y la hora local (EDT) no supera un segundo, y la discrepancia aumenta un par de segundos durante los siguientes días. Dado que en el RTC no hay concepto de zonas horarias, el comando timedatectl debe realizar una comparación para determinar la zona horaria necesaria. Si la hora del RTC no coincide exactamente con la hora local, significa que tampoco coincide con la zona horaria local.

En busca de información adicional, verifiqué el estado de systemd-timesync y descubrí lo siguiente:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Sincronización de Tiempo de Red
     Cargado: cargado (/usr/lib/systemd/system/systemd-timesyncd.service; habilitado; ajuste del proveedor: deshabilitado)
     Activo: activo (en ejecución) desde Sat 2020-05-16 13:56:53 EDT; hace 18h
       Docs: man:systemd-timesyncd.service(8)
   PID principal: 822 (systemd-timesyn)
     Estado: "Sincronización inicial al servidor de tiempo 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tareas: 2 (límite: 10365)
     Memoria: 2.8M
        CPU: 476ms
     CGrupo: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

May 16 09:57:24 testvm2.both.org systemd[1]: Iniciando Sincronización de Tiempo de Red...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: La hora del reloj del sistema no está establecida o se ha retrocedido, restaurando desde la marca de tiempo registrada: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Iniciada la Sincronización de Tiempo de Red.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Sincronización inicial al servidor de tiempo 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Presta atención al mensaje del registro que indica que la hora del sistema no está establecida o se ha retrocedido. El servicio Timesync establece la hora del sistema en función de la marca de tiempo. Las marcas de tiempo son mantenidas por el demonio timesync y se crean en cada sincronización exitosa.

El comando timedatectl no tiene la capacidad de tomar el valor de los relojes de hardware de los relojes del sistema. Solo puede establecer la fecha y hora a partir del valor ingresado en la línea de comandos. Puedes establecer el RTC al mismo valor que la hora del sistema usando el comando hwclock:

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Hora local: Mon 2020-05-18 13:56:46 EDT  
           Hora universal: Mon 2020-05-18 17:56:46 UTC  
                 Hora RTC: Mon 2020-05-18 13:56:46      
                Zona horaria: America/New_York (EDT, -0400)
Reloj del sistema sincronizado: sí                          
              Servicio NTP: activo                      
          RTC en TZ local: sí

La opción --localtime indica que el reloj de hardware muestra la hora local en lugar de UTC.

¿Por qué necesitas RTC en absoluto?

Cualquier implementación de NTP ajustará el reloj del sistema al momento del arranque. ¿Y para qué sirve entonces el RTC? No es del todo así: esto solo ocurrirá si tiene una conexión de red con un servidor de tiempo. Sin embargo, muchos sistemas no tienen acceso constante a una conexión de red, por lo que los relojes de hardware son útiles para que Linux pueda establecer la hora del sistema basándose en ellos. Es mejor que ajustar la hora manualmente, incluso si puede diferir del tiempo real.

Conclusión

En este artículo se abordan algunas herramientas para gestionar fechas, horas y zonas horarias. La herramienta systemd-timesyncd proporciona un cliente NTP que puede sincronizar el tiempo en el host local con un servidor NTP. Sin embargo, systemd-timesyncd no ofrece un servicio de servidor, por lo que si necesita un servidor NTP en su red, debe utilizar algo más, como Chrony, para funcionar como servidor.

Prefiero tener una sola implementación para cualquier servicio en mi red, así que uso Chrony. Si no necesita un servidor NTP local o si no le importa usar Chrony como servidor y systemd-timesyncd como cliente SNTP. Después de todo, no hay necesidad de usar las capacidades adicionales de Chrony como cliente si está satisfecho con la funcionalidad de systemd-timesyncd.

Otra observación: no está obligado a usar herramientas de systemd para implementar NTP. Puede usar una versión antigua de ntpd, Chrony u otra implementación de NTP. De hecho, systemd está compuesto por muchos servicios; muchos de ellos son opcionales, por lo que se pueden desactivar y usar algo más en su lugar. No es un enorme monstruo monolítico. Puede no gustarle systemd o algunas de sus partes, pero debe tomar una decisión fundamentada.

Me gusta la implementación de NTP en systemd, pero prefiero Chrony, porque se adapta mejor a mis necesidades. Esto es Linux, cariño -)

Publicidad

VDSina ofrece servidores para cualquier tarea, una amplia selección de sistemas operativos para instalación automática, hay posibilidad de instalar cualquier SO desde su propia ISO, conveniente panel de control desarrollo propio y pago diario. Recordemos que tenemos servidores eternos que ciertamente no son afectados por el tiempo 😉

Fuente: habr.com