I’m back again, after a bit of a unscheduled ‘break’ in my normal work life.  After a couple of days away for work on the Gold Coast, then the sad passing of my Grandfather and his memorial, then being sick over the last weekend from what I can only guess was a nasty 24-hour bug, I’m back.  And whilst a little worse for wear still today, it’s life pretty much as normal.

Today’s fun and games was on a server we use that uses LDAP authentication for its users.  Nothing special, except that today I started getting weird errors when logging in as my LDAP account, and the server booting me off with random error messages:

whoami: cannot find name for user ID 75966

-tcsh: ldap-nss.c:1312: do_init: Assertion `cfg->ldc_uris[__session.ls_current_uri] != ((void *)0)’ failed.

Solution

The simple solution was to check the permissions on /etc/ldap.conf (Centos) and sure enough, the permissions weren’t allowing normal users to read it (eg not 644).  Running this solves the problem:

chmod 644 /etc/ldap.conf

Cheers to the author @ http://www.ducea.com/2008/03/07/ldap-troubleshooting-i-have-no-name/ for the details.

..and how true that is.  Today’s time consumer is directly related to just 1 misplaced line of a buildout configuration (and presumably something that’s changed somewhere else).

The result

After much hunting and hunting, it turns out my Zope2 Fake Eggs weren’t being generated. (more…)

EDIT: Watch out for python-ldap 2.3.10, the latest version at time of writing. Seems like there’s an issue with it and Centos 5.4. Forcing python-ldap to be version 2.3.8 works, though. (easy_install python-ldap==2.3.8)

Previously, you might have read about setting up a Virtualenv on Ubuntu Jaunty. Now, that was reasonably painless since python-virtualenv and python-setuptools is in the Ubuntu repo. Whether it’s my Centos servers and their misguided repos or me just not being able to find such a related rpm packages, Centos just needs little more love to get it to the same setup. (Note: actually, there was a setuptools RPM that I installed, but nfi why it didn’t give me easy_install…) (more…)

Because I still haven’t remembered to set myself up with a limited-access account for blogging on my new site, I’m back here again. (EDIT: Migrated from old site)

This time is a lot of fun and games with removing an “open” logical volume from within a CentOS environment. The dom0 machine has a set of logical volumes in a volume group for each of the VMs and one of them went and failed dismally, and after its xen destruction (xm destory foo) its LV was left with it being “open”.

It’s not exactly easy to see how/why this would be the case and every command (lsof, fuser, mount, etc) told me that the LV wasn’t in use. But still, lvremove, lvchange, and dmsetup commands failed.

But, I’ve solved my problem! Hopefully yours too.. read on through the commands:

# lvchange -an /dev/vmsvg1/foo
LV vmsvg1/foo in use: not deactivating
# dmsetup info -c vmsvg1-foo
Name Maj Min Stat Open Targ Event UUID
vmsvg1-foo 253 65 L–w 1 1 2 XXX
# dmsetup remove -force vmsvg1-foo
device-mapper: remove ioctl failed: Device or resource busy
# lvchange -an /dev/vmsvg1/foo
/dev/vmsvg1/foo: read failed after 0 of 4096 at 0: Input/output error
/dev/mapper/vmsvg1-foop1: read failed after 0 of 2048 at 0: Input/output error
# dmsetup remove -force vmsvg1-foop1
# dmsetup remove -force vmsvg1-foo
# lvs vmsvg1
foo vmsvg1 -wi— 4.00G (it’s closed!!)
# lvchange -an /dev/vmsvg1/foo
# lvremove /dev/vmsvg1/foo
Logical volume “foo” successfully removed

So, after all that, it looks like there’s some stupid ‘p1′ references in /dev/mapper/ . Nfi why, but removing it (albeit by force with dmsetup) solved the problem.