Re: [time-nuts] future NTP programs...
> it would not be OK to design a daemon which handles the crypto stuff or the > control packets in a root-process, those should go in a sandbox. Absolutely agree, in my previous life in the data security arena (crypto, data security, white hat tester etc..), doing that sort of thing in a privileged process or similar (e.g. kernel) was a seriously discouraged - far too great a risk of compromise. Keep it all in a user state process with NO write access to anything except the communications port (serial / UDP / TCP / w.h.y.) it is talking on. Regards, David Partridge ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message <54615794.3040...@rubidium.dyndns.org>, Magnus Danielson writes: >I'm just saying that the NTP processing and the NTP monitoring may not >need to run by the same daemon necessarily. As the Varnish architecture shows, I'm fully in agreement with this. I should also add that one of the reasons I don't like the control mode packets is that they are complex. I have no issues with handling the standard 48 byte fixed format, no strings NTP timing packets in a root-process, but in todays environment it would not be OK to design a daemon which handles the crypto stuff or the control packets in a root-process, those should go in a sandbox. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
"Poul-Henning Kamp" writes: > > In message <546152ac.8090...@rubidium.dyndns.org>, Magnus Danielson writes: > > >Monitoring as such is an important task, and some of the NTP clients > >might be servers in other contexts, and then it makes sense to monitor > >that they got their NTP time into shape. > > For which there has existed a system call for 20 years now: > > ntp_gettime() has as argument a struct ntptimeval * with the following > members: > > struct ntptimeval { > struct timeval time;/* current time (ro) */ > long maxerror; /* maximum error (us) (ro) */ > long esterror; /* estimated error (us) (ro) */ > }; > > These have the following meaning: > time Current time (read-only). > maxerror Maximum error in microseconds (read-only). > esterror Estimated error in microseconds (read-only). And those fields have value, and they are not "enough". The aim of NTF's General Timestamp API is to have a timestamp with "enough" values in it. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
> I'm just saying that the NTP processing and the NTP monitoring may not > need to run by the same daemon necessarily, just because we did that in the > past. Pulling things from the kernel provide more isolation, and the > monitor daemon can have special code to handle security issues of > monitoring, without making the processing dito suffer from it, beyond > making sure the data is available somewhere. > Because once you get past the simplest item you can monitor, the time NTP thinks it is. Then the only process that would have the informations ntpd. For example if you want to know the round rip "ping" time from some peer to your server then what can you do but ask the server? Mostly the thinks you monitor are NTP internal states and statistics. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
I don't think ntp requires nor should have anything like a dedicated multi system monitoring platform of its own. The fact is that today's modern data collection methods are more than adequate - ntpd need only store its values in an accessible place and a graphite agent or ajna or your choice of robust system data mining tools can scrape them regularly and store them for posterity. A server-local cli infrastructure is clearly invaluable to the troubleshooting process. But overall health monitoring is a wheel not in need of an overhaul On Monday, November 10, 2014, Magnus Danielson wrote: > Poul-Henning, > > On 11/11/2014 01:15 AM, Poul-Henning Kamp wrote: > >> >> In message <546152ac.8090...@rubidium.dyndns.org>, Magnus Danielson >> writes: >> >> Monitoring as such is an important task, and some of the NTP clients >>> might be servers in other contexts, and then it makes sense to monitor >>> that they got their NTP time into shape. >>> >> >> For which there has existed a system call for 20 years now: >> >> ntp_gettime() has as argument a struct ntptimeval * with the >> following >> members: >> >> struct ntptimeval { >> struct timeval time;/* current time (ro) */ >> long maxerror; /* maximum error (us) (ro) */ >> long esterror; /* estimated error (us) (ro) */ >> }; >> >> These have the following meaning: >> time Current time (read-only). >> maxerror Maximum error in microseconds (read-only). >> esterror Estimated error in microseconds (read-only). >> >> > Sure. So that's what another daemon could be pulling out. > > I'm just saying that the NTP processing and the NTP monitoring may not > need to run by the same daemon necessarily, just because we did that in the > past. Pulling things from the kernel provide more isolation, and the > monitor daemon can have special code to handle security issues of > monitoring, without making the processing dito suffer from it, beyond > making sure the data is available somewhere. > > Cheers, > Magnus > ___ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
Poul-Henning, On 11/11/2014 01:15 AM, Poul-Henning Kamp wrote: In message <546152ac.8090...@rubidium.dyndns.org>, Magnus Danielson writes: Monitoring as such is an important task, and some of the NTP clients might be servers in other contexts, and then it makes sense to monitor that they got their NTP time into shape. For which there has existed a system call for 20 years now: ntp_gettime() has as argument a struct ntptimeval * with the following members: struct ntptimeval { struct timeval time;/* current time (ro) */ long maxerror; /* maximum error (us) (ro) */ long esterror; /* estimated error (us) (ro) */ }; These have the following meaning: time Current time (read-only). maxerror Maximum error in microseconds (read-only). esterror Estimated error in microseconds (read-only). Sure. So that's what another daemon could be pulling out. I'm just saying that the NTP processing and the NTP monitoring may not need to run by the same daemon necessarily, just because we did that in the past. Pulling things from the kernel provide more isolation, and the monitor daemon can have special code to handle security issues of monitoring, without making the processing dito suffer from it, beyond making sure the data is available somewhere. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message <546152ac.8090...@rubidium.dyndns.org>, Magnus Danielson writes: >Monitoring as such is an important task, and some of the NTP clients >might be servers in other contexts, and then it makes sense to monitor >that they got their NTP time into shape. For which there has existed a system call for 20 years now: ntp_gettime() has as argument a struct ntptimeval * with the following members: struct ntptimeval { struct timeval time;/* current time (ro) */ long maxerror; /* maximum error (us) (ro) */ long esterror; /* estimated error (us) (ro) */ }; These have the following meaning: time Current time (read-only). maxerror Maximum error in microseconds (read-only). esterror Estimated error in microseconds (read-only). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
David and Poul-Henning, On 11/10/2014 10:34 AM, Poul-Henning Kamp wrote: In message <647BB61DCE1F4679A45CD5C1DB1FE963@Alta>, "David J Taylor" writes: I want to be able to monitor a number of servers from a central monitoring point (which might not even be running NTP), and using ntpq with its different options is, for me, an ideal way to do that. First of all, I'm focusing on the client software right now. That said: It goes without saying that monitoring servers is a different ball-game than monitoring clients. And no, I still don't like the ntpq stuff, because it cannot express the kind of things you'll want to monitor on a server, if you are serious about running it: How many clients report us as their REFID (is there something horribly wrong in a firewall somewhere ?) How many satelites does my GPS see ? And so on... How I'll doing the monitoring once I get to the server software remains to be seen, but it is very likely to involve a CLI interface and possibly a shared memory state Pretty much like Varnish ... feel free to wonder why ? :-) I think it is fair to consider that over time, we need to revisit how things was designed and make changes. It might be better to run a separate daemon for the monitoring protocol, and it could be providing the traditional monitoring protocol or something new, or both. Monitoring as such is an important task, and some of the NTP clients might be servers in other contexts, and then it makes sense to monitor that they got their NTP time into shape. There is however many ways to slice that fish. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
"Poul-Henning Kamp" writes: > > In message <0AA8645271A94DF3968C90FE6BF94276@Alta>, "David J Taylor" writes: > > >- that there is (eventually) a Windows implementation. > > I'm writing the code to be as portable as I can make it, but I have > neither Windows machines nor clue how to program for their kernel-time-api. We should talk about it - there are some options and opportunities there. H ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message <647BB61DCE1F4679A45CD5C1DB1FE963@Alta>, "David J Taylor" writes: >I want to >be able to monitor a number of servers from a central monitoring point >(which might not even be running NTP), and using ntpq with its different >options is, for me, an ideal way to do that. First of all, I'm focusing on the client software right now. That said: It goes without saying that monitoring servers is a different ball-game than monitoring clients. And no, I still don't like the ntpq stuff, because it cannot express the kind of things you'll want to monitor on a server, if you are serious about running it: How many clients report us as their REFID (is there something horribly wrong in a firewall somewhere ?) How many satelites does my GPS see ? And so on... How I'll doing the monitoring once I get to the server software remains to be seen, but it is very likely to involve a CLI interface and possibly a shared memory state Pretty much like Varnish ... feel free to wonder why ? :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
From: Poul-Henning Kamp [] Personally, I feel that the ability to monitor the workings of an NTP implementation remotely is an important feature of the (present) software. So, this is one thing I really don't understand... You can monitor all your clients from your server if you want to, by looing at the timestamp the client sends you. I implemented this feature in NTPns over a decade ago (see below) Why on Earth would anybody prefer to monitor it on each client separately instead of getting one central unified view ? Yes, of course you should be able to tell if your timekeeping is good on the local machine, but I don't think the control-mode NTP packets is a good idea. Poul-Henning === Poul-Henning, But if I understand NTPns correctly (I didn't know about it, by the way), it does not address the task I have in mind. I don't want to monitor clients from my server. I don't want to monitor servers from my client. I want to be able to monitor a number of servers from a central monitoring point (which might not even be running NTP), and using ntpq with its different options is, for me, an ideal way to do that. I use Perl scripts to interpret the output and plot it with MRTG. What I'm doing at the moment happens to run on Windows, but as it's a combination of ntpq, Perl and MRTG is could be run almost anywhere Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message <43713AD334A7485B8B0CCED799C6C19A@Alta>, "David J Taylor" writes: >Personally, I feel that the ability to monitor the workings of an NTP >implementation remotely is an important feature of the (present) software. So, this is one thing I really don't understand... You can monitor all your clients from your server if you want to, by looing at the timestamp the client sends you. I implemented this feature in NTPns over a decade ago (see below) Why on Earth would anybody prefer to monitor it on each client separately instead of getting one central unified view ? Yes, of course you should be able to tell if your timekeeping is good on the local machine, but I don't think the control-mode NTP packets is a good idea. Poul-Henning NTPns > show ntpv4 0 partner IP number port leap v m s p P offset refid Max partners: 1 total ours others partners2458855 1603 partners good 1874843 1031 partners bad 584 12572 partners > 1s323 5318 partners < 1s470 10460 partners < 100ms 367 37330 partners < 10ms 521195326 partners < 1ms 777608169 NTPns > show ntpv4 0 partner bad IP number port leap v m s p P offset refid 0.0.38.89 123 no 3 3 0 0 0 -0.166501269 [] 0.0.62.87 123 no 3 3 0 0 0 -0.755177799 [] 0.0.10.55 123 no 1 3 0 0 0 -0.397674942 [] 0.0.240.197123 unk 4 3 0 6 -19-3308.8 [INIT] 0.0.227.61 123 no 4 3 0 0 0 -3.024952149 [] 0.0.125.188123 no 3 3 0 0 00.185896998 [] 0.0.145.174123 no 3 3 0 0 00.465722434 [] 0.0.196.133123 no 3 3 0 0 0 -0.180700990 [] 0.0.16.190 123 unk 3 3 0 10 -6 -0.520566284 [] 0.0.68.26 123 no 3 3 8 6 -180.345824138 [CHU_AUDIO#1] [...] IP numbers obfuscated to protect the incompetent... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
- that there is (eventually) a Windows implementation. I'm writing the code to be as portable as I can make it, but I have neither Windows machines nor clue how to program for their kernel-time-api. - that it responds to "ntpq -pn" and "ntpq -crv" commands so that it can be easily remotely monitored. The jury is still out on the control protocol. To be honest I don't much like it from a security point of view, and the parameters of my clock control algorithm may not map well into its datafields. Time will show... Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 == Yes, I can appreciate the Windows problems. We have more than a thousand clients running the reference NTP as ported by Meinberg very happily, but if there were a better-performing implementation that would be "nice" to have. Personally, I feel that the ability to monitor the workings of an NTP implementation remotely is an important feature of the (present) software. I can run on one system a single monitoring program which then checks NTP running on Windows, Linux and FreeBSD systems using exactly the same over the wire ntpq commands. Perhaps you can return dummy values where your algorithm differs? The ability to know lock status, offset and jitter (ntpq -crv) is useful for longer term checking, and the "*" in ntpq -p helpful for a response to a quick-look "is it working?" interrogation. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message <0AA8645271A94DF3968C90FE6BF94276@Alta>, "David J Taylor" writes: >- that there is (eventually) a Windows implementation. I'm writing the code to be as portable as I can make it, but I have neither Windows machines nor clue how to program for their kernel-time-api. >- that it responds to "ntpq -pn" and "ntpq -crv" commands so that it can be >easily remotely monitored. The jury is still out on the control protocol. To be honest I don't much like it from a security point of view, and the parameters of my clock control algorithm may not map well into its datafields. Time will show... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
From: Poul-Henning Kamp [] My first target is a daemon for clients, that's the most efficient way to eliminate as many KLOC-executions from the world as possible as fast as possible. After that, the intent is to reuse the same components also for S2+ slave servers, and later again S1 servers. But the target right here and now is clients only. == Poul-Henning, I would like to see two things in a new client: - that there is (eventually) a Windows implementation. - that it responds to "ntpq -pn" and "ntpq -crv" commands so that it can be easily remotely monitored. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] future NTP programs...
In message , =?iso-8859-1?Q?=22Bj=F6rn_Gabrielsson=22?= writes: >Nevertheless I was a bit surprised that the computer continued to serve >time claiming to be a S1-server, even if both local refclock and a number >of external S1-servers said time was false. I dont know if recent ntpd and >operating system versions still have this problem. Yeah, this is the kind of shit you have to put up with when your time-server source code is 100+ KLOC and has gotten to that size by "lets just add this feature" methodologies. >Poul-Henning, for the updated server with local refclock, have you >elaborated over My first target is a daemon for clients, that's the most efficient way to eliminate as many KLOC-executions from the world as possible as fast as possible. After that, the intent is to reuse the same components also for S2+ slave servers, and later again S1 servers. But the target right here and now is clients only. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.