From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4g0ptD1QD0z2yXK for ; Wed, 22 Apr 2026 06:17:40 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [IPv6:2001:678:b28::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (secp384r1 raw public key) server-digest SHA384 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (not verified)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4g0pt85YTNz2xQW for ; Wed, 22 Apr 2026 06:17:36 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4g0pt663G8z33B; Wed, 22 Apr 2026 06:17:34 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1776838655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N5DCIKSKN6Vun9tkJW7R7HLUCXZtnayNNziUdfzHGZE=; b=Cd/1nJJ3fqj5kH68l57xg+AoBJcoKuJtd+QmCeDhkXriPZ1sK7q644/Hk7W4Llj+z1kc9t S11JM32bZ9dQs2Dg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1776838655; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N5DCIKSKN6Vun9tkJW7R7HLUCXZtnayNNziUdfzHGZE=; b=r2qu0ijAkaOWSmxIuQid7g7hY+QvfG5kk5Pk9YsRBwc8jgBh64hrjsIMIdA+H0vuWXIv39 vNtqK+giHyJ0EugMf172j6qdjJB6NMMYacupgAIaceWQNgQIIl4ey/gsAV+AgPkghqCA64 YVlfCmy3ACftdxLwH/6TGqzeu2a4oSehgHJrfj1HoQCszi4UhIwdoi8gzCx2kGI/Aq3vrs xTraj+yYimRMlctIs7Kh8VGjALJKubPycaa5qBXPwnsANcEt0SNdmGuV0luzOB4aLrhcOF cEqf4Jtn5AfYYKYPO6RB6rRattwoOC/bLEqkxPQGm2W/p8I2JjZfotQtmD8REw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Question about potential consequence of patch to rotate Suricata logs daily. From: Michael Tremer In-Reply-To: Date: Wed, 22 Apr 2026 07:17:34 +0100 Cc: Bernhard Bitsch , "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <5F86412B-8747-4CB5-9BBC-0C95AE831418@ipfire.org> References: To: Adolf Belka Hello, I think your concerns are important and I do share a lot of them. We do have very inconsistent logging - or rather the rotation of the = logs is not very consistent. Your initial assumption is correct, that at the top of the configuration = file, we intend to rotate 52 times a year which results in keeping logs = for a whole year split into chunks of one per week. That being said, some other logs are then marked to rotate monthly, e.g. = /var/log/wtmp. So we would have up to 52 months of those. Why is that? I = am not sure=E2=80=A6 The motivation alone seems to be expected size. /var/log/wtmp does not = grow a lot, so a rotation of a couple of bytes is not really worth it. = Let=E2=80=99s do it weekly. Suricata=E2=80=99s logs are actually growing really fast on some = machines and people have been complaining about high disk usage, so I = thought it would be more suitable to rotate once a day. Generally I think 52 days is plenty of logging. If people prefer to = store more than that, on the firewall itself is potentially not the best = place to do so. There is a remote syslogging option available. Some data, like the graphs or even the Suricata alerts are being stored = separately and they do have other retention times. Hope this helps. -Michael > On 21 Apr 2026, at 21:08, Adolf Belka wrote: >=20 > Hi Bernhard, >=20 > Thanks for the clarification. So my worries were unfounded, good to = know. >=20 > Regards, >=20 > Adolf. >=20 > On 21/04/2026 19:05, Bernhard Bitsch wrote: >> Hi, >> the IPS graphs are generated from the iptables collectd samplings. >> They are independent from the log files. >> The log section of the WUI isn't touched, also. It depends on = /var/log/suricata/{fast|alert}.log only. >> BR, >> Bernhard >> Am 21.04.2026 um 18:20 schrieb Adolf Belka: >>> Hi Michael, >>>=20 >>> I saw that patch >>>=20 >>> https://git.ipfire.org/? = p=3Dipfire-2.x.git;a=3Dcommit;h=3D30ccb9ed80ee3ad70403794da4c937fd183b9bd8= >>>=20 >>> had been created. >>>=20 >>> It seems to me that this change will mean that there will only ever = be 52 days worth of logs for Suricata. The global value for rotate is 52 = which is intended to give a tear's worth of data for the various graphs. >>>=20 >>> With the Suricata logs being rotated daily and with the same global = rotate value ( there is no modified rotate value for the Suricata = section) then there will only ever be 52 days worth of Suricata Logs. = This will mean that the Suricata throughput graph will only show about 7 = weeks worth of data when the Year option is selected. >>>=20 >>> Was this the intent? >>>=20 >>> If not then there probably needs to be a rotate entry in the = Suricata section with rotate 393 to give a year's worth of data but then = that will put back the same amount of logs for people who have very = small disk drives. >>>=20 >>> If yes then maybe the Year option on the Suricata graph should be = removed or changed to 7 weeks as the 52 days would then be around 7.5 = weeks of data available. >>>=20 >>> It could also be that I am not familiar enough with the rotate = package and therefore my concerns are not valid. So I am open to getting = clarification. >>>=20 >>> Best regards, >>>=20 >>> Adolf. >>>=20 >=20 >=20