Posted on July 2nd, 2009 No comments
I just finished re-reading this post from a few hours ago and realized it has way too much detail and anecdotal information that most people aren’t going to want or need. What you need to know is the safest and easiest way to configure your staging server during a website redesign.
The goals are:
- Leave current website untouched while creating a new site at a staging URL
- Has to be easy to configure, reliable and repeatable at different ISPs
- Should require the least amount of effort & special skills to set up
- Should require the least amount of fiddling with your application code
- Should require the least amount of tweaking right at launch time
If you want to set up a staging server the easy way, here are my recommendations:
- Create a new hosting account based on the name of the main domain. DNS isn’t pointed to the staging server yet, but don’t worry about that. Chances are the new site will be avaliable at http://some.ip.ad.dress/~account/ but that’s ugly and not user-friendly.
- Add a parked domain to facilitate previewing, testing and approvals. Take advantage of the fact that a parked domain name can resolve to the staging server IP before the main domain is pointed. In essence, the parked domain is the staging domain and resolves to the staging server’s IP during and after development.
- Edit your local hosts file periodically to test the site at the main URL without having to change DNS entries at your provider.
- At launch, update the DNS for the main domain and point it to the IP of the staging server. There should be nothing more to do or configure differently because the web server was already programmed to serve the main domain in step 1.
Posted on July 1st, 2009 3 comments
So you decided to upgrade your website, redesign your site, or use the services of a new web guy. Since your existing website is still live on the internet, you want to keep your existing website live and untouched while you develop a new one on a staging server.
Any good web development company or website programmer should be able to explain how this process works. Perhaps they linked you to this post. Then again, this is not something that the average person under normal circumstances needs to do. Anyway…
In a nushell you have three options:
1. You can preview your domain at the new website’s IP address.
- Your web guy might be able to develop your new website at a static IP. If so, you can just browse that.
- That theory worked for the last several years, when you could devote a dedicated IP address to any site you wanted (most ISPs charge a buck or two a month for a static IP).
- Now that the net has run out of IP4-class IPs, nowadays you have to prove you need a static IP address (e.g. an e-commerce website needs a static IP for SSL Certificate installation) before they’ll just give you one.
- In short, your website may not be perfectly programmed to run at http://some.ip.add.ress/~newaccount/ although many do. For approvals and previewing purposes, emailing URLs around with numbers and funky characters in them tends to scare people. In short, in addition to being a little confusing, this may only be a viable option in certain circumstances.
2. You can register a domain name other than your main domain name, and point that domain name to your staging box as a parked domain.
- Parked domains are often called aliases, although aliases, or more accurately CNAME records are not exactly the same thing, which adds to the confusion. The shortest way to explain it is that if domainB.com is parked to domainA.com then typing domainB.com in a browser will bring up domainA.com. You can take advantage of how domain parking works during a redesign.
- For example, Salient Digital, Inc. has www.salientdigital.com for it’s main domain, so I register salientdigital.net. I create a hosting account on a new server on a different IP and create the account as salientdigital.com, but then add the parked domain, salientdigital.net.
- This way, I’m developing the new web application as and on salientdigital.com, according to the new server’s local dns. Nobody knows about salientdigital.net, including Google and the other Search Engines.
- For safe measure you can place a robots.txt in the root level with no index no follow, or even put an .htpasswd on the htdocs folder for added security.
- Once salientdigital.net is done and approved as the new website, I can point the DNS for salientdigital.net to the new (staging server’s) IP address… and no normal ‘launch’ is necessary.
3. You can hack your local DNS.
- This is the fastest and easiest way, but is the most technical as well.
- All operating systems (Mac OS X, Windows & Unix/Linux) have a “local hosts file”.
- Under Windows, this file is located in C:\WINDOWS\System32\drivers\etc\hosts.
- On Mac OS X and Unix systems, this file is located in /etc/hosts.
- Even though there is no .txt extension on this file, you can coerce your box to open it.
- Google how to edit hosts file for troubleshooting tips if you can’t find it or edit it.
- This solution overcomes the non-viability of option 1.
- How does it work? Why would I want to edit my hosts file?
- Your web developer will be developing your new site at some IP address.
- The server where this new account is set up knows how to serve it up, but you have to ask for it specifically. That is, if you make a request for salientdigital.com specifically to the ip address of the new/staging server, the server will know how to respond. The trick is requesting the old domain from the new server. To do this, we can hack our local hosts file.
- So the process goes like this:
- You type in http://salientdigital.com in your browser.
- The first place your system looks for where (the IP address of the Web Server) where that site might be located is the local system’s hosts file.
- If the server IP address is not in your hosts file, your system asks the DNS network for the location.
- If your local network doesn’t have a DNS entry for the domain you’re looking for, your ISP asks the DNS network on the internet at large for the server’s IP.
- So, the whole point of DNS is to map Domain Names to Server IPs.
- Adding an entry to your local hosts file is just instructing your computer exactly where a site is located so that it doesn’t need to check the Internet DNS system for the IP – you’ve listed it locally.
- Now, Ask your web guy to give you the IP address where your new site is being developed.
- Even if the IP is a shared IP address with an account name on the end of it, that doesn’t matter. It’s just how DNS works.
- Open your hosts file in a text editor, scroll to the end and press return at least once or twice, and then add the IP address, then some spaces or tabs, then the website domain name you are re-developing.
- You would enter something like
- where the first part is the NEW SERVER’s IP address, and the second part is the CURRENT/MAIN domain name.
- Save, and open a browser.
- Now, what happens next is magical:
- Browse to bbb.com and your new site will appear. You have to have the staging server set up as described above, using the main domain (bbb.com) for the account. (Adding a different parked domain as in Option 2 just makes it easier to pass around via email for approvals.)
- On your computer, and your computer computer only, and nowhere else on the internet, that hosts file tells your computer to look at the new server for the salientdigital.com home page. And the new server (at the new IP you put in your hosts file) returns it to you.
- 99.999% of the time, www.salientdigital.com will still resolve to the current, live, old website, while salientdigital.com (without the www.) shows the new site.
Once the new site is approved, the DNS record has been updated to the new IP (wait up to 48-72 hours for it to work worldwide… this is commonly called ‘DNS Propogation’ but it just means wait for a while)… you can go back into your hosts file and delete the line you added during development.
One thing to bear in mind is that you may need to tweak your web server settings, your ISP may not allow you to park domains before DNS is pointed, or your network administrator or ISP may be using a proxy server. Any of these can override your experience, so your mileage may vary. I’ve asked some ISP technicians about this before and realized I knew more about than they did. DNS can be screwy, so test from multiple browsers, different computers, clear your cache, when in doubt: reboot, Google it, backup your system first, etc. … All the normal precautions still apply.