|
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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
