Comment 25 for bug 90267

I would not use those steps. The 2 other solutions I remember from the comp.protocols.time.ntp archive which allow you to run ntp with a dynamic ip are

1. Use /etc/ppp/if-up.local to restart ntp each time ppp0 got a new ip. Does lose many hours of history but still keeps ntp working and the machine can also be used to serve time to other computers on the network. Small price to pay. Lose many hours history but keep a working ntp or have ntp stop working when ppp0 got a new ip was not a hard decision to make.

2. Have another machine on the network running 24x7 acting as a ntp server. The downside is yet another computer running all the time.

For a couple of years I went with option 1. It worked and gave me a ntp server for everything else. Option 2 happened when I decided to make my own stratum 1. The interface scanning in the newer ntp solve the problem created by option 1.

Ntpdate and ntpd -qg do the same thing. Just do it slightly differently. May as well pick one and and stick with it. One thing about using ntpd -g is it will step if the offset is > 128ms so you can get away with not using ntpdate at all.

To get ntp 4.2.2 to do a normal wild card bind you get to modify ntpd/ntp_io.c and rebuild the package. The rescanning bit is in a more recent version of ntp than what ubuntu uses.