The redirect functionality was commented out from the site aliases module before the alpha9 release because it was seriously breaking site installs, and needs to be re-thought out to fit in with the new architecture (especially SSL).

CommentFileSizeAuthor
#15 provision.diff.txt12.25 KBomega8cc
#13 nginx_fix_redirect.diff3.71 KBadrian

Comments

daveparrish’s picture

sub

butler360’s picture

Subscribing.

jaybhancock’s picture

Subscribing

DanielJohnston’s picture

Subscribing. I have live sites using this functionality, which makes upgrading rather awkward.

linuxgeneral’s picture

Priority: Normal » Major

Subscribing 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?

SeanBannister’s picture

sub

omega8cc’s picture

We 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.

willmoy’s picture

Sub, as kindly suggested by mig5 in #897696: www redirects

adrian’s picture

so 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 ?

adrian’s picture

Things 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 :

<VirtualHost *:80>
  ServerName www.example.com
  RewriteCond ${HTTP_HOST} example.com [OR]
  RewriteCond ${HTTP_HOST} old.example.com [NC]
  RewriteRule ^/*(.*)$ http://www.example.com/$1 [L,R=301]
</VirtualHost>
adrian’s picture

Another 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.

adrian’s picture

Status: Active » Patch (to be ported)

I 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 ?

adrian’s picture

StatusFileSize
new3.71 KB

omega8cc - 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.

adrian’s picture

i 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.

omega8cc’s picture

Status: Patch (to be ported) » Reviewed & tested by the community
StatusFileSize
new12.25 KB

I 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...

adrian’s picture

Status: Reviewed & tested by the community » Fixed

committed.

Status: Fixed » Closed (fixed)

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

  • Commit 5e87a61 on dev-dns, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x by adrian:
    Comment out the redirect option on the site alias config. #872064
    
    

  • Commit 5e87a61 on dev-dns, dev-log_directory, dev-migrate_aliases, dev-multiserver-install, prod-koumbit, dev-ssl-ip-allocation-refactor, dev-1205458-move_sites_out_of_platforms, 7.x-3.x, dev-588728-views-integration, dev-1403208-new_roles, dev-helmo-3.x by adrian:
    Comment out the redirect option on the site alias config. #872064