In <i573lc$sa...@speranza.aioe.org>, s. keeling wrote: >Joe <j...@jretrading.com>: >> Kamaraju S Kusumanchi wrote: >> > s. keeling wrote: >> >> T o n g <mlist4sunt...@yahoo.com>: >> >>> Where is the recommended place to read about Debian updates >> >>> that would affect end users? >> >> >> >> I think it's about this time that some jerk pipes up and says >> >> production machines serving users should be running stable, the >> >> raison d'etre of debian. Sorry. >> > >> > Here you go! Production machines serving users should be running stable! >> >> Indeed so, but for that to happen, a lot of people must do >> production-type work on sid and testing. How else do the bugs get >> reported? > >Users don't know how to report bugs. Hell, I often fsck it up, and >I've been running Linux since '93.
Production systems shouldn't be running testing/unstable. Your clients/users probably don't know or care what a "Debian" is. Your administrator(s) should, and should be capable of reporting bugs. Testing/unstable is good for, well, testing systems (or VMs). These can fail without impacting users and you can file bugs with Debian to get issues addressed before they become an issue in stable. Every so often, you should "throw away" your testing system, close a production system, and upgrade to testing -- to test the upgrade path, and file bugs on it. Of course, you'll do this (at least) a couple of times on release week to write and test the final upgrade procedure so you can move from oldstable to stable. >> What would probably help in that process would be some kind of >> organised rollback of the last batch of updates, without having to >> do a full backup-restore of the whole OS. Restore Points, anyone? > >Buy a Mac. Well, actually, this is possible under certain Linux setups, but no tool really does it. The process would go something like this: 1. Freeze all filesystems. This makes them sync to "disk", and causes writes to "hang" temporarily. 2. Take an LVM snapshot of each file system. 3. Thaw all filesystems. Writes will now finish, write caching begins again. (Your LVM snapshots now serve as a restore point.) 4. Do package manager actions. You can roll-back by restoring from the snapshots. Keeping multiple "restore points" around can poorly affect performance and boot times, so only a few should be kept around. When you do a restore, you will *lose* *everything* that happened since the "restore point" was taken. Depending on how early you catch issues, this may not be much of a problem. You can do selective restoring, but that can cause problems for the same reasons downgrades cause problems; new packages may upgrade data or configuration to a format the old package does not understand -- it is impossible to "update" the old package with this information, the old package is already "in the wild". (LVM isn't the only way to do this; btrfs and some other file systems support snapshots internally, and those are usually less of a performance issue) If you are thinking of implementing this but then not restoring /home (.e.g; *any* writable file system can have the same arguments made for and against it), you might as well just downgrade packages instead. aptitude/apt/dpkg/debconf can be queried for what packages are installed and how they were configured and such information can treated as a snapshot -- official packages of any age (with very few exceptions; at least since the service started) can be had from snapshot.debian.org. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
