Hello Stefan,

thanks for your reply.

Version 9 now looks good to me. I had to grant executable file permissions to the convert script, but that's not a big deal:

[root@maverick ~]# /usr/sbin/convert-ids-multiple-providers -bash: /usr/sbin/convert-ids-multiple-providers: Permission denied [root@maverick ~]# chmod +x /usr/sbin/convert-ids-multiple-providers [root@maverick ~]# /usr/sbin/convert-ids-multiple-providers

Since the script already ran on that machine, I had to execute

chown nobody:nobody /var/ipfire/suricata/suricata-default-rules.yaml

myself. Every functionality provided by the WebUI seems to work fine, and I was unable to break anything. :-)

(With URLhaus enabled, Suricata takes ages to reload on my testing machine, I am curious how many people will enable this provider despite the performance impact... We'll see.)

As soon as there is a testing announcement for Core Update 163, I will start a temporary branch for Core Update 164 and merge https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=shortlog;h=refs/hea... into it.

Thanks, and best regards, Peter Müller

Hello Peter,

a big thanks for having a look and sharing your issues here.

I've fixed both bugs and uploaded a new test package (009).

https://people.ipfire.org/~stevee/ids-multiple-providers/ids-multiple-provid...

Please re-test and report any remain or new issues.

A big thanks in advance,

-Stefan

...

Hello Stefan,

as discussed on Monday (https://wiki.ipfire.org/devel/telco/2022-01-03), I tested version 8 of the "IDS multiple provider" feature you developed. First of all, thank you very much for all the efforts you have put into this!

As you told me on the phone the other day, I downloaded the .tar.gz file, and extracted it directly into / :

[root@maverick ~]# sha256sum ids-multiple-providers-008.tar.gz 8fc42820a833f4a096c311d3e21a28f4a8dac7d772ca9b72ec0fbbbaad65be82  ids-multiple-providers-008.tar.gz [root@maverick ~]# tar xvzf ids-multiple-providers-008.tar.gz -C / usr/share/suricata/rules/app-layer-events.rules var/ipfire/langs/ etc/ var/ipfire/backup/ usr/share/suricata/rules/stream-events.rules usr/share/suricata/rules/files.rules usr/share/suricata/rules/http-events.rules usr/share/ usr/share/suricata/classification.config var/ipfire/suricata/oinkmaster.conf usr/share/suricata/rules/decoder-events.rules srv/ usr/share/suricata/rules/nfs-events.rules usr/ usr/local/bin/update-ids-ruleset etc/suricata/suricata.yaml usr/share/suricata/threshold.config var/ipfire/langs/de.pl var/ipfire/backup/bin/backup.pl usr/local/ usr/share/suricata/rules/smb-events.rules var/ipfire/backup/bin/ usr/share/suricata/rules/dhcp-events.rules usr/local/bin/ usr/share/suricata/rules/modbus-events.rules var/ipfire/ids-functions.pl usr/share/suricata/rules/ntp-events.rules var/ipfire/langs/en.pl var/ipfire/suricata/ usr/share/suricata/rules/dnp3-events.rules usr/share/suricata/reference.config usr/share/suricata/rules/smtp-events.rules usr/share/suricata/rules/ var/ipfire/backup/include srv/web/ipfire/ usr/share/suricata/rules/kerberos-events.rules usr/sbin/convert-ids-multiple-providers usr/share/suricata/ srv/web/ usr/share/suricata/rules/ipsec-events.rules srv/web/ipfire/cgi-bin/ids.cgi usr/sbin/convert-snort srv/web/ipfire/cgi-bin/ var/ipfire/ usr/sbin/ usr/share/suricata/rules/tls-events.rules var/ etc/suricata/ usr/share/suricata/rules/dns-events.rules var/ipfire/suricata/ruleset-sources

Afterwards, I updated the language cache and ran the convert script:

[root@maverick ~]# update-lang-cache [root@maverick ~]# /usr/sbin/convert-ids-multiple-providers The  does not exist. Cannot change the ownership!

Aside from the message emitted by /usr/sbin/convert-ids-multiple- providers (bug #12758 has been filed for investigating on this one), I came across a file permission error while writing /var/ipfire/suricata/suricata-default-rules.yaml (see bug #12759 for details).

Apart from these, the CGI looks good, is sufficiently translated (sometimes, "zurück" is spelled in capital letters, sometimes, it is not - but that's merely an aesthetic issue), and behaves like expected. So, I'd treat it al almost being ready for production. :-)

Please take a look at bug #12758 and #12759, and reply to me there if I shall provide further information.

Thank you in advance for your efforts.

Thanks, and best regards, Peter Müller