A maioria das pessoas acompanha o tempo. Acordamos na hora de concluir nossos rituais matinais e ir trabalhar, fazer uma pausa para o almoço, cumprir prazos de projetos, comemorar aniversários e feriados, embarcar em um avião e assim por diante.
Além disso: alguns de nós são obcecados pelo tempo. Meu relógio é alimentado por energia solar e obtém a hora exata do Instituto Nacional de Padrões e Tecnologia () para Fort Collins, Colorado via rádio de ondas longas . Os sinais de tempo são sincronizados com o relógio atômico, também localizado em Fort Collins. Meu Fitbit está sincronizando com meu telefone, que está sincronizando com o servidor , que eventualmente sincroniza com o relógio atômico.
Os dispositivos também controlam o tempo
Existem muitas razões pelas quais nossos dispositivos e computadores precisam de tempo preciso. Por exemplo, em bancos, mercados de ações e outros negócios financeiros, as transações devem ser executadas na ordem correta, e sequências de tempo precisas são essenciais para isso.
Nossos telefones, tablets, carros, sistemas de GPS e computadores exigem configurações precisas de hora e data. Eu quero que o relógio na área de trabalho do meu computador mostre a hora correta. Quero que os lembretes apareçam no meu calendário local na hora certa. A hora correta também garante que as tarefas cron e systemd sejam executadas na hora correta.
A data e a hora também são importantes para o registro, por isso é um pouco mais fácil encontrar determinados registros com base na data e hora. Por exemplo, uma vez trabalhei em DevOps (não era chamado assim na época) e estava montando um sistema de e-mail no estado da Carolina do Norte. Costumávamos processar mais de 20 milhões de e-mails por dia. Rastrear e-mail através de uma série de servidores ou determinar a seqüência exata de eventos usando arquivos de log em hosts geograficamente dispersos pode ser muito mais fácil se os respectivos computadores estiverem sincronizados no tempo.
Uma vez - muitas horas
Os hosts Linux devem levar em conta que existe um horário do sistema e um horário RTC. RTC (Real Time Clock) é um nome um pouco estranho e não muito preciso para um relógio de hardware.
O relógio do hardware funciona continuamente mesmo quando o computador está desligado, usando a bateria da placa-mãe do sistema. A principal função do RTC é armazenar o horário quando uma conexão com um servidor de horário não estiver disponível. Nos dias em que era impossível conectar-se a um servidor de horário pela Internet, todo computador precisava ter um relógio interno preciso. Os sistemas operacionais precisavam acessar o RTC no momento da inicialização e o usuário precisava definir manualmente o horário do sistema usando a interface de configuração de hardware do BIOS para garantir que estava correto.
Relógios de hardware não entendem o conceito de fuso horário; O RTC armazena apenas a hora, não o fuso horário ou o deslocamento do UTC (Tempo Universal Coordenado, também conhecido como GMT ou Horário de Greenwich). Você pode instalar o RTC usando uma ferramenta que abordarei posteriormente neste artigo.
A hora do sistema é a hora que o sistema operacional exibe no relógio da GUI em sua área de trabalho, na saída do comando date, nos registros de data e hora dos logs. Isso também se aplica quando os arquivos são criados, modificados e abertos.
Na página há uma descrição completa do RTC e do relógio do sistema.
O que há com o NTP?
Computadores em todo o mundo usam NTP (Network Time Protocol) para sincronizar seu horário com relógios de referência padrão na Internet usando uma hierarquia de servidores NTP. Os principais servidores de horário estão na camada 1 e estão diretamente conectados a vários serviços de horário nacionais na camada 0 via satélite, rádio ou até mesmo modems por linhas telefônicas. Os serviços de tempo da camada 0 podem ser um relógio atômico, um receptor de rádio sintonizado em sinais transmitidos por relógios atômicos ou um receptor GPS que usa sinais de relógio altamente precisos transmitidos por satélites GPS.
A grande maioria dos servidores de referência tem vários milhares de servidores públicos NTP stratum 2 abertos ao público. Muitas organizações e usuários (eu inclusive) com muitos hosts que precisam de um servidor NTP optam por configurar seus próprios servidores de horário para que apenas um host local acesse o estrato 2 ou 3. Eles então configuram os nós restantes na rede para usar o local servidor de tempo. No caso da minha rede doméstica, este é um servidor de camada 3.
Várias implementações de NTP
A implementação original do NTP é ntpd. Ele foi então acompanhado por dois novos, chronyd e systemd-timesyncd. Todos os três sincronizam o horário do host local com um servidor de horário NTP. O serviço systemd-timesyncd não é tão confiável quanto o chronyd, mas é bom o suficiente para a maioria dos propósitos. Se o RTC estiver fora de sincronia, ele poderá ajustar gradualmente a hora do sistema para sincronizar com o servidor NTP quando a hora do sistema local mudar ligeiramente. O serviço systemd-timesync não pode ser usado como um servidor de horário.
é uma implementação do NTP que contém dois programas: o daemon chronyd e uma interface de linha de comando chamada chronyc. O Chrony possui algumas funcionalidades indispensáveis em muitos casos:
- O Chrony pode sincronizar com um servidor de horário muito mais rápido que o antigo serviço ntpd. Isso é bom para laptops ou desktops que não funcionam o tempo todo.
- Ele pode compensar as flutuações do relógio, como quando o host vai dormir ou entra no modo de espera, ou quando o relógio muda devido ao salto de frequência, que diminui os relógios em cargas baixas.
- Ele resolve problemas de tempo relacionados à conexão de rede instável ou congestionamento de rede.
- Regula os atrasos da rede.
- Após a sincronização de tempo inicial, o Chrony nunca para o relógio. Isso fornece intervalos de tempo estáveis e consistentes para muitos serviços e aplicativos do sistema.
- O Chrony pode funcionar mesmo sem uma conexão de rede. Nesse caso, o host ou servidor local pode ser atualizado manualmente.
- O Chrony pode atuar como um servidor NTP.
Mais uma vez, NTP é um protocolo que pode ser implementado em um host Linux usando Chrony ou systemd-timesyncd.
Os RPMs NTP, Chrony e systemd-timesyncd estão disponíveis nos repositórios padrão do Fedora. O systemd-udev RPM é um gerenciador de eventos do kernel que é instalado por padrão no Fedora, mas é opcional.
Você pode instalar todos os três e alternar entre eles, mas isso criará uma dor de cabeça extra. Então é melhor não. As versões modernas do Fedora, CentOS e RHEL foram movidas para Chrony como a implementação padrão e também possuem systemd-timesyncd. Acho que o Chrony funciona bem, oferece uma interface melhor do que o serviço NTP, fornece muito mais informações e controle, o que os administradores de sistema certamente irão gostar.
Desativando serviços NTP
O serviço NTP pode já estar em execução no seu host. Nesse caso, você precisa desativá-lo antes de mudar para outra coisa. Eu tinha o chronyd em execução, então usei os seguintes comandos para pará-lo e desativá-lo. Execute os comandos apropriados para qualquer daemon NTP que estiver executando em seu host:
[root@testvm1 ~]# systemctl disable chronyd ; systemctl stop chronyd
Removed /etc/systemd/system/multi-user.target.wants/chronyd.service.
[root@testvm1 ~]#Verifique se o serviço está parado e desabilitado:
[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 ~]#Verificação de status antes do lançamento
O status de sincronização do relógio do sistema permite determinar se o serviço NTP está em execução. Como você ainda não iniciou o NTP, o comando timesync-status sugerirá isso:
[root@testvm1 ~]# timedatectl timesync-status
Failed to query server: Could not activate remote peer.Uma solicitação de status direta fornece informações importantes. Por exemplo, o comando timedatectl sem argumento ou opções executa o subcomando status por padrão:
[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 ~]#Isso fornecerá a hora local do seu host, hora UTC e hora RTC. Nesse caso, a hora do sistema é definida para o fuso horário America / New_York (TZ), o RTC é definido para a hora no fuso horário local e o serviço NTP não está ativo. A hora RTC começou a se desviar ligeiramente da hora do sistema. Isso é normal para sistemas cujos relógios não foram sincronizados. A quantidade de deslocamento 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 RTC - isso se aplica a alterações de fuso horário e configurações de horário de verão. Se o computador for desligado quando for necessário fazer alterações, o RTC não será alterado. Mas para servidores ou outros hosts que funcionam XNUMX horas por dia, isso não é um problema. Além disso, qualquer serviço que forneça sincronização de horário NTP ajustará o horário do host durante a fase inicial de inicialização, de modo que o horário estará correto novamente após a conclusão da inicialização.
Definindo o fuso horário
Normalmente, você especifica o fuso horário durante o procedimento de instalação e não tem a tarefa de alterá-lo posteriormente. No entanto, há momentos em que você precisa alterar o fuso horário. Existem várias ferramentas que podem ajudar. O Linux usa arquivos de fuso horário para determinar o fuso horário local de um host. Esses arquivos estão no diretório / usr / share / zoneinfo. Por padrão, para meu fuso horário, o sistema prescreve o seguinte: /etc/localtime -> ../usr/share/zoneinfo/America/New_York. Mas você não precisa conhecer essas sutilezas para alterar o fuso horário.
O principal é saber o nome do fuso horário oficial da sua localização e o comando correspondente. Digamos que você queira alterar o fuso horário para Los Angeles:
[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 você pode definir o fuso horário. Usei o comando date para verificar as alterações, mas você também pode 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 você pode alterar o fuso horário do seu host de volta para a hora local.
systemd-timesyncd
O daemon systemd timesync fornece uma implementação NTP que é fácil de gerenciar no contexto 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ê mesmo pode verificar:
[root@testvm1 ~]# systemctl status systemd-timesyncdConfigurando systemd-timesyncd
O arquivo de configuração para systemd-timesyncd é /etc/systemd/timesyncd.conf. Este é um arquivo simples com menos opções habilitadas do que os antigos serviços NTP e chronyd. Aqui está o conteúdo deste arquivo (sem modificações adicionais) na minha VM do 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 seção que contém, além dos comentários, é [Time]. Todas as outras linhas são comentadas. Esses são os valores padrão e não devem ser alterados (a menos que você tenha um motivo para isso). Se você não tiver um servidor de horário NTP definido na linha NTP=, o Fedora assume como padrão um servidor de horário Fedora alternativo. Eu costumo adicionar meu servidor de horário:
NTP=myntpserverSincronização de tempo em execução
Você pode iniciar e tornar o systemd-timesyncd ativo 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 do hardware
Aqui está a aparência da situação após a execução do 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 diferença entre o RTC e o horário local (EDT) é inferior a um segundo, e a discrepância aumenta em mais alguns segundos nos próximos dias. Como não há conceito de fuso horário no RTC, o comando timedatectl deve realizar uma comparação para determinar o fuso horário correto. Se a hora RTC não corresponder exatamente à hora local, ela também não corresponderá ao fuso horário local.
Procurando por mais informações, verifiquei o status do systemd-timesync e encontrei 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 mensagem de log que diz que a hora do sistema não foi definida ou foi redefinida. O serviço Timesync define a hora do sistema com base no registro de data e hora. Os timestamps são mantidos pelo daemon timesync e são criados em cada sincronização bem-sucedida.
O comando timedatectl não tem como obter o valor do relógio do hardware do relógio do sistema. Ele só pode definir a hora e a data a partir do valor inserido na linha de comando. Você pode definir o RTC para o mesmo valor da 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 opção --localtime diz ao relógio do hardware para mostrar a hora local, não UTC.
Por que você precisa do RTC?
Qualquer implementação do NTP definirá o relógio do sistema no momento da inicialização. E por que então RTC? Isso não é totalmente verdade: isso só acontecerá se você tiver uma conexão de rede com o servidor de horário. No entanto, muitos sistemas nem sempre têm acesso a uma conexão de rede, portanto, um relógio de hardware é útil para o Linux usar para definir a hora do sistema. Isso é melhor do que definir manualmente a hora, mesmo que possa se desviar da hora real.
Conclusão
Este artigo revisou algumas ferramentas para manipulação de data, hora e fusos horários. A ferramenta systemd-timesyncd fornece um cliente NTP que pode sincronizar a hora no host local com um servidor NTP. No entanto, systemd-timesyncd não fornece um serviço de servidor, portanto, se você precisar de um servidor NTP em sua rede, deverá usar outra coisa, como o Chrony, para atuar como um servidor.
Prefiro ter uma única implementação para qualquer serviço na minha rede, então uso o Chrony. Se você não precisa de um servidor NTP local ou se não se importa em usar o Chrony como servidor e o systemd-timesyncd como o cliente SNTP. Afinal, não há necessidade de usar os recursos adicionais do Chrony como cliente se você estiver satisfeito com a funcionalidade do systemd-timesyncd.
Outra observação: você não é obrigado a usar as ferramentas systemd para implementar o NTP. Você pode usar uma versão mais antiga do ntpd, Chrony ou outra implementação NTP. Afinal, o systemd consiste em um grande número de serviços; muitos deles são opcionais, então você pode desativá-los e usar outra coisa. Este não é um enorme monstro monolítico. Você pode não gostar do systemd ou de partes dele, mas deve tomar uma decisão informada.
Gosto da implementação do NTP pelo systemd, mas prefiro o Chrony porque atende melhor às minhas necessidades. É Linux, querida -)
Como a publicidade
VDSina oferece , uma grande variedade de sistemas operacionais para instalação automática, é possível instalar qualquer sistema operacional de sua preferência , confortável desenvolvimento próprio e pagamento diário. Lembre-se de que temos servidores eternos que são definitivamente atemporais 😉
Fonte: habr.com