FEATURE Split config
Split configuration file
Fail2ban had a single (atomic) configuration file /etc/fail2ban.conf until 0.7.0. This file became quite lengthy since it held several kind of parameters: general settings, mail settings, section settings, etc. The proposal was to split this configuration file into several ones. Fail2ban-client now processes the config files and provides respective commands to running fail2ban-server. So the server daemon knows nothing about config files.
Every configuration file will be stored in the /etc/fail2ban directory.
- /etc/fail2ban/fail2ban.conf (file) will contain the general settings.
- /etc/fail2ban/jails.conf (file) will contain the jail definitions (one filter and one or more actions). Actions get triggered if filter matches maxfailures times within findtime.
- /etc/fail2ban/filter.d (dir) will contain the filter settings. This is primarily a failregex option. No timeregex should be necessary - they are guessed from the set of known. If not recognized - please add it as before (pre 0.7)
- /etc/fail2ban/filter.d/sshd.conf (file) will contain filter settings for OpenSSH server.
- /etc/fail2ban/filter.d/apache-auth.conf (file) will contain filter settings for Apache authentication.
- /etc/fail2ban/action.d (dir) will contain the action settings, i.e. how to react if a specific filter was matched specified (look jails.conf above) number of times
- /etc/fail2ban/action.d/iptables.conf (file) will contain the settings for banning an IP address using Netfilter/Iptables.
- /etc/fail2ban/action.d/hosts.conf (file) will contain the settings for banning an IP address using TCPWrapper.
The following ideas are not yet implemented
- /etc/fail2ban/pattern.d (dir) will contain regular expression templates.
- /etc/fail2ban/pattern.d/standard-date.conf (file) will contain a regular expression matching a standard date format.
- /etc/fail2ban/filter.d (dir) : The files included in this directory can benefit from the templates in /etc/fail2ban/pattern.d.
Any user change should be done in a file.local file instead of file.conf. .Conf files file.conf are ready first, and then file.local are read. This way, settings in .local override .conf. This should avoid conflicts between user and package settings when upgrading.