This site is now 100% read-only, and retired.

XML logo

Tools should be distinct from Services
Posted by dkg on Fri 18 Sep 2009 at 18:47

Modern daemon implementations can be run in a variety of ways, in a range of contexts. The daemon software itself can be a useful tool in environments where the associated traditional system service is neither needed nor desired. Unfortunately, common debian packaging practice has a tendency to conflate the two ideas, leading to some potentially nasty problems where only the tool itself is needed, but the system service is set up anyway.

How would i fix it? i'd suggest that we make a distinction between packages that provide tools and packages that provide system services. A package that provides the system service foo would need to depend on a package that provides the tool foo. But the tool foo should be available through the package manager without setting up a system service automatically.

Bad Examples

Here are some examples of this class of problem i've seen recently:

akonadi-server depends on mysql-server

akonadi is a project to provide extensible, cross-desktop storage for PIM data. It is a dependency of many pieces of the modern KDE4 desktop. Its current implementation relies on a private instantiation of mysqld, executed directly by the end user whose desktop is running.

This means that a sysadmin who installs a graphical calendar application suddenly now has (in addition to the user-instantiated local mysqld running as the akonadi backend) a full-blown system RDBMS service running and potentially consuming resources on her machine.

Wouldn't it be better if the /usr/sbin/mysqld tool itself was distinct from the system service?

puppetmaster depends on puppet

Puppet is a powerful framework for configuration management. A managed host installs the puppet package, which invokes a puppetd service to reconfigure the managed host by talking to a centralized server on the network. The central host installs the the puppetmaster package, which sets up a system puppetmasterd service. puppetmaster depends on puppet to make use of some of the functionality available in the package.

But this means that the central host now has puppetd running, and is being configured through the system itself! While some people may prefer to configure their all-powerful central host through the same configuration management system, this presents a nasty potential failure mode: if the configuration management goes awry and makes the managed nodes inaccessible, it could potentially take itself out too.

Shouldn't the puppet tools be distinct from the puppetd system service?

Update: puppet 0.25.4-1 resolves this problem with a package re-factoring; the tools are in puppet-common, and the puppet package retains its old semantics of running the system service. Looks good to me!

monkeysphere Build-Depends: openssh-server

