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.

You may recall my terrible trinity of problems.

1. My Windows roaming profile won’t sync when I log out.

2. Windows tells me my password has expired (which it hasn’t) when I log in.

3. I can’t mount a Windows share from a UNIX machine when the Windows server is part of a domain. I can mount a non-domain Windows share, I can mount a Samba share and I can connect to a domain share with smbclient but not with mount.cifs, smbmount or mount_smbfs.

Problem 1 was fixed a while ago. Problem 2 is still a thorn in my side but problem 3 has now gone away.

I decided I’d have yet another look on Google for details of the problem. I got halfway through typing in my search query when I realised I couldn’t remember the error code mount.cifs gave when failing to mount a Windows machine. So I tried to mount from my Linux box.

And it worked.

Then I tried from my iMac. It worked again.

I have no idea why but it works. Maybe Microsoft patched something with a recent Windows fix. Maybe the Samba team patched something in Samba 3.0.28, to which I upgraded only yesterday. Maybe it was Solar flares.

Whatever the reason, I’m happy.

For now.

I finally got round to trying the iCal server again. Previously it was complaining that no virtual host could be found for iCal service. The solution is to create a Computer record in OpenDirectory whose name is the iCal server’s hostname followed by a dollar. For example ical$. It then all magically works despite there being nothing to do with iCal, virtual hosts or anything remotely resembling the error message in this new record.

And where have we seen hostnames followed by dollar signs before?

That’s right. Samba machine accounts.

And what attributes does Directory Utility.app allow us to map for Computer records?

Samba attributes.

Further research could prove interesting.

Oh and by the way the calendar still doesn’t work for reasons I’ll describe once I’ve fixed it.