Nginx Virtual host includes not working

Hi there!

I have been having some problems trying to use the include files to set redirections on my nginx server.
My the redirects are set in the file called redirects.conf.j2, in the folder wordpress-setup/templates/includes.d/mypage.com/.

When I run the playbook and deploy, the files are there, and my conf looks good. However, they don’t seem to be added to the Nginx configuration, because they don’t work. What does work is if I paste the content:

server {
    listen 80;
    server_name mypage.com;
    return 301 $scheme://www.mypage.com$request_uri;
}

At the end of the configuration template wordpress-site.conf.j2 (as a hack).

So, right now I have a way to make it works, but it isn’t very beautiful. Any ideas about it?

Thans for the support and thanks for your work in roots, it’s pretty useful!

What does that mean exactly? When you provision your server what does the output have for the relevant tasks? The task names are here: https://github.com/roots/trellis/blob/082430a3ad603d58be413cbf9a54b3e2f3d83cdc/roles/wordpress-setup/tasks/nginx.yml#L12-L35

Hi,

What I mean is that although the files are in the server, within the /etc/nginx/includes.d/ folder, they don’t seem to produce any effect (at first), right now my server doesn’t work.

These are the logs:


TASK: [wordpress-setup | Create includes.d directories] *********************** 
ok: [IP] => (item=mypage.com)

TASK: [wordpress-setup | Template files out to includes.d] ******************** 
changed: [IP] => (item=mypage.com/redirects.conf.j2)
ok: [IP] => (item=mypage.com/redirects.conf.j2)

Maybe I am not using it right, because I didn’t use any template to create those includes. I just add the files in wordpress-setup/templates/includes.d/mypage.com/

What’s in /etc/nginx/sites-enabled/mypage.com.conf? Do you see a line like this:

  include includes.d/mypage.com/*.conf;

Yes, that’s right:

include includes.d/mypage.com/*.conf;

I event tried to change this by an absolute path without any luck.

Oh I’m pretty sure I know what’s going on and you aren’t going to like it! I glossed over what you had in the includes file.

server {
    listen 80;
    server_name mypage.com;
    return 301 $scheme://www.mypage.com$request_uri;
}

Those includes.d files are included kind of in the middle of the conf. At the very bottom we have this:

{% for host in item.value.site_hosts if strip_www %}
server {
  {% if item.value.ssl is defined and item.value.ssl.enabled | default(false) -%}
    listen 443 ssl spdy;
  {% else -%}
    listen 80;
  {% endif -%}

  server_name www.{{ host }};
  return 301 $scheme://{{ host }}$request_uri;
}
{% endfor %}

That generates the same server block as you have but it’s taking precedence since it’s after it. So everything is working. Nginx includes it but then just overrides it with that other server block.

You can avoid this by setting strip_www to false.

Note: strip_www is a little broken since it doesn’t allow for what you want which is the opposite. It’s on our Todo list to have an option for www or no-www basically.

Hi,
it seems that I already set strip_www: false in /trellis/roles/nginx/defaults/main.yml, so it was already false, right?
Or should I set it somewhere else?

Well you should ideally never modify files in roles. Instead set variables in group_vars. But that’s strange then. If you did that then there shouldn’t be an issue with them overriding but I’m assuming it still has something to do with that :frowning:

Not sure I can help too much beyond that. It’s just an Nginx configuration issue at this point. The includes are working properly as they are intended. You could try moving the include includes.d/{{ item.key }}/*.conf; line to the end or further down.

Bingo!

Both solutions worked!

  • Setting strip_www: false in /trellis/group_vars/production/main.yml worked
  • Moving the includes.d/{{ item.key }}/*.conf; to the bottom of the file without explicitly setting strip_www to false worked too

so your theory about the rewriting makes sense!

Thanks a lot @swalkinshaw for your support and thank all the team for your work in roots, I am using the whole stack and I love it!

1 Like