I am using Debian-Testing and using ntpdate-debian for updating the time (ntpdate is taking a long time). I have following in /etc/rc.local file to open firewall otherwise ntpdate-debian does not work:
The first iptables-restore and ntpdate-debian commands work all right but the third command (iptables-restore blockall.rules) does not work. I check the status with 'sudo iptables-save' command after booting. How can I sort this problem? Thanks for your help.

"does not work" is really not much use. if you run the ntpdate command with the firewall in the appropriate state, what actually happens?

Why are you doing any of this in the first place? What are you not permitting ntp to known destinations all the time, and use ntpd?

I do not want to have a daemon running all the time. I want to synchronise time just once (at startup).

So I was initially using the command "{ntpd -qg; sudo hwclock -w}&;" in /etc/rc.local, but I noticed that it takes a long time to work when entered this command from commandline.

Then I noticed this "ntpdate" package in debian-testing repo. The command "sudo ntpdate" gives the error: "no servers can be used, exiting".

The command "sudo ntpdate-debian" works all right but needs some port to be unblocked. So I have to enter command to open the iptables temporarily. Otherwise it reports "sendto(ns02.hns.net.in): Operation not permitted" for all URLs.

You should specify a NTP server while running the command 'sudo ntpdate' like

sudo ntpdate -u <some time server>

The UDP port 123 should be open on the firewall.

ntpd uses absolutely minimal amounts of resources, and when running healthily won't even check once a day. There's no good reason for not running it. But either way, ntpdate and ntpd both use /etc/ntp.conf so, you'll need to configure it.

you shouldn't be using sudo in an rc.local file either as it's already root.

Does /etc/rc.local get executed before iptables package start the firewall? Is the iptables firewall state restored after reboot automatically and does it occur before /etc/rc.local execution? Do I really need to run a command to open iptables firewall at this stage?

rc.local would be the VERY last thing executed automatically by the init process. you should update the rulebase to permanently allow outbound connections to 123/UDP and forget about messing with iptables just to set the clock.

Hi,
Why not setup a script for cron;I set mine to '/etc/cron.hourly' so I get my clock set. You could set a time for cron to run once a day or use 'cron.daily' or however your Gnu/Linux is configured for 'cron'. You can just create a 'cron' job to task at whatever setting(s) you wish. Please be sure to use a 'pool'. Of course you should setup the firewall if you have blocked. But why block in the first place? I agree with 'acid_kewpie'. Setup your connection.

HTH!

Thanks to all you experts for helping me on this.

Hi,

Your Welcome!

Please provide feedback for the thread on what you decide to do so other members can be helped by the solution(s).

You're ;-)

I realized that the command "{ntpd -qg; hwclock -w}&;" in /etc/rc.local keeps the time correct on my computer, though this command does not work later on because of the firewall! I think that firewall is not active when rc.local gets executed.

UDP/123 should not be blocked.

I need to update the time only once- at startup. Any particular reason I should keep UDP/123 open all the time?

According to this site (http://www.speedguide.net/port.php?port=123), it may also pose security threat.

because that's good time management. Good sysadmin practise has all machines running ntpd. It is not a risk when ntpd is well configured.

ntpd does not periodically set the time, it tracks the reliability of the local system clock and uses multiple remote servers (Whereas ntpdate will only use one single server once) to understand how quickly the time is drifting off and make adjust the clock speed to keep it constantly correct.