Monday, March 22, 2010

Honey I moved the Webserver


That's nice dear Agata said briefly and then returned back to reading her latest novel

I refer to the momentus event (at least for me) as I completed the move of the static component of our website onto the new Intel server. I thought I'd document and explain the process

  • First, build the DMZ server which is based on Microsoft Windows 2008 R2 Enterprise (with GUI)

  • Choose the most appropriate Virtualisation software for my needs, environment and budget: Eventually VMware

  • Build a container OS for the WebServer inside a VMware virtual machine
The process went quite well initially. It was using Microsoft Windows 2008 R2 Standard Edition. I installed some usual components, updated all fixes and then found I don't have a valid license key! So ....
  • Rebuild the OS inside VMware using Microsoft Windows Web Server 2008 R2
Yes, I have bought that product and ironically based on previous woes I will not be using IIS but rather Apache
  • Installed Blackdot Apache 64 webserver.
I can stil barely believe that there is no offical Apache 64 build for Windows. Who is responsible for this travesty? Credit then to Jorge Schrauwen for his continued efforts in compiling it. His latest release 64 bit Windows release is now at 2.2.15
  • Create a separate VMware drive to hold entire static component of website.
Initially I tried putting the drive on the underlying physical OS, then sharing it into the VM using a command like this

net use x: \\192.166.5.44\staging

and using httpd.conf lines like

<Directory "X:/static">
Options FollowSymLinks
MaxConnPerIP 2
AllowOverride None
Order allow,deny
Allow from all
deny from long_list_of_tossers.com
</Directory>



Now bizzarely httpd.exe would NOT start as a Windows service using this configuration. However it would start from the command line with commands like

httpd -k start -e debug

So I tried using native paths. But which one to use? Forward or backslashes? I tied lots of combinations ...e.g


<Directory "//192.166.5.44/staging/static">
Options FollowSymLinks
MaxConnPerIP 2
AllowOverride None
Order allow,deny
Allow from all
deny from long_list_of_tossers.com
</Directory>


Alias /static/ "/192.166.5.44/staging/static/"

And, nothing worked. So admitting defeat I copied the 300GB static directoriesregion into a VMware virtual X: drive local to Webserver

  • Install Python
Google provides a Python script which I run daily. This produces sitemap files which are used by Google to hint at what URLs to track. Check Google Webmaster tools of course
  • Install DokuWiki software
My wiki contains an ever growing structure of good AIX, SAN, SAP, Storage and other IT disciplines. Dokuwiki needs to be installed as well as 64 bit PHP for windows.

Of course the beauty of Dokuwiki is that no backend database is required making it robust, and easily transferable. (Did you see the amazing companion Dokuwiki on a stick? )
  • Allow access thru firewall

In the firewall of the VMware guest OS (obviously not the host physcial OS) add httpd.exe access thru the Windows firewall

  • Enable localhost resolution in C:\windows\system32\drivers\etc\hosts
There is a commented explanation saying that it does not need to be enabled. Unfortunately my Firefox browser disagreed.

  • Test access from localhost on this local VMware system
  • Test access from local subnet i.e. 192.166.5.x in our case
  • Test access from adjacent subnet i.e. 192.142.7.x in our case
  • Install DynDNS client on this VM and disable on existing webserver
Multiple routers in our network can do this from an option in their setup menu. However I think it's more logical for maben.homeip.net to be set into dns from the webserver PC right?
  • Change the VDSL router rules to point to new server on ports
Until this point all inbound web traffic is diverted to the old Webserver. Here we now change the VDSL router to tell it to forward HTTP ports 80 et al to the new internal webserver address.


  • Test access from Internet and back out if it does not work
With the router changed we can test the website using an internet address. From experience it's also good to check it from a non home network, so with iPhone in hand, leave apartment and run as far as is needed to gain legitimate free Wi-Fi access. Lausanne, our home town has free Wi-Fi access, (NB:We are responsible adults in Switzerland, free Wi-Fi is perfectly legal) I had to run about 1Km!

  • Install Softperfect Bandwidth Manager


Whilst bandwidth limiting of the Webserver won't stop it being vulnerable to DOS attacks it might at least prevent uncontrolled uploads from trashing my Internet download connection.

I tried to use Netbalancer to limit utbound http traffic. However the product is not yet 64 Windows 2008 server compatible. So it is back to SoftPerfect bandwidth manager
  • Shutdown the VM and do a file copy backup
Well, always have a backup.
  • Copy Scheduled Tasks
A variety of tasks need to be xml exported from the existing Webserver and then xml imported on the new one. After importing each task change the domain/userid and password for each task. For security paranoia, all passwords are changed!
  • Restart and test Google maps
After manually running tasks to refresh index pages, refresh Google Site Maps, Check with Google webmaster tools that all is still working. In my case I need to revalidate the website but logging onto webmaster tools and cut pasting the verification line into the toplevel index.html file.

  • Check backup strategy
Make a windows network share of the total static content with a random password. From the master server (which is 2 firewalls away) setup a Syncback pull schedule to retreive using that password the static content daily and store it locally.

For security rules the entire DMZ server and all VM's inside it e.g. this Webserver can't open any connections to more secure parts of the the home network. This might sound obvious, i.e. the only way to copy content is to pull it from a more trusted part of the network, you can't push it.



Benefits of New Config
Predictability: Use of VMware allows one to allocate as much processor and memory as required to the Webserver instance. Previously when the Webserver ran on a physical machine it competed with all other running tasks resulting in varied performance.

Security: This is an isolated VMachine. It's Network card is not shared with any other Virtual machine. All passwords are random. This server can't push its data to anybody. If compromised you gain control of this Webserver only.

Backup: I can snaphot the OS using VMware, or (with VM partition down) do a file copy backup of OS partition .vmdk file is about 5 minutes

Portability: I can duplicate the VM configuration, make a few changes and experiment in a parallel VM with better settings, then when tested flip to that new VM configuration

Future
Create a VM based on SUSE SLES (my favourite enterprise Linux) and experiment with hosting the website under Linux based Apache 64. Path lengths are supposed to be shorter, and support for a plethora of useful security modules commonplace (unlike the Windows 64 bit version)


Links
Apache 64 under Windows. Only from Blackdot