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
