falco.yaml and falco_rules.yaml overwritten during upgrade in Debian

[carestad]

Hi

When upgrading from Falco 0.6.0 to 0.7.0 today I noticed the installer just replaced falco.yaml and falco_rules.yaml, no questions asked. Somehow I expected the installer to ask me whether to keep the locally modified version or replace it, but that did not happen.

Is this the expected behavior, and if so how should I prevent this from happening in the future?

[mstemm]

I think you bring up a good point. For the falco rules file, I think we want to continue overwriting falco_rules.yaml on upgrade--every release usually has a significant set of changes to the falco rules. If you're making changes to the set of rules, or using your own additional rules, you should be able to add them to a separate file and specify them via an additional -r <custom rules yaml> argument on the falco command line. I'll keep this issue open to track making this more clear as well as coming up with a consistent name for the file in the init.d wrapper script, etc.

For falco.yaml, you're right--I should keep falco.yaml by default. I'll change the packaging for this in the next release.

[carestad]

Great!

If falco.yaml will be unaffected in the future, is it possible to assign several rules_file in it? If not and I have to append the -r <custom rules yaml> to the falco binary, I would have to modify init scripts and/or create custom systemd units for this purpose.

Alternatively, what about having falco always look for a file with locally modified rules, for example /etc/falco_rules.local.yaml? Kind of like how fail2ban does it with their jail.conf and jail.local files.

[mstemm]

Yeah that's what I was thinking. By default the config/etc would look for a default as well as local rules file, both in the config and when the falco binary is given no arguments, and gracefully handle a missing local file, or something.

[mstemm]

@carestad what linux distro were you using, btw? Just want to make sure I also get the rpm/debian packaging right.

[carestad]

The problem occurred on Debian in the 8.X branch, but I suppose it would be the same for Debian 9.X.