Control: tags -1 +confirmed Hi,
I have looked into this bug and would like to outline how I intend to resolve it, so that others can comment before anything is uploaded.
The report raises two separate issues, and both are addressed.The first one is the autopkgtest suite, which implicitly assumed the presence of an eth0 interface and of a daemon started by the package installation. The suricatasc checks now start their own instance in unix socket mode, which does not attach to a capture interface at all, and the systemd test detects an interface that actually exists in the testbed instead of relying on the shipped configuration.
The second one is the daemon itself. The package ships the upstream default configuration, which uses eth0 as af-packet capture interface, and enabled and started the service on installation. On a system without eth0 the service ends up in the 'failed' state right after 'apt install'; on a system that happens to have one, the daemon monitors an interface the administrator never chose. The package is also frequently installed only to analyse pcap files, where no service is wanted at all.
The fix is to no longer enable the service on first installation, using a systemd preset that disables suricata.service. Administrators and downstream distributions can override that policy with a preset file of their own in /etc/systemd/system-preset/, without having to patch the package. Existing installations are unaffected, because presets are only evaluated when a package is installed for the first time. README.Debian gained a section on the initial configuration (capture interface, HOME_NET), and there is a NEWS entry for the behaviour change.
Interface autodetection was considered and rejected. Upstream does not implement it and has repeatedly declined to make a missing interfacenon-fatal, pointing at udev and the init system instead. A monitoring port in a typical IDS deployment has neither an address nor a default route, so a heuristic would systematically pick the wrong interface. Above all, configuring the interface anywhere but in suricata.yaml introduces a second source of truth; that construction exists in the upstream RPM packaging and is a recurring source of confusion in upstream support requests.
An installation-time prompt was considered as well. A meaningful first-time configuration is not limited to the interface, it also involves HOME_NET, the capture mode and the ruleset, so a debconf dialogue would either be incomplete or fairly involved. It would also require moving suricata.yaml to ucf handling. This may be revisited later, but it is out of scope here.
For what it is worth, this matches what upstream does in the packaging they control themselves: the OISF RPMs do not enable the service either and document 'systemctl enable suricata' as an explicit step. Within Debian, src:libreswan uses the same preset mechanism for the same reason.
The changes are prepared and will be uploaded to experimental after the upcoming 8.0.7 release, so that the behaviour on ci.debian.net can be observed before anything is merged or even reaches unstable.My current implementation is here: https://salsa.debian.org/ecite/pkg-suricata/-/commits/bug-895342
Comments are welcome. Regards, Andreas
OpenPGP_0xD74D4EE0580CA4FC.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
