LTSP 5 local devices fun

Been working on using LTSP 5 on a Kubuntu machine to replace our current LTSP 4 set up on debian. Part of this has been about getting local devices operational which, on the whole, works "out of the box" with the (k)ubuntu ltsp packages. The local devices appear under /media/ - which you could create a symlink to on the desktop for the users to easily access their devices.

However, I plugged in one of my USB memory sticks and nothing happened. So I went through the debugging routine:
Check that the device is partitioned (/dev/sdb1 rather than just /dev/sdb when plugged into my linux laptop)
Check that the ltsp workstation is seeing the device by logging into the local shell as root and using dmesg after plugging it in
Check the udev stuff is happening (look for an entry in /var/run/ltspfs_fstab)

That was where it was failing - no entry.

So I dug around in the udev rules and looked at the script that adds the entry to the fstab. Here was the source of the problem. This script uses the label on the volume to create the mount point and the volume label on my usb stick had a space in it - that was enough to prevent it from running the script properly.

So - if you want your removable media to work on a (k)ubuntu LTSP set up then make sure that any volume labels are without spaces.

Exim SMTP AUTH from LDAP

This turned out to be very simple indeed.

Here's a suitable config for LOGIN and PLAIN type auth:

ldap_login:
 driver = plaintext
 public_name = LOGIN
 server_prompts = Username:: : Password::
 server_condition = ${if ldapauth {user="uid=${quote_ldap:$1},ou=Users,dc=....." pass="$2" ldap://localhost/}{yes}{no}}
 server_set_id = $1
 server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}

ldap_plain:
 driver = plaintext
 public_name = PLAIN
 server_prompts = :
 server_condition = ${if ldapauth {user="uid=${quote_ldap:$2},ou=Users,dc=...." pass="$3" ldap://localhost/}{yes}{no}}
 server_set_id = $2
 server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}

The bit which wasn't explained very well (or at least not obvious to me) was what ldapauth did. There were various examples around which were pulling passwords out of a directory, having logged in with a suitable dn, but what this simple solution does is attempt to log into the LDAP directory using the credentials that "user" and "pass" are set to and since the LDAP directory contains the user authentication data as used by other systems (such as PAM or the unix NSS) it is authenticating against exactly the same thing.

This method won't work with the cram_md5 authentication driver as that requires a password to be pulled from somewhere and given to exim to work with.

Migrating users from shadow / tdbsam data to LDAP

This is still a work in progress at present, but I'm working on the migration of a set of user accounts from the traditional Linux shadow / Samba tdbsam back ends into an LDAP directory. This should result in a set up with much tidier administration and better sharing of credentials between servers.

A rough summary so far:
Installed slapd and samba and (I'm using Debian etch) the samba-doc package
Installed the smbldap-tools package

Added the samba.schema from the samba-doc package to the ldap config and amended the indices and permissions.

index objectClass,uidNumber,gidNumber,entryUUID,entryCSN eq
index cn,sn,uid,displayName pres,sub,eq
index memberUid,mail,givenname eq,subinitial
index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq


access to attrs=userPassword,shadowLastChange,SambaLMPassword,SambaNTPassword
by dn="cn=......" write
by anonymous auth
by self write
by * none


Got the domain SID and set up the smbldap-tools with appropriate defaults and done the base population of the LDAP directory with smbldap-populate

Amended samba to talk to the ldap directory

passdb backend = ldapsam:ldap://127.0.0.1/
ldap admin dn = cn=.......
ldap delete dn = Yes
ldap user suffix = ou=Users
ldap group suffix = ou=Groups
ldap machine suffix = ou=Machines
ldap passwd sync = Yes
ldap suffix = dc=.......
ldap ssl = no

and add references to the tools to make user admin simple (we like simple!)

add user script = /usr/sbin/smbldap-useradd -m "%u"
delete user script = /usr/sbin/smbldap-userdel "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
delete group script = /usr/sbin/smbldap-groupdel "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"

(one strange thing above is in the add user script - you may expect to include the -a option - which says this is a Samba account. This is only needed from the command line. Here we're after creating just the posix account and then Samba will separately add the extra bits to make it a Samba account. If you have the -a option in then trying to use the NT user manager will result in "a device attached to the system is not functioning" coming up when you try to add a user.)

Install libnss-ldap and libpam-ldap

Update /etc/nsswitch.conf to use "files ldap" for passwd, group and shadow

Amend the common-* PAM files as follows:

#
# /etc/pam.d/common-account - authorization settings common to all services
#
account sufficient pam_ldap.so
account required pam_unix.so

#
# /etc/pam.d/common-auth - authentication settings common to all services
#
auth sufficient pam_ldap.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required pam_deny.so

#
# /etc/pam.d/common-password - password-related modules common to all services
#

password sufficient pam_ldap.so
password sufficient pam_unix.so nullok obscure min=4 max=8 md5 use_first_pass use_authtok
password required pam_deny.so

#
# /etc/pam.d/common-session - session-related modules common to all services
#

session sufficient pam_ldap.so
session required pam_unix.so


For the main migration, the tools of interest are smbldap-migrate-unix-accounts, smbldap-migrate-unix-groups and pdbedit in that order. The first two are in the examples area of the documentation for smbldap-tools, gzipped by default, so you need to uncompress them and make them executable.

Take a copy of the old password and shadow files. Edit it down to just the accounts you want in LDAP (including taking machine accounts out). Then do

/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-accounts -P temp -S temp
/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-groups -G temp

This pulls all the unix stuff in.

Then pdbedit -i tdbsam -e ldapsam (presuming your old passwd.tdb file is still in the same place and Samba is configured to talk to the LDAP server) will pull in the Samba attributes and passwords of the old Samba accounts (including machines).

The next trick I'm working on is getting exim to talk to the LDAP server for SMTP AUTH

Fixing a broken grub MBR with LVM / and /usr

Following a power cut, a friend of mine found that he couldn't boot his Debian etch machine. It appeared that some traces of lilo were still lurking on the machine and had messed up the MBR during a kernel upgrade. As the partitions with the exception of /boot were in LVM volumes, it made the task of recovering the MBR a little more involved.

Here is the procedure we followed:

Boot from a Debian install CD into rescue mode and after following all the prompts get a shell on the system root
Copy the current fstab to fstab.safe (we need this to get the file system back in order later)
Re-boot from the Debian install CD, this time going through the normal route.
At the partition disks prompt, choose Manual.
Then choose the "Configure Logical Volume Manager" option.
Choose to keep the current config and activate the current volume group.
Pick finished to go back to the partitioner.
In the list of partitions, find the root and usr partitions and select each of them in turn option to use them as ext3 file systems with the appropriate mount point.
Choose the write changes to disk option. The installer should say it is going to format the swap partition and nothing else. If it says it is going to format anything else then go back and check how you have configured that partition.
When it brings up the message about an unclean system, use Alt-F2 to switch to the second console
Press enter to access the shell and type "chroot /target"
You are now in your original file system.
Mount the boot file system (probably with either mount /dev/sda1 /boot or mount /dev/hda1 /boot depending on your disks)
Now you can re-initialise grub with grub-install /dev/sda1 (or /dev/hda1) and use update-grub to ensure the menus are built.
Finally cd into /etc and copy your safe copy of fstab back over the one which the installer will have written out for you.
Then Ctrl-Alt-Del and you should be able to boot happily back into your original system.

Night service on an LG GDK phone system

Working just from the Installation Manual for an LG GDK-FP II / GDK-34i phone system, I had to restore the night service button to the reception console.

In this particular installation, the reception console is only an 8 flex button handset and if you swap it for a larger one and then put the 8 button one back, the flex button that was assigned to night service stops working.

The trick is to program the button to be a USER button:

PGM * # PGM 29 100100 {Flex button} 1 HOLD/SAVE

From the programming station.

Then on the reception console, press

PGM {Flex button} PGM 93 HOLD/SAVE

PGM 93 is described as [DND/FWD] BTN Assignment in the manual. Manual night service is effectively the DND button on the attendant console - though the 8 flex button handsets don't have a DND button to begin with (rather poor if you ask me!)

In general I've found it very hard work getting info about LG systems - pretty much no documentation available on the net - so having a copy of the intallation manual (which is incredibly terse) is very helpful!

NVidia linux driver fun

The desktop I use has an nVidia graphics card for which I use the enhanced Linux nVidia driver (on a Debian lenny machine). All was OK until a recent apt-get upgrade at which point the glx stuff stopped working. I had been using one of the GL screen savers and as soon as that started X crashed!

The answer was that the update had replaced the libglx.so library with a stock one, overwriting the nVidia custom one.

Simple answer - move /usr/lib/xorg/modules/extensions/libglx.so out of the way and put in a symlink from the nVidia one which was lurking at /usr/lib/xorg/modules/extensions/libglx.so.100.14.19

Restart X and all is happy again :)

Joining a Ubuntu / Kubuntu machine to an NIS domain with NFS shared home

Over the past few years, I have usually used Debian as my Linux distro of choice. The server on which our users are set up is sharing the login details with NIS and the home directories are shared by NFS.

This are then picked up by other servers such as our mail server and our LTSP server.

Having tried Kubuntu (the KDE based version of Ubuntu) for a while, I'm considering moving our LTSP server to that distribution as the user facing packages are all more up to date than you get with Debian.

There's a couple of "gotchas" in doing this.

First off, Ubuntu uses sudo rather than letting you log on directly as root. This means that you are always first of all logged on as a real user - who is then using files on /home - meaning that you can't easily NFS mount /home.

My solution to this was to boot to recovery mode which does give you a shell as root, then move /home to /localhome and amend /etc/passwd accordingly for the local user that was created during setup. Incidentally, I also made sure that this local user was not the same name or ID as any users that our main server has.

Next you install the nis stuff - and here's where the networking becomes interesting. The Network Manager doesn't bring the interface up properly once you're joined to an NIS domain - unless you explicitly set the interface to be "auto" - so /etc/network/interfaces looks like:

auto lo
iface lo inet loopback
address 127.0.0.1
netmask 255.0.0.0


iface eth0 inet dhcp

auto eth0


This ensures that the interface comes up before the machine attempts to join the NIS domain and so it is able to do so.


You then do the usual adding of +:::::: to /etc/passwd and similar to /etc/shadow, /etc/group and /etc/gshadow and the users become visible.

Add a suitable NFS mount for /home and lo and behold they can log in and see their files.