One of the basic principles of computer security is never to run anything you don't need.
I was pgrep
ping for a process today when I noticed that my Ubuntu 9.04 (desktop) machine was running a git server daemon. After a quick swear, I discovered that the git-daemon-run
package had been (probably inadvertently) installed, and removing it got rid of that process (and ensured that it wouldn't be restarted later).
But in other cases, I want the server package to be installed, but don't want the server daemon running. For example, I use lighttpd
for internal testing (it's started by specific test scripts for some applications, and listens only on localhost in those configurations) but I don't want it listening for outside connections with some random config file. (If I wanted to run one listening for outside connections, I'd configure and run it myself.)
I really don't like running all sorts of random servers I don't need on Internet-exposed machines, since who knows what security holes they open up. And I prefer not to have to muck about with firewalls, since that's yet another potential source of errors and misconfigurations that can open up security holes. It's not so hard to have Unix machines configured not to start any servers unless specifically asked to do so by the admin; NetBSD (and OpenBSD, too, I think) come this way by default.
How do I configure my Ubuntu systems never to start any kind of server daemon unless I specifically tell it I want it started?
(Asking to have a package installed is not, in my book, asking to start a server. If it is supposed to be, it's a terrible user interface, since many package installs don't even have a server to start, so it makes it far too easy to inadvertently start a server without realizing you've done so.)
EDIT: Just to make it clear, the problem is not that I want to be able to stop existing servers. The problem is that I don't want new servers started without an explicit request. This means I should be able to do any sysadmin task, such as installing a package, and be confident that no servers have started. Most responses do not address this point.
Install sysv-rc-conf and simply turn off the services you don't want to have running.
As someone with a similar problem, I feel very strongly that it is not reasonable for a daemon to presume that the user wants it started per default: There are a many perfectly valid use cases where this is not the case. (Not to mention that it is not always clear which installations actually include a daemon.) The daemon could be off per default, the user could be explicitly queried, or there could be a central setting. Anything else is Microsoftian reasoning entirely unworthy of Linux.
In addition, I find several of the above comments to the original poster to be rude, patronizing, and lacking in constructiveness. To suggest, e.g., that he should either accept the default behaviour or change distribution is truly remarkable. Firstly, no distribution will be a perfect fit, and jumping to a new distribution with associated extra work is unlikely to be a realistic solution over this one thing. Secondly, proficient Linux/Unix users are used to every behaviour being changeable: A problem may take two hours off digging, but then it is fixed. The natural thing for such a user to do, when the defaults are unsuitable, is to assume the existence of a work-around and try to find out what it is. Thirdly, in open source and free software etiquette,
If you don't like it, then patch the source code!'' is an acceptable response; however,
..., then take a hike!'' is not.The expectation of the packaging system is that when you install a server package, you want to run that server. It is a reasonable expectation.
Roy has answered this question for you. When you install a new server package, you stop that server and then use a tool like sysv-rc-conf to prevent that server from being started at the next reboot or runlevel change. Yes, you have to do some work yourself, and that's reasonable because you're configuring your system differently to most people who use Ubuntu.
You should invest some time to learn how to configure lighttpd so that it is permanently configured to only listen on localhost. Then, when you do start the server, you know it's already configured to your liking.
I found the following helpful for installing Ubuntu in chroot environments, like debootstrapping new xen guests. Credit actually goes to the xen-tools scripts for teaching me this:
echo '#!/bin/sh' > /usr/sbin/policy-rc.d
echo 'exit 101' >> /usr/sbin/policy-rc.d
chmod 755 /usr/sbin/policy-rc.d
With this script in place, apt will not start services after install. However, this is only half your problem, because symlinks are still put in place, the services will start after the next boot. I don't know how to automatically stop that :(
Barry Brown, in a comment on the question, provides a clue to a possible answer.
The packaging system uses the
invoke-rc.d
program to start the server after the package is installed.[1] This program will run/usr/sbin/policy-rc.d
to determine the policy on starting that server.The package
policyrcd-script-zg2
includes thepolicy-rc.d
script, which either runs/etc/policy-rc.d
with its parameters if present, and exits with that script's error code, or exits with 0 (success) otherwise. The interfacepolicy-rc.d
is expected to offer is documented briefly in theinvoke-rc.d
manage, and much more extensively in/usr/share/doc/sysv-rc/README.policy-rc.d.gz
.The next step, I suppose, is for me to test this.
Things remaining to be answered:
[1] What other parts of the system use
invoke-rc.d
? [2] Does this actually work?How about watching on the directories where the init scripts are located? You can likely make those directories unmodifiable with the chatr command.
Ideally, this is a matter of
post-inst
scripts. At the beginning of the Ubuntu project, an intentional effort was made to force sane defaults to dpkg configuration scripts, so that you and I don't have to answer every damn question that might come up, or waste time researching the options. Now that Ubuntu has set this up, many people aren't aware it exists. It should be possible to ask a question about whether to install as a daemon or not, but I don't see any such questions in the few packages I checked.Perhaps you should engage with the Ubuntu Server Team and maybe even Debian Policy to improve things.
You can try to create script that will check up list of installed services and verify them against some list of permitted services. If service is not in the list then script will turn it off. The script must be run at start before common services. And maybe run like daemon to shut freshly installed services. Or if possible to run automatically after each install to check for new services.
P.S. I can think of two possible causes of services start after package install. That is package feature, or that is package manager feature. If that is package feature i dont think there is some way to change service behaviour. If that is package manager feature maybe there is some configuration option to prevent service start after install. I dont know right now so just throwing ideas.
If you set up iptables with a default policy of DROP for the INPUT chain then you don't have to worry as much about listening ports because they will be blocked by iptables. Ubuntu server comes with a user friendly interface for iptables if you are new to iptables.
From your post, it sounds to me like you might be happier with a different Linux distribution such as CentOS. The default install process for CentOS will allow you to install different meta-packages, and by selecting none you might be happier with your base install.
Also, I think you question might have a been a bit clearer if you substitute 'service' or 'daemon' for the word 'server' when you mean something that runs on a server. People tend to use 'server' to refer to a physical box or VM. Although I guess its not technically incorrect.
Take a look at what run level you're in with the 'runlevel' command, and remove all the symlinks at /etc/rc
<
runlevel>.d/. You'll probably want some of the daemons running, but most could probably be removed.You can add them back in with a symlink from the script in /etc/init.d.
I think there is a command that'll do that same trick, and add all the symlinks for all the runlevels, but I just do it manually.