Hello Stefan,
better late than never I finally reviewed the IDSv4 changes you made, and installed the latest tarball onto my testing machine. Everything went pretty smooth, with the only exception of this message emitted by the converter script:
[root@maverick ~]# convert-ids-backend-files 5/4/2022 -- 17:37:00 - <Error> - [ERRCODE: SC_ERR_FOPEN(44)] - Failed to open configuration include file /var/ipfire/suricata/suricata-used-rulesfiles.yaml: No such file or directory
While ignoring this message did not cause any harm in my case, could you please confirm that this one is safe to ignore indeed?
Afterwards, I toyed around with the IDS CGI, and was unable to break it or cause any unwanted behaviour. Therefore, IDSv4 looks good to me, and I just merged this branch of yours into "next", and added all the necessary changes to Core Update 168 and its updater.
It would be great if you could have a look at https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=68725035744de0253f19e0b3... and drop me a line in case anything is still missing.
With regards to Patchwork, I assume https://patchwork.ipfire.org/project/ipfire/list/?series=2729 is superseded by the IDSv4 changes, but https://patchwork.ipfire.org/project/ipfire/patch/20220406192332.4865-1-stef... definitely is not. While I tend to agree with this patch, Michael asked for its rationale, so it would be great if you could reply to his question.
Aside from that, many thanks for your contribution. IDSv4 really is an improvement.
Thanks, and best regards, Peter Müller
Hello Peter,
thanks for having a look on the IDSv4 stuff.
Hello Stefan,
better late than never I finally reviewed the IDSv4 changes you made, and installed the latest tarball onto my testing machine. Everything went pretty smooth, with the only exception of this message emitted by the converter script:
[root@maverick ~]# convert-ids-backend-files 5/4/2022 -- 17:37:00 - <Error> - [ERRCODE: SC_ERR_FOPEN(44)] - Failed to open configuration include file /var/ipfire/suricata/suricata-used-rulesfiles.yaml: No such file or directory
While ignoring this message did not cause any harm in my case, could you please confirm that this one is safe to ignore indeed?
You can ignore this line. It appears because while suricata is running the main "suricata.yaml" config will got replaced.
The next time the suricata process get's triggered the next thime, this message will be shown once.
To deal with this correctly I would suggest to stop suricata during the update process, before extracting the files (if possible), to launch the converter and afterwards start suricata again.
Afterwards, I toyed around with the IDS CGI, and was unable to break it or cause any unwanted behaviour. Therefore, IDSv4 looks good to me, and I just merged this branch of yours into "next", and added all the necessary changes to Core Update 168 and its updater.
It would be great if you could have a look at https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=68725035744de0253f19e0b3... and drop me a line in case anything is still missing.
Thanks for doing this. I'm very happy that everything worked well and nothing got broke.
Except the start/stop suggestion from above and after a quick look the commit looks good for me.
With regards to Patchwork, I assume https://patchwork.ipfire.org/project/ipfire/list/?series=2729 is superseded by the IDSv4 changes, but
No, they are not superseded by the IDSv4 stuff. The "ipset whitelist series" is a separate one, which needs some additional work until we can merge this.
https://patchwork.ipfire.org/project/ipfire/patch/20220406192332.4865-1-stef... definitely is not. While I tend to agree with this patch, Michael asked for its rationale, so it would be great if you could reply to his question.
I've responded to that mail - in very short, please drop them.
Aside from that, many thanks for your contribution. IDSv4 really is an improvement.
Thanks, and best regards, Peter Müller
Best regards,
-Stefan
-
Peter Müller -
Stefan Schantl