Closed nemchik closed 2 years ago
this would also end up reading trace/debug logs if those are enabled in the arr. do we really need to look back to retroactively ban?
I believe it would make fail2ban do more work, and I suppose it is not likely very beneficial.
I thought I had seen other jails setup to behave similarly, but I don't think that's actually the case.
https://github.com/linuxserver/fail2ban-confs/blob/62ed71ae23144c97ff87f5d85a24a1b8d1e11dbc/paths-common.conf#L52-L54 is similar, but not exactly the same. I am not entirely sure what the wildcard is meant to do here, but it does not look like it would match logrotate
d files (where the number is appended to the end of the file before the extension, not to the beginning).
https://github.com/linuxserver/fail2ban-confs/blob/master/jail.d/sabnzbd-auth.conf is setup to pick up logrotate
d files, but if we're not merging this PR then we should change the sab jail to also only look at one file.
I think we should look for a digit, if we can, rather than a wildcard, but i dont know what globbing is used here
I think we should look for a digit, if we can, rather than a wildcard, but i dont know what globbing is used here
We're probably safer to NOT do wildcard on these, and also to remove the wildcard on the sab log. I'll close this and open a new PR to remove the wildcard from the sab log.
*arr apps do numbered log files. ex:
This should allow checking any of those files.
After this merges, we can modify the readme https://github.com/linuxserver/docker-fail2ban/blob/7b612f44bc848c2e2b584fe602617b2262bd61e4/readme-vars.yml#L53 to point to the folder instead of the file.