Closed (fixed)
Project:
Hostmaster (Aegir)
Version:
6.x-0.4-alpha2
Component:
Code
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
2 Aug 2010 at 22:32 UTC
Updated:
30 May 2014 at 10:04 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
daveparrish commentedsub
Comment #2
butler360 commentedSubscribing.
Comment #3
jaybhancock commentedSubscribing
Comment #4
DanielJohnston commentedSubscribing. I have live sites using this functionality, which makes upgrading rather awkward.
Comment #5
linuxgeneral commentedSubscribing with some things to consider while this is topic re-thought. Addressing this before or as DNS support is implemented will minimize upgrade issues while we move to beta.
1. Considering this is an administrative tool, the install script should at least generate a self-signed cert and default to encryption required. The target market seems to dictate that we should -not- address SSL issues as an after-thought.
2. Newly installed sites can have a default validated SSL enabled secure alias by redirecting to https://installed-site-com.example.com with a wildcard cert or https://example.com/installed-site-com with a single or multiple host certs. This is nice value added service to provide to clients who just need secure administrative logins to their Drupal sites.
3. Most of the work may already be done to configure an instance of AEgier as a SSL reverse proxy. I looks like advanced redirect configuration options added to the web clustering feature may be a good place start. This would allow us to have one web head to store and manage installed certificates and DNS configurations. It would also provide a clean way to manage reverse proxy redirects and address the cache issues of SSL enabled sites.
Just some fodder for more discussion.... anyone else think that this bug should qualify as major?
Comment #6
SeanBannister commentedsub
Comment #7
omega8cc commentedWe enabled now redirects in Barracuda and Octopus installs (both are using Nginx web server) for compatibility with existing installs, to not break them on the upgrade, but I added rather long warning to the Redirect checkbox and it is available only per site (global redirect option remains disabled).
The warning includes detailed explanation of the problem, since in our (Nginx based installs) case, the only problem is: Redirect == one way ticket. You would need to manually edit site web server configuration file to disable it. It is permanent when enabled the first time.
Our warning/explanation: "WARNING: it is currently a one way ticket, you can not turn off this redirect after it was enabled. This is why this feature is currently disabled in the official Aegir releases. We enabled it only for compatibility with existing installs, but please do not use it, unless you are sure you know what are you doing. Only when the site has enabled SSL in the Required mode, it will automatically redirect all aliases to the main domain, even without Redirect option enabled. Disabling SSL Required mode will also safely disable redirects."
We have now also by default enabled global SSL proxy available for all sites hosted on the Barracuda/Octopus servers, with forced SSL for all Hostmaster instances. Of course it should be added as a separate vhost using provision, which is simple and should be doable also for Apache, but I didn't want to introduce too many custom changes before it will be discussed as an acceptable solution.
Comment #8
willmoy commentedSub, as kindly suggested by mig5 in #897696: www redirects
Comment #9
adrian commentedso the issue is as follows :
http://img.skitch.com/20100921-bbcc45ynbeq7jen2bic58d8ie6.jpg
These are the vhosts that drive the whole system. The redirect flag is hackish in that it complicates the templates a lot. When it is set on a site, it causes the server aliases to not be generated, and then held over for the conditional inclusion of another template.
So it has the side effect of generating 2 vhosts instead of one. The SSL modes (enabled and required) also generate an additional vhost each. When mode SSL required is triggered, it also generates it's own http redirect instead of the other one.
These all conflict with each other. Even if we did generate all the vhosts, they would conflict with each other and it would become very tricky to know what is what.
These vhosts also need to be replicated for nginx. Omega8cc ?
Comment #10
adrian commentedThings i think we can do to resolve this ..
I think we need to split redirect and aliases, so they are separate fields. I saw a ticket for this before, but i can't find it now.
Another thing i think we should do is use the modrewrite method - http://drupal.org/node/535098#comment-1868320
Instead of a separate redirect vhost, we would simply unfurl the redirects in the main vhost.
so we would have :
Comment #11
adrian commentedAnother interesting action with redirects.
The primary reason to run a site on a different port (say 81) is when you are using something like varnish running on port 80.
The way we have the logic in redirects (and the site goto link) it actually appends the port number to it. So it would try to redirect you to $url:$http_port , which probably wont respond to your request.
Comment #12
adrian commentedI solved this in HEAD.
i rewrote the vhost templates so that they use modrewrite to redirect instead.
this is the most complex our generated configs get now , with both SSL redirect and redirection enabled :
http://gist.github.com/592948
We need to bring the nginx configuration back in line before i can make a release.
omega8cc ?
Comment #13
adrian commentedomega8cc - here's the nginx patch i think we need.
note: the vhost_redirect template is now not needed and can be deleted.
please test and get back to me.
Comment #14
adrian commentedi consider them fixed now. they work fine in all the different combinations.
the code for nginx is pretty much a straight port of the logic, so i just need omega8cc to confirm it generates a valid config file, so we can roll the new release.
Comment #15
omega8cc commentedI tested it with the patch attached below, and any combination of aliases/redirects/ssl modes works as expected. Congrats Adrian! It is fixed also for Nginx. I'm attaching a patch and links to files now required by Nginx configuration instead of proposing merge with my GitHub repo, since it is probably too fragmented now (there is more than a few commits) so patch + files will be easier, I think.
Files now required:
http://github.com/omega8cc/provision/raw/master/http/nginx/fastcgi_param...
http://github.com/omega8cc/provision/raw/master/http/nginx/fastcgi_ssl_p...
Files removed:
http://github.com/omega8cc/provision/raw/master/http/nginx/nginx_include...
http://github.com/omega8cc/provision/raw/master/http/nginx/vhost_redirec...
Comment #16
adrian commentedcommitted.