We (the OISF) are considering providing officically supported Suricata RPMs for CentOS and RHEL. I’m posting to get feedback on the interest, how we plan to do this and to ask some open questions we have.
We plan to provide the RPMs in a repo per major version. This would allow users to add the repo for 5.0 and keep up to date with 5.0 patch releases without a surprise upgrade to the next major release. We may add an additional repo that is always the latest release version, but I don’t see that being as useful in a production environments. Any thoughts about this?
The open questions we have are more about co-habitating or conflicting with the Surcata packages found in EPEL.
Should we aim to be as compatible as possible with the EPEL provided packages? Or should we aim to provide the best experience which may mean diverging from the EPEL packages?
Should we allow co-existing with the EPEL RPMs? This would mean using an alternate package name, something like “oisf-suricata” and installing into /opt.
Or should we conflict with the EPEL RPMs? This would allow us to install into the usual locations like /etc/suricata, /usr/bin, etc.
And how should we prevent the package from being overrided by the EPEL package? This is mainly of concern to systems using the previous release RPMs (for example, 4.1, but EPEL contains 5.0). Currently you have to do some tricks with with dnf/yum to prevent Suricata from being upgraded as documented here: https://copr.fedorainfracloud.org/coprs/jasonish/suricata-4.1/. The easiest work around I can think of is using an alternate package name “oisf-suricata”, but conflicting with “suricata”, and installing into the regular location of /usr. Another option is using the epoch.
Any other considerations we’ve missed?
I’ve created some test RPMs to explore how we want to do this over on COPR:
While I wouldn’t push to be disruptive, I’d prefer to use the usual locations without jumping through many hoops, if possible.
My current Suricata wishlist consists of a packaged version of stable with Hyperscan support on CentOS 8/8.1/RHEL.
I have it all running from source, but given the odd hurdles I encountered, a packaged version would be greatly appreciated.
That was something else I meant to bring up… Suricata as found in EPEL does not include Hyperscan support. But it is something we could provide in OISF provided RPMs.
So I’d be interested in comments with respect to having Hyperscan enabled or not.
For what it’s worth hyperscan is available on EL8 via EPEL, it looks like it just didn’t make it to the standard EL8 repo, it is currently only in epel8.playground. That is an easy fix.
From the EPEL/Fedora packaging perspective, I am not sure how many people use the packages and all the reasoning for why not.
The one thing that has come up with regard to EPEL is that it usually doesn’t follow the latest release but is one major release behind. Also the lack of hyperscan in EL7 due to the old boost libs one had bundle the boost libraries with their suricata src to build the RPM.
I have run the EPEL RPM along side the dev version (master branch) packaged in an RPM. The two ran side by side but it took a bit of work to get things so they didn’t conflict. It certainly can be done though and seemed to work rather well for us at the time.
I think it would be best to allow the EPEL/Fedora and OISF RPMs to exist side by side. I can get a sample spec to share on how I handled the dev version to it didn’t stomp the prod/stable version.
What hardware platforms would be supported with the OISF RPMs? Would it match with the EPEL/Fedora platforms? (ignoring the current ppcle hiccup with linking with the 4.x release)
It would be great to see HS make it into EPEL proper.
Either being stuck on one older version, or on the newer version when you are not yet ready to upgrade I think are common options. We hope to solve that, provided, Suricata in RPM form meets needs otherwise. It may not (custom compile time options, etc).
I’d want to be sure this is done for the right reasons. And I’ll be extra critical of yours given your involvement with the EPEL/Fedora RPMs, it only makes sense you’d like them to co-exists. The technical parts aren’t the bit that worry me, there do seem to be some conventions around this. The parts that worry me is that most of our documentation won’t line up with our provided RPMs. And it happens often in support-types requests where someone is running mismatched Suricata and configuration files, or libraries due to multiple installs from source, or one from source and one from package. I’d like to avoid this extra complexity if possible.
Probably just x86_64. It would be nice to enable the ARM builds that COPR supports as well. But I wonder if it should be limited to what we test. COPR no longer gives me the option to build ppcle, so probably wouldn’t worry about that.
I don’t imagine anyone wants to maintain branches of documentation to accommodate the variations that would come up in this case. Wearing a support staff hat, I would want the OISF RPMs to exist by themselves for the sake of simplicity.
It probably comes down to what the most common use case will be. Do folks run single instances of Suricata on a single server or do they run multiple instances per single server and would they run into a scenario where they would want different versions?
Admittedly the case where we ran two different versions side by side is probably not the typical use case. But it is one that is out there :).
Probably just x86_64. It would be nice to enable the ARM builds that COPR supports as well. But I wonder if it should be limited to what we test. COPR no longer gives me the option to build ppcle, so probably wouldn’t worry about that.
[/quote]
My vote would be limiting it to what OISF tests. When tooling changes or updates, it can be time consuming to troubleshoot across a number of hardware platforms.
Building HS before building Suricata is a pain for sure so that makes RPM attractive. I don’t know much about RPM packaging and/or the ability to install via RPM with the same options available using ./configure. That would be the decision maker for me. I don’t think I would use RPM w/o ability to choose/use build options - profiling, geoip, ebpf, unix-sockets, or similar functionality.
However, a pre-built RPM is probably very attractive to new users and people in larger corporate environments with requirements for using RHEL / CentOS. Reducing the number of build steps for that group will get more people to use Suricata and benefit from it until such time they need to specialize their configs.
The RPM is pretty much limited to including features that can be enabled by the packages found in the existing packaging system. On Fedora and CentOS this means all the common features, including epbf.
Some features like profiling would not be enabled as they do taking a performance hit. In previous packaging I’ve done, Ive created add “-profiling” packages that contain the binary suffixed with profiling, and so on.
In general, the RPMs that exist for Fedora and CentOS via EPEL are really good at this already. However, they don’t have the ability for the user to choose whether to use the previous maintained branch, or the most current release branch. Which is an option I’d like to give users.
This should probably the point of doing the RPMs, not trying to add all the latest and greatest optional features. Lets be honest. If you run CentOS/RHEL you’re not into the cutting edge anyway.
I just rebuilt Suricata (and Zeek for that matter) and any dependencies for EL7 and EL8 using software collections. Need this for RockNSM. I would love to have better upstream packages that track the latest. For that matter, I’m sure EPEL and Fedora would be amenable to maintaining packages via spec file.
@ish I actually used to use your RPMs, then EPEL caught up, then they didn’t. As for using OISF official RPMs, I have a hard requirement for packaged software to follow the FHS, same as RHEL/CentOS/Fedora. I know it’s a pseudo-standard that tons of platforms don’t abide by, but it makes the integration work of RockNSM easier if all the packages behave predictably, and it doesn’t hurt (IMO) other RPM-based distros. Also, you get some default SELinux policies out of the box and makes them easier to implement for add-on policies.
For implementation, you should make it easy for people to add it to their repo lists. Provide a .repo file and GPG sign, etc. We support offline installation and maintenance of sensors, so during our ISO build, I’d clone down any packages that, hopefully, co-exist with distro and EPEL repos. Then for sensors that are online point them to the official repo.
I think software collections are dead in EL8 because they now have AppStreams which can provide the same feature set in a more flexible way. My spec file uses conditionals to use software collection RPMs on EL7 hosts so it will actually build. It’s messy, but it works.
So just to summarize, a bit from this thread, and from some other input, I think we’re going to try and do the following.
Repositories for all maintained branches of Suricata. There seems to be demand for Suricata 5.0.x RPMs on EPEL 7, and to a lesser degree Suricata 4.1.x on EPEL 8. And these are the main uses cases I’d like to support.
We will install to the usual locations. So this means the OISF RPMs would conflict with EPEL RPMs. But for most users I think this is best, as all the documentation would line up. This isn’t really any change from the current RPMs, or users who install to /usr. As it is, the EPEL RPMs pretty following all our defaults anyways.
We will try to improve the RPMs where possible. For something like EPEL 7 this might mean pulling in our own Hyperscan package. For EPEL 8 it would mean helping, or testing Hyperscan in EPEL to make it a reality.
The one thing I’m having an issue deciding how to do best is make sure that someone who is following the 4.1.x branch to not be automatically updated to 5.0, for example a CentOS 8 system using our 4.1.x RPMs. I can think of 2 approaches:
Name the RPM “oisf-suricata”, this would “provide” Suricata, and conflict with other Suricata packages.
Set the epoch. This isn’t exactly the correct usage of epoch, but I don’t think its a bad abuse of it either.
I would like to do one of the other in my test repos for testing soon.
A full RPM version looks something like “epoch:major.minor.patch”. By default, the epoch is not set at all. But it exists as a way to set something that ranks higher than major. I think it originated with some package with a high version, then a “-ng” type package came along to supercede that old one but reset its version back down, but they wanted to make the “-ng” the replacement package.
So if we set the ephoch to 0, such that our 4.1.8 RPM has a version of 0:4.1.8, it will always be greater than the EPEL 5.1.x RPM (epoch 0 is greater than no epoch in RPM).
What do you think about using ‘conflicts’ to address the auto upgrade scenarios? I am not sure I have used it for that particular reason before but it could work I think.
Say Suricata 4.1.x RPM would conflict with Suricata >= 5. I fear that it would simply never be upgraded. DNF/Yum would see that Suricata 5.0.3 exists, see that the installed Suricata conflicts with that version, then it will not be upgraded. Even if 4.1.8 is installed and a 4.1.9 exists.
given your involvement with the EPEL/Fedora RPMs, it only makes sense you’d like them to co-exists. The technical parts aren’t the bit that worry me, there do seem to be some conventions around this. The parts that worry me is that most of our documentation won’t line up with our provided RPMs. And it happens often in support-types requests where someone is running mismatched Suricata and configuration files, or libraries due to multiple installs from source, or one from source and one from package. I’d like to avoid this extra complexity if possible.