On 03/20/2014 12:24 AM, Orion Poplawski wrote:
On 03/19/2014 02:56 PM, Matthew Miller wrote:
On Wed, Mar 19, 2014 at 02:32:40PM -0600, Orion Poplawski wrote:
Hmm, I like this alternative a lot. I'm probably taking this too
far, but I'm thinking of:
fail2ban-server - core components with minimal deps
fail2ban-firewalld - firewalld support/configuration - requires firewalld
fail2ban-hostsdeny - tcp_wrappers hosts.deny support - requires tcp_wrappers
fail2ban-mail - mail actions - requires /usr/bin/mail
fail2ban-sendmail - sendmail actions - requires
/usr/sbin/sendmail
fail2ban-shorewall - shorewall support - requires shorewall
fail2ban-systemd - systemd journal configuration
fail2ban - default component - installs -firewalld,-sendmail,-systemd
fail2ban-all - installs everything - also requires /usr/bin/whois
Comments?
That _might_ be going overboard. But it certainly does allow a lot of
flexibility. Somewhere there is a balance between that flexibility and the
extra packaging work and potential user confusion, and I'm not exactly sure
where that line is in this case. :)
This seemed reasonable to me so I've gone with it in rawhide now.
Testing welcome.
I am concerned that this looks like configuring the fail2ban package by
installing more packages. If we started doing it everywhere multiple
packages interact, it would combinatorially explode the number of
packages and make the system harder to maintain, not easier. Among other
things, it would make managing the subsystem on Fedora different than
everywhere else including upstream.
It's certainly a neat trick (down with obscure config files!), but the
approach does not scale. Taking this to extreme, we'd be doing yum
install emacs-vim-mode.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
