Bug#895342: suricata: new version fails to start if eth0 not present
Hi Steve and Arturo, just a few comments from my side… I might agree that the tests make some fragile assumptions, and I think that this problem can be solved quickly by wrapping the suricatasc calls, making sure that there is a Suricata instance running (in IDS mode) on an existing interface. The other issue raised by Steve is a bit more complex. Suricata is an IDS/IPS system, which rarely is used 'out of the box' but usually requires setup by a knowledgeable person. I think, however, that we can arrive at some sensible default configuration that leaves the least moment of surprise to a user who just installed the software. AFAICS we have several options here: a) Explicitly disable the service by default and display a note (via debconf) that informs the user that configuration is required before the system is usable. This is probably the easiest way -- but in essence avoiding the problem altogether ;) b) Use debconf to let the user choose a set of interfaces detected at install time (or pre-define at pressed, obviously), and pre-generate a config file that uses a lowest common denominator of basic but likely configuration choices (e.g. AF_PACKET, IDS mode, default bundled ruleset, ...) for monitoring the chosen interfaces, staying as close to upstream’s default config file as possible. If a user wants something more involved, then they can customize the setup by themselves. I have just played around with debconf a bit and it looks like this is quite straightforward to do. I'm just not sure yet how to handle non-interactive cases (such as the autopkgtests), but my first suggestion would be to go with the interface that provides the default route. What do you think? Cheers Sascha signature.asc Description: Message signed with OpenPGP
Bug#895342: suricata: new version fails to start if eth0 not present
Control: severity -1 normal On Wed, 18 Apr 2018 10:30:56 -0700 Steve Langasek wrote: > > There is at least one bug here in the package, which is that the > autopkgtests make a brittle assumption that eth0 will be available in the > test bed. eth0 is a legacy interface name in the kernel, and despite the > fact that eth0 is currently present on the ci.debian.net testbeds, this is > not a robust assumption. If you want to reorder the tests so that the > config file setup is done first, then that would address the bug in the > autopkgtests. > Hi, thanks for taking the time to elaborate. I talked to upstream to know if they plan to implement something for interface names at runtime. No plans. And I don't have time to work on that myself. Downgrading the severity to avoid the package removal from testing. On a side note: you mentioned the daemon should be up and running to consider the package being OK installed. While I agree that by installing the package we should get a daemon ready to use, How would you do that? given suricata acts as a firewall, the config is strictly baked per environment and no preset could be used as default?
Bug#895342: suricata: new version fails to start if eth0 not present
Control: reopen -1 Hi Arturo, On Wed, Apr 18, 2018 at 11:07:32AM +0200, Arturo Borrero Gonzalez wrote: > If you check debian/tests/systemd-service-test.sh [0], the interface > in use by the config file is decided at runtime. This code runs only for one of the tests. It doesn't change the fact that the suricata service as a whole is broken on install when eth0 is not present, and all commands which try to talk to the daemon prior to that point in the tests will fail. You could fix the autopkgtests to not depend on eth0 if you moved the systemd-service-test.sh to run before all other tests. But I don't think that would fix this bug, because I think the behavior of the package itself is still wrong. > What autopkgtest tests are you running? The ones shipped in your package. > This seem like an ubuntu specific issue. All tests in debian are going > fine, both in unstable and in testing [1]. The tests work fine in Debian because the testbed HAPPENS TO HAVE AN eth0 INTERFACE, as I said in the original bug report. I know the difference between Debian and Ubuntu and am not in the habit of gratuitously overinflating the severity of bugs filed in Debian for Ubuntu-specific issues. > This Debian bug may result in the package being removed from Debian > testing for no actual reason. I wrote the reason in my original bug report: I'm filing this as serious because it seems to me that neither of these behaviors - either starting up and being ineffective because it's running on the wrong interface, or failing to start up because the interface is hard-coded and not present - is a reasonable default behavior for an IDS. I think the interface should either be autodetected or prompted for at install time. I also wrote: Feel free to downgrade if you disagree. It's not clear to me that you disagree. It's not clear to me that you even read my bug report. So, reopening at original severity. > Closing this bug now as it seems totally bogus. There is at least one bug here in the package, which is that the autopkgtests make a brittle assumption that eth0 will be available in the test bed. eth0 is a legacy interface name in the kernel, and despite the fact that eth0 is currently present on the ci.debian.net testbeds, this is not a robust assumption. If you want to reorder the tests so that the config file setup is done first, then that would address the bug in the autopkgtests. I still also think it's a bug that the package installs successfully but the daemon fails to start if there is no eth0 interface. I think best practice is that a package ensures its daemons can be started before the package is configured, because it's better to surface a failure to the admin than to consider a package "configured" without providing core functionality to reverse-dependencies. This was in my view the issue that warranted a 'serious' severity, but you are free to disagree and downgrade the bug. > [0] > https://salsa.debian.org/pkg-suricata-team/pkg-suricata/blob/master/debian/tests/systemd-service-test.sh > [1] https://ci.debian.net/packages/s/suricata/ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#895342: suricata: new version fails to start if eth0 not present
If you check debian/tests/systemd-service-test.sh [0], the interface in use by the config file is decided at runtime. What autopkgtest tests are you running? This seem like an ubuntu specific issue. All tests in debian are going fine, both in unstable and in testing [1]. This Debian bug may result in the package being removed from Debian testing for no actual reason. Closing this bug now as it seems totally bogus. [0] https://salsa.debian.org/pkg-suricata-team/pkg-suricata/blob/master/debian/tests/systemd-service-test.sh [1] https://ci.debian.net/packages/s/suricata/
Bug#895342: suricata: new version fails to start if eth0 not present
Package: suricata Version: 1:4.0.4-1 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu bionic autopkgtest Dear maintainers, The latest version of suricata is failing its autopkgtests in Ubuntu because the suricata daemon does not start in the test environment. This appears to be due to the fact that the default suricata config assumes eth0 as an interface name, but the testbed has ens2 as its default interface: # /usr/bin/suricata --af-packet -c /etc/suricata/suricata.yaml --pidfile /var/run/suricata.pid 10/4/2018 -- 05:31:56 - - This is Suricata version 4.0.4 RELEASE 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19) 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_SYSCALL(50)] - Failure when trying to get MTU via ioctl for 'eth0': No such device (19) 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/botcc.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/ciarmy.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/compromised.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/drop.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/dshield.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-attack_response.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-chat.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-current_events.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dns.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-dos.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-exploit.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-ftp.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-imap.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-malware.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-misc.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-mobile_malware.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-netbios.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-p2p.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-policy.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-pop3.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-rpc.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-scan.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-smtp.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-snmp.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-sql.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-telnet.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-tftp.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-trojan.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-user_agents.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerging-voip.rules 10/4/2018 -- 05:31:56 - - [ERRCODE: SC_ERR_NO_RULES(42)] - No rule files match the pattern /etc/suricata/rules/emerg
