Some weeks ago Fedora 12 obsoleted linuxwacom and replaced it with xorg-x11-drv-wacom which apparently is a brand new XInput-based driver for Wacom tablets.

Immediately this caused me great pain and suffering as TPCButton mode, ie the thing where you hold a side button and tap the pen to do a click, stopped working and my side buttons were swapped round.

Rather than take the time to figure out what had happened I simply removed the xorg-x11-drv-wacom RPM and force installed the old linuxwacom to restore the status quo.

Last week, however, I forgot to exclude xorg-x11-drv-wacom from the list of packages NOT to be updated by YUM and lo and behold the RPM was installed again. This time I decided to get it working properly by reading the documentation about the transition.

Ha! Only kidding. There isn’t any documentation. So by trial and error – which is usually how these thing work – I managed to figure out what was going on.

With the old driver you added InputDevice sections to xorg.conf to declare the tablet devices and map them to /dev/input entries in the filesystem. You could then add options to these sections or use xsetwacom to set them on the fly.

Turns out you can still use xsetwacom. It’s just that the device names in your xorg.conf aren’t used any longer. I used xinput --list to enumerate the XInput devices on my display and found that four Wacom devices were present of which the most important was Wacom Intuos3 6×11. Since xsetwacom still works I was able to get my button swapping back by doing

    xsetwacom --set 'Wacom Intuos3 6x11' Button2 3
    xsetwacom --set 'Wacom Intuos3 6x11' Button3 2

The "correct" way to do so, however, is to run xinput --get-button-map 'Wacom Intuos3 6x11' and note that the buttons are interpreted as 1 2 3 4 5 6 7 and, since I wanted to swap 2 and 3, do

    xinput --set-button-map 'Wacom Intuos3 6x11' 1 3 2

TPCButton mode was previously set by doing xsetwacom --set <device> TPCButton on and at first I thought this was broken as I ran xsetwacom --set 'Wacom Intuos3 6x11' TPCButton on and nothing happened. A bit more digging (with xinput --list-props 'Wacom Intuos3 6x11') revealed why: the property has been renamed Wacom Hover Click and defaults to on. In other words when hover click is on you don’t need to tap in order to do a click with the side buttons. So to get the mode I wanted I could do either of the following:

    xsetwacom --set 'Wacom Intuos3 6x11' TPCButton off
    xinput --set-prop 'Wacom Intuos3 6x11' 'Wacom Hover Click' 0

Running xinput --list-props 'Wacom Intuos3 6x11' reveals the other editable properties, some of which have also been renamed.

If you’re following along from home remember that your device won’t be called Wacom Intuos3 6×11 unless it is, in fact, a Wacom Intuos3 6×11 (and maybe not even then).

Happy tabletting.

Logitech’s G13 is their much-hyped answer to the Nostromo SpeedPad and competitors. It was released in December to great fanfare so although I have been very happy with my SpeedPad n52 for many years now I was intrigued enough by the G13′s feature list that I decided I was prepared to pay the not-inconsiderable asking price to check it out.

The G13 is certainly not cheap. With an RRP of £79.99 it is unlikely to appeal much to people who don’t already own a similar device. In order to justify the expense it needed to be a significant improvement over the n52 and really deliver on its promised features.

Instead I found it to be a spectacular disappointment.

(more…)

The iPhone 2.2 firmware has been available for a while now but I’d thus far resisted the urge to upgrade because I’d heavily customised my jailbroken phone with my own sound effects, ringtones and Winterboard settings.

Official Apple stuff is backed up and restored after an upgrade but I knew I’d lose the personalised changes.

I decided to use Subversion to archive my tweaks and restore them after the upgrade. The exact steps I used aren’t precisely the same as I’ll describe here. I’ll change the description to be easier to follow along for people with no experience using Subversion before.

(more…)

Everyone in the office is doing it and I didn’t want to be left out so I downloaded VMware ESXi, intending to run it on a machine with an ASUS M2N-SLI motherboard.

