Background

This module was initally developed by Lance Albertson and some other guys from OSUOSL. Adrien Thebo, who by the way works for PuppetLabs, stepped in after some time and did some cleanup in the native types/providers that were included in there, and later he took over completely. Judging from the commit log though, the module was not getting the love it deserved

Meanwhile, we, the Gentoo Infrastructure team, decided to migrate from Cfengine 2 to Puppet. So I started digging around to check about Gentoo support in Puppet. Given the complexity of the package management in Gentoo, I didn’t have high expectations, and I wasn’t wrong. The internal Puppet Portage provider has pretty basic support, so I had to get my hands dirty and write something decent. Then I stumbled upon Adrien’s puppet-portage repo, which made me felt like I hit the jackpot. I started testing it to understand the functionality it covers, and meanwhile I spent some time reading books and experimenting with Puppet and Ruby, as both of them were pretty new to me.

Right after the Gentoo Miniconf I finally contacted Adrien and expressed my interest in developing more functionality to the module. In 3 – 4 months of hard work we managed to have all the functionality I had in mind, which is impressive. It was a great journey, as I had the chance to do quite some stuff in a technology that was completely unknown to me. Adrien was very helpful in giving me correct directions, and I even managed to write a native type and provider from scratch! Thanks a lot Adrien!

Special thanks also to Zac Medico, main Portage developer, for all his valuable input.

Features

Let’s see all the functionality this module provides. Most of the info below is stolen from the README file.

1) /etc/portage/package.*/*

There is a set of native providers that add support of handling entries for
/etc/portage/package.keywords, /etc/portage/package.use, /etc/portage/package.mask, /etc/portage/package.unmask. Examples:

package_use { 'app-admin/puppet':
  use     => ['flag1', 'flag2'],
  target  => 'puppet-flags',
  version => '>=3.0.1',
  ensure  => present,
}

“$use” can be either a string or an array of strings.

package_keywords { 'app-admin/puppet':
  keywords => ['~x86', '-hppa'],
  target   => 'puppet',
  version  => '>=3.0.1',
  ensure   => present,
}

“$keywords” can be either a string or an array of strings.

package_unmask { 'app-admin/puppet':
  target  => 'puppet',
  version => '>=3.0.1',
  ensure  => present,
}

package_mask { 'app-admin/puppet':
  target  => 'tree',
  version => '>=3.0.1',
  ensure  => present,
}

A few issues for the above providers (all the issues are reported in the repo’s Github tracker, but we decided to leave them for the next milestone)

• Renaming the target leaves an empty file behind
• Wrong permissions in package.*/* files: This is actually solved for newly created files, we need to find a way to enforce sane permissions to all files under /etc/portage though
• Trigger rebuild after package_* addition/edit: The portage_* providers don’t trigger rebuild, but portage::package (which is described below) does trigger proper rebuilds
• package_* should always use default values when their attributes are not explicitly specified
• package_* types do not update version when it was not initially defined
• integration tests need to cover the cases of adding removing attributes: Those last three issues are related
• Automatically convert old package.* files to dirs: This is probably not going to be fixed. In short, the Portage module works only if /etc/portage/package.* are directories. If any of those is a file, it will print an error. For now you should convert any package.* files there to directories manually. A bash script to do it quickly:

for target in keywords use mask unmask; do
    if [[ -f /etc/portage/package.$target ]]; then
        mv /etc/portage/package.$target /etc/portage/package.${target}_bak
        mkdir /etc/portage/package.$target
        mv /etc/portage/package.${target}_bak /etc/portage/package.$target/old
    fi
done

2) make.conf

NOTE: Be aware that make.conf has changed location, from /etc/make.conf to /etc/portage/make.conf. Make sure to update your systems as well. It’s new location makes much more sense. The Portage module uses by default the new location by default.

The Portage module provides a custom class to handle your entries in make.conf. Example:

portage::makeconf { 'use':
  content => 'flag1 flag2 flag3'
}

This entry will also trigger rebuild of the affected packages.

portage::makeconf { 'gentoo_mirrors':
  content => 'url1 url2'
}

As stated in issue #56, in a later milestone we will convert this class to a native type/provider, in order to make it more powerful.

3) portage::package

This is another custom class, which acts as a wrapper to the native package resource of Puppet. The following example sums up pretty much all of its functionality:

