Eu leio desktops / servidores que são executados por semanas sem reinicialização e nem interfaces de rede down / up preferem executar o cliente ntpd em vez de depender do ntpdate. Então eu instalei o pacote ntp com o libopts25. Devo agora remover o ntpdate para que ele não encontre o ntpd se o nic perder o link?
Além disso, vi em /etc/ntp.conf que a Canonical recebeu um pool de fornecedores do ntp.org. Como o ntp.org afirma que usuários simples podem usar {0,1,2,3} .countrycode.pool.ntp.org, eu deveria substituir o ubuntu pool com "my" fr pool, ou adicionar fr entradas em cima do ubuntu?
Além disso, eu precisaria da confirmação de algo que eu tenha entendido sobre o dito acesso exigido pelo firewall bidirecional (espero que isso ajude os outros): à primeira vista, somente pacotes de saída (porta 123) seriam permitidos. é o padrão principalmente em todos os roteadores ISL DSL), pois o NAT encaminhará os pacotes de resposta para o solicitante inicial ... contanto que o requisitante consulte por ip (ou por fqdn que mapeie para um único ip). Mas com sistemas como o pool.ntp.org respondendo por ip's aleatórios nós adicionalmente (ou em vez disso?) Precisamos de um port-forward ... então para a única máquina na lan que obteria ntp inicial "ofertas" (em relação ao ip desconhecido ) como conseqüências de suas consultas para um round-robin fqdn? Isso significa que o cliente ntpd também atua como um servidor (aqui não significa que dará tempo para outras máquinas, por exemplo, na LAN, mas significa que ele ouve as consultas de servidores ntp reais empurrando-o atualizações de tempo que ele pediu para outro ip) .. hmm, eu acho que sinto falta de algo que o RFC não vulgariza o suficiente para mim.