Bug 57407

Summary: [patch] Better NTP support for dhclient(8) and friends
Product: Base System Reporter: Roderick van Domburg <roderick>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me Keywords: patch
Priority: Normal    
Version: 5.1-CURRENT   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
isc-dhcp-ntp.patch none

Description Roderick van Domburg 2003-09-30 17:20:12 UTC 
	
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.
Comment 1 Roderick van Domburg 2003-09-30 17:24:13 UTC 
Forgot to edit the contact field - all feedback out to
r.s.a.vandomburg@student.utwente.nl please. Thanks!
Comment 2 Makoto Matsushita 2003-10-01 00:13:10 UTC 
+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
Comment 3 Roderick van Domburg 2003-10-01 05:05:34 UTC 
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.
Comment 4 Bruce M Simpson freebsd_committer freebsd_triage 2003-11-25 17:15:04 UTC 
Responsible Changed
From-To: freebsd-bugs->bms

I'm in hoover up network PRs mode. I'll look into this.
Comment 5 Bruce M Simpson freebsd_committer freebsd_triage 2003-11-25 17:16:09 UTC 
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.
Comment 6 Roderick van Domburg 2004-02-08 18:36:58 UTC 
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?
Comment 7 Roderick van Domburg 2004-02-14 14:36:50 UTC 
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.
Comment 8 Bruce M Simpson freebsd_committer freebsd_triage 2005-04-25 23:01:04 UTC 
State Changed
From-To: feedback->suspended

ENOTIME to work on this issue.
Comment 9 Bruce M Simpson freebsd_committer freebsd_triage 2006-08-02 14:10:17 UTC 
Responsible Changed
From-To: bms->freebsd-bugs

Back to the pool. 
Sadly, this really is something which should be handled by the vendor.
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2018-05-20 23:50:46 UTC 
For bugs matching the following conditions:
- Status == In Progress
- Assignee == "bugs@FreeBSD.org"
- Last Modified Year <= 2017

Do
- Set Status to "Open"
Comment 11 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:34:04 UTC 
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>