For this, you can use the chntpw utility.

First of all, mount the Windows partition.

Then crack it open with chntpw’s registry editor, and remove the entries.

# chntpw -e WINDOWS/system32/config/system
chntpw version 0.99.6 080526 (sixtyfour), (c) Petter N Hagen
Hive  name (from header): 
ROOT KEY at offset: 0x001020 * Subkey indexing type is: 686c 
Page at 0x54f000 is not 'hbin', assuming file contains garbage at end
File size 5767168 [580000] bytes, containing 1254 pages (+ 1 headerpage)
Used for data: 108658/5500560 blocks/bytes, unused: 1836/21680 blocks/bytes.

Simple registry editor. ? for help.

> cd MountedDevices

You can now show the mounted devices table. This one is populated with a bunch of stuff:

\MountedDevices> ls
Node has 0 subkeys and 8 values
  size     type            value name             [value if type DWORD]
    12  REG_BINARY        <\??\Volume{a04045a6-480a-11df-8146-806d6172696f}>
    12  REG_BINARY        <\??\Volume{a04045a7-480a-11df-8146-806d6172696f}>
   238  REG_BINARY        <\??\Volume{a04045a8-480a-11df-8146-806d6172696f}>
   164  REG_BINARY        <\??\Volume{a04045a9-480a-11df-8146-806d6172696f}>
    12  REG_BINARY        <\DosDevices\C:>
    12  REG_BINARY        <\DosDevices\D:>
   164  REG_BINARY        <\DosDevices\A:>
   238  REG_BINARY        <\DosDevices\E:>

Removing it is as simple as the ‘delallv’ command.

\MountedDevices> delallv

\MountedDevices> q

Hives that have changed:
 #  Name
 0  
Write hive files? (y/n) [n] : y
 0   - OK

And then it’s done. You can unmount the partition, and boot Windows again.

I’ve now got all the RetroLAN PCs running out of a copy-on-write image. This means I now have a single 4GB “base” image with an installation of Windows XP, instead of having 10 of them. It also means it is very trivial to reset the machine’s disk images, which I achieved with a bit of scripting.

First up, I needed to setup the copy-on-write images through `device-mapper`. This program is designed to let you setup software RAID, but it also allows snapshotting disks to provide a backup of a device at a point in time. Unfortunately, `dmsetup` doesn’t support accessing file images, only actual devices, so I need to create some loopback devices first.

# setup loop0 as the "master" image, and mark it as read-only so no changes ever get written back.
losetup -r /dev/loop0 /store/master.img
# we need to get the size of the image in sectors for use later on.
cow_size=`blockdev --getsize /dev/loop0`

The next step is to create a blank image file and loopback device to commit changes to. For my setup, I created 200MB images. Be aware of things like disk-based caches and automatic defragmentation will use up the allocated space very quickly, and when you run out of space in this file further writes will not be allowed, and Windows will soon crash with a blue screen of death. (More on dealing with this in a bit)

# remove any existing COW image
rm /store/pc-1.cow

# create a new 200MB image (it's actually comes out 5% more than stated, but it allows for overheads in the filesystem)
dd if=/dev/zero of=/store/pc-1.cow bs=1M count=200

# now hook it to a loopback device
losetup /dev/loop1 /store/pc-1.cow

Now we have two devices, `/dev/loop0` which contains the master image, and `/dev/loop1` which will contain any changes made to the disk. The next step is to use dmsetup to create a `device mapper` which will layer the COW image ontop of the original image.

# create the cow!
echo "0 ${cow_size} snapshot /dev/loop0 /dev/loop1 p 64" | dmsetup create pc1

This will create a device called `/dev/mapper/pc1`. You can use it in your iSCSI setup with something like this in your `/etc/ietd.conf`:

Target iqn.2010-01.lan.someplace.iscsihost:pc1
        Lun 0 Path=/dev/mapper/pc1,Type=fileio

You can then start `ietd`.

Now the next part is writing a script to let you reset the COW images. `ietd` does not like you changing things while it is running, so you’ll need to make sure your script suspends all disk activity before blanking out the COW image. Something like this:

# disconnect the COW image #1
ietadm --op delete --tid 1 --lun 0

# suspend dm activity
dmsetup suspend pc1

# clear the cow cache
dd if=/dev/zero of=/dev/loop1

# reload the cow table
master="/dev/loop0"
cow_size=`blockdev --getsize ${master}`
echo "0 ${cow_size} snapshot ${master} /dev/loop1 p 64" | dmsetup reload pc1

# resume dm activity
dmsetup resume pc1

# reconnect the COW image #1
ietadm --op new --tid 1 --lun 0 --params Path=/dev/mapper/pc1

You could change this script around so that it allows you to pass in a PC number as a command-line argument, and then hook in a CGI script that will call it to reset it remotely. In my setup, I’m using gPXE to boot from iSCSI, but it can also be used to access a URL via HTTP. So your CGI script reads in the request IP address, and if it is one of the resettable machines, it will reset it’s COW image. Then it sends back a gPXE script instructing it to run a DOS .com file that will reboot the computer. For this to work you need to have your CGI script execute the command as the superuser (root).

One of the things about the COWs is if you reset them or they become full while Windows is running, Windows will very soon crash, and refuse to boot up again. To better inform both yourself and users about the usage levels, you can read the information from `dmsetup`:

# dmsetup status pc8
0 8385930 snapshot 55296/409600

In this example, it is indicating that the full image is 8385930 sectors, and 55296 of 409600 sectors are used in the COW image. So I wrote a Python CGI script that reports this in a parsable fashion to clients:

#!/usr/bin/env python

print "Content-Type: text/plain\r\n\r"

from os import environ
from subprocess import Popen, PIPE

ip = environ['REMOTE_ADDR']
d = int(ip.split(".")[3])
if d >= 41 and d <= 54:
  machine = d - 40
  try:
    p = Popen(('/sbin/dmsetup', 'status', 'retrocow%d' % machine), stdout=PIPE, stderr=PIPE)
    stdout, stderr = p.communicate()
    use, total = stdout.split(' ')[3].split('/')
    use, total = long(use), long(total)
    print "OK %d %d" % (use, total)
  except:
    print "ERR Problem getting parsing information"
else:
  # return error
  print "ERR Not a RetroLAN Machine"

For me, the RetroLAN machines have IPs ending in 41 to 54. That corresponds to their PC number (retro-01 to retro-14). This script outputs the following text file when requested via CGI if successful:

OK 55296 409600

This isn’t very usable for the end user, so I wrote a .NET 2.0 app called `CowBell` that runs in the system tray showing the percentage of COW usage, and notifies them if they’re over 75% usage (which means they will crash soon). I’ve made source code available for download, which you’ll need to modify `frmMain.cs` line 37 to include the path to where you put the CGI script, and uncomment the line otherwise it will not compile. If you make modifications to this program I do ask that you share your improvements with me.

This is the message that constantly pops up when you’re over 75% usage:

The application refreshes it’s status every 10 seconds, and if you right-click the icon it shows the COW usage in sectors.

So I hacked together this VBScript that does a reverse DNS lookup on the IP, and uses that to get a specific wallpaper for the machine using a bit of copy-paste from the ‘net. The script requires you use JSWare’s JSSys addin for VBScript, so make sure you have that DLL installed and registered before trying to use my script. There’s a way to do it without JSWare using the registry, but it only applies after logging out and logging in again.

In the code it will try to grab the wallpaper from \\logres\wallpapers. You’ll need to change this for your setup. To activate this, I added it to the Startup folder, so about 5 seconds after login, the wallpaper is automatically changed to be for the correct machine.

One minor caveat: Apparently my network card was network card #2, and there was no #1. You can check what ID your card is in HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\, and change the line in the script appropriately.

' Automatically setup wallpaper (autowallpaper.vbs)

Function GetFQDN(ipaddress)
  set sh = createobject("wscript.shell")
  set fso = createobject("scripting.filesystemobject")
  Set Env = sh.Environment("PROCESS")

  workfile = fso.gettempname
  sh.run "%comspec% /c nslookup " & ipaddress & "  > " & workfile,0,true
  set sh = nothing
  set ts = fso.opentextfile(workfile)
  data = split(ts.readall,vbcr)
  ts.close

  set ts = nothing
  fso.deletefile workfile
  set fso = nothing
  for n = 0 to ubound(data)
    if instr(data(n),"Name") then
      parts = split(data(n),":")
      hostname= trim(cstr(parts(1)))
      Exit For
    end if
    hostname = "could not resolve IP address"
  next

  GetFQDN = hostname
End Function

Const HKCU = &H80000001
Const HKLM = &H80000002

Set objReg = GetObject("winmgmts:\\.\root\default:StdRegProv")

' Get NIC service name
objReg.GetStringValue HKLM, "Software\Microsoft\Windows NT\CurrentVersion\NetworkCards\2", "ServiceName", nicService

' Get IP address
objReg.GetMultiStringValue HKLM, "System\CurrentControlSet\Services\TCPIP\Parameters\Interfaces\" & nicService, "IPAddress", addrs

' Resolve name
fullname = GetFQDN(addrs(0))
shortname = split(fullname, ".")(0)

Dim objOps
Set objOps = CreateObject("JSSys3.Ops")

r = objOps.SetWallpaper("\\logres\wallpapers\" & shortname & ".bmp", "center")

So, I’ve had my Logitech G15 Gaming Keyboard for a while. However, one annoying thing about it (like other Logitech keyboards), it has the annoying feature of a different socket for the F and J keys, probably intended as hints for if you take all the keys off for cleaning. Unlike my previous Logitech wireless keyboard which had the socket rotated 90 degrees, the G15 has a small plastic key/guide which means you have to insert the F, U, J and H keys upside-down if you want to use the Dvorak keyboard layout instead of QWERTY (because you can only seem to order Dvorak keyboards online, at great expense).

This is a diagram of the G15’s key sockets, looking straight down. The one on the left is a normal key, while the one on the right is for a F or J key. I didn’t use a photo here because my keyboard is so horribly dirty and a close-up shot of the socket makes me ashamed…

You can easily scrape off the key/gude with a flat-head screwdriver. You just have to lever the screwdriver up and down a little bit and that key scrapes right off, allowing you to put in keys from either type of socket. Only a small amount of plastic needs to come off, and you don’t have to push very hard.

The end result is a G15 without any upside-down keys. There’s no disadvantage to doing this to your keyboard, and it’ll continue to work even if you switch your keyboard back to QWERTY again.

To do this, install [Registry Explorer][rexplrce11] on your device. If you don’t want to boot Windows (or can’t), you can use [this copy of the files][rexplrce11tbz2], which has the CAB files you’ll need to install it to your device. You can then [follow the HOWTO][sshwin20howto], then use Registry Explorer to add in the registry entries. Registry Explorer uses a GUI similar to the standard Win32 Registry Editor.

For convienience, I’ve created [a copy of my registry entries][unixreg], which you can import using the Registry Explorer software. Be aware that I store my UNIX root in `\Storage Card\unix`, due to limited internal memory. I’ve found that SSH will still try to store it’s `known_hosts` file in the `\unix` directory, so you’ll need to create that directory anyway (just leave it empty – don’t copy your UNIX root into it). The space used by the `known_hosts` file is minimal. My registry dump also uses the default username of “michael”, which you’ll need to change so it matches what you wrote in your `/etc/passwd` file.

One final thing is that ncurses apps (like irssi) seem to have some problems with the terminal type being set to ‘wince’. I’m presently working on getting a working terminfo file for Linux systems, so that they can properly handle OpenSSH on WinCE.

[sshwin20howto]: http://www.eskimo.com/%7Ewebguy/service/openssh.html
[rexplrce11tbz2]: /static/wince/rexplrce-1.1.tar.bz2
[unixreg]: /static/wince/unix.reg
[rexplrce11]: http://www.tucows.com/preview/32379

So, lets take a hypothetical network:

* eth0: Internet Connection (192.168.0.2)
* eth1: LAN Connection
* tap0: VPN Connection
* br0: Bridge between eth1 and tap0 (10.0.1.1)

Now, your local DHCP server is saying the subnet is 10.0.0.0/8, and it gives out IPs in the range 10.0.1.100 – 10.0.1.200. The remote end (10.0.2.1) gives out 10.0.2.100 – 10.0.2.200, and sets the routing accordingly. I found running the DHCP server on the bridge was a problem, particulary with the ISC DHCP server, as it uses raw sockets, thus making it quite hard to try and firewall out. The solution?

Set an IP for eth1 locally (and remotely), that is in the range, say 10.254.1.254, with the netmask 255.255.255.252. Bind your DHCP server (in /etc/default/dhcp3-server) to eth1. Then restart the DHCP servers, and voila. The DHCP servers only give out addresses locally. To your clients it will appear that 10.254.1.254 is giving out IP addresses.

ratemyrackmountedserver.com expired while I was moving. I decided to leave it dead, as this site kinda bellyflopped anyway. So there’s lots of nice broken links out there to my site… I apologise in advance for all that. I was stuck on dialup for about three weeks
at my new house. It took a little longer to get DSL provisioned than I had planned. So it’s back to mic.kyed.com for a little while.

iPrimus is the shittyest ISP ever. I like how their prepaid access kits were easy to use, but due to them having nonstandard Windows servers running the dialins, I had to use Windows as a gateway for a while. So I ended up setting up a Windows 2003 box with ICS for a few weeks. That’s now been wiped, and was probably comprimised during that time. Good on them. Also due to having to put a Windows server in the way and iPrimus’ very strict 5 hour session limits, my website was down for a while.

I’m now back up again, as of about two weeks ago. I just haven’t been bothered to write anything Now I think I may finally be bothered to get a new domain for myself… maybe. Once I find some spare money.

On the Saturday after my birthday, I had a rather subdued 18th party, due to the fact half of us had the flu. Oh well, good to catch up with some people. Last Saturday I went to LPC with some friends. It was good, though much bigger and slightly more serious than I’m used to. I wasn’t too worried, and we (myself, sherman, Hotsuma, Eecore) managed to trick Thrashbarg into having Windows running on his computer. It was only Windows 95, but Thrashbarg’s earlier zealotry on IRC made it still rather good. He argues that it didn’t count because it wasn’t installed on his hard drive. Oh well

ratemyrackmountedserver.com
notice: I’m moving house next weekend, so the server will be down during this time… until I get my internet connection setup again. Lets hope I can actually get ADSL2+.

Windows x64 is still a pain in the butt, programs rarely exit cleanly if they are more complex than a web browser. Games randomly reboot the machine during play. What the hell, why can a program like that be able to do that? Isn’t that what all this data execution prevention crap is all about?

I don’t know how Windows users put up with this.

Step One: Revert to a 1.0.0 Patch State

This is easy to do. Move Data/Patch.MPQ and wow-patch.mpq to another folder, such as your desktop. Then grab the WoW Repair Utility, and run it. There will be a warning telling you that your WoW install will need to be reverted to an older version. Click yes, and leave the checker to run in the background.

Step Two: Download the 1.5.0 Patch.

The Blizzard downloader is a really simple (to the point of bad) BitTorrent client. To get the patch, and not have to run that downloader or the Blizzard Updater (probably you’re still running
the repair utility at this point), I’m suggesting you run another BitTorrent client to do the download. Blizzard don’t officially supply users with the torrents, however a guild called Nomadic Tendancies have extracted the torrent from the downloader. Download this in your favourite client. You can verify that it is official because the tracker should be http://us.tracker.worldofwarcraft.com:3724/announce. Now that the tracker is up, your download should run smoothly, and in the case of ADSL connections, if you’re using a properly configured client it won’t saturate your uplink to the point you can’t download anything.

Screenshot of downloading the 1.5.0 patch in Azureus on WinXP, using Blizzard’s tracker. The speeds are rather good for me, so you may go faster (or slower!)

Step Three: Patch and Run!

Wait for the download to finish, and the repair utility to finish. Then run the patch file. If all went well, the patch should have completed correctly. When you click OK on the patch success dialog, WoW will automatically run. If you use a UI modification such as Cosmos, close WoW then run it’s executable first before running WoW again to allow it to patch your Interface files again. At the time of writing, Thottbot is running very slowly, so Cosmos may
time out and fail to upload any presently cached data.

Should problems arise…

I can’t really be liable for them – this is a “might work” fix, and I apologize if I’ve made things worse for you. Try moving the patch.MPQ and wow-patch.mpq files back to their original location. If you still have problems, try contacting Technical Support, and also try a complete reinstall.