1

I configured an NTP server on a CentOS 7 machine (a virtual one) and also configured the ntp.conf file of the clients (which also are virtual and run CentOS 7). The NTP synchronization works perfectly when I explicitly start/restart the ntpd service with "systemctl (re)start ntpd" on the client machines. But when I try to test the "automatic" synchronization by changing the time on the server, the clients will neither be "notified" nor update their clocks (the clocks stay as they were synchronized during the last restart of ntpd). I even tried to change the polling frequency from the ntp.conf file of the clients, but nothing seemed to work. I would really appreciate some help.

PS: here are the ntp.conf files from the server and one client:

Server:

# For more information about this file, see the man pages
# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
restrict ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server 127.127.1.0

fudge 127.127.1.0 stratum 1

#broadcast 192.168.1.255 autokey    # broadcast server
#broadcastclient            # broadcast client
#broadcast 224.0.1.1 autokey        # multicast server
#multicastclient 224.0.1.1      # multicast client
#manycastserver 239.255.254.254     # manycast server
#manycastclient 239.255.254.254 autokey # manycast client

# Enable public key cryptography.
#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

# Enable writing of statistics records.
#statistics clockstats cryptostats loopstats peerstats

# Disable the monitoring facility to prevent amplification attacks using ntpdc
# monlist command when default restrict does not include the noquery flag. See
# CVE-2013-5211 for more details.
# Note: Monitoring will not be disabled with the limited restriction flag.
disable monitor

Client:

# For more information about this file, see the man pages
# ntp.conf(5), ntp_acc(5), ntp_auth(5), ntp_clock(5), ntp_misc(5), ntp_mon(5).

driftfile /var/lib/ntp/drift

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
restrict ::1

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server 192.168.1.38 #This is the ip address of the server

#broadcast 192.168.1.255 autokey    # broadcast server
#broadcastclient            # broadcast client
#broadcast 224.0.1.1 autokey        # multicast server
#multicastclient 224.0.1.1      # multicast client
#manycastserver 239.255.254.254     # manycast server
#manycastclient 239.255.254.254 autokey # manycast client

# Enable public key cryptography.
#crypto

includefile /etc/ntp/crypto/pw

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

# Enable writing of statistics records.
#statistics clockstats cryptostats loopstats peerstats

# Disable the monitoring facility to prevent amplification attacks using ntpdc
# monlist command when default restrict does not include the noquery flag. See
# CVE-2013-5211 for more details.
# Note: Monitoring will not be disabled with the limited restriction flag.
disable monitor
  • Have you checked that your ntpd actually remains running on the clients? IIRC, CentOS7 ships with both ntpd and chronyd, and the latter is the default. – Ulrich Schwarz Mar 5 '16 at 9:08
  • Hello Ulrich, thanks for your response. ntpd is efficiently running on the clients and concerning chrony, I've totally removed it from the clients... – Reda94 Mar 5 '16 at 9:44
  • If I recall correctly, ntp client uses 'adjtime' to set the clock... it tries to match the server gradually, one second at a time. That's why the typical usage for ntpdate is ntpdate -b. By how much are you changing the time for your test? – Otheus Mar 5 '16 at 22:23
  • You should also do some sanity-checking with ntpdc, to make sure the server reports the time you think it should be reporting. – Otheus Mar 5 '16 at 22:25
2

I think you also have to uncomment the restrict line on the server to make ntp available in that network. Then restart ntpd.

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

On the client side, you can also add iburst to the server configuration line, which should speed up the initial clock syncronization and restart ntpd.

server 192.168.1.38 iburst

With ntpq -p you can list the servers and if a connection was made.

2

A couple of notes to your configuration:

A general rule I use is:

  • don't put the ntp server on a virtual machine
  • don't trust the local clock on the ntp server.

You write you will use an isolated network (so the pool servers can't be contacted). You'll probably have to rely on the hardware clock. But try to get the ntp server out of the VM.

For the clients, on VMs I always have as first line in ntp.conf:

tinker panic 0

NTP then doesn't panic when there is a large time offset.

0

You are probably not syncing with the ntpd during (re)start, but by using ntpdate (you can check if /etc/sysconfig/ntpdate exists)

Additionally he clients probably have some trust in their own clock and won't make any sudden jumps. ntpd, if faced with sudden changes (i.e. ones that are noticeable for you) in a master clock, will assume the master is faulty and continue with its own time.

As you don't explain why you are doing this it is difficult to give advice apart from don't play around with ntp if you don't have to.

You should also double check that chronyd and/or systemd's timesyncd are not interfering with your experiments.

  • Hello Anthon and thanks for your response. I'm trying to configure NTP in a small cluster in orphan mode, i.e without an internet connection (the server is considered as the original clock, hence its ntp configuration file). Indeed I'm using ntpdate (I stop the ntpd service, then I type in "ntpdate 192.168.1.38" then I restart the ntpd service) instead of ntpd simply because I don't know how to use it... And concerning the trust of the client machines in their own clock, is there a way to overcome this ? – Reda94 Mar 5 '16 at 9:41
  • @Reda94 I don't know of the top of my head if you can remove the reliance on the local clock (and the internal clock). Although I did read Mill's Computer Network Time Synchronization (recommended), I can't say I understand most of NTP. It just can take long to synchronise. Have a look here here how long things can take with ntp, and make sure your not too impatient :-) – Anthon Mar 5 '16 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.