About Archive Tags RSS Feed


Dwayne, I think you might be colorblind.

13 April 2010 21:50

It is unfortunate that most server-packages don't seperate out their init scripts into separate packages:

  • foo
    • Contains the server binary, associated config files, and libraries.
  • foo-run or foo-server
    • Contains the init script(s).

Right now its a real pain to have to modify things like /etc/init.d/ssh to launch two daemons, running on two different ports, with two different configuration files.

Running multiple copies of SMTP daemons, databases, and similar things is basically more complex than it has to be, because our packages aren't setup for it.

If you maintain a daemon please do consider this, failing that honoring a flag such as "DISABLED=true" in /etc/default/foo would allow people to use their own /etc/init.d/foo.local initscript. (That's not perfect, but it is a step in the right direction.)

ObFilm: Little Miss Sunshine.



Comments on this entry

icon mirabilos at 17:02 on 13 April 2010


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

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.

icon Np237 at 18:00 on 13 April 2010

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.

icon Steve Kemp at 18:02 on 13 April 2010

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.

icon Daniel Kahn Gillmor at 18:11 on 13 April 2010
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.

icon Jonathan Carter at 19:53 on 13 April 2010

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.

icon Matthew W. S. Bell at 22:58 on 13 April 2010

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

icon Steve Kemp at 23:52 on 13 April 2010

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.

icon -dsr- at 00:14 on 14 April 2010

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.

icon Daniel Kahn Gillmor at 04:56 on 14 April 2010

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):


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?

icon Frank lin Piat at 07:37 on 14 April 2010

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)

icon Steve Kemp at 10:03 on 14 April 2010

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.)

icon Daniel Kahn Gillmor at 15:48 on 14 April 2010

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.