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:
Thanks for any feedback, even if its just to express interest.