Synchronizing time on AIX - Aix

This is a discussion on Synchronizing time on AIX - Aix ; 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 ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Synchronizing time on AIX

  1. Synchronizing time on AIX

    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

  2. Re: Synchronizing time on AIX

    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


  3. Re: Synchronizing time on AIX

    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

  4. Re: Synchronizing time on AIX

    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.


  5. Re: Synchronizing time on AIX

    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.


+ Reply to Thread