Configuring ntpd with CFEngine

Installation | pool.ntp.org Configuration | Three Tier Infrastructure | Testing | Timezone

Modern systems must syncronize their clocks, to avoid problems with time sensitive software (such as Kerberos), and to allow log correlation. This page outlines how to configure Network Time Protocol (NTP) software using CFEngine version 2.

Installation

Either install the same ntpd version on all systems (via a software depot), or ensure the configuration works for each different supported platform (e.g. the default ntpd software on Mac OS X, the ntpd package on RedHat Linux, or OpenNTPD on other systems). Different versions of ntpd may require different configuration, though standardizing on driftfile and other details will reduce the complexity of the ntp.conf configuration.

ntpd could also be included in a base system image, or required in a KickStart configuration file.

pool.ntp.org Configuration

Clients with Internet connectivity can use the public pool.ntp.org time servers. Firewalls must allow User Datagram Protocol (UDP) 123 traffic to (and back from) the public time servers.

CFEngine configuration should be spread into different files, and import used to include relevant configuration. This example assumes a master cfagent.conf contains includes for CFEngine Classes in cf.classes, and a cf.applications that in turn includes cf.app_ntp for ntpd configuration. A global cf.site should also include an AddInstallable statement with a restart_ntp class.

The configuration files should be stored under version control.

Three Tier Infrastructure

Larger sites may not allow NTP traffic from client systems to the Internet. Instead, clients must syncronize against at least three internal time servers. The internal servers peer with one another, and syncronize against another layer of time servers. The top level time servers syncronize with hardware clocks (such as Global Positioning System (GPS) receivers) and stratum 1 time servers on the Internet.

Larger sites could also use Anycast to route NTP traffic.

Firewall Rules

Internal clients need UDP 123 access to and back from the role_ntp_server_private systems. Some firewalls, such as Packet Filter (PF), can keep state on NTP traffic, and does not need to allow new connections from the servers back to the clients:

pass out on $if_public proto udp to any port ntp keep state
block in on $if_public proto udp to any port ntp

The role_ntp_server_private systems require UDP 123 access between one another, and to (and from) the role_ntp_server_public servers. The role_ntp_server_public servers will need Internet access to any stratum 1 time servers syncronized with. Consider adding the role_ntp_server_public servers to the pool.ntp.org time servers.

Any monitoring systems will need UDP 123 access to (and back from) the various time servers being monitored.

Configuration

Testing

Use monitoring software to track the time drift; checks should warn if a time server drifts out of line, or if a client cannot reach a server. Monitoring software such as Nagios should have plugins available to check NTP. If testing ntpd in a development environment before moving it to production, be sure to:

  1. Confirm whether localhost can query ntpd, and that the time servers are reachable by the client.
  2. $ ntpq -p
    remote refid st t when poll reach delay offset jitter
    ============================================================================
    +192.0.2.121 192.0.2.123 3 u 29 64 377 0.321 0.169 0.101
    +192.0.2.122 192.0.2.123 3 u 44 64 377 0.278 -0.801 0.120
    *192.0.2.124 192.0.2.123 3 u 34 64 377 0.217 -0.582 0.109
    LOCAL(0) LOCAL(0) 10 l 35 64 377 0.000 0.000 0.001

  3. Confirm the monitoring hosts (if any) can query ntpd.
  4. $ ntpq -p client.dev.example.org
    ?

If the system time has drifted too far, ntpd will not be able to correct the problem. In this case, run ntpdate to correct the time to a ?close enough? value. Look for *LOCAL(0) in the output of ntpq to detect when the local fudge clock is being used instead of the servers.

Timezone

If possible, set all systems to UTC. This facilitates growth or mergers that lead to data centers in different time zones. Users should set a local TZ environment setting to display in the local format, if desired. However, users with custom TZ settings must then use sudo -H ? or otherwise ensure that their custom timezone does not pollute the system, for example when restarting software as root.