My work at Rackspace has involved working with a bunch of Debian chroots lately. One problem I had was that daemons tried to start in the chroot as soon as I installed them. That created errors and made my ansible output look terrible.
If you’d like to prevent daemons from starting after installing a package, just toss a few lines into /usr/sbin/policy-rc.d:
|
1 2 3 4 5 |
cat > /usr/sbin/policy-rc.d < < EOF #!/bin/sh echo "All runlevel operations denied by policy" >&2 exit 101 EOF |
Now, install any packages that you need and the daemons will remain stopped until you start them (or reboot the server). Be sure to remove the policy file you added once you’re done installing your packages.
This seems like a good opportunity to get on a soapbox about automatically starting daemons. ;)
I still have a very difficult time understanding why Debian-based distributions start daemons as soon as the package is installed. Having an option to enable this might be useful for some situations, but this shouldn’t be the default.
You end up with situations like the one in this puppet bug report. The daemon shouldn’t start until you’re ready to configure it and use it. However, the logic is that the daemon is so horribly un-configured that it shouldn’t hurt anything if starts immediately. So why start the daemon at all?
When I run the command apt-get install or yum install, I expect that packages will be installed to disk and nothing more. Even the definition of the English word “install” talks about “preparing” something for use, not actually using it:
To connect, set up or prepare something for use
If I install an electrical switch at home, I don’t install it in the ON position with my circuit breaker in the ON position. I install it with everything off, verify my work, ensure that it fits in place, and then I apply power. The installation and actual use of the new switch are two completely separate activities with additional work required in between.
I strongly urge the Debian community to consider switching to a mechanism where daemons don’t start until the users configure them properly and are ready to use them. This makes configuration management much easier, improves security, and provides consistency with almost every other Linux distribution.
This is especially useful when installing things in Dockerfiles.
hear hear! one of the most annoying things about the Debian methodology, thanks for sharing. This should be a knob somewhere in /etc/ as usual and I’ve never understood why not. *shrug*
Could not agree more. A $CLIENT has this exact thing in place for a few services, and I’m glad you blogged about it–it’ll save a lot of other people a lot of frustration too.
Its a conscious design decision of debian. Many other do it the other was around. But I still agree, it schould be turn-off-able
Thanks for sharing this tip. I’ve been upset quite a lot of times by this. Especially when I don’t want to run a service on the default port.
Do you think there is a chance it will ever change?
I’ve gone even further in the past, purging all management scripts from deb packages upon installation:
https://gist.github.com/jordansissel/748313
It’s a fun hack to hook apt-get ;)
Except you’re overlooking one thing: per the Debian policy, services should only listen on localhost by default. As an administrator, you are expected to change the daemon to listen externally. Armed with that knowledge, other than cluttering STDOUT with useless garbage, what damage is starting a service which binds to localhost? It’s assumed that if you install a service, you want it running. And more often than not, the sane defaults work for many people. So, change the bind address, and restart.
good
easier: RUNLEVEL=1 apt-get install …
Clever!
The reasoning generally goes something like: “Why would you want to install X (where X is something that requires a running service), if you don’t want X running?” Additionally, the point is usually raised that this is the Element of Least Surprise for a less knowledgeable user, and that it is far easier for them to figure out how to shut a service down (including by removal of the package), than it is to scratch their head wondering if the installation succeeded, or if the software is working.
Of course, this assumes that service can do something useful on first-start (think welcome page for a webserver), and that it isn’t insecure; If that’s not the case, it’s a bug.
If you’re working in a chroot, I’d say you’re squarely in Advanced territory, and shouldn’t be surprised if default behavior isn’t tailored to what you’re doing. In this case, the policy interface exists for just such exceptional circumstances.
I think this post will help you understand why services are started by default on Debian after installing it:
“””
The reason that RedHat don’t start things is that their default approach has been to install a whole load of stuff that you might possibly want, and allow you to enable it when you are inspired to give some new service a try.
The Debian approach has always been to not install anything that you don’t intend to use. It is also to ensure that if you do choose to install something, it should be doing something useful by the end of the install (if possible, security considerations allowing).
That is also why Debian and RedHat diverge when it comes to prompting the user for configuration questions — RedHat just want the software to install, whereas Debian wants it to be useful, so may need to ask questions.
It also leads to the fact that you can do major release upgrades of Debian, whereas that’s not really supported in RedHat, as chances are your configuration is going to get trashed to some extent, and they don’t have the chance to ask you what you want to do about it.
[…]
“””
https://lists.debian.org/[email protected]
Remember to chmod +x policy-rc.d
Thanks for this. Two points:
1) I found that this was the only safe way to get debirf to run to completion after injecting some modules to use custom repos. It seems a lot of (particularly proprietary) “server system-health” packages include code in their init-scripts’ start() functions to sniff out the RAID controllers, etc. In a lot of cases they don’t even pretend to handle unexpected system-responses (like when the image is being built on a different system than the destination one, or when the image is being built as non-root so there are inadequate device-permissions anyway). When they fail the debirf-build borks, and I did *not* want to remove the -e shellopt from scripts or to separate out individual package installs for “[install] 2>/dev/null || true” types of hand-holding…
2) It would be good to update the post to incorporate Hugh Saunders’ comment about adding the “chmod +x”. I know it’s obvious, but I’m embarrassed to admit the lack of that obvious command cost me a wee bit of time before I bothered reading the comments (and then slapping myself vigorously on the forehead)…
Thanks. It’s really annoying, especially if a cluster software is managing the services and you don’t think about this stupid behaviour.
Great post! Saved my day when installing/updating packages in a chroot environment. Works for ‘older’ packages on Debian 8 which do not use systemd yet.
FYI on debian, debootstrap (a handy set of scripts for creating full-system chroots) sets a policy-rc.d like this, but also replaces /sbin/start-stop-daemon with a no-op: https://anonscm.debian.org/cgit/d-i/debootstrap.git/tree/scripts/sid?id=c4ad96b3972426df3d261d33a5025335fef86f79#n159
Maybe there are some packages that require that?
Also, IMO, while there are many situations where installing a service and starting it with good defaults in a single step is handy, not having the service starts be an optional step that the package system is aware of and can skip seems like an oversight that should be remedied.
Be careful with that one.
Logrotate for /var/log/syslog is using invoke-rc.d for triggering rsyslogd
which causes logs to no longer be rotated.
thnx dude came in handy!