Voila!

Update: I've been granted commit access to the simplesamldokuwiki project, so instead of below text I advise to use the README as shipped with the 0.4 release instead of below steps.

If you want to provide a wiki but want to leave the authentication to one or more external identity providers, like an identity federation, Dokuwiki and simpleSAMLphp are a good combination. However, the existing documentation is lagging behind on developments in these software packages (i.e. doesn't work anymore), so here's what worked for me.

Ingredients:

A Debian 5.0 Lenny system.

Dokuwiki Debian Lenny package (0.0.20080505-4+lenny1).

simpleSAMLphp Debian squeeze package (1.6.2-1).

SSP is not available in Lenny yet but the package from Squeeze installs cleanly on Lenny.

simpleSAMLdokuwiki integration package.

Note that I'm linking to a bug report - you need the file version included in the bottom of that bug report, because the released versions are outdated.

I assume you have read the Dokuwiki and simpleSAMLphp documentation for information on how to install and configure either one; this article purely focuses on the integration part; not on e.g. how to connect an IdP to simpleSAMLphp.

• Install the Debian packages and make sure they work; dokuwiki is accessible and simpleSAMLphp is accessible and configured for your IdP. The simpleSAMLphp website is a good resource for this.
• Put the simplesamlphp.auth.class downloaded from the bug report somewhere on the system, e.g. /opt/simplesamldokuwiki
• Enable the authentication class:

  cd /usr/share/dokuwiki/inc/auth && ln -s /opt/simplesamldokuwiki/simplesamlphp.auth.class

• Add the following to /etc/dokuwiki/local.php (tune attribute names, add more Dokuwiki settings as desired of course):

  $conf['authtype'] = 'simplesamlphp';
  
  $conf['simplesamlphp_path'] = '/usr/share/simplesamlphp';
  $conf['simplesamlphp_attr_user']     = 'urn:mace:dir:attribute-def:eduPersonPrincipalName';
  $conf['simplesamlphp_attr_name']     = 'urn:mace:dir:attribute-def:cn';
  $conf['simplesamlphp_attr_mail']     = 'urn:mace:dir:attribute-def:mail';
  $conf['simplesamlphp_attr_grps']     = 'groups';
  

• In /etc/simplesamlphp/config.php, set the following so they can share a cookie:

          'session.phpsession.cookiename'  => 'DokuWiki'
  

I also provided a patch to the simplesamldokuwiki class cited above to enable the IdP to not pass a 'mail' attribute: see bug report.

As I'm currently attending the EUgridPMA meeting in Zagreb I thought I'd share a bit of this project I've been working on for the past year: the TCS eScience project.

In the scientific world lots of calculations are performed on distributed computing platforms known as grid. Because users of other institutions will be using your hardware, authentication is needed and this problem has been solved with x.509 personal certificates. The problem however, is that these certificates of course have to be issued by some CA. Currently in Europe alone there are over 40 active CA's, even multiple per country, dedicated to this job. They are accredited through the EUgridPMA which meets regularly. For scientists, it's often cumbersome to obtain a certificate: find your local CA, present an ID (probably in person), and sometime later receive your certificate. The process can take days or even weeks. Scientists are not interested in CA's but just want to practice science.

Our solution is a central web portal where users can request a certificate and have it delivered in minutes. This leverages the fact that identities of scientists normally have already been vetted at their home institution: users log in to the portal via federated login. Their home institution passes a special attribute that declares "Yes, we have really seen photo ID of this person and the name is correct". This attribute must of course not be passed for guests or test users or role accounts. However, it may still be easy to mass-provision it. In the Netherlands for example, the employer is required by law to verify the identity of each employee, so all employees can be automatically assigned the attribute.

After logging in and uploading (or generating) a csr, the request is passed in the back end to the Comodo API. This also means that we do not need to perform the complex operations of running an online CA (with hardware crypto devices, crl's, etc.). The use of Comodo is part of the same deal as the TERENA Certificate Service for host SSL certificates. The Comodo API responds within two minutes with the certificate which the user can download.

Currently 10 European countries are involved with the project (nl no se fi dk at cz it fr be), and more have shown interest. The certificates we issue have been accredited by the EUgridPMA so can be used on the grid. A separate but similar service is being set up for 'regular' personal certificates for the academic community, e.g. for s/mime usage. More details are in the presentation and paper by portal software developers Henrik and Thomas at the most recent TNC.

In a setup where we use Apache FastCGI with PHP through mod_fcgid and suEXEC, we experienced the problem that long running scripts always resulted in a 500 Internal Server Error after exactly 40 seconds. This is due to the IPCCommTimeout setting, but changing that setting didn't seem to yield any effect.

I stumbled on a blog entry saying that they only work within the VirtualHost block. I tried this for my test-vhost but it also didn't work. It took me a while to find the complete solution (workaround): you need to specify IPCCommTimeout in every VirtualHost block, because a later VirtualHost will globally reset your setting in a previous one.

So until this bug is fixed the neat workaround is to place the mod_fcgid settings in a separate configuration file and Include that file inside each VirtualHost.

Today everyone in the Netherlands received a letter about the new national electronic health record (EPD) and the possibility to object against registration. EPD aims to provide access to one's patient data to every care provider through a central information broker. I have submitted the form to disallow my data to be accessed through this system.

First of all, there's no clear benefit for me, and I think that goes for the large majority of people. The possible situation where someone has a critical condition and isn't treated by his regular doctor and is unable to inform the stand-in of this and the stand-in has the time to delve through the entire EPD and actually finds and correctly interprets the necessary information seems extremely small for anyone, let alone the big majority that doesn't suffer such critical conditions in the first place. Hence, making it the default for everyone seems very inappropriate. See also this interesting article, written in Dutch by my uncle.

Interestingly the same minister was recently opposed to a default-allow for organ donorship, which may address a problem that is much more real.

The other concern is security. I am not worried by the technical security of the system, it seems to be of acceptable standard (see this report by my friend Niels). I am more concerned about access restrictions: these are implemented post hoc, that is, anyone can access my file and I can check who accessed my it and whether they had the right to. However, this procedure involves sending in paper forms which I think in practice will not bring about much review.

Combined this project reminds me of voting computers - introducing new concerns while solving no actual problems.

Yesterday I attended a lecture by professor D.J. Bernstein, best known for his products like qmail, owner of one of the coolest domain names in the world and for his often controversial but always interesting visions.

His talk focused on why the majority of internet traffic still is not encrypted. We protect our email passwords but the 95% of other things we do is completely unprotected from a sniffer. He then narrowed it down to DNS. The problems with DNSSEC are evident and it's still a question of whether it will ever be implemented (after 15 years the design is still in flux, let alone that it's properly implemented or actually used).

On a more constructive side he presented his own solution: DNSCurve: using elliptic curve cryptography to not only sign but also encrypt DNS traffic, and do so on the fly rather than the cumbersome precomputation approach of DNSSEC. Bernstein shows that the extra cost of on the fly cryptography is, even for root servers, very minor compared to the costs of the entire system, but it does significantly reduce the administrative burden compared to DNSSEC. As usual he has made an interesting case, a worthwhile read.

Our friend Jaap is besides a mathematical researcher also an aviator. Last weekend he took Erik, Judith and me on a flight from Hoogeveen (EHHO) in Drenthe to the island of Ameland (EHAL). It's a really nice experience to plan the flight on the map, fly over land, the Waddensea and the North Sea, hear the radio communications; and the check-in was a lot more relaxed compared to EHAM (Schiphol). On the other hand the on-board catering left something to be desired.

all pictures are here

A few weeks ago we released version 2.2.0, and now version 2.2.1 of DOMjudge, our programming contest jury system. I'm actually very satisfied with the 2.2 branch because it implements some important wishes that users of the system had, especially moving nearly all state into the one central database instead of spread over db, files and hosts. It is getting more and more complete on the functionality side.

Our next target, 3.0, will focus on a different part: installing the system and getting it running is not quite trivial. The system has grown organically, and the current setup procedure tries to install everything at once, from building the judging environment, setting up the web interface to generating the documentation. We aim to pull that apart so it gets easier and the administrator keeps better oversight. But that's all for the next contest season. Meanwhile, the 2.2.x branch will be maintained for bugfixes at least until ultimo 2008.

This morning's newspaper featured a front page article reporting that elementary schools are bad at math. The third paragraph states:

"The quality of arithmetic education has a strong variation. Nearly a quarter of all schools is weak, over a quarter are strong. Exactly half scores 'average'."

Maybe I've been badly educated, but don't those statistics match what should be expected? If it's a normal (gaussian) distribution, both the lower and higher scoring chunks should be about the same size and indeed, the average part should be by far the largest. Of course I could be misunderstanding it all, probably due to me also being educated under this system.

The msttcorefonts package, downloader of the Microsoft Core Fonts for the Web, has been renamed to ttf-mscorefonts-installer to be more in line with other TrueType font packages (this is in testing since today).

But better news is that it hopefully is losing relevance: a few weeks ago, the ttf-liberation package entered testing. The Liberation fonts are good replacements for Arial, Courier New and Times New Roman, created by RedHat and released under a free licence. Users requiring these three fonts can just install the ttf-liberation package from main, rather than use the (necessarily) convoluted downloader from contrib. Quite a win for Debian's compatibility with the Windows World.

Recently my Nikon D70s, when using a new Sigma lens, displayed the following error in the aperture display: fEE. As it took me some time to find out the cause and fix it, I'll explain it here perhaps for the benefit of others.

What does it mean? Some lenses require that the aperture is set to smallest when they are connected to the body (the largest f-number; this is usually coloured orange). fEE is indicated when the lens is connected wrongly and the camera refuses to operate until the lens is reconnected.

If like me you still get the fEE even though you've connected the lens correctly, then obviously something is broken. The camera "knows" whether the aperture ring is set to the right value due to a notch on the lens (rightmost picture) and a switch on the body ("EE Servo Coupling Post", left picture). In my case the switch on the body had broken off.

You can of course send your camera in for repair, but for me it was easily repaired by sticking a hairpin in the switch. A little piece of plastic and some superglue could work as well.

Here's a selection of pictures from a recent visit to the Efteling.

Click the icons for full versions or view full set. I'm still planning on making yet another web photo album software of my own based on a revolutionary idea. Maybe I will actually do it sometime, who knows.

For a project I was looking for a way to use GNU Mailman for mailinglist management (especially its powerful web based moderation, bounce handling and attachment scrubbing features) but storing the mailinglist member information in a SQL database. That's useful when you want to relate mailinglist members to extra information already in a database and functionality on an interactive website, and it's possible on a per-mailinglist basis. This turned out to be not very difficult but just not that clearly documented.

What I used:

• Mailman. I used the 2.1.x version packaged in Debian etch: an "open" system is just one apt-get away!
• The MySQL Member Adaptor available from rezo.net. There are several versions of MySQLMemberAdaptor around the web, but this one seems the most recent.

This explanation assumes you know how to work with Mailman in a regular setup, and things like creating databases and users under MySQL. Take the following steps:

1. Install and set up mailman as you would otherwise.
2. Put the MysqlMemberships.py file into the dir that is Mailman's base, this normally already has files like MemberAdaptor.py in it. For Debian this is /usr/lib/mailman/Mailman. You only need to add MysqlMemberships.py, the other files from rezo.net are not needed.
3. The create table query in MysqlMemberships.py does not work with MySQL 5, I had to apply this patch which I've sent to MySQLMembership's author in the meantime. This patch has been applied by Fil.
4. For bounce handling to work well, you may need this patch aswell: patch for Bouncer.py; it has been applied in Mailman 2.1.11 and up.
5. Create a database and a MySQL user, and add that information into your mm_cfg.py, like this:

   MYSQL_MEMBER_DB_NAME = "mailman"
   MYSQL_MEMBER_DB_USER = "mailman"
   MYSQL_MEMBER_DB_PASS = "somethingrandom"
   MYSQL_MEMBER_DB_HOST = "localhost"
   MYSQL_MEMBER_TABLE_TYPE = "wide"        # wide means one table per list, flat = one large table

6. Create a mailinglist like you normally would (e.g. via newlist). To enable the MySQL backend for just that list, create a file extend.py under /var/lib/mailman/lists/listname with the following content:

   from Mailman.MysqlMemberships import MysqlMemberships
   
   def extend(list):
           list._memberadaptor = MysqlMemberships(list)
   

   (whitespace is significant in Python).
7. It should work now! Upon receiving the first request for your list, the database table will be created automatically, which you can then populate. You may need to restart the mailman qrunner after you make further changes to your setup.