Bug #1911
openCommandline provided configuration values don't persist after initial startup
Description
When using --set key=value commandline arguments to set some configuration parameters on startup, it seems that those values are not carried across reloads.
What I'd expect would happen:
# suricata ... --set default-rule-path=/some/path kill -USR2 suricata_pid <suricata reloads normally, reading rules from /some/path>
What actually happens
# suricata ... --set default-rule-path=/some/path kill -USR2 _suricata_pid <suricata reloads normally, reading rules from default (compiled in) /etc/suricata/rules but due to wrong directory in regard of --set argument, the rule files aren't found -> operation continues with empty ruleset>
Updated by Jason Ish about 8 years ago
- Assignee set to Jason Ish
- Target version set to TBD
Will look into this.
Updated by Victor Julien about 8 years ago
Think the issue likely is related to the new namespace we load the new config into?
Updated by Jason Ish about 8 years ago
Something like that. --set has issues in how its used, and I think its how I mark certain configuration parameters as "final". So if you go and load a new config, and don't iterate through the old config looking for the "final" values, you'll lose them.
I've talked before about having to config trees. Once that contains values set on the command line, the other the values from the file. When looking something up it will look in the command line conf tree first, then fall back to the file. So if I file reload takes place, it shouldn't matter.
It comes with other issues like how to properly iterate the full config for a dump.
Updated by Jason Ish over 2 years ago
- Related to Feature #4782: config: add command to dump all active settings added
Updated by Jason Ish over 2 years ago
- Status changed from New to In Review
Fix for this specific issue in review here: https://github.com/OISF/suricata/pull/7376
The broader idea is something I'm considering as part of a config overhaul, being discussed in #4782 .