ntpd Fails at Boot

[Bevan C. Bennett]

Markku Kolkka wrote:
> Bevan C. Bennett kirjoitti viestissään (lähetysaika Maanantai 05. 
> Tammikuuta 2004 19:42):
> 
>>Actually, it's not at all redundant for the common NTP setup
>>where there are 2-3 time servers and then all other systems
>>are configured as broadcast or multicast clients.
> 
> 
> How does punching holes for NTP servers in the firewall help in 
> this case? Connection tracking takes care of communicating with 
> the servers, and the firewall must be manually configured for 
> client connections anyway, the init script doesn't do anything 
> to allow them.

Connection tracking does -not- take care of communicating with 
broad/multi-cast servers because the client is just listening to UDP 
broad/multi-cast packets from the server, so there is no connection to 
track. The servers NTP packets are not in response to packets from the 
client, thus not part of an existing connection.

There's normally a brief conversation when a new server is 'discovered', 
but without an NTP firewall hole, that discovery never occurs.

I'm verifying this right now on my network, where I added:
FIREWALL_MODS="no" to a test client's /etc/sysconfig/ntpd file, then 
restarted iptables and ntpd (in that order).

After several minutes the client still has no time synchronization:
[bevan at wallace ~]> ntpq -p
No association ID's returned

I then restore /etc/sysconfig/ntpd and restart ntpd once more, allowing 
it to poke it's firewall holes and within a minute it has properly gone 
back to synchronizing to my time broadcasts.

You could argue that it's just as easy conf-file-wise to specify the 
servers directly in /etc/ldap.conf, in which case the client will 
initiate the connection and connection-tracking might help (I only say 
might because I haven't tested it), but that increases both network 
traffic and load on your NTP servers.