bug#37388: <nginx-configuration> can lead to syntactically invalid configs

[Christopher Baines]

Ludovic Courtès <address@hidden> writes:

> It’s nice that we have <nginx-configuration> but I noticed that, unlike
> most or all other configuration records that we have, it’s possible to
> create an <nginx-configuration> record that leads to a syntactically
> invalid nginx config file.
>
> For example, if you have a location block like this:
>
>         (nginx-location-configuration
>           (uri "/manual/")
>           (body (list "alias /srv/guix-manual")))
>
> Guix will silently create an invalid nginx config file, which you’ll
> only notice once you’ve reconfigured and nginx fails to start.

I wonder if some errors could be caught at build time, before attempting
to start the service.

If in the derivation to build the configuration file, nginx is run
against the built config file with -t, that might spot errors at
derivation build time.

> See why?  That’s because we’re missing a semicolon in the “alias”
> directive, and that directive is spit out directly as is.
>
> To address it, we could have record types for <alias>, <root>, and all
> the directives out there; it could be tedious, unless we automate it,
> effectively creating a complete EDSL.
>
> Another approach would be to have an sexp representation of the nginx
> configuration language.  That’d effectively replace semicolons with
> parentheses :-), but more importantly, that would allow us to not paste
> strings as-is in the resulting config file.  The downside is that it’s
> very much “free style” compared to records, but we could still
> pattern-match the sexp to validate certain properties.

An sexp representation sounds good, although I think records will work
out better for the common and high level parts.

signature.asc
Description: PGP signature