As that machine was in use, I tested out ESXi on an older ASUS A8N-SLI board. In many ways the M2N-SLI is an evolution of the A8N-SLI so when ESXi installed and ran on the older hardware I was confident that it would work on the newer board too.

Not so.

Although ESXi worked when booted from a USB stick, the installer refused to run because it couldn’t find any supported disks. Clearly my SATA controller must be supported or the USB version wouldn’t be able to see the disks and create datastores, which it could.

The solution? I installed ESXi and created datastores on the A8N-SLI and simply unplugged the disks and plugged them in the M2N-SLI. Pleasingly the system booted first time and apart from telling it to use the (different) NIC on the new machine I didn’t have to do anything to get it working.

There I was minding my own business when my iMac suddenly complained that it had lost my home directory. At about the same time I began to hear an ominous clicking sound from the direction of my QNAP. After a few minutes this went away and was replaced by a loud beep. At that point the Mac popped back to life and I was able to ssh to the QNAP.

Rut roh! Looks like one of the disks in my RAID1 has croaked.

    SCSI error : <0 0 0 0> return code = 0x8000002
    sda: Current: sense key=0x3
        ASC=0x0 ASCQ=0x0
    Info fld=0xcbd60ed
    end_request: I/O error, dev sda, sector 213737708

    md: unbind
    md: export_rdev(sda1)
    raid1: Disk failure on sda4, disabling device. 
    	Operation continuing on 1 devices
    RAID1 conf printout:
     --- wd:1 rd:2
     disk 0, wo:0, o:1, dev:sdb4
     disk 1, wo:1, o:0, dev:sda4

QNAP’s website says they will replace faulty kit free of charge so I hope to be back up and running properly again soon.

/var/ldap/ldap_client_file needs to contain:

    NS_LDAP_AUTH= tls:simple
    NS_LDAP_CREDENTIAL_LEVEL= proxy

/var/ldap/ldap_client_cred needs to contain:

    NS_LDAP_BINDDN= 
    NS_LDAP_BINDPASSWD= 
    NS_LDAP_HOST_CERTPATH= 

And here’s the non-obvious (and most important) step. You need to set up the above-referenced certificate store. Assuming your CA certificate is in /etc/sfw/openssl/certs/ca.crt and you set NS_LDAP_HOST_CERTPATH= /var/ldap (which is actually the default location), you need to do this:

    # certutil -A -a -i /etc/sfw/openssl/certs/ca.crt -n RootCA -t CT -d /var/ldap

The Solaris 10 LDAP client stores its credentials in the file /var/ldap/ldap_client_cred. The password is hashed using NS1 format. The correct hash for your password is created for you when you use ldapclient to generate the configuration but if you simply wish to change the credentials without running that tool you have to jump through a few hoops.

One suggested solution is to find a Solaris 8 system and use the LDAP configuration tools from there, as one option allows you to dump a profile to stdout without applying it. This is a bit of a hassle if you have a Solaris 8 system and not much use if you don’t.

Now that Solaris is Open Source it’s much easier to create an NS1 hash. We can build our own tool straight form the horse’s mouth.

libsldap has the code we need. At time of writing it’s available from the OpenSolaris project. Download the three files ns_internal.h, ns_sldap.h and ns_crypt.c. On a Solaris 10 system the ns_crypt.c file can be compiled without any changes.

    $ gcc -I . -c ns_crypt.c

On Linux we can make a few tweaks to the code in order to compile it.

• In ns_crypt.c:
  • Comment out all lines referring to ns_crypt_lock.
• In ns_internal.h:
  • Comment out the line #include <thread.h>.
  • Comment out all lines referring to thread_t.
  • Comment out all lines referring to mutex_t.
• In ns_sldap.h:
  • Add the following lines above #include <stdio.h>:

      typedef unsigned int uint_t;
      typedef unsigned char boolean_t;
      #define B_TRUE 1
      #define B_FALSE 0

