Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 1 subscriber
  • Views 1907 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[1.401] Time adjustments on legacy ACC

m.fischer
Hi,

the date/time-settings on the ACC were not correct. An "ntpdate ip-of-asg-with-ntp-allowed" via ssh-console gives the following error:

ntpdate ip-of-asg-with-ntp-allowed
Error : Servname not supported for ai_socktype
1 Mar 03:25:49 ntpdate[27474]: can't find host ip-of-asg-with-ntp-allowed

The solution:

See http://www.ducea.com/2006/09/11/error-servname-not-supported-for-ai_socktype/

Create an file /etc/services on the acc with the two lines

ntp             123/tcp
ntp             123/udp

After this an "ntpdate ip-of-asg-with-ntp-allowed" on the ACC works as expected.

Is there another way to set the time on the ACC via NTP without this changes?

Is it possible to add an ntp-configuration via web-management of the ACC?

Regards,
Manuel


This thread was automatically locked due to age.
Parents
  • 0
    Eek, I just noticed that my ACC box's clock has drifted off a handful of hours.

    Please astaro, add ntpd to the next release of ACC.
  • 0 in reply to drees
    Hi folks,

    yes yes yes ... we are painfully aware of the problem. And we will do something about it in the next release - but it will be bundled with a some major changes so please be patient for some more time.

    At the moment you can neither change the time via the Frontend nor use NTP without the above "inofficial" way proposed by Manuel (thanks!). We had that workaround posted earlier in the life of ACC.

    So please use the "Manuel" workaround and don't be mad - everything will get better!

    Cheers,
    Henning
  • 0 in reply to megaposer
    Not mad, just want to see that you guys are working on it. [:)]

    I'll add a daily cron job to sync up the time using ntpdate for now.
  • 0 in reply to drees
    Here's how you can get the ntpd daemon running at startup, nearly all the bits are there. This should keep your server in sync all the time which is better than syncing up every periodic interval using cron.

    1. Edit /etc/ntp.conf and add the ntp servers you want to use after line 41:
    server ntp1.example.com
    server ntp2.example.com

    2. Edit /etc/init.d/xntpd and on line 44 change XNTPD_OPTIONS from "-U ntp" to "-u ntp".

    3. Create a symlink in /etc/init.d/rc3.d to start xntpd on start up:
    # cd /etc/init.d
    # ln -s ../xntpd rc3.d/S99xntpd

    4. To finish it up create symlinks to shut it down on single user mode, halt and reboot:
    # cd /etc/init.d
    # ln -s ../xntpd rc0.d/K01xntpd
    # ln -s ../xntpd rc1.d/K01xntpd
    # ln -s ../xntpd rc6.d/K01xntpd

    5. If you want to fix the timezone while you're at it, remove the /etc/localtime symlink and point it to the correct time zone:
    # rm /etc/localtime
    # ln -s /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

    6. Sync up your clock and then sync it to the hardware clock
    # /etc/init.d/xntpd ntptimeset
    # hwclock --systohc

    7. Start up ntpd and check that ntp is running:
    # /etc/init.d/xntpd start
    # ntpq
    peers (this should show your ntp servers as well as a localhost ntp server)
    quit

    8. Reboot and check that it's running using ntpq from previous step.

    Everything above should be done as root.

    Hope this helps!
Reply
  • 0 in reply to drees
    Here's how you can get the ntpd daemon running at startup, nearly all the bits are there. This should keep your server in sync all the time which is better than syncing up every periodic interval using cron.

    1. Edit /etc/ntp.conf and add the ntp servers you want to use after line 41:
    server ntp1.example.com
    server ntp2.example.com

    2. Edit /etc/init.d/xntpd and on line 44 change XNTPD_OPTIONS from "-U ntp" to "-u ntp".

    3. Create a symlink in /etc/init.d/rc3.d to start xntpd on start up:
    # cd /etc/init.d
    # ln -s ../xntpd rc3.d/S99xntpd

    4. To finish it up create symlinks to shut it down on single user mode, halt and reboot:
    # cd /etc/init.d
    # ln -s ../xntpd rc0.d/K01xntpd
    # ln -s ../xntpd rc1.d/K01xntpd
    # ln -s ../xntpd rc6.d/K01xntpd

    5. If you want to fix the timezone while you're at it, remove the /etc/localtime symlink and point it to the correct time zone:
    # rm /etc/localtime
    # ln -s /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

    6. Sync up your clock and then sync it to the hardware clock
    # /etc/init.d/xntpd ntptimeset
    # hwclock --systohc

    7. Start up ntpd and check that ntp is running:
    # /etc/init.d/xntpd start
    # ntpq
    peers (this should show your ntp servers as well as a localhost ntp server)
    quit

    8. Reboot and check that it's running using ntpq from previous step.

    Everything above should be done as root.

    Hope this helps!
Children
  • 0 in reply to drees
    Hi everyone,

    thanks for helping us filling the gap till the next release!

    There is one thing to remember when syncing time after it has been some minutes off. The agent-manager component uses timestamps internally to verify if cached monitoring data needs to be refreshed. Suppose you have data cached at time X and it would get refreshed in X+30 seconds. Additionally assume your clock is 5 minutes ahead and gets corrected via NTP. Then the cached data will not be refreshed as expected but 5 minutes later.

    Anyway, this will only happen initially - afterwards your clock should only drift some seconds a day and have no noticeable impact.

    Cheers,
    Henning
  • 0 in reply to megaposer
    Would a reboot solve any caching issues - say for example if your clock was running a few days too fast and you wanted to speed up the process instead of waiting a few days for the cache to expire and refresh?
  • 0 in reply to drees
    Sure, of course. 

    As an alternative you can go command-line and restart the "three" critical services (see my posting: "Components of the ACC", https://community.sophos.com/products/unified-threat-management/astaroorg/f/61/t/56714).

    We are going to avoid such issues with the next release of ACC so you guys can use and trust the time synchronization without worrying about data caching problems.
Unfiltered HTML