NTP - how to slack it best?
Hey all,
So I've embarked on my Slackware journey, and so far it's been a blast. I don't know what it is about Slackware that I like, but it just seems "right". Also I must say that so far the Slackware community seems really nice. :) I have though run into my first issue: NTP I've always used NTP on all my servers to keep time correct. I've never been fond of adjusting time using a cronjob once or twice a day - I like the NTP way better. I've installed the NTP package using slapt-get (wonderfull tool!) and I've setup my config file, but how do I go about starting NTP at boot? I've found some references on this forum, but most talk about creating a script and putting it in rc.d. Is that the correct way, or should I just start it from rc.local? Also from the Trustix NTP package I'm used to getting a time-slew message each time I start the daemon; this does not seem to happen with Slackware. How can I be sure the thing is even working? I hope some Slackware/NTP experts out there can point me in the right direction. Regards, Thomas |
Well, I'm not NTP expert, but I start it from rc.local and it works just fine. Just be sure in your config file, to point to pool servers and not to any specific time server. Using the pool servers is perfectly fine for personal use and spreads the load around.
|
I have this in /etc/rc.d/rc.local:
# Start the NTP daemonand this is /etc/rc.d/rc.ntpd (it must be executable): #!/bin/shNote the "/usr/sbin/ntpd -l /tmp/ntp.log" that logs activity to /tmp/ntp.log (or wherever you'd like); that's how you tell it's working (look at the log every so often). I also clean that log out with every start so it doesn't get huge. The servers I use (in /etc/ntp.conf) are: server 127.127.1.0 # local clockYou need the local clock server so that if your internet connection goes away ntp will continue to run against the local clock then re-sync to a server once the internet comes back. Hope this helps. |
Thank you both for the assistance. NTP is working like a charm now. :)
|
I use a similar approach as that posted by tronayne. However, for the sake of future visitors to this thread, such an approach will not succeed well with dialup users, as I currently am.
When the rc.ntpd script launches the NTP daemon, the NTP daemon expects to be online. This is not going to happen with typical dialup users. I therefore have modified my rc.ntpd script to use the ping command to check whether I am online before launching the NTP daemon. An unsuccessful ping and the script terminates without starting the NTP daemon. Should I one day find myself with a broadband connection, I need not modify my existing rc.ntpd script because the ping command will have succeeded and NTP will have direct online access to the time servers. An addition to configuring my rc.d scripts in such a manner, I use a script that I wrote from scratch that handles NTP on-the-fly after I dial up and make an online connection. |
Quote:
-Y1 |
Using the pool names is exactly what should be done unless you've contacted the administrators of the named servers and gotten their permission to get time from them.
There is no benefit to using specific servers over pool servers, unless you know you're really really close to one (like, you're at the university where it's hosted). The pool servers are not just some random machines that have had their clocks synched to someone's cheap digital wristwatch. Every single one of them is synched to a high-tiered server, and can be considered quite accurate. |
Quote:
If a person wants only to sync a single computer clock and is not serving other computers on a LAN and does not need to run the ntp daemon, then I believe ntpdate may be used with any of the listed lower-tiered public ntp servers. The ntpdate command is a one-shot sync as opposed to the continuous synchronizing performed by the ntp daemon. The ntp site has a list of such public servers. ntpdate also is useful for people with a non-continuous internet connection, such as dialup, where running the daemon is challenging. For people with minimal time sync needs and clocks that drift little, using ntpdate and a public server located nearby makes sense, although pool servers may be used too. Using both ntpdate along with the ntp daemon also makes sense if the computer clock drifts a lot. Using ntpdate to perform a one-time sync will ensure that the ntp daemon does not fail because of too large of a drift. If a person is going to use the ntp daemon to maintain the clock, then the pool servers should be used. This is configured in the /etc/ntp.conf file: server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org However, this configuration will tap into pool servers anywhere in the world, which might mean incorrect time syncs. According to the ntp pool web page, users should use a geographical prefix to obtain better time results: server 0.us.pool.ntp.org server 1.us.pool.ntp.org server 2.us.pool.ntp.org or server 0.mx.pool.ntp.org server 1.mx.pool.ntp.org server 2.mx.pool.ntp.org etc. If there are an insufficient number of country servers, which tends to reduce reliability, then the prefix should refer to the larger regional areas. Please let me know if I am incorrect. |
Quote:
One query, at boot only, is no big deal (and, oh, by the way, I did ask for permission to do so and did receive an OK from the site administrator some years back). At the time, the pool didn't exist and, when the pool first came on line, it didn't always work. Nowadays, well, it's pretty much always there (and I do have the pool servers in ntp.conf) and I suppose one could replace the government NTP servers with a pool server at start-up. Main thing is, one reliable hit to set the clock at start-up and that's all it takes. |
Quote:
I would bet if you asked the administrator today, you would probably get a different answer. |
Woodsman,
Would you mind posting your rc.ntpd script that includes the ping command? I like the idea of checking for connectivity before the NTP daemon starts. Thanks, Gary :) |
Quote:
|
I've come across a problem with the 10.2 NTP package: It doesn't work right. :)
In order for it to work as "intended", open ntp.conf and change the following line: restrict default noquery notrust nomodify to restrict default noquery nomodify And voila! everything works. :) I don't know why the ntp.conf file is setup like this, but then again, I am a complete Slackware beginner. Regards, Thomas |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 01:47 PM. |