I just spent a couple of hours troubleshooting a stupid problem where I got access errors when trying to backup a VM from a newly-installed Veeam server. Searching forums for answers I got red herrings all over the place, from opening up the Windows Firewall for RPC traffic, to removing Veeam VSS files from various folders and shares, to purging keys in the Registry.
It turned out none of that was the cause of the problem, but instead I had re-discovered an issue I’ve seen before: For some reason, Veeam sometimes won’t work properly with UPN logons (username@domain) but instead requires Down-Level logon names (DOMAIN\username). Changing that fixed the problem.
Using keepalived in combination with a couple of HAProxy instances is a convenient yet powerful way of ensuring high availability of services.
Up until now, I’ve considered it enough to monitor the VMs where the services run, and the general availability of a HAProxy listener on the common address. The drawback is that it’s hard to see if the site is served by the intended master or the backup load balancer at a glance. The image to the right shows the intended – and at the end of this article achieved – result, with the color of the lines between nodes giving contextual information about the state of the running services.
Monitoring state changes could naïvely be achieved by continuously tailing the syslog and searching for “entered the MASTER state”. This would be a pretty resource-intensive way of solving the issue, though. A less amateurish way to go about it would to use keepalived’s built-in capability of running scripts on state changes, but there are a number of situations in which you can’t be sure that the scripts are able to run, so that’s not really what we want to do either.
This is really a how-to for my personal hardware setup in case I want to try other distributions or operating systems on my gaming computer down the line. However it may be helpful to anyone who would like to play games or run flight sims in a Linux environment. What? Stranger things have happened!
Objective Create a secure high availability (HA) load balancing service spreading user load across two pairs of two servers, providing two different sets of services:
One service requires SSL passthrough, while the other is a websockets connection over SSL, where the use of a proxy demands SSL termination. Securing communications with the web backend for the latter is done by routing the traffic via an OpenVPN tunnel.
The software I’ve chosen for this, is HAProxy 1.5 on FreeBSD 10.1-Release, running in a VSphere 5.5 environment.
The documentation for OpenVPN is pretty good, but I found a detail that may cause some confusion in a Windows environment, so I thought I’d address it here:
What do you do if you need to run OpenVPN but still want the Windows Firewall to work on your Windows server?
The background for this issue is how Windows decides what profile to use for a specific network: It reads the gateway address. The TAP interface for OpenVPN doesn’t automatically receive a gateway, so the network profile for it will be “Unknown network”, and so it won’t allow the necessary traffic for the OpenVPN connection to be properly established.
So what do you do?
First, open up a port in your firewall to allow for the initial handshake to be made between the client and the server. By default, this is UDP port 1194. Then we need to take a step back. We don’t want to open an uncontrolled pipe from the VPN client to the server, which is exactly what happens if you turn off the firewall for the VPN TAP device.
Instead, we’ll do two things:
1) Give the OpenVPN TAP device a gateway. In the server configuration for OpenVPN, you assign a subnet to be used by OpenVPN. The server will be [subnet].1. The gateway will be [subnet].2.
2) Some people claim that the above doesn’t always work unless you set the status of the TAP device to “always connected”, so let’s do that.
You now have control over data in the VPN tunnel too, using Windows firewall, meaning that you can stop unwanted traffic within the tunnel easily.
I found this old CD with Tomb Raider on it – you know, the old 3D puzzle/maze/action game from 1996 or something?
I don’t know how many hours I spent on it, and when I bought myself a 3Dfx Voodoo graphics accelerator, there was actually a patch to make this game use that lovely piece of hardware for real 640×480 action. Back then, it was so cool, I really don’t know what to compare it to.
But I digress. Okay, so I found this CD. Now what? I googled around a bit and found Tomb Raider Chronicles, who seem to have dedicated a lot of time to get these old games running on modern hardware. Unfortunately, they hadn’t done anything with TR1 since about 2007, so I was afraid things wouldn’t work really flawlessly anyway. And sure enough, their Advanced Installer software did it’s magic, but unfortunately the magic fizzled in the end. The game got installed, it seemed to start, but crashed right back to the desktop.
Now, I was determined to get things going, though, so I spent some more time with google and found a howto, using another piece of code on Tomb Raider Forums. It’s meant to solve the problem in Vista, but obviously it works just as well for XP SP3.
User Gidierre pointed me in the right way, to use SSDH in place of MSCDEX – actually I don’t even know if that’s required yet it seems to need to be done this way to work. However, user Chug a Bug gave me the required tips that made the game start:
1) Download and install VDMsound 2.10. Reboot.
2) Download and install the Advanced TR Installer (TR1setup.exe). Choose dgVoodoo 1.40 as the version. Do not choose the option to create an desktop shortcut.
3) Download ssdh.zip. Unzip the files.
4) Drag and drop ssdh.exe to C:\Tombraid and ssdh.dll to C:\windows\system32
5) Drag and drop glide2x.dll from C:\Tombraid to C:\windows\system32
6) Copy (not move) vddloader.dll from c:\program files\vdmsound to c:\windows\system32 (so theres a copy in both folders)
7) Open dgVoodooSetup if you havn’t opened it already (C:\tombraid\dgVoodooSetup > click it) – on the right hand side click the “search” button – point it towards c:\windows\system32\glide2x.dll. Buttons are now no longer greyed out? Good, you’ve found it. Click the “DOS” platform > click the “VESA” tab> tick “Use built in VESA support”. Click “ok”.
8) Make a batch file in the folder C:\Tombraid –
And I can tell you that the game has aged. No doubt about that. But still: I’m actually re-living Tomb Raider 1 in a full 1920×1080 resolution in 2010. That’s pretty amazing if you ask me.
Respect to all the guys who were involved in making this possible!