Thanks for your further testing and feedback, especially the bug report(s). You rock! :)
Hmm, I wonder WTH is going on with the log failure? By default that dir should be owned by www-data - the user Apache runs under - so that's all very weird... I'll have to look into that; I've opened a bug . As I'm super keen to fix the critical issue with Redmine, unfortunately it won't be fixed for v18.1.
Otherwise we're shipping the Debian mod_evasive defaults. Generally Debian provide sane defaults, but it seems it want's some loosening.
FYI we use it (with the TurnKey default) on this website and I haven't noticed any issues. But that doesn't mean that others don't - and obviously you did in your use case. IIRC there was at least one other user that was getting 403s and didn't know why - hence why we made the log location change. Others have just disabled it.
I'm ok with loosening the defaults but TBH, I'm not sure exactly what we should change them too? Adding client IPs (other than localhost?) is not an option for us. Although as a minimum we probably should add the (disabled) setting with a comment. Beyond that, these would be the ones to adjust:
DOSPageCount - threshhold for the number of requests for the same page by the same client within DOSPageInterval
DOSSiteCount - threshhold for the total number of requests for any object by the same client and the same listener process within DOSSiteInterval
DOSPageInterval / DOSSiteInterval - time in seconds that above are applied
The DOSSiteCount is per listener and we have no control over the number of listener processes as it depends on server resources (to a max of 1000 IIRC). So servers with more resources will have more listeners so likely take more beating the hit the limit. And the opposite for lower resource servers.
DOSPageCount is simply per interval, but limited to a specific URL.
My guess is that you were hitting the DOSSiteCount but unfortunately because it wasn't logging we can't be sure.
I'll have a play when I have time.
The systemd-sysctl errors are new to me?! I wonder if it's hardware dependent?
FWIW my local TKL v18.x servers only have 2 journal entries per boot:
Although on second glance it's a bit weird that the "Deactivated successfully" comes before the "Apply Kernel Variables"? Although they both have the same timestamp, so perhaps that's just a querk?
Regardless, to get rid of the error message in your logs, disable it. I.e.: comment out kernel.printk in /etc/sysctl.conf. FWIW it's commented out by default, but I don't recall exactly what it does. Something to do with quieting kernel output to the terminal I think?
Thanks for the feedback and bug report(s)
Thanks for your further testing and feedback, especially the bug report(s). You rock! :)
Hmm, I wonder WTH is going on with the log failure? By default that dir should be owned by www-data - the user Apache runs under - so that's all very weird... I'll have to look into that; I've opened a bug . As I'm super keen to fix the critical issue with Redmine, unfortunately it won't be fixed for v18.1.
Otherwise we're shipping the Debian mod_evasive defaults. Generally Debian provide sane defaults, but it seems it want's some loosening.
FYI we use it (with the TurnKey default) on this website and I haven't noticed any issues. But that doesn't mean that others don't - and obviously you did in your use case. IIRC there was at least one other user that was getting 403s and didn't know why - hence why we made the log location change. Others have just disabled it.
I'm ok with loosening the defaults but TBH, I'm not sure exactly what we should change them too? Adding client IPs (other than localhost?) is not an option for us. Although as a minimum we probably should add the (disabled) setting with a comment. Beyond that, these would be the ones to adjust:
DOSPageCount - threshhold for the number of requests for the same page by the same client within DOSPageInterval
DOSSiteCount - threshhold for the total number of requests for any object by the same client and the same listener process within DOSSiteInterval
DOSPageInterval / DOSSiteInterval - time in seconds that above are applied
The DOSSiteCount is per listener and we have no control over the number of listener processes as it depends on server resources (to a max of 1000 IIRC). So servers with more resources will have more listeners so likely take more beating the hit the limit. And the opposite for lower resource servers.
DOSPageCount is simply per interval, but limited to a specific URL.
My guess is that you were hitting the DOSSiteCount but unfortunately because it wasn't logging we can't be sure.
I'll have a play when I have time.
The systemd-sysctl errors are new to me?! I wonder if it's hardware dependent?
FWIW my local TKL v18.x servers only have 2 journal entries per boot:
Although on second glance it's a bit weird that the "Deactivated successfully" comes before the "Apply Kernel Variables"? Although they both have the same timestamp, so perhaps that's just a querk?
Regardless, to get rid of the error message in your logs, disable it. I.e.: comment out kernel.printk in /etc/sysctl.conf. FWIW it's commented out by default, but I don't recall exactly what it does. Something to do with quieting kernel output to the terminal I think?