Over the summer, to help with the prevention of boredom, a friend and I sat down and decided to make a game. This game lives in the browser. He's writing the client (browser) side code, I'm writing the server side code.
A bit of information:
- The actual requests and responses are pretty small - no more than 300 bytes after the initial data loading.
- These requests occur every 1.5 seconds, but we'll likely increase that down the road.
- The testing was done in a VM running a 64-bit copy Windows Vista. The VM host is an Intel i7 920 running qemu-kvm (or, it is a really fast VM, thanks to CPU virtualization extensions.).
- Browsers: Firefox 3.5.1 with the JIT compiler enabled; Google Chrome 184.108.40.206; Safari 4.0.2; all under Windows Vista - all being the latest version available. (I wish I could have tested Opera too, but it has a very very strange bug involving the RSA.)
- I'm going to say "99% CPU," "10% CPU," and so on. Task Manager splits the load percentage over every core on the machine, and the i7 has 8 that it detects. However, as stated, this was done in a VM, which I allocated a single CPU to. "99% CPU" is going to mean "hey this app just froze on me and took most of the OS with it."
As I said, we noticed... responsiveness issues. I went to investigate, when I realized that my copy of Firefox that wasn't within the VM was doing the same thing...
- Firefox jumps from 99% CPU 'down' to 65% CPU as reported by Vista's task manager. On occasion it hit 0, but only for very brief periods of time. The RAM usage was also fun to watch: over a period of many requests, it would mostly remain stable - only to jump by 80MB or more for several seconds, and then back down. This resulted in every three out of four keystrokes being lost, on average, never mind the huge memory churn.
- Safari sat there and looked at us funny.
- Chrome shocked my friend and I. Sure, we had heard that it was fast, and I had done a bit of reading on it. However, I was quite surprised when I saw that it was using a maximum of 10% CPU and roughly 18MB of RAM without any spikes in either. Wow.
Talk about optimization.
While Chrome may not have another user (I quite enjoy Firefox, and having tabs on top of the URL bar really bugs me), at a bare minimum it has seriously impressed me.
Isn't that easy?
With IPv4, we can have up to three bytes per zone delimiter, or in regular speak, three numbers per dot.
With IPv6, every single hex digit is given a zone delimiter, instead of groups of three. This is really nice in terms of flexibility, but people whine enough about v6 address length enough as-is. This pretty effectively doubles it.
For example, 2001:470:d82b:ffff:217:31ff:fec4:919a becomes a.220.127.116.11.c.e.f.f.f.18.104.22.168.2.0. f.f.f.f.b.2.8.d.0.7.4.0.22.214.171.124.ip6.arpa. This is, to put it lightly, nasty. The slightly shortened suffix goes entirely unnoticed.
It's pretty easy to glance at a v4 address and type out the reverse DNS mapping. It is right next to impossible to do that with a full length v6 address. You mentally transpose a digit and suddenly you're trying to mess with an address billions upon billions of addresses away from the one you care about.
Quick note: dig rectifies this problem. "dig -x [ip-addr-goes-here]" will perform a reverse DNS lookup on the address (both v4 and v6), but more importantly, it prints out the address in the proper reverse DNS form.
dig -x 2001:470:d82b:ffff:217:31ff:fec4:919a
;; QUESTION SECTION:
;a.126.96.36.199.c.e.f.f.f.188.8.131.52.2.0.f.f.f.f.b.2.8.d.0.7.4.0.184.108.40.206.ip6.arpa. IN PTR
No more pain!
When I was initially setting up the server <--> home tunnel, my firewalling rules gave me a fair bit of crap. Staring at tcpdump for quite some time didn't give me any leads concerning the proper rule to create, and I wound up whitelisting my entire home IPv4 address (that sounds a bit silly - whitelisting an 'entire v4 address' - you know, all one of them).
I finally got sick of allowing this IP full access to everything, because there were quite a number of ports "open" on the server but that I didn't want anyone outside accessing. This also caused problems with creating proper rules in the first place, because my only test bed was... from an entirely whitelisted IP. Suffice it to say some things that I thought were open were in fact not open to anyone but me, and this caused me quite the headache before I figured it out.
So how did I fix this? The answer is actually pretty simple - 42.
Wait, no. I meant 41. Sorry. Really I did. 41 is the protocol number assigned to IPv6. If this was obvious to others, well, sorry that I'm so slow. I didn't know. If I had known that I should be picking random numbers and trying them in a not exactly often used iptables command, then maybe I would have done this earlier.
Fun fact: "TCP" is 6. Note how this is ambiguous in terms of which "IP" it means, but in this case, it means IPv4. Why TCP is "6" is evidently defined in RFC 793, and why IPv6 is "41" can be found in RFC 1883 (or 1112, not exactly sure).
Note how TCP is 6, and that UDP is 17. Both TCP and UDP are commonly known as "TCP/IP" and "UDP/IP." Both of these operate quite nicely over both IPv4 and IPv6. IPv6 has an assigned number - but IPv4 does not. How you would intermix this I'm not sure. I can block IPv6 quite nicely it seems, but IPv4 is strangely absent. Does 6 imply v4? Does 17 imply v4? How can you filter UDP over 41?
I have no idea. I'm confused too. If you can make sense of the why, I'd be very interested in finding out why these protocol number seem so convoluted and inconsistent. It is pretty obvious that the protocol number for v6 was tacked on long after the base numbers for TCP and UDP were established, but whatever.
So how did I fix this firewalling issue?
# iptables -I INPUT -s <v4 home address here> -p 41 -j ACCEPT
... from the tunnel server. I didn't have to create a matching rule on my home router, and of course, ymmv.
For those of you familiar with iptables, the "-p 41" may look somewhat familiar to you. It should:
# iptables -I INPUT -p tcp --dport 80 -j ACCEPTIt is just a simple protocol match. All we're doing is matching the v4 source address, the v6 data, and allowing it through. Despite the above example doing something quite different, the -p switch does the same thing: matches a protocol.
Been using it ever since.
Whoa now, wait a minute! People use IPv6?
For the most part, I set it up and poked with it for vanity purposes. "Hey look at me! I'm speaking a protocol that your router has no idea what to do with!" I had little actual use for it. For the most part I never had any real problems, but no real benefit either.
But it's been a few months, and I recently had my "IPv6 Epiphany." So here, have some random bits of info that I've picked up while playing with it.
1. IPv6-in-IPv4 tunnels aren't really firewall friendly, nor are they the easiest thing to configure. I wound up whitelisting my home router's IPv4 address on my server, exempting it from all other iptables rules. This fixed a problem that cropped up when I rebooted my server, resetting my firewall rules to their saved state, and broke my ability to SSH into my server from home without specifying -4. Further, configuring a tunnel with iproute2 is pretty easy. Configuring a tunnel from CentOS to Debian using the "proper system-specific methods" really isn't. Debian I got working. CentOS I didn't, and wound up writing a pseudo-service to manage the tunnels and routes. All things considered, I probably would have wound up doing the same thing for my Debian router if it was as overloaded as my server in terms of IPv6 config.
Plus you have the increased latency. As a whole, this hasn't been a problem for me.
2. Not everyone who runs IPv6 maintains their v6 stack nearly as well as they do their v4 stack. This has proven to be a problem. For example, I was looking into H.323, and tried to open up the Open H.323 website.
The problem lies in the DNS. The OpenH323 project had a v6 DNS server. This server did not respond to queries coming over the v6 transport, breaking DNS resolution nicely for me. When I went poking with dig, it responded happily over v4. (It seems that their DNS is broken for both v4 and v6, so perhaps it was coming anyway. But the point stands. When your site works, you're content. You're not going to spend time checking that it works over both v4 and v6. This leads to problems.)
3. Application support.
From a sysadmin standpoint, nearly every computer out there has a DHCP client. Wait, sorry. Nearly every computer out there has a DHCPv4 client. This poses a problem when it comes to v6 connectivity. This is one area where Vista is quite a bit ahead of the *nix - they ship a DHCPv6 client and full stateless v6 autoconfig support by default. Their stateless autoconfig leaves a bit to be desired, as it ignores RDNSS data in the router advertisements, but they have documented how to get full DNS resolution on a stateless-only interface. It's pretty simple.
Linux, at a minimum, has a stateful DHCP client kicking around, but it isn't installed or even mentioned in most distro networking guides. It's not even available in several distros. The kernel has great stateless autoconfig, but RDNSS isn't exactly a kernel space setting either. There is a user space tool around that watches for the router adverts and adjusts /etc/resolv.conf as needed, but it's even less known than the stateful DHCP client.
There are also a couple really popular open source programs out there that don't speak v6 at all. There are two that bug me to this day: MySQL and Asterisk. MySQL is really not too huge of an issue right now, but to my knowledge they aren't even working on it. Maybe Drizzle could?
Asterisk is really the bigger issue. One of the largest roadblocks to getting VoIP with SIP to play nicely is NAT. To put it simply, it doesn't work with NAT. I can see (properly done) VoIP being a huge, monumental boost of support and a fantastic reason to get v6 working. Nearly the entire point of deploying v6 now is massively increased connectivity (with v4 connectivity dropping drastically in the near future). The current v4 (NAT) landscape is incredibly inhibiting to SIP, and while you can argue the relative merits of SIP to any other VoIP protocol, the value of having full connectivity from any one device to any other device really can't be understated.
(A note to you "but I like NAT because it's a great firewall!" people: first off, no it isn't. Second, there is a very simple rule here that both mirrors what you "get" with NAT and is arguably more secure than NAT. It happens to be called "default deny." From there, if you want to support VoIP, you can add one single rule and have great VoIP support. Have a /48 that houses both users and servers? Great - subnetting is your friend. Just open :80 to the server subnet.)
4. IPSEC. Still sucks to configure, is only going to become more important with enhanced device to device communication. Isn't supported by any mobile phone I'm aware of. Have a mobile phone that can connect to a SIP server over wifi? Great! Can it do IPSEC? Nope. Sure, TLS exists for a reason, but full-blown IPSEC has numerous advantages over TLS and it really isn't supported anywhere but the router and desktop. (Plus it still sucks to configure.)
Does your (insert handheld gaming device here) support IPSEC? No? Well sure I wasn't expecting it to, but it'll be interesting to see how this plays out over the next couple years.
5. Reverse DNS. 3.d.220.127.116.11.e.f.f.f.b.3.f.1.2.0.d.f.f.f.b.2.8.d.0.7.4.0.18.104.22.168.ip6.arpa. Do I really need to say just how much configuring reverse DNS sucks? No? Good. Is there a better solution? Probably not. I'm just glad that dig and ipv6calc are of use here, so I don't have to manually type out every full-length DNS record.
1. Pretty much every single application I've used on linux supports it very well. Everything from HTTP to IMAP to Kerberos to SSH is operating flawlessly for me over v6. Vista has v6 CIFS, rdesktop, and RPC. I could make a full list here of what is supported in terms of services and clients across different OSs, but really, the list of what isn't properly supported is shorter at this point. And yes, for the most part, that applies to Windows too.
2. It's supported, well, by every (very?) modern OS. Vista just works with it. Linux just works with it.
There are some "gotchas" with both, but they'll be resolved over time and as more and more sysadmins come to use it. Vista actually has a default 6to4 tunnel built in, that starts up if you have a public v4 address. Even if your ISP doesn't support v6 (not that any of them do), if you can plug your Vista box in straight to the internet, you'll get v6 without any configuration or hassle.
3. NAT really sucks. The simple connectivity provided by v6 rocks. Now this leads back to how I started this entire post. First, a bit of background.
I run CentOS on my server. SSH has all password-based authentication disabled, and only supports Kerberos (GSSAPI) and pubkey auth.
I have a few RPMs that I need to rebuild to support a few extra things (namely postfix to support mysql, and kerberos to support an LDAP backend). I'd rather not keep all of the needed -devel packages installed on my server, and I'd also prefer to keep gcc and the rest of the needed buildutils not installed. The obvious solution is to rebuild them on another CentOS box, create a mini RPM repo, and then just use yum to install them. The process is simple enough.
The trick comes in actually getting those rebuilt RPMs to my server. This is also where v6 happens to make my life incredibly easy.
My CentOS "build box" is a VM running on my Vista box. This is really the best solution for me. I don't need to have a dedicated CentOS box here, and as a result of that I can click "turn off" and forget about it entirely until I need it again. This is probably the only really good use of VMs that I've found so far, but I digress.
As mentioned, you can't login to my server over SSH without an SSH key or kerberos auth. This means that I can't just scp them up to my server without either copying my existing key(s) over, or generating new keys and adding them
It was at this point I realized that my v6 setup meant that my VMs had public v6 addresses. And then a light clicked on.
I fired up rsync on the VM, copied the v6 address, and then from the server used rsync to move them over.
And it just worked. No port forwarding. No key configuration. No advanced auth config for the VM. I could have used apache+wget just as easily. I was able to start a service (on a VM that sits on a host behind NAT) and use it without any hassle, without any VPN trickery - it just worked.
If you compare the effort it would take to setup v6 on your home network and an "external" network, and compare that to the port forwarding, NAT translation/incompatibility, "hey this port is already in use, by another NAT'd device, guess that means we get to start using extensive proxies or odd ports" mess that may be involved in something as simple just getting host A to talk to host B...
... I think v6 comes out ahead in terms of what you get and the time it takes to make it work.
Likewise, IPv6 is pretty much useless if it is never used. I can assign the addresses all I please but ultimately if all I do is ping my desktop that sits "behind NAT" with it then for the most part the effort was wasted.
My server runs CentOS 5.2, my desktop runs Gentoo, my laptop Debian, my router Debian, my windows desktop Vista (dual boot Server 2008), and the Vista box also has three instances of OpenBSD running within VMWare.
I've got a pretty good testbed to see just what does/doesn't support IPv6, in terms of everything general web browsing to random system daemons to whatever end user programs you have a desire to run. So, I put together a small bit of info concerning what handles IPv6 perfectly, what is kind of broken, and what just looks at it with a mystified look on its face.
So to start:
As far as I know, the first IPv6 stack was available for Windows 2000 via a separate download. XP bundled it by default, but left it uninstalled. Vista has the IPv6 stack enabled by default.
Got a pretty new IPv6 stack with 2.6. Had a working stack in 2.4. I'm pretty sure 2.2 had a functional stack too, as did 2.0. Don't quote me on that.
Has supported IPv6 since 2.7.
Apache has support IPv6 ever since the 2.0 release. Every component of apache that I tested supported IPv6 just fine, from general web page serving to SSL to proxies. Considering how much of the web is still on 1.3, all of those hosts will have to be upgraded to 2.0+ before a much wider IPv6 web base is available.
IIS (the Microsoft webserver) has supported IPv6 from their 6.0 release, also known as Server 2003. Most places use at least 2003 on their servers, the era of Win2k webservers kind of died out with Code Red and all of those other worms.
Just kind of sits and looks at IPv6 like it has no clue what it is. Which is actually entirely true. Boo.
Talks happily with IPv6. At least I think. I'm too lazy to start my local copy and check. Their page on the matter isn't what one would call descriptive. No clue when this support was added.
Supported since their 2005 release.
Offically supported as of 2006.
Supported as of the 3.2 release, which was actually just on June 1st of this year.
Supported with XP and onward. Probably Win2000 too.
So the servers are looking pretty good. Unless you run MySQL, which is pretty much everyone. Boo.
At a minimum, we can serve any content over HTTP just fine, and we can access most database just fine too, unless your name starts with a "My" and ends with a "SQL."
Mozilla Suite (and Firefox, Thunderbird, Seamonkey and friends)
Native IPv6 support, ever since the year 2000. Still has some work to be done according to the meta bug, but pretty much all of those bugs are on random operating systems that don't adversely change your ability to connect to IPv6 enabled sites.
Supported IPv6 ever since 4.0, once you applied a patch from their research division. Likewise real native support was probably with 5.0, if not it was by 6.0.
Supported as of Outlook 2007.
Supported. The KDE project has traces of IPv6 development starting around 1999. As far as I can tell, IPv6 is natively supported in every program in 3.5.
Supported. Not clue as of when due to the GAIM --> Pidgin name change, and I'm far too lazy to figure that out.
MSN Messenger, AIM, ICQ and friends
Who cares? (Likely not supported, though I doubt the client is the blocker in these cases.)
Supported since '04.
Supported. Probably since forever. Go OpenSSH.
Not supported without loading a third-party DLL. mIRC sucks anyway.
Supported.... on Windows since '03, *nix and friends likely even earlier.
I could go on and on and on. I won't, because I have no desire to list hundreds of thousands of software packages and their relative IPv6 states. Plus I'm getting tired and this entire post was spontaneous. Not too bad for 30 minutes of google.
But for the most part, we've got a great picture. Every operating system, browser, and web server supports IPv6 and supports it fantastically well. Nearly every program on *nix supports IPv6 and has for quite some time, and most of the big name Windows programs support IPv6 as well.
Not mentioned here was DNS, but the protocol has had support for it since (just about) forever and now that we have AAAA records for the root servers in the public DNS, DNS is good to go with IPv6 from start to finish.
Now we just have to work on the ISPs and home grade routers...
Footnote: one of the comments I got on my initial IPv6 entry was someone reporting success in integrating their LAN with IPv6. While I'm glad to hear it, I'm even more glad that when I got the "unapproved comment has been posted" notification e-mail, the corresponding IP address was a v6 address. The second I had IPv6 up and running on my server, I threw in AAAA records for pretty much everything. If I had to guess, they didn't even know they were using IPv6 to view this blog and post the comment - which is exactly the goal.
So I setup IPv6 for the machines I own. I still depend on IPv4 simply due to IPv6 not being available... well, most anywhere. At least not natively.
A big part of the reason that we don't have IPv6 in more places is because... well, circular dependency here, but because it isn't around. I can't plug my laptop into any other ISP's line and use IPv6 natively, and even if I could, the chances of the average home grade router working with it is about two.
Out of thousands.
So to get around this, IPv6 in IPv4 tunnels are used. They do exactly what their name implies: tunnels IPv6 data within IPv4 packets. The downsides to IPv6 tunneling are latency/overhead and... your ability to keep your IP addresses. If you don't have native IPv6, then your current hosting provider or ISP won't be the one giving it to you - meaning you get to get the IPs from a third party company. When your hosting provider or ISP turns IPv6 on, what are the chances that you'll be able to reassign entire blocks of IPv6 address space? Probably not too great. If you've got Comcast as your home ISP, I don't think that your tunnel broker is going to happily move your address blocks over to Comcast's control - at all.
While the latter point is generally a deal breaker for a lot of people, in the long run, I don't care. IP address reassignment happens all the time. There's no rule stating that you must drop your tunnels once you get native IPv6, and there's no reason why it would be overly problematic or painful either. Simply bring up the native IPv6, change the DNS records, and drop your tunnels a few days later.
With this knowledge in hand, I went poking around the vast area known as the Internet and selected Hurricane Electric's IPv6 Tunnel Broker. What really sold me (for free, that is) on using HE for my tunnel was really twofold: one, their views on IPv6 (which boil down to "we'd really like to be in business when IPv4 is exhausted, so we're going to deploy native IPv6 everywhere, provide a tunnel broker for free for anyone and everyone, and we're going to do it three years before crunch time") and two, the fact that it was free.
In selecting HE, I also got full reverse DNS control, selection of the closest HE router to my server, full control of a /64 subnet and a /48 subnet (by request, which I requested), the possibility of adding three more /64 subnets and three more /48 subnets to my account, and full operating system support (with instructions for setup with linux-net-tools, iproute2, *BSD, OSX, Solaris, Windows XP+, and Cisco).
Not bad for $0. I'm a happy customer (and a potential customer should I ever need colocation/dedicated servers).
I setup my account with HE, logged in, and was presented with simplistic instructions on how to setup my CentOS server.
ip tunnel add he-ipv6 mode sit remote 22.214.171.124 local 126.96.36.199 ttl 255 ip link set he-ipv6 up ip addr add 2001:470:4:b2::2/64 dev he-ipv6 ip route add ::/0 dev he-ipv6
I created a new 'sit' tunnel named 'he-ipv6', with remote endpoint 188.8.131.52 - coming from 184.108.40.206 - and then turned the link up. Easy enough. Then I added my /64 allocation to the newly created tunnel, and pointed the default route through that tunnel.
Wait a minute. That's it? I'm IPv6 enabled already?
[kyle@averageurl ~]$ ping6 ipv6.google.com PING ipv6.google.com(2001:4860:0:1001::68) 56 data bytes 64 bytes from 2001:4860:0:1001::68: icmp_seq=0 ttl=55 time=327 msYup...
From there, I requested a /48 subnet so I could allocate a few full /64 subnets to my house (a /64 for my LAN, wifi, and secondary wifi), brought some more tunnels up, and then from my desktop...
kyle@ksb ~ $ ping6 ipv6.google.com PING ipv6.google.com(2001:4860:0:2001::68) 56 data bytes 64 bytes from 2001:4860:0:2001::68: icmp_seq=1 ttl=54 time=325 ms
And now my desktop is IPv6 enabled. Go ahead, ping6 2001:470:d82b:ffff::2! You'll hit my home desktop. Then ping ::3 - my Vista box. Yup, that's right! My windows box is also on the IPv6 network. :fffe::2 would be my laptop on the wifi. The entire :fffd::0/64 subnet (and corresponding wifi AP) is unused currently, but perhaps once I decide to upgrade my router's software and play with wpa_supplicant that will change.
But why did I do this? What did I gain? Well, for starters, it was really fun to use HE's Looking Glass to run a traceroute to my desktop...
Tracing the route to IPv6 node 2001:470:d82b:ffff::2 from 1 to 30 hops 1 2 ms <1 ms <1 ms 2001:470:0:32::2 2 76 ms 75 ms 75 ms 2001:470:0:35::2 3 103 ms 103 ms 103 ms 2001:470:0:4b::2 4 103 ms 103 ms 103 ms 2001:470:0:8c::2 5 148 ms 148 ms 148 ms 2001:470:4:b2::1 6 234 ms 236 ms 238 ms 2001:470:d82b:ffff::1 7 234 ms 233 ms 233 ms 2001:470:d82b:ffff::2... while it sits behind my IPv4 NAT router. And then my Vista computer, and then my laptop connected to the wifi. Then I got to go take a look at The KAME project and check out the dancing turtle. It turns out that Google's IPv6 site also has an animated logo.
But in the end, I can now access all of my computers from behind NAT, without actually using any NAT - at all. I could drop the IPv4 addresses from some computers and still retain access to them, full access. This may prove to be both a blessing and a curse, but given time, we'll see..
(And yes, I know I shouldn't be using ::1 for my routers, that'll change soon enough.)
That's always a fun feeling. "Oh, hey, look at all of this stuff I wrote about a year and a half ago. It's... it is... so.. entirely wrong. And to think I took my time to write that, scanned it once for typos (missed many), and then attached my name to it by clicking the big 'Save' button."
I was sorely tempted to remove my existing content (content! ha!) and start over with this post, but that feeling quickly subsided when I remembered that no matter how hard I try, and no matter how little people may care, somewhere it was archived. Saved as organized bits on a disk somewhere in the world, indexed by multiple bots, and easily found by anyone looking for my name. Kinda creepy when you think about it.
The other reason that I quickly gave that up, is equally simple. Some of it, I actually like. I've outlined in the past in great detail things which I still believe, and a lot of my philosophies. Sure, the ratio of posts I like is still nearly three to one, but hey, I'll live with it.
After just over a year of not touching this blog, for reasons many, I think I'll be.. well, I don't want to say "back to blogging." There's too much cliche involved with that line. I can think of no quicker way to blog deletion than by announcing my triumphant return of posting random things that no one cares about on a website that no one subscribes to (let alone visits to post comments).
Except of course, for the bots (feed aggregators included).
But who knows what will happen!
I recently installed a jabber server for my small office(s). We recently expanded to three separate buildings, one in Sandy, one in Salt Lake City, and another in Bountiful. Likewise, suddenly the ability to communicate was limited by phones and e-mail, and for the large majority (80%) of the needed communication, both of those options were either overkill (one-line e-mail?) or impractical (staying on hold for 30 minutes, tieing up a phone line, to ask a single six-word question).
It's funny how little we value the ability to easily communicate until it's suddenly not so easy.
I started out trying to install ejabberd, but failed miserably. In both the Sandy and Salt Lake offices, I have a modest linux router installed, doing all routing/firewalling/networking in general. Likewise, throw in the DNS SRV records on a per-site basis, in theory I would have been able to point all clients to the same host, but end result have them all wind up connecting to their local instance of ejabberd.
For those of you who don't know, ejabberd is famous for it's ability to cluster and fail/fault-over abilities. It uses a database that is essentially distributed by default. Further, it has a very nice web interface for management, along with a shared roster (list of people on the service) built-in. Sadly, I never was able to get the distributed part of it (the reason to use it) working. I would add a user on one side, and magically, that user would never appear on the other. Huh, oh well.
I wound up reverting back to the tried and true method (for me, anyways) of getting a jabber server up and running: jabberd2. Jabberd2 is not distributed like ejabberd, but it also typically uses MySQL as the backend (granted, ejabberd can also, and I've never tried to do so either, but I also know how to make jabberd2 work, and that's what I wanted here), which I'm rather familiar with.
So, about twenty minutes after I gave up on ejabberd, I had a functional jabberd2 server, up and ready to go. (For those of you curious, I have a 1.2TB RAID5 array, on which the database server is running. Overkill, yes, but I don't want to burden the router down with a database server.) Now for the fun part: the client, the program that everyone will actually be using.
All of the clients are running Windows XP, along with two or three Windows 2000 boxes. jabber.org has an impressive list of jabber clients, for pretty much any OS under the sun. In the end, I chose Miranda IM, for several reasons:
- Final distributed file size: I wound up with a 556kb .msi installer that I built for it (more on that later).
- Runtime size: I'm pretty sure that everyone lost maybe a megabyte of RAM from running this, if that. Small, light, and fast are all words that I'd use to describe this.
- Ability to customize: at it's core, it's a small executable with a large army of plugins (DLLs), providing additional functions. Likewise, I just cut out everything except the jabber components, and hey, I have a perfect IM client for jabber and jabber only.
- mirandaboot.ini: A little-known feature of Miranda. Drop this file into the install directory, and you can change program defaults. In this case, it's set to automatically create a user profile in their own user's directory, named after their domain logon name.
- Looks for DNS SRV records and uses them (Hey, gaim, where are you? Oh, right, you're STILL LACKING THIS HORRIBLY SIMPLE FEATURE. What's so hard about a DNS lookup, really?).
- Easy to use, simplistic.
All in all, this is pretty much a perfect client for people. It's simple enough to use, effective, small, and to top it all off, free. The only thing it was missing was a .msi installer package (it is being installed on a windows domain after all), and the official stance from the Miranda devs consists of, "you have a .zip and a .exe installer, and what we provide works. If you want a .msi package, feel free to build it yourself." As a result, I did, and I used Wix to do it. Yay for open source and free Microsoft programs that get the job done, and get it done well. The posts I saw on the Miranda forums included a lot of users wanting a .msi installer, so once I polish it off, I'll post both the Wix .xml file, along with the final .msi for people to abuse. For now, I'll link to the .msi which I'm using here. This includes jabber components only, and installs without prompting to Program Files. This file is suitable for usage anywhere, as it saves all settings in places where anyone can write to, and it is multi-user sane (in the sense that user A can't see user B's settings and contacts).
Earlier, I mentioned that ejabberd has shared rosters, where basically everyone can see the same group of people. Sadly, jabberd2 lacks this feature, but makes up for it in another way: it has MySQL as it's backend. This makes is horribly easy to write a small script which clears the existing roster table, and re-populates it with everyone else who is registered with the service. This makes it pretty easy to accomplish a similar "shared roster", and it bypasses the semi-complicated process to add a user, consisting of:
- Finding the person to talk to,
- Adding the person to talk to,
- Waiting for the the person on the other end to both sign in, and click allow,
- Waiting for the person on the other end to add you themselves,
- Finally allowing that user access to talk to you.
For people who only know how to use computers as far as clicking File, Print goes, the automatic addition of new users to their lists saves time and effort all the way around. Not to mention the new person doesn't have to go and add thirty other people, and then wait for all thirty people to add and authorize the new person.
In the end, I wound up with a setup that's as close to perfect as it can get. Shared rosters, easy to use client, and a client that works perfectly and easily.
I'm rather liking this whole "run your own IM server" idea now that
I'm using it on a scale larger than two users. And hey, so are all of
- miranda-0.5.1-1st.msi (.msi installer, jabber components only)
- miranda-1st.xml (Wix .xml file, used to create your own .msi, jabber components only)
- miranda.xml (Wix .xml file used to create your own .msi, all Miranda IM components)
Once again, these files do not include a GUI installer of any sort, but rather will install the program automatically without prompting. There's your warning.