DST Change

Nope.  It sure hasn't.  Nice of them to think about us, don't you think?

Nope.  It sure hasn't.  Nice of them to think about us, don't you think?

Nice attitude [;)]

I contacted support a while back about this. The following is me paraphrasing what they told me: They aren't releasing an update for V5 that would address the DST change. They were, at the time, working on the V6 update. V7's already compliant.

We're still on V5. So I think it's either change it by hand, or try something like this:

#!/bin/sh

wget 'elsie.nci.nih.gov/.../tzdata2007c.tar.gz'
mkdir -p /tmp/tzdata
tar xf ./tzdata2007c.tar.gz -C /tmp/tzdata
cd /tmp/tzdata
zic -d /tmp/zoneinfo northamerica
cp /tmp/zoneinfo/EST5EDT /usr/share/zoneinfo/
cp -r /tmp/zoneinfo/America/* /usr/share/zoneinfo/America/
ln -fs /etc/localtime /usr/share/zoneinfo/EST5EDT
zdump -v /usr/share/zoneinfo/EST5EDT | grep 2007
echo '------------------------'
zdump -v /usr/share/zoneinfo/America/New_York | grep 2007
echo '------------------------'
zdump -v /etc/localtime | grep 2007
cd /tmp
rm -rf zoneinfo/ tzdata/
echo "Update completed"


Which I've not done, because tho I think it'd fix the issue I don't have a dev-environment v5 system setup to test it with.

Daylight Savings time automatic change has been added to V6.304

Where is it? No announcements yet. IMO, this update is at least 2 weeks late. No one in their right mind will update a production system on a Thursday or Friday before a weekend.

Where is it?

Go into webadmin, to the System >> Up2Date page and click on Start to prefetch the update, and you'll get it.

That seems to work. Couldn't fine the update on any of the mirrors when I checked an hour ago, either.

Where is it? No announcements yet. IMO, this update is at least 2 weeks late. No one in their right mind will update a production system on a Thursday or Friday before a weekend.

I did the upgrade to 6.304 on both my office and home Astaro boxes. The only problem I experienced was that  today's network stats disappeared, leaving today's networking strip charts with no data. But that is a relatively minor issue.

Having left my right mind behind many years ago, I'm free to update my Astaro boxes whenever I want.  [:D]

LOL. Luckily they appear to have minimized the number of changes for this release. We have pushed it out to non-critical sites with only one issue so far. clamav seems to be dying/restarting every hour and it's generating email alerts.

Will open a new thread for that one.

6.304 was just released to deal with it.

6.304 doesn't even install on 2 of our 6.303 systems... it just says "done" and doesn't install anything.  Methinks there are some corrupt packages on the up2date server.  And the clamd issues concern me.

Does it say anything in the Up2date log on the machines that failed? or perhaps the middleware log, since up2date says it needs to restart the middleware? Also, the clamav issue can be fixed with a reboot. See up2date.astaro.com:

"Note (March 9th):
Due to symbolic link problem within the new Clam AV scan engine the Up2Date was reloaded.
There is no change of the content or functionality, just a corrected link.
If you already installed 6.304 and experience problems, please reboot the ASG - this will fix the problem.
We apologize for the inconvenience!"

6.304 doesn't even install on 2 of our 6.303 systems... it just says "done" and doesn't install anything.  Methinks there are some corrupt packages on the up2date server.  And the clamd issues concern me.

Looks like Astaro went and re-rolled 6.304 again.

6.304 doesn't even install on 2 of our 6.303 systems... it just says "done" and doesn't install anything.  Methinks there are some corrupt packages on the up2date server.  And the clamd issues concern me.

Looks like Astaro went and re-rolled 6.304 again.

The ClamAV restart issue can be solved with a restart of the Astaro box.  It's some issue with a symbolic link.

After manually deleting the "bad" 6.304, I manually kicked off another up2date... this one worked.. and it was GPG signed at 8:50EST.. so they "re-rolled" it... bad thing is I have about 7 customer ASGs to update, who wants to bet they all prefetched a "bad" 6.304 package?  Argh!  (I be a pirate now)

After manually deleting the "bad" 6.304, I manually kicked off another up2date... this one worked.. and it was GPG signed at 8:50EST.. so they "re-rolled" it... bad thing is I have about 7 customer ASGs to update, who wants to bet they all prefetched a "bad" 6.304 package?  Argh!  (I be a pirate now)

Bruce, if you monitor all your systems with ACC you can start a up2date prefetch from there on all systems with a couple clicks, ASL/ASG will detect that the md5sum changed and redownload the update.

If not, just log into each one and prefetch the update again.

No need to delete the "bad" update.

If you want long enough, ASL/ASG will do this on its own.

In this case no, running another prefetch did not work... Astaro support told me where to go to delete the corrupt files.

Weird, that worked for me on 2 systems...

It should do this on it's own. If the downloader notices that the file that is offered by the server has a different checksum than the one that you have locally, it assumes that the file is broken, and will remove it automatically before downloading the new one.

I understand what you're saying... but since Astaro was changing the images that morning (from my understanding... too bad they aren't testing those when they deploy them to the various up2date servers... we've had this problem before), my box was probably randomly hitting a server that had not had it's package updated... so Astaro support told me what to do to force it, and it did involve manually deleting the bad package.