Re: Packages should not Conflict on the basis of duplicate funct
> > Ok, let's bring this back to implementation. How would you propose we handle
> > this? Currently daemons install, set themselves up, and begin running.
> d) have something that keeps track of installed services, perhaps with
> priorities akin to alternatives. If there weren't an issue of
> services being run either in inetd or standalone, this could
> be accomplished with a souped-up update-inetd.
This debate has been making me wonder about a specific daemon control package.
The idea is that it would provide a file, or command, which would be checked
by the /etc/init.d of a package which is thinking of starting a daemon.
If the daemon control package is not installed then the init.d script should
just start the daemon as currently. If it is installed then the init.d
script will be told whether to start the daemon, to just start it on certain
interfaces or non default ports or ...
The actual package would be simple to write (probably just shell scripts), but
it would be best to have a comprehensive set of things which it should do
before starting to code.
Some of this seems similar to debconf, though I get the impression that
debconf is intended to be invoked at package installation time, rather than
at init runlevel changes. The daemon control package should certainly
integrate with debconf to determine the initial state for the daemons, though
this would probably be done by the packages themselves, i.e. they ask
"should I be started by default" and do a
daemoncontrol-set 'packagename' on
(or similar)
I would also like it to integrate with the PCMCIA schemes. For example I run
various daemons on my laptop when it is connected to the network at work,
and different ones when it is connected to the network at home, but usually
these are just wasting memory when it is not connected to a network at all.
I have another laptop which I use as a demonstration firewall, as well as it
being loaded up with network probing tools etc. I have tests in its init.d
scripts to check what mode it is in to decide whether to start or not.
Sometimes your laptop may sit behind a SOCKS firewall, and at other times not.
Note that Silicon Graphics IRIX has a scheme like this which allows daemons
to be installed but not enabled. I suspect in their case it is driven by
their desire to have a fancy graphical interface with a 'click here to enable
security hole' feature.
This scheme should provide a balance between the people who want things to
just install and run (because that should be its default behaviour) and those
who want to OK everything. Daemoncontrol would be a convenient place to put
a flag which says 'ask me (the user) before enabling any daemons'
John Lines
Reply to: