Bug 1490993 - Redirect fun with lists
Summary: Redirect fun with lists
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: GlusterFS
Classification: Community
Component: website
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Amye Scavarda
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-12 17:02 UTC by Amye Scavarda
Modified: 2017-09-20 15:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-20 15:52:26 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)
WPEngine UI screenshot (21.61 KB, image/png)
2017-09-12 17:35 UTC, Karsten Wade
no flags Details

Description Amye Scavarda 2017-09-12 17:02:58 UTC
Description of problem:
Things that may have previously gotten directed to pipermail are now being eaten by the redirect.

Example: 
http://www.gluster.org/pipermail/gluster-users/2015-March/020995.html

What they actually wanted: 
http://lists.gluster.org/pipermail/gluster-users/2015-March/020995.html 

Expected results:
We'll need to figure out the proper regex to redirect the lists domain again.

Comment 1 Karsten Wade 2017-09-12 17:29:18 UTC
Looking at the WP UI for this, the source URL supports regexp but I'm not sure how the target URL gets the matching string fed in.

So the source regexp could be (at least to try):

*gluster.org/pipermail.*

This way if www or no sub-domain is used, it matches.

For "Position", aiui Top means run this rule first, Bottom means run this rule after all others. I'd say Bottom is safest to try first so it doesn't steal blog posts & redirect. i.e., the risk is if there is ever a page or post that is www.gluster.org/pipermail it will get redirected/rewritten.

Looks like this is the plugin being used:

https://wordpress.org/plugins/redirection/

Comment 2 Karsten Wade 2017-09-12 17:32:31 UTC
One fix for the source URL:

.*gluster.org/pipermail.*

(Reading through https://wpengine.com/support/regex/ )

Comment 3 Karsten Wade 2017-09-12 17:35:51 UTC
Created attachment 1324980 [details]
WPEngine UI screenshot

Comment 4 Karsten Wade 2017-09-12 17:41:09 UTC
The WPEngine how to recommends this pattern:

Name: Redirect catch all
Domain: www.domain.com
Source: ^/thisiswhere/myfileswere/(.+)
Destination: /thisiswhere/myfilesmovedto/$1
Redirect type: 301 Permanent

Our UI is a bit different (ref attached PNG), we need to fill out:

Source URL:
Regex [./]
Title:
Match: [URL only]   <== anything else interesting under that menu?
When matched: [Redirect to URL] w/ 301    <== seems like a good choice
Target URL:
Group: [Modified Posts]   <== anything else interesting under that menu?
Position: Bottom might be safest so we're not overwriting WP rules

So I think "Source URL" would be a regex of:

.*gluster.org/pipermail(.+)

Target URL:

lists.gluster.org/pipermail/$1

This should grab whatever follows /pipermail/ at any subdomain (or no subdomain so plain gluster.org/pipermail/) and redirect that follow stuff to lists.gluster.org/pipermail/.

Comment 5 Amye Scavarda 2017-09-12 17:54:33 UTC
This doesn't pick up any hits, not sure why. 
I'm using "https://www.gluster.org/pipermail/gluster-devel/2017-August/thread.html" as a test URL, so let's keep poking at it.

Comment 6 Karsten Wade 2017-09-12 18:00:28 UTC
New ideas since #c4 didn't work:

Source URL:

.*gluster.org/pipermail/(.+)

Target URL:

lists.gluster.org/pipermail/$1

... or ...

Source URL:

.*gluster.org/pipermail/(.*)

Target URL:

lists.gluster.org/pipermail/$1

Comment 7 Amye Scavarda 2017-09-12 20:08:54 UTC
Alright, so this is now even more broken than we had it before.
I'll go ahead and remove the redirects that were put in place, and will await further instruction on this. 

Timeline for fix: sometime this week if possible? 

I'm not sure how this worked in the first place, and it may be that the WP install is trying to eat all the things.

Comment 8 Karsten Wade 2017-09-12 20:32:49 UTC
I'll bring the discussion back to Michael, we'll figure out a plan & timeline, and return with those to this ticket. Once we have a plan in place here, we'll reassign to you for ACK on the plan and reassignment back to complete to close.

Comment 9 Karsten Wade 2017-09-12 20:35:35 UTC
One more point -- we should also make sure that www/mailman(.*) also redirects to lists.gluster.org/mailman$1.

Comment 10 M. Scherer 2017-09-13 00:32:43 UTC
You shouldn't place the domain in source URL, since the domain is not part of the URL. 

Name: Redirect catch all
Domain: www.gluster.org
Source: ^/pipermail/(.*)
Destination: http://lists.gluster.org/pipermail/$1
Redirect type: 301 Permanent


That's the equivalent of the existing setup on Apache side:

https://github.com/gluster/gluster.org_ansible_configuration/blob/master/roles/httpd_www/templates/redirect_lists.conf

Comment 11 Karsten Wade 2017-09-14 15:17:06 UTC
OK, that helped a lot -- I didn't prepend the rule with ^ and that fixed this case so the rewrite/redirect is now working for hardlinked mailing list links.

Comment 12 Karsten Wade 2017-09-14 15:40:16 UTC
Next question is, what is the best/proper way to handle these rewrites?

* DNS
* Apache via wordpress instance?
* WPengine's redirect interface?

Comment 13 M. Scherer 2017-09-14 15:48:00 UTC
We can't do DNS for that. Apache via wordpress mean on the wordpress level, it would work but that's consuming ressources. I would go WPengine redirect interface, that's done on nginx so faster, so better latency and less risk of breakage.

Comment 14 Amye Scavarda 2017-09-14 16:10:50 UTC
Here's what I'll do: 
It seems to be working at the moment, so let me see if it continues to work, and what it does to our traffic to have the redirect through the direct WordPress install. 
I'll give it until EOD today and compare against what we had previously and see if it makes a big difference. 
If it does, I'll move it to the nginx interface through WPEngine.

Comment 16 Amye Scavarda 2017-09-20 15:52:26 UTC
WPEngine gave me a note on the internal portal that we were likely to go over our traffic, so I've moved this to their nginx redirect rules as of 8:50am Pacific time.


Note You need to log in before you can comment on or make changes to this bug.