Daniel Palmer wrote: > Peter Valdemar Mørch wrote: >> Ok, but what is the alternative? I find that without dist-upgrade, I >> end up with a constantly growing number of packages in the >> "The following packages have been kept back" >> category. > Jamming dist-upgrade into a cron job will cause problems when a package > doesn't upgrade cleanly.. for example mysql is getting upgraded, the > server will stop and not come back up. Even worse if a kernel upgrade > doesn't create the initrd correctly.. basically too much is going on and > someone should be checking on it. Too much is going on in testing, unstable and experimental but not in the stable branch. Also, in a stable branch (etch at the moment) upgrade and dist-upgrade should behave equally. What I mean is that in 99.8% of the updates in a stable branch you won't have that kind of problems. Of course you'll have monitoring system for those 100s of servers and eventually if anything breaks you'll notice. And it's even easier if those 100s of machines are nearly identical to have one in the test lab and first run the updates on it and then on the rest. But it again all comes down to what you are running, what is important for you and what are your priorities. That's just my opinion. > > I don't think apt is meant to be automated. Updating package lists and > pre-caching the packages you'll need later with cron-apt speeds things > up though. The best option would be to use one of the applications other > people have mentioned to *manage* mass updates. The ideal solution is to > sit down once a week, manage an update and have the result propagate to > your machines. Looking at the screenshots, fai seems to do exactly this. > RHEL has a web-based system that does exactly the same but at a price. :P -- regards, Georgi Alexandrov key server - pgp.mit.edu :: key id - 0x37B4B3EE Key fingerprint = E429 BF93 FA67 44E9 B7D4 F89E F990 01C1 37B4 B3EE
Attachment:
signature.asc
Description: OpenPGP digital signature