Older blog entries for lukeh (starting at number 37)

14 Feb 2001 (updated 14 Feb 2001 at 11:31 UTC) »

Here's a review of a recent gig and a preview of an upcoming one with The Lovers. Any Advogato readers in Melbourne, come on down!

</a>

Been working on an Objective-C binding for XML-RPC. It's working, based on xmlrpc-c; see this link for more information. The thing is whether to rewrite it to be independent on xmlrpc-c or not.

nss_ldap-129 now supports autoconf. Tested on Solaris, Linux, and FreeBSD; AIX testers wanted! I expect things to break but this was an important thing to do for portability. Thanks to Doug Nazar and David Begley who have worked on the pam_ldap autoconf support, upon which this work was based.

Joe Little and I gave a talk last night SVLUG on LDAP directory services and the Open-IT project. Open-IT is, amongst other things, a clearinghouse for RPMs of PADL's Open Source offerings.

Over the weekend I wrote some glue between JavaLDAPand Ganymede. Ganymede is a very cool, object-oriented framework for managing directory information, and although it is not designed to be used as a directory service per se, it maps closely enough to LDAP that I thought it would be an interesting project to integrate the two.

Also, there are new releases of pam_ldap and nss_ldap. These should show up on Freshmeat soon.

Fred has posted a diary entry, so I suppose I'd better post one too! I've been busy preparing for my final year recital. One of the interesting projects has been integrating support for Apple's proprietary keychain technology into PAM. The keychain lets you lock arbitary passwords (for applications, websites, etc) under one password: it's one of the more practical solutions to single-sign. (I would, of course, prefer the entire world to use Kerberos, but...) Anyway, the PAM integration lets you use the "use_mapped_pass" and "try_mapped_pass" options specified in the original PAM RFC to indicate that a module should retrieve (or attempt to retrieve, respectively) a user's authentication token from the keychain. There's also a pam_keychain module which unlocks the keychain at logon time.

nss_ldap-122 fixes a race condition and a few other bugs. More exciting is that the IRS support has finally been exercised, which means support for BSDI, FreeBSD and (believe it or not) AIX. I didn't even know that AIX had something akin to the Nameservice Switch (I think it's supposed to look to the end-user like NSS, even though the underlying implementation is the BIND IRS), so it's pretty cool when someone sends you patches to get it work. And, pam_ldap-77 fixes a few bugs, such as proper support for NDS password changing. Users of this software seem to be using Bugzilla so I've been addressing some of those bugs, too. Other than that, not much to report in the Open Source department.

Time for a diary entry, it has been a while. I've been working a bit on Darwin lately, integrating GSS-API authentication into NetInfo (with the help of the NFSv4 project's rpcsec_gss library), getting PAM running on MacOS X, and generally tending to our LDAP/NetInfo gateway. And in the last six weeks of university, finally!

I've had a bit of a cold this weekend, which provided ample opportunity to do some coding (as I didn't feel too guilty about not practising or going out).

On the PADL front, I've added support for template users to pam_ldap. I'm not sure whether this works yet, though :-) Template users are a (as far as I know) FreeBSD practice where the PAM host application refetches the username from PAM after calling pam_authenticate(). This lets the module change the username under the application's nose, which is ideal for ISP applications; for example, a user might logon as lukeh@padl.com, and be mapped to the template user nobody. pam_ldap will either map users to a default template user, or read the template user from an attribute in the user's entry. (Both of these are configurable.) You might stack pam_ldap and pam_ntdom, setting pam_login_attribute in /etc/ldap.conf to userPrincipalName, and pam_template_login_attribute to sAMAccountName; then, you could login as lukeh@padl.com; pam_ldap will search for (userPrincipalName=lukeh@padl.com), and then set the username to the value of the sAMAccountName attribute in the resulting entry (eg. lukeh). pam_ntdom would then retrieve the username from PAM, and do an NT domain authentication against "lukeh". Finally, login would retrieve the username from PAM, and call getpwnam("lukeh"). YMMV, this code is experimental! Code, as usual, is at ftp.padl.com.

