Running CentOS 3.4, I enabled the ntpd service and noticed that it opens up a hole in the firewall for ntp from 127.127.1.0. I look in the ntpd initscript and see that it's reading in servers from /etc/ntp/step-tickers. However, that file is empty... /etc/ntp/ntpservers contains clock.redhat.com and clock2.redhat.com, but ntpservers isn't used *anywhere*.
This looks like a bug, but maybe I'm overlooking something stupid. I reviewed the RHEL manuals, but they only reference the GUI utilities now (grrr).
Any ideas a) where 127.127.1.0 is coming from (parsing bug?), or b) why the initscript doesn't reference /etc/ntp/ntpservers?
Thanks,
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Jason Dixon wrote:
Any ideas a) where 127.127.1.0 is coming from (parsing bug?), or b) why the initscript doesn't reference /etc/ntp/ntpservers?
a) It's in the main config file, /etc/ntp.conf :
server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10
b) Because they're not a part of ntp, but a part of system-config-date
$ rpm -qf /etc/ntp/ntpservers system-config-date-1.7.15-0.RHEL4.1
-te
On Apr 19, 2005, at 12:22 PM, Troy Engel wrote:
Jason Dixon wrote:
Any ideas a) where 127.127.1.0 is coming from (parsing bug?), or b) why the initscript doesn't reference /etc/ntp/ntpservers?
a) It's in the main config file, /etc/ntp.conf :
server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10
Thanks for clarifying that.
b) Because they're not a part of ntp, but a part of system-config-date
$ rpm -qf /etc/ntp/ntpservers system-config-date-1.7.15-0.RHEL4.1
Not on CentOS 3.4:
[root@polaris root]# rpm -qf /etc/ntp/ntpservers redhat-config-date-1.5.22-3
Thanks,
-- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Jason Dixon wrote:
b) Because they're not a part of ntp, but a part of system-config-date
[root@polaris root]# rpm -qf /etc/ntp/ntpservers redhat-config-date-1.5.22-3
My bad on that - I used a CentOS4 machine by accident. The name may have changed slighty but the meaning/point is the same - that file is for use but the random redhat config tools, not by ntpd itself.
Specify your upstream servers in /etc/ntp.conf like so:
# http://twiki.ntp.org/bin/view/Servers/NTPPoolServers server us.pool.ntp.org server us.pool.ntp.org server us.pool.ntp.org
# backups just in case server ntp.ucsd.edu # (San Diego, CA) server ntp1.maincoon.com # (Quincy, CA)
Then comment out those silly 127.127.* lines that are in there by default. This is for your master server; then simply point all your clients at this new master, and everything will be kosher.
-te
On Apr 19, 2005, at 12:38 PM, Troy Engel wrote:
Then comment out those silly 127.127.* lines that are in there by default. This is for your master server; then simply point all your clients at this new master, and everything will be kosher.
the 127.127.1.0 lines are not silly - they enable your master server to remain in operation if it loses its connection to its upstream timeservers, under the assumption that the machine's own hardware clock is moderately reliable. fix their configuration, but leave them in - they're a good thing when configured properly (i.e. not the way Red Hat's GUI tools set them up).
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
Steve Huff wrote:
the 127.127.1.0 lines are not silly - they enable your master server to remain in operation if it loses its connection to its upstream timeservers, under the assumption that the machine's own hardware clock is moderately reliable. fix their configuration, but leave them in - they're a good thing when configured properly (i.e. not the way Red Hat's GUI tools set them up).
That's an important disctinction - that the machine's hardware clock is moderately reliable. I have usually found them to be unreliable, and as such wish my master to stop serving time sync's to all the clients when it loses it's upstream connection. So, in my opinion/scenario/belief, they should be commented out. :)
-te
On Tue, 2005-04-19 at 12:30 -0400, Jason Dixon wrote:
On Apr 19, 2005, at 12:22 PM, Troy Engel wrote:
Jason Dixon wrote:
Any ideas a) where 127.127.1.0 is coming from (parsing bug?), or b) why the initscript doesn't reference /etc/ntp/ntpservers?
a) It's in the main config file, /etc/ntp.conf :
server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10
Thanks for clarifying that.
b) Because they're not a part of ntp, but a part of system-config-date
$ rpm -qf /etc/ntp/ntpservers system-config-date-1.7.15-0.RHEL4.1
Not on CentOS 3.4:
[root@polaris root]# rpm -qf /etc/ntp/ntpservers redhat-config-date-1.5.22-3
On EL3 the name was redhat-config-date ... it is system-config-date in EL4. If you have GUI insalled, right click on the clock and pick the "Adjust Date & Time" option and click the "Network Time Protocol" tab...enable NTP and add your server(s) to the box.
If you don't have GUI, Just add the name (or IP) of the server you want to use in /etc/ntp.conf like this:
server clock1.redhat.com
then restart ntpd like this:
/etc/init.d/ntpd restart
On Tue, 2005-04-19 at 17:34, Jason Dixon wrote:
Running CentOS 3.4, I enabled the ntpd service and noticed that it opens up a hole in the firewall for ntp from 127.127.1.0. I look in the ntpd initscript and see that it's reading in servers from /etc/ntp/step-tickers. However, that file is empty... /etc/ntp/ntpservers contains clock.redhat.com and clock2.redhat.com, but ntpservers isn't used *anywhere*.
This looks like a bug, but maybe I'm overlooking something stupid. I reviewed the RHEL manuals, but they only reference the GUI utilities now (grrr).
Any ideas a) where 127.127.1.0 is coming from (parsing bug?), or b) why the initscript doesn't reference /etc/ntp/ntpservers?
check /etc/ntp.conf, that's the default config file for the ntp daemon.
There you'll find "127.127.0.1" being the local ip for the local clock of your system. It's used as fallback timeserver if you don't provide a regular one in /etc/ntp.conf. Add your favorite timeserver(s) in the section:
# --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. # restrict mytrustedtimeserverip mask 255.255.255.255 nomodify \ notrap noquery # server mytrustedtimeserverip
if you're using a hostname instead of ip, remove "mask 255.255.255.255" or ntpd will not start (at least the last time I checked...)
If you configured the default redhat firewall the initscript /etc/init.d/ntpd will open the ntp port for all servers configured in /etc/ntp.conf (local clock and remote servers)
/etc/ntp/step-tickers is used to compensate an offset of more than the default sanity limit of 1000s when starting ntpd by setting the time hard once. Put the ip or hostname of your favorite timeserver(s) in the file, one per line and the initscript will set the time to the one from the server regardless which offset your system time has when starting. If your time offset is more than 1000s to your configured ntpservers in /etc/ntp.conf and you don't set any step-tickers, start of ntpd will fail.
as a side note: if you use Red Hat's GUI tools to set up time synchronization, they do it wrong. here are some excerpts from /etc/ntp.conf on a 3.4 system (and the problem persists in 4):
--- begin paste ---
# Prohibit general access to this service. restrict default ignore restrict www.xxx.yyy.zzz mask 255.255.255.255 nomodify notrap noquery
...
# --- OUR TIMESERVERS ----- # or remove the default restrict line # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system.
# restrict mytrustedtimeserverip mask 255.255.255.255 nomodify notrap noquery # server mytrustedtimeserverip
...
# --- GENERAL CONFIGURATION --- # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server www.xxx.yyy.zzz fudge 127.127.1.0 stratum 10
--- end paste ---
(the ip address of our timeserver has been replaced by www.xxx.yyy.zzz)
first off, the Undisciplined Local Clock configuration is wrong - it should be 127.127.1.0, which is the instruction that tells ntp to fail over to the local machine's hardware clock (set down at stratum 10 so that it'll only be used if the machine can't reach any of the real timeservers). Red Hat has broken this functionality, for no good reason that i can tell; with their config, ntp stops working if the machine can't get to its timeservers.
second, in the first section is the wrong place to put the security restrict line for the timeserver. it should be down in the second section, "OUR TIMESERVERS" (replace mytrustedserverip with the ip address of the time server, and repeat that pair of lines for each timeserver).
i continue to be mystified by Red Hat's behavior in this case; it seems like it would have taken just as much effort to get it right as to get it wrong. hmm.
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
-
Jason Dixon -
Jens Grigel -
Johnny Hughes -
Steve Huff -
Troy Engel