Bug 167273 - dhclient-script broken system time
dhclient-script broken system time
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dhcp (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-01 01:38 EDT by Nathan G. Grennan
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-09 12:20:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
New localtime that broke time (58 bytes, application/octet-stream)
2005-09-01 01:40 EDT, Nathan G. Grennan
no flags Details
Original localtime that was renamed by the script (1017 bytes, application/octet-stream)
2005-09-01 01:40 EDT, Nathan G. Grennan
no flags Details

  None (edit)
Description Nathan G. Grennan 2005-09-01 01:38:55 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.10) Gecko/20050719 Galeon/1.3.21

Description of problem:
  For some reason the section of dhclient-script below was called. It replaced "/etc/localtime" with a new copy and renamed the original to "/etc/localtime.predhclient". It caused the time zone to go from PDT to GMT-6. Instead of just setting the time 2 hours off that might be expected, the time was 11 hours off.

        if [ -n "$new_time_offset" ]; then
        #   DHCP option "time-offset" is requested by default and should be handled.
        #   The geographical zone abbreviation cannot be determined from the GMT offset,
        #   but the $ZONEINFO/Etc/GMT$offset file can be used:
            ((z=new_time_offset/3600));
            tzfile=/usr/share/zoneinfo/Etc/GMT`printf '%+d' $z`;
            if [ -e $tzfile ]; then
                /bin/mv -f /etc/localtime /etc/localtime.predhclient;
                /bin/cp -fp $tzfile /etc/localtime;
                /bin/touch /etc/localtime;
            fi;
        fi;


Version-Release number of selected component (if applicable):
dhclient-3.0.2-20.FC4

How reproducible:
Didn't try

Steps to Reproduce:
1. Haven't tried
  

Additional info:
Comment 1 Nathan G. Grennan 2005-09-01 01:40:09 EDT
Created attachment 118331 [details]
New localtime that broke time
Comment 2 Nathan G. Grennan 2005-09-01 01:40:56 EDT
Created attachment 118332 [details]
Original localtime that was renamed by the script
Comment 3 Nathan G. Grennan 2005-09-01 01:44:36 EDT
I don't think this should be the default, and there should definitely be an
option to turn it off.
Comment 4 Nathan G. Grennan 2005-09-01 01:47:03 EDT
In my case it was a cable company dhcp server that likely triggered this. I
don't agree with the idea of letting the cable company set my /etc/localtime. I
don't like /etc/resolv.conf being replaced either, but at least it is more
logically and has PEERDNS=no to disable it.
Comment 5 Rudi Chiarito 2005-09-06 09:51:56 EDT
It looks like the offset of the GMT timezone files has the wrong sign. I.e. I am
in Central Time, but the GMT-6 file seems to result in a time that is 6 hours
ahead of GMT, not behind. Bug in tzdata?

Even then, this doesn't seem to take daylight saving time into account, at least
with my isp's dhcp server. Right now it reports -6, which is CST, not CDT, which
is GMT-5.
Comment 6 Brian Gerst 2005-09-12 10:47:27 EDT
My time keeps moving forward by 11 hours as well:
$ date; TZ=EST5EDT date
Mon Sep 12 19:36:56 GMT-5 2005
Mon Sep 12 10:36:56 EDT 2005

My DHCP server is a FC3 box.  This needs to be an opt-in option.  It is only
useful for mobile users.
Comment 7 Brian Gerst 2005-09-12 10:50:38 EDT
(In reply to comment #6)
> My time keeps moving forward by 11 hours as well:

I meant 9 hours, sorry.  Again it looks like it's adding 5 hours instead of
subtracting, and not taking DST into account.
Comment 8 Jason Vas Dias 2005-09-12 19:23:00 EDT
This bug is now fixed with dhcp-3.0.2-22.FC4 (FC4) and dhcp-3.0.3-6 (Rawhide).

I can understand why you would not want the machine time zone set on your 
home computer by your cable provider .

The time-offset processing now must be enabled with a setting in an ifcfg- file 
or the /etc/sysconfig/network file:  DHCP_TIME_OFFSET_SETS_TIMEZONE=yes .

The rationale behind providing the time-offset support was that time-offset
is a parameter requested by dhclient by default, and was not being handled
by the dhclient-script. It could be useful for people with networks of 
machines spanning multiple timezones, or with ensuring that groups of machines
get the same wall-clock time, and when setting the NTP server parameters with
DHCP. I wasn't expecting that ISVs providing DHCP service to home computers
would set this option .

The problem was that while the $zoneinfo/Etc/GMT* files are named with 
positive hours east of Greenwich, they contain "seconds west of Greenwich" -
so the GMT-5 file contains 'gmtoff=18000' (GMT PLUS 5 hours), and the GMT+5 
file contains 'gmtoff=-18000' (GMT MINUS 5 hours), which is highly non-intuitive
and possibly a tzdata bug - sorry for the mistake.

The server should be taking account of DST in the value it specifies for 
time-offset - when told to be at a certain time-offset from GMT, the client
should not modify that value based on what DST it was at - GMT has no DST.

dhcp-3.0.2-22.FC4 will be in FC-4 updates tomorrow.
Comment 9 Fedora Update System 2005-09-12 23:56:53 EDT
From User-Agent: XML-RPC

dhcp-3.0.2-22.FC4 has been pushed for FC4, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.