Vanity Redirect

These redirects are quite easy to do, but thought I would cover the process I usually take in implementing them. I doubt very seriously that there will be any redirects submitted for the web sites, so will only cover those under the new CWA architecture. If I mention anything that you already know, my apologies but I figured I would cover it as completely as I could in this email.


  1. The servers that you will be working on are:


  1. The redirect file you will be editing is located on the NFS share, and can be found by navigating to ‘/media/engine_etc/apache’. The file’s name is ‘’. I also keep all redirects in the file in alphanumeric order, as currently there are over 1,300 redirects in the file and keeping them alphabetized makes for easy additions and changes as they occur.


  1. My usual habit is to open 5 SSH sessions… one to each one of thegescpresX servers and then another one to gescpres1, which is where I edit the redirect file. How you want to work it yourself is personal preference, but this allows me to easily edit the redirect file in one window, and then perform the Apache configuration reloads in the others (with cut/paste).


  1. The CO will usually have in the “Order Description” area one or more redirects listed along the lines of:
    1. home/httpd/
    1. home/httpd/
    1. home/httpd/


The first portion is the redirect path (and not really the true path, as the “html/” directory is left out, but at least it’s clear that what is wanted<somethingto be redirected somewhere), and the second is the URL that it is to be redirect to. If you have any questions on them ask Gretchen or Scott for more details (Scott usually gives both portions in URL form and I’ve had Scott accidentally reverse the two and it wasn’t until I had emailed him that I didn’t take care of redirects on 3rd-party servers that I realized, and he confirmed, that he had the URLs reversed).


  1. First, create a local backup of the redirect file so that the copy has the extension “.YYYYMMDD”. You can use the following to do this easily for you (as root):


# cd /media/engine_etc/apache

# cp `date +"%Y%m%d"`


Please follow this format if you would, as this allows for easily seeing the dates of each backup as well as keeping the archive files listed alphabetically and chronologically ordered in the directory listings. If you like you could even just manually append the extension to the archive file, just so long as the filename has a period and the 201103<DD> date appended to it. I usually only keep approximately three archive backups on hand, but sometimes don’t purge older backups until I get around six or more and want to reduce clutter. Thanks!


  1. Once you have the file backed up, edit it with vi/vim. You will notice that each redirect starts with the ‘RewriteRule’ directive. This is usually followed by the regular expression “^/” and a string, which means to implement the rewrite for any URL that begins with the forward slash followed by that string. All redirects also end with a space and the flags ‘[R,L,NS]’ after the URL being redirected to (which will redirect to the fully-qualified URL, specifies it is the last rule in the rule set to process, and to not process any subrequests, respectively).


  1. Therefore, using the above examples, the redirects (entered alphabetically in the file) would appear as:
    1. RewriteRule ^/sportsdaypole/ [R,L,NS]
    1. RewriteRule ^/bedford [R,L,NS]
    2. RewriteRule ^/carrollton [R,L,NS]


NOTE: One thing to watch out for is if you have redirects, existing or new, that contain the same subset of characters as other redirects. Again, using the example “c” above, if there was a redirect in place for “^/carroll” that already exists:


RewriteRule ^/carroll[R,L,NS]


When adding the redirect for “^/carrollton”, if the redirect for “^/carroll” was not changed the new redirect wouldn’t be processed (as the redirect would have anything beginning with “carroll” automatically redirect and no more rule sets would be processed.


To get around this, you would need to add the regular expression “$” (signifies the EOL) to the end of “carroll” in that redirect, which would then specify that the rule is to process the “carroll” redirect only if the line begins and ends with “carroll”. The edited set of redirects would then be listed as:


RewriteRule ^/carroll$ [R,L,NS]

RewriteRule ^/carrollton [R,L,NS]


And both redirects will then be processed correctly.


  1. Save the ‘’ redirect file and proceed with reloading the Apache configuration on each of thetdmzwebappX servers (which include that file as part of the configuration, and which is why it is located on an NFS share common to them all).


  1. To reload the Apache configuration on each of the servers, use one of the following commands, whichever you prefer (as root):


# /etc/init.d/httpd reload


# service httpd reload


The important thing to keep in mind is to not reload the configuration on all four servers consecutively too quickly. Give yourself 5 minutes or so between the reloads as this will prevent too many disruptions from occurring at the same time. As well, if you have a failed reload on the first server being acted upon, you know you have an error in your redirect file that needs to be corrected before attempting further reloads. Performing a reload instead of a restart is less disrupting to the visitors hitting that particular web server.


  1. Once you have the reloads completed successfully you should be ready to test your redirects to make sure they are operating as they should by hitting those URLs in your browser. If you find that “” redirects properly to “”, “” properly redirects to “”, “” properly redirects to “” and “” properly redirects to “” then you are good to close out the Change Order.


NOTE: It’s important to not only test the redirects that were a part of the change, but also any redirects that were edited if you needed to make changes to satisfy the rule set for the redirects, such as the “carroll” and “carrollton” examples used above.


BTW, all these redirect examples were taken from past COs or the redirect file, so they are actual redirects you will see in the file when reviewing it. Likewise, other than perhaps correcting one or more redirects by adding the regular expression “$” to the end of string names to make the redirect listed in the CO work as it should, that is the only liberty I take when processing the CO. If the CO states for a redirect to end with “/”, then that’s what I put in. If the CO states for a redirect to end with the string name given, then that’s what I put in (unless it needs the “$” character at the end of the string name to make it work with other redirects listed).