Crossed Wires

Vic’s Blog

Archive for category Linux

Zeroshell redux

May 4

Posted by Vic in Linux, Networks | 4 Comments

I wrote about Zeroshell, and how I thought it was pretty great. I still do, but it hasn’t taken centre-stage in my network configuration like I thought it would. I’ve had to tone down my raves about some of its integrated features as well.

The fact that it hasn’t taken centre-stage is possibly as much to do with VMware’s bogus clock-drift problems as anything, as I haven’t dedicated hardware to my Zeroshell instance yet (I could keep it running virtual, but some of the things I want to do with it will make more sense if it’s a separate machine). VMware Server takes another barb for its handling of VLAN tagging (but to be fair that might be the Linux 8021q module works). It seems that if you have any VLAN definitions on a network card, VMware won’t get to see any VLAN tags on that NIC. You can get a guest attached to a bridged interface to see the real VLAN tags, but only if Linux has not got any VLAN awareness over that NIC.

Alright, so enough ragging on VMware. I have Zeroshell attached to the networks it needs and all is fine. Except that I can’t actually change anything! The web interface that I spoke so highly of originally is actually very restricted in some areas. One of these is in the RADIUS server, and it bit me badly when I decided I’d use Zeroshell’s RADIUS server to authenticate access to the Web interface of my Linksys switch. Turns out that the Linksys firmware expects a particular attribute to appear in the response from the RADIUS server.

The fact that Linksys don’t document this anywhere is not Zeroshell’s fault, but that there is no interface allowing me to do updates to the records above what Zeroshell uses for its own applications is a bit of an issue. It means that instead of a Zeroshell box potentially becoming the hub of administration functions, it is in danger of becoming just another little vertical application server that doesn’t integrate.

Having said that, the backend for most (all?) authentication data is LDAP so a tool like PHPLDAPAdmin might be usable to extend the base records. But, arguably, I shouldn’t have to do that! It is still beta software though, so improvements and enhancements will be made.

The other area that it’s a bit lacking in is monitoring/graphing. Okay sure, I’d probably integrate Zeroshell into the rest of my Cacti setup, but it would be nice if Zeroshell did like other router distos and had a pre-built statistics/graphing page.

Zeroshell is still my pick (I revisited pfSense and fixed the problem updating, but to me it doesn’t have enough function to justify running its own hardware), but it’s just not quite the bees-knees it was when I first saw it.

Tags: , ,

When Upgrades Go Wrong

May 4

Posted by Vic in Linux | No Comments

I’m running Debian on a Linksys NSLU2 storage device, and it works really well in general. So well in fact that a lot of the time I forget the thing is even there! It’s sitting in the garage minding its own business, serving out video and music files, and storing backups of the other systems in the house. Just occasionally, however, the thought pops into my head to run a system update over it — a habit I’ve gotten into for the Gentoo systems in the house, but “the Slug” usually misses out. About a fortnight ago however I decided to do the “apt-get shuffle”. Timing, as they say in sport and comedy, is everything.

I’ve become fairly complacent about system updates. All the distros I use now have got excellent tools for keeping everything up-to-date, and for making sure that things don’t go wrong in the process. It’s all just software, however, and it’s all too easy for something to get missed or for a bug to creep in. One such bug that did exactly that is this one. Unreported at the time I did my update, it rendered my Slug unbootable after the update I gave it.

It took me a day to realise that the Slug was off the network. The failure of the nightly backups was my first clue. Next was the inability to stream any of the media files stored on it. For the next week, on-and-off, I tried a dozen things in an attempt to get it working again. I finally arrived at a process that used the Debian Installer firmware image as a way to get a running system onto the device, allowing me to then access the hard disk and try and reflash earlier kernel and initrd images to it.

I started trying to work on the boot disk, but I couldn’t see it for some reason. Then I discovered that the power supply of the USB2 disk enclosure that holds it was playing up! Now, I had two problems–was one related to the other? Was my boot problem just a hard disk problem all along? Turns out that the power supply failure was a coincidence–replacing the power supply got the disk working again but made no improvement in the bootup scenario.

The NSLU2 boots differently to a PC. On a PC, the BIOS locates some boot code on a storage device and executes that, which usually is a program like LILO or GRUB that has more intelligence and (in the case of GRUB) a way to interact with it. These boot loader programs then load in the kernel and start executing it. With the NSLU2, however, the kernel and the “initial root device” are written into the flash memory of the device–they more-or-less are the BIOS.

On a PC, if there’s a problem with the kernel or initrd you can generally select another one from a list. Worst-case would have you installing the hard-disk in a different PC and fixing the problem from there. On a NSLU2, however, any problem with the kernel or initrd can’t be fixed by changing the hard disk because the kernel and initrd aren’t read from the hard disk but from the flash memory instead. There’s also no option for selecting another kernel, since the NSLU2 is a “headless” device with no console (besides, there’d be no room in the flash memory for two copies of kernel and initrd).

Once I’d been able to get my Slug booting (by writing out a previous version of a kernel and initrd) I was going to leave it alone… but curiosity got the better of me. I’d suspected a bad update to the utility that generates the initrd, and sure enough an “apt-get update && apt-get upgrade” revealed a pending update to the initramfs-tools package. Google led me then to the above bug report. With fingers crossed I did the update, reflashed, and rebooted… successfully!

The Slug is now back in its usual place, quietly going about its business of entertaining us and keeping critical data safe. I might at least think twice before doing a kernel update on the poor beast in future though!

Tags: , , , ,

Zeroshell: network services distro

Apr 12

Posted by Vic in Linux, Networks | 3 Comments

I love it when, almost by chance, I find something new. I decided yesterday to look at FLOSS-based router distributions. I’ve been using IPCop for a while, as an easy way to create a VPN to another location. Unfortunately, IPCop failed my latest requirement: 802.1Q VLAN support. So I went surfing and found an absolute ripper in Zeroshell, but I didn’t find him straight away…

First I found pfSense, a FreeBSD-based distro that seemed to fit the bill–indeed the very first question the Live-CD asked me on bootup was “do you want to use VLANs?”. It also promised a very extensive set of additional packages that extend it’s capability into areas like file/print, WWW proxying, and a host of other features. However, even though it has a very nice web-based configuration facility, due to what looks like a problem on their web site I was unable to even look at what packages are available. Since some of the basic function I would like is provided by these packages, I’ve had to move on–but pfSense gets an honourable mention because of its easy installation and excellent configuration interface.

I looked again at Smoothwall, but soon remembered why I discounted it at the time I chose IPCop. For me, the level of function I think I’d use is a bit too close to the threshold of function in the “community” (read, “free”) version. Astaro would go in this category too, except that I was too dense to be able to even find much clear information about the level of function you get in their community version. So no recommendation on either of these, as I’ve never used either–I do work with a fellow who happily uses Smoothwall though.

Then, I came across Zeroshell. The lead developer describes it as “a small Linux distribution for servers and embedded devices aimed at providing the main network services a LAN requires”. And does it ever! It’s a veritable Alladin’s Cave of features and functions. It certainly does everything I was looking for, from VLAN tagging through QoS to VPNs, from an SPI firewall to multi-zone DNS and multi-subnet DHCP servers, but also has Certificate Management (using a self-signed CA certificate or one you import), a RADIUS server, WiFi access-point capability with multiple SSID and VLAN mapping, captive portal or “normal” HTTP proxying, 802.1d bridging, clients for Dynamic DNS, a Kerberos 5 server, plus a raft of other capabilities. Zeroshell–named because the author wanted to provide a system that was extremely flexible and powerful yet did not require users to access a shell prompt–is remarkably feature rich, and yet the download for the ISO image is only around 100MB (a bit beefier than pfSense, admittedly, which weighed in at around 60MB).

There are a couple of downsides, however. Until very recently, installing to a hard disk was not supported. The distro is designed to boot from a CD only, but can use an installed hard disk (if available) for what it calls “databases”, where configuration and other data is kept. With the latest release, however, the developers have created a “1GB USB drive” download (the size of the download isn’t 1GB), which is designed to be copied to a USB pendrive or hard disk.

The other downside (and it’s not fair to say that, as will become clear) is the web interface. Not because it’s ugly or not functional: it is neither of those. It’s clean and well laid out, and fairly consistent. It’s very technical, however. Where other distros tackle the “SOHO divide” by hiding details such as protocol numbers or port ranges, Zeroshell uncovers all this stuff in its gory detail. So it’s great for someone like me, who looks at the interfaces on other systems and pines for the knobs I can’t fiddle with, but it’s not for newcomers.

It looks to be a fairly new project (current release is 1.0beta9), but the forums look good and there does seem to be a bit of activity around it. I’m running Zeroshell in a VMware guest at the moment while I kick the tyres–the VMware download is also available from the project’s mirrors–but I reckon this one will be a keeper!

Tags: ,

MythTV fun and games

Apr 1

Posted by Vic in Hardware, Linux | No Comments

Bad things don’t always come in threes. For my MythTV setup, four bad things all happened at once. First was that the governments of the Australian states that run Daylight Savings Time (DST) decided to jump on the energy-saving bandwagon and change the end-time for DST this year. Second was that the OzTivo folks changed the API for connecting to their program guide data, and closed the old API interface on the same weekend that DST was originally due to finish. Third, for some reason that I’m still investigating, my run-an-emerge-world-at-least-every-fortnight MythTV backend had an old timezone-data package, so any times it handled that should have still been DST weren’t. Fourth, Shepherd isn’t quite as smart as I thought it was, and I didn’t find out until too late…

Let me get something straight: Shepherd is the bees-knees of EPG grabbers for Australian MythTV users. If you’re a MythTV user in .au and not running Shepherd, stop reading this right now and go and update your system to use it–you’ll be glad you did. If I had just looked at some of the output it has been generating since OzTivo announced it’s changes, most of the agro I’ve suffered the last few hours would have been avoided.

In a nutshell, Shepherd is a “meta-grabber”. It includes code that can get program data from a dozen or so sources, and keeps looking up sources until it fills your listings with data goodness. It automatically updates these individual source grabbers as well, so you should never need to worry about its up-to-date-ness (more on that later though). It also fetches extra program data from IMDB and TVDB, and can even automatically grab station icons for you. Highly, highly recommended.

I could see that some of my EPG data was coming from OzTivo because I had seen the notes that they had put in the program data advising of the API change. The weird thing I saw was that for a program I was recording in the same timeslot each day, sometimes the message would be there and other times not. While I thought that this was a little strange, I figured that the OzTivo folks were just being overly cautious and trusted Shepherd to do all the updates it needed.

Then, ever since Sunday morning when the southern states *didn’t* switch back from DST, I’ve had recording times out by an hour–programs trying to record an hour early. So as I mentioned, I had ye-olde timezone data on the backend, which can’t have helped depending on the data source (although I’m trying to work out if this actually is a contributor as I would have thought it would send the recordings an hour late… plus, others who have confirmed their timezone data have had the same problems). For a couple of programs, I actually had double entries: one an hour too early, then a second one at the right time. This was weird, and I still can’t explain it!

A manual run of mythfilldatabase showed why I was getting the repeated OzTivo API messages. Shepherd had downloaded the updated grabber alright, but the new version has a Perl dependency that wasn’t satisfied and it couldn’t run. Rather than bail out, Shepherd elected just to keep running with the old grabber. Given the circumstances, I’m still deciding how I feel about that. :-

So once I was confident that the grabbers were working okay again, I decided to get the EPG straight. I remembered that mythfilldatabase will not replace any existing data it thinks is valid, which is why only data post-April-5-or-so looked nice again. So, with a mailing list post or two as encouragement, I truncated (database-admin-speak for “deleted all the data from”) the “program” and “programrating” fields in the mythconverg database and ran mythfilldatabase. After about 20 minutes, voila, fixed guide data!

So now I’m thinking of how I can alert myself to a problem with Shepherd. I used to just check the result of the last mythfilldatabase run through Information Centre or mythweb, but since Shepherd ends cleanly so does mythfilldatabase. Looks like I might have to come up with something hackish to look for Perl runtime errors in the mythfilldatabase log and do a Nagios passive service check or something… Sigh, as if I needed another little project to keep me busy… :)

Tags:

SLES, you make it so hard to like you

Mar 15

Posted by Vic in Linux, Soapbox | No Comments

Just wended my way through another SLES 10 install on s390x. It’s b0rked though, and I’ll probably have to redo it. I had some kind of I/O error during the install which seems to have resulted in a couple of the filesystems being remounted read-only. Not too much trouble you’d think…

Some things aren’t starting because of missing binaries in /usr, frustrating but probably recoverable. The network startup is totally clagged though, and I can’t even begin to work out how what happened… happened.

During bootup, at the time it tries to configure the network interface, I get streams of error messages about problems running the “ip” command. The error text is full of garbage that the init script is trying to parse as text configuration–it looks like a corrupted filesystem or a binary file.

I manually configured the network (not a trivial task in s390x, it must be said), and started to poke around. I got this when I logged in as root:

Last login: Sat Mar 15 12:48:36 2008
/usr/X11R6/bin/xauth: error while loading shared libraries: libXau.so.6: cannot open shared object file: No such file or directory
-bash: read: read error: 0: Is a directory
lxs0za01:~ #

Okay, so I won’t get funky X-based YaST.  No problem, I’ve spent more time in the ncurses-mode YaST anyway…

lxs0za01:~ # yast
warning: the ncurses frontend is installed but does not work
You need to install yast2-ncurses to use the YaST2 text mode interface
lxs0za01:~ #

WHAT!!! What the @#!$ happened there?!?!?

Okay, so I’ve calmed down about that, so I go looking for the problem with the network initialisation…

lxs0za01:~ # cd /etc/sysconfig/network
lxs0za01:/etc/sysconfig/network # ls -go ifcfg*
-rw-r–r– 1   141 2006-06-17 07:30 ifcfg-lo
lrwxrwxrwx 1    16 2008-03-15 02:23 ifcfg-qeth-bus-ccw-0.0.0f00 -> /lib64/ld-2.4.so
-rw-r–r– 1 27470 2006-06-17 07:30 ifcfg.template
lxs0za01:/etc/sysconfig/network #

Priceless. You can’t make this stuff up. I cannot for the life of me work out how this could possibly have happened. I guess I just blame it on a whacked-out filesystem and move along.

Okay, so both of these issues probably have extenuating circumstances unrelated to SLES or YaST… but it’s nice to have a vent now and then. I’ll write up something a bit fairer once I fix this b0rkedness. :)

Thinking of a Gentoo desktop

Mar 3

Posted by Vic in Linux | No Comments

I know I’m going to cop a beating on the Planet for this post, but here goes…
For a long time I ran a desktop system built on Gentoo Linux. A while back I tried Ubuntu, and I’ve been running that as my desktop ever since. Every now and then, though, I feel an inclination to pop back to Gentoo — usually it will be because of some package I want to be able to install, or later versions of packages that don’t make it into the usual binary-distro world without introducing “dependency hell” (I’m having this problem at work, with a distro based on RHEL 5.1 and hardware that’s just too new for it… Even if I wanted to build drivers from source, the libraries the drivers link against are too old as supplied, meaning I’d have to rebuild the libraries too, which probably means something else will be too old…).

I run Gentoo on both my “servers” at home. At the time I got my dual-Opteron, Gentoo was the only “free” distro around that had a x86_64 version ready to roll. When it came time to build my phone-and-TV server, it got Gentoo as well because it was the only way I could get the right combination of all the versions of code (Apache, PHP, Asterisk, MySQL, MythTV, ccxstream, etc) that I needed and have them all maintained in the distribution’s package management system (Debian has no ccxstream package, for instance). I don’t run Gentoo because I’m a ricer. Portage has the right package mix for me, and its ability to control the configuration of packages through USE flags gives me an opportunity to control the options that are enabled in the packages I install.

I have blogged previously about some hardware I bought that I haven’t been able to put to good use. I decided to give it another try by building a Gentoo system on it, because an ebuild for the bleeding-edge ATI driver that is supposed to support the graphics chipset in this clunker is in Portage.

Let me say, it’s been a while since I built a Gentoo system from scratch. You don’t even do it truly from scratch anymore either — the days of starting with a stage-1 tarball are over apparently, and stage-3 is always the way to go. Even so, this system took a whole weekend to get to the stage where I could log on and get a KDE desktop (to be fair though, there was a lot of kicking off an emerge, coming back to it a couple of hours later to find it had died ten minutes in, fixing the issue and restarting… so it wasn’t 48 hours solid time spent).

