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