- Managing Linux Users and Groups
- Managing File Ownership and Permissions
- Lab Exercise 3.1: Managing Linux Security
- Managing the Linux Networking Configuration
- Managing Linux Applications and Services
- Lab Exercise 3.2: Installing Linux Products and Managing Processes
- Implementing and Configuring NTP
- Lab Exercise 3.3: Implementing NTP
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing and Configuring NTP
Before ending this chapter, we need to discuss one more topic—time synchronization. Before implementing Novell Nterprise Linux Services, it is critical that you configure all the servers that will be installed into the same eDirectory tree to synchronize their internal clocks.
Why Time Must Be Synchronized
Many new eDirectory administrators fail to understand the absolute importance of time synchronization in their network. With many other network operating systems, having your server clocks in sync is nice, but not really necessary.
With eDirectory, however, it is absolutely critical. The reason for this is the nature of the eDirectory database itself. eDirectory is a distributed database. It can be configured to reside on a single server in your network (a very bad idea) or it can be configured to reside on multiple servers in the network.
eDirectory implements two concepts: partitioning and replication. Partitioning allows you to divide the database into logical chunks. This can be very useful if you have a large, geographically dispersed organization.
For example, suppose your organization has offices in Salt Lake City, Santaquin, and Idaho Falls. In your eDirectory tree, you may have containers for each location. You can create a partition for each container and for the root of the tree, as shown in Figure 3.34.
)
Figure
3.34 Partitioning the eDirectory tree.
By partitioning the tree, you have created three logical divisions in your eDirectory database. One of the key features of eDirectory is the fact that you can create multiple copies (called replicas) of each partition and store them on multiple servers in the tree.
In the example in Figure 3.34, the Salt Lake City server could hold replicas of the tree root partition, the SLC partition, the SAN partition, and the IDA partition. The other servers can also hold replicas of all the partitions.
Information in all the replicas is synchronized at regular intervals. eDirectory ensures that all the data in all the replicas remains consistent.
If a disaster were to happen and a server were to go down, the eDirectory tree would continue to function normally because the loss of the server would be detected and a replica stored on a different server would be promoted and used to replace the information lost.
This high degree of fault tolerance is one of the key value propositions behind eDirectory. However, this database design is highly dependent on each server being set to the same date and time.
eDirectory uses time stamps to keep track of operations. For example, in Figure 3.34, suppose an administrator in Santaquin changes a user's password. Then, an hour later, an administrator in Idaho Falls changes the same user's password again. If time is synchronized on all the servers, there is no problem. The sequence of events is preserved and implemented.
If time is not synchronized, however, continuity in the database can be lost. eDirectory may lose track of which operation occurred first and which occurred second.
TIP
If eDirectory detects operations in the database that have time stamps ahead of the current time, it tries to keep data consistent by issuing what is called synthetic time.
It is very important that you keep the system clocks on all your servers synchronized. In the "old days" when eDirectory (back then it was called NDS) ran only on NetWare, time synchronization was relatively easy. NetWare implemented the Timesync protocol, which automatically detected whether the server was the first server installed in the tree or if it was a later server.
If your server were the first server in the tree, it would be automatically configured as a Single Reference time provider. Subsequent servers were automatically configured as Secondary time consumers. The Secondary servers would query the Single Reference server and adjust their date and time to match it.
Today, you have to do a little more work to synchronize time when you are working with servers that use operating systems other than NetWare. eDirectory now runs on a variety of platforms. The Timesync protocol only runs on NetWare. To synchronize time between NetWare, Linux, and Windows servers, you have to use a time-synchronization protocol that can be run on all three.
In this book we will use the Network Time Protocol (NTP) to synchronize time. NTP is an Open Source product that can synchronize time on a variety of platforms. You can learn more about NTP at http://www.ntp.org.
Before configuring NTP, you need to plan your NTP deployment. You need to determine which servers will provide time and which servers consume time.
One of the very useful features of NTP is the fact that you can use it to synchronize time with time providers over the Internet. There are many publicly accessible NTP time providers on the Internet that get their time directly from the United States Navy atomic clock.
TIP
A list of NTP time servers you can use is available at http://www.eecis.udel.edu/~mills/ntp/servers.html.
A commonly used NTP time-synchronization strategy is depicted in Figure 3.35.
)
Figure
3.35 A commonly used NTP time-synchronization strategy.
In this configuration, one server in the organization is used to get its time from an NTP time provider on the Internet. This is the Organizational Time Provider. Other servers in the organization are then configured to get their time from the Organizational Time Provider.
TIP
The NTP service can be both a time provider and a time consumer at the same time. In Figure 3.35, the Organizational Time Provider fills both of these roles simultaneously.
There are, of course, many other ways to configure your NTP strategy. Some organizations configure all their servers to get their time directly from a public NTP time provider on the Internet. Others aren't concerned with synchronizing with a time provider on the Internet. Instead, they designate one server in the organization as an NTP time provider and configure their other servers to get their time from it.
Very large organizations may implement a hierarchy of time providers. This is possible because NTP uses the concept of strata. A detailed discussion of NTP is beyond the scope of this book. If you would like to learn more about NTP, check out the Time Precision HOWTO document available at http://www.tldp.org/HOWTO/TimePrecision-HOWTO/index.html.
For our purposes, we simply need to ensure that each server in our network that will be installed into the eDirectory tree is configured to synchronize time with the other servers.
On a Linux server, this is done with the xntpd daemon. When you installed your SUSE Linux server, the xntp package should have been installed by default, as shown in Figure 3.36.
)
Figure
3.36 Installing the xntp package.
If this package wasn't installed for some reason, you should install it using the steps we covered in the previous section in this chapter.
CAUTION
If you are going to use NTP to synchronize time among Linux servers, you can use version 4.x of the NTP daemon. However, this version is not compatible with the NTP service on a NetWare server. If you need to synchronize your Linux server with a NetWare server, you need to uninstall the 4.x version and then download and install version 3.x of the NTP daemon on your Linux server.
Once the package is installed, you need to configure the service and start it. The NTP daemon is configured using the ntp.conf file located in /etc, shown in Figure 3.37.
)
Figure
3.37 Configuring the xntpd daemon with the ntp.conf file.
Notice that the first entry in the file is a parameter that reads server 127.127.1.0. This parameter provides a fallback strategy. If the xntpd daemon can't contact the NTP time provider it has been configured to use, it will query the system BIOS clock to get its time. This parameter is added to your ntp.conf file by default.
To configure the xntpd daemon to get time from an NTP time provider, enter the following parameter in the ntp.conf file:
For example, if you wanted your server to get its time from a time provider with an IP address of 10.0.0.1, you would enter server 10.0.0.1.
Once this is done, you should save the changes to your ntp.conf file and exit your text editor.
Now, before you start your xntpd daemon, there are a few steps you need to complete. The NTP protocol is a little bit fussy. If the time on your server is more than 17 minutes out of synchronization with the time on the NTP time provider, the NTP protocol considers the time source "insane" and will refuse to synchronize.
Therefore, you need to set your system time as closely as possible to the time provider's time before you start the xntpd daemon. This involves three steps:
Configure your server's time zone by entering tzselect at a shell prompt. Follow the time zone wizard prompts to set your time zone, as shown in Figure 3.38.
Manually set your server's system time using the date command. The date command expects you to provide the current date and time in the format mmddhhmmyyyy. For example, if the current date and time is August 30, 2004, 8:30 p.m., you would enter date 083020302004. Note that the hour is specified using the 24-hour clock.
Perform a one-time synchronization with the NTP time provider by entering ntpdate time_provider_IP_address. For example, if your time provider's IP address is 10.0.0.1, you would enter ntpdate 10.0.0.1. You may have to run this command several times. As a general rule of thumb, you should rerun the command until the offset reported by this command is less than 1 second.
)
Figure
3.38 Setting your server's time zone.
NOTE
If the xntpd daemon is running, you can't run the ntpdate command.
At this point, your server's clock should be in sync with your time provider's clock. However, if you leave it in this state, the time on your server will quickly drift away from the time on the time provider.
To keep this from happening, edit your ntp.conf file as discussed earlier and add a server entry for your time provider. Once this is done, start the xntpd service on your server by entering /etc/init.d/xntpd start at a shell prompt.
By default, the xntpd service is not configured to automatically start. You need to make sure the xntpd service is started every time the server is booted by entering chkconfig xntpd 35 at a shell prompt.
Once the xntpd daemon is running, you can use the ntpq command to see the time providers it is configured to use. Open a terminal session and enter ntpq –p.