Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nginx service: add commonHttpConfig option #23279

Merged
merged 1 commit into from Mar 20, 2017

Conversation

mbbx6spp
Copy link
Contributor

Motivation for this change

For users of the nginx module that use the declarative virtualHosts structure there must be a way to define common definitions like log_format before using them inside of the server or location context blocks of the generated virtual hosts that is also at the http context block scope. Currently the NixOS nginx module does not offer a solution that doesn't require me to manage raw config files for my virtual hosts (I get an emerg because when I try to append the http config via appendHttpConfig it shows up after the virtual host generated usage).

I added a nginx module VM test to very this works. See nixos/tests/nginx.nix.

Things done
  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@mention-bot
Copy link

@mbbx6spp, thanks for your PR! By analyzing the history of the files in this pull request, we identified @globin, @domenkozar and @fadenb to be potential reviewers.

@fpletz
Copy link
Member

fpletz commented Feb 28, 2017

We've using appendHttpConfig for setting options like error_log, log_format, or add_header and it does seem to work fine for us.

Are there options that have to be defined before the server blocks?

@mbbx6spp
Copy link
Contributor Author

mbbx6spp commented Mar 1, 2017

@fpletz when I use appendHttpConfig with a custom log_format definition and I use the name of that custom log format inside the extraConfig attribute in an access_log line for either a virtual host (server block context) or a location context I receive an emerg error on nginx startup that looks like this:

proxy# [   16.076903] nginx[936]: nginx: [emerg] unknown log format "detailed" in /nix/store/HASH-nginx.conf:110

(when I use the virtualHosts declarative form and not managing my own server blocks inside the appendHttpConfig underneath my custom log_format). I would rather not resort to lumping all my virtual host server blocks inside the appendHttpConfig again. When I use the commonHttpConfig from this SHA, my nginx VM tests succeed since I don't receive an emerg error on nginx startup.

Of course, if I add a global access_log that refers to the custom log_format I would just put that underneath the log_format declaration and that might work, but when I do not want to universally apply the same access_log to all server contexts this does not apply.

@mbbx6spp
Copy link
Contributor Author

mbbx6spp commented Mar 7, 2017

Just to bump this because I don't think the use case is understood. appendHttpConfig does not satisfy my particular needs. Here is a small nginx config to demonstrate:

error_log  stderr;

events {

}

http {
  server {
    listen 80;
    server_name "my.bla.com";
    access_log   logs/my.bla.access.log  myformat;
  }
  server {
    listen 80;
    server_name "my.other.com";
    access_log   logs/my.other.access.log  combined;
  }

  # where appendHttpConfig would be placed.
  log_format myformat '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';
}

Checking nginx config file shows this emerg error as mentioned in the original description and my comment above.

$ nginx -t -c $PWD/crap2.conf
2017/03/06 18:14:19 [emerg] 20069#0: unknown log format "myformat" in <bla>/crap2.conf:9
nginx: configuration file <bla>/crap2.conf test failed

Hopefully that illustrates the problem with appendHttpConfig.

@fpletz fpletz requested a review from globin March 7, 2017 00:57
Copy link
Member

@fpletz fpletz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I forgot about this PR. Thanks a lot for the explanation and the examples. And the test of course! Looks good to me.

@globin What do you think? I'm not sure if the wording could confuse anyone.

@fpletz fpletz added this to the 17.03 milestone Mar 7, 2017
@fpletz fpletz added the 9.needs: port to stable A PR needs a backport to the stable release. label Mar 7, 2017
@fpletz
Copy link
Member

fpletz commented Mar 7, 2017

Also, this should be backported to 17.03 at least.

@globin
Copy link
Member

globin commented Mar 7, 2017

How about prependHttpConfig?

@mbbx6spp
Copy link
Contributor Author

Is this going to make it into 17.03? @globin if you want to change it to prependHttpConfig you should make sure it goes all the way on the top. I didn't want to mess with the ordering too much. If it changes, please provide an update here and update the docs.

@fpletz
Copy link
Member

fpletz commented Mar 20, 2017

Yes, you're right. @globin and I discussed this a few minutes ago and we'll go with your suggestion. Thanks!

This will be backported to 17.03.

@fpletz fpletz merged commit fff8cc7 into NixOS:master Mar 20, 2017
fpletz added a commit that referenced this pull request Mar 20, 2017
fpletz pushed a commit that referenced this pull request Mar 20, 2017
fpletz added a commit that referenced this pull request Mar 20, 2017
cc #23279

(cherry picked from commit 7151e74)
@samueldr samueldr removed the 9.needs: port to stable A PR needs a backport to the stable release. label Apr 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants