Second GSoC Report

A lot has happened since the last report. The main change in nacho was probably the move to integrate django-ldapdb. This abstracts a lot of operations one would have to do on the directory using bare ldap and it also provides the possibility of having the LDAP objects in the Django admin interface, as those are addressed as Django models. By using django-ldapdb i was able to remove around 90% of the self written ldap logic. The only functionality that still remains where i have to directly use the ldap library are the password operations. It would be possible to implement these features with django-ldapdb, but then i would have to integrate password hashing functionality into nacho and above all i would have to adjust the hashing function for every ldap server with a different hashing algorithm setting. This way the ldap server does the hashing and i won’t have to set the algorighm in two places.

This led to the next feature i implemented, which was the password reset functionality. It works as known from most other sites: one enters a username and gets an email with a password reset link. Related to this is also the mofification operation of the mail attribute: i wasn’t sure if the email address should be changeable right away or if a new address should be confirmed with a token sent by mail. We talked about this during our last mentors-student meeting and both formorer and babelouest said it would be good to have a confirmation for email addresses. So that was another feature i implemented.

Two more attribute that weren’t part of nacho up until now were SSH Keys and a profile image. Especially the ssh keys led to a redesign of the profile page, because there can be multiple ssh keys. So i changed the profile container to be a bootstrap card and the individual areas are tabs in this card:

Screenshot of the profile page

For the image i had to create a special upload form that saves the bytestream of the file directly to ldap which stores it as base64 encoded data. The display of the jpegPhot field is then done via

<img src=data:image/png;base64,...

This way we don’t have to store the image files on the server at all.

A short note about the ssh key schema

We are using this openssh-ldap schema. To include the schema in the slapd installation it to be converted to an ldif file. For that i had to create a temporary file, lets call it schema_convert.conf with the line

include /path/to/openssh-ldap.schema


sudo slaptest -f schema_convert.conf -F /tmp/temporaryfolder

one gets a folder containing the ldif file in /tmp/temporaryfolder/cn=config/cn=schema/cn={0}openssh-ldap.ldif. This file has to be edited (remove the metadata) and can then be added to ldap using:

ldapadd -Y EXTERNAL -H ldapi:/// -f openssh-ldap.ldif

What else happend

Another big improvement is the admin site. Using django-ldapdb i have a model view on selected ldap tree areas and can manage them using the webinterface. Using the group mapping feature of django-auth-ldap i was able to give management permissions to groups that are also stored in ldap.

I updated the nacho debian package. Now that django-ldapdb is in testing, all the dependecies can be installed from Debian packages. I started to use the salsa issue tracker for the issues which makes it a lot easier to keep track of things to do. I took a whole day to start getting into unit tests and i started writing some. On day two of the unit test experience i started using the gitlab continuous integration feature of salsa. Now every commit is being checked against the test suite. But there are only around 20 tests at the moment and it only covers registration and login and password reset- i guess there are around 100 test cases for all the other stuff that i still have to write ;)

debian gsoc18