Bizarre Nginx Config Produced On Provision [Solved]

trellis
1

Trying to set up a fresh development environment for a new site. Forked off the latest version of Trellis, modified the development folder’s wordpress_sites and vault files for the site name I’m using, and ran vagrant up. Provisioning seems to go fine, until the very end:

RUNNING HANDLER [common : reload nginx] ****************************************
ERROR! Unexpected Exception: 'TaskInclude' object has no attribute 'has_triggered'
to see the full traceback, use -vvv
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

Attempting to open the local development url produces the default “Welcome to nginx!” page. SSHing into the vagrant box and running sudo service nginx restart appears to successfully restart it, but the domain no longer loads. Anyone else experiencing this?

Updated

This appears to be the real issue: For whatever reason, ansible is producing a bizarre configuration for nginx:

# Ansible managed: [[snipped]]

server {
  listen 80;

  server_name   i   n   t   r   a   x   i   a   .   l   o   c   a   l  ;
  access_log   /srv/www/intraxia.com/logs/access.log;
  error_log    /srv/www/intraxia.com/logs/error.log;

  root  /srv/www/intraxia.com/current/web;
  index index.php index.htm index.html;

  charset utf-8;

  # See Virtualbox section at http://wiki.nginx.org/Pitfalls
  sendfile off;

  add_header Fastcgi-Cache $upstream_cache_status;


  include acme-challenge-location.conf;

  include includes.d/intraxia.com/*.conf;
  include wordpress.conf;

  location ~ \.php$ {
    try_files $uri =404;
    error_page 404 /index.php;

    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT $realpath_root;
    fastcgi_pass unix:/var/run/php-fpm-wordpress.sock;
  }
}


server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.n;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://n$request_uri;
    }
  }
server {
  listen 80;
  server_name www.t;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://t$request_uri;
    }
  }
server {
  listen 80;
  server_name www.r;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://r$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://a$request_uri;
    }
  }
server {
  listen 80;
  server_name www.x;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://x$request_uri;
    }
  }
server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://l$request_uri;
    }
  }
server {
  listen 80;
  server_name www.o;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://o$request_uri;
    }
  }
server {
  listen 80;
  server_name www.c;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://c$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://a$request_uri;
    }
  }
server {
  listen 80;
  server_name www.l;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://l$request_uri;
    }
  }
2

Update:

This is the error log for nginx:

2016/06/09 11:55:16 [emerg] 1268#1268: server name "." is invalid in /etc/nginx/sites-enabled/intraxia.com.conf:6
2016/06/09 11:55:16 [emerg] 1271#1271: server name "." is invalid in /etc/nginx/sites-enabled/intraxia.com.conf:6
2016/06/09 11:55:18 [emerg] 1284#1284: server name "." is invalid in /etc/nginx/sites-enabled/intraxia.com.conf:6
2016/06/09 11:58:04 [warn] 1309#1309: conflicting server name "www.i" on 0.0.0.0:80, ignored
2016/06/09 11:58:04 [warn] 1309#1309: conflicting server name "www.a" on 0.0.0.0:80, ignored
2016/06/09 11:58:04 [emerg] 1309#1309: invalid server name or wildcard "www.." on 0.0.0.0:80
2016/06/09 11:58:05 [warn] 1320#1320: conflicting server name "www.i" on 0.0.0.0:80, ignored
2016/06/09 11:58:05 [warn] 1320#1320: conflicting server name "www.a" on 0.0.0.0:80, ignored
2016/06/09 11:58:05 [emerg] 1320#1320: invalid server name or wildcard "www.." on 0.0.0.0:80

Which suggested the configuration was borked. So I checked out the nginx site config:

# Ansible managed: [[snipped]]

server {
  listen 80;

  server_name   i   n   t   r   a   x   i   a   .   l   o   c   a   l  ;
  access_log   /srv/www/intraxia.com/logs/access.log;
  error_log    /srv/www/intraxia.com/logs/error.log;

  root  /srv/www/intraxia.com/current/web;
  index index.php index.htm index.html;

  charset utf-8;

  # See Virtualbox section at http://wiki.nginx.org/Pitfalls
  sendfile off;

  add_header Fastcgi-Cache $upstream_cache_status;


  include acme-challenge-location.conf;

  include includes.d/intraxia.com/*.conf;
  include wordpress.conf;

  location ~ \.php$ {
    try_files $uri =404;
    error_page 404 /index.php;

    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT $realpath_root;
    fastcgi_pass unix:/var/run/php-fpm-wordpress.sock;
  }
}


server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.n;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://n$request_uri;
    }
  }
server {
  listen 80;
  server_name www.t;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://t$request_uri;
    }
  }
server {
  listen 80;
  server_name www.r;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://r$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://a$request_uri;
    }
  }
server {
  listen 80;
  server_name www.x;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://x$request_uri;
    }
  }
server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://l$request_uri;
    }
  }
server {
  listen 80;
  server_name www.o;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://o$request_uri;
    }
  }
server {
  listen 80;
  server_name www.c;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://c$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://a$request_uri;
    }
  }
server {
  listen 80;
  server_name www.l;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://l$request_uri;
    }
  }

I’m running the latest version of Ansible (2.1.0.0) and Vagrant (1.8.1).

3

I had this issue too until I pushed Ansible back down to 2.0.2.0. Give that a try.

Also see here: 'TaskInclude' object has no attribute 'has_triggered'

1 Like
4

Oh lame… Is there an ansible ticket (that we know of) related to this?

5

@cfx I downgraded, and no longer get that error, but the server still provisions with the extremely odd nginx configuration as posted above:

server {
  listen 80;

  server_name   i   n   t   r   a   x   i   a   .   t   e   s   t  ;
  access_log   /srv/www/intraxia.com/logs/access.log;
  error_log    /srv/www/intraxia.com/logs/error.log;

  root  /srv/www/intraxia.com/current/web;
  index index.php index.htm index.html;

  charset utf-8;

  # See Virtualbox section at http://wiki.nginx.org/Pitfalls
  sendfile off;

  add_header Fastcgi-Cache $upstream_cache_status;


  include acme-challenge-location.conf;

  include includes.d/intraxia.com/*.conf;
  include wordpress.conf;

  location ~ \.php$ {
    try_files $uri =404;
    error_page 404 /index.php;

    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    fastcgi_param DOCUMENT_ROOT $realpath_root;
    fastcgi_pass unix:/var/run/php-fpm-wordpress.sock;
  }
}


server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.n;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://n$request_uri;
    }
  }
server {
  listen 80;
  server_name www.t;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://t$request_uri;
    }
  }
server {
  listen 80;
  server_name www.r;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://r$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://a$request_uri;
    }
  }
server {
  listen 80;
  server_name www.x;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://x$request_uri;
    }
  }
server {
  listen 80;
  server_name www.i;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://i$request_uri;
    }
  }
server {
  listen 80;
  server_name www.a;

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

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

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://t$request_uri;
    }
  }
server {
  listen 80;
  server_name www.e;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://e$request_uri;
    }
  }
server {
  listen 80;
  server_name www.s;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://s$request_uri;
    }
  }
server {
  listen 80;
  server_name www.t;

  include acme-challenge-location.conf;

    location / {
      return 301 $scheme://t$request_uri;
    }
  }
6

Nevermind, I missed a - in the YAML config, so it treated like the word as a dictionary, and iterated over the letters in the domain rather than a list of domains.

1 Like