🥇Sincronização de tempo no Linux: NTP, Chrony e systemd-timesyncd

A maioria das pessoas acompanha o tempo. Nós acordamos a tempo para realizar nossos rituais matinais e ir ao trabalho, fazer pausas para o almoço, cumprir prazos de projetos, celebrar aniversários e feriados, pegar um avião e assim por diante.

Além disso, alguns de nós são obcecados pelo tempo. Meu relógio é movido a energia solar e recebe a hora exata do Instituto Nacional de Padrões e Tecnologia (NIST) em Fort Collins, Colorado, através de uma estação de rádio de longa frequência. WWVB. Os sinais de tempo são sincronizados com relógios atômicos também localizados em Fort Collins. Meu Fitbit se sincroniza com meu telefone, que se sincroniza com o servidor NTP, que, por sua vez, se sincroniza com os relógios atômicos.

Os dispositivos também acompanham o tempo.

Há muitas razões pelas quais nossos dispositivos e computadores precisam de um tempo exato. Por exemplo, no setor bancário, nos mercados financeiros e em outras empresas, as transações devem ser realizadas em uma ordem adequada, e sequências temporais precisas são cruciais para isso.

Nossos telefones, tablets, carros, sistemas GPS e computadores exigem ajustes precisos de data e hora. Eu quero que o relógio na área de trabalho do meu computador mostre a hora certa. Eu quero que os lembretes no meu calendário local apareçam na hora correta. O tempo correto também garante que tarefas cron e systemd sejam executadas na hora certa.

Data e hora também são importantes para a manutenção de registros, facilitando um pouco mais a localização de determinados logs, orientando-se pela data e hora. Por exemplo, uma vez trabalhei em DevOps (na época não era assim que chamávamos) e estava configurando um sistema de e-mail na Carolina do Norte. Anteriormente, processávamos mais de 20 milhões de e-mails por dia. Rastrear e-mails através de uma série de servidores ou determinar a sequência exata de eventos usando arquivos de log em hosts geograficamente distribuídos pode ser muito mais fácil se os computadores relevantes estiverem sincronizados em relação ao tempo.

Um tempo — muitos relógios.

Hosts Linux devem considerar que existe o tempo do sistema e o tempo do RTC. RTC (Relógio de Tempo Real) é um nome um pouco estranho e não muito preciso para os relógios de hardware.

Os relógios de hardware funcionam continuamente, mesmo quando o computador está desligado, utilizando uma bateria na placa-mãe do sistema. A principal função do RTC é manter a hora quando a conexão com o servidor de tempo não está disponível. Em tempos em que não era possível conectar ao servidor de tempo pela internet, cada computador precisava ter relógios internos precisos. Os sistemas operacionais precisavam acessar o RTC durante a inicialização, e o usuário deveria definir manualmente a hora do sistema, usando a interface de configuração de hardware da BIOS, para garantir que estivesse correta.

Os relógios de hardware não compreendem o conceito de fusos horários; no RTC, apenas a hora é armazenada, e não o fuso horário ou o deslocamento em relação ao UTC (Tempo Universal Coordenado, que também é conhecido como GMT ou Horário Médio de Greenwich). Você pode configurar o RTC usando uma ferramenta que descreverei mais adiante neste artigo.

A hora do sistema é o tempo que o sistema operacional exibe no relógio da interface gráfica de usuário (GUI) na sua área de trabalho, na saída do comando date, nas marcas de tempo dos registros. Isso também se refere ao tempo de criação, alteração e abertura de arquivos.

Na página man para rtc Há uma descrição completa do RTC e dos relógios de sistema.

E o que há sobre o NTP?

Computadores em todo o mundo utilizam o NTP (Protocolo de Tempo de Rede) para sincronizar seu tempo com relógios de referência padrão pela internet, através de uma hierarquia de servidores NTP. Os servidores de tempo principais estão no nível 1 e estão diretamente conectados a vários serviços nacionais de tempo no nível 0 via satélite, rádio ou até mesmo modems por linhas telefônicas. Os serviços de tempo no nível 0 podem ser relógios atômicos, receptores de rádio ajustados para sinais transmitidos por relógios atômicos ou receptores GPS que utilizam sinais de relógios transmitidos por satélites GPS.

Na grande maioria dos servidores de referência, há milhares de servidores NTP stratum 2 públicos disponíveis para todos. Muitas organizações e usuários (incluindo eu) com um grande número de hosts que precisam de um servidor NTP preferem instalar seus próprios servidores de tempo, para que apenas um host local se conecte ao stratum 2 ou 3. Em seguida, eles configuram os nós restantes na rede para usar o servidor de tempo local. No caso da minha rede doméstica, isso é um servidor de nível 3.

