Normally Provision runs test to check if Nginx has been compiled with (contrib) upload progress module and adds extra line in the /var/aegir/config/nginx.conf file:

upload_progress uploads 1m;

Then it is using the nginx_advanced_include.conf config include in every site vhost to leverage upload progress feature.

However, when you enable the nginx_ssl feature in Aegir *after* you provisioned some sites, the server node will be re-verfied, but this time Provision will fail to add expected (and now required) line in the /var/aegir/config/nginx.conf file, which will prevent Nginx reload and when you will try to force Nginx restart (or reboot the server) it will not be able to start at all because of fatal error:

root@server:/var/aegir/config/server_master# service nginx reload
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: [emerg] zero size shared memory zone "uploads"
nginx: configuration file /etc/nginx/nginx.conf test failed

To get your sites back online you will need to either add this line manually or re-verify all sites, so their vhosts will include nginx_simple_include.conf instead, which doesn't use the upload progress feature.

Of course you can also just disable the nginx_ssl feature in Aegir, but if you are already using it for one or more sites, you are locked in and have to add that line manually after every upgrade or server verify.

This is probably because the function save_server() {} exists only in the provision/http/Provision/Service/http/nginx.php file but is not used (and doesn't exist) in the provision/http/Provision/Service/http/nginx/ssl.php file.

We will test it ASAP and submit a patch.

Comments

omega8cc’s picture

Status: Active » Needs review
Anonymous’s picture

Hmm, I actually installed Aegir with Nginx and PHP5-FPM (for the first time!) to try and reproduce this and I couldn't.

That said, I couldn't get SSL working on Nginx anyway... it fails due to too many listeners clashing.

This is a side note, but, is there any documentation on getting Aegir and Nginx working properly (sans-Barracuda)? We didn't even have PHP5-FPM/CGI instructions in the docs, so I just did that myself..

Can you confirm if the nginx version in standard Debian Squeeze is affected by this (e.g whether it has upload progress compiled in)? Last I checked, it didn't, so I was surprised I couldn't get it to crash. It never wrote that config line into the nginx.conf though so I probably went wrong elsewhere.

Otherwise like usual I am happy to blindly commit Nginx fixes from you a always :) but figured I should finally get around to testing them myself too. (since Jenkins doesn't test Nginx installs... yet)

Any tips for me on how to consistently reproduce? Should I just install barracuda?

P.S If you ever get time (!) to write up vanilla Nginx + PHP CGI docs on the community site, you will be my hero :)

omega8cc’s picture

Wow! Nice to see you in the Nginx world :)

This upload progress stuff is never compiled in any distro, as it is a contrib module (and I have no idea if it will be included in any point in the future), so you can't reproduce it on any standard apt-get based install.

It went unnoticed because BOA by default doesn't use Aegir built-in SSL (because the built-in SSL doesn't support TLS/SNI) and instead we suggest to use an easy local SSL proxy for any SSL enabled domains: http://drupalcode.org/project/barracuda.git/blob/HEAD:/docs/SSL.txt since it allows to use either standard IP per domain setup or TLS/SNI.

Of course the plan is to submit TLS/SNI support to Aegir core, and the current proxy workaround is just a temporary thing.

There is nothing special in a standard apt-get based install for Aegir on Nginx and PHP-FPM, as we are using basically default setup, so it should just work (however I didn't test it in a few recent months).

Yes, the how-to for standalone (not-BOA) Aegir+Nginx+PHP-FPM install is on my to-do list :)

omega8cc’s picture

Hmm, however, standard SSL feature in Aegir should also work just fine - many BOA users have it enabled (and I also tested it many times) while we don't modify anything (in BOA) to get it to work out of the box. It is weird it didn't work for you.. I will try to reproduce it soon.

omega8cc’s picture

Oh, and Barracuda already has this patch included.

Anonymous’s picture

I still had trouble reproducing this, but I think that's more to do with my attempts at Nginx and less about the issue itself. I understand the issue you've described and how/why the patch probably fixes it.

Could I possibly twist your arm into providing a 6.x-1.x patch? Or am I asking too much after having not committed this already :)

omega8cc’s picture

Status: Needs review » Patch (to be ported)

OK, I will submit a patch for 6.x-1.x

omega8cc’s picture

Please don't commit the patch for 6.x-2.x linked at #1 - it will be refactored in our new clean repository: http://drupal.org/sandbox/omega8cc/1443220

Here is the patch for 6.x-1.x: http://drupalcode.org/sandbox/omega8cc/1443220.git/commit/0d98b016578886...

omega8cc’s picture

Version: 6.x-2.x-dev » 6.x-1.x-dev
Status: Patch (to be ported) » Needs review

This needs review.

Anonymous’s picture

Status: Needs review » Needs work

Thanks, committed to 6.x-1.x !

I'll keep this open to wait for the new 6.x-2.x patch.

omega8cc’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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

  • Commit d9d297d on 6.x-1.x, dev-drupal-8, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-subdir-multiserver, 6.x-2.x-backports, dev-helmo-3.x authored by omega8cc, committed by mig5:
    Issue #1388906 by omega8cc - It is possible to break Nginx based install...