Unfortunately the ATI driver still doesn’t support XVideo on this chipset, so I still can’t use this board for its intended use as a MythTV frontend (I do have an old PCI nVidia 5200 card that, even though it’s at least three years old, I’m sure will run rings around this stinking ATI 1250). So the point of the whole exercise was, unfortunately, lost. But I did get a refresher in the amount of effort a Gentoo build would take.

After that weekend’s effort, I was a bit put off by the thought of building up an entire desktop system from scratch. When I thought about it though, my concerns were for nothing. The compiling? The kind of systems I’m building on (modern dual-core chips) will chew through compiling most software in a snap — heck, for simple packages I can install on a Gentoo system quicker than yumex can initialise its repositories. I’ve got running systems I can use as a model to get USE flags right, and my NFS-shared Portage tree means that I sync once and use everywhere (even downloading source packages happens only once).

Plus, now, I know Gentoo. Sure, APT on a Debian-based distro is nice, but I still am lost when it comes to the right dpkg command to locate what package provides a certain file, for instance. I get frustrated when something fails to build on Gentoo because some other package wasn’t built with the right USE flag, but I know how to fix that, and its fixed in a flash. Likewise for rebuilding some system library that causes a bunch of other packages to fail without warning, and likewise for the strange b0rkedness that happens in Portage sometimes when packages change versions (gnupg is a recent example). I know how to fix Gentoo when it breaks — I can’t say that with much confidence for other distros.

Some might say “use a distro that doesn’t break in the first place”, which is a fair comment. But if I have to choose between an occasional hiccup and missing functionality, then hand me the Eno (Pepto-Bismol, Tums, etc)… ;)

Which brings me to my dilemma — apart from the fact that I have crappy unaccelerated non-video graphics and I haven’t been able to run Compiz for ages (a problem that Gentoo wouldn’t solve for me anyway), Ubuntu isn’t really broken for me. There’s not a compelling reason for me to throw Gutsy out, and with Hardy around the corner there’s even less reason to switch right now.

So, I’ll wait. And watch. Having to work on more Red Hat systems at work is reacquainting me with their particular mojo, perhaps even enough to try Fedora. Also, I’ve just scraped together some parts to make an openSUSE 10.3 build for something work-related so I’ll catch up with things there (since I haven’t really seen a SUSE system as a desktop since SuSE Linux 7).

I love this about Linux — freedom to choose!

Tags: ,

OpenTTD

Jan 28

Posted by Vic in Fun, Linux | No Comments

So I was catching up on the RSS feeds I subscribe to, and came across an article on the latest issue of Full Circle (a magazine about goings-on around Ubuntu Linux). In it I found an article on OpenTTD, an open-source clone of the old 90′s game Transport Tycoon Deluxe. As one who spent many an hour in front of games like Railroad Tycoon in my youth, I had to try it. Unfortunately, I’m hooked…

I’ve been playing the game all night since I found it on Monday afternoon. Sleep seems a distant priority compared to making sure I snag the subsidy for a passenger service from Podlondlington to Nunmubhattan…

It’s easy to install on the Ubuntus, but you do need to obtain the data files from the original CD — the Full Circle article contains instructions on how to do that (or I’m sure the website tells you).

Sure, the graphics don’t measure up to today’s insane system-melting specifications and the isometric view, while state-of-the-art in its day, is at times frustrating (I’m sure there was a control you could use to hide the buildings so you could see behind things… maybe I’m thinking of Lincity). Still, it’s both a great bit of entertainment and a trip down memory lane at the same time. If you’re like me and played with the Tycoon games as a kid, or if you’re a bit of a retrogamer, I encourage you to check it out. Don’t expect to see much of your family for a while though… :)

Tags:

KDE 4.0: be free.

Jan 18

Posted by Vic in Linux | No Comments


Since I watch Planet KDE it was easy to get caught up in the excitement around the launch of the new version of KDE (the announcement is here). I was unable to resist giving it a try on the laptop! So this post is coming from Konqueror 4.0.0.

