Ubuntu – How to stop Ubuntu from starting daemons I’ve not explicitly asked to run

package-managementSecurityUbuntu

One of the basic principles of computer security is never to run anything you don't need.

I was pgrepping 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.

Best Answer

Install sysv-rc-conf and simply turn off the services you don't want to have running.

sudo apt-get install sysv-rc-conf
DESCRIPTION: sysv-rc-conf gives an easy to use interface for manag‐ ing "/etc/rc{runlevel}.d/" symlinks.

alt text

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Many people seem to be afraid of mixing stable with testing, but frankly, testing is fairly stable in its own right, and with proper preferences and solution checking, you can avoid the "stability drift" that puts your core packages on the unstable path.

"Testing is fairly stable??", you ask. Yes. In order for a package to migrate from unstable to testing, it has to have zero open bugs for 10 consecutive days. Chances are that, especially for the more popular packages, somebody is going to submit a bug report for an unstable version if something is wrong.

Even if you don't want to mix the environments, it's still nice to have the option there in case you run into something that requires a newer version than what is in stable.

Here's what I recommend for setting this up:

First, create the following files in /etc/apt/preferences.d:

stable.pref:

# 500 <= P < 990: causes a version to be installed unless there is a
# version available belonging to the target release or the installed
# version is more recent

Package: *
Pin: release a=stable
Pin-Priority: 900

testing.pref:

# 100 <= P < 500: causes a version to be installed unless there is a
# version available belonging to some other distribution or the installed
# version is more recent

Package: *
Pin: release a=testing
Pin-Priority: 400

unstable.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=unstable
Pin-Priority: 50

experimental.pref:

# 0 < P < 100: causes a version to be installed only if there is no
# installed version of the package

Package: *
Pin: release a=experimental
Pin-Priority: 1

(Don't be afraid of the unstable/experimental stuff here. The priorities are low enough that it's never going to automatically install any of that stuff. Even the testing branch will behave, as it's only going to install the packages you want to be in testing.)

Now, creating a matching set for /etc/apt/sources.list.d:

stable.list: Copy from your original /etc/apt/sources.list. Rename the old file to something like sources.list.orig.

testing.list: Same as stable.list, except with testing.

unstable.list: Same as stable.list, except with unstable, and remove the security lists.

experimental.list: Same as unstable.list, except with experimental.

You can also add a oldstable in sources.lists.d and preferences.d (use a priority of 1), though this moniker will tend to expire and disappear before the next stable cycle. In cases like that, you can use http://archive.debian.org/debian/ and "hardcode" the Debian version (etch, lenny, etc.).

To install the testing version of a package, simply use aptitude install lib-foobar-package/testing, or just jump into aptitude's GUI and select the version inside of the package details (hit enter on the package you're looking at).

If you get complaints of package conflicts, look at the solutions first. In most cases, the first one is going to be "don't install this version". Learn to use the per-package accept/reject resolver choices. For example, if you're installing foobar-package/testing, and the first solution is "don't install foobar-package/testing", then mark that choice as rejected, and the other solutions will never veer to that path again. In cases like these, you'll probably have to install a few other testing packages.

If it's getting too hairy (like it's trying to upgrade libc or the kernel or some other huge core system), then you can either reject those upgrade paths or just back out of the initial upgrade altogether. Remember that it's only going to upgrade stuff to testing/unstable if you allow it to.

EDIT: Fixed some priority pins, and updated the list.

Linux – Are there any reasons NOT to run an Ubuntu server

There's no real reason not to, so long as you're not using any software that is unsupported on Ubuntu Server.

We run CentOS because it's got binary compatibility with RedHat Enterprise, which a lot of commercial software releases packages for. It makes my life easier, and it's really pretty stable (not that Ubuntu isn't).

If you know Ubuntu, go with Ubuntu.

Best Answer

Related Solutions

Debian – Running Stable and Installing Packages from Testing

Linux – Are there any reasons NOT to run an Ubuntu server

Related Topic