From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Subject: Re: Feedback on drop-hostile graph changes for bug#12981 Date: Sat, 10 Feb 2024 15:22:49 +0100 Message-ID: <a6c83063-2a1a-4882-8d84-e1455c933563@ipfire.org> In-Reply-To: <E6A1F37D-E967-457D-8E15-BFBAC51F4088@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8857028306171496728==" List-Id: <development.lists.ipfire.org> --===============8857028306171496728== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Jon and Michael, On 10/02/2024 15:09, jon wrote: > Keep in mind there is a fcron for old RRDs (over 1 year old): >=20 > # Cleanup the collectd RRD (graphs) > %weekly * * /bin/find /var/log/rrd -mtime +365 -type f -name '*.rrd' -delet= e -o -type d -empty -delete The problem here is that we are changing the Hostile data from DROP_HOSTILE i= nto DROP_HOSTILE_IN & DROP_HOSTILE_OUT but we want to keep the history of DRO= P_HOSTILE and in a fresh install it is only creating the DROP_HOSTILE_IN and = DROP_HOSTILE_OUT directories and the graph is also looking if there is any da= ta historically from the DROP_HOSTILE data. >=20 >=20 >> On Feb 10, 2024, at 7:14 AM, Adolf Belka <adolf.belka(a)ipfire.org <mailto= :adolf.belka(a)ipfire.org>> wrote: >> >> Hi Michael, >> >> Sorry for delay in feedback. >> >> I tried out the drop-hostile changes with both an update from CU182 to CU1= 84 and a fresh install of CU184 and had an error message showing with the gra= ph in both cases. >> >> When I did the update from CU182 to CU184 the error message >> >> /var/log/rrd/collectd/localhost/iptables-filter-HOSTILE_DROP_IN/ipt_bytes-= DROP_HOSTILE.rrd >> >> was not present. >> >> See the screenshot attachment. >> >> Checking the directories there was only the iptables-filter-HOSTILE_DROP d= irectory and not the iptables-filter-HOSTILE_DROP_IN or iptables-filter-HOSTI= LE_DROP_OUT directories. >> >> Maybe something needs to be done in the update.sh script to create the new= directories. I am not sure what though. >> >> >> When I did a fresh install from CU184 it was the other way round. >> >> /var/log/rrd/collectd/localhost/iptables-filter-HOSTILE_DROP/ipt_bytes-DRO= P_HOSTILE.rrd >> >> was not present. >> >> Checking the directories there were the iptables-filter-HOSTILE_DROP_IN an= d iptables-filter-HOSTILE_DROP_OUT directories but not the iptables-filter-HO= STILE_DROP directory. >> >> For a fresh install then there will be no history with the old naming so h= ere I would think we need to create the old directory name as standard for ev= eryone but it will just not have any data. If the user does a restore of an o= ld backup then that HOSTILE_DROP data would become available. I think I might have found out what has caused this. In my original patch set= I changed collectd.conf to only chain the filters for the IN and OUT and I r= emoved the Chain filter HOSTILE_DROP DROP_HOSTILE entry in the plugin iptable= s section. As we are continuing to use the HOSTILE_DROP for the history I have added tha= t old line back into collectd.conf and am running a build and will test out t= hat fresh install to see if it solves the problem for that particular issue. Regards, Adolf. >> >> >> On the fresh install of CU148 I did a restore of a backup from CU182 and t= hen the graph worked as all three directories then were present. >> >> >> Regards, >> >> Adolf. >> <firewall hits graph core update.png> >=20 --===============8857028306171496728==--