I thought I would write up a note about the Fedora Directory Server. Although it didn’t get a huge amount of press, we did release something that we felt comfortable calling 1.0. (And then in true brown paper bag fashion, was quickly followed by 1.0.1.) Since then we’ve had many thousands of downloads and the traffic on the mailing list has been pretty high – it’s clear that people are downloading it and using it in the real world.
The 1.0 release is marked as such because we achieved a few important milestones:
1. This release is completely open source. The source for all of the components, from the admin server to the client side admin tools, is available under the GPL.
2. We managed to replace the somewhat aged (but still maintained) Netscape Enterprise Server in the admin server. We didn’t feel it was worth releasing another web server when apache is so well maintained and is the defacto standard on Linux systems.
We’ve had a lot of contributions for the wiki, especially in the area of getting the Directory Server to integrate with the huge amount of open source software that’s out there. The HOWTOs that have been filled in contain incredibly useful information.
As noted above we replaced the admin web server with something apache-based. One side effect of this is that we replaced the venerable mod_ssl with an module called mod_nss that uses NSS for crypto operations. There are a huge number of programs using NSS for crypto these days. These include Firefox, Thunderbird, Evolution, Gaim, OpenOffice, and a few of the server products. It’s well-tested and well-supported and its friendly licensing means that it can be used from just about any type of program, even those licensed under the GPL (where OpenSSL falls down pretty hard.)
One of the things that we’ve been discussing internally at Red Hat for a long time is how to make it easier to manage the various certificate databases that are popping up on Linux systems these days. From the Cert for your IMAP server, to sendmail to postfix to a host of client programs, everyone has their own certificate database. Each has to have its own system for managing those certificates and each has to have its own set of documentation describing how to do it. This has turned into a bit of a nightmare, and is something that we ought to be fixing.
NSS makes this a bit easier. It uses a database instead of just flat files for managing certificates. While it means that you have to use command line tools to import and export certificates, it also means that it’s possible to get at that information programatically. And that means it’s easier to write tools to manage certificates. In the most recent version of NSS it’s now possible to share that database among multiple programs. This is most compelling on the client side, where it would make sense if you could sign your email and documents (OOo apparently supports this) with the same certificate. Gaim, the web browser and mail client could all use the same certificate for authenticating to services that support client auth via certificates. It also means that instead of every program that uses crypto having to write its own interface for managing certificates, everyone can call out to the system service to do so. This turns certificate management into an operating system service instead of it being something that each program handled in its own way.
Anyway, that’s only part of the argument. But it’s a good opening salvo, both on the client side and the server side. The technology pieces are falling into place to unify certificate management – a huge part of a strong identity management story – on Linux systems.