I tried an early Beta of the KDE 4.0 Live CD, but it was still using the KDE3 Kicker and was also a bit unstable. I wasn’t sure if it was the fact I was running in a virtual machine that made the graphics a bit flaky or whether it really was beta-quality code making things a bit funny. The KDE team put a lot of effort into bug-swatting in the weeks leading up to 4.0 being tagged, and it’s a lot better now!

This announcement from the Kubuntu folk shows how to get the KDE 4 packages installed on Gutsy. KDE 4 installs in a different path to KDE 3, so you can try out KDE 4 without affecting your existing environment.

I did have a bit of a heart-starter with this though, as apt-get wanted to remove a package called “kdebase-bin-kde3″, which looked risky! It’s okay though, as equivalent binaries are provided by “kdebase-bin-kde4″. In fact, if you follow Kubuntu’s instructions exactly, you should not see the issue: it happened to me because I did a system update after adding the Kubuntu PPA repository but before installing KDE 4. The system update brought a bunch of updated KDE 3 packages out of the PPA, one of which was to replace the standard “kdebase-bin” package with a “kdebase-bin-kde3″.

First impressions are that Oxygen (the new artwork for 4.0) looks great — it’s a very modern look. Some might think it borrows from Vista, but to me it’s got as much of Mac OS X’s appearance as that of Aero. Plasma (the desktop shell) does some interesting things, like turning desktop icons into widgets, but I’m yet to spend enough time with it to experience the other improvements it brings.
The biggest thing I’m looking to trying out is the compositing built into the window manager, KWin. Unfortunately the laptop is a bit old for this to work well (or at all in fact), so I’ll either have to find some magic Xorg setting or get the KDE 4 packages on the desktop machine. I’ve had trouble running Beryl and Compiz thanks to something about the terminal program Yakuake tickling a long-lived bug in X11 (I think part of the reason it’s long-lived is that the X11 folks don’t accept it as a bug but rather a fringe case that Yakuake shouldn’t be exercising, hence a stand-off) so it will be interesting to see if KWin has the same kind of issue.

As for bugs, well there look like plenty. :) As I’m keying this, Konqueror is chewing 100% CPU and the characters are delayed by a couple of seconds (and of course, now that I observe this, it stops doing it). Still with Konqueror, this is about the third time I’ve tried to post this thanks to Konqueror segfaulting for strange reasons. Also, the Alt-F2 program launcher reports that it was unable to launch whatever you told it to, even though it does so successfully.

There has been plenty written by the KDE folks about the “1.0.0 release of KDE 4″, and they’re copping a fair amount of stick from people who think they’ve done the wrong thing by releasing as 4.0.0. I’m on KDE’s side. Although many KDE folks have used their KDE 4 builds as their daily desktop for months, I haven’t seen anyone who wears a KDE hat recommending that others do so. The term “will eat your children” has been used to describe KDE 4 by folks from the KDE team, so there has never been any pretense that KDE 4.0.0 would be a daily desktop for the majority of users. I’ve never really participated in large-scale software development, but I can see their motivation for releasing what they had as 4.0.0 — I’m proof of it. As long as it was a beta I was not really all that fussed about trying it out; even after there were release candidates I wasn’t all that keen. As soon as you call it a release, however, your early-adopters rush in and kick the tyres and your real testing can start.

By being open about 4.0.0′s status (and I don’t think you can get more open than “will eat your children”), they can make sure that subsequent releases are a lot better than they would be if they dragged on in perpetual beta — the model that Google and the Web 2.0 fraternity seem to insist is better, plodding on for months hiding behind beta status and its implicit “get out of jail free” card.

Instead, KDE has shown the courage to take their code, along with its bugs, and hold it up as something they are proud to give to the world. It’s the foundation not only for future releases of KDE, but possibly the start of new ways that people work with their computers. By working with the community, instead of closeted away from it, I believe the KDE team will succeed.

Okay, so that finished a bit more ra-ra than I planned! Seriously, give KDE 4.0 a try… but if you aren’t happy to suffer a few bugs then by all means wait until 4.0.1 or even 4.1. Oh, and be free. :)

Jabber and Google: part two

Jan 13

Posted by Vic in Linux, Networks | No Comments

