what an idiotic article
|
| Author | Content |
|---|---|
| herzeleid Mar 10, 2007 8:14 PM EDT |
duh - short answer? yes. While the article writer makes it sound as though DST changes were problematic for linux, the fact is that the linux systems were the quickest and easiest fixes. The vendors automatic updates handled it all transparently, and with a lot less fuss than what the windoze peecee admins had to go through. Solaris DST updates were no walk in the park either BTW. |
| jimf Mar 10, 2007 8:37 PM EDT |
What FUD. Everything was fixed for DST in Debian a month ago. |
| tracyanne Mar 10, 2007 9:28 PM EDT |
FUD indeed, I got the DST updates for Mandriva, and i don't even need them. |
| ml2mst Mar 11, 2007 12:35 AM EDT |
LOL! this article is one load of crap. This guy even beats our cola trolls (comp.os.linux.advocacy). What a joke :D |
| cr Mar 11, 2007 12:43 AM EDT |
I did it manually on a coupla the old boxes I've got here, following SJVN's article, then smartened up and scripted it. scp the script and the tzdata tarball over to the target machine, then shell in and... #!/bin/sh # # update_tzdata --crb3 09Mar07/10mar07 # # SJVN's steps, modified. # for some reason, wget is having a problem fetching from demonhouse... # well, then, scp it along with this script to $TARGET/root, then # move it into place. script turns 4 minutes of work into 15 seconds, # as long as there's host-level ssh-auth in place. okay so far on # redhat, MEPIS/debian and slackware boxen. # mkdir /tmp/tzdata cd /tmp/tzdata mv /root/tzdata2007c.tar.gz /tmp/tzdata/ tar -zxvf tzdata2007c.tar.gz zic -d zoneinfo northamerica cd zoneinfo cp -r * /usr/share/zoneinfo/ mv /etc/localtime /etc/localtime-orig ln -s /usr/share/zoneinfo/America/New_York /etc/localtime echo ---------------------- zdump -v /etc/localtime | grep 2007 echo ---------------------- echo Check that. Reboot if it looks good. I'll probably spend the next week occasionally bringing up boxes, running this and putting them away again. No biggie. |
| dinotrac Mar 11, 2007 5:29 AM EDT |
Come on you guys! This shameless and idiotic fanboi crap doesn't do anybody any good. This morning, when I sat down to my machine, it went something like this: "Hey!! What are you doing down here at this hour." "It's 7:00. I'm always up by now." "What do you think I am? Some kind of Windows tramp? I can read the clock. I'm also smart enough to know it's really 6:00. Just because you fool people can fool yourselves doesn't mean I should have to suffer, too." "Sigh." |
| stevem Mar 11, 2007 5:45 PM EDT |
I don't get it? The USA (only?) shifts it's DST start date and it's a "Y2K" event? Do you guys get some weird water or oxygen over there??? We shifted DST by ~ 2 months for the Sydney Olympics in 2000. Late last year West Australia finally switched DST on, creating (I understand) the first ever +0900 time zone. Apparently causing all sorts of havoc with various Windows applications that didn't allow for the possibility. If you want scary with DST shifts and the like, try talking to Windows Admins. Apply the patch to add for this year only. Reboot server. Note that outlook/exchange will get all your current meetings set for that period an hour out. When DST ends, remove patch. Reboot server. Note that outlook/exchange will get all your meetings an hour out. And gawd forbid you should ever try and re-read date/time stamps from the changeover period of years gone by. Can't be done. Solaris DST updates are a walk in the park. The downside with Solaris is that you do need to reboot as (from memory) core parts of libc or similar won't pick up the change without a bounce. When we last had a DST shift, for the Melbourne Commonwealth Games from memory, I choose not to patch/bounce our Solaris servers for that two week period. But then, I don't run exchange or outlook on Solaris either. ;-) |
| herzeleid Mar 11, 2007 9:26 PM EDT |
Quoting: cr script said: echo Check that. Reboot if it looks good.Eh, reboot a perfectly working linux box for no reason? LOL, I'd fire your @ss if you worked for me. |
| jimf Mar 11, 2007 10:27 PM EDT |
> echo Check that. Reboot if it looks good. Just for changing the time? Dito with the fireing ;-) |
| cr Mar 11, 2007 10:51 PM EDT |
> LOL, I'd fire your @ss if you worked for me.
> Just for changing the time? Dito with the fireing ;-) Rationale, from UPDATED: Switching your Linux systems to the new DST, http://www.linux-watch.com/news/NS6300294422.html, by SJVN: The final touch is to make sure all your daemon services know about the DST change. Many important background applications, like sendmail, postfix, MySQL, and BIND named, only load /etc/localtime -- that is, they only check the date and time -- when they're starting up. Rather than track such applications down, the best thing to do is to simply reboot the system. That way, all the services will start fresh, with the correct DST time information safely locked into your CMOS clock. None of the machines so touched are UPS-supported. None of them are HA or frontline to the Internet. The house is on dialup and the drops were done at no-carrier. Other than giving up brag-points on uptime, I don't see the problem in this situation. Educate me different, o wise ones. |
| Sander_Marechal Mar 11, 2007 11:32 PM EDT |
One word: NTP. OS dependent DST settings should be reserved for boxed that are physically incapable of accessing the net. |
| cr Mar 11, 2007 11:48 PM EDT |
> One word: NTP. > OS dependent DST settings should be reserved for boxed that are physically incapable of accessing the net. My Linux boxes are all GMT-set down at the hardware level. I have two machines whose ntpd's sync to the NTP pools on the Internet, when the Net's up, and each other; all the rest sync off of them, including the ones that just run ntpdate at startup. Other than a resync, and having to keep the Net connection up until both local masters show lock in an ntpq -pn report, I still don't see the problem. |
| dcparris Mar 12, 2007 6:38 AM EDT |
All I know is, my laptop had the correct time, but I actually did forget to set my clock. Go figure. |
| DarrenR114 Mar 12, 2007 7:10 AM EDT |
@DC -
When I woke up Sunday - the only machine in my house that had the wrong time was my Mother-in-law's MS-Windows XP PC. My wife's iBook, my Linux servers, and even my laptop (running Ubuntu) had the correct time. NTP is da bomb, baby! |
| hkwint Mar 12, 2007 10:59 AM EDT |
ntpq -pn is rather depreciated in my distro, but /etc/init.d/ntpdate does the trick. Also, you can refuse to set the clock one hour forth or back. I did when I was in Portugal for three days (time difference -1 hour compared to CET where I live). That way, either if you are one hour to early or one hour to late, you can always blame it on the time difference, and you not understanding it. If other people want to explain it to you, tell them about the earth rotating from east to west, or was it the other way? and how this affected your flying time, which became shorter - or longer? because the time difference. They soon will lose their understanding of it, and won't be mad you are an hour too late. |
| jezuch Mar 12, 2007 3:46 PM EDT |
The most fun is duel-booting Windows and Linux during the time change. Linux will consult NTP, keep the GMT in system clock and only tweak its delusion of time. On the other hand, Windows will be Smarter Than Thou and show a message "Look! I updated your clock for ya!", screw the system clock and confuse Linux after next reboot. Your differential backups will try to backup entire system, tripwire will (probably) panic and so on. Fun, I say! |
| jdixon Mar 12, 2007 4:30 PM EDT |
> ...duel-booting Windows and Linux... Is that a deliberate misusage? I think either you or someone else has used it before, but I second the motion that it's an excellent term in this case. |
| jezuch Mar 13, 2007 1:36 AM EDT |
I've seen it on lxer, and in this case it's deliberate :) |
| cr Mar 13, 2007 1:40 PM EDT |
Still waiting... |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!