The Monkeysphere is a framework for managing SSH authentication through the OpenPGP Web-of-Trust (i'm one of the authors). To ensure that the package interacts properly with the OpenSSH implementation, the monkeysphere source ships with a series of test suites that exercise both sshd and ssh.

This means that anyone trying to build the monkeysphere package must pull in openssh-server to satisfy the build-depends, thereby inadvertently starting up a potentially powerful network service on their build machine and maybe exposing it to remote access that they didn't intend.

Wouldn't it be better if the /usr/sbin/sshd tool was available without starting up the ssh system service?

Good Examples

Here are some examples of debian packaging that already understand and implement this distinction in some way:

apache2.2-bin is distinct from apache2-mpm-foo
Debian's apache packaging recently transitioned to split the apache tool into a separate package (apache2.2-bin) from the packages that provide an apache system service (apache2-mpm-foo). So apache can now be run by a regular user, for example as part of gnome-user-share.
git-core is distinct from git-daemon-run
git-core provides the git daemon subcommand, which is a tool capable of providing network access to a git repo. However, it does not set up a system service by default. The git-daemon-run package provides a way for an admin to quickly set up a "typical" system service to offer networked git access.
vblade is distinct from vblade-persist
vblade offers a simple, powerful utility to export a single file or block device as an AoE device. vblade-persist (disclosure: i wrote vblade-persist) provides a system service to configure exported devices, supervise them, keep them in service across system reboots, etc.

Tools are not Services: a Proposal

Let's consider an existing foo package which currently provides:

  • the tool itself (say, /usr/sbin/foo) and
  • sets up a system service running foo, including stock foo daemon configuration in /etc/foo/*, startup scripts at /etc/init.d/foo, service configs at /etc/default/foo, etc.

I suggest that this should be split into two packages. foo-bin would contain the tool itself, and foo (which Depends: foo-bin) would contain the service configuration information, postinst scripts to set it up and start it, etc. This would mean that every instance of apt-get install foo in someone's notes would retain identical semantics to the past, but packages which need the tool (but not the service) can now depend on foo-bin instead, leaving the system with fewer resources consumed, and fewer unmanaged services running.

For brand new packages (which don't have to account for a legacy of documentation which says apt-get install foo), i prefer the naming convention that the foo package includes the tool itself (after all, it does provide /usr/sbin/foo), and foo-service sets up a standard system service configured and running (and depends on foo).

Side Effects

This proposal would fix the problems noted above, but it would also offer some nice additional benefits. For example, it would make it easier to introduce an alternate system initialization process by creating alternate service packages (while leaving the tool package alone). Things like runit-services could become actual contenders for managing the running services, without colliding with the "stock" services installed by the bundled tool+service package.

The ability to create alternate service packages would also mean that maintainers who prefer radically different configuration defaults could offer their service instantiations as distinct packages. For example, one system-wide foo daemon (foo-service) versus a separate instance of the foo daemon per user (foo-peruser-service) or triggering a daemon via inetd (foo-inetd-service).

One negative side effect is that it adds some level of increased load on the package maintainers — if the service package and the tool package both come from the same source package, then some work needs to be done to figure out how to split them. If the tool and service packages have separate sources (like vblade and vblade-persist) then some coordinating footwork needs to be done between the two packages when any incompatible changes happen.

Questions? Disagreements? Next Steps?

Do you disagree with this proposal? If so, why? Unfortunately (to my mind), Debian has a long history of packages which conflate tools with services. Policy section 9.3.2 can even be read as deliberately blurring the line (though i'd argue that a cautious reading suggests that my proposal is not in opposition to policy):

Packages that include daemons for system services should place scripts in /etc/init.d to start or stop services at boot time or during a change of runlevel.

I feel like this particular conflict must have been hashed out before at some level — are there links to definitive discussion that i'm missing? Is there any reason we shouldn't push in general for this kind of distinction in debian daemon packages?

 

Comments on this Entry

Re: Tools should be distinct from Services
Posted by Anonymous (173.50.xx.xx) on Fri 18 Sep 2009 at 19:51

I love this idea.

A few other, less obvious, examples:

  • Many game packages include servers. These servers need not have separate packages for the server binaries, as many do; users might want to start the server themselves manually (or via a mechanism the client provides). However, the configuration for a system-wide server should go in a different package. (Example: pioneers.)
  • rsync: rather than having configuration for a system-wide daemon in the rsync package, disabled by default, just put it in rsync-service.
  • sane, which has a disabled-by-default system-wide configuration for "saned".
  • nethack. Why not split the dubiously useful system-wide recover-on-boot functionality into a separate package?

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (130.107.xx.xx) on Fri 18 Sep 2009 at 23:47
another example of relatively decent use: git-core (binaries) but gitosis (git repository hosting application), gitweb (web interface to git, even git-gui (graphical UI for git -- a service, if you will, that needs other things like X and tcl.

--jeremy

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Sat 19 Sep 2009 at 00:13
[ View Weblogs ]
I'm not sure these are examples of the concern that i'm raising here, though i'm certainly glad that none of these packages are bundled together with git-core automatically. They're good examples of reasonable packaging granularity, but none of them provide a system service in the sense i'm talking about, as far as i can tell. They're all tools, but neither provide nor start any system daemons.

gitosis appears to provide only a tool, along with instructions about how to enable the service if you want it (see /usr/share/doc/gitosis/README.Debian). I could be mistaken, though, as i've never administered it.

gitweb (which i've also never administered) also appears to provide a tool itself (code that can provide human-readable HTML-based views into a git repository), but does not start up a service (beyond dropping a script in /usr/lib/cgi-bin); it expects the service to be configured by the admin's reasonable configuration of a web server, which is beyond the scope of the packages.

git-gui also does not provide a service in the sense that i describe in the original post -- i don't think it provides a system daemon at all, or even anything that could be used as a system daemon.

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (71.241.xx.xx) on Sat 19 Sep 2009 at 00:13
This is Definately a step in the Right direction!
Less stuff running that is not needed allows a more customisable system.
I say this as a long time end user.
It is very annoying to have extra things loaded just because of "Dependencies".
I started out many years ago with Slackware.
Now I love debian's package system.
But as the years go by the Dependency Bloat seems to grow as well.
I think you have a good idea.
More to fine tuneable package selection.
Hope more people see and like your idea...
Thanks

[ Parent ]

X font server was "recomended"
Posted by Anonymous (74.216.xx.xx) on Sat 19 Sep 2009 at 21:11
Splitting packages like this makes some sense. Debconf and default off may make sense too.

Services should possibly be disabled (especially for non-loopback, but even that's a possible security/resource problem) by default with debconf priority high/critical. Having a service get automatically started when you install a different package seems like a problem. This is how many vulnerable services have been installed in the past (e.g. NT4 Option Pack, PWS, early sshd?).

You might also want to look at the changing package size limitation that was imposed by the ftpmasters. Splitting packages has many costs.

Requires should only be on tools. If the service is required, the package should be recomends just like the X font server was. This doesn't help much for transitions, but is worth pointing out.

The problem seems to be suited to a case by case basis.

Drew Scott Daniels
http://boxheap.net/ddaniels/resume.html

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (92.39.xx.xx) on Sat 19 Sep 2009 at 22:33
I think you mean that configuration is separate from binaries/software, and both can be managed by the packages system. I think the exim packages have this set up quite well.

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (87.184.xx.xx) on Tue 22 Sep 2009 at 11:39
Wouldn't build chroots have rc.policy to not start sshd? The disadvantage seems imaginary for properly configured build hosts.

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Tue 22 Sep 2009 at 14:51
[ View Weblogs ]
most build chroots don't have sshd previously installed. Are you suggesting that the administrators are supposed to place /etc/rc2.d/K20ssh symlinks anyway? Should build build chroots also have rc.policy to not start other network services that potentially open up access to local resources (e.g. cups, any of the various ftpds, etc)?

When a new network-accessible service package is added to debian, do build chroots automatically get rc.policy fixes to disable that service?

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (84.226.xx.xx) on Mon 30 Nov 2009 at 21:02
I can mainly speak for one of your examples but have a few other general remarks later:

puppetmaster and puppetd share a huge code basis, the actual binaries are quite small and they are even getting smaller, as puppet devlopers would like to have only one tool for everything.
Anyway either you split this huge codebasis into a -lib package or you would end up with duplicated code. The former seems to be definitely the solution to go, but - as you mentioned - will give more load on package maintainers.

Besides that: your good example git-daemon depends on git-core. What's the difference to puppetmaster depending on puppet? That puppet comes with a services called puppetd, which is enabled by default? This will lead us to may more general comments:

But I'd like to have a more general view on your main criticism in this example. Your main point is that puppetd gets automatically started. Isn't this itself the more general and main problem?
Why does Debian automatically enable services? Isn't rather this a bad behavior?
As you mentioned you might get unconfigured services or unwanted services automatically running.
Besides that: let's have a look on desktop systems: I have plenty of network services installed on my laptop due to development reasons: apache, mysql, postgresql, dhcp, tftp, dns and so on. And they all get automatically enabled on my laptop or desktop. They are even always started while updating and I had already turned them off!

Isn't the automatic enabling of services rather the bad behavior? Aren't you trying to solve a problem with a solution that will bring much more workload to package maintainers which could be solved much more easy: Don't enable services by default.

For example every RedHat based distribution (like Fedora etc.) or every BSD-Flavor behaves like that. I never understood nor do I currently why Debian thinks that it should enable every service by default and I end up writing silly scripts for my desktop/laptops systems which disable every unwanted services after every update of them. I need these services on my laptop for development, but they don't need to run everytime nor start automatically. I could easily tell you various reasons for server systems as well, why I might not want to have services to start automatically.

PS: There might be an easy solution for that and I simply might not yet have found it. But various Debian developers couldn't help me as well, so I assume there isn't an easy solution for it. I simply don't see any valid reason to enable services by default. If I want to have a service as a sysadmin, besides installing it, I should also know how to enable and start it or I have a cool configuration management tool, which does that for me. Still it would be more secure by default to not enable services automatically and less work for package maintainers.

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (84.226.xx.xx) on Mon 30 Nov 2009 at 21:20
ok, maybe I misinterpreted a bit your suggestions. So see my comments more supportive to not enable services by default and split the enable and start process into the service package.

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Mon 30 Nov 2009 at 22:26
[ View Weblogs ]
Exactly: ship the tools as one package, but without any automatic service provision. Then put the initscripts into a separate package which depends on the package with the tools.

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (62.12.xx.xx) on Wed 2 Dec 2009 at 09:58
And the initscripts would still be enabled by default? This wouldn't solve the problem which all developers have on their systems. They need the initscripts but they simply don't need to run the service automatically nor they want to have re-enabled it after every update.

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Wed 2 Dec 2009 at 17:11
[ View Weblogs ]
What's the use case where developers need the initscripts but don't need the system service? The whole point of an initscript is to run the system service.

A developer who wants to manually start the system service for her work but leave it generally disabled would install the service package (which Depends: on the tools package). Then she would instruct the system initialization system to not start the service automatically. For example, in recent versions of sysv-rc:

update-rc.d foo disable
or in older versions of sysv-rc, something like:
update-rc.d foo stop 20 0 1 2 3 4 5 6
She can now start and stop the system service as needed with /etc/init.d/foo [start|stop]. This particular use case has been solved on debian systems for many years.

The concern i raised above is about the use case where someone legitimately needs the tools, but has no plans or need to run the system service at all. We currently don't handle that situation well.

[ Parent ]

Re: Tools should be distinct from Services
Posted by Anonymous (62.12.xx.xx) on Thu 10 Dec 2009 at 08:00
Right. The discussion diverted a bit and we don't really have to continue it here. I simply thought that your proposals might be as well a solution for the following problem:

For example if a developer is developing php-applications using mysql or postgresql and maybe she's also doing from time to time some Java development using Tomcat and the two DBMS.

So I'd like to have apache, tomcat, mysql and postgres on my desktop system. I install them configure them. Disable them to come up at the boot-time, done.

However as it is a desktop system the developer might be using testing or even sid, so that she simply can use some newer tools, hence updates happen quite often, as well the aboved mentioned services get updated. And everytime one of the services gets updated it's reenabled to start during system initialization and it's even restarted!
Doesn't really matter if she have only a few services and if forgot it once or twice, she will see during the next system initialization and will remember it. Is a bit uglier if she has for example lighttpd and apache installed and both running on port 80, if both gets updated and restarted...
It matters more if she's a system developers and might have dhcpd (for various reasons) on her system. If she forgets to disable that one, she might suddenly concur with the company's one. And so on.

What I simply wanted to add to the discussion is that I think it's in general a bad behavior of Debian to enable services by default and to re-enable and start them on updates. Which is not something you were talking about, but which might be considered as well in this discussion.

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Thu 10 Dec 2009 at 16:36
[ View Weblogs ]
Mr. Anonymous wrote:
I think it's in general a bad behavior of Debian to enable services by default and to re-enable and start them on updates.
And i'm trying to point out that if you've disabled the services properly, i think it is a serious bug if they get re-enabled and restarted on updates. It should not happen, according to policy, from what i can tell.

If that happens to you, please report it and we can get it fixed. This is indeed a different issue than the one i'm raising, but it's worth fixing too.

[ Parent ]

Re: Tools should be distinct from Services
Posted by dkg (216.254.xx.xx) on Mon 15 Mar 2010 at 22:44
[ View Weblogs ]
It was just pointed out to me that puppet version 0.25.4-1 includes a package re-factoring which splits the tools out into puppet-common so that puppetmasters don't automatically have the puppet service running. So they resolved the issue i raised here for the puppet-related packages.

Kudos to the puppet team for their packaging work!

[ Parent ]