Service is running/active and I can see logs in journalctl -f -u fail2ban, but none in /var/log/fail2ban.log
In /etc/fail2ban/fail2ban.local, logtarget = /var/log/fail2ban.log
Any ideas?
Checkout /etc/fail2ban/fail2ban.d/97_dietpi.conf, where logs are forced to STDOUT to avoid needing a plain text log file. If you need it:
echo -e '[Definition]\nlogtarget = /var/log/fail2ban.log' > /etc/fail2ban/fail2ban.d/99_log_to_file.conf
systemctl restart fail2ban
Thanks for the reply. Here’s what I get:
dietpi@DietPi:~$ sudo echo -e ‘[Definition]\nlogtarget = /var/log/fail2ban.log’ > /etc/fail2ban/fail2ban.d/99_log_to_file.conf
-bash: /etc/fail2ban/fail2ban.d/99_log_to_file.conf: Permission denied
contents of etc/fail2ban/fail2ban.d/97_dietpi.conf are:
[Definition]
logtarget = SYSOUT
Should I change SYSOUT to STDOUT?
No, “SYSOUT” is correct as the process in running as systemd service. It basically the same as “STDOUT” (logging as well to the “standard output” of the process) but omits timestamps and metadata which is added by the systemd journal already.
You cannot do shell redirects > with sudo. Only the echo runs as root but the redirect is done as dietpi user 
. You can do it like that:
echo -e '[Definition]\nlogtarget = /var/log/fail2ban.log' | sudo tee /etc/fail2ban/fail2ban.d/99_log_to_file.conf
So echo runs unprivileged but tee runs as root which writes to a file directly without redirect.
Or:
sudo bash -c 'echo -e "[Definition]\nlogtarget = /var/log/fail2ban.log" > /etc/fail2ban/fail2ban.d/99_log_to_file.conf'
So everything runs in a root subshell 
.
You cannot do shell redirects > with sudo. Only the echo runs as root but the redirect is done as dietpi user >
> . You can do it like that: echo -e
Understood. Reason I ran sudo is because your first command gave permission denied also, but now i know about sudo and echo.
sudo bash -c ‘echo -e “[Definition]\nlogtarget = /var/log/fail2ban.log” > /etc/fail2ban/fail2ban.d/99_log_to_file.conf’
Thank you, this worked, yay!! Any reasons why I ahve to run this to see logs output here by default? I had spun up a test vm to see if all default settings would give logs but that one didn’t either.
if possible DietPi aim’s to avoid writing logs to /var/log/ and logs are written to the systemd journal only. If I’m not mistaken this is done to reduce r/w operation. But I guess MichaIng could explain it more in detail.
I mean by default /var/log is a RAM drive (tmpfs) on DietPi, so disk writes are not related. But it is much easier to debug issues when you get the full picture via journalctl or not only process logs but service level logs via journalctl -u servicename. Otherwise it is sometimes a pain as you need to check both, journalctl and plain text log file, to get the full picture, still cannot be sure about the exact order of events across those due to slight timestamp mismatches or when they simply have insufficient precision, like no sub-seconds timestamps and all such.
Also it is a security aspect to not make sensitive logs available as plain text files, often world-readable.
And it is the future: Debian by default since Bookworm has rsyslog not installed anymore or any other second level syslog daemon. Already since Bullseye by default it ships with persistent journal logs to /var/log/journal.
Any downside for you when getting all fail2ban logs via journalctl -u fail2ban?
Those are interesting insights, and knowing order of events and having 1 place for logs makes sense for troubleshooting.
No downsides per se regarding seeing logs in journalctl, I just thought my system was broken or misconfigured since I followed installation directions from various sites referencing the logs were to be found in that directory/file. I’m also testing various system monitoring software, and netdata for instance references /var/logs/fail2ban.log to pull data from: https://learn.netdata.cloud/docs/agent/collectors/python.d.plugin/fail2ban/
I’d be happy to configure monitoring software to get logs from journalctl instead, I just don’t have the know-how to figure that one out.
The security side makes sense, and if the future is more security, I’m all for it, but its nice to see logs too;)
For pulling logs automatically indeed usually software has/needs specific backends. E.g. fail2ban itself has a systemd backend to read logs from there, using systemd unit name and other identifiers, instead of a plain text log file. This would hence need to be checked with the software you use for monitoring. But if required, you know now how to enable a fail2ban log file, and in dietpi-software the full logging option replaces RAMlog with rsyslog, which enables all the syslog files in /var/log.