I'd like to implement support in Provision's nginx/nginx_ssl servers for the X-Forwarded-For and PROXY protocol headers.

Would a patch be accepted that does not provide this support to the apache servers?

I think this needs to be in provision itself because there are no hooks for altering nginx config lines which has already been defined (such as listen). Correct me if I'm wrong and I'll make my own module instead.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JamesK created an issue. See original summary.

colan’s picture

Would a patch be accepted that does not provide this support to the apache servers?

Yes, an Nginx-only patch would be fine. Apache work on this can be done later. Thanks for doing this!

Please be aware that the SSL/HTTPS functionality in core (Provision) is essentially deprecated. We're about to roll out Aegir HTTPS which is the replacement. If you could add a merge request over there for the HTTPS stuff as well, it would be fantastic.

JamesK’s picture

Thanks for the quick reply. How stable is Aegir HTTPS?

colan’s picture

It will be ready for testing as soon as I get Replace all references to upstream project letsencrypt.sh with 'dehydrated' completed, which I'm working on right now. Take a look at the issue queue, but the one thing that'll be missing is support for certificates other than Let's Encrypt. The issue for that is Add a 'manual' Certificate implementation. Patches welcome! The original goal of the project was to add Let's Encrypt support to Aegir as per #2629560: [meta] Let's encrypt support, so nobody's looking at other certificates yet.

So it's not ready for Production today, but I'm planning to have it in that state for one of my projects (php7+nginx) by the end of the month, having LE certs for all hosted sites.

Other testers would really help. :)

ergonlogic’s picture

Note that reverse proxy support has been discussed for a long time: #1047174: Reverse proxy support

Ideally, this'd be implemented as a separate service type (proxy), for which we could have a default implementation (nginx). This'd make Apache support moot, as an Nginx proxy can sit in front of an Apache web server. This would also allow Varnish (or other) support later on.

JamesK’s picture

@ergonlogic Thanks for linking that issue. The discussion is related, but this issue is about having the nginx config support putting a reverse proxy in front of it, not for configuring nginx as a reverse proxy. PROXY protocol support can't be provided at the PHP level and requires changing the listen directive in the nginx config, so this has to be patched into the nginx feature itself.

ergonlogic’s picture

Ah, my mistake. Would context appended to the server or platform config, or in the pre.d/ dir not work?

JamesK’s picture

Only with an API change to allow hooks into setting `listen` in the vhost config.

JamesK’s picture

FileSize
8.46 KB

Here's the provision patch.

JamesK’s picture

Assigned: Unassigned » JamesK
Status: Active » Needs review
Related issues: +#2830365: Support load balancers (UI)
colan’s picture

Issue tags: +Port to Aegir HTTPS
JamesK’s picture

Is any further work needed?

memtkmcc’s picture

Status: Needs review » Needs work

The patch looks good to me, but you can't assume that the server was built with --with-http_realip_module, so perhaps the extra check would be a good idea, like we do this for some other modules?

JamesK’s picture

edit: never mind

JamesK’s picture

FileSize
16.38 KB

I've addressed #13 and also made the default server block respond to requests for health checking.

JamesK’s picture

Status: Needs work » Needs review
JamesK’s picture

Status: Needs review » Needs work

Need to fix the server ssl location block

JamesK’s picture

Status: Needs work » Needs review
FileSize
16.8 KB
bdragon’s picture

I need a little helper on top of these changes to support using this patch for its Provision_Service_http_public public changes to fix #2952716: Support load balancers (hosting_https+ui) not getting https_proxy_type passed through to provisioning properly.

dpovshed’s picture

Unfortunately even with the latest patch the settings from UI are not reflected either in the backend nor in the drush aliases file.

When debugging, I noticed that $this->server->https_proxy_type is always 0 disregarding of the selected value.