Re: Managing large numbers (100+) of Debian-based machines
on 12:21 Thu 07 Apr, Laurence Hurst (L.A.Hurst@lboro.ac.uk) wrote:
> Hi folks,
> I am looking at possibly deploying Debian (or a derivative thereof) on
> a large number of machines (initially 80 but I fully expect the final
> number to end up being in excess of 100) which are intermittently
> connected to the network (due to multi-boot setup). I was wondering if
> anyone else has a large(ish) installation base and what tools they
> were using to manage the machines (especially when it comes to
> patching)? On this scale manual ssh methods become unmanageable, even
> using the likes of pdsh and before I even consider the fact the
> machines will not all be in Linux at any given time. Unfortunately I
> have no budget for this project so an Ubuntu/Landscape solution is not
> workable. Ideally something usable by non-Linux (but technically
> competent Windows) administrators would be nice (e.g. a "point and
> shoot" web-interface to mass deploy updates). Does anyone have any
> suggestions of existing projects which fit this bill or am I going to
> have to roll my own solution?
Basics:
- Deployment: FAI + PXEboot (especially for servers).
- Management: pdsh/dsh for ad-hockery is good. You'll need a tweaked
sudoers file (to be able to run at least diagnostic commands) for
management accounts. For real management...
- Puppet, chef, or cfengine. I'd lean toward puppet or chef. These
are used by a number of organizations especially for end-user system
management (Google makes extensive use of Puppet for engineering
desktops/laptops).
- A user-accessible ticket request system for end-user support.
Backed by ...
- A bugtracking and issues database (wiki). The ticket-tracking,
bugtracking, and wiki don't have to be fully integrated, though the
first two likely are. There's some separation of roles, though in
my experience the less between the first two the better. It's just
that some organizations have a lower tolerance for seeing the
sausage-making involved in issues resolution than others, and of
course, of learning a complex interface. A good BTS will offer
appropriate end-user and engineering views on the process.
- A host management database of some sort. Unfortunately I don't have
any recommendations as most I've seen are in-house, DIY systems.
I'd be very open to discussion of methods.
- A local Debian mirror, or at the very least, apt-proxy, to minimize
bandwidth utilization.
- Proper test/staging of new releases / updates, as well as a
designated "guinea pig" group for testing updates (some things just
can't be tested in an automated fashion), essential for end-user
deployments.
A bevvy of other things I'm leaving out, but I'd like to see what others
have to say.
--
Dr. Ed Morbius, Chief Scientist / |
Robot Wrangler / Staff Psychologist | When you seek unlimited power
Krell Power Systems Unlimited | Go to Krell!
Reply to: