Flashing the firmware on a 3c905c network card

There's two revisions of the 3C905C out there. The earlier one has an issue when using boot code on the card in that you can't make use of the "next server" option in your dhcp config - it simply fails to boot from the correct server reporting a timeout during the TFTP.

The later version works fine - so here's the trick - take the firmware from a later one and flash it to the earlier.

Using a debian box this is relatively simple.

Install the etherboot package to get the tools needed.

Then in /usr/share/doc/etherboot/contrib/3c90xutil/ gunzup cromutil.c.gz and bromutil.c.gz

Make sure you have built-essential on your system and then use make to compile the tools

Now, with the good card in the system, do

lspci -v | less

and look for the ethernet controller. Make a note of it's I/O port address (ours was a000

Then to get the rom image type

./cromutil [ioport] read > [imagename]

e.g.

./cromutil a000 read > working.rom

Now shut down the machine and replace the good card with the one that needs programming

Once you've booted back up, go to /usr/share/doc/etherboot/3x90xutil/

Use lspci -v again to check the address of this card

Then do

./cromutil [ioport] erase
./cromutil [ioport] prog < [imagename]

You should now have a card programmed with the later firmware and capable of correct remote booting where the boot host is other than the dhcp host.

Using LDAP for email aliases

As I gradually migrate various servers to using LDAP as the auth back end, it occured to me that there was some duplication going on in terms of adding the users' email addresses to the LDAP so that they could be looked up on clients and then having an aliases file that was being used by exim to do the delivery.

So I've come up with the following for allowing exim to take advantage of the email addresses stored in the LDAP database:

### router/450_local_ldap_aliases
#################################

# This router handles aliasing looking up email addresses in an ldap database.
#

ldap_aliases:
debug_print = "R: ldap_aliases for $local_part@$domain"
driver = redirect
domains = +local_domains
allow_fail
allow_defer
data = ${lookup ldap {ldap://127.0.0.1/ou=Users,dc=...?uid?sub?(mail=$local_part@$domain)}}

Ubuntu on a Dell XPS M1530

With the release of Ubuntu 8.10 (Intrepid Ibex) the vast majority of stuff on a Dell XPS M1530 works out of the box. One caveat is the touchpad. It jumps around like a demented rabbit!

The solution is simple.

Edit /boot/grub/menu.lst

Find the line that starts
# kopt=root=UUID....

Add i8042.nomux=1 to the end of that line

Then run update-grub and reboot.

Office 97 as a normal user

Usually when you put a Windows XP machine on a user's desktop you want to have them logging in as a standard user rather than a power user. However various bits of software have issues with that due to poor design of the way they handle the registry. They try to write to keys or create keys in areas that they don't have permission.

One such delight is Office 97. There are two specific problems. Firstly, spelling and grammar checking is disabled. This has to be fixed with a registry permissions edit.

HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Proofing Tools\Spelling

HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Proofing Tools\Grammar

both need to have Set Value and Create Subkey enabled for the group Users

The other issue is VBA macros. There are two solutions here. One is another set of permissions changes - but these open up quite a lot in the registry. Much better is this solution.

As administrator run a macro - doesn't matter what - just something to get the macro system used.

Then in

C:\Documents and Settings\Administrator\Local Settings\Temp\VBE\

you will find MSForms.EXD

Copy that to somewhere accessible. Then for each user who needs to run VBA macros, copy this file into their Local Settings\Temp\VBE folder.

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.