portage::package { 'app-admin/puppet':
  use              => ['-minimal', 'augeas'],
  use_version      => '>=3.0.1',
  keywords         => ['~amd64', '~x86'],
  keywords_version => '>=3.0.1',
  mask             => '<=2.3.17',
  unmask           => '>=3.0.1',
  target           => 'puppet',
  target_keywords  => 'puppet-keywords',
  ensure           => '3.0.1',
}

• If no $target_{keywords,use,mask,unmask} is specified, then the value of $target is being used.
• The variables keywords, mask and unmask also accept the special value ‘all’, that will create versionless entries. (This applies only to portage::package, if you want versionless entries in any of the above package_* types, you can just omit the version attribute.)
• Any change in portage::package will also trigger the appropriate re-emerge to the affected package.

This class was my ultimate functionality request for Portage support in Puppet generally, thus it’s the part I’ve spent most of my time on.

4) Facts

All make.conf variables and most of the eselect modules are shown by facter:

...
eselect_profile => hardened/linux/amd64
eselect_python => python3.2
eselect_ruby => ruby19
...
portage_portage_tmpdir => /var/tmp
portage_portdir => /usr/portage
portage_python_single_target => python2_7
portage_python_targets => python2_7 python3_2
portage_ruby_targets => ruby19
portage_sync => rsync://rsync.gentoo.org/gentoo-portage
...

Keep in mind though that some of the eselect modules are not being shown as facts on purpose. The reason is that either they are not useful, or they produce too complex output that needs further investigation on how to implement. The blacklisted eselect modules are ‘help’, ‘usage’, ‘version’, ‘bashcomp’, ‘env’, ‘fontconfig’, ‘modules’, ‘news’ and ‘rc’.

5) eselect

The eselect type/provider checks for the current state of an eselect module by reading the variable of the equivalent fact. Examples:

eselect { 'ruby':
  set => 'ruby19',
}

For eselect modules that have submodules (eg php):

eselect { 'php_apache2':
  set => 'php5.3',
}

This pretty much covers everything. I hope it will be useful for the community. Feel free to submit bugs, patches or ideas at the repo’s Github issue tracker.

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML file

There were some serious bugs in the edit account page. The ACL is very complex there, since there are public attributes (accessed by everyone), semi-private attributes (accessed by the user only and the admins (eg. birthday)), and private ones (accessed only by admins). Keep in mind that everything is configurable, but there is some duplication between the Django and LDAP ACL, since there is no easy way to parse the LDAP slapd.conf yet, we need to migrate our infra to cn=config first, which is a not easy long term task. The bug was not in the LDAP part, remember that the user changes his/others’ (in case he has the right privs) attributes with his own account, not by using a global admin account. The bug was in the Django part, where the system expected to be able to change some data, and weird error messages/exceptions were thrown out. Unfortunately this is not complete yet, it needs more investigation in order to ensure we are not opening any security holes here. The good news is that I tested with our current official configuration, and various tweaks on it, and seems to perform fine. Plus, it seems ready for the improvements I intend to do (for adding regular users in LDAP etc).

I was also able to plug in some CSS/JS written by my mentor. It is just some preliminary work, nothing complete yet, we’ll need more help on this, especially from people with some experience in web design stuff.

Beacon didn’t work out as expected. It became too complex, consisting of lots of JS and XSLT, for reading the XML files and printing them. It even stores accounts in its own DB to keep track of the documents that users edit. This was way out of our needs, we just need the WYSIWYG part only and plug it in in a separate web app. Obviously in its current state it is not a workable solution without significant additional effort. What we could do for now is to split some parts of its code, like the python scripts for converting XML to HTML and the opposite, which is also not an easy task.

I must admit that I am really happy that the GSoC is coming to its end, and the real fun begins

As a KDE packager, I usually have to write and test patches, especially build system related (Examples: Choqok, Amarok, Plasma and happy KStatusNotifierItem’d Akregator and Kaffeine, they don’t look ancient any more ). Gentoo, as a source based distro, has the ability to provide packages that clone/checkout the source from upstream’s SCM and compile it directly (called live ebuilds). For KDE, it provides live ebuilds from KDE SC master/trunk and the branch(es) (currently 4.7), plus live ebuilds for many extragear/playground and other packages (all of the above are available in the kde overlay). Also, we provide Qt live ebuilds both from master and many branches, in the qting-edge overlay. I wanted to use our Gentoo live ebuilds in order to test patches, but there were multiple problems. Emerge downloads the sources in $DISTDIR and stores them as the portage user. Plus, the git eclass was using bare repos, and it would reset the repo to master before each emerge. In order to solve those problems, I created a few scripts and wrappers, and convinced Tomas to introduce two new variables in the new git-2 eclass to fit my needs (thanks a lot bro, you owe me a beer).

