[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kai Hendry wrote: > On Thu, Jun 12, 2003 at 12:01:06PM +0100, Simon Waters wrote: > >>One that burnt me the other day was that as far as I can discover Debian >>apt, doesn't log activity. If true this is a serious issue for some >>potential commercial users of Debian. > > > apt-get update | tee moo.txt > > perhaps script too? Or an alias, but what I mean is if I am handling packages, it should log package handling. Your above approach doesn't fix it if while I'm away Neil comes in and does "dpkg -i /mnt/cdrom/packagesimonshouldhaveupgradedlongago". He might forget the "tee" if he apt'ed, or bypass my aliases, and what happens if it runs out of disk space due to the logging.... I appreciate these issues can be made up by good procedures, that was the Microsoft line at the W2K launch - I paraphrase "the real problem with data centre NT, is that NT admins have no experience of data centre procedures" - but even those who do struggled to find out what files were upgraded by what patch, when, and who was logged in doing it at the time (Administrator of course). So good audit trails should be an option, and probably should default on. Maybe I'm old fashioned and should just design to put root disks on network storage, but then my network storage system had better have stunning change control itself. Coz I've been there when the network storage device revealed the bug in that last firmware update, and it wasn't pretty, even if it did fix an NFS v3 bug :-( > The way I see people updating debian is like: > for i in machines: > ssh i -c some_command > > Something like that... Done that, been there, with HP-UX and swinstall, but Debian has tools more like the expensive HP ones, which I haven't tried out yet for managing groups of computers under Debian. The HP tools let you schedule trial updates to ensure dependencies are okay, and you have enough disk space in each logical volume. So be interesting to see how Debian compares. So you can designate some of your HP workstations as "test" boxes, and then schedule a test upgrade to make sure the upgrade will work, before scheduling the genuine thing for when the development team are asleep (everyone always tests things on the developers systems in my experience - "developer" is a little known synonym of "guinea pig" - probably because they often bring fixes or workarounds with their bug reports). swinstall (and friends) were the best of such tools in the proprietary world I saw, this was all "enterpise quality" software back in the mid 90's. Sure none of it is terribly clever, and you can get 99% with cron and a few scripts, but in enterprise environments, putting your own scripts in for this sort of thing is hard work, not least because it is tough for the little guys to test. Ironically schools and universities would make an ideal test site for such software, as they face the same issues, but downtime tends to be less critical. Don't get me wrong, I think Debian is superb, just want to learn (or fix) specific aspects. It is interesting how slow progress in the proprietary Unix world is in comparison to free software. Although I note that Debian stable/testing turn over is very slow, and solid, given the tagrets they set themselves the results are definitely comparable to proprietary Unix system vendors. Although an interesting question is was Unix slow because it tried to be unified. GUI development seemed to die after every vendor went with HP-VUE (oops CDE). This battle between standardisation and diversity seems to be my theme for the month. Simon -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+6I5YGFXfHI9FVgYRAu7wAJ0ZM6Q5dZtdmDgfhicQ/4l7T6DXcwCgrxC6 HveOxxhk5FGoZRwEyLLI2ig= =MXWx -----END PGP SIGNATURE----- -- The Mailing List for the Devon & Cornwall LUG Mail majordomo@xxxxxxxxxxxx with "unsubscribe list" in the message body to unsubscribe.