bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gábor Boskovits
Subject: bug#37388: <nginx-configuration> can lead to syntactically invalid configs
Date: Thu, 12 Sep 2019 14:49:10 +0200

Hello,

Ludovic Courtès <address@hidden> ezt írta (időpont: 2019. szept. 12., Cs, 9:58):
Hello Guix!

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.

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.


I would most probably go for the sexp version.
 
Thoughts?

I would like to add some more information to this, which I encountered when trying to find a solution to the last-modified issue:

1. the nginx configuration can only be extended using server blocks, so it is not possible to inject a location or a nested location.
2. the meaning of the nginx configuration can dependent on the order of directives in the configuration. Either we should give
and explicit mechanism for dealing with that, or disallow such configurations.

If you feel these points to be off topic, then I can open a separate bug for that, but these seem to relate to the confgiuration mechanism,
and should be considered when designing the new interface. Wdyt?
 

Ludo’.




Best regards,
g_bor

--
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

reply via email to

[Prev in Thread] Current Thread [Next in Thread]