[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Configuration Packaging System

On Wed, 27 Feb 2008, Ian Jackson wrote:

Timothy G Abbott writes ("Re: Debian Configuration Packaging System"):
All of the important problems with our dpkg-divert based configuration
package system that have been discussed in this forum are problems for any
configuration mechanism other than debconf preseeding.  Debconf preseeding
is unacceptable for site configuration because it is insufficiently
general (often things need to be configured that are not set up as debconf

I think a better approach is just to have a package which writes stuff
over the configuration files without diverting them.

Such a package is putting itself in the position of the system
administrator, which is presumably what you intend.  That's not
appropriate for a Debian package but for a site-specific configuration
setting system it's OK I think.

If we were running a cluster of identical machines, such a system would probably work. But we actually don't intend to be in the position of the system administrator; we just want to provide defaults in a decentralized environment with many different sysadmins. This is a harder setting, and I think our users find it useful that they can run etch or sid or even Ubuntu as needed to get their work done and benefit from the site defaults.

Our current deployment is on a few hundred machines, primarily personal machines owned by individuals who want to be able to access MIT services, but who do their own system administration. We offer various metapackages with different levels of login integration, and we support all Debian and Ubuntu releases from sarge until present from a single set of source packages, a valuable feature of the configuration package creator interface of our system.

So, our goal is to provide our users with the same opportunities to override our configuration defaults as they would have had if Debian had been providing them instead. Using the Debian packaging system for this configuration is a good way to achieve this.

You do have to deal with conffile prompts and other kinds of things
that happen when software (package maintainer scripts, and dpkg) spot
you've modified the files.  But if you do all of your installations in
a noninteractive mode (with a noninteractive debconf frontend and with
dpkg configured not to prompt about conffiles) you get predictable
behaviour which you can override as you like.

We've found it pretty useful to be able to install our configuration on an existing system.

	-Tim Abbott

Reply to: