
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
- Rebuild the OS inside VMware using Microsoft Windows Web Server 2008 R2
- Installed Blackdot Apache 64 webserver.
- Create a separate VMware drive to hold entire static component of website.
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
- Install DokuWiki software
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
- 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
- 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
- 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
- Copy Scheduled Tasks
- Restart and test Google maps
- Check backup strategy
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