Bug#495936: collectd: Provide minimal collector only package
On Aug 22, Joey Hess jo...@debian.org wrote: * The default rrd setup was appropriate for only one or two out of dozens of machines collectd was installed on. Agreed. I was considering deploying collected at work on ~500 servers and I am shocked that this has not been solved yet. Everywhere except on single-host networks (which I believe are not very relevant for a package whose only purpose in life is efficiently and scalably monitoring servers), the common use case for this package is to be configured as client, not as the graphing server. * On all the rest, by the time I edited the config file to enable network reporting and disable rrd, /var/lib/collectd had already had a dozen or more MB of rrd files written to it, which added another step of going around and cleaning that up, which I have yet to finish doing. Indeed, it is quite annoying having to clean up after a package on every system because the default configuration is designed for the special case instead of the common one. -- ciao, Marco signature.asc Description: Digital signature
Bug#495936: collectd: Provide minimal collector only package
Joey Hess jo...@debian.org writes: (Oh, I see I've missed this one while filing Bug#544311...) My observations in setting up collectd for my machines are: * The default rrd setup was appropriate for only one or two out of dozens of machines collectd was installed on. * On all the rest, by the time I edited the config file to enable network reporting and disable rrd, /var/lib/collectd had already had a dozen or more MB of rrd files written to it, which added another step of going around and cleaning that up, which I have yet to finish doing. [...] Splitting the package to collecd and collectd-core would better address my needs. I don't know if an additional collectd-client type package would be useful, since I'd still have to edit the config file to configure the host to log to (AFAIK my vpn doesn't support multicast). My opinion is to have a base collectd package, which in turn Recommends: collectd-rrdtool containing just the aforementioned plugin. As it was noted, the configuration file as it's currently supplied is going to be useless with the rrdtool plugin removed. Therefore, and also to avoid the ``disk full'' situation, I ask for an explicit activation for collectd, like it's done, e. g., for the smartmontools package: $ ar p smartmontools_5.38-3_amd64.deb data.tar.gz \ | tar -zxO ./etc/default/smartmontools # Defaults for smartmontools initscript (/etc/init.d/smartmontools) # This is a POSIX shell fragment # List of devices you want to explicitly enable S.M.A.R.T. for # Not needed (and not recommended) if the device is monitored by smartd #enable_smart=/dev/hda /dev/hdb # uncomment to start smartd on system startup #start_smartd=yes # uncomment to pass additional options to smartd on startup #smartd_opts=--interval=1800 $ (Note the commented out `start_smartd=yes' option.) -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#495936: collectd: Provide minimal collector only package
My observations in setting up collectd for my machines are: * The default rrd setup was appropriate for only one or two out of dozens of machines collectd was installed on. * On all the rest, by the time I edited the config file to enable network reporting and disable rrd, /var/lib/collectd had already had a dozen or more MB of rrd files written to it, which added another step of going around and cleaning that up, which I have yet to finish doing. * A few of my clients have limited disk space and it would be nice to be able to drop the unnecessary plugin depends from them. Splitting the package to collecd and collectd-core would better address my needs. I don't know if an additional collectd-client type package would be useful, since I'd still have to edit the config file to configure the host to log to (AFAIK my vpn doesn't support multicast). -- see shy jo signature.asc Description: Digital signature
Bug#495936: collectd: Provide minimal collector only package
Just wondering, maybe moving the rrdtool plugin to its own package (Suggested by collectd) would do the job? On Thu, Aug 21, 2008 at 3:05 PM, Sebastian Harl [EMAIL PROTECTED] wrote: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495936: collectd: Provide minimal collector only package
Hi, On Fri, Aug 22, 2008 at 10:45:05AM +0200, Marc Fargas wrote: Just wondering, maybe moving the rrdtool plugin to its own package (Suggested by collectd) would do the job? No. Then the default installation would not provide any useful functionality. The same could be achieved by moving librrd from Depends: to Recommends: (just like for any other plugin with external dependencies) but I did not do that for exactly the same reason. 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. Any thoughts? 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 signature.asc Description: Digital signature
Bug#495936: collectd: Provide minimal collector only package
On Fri, Aug 22, 2008 at 1:05 PM, Sebastian Harl [EMAIL PROTECTED] 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. 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. 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 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 :) Off topic: how hard would it be to make debconf enable collectd plugins if the related packages are around (and dependencies?) my packaging skills are limited to my own python scripts so I don't know :) Thanks for all the quick replies ;) Regards, Marc -- http://www.marcfargas.com - will be finished someday. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495936: collectd: Provide minimal collector only package
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 [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) 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 signature.asc Description: Digital signature
Bug#495936: collectd: Provide minimal collector only package
Package: collectd Version: 4.4.2-1+b1 Severity: wishlist Hi, Installing collectd depends on librrd which then depends on libpango, etc. I'm not sure but if you are only intereseted in collecting data and sending it to a server, is librrd needed on the clients? It'd be nice to have a collectd-collector agent which didn't depend on server-only libs so Clients would have much fewer dependencies. I don't know if that's even possible, that's why I set wishlist ;)) Regards, Marc -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (500, 'gutsy'), (300, 'unstable'), (150, 'experimental'), (100, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495936: collectd: Provide minimal collector only package
Hi Marc, On Thu, Aug 21, 2008 at 02:45:56PM +0200, Marc Fargas wrote: Installing collectd depends on librrd which then depends on libpango, etc. I'm not sure but if you are only intereseted in collecting data and sending it to a server, is librrd needed on the clients? Nope, it's not needed in that case. It'd be nice to have a collectd-collector agent which didn't depend on server-only libs so Clients would have much fewer dependencies. That sounds like a good idea to me. I'm not entirely sure how to implement that but I will come up with something. This could be basically the same package with a different default configuration and thus without the dependency on librrd. I don't like to ship the same stuff twice though ... I don't know if that's even possible, that's why I set wishlist ;)) Well, this would have been wishlist in any case... ;-) 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 signature.asc Description: Digital signature
Bug#495936: collectd: Provide minimal collector only package
On Thu, Aug 21, 2008 at 3:05 PM, Sebastian Harl [EMAIL PROTECTED] wrote: It'd be nice to have a collectd-collector agent which didn't depend on server-only libs so Clients would have much fewer dependencies. That sounds like a good idea to me. I'm not entirely sure how to implement that but I will come up with something. This could be basically the same package with a different default configuration and thus without the dependency on librrd. I don't like to ship the same stuff twice though ... One option could be to move librrd to Recommends, but then people would be left with an unusable package if they don't pay attention. That's why I said about a different package, althought being almost the same, it makes things clear :) Thanks for taking a look at it :) -- http://www.marcfargas.com - will be finished someday. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
