[collectd] "Redesign" of the Debian collectd package
sh at tokkee.org
Wed Sep 30 18:37:48 CEST 2009
This is a follow-up to Debian bug report [bts495936] and to other people
interested in that issue. Below, you'll find a summary of the changes, I
intend to implement in the Debian packaging of collectd. I'd be really
happy about feedback about that (even if it's just a short "ack" [on
IRC] ;-)). If I do not get any feedback within the next few days, I'll
assume that nobody has any major objections ;-)
The following main issues are supposed to be tackled:
* Get rid of the dependency on librrd.
* Make it easy to introduce custom configurations.
* Provide reasonable defaults for less experienced users.
* Be scalable (small as well as large setups should be equally simple
to set up)
This is what I'm planning to do:
* Introduce a new binary package "collectd-core":
This package ships the daemon as well as all plugins and the init
script. *All* plugin dependencies are suggested by that package (i.e.
not installed by default by any package managers, unless it's
configured to do so). The daemon will be enabled by default (in the
init script) but refuse to start, if /etc/collectd/collectd.conf (or
whatever has been configured in /etc/default/collectd) is not
available - to not break the package installation in that case, a
warning will be printed only but the script will not return with an
error status. I'm a bit uncertain about that but imho, it's the most
sensible behavior and I think there are other services in Debian that
behave the same way. The package ships a couple of sample
configurations in /usr/share/doc/.
* The collectd package mostly provides the configuration. I'm thinking
about disabling a few more plugins by default. It's your chance now
to speak up if you have any preferences in that regard. By default,
no output plugin will be enabled but a (medium-priority [*]) debconf
question will make it possible to chose (this includes preceeding)
zero or more plugins and, possibly, specify the most important config
options of the selected plugins (low-priority questions). The
specified configuration will be created as separate files (one for
each specified plugin) in /etc/collectd/collectd.conf.d/ which will
be included by /etc/collectd/collectd.conf. Of course, this will
still have to make sure that any existing (or modified) configuration
does not get overwritten -- since debconf will not handle all config
option, changes to those files *must* be supported. I'm not entirely
sure yet, how to solve that - any input would be very appreciated.
One approach might be to modify the *options* of the config
parameters supported by the package using sed or similar -- thus
leaving all other options untouched. This package will recommend
*all* plugin dependencies.
The "collectd-core" package will make it possible to build custom
packages on top of that, which provide a custom configuration and depend
on the appropriate libraries required by that configuration. That
package would have to depend on "collectd-core" and conflict / replace /
provide "collectd". Imho, this should be a fairly nice approach for
large (homogeneous as well as heterogeneous) setups (which, I suppose,
usually maintain a custom repository anyway).
Still, the "collectd" binary package will make it easy for novice users
to get started and -- by letting the user preseed the most important
config options through debconf -- should also provide a fairly nice way
to setup medium sized setups, thus providing an, imho, nicely scalable
I hope this handles all issues that have been raised by various people
in the discussions about this topic. Please tell me, if I'm missing some
There have been some requests to enable a network client sending to
multicast by default. I don't think that's a good idea, though, since it
would expose all values to "the world" by default. So, this would have
to be done in a separate package specifically created for that purpose
which does not make sense imho.
Possible *future* extensions (some random ideas):
* Provide some helper script to ease the creation of custom packages
(by letting the user specify a list of plugins and creating, e.g.,
the appropriate dependencies from that).
* Patch collectd to list the required deps if loading a plugin fails.
* Something like Apache's a2enmod / a2dismod to enable / disable
plugins through symlinks from /etc/collectd/plugins.enabled/ to
/etc/collectd/plugins.available. I'm not really sure if a user would
benefit from that, though, since the configuration would be split up
in *lots* of different parts (89 as of collectd 4.8).
* Provide even fancier ways to configure collectd. That's something
that should be done upstream though (and possibly include hooks to do
distribution-specific stuff like determining dependencies, etc.).
Further suggestions and comments are very appreciated!
[*] What is the default debconf priority? That should be a reasonable
priority for that question as well.
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090930/a00b74e2/attachment.pgp
More information about the collectd