-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 02/29/2012 07:02 PM, jdow wrote:
On 2012/02/29 06:33, Aaron Konstam wrote:
On Tue, 2012-02-28 at 14:10 -0800, jdow wrote:
On 2012/02/28 07:38, Aaron Konstam wrote:
On Mon, 2012-02-27 at 18:06 -0800, Marvin Kosmal wrote:
On Mon, Feb 27, 2012 at 3:17 PM, Patrick Dupre patrick.dupre@york.ac.uk wrote: Hello,
I am runing chrony chronyd.service - NTP client/server Loaded: loaded (/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Mon, 27 Feb 2012 22:42:01 +0100; 35min ago Main PID: 4150 (chronyd) CGroup: name=systemd:/system/chronyd.service └ 4150 /usr/sbin/chronyd -u chrony
but my clock is still not on time. How can I synchronize is manually (before I sued to do ntpdate time.server.
Run: system-config-date and in the Time Zone display be sure UTC is checked.
Unless somebody broke ntp that last is in no way required. It has never been required. It doesn't even seem to require the motherboard clock to be set to UTC.
{^_^}
Although it is always good to hear from jdow her statement is wrong. Tim Waugh and I spent at least a month trying to debug the fact that on my network printer browsing did not work. After a lot of agony and searching log files we found that the problem was the print client was jumping around in time so the server got confused about the browsing and just gave up. Also ntpd would quit shortly after it was started. The problem was fixed by checking UTC in the system-config-date display.
I cannot speak to chrony. But I've been running ntp happily since it was xntp.
On my SL6.2 virtual test machines which run in VirtualBox hosted on Win 7 the clocks are all set, properly, to Los Angeles time. ntp locks right up slick as you could ask. I do take back the bit about motherboard running UTC. I notice VirtualBox has the UTC checkbox ticked. So motherboard is UTC. I believe there is a configuration setting for NTP to handle that. But the timezone setting certainly does not have to he UTC.
[jdow@sl6 ~]$ date;date -u Wed Feb 29 15:49:08 PST 2012 Wed Feb 29 23:49:08 UTC 2012
ntpq> peers remote refid st t when poll reach delay offset jitter ==============================================================================
+we.love.servers 192.43.244.18 2 u 29 64 377 36.411 -84.322 10.851 +64.73.32.134 192.36.143.150 2 u 1 64 377 85.706 -101.83 11.770 -mirror 204.9.54.119 2 u 46 64 377 83.161 -69.662 21.143 *me2.xxxxxxxxx.x 69.25.96.13 2 u 44 64 377 0.431 -97.046 13.406
On the SL6.2 firewall machine the motherboard clock is set to UTC, the system is set to Los Angeles time. [jdow@me2 ~]$ date;date -u Wed Feb 29 15:49:43 PST 2012 Wed Feb 29 23:49:43 UTC 2012
It setup this way mostly right out of the box. I had OTHER problems porting in my very historically based configuration; but, ntp was no big deal.
(SELinux is a borked pain in the asterisk. I leave it running. But I am less and less enthused by it every day. It, dhcpd, named, and SpamAssassin don't seem to get along well together when dhcpd is supposed to update a useful dhcpd setup. And some how named gets MANY hanging locks that make it impossible to shut it down gracefully.)
This is the important part of the setup. ===8<--- driftfile /var/lib/ntp/drift restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst includefile /etc/ntp/crypto/pw keys /etc/ntp/keys #trustedkey 4 8 42 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
The virtual machines are similar: ===8<--- driftfile /var/lib/ntp/drift restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1
server 0.rhel.pool.ntp.org iburst server 1.rhel.pool.ntp.org iburst server 2.rhel.pool.ntp.org iburst
includefile /etc/ntp/crypto/pw keys /etc/ntp/keys
# new machine (A pointer to the local server) server 192.168.xx.1 ===8<---
/etc/sysconfig/clock: ZONE="America/Los Angeles"
{^_^}
Please tell us the problems you are having with SELinux? Maybe we can fix it for everyone if you have a common configuration. Open a Bugzilla please.