In part one I mentioned how I was considering using Google Talk as my main chat ID. As it turns out, I talked myself out of it pretty quickly after I delved into using Google Talk to connect to MSN and other services as I do now with my own Jabber server. While there are a lot of links around for using Jabber transports to hook your Google Talk ID to other services, there’s a tiny catch… well, actually, I think it’s a bloody great huge catch personally.

You see, it wasn’t until I read the how-tos that it became clear how it works. The trick is that Google doesn’t run Jabber transports on their own servers, so you therefore need to take advantage of various “open” Jabber servers that do (“open” in this context refers to a server that lets you use its transports without necessarily being a registered user there).

Seeing there didn’t seem to be any restrictions on the servers that could be used, I figured that I could use my own server. Sure enough, after the right incantations to expose the service on the ‘net, I could connect my Google Talk ID through the Jabber-MSN transport on my server to my MSN account. Yay, right? Well, not really — each little test message I sent in either direction incurred three trips over my Internet connection! Yes, three: one to go from my Google Talk client to Google, one back from Google to the transport on my Jabber server, then a third from the transport to MSN. Obviously the same happens in reverse as well (for incoming messages from MSN).

Seeing this as a less than optimum setup, and also being wary of getting listed as a Google Talk-friendly Jabber transport provider, I lopped the transport’s external visibility and went back to using my own JID for transport access. It’s a bit of a shame too; since fring (mentioned briefly in my last post) doesn’t let me connect to an arbitrary Jabber server, to keep connected to everything I’d need two mobile chat programs running.

It’s not like I do that much IM that I need to keep all this running, but it is at least a little bit interesting… :)

Jabber and Google, part one

Jan 7

Posted by Vic in Linux, Networks | No Comments

I reactivated an idle Google account the other day. A friend of mine from the Netherlands invited me ages ago but I never really did anything with it until I discovered that a Google Mail account can be used for other Google stuff as well, including Google Talk. I read that Google Talk is based on Jabber and works with any Jabber client, so I flicked over to Kopete and plugged in the details. Sure enough it worked… but then it got interesting.

I run a Jabber server for internal things. I wanted to have a secure, private chat facility to use over VPN with my nephews; I want to someday migrate my Nagios IRC bot to Jabber; and I use transports to link into MSN and Yahoo! to reach friends on those networks. The last point is great: I really like the fact that now, from whatever Jabber client I use (even the mobile ones I’ve played with) that I merely connect to my Jabber server and I’m online on MSN and Yahoo! as well.

Google Talk, though, has proven to be a bit of a challenge. It’s actually working like a tower, even though it’s based on (arguably) the most open of the IM platforms! You see I more-or-less took for granted that “transport” way of doing things, using my Jabber server to bridge to other networks. There’s no Jabber transport for Jabber though!

What I want to do kind-of flies in the face of how Jabber is designed. Ideally, you’re supposed to only have one Jabber ID (JID) — Jabber creates an open network with servers establishing connections when needed, very much like e-mail, and you only need an ID on one server to be able to chat with anyone on any other server. So what I wanted to do, which was connect to one Jabber server and have it “relay” messages to an ID on a different server is just not necessary with Jabber. Nor should it be necessary for Google Talk users to send messages to me using my Google Talk ID only — they can send straight to my JID on my Jabber server.

In the early days of Google Talk, Google had not enabled the “server-to-server” functionality that allowed this kind of communication to happen. Google Talk worked just like MSN, Yahoo! or AIM — you had to have a Google Talk account to chat with anyone on Google Talk. While this was the case, folks were looking making a Jabber-Jabber transport for connecting Jabber servers to Google Talk. At some point, though, Google opened the connectivity paths that allowed Google Talk to exist on the open Jabber network (I’ve tested this for myself). Once this happened, the need for a  ”Google Talk Transport” for Jabber evaporated in most people’s minds.

The solution nowadays is to use a client that supports multiple connections, and connect to your Jabber and Google Talk accounts at the same time. It works of course, but you don’t get the nice benefits that a transport provides — the main one being access to all your IM services and accounts from a single server connection.

So now, having resigned myself to not being able to bring my home JID and Google Talk ID together, the question arose: do I still need my own Jabber server? My current fave mobile IM client only connects to Google Talk… Could I get by just using the Google Talk service? Find out in Part two! :)