TURNKEYGNU / LINUX
English

Forum archive

Maddening time server/tklbam issue

Supporttklbamntp

So I've been eager to try tklbam for the past few years but have been unable to get it to work on our network.

I get the meesage:

> tklbam-backup
##########################
## FIXCLOCK HOOK FAILED ##
##########################

Amazon S3 and Duplicity need a UTC synchronized clock so we invoked the
following command::

ntpdate -u pool.ntp.org

Unfortunately, something went wrong...

3 Dec 16:12:59 ntpdate[4120]: no server suitable for synchronization found
_____________________________________________________________________________________

It appears that the problem has to do with my office's access control list (firewall). Port 123 is open but I think the problem seems to stem from the fact that the request goes out to a "pool" of IP addresses and I can't predect where it's coming back from.... Possibly?

Does anyone know how I would open an ACL for this to work? Opening UDP port 123 is not fixing the problem.

Replies (3)

You can change the hook to sync with a specific NTP server

Reply 1
Duplicity relies on accurate time so syncing the clock is required. The hook that syncs time is in /etc/tklbam/hooks.d/fixclock.

I committed a fix to the hook error message so that it explains how to change pool.ntp.org to something else (e.g., the IP of a specific NTP server):

You can change the NTP server like this:

    export NTPSERVER=my.ntp-server.net
    tklbam-backup
PS: sorry for the ridiculously late reply. This message fell between the cracks and I only came across it while searching for messages about TKLBAM hooks.

Change /etc/tklbam/hooks.d/fixclock

Reply 2

Here's what I ended up doing

nano /etc/tklbam/hooks.d/fixclock

Change this line from this

command = "ntpdate -u " + NTPSERVER

To this (see details here)

command = "ntpdate-debian"

Then run

tklbam-restore [backupid]

I found that worked.

Hope that helps

Sorry about slow response...

Reply 3
Actually TBH I thought that I posted a response to this thread early last week?! Obviously not... :(

Anyway, can you contact the NTP server? Is the time configured as either UTC, or UTC, but then with the locale offset? FWIW unlike Windows, TurnKey (and most Linux) have the clock set at UTC (and ideally the bios time set to UTC too). The real time where you are is then calculated using a locale. (reconfigure that using "dpkg-reconfigure tz-data").

Often on a server, I leave the system as UTC (I also set the BIOS clock to UTC if running on hardware). However, if you weren't aware of this config idiosyncrasy, you may change the clock to be your local time (but the server still thinks it's UTC). I'm not sure, but I recall from my Windows days, that if the local time and the remote NTP server time were too far out of whack, that it would not adjust the time, unless you explicitly forced it to. Maybe something similar is happening here?

So bottom line is that I'd be inclined to see what is going on with NTP. Make sure that your server is connecting to the remote NTP server ok and check that it is adjusting the time as it should be.

If you can ensure those factors but continue to have issues, then I'm not sure what it could be. Is your internet particularly slow? Perhaps there is too much latency between your server and the remote storage? ALthough TBH I doubt that would be it...