Várias implementações do NTP

A implementação original do NTP é o ntpd. Depois, vieram duas mais recentes, chronyd e systemd-timesyncd. Todos os três sincronizam o tempo do host local com um servidor NTP. O serviço systemd-timesyncd não é tão confiável quanto o chronyd, mas é adequado para a maioria das finalidades. Se o RTC não estiver sincronizado, ele pode gradualmente ajustar o tempo do sistema para se alinhar com o servidor NTP, quando o tempo do sistema local se desvia um pouco. O serviço systemd-timesync não pode ser utilizado como um servidor de tempo.

Chrony — é uma implementação do NTP que contém dois programas: o daemon chronyd e uma interface de linha de comando chamada chronyc. O Chrony tem algumas funcionalidades que, em muitos casos, são simplesmente indispensáveis:

O Chrony pode sincronizar com um servidor de tempo muito mais rapidamente do que o antigo serviço ntpd. Isso é bom para laptops ou desktops que não ficam ligados o tempo todo.
Ele pode compensar variações na frequência do clock, como quando o host entra em modo de suspensão ou hibernação, ou quando a frequência do clock muda devido a flutuações abruptas que desaceleram os clock em baixa carga.
Ele resolve problemas de tempo relacionados a conexões de rede instáveis ou sobrecarga de rede.
Ele ajusta as latências da rede.
Após a sincronização inicial do tempo, o Chrony nunca para os relógios. Isso assegura intervalos de tempo estáveis e consistentes para muitos serviços e aplicações do sistema.
O Chrony pode funcionar mesmo sem conexão à rede. Nesse caso, o host ou servidor local pode ser atualizado manualmente.
O Chrony pode atuar como servidor NTP.

Mais uma vez: NTP é um protocolo que pode ser implementado em um host Linux usando Chrony ou systemd-timesyncd.

Os pacotes RPM NTP, Chrony e systemd-timesyncd estão disponíveis nos repositórios padrão do Fedora. O RPM systemd-udev é o gerenciador de eventos do kernel, que é instalado por padrão no Fedora, mas não é obrigatório.

Você pode instalar todos os três e alternar entre eles, mas isso pode causar dores de cabeça desnecessárias. Portanto, é melhor evitar. As versões modernas do Fedora, CentOS e RHEL adotaram o Chrony como a implementação padrão, além de contar com o systemd-timesyncd. Acredito que o Chrony funciona bem, oferece uma interface melhor do que o serviço NTP, fornece muito mais informações e aumenta o controle, o que certamente agradará os administradores de sistema.

Desativando os serviços NTP

É possível que um serviço NTP já esteja em execução no seu host. Se este for o caso, você precisará desativá-lo antes de mudar para outra coisa. Eu estava executando o chronyd, então usei os seguintes comandos para pará-lo e desativá-lo. Execute os comandos apropriados para qualquer daemon NTP que você estiver utilizando em seu host:

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

Verifique se o serviço está parado e desativado:

[root@testvm1 ~]# systemctl status chronyd
● chronyd.service - cliente/servidor NTP
     Carregado: carregado (/usr/lib/systemd/system/chronyd.service; desativado; preset do fornecedor: habilitado)
     Ativo: inativo (morto)
       Docs: man:chronyd(8)
             man:chrony.conf(5)
[root@testvm1 ~]#

Verificando o status antes de iniciar

O status da sincronização de tempo do sistema permite determinar se o serviço NTP está em execução. Como você ainda não inicializou o NTP, o comando timesync-status dará uma dica sobre isso:

[root@testvm1 ~]# timedatectl timesync-status
Falha ao consultar o servidor: Não foi possível ativar o par remoto.

Uma consulta direta ao status fornece informações importantes. Por exemplo, o comando timedatectl sem argumentos ou parâmetros executa a subcomando status por padrão:

[root@testvm1 ~]# timedatectl status
           Hora local: Sex 2020-05-15 08:43:10 EDT  
           Hora universal: Sex 2020-05-15 12:43:10 UTC  
                 Hora RTC: Sex 2020-05-15 08:43:08      
                Fuso horário: America/New_York (EDT, -0400)
Sincronização do relógio do sistema: não                          
              Serviço NTP: inativo                    
          RTC no TZ local: sim                    

