We have tried to migrate SSL sites to our pack today, and it was a huge clusterfuck.

It seems to have totally failed: the alias for the sites didn't even accept the --ssl_enabled flag (absent from the alias file) and the SSL wasn't configured properly on the master server. I didn't check on the slave, but this was a huge problem. Somehow, the sites inherited *two* IPs: the internal and external IP of the pack's slave server.

While there seems to be obvious problems with the pack here, I believer this is also related to the obscure way we have to deal with IP addresses, and therefore with #1126640: move the SSL IP allocation to the frontend, which should be fixed before we bang our heads on this.

In the meantime, the workaround is to avoid provisionning SSL sites on clusters.

Comments

mccrodp’s picture

mccrodp commented

I have sites served by Varnish (reverse proxy server) that require a dedicated IP address and SSL support. So, this issue may also be somewhat related to #1047174: Reverse proxy support if the recommended method for provisioning sites behind reverse proxies such as Varnish in 2.x is to use cluster servers as described in comment #4 of that issue.

anarcat’s picture

anarcat commented

The SSL refactoring is going well and I will be looking again at this issue shortly. Now the trick will be to send a server -> IP mapping to the backend instead of just an IP listing. That way the backend can figure out how to create vhost files properly.

anarcat’s picture

anarcat commented

There is some progress here. The IP allocation code was fully refactored (in #1126640: move the SSL IP allocation to the frontend). That also includes allocating IPs for slave servers (#2000964: Install of web pack with ssl fails to allocate IP and cert), but it is unclear if this is actually functional. More testing is required, obviously, but we're on the right track.

One workaround for this would be to hack a hardcode of SNI for machines with SSL in the cluster, see #1926520: Support Server Name Indication (SNI) for SSL for that.

anarcat’s picture

anarcat commented
Status: Active » Fixed

so IP allocation works, now the only problem is that the ssl_enabled parameters are not accepted by provision-save. i tried to push a patch to fix that in provision (7a86f47), but it still wouldn't accept the parameters without --strict=0, which is a problem. this is similar to #1972286: Unknown options for provision-save but the fix there is, I suspect, incorrect - the classes should add their own properties through set-property, just like it's done in 7a86f47 but somehow that doesn't work, maybe some oddity related to clusters or the bootstrap order.

so i'll close this issue because it works if you manually run provision-save on the alias with --strict=0, and will followup in #1972286: Unknown options for provision-save.

Status: Fixed » Closed (fixed)

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

  • Commit 7a86f47 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 sites on clusters have the proper properties

this is...