Unfortunately the problems are quite deep seeded. I’m still actively participating in the LAN scene (I recently travelled to Sydney to help out with LANTACO, a LAN run by the Macquarie University Computer Society and that was a lot of fun), however I’m not involved the ongoing operation of any public events.

On the roadmap is the completion of the Jabberwocky project, which will provide a complete integrated stack of services for LAN parties. I’ll also be looking at releasing the software I’ve developed for StreetGeek as open source in the coming months.

Update 2010-11-08: I’ve read a lot of stuff about “bad blood”, and a lot of people are frustrated that I’m not involved with this event anymore.

I would ask that you do not engage in attacks against StreetGeek or it’s admins in my name. It doesn’t do anyone any favours, and just rubs further salt in the wounds.

If you don’t like where StreetGeek is going, either work towards fixing it or don’t attend anymore. Just don’t do anything stupid.

Thanks.

Just thought I should post this, because I do not wish to be attributed as having written such horrible software, nor impose it on anyone else.

This will only affect StreetGeek X (10.10). We will be resuming our support of StreetGeek for the 10.11 event, provided the rest of the committee is happy for us to do so.

We are withdrawing our support for the event as we are not happy with the organisation of the event, and certain repeated actions by particular members of the committee. We have made every attempt to outline our concerns with the committee, and we believe that with the exception of a few members, it has fallen on deaf ears. These issues are, for the most part, specific to the way StreetGeek X has been handled, and do not apply to other events run by StreetGeek.

We have set extremely high standards for ourselves over the term of our involvement with StreetGeek, and we believe that these issues will prevent us from continuing to provide the quality of service that we pride ourselves on.

Unfortunately, as these issues are considered confidential by the admin team, we cannot disclose the full details of them publicly.

Our non-involvement means that any service that we provide will not be provided by us at StreetGeek X. This covers a wide variety of things, which we won’t go in to here due to confidentiality issues.

We hope that this will be a singular occurrence, and we will continue to strive towards resolving these issues in the future. Unfortunately, our words have not been heeded and we felt that action was to become our voice in this matter.

Do not take this as a “banner of protest”. This issue is purely between us (William and I) and the SGX team.

Sincerely,

.

~micolous and ~firstyear

UserProfile objects (returned by whoami and whois_ip) now also include the user’s forum numeric user ID. This means that your application can track when a user has changed their username.

Additionally, there’s now a new “python” output method for the HTTP GET API which gives the output of repr() on the result object. It’s not recommended that you use this with Python (instead use XMLRPC), but there may be instances where you find this useful.

This will allow in-browser applications to determine the identity of who you are logged in as before attempting to fall back to who owns the computer.

In other news, portal2 v2.8.3 now has a couple of other changes to it, such as support for clustering and a new graph on the usage page which is generated client side (and much faster than the server-side graph).

StreetGeek itself has seen many major changes over the years, as it grew from a LAN of about 20 people hanging out in The University of Adelaide to running monthly events with over 100 attendees at Colonel Light Gardens Uniting Church, the LAN area at AVCON, and leading SAGAfest in 2009. With this, it’s had to adapt to these new, larger environments, and invest in better hardware.

Here’s what StreetGeek’s network looks like, showing only the switches.

StreetGeek’s backbone is a Cisco-Linksys SGE2010. It’s a 48 port managed full-fabric gigabit switch, with 4 SFP ports. It replaced a previous Alloy 48-port managed gigabit switch, which didn’t have as many features, and had the nasty habit of overheating under the load we put it through. This switch lives on the “mu table” (formerly known as the B/C tables).

Coming off that are three Cisco-Linksys SRW2024 switches. They’re 24-port managed full-fabric gigabit switches, which are connected to the backbone each by two copper links using link aggregation. This means between these switches and the backbone there is 2gbit/s of connectivity, full-duplex. These switches live on D, E and G tables, where they together pushed about 7 TiB of traffic during the 10.06 event, with 1.1GiB/s peaks from clients on those tables (that’s about 10gbit/s). While the amount may seem impressive, in reality it’s really not – the switches could push 8.3GiB/s (72gbit/s) of traffic, which if running flat out for an entire event would add up to about 758.6 TiB.

On the overflow tables, and in the console area, there are Cisco-Linksys SR2024 switches. They’re the unmanaged counterpart of the SRW2024, so they don’t support link aggregation. These are connected in various points around the LAN, generally where there aren’t a large amount of clients to justify extra bandwidth.

