Category: SysAdmin


Sipgate and the Zoom 5801 ATA

Following on from my initial foray into SIP a couple of weeks back, I ordered a Zoom 5801 ATA from Expansys, so I could hook my good old-fashioned cordless phone up to Sipgate.

I wasn’t impressed by the six working days it took to turn up, but it was free delivery.

In terms of hooking it up, the man-traps to avoid are:

  • Your Sipgate password for registering a device is NOT the same one you use to log in to their website
  • You don’t need STUN enabled or configured
  • I’ve got various SIP ports forwarded from my router to the ATA’s IP address, though I’m uncertain if they’re absolutely necessary (Google for the ranges to use).

My router is Virgin Media’s latest Superhub.

    Having configured it all, incoming calls work perfectly, and my twelve quid cordless phone from Argos manages to display the caller ID, which beats both Virgin Media and BT’s landlines hands down. Outgoing calls work too, and don’t forget that Sipgate don’t charge for 0800 numbers (unlike your mobile provider).

    Lastly, since you’ve got Nagios running on the PC behind your sofa anyway (right?), let’s set up a simple check to scrape the web interface and verify that the ATA is correctly registered with Sipgate:

    define command{
     command_name    check_zoom_ata
     command_line    $USER1$/check_http -a administrator:yourpassword -I $HOSTADDRESS$ -r "Ready to make calls"
     }

    Now define a service using this command, and associate the service with one or more hosts/hostgroups in the usual way.

    Slow outbound e-mail?

    I’d noticed for years that sending outbound e-mail from Thunderbird to my server on port 587 took far longer than it should have – about six seconds of staring at the progress bar.

    Today, I was finally bored enough to work out the cause: Exim is configured to perform ident checks, which take 5 seconds to time out. Since port 587 only accepts mail from authenticated users, we can disable the ident checks for it:

    rfc1413_hosts = ${if eq{$interface_port}{25}{*}{! $sender_host_address}}

    If you’re running Debian, change the above in /etc/exim4/conf.d/main/02_exim4-config_options.

    Dot everything

    I read with interest the news that ICANN has approved the ability for companies to register .anything domain names (so KFC could register .chicken and have http://chicken as their website). Some are saying that  chaos will follow.

    Personally, I’m not too worried. In the last week I’ve seen both an older relative and someone my own age refusing to believe that websites without www in front of them can possibly exist (visiting www.sub.example.com despite being told to go to sub.example.com), so I suspect anyone silly enough to shell out $185,000+ will watch the abysmal traffic to their website and wish they’d spent their money on a leaflet campaign instead…

    IPv6 support in Android

    I’m pleased to report that (having fixed the IPv6 on my home WiFi), my HTC Desire S running Android 2.3 picks up an auto-configured IPv6 address on its WiFi interface. This is then used successfully by the built-in browser, K9 Mail and Irssi Connectbot.

    I was hoping to include a screenshot showing the IPv6 address the phone had obtained, but apparently you can only screenshot a non-rooted Android by using the developer tools … sounds like a job for another day.

    update-grub not working on your Debian Squeeze domU?

    We‘ve been having a spot of bother with update-grub not working on our Debian Xen guests since upgrading them to squeeze.

    The symptom: update-grub (as run after the installation of a new kernel package) fails because it’s ‘unable to find [a] GRUB drive for /dev/sda2 – check your device.map’. This happens using both grub-legacy and the new grub-pc package.

    You’ll probably have run into this if your guests were created using xen-tools.

    Skipping over the related bugs, the long and short of it seems to be:

    • The way Xen pokes /dev/sda1 and /dev/sda2 (which are probably LVMs on your dom0) into your guests without a corresponding block device confuses grub
    • grub used to be dumb enough to ignore the mysterious presence of ‘partitions’ with no block device and carry on anyway
    • The versions in Debian Squeeze are just clever enough to be dangerous and fall over in this situation

    Happily, we’ve worked out the fix. Grub is hard-coded to do the right thing in this situation if your disk devices are called ‘/dev/xvd[a-z]‘, so you need to:

    1. Fix all references to ‘/dev/sda2′ to read ‘/dev/xvda’ (and /dev/sda1 to /dev/xvdb). In practice this means grub’s menu.lst and possibly your /etc/fstab if that isn’t by UUID
    2. Edit the /etc/xen/guest-name file on the dom0 to rename the partitions (change the ‘root’ specifier and the lines in the ‘disk’ list)
    3. Destroy (sudo xm destroy) your guest. Note that you must destroy and recreate it; rebooting won’t give Xen a chance to rename the devices.
    4. Bring it up again with xm create -c config-file
    5. Profit.

    When Sixxs met BytemarkDNS

    Edit: Those of you coming across this post by googling for ‘Sixxs rDNS’ should note that Bytemark’s DNS service isn’t free unless you already have a server with them, but there are a number of free alternatives out there.

    With IPv4 address space exhaustion practically upon us, I decided it was high time my house got IPv6. This is quite easy to do even if your ISP, like ours, doesn’t support it natively. Get a Sixxs tunnel, apply for a subnet, set up radvd on the Linux box behind your sofa (you do have one, right?) and there you are.

    Even Windows XP can be trivially prodded into IPv6ing itself up, and my router seems not to mangle the radvd broadcasts so even wireless clients can have v6 if they support it.

    What really impressed me, though, was what happened when I wanted to set up reverse DNS for my new Sixxs subnet. I’ve been assigned 2a01:348:1af::/48 and the Sixxs page tells you that you’ll need your own DNS server to host the necessary records. I don’t run my own DNS; I use Bytemark’s content DNS service.

    I wasn’t expecting Bytemark to support adding rDNS records for random IPv6 /64s, however as it turns out, once you work out what the TinyDNS file needs to look like:

    # IPv6 rDNS authority for Sixxs subnet 2a01:348:1af::/48
    
    .f.a.1.0.8.4.3.0.1.0.a.2.ip6.arpa::a.ns.bytemark.co.uk
    .f.a.1.0.8.4.3.0.1.0.a.2.ip6.arpa::b.ns.bytemark.co.uk
    .f.a.1.0.8.4.3.0.1.0.a.2.ip6.arpa::c.ns.bytemark.co.uk
    
    # Machines in the first /64 (home network)
    6router.ipv6.dnorth.net:2a01034801af00000000000000000001:8640

    … it Just Works:

    $ host 2a01:348:1af::1
    1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.f.a.1.0.8.4.3.0.1.0.a.2.ip6.arpa domain name pointer router.ipv6.dnorth.net.

    Nice one, Bytemark!

    2011 geek wishlist

    In no particular order…

    • That Debian Squeeze will release in Q1 2011
    • That I’ll discover a J2EE Servlet Container which isn’t totally horrible
    • That some kind of reconciliation between the JCP and Apache will occur
    • That Java 7 won’t be delayed forever
    • That Python 3 will get adopted faster than PHP 5 or Java 1.5 did
    • That we’ll finally see some major UK ISPs offering IPv6

    Leave a comment if you can see anything I’ve missed, and we’ll check on them all at the end of the year…

    Crap hardware stole my weekend

    A wise man once wrote:

    Unlike the precocious child who will taunt you mercilessly, knowing just how to report the beating they deserve to their school teacher in a manner that will have you in Police custody before lunchtime, hardware is sneaky.

    I couldn’t agree more.

    Hardware and I have never really got on, but we’ve always maintained a queasy peace – my laptop may not hibernate properly under Ubuntu, but it sort-of works. Likewise the machine behind my sofa refuses to charge its CMOS battery, but as long as I reboot it rather than shutting it down, it manages to come back without manual intervention.

    Last weekend, though, hardware declared war. And it did so under the guise of a familiar occurence – a phone call from a family member about some “computer trouble”. Mum and Dad have their internet courtesy of now-defunct Tiscali UK, which was taken over by TalkTalk. For about three years, the Tiscali-branded black box router had been sitting in their study and working. It didn’t feel like the highest-quality piece of kit in the world, but it did manage to keep the connection open and serve one wired client – a desktop PC – and my sister’s laptop over WiFi.

    Three years on, it died. No problem, I thought. I ordered a reasonably priced replacement to be shipped over there, and the next weekend I tried to talk Mum through installing it over the phone. No good – we eventually established, after much frustration, that the router was not DOA, but partially-alive OA, and kept dying within 30 seconds of being plugged in.

    Sigh. Grit teeth. Pack it up, return it, buy something a bit more expensive from Netgear. Talked Mum through installing that, no need for WiFi just yet, job done.

    Fast-forward to last weekend when my sister rocked up wanting to use the WiFi. No problem, I thought (you’d think I’d know better by now…) – the router is configured with the same network name and password as the last one, so it should Just Work.

    Guess what, it didn’t. So I stepped into the breach, fired up Vista on her machine, point it at the right access point, find it asking me for a PIN. Gah? Turns out that since I last played with this stuff, WiFi protected setup has been invented. And for sure, it sounds like a good idea, but in this case, I don’t want it. Please just let me specify the password by hand. Vista, as far as I can tell, won’t let you do this.

    OK, disable WPS on the router, change the network name to make devices forget everything they think they know about it, try again. “Wireless authentication failed because of a timeout”. And no further progress was possible. Much Googling suggests that the Atheros wireless chipset in the laptop is incompatible with certain Netgear routers, and nobody has a solution to this.

    Great. At this point, the urge to throw all  the blasted computers out of the nearest window was strong enough that I decided it would be a good time to hand my sister the 100 metre Ethernet cable and give up. And it was at this point that Mum wandered in and said “the internet isn’t working”.

    Sure enough, the desktop PC had lost its connection. What’s more, it had lost all knowlege of containing a network card, and no amount of poking, prodding or re-seating would make it work. It still had flashing lights on the back, but nobody was home.

    It was at this point that I looked up from the screen with bleary eyes and realized I had to be back at work in the morning.

    I’m not really interested in aportioning blame for all this, but I do find it depressing that after 10 years, WiFi is still about as friendly as a cornered rat when it goes wrong, and badly implemented all over the place.

    SysAdmin stuff

    It’s amazing how many fewer afternoons I seem to spend hacking around on my servers these days. Perhaps I got a life; I certainly got a full-time job. I have however sorted a few long-standing bits and pieces out today…

    dnorth.net is now available over IPv6

    As are its various satelite sites and www.saintcolumbas.org. Sorry, no, there is no bouncing logo to reward those of you viewing them via such.

    A backup system that doesn’t Totally Suck

    I’ve finally retired my creaking “run a shell script to rsync them onto my laptop when I remember (i.e. every six months)” manaul backup system in favour of an encrypted LVM partition on my home server, and rdiff-backup to make nice incremental backups of everything on a nightly basis. The instructions on how to do it are all out there on the interweb, and it’s not too difficult, fortunately. I’m a bit disappointed that backupninja doesn’t support remote rdiff-backup, but I guess I should submit a patch if it bothers me that much…meanwhile, my wrapper script seems to work just fine.

    mod_wsgi delivers on the promise

    It’s been over a year since I deployed Django in production, and I wasn’t looking forward to it. Last time, I had a lot of trouble with mod_python, sessions and decimal objects refuising to pickle.

    Thankfully, all this really seems to have grown up in the last year – mod_wsgi is now the recommended way of deploying Django in production, and following the mod_wsgi django instructions, I was in business in 20 minutes. No fuss, no mess, no drama, and best of all, using daemon mode, no noticeable performance hit when serving static files and PHP off the same Apache installation. The ability to run the django project as its own unprivileged user when using daemon mode is also real handy.

    Powered by WordPress | Theme: Motion by 85ideas.