My friend Joshua Reich has been working on some interesting LDAP-related projects which I hope to help him with. Check out his homepage at www.i2pi.com. Josh is one of the DataServe clan.

On the Darwin front, I've done a little bit more work on the PAM port, not much though, I'm waiting on getting MacOS X up and running first. A bit hard without any PPC hardware to speak of; still, Rhapsody DR2 is quite a nice Intel Unix! Also looked at adding support for reentrant name resolution APIs to Darwin, for the moment just those in the Single UNIX Specification (getpwnam_r(), getpwuid_r(), getgrnam_r(), getgrgid_r()). There seem to be some issues with lookupd in getting this working (not architectural issues, it just doesn't work!). You can check these out in the lukeh-SingleUNIXSpecificationV2 branch of Libraries/NeXT/libinfo. You will need a login to access this.

The final, and perhaps more interesting project, has been a NetInfo backend for OpenLDAP. The backend uses Marc Majka's dsstore API, rather than the NetInfo client library. dsstore is a hierarchical database library with an information that's sort of a cross between NetInfo and LDAP. You get the good things about NetInfo: for example, entries' distinguished names are dynamically constructed, rather than being stored with entry; and the good things about LDAP, such as complex queries. The library will either talk directly to the database on disk (and indeed is used as the backend by the MacOS X NetInfo daemon) or to a remote NetInfo database. Anyway, the OpenLDAP backend, back-netinfo, uses this API. It's quite a thin layer: most of the code is spent mapping between slapd data structures, such as filters, and their analogues in dsstore. The trickier code has to do with mapping information models, which could do with some work. For the moment, dsstore meta-attributes are mapped to LDAP attributes with the ;x-meta tag, except for objectClass, which is mapped to the LDAP objectClass attribute. objectClass is also special-cased so that it always contains extensibleObject and top, and so that filters such as (objectClass=*) will succeed even though the NetInfo entry does not contain these attributes. I expect this code will be able to go away once dsstore can deal with schema itself, and slapd lets backends handle their own schema. Attributes which slapd doesn't know about (ie. haven't been defined in a schema anywhere) appear as operational attributes, and are thus not user-modifiable. To make this useful with existing NetInfo deployments, we need to map between well known NetInfo and X.500 attribute types.

Here is an example of searching for a user in NetInfo, and then in LDAP:

% niutil -read . /users/lukeh
name: lukeh
uid: 1002
passwd: *
realname: Luke Howard
gid: 1000
home: /home/lukeh
shell: /bin/tcsh
sn: Howard
modifiersName: NAME=ROOT,OU=PEOPLE
modifyTimestamp: 20000702234549Z
_writers_passwd: lukeh
_writers_change: lukeh
% ldapsearch -LLL -b "ou=People" name=lukeh '*' '+'
dn: name=lukeh,ou=People
name: lukeh
uid: 1002
passwd: *
realname: Luke Howard
gid: 1000
home: /home/lukeh
shell: /bin/tcsh
sn: Howard
modifiersName: NAME=ROOT,OU=PEOPLE
modifyTimestamp: 20000702234549Z
writers_passwd;x-meta: lukeh
writers_change;x-meta: lukeh
objectClass: top
objectClass: extensibleObject
subschemaSubentry: cn=Subschema

I've been working on porting Linux-PAM to Darwin. This has been a lot of fun!

Does anyone know how you change your Advogato.org password?

Joe Little (jlittle) makes some interesting points about LDAP and NetInfo. One of the projects we talked about doing was writing an OpenLDAP backend to NetInfo's database layer, dsstore. I think this would be a useful project as I think NetInfo is easier to configure/manage on a large, distributed network than many LDAP implementations. We should remember (as Microsoft have with Active Directory) that LDAP is just an access protocol, and that there's nothing stopping you building something as elegant as NetInfo using LDAP as the principal access protocol. When most implementations are derived from the same codebase (the University of Michigan code), it becomes difficult for people to separate what the protocol provides from what has historically been provided by implementations of it.

So, given some cycles to burn, one should ask whether it's better to put some time into the OpenLDAP dsstore backend (which would make Apple happy) or instead put the work into OpenLDAP so that it has a similar complement of management and population tools as NetInfo.

28 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!