From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on drop-hostile graph changes for bug#12981 Date: Sat, 10 Feb 2024 18:08:56 +0100 Message-ID: <3e98e120-8dae-49db-9da6-56801ea60e9e@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5373261981161336345==" List-Id: --===============5373261981161336345== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 10/02/2024 15:22, Adolf Belka wrote: > 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): >> >> # Cleanup the collectd RRD (graphs) >> %weekly * * /bin/find /var/log/rrd -mtime +365 -type f -name '*.rrd' -dele= te -o -type d -empty -delete > The problem here is that we are changing the Hostile data from DROP_HOSTILE= into DROP_HOSTILE_IN & DROP_HOSTILE_OUT but we want to keep the history of D= ROP_HOSTILE and in a fresh install it is only creating the DROP_HOSTILE_IN an= d DROP_HOSTILE_OUT directories and the graph is also looking if there is any = data historically from the DROP_HOSTILE data. >> >> >>> On Feb 10, 2024, at 7:14 AM, Adolf Belka > wrote: >>> >>> Hi Michael, >>> >>> Sorry for delay in feedback. >>> >>> I tried out the drop-hostile changes with both an update from CU182 to CU= 184 and a fresh install of CU184 and had an error message showing with the gr= aph 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 = directory and not the iptables-filter-HOSTILE_DROP_IN or iptables-filter-HOST= ILE_DROP_OUT directories. >>> >>> Maybe something needs to be done in the update.sh script to create the ne= w 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-DR= OP_HOSTILE.rrd >>> >>> was not present. >>> >>> Checking the directories there were the iptables-filter-HOSTILE_DROP_IN a= nd iptables-filter-HOSTILE_DROP_OUT directories but not the iptables-filter-H= OSTILE_DROP directory. >>> >>> For a fresh install then there will be no history with the old naming so = here I would think we need to create the old directory name as standard for e= veryone but it will just not have any data. If the user does a restore of an = old backup then that HOSTILE_DROP data would become available. > > I think I might have found out what has caused this. In my original patch s= et I changed collectd.conf to only chain the filters for the IN and OUT and I= removed the Chain filter HOSTILE_DROP DROP_HOSTILE entry in the plugin iptab= les section. > > As we are continuing to use the HOSTILE_DROP for the history I have added t= hat old line back into collectd.conf and am running a build and will test out= that fresh install to see if it solves the problem for that particular issue. > Looks like I don't understand the whole collectd/rrd/graphs thing enough. Adding that line back into the collectd.conf file did not cause the iptables-= filter-HOSTILE_DROP directory to be created. I have looked through all the code changes done and I can't understand why th= is is occurring let alone how to fix it. Regards, Adolf. > Regards, > Adolf. >>> >>> >>> On the fresh install of CU148 I did a restore of a backup from CU182 and = then the graph worked as all three directories then were present. >>> >>> >>> Regards, >>> >>> Adolf. >>> >> --===============5373261981161336345==--