Lucas King wrote:
i am looking for information as to how time is maintained on a Linux box.
i am currently running Redhat 7.2 (i am not sure if this is relevant) on a box on which i have set up a time server for a network. the time server delivers its time, via NTP, as UTC. i set up the client, being in Sydney, to add 10 hours to the UTC time that it receives. this is fine when on Eastern Standard Time (EST). however, things get more complicated when Daylight Saving Time (DST) kicks in. i don't want to go around to every client and adjust the added time from 10 hours to 11 hours. what a pain in the neck.
You can't.
At its heart, in what we call the "system clock", Linux keeps the time in UTC (what you may know as Greenwich Mean Time). The Network Time Protocol distributes the time in UTC too. When a program asks for the time (say via the localtime() C function) the UTC system clock is read and adjusted to the local time. This adjustment is done by the timezone subsystem. This is a set of timezone data files in /usr/share/zoneinfo and a configuration file /etc/localtime. The configuration file is traditionally a symbolic link to a timezone file in /usr/share/zoneinfo (but Red Hat Linux copies the file instead). An individual user can alter their timezone as can an individual terminal -- both using the TZ environment variable. This allows for interstate users and interstate terminals. In RHL you can find the timezone data files in the glibc-common package. In RHL the timeconfig program (in the timeconfig pakage) is used to establish /etc/localtime. When the machine is shut down the system clock needs to be written to the clock-calendar chip. A small battery maintains the time and date on this chip. Unfortunately, Windows likes to keep the time on this chip in localtime, (a very dumb choice). UNIX operating systems keep the time on their clock-calenadar chips in UTC. So Linux needs to be able to do both -- one to be compatible with dual-boot Windows machines and the other to be compatible with dual-boot UNIX machines (such as a Sun or Alpha). Thus the question "Hardware clock set to GMT" asked by timeconfig and the --utc and --localtime arguments to hwclock. If you have a Windows dual-boot machine, set the hardware clock (another name for the clock-calendar chip) to localtime, otherwise set it to UTC. If you select local time for the hardware clock then when the system time is written to the hardware clock the system time will be run through the timezone data to get the local time and the local time will be written to the hardware clock. Now, the timezone files know about the change to daylight savings. They know about this because there is a worldwide collection of timezone information maintained at ftp://elsie.nci.nih.gov/pub/ in the files starting with tz. The timezone information in Linux is occassionally refreshed from this collection. So why would the time be wrong at a timezone change: - programs started on one side of a timezone change are still running. - you are running the hardware clock on local time and you didn't update it. If you take time from an external NTP server the quick fix is: service ntpd start hwclock --localtime --systohc The better option is to keep the hardware clock at UTC, which is why this is recommended unless you need to dual- boot Linux and Windows. - the timezone data files could be wrong. Download the latest tzcode file from elsie and check. Lots of OSs use the tzcode files, so I doubt that these are wrong for any date in any part of Australia from about 1970. - RHL may not be using the latest timezone file. Short-term fix: replace the files with the tzdata files from elsie. Long-term fix: keep distribution at or near latest release.
is it possible to have the network delivered time adjusted depending on whether it is EST or DST?
No. NTP uses UTC. There's no practical choice. Think about your average sysadmin being asked to calculate their offset from UTC. Think about the odds of them getting it right all of the time. Arrrgh. Much better to have a single on-the-wire time so that timezone configuration errors only effect one machine. Regarding your question about maintaining the zoneinfo files. This is a subset of "how do I maintain packages on my system" which you need to solve to avoid security incidents. Solutions abound -- all very nice because of Linux's modular structure. Individuals with cash like Red Hat Network, individuals without cash find autorpm nice, and system administrators with tens to thousands of machines to maintain use autoupdate (as this allows them to insert their own RPMs, a nice way of applying corporate-wide configuration standards, such as which NTP server to use).
The information contained in this e-mail message and any accompanying files
is or may be confidential.If you are not the intended recipient, any use, dissemination, reliance,forwarding, printing or copying of this e-mail or any attached files is unauthorised.This e-mail is subject to copyright. No
part of it should be reproduced,adapted or communicated without the written
consent of the copyright owner.If you have received this e-mail in error,
please advise the sender immediately by return e-mail, or telephone and
delete all copies.Fairfax does not guarantee the accuracy or completeness
of any information contained in this e-mail or attached files. Internet
communications are not secure, therefore Fairfax does not accept legal
responsibility for the contents of this message or attached files.
!^#%$#, you help someone and then they threaten to sue you. If I'd seen this before writing the above I wouldn't have bothered. -- Glen Turner (08) 8303 3936 or +61 8 8303 3936 Australian Academic and Research Network www.aarnet.edu.au -- SLUG - Sydney Linux User's Group - http://slug.org.au/ More Info: http://lists.slug.org.au/listinfo/slug
