Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> muradm <mail@muradm.net> writes:
>
>> * gnu/services/security.scm (fail2ban-jail-configuration)
>> [enabled?]: Should be maybe-boolean, which is how normaly 
>> fail2ban
>> is configured. This also allows sections without enabled field
>> like @samp{[DEFAULT]}.
>> * doc/guix.texi: Type of enabled? is maybe-boolean.
>> ---

[...]

>> @@ -197,7 +197,7 @@ (define-configuration 
>> fail2ban-jail-configuration
>>     "Required name of this jail configuration."
>>     empty-serializer)
>>    (enabled?
>> -   (boolean #t)
>> +   maybe-boolean
>
> I made this change willingly, because it doesn't make sense to 
> me to
> define a jail configuration that is disabled by default.
>
> Does that make sense?

When I was implementing configuration, I was thinking the same.

However, while trying to find sensible or hardcoded defaults,
looking at code and usage examples, I found that configuration
of fail2ban is quite loose, than one can anticipiate. Variables
can be overriden from many places, so absence of variable also
becomes as important. So I decided to opt-in for most fields
as maybe-.

IMHO, this is why they had to make --d/--dp flags to
dump effective configuration :)

I actually mention that in the docs, where it says that
unspecified values are not serialized in favor of whatever
are defaults and/or values specified elsewhere. Which are
basically hard to track.

And finally there is a [DEFAULT] section which applies to
all jails. But it is not a jail by itself. So if there is
"enabled = false" or "enabled = true", fail2ban fails to
start, because of unexpected variable for that section.

I hope it is clear enough.

Thanks in advance,
muradm

>
> Thanks,
>
> Maxim