On Oct 23, 5:16 am, Patrick Tonnerre wrote:
> 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.
>
> Regards
> --
> Patrick

Patrick: I think you're mixing up a couple of different things here.
The change to winter
time should happen automagically (without any action on your part) so
long
as you have the system set to the right timezone for your location.
I'm sorry but
my schoolboy French (from long ago) isn't up to parsing the meanings
of the
terms you list.
By contrast, ntpdate along with other things (xntpd and setclock) is
used to
synchronize the clocks of various servers to each other and has
nothing per se to do with a change to winter time.

HTH

Jim Lane

Patrick Tonnerre 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:


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 /* I don't speak for IBM ... */
/* Heck, I don't even speak for myself */
/* Don't believe me ? Ask my wife :-) */
Richard D. Latham lathamr@us.ibm.com

On Oct 23, 12:05 pm, lath...@us.ibm.com (Richard D. Latham) wrote:
> Patrick Tonnerre 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:
>
>
> 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 /* 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...@us.ibm.com

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.

On Oct 23, 10:16 pm, Patrick Tonnerre wrote:
> 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.
>
> Regards
> --
> Patrick

my 2¢ worth.
You will probably find someone in your organisation already has an NTP
service running.
Make sure it's a "reliable" service, and use it.
Increasing the syslog to at least "info" will show you when NTP loses
it's connection.
Also, NTP has had many security advisories in the past and isn't the
most robust technology every. Having said that, I've always used it
because I haven't seen anything better.