Summary: | rrd files in /var/log/rrd/collectd/localhost/iptables-filter-HOSTILE/ not being updated | ||
---|---|---|---|
Product: | IPFire | Reporter: | Adolf Belka <adolf.belka> |
Component: | --- | Assignee: | Adolf Belka <adolf.belka> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | Minor Usability | ||
Priority: | - Unknown - | CC: | bbitsch, michael.tremer, peter.mueller, rejeancgrpq |
Version: | 2 | ||
Hardware: | unspecified | ||
OS: | Unspecified | ||
Attachments: |
repair script
corrected repair script |
Description
Adolf Belka
2022-04-03 12:13:33 UTC
I can reproduce the error. I can also give an explanation. collectd.conf tries to collect entries in chain HOSTILE, but the check is made in chain HOSTILE_DROP. Changing this in collectd.conf and /var/ipfire/graphs.pl brings up the data again. Affected files /etc/collectd.conf: <plugin iptables> ... Chain filter HOSTILE DROP_HOSTILE -> Chain filter HOSTILE_DROP DROP_HOSTILE /var/ipfire/graphs.pl: in function updatefwhitsgraph "DEF:hostile=".$mainsettings{'RRDLOG'}."/collectd/localhost/iptables-filter-HOSTILE/ipt_bytes-DROP_HOSTILE.rrd:value:AVERAGE", -> "DEF:hostile=".$mainsettings{'RRDLOG'}."/collectd/localhost/iptables-filter-HOSTILE_DROP/ipt_bytes-DROP_HOSTILE.rrd:value:AVERAGE", Didn't check whether the graphs/values for week/month/year were present. Also didn't search for a transport of the old values in xxx-HOSTILE RRDS into the xxx-HOSTILE_DROP RRDs. I will give that a try. Had a look through the commits and not sure I can see where that has been changed but will look further tomorrow when I am not feeling so tired. Thanks for the guidance. Created attachment 1030 [details]
repair script
Comment on attachment 1030 [details]
repair script
A first attempt to solve the problem.
Hope it is complete, correct and helpful.
I just tried the script on a vm testbed clone. It didn't work for me. I had read through it beforehand but had missed that the line doing sed on graphs.pl presumes you are in the /var/ipfire/ directory or at least a directory that has a path that knows where graphs.pl is. Anyway, I manually edited the files on my vm clone system and the graph then worked. It shows 0Bps for the hour, day and week entry as the vm does not get any Hostile Networks through to it because my boundary production IPFire is set to drop them all. The month and year have -nan as the entry. Anyway this looks to be working so I will no look at creating a patch to fix this and confirm with an install that it actually works before submitting. Sorry for the incompleteness. :( Yes, the sed command must work on /var/ipfire/graphs.pl I should look closer if I make a resume of my manually changes. Created attachment 1031 [details]
corrected repair script
I have done a build of the changes and installed it on a vm in my testbed system. The graph was created as expected. I will submit a patch of the changes One thing I have noticed is that any backup done with CU165/166 will have the directory iptables-filter-HOSTILE backed up. Once the directory iptables-filter-HOSTILE_DROP is present then that will be backed up. It could leave some people with an orphaned directory and files. Could always be removed if present by the update.sh script for the CU that this fix is implemented with. Patch submitted to dev mailing list and to patchwork. https://patchwork.ipfire.org/project/ipfire/list/?series=2711 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=918ee09b3bf19cd07e340c69d80769391abd341f https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d4ea277285f6a28c3f4bcdfd1559b37d51662d2d *** Bug 12823 has been marked as a duplicate of this bug. *** Upgraded a CU166 vm to CU167 and confirmed that the graphs now work correctly after a short while to fill some data. The directory /var/log/rrd/collectd/localhost/iptables-filter-HOSTILE/ should be deleted in the CU update.sh script |