[collectd] Bug#495936: collectd: Provide "minimal" collector only package
Sebastian Harl
sh at tokkee.org
Fri Aug 22 14:20:37 CEST 2008
Hi,
(Cc'ing the collectd mailing list as others might be interested in that
as well - see http://bugs.debian.org/495936 for the full history of the
bug report.)
On Fri, Aug 22, 2008 at 01:29:24PM +0200, Marc Fargas wrote:
> On Fri, Aug 22, 2008 at 1:05 PM, Sebastian Harl <sh at tokkee.org> wrote:
> > The only sane way to implement this is to have two packages (e.g.
> > "-server" and "-client") which conflict each other and provide different
> > configurations each (i.e. either rrdtool or network enabled). They would
> > both need the collectd binary and the plugins, so that would probably
> > have to be split out into an extra package (e.g. "-core") so that we
> > don't have to ship that twice. "-server" and "-client" would both depend
> > on that. The "collectd" package would then only be a dummy package
> > depending on "-server" (i.e. the one with rrdtool enabled), I guess.
> > Imho, this is the more reasonable default and preserves the "semantics"
> > on upgrades.
>
> That's nice! But I'd maybe name the "-client" as "-agent".
The term "agent" has never been used in the context of collectd and,
frankly, does not really make any sense to me. Also, "-client" is
commonly used in package names in Debian so I will stick to that.
> If I understand it correctly: collectd-server would be "the one
> receiving data" with a Depends on librrd4 and collectd-core; Then
> collectd-(agent|client) would not depend on librrd4 but yes on
> collectd-core.
Right.
> On the default configurations for both packages I'd enable the Listen
> & Server lines for the recommended multicast address, that would make
> collectd "just work" in a LAN environment! like:
>
> Listen "ff18::efc0:4a42"
Hrm... as collectd does not, by itself, provide any means of encryption
or authorization, I don't think it's a good idea to enable a listening
server by default. In fact, this would easily allow DoS attacks by
filling up the disk with random RRD files.
I think it's fine to add a "Server" line in the client package though as
this is what the package is (going to be) all about. Using a multicast
address for that sounds like a reasonable default to me. I'm not
entirely sure what happens if an IPv6 address is enabled when the host
does not support IPv6, so I will double-check that before enabling an
IPv6 multicast group as well.
> I wouldn't make both packages conflict, unless collectd-server
> description says "It also provides agent functionallity (as provided
> by collectd-agent package)" so people do not try to install both :)
Both packages would provide at least /etc/collectd/collectd.conf so they
_have_ to conflict.
> Off topic: how hard would it be to make debconf enable collectd
> plugins if the related packages are around (and dependencies?)
I was rather thinking about implementing something similar to Apache's
a2enmod / a2dismod mechanism. The configuration would then be split up
into one file for each plugin. Those files could then be added
(symlinked) into some directory (e.g. /etc/collectd/plugins.enabled)
which would be included by the main config file.
Some more logic could be built around that to (optionally!)
automatically install the dependencies of all enabled plugins (when
running "c4enmod" or during upgrades), etc.
Anyway, this is unrelated to this bug, so, if you're interested in
further discussion on this topic, either join the IRC channel #collectd
on freenode, start a new thread on the collectd mailingslist
(collectd at verplant.org) or open a new wishlist bug report against
collectd.
Cheers,
Sebastian
--
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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20080822/2395e050/attachment.pgp
More information about the collectd
mailing list