Project

General

Profile

Actions

Feature #4782

open

Task #4780: config: configuration usability improvements

config: add command to dump all active settings

Added by Victor Julien over 2 years ago. Updated 4 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
Target version:
-
Effort:
Difficulty:
Label:

Description

Differs from --dump-config in that the latter only dumps settings that are loaded from the YAML, but not built-in defaults.


Related issues 6 (5 open1 closed)

Related to Suricata - Bug #1911: Commandline provided configuration values don't persist after initial startupIn ReviewJason IshActions
Related to Suricata - Task #5939: config: deprecate multiple "include" statements at the same levelClosedJason IshActions
Related to Suricata - Feature #1993: commandline: introduce --enable-all-outputs switchAssignedOISF DevActions
Related to Suricata - Feature #3636: eve: configuration options to enable all, none or just a default set of outputsAssignedJuliana Fajardini ReichowActions
Related to Suricata - Feature #4781: config: add command to dump built-in config defaultsNewActions
Related to Suricata - Task #4762: Suricon 2021 brainstormAssignedVictor JulienActions
Actions #1

Updated by Victor Julien over 2 years ago

  • Tracker changed from Task to Feature
Actions #2

Updated by Jason Ish over 2 years ago

Exim was the tool that was brought up as an example, exim -bP dumps the active configuration, even if the config file is empty. It does have the benefit of a very flat, key=val configuration file format.

Actions #3

Updated by Victor Julien over 2 years ago

I think postfix was another one that was brought up http://www.postfix.org/postconf.1.html

Actions #4

Updated by Jason Ish almost 2 years ago

  • Related to Bug #1911: Commandline provided configuration values don't persist after initial startup added
Actions #5

Updated by Jason Ish almost 2 years ago

Some thoughts on getting this done.

- All configuration needs to exist in a single datastore.
- This datastore can simply be a hard-coded YAML file that provides a complete fully default configuration.
- There also needs to be a "configuration" factory of sorts, as we have dynamic elements to our configuration. A common example of this is outputs, you can register multiple eve outputs so we can't hard code all these into a defualt configuration, but we can provide a default configuration for each eve logger, provided via a factory method of sorts.
- There also needs to be some precedence order to solve issue #1911 in a more generic way. Where when getting a configuration value with a prefix, the "fixed" set of vars is checked first, this makes sure stuff on the command line always takes precedence over values in the configuration file.
- I'd like this "central datastore" of config to be its own Rust crate that could also be used independently of Suricata for working with the configuration. We can get this pretty much for free by keeping it in mind from the start.
- Modules should not fall back to hard coded configuration they did not get from the main config datastore. The hardcoded value should be put into the datastore.

This should allow one to dump the complete default configuration, as well as a running config, which is the default configuration with the loaded configuration layered on top. With every possible configurable value in the output.

Actions #6

Updated by Jason Ish almost 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Jason Ish

I now have a draft PR with some work towards this issue. Specically the comment here: https://github.com/OISF/suricata/pull/7528#issuecomment-1154352418

Actions #7

Updated by Jason Ish about 1 year ago

  • Related to Task #5939: config: deprecate multiple "include" statements at the same level added
Actions #8

Updated by Victor Julien 4 months ago

  • Related to Feature #1993: commandline: introduce --enable-all-outputs switch added
Actions #9

Updated by Victor Julien 4 months ago

  • Related to Feature #3636: eve: configuration options to enable all, none or just a default set of outputs added
Actions #10

Updated by Victor Julien 4 months ago

I've added relations to #1993 and #3636 as I think these would be much simpler to implement if built-in defaults would be "hard coded" yaml files. Enable all outputs would then just mean we select a different hard coded built-in default for outputs. Make sense?

Actions #11

Updated by Jason Ish 2 months ago

  • Related to Feature #4781: config: add command to dump built-in config defaults added
Actions #12

Updated by Jason Ish 2 months ago

  • Related to Task #4762: Suricon 2021 brainstorm added
Actions

Also available in: Atom PDF