At the moment, Firstyear has loaned the use of his Apple Airport Extreme access point. It’s a 802.11n access point, which is also one of the few wireless access points on the market that can do 2.4GHz and 5GHz at the same time (thereby effectively doubling the available spectrum that an access point can occupy). They easily handle having 50 clients on the network, and have coverage around most of the venue. We’re planning to replace this in the future with the LAN purchasing two of it’s own Airport Extremes: one in the main hall, and one in the console area.

We’ve tested these access points with gm trying to perform denial of service attacks against it with thousands of simulated clients, and it held up where other routers would just crash. Previously we had used 3 D-Link 802.11n access points to service the network, however the reliability of these access points under load was absolutely atrocious.

Something that may stand out with this is that the console area has a very poor layout. In the end, the console area doesn’t push enough traffic to justify additional cabling to do things “properly”. The only current-generation console that has gigabit ethernet is the Playstation 3, and nothing on the Playstation 3 actually pushes that kind of bandwidth. Typically, LAN games use a megabit or two per second, which is just tiny. The largest amount of bandwidth is used by the RetroLAN PCs, where 10 machines boot from an iSCSI virtual disk – and even then that’s only used for the operating system.

So this has pretty much covered our layout. We run a lot of services on the network itself, which will be covered in later editions of this series. Most of them are from servers in the office, or from servers in the admin area of the LAN hanging off the backbone.

Unfortunately, there’s no online “simulator” available, but that should be trivial for someone to write if they’re testing their program.

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.

Update 2010-10-05: Dealing with duplicate names

Something which I omitted from the original version of this post was how to deal with the duplicate names on the network. In my configuration, I’ve set the computer name PC-00 on the master iSCSI image.

I then setup a DNS and WINS server. On the DNS server, I created forward and reverse entries for each of the computers on iSCSI (eg: pc-01.example.lan). On the WINS server, I used Samba to make it proxy DNS (dns proxy = yes), but that shouldn’t be required as Windows will fall back to using DNS after failing WINS (and DNS is faster than WINS). The benefit to having the WINS server is for non-iSCSI clients register their names to it, so they can still be looked up without NetBIOS.

I configured the master image to use this WINS server and search domain (eg: example.lan), as DHCP options are ignored when booting from iSCSI with the exception of the DNS server. I then disabled NetBIOS over TCP/IP manually (see Microsoft Knowledge Base article 323357).

Now, Windows does not try to discover other hosts, or advertise it’s presence using NetBIOS. You can still connect to other clients via normal UNC names (eg: \\PC-01), and if your non-iSCSI clients have DNS entries created by DHCP or WINS configured, it will allow those to be discovered as well. Normally when Windows detects a duplicate computer name on the network it will pop up a notification – with these changes the computer name can be “wrong” according to Windows and it won’t matter or complain.

Mark Russinovich (of SysInternals fame, now working for Microsoft) wrote that duplicate SIDs for the most part don’t matter, so having duplicate SIDs isn’t really a problem either. Though I don’t run these clients on a domain – but according to the post that shouldn’t matter either.

If you’re using a script to perform an action based on the computer’s name, you’ll have to modify it to look up the computer’s DNS name from it’s IP address rather than getting it from Windows. I’ve included an example of this in an earlier post where I wrote a VBScript to change the wallpaper based on the computer’s name as reported by DNS. I use this with StreetGeek’s RetroLAN setup to show the computer’s hostname in the top right corner of the screen.

Something else you should be aware with in this configuration is your licensing requirements. All the machines will have the same product key. You may be able to use this setup if you have a Volume Licensing Agreement with Microsoft for Windows (where you have one key that is used for all installations of a Windows version in your organisation). Some organisations believe that having the same product key where the key is not a volume licensing key, even when your organisation holds enough licenses for that version of Windows, that it is illegal. I’m not a lawyer though, and you should seek legal advice about before deploying this.

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")

In SAGAPresenter (the presentation software I wrote for StreetGeek and SAGAfest), I wrote a fully functioning PETSCII telnet server. This meant that I wasn’t just pretending to look like a Commodore 64 with downgraded graphics, but I was sending actual command-codes that a Commodore 64 with a network card (and telnet client) could interpret and display. Unfortunately, we didn’t have a C64 with a network adaptor for the LAN, so I installed Per Olofsson’s cgterm, which emulated the C64 on a normal PC without the need for special hardware. It was also much easier to hook up to a projector for the event.

All the while, the traditional GTK# interface was still running, and the displays all perfectly synchronised with each other. I used this PETSCII .NET encoding handler to do a little bit of the text conversion, however I had to write my own code to handle the text alignment and inserting control characters in the right spot.

All in all it was a fun hack, with not a huge amount of code additions required. I spent most of the time converting sponsor banners by hand to PETSCII and tweaking to get them just right!