Description
-----------

After the recent Suricata logrotate change, the IPS log page can appear to
delete or lose the previous day's IPS events shortly after midnight.

The underlying Suricata log does not appear to be deleted. Instead, the web UI
appears to look at the wrong rotated file for the selected date.

Source-side regression candidate:

  30ccb9ed80ee3ad70403794da4c937fd183b9bd8
  logrotate: Rotate Suricata logs daily
  AuthorDate: Tue, 21 Apr 2026 10:32:11 +0100 (09:32 +0000)

That commit changes /var/log/suricata/*.log rotation from weekly to daily in:

  config/etc/logrotate.conf

Current relevant logrotate block:

  /var/log/suricata/*.log {
      daily
      copytruncate
      notifempty
      missingok
      sharedscripts
      postrotate
          /bin/kill -HUP `cat /var/run/suricata.pid 2> /dev/null` 2> /dev/null || true
      endscript
  }

However, the IPS log viewer still calculates the rotated log suffix using
week-based logic:

  html/cgi-bin/logs.cgi/ids.dat

Relevant code: https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/logs.cgi/ids.dat;hb=30ccb9ed80ee3ad70403794da4c937fd183b9bd8#l136

  $datediff=int(($doy-$tdoy)/7);

The same CGI then maps the calculated datediff to:

  /var/log/suricata/fast.log
  /var/log/suricata/fast.log.$datediff.gz

This appears to be incompatible with daily log rotation. After midnight,
yesterday's events are moved to fast.log.1.gz, but the CGI can still calculate
datediff == 0 for yesterday and read the new/current fast.log instead.

Steps to reproduce
------------------

1. Use an IPFire build that contains commit:

     30ccb9ed80ee3ad70403794da4c937fd183b9bd8

   or otherwise has daily Suricata rotation in /etc/logrotate.conf.

2. Enable IPS and generate at least one Suricata fast.log event during the day.

3. Confirm that the event is visible in the web UI under the IPS logs page.

4. Wait until after midnight, or force the same condition by running logrotate
   after the date changes:

     /usr/sbin/logrotate /etc/logrotate.conf

5. Confirm that the previous day's Suricata log has been rotated, for example:

     ls -lh /var/log/suricata/fast.log*

   Expected filesystem result after rotation includes something like:

     /var/log/suricata/fast.log
     /var/log/suricata/fast.log.1.gz

6. In the web UI, open the IPS log page and select yesterday's date.

Expected behaviour
------------------

Selecting yesterday's IPS log should show yesterday's IPS events.

With daily Suricata rotation, yesterday should map to:

  /var/log/suricata/fast.log.1.gz

Two days ago should map to:

  /var/log/suricata/fast.log.2.gz

and so on.

Actual behaviour
----------------

After the first post-midnight logrotate run, yesterday's IPS log can appear
empty or deleted in the web UI.

The likely reason is that html/cgi-bin/logs.cgi/ids.dat still calculates the
rotated log index as a weekly offset. For most weekdays, yesterday still
produces datediff == 0, so the CGI reads:

  /var/log/suricata/fast.log

instead of:

  /var/log/suricata/fast.log.1.gz

This makes it look as though the previous day's IPS log has been deleted, even
though the events are still present in the rotated Suricata log file.

Suggestion
----------

Update html/cgi-bin/logs.cgi/ids.dat so that the rotated Suricata fast.log
index is calculated in days, not weeks.

In other words, for the IPS log viewer:

  today       -> /var/log/suricata/fast.log
  yesterday   -> /var/log/suricata/fast.log.1.gz
  2 days ago  -> /var/log/suricata/fast.log.2.gz

Alternative fix would be to revert Suricata log rotation back to weekly, but
daily rotation seems intentional from the commit message, so updating ids.dat
looks like the better fix.