I just spent 2 hours trying to figure out why fail2ban didn’t increment the ban count.
--- a/fail2ban/etc/fail2ban/jail.local
+++ b/fail2ban/etc/fail2ban/jail.local
@@ -1,6 +1,6 @@
[DEFAULT]
-bantime.incremet = true
+bantime.increment = true
bantime.rndtime =
bantime.maxtime =
bantime.factor = 1
After I found that I seriously considered becoming a goose farmer.
One time I was trying to figure out why the MySQL command wasn’t connecting.
mysql -h127.0.0.1 -p6033
Eventually ended up having four different people help me in a huddle. After two hours we figured it out… it turns out the argument is -P for port.
I wasted several thousand dollars of company time with a casing issue 🥴
My team once spent an entire afternoon trying to figure out why an API call was returning either incorrect data, or just no data at all.
Basically we were in the middle of migrating the API call from one API to another and we didn’t update the URL in the variable, so it was still hitting the old API 🙃
because of garbage like that I always use the long option names in scripts, even when the short one would be obvious
Yeah, for scripts that should be the norm. It really helps with legibility and maintainability, not having to have the manual open for 5 programs while tweaking stuff. 👌
happens to the best. if fail2ban were any more resiliently engineered it would have failed to start due to the error in the config file
This is such an underutilized and neglected behavior.
The very least a config parser should do is to log a warning.
Well… Do you really think you’d do any better at incrementing geese?