Okupy – Report #3

Quick summary:

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 past two weeks I’ve finished the LDAP bits, plus I’ve added some more features mostly needed for development purposes. In the settings files, the administrator can provide a bunch of variables:
  • the OU(s) the users are stored (there is support for multiple OUs, for example to separate users from developers with ou=users and ou=developers, while keeping unique usernames)
  • the credentials for the anon user (minimal privileged user to perform LDAP queries in case the anonymous search is disabled, both cases are covered in the app)
  • credentials of the admin user (needed mostly for user creation), the objectClasses for new users, the base attribute to search for users (uid and cn are the most common)
  • a map with user profile attributes (Django has only username/password/email/real name in its base profile, it is easily extendable though by specifying a connection between user profile fields and LDAP attributes)
  • a map with LDAP and ACP groups (for example, is_infra, is_devrel etc, depending on the LDAP permissions the user is able to view or touch other user’s data)

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.

3 Responses to Okupy – Report #3

  1. jms says:

    “it will replace Gorg and provide Beacon as WYSIWYG editor to edit the XML files”

    Very interested/curious bout this.
    jms

    Reply
  2. Pavel says:

    Hi, there’s been some discussion at http://hwoarang.silverarrow.org/2011/06/28/council-manifesto-2011/ about how docs/wiki might be handled in Gentoo (hopefully) better then they are right now. Maybe you’d like some of the ideas (i.e. proxy maintaining docs, docs validation, etc.) and could implement them in your GSOC? Thanks, Pavel

    Reply
  3. tampakrap says:

    Here [1] is my full proposal. I thought of putting a “Send to bugzie” button instead of Save when a non-privileged user edits a doc, and a diff will be produced and sent to the docs team. Apart from that, gsoc period is too small, I can’t accept any feature requests now, it has to wait for September

    [1] http://www.google-melange.com/gsoc/project/google/gsoc2011/tampakrap/27001

    Reply

Leave a Reply