One of the production sites I manage has a pretty straightforward setup. Your basic firewall, some 1-to-1 NAT routing and a pair of Web/App servers behind it. OK, there are some other boxes behind the firewall as well, but they’re not really germane so I’ll just wave my hands and gloss over that aspect.
Simplified, it looks like this:
I have two external IPs (y.y.y.2 and 3) each going to a different web server. The firewall gets each to the appropriate internal web server over port 80 to Linux and SSL port 443 for the Windows server.
The Linux web server hosts a pile of WordPress and Joomla sites. It also runs VMware Server and hosts a few small “utility” servers.
The Windows server hosts a .NET application with a separate SQL Server back end.
My goal is display a maintenance page when I’m doing maintenance or rebooting either the Windows server or the SQL Server behind it.
I have a few options, but also some wrinkles to ponder. I figure that right before I start maintenance I’ll pop onto the firewall and redirect all the y.y.y.3 traffic somewhere else. When done I then redirect it all back. That part seems easy enough.
Should I send it the traffic the Linux / Apache server? Well, that server doesn’t have a “root” site. Everything on that box is hosted via virtual hosts. That may or may not be an issue. Obviously path names wouldn’t match up from the site on the Windows server to the Linux/Apache server. I thought maybe I could just set a 404 page on the Linux server to give my maintenance message – but would that hose up 404s on all the sites that server currently hosts? Or is that all separate between Apache virtual hosts?
Or maybe I could just build a little Linux VM client with a 404 to do the same thing?
But wait, I don’t really want to have to install my SSL cert on a standby server. If I redirect port 443 to port 80 is the client browser going to holler?
And hey, am I even on the right track with how to approach this? Buying a bunch of hardware isn’t the answer.
I’ve been mulling this over for a few days and have about got myself into analysis paralysis so now I’m opening it up for more thoughts and insight. What would you do?
Possibly Related posts:
January 17th, 2009 
Tags: 
There are plenty of folks more versed in networking than I am but I’ll make a suggestion or so since I enjoyed reading some of the content on your site, and I’ve been the victim of my own analysis paralysis too.
I bet there’s a good chance the only pages linking to your SSL enabled pages are from your own sites. Maybe, maybe not, you can use a backlink checker to see. If that’s the case, you don’t need to worry about SSL when you’re doing your maintenance.
You mentioned hosing your 404 pages with the temporary one. Why is that important to you? Most users generally don’t care what a 404 page looks like, and in your case, “down for maintenance” is as good to see as any 404. If your users don’t care, then it’s something you might worry less about. If they do, then that’s a different story!
Hi Steven,
Unfortunately, we have a few partners that also link into the SSL side of things. Setting that aside for the moment, however, why wouldn’t I need to worry about SSL if that were the case?
Wouldn’t the browser holler about getting a 301 redirect from an SSL url to a non-SSL? Or is that the part that I’m overthinking?
I really just need to setup some tests on this stuff!
Thanks for the thoughts and kind words
Hi Chris, I’m pretty sure the browser will throw a warning for redirecting from SSL to not. But it’s really about what the real cost is, right?
Someone might ask themselves how many users would see the warning in the amount of time that the site is going to be under maintenance. And out of those folks, how many will think your site is less credible after seeing the redirect warning and a maintenance page?
If that number is low enough for you, then it’s not something to worry about. If it isn’t, then what’s the cost of fixing that vs. the users you might lose?
There might even be a case where it’s cheaper and easier to socially engineer the problem and email your site stakeholders about the downtime. Lot’s of ways to scale back the problem.
Good luck and nice chatting w/ you!