Samba/hwclock -- Samba Time Server Not Right
David Rankin
drankin at cox-internet.com
Fri Jan 18 23:19:06 GMT 2002
Andrew,
Since I got your message I've dived back into my mess with Samba
serving the wrong time. I'm pulling my hair out. Look at the following.
It doesn't make sense to me at all : (
<snip>
For the benefit of the rest of the great folks on the list my config
is:
Mandrake 7.2, 2.2.19 kernel, Samba 2.09, Abit KT7 mobo, T-bird
800Mhz, 256M (every thing else is bone stock 7.2 ISO install -- no
monkey business at all)
<resume>
[root at Nemesis sysconfig]# ntpdate tock.greyware.com
18 Jan 22:24:38 ntpdate[16275]: adjust time server 208.14.208.44
offset 0.028053 sec
[root at Nemesis sysconfig]# date
Fri Jan 18 22:24:44 CST 2002
(Correct localtime)
[root at Nemesis sysconfig]# date -u
Sat Jan 19 04:24:48 UTC 2002
(Correct UTC)
[root at Nemesis sysconfig]# hwclock -r --utc
Fri Jan 18 22:25:04 2002 -0.356267 seconds (Correct
-This is localtime)
[root at Nemesis sysconfig]# hwclock -r --localtime
Sat Jan 19 04:25:08 2002 -0.011848 seconds (Correct
-This is UTC - What's in the clock)
The system clock is set just fine. (The hardware clock always returns
local time so -- localtime just tells it to return what is in the
hardware clock without applying an offset -- i.e. UTC)
OK, lets talk config a little bit:
[root at Nemesis sysconfig]# cat /etc/sysconfig/clock
ZONE=America/Chicago
UTC=true
ARC=false
[root at Nemesis sysconfig]# cat /etc/timezone
America/Chicago
[root at Nemesis /etc]# ls -al localtime
lrwxrwxrwx 1 root root 35 Jan 18 22:34 localtime ->
/usr/share/zoneinfo/America/Chicago
All looks good. (at least to me) Now let's look at how the Samba server
"Nemesis" serves time:
C:\WINDOWS>net time \\nemesis /yes (My
Linux/Samba box)
Current time at \\NEMESIS is 1-19-2002 4:38A.M. (Not
Correct!! this is UTC)
The command was completed successfully.
C:\WINDOWS>net time \\rankin /yes
(Win95 Machine)
Current time at \\RANKIN is 1-18-2002 10:40P.M. (fine -
no update from server yet)
The command was completed successfully.
C:\WINDOWS>net time \\tripod /yes
(Win98 Machine)
Current time at \\TRIPOD is 1-18-2002 10:40P.M. (fine -
same explaination)
The command was completed successfully.
C:\WINDOWS>net time \\secretary /yes
(WinME Machine)
Current time at \\SECRETARY is 1-18-2002 10:40P.M. (fine - same
explaination)
The command was completed successfully.
(sidebar -- Tripod got its name because it only has 3 of the 4 rubber
footies on the bottom of the case)
Now, continuing our investigation, just for comparison, let's do the
following:
[root at Nemesis david]# hwclock -w --localtime
[root at Nemesis david]# hwclock -r
Fri Jan 18 22:49:54 2002 -0.821966 seconds
[root at Nemesis david]# hwclock -r --utc
Fri Jan 18 16:50:07 2002 -0.765450 seconds
[root at Nemesis david]# hwclock -r --localtime
Fri Jan 18 22:50:15 2002 -0.220777 seconds
Here is where things really get screwy! The hardware clock gets set to
localtime (correct). Now let's see if Samba serves the correct time:
C:\WINDOWS>net time \\nemesis /yes
Current time at \\NEMESIS is 1-19-2002 5:00A.M.
The command was completed successfully.
Samba is still serving UTC. -- I don't get it. I'm either missing
something really basic (it's happened before) or I have a really big
problem with system configuration or there is a big bug somewhere. It
looks to me like Samba is serving time from the system clock as UTC no
matter what the localtime/zoneinfo config is.
<snip>
Beer break
<resume>
Allright, let's check our config again before the next test:
[root at Nemesis david]# date
Fri Jan 18 23:39:44 CST 2002
[root at Nemesis david]# date -u
Sat Jan 19 05:39:47 UTC 2002
[root at Nemesis david]# hwclock -r
Fri Jan 18 23:39:54 2002 -0.353391 seconds
[root at Nemesis david]# hwclock -ru
Fri Jan 18 23:40:02 2002 -0.487127 seconds
[root at Nemesis david]# hwclock -r --localtime
Sat Jan 19 05:40:14 2002 -0.402610 seconds
[root at Nemesis david]# cat /etc/sysconfig/clock
ZONE=America/Chicago
UTC=true
ARC=false
[root at Nemesis david]# cat /etc/timezone
America/Chicago
[root at Nemesis david]# ls -al /etc/localtime
lrwxrwxrwx 1 root root 35 Jan 18 22:34
/etc/localtime -> /usr/share/zoneinfo/America/Chicago
Now, lets remove the /etc/localtime link and see what we get from Samba:
C:\WINDOWS>net time \\nemesis /yes
Current time at \\NEMESIS is 1-19-2002 5:49A.M.
The command was completed successfully.
Still UTC no matter what! :-() ! (#^%&$# -- long string of cuss words --
^$#%^$&^!, you get the picture)
Well, just how do you get Samba to serve the correct time to WinXX
clients over a LAN? Let's try this:
#rm /etc/localtime
(now manually set the system time to local time by reading the time
from a Windows machine)
[root at Nemesis david]# date 01190021.00
Sat Jan 19 00:21:00 /etc/localtime 2002
[root at Nemesis david]# date
Sat Jan 19 00:21:22 /etc/localtime 2002
[root at Nemesis david]# date -u
Sat Jan 19 00:21:31 UTC 2002
[root at Nemesis david]# hwclock
Sat Jan 19 06:21:39 2002 -0.982489 seconds
[root at Nemesis david]# hwclock --localtime
Sat Jan 19 06:22:03 2002 -0.776325 seconds
Let's see if the time served by Samba is really the correct time now:
C:\WINDOWS>net time \\nemesis /yes
Current time at \\NEMESIS is 1-19-2002 5:49A.M. (At last -- the
correct time is served!!)
The command was completed successfully.
Well now, what happens if we recreate the link for localtime
[root at Nemesis david]# ln -s /usr/share/zoneinfo/America/Chicago
/etc/localtime
[root at Nemesis david]# date
Fri Jan 18 18:36:40 CST 2002
[root at Nemesis david]# date -u
Sat Jan 19 00:37:11 UTC 2002
[root at Nemesis david]# hwclock -ru
Sat Jan 19 00:37:33 2002 -0.318901 seconds
[root at Nemesis david]# hwclock -r --localtime
Sat Jan 19 06:37:48 2002 -0.792366 seconds
All just as it should be because based upon /etc/sysconfig/clock
'UTC=true' the system clock thinks it's in UTC. The hardware clock is
fine. The only problem is that in this configuration there is a complete
mismatch between the system clock and the hardware clock. The system
clock is set to 'localtime' and the hardware clock is set to 'UTC'. This
renders rdate, ntpdate and xntpd USELESS. Because when you use ntpdate
or xntpd to update the time to the system time is returned in UTC and
the system relies on the localtime softlink to provide the correct local
time for the system. Which, in turn, hoses the Samba time server into
serving UTC regardless of what the localtime softlink is set to. Not
good ....
Now I may be missing something simple, and if that is the case, please
feel free to flame me royally -- at least I will learn something. But if
everything looks OK, then, Houston -- we have a problem...
Ok, so what have I learned?
(1) It appears to me that Samba serves time based upon the system
clock;
(2) Regardless of what the tz setting is, Samba is going to serve
the 'actual' time stored in the system clock regardless of the tz info;
(3) As a result/consequence of (2) above, Samba ignores the tz
setting when serving time; and
(4) All of you who are telling me that you have your server
hardware clock and system clock set to UTC and are relying on the tz
setting to have Samba serve the correct time to your windows clients ---
I WANT TO KNOW HOW IN THE HECK YOU ARE DOING IT!!!!
In the immortalized words of Tom Hanks: "That's about all I have to say
about that."
I hope this is helpful, at least somewhat thorough with regard to the
problem I am experiencing. And I really hope that someone smarter than I
can point out to me, diplomatically of course, where I have my "CRI."
P.S. (CRI = cranal rectal inversion)
--
David C. Rankin, J.D., P.E.
RANKIN * BERTIN, PLLC
1329 N. University, Suite D4
Nacogdoches, Texas 75961
(936) 715-9333
(936) 715-9339 fax
More information about the samba
mailing list