The new sipx-setup-system script attempts to configure ntpd and set the system clock using it. This not only increases the likelihood of ntpd being set up, it (usually) avoids having to prompt for the date and time. In order to avoid having to ask the user for NTP servers, the script provides a default set of three servers using the pool.ntp.org [1].
If the system is connected to the Internet, even through a reasonable firewall, this will usually work well enough. There is a task in the current sprint to allow the user to configure better NTP servers (the default are from the global pool, so it's very likely that there will be more local servers available somewhere). However - there have been some problems with this... it seems that if you configure bad or unreachable NTP servers, the command used to initially set the time [2] can just hang indefinitely. Since the setup script is not easily abortable, this is a pretty bad thing. My first cut at fixing this was to try pinging each server and only setting the time if at least one answered the ping. This helped somewhat, but didn't quite do the trick, since if you happen to get an NTP server that answers 'ping' but not NTP requests (can happen - the pool information from DNS can be out of date) then you're stuck again. I've got a patch that uses the 'nc' command to see if something is listening to (or, more accurately - that no ICMP errors are returned for UDP packets to) the NTP port. This helps a bit more. All this probing is a little time consuming, but my latest version at least keeps putting up progress messages... I have not found a way to do a really good test of a remote NTP server... if anyone has an idea, I'd love to hear it. [1] http://www.pool.ntp.org/ [2] /usr/sbin/ntpd -q -g _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
