Joachim Breitner's Homepage

Debian as a Linux distrubtion is all about integration and ease of management, which includes init-scripts. I’d like to propose a feature that might be helpful to quite a few system administrators while being non-disruptive to all others.

For a lot of daemons there are use-cases that require more than one instance of the daemon to be running. With instance I mean a separate process with it’s own configuration files, but on the same system, which rules out virtualisation or changeroots. Examples are copies of the “main server” running on a different port, to test new settings, different servers on different IPs, a HTTP-Server-Split into a slick static-and-proxying server and a heavy backend server, a mail server split with a virus scanner in between etc.

So as an administrator I currently not only have to write the configuration for the additional instances, but also write my own init scripts and modify them, never being sure if I did it good or whether it will cause problems on package upgrade or similar things. I’d rather see the functionality built-in to the package’s init script directly.

There is a package in Debian that already provides this: The OpenVPN package maintained by Alberto Gonzalez Iniesta allows the user to define new instances of OpenVPN simply by adding a new file to /etc/openvpn/. The file /etc/default/openvpn defines which of these instances are to be started when I or the system start runs /etc/init.d/openvpn start. /etc/init.d/openvpn stop stops all running instances and /etc/init.d/openvpn restart also restarts just the currently running servers. I can easily control a specific instance by adding it’s name (which is the configuration file’s basename) after the command to the init script.

I think these semantics are clear, sensible and non-disruptive and should be available with every Debian package where the administrator might want to run several instances at once: web server, mail server, ftp servers, name servers etc.

In those cases where the daemon is not configured by a single file alone, one directory with the configuration for one instance is needed. Otherwise, I don’t see why this should be a problem. For backwards compatibility, the “normal” configuration file locaction could be an implicit instance called “default” and all additional instances go to their own directory (e.g /etc/ntpd.conf is instance “default”, and /etc/ntpd/public.conf is instance “public”).

Comments welcome.