Ubuntu VMs and Time

Ubuntu 8.04 in VMs under VMWare Server 2.0.1 need the kernel parameter "clocksource=acpi_pm" when they boot. Edit /boot/grub/menu.lst and add "clocksource=acpi_pm" to the end of the line that starts "# kopt=". Don't remove the "#". In this context it's not a comment. After you save the file, run "sudo update-grub" and then reboot.

If the guest doesn't have this kernel parameter specified, time runs backwards on the guest O/S, or time hangs or gets stuck. This was showing up especially on my backup server running bacula, and the backup clients that had large amounts of data. I suspect that high loads exacerbate the problem.

xsane Problems

This morning I scanned a small French reader that Marc particularly liked. At noon I had to scan two pages for Angela, because she'd left them at home. When I went to scan I got this: "Failed to start scanner: Invalid argument".

After much flailing, including re-installing hplip and xsane, and doing sudo

ln -s /usr/lib/libhpmud.so.0 libhpmud.so

I finally got brave and simply moved ~/.sane/xsane to ~/.sane/xsane.old, then started xsane and it worked.

After the fact, I figured out that the problem started when I clicked on the preview pane in xsane and set the size of the area I was scanning to 0. The message wasn't very helpful. (I figured it out by diff'ing the xsane.conf that worked with the one in xsane.old.)

In addition, hp-check reports there's no plug-in installed for my printer, even though everything seems to be working. Go figure.

All this under Ubuntu 9.04 using an HP CM1312nfi MFP.

Getting Identity From Active Directory

I needed a test environment where I could test mounting and accessing Windows shares on a Linux machine, using identities and permissions obtained from Active Directory (AD). After the initial setup, I wanted to run a processes periodically in the background, without user intervention. Therefore, having the user enter the password each time wasn't an option. Also, the background process would be run periodically forever in the future. I didn't want to store passwords because the processes would fail after the user changed their password (and it's not a good idea to store passwords anyway).

The Kerberos authentication scheme in Windows and Linux uses tickets, which can be used to prove that a process is acting on behalf of a user. A user gets a ticket by requesting one and providing their password. Until that ticket expires, processes that support Kerberos can be run with the permissions of that user.

So let's say we want to access a Windows share as user "testa", which is a Windows user known to the AD server. The Linux machine asks for a ticket for testa, using testa's password. The AD server validates the password and gives the Linux machine a ticket. The Linux machine can then mount the Windows share using Kerberos authentication. Accesses to the files and directories on the share will then be allowed or denied based on testa's permissions.

I built an AD server on Windows 2003 Server SP2. The client machine was Ubuntu Desktop Edition 9.04.

Here's how I went about it:

1. Build an Active Directory server accepting the defaults. This included allowing it to set up its own DNS server. I already have DNS servers in my network, but I'm not a DNS expert. I've had bad luck changing my DNS setup in the past, so for this test I just let AD do its thing.
2. Install required packages on the Linux machine:
   

sudo apt-get install krb5-user keyutils


3. Replace the installed /etc/krb5.conf with the following. You have to replace "my.domain.tld" with your own domain, of course. Be careful to copy uppercase and lowercase:

[libdefaults]
default_realm = MY.DOMAIN.TLD
default_checksum = rsa-md5


[realms]
MY.DOMAIN.TLD = {
kdc = ADServer.my.domain.tld
}

[domain_realm]
.my.domain.tld = MY.DOMAIN.TLD
my.domain.tld = MY.DOMAIN.TLD


4. Add the following line to /etc/request-key.conf. The order of the lines is important. I put it last and nothing changed. I put it first and everything worked:

create cifs.spnego * * /usr/sbin/cifs.upcall %k %d


5. Get a key with kinit. Run kinit with sudo. The ticket you get is for the AD user testa whether you run as sudo or not, but the place that kinit stores the ticket depends on the Linux user who runs kinit. Since the mount command runs as root, you have to get a ticket for root or mount won't find the ticket
   

sudo kinit -f testa


6. Mount the share, replacing "FileServer", "Share", and "/tmp/mnt" with appropriate values for your systems:

sudo mount -t cifs -o sec=krb5i //FileServer/Share /tmp/mnt

For a while I was getting "mount error(2): No such file or directory" when I tried to mount. It was because I hadn't installed the keyutils package.

I've tested this up to and including the mount. I haven't finished testing the background process I originally wanted to build. I may modify this post based on my testing experience, so check back later.