05:40:53 <joerg> sounds sorta lame to blame also for pulse hickups

05:41:04 <joerg> alsa too

06:35:25 <brocashelm> problems with upgrading/installing fail2ban, due to ipv6 rules not being "defined". same version on all other machines with zero issues, except this one: https://dpaste.org/gAm9V

06:58:14 <hagbard> with the exact identical configuration and rules files?

06:59:59 <brocashelm> yes

07:01:48 <hagbard> strange indeed

07:06:09 <hagbard> The Error seems to be a python OSError, originating from the kernel.

07:08:39 <hagbard> nftables or iptables module not not loaded, or whatever fail2ban is configured to use?

07:21:52 <brocashelm> hmmm

07:22:53 <brocashelm> what i did was edit sshd.local and defaults-debian.conf to set [sshd] enabled to false, and then it went through

07:23:51 <brocashelm> there's also a debian bug report (#1024305) for it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1024305

07:24:30 <hagbard> that's just about the warning. Thats different from the error.

07:44:48 <rwp> I upgraded a system from beowulf to chimaera in the last week and hit that same fail2ban allowipv6 Bug#1024305 error too.

07:45:18 <rwp> But I was also having python package upgrade dependency problems too. I had to more forcefully take charge of the python package upgrade.

07:45:41 <rwp> In that process I purged fail2ban, completed the rest of the system upgrade, then installed fail2ban back on again.

07:46:06 <rwp> After I completed the upgrade the re-install of fail2ban afterward had no such allowipv6 error!

07:46:28 <rwp> I found that very strange. But since it isn't giving me the error I no longer have a test case.

07:46:46 <rwp> I can only assume that the fail2ban error was somehow related to the incomplete python upgrade that the system was in at that time.

07:48:56 <rwp> Oh! My chimaera system of course only has fail2ban 0.11.2-2 on it! My confusion. I must be confusing it with my Ceres system.

07:49:31 <rwp> My Ceres system still needs the allowipv6 = auto addition to be quiet. I put it in /etc/fail2ban/fail2ban.d/local.conf so that it would not modify the conffile and would not need merging in the future.

07:49:38 <rwp> Sorry for adding this noise due to my confusion.

07:50:56 <rwp> The rest of what I reported about python in the beowulf to chimaera upgrade and purging fail2ban and reinstall was accurate though.

08:07:06 <onefang> In my experience fail2ban fails to ban often, coz it's fighting with the firewall. Now I'm looking for fail2ban + firewall combination that works with this years new *tables or whatever it is called this year, and doesn't fail to ban.

08:07:46 <onefang> But right now it's Sunday morning and I'm still waking up.

08:15:09 <rwp> At this moment iptables still works. I have yet to learn how to drive nftables.

08:15:10 <rwp> It is annoying that though they could keep the interface compatible and change the internals that they have chosen to thrash us all multiple times.

08:15:56 <rwp> But as for fail2ban in Beowulf anyway there was no trimming (sqlite optimize?) of the sqlite database files.

08:16:09 <rwp> Meaning that on my systems those grow and grow and grow without bounds.

08:16:43 <rwp> At the last upgrade on my system I quoted above the sqlite files were 3.1GB in size and were filling up the /var partition causing problems.

08:19:59 <onefang> Well when I put an IP into my firewall coz I'm tired of it poping up in fail2ban, I stop both and delete the sqlite file completely, so fail2ban wont try to unban the IP the firewall thought it banned. The recedive thingy seems to be helping, but still leaves a window of oppurtunity when I want a permaban for an IP.

08:21:29 <rwp> I don't think fail2ban is the right place to place a perma-ban on an IP address. I just do those in the firewall and fail2ban doesn't know about it.

08:22:35 <onefang> Which is why when the timeout for fail2ban runs out, fail2ban will unban the IP, and the firewall doesn't know that this IP is now allowed through.

08:23:37 <rwp> I am confused. Sorry. Are you saying that if you ban an IP at the firewall level outside of fail2ban that fail2ban will at the timeout unban it? (Doesn't work like that here. Wrong chain.)

08:24:13 <onefang> Yep, exactly. It fails to ban.

08:25:09 <rwp> Which firewall is that? I use shorewall (I know, it is moribund, and I will eventually need to move on) and these will be in different chains and have no interaction at all.

08:25:26 <FatPhil> I've always planned to write my own back-to-basics fail2ban replacement. The guys doing dictionary attacks on my SSH ports may be blocked 90% of the time, but it seems dumb to just let them have the same chances again as soon as they're unblocked. It shouldn't be so forgiving.

08:25:33 <onefang> Ah use a different IP chain, or IP table, or NF table, or what ever the kernel people change it to next year.

08:25:43 <onefang> shorewall. lol

08:26:25 <rwp> Laugh if you want but I like it and will miss it when it becomes unusable. I like files on disk for configuration and it provides it.

08:26:57 <onefang> These days the bad people tend to use throw away cloud IPs or network bot armies, so fail2ban is becoming less relevant anyway.

08:27:09 <rwp> The author and main maintainer is basically retiring from the project. Unable to deal with the endless kernel changes and endless need to support of everyone.

08:27:20 <onefang> Yes, I like shorewall to, which is why I still use it.

08:27:46 <rwp> Oh! You laughed at the mention of it. I thought you were against it. Miscommunication there.

08:27:49 <onefang> I was laughing coz I DO use it.

08:28:36 <rwp> The main firewall I see people using today is ufw due to popularizing in Ubuntu.

08:28:47 <rwp> I haven't tried hard to learn it but it seems to be one that one crafts in place with commands rather than having files on disk for configuration.

08:29:01 <rwp> A dynamic versus static type of configuration paradigm.

08:29:31 <onefang> But yeah, for that shorewall maintainer retiring reason, *tables, and this failToBan thing I've been searching for a new combo for some time.

08:29:40 <rwp> ufw may have a way to statically configure it but no one who I have chatted with that uses it knows how to do it using ufw.

08:30:20 <rwp> Like FatPhil I have been thinking I might try my hand at writing a firewall and fail2ban replacement for my own use.

08:30:37 <onefang> You two should work together. B-)

08:31:08 <rwp> Because fail2ban is very limited in scope. It's stateless more than state full. Making it hard to catch some common and typical abuse attack patterns.

08:32:18 <onefang> Also post about this planned replacement on the Devuan-dev mailing list, you might find more contributors.

08:33:17 <onefang> Don't forget to make the backend modular, for next years kernel *tables.

08:38:15 <onefang> Also fail2ban scans your log files looking for errors, and I've been trying out other security things that also scan your log files looking for suspicious activity. Maybe a more flexible log scanner that can do various responses besides banning IPs? Then there's not half a dozen tools all scanning my log files. Then getting bogged down when ntfs-3g dumped 12 GB of duplicated error messages into syslog the other day.

08:41:12 <onefang> OK time to finish waking up.