Desvio temporal e fuso horário errado dentro da configuração NTP

Question

Temos 2 VLANs, cada VLAN tem um servidor que fornece DHCP, DNS e NTP para sua VLAN correspondente. Esses 3 servidores levam tempo de um servidor NTP local. Aqui está a configuração do cliente e dos servidores NTP em cada VLAN e o problema de cada configuração:

VLAN 1:

Servidor NTP (Scientific Linux 7.3)

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
logfile /var/log/ntp.log
driftfile /var/lib/ntp/drift
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
restrict 127.0.0.1
restrict xx.xx.xx.xx mask XX.XX.XX.XX nomodify notrap

Cliente NTP (Scientific Linux 7.3)

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
server yy.yy.yy.yy   # added by /sbin/dhclient-script

Este servidor está sempre à deriva durante 3 horas, apesar do fuso horário correto.

VLAN 2:

Servidor NTP (Scientific Linux 6.4)

restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
logfile /var/log/ntp.log
server 127.1.1.0 # local clock
fudge  127.127.1.0
driftfile /var/lib/ntp/drift
restrict 127.0.0.1
restrict xx.xx.xx.xx mask XX.XX.XX.XX nomodify notrap

Cliente NTP (Scientific Linux 6.4)

driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
server yy.yy.yy.yy   # added by /sbin/dhclient-script

Aqui não consegui alterar o fuso horário. Deve ser EET , mas é sempre EEST , apesar do valor do link /etc/localtime .

Eu me certifiquei de que:

1. Nenhuma regra de firewall ( iptables -F )
2. O daemon ntpd está em execução e ativado ( chckonfig on )
3. O CentOS 7.x usa outro serviço de hora chamado chronyd , que bloqueia ntpd da inicialização. Então eu desabilitei (Perdi a fonte para isso :().

Depois de configurar esses serviços, nós os sincronizamos com o NTP local uma vez. Através da configuração do DHCP em cada servidor, temos option ntp-servers xx.xx.xx.xx; , para que as informações do NTP sejam distribuídas com o DHCP. Eu tentei adicionar o endereço do servidor NTP local ao /etc/ntp.conf do servidor, mas o problema ainda está lá.

Observe que todos os servidores são virtualizados por meio do VMWare ESXi.

    

Answer 1

Se o /etc/localtime estiver apontando para /usr/share/zoneinfo/EET , essa definição de fuso horário inclui o Horário de verão europeu (= horário de verão europeu) e entre o último domingo de março e o último domingo de outubro, esse fuso horário será listado como EEST EET. E no momento em que escrevo, o dia da mudança foi ontem ...

Você deve ler as melhores práticas de marcação de tempo do VMware para VMs Linux . Resumindo:

• verifique se o VMware Host está usando o horário e o fuso horário corretos.
• se você estiver usando o NTP nos convidados:
  • verifique se a sincronização de horário do VMware Tools está desativada
  • adicione tinker panic 0 como a linha primeiro do /etc/ntp.conf
  • se houver uma definição de relógio local como server 127.127.1.0 em ntp.conf , comente .
  • insira os nomes de host ou endereços IP de seus servidores NTP no arquivo /etc/ntp/step-tickers para fazer seus sistemas pularem seus relógios no tempo correto na inicialização assim que as interfaces de rede forem ativadas e qualquer coisa que seja sensível ao tempo, como bancos de dados, ainda não foi começou.

Algumas armadilhas que encontrei:

• /etc/adjtime especifica qual é o relógio de hardware esperado: UTC ou LOCAL. Alterar apenas a variável em /etc/sysconfig/clock não necessariamente fará o que você deseja. Certifique-se de que ambos os lugares estejam de acordo, apenas para garantir.
• verifique se seus servidores NTP estão atendendo o tempo correto UTC .
• quando uma hora do sistema é um número exato de horas de folga, primeiro use date -u para verificar se a ideia do horário UTC do sistema está correta. O NTP só lida com o UTC; qualquer erro de conversão para a hora local é culpa das configurações de fuso horário.

Answer 2

Então, depois de uma luta com esses servidores, o problema foi resolvido. Aqui estão os detalhes:

1. Para o servidor CentOS 7.X, desativei ntpd e usei chronyd , mantendo ntpd nos clientes. Parece que chronyd será o daemon NTP suportado pelo CentOS 7.X em diante. A configuração chronyd requer apenas server xx.xx.xx.xx prefer iburst e allow yy.yy.yy.yy/ZZ em /etc/chrony.conf
2. Para o servidor CentOS 6.4, tive que instalar uma nova versão de tzdata aqui e, em seguida, vincule /etc/localtime ao fuso horário correspondente, no meu caso Asia/Amman

Algumas armadilhas que eu contei:

• O erro de pesadelo no server suitable for synchronization found nos clientes do CentOS 6.4 foi resolvido parando ntpd , executando ntpdate e, em seguida, iniciando ntpd .
• Por alguma razão eu não me lembro, no CentOS 6.4 eu tive que mudar restrict 127.0.0.1 para restrict localhost