Hello Adolf,

Whoops, my bad…

I cherry-picked the change into master:

  
https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=a950be6cd698adb9d16c458c0189c7ec2bf7494c

And after this, it all works well?

-Michael

> On 30 Sep 2025, at 12:46, Adolf Belka <[email protected]> wrote:
> 
> Hi Michael,
> 
> On 30/09/2025 13:33, Adolf Belka wrote:
>> Hi Michael,
>> I looked at the source tarball for the suricata-reporter package and the 
>> settings in the LFS etc should have given the correct directories, ie 
>> /var/run/suricata/ and /var/log/suricata/ and in one of my build systems, I 
>> checked in the build directory and that is what is there.
>> However it did not end up like that after the update so maybe something went 
>> wrong in the nightly build for that package.
> 
> I have found out what happened. The lfs version in master only had
> 
> cd $(DIR_APP) && \
> ./configure \
> --prefix=/usr \
> --sysconfdir=/etc
> cd $(DIR_APP) && make $(MAKETUNING)
> cd $(DIR_APP) && make install
> 
> so it was missing the
> 
> --localstatedir=/var
> 
> line which was added into next but not merged back to master.
> 
> Regards,
> 
> Adolf.
> 
> 
>> Regards,
>> Adolf.
>> On 30/09/2025 13:21, Adolf Belka wrote:
>>> Hi Michael,
>>> 
>>> I kept looking at things and eventually found that the database was set at 
>>> /usr/var/log/suricata/ so I changed that line in suricata-reporter as well 
>>> and now I have triggered three alerts and I got three emails.  Yaaah.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> 
>>> On 30/09/2025 12:47, Adolf Belka wrote:
>>>> Hi Michael,
>>>> 
>>>> With the below fixes suricata-reporter is now running as a process but 
>>>> setting of an alert still does not get any messages in the dma logs and in 
>>>> the messages file there is nothing from suricata or suricata-reporter.
>>>> 
>>>> Of course it could be that my fix for suricata-reporter gets it running 
>>>> but not in the right way. So I will wait for your comments on my findings 
>>>> in the emails below and try the testing again when you are happy that 
>>>> suricata-reporter is working as it should be.
>>>> Bear in mind that I have never done any coding with python, only updated 
>>>> the packages.
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.
>>>> 
>>>> 
>>>> On 30/09/2025 12:34, Adolf Belka wrote:
>>>>> Hi Michael,
>>>>> 
>>>>> I might have found the reason for the problem or at least I was able to 
>>>>> get suricata-reporter running.
>>>>> 
>>>>> I had a go at reading through the suricata-reporter python code. I found 
>>>>> a line about setting the socket path that said
>>>>> 
>>>>>          def socket_path(self):
>>>>>                  return self.config.get("DEFAULT", "socket",
>>>>>                          fallback="/usr/var/run/suricata/reporter.socket")
>>>>> 
>>>>> so I changed the last line to read /var/run/suricata/reporter.socket 
>>>>> instead of /usr/var...
>>>>> 
>>>>> and after that starting the suricata initscript also started the 
>>>>> suricata-reporter and I could see three processes running now, suricata, 
>>>>> suricata-watcher and suricata-reporter.
>>>>> 
>>>>> Will now test it out with some alerts.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Adolf.
>>>>> 
>>>>> On 30/09/2025 12:20, Adolf Belka wrote:
>>>>>> Hi Michael,
>>>>>> 
>>>>>> On 30/09/2025 11:47, Adolf Belka wrote:
>>>>>>> Hi Michael,
>>>>>>> 
>>>>>>> 
>>>>>>> On 30/09/2025 11:19, Michael Tremer wrote:
>>>>>>>> Hallo Adolf,
>>>>>>>> 
>>>>>>>> You can simply remove any files in /var/spool/dma and make sure that 
>>>>>>>> there are no sendmail processes running any more.
>>>>>>>> 
>>>>>>>> Regarding why the reporter is not sending any emails, we might need to 
>>>>>>>> dig deeper.
>>>>>>>> 
>>>>>>>> If you kill the reporter when it is running as usual, you can start it 
>>>>>>>> again in debug mode where it will stay in foreground and will log to 
>>>>>>>> the console what it is doing. Maybe that will tell us a little bit 
>>>>>>>> more. Launch it again like this:
>>>>>>>> 
>>>>>>>>    suricata-reporter --config=/var/ipfire/suricata/reporter.conf -vvv
>>>>>>> 
>>>>>>> I didn't even get to triggering an alert as suricata-reporter didn't 
>>>>>>> even want to start.
>>>>>>> 
>>>>>>> Single line error message
>>>>>>> Failed to bind to socket: [Errno 2] No such file or directory
>>>>>> 
>>>>>> I tried restarting suricata from the cli and got the message that 
>>>>>> suricata-reporter was not running from the stop step then after the 
>>>>>> start step it said
>>>>>> 
>>>>>> Starting Intrusion Prevention Reporter...                                
>>>>>>                [  OK  ]
>>>>>> /etc/rc.d/init.d/functions: line 534: /var/run/suricata/reporter.pid: No 
>>>>>> such file or directory
>>>>>> 
>>>>>> I found that the /var/run/suricata/ directory did not exist.
>>>>>> 
>>>>>> I created it and tried restarting suricata again and got
>>>>>> 
>>>>>> Stopping Intrusion Prevention System...                                  
>>>>>>                [  OK  ]
>>>>>> Stopping Intrusion Prevention Reporter...    Not running.                
>>>>>>                [ WARN ]
>>>>>> Starting Intrusion Prevention Reporter...                                
>>>>>>                [  OK  ]
>>>>>> Starting Intrusion Prevention System...                                  
>>>>>>                [  OK  ]
>>>>>> 
>>>>>> But running the status command gave
>>>>>> 
>>>>>> suricata is running with Process ID(s)  8817.
>>>>>> /usr/bin/suricata-reporter is not running but 
>>>>>> /var/run/suricata/reporter.pid exists.
>>>>>> 
>>>>>> So my creating the suricata directory has allowed the pid to be created 
>>>>>> but suricata-reporter hasn't started because it still has the error 
>>>>>> message about the socket. So creating the suricata directory in 
>>>>>> /var/run/ did not solve that problem.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Adolf.
>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> 
>>>>>>> Adolf.
>>>>>>> 
>>>>>>>> 
>>>>>>>> If you then trigger an alert, you should see some activity there and 
>>>>>>>> hopefully some problem as well if the email cannot be sent.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> -Michael
>>>>>>>> 
>>>>>>>>> On 29 Sep 2025, at 17:50, Adolf Belka <[email protected]> wrote:
>>>>>>>>> 
>>>>>>>>> Further info on the mailq stuff.
>>>>>>>>> 
>>>>>>>>> I went to /var/spool/dma/ and read the contents of some of the files 
>>>>>>>>> there. Basically they are related to a problem with arpwatch and 
>>>>>>>>> nothing to do with suricata-reporter.
>>>>>>>>> 
>>>>>>>>> I will need to separately try and figure out what is happening to 
>>>>>>>>> cause those. There are 13 entries in the dma directory, all with the 
>>>>>>>>> same date/time and I checked three different entries and they were 
>>>>>>>>> all related to arpwatch.
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> 
>>>>>>>>> Adolf.
>>>>>>>>> 
>>>>>>>>> On 29/09/2025 18:37, Adolf Belka wrote:
>>>>>>>>>> Without any new alerts being triggered by the IPS the dma logs 
>>>>>>>>>> showed more of those messages about error creating mbox root.
>>>>>>>>>> I then triggered some more alerts in IPS and no new dma messages 
>>>>>>>>>> were seen.
>>>>>>>>>> I also checked the mailq output before and after triggering the 
>>>>>>>>>> alerts and there were no additional entries compared to previously.
>>>>>>>>>> Regards,
>>>>>>>>>> Adolf.
>>>>>>>>>> On 29/09/2025 18:10, Adolf Belka wrote:
>>>>>>>>>>> Hi Michael,
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 29/09/2025 17:44, Michael Tremer wrote:
>>>>>>>>>>>> Hello,
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks for testing this. So let’s go through this step by step…
>>>>>>>>>>>> 
>>>>>>>>>>>> First of all, is the companion daemon running? It is a process 
>>>>>>>>>>>> called suricata-reporter.
>>>>>>>>>>> 
>>>>>>>>>>> I couldn't find it. Running ps aux | grep suricata showed 
>>>>>>>>>>> suricata-watcher and suricata but no suricata-reporter.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> If so, can you check if the configuration file has emails enabled? 
>>>>>>>>>>>> It is in /var/ipfire/suricata/reporter.conf.
>>>>>>>>>>> 
>>>>>>>>>>> Yes there is enabled = true in the [email] section.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> And finally, can you run “mailq” to see if the emails have been 
>>>>>>>>>>>> sent and maybe have bounced?
>>>>>>>>>>> 
>>>>>>>>>>> Ran that command and got a load of stuff but I don't understand it 
>>>>>>>>>>> all all.
>>>>>>>>>>> 
>>>>>>>>>>> Here are just a few that were shown as examples
>>>>>>>>>>> 
>>>>>>>>>>> ID    : 1a0794.335a3b40
>>>>>>>>>>>  From    :
>>>>>>>>>>> To    : root
>>>>>>>>>>> -- 
>>>>>>>>>>> ID    : 1a078b.335a3b40
>>>>>>>>>>>  From    :
>>>>>>>>>>> To    : root
>>>>>>>>>>> -- 
>>>>>>>>>>> ID    : 1a078a.335a3b40
>>>>>>>>>>>  From    :
>>>>>>>>>>> To    : root
>>>>>>>>>>> -- 
>>>>>>>>>>> ID    : 1a0789.335a3b40
>>>>>>>>>>>  From    :
>>>>>>>>>>> To    : root
>>>>>>>>>>> -- 
>>>>>>>>>>> ID    : 1a0788.335a3b40
>>>>>>>>>>>  From    :
>>>>>>>>>>> To    : root
>>>>>>>>>>> -- 
>>>>>>>>>>> 
>>>>>>>>>>> I am also seeing the following in the dma logs
>>>>>>>>>>> 
>>>>>>>>>>> 17:15:00 dma[1a0792.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a0792.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a078c.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a078c.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a078a.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a078a.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a078e.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a078e.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a078a.335a3b40]:  cannot execute 
>>>>>>>>>>> /usr/lib/dma-mbox-create: No such file or directory
>>>>>>>>>>> 17:15:00 dma[1a0788.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a0788.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a0790.335a3b40]:  local delivery deferred: can not 
>>>>>>>>>>> create `/var/mail/root'
>>>>>>>>>>> 17:15:00 dma[1a0790.335a3b40]:  error creating mbox `root'
>>>>>>>>>>> 17:15:00 dma[1a0792.335a3b40]:  cannot execute 
>>>>>>>>>>> /usr/lib/dma-mbox-create: No such file or directory
>>>>>>>>>>> 17:15:00 dma[1a078c.335a3b40]:  cannot execute 
>>>>>>>>>>> /usr/lib/dma-mbox-create: No such file or directory
>>>>>>>>>>> 17:15:00 dma[1a0792.335a3b40]:  <root> trying delivery
>>>>>>>>>>> 17:15:00 dma[1a078c.335a3b40]:  <root> trying delivery
>>>>>>>>>>> 
>>>>>>>>>>> Regards,
>>>>>>>>>>> 
>>>>>>>>>>> Adolf.
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> -Michael
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 29 Sep 2025, at 13:58, Adolf Belka <[email protected]> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Forgot to mention, I pressed the test button on the Mail Service 
>>>>>>>>>>>>> WUI page and immediately received the test mail message.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I use a mail server I have running on my local network.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Adolf.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 29/09/2025 14:52, Adolf Belka wrote:
>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>> I just ran the update for CU198 Testing on my vm systems.
>>>>>>>>>>>>>> The update itself went fine without any error messages or 
>>>>>>>>>>>>>> hiccups.
>>>>>>>>>>>>>> I then went to test the IPS emailing of alerts.
>>>>>>>>>>>>>> I used the same sender and recipient email addresses as I have 
>>>>>>>>>>>>>> specified on the Mail Service WUI page.
>>>>>>>>>>>>>> I set the alert severity to All, Including Informational Alerts.
>>>>>>>>>>>>>> I then followed the suricata testing process as defined in
>>>>>>>>>>>>>> https://docs.suricata.io/en/suricata-8.0.1/quickstart.html#alerting
>>>>>>>>>>>>>> and I ended up with alerts in the IPS-Logs but no email message 
>>>>>>>>>>>>>> received.
>>>>>>>>>>>>>> I checked the System logs for the mail system and there was no 
>>>>>>>>>>>>>> message trying to be sent. I ran the test 7 times, so ended up 
>>>>>>>>>>>>>> with 7 messages in the IPS-Logs.
>>>>>>>>>>>>>> I then checked the IPS system Logs and there was no mention of 
>>>>>>>>>>>>>> detecting the alerts and trying to send an email.
>>>>>>>>>>>>>> I ran the command tail -f /var/log/messages so I could see any 
>>>>>>>>>>>>>> additional log entries when I triggered the IPS alerts but again 
>>>>>>>>>>>>>> nothing was shown when I triggered the alerts, although the 
>>>>>>>>>>>>>> messages did end up in the IPS Logs section.
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Adolf.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 


Reply via email to