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@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.
