Dear Package Maintainers: Stop Being Clever
standalone-sysadmin.com
standalone-sysadmin.com
RHEL and Debian (and their respective derivatives) have different philosophies on packaging, which is why you see this result.
The RHEL philosophy is simple; package installation only installs the package, starting daemons is a separate process.
The Debian philosophy is that installing a daemon should also make that daemon run, unless it's not possible the make the daemon run securely by default. Things like the /etc/default RUN="no" aren't the package maintainer trying to be clever, but rather them following Debian packaging guidelines. There also the reason you see things like MySQL listening only on the loopback interface by default on Debian.
One you understand this the decisions seem a bit less crazy.
For me, the big issue with the Debian approach isn't on installation, but rather on upgrade. On Debian, running 'apt-get upgrade' on a live server can cause an unspecified amount of downtime. If you're upgrading MySQL, MySQL will get restarted. If you're upgrading a library on which multiple daemons rely, they will also get restarted. yum upgrade on RHEL doesn't suffer from the same problem, and you can schedule the restart yourself.
Again, this is because of a philosophical difference. On Debian, the idea is that if you've asked to upgrade something, it should be upgraded. On RHEL, you can upgrade a package, but continue to run the old (potentially insecure version).
Or specifically, it will get stopped, your packages will spend 15 minutes updating (or longer if there's an interactive prompt mid way and you aren't paying attention), and then it will get started again.
I'm quite happy with the debian way of doing things, but I'd really like it if apt-get was smart enough to stop / upgrade / start individual services, rather than stop-all / upgrade-all / start-all...
As you said - it's not a debian-specific thing. Some packages may do it if they explicitly require it (and I haven't seen one doing this in the official repos so far).
You can examine those scripts with "rpm -q --scripts mysql-server".
If you want to run a service, you have a runlevel editor.
This is, chkconfig in RH based, and update-rc.d in debian based.
That is the tool for the job.
Nowadays it seems that everybody prefers to invent an additional switch, this is a shell boolean or string, in /etc/sysconfig (RH) or /etc/default (debian).
Why ?
Contrary to the article, I think this is a rather good policy. It makes sure packages are usable as they are, rather than the normal process of config, make, make-install, and last adding user configuring before anything will start up. Debian is not Gentoo.
For those daemons which this isn't possible, package maintainers has a harder time. One of the better ways is simply to have it run, but in a safe way which do nothing. That would solve the issues the article describes, and would not be harmful.
Regarding the first issue, sane defaults and usable packages directly after installation came as a result of the config, make, and make-install process. Users should get a useful package directly without needing to spend days adding all the default settings to start a simple mail or web daemon.
The second issue has nothing to do with config, make, and make-install. It has to do with non-standard hacks. If nagios3 had simply started up like apache, this would have been a non-issue.
I'd argue it would be worse. I'd rather have the program not run at all than have it preconfigured in a way that contradicts its regular operation and having to reconfigure it to make it work normally.
As such, there is no sane configuration that contradicts its "regular" operation, if there is no regular operation to begin with.
Apache is a typical example here, as default installation provide no personal website, no web frame work, no kind of web site to speak of. Default here, is to do basically nothing and wait for the user to configure and install.
Recently a workmate installed nginx from the upstream repo and... surprise: nginx packages things different to Debian. You may like it more or less, but there are different solutions for the same problem.
That being said, I'm in the environment relatively recently and it's established, and I'm the one who has to learn to adapt since I don't see our infrastructure changing dramatically soon. Other than finally adding configuration management, that is.
After years of "OOTB pwnage", they started to make things a bit more secure by default and they eventually got to the point we're at today (where most installations are relatively secure by default, OOTB).
(Side note: I believe it was RHL 5.2 that shipped with wu-ftpd enabled out of the box. By the time it shipped (or shortly afterwards, I forget which), there was a remote root exploit for wu-ftpd. Thus, if you installed RHL 5.2, you'd likely get pwned in short order.)
Modern distros help with this a lot by offering rapid package updates, automatic updating and smarter firewall and security measures. A lot of this stuff was controlled by very esoteric text configuration files in the past, which made it hard even for a savvy person to get right every time.
This is definitely not the debian/ubuntu way of doing things.
If I find some time I'll see if I can repackage things to properly use debconf and push things upstream.
If you are using debconf interactively, it simply doesn't scale - if you are preseeding - or using juju, puppet or chef - what value does debconf add?
Please don't assume that it is simply wrong, just because it doesn't do x or y.
The debconf templates will always be trying to play catchup, and the transition of options between components doesn't make a lot of sense.
It would be really good to know what issues you have identified, as we take quality very seriously in this area.
However, your help with packaging will be most appreciated. Feel free to give me a shout on IRC, and we'll go through it.
I'll definitely give you a shout on IRC.
IMO it's not worth maintaining Debian packages of one's software or supporting it on Debian. Let Debian have their own packager for it if they want to, and direct support requests to them.
Why are there so many non-standard ways that a package can decide to not start? I really appreciate that the package maintainer is trying to do the right thing, but it's ridiculous that there isn't a way to do it - there's the Debian default and then there's whatever the packager thought up.
That's nuts, and needing to manage the same resource twice in puppet isn't a tragedy or big deal, but it's a symptom that something is wrong.
In your blog post you only mention one way of controlling startup- via an environment variable sourced from a file in /etc/defaults. This is the standardized, documented place in Debian for controlling the behavior of init scripts. Offhand, I can't think of any other ways I've seen packager maintainers controlling startup. I'd really need to see more evidence before agreeing that things are "ridiculous", "nuts", or "wrong".
http://www.debian.org/doc/manuals/maint-guide/dother.en.html...
More examples here: http://serverfault.com/questions/526075/fixing-services-that...
As it is, figuring out exactly how to do this has to be done for each service. It's tedious, IMO, though I understand the history of why this is the case.
I disagree that this is currently really more of a problem on Debian/Ubuntu that it is on Red Hat. E.G. If I want to manage BIND via puppet on Red Hat, I'm going to have to care about /etc/sysconfig/named.
This has been a long-standing bug in Debian which, due to their glacial processes, will probably prevail eternally.
In theory it is possible to disable the post installation auto-start with a specially crafted 'policy-rc.d'. In practice you don't want to go there, as it tends to break in unexpected ways.
http://serverfault.com/a/526123/76707
I'm a longtime Redhat/CentOS guy recently moved over to Ubuntu. It has definitely been a bit weird getting adjusted.
One counterpoint to the OP's rant? SSH.
It seems to me that the author was saying that consistency is important - installed services are expected to have a consistent behavior on a given platform.
A lot of tooling is built based on this, because that behavior is defined by the respective systems.
When people force override of these behaviors, it does break things as well as cause frustration.
The article isn't a criticism of any one packaging system or autostart choice of a distribution, but rather of individual packagers who impose their own choices over those of the system they're packaging for.
I agree with the objection: I think that times have moved on, and in reality today people use configuration management tools and almost always want to change the default configuration on a server daemon. Therefore, it doesn't make much sense to start it automatically.
As bashtoni says: this isn't a problem with package maintainers. It's a problem with Debian Policy.
A stepping stone to a full solution is to arrange a standard to configure the system not to start a daemon by default, and arrange for packages to follow that standard. policy-rc.d is just such a standard.
This is effectively how Debian/Ubuntu work. Once you know it, you can work around it. That said, it would be nice to have packages that don't run their service.