Define the needs

In short, what I want is:

• download the sources somewhere in my homedir
• my everyday user to have write permissions to them
• non-bare clones
• url = anongit.kde.org AND pushUrl = git.kde.org, if possible directly on initial clone
• if possible, have a live and a regular release side by side

The last dot was solvable, but not any more. We used to provide a kdeprefix USE flag, that allowed us to do exactly this (install multiple KDE versions using different prefix (eg /usr/kde/4.7 /usr/kde/live). It had many problems though, that forced us to remove it. The problems it had were mostly in non-KDE packages, eg Sip, which also needed to be prefixed, which was too much workload. Anyway, a chroot could solve that issue.

As for the permission issue, I asked Zac if portage itself could provide something like this (using my user instead of the portage user), and he suggested that creating a git wrapper would be a clean solution.

After a while I was able to extend the above for my gentoo overlays (unofficial ebuild git repositories), since I have write access to most of the ones I use in my system.

Configuration

All the scripts mentioned can be found here. Although well tested here for the past few months, use them at your own risk. In the following examples I’m going to use the configurations for both the KDE and Gentoo git repos. Of course, you can ignore them (“Gentoo repos” blocks in the following scripts).

First, we need to set the following in /etc/make.conf:

# Needed by the Git wrapper
KDE_DEVELOPER=1 # For the KDE repos
GENTOO_DEVELOPER=1 # For the Gentoo repos
EGIT_NONBARE=1 # This one sets the git-2 eclass to clone non-bare repos

Next, we set up some git aliases in ~/.gitconfig, as suggested here:

# KDE Repos
[url "git://anongit.kde.org/"]
    insteadOf = kde:
[url "git@git.kde.org:"]
    pushInsteadOf = kde:
# Gentoo Repos
[url "git://git.overlays.gentoo.org/"]
    insteadOf = gentoo:
[url "git@git.overlays.gentoo.org:"]
    pushInsteadOf = gentoo:

And the git wrapper, which should be put in /usr/local/sbin/git:

#!/bin/bash
source /etc/make.conf
USER="tampakrap"
GROUP="tampakrap"
GIT="/usr/bin/git"
 
if [[ $1 == 'clone' ]]; then
    # KDE Repos
    if [[ $2 == "git://anongit.kde.org/"* ]] && [[ $KDE_DEVELOPER == 1 ]]; then
        KDE_REPO=$(echo $2 | sed 's:git\://anongit.kde.org/::')
        $GIT "$@"
        chown -R $USER:$USER $DISTDIR/egit-src/$KDE_REPO
    # Gentoo Repos
    elif [[ $2 == "git://git.overlays.gentoo.org/"* ]] && [[ $GENTOO_DEVELOPER == 1 ]];then
        GENTOO_REPO=$(echo $2 | sed 's:git\://git.overlays.gentoo.org/::')
        $GIT "$@"
        chown -R $USER:$GROUP $DISTDIR/egit-src/$GENTOO_REPO
    else
        $GIT "$@"
    fi
else 
    if [[ ${PWD%/*} == $DISTDIR/egit-src ]] && ( grep -s -q gentoo .git/config || grep -s -q kde .git/config ); then
        sudo -u $USER $GIT "$@"
    else
        $GIT "$@"
    fi
fi

The above script consists of two parts: if the git argument is clone, it checks if the URL is a KDE or Gentoo one and chowns the repo after cloning. If it is something else (eg pull), it checks again if the URL is a KDE or Gentoo one, and uses sudo -u $USER:$GROUP to preserve the permissions of the repo. The repos are still in the $DISTDIR/egit-src dir ($DISTDIR is usually /usr/portage/distfiles, but it can be changed in /etc/make.conf), so the following script creates symlinks of those somewhere in the homedir (put it in /usr/local/bin/create_repolinks):

#!/bin/bash
 
# Headers
source /etc/make.conf
. /etc/init.d/functions.sh
 
# Variables
REPO_DIR="/home/tampakrap/Source_Code/" # Where to store the symlinks of the repos
GENTOO_REPO_DIR="${REPO_DIR}gentoo/"  # Gentoo repos
KDE_REPO_DIR="${REPO_DIR}kde/" # KDE repos
OVERLAY_DIR="/var/lib/layman"
 
# No root
if [[ $UID == 0 ]]; then
	   eerror 'root is forbidden'
	   exit 1
fi
 
# Gentoo Overlays
cd $OVERLAY_DIR
for repo in `ls -d */`
do
	   pushd $repo > /dev/null
	   einfo "Checking $repo overlay"
	   if [[ ! -z `grep git.overlays.gentoo.org .git/config` ]]; then
		      sed -i -e 's:git\://git.overlays.gentoo.org/:gentoo\::' .git/config
		      ewarn "gentoo git url corrected for $repo overlay"
	   fi
	   [[ -L ${GENTOO_REPO_DIR}${repo%/*} ]] || (ln -s /var/lib/layman/$repo ${GENTOO_REPO_DIR} && ewarn "New symlink for $repo overlay")
	   popd > /dev/null
done
 
# KDE Repositories
cd $DISTDIR/egit-src
for repo in `ls -d */`
do
	   pushd $repo > /dev/null
	   einfo "Checking $repo repository"
	   if [[ ! -z `grep anongit.kde.org .git/config` ]]; then
		      sed -i -e 's:git\://anongit.kde.org:kde\::' .git/config
		      ewarn "kde git url corrected for $repo"
	   fi
	   if [[ ! -z `grep kde: .git/config` ]]; then
		      [[ -L ${KDE_REPO_DIR}${repo%/*} ]] || (ln -s ${DISTDIR}/egit-src/$repo ${KDE_REPO_DIR} && ewarn "New symlink for $repo")
	   fi
	   popd > /dev/null
done

Last but not least, we need the kde overlay, to get the live ebuilds:

layman -f -a kde

For more information on this, take a look at the Gentoo KDE Guide

Usage

With the above configuration, we can use:

emerge -av =amarok-9999
create_repolinks

and get the amarok repository in our homedir, ready to patch it. As I said, in case we modified the code and tried to re-emerge the ebuild to get our patch in action, emerge will reset our repo to master again. Thus, we need to use the following variable:

EVCS_OFFLINE=1 emerge -av1 amarok

This will prevet the reset of the repo. In case we want to use a full live environment, we can even put that var in make.conf, but it is not recommended, better to use it in single emerge runs like the above.

That’s it. I plan to write a PyKDE UI for easy installation of the scripts, and maybe write a proper techbase article for it. Any feedback is appreciated.

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML file

Two important things hapenned: 1) I passed the midterm (thanks to my mentor and everyone involved) 2) I graduated YEY!

I’ve left the LDAP bits behind for now (apart from bugfixing here and there). It is working fine, and supports:

• login (with any of user’s mail)
• registration (the admin can specify which OU will be used for initial user creation) (for development purposes, it can even create top O and OU in an empty LDAP server)
• map LDAP ACL to Django ACL
• view some user’s data (in settings we can specify which attrs the user himself can see, and which ones privileged users can see)
• edit own data (again, only specific attrs based on perms)
• edit other user’s data (if the logged in user has the correct permissions for that)
• An addressbook (list of users, separated in developers, exdevs, others (the lists are configurable))

I’m still working on the UI, and started messing around with Beacon. It is a very interesting project, which is getting more love again, through a Fedora GSoC project (it even started as a GSoC project). It has two backends, a PHP and a Django one. I already talked to the upstream guys, they showed me their TODO list [1]. Some of those are needed for me as well, which is very nice, since my patches can go upstream directly. I was going to write a custom script to export the generated XML output, which is one of the things Beacon itself needs as well. Another important thing is to load external files in order to edit them. Finally, the git integration I was going to implement also sounded like a nice feature. Really glad to see that we are on the same road, my plan was to not fork the project but keep the changes there as possible. Matt, my mentor, was helping Beacon with the Django part since the beginning. I plan to work on those three features for the next week (weekend included).

Apart from the above, I’m working on our XSLT and Python’s decorators to create Django templates based on our XML files.

Okupy is deployed in the server, I need a final review from my mentor and will open it to some people for testing really soon (target: this weekend).

[1] http://tinyurl.com/3g4424o

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML files.

This is going to be small but really important. Robin set up for me an LDAP instance in vulture for me, plus reviewed my cfengine patches for OpenLDAP, Django and the various depedencies, thanks a lot for this! I’m in the process of deploying the web application to the server, and will move development fully there. I plan to open it for a few people for more beta testing in the following week. There has also been some internal Infra discussion on whether to use multiple OUs (OU=users, OU=developers etc), without an agreement yet, but my code works either way. Also I need to expand our LDAP configs and add a few more groups there, like a user.group, and some other privileged groups like devrel, pr (currently we have only infra, recruiters and devrel I think).

As for the development of the app itself, the past days I’ve been doing various bugfixing in the LDAP frontend and playing around with the UI mostly. It is very configurable, the admin can choose which LDAP values to print, and in which form (eg human readable: username / first name / last name OR keep the LDAP names: uid / givenName / sn). The user can view his own attributes or someone else’s public attributes. A privileged user can see more attributes from other users, plus add/remove another user from some groups. There has been some ACL duplication here, but unfortunately there isn’t a better way to do it at the moment. Robin proposed another long term solution: if we move our LDAP configs to the new cn=Config style, the app then could parse that config and generate the ACL accordingly to Django settings. It can’t be done now though, since Infra needs to migrate LDAP to that style first, which I know it’s going to be painful (I’ve done it already for a uni server about a year ago). I’m working on the UI of the edit view now, which is a generated form by the user profile model. Although it works (user can edit his data successfully, admins (eg infra/recruiters in Gentoo case) can edit other users’ data as well), there has been some pain in printin nice the multivalued attributes of LDAP. Currently, the multivalued attrs are transfered to a TextField in the DB, and the values are separated with :: for easy split-desplit. With the help of Matt I wrote a form widget, but it still needs to look prettier when the user wants to add or delete a new value.

Apart from the above, I’ve also started working in general on the UI, and the front page. Matt gave me some some CSS to plug in to my templates, but my overall goal would be to create an easy way to create new themes to the app, instead of having to touch the templates (should be easy in Django). The UI and the front page is what I’m going to do for the next few days, and then start working on the Beacon and XSLT/XML parts. Last but not least, I wrote an addressbook as a replacement to userinfo.xml.

I’m writing a CMS for the Gentoo website, that will offer an LDAP web interface, plus it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML files.

The login system had to change though. Robin wanted mail logins instead of username logins. This needed a lot of changes, since in LDAP mail is a multi-valued attribute, and in Django is single-valued field. I created an all_mails field in user profile instead, that has all the mails, but the user has to verify about them first. In initial registration, the user’s mail is stored in a DB table, along with a 30char string, and a mail is sent to the user which contains the same string in the form of a URL. The system checks if those two match, and if they do, it removes the entry from that table and moves the mail to the user’s LDAP mail attribute (and in the all_mails field in the DB, if applicable). The same procedure is followed when the user wants to add a new email to his account, for which he has to verify before getting it in the list. Afterwards, the user can log in with any of those emails he has verified. For password recovery, the user fills in the mail he wants to use for that session.

The user profile is extendable, if other people want to use the LDAP frontend. For now there is a GentooProfile class that extends the UserProfile class, that has gentoo-specific fields based on the LDAP attributes Gentoo uses, plus the custom gentoo LDAP schema.

User settings are available, under accounts/$USER subURL. The system checks if the URL maps to the user currently logged in, or another user in the LDAP server, then checks if the user is in the DB, migrates it if not, and shows the fields according to the logged in user’s permissions. Edit settings is also available and works with the same logic.

I’ve also added a lot of docstrings there, and started messing around with sphinx.

The logging system is improved as well. The errors are printed in console if the project is run with Django’s runserver for development purposes, and in /var/log/messages (which is configurable, it can go to a dedicated dir easily) for production use.

More tests were written, and the ebuild is almost complete. I’ve set up an instance in one of my home servers, which will run tests automatically and notify me for failures.

There is an addressbook available, as a replacement to userinfo.xml we currently have. I’m going to play around with genmap as well to replace the developer map.

Since the LDAP work is done, with only bugfixes and small improvements needed here and there, I’ve started working on the front page. It will follow the steps of the one we currently have. It will be a syndication-like page, combining the info from planet/blogs, news items written by PR team, new packages etc. I also started working on the lxml scripts to parse our XML documentation, and next week I’ll plug in the design done in www-redesign repo, and improve it as possible.

PS. The report was delayed, because I’ve been offline pretty frequent due to multiple reasons. I had my last exams, which went good and I probably graduated (finally!), I had to be on another city without internet for some days, and finally, the frequent power cut in Greece (as part of the general strikes, riots and frustration of the economic crysis here) not only kept me offline, but also destroyed one of my drives in my desktop, and one of my home servers completely. I learned from that though, I follow their website for future power cuts.

•  Login to the system (report #1 explains in detail how login works). It previously was using only the basic info (real name, primary email), but now it is configurable to use more info, where the sysadmin is able to define in the config files. This was easy to do, by creating a second dictionary to map the django user profile fields with LDAP attributes.
• Signup. For this, an admin LDAP account is needed to be put in the config file. The admin account, contrary to other backends, is used only to create new users. Other LDAP implementations use that admin account for everything though. So, now the user declares username/password, the anon account searches if the user already exists (both the username and the email have to be unique), and if not, it creates the account, using the same dictionary to map django DB fields with LDAP attributes.
• User settings. There are some forms that allow the user to change his data. This is done by using his own account, and not by using the admin account to do that. A second password is being created for the session, since we didn’t want to cache the regular password. (again, report #1 has more info about it).
• Map LDAP ACL to Django groups. For that, a special multivalued attribute is used, in gentoo it is called gentooAccess, which contains some *.group entries that specify the user’s special permissions. This gives the abillity to a special team to touch other users’ data, eg infra. While the mapping is complete, the UI is not yet.

Other things that I did:

• I set up the service in one of my home servers, so that Matt can test it too. The LDAP used there is very minimalistic.
• I gave Robin some cfengine patches for both the webapp and the LDAP (which should be as much identical to the official as possible). They are not complete yet though. Once the webapp is up and running in vulture ( the soc.dev server) I’ll be able to test it in our official configuration.

What I’m going to do during the weekend:

• Improve documentation (docstrings) and fire up sphinx
• Improve logging system
• I started writing some tests for the backend, I’m going to finish it, and plus write tests for all the above as well.
• Create an ebuild to automate tests
• Finish the “touch other users’ data” UI

After that, the LDAP system will be finished, and let the tests show me bugs. Next week I’ll start working on the website part, beginning with the LXML parsing of our docs.

Time to sleep, it is 0640 already here, I didn’t even realize the sun is up.

My major goal was to finish the LDAP backend part, either by using an existing library or writing it from scratch. Finally, after taking a look at many libraries and implementations, I wrote my own. More specifically, what the Django LDAP authentication backend does is to override the default Django DB authentication backend. When a user logs in, the backend checks if the user exists in the LDAP server. In order to do the search, the OpenLDAP server has to provide either an account to do that (an “anonymous” account with minimal privileges, just to do those kinds of ldap queries) or allow anonymous searches. In case the account is being used, it has to be declared in the settings file. I took it one step further from what the other backends did actually: in a common ldap configuration, all users are under OU=users or something. I intend to split it though to OU=users and OU=developers, thus I allowed the backend to search in multiple organizational units, by converting the variable to a python list. If the query sends a result (meaning the user is found), then it tries to bind with the credentials provided in the login form. If it suceeds, then the user data (apart from the password) are transfered to the django db, where they are going to be used for the rest of the session. Django actually has only email, real name and username in its accounts, but it gives the opportunity to extend those by creating a profile. That is technically an extra table in the db, with the ability to add custom fields, really handy.

The major problem that I’ve faced with all those ldap backends was that they all asked for an admin account, and they performed all changes with that account. That is acceptable for user creations but not for all the other cases. If a user wants to change his data, he should be able to do it with his regular account. Another problem emerged here though. OpenLDAP asks for the password before every action and one solution was to do it that way. Bcooksley had another idea though, to create a second 50char password, which will stay only for one session, and will be destroyed using itself at the end. I liked that idea very much, as asking the password is not too user friendly in my opinion, and the web frontend looses its purpose. For important changes though the password will be required (that includes uploading a new SSH/GPG key, or resetting the password).

The LDAP backend is now working, which is really cool, I didn’t expect it to be done so fast. My next step is to write some tests and documentation, for which I’ll use sphinx. Also, I plan to continue working on the ldap web frontend, by finishing the login/signup systems, and the user settings page, and then start messing with the UI.