Hi,

I have the same problem at work, also for things like
when you need the stuff installed but don’t want it
started.

I think DISABLED in /etc/default/foo is a step into
the right direction, but I personally like flag files
more, since you can put them into place using a company
configuration package.

As of today, I use dpkg-statoverride on things like
smbd and nmbd, postgresql, apache2, and a simple script
with which the users of the PC can disable/enable them.

This also helps a lot launching daemons as user. For example gnome-user-share can launch an apache2 instance, and it required splitting the apache packages.

np237: Exactly.

That's what I'm doing for hosting my websites - I have a dedicated instance of thttpd running for each site upon my box, running as its own UID.

I wrote a similar-but-more-verbose post about the same idea a little while back.

I wonder if it would be useful to try to formalize that convention through a DEP or something.

I like the way that dnsmasq is packaged. dnsmasq-common contains the binaries, and you can install just that if you manually want to control startup, etc.

Then there is the dnsmasq package, it depends on dnsmasq-common and contains the actual init scripts.

This way, and end user can simply install dnsmasq and it will work out of the box as expected, or a more experience user/admin who wants to do something more specific can just install the -common package.

This is an example of general (package) managed configuration.

Daniel, thanks for the link. I did think I'd heard of this idea before but I couldn't recall where it was. Formalising the idea seems like a good idea, but I guess the first step is achieving a consensus that other people would be happy with it. I think filing a couple of wishlist bugs against server packages, to allow the maintainers to comment, would be relatively simple way of achieving that.

Jonathan, the dnsmasq package is a great example of things working the way I wish more would.

I think the Apache convention of /etc/package/conf.d/, where every extant file in conf.d is included in the startup is a pretty good idea.

For more elaborate systems, I use Tuttle (http://dev.smartleaf.com/tuttle/tuttle.html) which can handle configuration of several services, related cron jobs, directory trees, and so forth as a unit, doing variable substitution to turn generic config files into specific instances.

Steve, it looks like this is actually already happening:

mysql-server just moved to mysql-server-core-5.1 (tools, no initscripts) and mysql-server-5.1 (initscripts):

http://bugs.debian.org/513382

apache made the split a little while ago, into apache2.2-bin (tools, no initscripts) and apache2-mpm-whatever (initscripts).

puppet made the split into puppet-common (tools, no initscripts) and puppet and puppetmaster (two different sets of initscripts, depending on the services needed for the machine).

maybe file a bug against thttpd to move /usr/sbin/thttpd and thttpd.8.gz into the thttpd-util package it's already shipping?

Separating daemon and init.d script is certainly a good idea, as it allows to install multiple virtual package at the same time (httpd for instance).
The DISABLE is certainly an interesting feature (even though, it duplicates update-rc.d feature).

Did you investigate in multiple instance?
For example, the apache init script, when invoked from the symlink /etc/rc2.d/S23thttpd.foo, could use /etc/default/thttpd.foo configuration file. For the remaining, /etc/init.d/apache2 has some nice ideas for supporting multi-configurations)

I'm tempted to adopt thttpd and I could then do that movement... Ponders.

I hadn't realised so many packages were making the split already, and it is definitely good that MySQL has.

I think the other outstanding one that I care about is openssh-server - I do often want two copies of that running.

(One on a public IP running key-only auth, and one on an internal VPN IP with passwords available.)

I'd also love to see openssh-server split out from its init scripts, because we're using it as a build-dependency for monkeysphere (running the test suite against sshd -i over a unix-domain socket) and it's silly to launch a service for a build-dep.

However, you can probably solve your sshd plan more easily with the current sshd_config, using and Address-based Match clause to govern PasswordAuthentication.