Quantcast
Channel: Standalone Sysadmin » Linux/Unix
Viewing all articles
Browse latest Browse all 21

Dear Package Maintainers: Stop Being Clever

$
0
0

In the Linux world, there are two ways of treating a service/daemon installation.

The Right Waytm (which is what Redhat does) is to install the service but not start it immediately. This only makes sense. The administrator hasn't had time to configure it yet, it may be harmful, etc, etc. You should install the software, make it available, put skeleton config, whatever, but leave it up to the administrator to actually turn on.

The Wrong Way is what Debian / Ubuntu does, where software that's being installed will begin running immediately following the completed installation. This is wrong. It's bad. It was, in my opinion, a dumb design decision.

That being said, it was a design decision made by the distribution. If you are a person who packages software for a distribution that has made certain design decisions,

STOP TRYING TO OUTWIT THE DISTRIBUTION

I don't know how to say it more clearly than that. I have, in my year of experience with Ubuntu, found many pieces of software that find clever ways to not run immediately following installation. Some will put a flag in the initialization script itself, but most will create a file in /etc/default/ matching the service name, and will put a flag in there that, out of the box, prevents the service from running.

The idea behind this is solid. It's clearly a bad idea to run software immediately following installation, but as a software packager, that is not a decision you should be making. If you're bundling Ubuntu software, you need to follow the tao of Ubuntu, even if you don't like it, because things expect software running under Debian-based distros to behave a certain way.

Here's a case in point.

I've been working on puppetizing my installation of Nagios. Nagios itself works fine. This block is really all I need to do once I get my configuration in place:

   package { 'nagios3':
      ensure   => present,
      before   => [
                  File['/etc/nagios3'],
                  Package["pnp4nagios"],
                  ],
   }
   service { "nagios3":
      enable   => true,
      ensure   => "running",
      require  => Package["nagios3"],
   }

That will install nagios3 and make sure that the service is running. The files that are referenced there will update the service when they change because of a "notify" line. But it works just fine, because the person packaging it wasn't trying to be clever.

This, on the other hand, does not work:

   service { "npcd":
      enable   => true,
      ensure   => "running",
      require  => [
                  Package["pnp4nagios"],
                  File["/etc/default/npcd"],
                  ],
   }

As you can see, I've got "enable" set to true, and "ensure running" set, nevertheless the service WILL NOT run. Why? Because of these lines in /etc/init.d/npcd:

     46 # Check if RUN is set to "yes" in /etc/defaults/npcd
     47 if [ "x$RUN" != "xyes" ] ; then
     48         echo "$NAME has been disabled in /etc/default/npcd."
     49         exit 0
     50 fi

Here are the contents of /etc/defaults/npcd out of the box:

# Default settings for the NPCD init script.

# Should NPCD be started? ("yes" to enable)
RUN="no"

# Additional options that are passed to the daemon.
DAEMON_OPTS="-d -f /etc/pnp4nagios/npcd.cfg"

Awesome. You might naively think, like I did, that RUN="no" is standard, but that's not the case. I asked about this problem on ServerFault, and one of the answers found half a dozen ways to signal "please don't start the service".

As someone who has to use the software that you're packaging, I'm asking you to not do this.

Seriously, please stop. You're breaking other things by trying to do the "right" thing.


Viewing all articles
Browse latest Browse all 21

Trending Articles