I just installed and configured IPfire 2.25 core 142.
I was able to download a ruleset for IPS, but i can’t get the daemon to start.
When i try to start it manually, it says that suricata.pid doesn’t exist.
Is there a way to create the file manually? This is for a class and i am unable to update due to class rules.
Hey Eric - welcome to the IPFire Community!
That version is very old. We just release core 167 and so you are 25 updates behind. Core 142 was released in March 2020.
If you continue to use it please keep in mind that support will be near non-existent since it is so old!
I think you need to enable IPS, and pick a Ruleset (like Emergingthreats.net Community Rules) and then pick at least one rule. That should get things moving forward.
I am doing this from memory and so I may be off a step or two…
Hi,
may I ask which source you got that Core Update 142 installation media from? Who on earth is still distributing such outdated files?! No wonder we observe terrible update rates. 
I think it is best if you download the latest ISO, and reinstall from scratch. That is definitely a lot less painful than going through dozens of updates.
Thanks, and best regards,
Peter Müller
Thank you for your reply! I am using it for my capstone security class. I received it from my professor who holds onto about every ISO he can get ahold of. We are using an outdated version that has known vulnerabilities and have to defend it
Thank you for the reply! Unfortunately i am unable to upgrade due to the rules of the class. I was able to get it running, then it stopped and i can’t get it running again. I saw in another thread that there was a known issue where surricata.pid would become locked and users had to manually delete it. However, when I looked for it, the file wasn’t there and I can’t get it to reappear when i activate the rules and IDS.
The problem with suricata.pid getting locked is a more recent one in the CU 16x, I can’t remember precisely which.
You would probably need to go and look at how suricata worked with Core Update 142. There are likely to be some differences between then and now.
The pid file is the Process ID file for the suricata program. The pid file is, or should be created when suricata starts. Therefore you can not create it manually.
Could you check if the pid file is actually still present. It should be killed and removed when suricata stops but I am not sure what would happen if a pid file didn’t get removed for some reason and was already present when suricata tried to start.
The file, if existing, is at
/var/run/suricata.pid
Hi,
first of all, it is good to know that this outdated usage is actually intentional, and not caused by somebody distributing outdated installation media for productive usage. Good luck with that hardening exercise!
The PID problem was fixed in this commit in late 2020. Since it is a rather trivial change to the Suricata initscript, it should be easy to apply that manually.
Thanks, and best regards,
Peter Müller
Thank you everyone for the advice and help!! I did a lot more digging and I still am not sure what the problem was. I ended up building a new machine and IPS worked no problem!
Hi,
ah, such non-reproducible issues are always nasty. 
Should you decide to run an up-to-date IPFire version sometimes, and the problem persists (I don’t hope so, but no firewall distribution is perfect), please do let us know so we can investigate further on it. Also, should your research uncover any security problems in IPFire that have not been addressed meanwhile, please let us know (via security@ipfire.org) as well.
All the best,
Peter Müller
