I posted this as a comment on the blog, but I'm duplicating here:
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).
> If you're upgrading MySQL, MySQL will get restarted.
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...
What I don't understand is why every maintainer adds a (unneeded) layer for enable/disable.
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).
When packaging a daemon for Debian, the maintainer should add sufficient questions during installation, and sane default values, to start the service.
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.
What does packages using non-standard hacks that break puppet scripting have to do with configuring and building source code? That's not related to the issue at all...
> 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.
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.
Every package maintainer needs to make some decisions when packaging software. Debian has very specific guidelines about packing, so if you don't like it may be Debian is the wrong distribution _for you_.
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.
Author of the article here. Thanks, and I agree with you. I have some disagreements with the way Ubuntu does things like this, and I'd prefer an RHEL clone (which, of course, has tradeoffs too).
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.
I remember installing Red Hat 4, going on IRC and getting rooted. Red Hat's approach comes from lots of learning, and I think it's smart. Thanks for the post.
We have a similar problem when deploying Openstack using puppet - all the services need to be brought up after config that sets things like the central DB and AMQP locations. It means that a deployed site will always have errors in their logs right from the start, which confuses customers and makes it harder to spot when there is actually an error in the deployment tool.
If you're using Ubuntu, the .deb packages need a lot of work. I've been playing around with this for the past week and there are all sorts of little glitches and gotchas. A big problem is that the package maintainers didn't use debconf, so you end up having to install, set some settings and then bring the service up.
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.
Debian always think they know better than the authors of the software they're distributing (the worst, but by no means only incident being their key generation bug). When I maintained a linux program I received twice as many bugs from Debian users as anything else, because Debian repackaged KDE in a way that broke its autoconf macros. And anyone who's ever tried to follow a tutorial for e.g. Tomcat will know how radically Debian rearranges its files.
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.
I hate to say it, but this is just a rant by a RedHat/CentOS admin who has started using Debian/Ubuntu for the first time and just doesn't know why things are done differently there.
Author here. You're 99% correct. I'm historically an RHEL-based admin, who has started using Debian/Ubuntu for the first time (relatively, for about a year), but I totally get why these things are done. What I deeply disagree with is how they're done.
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.
Maybe it would be a good idea to provide the reason why things are done differently. He seems happy to accept the Debian standards despite disagreeing with them. Help the guy (and the rest of us who has asked the same question) out.
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.
It seems like a lot of these comments are missing the point by discussing virtues of various packaging systems and auto-start behaviors.
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.
Debian's thinking on this is that a user won't install a daemon unless he wants it to run, and that a package should get everything into an immediately useable state by default. Therefore, a daemon should be started automatically when a package is installed.
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.
I believe ElasticSearch will automatically connect to any nodes with the same cluster-name. The package installs it with the default cluster-name. Since it starts on install, you don't have a chance to change this name before it's done that...
Apache's Cassandra deb that a similar behaviour and has a greater impact than ES's super-hero node names. A newly started Cassandra node will absent a token declaration in its yaml file, auto-assign a token. This is never what you want in a cluster distribution. So the workaround is either to patch the deb to not autostart or let it start, stop it, and blow away the data directories. This allows cluster management tools (such as Priam) to control the token allocation first, and then re-start Cassandra.
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.
[+] [-] bashtoni|12 years ago|reply
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).
[+] [-] Shish2k|12 years ago|reply
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...
[+] [-] freiheit|12 years ago|reply
You can examine those scripts with "rpm -q --scripts mysql-server".
[+] [-] txutxu|12 years ago|reply
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 ?
[+] [-] belorn|12 years ago|reply
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.
[+] [-] stephen_g|12 years ago|reply
[+] [-] _pmf_|12 years ago|reply
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.
[+] [-] reidrac|12 years ago|reply
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.
[+] [-] MPSimmons|12 years ago|reply
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.
[+] [-] codezero|12 years ago|reply
[+] [-] antihero|12 years ago|reply
[+] [-] stonith|12 years ago|reply
[+] [-] Patrick_Devine|12 years ago|reply
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.
[+] [-] lmm|12 years ago|reply
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.
[+] [-] Daviey|12 years ago|reply
[+] [-] jmomo|12 years ago|reply
[+] [-] MPSimmons|12 years ago|reply
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.
[+] [-] lmickh|12 years ago|reply
[+] [-] jrochkind1|12 years ago|reply
[+] [-] moe|12 years ago|reply
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.
[+] [-] dmourati|12 years ago|reply
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.
[+] [-] GrinningFool|12 years ago|reply
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.
[+] [-] rlpb|12 years ago|reply
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.
[+] [-] Qantourisc|12 years ago|reply
[+] [-] Chris2048|12 years ago|reply
[+] [-] dehora|12 years ago|reply
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.