Another alternative is just bypass the Deb repo's altogether and install from source, but do so using the awesome Debian Alternatives tool [1] so as not to drop a bunch of unmanaged files into /usr/bin, /usr/local/bin, etc. Takes some setup work, but very powerful and useful after you get it working. Example scripts:
Can do similarly with any other package. Download and compile the source to --prefix=/opt/name/version, look at the /opt structure (it will mirror /usr/bin, /usr/local/bin/, /usr/share/man) and script the update-alternatives command correspondingly.
Tons of benefits, among them being better post-install startup control, but also you can install multiple versions side-by-side and swap among with a single command. Upgrade painlessly, rollback if the new version breaks things, all very easily.
I've used stow to manage installs under /use/local before, which seems like a slightly easier approach. It does something similar but manages the install as a series of symlinks from /usr/local/bin to /usr/local/stow/<packagename>/bin.
It's pretty easy to setup and works the same on any distro.
Learning this seems to be a rite of passage for anyone who spends enough time doing Debian deployment work.
I think the complaints that starting daemons should not be the default are missing the mark: Debian is there to provide a complete, working system on its own terms. They want you to be able to apt-get install <thing> and have <thing> working, out of the box, with no further work on your part. I get that there are situations where this is inconvenient, and for my money there ought to be an `apt-get install --no-launch` switch rather than monkeying with an obscurely-named shell script, but if you've run into this then you've run into an instance where the system wasn't designed for you.
This is the same reason you probably shouldn't, for instance, do development against the packaged ruby - it's there to run the applications which Debian provides, no more, no less. If your needs align with the needs of the end-user applications which Debian provides, that's great. As soon as you step outside those lines, you're going to have a bad time.
Agreed. I've run into a similar kind of problem with their package manager as well. If you try to install a package for which some of the dependencies can no longer be met because of a poorly maintained repository or something, you make take a closer look at the application and determine that you would be able to do the work you needed to do without that dependency being met. All other major Linux distros have package managers that allow you to override the dependency check (in the case of SUSE, you can do this interactively with excellent granularity, on RHEL you can simply disable the check altogether but then you're on your own). On Debian and Ubuntu, you have to switch to using dpkg to install the package directly instead of apt in which case you can get past the dependency check, but then as soon as you use apt again it will refuse to work until you've removed the offending package or satisfied the dependency.
I understand the need to warn the user about the consequences of what they're doing, but at the end of the day they are using the software, not the other way around. As the admin, I want the ability to override checks once I have done my due diligence.
> They want you to be able to apt-get install <thing> and have <thing> working, out of the box, with no further work on your part.
Except that there is practically no way for say, winbind, or openldap, or bind to be able to start up successfully without configuration first. Then the oh so frequent case nowadays of preparing a deployment image in a chroot and bang, install fails because of unwanted starting services that conflict with the host.
> This is the same reason you probably shouldn't, for instance, do development against the packaged ruby
Excuse me, this is insane. You're using a well-maintained distribution because you don't want to manage your own installation of Ruby or Python or Perl or PHP and countless modules, frameworks and the like, on the production systems. All the point of running Debian is developing against the provided binaries, because you want to use the same versions in dev and deployment, don't you??? and have an easy maintenance, upgrades, etc.
What is needed is a simple switch to apt-get/aptitude/dpkg to NOT start the services when installing, and maybe some other switches to NOT run preinst/postinst. That's it.
There are good reasons to prevent the auto-start behaviour. Having your own configuration ready for example. Preventing things from breaking when something is already listening on their default port. Preventing creation of the initial files in the wrong place.
You can find many more cases if you do more server automation. Most people don't need them, but it can be very useful. And no, it's got nothing to do with start on (re)boot.
I agree. If the install is finished, then the system should be in its new normal condition, and that condition is either daemon-on or daemon-off. There is quite likely a real issue here worth fixing, but the fix is probably more nuanced than just daemon-off.
Why must they go hand in hand? What goes wrong if after installing a package the daemon is not started automatically, while the configuration is such that it will start on reboot?
The post is missing a critical point: per the Debian policy, services should only bind to localhost upon installation. Further, Debain advertises itself as the "universal" operating system. This implies that the defaults are sane for many people, and if the administrator of the system installs a service, the administrator probably wants the service running. So, the only thing left to do, is change the bind address, and restart the daemon. Further, per the Debian policy, when a daemon package is installed, it's configured to start automatically on boot for run level 2. The policy is written in such a way, that Debian system administrators know _exactly_ the state of their system, after installing packages.
This post is written from the Red Hat way of doing things, in that you install the daemon, do configuration, then start the daemon. However, there is no consistency with Red Hat systems. Some package maintainers will have the daemon configured to start on boot, some not. So, after configuring and starting, you also need to use chkconfig(8) to check if the daemon you just installed is ready to start on boot. More often than not, it's "off", which means it won't start. Painful thing to discover when the server restarts, and customers are calling in that their website isn't loading, or they can't access their NFS share.
IMO, I have come to find the Debian way of installing services more sane, than the Red Hat way. I want my system working, and I want to know the state my system is in when making major changes. Red Hat is just too inconsistent here, and it doesn't help that they have the /etc/rc.d/init.d/ historical baggage.
I really like the way it's now. But in some edge cases you need the service stopped in the first place.
For example RabbitMQ initiates a database which denies cluster configurations if intact. So in Debian way if you are using some configuration management tool to start a RabbitMQ cluster you have install/stop/resetdb/restart cycle which is prone to failing.
Surely not all daemons start automatically. Some of them source files from /etc/default, with an "off" setting per default. And there are plenty of daemons for which it makes sense to start automatically (eg, installing pulseaudio and expecting it to work without having to figure out how to configure it is not an unreasonable expectation). So maybe:
- more daemons (eg, puppet) ought to be "off" per default when it doesn't make sense
- apt-get should provide a switch to prevent newly-added daemons from starting, which could be used by provisioning systems
But saying that "daemons should never start at install" is silly.
"daemons without sane defaults should never start at install"
It's silly that certain daemons check for a default settings file to decide if an execution is permitted rather than skipping that logic and defaulting the service off until either user intervention provides sane operating defaults, or the defaults are known to be sane otherwise.
I agree that a switch should be included with the package managers, but I also believe that the package managers should look for a switch from the package maintainers as well.
"areDefaultsSane = 0" should require user intervention to start after install and would be intended for things like insecure network daemons or daemons that control thermals/power/otherwiseImportantThings, whereas things that flagged "areDefaultsSane" as true would be started without intervention, this being intended for things like pulse.
things like thinkfan (a cpu/fan manager for linux) include "run_at_start = False" in the /etc/default file and things like that, but it feels woefully inadequate to rely on the package itself to check for something potentially mean when the environment could handle it in a standardized way, perhaps within whatever metadata is included in the deb file rather than the packages' included /etc/default/? (disclaimer: I don't know how deb files are put together)
AFAIK it is Debian (and Ubuntu) policy for all packages to auto start services. And it is also quite difficult to pre-set package config files before installing, especially if you want to script it with a configuration manager like puppet. I can't recall ever seeing a package in the official repositories for which this is not the case, and it is a real and genuine pain point in using Debian as a server.
I think a saner default would be to not start daemons on install. It's one of the reasons CentOS has grown on me.
The biggest annoyance is the lack of consistency. Some daemons start on install, others do not. Some use an /etc/default file to control it, others do not.
It's actually why I left Debian for another distribution... I think that it may have also had a bad habit of overwriting /boot/grub/menu.lst every time that program was updated. That could have been Ubuntu, though. It was a dual-booter's nightmare! I had to boot from a live cd and fix way too often.
Would this be a good fit for preventing Postgres from starting on Ubuntu? In the past with ansible I've had to install it, stop it, move the DB files to the non-default location of my choice, change the configs, and start it up again. Would have been easier to skip a couple of those steps.
I had the same issue. There is another solution for postgres.
Install postgresql-common first. Edit /etc/postresql-common/createcluster.conf to disable creation of the cluster on install (or change the options used to create the cluster) and then install postgresql-x.y
[+] [-] SkyMarshal|11 years ago|reply
https://github.com/byrongibson/scripts/tree/master/install/h...
https://github.com/byrongibson/scripts/tree/master/install/j...
https://github.com/byrongibson/scripts/tree/master/install/s...
Can do similarly with any other package. Download and compile the source to --prefix=/opt/name/version, look at the /opt structure (it will mirror /usr/bin, /usr/local/bin/, /usr/share/man) and script the update-alternatives command correspondingly.
Tons of benefits, among them being better post-install startup control, but also you can install multiple versions side-by-side and swap among with a single command. Upgrade painlessly, rollback if the new version breaks things, all very easily.
Reminiscent of Gobo Linux [2] but still a Debian.
[1]:https://wiki.debian.org/DebianAlternatives
[2]:https://en.wikipedia.org/wiki/GoboLinux
[+] [-] ars|11 years ago|reply
[+] [-] cdjk|11 years ago|reply
It's pretty easy to setup and works the same on any distro.
[+] [-] regularfry|11 years ago|reply
I think the complaints that starting daemons should not be the default are missing the mark: Debian is there to provide a complete, working system on its own terms. They want you to be able to apt-get install <thing> and have <thing> working, out of the box, with no further work on your part. I get that there are situations where this is inconvenient, and for my money there ought to be an `apt-get install --no-launch` switch rather than monkeying with an obscurely-named shell script, but if you've run into this then you've run into an instance where the system wasn't designed for you.
This is the same reason you probably shouldn't, for instance, do development against the packaged ruby - it's there to run the applications which Debian provides, no more, no less. If your needs align with the needs of the end-user applications which Debian provides, that's great. As soon as you step outside those lines, you're going to have a bad time.
[+] [-] TallGuyShort|11 years ago|reply
I understand the need to warn the user about the consequences of what they're doing, but at the end of the day they are using the software, not the other way around. As the admin, I want the ability to override checks once I have done my due diligence.
[+] [-] wazoox|11 years ago|reply
Except that there is practically no way for say, winbind, or openldap, or bind to be able to start up successfully without configuration first. Then the oh so frequent case nowadays of preparing a deployment image in a chroot and bang, install fails because of unwanted starting services that conflict with the host.
> This is the same reason you probably shouldn't, for instance, do development against the packaged ruby
Excuse me, this is insane. You're using a well-maintained distribution because you don't want to manage your own installation of Ruby or Python or Perl or PHP and countless modules, frameworks and the like, on the production systems. All the point of running Debian is developing against the provided binaries, because you want to use the same versions in dev and deployment, don't you??? and have an easy maintenance, upgrades, etc.
What is needed is a simple switch to apt-get/aptitude/dpkg to NOT start the services when installing, and maybe some other switches to NOT run preinst/postinst. That's it.
[+] [-] ars|11 years ago|reply
They go hand in hand.
So this really has nothing to do with install, but with the default configuration of a freshly installed daemon: Is it by default set to start or not.
[+] [-] viraptor|11 years ago|reply
You can find many more cases if you do more server automation. Most people don't need them, but it can be very useful. And no, it's got nothing to do with start on (re)boot.
[+] [-] mtdewcmu|11 years ago|reply
[+] [-] Confusion|11 years ago|reply
[+] [-] atoponce|11 years ago|reply
This post is written from the Red Hat way of doing things, in that you install the daemon, do configuration, then start the daemon. However, there is no consistency with Red Hat systems. Some package maintainers will have the daemon configured to start on boot, some not. So, after configuring and starting, you also need to use chkconfig(8) to check if the daemon you just installed is ready to start on boot. More often than not, it's "off", which means it won't start. Painful thing to discover when the server restarts, and customers are calling in that their website isn't loading, or they can't access their NFS share.
IMO, I have come to find the Debian way of installing services more sane, than the Red Hat way. I want my system working, and I want to know the state my system is in when making major changes. Red Hat is just too inconsistent here, and it doesn't help that they have the /etc/rc.d/init.d/ historical baggage.
[+] [-] fsniper|11 years ago|reply
For example RabbitMQ initiates a database which denies cluster configurations if intact. So in Debian way if you are using some configuration management tool to start a RabbitMQ cluster you have install/stop/resetdb/restart cycle which is prone to failing.
So some edge cases need this kind of 2cents.
[+] [-] mercurial|11 years ago|reply
- more daemons (eg, puppet) ought to be "off" per default when it doesn't make sense
- apt-get should provide a switch to prevent newly-added daemons from starting, which could be used by provisioning systems
But saying that "daemons should never start at install" is silly.
[+] [-] serf|11 years ago|reply
It's silly that certain daemons check for a default settings file to decide if an execution is permitted rather than skipping that logic and defaulting the service off until either user intervention provides sane operating defaults, or the defaults are known to be sane otherwise.
I agree that a switch should be included with the package managers, but I also believe that the package managers should look for a switch from the package maintainers as well.
"areDefaultsSane = 0" should require user intervention to start after install and would be intended for things like insecure network daemons or daemons that control thermals/power/otherwiseImportantThings, whereas things that flagged "areDefaultsSane" as true would be started without intervention, this being intended for things like pulse.
things like thinkfan (a cpu/fan manager for linux) include "run_at_start = False" in the /etc/default file and things like that, but it feels woefully inadequate to rely on the package itself to check for something potentially mean when the environment could handle it in a standardized way, perhaps within whatever metadata is included in the deb file rather than the packages' included /etc/default/? (disclaimer: I don't know how deb files are put together)
[+] [-] stormbrew|11 years ago|reply
[+] [-] duskwuff|11 years ago|reply
[+] [-] dale-cooper|11 years ago|reply
The biggest annoyance is the lack of consistency. Some daemons start on install, others do not. Some use an /etc/default file to control it, others do not.
[+] [-] atoponce|11 years ago|reply
[+] [-] pling|11 years ago|reply
I rather prefer the /etc/rc.conf approach of BSD systems though.
[+] [-] nnnnni|11 years ago|reply
[+] [-] akurilin|11 years ago|reply
[+] [-] mw42|11 years ago|reply
Install postgresql-common first. Edit /etc/postresql-common/createcluster.conf to disable creation of the cluster on install (or change the options used to create the cluster) and then install postgresql-x.y
[+] [-] claudius|11 years ago|reply
[+] [-] rlpb|11 years ago|reply
[+] [-] CarlHoerberg|11 years ago|reply
[+] [-] kolev|11 years ago|reply
[+] [-] emanuelez|11 years ago|reply