This patch adds support to dhclient(8) and friends to automatically write out an appropriate /etc/ntp.conf if a NTP server was supplied by the DHCP server, querying for NTP servers by default. The changes in functionality are fully reflected in the man pages. I believe these feature changes to be justified, since ntpd is an integral part of the FreeBSD base system. The changes are transparent to nearly all users. It eases the task of configuration and better suits FreeBSD to NTP-enabled environments. This behavior already is exhibited by the PhysTech DHCP client that is the default client on many Linux distributions. I have contacted the ISC DHCP development team asking them to include this functionality upstream. Without commenting on the quality of this patch, however, they preferred a far more complex and extensible system rather than including operating system-dependent implementations. So far, no one at ISC has taken this task upon himself and it is unlikely that it will appear anytime soon if at all. I would be more than happy to maintain this patch for future ISC DHCP imports.
Forgot to edit the contact field - all feedback out to r.s.a.vandomburg@student.utwente.nl please. Thanks!
+make_ntp_conf() { + if [ x"$new_ntp_servers" != x ]; then + ( echo restrict default noquery notrust nomodify >/etc/ntp.conf ) + exit_status=$? + if [ $exit_status -ne 0 ]; then + $LOGGER "WARNING: Unable to update ntp.conf: Error $exit_status" + else + ( echo restrict 127.0.0.1 >>/etc/ntp.conf ) + for ntpserver in $new_ntp_servers; do + ( echo restrict $ntpserver >>/etc/resolv.conf ) + done + for ntpserver in $new_ntp_servers; do + ( echo server $ntpserver >>/etc/resolv.conf ) + done + ( echo driftfile /etc/ntp.drift >>/etc/resolv.conf ) + fi + fi +} I doubt if this function, make_ntp_conf() does the right things, since it writes NTP-related contents to /etc/resolv.conf (see above). -- - Makoto `MAR' Matsushita
You are right. Obviously, it should have been written to /etc/ntp.conf. It's a mistake I made in my very first patchset where I (too) blindly copied the make_resolv_conf() example. I'm not sure how I managed to submit the incorrect patch. No matter; the corrected version is available at http://home.student.utwente.nl/r.s.a.vandomburg/patches/isc-dhcp-ntp.patch. s/resolv.conf/ntp.conf/ in make_ntp_conf(). Oops.
Responsible Changed From-To: freebsd-bugs->bms I'm in hoover up network PRs mode. I'll look into this.
State Changed From-To: open->feedback I was just thinking the other day we need something like this. Have you fielded this with isc-dhcp maintainers, however? We keep it on a vendor branch so I am reluctant to commit this as-is.
Sorry to get back to you so late. I sent an email over the ISC DHCP hackers list but never got any response. Perhaps someone with more "authority" will draw more attention?
Actually, I now remember I did have a discussion about this with a developer. He opted for a more dynamic approach: daemons et al could write out a file to, say, /etc/dhcp/options/XXX to express their interest in certain hooks and provide a way to write out such a configuration file. Agreed, it is the better approach but I can't devote the resources to write that for dhclient. No one else volunteered either. In short, it looks like it won't get accepted into the vendor branch.
State Changed From-To: feedback->suspended ENOTIME to work on this issue.
Responsible Changed From-To: bms->freebsd-bugs Back to the pool. Sadly, this really is something which should be handled by the vendor.
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
Keyword: patch or patch-ready – in lieu of summary line prefix: [patch] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>