Bug 167273
| Summary: | dhclient-script broken system time | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nathan G. Grennan <redhat-bugzilla> | ||||||
| Component: | dhcp | Assignee: | Jason Vas Dias <jvdias> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | |||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4 | CC: | sundaram | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2005-10-09 16:20:46 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Created attachment 118331 [details]
New localtime that broke time
Created attachment 118332 [details]
Original localtime that was renamed by the script
I don't think this should be the default, and there should definitely be an option to turn it off. 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. 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. 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. (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. 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. 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. |
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: