CU198 Testing - first feedback on Suricata alert email sending

CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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.

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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.
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Michael Tremer]

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.

If so, can you check if the configuration file has emails enabled? It is in /var/ipfire/suricata/reporter.conf.

And finally, can you run “mailq” to see if the emails have been sent and maybe have bounced?

-Michael

> On 29 Sep 2025, at 13:58, Adolf Belka <adolf.belka@ipfire.org> 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.
> 
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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.
>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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.
>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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.
>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Michael Tremer]

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

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>> 
>>>>> 
>>>> 
>>> 
> 
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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.

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Michael Tremer]

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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

Hi Michael,

On 30/09/2025 16:07, Michael Tremer wrote:
> 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?

I will test and see but from my earlier testing I think the suricata directory in /var/run will need to be created somewhere so that when rebooting it is created.

In the update.sh script it creates that directory but after doing a reboot it is no longer present and so suricata-reporter won't start as it hasn't got the directory to place the pid file in.

That occurred for me after making the path changes in the suricata-reporter file so I don't believe just having that change in master by itself will be enough.

The directory for the database is fine as it is in the same directory as the fastlog is placed so it already exists.

I can test your cherry picked change after it has been through the nightly build and confirm one way or the other for the
/var/run/suricata/ directory.

Regards,

Adolf.


> 
> -Michael
> 
>> On 30 Sep 2025, at 12:46, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Michael Tremer]

Hello,

This should be created here:

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

I added the script to the updater :( I wish I was doing better at this.

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

Best,
-Michael

> On 30 Sep 2025, at 16:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 30/09/2025 16:07, Michael Tremer wrote:
>> 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?
> 
> I will test and see but from my earlier testing I think the suricata directory in /var/run will need to be created somewhere so that when rebooting it is created.
> 
> In the update.sh script it creates that directory but after doing a reboot it is no longer present and so suricata-reporter won't start as it hasn't got the directory to place the pid file in.
> 
> That occurred for me after making the path changes in the suricata-reporter file so I don't believe just having that change in master by itself will be enough.
> 
> The directory for the database is fine as it is in the same directory as the fastlog is placed so it already exists.
> 
> I can test your cherry picked change after it has been through the nightly build and confirm one way or the other for the
> /var/run/suricata/ directory.
> 
> Regards,
> 
> Adolf.
> 
> 
>> -Michael
>>> On 30 Sep 2025, at 12:46, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

On 30/09/2025 17:10, Michael Tremer wrote:
> Hello,
> 
> This should be created here:
> 
>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=82269b9647e2430a0f12fcb9a0319ba499c3bdee
> 
> I added the script to the updater :( I wish I was doing better at this.

You always say to me, that is why we do testing because to err is human.

> 
>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=9150cbddeb913ce093f2f7e0669e4a8ab3265bb0
> 
> Best,
> -Michael
> 
>> On 30 Sep 2025, at 16:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 30/09/2025 16:07, Michael Tremer wrote:
>>> 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?
>>
>> I will test and see but from my earlier testing I think the suricata directory in /var/run will need to be created somewhere so that when rebooting it is created.
>>
>> In the update.sh script it creates that directory but after doing a reboot it is no longer present and so suricata-reporter won't start as it hasn't got the directory to place the pid file in.
>>
>> That occurred for me after making the path changes in the suricata-reporter file so I don't believe just having that change in master by itself will be enough.
>>
>> The directory for the database is fine as it is in the same directory as the fastlog is placed so it already exists.
>>
>> I can test your cherry picked change after it has been through the nightly build and confirm one way or the other for the
>> /var/run/suricata/ directory.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>>> -Michael
>>>> On 30 Sep 2025, at 12:46, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Adolf Belka]

Hi Michael,

So I ran the latest update from CU197 to CU198 Testing.

suricata-reporter is running successfully and all directories are present also after reboot.

However when triggering an alert no email gets delivered. This message is in the dma log:-

13:36:25 dma:  can not open auth file `/var/ipfire/dma/auth.conf': Permission denied


Regards,

Adolf.


On 30/09/2025 17:15, Adolf Belka wrote:
> 
> 
> On 30/09/2025 17:10, Michael Tremer wrote:
>> Hello,
>>
>> This should be created here:
>>
>>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=82269b9647e2430a0f12fcb9a0319ba499c3bdee
>>
>> I added the script to the updater :( I wish I was doing better at this.
> 
> You always say to me, that is why we do testing because to err is human.
> 
>>
>>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=9150cbddeb913ce093f2f7e0669e4a8ab3265bb0
>>
>> Best,
>> -Michael
>>
>>> On 30 Sep 2025, at 16:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> On 30/09/2025 16:07, Michael Tremer wrote:
>>>> 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?
>>>
>>> I will test and see but from my earlier testing I think the suricata directory in /var/run will need to be created somewhere so that when rebooting it is created.
>>>
>>> In the update.sh script it creates that directory but after doing a reboot it is no longer present and so suricata-reporter won't start as it hasn't got the directory to place the pid file in.
>>>
>>> That occurred for me after making the path changes in the suricata-reporter file so I don't believe just having that change in master by itself will be enough.
>>>
>>> The directory for the database is fine as it is in the same directory as the fastlog is placed so it already exists.
>>>
>>> I can test your cherry picked change after it has been through the nightly build and confirm one way or the other for the
>>> /var/run/suricata/ directory.
>>>
>>> Regards,
>>>
>>> Adolf.
>>>
>>>
>>>> -Michael
>>>>> On 30 Sep 2025, at 12:46, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
> 

Re: CU198 Testing - first feedback on Suricata alert email sending

[Michael Tremer]

Hello,

Good, one step further.

> On 1 Oct 2025, at 12:44, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> So I ran the latest update from CU197 to CU198 Testing.
> 
> suricata-reporter is running successfully and all directories are present also after reboot.
> 
> However when triggering an alert no email gets delivered. This message is in the dma log:-
> 
> 13:36:25 dma:  can not open auth file `/var/ipfire/dma/auth.conf': Permission denied

Hmm, that might actually become a little bit of a problem here potentially.

The reporter is running as an unprivileged user and therefore executes the sendmail command as such user.

What permissions does this file have on your system?

Best,
-Michael

> Regards,
> 
> Adolf.
> 
> 
> On 30/09/2025 17:15, Adolf Belka wrote:
>> On 30/09/2025 17:10, Michael Tremer wrote:
>>> Hello,
>>> 
>>> This should be created here:
>>> 
>>>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=82269b9647e2430a0f12fcb9a0319ba499c3bdee
>>> 
>>> I added the script to the updater :( I wish I was doing better at this.
>> You always say to me, that is why we do testing because to err is human.
>>> 
>>>    https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=9150cbddeb913ce093f2f7e0669e4a8ab3265bb0
>>> 
>>> Best,
>>> -Michael
>>> 
>>>> On 30 Sep 2025, at 16:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>> On 30/09/2025 16:07, Michael Tremer wrote:
>>>>> 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?
>>>> 
>>>> I will test and see but from my earlier testing I think the suricata directory in /var/run will need to be created somewhere so that when rebooting it is created.
>>>> 
>>>> In the update.sh script it creates that directory but after doing a reboot it is no longer present and so suricata-reporter won't start as it hasn't got the directory to place the pid file in.
>>>> 
>>>> That occurred for me after making the path changes in the suricata-reporter file so I don't believe just having that change in master by itself will be enough.
>>>> 
>>>> The directory for the database is fine as it is in the same directory as the fastlog is placed so it already exists.
>>>> 
>>>> I can test your cherry picked change after it has been through the nightly build and confirm one way or the other for the
>>>> /var/run/suricata/ directory.
>>>> 
>>>> Regards,
>>>> 
>>>> Adolf.
>>>> 
>>>> 
>>>>> -Michael
>>>>>> On 30 Sep 2025, at 12:46, Adolf Belka <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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 <adolf.belka@ipfire.org> 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.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
> 
>