Re: speculations to characterize issues for Debian Enterprise
Geoff Crompton <geoffc@trinity.unimelb.edu.au> writes:
> Russ description of this server class packages made me immediately
> wonder why he wasn't using puppet for that. Perhaps that is what
> Standford were doing before they started using puppet, and have
> continued their practice.
> Can you mention why you don't think puppet is the right solution?
> Clearly the defaults on any package will not suit every enterprise, and
> some customisation is required. Puppet can do that just as well as a vi
> session, or a local configuration package.
We use Puppet to manage anything that's a configuration file (well,
mostly; we install some cron jobs and init scripts in packages). We use
Puppet to install everything else. I like to have scripts and the like in
/usr/bin and /usr/sbin, managed like regular Debian packages.
I talked about this some in my talk at DebConf. It's overkill; you can
install scripts in /usr/local using Puppet. But I think it has a huge
advantage in training within a group to have a strict policy that anything
that isn't a configuration file goes in a package: it means everyone in
the group learns how to package, because they have to to change scripts
installed on the system. It also means that you can use the same
techniques for managing things as the Debian packaging system, which in
turn teaches people how to build regular Debian packages for more complex
things (like compiled software) that you don't want to manage via Puppet.
We do not use configuration packages. That's not what all those
server-class packages are. They're for installing locally-written
software and occasionally for managing package installations, since it's
way more efficient in Puppet to install a package with a bunch of
dependencies than to list a bunch of separate packages to install.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: