[bug#57473] [PATCH v2 3/4] gnu: fail2ban-service-type: Fix type of enabled? field.

[muradm]

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

signature.asc
Description: PGP signature