It’s not really unsupported…it’s just hard as hell to get the dependencies installed. Though, I didn’t know that until this conversation took place and I went and looked at what the dependencies are and what those dependencies depend on, and realized it’s all very modern Perl (and CentOS 6 has a Perl that is embarrassingly old…it was old even when CentOS 6 was new, and because RHEL/CentOS lock in the version through the lifecycle of the release, it never gets updated, except security backports…this is ordinarily a good feature, but for something you want modern features out of, it’s annoying).
So…basically, if you want modern features, you should use a modern version of your distro. I’ll see about making the 2FA feature smarter about when it tries to install dependencies, and if it sees it’s running on a very old Perl, it won’t even try, it’ll just say, “Hey, your Perl is too old.”
“About Fail2ban… would CSF firewall be an alternative, or use Fail2ban in addition to CSF? We have CSF and LFD and that already locks people out with failed passwords.”
Yes, CSF and LFD is a reasonable alternative to Fail2ban+iptables (on CentOS 6) or Fail2ban+firewalld (on CentOS 7 and other systemd-based distros) that Virtualmin sets up during installation. Ilia prefers it and has done a lot of work to make Authentic theme work nicely with CSF, including stuff like notifications and such (I think, though I don’t use CSF myself).
We considered going the CSF route, and it definitely has its advantages, but our policy of sticking as closely to the OS defaults as possible led to choosing firewalld (or iptables on old distros) instead. I also like lighter weight firewalls on servers…you really don’t need a bunch of complexity, and it can make it harder to understand when things go wrong if there are dozens or hundreds of rules that don’t actually do anything useful. Even the default firewall on CentOS is a bit crowded for my taste, but we mostly leave it alone in the interest of sticking close to stock.
But, if LFD is configured to watch all of the relevant logs, you should be fine not using fail2ban. They perform roughly the same service for you.
Fail2ban has actually kinda been a disappointment to me now that we have it out there in the wild. It can, in some circumstances, balloon up to tremendous size, at least in terms of VIRT memory usage (this rarely actually impacts the system, but it’s still alarming to see a 1.5 GB process, even if only 70MB of it is resident in memory). I’d like it if it were a little less resource intensive. I’m not sure if it has a memory leak or if it’s just memory-mapping all of the log files it watches (which would probably be mostly harmless), but it ends up being a pretty big resource consumer both in terms of memory and CPU, for a task that really ought to be very easy and not requiring a lot of resources.