La mayoría de las personas llevan la cuenta del tiempo. Nos levantamos a tiempo para completar nuestros rituales matutinos e ir a trabajar, tomar un descanso para almorzar, cumplir con los plazos de los proyectos, celebrar cumpleaños y días festivos, abordar un avión, etc.
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 () a Fort Collins, Colorado a través de radio de onda larga . Las señales horarias están sincronizadas con el reloj atómico, también ubicado en Fort Collins. Mi Fitbit se está sincronizando con mi teléfono que se está sincronizando con el servidor , que finalmente se sincroniza con el reloj atómico.
Los dispositivos también controlan el tiempo
Hay muchas razones por las que nuestros dispositivos y computadoras necesitan una hora precisa. Por ejemplo, en la banca, los mercados bursátiles y otros negocios financieros, las transacciones deben realizarse en el orden correcto, y las secuencias de tiempo precisas son críticas para esto.
Nuestros teléfonos, tabletas, automóviles, sistemas de GPS y computadoras requieren configuraciones precisas de fecha y hora. Quiero que el reloj del escritorio de mi computadora muestre la hora correcta. Quiero que los recordatorios aparezcan en mi calendario local en el momento adecuado. La hora correcta también garantiza que los trabajos cron y systemd se ejecuten en el momento correcto.
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 según la fecha y la hora. Por ejemplo, una vez trabajé en DevOps (no se llamaba así en ese momento) y estaba configurando un sistema de correo electrónico en el estado de Carolina del Norte. Solíamos procesar más de 20 millones de correos electrónicos al día. El seguimiento del correo electrónico a través de una serie de servidores, o la determinación de la secuencia exacta de eventos utilizando archivos de registro en hosts dispersos geográficamente, puede ser mucho más fácil si las computadoras respectivas están sincronizadas en el tiempo.
Una vez - muchas horas
Los hosts Linux deben tener en cuenta que existe una hora del sistema y una hora RTC. RTC (Real Time Clock) es un nombre un poco extraño y no muy preciso para un reloj de hardware.
El reloj del hardware funciona continuamente incluso cuando la computadora está apagada, usando la batería en la placa base del sistema. La función principal del RTC es almacenar la hora cuando no se dispone de una conexión a un servidor horario. En los días en que era imposible conectarse a un servidor de tiempo a través de Internet, cada computadora tenía que tener un reloj interno preciso. Los sistemas operativos tenían que acceder al RTC en el momento del arranque y el usuario tenía que configurar manualmente la hora del sistema mediante la interfaz de configuración de hardware del BIOS para asegurarse de que fuera correcta.
Los relojes de hardware no entienden el concepto de zonas horarias; RTC solo almacena la hora, no la zona horaria o el desplazamiento de UTC (Tiempo universal coordinado, también conocido como GMT o Hora media de Greenwich). Puede instalar RTC usando una herramienta que trataré más adelante en este artículo.
La hora del sistema es la hora que el sistema operativo muestra en el reloj de la GUI de su escritorio, en la salida del comando de fecha, en las marcas de tiempo de los registros. Esto también se aplica cuando se crean, modifican y abren archivos.
Página hay una descripción completa del RTC y el reloj del sistema.
¿Qué pasa con NTP?
Las computadoras de todo el mundo utilizan NTP (Network Time Protocol) 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 la capa 1 y están conectados directamente a varios servicios de tiempo nacionales en la capa 0 a través de satélite, radio o incluso módems a través de líneas telefónicas. Los servicios de tiempo de capa 0 pueden ser un reloj atómico, un receptor de radio sintonizado con señales transmitidas por relojes atómicos o un receptor GPS que utiliza señales de reloj de alta precisión transmitidas por satélites GPS.
La gran mayoría de los servidores de referencia tienen varios miles de servidores públicos NTP stratum 2 abiertos al público. Muchas organizaciones y usuarios (incluido yo mismo) con muchos hosts que necesitan un servidor NTP eligen configurar sus propios servidores de tiempo para que solo un host local acceda al estrato 2 o 3. Luego configuran los nodos restantes en la red para usar el servidor local. servidor de tiempo. En el caso de mi red doméstica, este es un servidor de capa 3.
Varias implementaciones de NTP
La implementación original de NTP es ntpd. Luego se le unieron dos más nuevos, chronyd y systemd-timesyncd. Los tres sincronizan la hora del host local con un servidor de hora NTP. El servicio systemd-timesyncd no es tan confiable como chronyd, pero es lo suficientemente bueno para la mayoría de los propósitos. Si el RTC no está sincronizado, puede ajustar gradualmente la hora del sistema para sincronizar con el servidor NTP cuando la hora del sistema local cambia ligeramente. El servicio systemd-timesync no se puede utilizar como servidor horario.
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 características que son indispensables en muchos casos:
- Chrony puede sincronizar con un servidor horario mucho más rápido que el antiguo servicio ntpd. Esto es bueno para computadoras portátiles o de escritorio que no funcionan todo el tiempo.
- Puede compensar las fluctuaciones del reloj, como cuando el host se va a dormir o entra en modo de suspensión, o cuando el reloj cambia debido al salto de frecuencia, lo que ralentiza los relojes con poca carga.
- Resuelve problemas de tiempo relacionados con la conexión de red inestable o la congestión de la red.
- Regula los retrasos de la red.
- Después de la sincronización de tiempo inicial, 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 una conexión de red. En este caso, el host o servidor local se puede actualizar manualmente.
- Chrony puede actuar como un servidor NTP.
Una vez más, NTP es un protocolo que se puede implementar en un host Linux mediante Chrony o systemd-timesyncd.
Los RPM de NTP, Chrony y systemd-timesyncd están disponibles en los repositorios estándar de Fedora. El RPM systemd-udev es un administrador de eventos del kernel que se instala de forma predeterminada en Fedora, pero es opcional.
Puede instalar los tres y cambiar entre ellos, pero esto creará un dolor de cabeza adicional. Así que es mejor no hacerlo. Las versiones modernas de Fedora, CentOS y RHEL se han trasladado a Chrony como implementación predeterminada y también tienen systemd-timesyncd. Creo que Chrony funciona bien, brinda una mejor interfaz que el servicio NTP, brinda mucha más información y control, lo que sin duda disfrutarán los administradores de sistemas.
Deshabilitar servicios NTP
Es posible que el servicio NTP ya se esté ejecutando en su host. Si es así, debe desactivarlo antes de cambiar a otra cosa. Tenía chronyd ejecutándose, así que usé los siguientes comandos para detenerlo y deshabilitarlo. Ejecute los comandos apropiados para cualquier demonio NTP que esté ejecutando en su host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Compruebe que el servicio está detenido y deshabilitado:
[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - NTP client/server
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 ~]#Comprobación de estado antes del lanzamiento
El estado de sincronización del reloj del sistema le permite determinar si el servicio NTP se está ejecutando. Como aún no ha iniciado NTP, el comando timesync-status indicará esto:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Una solicitud de estado directa proporciona información importante. Por ejemplo, el comando timedatectl sin argumentos ni opciones ejecuta el subcomando de estado de forma predeterminada:
[root@testvm1 ~]# timedatectl status
Local time: Fri 2020-05-15 08:43:10 EDT
Universal time: Fri 2020-05-15 12:43:10 UTC
RTC time: Fri 2020-05-15 08:43:08
Time zone: America/New_York (EDT, -0400)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode cannot be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#Esto le dará la hora local de su host, la hora UTC y la hora RTC. En este caso, la hora del sistema se establece en la zona horaria de América/Nueva_York (TZ), el RTC se establece en la hora de la zona horaria local y el servicio NTP no está activo. La hora RTC ha comenzado a desviarse ligeramente de la hora del sistema. Esto es normal para sistemas cuyos relojes no han sido sincronizados. La cantidad de compensació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 RTC; esto se aplica a los cambios de zona horaria y la configuración de DST. Si la computadora se apaga cuando es necesario realizar cambios, el RTC no cambiará. Pero para los servidores u otros hosts que funcionan las XNUMX horas, esto no es un problema en absoluto. Además, cualquier servicio que proporcione sincronización de hora NTP ajustará la hora del host durante la fase de inicio inicial, por lo que una vez que se complete el inicio, la hora volverá a ser correcta.
Configuración de la zona horaria
Por lo general, especifica la zona horaria durante el procedimiento de instalación y no tiene la tarea de cambiarla más adelante. Sin embargo, hay momentos en los que necesita cambiar la zona horaria. Hay varias herramientas que pueden ayudar. Linux usa archivos de zona horaria para determinar la zona horaria local de un host. Estos archivos están en el directorio / usr / share / zoneinfo. De forma predeterminada, para mi zona horaria, el sistema prescribe esto: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Pero no necesitas conocer esas sutilezas para cambiar la zona horaria.
Lo principal es saber el nombre de la zona horaria oficial de tu ubicación y el comando correspondiente. Supongamos que desea cambiar la zona horaria a Los Ángeles:
[root@testvm2 ~]# timedatectl list-timezones | column
<SNIP>
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
<SNIP>Ahora puede configurar la zona horaria. Usé el comando de fecha para buscar cambios, pero también puedes usar timedatectl:
[root@testvm2 ~]# date
Tue 19 May 2020 04:47:49 PM EDT
[root@testvm2 ~]# timedatectl set-timezone America/Los_Angeles
[root@testvm2 ~]# date
Tue 19 May 2020 01:48:23 PM PDT
[root@testvm2 ~]#Ahora puede volver a cambiar la zona horaria de su host a la hora local.
systemd-timesyncd
El demonio timesync de systemd proporciona una implementación de NTP que es fácil de administrar en el contexto de systemd. Está instalado por defecto en Fedora y Ubuntu. Sin embargo, solo se inicia de forma predeterminada en Ubuntu. No estoy seguro acerca de otras distribuciones. Puedes comprobarlo por ti mismo:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfiguración de systemd-timesyncd
El archivo de configuración para systemd-timesyncd es /etc/systemd/timesyncd.conf. Este es un archivo simple con menos opciones habilitadas que los antiguos servicios NTP y chronyd. Aquí está el contenido de este archivo (sin más modificaciones) en mi Fedora VM:
# 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=2048La única sección que contiene, además de los comentarios, es [Tiempo]. Todas las demás líneas están comentadas. Estos son los valores predeterminados y no deben cambiarse (a menos que tenga una razón para hacerlo). Si no tiene un servidor de tiempo NTP definido en la línea NTP=, Fedora usa de forma predeterminada un servidor de tiempo de reserva de Fedora. Por lo general, agrego mi servidor de tiempo:
NTP=myntpserverSincronización de tiempo en ejecución
Puede iniciar y activar systemd-timesyncd de esta manera:
[root@testvm2 ~]# systemctl enable systemd-timesyncd.service
Created symlink /etc/systemd/system/dbus-org.freedesktop.timesync1.service → /usr/lib/systemd/system/systemd-timesyncd.service.
Created symlink /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 del reloj del hardware
Así es como se ve la situación después de ejecutar timesyncd:
[root@testvm2 systemd]# timedatectl
Local time: Sat 2020-05-16 14:34:54 EDT
Universal time: Sat 2020-05-16 18:34:54 UTC
RTC time: Sat 2020-05-16 14:34:53
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no Inicialmente, la diferencia entre la hora RTC y la hora local (EDT) es de menos de un segundo y la discrepancia aumenta otro par de segundos en los próximos días. Dado que no existe un concepto de zonas horarias en RTC, el comando timedatectl debe realizar una comparación para determinar la zona horaria correcta. Si la hora RTC no coincide exactamente con la hora local, tampoco coincide con la zona horaria local.
Buscando más información, revisé el estado de systemd-timesync y encontré esto:
[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2020-05-16 13:56:53 EDT; 18h ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 822 (systemd-timesyn)
Status: "Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org)."
Tasks: 2 (limit: 10365)
Memory: 2.8M
CPU: 476ms
CGroup: /system.slice/systemd-timesyncd.service
└─822 /usr/lib/systemd/systemd-timesyncd
May 16 09:57:24 testvm2.both.org systemd[1]: Starting Network Time Synchronization...
May 16 09:57:24 testvm2.both.org systemd-timesyncd[822]: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2020-05-16 13:56:53 EDT
May 16 13:56:53 testvm2.both.org systemd[1]: Started Network Time Synchronization.
May 16 13:57:56 testvm2.both.org systemd-timesyncd[822]: Initial synchronization to time server 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#Observe el mensaje de registro que dice que la hora del sistema no se ha configurado o se ha restablecido. El servicio Timesync establece la hora del sistema en función de la marca de tiempo. Las marcas de tiempo son mantenidas por el daemon timesync y se crean en cada sincronización exitosa.
El comando timedatectl no tiene forma de tomar el valor del reloj del hardware del reloj del sistema. Solo puede configurar la hora y la fecha a partir del valor ingresado en la línea de comando. Puede establecer el RTC en el mismo valor que la hora del sistema mediante el comando hwclock:
[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
Local time: Mon 2020-05-18 13:56:46 EDT
Universal time: Mon 2020-05-18 17:56:46 UTC
RTC time: Mon 2020-05-18 13:56:46
Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
NTP service: active
RTC in local TZ: yesLa opción --localtime le dice al reloj del hardware que muestre la hora local, no UTC.
¿Por qué necesita RTC en absoluto?
Cualquier implementación de NTP configurará el reloj del sistema a la hora de inicio. ¿Y por qué entonces RTC? Esto no es del todo cierto: esto solo sucederá si tiene una conexión de red al servidor de tiempo. Sin embargo, muchos sistemas no siempre tienen acceso a una conexión de red, por lo que es útil que Linux use un reloj de hardware para configurar la hora del sistema. Esto es mejor que configurar la hora manualmente, aunque puede desviarse de la hora real.
Conclusión
Este artículo ha revisado algunas herramientas para manipular la fecha, la hora y las zonas horarias. La herramienta systemd-timesyncd proporciona un cliente NTP que puede sincronizar la hora en el host local con un servidor NTP. Sin embargo, systemd-timesyncd no proporciona un servicio de servidor, por lo que si necesita un servidor NTP en su red, debe usar otra cosa, como Chrony, para que actúe como servidor.
Prefiero tener una implementación única para cualquier servicio en mi red, por lo 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 es necesario utilizar las funciones adicionales de Chrony como cliente si está satisfecho con la funcionalidad de systemd-timesyncd.
Otra nota: no es necesario que utilice las herramientas systemd para implementar NTP. Puede usar una versión anterior de ntpd, Chrony u otra implementación de NTP. Después de todo, systemd consta de una gran cantidad de servicios; muchos de ellos son opcionales, por lo que puede desactivarlos y usar otra cosa en su lugar. Este no es un enorme monstruo monolítico. Es posible que no le guste systemd o partes de él, pero debe tomar una decisión informada.
Me gusta la implementación de NTP de systemd, pero prefiero Chrony porque se adapta mejor a mis necesidades. Es Linux, bebé -)
Sobre los derechos de publicidad
Ofertas VDSina , una gran selección de sistemas operativos para la instalación automática, es posible instalar cualquier sistema operativo desde el suyo , cómodo desarrollo propio y pago diario. Recuerda que tenemos servidores eternos que definitivamente son atemporales 😉
Fuente: habr.com