| Setting time the right way, the Linux way |
Oct. 03, 2007
"Does anyone really know what time it is? Does anyone really care?" It's a fine song lyric for Chicago, but when it comes to computers, the answer is, "Yes, we really care. We, really, really care that our all are computers' servers logs, e-mail date and time stamps, and our backups agree on the date and time."
How do you do that, though? The usual answer on SOHO (Small Office/Home Office) networks is to have each PC call in over the Internet to a NTP (Network Time Protocol) server. That's fine, but it does waste a few bits of network bandwidth and with any modern Linux you can set up your own personal NTP server for your PCs.
Since I typically have two-dozen computers running in my home office, I decided that it was high time to coordinate my system's clocks with my own NTP server. Before I get into the details of how I did it, let's take a brief look at how Linux PCs keep time and how the master NTP servers work.
Linux Standard Time
Most Linux systems keep time with two clocks. The hardware clock, a.k.a. the "CMOS (complementary metal oxide semiconductor) clock," is present in most x86-based systems. The CMOS, a battery-backed time clock located on the motherboard, runs all the time. It also tends to lose time as the computer ages and the battery slowly dies. The other clock, the system clock, is a software clock and it starts when you boot up your system. It's this clock that's used by most internal Linux programs and Linux applications.
By default, the system clock takes its time from the CMOS clock. A far better way to set the system clock is to get the time from an NTS (network time server). This is typically done by the program ntpd (Network Time Protocol Daemon). This program uses ntpd's protocol, NTP to get the right time from an NTS.
Some older Linux and Unix systems required you to use a program called ntpdate to actually set the time manually. Now, that functionality is included in the ntpd package.
The system clock, no matter how you update it, doesn't keep time the way you do. For Linux and Unix, the universe began at midnight UTC (a.k.a. Coordinated Universal Time, formerly Greenwich Meridian Time), or 12:00 a.m. on Jan. 1, 1970. The system clock tells time by counting the number of seconds since the Linux "universe" began. This method of telling time is referred to as the Unix Epoch.
If you want to know what time it is in Linux time, you can find it by running the command:
date +%s
from a shell terminal.
Since most computers store the Epoch's number of seconds as a 32-bit signed integer, the "End of Time" will come at 03:14:07 UTC on Tuesday, Jan. 19, 2038. Since we're quickly moving to 64-bit computing, that won't be a real problem. The "End of Time" using a signed 64-bit integer will come sometime on Sunday, Dec. 4 in the year 292,277,026,596. With more than 290 billion years to go, I'm not going to sweat it.
Believe it or not, we are already beginning to run into Epoch timing problems. For example, come January 19, 2008, you may get some interesting results from a 30-year mortgage calculator running on an older Linux or Unix system.
You also may have noticed in this discussion on how Linux tells time that I haven't said a thing about DST (Daylight Savings Time) or of time zones. That's because Linux doesn't track those with its time programs. Instead, Linux stores its time zone and DST information in a specific file, /usr/share/zoneinfo. Older Linux systems may store the information in the file, /usr/lib/zoneinfo. The local time zone and DST are both usually determined by a symbolic link to /etc/localtime.
Since DST is set by local political fiat, and has nothing to do with reality, you will sometimes need to reset your DST settings. That happened earlier this year in the United States and required network and systems administrators to get their systems properly synced up with the new DST. For Linux, complete instructions on how to deal with DST changes can be found in my story, Switching your Linux systems to the new DST.
The one significant change since I wrote that story--pay attention Linux users in New Zealand--is that the most up-to-date Time Zone file is tzdata2007h.tar.gz, which is dated Oct. 1, 2007. If you're in New Zealand, which just changed how it handles DST, you may want to get this file from the ftp site: ftp://elsie.nci.nih.gov/pub/ and install it. In particular, Debian-based distributions should make sure they've updated since Debian didn't push the proper update through for its stable releases.
Coordinated Universal Time and NTP Time Servers
UTC is the international time standard. It's the correct term for what I, and many others, still think of as GMT (Greenwich Meridian Time) or Zulu. In UTC, which uses a 24-hour clock, zero UTC is midnight in Greenwich, England, which lies on the zero longitudinal meridian. Thus, 4 p.m. in Greenwich is expressed in UTC 16:00 UTC.
The technical difference between GMT and UTC is that while the GMT is based on the solar day, the UTC is based on, get ready for this, "The second is the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium-133 atom."
Why is this important? Well, you see, the Earth doesn't really take exactly 24 hours, or 86,400 atomic seconds, to do one complete spin. Instead, the Earth is slowing down its rotation. So, every now and again, almost always on New Year's Eve, we have leap-seconds added to UTC.
Since a day is approximately 24 hours long, the world is split into 15-degree-wide longitudinal bands (360 degrees/24 hours). Each band represents one hour. So, for instance, my home in Asheville N.C., is located at about 82 degrees west longitude. Rounded down from 82/15, you'll see that I'm in the EST (Eastern Standard Time) zone. This means I'm five hours behind UTC. So, when I talk with my Ziff Davis Enterprise colleague in London, UTC time zone, at 10 a.m. EST, it's 3 p.m. UTC for her.
The world being what it is, you can't figure out time zones just by degrees of longitude alone. Besides the aforementioned DST concerns, regional and country boundaries, also jiggle the time zone lines.
To avoid all that, Linux and Unix systems always, or at least they should, keep UTC time. Linux finds out what time it is by using NTP. NTP, in turn, checks with a reference clock.
Now, you can have a reference clock of your very own. These actually aren't clocks per se. Instead they tend to be radio or GPS (Global Positioning System) receivers. These "clocks" check in with a variety of international time services, based on atomic clocks, to keep accurate time. Most people, however, opt to use a NTP server.
Broadly speaking, there are two kinds of public NTP servers, primary and secondary, or stratum 1 and stratum 2. A stratum one is connected directly to a reference clock. A stratum 2, as you probably have already guessed, is linked to one or more stratum 1 clocks.
It is these NTP servers that you'll use to set the time for your own small NTP server.
A NTP Server to Call Your Own
First, you need to pick a server for your own time-keeper. This is a lightweight task, so I picked on my "weakest" Linux server, an HP Pavilion 521n with a 1.4GHz AMD Athlon processor and 256MB of RAM.
On this system, I put a copy of openSUSE 10.2. Yes, you can run openSUSE on a state-of-the-art circa 2001 PC. First, I just needed to set up an NTP client. With YaST, openSUSE's do-it-all administration program, that wasn't any trouble at all. You just open up YaST, with the root password, and select Network Services and head to NTP Configuration.
All you need do is pick out NTP Configuration from the YaST Network Services menu to get started.
(Click to enlarge)
Next, I tell it to start up when on system boot. After all, this is a network service. It should always be running. The program that checks the time, ntpd, works both as the client and the server.
It's at this point that I also tell it to look to use random servers from pool.ntp.org. You may be used to the idea of hard-coding NTP servers, either by name or by IP address, to check on your time. This is not a good idea.
Here, you just set NTP up to start automatically and look to pool.ntp.org for a randomly selected NTP server rather than type in a specific NTP server.
(Click to enlarge)
Time servers come and go; sometimes they're down and sometimes they test settings on them that can completely foul up your time-keeping. For example, I know of at least one instance where a NTP server was experimenting with setting a time using a 64-integer. All the 32-bit systems that came to the server during that time were presented with a time beyond their ability to count and... Well, let's just say it was ugly and leave it at that.
Next, I find it easier to just go directly to the configuration file to make the final settings for my server. This file's location varies from distribution to distribution. On openSUSE, like many other Linuxes, the file, ntp.conf, is in the /etc directory. To get there, and modify it, you need to log on to a terminal as the root user.
Anyone, and I mean anyone, can set up an ntp configuration file Just be sure to use an ASCII editor rather than a real word-processor to make your changes. Personally, I always use vi.
(Click to enlarge)
Once there, the changes are really, really minor. You'll need to double-check that the servers have been set up properly. Those are the lines reading:
server 0.pool.ntp.org
and so on. Why are there three of them? Remember, you want the most accurate possible time and you want to avoid disasters like the one I described above when a 64-bit time integer crashed a system expecting 32-bit integer times. So, at the very least, for your NTP server, you want three NTP servers. Your system will average their times to come up with the "right" time for your network.
Next up you need to restrict the type of access you want other servers to have to your NTP server. In this example, the servers are not allowed to modify the run-time configuration or query your Linux NTP server.
What I've done is let the system itself, or to be more precise, the services it calls, modify its time:
restrict 127.0.0.1
Next, I don't want any systems within my network to be able to modify my NTP server's time, so I use the line
restrict 192.168.0.0 mask 255.255.255.0 nomodify
From this, you can tell that I'm running a typical type C network. My valid IP addresses are in the 192.168.0.1 to 192.168.0.254 range. The last term "nomodify" lets ntpd know that it's not to allow any other servers in its network to try to change its clock.
That's really it. The log statement should already be in the file and uncommented. This keeps the NTP log in its usual location:
Logfile /var/log/ntp
There's one other rather mysterious line in the configuration file you may be wondering about:
Driftfile /var/lib/ntp/drift/ntp.drift
This is the file which keeps track of your computer's clock. Your PC's internal clock is not going to be that accurate and this file contains its "clock drift" or "frequency error" of your NTP's server system clock.
Ntpd updates this file every hour so it can get an estimate of your clock drift. With this, ntpd has a good estimate of what the time should be, according to your clock, to serve as a way to help synchronize your NTP server with the external NTP servers you're using to keep track of time.
In particular, this helps your server determine just how often it will check to see that it's keeping accurate time. NTP uses this data in clock discipline algorithm to determine how often your server will poll other servers to maintain maximum accuracy with minimum network load. By default, the minimum interval is 64 seconds and the maximum is 1,024 seconds. You can manually set this to check far more often--although if you really need to do that you probably need an atomic clock to call your own or a more stable--or longer if you have an especially slow Internet connection.
There are other fancier commands you can put into your ntpd.conf file, but this is really all you need for a basic small LAN. If you need more, check in to the University of Delaware NTP Web site. It's the best NTP support site I know.
You then stop and restart the NTP server so that it will look up the time and be ready to start telling other computers, when they request it, what time it is. You can do this from YaST, but since, at this point, you're still in a shell terminal you might as well do it here with the commands:
service ntp stop
service ntp start
After setting up the configuration file, it's time to stop the running ntp service and then start it again so it will read its new marching orders from the ntpd. conf file
Did it work? You could just run something like:
ps -ef | grep ntp
but that just lets you know if the process is running.
What you really want to do is run the command: ntpdc. You use this program to check on the state of your ntp daemon. You can also use it across networks to see what other ntpd programs are up to. For our purposes, we just want to check on our local NTP server. For that, just run:
ntpdc -p
The "-p" option also makes your local NTP print out what peers it's using to find the time.
Sure enough, my NTP server is alive, well and picking up the time, as requested, from three other NTP servers. Presuming that all is well, you're ready to start setting the time across your network's PCs.
(Click to enlarge)
NTP Clients
With Linux, it's easy. You just find your NTP client and point it at your NTP server. Here, on Cassandra 2.1, the KDE version of Linux Mint, an Ubuntu-based distribution, all I had to do was open my desktop clock's Adjust Date & Time control. I then logged in as root to set the program to automatically pick up the time from 192.168.0.250, the permanent IP address of my NTP server.
Click on the clock, order it to set the time and date automatically from my brand-new NTP server and life is good for this Ubuntu-based Mint workstation.
(Click to enlarge)
With modern versions of Windows, it's also easy. You simply open up the Date and Time applet from the Control Panel and set the Internet Time option to the address of your new NTP server.
In Windows, you need to make a few more steps, but it's really not difficult at all to sync Windows with a NTP server.
It gets a little more complicated with Windows 2000 or older versions of Windows. For these, I use the shareware program Tardis 2000. There are many other free and shareware time-setting programs for Windows, but I've been a Dr. Who fan for years, so I've always been amused to use a Tardis to set my time. Besides, the program works well.
You can download Tardis 2000 from many popular Windows download sites. Just follow the instructions, and you'll be up and on time in less time than it took to read this article.
On a Mac, it's even easier. You pop open your Apple Menu, head to System Preferences and click on Date & Time. Next, you select the check box "Set Date & Time Automatically," enter your NTP server's IP address, and that's it.
Like Linux, Mac OS X makes working with an NTP server for a clock simple.
(Click to enlarge)
Is it worth it? For me, it is. Keeping the right time across your network makes network services more reliable, working out problems from system logs much easier, and tracking e-mail, IMs and documents a breeze. For a serious network, you need a serious time server, and with Linux and NTP, setting one up isn't really that much trouble.
Steven J. Vaughan Nichols
Do you have comments on this story?
Talkback here
NOTE: Please post your comments regarding our articles using the above link. Be sure to use this article's title as the "Subject" in your posts. Before you create a new thread, please check to see if a discussion thread is already running on the article you plan to comment on. Thanks!
Related stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed