|
Internet: Time Servers
Netware Servers
The prefered method of TIme Syncronization within ed-IT
is NTP, the solutions below will be aimed at providing a clean
NTP feed to the NDS EDFAC_TREE.
As we run NW4.11 and NW5.0, the notes will be for these versions.
If this seems new/alien I'd suggest you break open your manuals immediately
and learn about timesync as it's essential to NDS operation. As all the
changes that take place in your network get recorded the information must go
to all replicas of your partitions. Each change has a timestamp. If a
receiving server is not in sync time-wise your results are unpredictable.
You're finished when time is correct and stays correct *and* the
command TIME states that "Time is synchronized to the net" on all
servers.
Setting time on NW servers.
AUTOEXEC.NCF
# ------------------------------------------------------------------------
# Melbourne Uni Netware 5 Server: "KRYPTON"
# AUTOEXEC.NCF: Last Modified 18/4/2000
# ------------------------------------------------------------------------
# ---- Netware Settings --------------------------------------------------
SET TIME ZONE = EST-10ESUT
SET DAYLIGHT SAVINGS TIME OFFSET = 1:00:00
SET START OF DAYLIGHT SAVINGS TIME = (OCTOBER SUNDAY LAST 2:00:00 AM)
SET END OF DAYLIGHT SAVINGS TIME = (MARCH SUNDAY LAST 2:00:00 AM)
SET TIMESYNC TYPE = SINGLE
SET DEFAULT TIME SERVER TYPE = SINGLE
|
LIST1: AUTOEXEC.NCF
GMT vs UTC
They're functionally the same. GMT is a time zone, UTC is a time value. The
time in the GMT zone equals the value of UTC.
TIME
It is simple enough to set Time on the server (SET TIME...) and then
unload and load your timesync.nlm (unload....load), answer yes to the
question it asks you.
KRYPTON:time
Time zone string: "EST-10ESUT"
DST status: ON
DST start: Sunday, October 28, 2001 2:00:00 am EST
DST end: Sunday, March 25, 2001 2:00:00 am ESUT
Time synchronization is active.
Time is synchronized to the network.
Friday, January 5, 2001 1:15:16 am UTC
Friday, January 5, 2001 12:15:16 pm ESUT
|
LIST2: TIME
If all fails simply perform a SET TIME on *all* servers. And after that
a TIME RESET using MONITOR.NLM
KRYPTON:set time 10:30 am
|
LIST: SE TIME
TIMESYNC.NLM
Timesynch.NLM is the module which controls the time synchronization process.
LIST: TIMESYNCH DEBUG
When you bring the server up and time does not synchronize, by default the timesync debug
screen will load. This can be loaded manually by typing: (set timesync debug = 7) and turned off manually
by typing (set timesync debug = 0), if setting it to 0 does not turn it off, set it to 7, then set it to 0 and it
should be turned off.
TIMESYNC.CFG
The below recommended TIMESYNC.CFG file for a NW5 server, and should
be placed in SYS:SYSTEM. For an explanation of these parameters,
refer to your Netware manuals. Time can also be configured with SERVMAN.NLM.
# 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 = 3
Polling Interval = 600
Service Advertising = ON
Synchronization Radius = 2000
Type = SINGLE
# TIMESYNC Configured time source list
TIME SOURCE = 128.250.151.40:123
TIME SOURCE = 128.250.3.11:123
|
LIST: TIMESYNC.CFG
SET TIMESYNC Directory Tree Mode = On
SET TIMESYNC Configured Sources = On
|
LIST: SET TIMESYNCH from console
"Type" defines what form of time server
the machine is to be (single reference, ref, primary, secondary).
... However, you may choose to reconfigure the current 'primary' to a
'secondary' and a 'secondary' to a 'reference' and another 'secondary'
to a 'primary' in this case. 'reference' servers do not adjust their
time. So in the end everything is equal to it (except for other
'reference' servers ofcourse).
BTW you need at least two 'primary' and/or 'reference' server.
An option is to have *one* 'single reference' and everything else a
'secondary'.
So, in short.
Uniform Adjustment Requested: -2.10CAA1CB
This server is configured as a SECONDARY
Sun Jan 7 02:13:30 2001
*** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
offset.h = FFFFFFFD offset.l = FA79E2F5
Uniform Adjustment Requested: -2.05861D0B
This server is configured as a SECONDARY
Sun Jan 7 02:23:23 2001
*** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
offset.h = FFFFFFFD offset.l = FA97FE05
Uniform Adjustment Requested: -2.056801FB
This server is configured as a SECONDARY
Sun Jan 7 02:33:16 2001
*** Time is synchronized *** *** Time is synchronized ***
TIMESYNC: Polled server 128.250.151.21 (Reference/Single Reference)
offset.h = FFFFFFFD offset.l = FA986F55
HOW
- We explicitly "told" our SINGLE server (KRYPTON)
to get the time from the reference server
TIMESYNC Add Timesource = reference server
TIMESYNC configured sources = on
# TIMESYNC Configuration Parameters
Configured Sources = ON
Directory Tree Mode = ON
Hardware Clock = ON
Polling Count = 3
Polling Interval = 600
Service Advertising = ON
Synchronization Radius = 2000
Type = SINGLE
# TIMESYNC Configured time source list for KRYPTON
TIME SOURCE = 128.250.151.40:123
TIME SOURCE = 128.250.3.11:123
- SAP time-broadcast on the reference server are not used,
if you are running a Netware rather than UNIX refernce server use ...
TIMESYNC Service Advertising = off
Why????? The SAP-broadcast of the reference server will be lost before
it was picked up by the primary servers. By forcing the primary servers to
get the time from our reference server SAP is not needed (at least
for the communication between the reference and primary servers).
[Win95 IPX machines really stuff up SAP on the network]
- Secondary local on the WAN (CHAOS, HELIUM, COSMOS)
# TIMESYNC Configuration Parameters
Configured Sources = OFF
Directory Tree Mode = ON
Hardware Clock = ON
Polling Count = 3
Polling Interval = 10
Service Advertising = ON
Synchronization Radius = 2000
Type = SECONDARY
# TIMESYNC Configured time source list for HELIUM
TIME SOURCE = 128.250.151.21
TIME SOURCE = .KRYPTON.EDFAC
- Secondary remote on the WAN (ARGON)
Configured Sources = ON
Directory Tree Mode = ON
Hardware Clock = OFF
Polling Count = 3
Polling Interval = 600
Service Advertising = OFF
Synchronization Radius = 4000
Type = SECONDARY
# TIMESYNC Configured time source list
TIME SOURCE = 128.250.151.21
TIME SOURCE = .KRYPTON.EDFAC
TIME SOURCE = NTP.EDFAC.UNIMELB.EDU.AU
"Synthetic time is being issued..." messages at the console
When you modify an NDS object the object is time stamped.
If you change the time backwards on your network, you will see that
you get synthetic time being issued on partition <some name>.
This message is displayed every 2 minutes while time synch tries to close the gap.
If the gap is too large you will need to use DSRepair using the -a switch.
Can someone define EPOCH for me?
Epoch is the time base of the system. NDS keeps messages in order
by timestamp, and needs to so that an old message is recognized as having
likely inaccurate information compared to recent messages and hence should
be discarded.
Using DSREPAIR to "declare a new epoch" means in practice to stop,
wait for the declarer to say The time a the tone will be ..., and then
let servers progress from that point forward. Those servers ahead of the
time hack are obliged to forget and then relearn information based on the
announced time. One does not want to "declare" frequently because it is a
serious disruption to NDS synchronization activities, but when we need it
we really need it.
The common mistake on epoch things is let a server get days or
years ahead of the tree. Oh boy, that's serious stuff. Ditto in the
other direction. So we always check the time when rebooting a server
and only after that check do we let the machine start server.exe. The
smarter the system manager the more often time/dates are set wildly wrong,
an observed situation based on not wanting to follow directions.
MONITOR.NLM
Within MONITOR.NLM (Monitor replaces Servman in NW5) there's an option to ADJUST time.
If all fails simply perform a SET TIME on *all* servers. And after that
a TIME RESET using MONITOR.NLM
It may not be recommended by some but up to now this has worked for me.
FIG1: MONITOR.NLM - Time settings in NW5 Monitor
Server Parameters>Time
[australia-tasmania]
time-zone-name = EST
time-zone-full-name = Australia/Tasmania
time-zone-offset = -10:00
dst-name = none
[australia-queensland]
time-zone-name = EST
time-zone-full-name = Australia/Queensland
time-zone-offset = -10:00
dst-rule = none
[australia-north]
time-zone-name = CST
time-zone-full-name = Australia/North
time-zone-offset = -9:30
dst-rule = none
[australia-west]
time-zone-name = WST
time-zone-full-name = Australia/West
time-zone-offset = -8:00
dst-rule = none
[australia-south]
time-zone-name = CST
time-zone-full-name = Australia/South
time-zone-offset = -9:30
dst-name = none
DSREPAIR.NLM
Troubleshooting:
Run DSRepair Report Synchronization Status. If servers are out of sync this needs to be corrected - in
some cases it may be caused by a communications problem between servers. Also check that network
time server configurations are appropriate. See TIDs 2930686, 2908867, and 2918511 for excellent
information on this. Run unattended repairs on servers with master replicas of user partitions. Make sure
your DS.NLM versions are current.
/****************************************************************************/
Netware 5.00 Directory Services Repair 5.21 , DS 7.44
Log file for server ".KRYPTON.EDFAC" in tree "EDFAC_TREE"
Start: Friday, September 8, 2000 11:34:29 am Local Time
Retrieve replica status
Partition: .[Root].
Replica: .HELIUM.EDFAC 9-08-2000 11:30:12
Replica: .CHAOS.EDFAC 9-08-2000 11:33:46
Replica: .KRYPTON.EDFAC 9-08-2000 11:32:32
Replica: .ARGON.EDFAC 9-08-2000 11:31:01
Replica: .COSMOS.EDFAC 9-08-2000 11:28:54
All servers synchronized up to time: 9-08-2000 11:28:54
*** END ***
/****************************************************************************/
Netware 5.00 Directory Services Repair 5.21 , DS 7.44
Log file for server ".KRYPTON.EDFAC" in tree "EDFAC_TREE"
Time synchronization and server status information
Start: Friday, January 5, 2001 12:17:44 pm Local Time
DS.NLM Replica Time Time is Time
Server name Version Depth Source in sync +/-
---------------------------+---------+---------+-----------+--------+-------
.HELIUM.EDFAC 7.44 0 Secondary Yes + 1
.CHAOS.EDFAC 6.09 0 Secondary Yes 0
.KRYPTON.EDFAC 7.44 0 Single Yes 0
.ARGON.EDFAC 7.44 0 Secondary No + 71:02
.COSMOS.EDFAC 7.44 0 Secondary Yes 0
*** END ***
|
LIST4: DSREPAIR.NLM (SYS:SYSTEM\DSREPAIR.LOG)
For pre-NW5 boxes.
RDATE
RDATE uses the RFC 868 "Time protocol" (port 37),
NOT the RFC 867 "Daytime protocol" (port 13), so port 37 must be available
for you to use RDATE.
Here is a rdate.ncf command files, just for reference:
load rdate.nlm /q /u /p 60 n.n.n.n n.n.n.n n.n.n.n
|
LIST3: RDATE.NCF
Translation: /q be quiet, /u use UDP rather than TCP, /p 60 poll every 60
minutes, and try one of the three addresses which follow.
RDATE2: RDATE2
The NetWare time sync client RDATE has been simplified and is available with source as RDATE2. A NetWare time sync
*daemon* is also available. A complete package of the three is included here.
Time synchronization has been lost after XXXXX successful polling loops.
6-09-2001 8:46:13 am: TIMESYNC-5.15-62
Time synchronization has been lost after 8565 successful polling loops.
6-09-2001 8:46:22 am: TIMESYNC-5.15-63
Time synchronization has been established.
6-10-2001 6:56:59 am: TIMESYNC-5.15-62
Time synchronization has been lost after 8038 successful polling loops.
6-10-2001 6:57:08 am: TIMESYNC-5.15-63
Time synchronization has been established.
|
LIST4: Errors from the console of HELIUM.
TIMESYNC-X-72: Time synchronization has been lost after
number successful polling loops.
Source: TIMESYNC.NLM
Explanation: Time synchronization was lost for some unexplained reason. This is normally not a problem and the
system will reestablish synchronization. However, if the problem occurs frequently, the system may have a hardware
or network problem.
Action: Try the following:
Check for recent time changes or configuration changes that may have caused this problem.
Check the Synchronization Radius parameter and make sure it is not unreasonably small. A practical limit is
1000 milliseconds (1 second).
The system might be experiencing a hardware or network problem. See Troubleshooting in the online
documentation.
http://www.novell.com/documentation/lg/nw5/usreflib/sysmsenu/data/hs3clxsy.html
Documents, White Papers, Links and Resources.
Time Synchronization Solutions Guide
http://www.connectotel.com/netware/timesg.html
Email thread on NetWare & Time Synchronization
nov-tim1.txt
nov-tim2.txt
Time Synchronization
http://www.circa.ufl.edu/netware/timesync.html
Novell Technical Information Documents
Time Synchronization White Paper (doc# 10020147)
doc # 2930686
SFT III Time Not in Synch With the Network
(doc# 2926308)
Novell AppNote- "Using Network Time Protocol (NTP) with NetWare 5", © Jul 99
Using NTP with NetWare
Time Synchronization Solutions Guide for NetWare (24 Oct 95)
Novel-guide.txt
Understanding Time Synchronization in NDS
Caldera NetWare for Linux
Introduction to NDS
Restricted access: http://docs.edfac.unimelb.edu.au/ndsdesc/06.htm
http://www.bmends.bme.hu/documentation/ndsdesc/06.htm
|