2008-01-20

I got a QNAP

Filed under: Geekiness — iain @ 13:12:44

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

More on Leopard’s automounter

Filed under: Geekiness — iain @ 11:58:09

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.

Powered by WordPress