In the mornings, around 08:00, I try to access the page “Intrussion Prevention” and this always appears. It won’t let me access:
The only way I know how to access it is by restarting the IPFire.
My machine profile is: fireinfo.ipfire.org - Profile 509c7b9c50f8d6a5df7049b70e051019ab787fc9
Is it happening to someone else?
I can confirm that I am also having this issue. The message does not revert back to the normal page after the update.
Bug submitted …
Edit: Please feel free to add any additional details
Hello @roberto and all,
I have the same problem, i haven’t done anything on IPFire since the last update (cu 164 testing)…
Note : For a long time, IP BlockLists addon (@timf version) has been installed in my IPFire and now displays (several pages) :
Edit - For the above IP Blocklists display problem, functional solution
Many thanks to @cbrown for sharing
Just installed the 164 test update tonight. Everything seems OK except I am seeing the same issue here with IPS; I only had the one ruleset (emerging threats) enabled, and I don’t see the rules on the main screen. If I try to edit the rules I just get “The ruleset changes are being applied” forever. The rules that I previously set are still working because I can see hits in the logs. Adding a second ruleset allow me to edit either of them.
EDIT: Additionally, I deleted the rulesets, disabled IPS, then went through the steps of re-adding them. I can no longer edit the rulesets that I’ve selected, so no way of applying anything. Deleted that again, restored my old backup, and although I can’t edit it at all, my original ruleset is now applied and running again.
Regarding the rulesets not being able to be displayed, I’ve raised a bug for it Bug id=12788 which was related to the started topic of
[Manual Update missing on core 164-TEST] (7329)
Appears that doing a UPDATE to core 164 TEST keeps the ‘Customize Ruleset’ function working as normal. But doing a new full install of 164 TEST and then restoring from backup tends to break things. But without a backup restore the rulesets function and are displayed correctly.
Thanks. I’ll keep testing for a few days and see what happens.
@hobthrust - According to the bug 12788 comments, looks like the lads ( with big help from @cbrown ) have been able to replicate the issue and a new nightly of 164 test will be created. I’m waiting for it to test.
@rejjysail great, thanks for letting me know, I’ll look out for it.
@rejjysail I haven’t applied a nightly build before and I can’t seem to find out online, is there a way to move to that via pakfire or does it require a clean installation?
I’m not a developer, and I may have mis-used the term ‘nightly’
The core164 (testing) had IPS rules issues (and possibly others) which related to doing a restore from previous backup. In order the make 164 stable available asap, they decided to possibly hold back the new IPS features and create a new core 165 for deeper testing. It’s not available on pakfire as far as I know. I had to dig through the directories to download the core 165 .iso, so it requires a FULL INSTALL. And for the life of me, I can’t figure out now where exactly it was located. Either way, I think you should wait for official announcments from the team.
Thanks for the update. I’m still having the suricata issues but it’s not a huge problem. I might just do a new installation tomorrow.
I just finished testing the fix changes they’ll be putting into final 164.
From an full .iso install, all worked fine for from the old restore.
I suspect this new 164 will be made available very shortly.
Has the problem with the 164 been solved? Still applying the update on my IPFire, the problem continues:
Hy to all,
i can confirm the same issue as @roberto.
Same problem here after update to core 164. I’m getting this message in the Oinkmaster section of the system log:
oinkmaster: Downloading ruleset for provider: registered.
I’m having the endless
The ruleset changes are being applied. Please wait until all operations have completed successfully…" also
Looked for the lock file but it doesn’t show …
[root@ipfire suricata]# cd /var/tmp/
[root@ipfire tmp]# ls -la
drwxrwxrwt 2 root root 4096 Mar 14 10:02 .
drwxr-xr-x 15 root root 4096 Mar 9 13:46 …
-rw------- 1 nobody nobody 339747 Mar 14 01:25 idsrules-community.tar.gz
-rw------- 1 nobody nobody 3192188 Mar 14 01:25 idsrules-emerging.tar.gz
[root@ipfire tmp]# cd /tmp
[root@ipfire tmp]# ls -la
drwxrwxrwt 3 root root 4096 Mar 14 10:02 .
drwxr-xr-x 21 root root 4096 Mar 13 15:16 …
drwxr-xr-x 4 nobody nobody 4096 Mar 14 10:02 ids_tmp
[root@ipfire tmp]# cd ids_tmp/
[root@ipfire ids_tmp]# ls -la
drwxr-xr-x 4 nobody nobody 4096 Mar 14 10:02 .
drwxrwxrwt 3 root root 4096 Mar 14 10:02 …
drwxr-xr-x 2 nobody nobody 4096 Mar 14 10:02 conf
drwxr-xr-x 2 nobody nobody 4096 Mar 14 10:02 rules
Must be something other than the lock file
Edit: Also, there is no oinkmaster process runing:
[root@ipfire ids_tmp]# ps -ef | grep oink
root 12325 4898 0 10:20 pts/0 00:00:00 grep oink
Well, I have searched for it, I have found it and I have deleted it and without restarting the IPFire it has allowed me to access it without problems.
while I am sorry Core Update 164 caused such a mess (two major bugs in one release - sigh), I am glad to see the discussion going on here, trying to find, understand and resolve the issue. Excellent!
If I got this right, this and this thread cover the same issue. Therefore, I take the liberty to close this one, to avoid the same problem being discussed in two different places. Please post to the other thread, if necessary.
Thanks for your understanding, and best regards,