Hi, Christopher. Thanks for asking this question. It's a good one.
On Saturday, 06 October 2018 at 12:54, Christopher Engelhard wrote:
Hi, I've recently created a package for SSHGuard [1]. SSHGuard is a program to block brute-force attacks on SSH and other services, similar to fail2ban/etc.
Now, my issue is the following:
- SSHGuard is completely agnostic with respect to the firewall-backend
it uses and the logs it reads. Accordingly, it ships with an example config file that does not set either backend or logreader, the user has to do that themselves. There are, however, commented example lines configuring iptables + journald.
- Fedora, obviously, by default uses firewalld and journald.
What is the guideline for packaging software like this:
- Leave it as upstream ships it.
- user will have to configure the package before it becomes functional
- no dependency on any non-essential packages
- ship example config file as real config file, with upstream's example config activated
- package works out-of-the-box
- introduces additional, non-default dependency (iptables)
Ship this configuration in a subpackage (sshguard-iptables). Use rich dependencies to have it auto-installed if iptables-services is installed.
- ship custom config file preconfigured for Fedora defaults
- package works out-of-the-box
- introduces dependency on default Fedora packages (firewalld)
Ship this configuration in a subpackage (sshguard-firewalld). Use rich dependencies to have it auto-installed if firewalld is installed.
Granted, option (2) is rather silly,
It's not silly if it's optional.
but is (1) or (3) the correct way to go about configuring the package?
(3) is the best option if you want to do as little work as possible but still create a seamless experience for the default case. With a little more work, you can make users of non-default configurations (like myself) happy(-ier).
PS. What's wrong with fail2ban?
Regards, Dominik