Re: [Dorset] Setting up an NTP Server in a Closed Network
On Thursday, 24 August 2017 13:48:59 BST Terry Coles wrote: > On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote: > > ntp-wait(1) might be of interest: "This can be useful at boot time, to > > delay the boot sequence until after ntpd -g has set the time". > > That is definitely of interest. If all else fails, then this could ensure > that the clocks are synced before we try to run our software. > > However, the man page isn't very helpful with respect to when to launch it > and where from. Since there isn't much point in delaying the start of the > system until NTP itself has started, then I'm assuming that I could put it > into rc.local, except that this file has the following comment in it: > > # This script is executed at the end of each multiuser runlevel. > > If it waits until the end of the runlevel, is that too late? Presumably, as > long as further processing is delayed before we launch our software from > .bashrc, we should be OK. Ralph, Well I tried it in rc.local and it works. It is an interesting experience, because although it does hold up further booting until sync occurs, messages continue to arrive from the boot process for a short time. I assume that this is upstart in action, eg the residual messages come from boot activities triggered by upstart before the command is executed, but which hadn't finished. Anyway, the system then sits there doing next to nothing until the clock syncs (you get a rather abrupt OK) and then our software starts immediately after. I'd still like to know if there is a solution to the 10 minutes of KoDs, but this will work and it isn't as if we are trying to control something that needs microsecond response times. Thanks for your help. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Thursday, 24 August 2017 12:51:38 BST Ralph Corderoy wrote: > Where was this script? I forgotten upstart, but it probably still copes > with scripts in /etc/init.d. If it's one of those, see update-rc.d(8). > https://debian-handbook.info/browse/stable/unix-services.html#sect.system-bo > ot The script that I modified was the standard one to start ntpd. It is installed in /etc/init.d. Anyway, I've moved on a bit since then (see below). > I notice date(1) says UTC on one machine, and GMT on the other. The I hadn't spotted that. I'll make them the same. > `-q' could do with a `-g' if you expect the discrepancy to be large. > The `KoD... inconsistent xmt/org/rec timestamps. Ignoring.' that last > some minutes are because the incoming packets from the server don't have > those three timestamps set to the xmt one that was sent out. I don't > know why that would be. Yes. I kind of worked out what the error was, but not necessarily the cause. > > As you can see, the sync is quicker, but it still took nearly 5 > > minutes. I'm not sure why the daemon takes that long, but it may be > > as good as it gets. Does anyone know? > > Not getting those `ignoring' messages will probably shorten that. Wouldn't that be nice :-) > > Final question; I can only start ntpd as root, so I intend to put the > > startup line in the /etc/ rc.local. > > If it's installed as a package then it will have a start-up script to > enable, as pointed to above. Look at the contents of the package with > `dpkg -l $packagename'. I think that your ntp-wait (see below) is a better approach anyway. > > I now understand a little more about the Kiss of Death packet that is > > being sent by the server. I have discovered that the server is > > comparing timestamps from the RTC and the system files and suppressing > > the transmission of a valid signal until they are consistent, but why > > they shouldn't be I'm not sure. > > Was https://afterthoughtsoftware.com/products/rasclock closely followed > on installation? Look at dmesg(1) output after booting and see if it > mentions clocks or time sources. Could the `fake-hwclock' they ship in > Raspbian be interfering? I revisited the config instructions at that link and discovered that I'd missed out a step ;-( That's the penalty of having the instructions on one screen and the file being edited on another in a room at other end of the house! I've fixed that now, but I need to leave time for the RTC to get it wrong again, in case there is still some error somewhere. > > Bad news this morning I'm afraid. I turned on the system to confirm > > yesterday's results and ran 'sudo ntpd -q' immediately after buttspi > > had booted, exactly as I did yesterday. The daemon reported its > > progress, exactly as before, but it exited without syncing. I tried a > > few more times with the same results. > > That could be the lack of -g mentioned above. I tried this several more times and then went back to the default method of launching ntpd. After approx 10 minutes the clocks synced. I'll investigate the discrepancy between the timezones on the two devices and see if that helps. > ntp-wait(1) might be of interest: "This can be useful at boot time, to > delay the boot sequence until after ntpd -g has set the time". That is definitely of interest. If all else fails, then this could ensure that the clocks are synced before we try to run our software. However, the man page isn't very helpful with respect to when to launch it and where from. Since there isn't much point in delaying the start of the system until NTP itself has started, then I'm assuming that I could put it into rc.local, except that this file has the following comment in it: # This script is executed at the end of each multiuser runlevel. If it waits until the end of the runlevel, is that too late? Presumably, as long as further processing is delayed before we launch our software from .bashrc, we should be OK. -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
Hi Terry, > I then did as Ralph originally suggested and stopped the NTP service > from running. (I wasn't sure how to do this, so I added and exit 0 to > the beginning of the script, which seemed to work OK. If there's a > better way, I'd be interested to hear it.) Where was this script? I forgotten upstart, but it probably still copes with scripts in /etc/init.d. If it's one of those, see update-rc.d(8). https://debian-handbook.info/browse/stable/unix-services.html#sect.system-boot > I then executed 'sudo ntpd -q' after logging into [buttspi]. I've put > the screenshot of the results at: > > http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png I notice date(1) says UTC on one machine, and GMT on the other. The `-q' could do with a `-g' if you expect the discrepancy to be large. The `KoD... inconsistent xmt/org/rec timestamps. Ignoring.' that last some minutes are because the incoming packets from the server don't have those three timestamps set to the xmt one that was sent out. I don't know why that would be. > As you can see, the sync is quicker, but it still took nearly 5 > minutes. I'm not sure why the daemon takes that long, but it may be > as good as it gets. Does anyone know? Not getting those `ignoring' messages will probably shorten that. > Final question; I can only start ntpd as root, so I intend to put the > startup line in the /etc/ rc.local. If it's installed as a package then it will have a start-up script to enable, as pointed to above. Look at the contents of the package with `dpkg -l $packagename'. > I now understand a little more about the Kiss of Death packet that is > being sent by the server. I have discovered that the server is > comparing timestamps from the RTC and the system files and suppressing > the transmission of a valid signal until they are consistent, but why > they shouldn't be I'm not sure. Was https://afterthoughtsoftware.com/products/rasclock closely followed on installation? Look at dmesg(1) output after booting and see if it mentions clocks or time sources. Could the `fake-hwclock' they ship in Raspbian be interfering? > Bad news this morning I'm afraid. I turned on the system to confirm > yesterday's results and ran 'sudo ntpd -q' immediately after buttspi > had booted, exactly as I did yesterday. The daemon reported its > progress, exactly as before, but it exited without syncing. I tried a > few more times with the same results. That could be the lack of -g mentioned above. > I then checked the time on sumppi and the RTC had lost nearly an hour > overnight. I can't understand this; the battery seems fine, it kept > good time on Tuesday night, although it kept bad time last night and > on Monday night. > > I'm going to put the RTC onto one of my Pis this afternoon and see if > it keeps good time on that. With the SD card so its the same hardware and software? I suspect the OS and distribution are fighting over the source of time at start up. ntp-wait(1) might be of interest: "This can be useful at boot time, to delay the boot sequence until after ntpd -g has set the time". Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Deleting old Firefox Certificates
Hi Clive, > Looking at my Firefox stored Certificates, I have a lot of > certificates with 'life=permanent' and old 'expiry dates' (going back > to 2014!). Under `about:preferences#advanced' then Certificates, I see headings Your Certificates People Servers Authorities Others Leave `Authorities' alone as I'd have thought that's what ships with Firefox or the system to validate other certificates at the top of the chain. Under `Servers', I see ones for server `*' that look like they are `Bogus' or `Explicitly Distrusted'. I'd leave those alone too. > Question is should I delete all these certificates with old expiry > dates, or will it affect sites which I visit? I'd just leave it all alone. Your browser is visiting many more sites with https than you realise to load a typical web page, and all their certificates will be stashed away. Cheers, Ralph. -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
[Dorset] Deleting old Firefox Certificates
Hi all Looking at my Firefox stored Certificates, I have a lot of certificates with 'life=permanent' and old 'expiry dates' (going back to 2014!). Some are generated from M$ and I assume are from when I bought the laptop (with Win7 on it). I no longer use M$, long live Linux :-). A lot of 'owners' I do not recognise but could be covering bank or other sites I have accounts with. Question is should I delete all these certificates with old expiry dates, or will it affect sites which I visit? -- *C A Wills* /Supporting Linux Mint & Open Source/ -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
Re: [Dorset] Setting up an NTP Server in a Closed Network
On Wednesday, 23 August 2017 19:42:02 BST Terry Coles wrote: > On Wednesday, 23 August 2017 18:10:45 BST Terry Coles wrote: > > I then executed 'sudo ntpd -q' after logging into buttspi. I've put the > > screenshot of the results at: > > > > http://hadrian-way.co.uk/Misc/Butts_Pi_Screenshot.png > > > > As you can see, the sync is quicker, but it still took nearly 5 minutes. > > I'm not sure why the daemon takes that long, but it may be as good as it > > gets. Does anyone know? Is it because it takes that long for the RTC and > > the System Clock on the server to home in on each other? Bad news this morning I'm afraid. I turned on the system to confirm yesterday's results and ran 'sudo ntpd -q' immediately after buttspi had booted, exactly as I did yesterday. The daemon reported its progress, exactly as before, but it exited without syncing. I tried a few more times with the same results. I then checked the time on sumppi and the RTC had lost nearly an hour overnight. I can't understand this; the battery seems fine, it kept good time on Tuesday night, although it kept bad time last night and on Monday night. I'm going to put the RTC onto one of my Pis this afternoon and see if it keeps good time on that. Does anyone have any ideas why the RTC should be so erratic? -- Terry Coles -- Next meeting: Bournemouth, Tuesday, 2017-09-05 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
