A maioría da xente segue o tempo. Levantámonos a tempo para completar os nosos rituais da mañá e imos traballar, facer unha pausa para xantar, cumprir os prazos dos proxectos, celebrar aniversarios e vacacións, abordar un avión, etc.
Ademais: algúns de nós estamos obsesionados co tempo. O meu reloxo funciona con enerxía solar e obtén a hora precisa do Instituto Nacional de Estándares e Tecnoloxía () a Fort Collins, Colorado a través de radio de onda longa . Os sinais de tempo están sincronizados co reloxo atómico, tamén situado en Fort Collins. O meu Fitbit estase sincronizando co meu teléfono que se sincroniza co servidor , que finalmente se sincroniza co reloxo atómico.
Os dispositivos tamén fan un seguimento do tempo
Hai moitas razóns polas que os nosos dispositivos e ordenadores necesitan a hora precisa. Por exemplo, na banca, os mercados de accións e outros negocios financeiros, as transaccións deben realizarse na orde adecuada, e para iso son fundamentais as secuencias de tempo precisas.
Os nosos teléfonos, tabletas, coches, sistemas GPS e ordenadores requiren unha configuración precisa de data e hora. Quero que o reloxo do escritorio do meu ordenador indique a hora correcta. Quero que os recordatorios aparezan no meu calendario local no momento adecuado. A hora correcta tamén garante que os traballos cron e systemd se executen no momento correcto.
A data e a hora tamén son importantes para o rexistro, polo que é un pouco máis doado atopar determinados rexistros en función da data e da hora. Por exemplo, unha vez traballei en DevOps (non se chamaba así naquel momento) e estaba a configurar un sistema de correo electrónico no estado de Carolina do Norte. Adoitabamos procesar máis de 20 millóns de correos electrónicos ao día. O seguimento do correo electrónico a través dunha serie de servidores ou a determinación da secuencia exacta de eventos mediante ficheiros de rexistro en hosts dispersos xeograficamente pode ser moito máis sinxelo se os ordenadores respectivos están sincronizados no tempo.
Unha vez - moitas horas
Os hosts Linux deben ter en conta que hai unha hora do sistema e unha hora RTC. RTC (Real Time Clock) é un nome un pouco estraño e pouco preciso para un reloxo de hardware.
O reloxo de hardware funciona continuamente mesmo cando o ordenador está apagado, utilizando a batería da placa base do sistema. A función principal do RTC é almacenar o tempo cando unha conexión a un servidor de tempo non está dispoñible. Na época en que era imposible conectarse a un servidor de tempo a través de Internet, cada ordenador tiña que ter un reloxo interno preciso. Os sistemas operativos tiñan que acceder ao RTC no momento do inicio e o usuario tiña que configurar manualmente a hora do sistema mediante a interface de configuración de hardware da BIOS para asegurarse de que era correcta.
Os reloxos de hardware non entenden o concepto de fusos horarios; RTC só almacena a hora, non a zona horaria nin a compensación do UTC (Tempo Universal Coordinado, tamén coñecido como GMT ou Hora Media de Greenwich). Podes instalar RTC usando unha ferramenta que tratarei máis adiante neste artigo.
A hora do sistema é a hora que o SO mostra no reloxo da GUI do teu escritorio, na saída do comando de data, nas marcas de tempo dos rexistros. Isto tamén se aplica cando se crean, modifican e abren ficheiros.
Na páxina hai unha descrición completa do RTC e do reloxo do sistema.
Que pasa con NTP?
Ordenadores de todo o mundo usan NTP (Network Time Protocol) para sincronizar a súa hora con reloxos de referencia estándar a través de Internet mediante unha xerarquía de servidores NTP. Os principais servidores horarios están na capa 1 e están conectados directamente a varios servizos horarios nacionais na capa 0 vía satélite, radio ou incluso módems a través de liñas telefónicas. Os servizos de tempo de capa 0 poden ser un reloxo atómico, un receptor de radio que está sintonizado con sinais transmitidos por reloxos atómicos ou un receptor GPS que utiliza sinais de reloxo de alta precisión transmitidos por satélites GPS.
A gran maioría dos servidores de referencia teñen varios miles de servidores públicos NTP estrato 2 abertos ao público. Moitas organizacións e usuarios (incluído eu) con moitos anfitrións que necesitan un servidor NTP optan por configurar os seus propios servidores de tempo, polo que só un host local accede ao estrato 2 ou 3. Despois configuran os nodos restantes da rede para usar o local. servidor de tempo. No caso da miña rede doméstica, este é un servidor de capa 3.
Varias implementacións de NTP
A implementación orixinal de NTP é ntpd. Despois uníronlle dous máis novos, chronyd e systemd-timesyncd. Os tres sincronizan a hora do servidor local cun servidor de tempo NTP. O servizo systemd-timesyncd non é tan fiable como chronyd, pero é o suficientemente bo para a maioría dos propósitos. Se o RTC non está sincronizado, pode axustar gradualmente a hora do sistema para sincronizarse co servidor NTP cando a hora do sistema local vaia lixeiramente. O servizo systemd-timesync non se pode usar como servidor de tempo.
é unha implementación de NTP que contén dous programas: o daemon chronyd e unha interface de liña de comandos chamada chronyc. Chrony ten algunhas características que son indispensables en moitos casos:
- Chrony pode sincronizarse cun servidor de tempo moito máis rápido que o antigo servizo ntpd. Isto é bo para portátiles ou escritorios que non funcionan todo o tempo.
- Pode compensar as flutuacións do reloxo, como cando o anfitrión pasa a durmir ou entra no modo de suspensión, ou cando o reloxo cambia debido ao salto de frecuencia, que ralentiza os reloxos a baixas cargas.
- Resolve problemas de tempo relacionados coa conexión de rede inestable ou a conxestión da rede.
- Regula os atrasos da rede.
- Despois da sincronización horaria inicial, Chrony nunca para o reloxo. Isto proporciona intervalos de tempo estables e consistentes para moitos servizos e aplicacións do sistema.
- Chrony pode funcionar mesmo sen conexión de rede. Neste caso, o servidor ou host local pódese actualizar manualmente.
- Chrony pode actuar como servidor NTP.
Unha vez máis, NTP é un protocolo que se pode implementar nun host Linux usando Chrony ou systemd-timesyncd.
Os RPM NTP, Chrony e systemd-timesyncd están dispoñibles nos repositorios estándar de Fedora. O systemd-udev RPM é un xestor de eventos do núcleo que está instalado por defecto en Fedora, pero é opcional.
Podes instalar os tres e cambiar entre eles, pero isto creará unha dor de cabeza extra. Entón, é mellor non facelo. As versións modernas de Fedora, CentOS e RHEL pasaron a Chrony como implementación predeterminada e tamén teñen systemd-timesyncd. Paréceme que Chrony funciona ben, proporciona unha interface mellor que o servizo NTP, proporciona moita máis información e control, que os administradores do sistema seguramente gozarán.
Desactivando os servizos NTP
É posible que o servizo NTP xa se estea executando no teu servidor. Se é así, debes desactivalo antes de cambiar a outra cousa. Tiven chronyd en execución, polo que usei os seguintes comandos para paralo e desactivalo. Execute os comandos axeitados para calquera daemon NTP que estea executando no seu servidor:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Comprobe que o servizo estea detido e desactivado:
[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 do lanzamento
O estado de sincronización do reloxo do sistema permítelle determinar se o servizo NTP se está a executar. Como aínda non iniciaches NTP, o comando timesync-status indicará isto:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Unha solicitude de estado directa proporciona información importante. Por exemplo, o comando timedatectl sen argumentos nin opcións executa o subcomando status por defecto:
[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 ~]#Isto darache a hora local do teu anfitrión, a hora UTC e a hora RTC. Neste caso, a hora do sistema establécese na zona horaria de América/New_York (TZ), o RTC establécese na hora da zona horaria local e o servizo NTP non está activo. A hora RTC comezou a desviarse lixeiramente da hora do sistema. Isto é normal para sistemas cuxos reloxos non foron sincronizados. A cantidade de compensación no host depende do tempo que pasou desde a última sincronización do sistema.
Tamén recibimos unha advertencia sobre o uso da hora local para RTC; isto aplícase aos cambios de zona horaria e á configuración do horario de verano. Se o ordenador está apagado cando hai que facer cambios, o RTC non cambiará. Pero para servidores ou outros hosts que funcionan durante todo o día, isto non é un problema en absoluto. Ademais, calquera servizo que proporcione sincronización horaria NTP axustará a hora do host durante a fase de inicio inicial, polo que a hora volverá ser correcta despois de que se complete o inicio.
Axuste da zona horaria
Normalmente, especifica o fuso horario durante o procedemento de instalación e non ten a tarefa de cambialo máis tarde. Non obstante, hai momentos nos que cómpre cambiar o fuso horario. Hai varias ferramentas que poden axudar. Linux usa ficheiros de zona horaria para determinar a zona horaria local dun servidor. Estes ficheiros están no directorio /usr/share/zoneinfo. Por defecto, para a miña zona horaria, o sistema prescribe isto: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Pero non é preciso coñecer tales sutilezas para cambiar a zona horaria.
O principal é coñecer o nome da zona horaria oficial da súa localización e o comando correspondente. Digamos que queres cambiar a 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>Agora podes configurar o fuso horario. Usei o comando date para comprobar se hai cambios, pero tamén podes 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 ~]#Agora podes cambiar a zona horaria do teu anfitrión á hora local.
systemd-timesyncd
O daemon systemd timesync proporciona unha implementación NTP que é fácil de xestionar no contexto systemd. Está instalado por defecto en Fedora e Ubuntu. Non obstante, só comeza por defecto en Ubuntu. Non estou seguro doutras distribucións. Podes comprobar por ti mesmo:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfigurando systemd-timesyncd
O ficheiro de configuración para systemd-timesyncd é /etc/systemd/timesyncd.conf. Este é un ficheiro sinxelo con menos opcións activadas que os antigos servizos NTP e chronyd. Aquí está o contido deste ficheiro (sen máis modificacións) na miña máquina virtual 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=2048A única sección que contén, ademais de comentarios, é [Tempo]. Todas as outras liñas están comentadas. Estes son os valores predeterminados e non se deben cambiar (a non ser que teñas un motivo para facelo). Se non tes un servidor de tempo NTP definido na liña NTP=, Fedora por defecto utiliza un servidor de tempo Fedora alternativo. Normalmente engado o meu servidor de tempo:
NTP=myntpserverExecución de sincronización temporal
Podes iniciar e activar systemd-timesyncd deste xeito:
[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 do reloxo do hardware
Aquí está o aspecto da situación despois de executar 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, a diferenza entre RTC e hora local (EDT) é inferior a un segundo, e a discrepancia aumenta un par de segundos máis durante os próximos días. Dado que non hai ningún concepto de fusos horarios en RTC, o comando timedatectl debe realizar unha comparación para determinar a zona horaria correcta. Se a hora RTC non coincide exactamente coa hora local, tampouco coincide coa zona horaria local.
Buscando máis información, comprobei o estado de systemd-timesync e atopei isto:
[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 a mensaxe de rexistro que di que a hora do sistema non se axustou ou que se restableceu. O servizo Timesync establece a hora do sistema en función da marca de tempo. As marcas de tempo son mantidas polo daemon timesync e créanse en cada sincronización exitosa.
O comando timedatectl non ten forma de tomar o valor do reloxo de hardware do reloxo do sistema. Só pode establecer a hora e a data a partir do valor introducido na liña de comandos. Podes establecer o RTC co mesmo valor que a hora do sistema usando o 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: yesA opción --localtime indica ao reloxo do hardware que mostre a hora local, non UTC.
Por que necesitas RTC?
Calquera implementación de NTP establecerá o reloxo do sistema no momento do inicio. E por que entón RTC? Isto non é totalmente certo: isto só ocorrerá se tes unha conexión de rede co servidor de tempo. Non obstante, moitos sistemas non sempre teñen acceso a unha conexión de rede, polo que un reloxo de hardware é útil para Linux para configurar a hora do sistema. Isto é mellor que configurar a hora manualmente, aínda que pode desviarse do tempo real.
Conclusión
Este artigo revisouse algunhas ferramentas para manipular data, hora e fusos horarios. A ferramenta systemd-timesyncd proporciona un cliente NTP que pode sincronizar a hora do servidor local cun servidor NTP. Non obstante, systemd-timesyncd non ofrece un servizo de servidor, polo que se precisa un servidor NTP na súa rede, debe utilizar outra cousa, como Chrony, para actuar como servidor.
Prefiro ter unha única implementación para calquera servizo da miña rede, polo que uso Chrony. Se non precisa un servidor NTP local ou se non lle importa usar Chrony como servidor e systemd-timesyncd como cliente SNTP. Despois de todo, non é necesario utilizar as funcións adicionais de Chrony como cliente se estás satisfeito coa funcionalidade de systemd-timesyncd.
Outra nota: non está obrigado a utilizar as ferramentas systemd para implementar NTP. Podes usar unha versión antiga de ntpd, Chrony ou outra implementación de NTP. Despois de todo, systemd consta dunha gran cantidade de servizos; moitos deles son opcionais, polo que podes desactivalos e usar outra cousa no seu lugar. Este non é un monstro monolítico enorme. Quizais non che guste systemd ou partes del, pero deberías tomar unha decisión informada.
Gústame a implementación de NTP de systemd, pero prefiro Chrony porque se adapta mellor ás miñas necesidades. É Linux, nena -)
Sobre os dereitos da publicidade
VDSina ofrece , unha gran selección de sistemas operativos para a instalación automática, é posible instalar calquera SO dende o teu , cómodo desenvolvemento propio e pago diario. Lembra que temos servidores eternos que son definitivamente eternos 😉
Fonte: www.habr.com