>>> In article <7q7r56-9tb....@gateway.py.meinberg.de>, Martin Burnicki >>> <martin.burni...@meinberg.de> writes:
Martin> *only* sends via an unprivileged port if either -q (query only), -u Martin> (unpriv. port), or -d (debug) is given on the command line. Harlan> First, given that ntpdate is about to be deprecated in favor of the Harlan> new SNTP Client, ... Martin> The topic of this thread is ntpdate vs. ntpd, and I just wanted to Martin> clarify some statements about ntpdate which are simply wrong. Yes, and since ntpdate is being deprecated with the replacement being various combinations of ntpd and sntp I figured we might as well be sure any desired changes could be accomodated "in the future": Harlan> ... while this discussion is interesting at face, I see us using Harlan> this information to guide the bahavior of the sntp code and don't Harlan> expect to see any changes to ntpdate (especially since there is no Harlan> maintainer for ntpdate). Martin> From the discussion here I don't see why any changes should be Martin> required/requested for ntpdate. Agreed, but I think we may want to tweak the behavior of sntp. Harlan> Without thinking about this much, I agree 100% that -u should mean Harlan> "not from port 123". Harlan> Harlan> I can see cases where one *might* want this behavior for -q but I'm Harlan> not certain it should be forced for -q. Harlan> Harlan> I wonder quite a bit more why we would want this behavior for -d. Harlan> Harlan> For either of these last two cases it should be trivial to also Harlan> supply -u if that is what was really desired. Martin> What I've written corresponds to the behaviour of ntpdate as-is, and Martin> IMHO this is very useful. OK. Martin> As I understand this, this is due to the history of ntpdate. I think so. Martin> If "ntpdate %host%" was run to set the system time then this worked Martin> to set the initial system time before ntpd was started but did not Martin> work if ntpd already had port 123 open. I think so, too. Martin> This kind of usage may be obsolete after -g has been introduced for Martin> ntpd. BTW, why is the beaviour of ntpd -g not the default? IMHO Martin> this is exactly what users expect from ntpd. Because ntpd also gets restarted, and there is a strong belief that -g is bad for a restart and restarts will happen more often than boots. Martin> Anyway, ntpdate is still very good to debug NTP problems. And sntp should be able to take over that role. Martin> You can run ntpdate -q as a quick test to check the time offset Martin> against a particular server, even if ntpd is running and that server Martin> is not in ntpd's list. If you want to see more details of the packet Martin> exchange you can run ntpdate -d. Both commands can easily be used Martin> without interfering with the running ntpd, and this is mainly Martin> because they use a different port to send the request. Makes sense, and "ntpdate -q" is the same as "sntp" and with each you will get more verbosity/debugging if one supplies -d. Martin> IMHO programs which do not provide any services should in general Martin> use random ports by default. ntpdate sending requests via port 123 Martin> is IMHO an exception in order to prevent it from unintentionally Martin> messing up ntpd. If sntp can also be run as daemon then maybe it Martin> should use port 123 in daemon mode, but use a random port by default Martin> in non-daemon mode. If somebody wants to set the clock using sntp, I'm perfectly fine having it use port 123 by default and a random port only if -u is provided. sntp does not at this time have a daemon mode. Max, is this correct? Since sntp is effectively a new program, I'm OK having a discussion about exactly what options are appropriate in which circumstances. My preference is to start from a "clean slate". Martin> If ntpd is not running you can use ntpdate with and without -u/-d to Martin> see if a reply from an upstream server is received. This can be Martin> helpful to find out whether a firewall is blocking no ports / all Martin> ports / only privileged ports. Yes, and sntp can be used similarly. Martin> The problem with ntpdate is that code which is used in several Martin> programs of the NTP package (ntpd, ntpdate, ntptimeset, ...) has Martin> been *copied* from one program to another instead of putting it into Martin> a commonly used source file, e.g. in libntp. Over the years changes Martin> have been applied to the code in ntpd, but those changes have not Martin> made their way into the other programs of the package. Agreeed. Martin> Recently sntp has been written from scratch. So this a pretty new Martin> code base. However, AFAIK this did not compile e.g. under Windows, Martin> and in the mean time the author/maintainer has disappeared. This is the old, msntp implementation. That code also had licensing issues. Martin> Now gsoc-sntp is there, and I don't see how this could be built Martin> e.g. under Windows. What I see is that a number of functions which Martin> are available in ntpd and can be used both under Unix and windows Martin> have again been duplicated/rewritten in gsoc-sntp. So there is one Martin> more code base which needs to be ported and maintained. Great. First, the intent is that gsoc-sntp will build under Windows. Second, there wasn't time during GSoC to revamp the code tree so a single common codebase was used. This is something we intend to do, but it will not happen before 4.2.6 comes out. There was also a fair amount of discussion about whether or not the sntp codebase should be completely separate from the ntpd codebase. My decision was to have them share code whenever possible, and unless I am convinced the other can of worms is tastier, this is what we'll be doing. Martin> BTW, the same basic problem is with the ISC libraries, which also Martin> seem to have been copied e.g. from ISC's bind. Nowadays there a Martin> different versions of the same source code modules both in libisc/ Martin> and ports/winnt/libisc, e.g. interfaceiter.c, isc_strerror.c, and Martin> net.c. This was a mistake IMO, and there should have been a single codebase. I believe the reason for it is that in the stock ISC libisc/, there are subdirs for unix/ and win32/ and when Danny(?) did the initial import of libisc the main codebase was flattened a bit and it contains the Unix code, and the ports/winnt/ subtree contains the win32/ code. This should get better when ISC releases libisc as a tearoff/standalone library. My intent is to import libisc as a single unit, and this will affect the build scripts for Windows. Martin> IMHO this is also quite error prone. E.g. There are 5 (!) instances Martin> of the isc_interfaceiter_create() function in the code base, 3 below Martin> libisc/, and 2 below ports/winnt/libisc/. Yes, this is Bad and it's on the list of things to resolve. -- Harlan Stenn <st...@ntp.org> http://ntpforum.isc.org - be a member! _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
