Systemd unit: Do not send falco alerts to /var/log/messages by default

[ghost]

Signed-off-by: Domenico Chirabino chirabino@protonmail.com

What type of PR is this?
/kind bug

Any specific area of the project related to this PR?
/area engine

What this PR does:
This PR set StandardOutput to null in the systemd unit configuration falco.service.

Why we need it
After the migration from initd to systemd (#1448), when falco is installed via systemd it writes to /var/log/messages by default.

The problem is not present when manually running Falco (without using systemd).

This is due to the default value in the systemd configuration: DefaultStandardOutput=journal (which falco inherits), so that Falco standard output is redirected to /var/log/messages (see https://manpages.debian.org/wheezy/systemd/systemd.conf.5.en.html).

At the time of writing a workaround is to disable stdout_output:

stdout_output:
  enabled: false

I think that falco should not write to system logs by default. Moreover, asking users to disable stdout_output (enabled by default) may be misleading and confusing (ie. I want stdout_output enabled so I can start falco manually for debugging or for testing rules)

Which issue(s) this PR fixes:
Fixes #1673

Special notes for your reviewer:
Thanks for your time :)
/cc @leogr

Does this PR introduce a user-facing change?:

fix(scripts): correct standard output redirection in systemd config (DEB and RPM packages)

[poiana]

Welcome @chirabino! It looks like this is your first PR to falcosecurity/falco 🎉

[leogr]

/milestone 0.30.0

[poiana]

LGTM label has been added.

Git tree hash: a0ff8fb9f25322faa0233cf087984753f2d3c2cb

[mstemm]

I can kind of agree that falco logs shouldn't go to /var/log/messages by default. But with this change, where are falco alerts logged when run under systemd?

[leogr]

I can kind of agree that falco logs shouldn't go to /var/log/messages by default. But with this change, where are falco alerts logged when run under systemd?

Short answer: alerts will be still sent to syslog since the syslog_output is enabled by default 👇

falco/falco.yaml

Lines 154 to 155 in 7c98d00

	syslog_output:
	enabled: true

TL;DR
Actually, this issue is trying to fix a problem introduced in 0.28.0 by #1448 and does not prevent alerts from being sent to syslog.
Before that version, Falco was shipped with the initd configuration. syslog_output was the way to deliver alerts. Moreover, standard output was discarded by initd.
Starting from 0.28.0, when Falco migrated to systemd, the problem was introduced. Basically, systemd redirects (by default) the Falco's standard output to journal too (or to other destinations, depending the system configuration), while the syslog_output is still enabled. The final result is that we are getting duplicated log lines in /var/log/messages (you can find an example in this comment).
Luckily, the systemd's behavior can be configured (see StandardOutput= in https://manpages.debian.org/wheezy/systemd/systemd.exec.5.en.html).
Indeed, this fix just tells systemd not to copy the Falco standard output to /var/log/messages, avoiding duplicated log lines. Thus, the expected result is to restore the original Falco behavior (pre 0.28.0).

Note: It's been a long time since I've experienced this problem, so that I may have forgotten something. Also, I may be missing something, so make sure my reasons are correct 😸

[mstemm]

Sounds good, as long as there's some output channel still enabled.

[leogr]

/approve

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: chirabino, leogr

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[FedeDP]

Sorry for necrobumping; does anyone remember why the patch was only applied to rpm service, and not debian too?
@leogr @chirabino

[leogr]

Sorry for necrobumping; does anyone remember why the patch was only applied to rpm service, and not debian too? @leogr @chirabino

IIRC correctly, either the Debian default was different (so the issue was not present there) or we just forgot it 😸