Red Hat Bugzilla – Bug 479208
collectd is built without iptables plugin
Last modified: 2009-03-04 11:29:47 EST
Description of problem:
The iptables plugin is missing from the collectd package.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install collectd.
2. Notice that /usr/lib64/collectd/iptables.so doesn't exist.
/usr/lib64/collectd/iptables.so is missing.
/usr/lib64/collectd/iptables.so should be there.
The changelog says that the iptables plugin was disabled, but then reenabled again:
* Mon Jun 09 2008 Alan Pevec <email@example.com> 4.4.1-1
- New upstream version 4.4.1.
- plugin changes: reenable iptables, disable ascent
* Tue May 27 2008 Alan Pevec <firstname.lastname@example.org> 4.4.0-2
- disable iptables/libiptc
I can confirm this. Looking at configure.in, the iptables plugin requires libiptc.h, so I'm guessing that the plugin disappeared because of bug #462207 (filed against F-9, but I can confirm that it's the same on F-10).
For this to not go unnoticed from now on, you might want to explicitly list all of the expected plugins in the %files section of the spec file. I would definitely do that if I were the owner of the package :-)
Created attachment 328543 [details]
patch to update libip6tc.c for newer def of in6_addr in <netinet/in.h>
(In reply to comment #1)
> I can confirm this. Looking at configure.in, the iptables plugin requires
> libiptc.h, so I'm guessing that the plugin disappeared because of bug #462207
> (filed against F-9, but I can confirm that it's the same on F-10).
The collectd source comes with its own libiptc.h, so I think that's not the problem.
If I change '--without-libiptc' to '--with-libiptc' (or simply remove it) in the spec file, the build blows up on me:
gcc -DHAVE_CONFIG_H -I. -I../../src -DIPTABLES_VERSION=\"1.4.0\" -I/lib/modules/18.104.22.168-159.fc10.x86_64/source/include -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c libip4tc.c -fPIC -DPIC -o .libs/libiptc_la-libip4tc.o
libip6tc.c: In function 'ipv6_prefix_length':
libip6tc.c:141: error: 'const struct in6_addr' has no member named 'in6_u'
libip6tc.c:145: error: 'const struct in6_addr' has no member named 'in6_u'
make: *** [libiptc_la-libip6tc.lo] Error 1
The problem appears to be that the definition of in6_addr in <netinet/in.h> changed sometime after collectd started shipping its own copy of the libiptc source.
For a discussion of the problem, see here
under the heading "backport ufw 0.22/iptable to hardy. Bug #268931".
There appears to be a simple solution, viz., replacing 'in6_u.u6_addr32' with 's6_addr32' in src/libiptc/libip6tc.c.
I've attached a patch for this. This change is sufficient for getting the source RPM to build an iptables.so plugin. (I haven't tested the plugin yet, however, so I can't say whether this change is sufficient for building a *working* iptables.so plugin, though.)
Also, changes to the spec file:
Remove '--without-libiptc', add '--enable-iptables'.
(In reply to comment #3)
> (I haven't tested the plugin yet,
> however, so I can't say whether this change is sufficient for building a
> *working* iptables.so plugin, though.)
I'm collecting some data with it now, so, yes, my patch does appear to work.
patched upstream a30f785e3411091fceb2f5c850beb5067c18396d
rebasing to 4.5.3 which includes it
collectd-4.5.3-1.fc10 has been submitted as an update for Fedora 10.
collectd-4.5.3-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.