On Thu, Aug 12, 2010 at 10:37, Mike Soultanian <msoul...@csulb.edu> wrote:
>>> server - the problem is that it can't be done for another couple weeks >>> (IT >>> department won't do it right away as it involves restarting all of the >>> servers and a whole change management process). >> >> Remind me to not ever set up any kind of change management processes >> like that. Sounds like IT is "top heavy". > > Heh - yeah, kinda frustrating. The guy that is doing the Apache config is > going on vacation, so we have to wait until he comes back (a couple weeks) > before the change can be made. No backup staff ... ouch. > From what they've told me, they restart all 32 instances served by their 3 > clustered servers, so the downtime is minimal, but this is a production > environment so taking down something like the campus web server needs to go > through their Change Management process. It's actually not that bad (except > in this particular situation) because they send out a notification to the > involved parties (the entire campus, in this case) so that everyone knows > what's happening and people don't freak out when something isn't working. If they have load balancing, the restarts can be made transparent. Just disable the server from the load balancer, wait the prescribed time (usually just a few seconds), reboot the machine or restart the service, then enable the server back into the load balancer. Just don't do this during the peak loads when total capacity is in use. Otherwise, they need a nightly restart window. > That machine isn't running php and I really don't want to figure out how to > install it and get everything configured. Believe me, I could, but time's > an issue and this needs to work today (Thursday). I already have Apache > running and it's stable and I just need this setup to work for another two > weeks without any lost sleep. That's why I figured the easiest thing to do > is just forward everyone over to the main server until we're able to make > the VirtualHost change on the main server and then make the final update to > the (www.)cota.csulb.edu DNS entry. So what is the plan to get people out of http://www.csulb.edu/colleges/cota later on? Make it be a redirect back to http://cota.csulb.edu/ once it is running as a VirtualHost on the central server? > So I was playing around and came up with this: > > TEST DNS: > > <VirtualHost *:80> > ServerName wwwtest.cota.csulb.edu > RewriteEngine on > RewriteRule (.*) http://www.csulb.edu/colleges/cota/ [R=permanent] > </VirtualHost> > > > REAL DNS (goes live sometime on Thursday): > > <VirtualHost *:80> > ServerName cota.csulb.edu > RewriteEngine on > RewriteRule (.*) http://www.csulb.edu/colleges/cota/ [R=permanent] > </VirtualHost> > > <VirtualHost *:80> > ServerName www.cota.csulb.edu > RewriteEngine on > RewriteRule (.*) http://www.csulb.edu/colleges/cota/ [R=permanent] > </VirtualHost> > > The first one is just a test to make sure it was working correctly (that DNS > will be removed later today). In a couple hours (www.)cota.csulb.edu should > be updated and the second two will go into effect. I had initially done it > with the Redirect directive, but I found that RewriteRule saves all the > arguments after the ? (but drops the filename) which is really helpful > (they're the same for both the php and ColdFusion versions of our software). Why permanent? If someone bookmarks the permanent, it will save the redirect target. Since you are later going to change back, you should want bookmarks to save the temp URL. That (temp) is supposed to be the default. Another option is to proxy the requests. Then no one sees the alternate temporary URL. The downside is the traffic gets heavier. > Is there any way to combine the last two entries into one so that the > VirtualHost will respond to both www.cota.csulb.edu and cota.csulb.edu? <VirtualHost *:80> ServerName cota.csulb.edu ServerAlias www.cota.csuib.edu ... -- sHiFt HaPpEnS! --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
