March 2009 Archives

Let's assume that we have two systems, one which support LDAP user accounts and other system, based on relational database (Koha, in this example) which has user information which you would like to expose using LDAP for first system.

We could export all data required into institution LDAP, but that would push a lot of junk which is really required only by one application. Worse yet, some of that data is somewhat sensitive because it include serial numbers (SID) and data from RFID cards.

But, since application supports LDAP and we have Net::LDAP::Server it should be easy! And it really is.

LDAP server accessing Koha database using DBI is really converter of LDAP search query into SQL where syntax which is than appended to initial select which returns attribute values for LDAP entry which will be returned for search request.

This small example will hopefully be useful to other people who would like to integrate two systems by exposing user data via LDAP protocol. Just remember that pushing real valid usable data back to LDAP always makes more sense if that data is useful for current or future systems...

PerlMonks has node with this annoucement, so you might want to comment there if it's in interest of general perl comunity

Redis is another in-memory hash store with disk persistence. It's different from memcached or Tokyo Cabinet because it has native list and set types. Even better, it has atomic operations like set intersection, increment/decrement, sort (!) and so on. This makes it suitable for implementation of real applications without traditional relational databases.

If you want to try it with perl, head over to Redis perl bindings and redis from git repository at github. It supports tie to hash or arrays if you don't want to use Redis API directly.

I just finished implementing current version of protocol (which will change soon it seems) and I would like to implement some sample scripts before I push it to CPAN near you.

This weekend I worked on LDAP mungling: we needed to roll-out Koha with LDAP support, but at the same time, central LDAP server didn't have all data (date of birth, gender and address) needed for full entry about user in Koha. We had those data available as CSV export from other systems.

There are many ways to tackle this problem from modifying Koha LDAP support (which I was somewhat reluctant to do) to importing data back into LDAP. However, none of those things can be done in just one day, so I decided to write small LDAP proxy which will do data marging for me.

I started with Net::LDAP::Server based solution implemented by LDAP::Virtual module, but soon I stumbled upon problem of compareRequest which I couldn't implement correctly. Since it's required for login this was show-stopper.

After a bit of searching, I found simple-proxy.pl which is part of Net::LDAP. This is simpler script which operates directly on sockets and ASN encoding of entries. It's very useful in debugging, so I decided to re-implement modification of searchResEntry from LDAP server as ldap-rewrite.pl with following changes:

• augment LDAP entry with data from YAML file (with configurable prefix for attribute names)
• support SSL to upstream LDAP server
• expand attributes with multiple values into separate attribute for each occurrence (to enable easy import of second value from attribute address using something like address_1 (it's 0 based, same as perl arrays)
• generate additional attributes using concatenation of prefix: from data and attribute name (to get hrEduPersonUniqueNumber_JMBG from attribute hrEduPersonUniqueNumber which has JMBG: 1234567890 as value)

To keep it really KISS I used yaml files named as dn (for example, uid=dpavlin,dc=example,dc=com.yaml) for simple, human readable file fromat. This enabled me to separate data-mungling part into csv2yaml.pl. In this script, I converted values from CSV delimited by # into separate attributes, detect phone numbers which are mobile or fixed and do other tweaks (like gender mapping). YAML files are also nice if I want to implement audit trail of changes: I can just import them all into git and be done with it.

For future versions, I can envision that overlay data can also be fetched from database, so I can add additional attributes to LDAP entries directly from Koha database. This will be useful when connecting with copiers which require LDAP with card number for each user which isn't available in upstream LDAP directory.

Not bad for 4k of perl code :-) I hope this will help you use LDAP as directory for different data as opposed to just login service. Don't forget to push all useful data back to LDAP server, so that all application can take benefit from it without need to worry about source data format.

It seems that Intel driver for Xorg allocates virtual destop as maximum rectangular size of biggest attached screen. In my example, I have:

• 1920*1200 LCD monitor connected via VGA (sic! x200 doesn't have DVI)
• 1280*800 internal LCD display

Xorg seems to think that my virtual desktop should be 1920*1920. This is probably correct if I want to rotate my screen freely (which doesn't really work with Intel driver because screen refresh in any orientation other than normal is just too slow to be useful).

I want to have VGA output above internal LVDS with something like

xrandr --output VGA --auto --above LVDS

It should be 1290*2000 = 1920*(1200+800) so I had to add following in /etc/X11/xorg.conf:

Section "Screen"
        Identifier      "Default Screen"
        Monitor         "Configured Monitor"
        SubSection "Display"
                Virtual 1920 2000
        EndSubSection
EndSection

Nice and simple. I really love new x.org configuration files with much less clutter...