On Monday 28 February 2011 14:42:41 John A. Sullivan III wrote: > That is ultimately what led us to Debian. It has been our first major > experience with Debian and we have been quite pleased with it as the > best balance for a desktop OS thus far when we combine stable, > backports, and occasional bits from testing with a well designed > preferences file. Very, very interested in other thoughts - John I run multiple Debian systems that have stable/testing/unstable/experimental and all the add-ons volatile/backports/security/updates/proposed updates. I use a preference file that keeps me with stable+security+volatile/updates mostly and for the times when I want something out of one of the other repositories tracks upgrades so that I get security updates in a timely manner. I use unattanded-upgrades with a lightly massaged configuration, one custom one-line cronjob, logcheck plus a tiny bit of custom logcheck rules, and a good tripwire policy to keep them up-to-date and provide baseline reporting. It would take some effort, but not much, to extend this to 100 systems. At that point, a new stable release would take a lot of effort to manage. Throw in nagios and a bunch of custom rules, determine a process for managing the stable upgrade including more automation, tie all of that into a ticketing system that includes a mass of scripts to pre-analyze the reports and will reduce communication overhead (since you'll need more that 3 administrators at that point) and you can probably scale to 1000, maybe more depending on how similar the systems are. Administrators will be remote for virtually all of these systems, have a plan for accessing each system when it's primary network connectivity is down and going no-site if absolutely necessary. Beyond that point, the number of administrators gets too large, and you'll certainly start running to to too many slightly different configurations / configuration sets. Specialization and division of responsibility are key here, and SELinux or AppArmor should be added to the environment to enforce divisions of responsibility so no one team is stepping on another. Debian security is good, but your organization likely has quite a large vulnerability cross section; your own security team should be doing active penetration testing on your own systems, monitoring disclosures, and helping the Debian security team, particularly testing fixes to see if they introduce regressions and testing exploits to see if they affect (your) Debian systems. At all stages, particularly when using Debian, your administration staff needs to be encouraged to interact with the community around issues they encounter and to contribute as much as possible so that your system diverge as little as possible from the well-tested releases. Even if your business is software, it is unlikely to be providing a UNIX-like OS; whatever "IP" is produced by your administration stuff is not a competitive advantage in your market, so it is better to share and integrate it than it is to maintain it on your own. Many FLOSS projects are slightly averse to breaking someone's working setup if they know it exists and contributors will often provide backwards compatibility and/or detailed migration instructions if they know there's a need for it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.