Bounty - Date/Time/NTP module for trixbox front-end
I would like to put in $50 towards the Date/Time/NTP module for the trixbox frontend. I have the hardest time configuring the time and date in Linux and I end up having to use Webmin everytime for it....
Please post here if you want to also contribute towards this bounty or if you are going to take up the challenge and get it working. :)
Undrhil
It's great that you're offering a bounty, but you can do "rdate -s time-b.nist.gov" from a command line and sync your time pretty easily.
You can put the following lines into a file, change the permissions on it and call it from cron once a day and your clock shouldn't drift too much.
#!/bin/sh
TIMESERVER="time-b.nist.gov"
rdate -s $TIMESERVER
hwclock --systohc
As long as you set your timezone correctly during the install that will work.
I can give more explicit instructions for doing that, if necessary.
Yes, and I can also run yum -y update from the command line, so what's the point of the package manager in trixbox? It's all about ease of use and consolidation. If I am sitting at the main trixbox screen and realise the time isn't right, why should I go run a terminal to log in when I can just open the time/date module and click "Refresh" or whatever? Time is money, as the saying goes .. and anything which can be done to save time is welcome.
Now, I do understand what you are saying about this being easy to configure, but I wonder if they could roll this out as part of the install for the system. It sets up the time zone and everything already. Why not have the main install create this file and add a cron job for it to run at midnight or something. That would be possible, wouldn't it? Then, there would be no need for the module.
Anyone think that this auto-update script is a good idea?
so what's the point of the package manager in trixbox?
I've often wondered that myself. :) (Sycophants: relax, it's a joke.) It takes me much less time to do anything in the shell than it takes for the trixbox admin page to even load. But that's me.
I don't think the module is a bad idea, I was just giving you (or anyone searching) an alternate option to achieve your goal in the meantime.
It sets up the time zone and everything already. Why not have the main install create this file and add a cron job for it to run at midnight or something. That would be possible, wouldn't it?
They're using whatever's built into the CentOS text mode installer to install. I don't think they have the resources to customize the installer to that degree, so, unless CentOS (Red Hat, actually) includes this in the text mode installer then we have to settle for doing it by hand or with a (yet to be created) trixbox module.
An NTP daemon that continuously keeps the time in sync in the background is a much better option.
When you run a cron job once a day (or even more often) you will have sudden jumps in time (even if only a second or two), which is absolutely NOT what you want on an Asterisk system!! It can cause unexpected behaviour and of course, things like CDRs, billing etc. are affected by it as well.
So, better do this right and use a daemon that continuously compensates for clock drift.
BTW, I don't know if there is something like this in Trixbox already.
Maybe Andrew or Kerry can post here to let us know?
Configuration from the dashboard is of course a good idea.
You're right, I wasn't really thinking and I gave bad advice -- good call.
This did get me looking, though, and I never did before. It looks like ntpd is installed and enabled by default in trixbox 2.4, at least. As long as you set your time in your system bios to something within a few minutes of the "real" time before install, and set your time zone correctly it should synchronize with the Internet.
It uses the ntp pool servers by default, and if it can't reach them it uses the local clock.
If you don't set your system bios first, you can still fix it by doing:
service ntpd stop
ntpdate -u 0.pool.ntp.org
service ntpd start
then, to seal the deal, after it synchronizes do:
hwclock --systohc
to set your bios.
You know it's synchronized when you can type:
ntpq -p
and you get a display like:
remote refid st t when poll reach delay offset jitter
==============================================================================
+mainframe.cynac 216.218.254.202 2 u 459 1024 377 34.273 -1.807 0.017
*clock.trit.net 192.12.19.20 2 u 573 1024 377 71.511 -5.573 5.321
+lashiir.sapros. 74.53.198.146 3 u 532 1024 377 35.145 18.751 3.464
LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000 0.008The line with an asterisk in front of it ("*") means ntpd is doing its job.
Edit: to be clear, it can take a few minutes (up to half an hour or so, sometimes) for it to synch, so be patient.
This has been my preferred method for years in a Linux environment. Very simply, non-bulky.
I just create a file in /etc/cron.weekly
pico /etc/cron.weekly/update_time
#!/bin/sh
TIMESERVER="time-b.nist.gov"
rdate -s $TIMESERVER > dev/null 2>&1
hwclock --systohc > dev/null 2>&1
Save the file and then give it permission... chmod 755 /etc/crons.weekly/update_time
elle.fallingsno 216.218.254.202 2 u 89 256 377 105.309 -35764. 13572.0
clock3.redhat.c .CDMA. 1 u 89 256 377 96.141 -15959. 15302.2
lashiir.sapros. 74.53.198.146 3 u 143 256 377 75.339 -29511. 10899.0
*LOCAL(0) .LOCL. 10 l 22 64 377 0.000 0.000 0.001
by the way, that is what i get when i type ntpq -p if that helps.
It can take quite a while before the clocks sync, depending on the specific random servers you get and the traffic and all sorts of things. Wait at least 15 minutes. I forgot how long the docs said to wait, but I remember thinking it was unreasonable. :)
That being said, your jitter and offset are awfully high there, make sure you're not skipping the:
ntpdate -u 0.pool.ntp.org
step. You'll have to stop ntpd first (service ntpd stop) then run that command (more than once wouldn't hurt) then restart ntpd (service ntpd start.)
HTH

Member Since:
2006-06-25