Entries by Thijs Kinkhorst

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.

A survey has shown that 16% of youth doesn't know why we're celebrating the 5th of May. According to quality news show Editie NL, this is a worrying fact. Well, is it? I find it rather reassuring that appearently 84% of the younger generation do know that 5 May is about the libration from German occupation (I remember now that I forgot to thank the Canadiens when I was there two weeks ago). 16% is not much: if you get a 16% discount you're usually not making a great deal. Actually, I would be very surprised of a survey that would show that less than 16% of people are completely ignorant of the world around them. These same people probably would't know the connection between the colour of the national team's shirts and the royal house, or be able to tell whether St Nicolaas is a protestant or catholic. Or the ones that claim money because -6 is larger than -5.

Every country has its fair share of "challenged" people. Also in recent news is that Barack Obama is losing votes because he admitted to eating rucola (arugula) from time to time. Voter's "reasoning" boils down to "if I don't know what that is, then a president that eats it can't be trusted". It gets even more sad when you realise that these people probably do know it, but don't realise they call it rocket. Great way to lose votes.

There is some discussion again about what should be on topic for Planet Debian, whether it should be used for Debian-related announcements and what the archival policy should be. I believe that this discussion is rooted in two circulating views of what Planet Debian should be:

1. A forum for DD's to post Debian-related thoughts and ideas, to be used for those cases where they think a mailing list post may be less appropriate;
2. A way to collect stories about what DD's do and think in any context, the human interest angle: get to know your Debian peers more than just in technical matters.

Although I always regarded Planet Debian to be the latter and I appreciate reading posts telling me about someone's job or other interests, either one isn't an invalid approach per se. They do however prompt different choices about listing policy (Debian-only feeds vs. everything goes), how much effort it is to keep up with them and perhaps archival.

The best way to match the expectations of those two groups would be to create two "planets", one for each group. Create an aggregator where any DD can add any of their feeds, and another one with a strict listing policy: only feeds that carry posts actually related to Debian development matters (probably a subset of the first). Then only the question remains which one will get to carry the Planet Debian name...