Now save the following as main.c.

    #include "ns_sldap.h"
    #include "ns_internal.h"
    
    static int is_cleartext(const char *pwd) {
        return strncmp(pwd, CRYPTMARK, strlen(CRYPTMARK));
    }
    
    int main(int argc, char **argv) {
      if (argc == 1) {
        fprintf(stderr, "Usage: ns1 <hash>\n");
        fprintf(stderr, "Usage: ns1 <plaintext>\n");
        exit(1);
      }
    
      if (is_cleartext(argv[1])) printf("%s\n", evalue(argv[1]));
      else printf("%s\n", dvalue(argv[1]));
      exit(0);
    }

Compile ns1.c:

    $ gcc -I . -c ns1.c

And finally link the two object files.

    $ gcc -o ns1 ns1.o ns_crypt.o

You may need to add -lcrypt to the above on Linux.

With the tool we just compiled we can make some NS1 hashes.

    $ ./ns1 my_secret_password
    {NS1}c2ab9ff37b69c4b5a665a2b15d003bba0779
    $ ./ns1 {NS1}c2ab9ff37b69c4b5a665a2b15d003bba0779
    my_secret_password

I already knew how to save the LDAP config back to the LDAP server and initialise a client using Directory Utility.app. That works well and is easy to understand. Unfortunately it requires using the GUI. It’s hard to script GUIs. I also already knew which files were changed when configuring DirectoryService so it shouldn’t be too hard to automate the process.

Configuring LDAP requires two steps. First you tell the DirectoryService LDAPv3 plugin about your server then you add LDAP to the search node list.

The first file edited is /Library/Preferences/DirectoryService/DSLDAPv3PlugInConfig.plist. It’s created whether you use the Advanced section of the GUI to configure the server manually or just pull everything from ou=macosxodconfig. Read the linked articles if the above makes no sense.

Simply copying a working configuration file from somewhere else is possible and in an environment with lots of identically-configured machines it may even be desirable. You may not necessarily want to do it, however, if you have other LDAP servers, NIS server, OpenDirectory servers, Active Directory servers etc already configured on a particular machine. This was the case for my OS X Server machine, for example. Luckily we can script the addition of the LDAP profile.

    # dsconfigldap -a ldap.iain.cx

If you’ve already written the configuration back to the LDAP server, the above is all that’s needed to tell the workstation about it.

The second file, which determines whether or not the LDAP service is consulted for authentication, is /Library/Preferences/DirectoryService/SearchNodeConfig.plist. Because it’s a small file it’s easy to use Perl, cfengine or $YOUR_FAVOURITE_SCRIPTING_TOOL to add the correct lines viz:

            <key>Search Node Custom Path Array</key>
            <array>
                    <string>/LDAPv3/ldap.iain.cx</string>
            </array>

    ...

            <key>Search Policy</key>
            <integer>3</integer>

Exercise for the reader: you could use defaults to do it.

It seems the Search Policy=3 section is needed to set a Custom search path (ie actually using the settings we’ve configured).

Aside: If your LDAP schema includes contact details you can also configure ContactsNodeConfig.plist in the same way.

Once the proplists have been edited you simply kill DirectoryService and wait for it to be automagically restarted. Everything should then Just Work!

To confirm this:

   # dscacheutil -configuration
    DirectoryService Cache search policy:
        /Local/Default
        /BSD/local
        /LDAPv3/ldap.iain.cx

I bought a QNAP TS-209 Pro NAS in the hope of reducing the load on my fileserver a little bit. The TS-209 comes with a bunch of features (though I won’t use many of these) including, notably, NFS and CIFS support. Sadly, the latter was the one thing which didn’t work perfectly first time, as everything else on this very nice little unit did. I was given the option of participating in a Windows Workgroup or joining an Active Directory domain but there was no option to do an RPC join. This is a problem as my domain controller is the aforementioned fileserver.

