After the recent changes in nginx (i suspect #1635596: nginx: do not decide the policy for users), there is a new problem when verifying a site:

    aegir@angela:/home/anarcat$ drush @hostmaster provision-verify
    <em>nginx</em> on <em>angela</em> could not be restarted. Changes might not be available until this has been done. (error: <em>Reloading nginx configuration: nginx: [emerg] open()                                    [warning]
    &quot;/var/aegir/config/includes/nginx_vhost_common.conf&quot; failed (2: No such file or directory) in /var/aegir/config/server_master/nginx/vhost.d/aegir.angela.anarcat.ath.cx:31
    nginx: configuration file /etc/nginx/nginx.conf test failed</em>)

This would happen even after server verification.

I fixed this by manually creating the following symlink:

lrwxrwxrwx 1 aegir aegir 25 mai 17 20:59 nginx_vhost_common.conf -> nginx_simple_include.conf

but this seems to me to be a bug in the server verification.

Comments

omega8cc’s picture

omega8cc commented
Priority: Critical » Normal

This is nothing new. And this is only a symptom, not a real problem. This is also a reason we had to add the how-to to force **server** (not the site) re-verify *via front-end*, because backend verification doesn't update these config files.

su -s /bin/bash - aegir -c "drush @hostmaster hosting-task @server_master verify --force -d"

It would be nice to get this fixed, but the problem is already well known, so I would tend to close this as a duplicate of many previously reported issues, which affect not only Nginx configuration, but also lost vhost aliases etc.

anarcat’s picture

anarcat commented
Priority: Normal » Critical

reverifying the site through the frontend doesn't help, the symlink is still not created. furthermore, i am not sure how this is related to #1004526: Automatic aliases are not persisted across rename and clone.

omega8cc’s picture

omega8cc commented

You need to re-verify the **server**, not the site. And yes, it is related, because it is another case for the same problem - some things work properly only when you run Verify via frontend. There are of course differences but the problem is the same - Verify in the backend doesn't work as it should work, while running it via frontend does work as expected - in both cases. It is a problem known for years already - at least since 2010.

anarcat’s picture

anarcat commented

actually, you were right, i just forgot to wait for the queue to run - so running it through hosting-task actually works! weiiird.

omega8cc’s picture

omega8cc commented

So, I think that the original issue here is a result of confusion, because it simply can't work on a *site* verify, because it is the *server* what needs to be re-verified - to make it more puzzling - via frontend.

omega8cc’s picture

omega8cc commented

Note also that running server verify via frontend has this not so nice side effect - it will trigger re-verify for all platforms.

anarcat’s picture

anarcat commented
Status: Active » Fixed

i figured it out. the problem was that the include file was generated in the 'platform' context instead of the 'server' context. this was working from the frontend because, as you mentionned, the frontend verify triggers verification for all platforms, which then in turn would generate the missing config.

see commit e918bcc

omega8cc’s picture

omega8cc commented

Right, not sure how it got there, probably leftover from earlier testing in a local dev branch. Thanks for the fix!

anarcat’s picture

anarcat commented
Title: missing nginx_vhost_common.conf file on site verify » cannot generate multiple configuration files in nginx
Status: Fixed » Needs work

So this commit actually broke the nginx port completely, because contrary to what i though...

    $this->configs['server'][] = 'Provision_Config_Nginx_Server';
    $this->configs['server'][] = 'Provision_Config_Nginx_Inc_Server';

... that doesn't create two configuration files, it just creates the latter file. crap. so now 2.x doesn't generate the main nginx.conf file. blast.

omega8cc’s picture

omega8cc commented

Uh, so I guess this is why I have used the platform context here (which is not used in Nginx for anything else). Just to avoid creating completely new context etc.

I have tried various tricks to make this happen, but it seems that it is not really possible to create extra config files in the same context on the same (init) run, because there is only one config template defined to process etc.

anarcat’s picture

anarcat commented
Assigned: Unassigned » anarcat
Status: Needs work » Fixed

yep, i've figured it out, actually.

this is a potentially disruptive change, but at least i was able to successfully generate both config files now.

see dc87266 commit.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

  • Commit dc87266 on dev-drupal-8, 6.x-2.x, dev-ssl-ip-allocation-refactor, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by anarcat: 
    properly manage multiple configuration files per context

it seems this...
  • Commit e918bcc on dev-drupal-8, 6.x-2.x, dev-ssl-ip-allocation-refactor, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x by anarcat:
    make sure we can verify servers directly, closes #2000038

this was...