Re: Synchronizing time on AIX
- From: Juan Medina <jmedinar@xxxxxxxxx>
- Date: Wed, 24 Oct 2007 14:24:31 -0000
On Oct 23, 12:05 pm, lath...@xxxxxxxxxx (Richard D. Latham) wrote:
Patrick Tonnerre <nos...@xxxxxxxxxx> writes:
Hi from France,
newbie on AIX, i want to automate synchronizing time for the next
coming winter time (28th october).
We made tests using the ntpdate command but i think it need good
paramaters on smit. In Smit We dont really understand the diffence
between :
- ID standard time ("ID heure standard" en français)
- ID state time ("ID d'heure d'état" en français)
Thanks for any help/advice for the best way to set up that process.
As I typed this up, I realized what your actual question was. The
answer to your specific question is buried in the following, but there
is a lot more detail than you probably needed. Since I've already
typed it all in, I'm going to leave the detailed explaination for the
benefit of anyone else wondering about this topic.
========================
I think you are confusing two related but seperate topics.
Topic 1 - How do I keep the clock on a machine synchronized to some
authorative source ?
Topic 2 - When I ( or a program ) displays the current time, how do I
get the system to automatically adjust it's reported "local time" to
account for the presense or absense daylight savings time ?
Lets talk about Topic #2 first.
In general, we (should, and do) set the clock on a machine to UTC ( or
GMT ) time. An environment variable, 'TZ=xxxdyyy' controls the
transformation from UTC to local time, where 'xxx' is a three
character abbreviation for the local timezone in 'standard' (i.e. NOT
daylight savings time" and 'yyy' is an abbreviation for local timezone
when daylight savings time is in effect. 'd' is the offset from UTC time.
The default value for the TZ environment variable is chosen at
installation time, and stored in /etc/environment. The chtz command
will change this system-wide value, if you don't like directly
editing the /etc/environment fle.
The CRITICAL detail is, IF the last 2 characters of the 'yyy' part of
the TZ variable are equal to 'DT', this tells the system that
daylight savings time is in effect at 'this location', and
automatically applies the systems built-in rules for daylight savings
time adjustment.
It turns out that the '3 characters' are arbitary. What's important is
that the last 2 of the'yyy' part be 'DT', and that the UTC offset
value is properly chosen.
I don't know the 'normal value for France. For a machine located on
the east coast of the US, the usual TZ value is "EST5EDT".
I believe for France that the correct UTC offset is '-1'.
My school boy french is over 30 years old, but I believe that "ID
heure standard" is "daylight savings time NOT in effect" and "ID
d'heure d'etat" is "daylight savings time IS in effect".
So I'm guessing that setting the TZ environment variable to "FST-1FDT"
would work. Remember that you can experiment in an xterm, by (assuming
ksh) "export TZ=FST-1FDT ; date " to see the effects. To see the
daylight savings time change occur, you'd have to set the local system
clock to sometime after 28 October. ntpdate isn't going to let you do
that, so read the discussion about "Topic 1" below.
Users may optionally over-ride the TZ setting ( in their start-up
scripts, i.e. .kshrc, .profile, etc. ) so that, if the machine is in
England but you're always logging on from France, the correct (from
your perspective) local time gets displayed.
It turns out that the TZ variable is much more complicated than my
short discussion above would indicate. For all the gory details, check
this URL:
<http://www-1.ibm.com/support/docview.wss?rs=0&uid=isg3T1000252>
Now lets talk about Topic #1.
There is a defined protocol and a set of programs implementing the
protocol designed to set the local clock to the 'correct' value, and
to ensure that the value doesn't drift materially from the 'correct'
value. We call these guys "NTP", which stands for Network Time Protocol.
The NTP protocol ( and programs that implement the protocol ) make
remote requests to one or more "NTP Servers" which are presumed to
know the correct time. The NTP Server(s) may have a radio listening to
one of the radio broadcast time sources, it may have it's own special
GPS receiver which outputs the 'correct' time once every few seconds
on a serial port, or it's own atomic clock, but usually they just do
what DNS servers do, which is "ask somebody else that knows the
answer" ... in other words, the NTP Server also uses the NTP protocol
to stay synchronized to a lower stratum NTP Server. ( "lower stratum"
== "presumed more accurate" ).
Just like DNS, there can be a tree of NTP Servers, with only the
"root" of the tree having an actual physical time source reference.
The program "xntpd", controlled by the configuration file /etc/ntp.conf,
implements the NTP protocol, and multiple times per minute, requests
the current time from the configured NTP server(s).
But xntpd doesn't just force the local clock to the 'correct' value. It
'skews' the local clock setting to bring it closer to the 'correct'
time. It will either speed up or slow down the local clock, to
gradually converge the local clock setting with the 'correct' time. It
will never set the local clock backwards. "Time always runs in the
forward direction" is a primary requirement of the NTP specification.
So, set up a proper /etc/ntp.conf pointing at an valid NTP Server,
execute "startsrc -s xntpd", as root, and once the local xntpd has
skewed the local clock to the 'correct' value, your local clock will
never again get more than a few milliseconds from the 'correct' time.
( Assuming of course, that the owner of the NTP Server doesn't
turn it off . )
There's one other thing you MUST know about the NTP protocol,
specifically the behavior of the local xntpd daemon.
When the xntpd daemon starts up, it will contact the configured NTP
Servers to determine the correct time. If the local clock is set to a
time that is more than 5 minutes different that the 'correct' time,
the ntpd daemon will refuse to modify the local clock. The xntpd
daemon will instead immediate exit.
This behavior is why the program "ntpdate" exists. It contacts one or
more NTP Servers to determine the 'correct' time, and forces the local
clock to that value.( "man ntpdate" )
NOTE that ntpdate will decline to reset the local clock IF a local
xntpd daemon is running.
--
#include <disclaimer.std> /* I don't speak for IBM ... */
/* Heck, I don't even speak for myself */
/* Don't believe me ? Ask my wife :-) */
Richard D. Latham lath...@xxxxxxxxxx
Hi
Take any machine in your environment as a Server set it up ... and the
rest set them as clients... here the required steps
Best Regards
SETTING UP AN NTP SERVER
1. edit the /etc/ntp.conf file
server 127.127.1.0 prefer
driftfile /etc/ntp.drift
tracefile /etc/ntp.trace
save file and exit.
2. smitty xntpd-->start at both system restart and now.
Let run for approximately 10 minutes before moving to step 4.
Otherwise, stratum will show 16.
3. lssrc -ls xntpd
Stratum should show between 3-4 but ok as long as it doesn't show
16.
Server is ok, now to configure client.
SETTING UP AN NTP CLIENT:
1. edit the /etc/ntp.conf file:
server 9.7.84.102
driftfile /etc/ntp.drift
tracefile /etc/ntp.trace
kk
2. ntpdate 9.7.84.102
If it doesn't say "no server suitable for synchronization found", go
to next step.
3. smitty xntpd-->start at both system restart and now.
Let run for approximately 10 minutes or so before going on to step
4. Otherwise stratum may show 16.
4. lssrc -ls xntpd
Stratum should show 4-5. If it doesn't its ok as long as it doesn't
show 16.
Clocks should now be in sync. Repeat client steps to setup other
clients if necessary.
.
- References:
- Synchronizing time on AIX
- From: Patrick Tonnerre
- Re: Synchronizing time on AIX
- From: Richard D. Latham
- Synchronizing time on AIX
- Prev by Date: Re: make C++ dynamic lib with xlC.rte 9 work under xlC.rte 6?
- Next by Date: log root logins?
- Previous by thread: Re: Synchronizing time on AIX
- Next by thread: Re: Synchronizing time on AIX
- Index(es):
Relevant Pages
|