Aviso: O sistema está configurado para ler a hora RTC no fuso horário local.
         Este modo não pode ser totalmente suportado. Isso criará vários problemas
         com mudanças de fuso horário e ajustes de horário de verão. O RTC
         nunca é atualizado, ele depende de facilidades externas para mantê-lo.
         Se possível, use RTC em UTC chamando
         'timedatectl set-local-rtc 0'.
[root@testvm1 ~]#

Assim, você obterá a hora local do seu host, a hora UTC e a hora RTC. Neste caso, a hora do sistema está configurada para o fuso horário America/New_York (TZ), o RTC está ajustado para o horário no fuso local, e o serviço NTP está inativo. A hora RTC começou a se desviar um pouco da hora do sistema. Isso é normal para sistemas cujos relógios não foram sincronizados. A magnitude do desvio no host depende do tempo decorrido desde a última sincronização do sistema.

Também recebemos um aviso sobre o uso da hora local para o RTC — isso se refere a mudanças de fuso horário e configurações de horário de verão. Se o computador estiver desligado no momento em que as mudanças precisarem ser feitas, a hora RTC não mudará. Mas para servidores ou outros hosts que funcionam 24 horas por dia, isso não é um problema. Além disso, qualquer serviço que forneça sincronização de tempo NTP ajustará a hora do host ainda no início da inicialização, então após a conclusão da inicialização, a hora se tornará correta novamente.

Configuração do fuso horário

Normalmente, você especifica o fuso horário durante o procedimento de instalação, e não há necessidade de mudá-lo depois. No entanto, há casos em que é necessário alterar o fuso horário. Existem várias ferramentas que podem ajudar. Para determinar o fuso horário local, o Linux usa arquivos de fusos horários. Esses arquivos estão localizados no diretório /usr/share/zoneinfo. Por padrão, para o meu fuso horário, o sistema registra isto: /etc/ localtime -> ../usr/share/zoneinfo/America/New_York. Mas você não precisa saber esses detalhes para mudar o fuso horário.

O principal é saber o nome oficial do fuso horário para sua localização e o comando correspondente. Por exemplo, você quer mudar o fuso horário para Los Angeles:


[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

Agora você pode definir o fuso horário. Eu usei o comando date para verificar as alterações, mas você também pode usar o timedatectl:

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

Agora você pode mudar o fuso horário do seu host para o horário local.

systemd-timesyncd

O daemon systemd timesync fornece uma implementação do NTP que é fácil de gerenciar no contexto do systemd. Ele é instalado por padrão no Fedora e no Ubuntu. No entanto, ele só inicia por padrão no Ubuntu. Não tenho certeza sobre outras distribuições. Você pode verificar por conta própria:

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

Configurando o systemd-timesyncd

O arquivo de configuração para o systemd-timesyncd é /etc/systemd/timesyncd.conf. É um arquivo simples com menos opções habilitadas do que os antigos serviços NTP e chronyd. Aqui está o conteúdo desse arquivo (sem alterações adicionais) na minha 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=2048

A única seção que ele contém, além dos comentários, é [Time]. Todas as outras linhas estão comentadas. Esses são os valores padrão, que não precisam ser mudados (a menos que você tenha motivos para isso). Se você não tiver um servidor NTP especificado na linha NTP=, por padrão o Fedora usa um servidor NTP reserva. Geralmente adiciono meu servidor NTP:

NTP=myntpserver

Executando o timesync

Você pode iniciar e ativar o systemd-timesyncd assim:

[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 ~]#

Configurando o relógio de hardware

Aqui está a situação após iniciar o 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      
                Fuso horário: America/New_York (EDT, -0400)
Relógio do sistema sincronizado: sim                          
              Serviço NTP: ativo                      
          RTC no TZ local: não

Inicialmente, a diferença entre o RTC e o horário local (EDT) não ultrapassa um segundo, e a discrepância aumenta em mais alguns segundos ao longo dos próximos dias. Como não há no RTC o conceito de fusos horários, o comando timedatectl deve fazer uma comparação para determinar o fuso horário desejado. Se o tempo do RTC não corresponder exatamente ao horário local, significa que também não corresponde ao fuso horário local.

Em busca de informações adicionais, verifiquei o status do systemd-timesync e descobri o seguinte:

[root@testvm2 systemd]# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Sincronização de Horário de Rede
     Loaded: carregado (/usr/lib/systemd/system/systemd-timesyncd.service; habilitado; preset do fornecedor: desabilitado)
     Active: ativo (em execução) desde Sáb 2020-05-16 13:56:53 EDT; 18h atrás
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 822 (systemd-timesyn)
     Status: "Sincronização inicial com o servidor de tempo 163.237.218.19:123 (2.fedora.pool.ntp.org)."
      Tasks: 2 (limite: 10365)
     Memory: 2.8M
        CPU: 476ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─822 /usr/lib/systemd/systemd-timesyncd

16 de maio 09:57:24 testvm2.both.org systemd[1]: Iniciando Sincronização de Horário de Rede...
16 de maio 09:57:24 testvm2.both.org systemd-timesyncd[822]: O horário do relógio do sistema não está definido ou foi revertido, restaurando do timestamp gravado: Sáb 2020-05-16 13:56:53 EDT
16 de maio 13:56:53 testvm2.both.org systemd[1]: Sincronização de Horário de Rede iniciada.
16 de maio 13:57:56 testvm2.both.org systemd-timesyncd[822]: Sincronização inicial com o servidor de tempo 163.237.218.19:123 (2.fedora.pool.ntp.org).
[root@testvm2 systemd]#

Observe a mensagem do log indicando que o horário do sistema não está definido ou foi retrocedido. O serviço Timesync define o horário do sistema com base na marcação de tempo. As marcações de tempo são mantidas pelo daemon timesync e são criadas a cada sincronização bem-sucedida.

O comando timedatectl não tem a capacidade de pegar o valor do relógio de hardware dos relógios do sistema. Ele pode definir a hora e a data apenas com base no valor inserido na linha de comando. Você pode definir o RTC para o mesmo valor que o horário do sistema usando o comando hwclock:

[root@testvm2 ~]# /sbin/hwclock --systohc --localtime
[root@testvm2 ~]# timedatectl
               Hora local: Seg 2020-05-18 13:56:46 EDT  
           Hora universal: Seg 2020-05-18 17:56:46 UTC  
                 Hora RTC: Seg 2020-05-18 13:56:46      
                Fuso horário: América/Nova_York (EDT, -0400)
Relógio do sistema sincronizado: sim                          
              Serviço NTP: ativo                      
          RTC no TZ local: sim

A opção --localtime indica que o relógio de hardware está mostrando a hora local e não UTC.

Por que você precisa do RTC?

Qualquer implementação do NTP definirá os relógios do sistema na inicialização. E então, qual é a necessidade do RTC? Não é bem assim: isso ocorrerá apenas se você tiver uma conexão de rede com um servidor de horário. No entanto, muitos sistemas não têm acesso permanente a uma conexão de rede, portanto, os relógios de hardware são úteis para que o Linux possa definir a hora do sistema com base neles. Isso é melhor do que definir a hora manualmente, mesmo que possa estar desviado do horário real.

Conclusão

Neste artigo, examinamos algumas ferramentas para gerenciar a data, hora e fusos horários. A ferramenta systemd-timesyncd fornece um cliente NTP que pode sincronizar o tempo no host local com um servidor NTP. No entanto, o systemd-timesyncd não fornece um serviço de servidor, então, se você precisar de um servidor NTP em sua rede, deve usar outra coisa - como o Chrony, para funcionar como servidor.

Prefiro ter uma única implementação para qualquer serviço em minha rede, então uso o Chrony. Se você não precisa de um servidor NTP local ou se está disposto a usar o Chrony como servidor e o systemd-timesyncd como cliente SNTP. Afinal, não há necessidade de usar os recursos adicionais do Chrony como cliente, se você está satisfeito com a funcionalidade do systemd-timesyncd.

Mais um ponto: você não é obrigado a usar ferramentas do systemd para implementar o NTP. Você pode usar a versão antiga do ntpd, Chrony ou outra implementação do NTP. Afinal, o systemd consiste em muitos serviços; muitos deles são opcionais, portanto podem ser desativados e substituídos por outra coisa. Não é um monstro monolítico enorme. Você pode não gostar do systemd ou de suas partes, mas deve tomar uma decisão fundamentada.

Gosto da implementação do NTP no systemd, mas prefiro o Chrony, pois ele atende melhor às minhas necessidades. Isso é Linux, baby -)

Em nome da publicidade

A VDSina oferece servidores para qualquer tarefa, uma enorme variedade de sistemas operacionais para instalação automática, há a possibilidade de instalar qualquer SO a partir do próprio ISO, conveniente painel de controle desenvolvimento e pagamento diário. Lembre-se, temos servidores eternos que realmente estão além do tempo 😉

Fonte: habr.com