OpenBSD Journal

OpenBSD-current gets its own NTP daemon

Contributed by grey on from the henning in the daemon lab again dept.

Thanks to Ash'aman for writing: Henning Brauer & Co. are now hacking an Network Time Protocol daemon into shape in -current. According to the commit message it is already capable of answering (s)ntp4 requests with the local time and ipv6 support has been added as well. Yet another reason to love OpenBSD!

(Comments are closed)

Comments

  1. By Anonymous Coward (24.34.57.27) on

    Yet another reason to love OpenBSD!

    Because they reinvent the wheel instead of spending time on something more worthwhile? Where's SMP support in a release?

    Comments

    1. By Anonymous Coward (67.71.26.138) on

      I think it's kinda neet... sntpd, sntp, ntpd and ntp - native (if I understand it that way?) but is it that important over other options we have at present? Perhaps a licensing issue is the reason behind this rather than modifying something else? I too would personally much prefer some SMP support over time spent on things like this, but hey, this is a volunteer thing so who really has the right to complain? I for one sure don't and I'm still very proud and grateful for OpenBSD and all it has to offer - at present and in the future.

    2. By Anonymous Coward (67.71.26.138) on

      I think it's kinda neet... sntpd, sntp, ntpd and ntp - native (if I understand it that way?) but is it that important over other options we have at present? Perhaps a licensing issue is the reason behind this rather than modifying something else?

      I too would personally much prefer some SMP support over time spent on things like this, but hey, this is a volunteer thing so who really has the right to complain? I for one sure don't and I'm still very proud and grateful for OpenBSD and all it has to offer - at present and in the future.

      Comments

      1. By Anonymous Coward (67.71.26.138) on

        Sorry about the double post, long story... Is there any way it can be removed?

    3. By djm@ (61.95.66.134) on

      You are wrong in thinking that time spent on ntpd could magically be turned into time spent implementing SMP. These activities are not comparable, it is something like blaming your cardiologist for not fixing your fridge.

      Comments

      1. By tedu (128.12.75.69) on

        but see, when you don't write code, it's all the same. it's just as easy to whine about complex features as simple features.

    4. By Otto (82.197.192.49) otto@drijf.net on http://www.drijf.net

      Because they reinvent the wheel instead of spending time on something more worthwhile? Where's SMP support in a release?

      If you ever looked at the existing ntpd code, you know why a new version should be written. ntpd is a big, scary daemon: it handles network stuff and it runs as root. OpenBSD needs a simple, privilege separated ntpd.

      If a wheel is square, it needs to be replaced.

      Comments

      1. By Tim Kelly (65.4.114.23) hockey [at] dialectronics.com on http://www.dialectronics.com

        What I'd like to see is a separation of the ntpd from an ntp client. It is unnecessary to have to run a full ntp server just because you want to sync your particular computer to network time. This separation has been done on other operating systems (MacOS 9.x comes to mind), so if ntpd is being rewritten for OpenBSD, now would be a good time to do this (if it hasn't already).

        Comments

        1. By Daniel (212.184.120.194) on

          You might want to check the manpage for rdate.Perhaps it does what you want?

          Comments

          1. By Tim Kelly (65.4.114.23) hockey [at} dialectronics.com on http://www.dialectronics.com

            Looks like rdate will do it. It's amazing that OS X can't make such a simple leap (as of 10.2.3, selecting "Use a network time server" would enable ntpd without informing the user of this action).

            Comments

            1. By Tim Kelly (65.4.114.23) on

              Oops - I forgot to say thanks!

        2. By Henning Brauer (80.86.183.227) henning@openbsd.org on

          What I'd like to see is a separation of the ntpd from an ntp client. It is unnecessary to have to run a full ntp server just because you want to sync your particular computer to network time. in OpenBSD, rdate supports ntp as well, so for a very simple client this is sufficient. aside from that, the difference between a "real" ntp client and a ntp server is close to zero - basically, all you need to do is ignoring requests. might be a good idea to add a command line switch or config file option or somesuch for that.

        3. By Anonymous Coward (134.100.120.75) on

          However, there are very valid reasons why the client and the server should be the same daemon. Let me explain :

          The simple setup would be : one server (e.g. with broadcast instruction and being client to a remote stratum-1 or stratum-2 server) and several clients (with server lines in their config). Essentially, the server is a relay and the central point of failure. If the master fails, all the clients will essentially drift (at least relative to each other)

          However. there is a more elegant way : the use of the peer instruction in the config file. Then there is no distinction between server and client anymore (one or two still should but need not be client to some stratum-1 or stratum-2 master servers). The advantage is that such a "swarm" of peers will keep the time accurate relative to each other even if there is no server available (because e.g. the connection to the external stratum-1 or stratum-2 server drops). I.e. no drifting is happening.

          Hmmm ... I guess the peer functionality could be implemented in the client.

        4. By Anonymous Coward (64.231.4.175) on

          Because it many cases an NTP daemon is both a server and a client at the same time. It gets the time from clocks on the Net, and then lmachines on the local network sync to it. The case of your home machine syncing from the 'net and nothing syncing to it is just one case (though a common one).

        5. By RC (4.61.196.211) on

          X It is unnecessary to have to run a full ntp server just because X you want to sync your particular computer to network time. Not really... Of course you don't have to serve requests to the network if you don't want to, but having the daemon running gives you something that rdate/ntpdate doesn't... It will collect statistics on how out-of-sync your local clock is, and use that to slightly speed-up or slow-down your local system clock ("tickadj"). That means more accurate time with less network updates. Now, I don't consider that too important on a LAN... If you want to run rdate every 10 minutes, there's little reason not to do so. However, when you are syncing over the internet to public time servers, the less bandwidth you use, the better off everyone is. Personally, I let workstations use rdate at bootup, but any machines that need accurate timestamps in their syslogs should run ntpd, even if they don't serve any ntp clients.

        6. By Anonymous Coward (132.204.24.84) on

          If you look at openntpd, you'll see that the server part is tiny. And it's only active if requested explicitly in the config file, so there's no security problem either.

      2. By Ash'aman (212.135.28.58) on

        Exactly! First thing I do after I install OpenBSD is install NTP from ports. Now it's in the base system and it will benefit from all the OpenBSD goodness I've come to depend on, such as privsep, source auditing, low-carb code, etc. Thank you Henning!

      3. By Anonymous Coward (24.89.13.231) on

        Or you can build a special road for it...

    5. By Anonymous Coward (192.195.135.35) on

      So where are your SMP patches?

    6. By Anonymous Coward (195.217.242.33) on

      Where's SMP support in a release?

      I thought you were doing it ?

    7. By mirabile (2001:6f8:94d:1:2c0:9fff:fe1a:6a01) on

      OpenBSD 3.7 will have SMP, they promised. I don't like it. I don't like the ntpd either - the (S)NTP protocol suite is broken, both with regards to leap seconds[1] and to the Y2038 problem. [1] http://cr.yp.to/proto/utctai.html I already fixed [1] in rdate(8).

      Comments

      1. By mirabile (2001:6f8:94d:1:2c0:9fff:fe1a:6a01) on

        Why can't you simply allow plaintext postings? Slashcode does, even the old deadly did.

        But then, it's nice you do IPv6.

        Comments

        1. By krh (207.75.180.242) on

          At the bottom of every page on undeadly is a link marked source code. I'm sure that you can write a patch if the urge strikes you.

      2. By djm@ (61.95.66.134) on

        I don't recall anyone "promising" that 3.7 will have SMP, I think more modulated words like "hopefully" were used.

      3. By Anonymous Coward (209.162.224.62) on

        Its ok, you don't like everything, and everyone doesn't like you, so it balances out.

    8. By Damien (213.41.138.23) on

      Its very funny to see always the same people that keep asking for something instead of doing it themselves. One thing is sure: ranting will not help making more source code :)

      Comments

      1. By mirabile (2001:6f8:94d:1:2c0:9fff:fe1a:6a01) on

        Me sending in diffs won't usually do the job either. I've seen that before.

        Comments

        1. By Miod (212.234.41.17) miod@ on

          Maybe because your diffs are not always good enough, or do not match the project's goals.
          Submitting a diff does not necessarily imply that it will be picked up...

    9. By Olivier (83.77.64.188) olivier.brisson@bluewin.ch on http://www.rando-roller-grenoble.org

      Who really needs SMP? But for NFS, security and plenty other reasons, NTP is a must to have.
      Oliver

  2. By Peter Williams (68.40.183.235) peter@pbw.us on http://pbw.us

    I think that it is great that work is being done on this. OpenBSD does a great job of improving soruce for programs. Thanks!~ Peter

  3. By corey (208.191.164.101) on

    I'm happy to see security enhancements and code cleanup in ntpd. The existing one won't even run on a 32MB machine because it tries to lock a large portion of itself in memory (presumably to keep swapping activity from screwing up the time sync routines), and I always had to comment that locking code out and recompile to get it going on my home firewall.

    Just curious: is the "new" ntpd going to be a complete replacement for the existing version, i.e., with local clock correction, multiple external clock drivers, etc.?

    Comments

    1. By Henning Brauer (80.86.183.227) henning@ on

      Just curious: is the "new" ntpd going to be a complete replacement for the existing version, i.e., with local clock correction, multiple external clock drivers, etc.?
      Yes, that's the plan. Help is welcome of course ;)
      I have client functionality, i. e. the ability to sync to one external server, partly done locally, need to find some time to finish that. Alexander has the key stuff mostly done. We then need the PLL shitz, which is a bit... complicated, but I am sure we'll find our way.

      Comments

      1. By corey (208.191.164.101) on

        I'd love to help, but I'm afraid my C skills aren't up to the task. Maybe one of these days...

    2. By Henning Brauer (80.86.183.227) henning@ on

      Just curious: is the "new" ntpd going to be a complete replacement for the existing version, i.e., with local clock correction, multiple external clock drivers, etc.?
      Yes, that's the plan. Help is welcome of course ;)
      I have client functionality, i. e. the ability to sync to one external server, partly done locally, need to find some time to finish that. Alexander has the key stuff mostly done. We then need the PLL shitz, which is a bit... complicated, but I am sure we'll find our way.

    3. By Alexander Guy (206.72.82.135) alexander@ on

      Just curious: is the "new" ntpd going to be a complete replacement for the existing version, i.e., with local clock correction, multiple external clock drivers, etc.? Yes, as time permits. I've got GPS satellite syncronization in my local tree, using any NMEA-compatible GPS (I'm looking at PPS support right now, but don't hold your breath). When it shapes up, I'll send out diffs.

      Comments

      1. By Anonymous Coward (4.16.136.107) on

        You guys rock. That's exactly what I was wanting. :D

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]