Not to worry, though. One of my reasons for buying this particular unit was that it is an embedded Linux system with SSH access. Let’s have a look inside.

    [~] # find /etc -name smb.conf
    /etc/smb.conf
    /etc/default_config/smb.conf

So if I edit the smb.conf and configure the domain I should be able to join it.

    [~] # net join
    -sh: net: command not found

Ah. Where’s Samba?

    [~] # ps waux | grep smbd
     1020 admin      2920 S   /usr/local/samba/sbin/smbd -D

Let’s try this then.

    [~] # /usr/local/samba/bin/net join
    Joined domain CAMBRIDGE.

Great! But there’s one problem. Without knowledge of my LDAP accounts the QNAP won’t be able to assign consistent UIDs to Samba connections and there’s no nss_ldap installed. Let’s poke some more.

Although the guts of the TS-209 comprise an embedded distribution, the device ships with a basic install of Debian Etch on /share/MD0_DATA/etch. If we chroot into it we should be able to install the LDAP libraries.

    [~] # chroot /share/MD0_DATA/etch
    [~] # apt-get update
    ...
    [~] # apt-get install libnss-ldap

Unfortunately the C libraries used by the Etch install and the embedded OS outside the chroot don’t match so I couldn’t just use the new libnss_ldap.so.2. So how about I disable Samba from the QNAP web interface and apt-get Samba inside the chroot?

There’s one more hurdle. The QNAP puts shares you create under /share/MD0_DATA which is outside the chroot. A bind mount fixes this.

    [~] # mkdir -p /share/MD0_DATA/export/home
    [~] # mount -o bind /share/MD0_DATA/home /share/MD0_DATA/export/home

Samba inside the chroot can be configured to share out /export/home.

This is all very well except Samba won’t start on reboot because the Etch init scripts won’t be run. Some investigation revealed that the QNAP runs two sets of startup scripts stored inside the chroot.

1. Scripts in /share/MD0_DATA/etch/ext/extchroot-bin are run outside the chroot.

2. Scripts in /share/MD0_DATA/etch/ext/bin are then run inside the chroot.

So the solution is very simple.

/share/MD0_DATA/etch/ext/extchroot-bin/S00-export.sh:

    #!/bin/sh
    DATA=/share/MD0_DATA
    EXPORT=$DATA/etch/export
    
    for share in home files smb; do
      mkdir -p $EXPORT/$share
      mount -o bind $DATA/$share $EXPORT/$share
    done

/share/MD0_DATA/etch/ext/bin/020-services.sh:

    #!/bin/sh
    /etc/init.d/samba start

I had the Leopard automounter more or less working happily but there was one setback. A combination of Finder’s and Office’s braindead behaviour was triggering many many automount lookups which showed in the LDAP logs:

    filter="(&(|(objectClass=automount))(|(automountKey=.DS_Store)))"
    filter="(&(|(objectClass=automount))(|(automountKey=.hidden)))"
    filter="(&(|(objectClass=automount))(|(automountKey=\2A)))"
    filter="(&(|(objectClass=automount))(|(automountKey=\2A)))"

This was because the Mac wanted to see what was under /home, on which home directories were automounted. It would be annoying if all it did was fill my LDAP logs with this spam. When the automounter causes Rebecca’s machine to kernel panic once every few days, it gets extremely tiresome.

My response to this was to change the automount rules so that /home was managed by auto_static instead of auto_home.

    dn: automountKey=/home,automountMapName=auto_static,ou=mounts,dc=iain,dc=cx
    objectClass: top
    objectClass: automount
    automountKey: /home
    automountInformation: -fstype=nfs,tcp,rw,intr files:/home

On the Linux clients this worked. The Macs, however, were having none of it. With this setup /home was completely inaccessible. All attempts to look at the directory, even ls -ld failed with Permission Denied. The solution is to comment out the /home line in /etc/auto_master.

As a poster in the above thread puts it, sigh.