Enterprise Software

Using NTP as a time source for your NetWare servers

NetWare relies on accurate common times to ensure that NDS updates and synchronizations occur correctly. Eric Toll shows how you can easily create a reliable common time setting throughout your network with NetWare 5.x and an Internet connection.


Having accurate synchronized time across your LAN and WAN is critical in a NetWare environment. NetWare relies on accurate common times to ensure that NDS updates and synchronizations occur correctly. Fortunately, you can easily create a reliable common time setting throughout your network with NetWare 5.x and an Internet connection. In this Daily Feature, I’ll show you how to use NTP (Network Time Protocol) with your NDS tree and how to make all your servers and workstations use the correct time.

What is NTP?
NTP was first described by Dr. David Mills in Request for Comments (RFC) document 958, "Network Time Protocol (NTP)," dated Sept. 1, 1985. This RFC was produced subsequent to experiments Dr. Mills had carried out on time synchronization, which are described in the documents RFC 957 "Experiments in network clock synchronization" and RFC 956 "Algorithms for synchronizing network clocks," both also dated Sept. 1, 1985.

As with many of the other Internet protocols, it was through this investigative work that NTP was developed, first as a research project and subsequently as an Internet standard. The current NTP version is version 3. It’s documented in RFC 1305 of March 1992 and is a proposed Internet standard.

Vendors on many different platforms—including UNIX, NetWare, Windows NT, and Apple Macintosh—implement NTP. NTP provides the means for networked computers to serve and obtain accurate time on the Internet. An NTP client is a computer that obtains its time from a time source. An NTP server is the computer that provides an accurate source of time.

NDS, NTP, and you—why it’s good
Novell NDS needs to have the correct synchronized time for it to work effectively. This is because when you make a change in NDS, the changes to the requested object are timestamped. NDS needs to timestamp objects and changes to those objects (users, rights, and so forth) for consistency. It’s really the only way the servers can vote on who has the latest and greatest information.

Obviously, having your time synchronized is important, and it’s even better to have the correct synchronized time. That’s because of the way Novell has configured its client software to obtain time updates. In the last few versions of Client32, the default setting is to obtain and change the workstation’s time based on the server time. Because this is the default option, you have the possibility of forcing the incorrect time to be set on your users’ Windows workstations.

I remember a friend telling me that a user’s clock was set incorrectly, so the user would set it right in Windows via the system tray clock, only to have it get set 15 minutes ahead every time he logged back in to NDS. This was a perfect example of the problem with servers having the wrong time.

Why you need NTP
If you’re not currently using NTP, you must rely on your server’s internal clock to maintain system time. Very rarely have I seen a server where the time could be set accurately once and remain consistent for longer lengths of time. Let’s face it: NetWare servers, if set correctly, will stay up for years at a time, so you may not have the opportunity to set the BIOS clock again.

Even the best servers have internal clocks that may lose or gain several minutes over 6 months. “Big deal,” you say, “I’ll just set the time from the server console.” This is an option if you have only one server and you haven’t changed anything recently. But if you have multiple servers and time synchronization is active, you have to wait for the servers to resynchronize the time among themselves. This process can throw consistency out the window.

Finding an NTP server
You need to look on the Internet for a list of public NTP servers that will give you the time of day. As of this writing, I found a good place to get a list of NTP servers here.

I like to pick servers that are geographically near my server, but you can choose any Internet server. That’s because your NetWare server has a UTC (Universal Time Coordinates) or time zone set, so it will know to add or remove the correct number of hours.

Note that there are two categories for public time servers: Stratum 1 and Stratum 2. You should use a Stratum 2 server because there are only a few Stratum 1 servers, and the Stratum 1 servers set the time on the Stratum 2 servers. A Stratum 1 server is more accurate than a Stratum 2 server, and when I say more accurate, the difference we are talking about is a minuscule +/- 0.0001 seconds—not really an issue.

Setting your server to connect to NTP
When you connect your NetWare server to the Internet, you must make a few changes to it to accept time from an NTP server. First, you must configure the server that is connected to the Internet to be a single-reference type of server.

Single-reference time servers go out and get the correct time from the sources you choose. To specify single-reference servers, begin by loading Monitor from your NetWare 5.x server console. Select Server Parameters from the Available Options menu and choose Time. You’ll then see the Time Parameters screen, shown in Figure A.

Figure A
You can use Monitor to change settings for Timesync.


Scroll down the list box with your arrow keys and highlight Default Time Server Type. Check to make sure it is set for Single Reference. If not, press [Enter] to change it and type single in the field. Press [Enter] again to save the change.

Next you need to go to the Timesync Configured Sources and check to make sure it’s set to On. This tells your NetWare server to use only the servers you entered to be contacted for the correct time.

Last but not least, you need to check the Timesync Hardware Clock value. Make sure that this variable is also set to On.

The TIMESYNC.CFG file in your SYS:system directory
If you’re brave, you can also make changes to your Timesync configuration by making changes directly in the TIMESYNC.CFG file on your server. You may choose to edit this file manually by using your favorite editor. I like to use the one that comes with NetWare right from the Console. Just type:
edit sys:system\timesync.cfg

and the file appears on your screen. Here is a sample TIMESYNC.CFG file:
# TimeSync.Cfg is now updated automatically,
# when changes are made on the System Console
# TIMESYNC Configuration Parameters
Configured Sources = ON
Directory Tree Mode = ON
Hardware Clock = ON
Polling Count = 10
Polling Interval = 30
Service Advertising = OFF
Synchronization Radius = 2000
Type = SINGLE
# TIMESYNC Configured time source list
TIME SOURCE = 128.59.64.60:123
TIME SOURCE = 128.59.35.142:123
TIME SOURCE = 128.59.16.20:123
TIME SOURCE = 204.168.28.9:123

As you can see, I put a few extra Time Source entries in the file. If you set up only one and that NTP server goes down, you’re stuck.
Getting the rest of your servers and tree set
Depending on how many servers you have in your NDS tree, you can explicitly tell each server to get its time from the single-reference servers, or you may have a few key servers. A good configuration is to have one per each WAN location to get the correct time from our new single-reference server, and then basically spread the word by time service advertising, SAP advertising via IPX, or SLP via IP.

I don’t use advertising because it just makes your network busier. However, in some cases this may be a better option for you if you’re in a large environment.
If you have NetWare 4.x servers in your tree and you want them to get and keep the correct time from the single-reference server, you need to have IPX enabled on the private or inside network interface.
Timesync debug screen
You may see the Timesync debug screen. Don’t panic. It’s not a problem—it’s basically just NetWare telling you it’s getting the correct time, and minor corrections are being made to the NetWare Server time. It would look something like this:
Uniform Adjustment Requested: -1.0333D730
This server is configured as a SINGLE REFERENCE
Fri Sep 15 19:46:36 2000
TIMESYNC: Polled server 128.59.64.60:123 (Reference/Single Reference)
   offset.h = FFFFFFFF offset.l = 01B9D575
TIMESYNC: Polled server 128.59.35.142:123 (Reference/Single Reference)
   offset.h = FFFFFFFE offset.l = F9CD3DCE
TIMESYNC: Polled server 128.59.16.20:123 (Reference/Single Reference)
   offset.h = FFFFFFFE offset.l = FBADA5B2
TIMESYNC: Polled server 204.168.28.9:123 (Reference/Single Reference)
   offset.h = FFFFFFFE offset.l = F8430ECA
Uniform Adjustment Requested: -0.04220E10
This server is configured as a SINGLE REFERENCE
Fri Sep 15 19:47:19 2000


Conclusion
Wouldn’t it be cool to tell users that they can set their watch from their Client32 PC? And that not only is it accurate, it’s also accurate to within a few hundredths of a second? And just think how happy your servers will be being synchronized with the accurate time. For more information from Novell, go to Novell Support and enter NTP or timesync as a search term.

Eric Toll is a Certified NetWare Engineer for NetWare 5 and an IBM Certified Technical Solutions Specialist and e-Business Application Architect for IBM’s AS/400 product line. He is corporate IT manager for Panthus Corporation in Syracuse, NY, writes for Network Computing Magazine, and has enjoyed working with ever-changing technology since he began doing networking in the late 1980s. Send him your comments.

The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks