/dev/otmar

Now that Andrea owns a Mac again it was overdue to get iSync up and running with her Phone.

iSync is nice, but her Nokia 2680 is neither supported by the 10.7 iSync, nor does Nokia provide a suitable plugin. Luckily, there are alternatives. Paul Bain has published a few plugins on his blog, including one for the 3600 Slide. According to one of the comments, that should be pretty easy to adapt for the 2680s.

Installing the plugin and replacing all occurrences of “3600 Slide” with “2680s” was simple, but it didn’t work: iSync still complained about an “unsupported phone”.

The solution became apparent when looking at the log in /var/log: the phone is actually a “2680s-2″, and once I got the strings right, iSync was happy.

To make things easier for others trying to replicate this, here is a zip of the my resulting plugin. (And I hope plain zip did the job, and I’m not running into some macos resource fork & co weirdness.)

HTH.

I’ve been trying to adapt the offline plugin to our needs. Here are my changes:

offine.diff

Caveats:

• It clashes with how “datadir” is set in the example in the security page. That field must not contain a trailing ‘/’.
• The plugin should remove the .zip file before adding files to it to avoid obsolete files accumulating there.

I recently got a request for help concerning the generation of ENUM Validation Tokens according to RFC 5105.

In order to check what went wrong, I had to re-install the software I used while writing that RFC. That wasn’t so easy as the upgrade from Xerces 2 to Xerces 3 made a few changes to the XML Signing module necessary:

(more…)

I’ve just uploaded mod_epp 1.7 to sourceforge.net.

Thanks to CentralNIC for funding the debugging effort.

(And no, there will no picture of me with a brown paper bag over my head on this blog. But yes, that bug was stupid.)

Just a quick remark: a “aptitude install ddd” showed that this package depended on lesstif2 which is an Open Source re-implementation of the Motif GUI library.

Most of the reader here will never have heard about Motif.

Back when I started working with X, there were two competing GUI standards: OpenLook and Motif. Free Software (the term Open Source wasn’t invented yet) stuck to the basic Athena Widgets or (later) used Tk. Despite the strict licensing scheme of Motif some projects (e.g. the original Mosaic Browser) went with Motif nevertheless — motivating the Lesstif project.

It could have owned the Unix GUI market, but it wasn’t compatible with free software, so it lost the battle for developer mindshare and fell into obscurity. Qt almost made the same mistake, but they were a bit more liberal in the beginning and as GTK took off, they had to open up even more to stay relevant.

In other words, the decision not to support free software with Motif killed it.

I’m doing a bit of network monitoring with SNMP again, and stumbled upon yet another cisco SNMP bug. Back when I wrote the pan-european NMS for KPNQwest, I had to work-around a good number of bugs in the IOS snmp agent, but this time it’s a bug in the MIB file:

Using the CISCO-BGP4-MIB, I can graph the state of my BGP peerings. All fine, when looking at

    CbgpPeerAddrFamilyPrefixEntry ::= SEQUENCE {
        cbgpPeerAcceptedPrefixes        Counter32,
        cbgpPeerDeniedPrefixes          Gauge32,
        cbgpPeerPrefixAdminLimit        Unsigned32,
        cbgpPeerPrefixThreshold         Unsigned32,
        cbgpPeerPrefixClearThreshold    Unsigned32,
        cbgpPeerAdvertisedPrefixes      Gauge32,
        cbgpPeerSuppressedPrefixes      Gauge32,
        cbgpPeerWithdrawnPrefixes       Gauge32
        }

you notice that the Gauge32 vs. Counter32 types are mixed up.

cbgpPeerAcceptedPrefixes is the only Gauge here, whereas cbgpPeerDeniedPrefixes, cbgpPeerAdvertisedPrefixes, cbgpPeerSuppressedPrefixes and cbgpPeerWithdrawnPrefixes are actually Counters, e.g.

    cbgpPeerWithdrawnPrefixes  OBJECT-TYPE
        SYNTAX      Gauge32
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
                "This counter is incremented when a route prefix,
                 which belongs to an address family, is withdrawn on
                 this connection. It is initialized to zero when the
                 connection is undergone a hard reset."
        ::= { cbgpPeerAddrFamilyPrefixEntry 8 }

Initially, Windows 7 looked nice. But the longer I worked with it, it’s starting to show the usual Windows cruft:

I already wrote about the empty lists within Windows Update. Yes, that still happens.

Hibernate does not work.

And now I tried to setup a backup, and ended up with:

I recently got contacted by SIDN regarding some problems with mod_epp. They were running into issues when combining mod_epp with mod_proxy and needed me to find a fix. We came to an agreement, I spend some time programming C again, and here it is: mod_epp version 1.6.

Changes:


* Bugfix: Internal EPP error messages work again
* Default value for EPPAuthURI
* New config statement: EPPReturncodeHeader
- Backend can signal EPP RC to mod_epp
* New feature: implicit login
- EPPAuthURI = implicit
- no special request to authenticate
- uses either HTTP error code or via EPPReturncodeHeader
of the command.
* New feature: User-Agent: header set
* Bufix/Feature: Connection close now works on mod_proxy
- X-Connection
- via EPP return code

* A mod_proxy setup is now fully supported. See README.

Get it here.

As mentioned before, I disabled xen before the etch->lenny upgrade. Now I’ve re-enabled xen, and the following bits may be of wider interest:

My server at the Hetzner hosting center has one static IP address and a small network that is routed towards that IP address. So my plan was to use this small network (88.198.160.176/28) for the virtual switch inside the xen Dom0 and connect all the domUs to it. I solved this the following way:

In /etc/network/interfaces I tell Debian to create the bridge and use br0 as the interface of the dom0 into that bridge:

auto br0
iface br0 inet static
        pre-up brctl addbr br0
        address 88.198.160.177
        netmask 255.255.255.248
        bridge_fd 0
        bridge_hello 0
        bridge_stp off

That way, the xen scripts themselves have little to do. The settings in /etc/xen/xend-config.sxp are:

(vif-script 'vif-bridge bridge=br0')
(network-script network-route)

In the config-file for each individual domU, I just use something like

vif  = [ 'ip=88.198.160.178,mac=00:16:3e:77:e2:79,bridge=br0' ]

but I’m not sure whether that’s actually needed at this point.

Concerning the domUs: The hints in the Debian Wiki were helpful, especially about changes to the console handling.

Just in case somebody was wondering why this blog was down over the weekend:

I finally bit the bullet and upgraded my server from Debian etch to Debian lenny. And while doing that ran into Bug #541371.

Otherwise the upgrade was pretty painless. But as timid (some might say sane) as I am, I disabled xen before the upgrade. Getting that up and running with a new kernel will be the next step. This is especially tricky as I do not have a remote console, just the Hetzner rescue system.

Oh, and as I’m no longer running a pre-historic wordpress, this blog might get a new design sooner than later.