Hello!

On Thu, Aug 29, 2019 at 08:04:41AM +0200, Guillaume Outters wrote:

> Hello,
>
> as an Nginx user, I regularly discover new features that prove
> useful if not game changers.
>
> However I stay puzzled (nearly since I started using it) on why
> the config include system does not allow relative paths, that
> is, relative to the currently parsed file. This would allow for
> simple modular config designs, where a "main" server config file
> can embed the snippets that are deployed next to it.
> The only tips I see on the forums and so is "hey, just use a
> templating system to absolutize every include at deployment
> time", which takes us away from Nginx' KISS philosophy.
>
> In an ideal world, my production nginx.conf would only include
> /var/www/*/app.conf, and I could drop my "blorp" web app (that I
> developed on /home/gui/www/blorp) in /var/www and have it
> running at the next nginx reload, with it correctly loading
> every location /xxx { include inc/phpfpm.conf; } of its
> app.conf.
> For now, I either have to centralize the snippets in
> /etc/nginx/inc/phpfpm.conf (thus when a new rule has to be added
> my developer has to tell my system operator to apply the change
> to the centralized file), or inline the snippets in the (then
> monolithic) app.conf (hey, duplication!), or hardcode the
> snippet's path as /var/www/blorp/inc/phpfpm.conf (and symlink it
> on my dev machine so that prod and dev config files are
> shared?), or better make the app.conf a template and fill
> absolute paths at deployment, so that if I want to run my shiny
> new version of blorp as blorp-ng along blorp it does not include
> the old version's phpfpm.conf erronously.

While this may be a counter-intuitive and not very convenient in
some cases, this is how it currently works: paths to configuration
files are resolved from the conf prefix, that is, from the path to
nginx.conf. You can think of it as if contents of included files
are imported into nginx.conf itself, and processed afterwards.

Changing this to resolve relative paths from the current included
file instead is possible, but would be a major change - I suspect
it will break a lot of configurations. Not sure we are going to
do this.

> The following patch adds a simple heuristic to include: if the
> includee starts with "./", it is considered relative to the
> current file. If not, the current heuristic applies (paths stay
> relative to the prefix).
>
> I would be interested in learning the flaws or drawbacks in this
> (bad?) idea. I first thought "security", (disallowing relative
> includes keeps included files under control in config's root),
> but anyhow, either you keep total control on the config (and are
> on your responsibility to not include anything out of the conf
> tree) or give the web app's developer a hook to load its
> app-required snippets, and then nothing prevents him to include
> whatever he wants.

Certainly I'm against this approach, as it breaks POLA. The
"include ./example.conf;" construct shouldn't be handled
differently from "include example.conf", these are clearly the
same thing.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel