Red Hat's directory server [LWN.net]

Managing large networks is a challenging task in a number of ways. One of those challenges is dealing with user information throughout a large institution. A single system can keep that information in /etc/passwd, and a small network can rely on tools like rsync or NIS. When the scale of the network gets large enough, however, and a sufficient number of levels of politics gets in the way, simple tools will no longer do the job in an easy or reliable manner. There comes a point where this information needs to live in a central database and be made available as needed across the network.

The larger proprietary software vendors - Microsoft, Sun, Novell, etc. - have long offered directory server products aimed at large network ("enterprise") deployment. These products not only make basic user information available network-wide; they can also be used to distribute a wider array of information. Directory servers are a useful and necessary tool, and the competition in this area is fierce.

Red Hat has set itself up to compete directly with the other "enterprise" software companies. To that end, Red Hat has put together a number of valuable products and services, but, so far, it has not been able to offer a directory server as part of its solution. That gap in Red Hat's offerings has increasingly looked like a liability, especially as Novell increases its efforts to compete in the same space. So Red Hat needed a directory server. It found one, some time ago, when it acquired many of the remaining bits of Netscape from AOL. Since the acquisition, however, little has been heard about the former Netscape's offerings.

Until now. On June 1, Red Hat announced the availability of its directory server product. The (now) Red Hat Directory Server is fast, with an impressive array of capabilities; for the full list, see the product sheet [PDF]. The directory server product is sold like Red Hat Enterprise Linux: by subscription. Pricing is not yet available.

The Red Hat Directory Server also resembles RHEL in another way: it has a Fedora equivalent. The Fedora Directory Server Project is where the development work will be done; the site offers source, documentation, mailing lists, etc. It is, in other words, just another free software development project.

At the Fedora site, one can see that, in fact, not all of the directory server code has been released - yet. The server itself is available under a special GPL+Exception license. The code is generally governed by the terms of the GPL, with the exception that plugin modules can remain proprietary. Those modules, however, must restrict themselves to a carefully-specified set of interfaces; anything linking to any other part of the server can only be distributed under the GPL. Other parts of the system - the management console and admin server components - remain non-free, though they are available in binary format. Red Hat plans to free that code as well, but some work is involved; those components are written in Java, and do not play well with the free Java implementations.

The Fedora project has some ambitious goals; the best description of what they have in mind can be found in Christopher Blizzard's weblog. The project claims to want to bring in outside developers, and to make them "feel that they are equals." Given all that the directory server hackers want to do, they will almost certainly need some help from outside. Consider this:

One of our larger technical objectives - as I've said - is to integrate with as much software as possible. This means that when possible we're a configuration store for every application on a system. Every user pref. Every service on your machine can store its configuration in one of these servers. Have you ever had the vision of dropping a machine on a network and having it come up, self-install, and just start working? We'd like to see it too because it offers compelling cost of ownership argument that we think free software is in a unique position to provide. But it requires participation from the larger software development community. This means you and your project.

To some readers, this vision sounds like the Windows registry - except that it's a nightmare, monster central registry for thousands of users. The "everything lives in the directory server" approach clearly will not be for everyone. But, for people wanting to create a single, integrated environment across a large organization, this vision will have some appeal. It is truly a view of the network as a single, large computer, with a minimum of boundaries. It promises to reduce the cost of administering large numbers of systems. One can see why Red Hat thinks it needs to go in this direction to remain competitive in the future.

High-end directory servers have, so far, been the domain of expensive, proprietary software. The freeing of the Netscape server, if handled well, could bring an end to that era. So this move by Red Hat is important, and deserving of support. High-quality free infrastructure is a good thing.

(Log in to post comments)

OpenLDAP

Posted Jun 2, 2005 15:22 UTC (Thu) by cdmiller (subscriber, #2813) [Link]

Netscapes directory server was OK, but I see no current advantage in it over OpenLDAP. OpenLDAP has been "enterprise" level for several years, (running 30,000 student campuses etc.), and simply continues to improve. I doubt OpenLDAP will see a need to respond other than to continue with business as usual. The nice thing is there will now be 2 open source, "enterprise level", directory servers in the world placing pressure on Novell's and others proprietary offerings. Two GPL compatible enterprise level directory servers which can compete and use the best code from each other...

OpenLDAP

Posted Jun 2, 2005 16:42 UTC (Thu) by ccyoung (subscriber, #16340) [Link]

Actually that's 3 - as I understand Samba3 is reworking OpenLDAP for thier own use.

OpenLDAP (Samba4)

Posted Jun 2, 2005 21:04 UTC (Thu) by linuxbox (subscriber, #6928) [Link]

Indeed. But it appears that the Samba directory will be an all-new implementation, aimed precisely at meeting the needs of Samba4.

OpenLDAP

Posted Jun 2, 2005 17:43 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

If it's saner and easier to work with than Novell's eDirectory, this will make me very happy. That thing is a nightmare...

OpenLDAP

Posted Jun 9, 2005 14:23 UTC (Thu) by gouyou (subscriber, #30290) [Link]

Multi-master replication ?

Red Hat's directory server

Posted Jun 2, 2005 14:18 UTC (Thu) by khim (subscriber, #9252) [Link]

Not at all. "GPL+something" (where somethins is additional relaxation, not additional constraint) can be considered "plain GPL" as far as free software is concerned. Thus it does not add to "license mess". In fact I think it's preferred way to license stuff: you can easily add precise relaxation on "as needed" base (it's Ok to link with PHP/Zend-licensed software, it's Ok to use if you are only using this or that API, etc) yet for free software crown who does not like to read fine details it's just GPL, nothing more.

Red Hat's directory server

Posted Jun 2, 2005 21:30 UTC (Thu) by fergal (subscriber, #602) [Link]

"GPL+something" (where somethins is additional relaxation, not additional constraint) can be considered "plain GPL" as far as free software is concerned.

Not so sure about that. By relaxing this constraint you are achieving the goal of freedom of use. By allowing linking with unfree software you are hurting the goal of making everything else free because you are making it easier to maintain proprietary modules.

Red Hat's directory server

Posted Jun 9, 2005 9:52 UTC (Thu) by ringerc (guest, #3071) [Link]

While I can see where you're coming from, I think there are a few other important points there:
(a) GPL with exceptions is still way better than proprietary. It's still free. AFAIK you can also take it and "pure-GPL" it if you feel the need.
(b) The modules don't have to be non-free, and the exception doesn't have to permit non-free modules. It can simply be for modules that, for some reason, must have additional restrictions. A good example is MySQL, which offers exceptions for PHP and (AFAIK) OpenSSL.

Obvious licensing

Posted Jun 6, 2005 6:33 UTC (Mon) by frazier (subscriber, #3060) [Link]

Provided the example provided is correct (that the software is actually GPL + fewer restrictions), the obvious question is:
Why not release as GPL and an additional extended rights license? That would make things more compatible and understandable to everyone.

Red Hat's directory server

Posted Jun 2, 2005 19:01 UTC (Thu) by giraffedata (subscriber, #1954) [Link]

I've been trying for years to understand what a directory server is for. I can pretty much see how it could be more efficient than a shared filesystem for some things. But how does a directory server compare to a database server, such as a PostgreSQL server?

Red Hat's directory server

Posted Jun 2, 2005 19:39 UTC (Thu) by iabervon (subscriber, #722) [Link]

I'm not entirely sure myself, but I think that it's essentially a non-SQL database with a standardized network protocol to access it. If you used Postgres or mysql or Oracle or something like that, you would need each program that's using it to understand the specific network protocol. LDAP is standardized on the network, so that the clients don't have to have drivers for different servers. There's a lot of further stuff beyond just LDAP, which essentially amounts to a standard database schema for particular purposes, which is also standardized somewhat, and is based on the LDAP database structure rather than SQL.

How is LDAP different from a relational database?

Posted Jun 2, 2005 20:38 UTC (Thu) by nicku (subscriber, #777) [Link]

The main difference between applications that use an LDAP directory and those that use a relational database is that the directory server is likely to use a variety of clients from widely different sources, while the database often has the application coupled more closely.

The big advantage of LDAP is that standardisation has been more successful that for SQL. The protocol is simple enough for many applications to be able to use a directory directly.

Of course, a directory is usually faster to read than write, and is often used for authentication. We implemented an OpenLDAP directory at HKIVE(TY) in the ICT department so that we can have one source of authentication and user information rather than replicate this information for each application.

The structure of a directory is tree-shaped, rather then tables linked by keys.

Uses: authenticating computers in the laboratory running Linux, or Windows; authenticating web applications (such as online quizzes). You can read more about it here.

Red Hat's directory server

Posted Jun 5, 2005 7:03 UTC (Sun) by komarek (subscriber, #7295) [Link]

One thing the other posters didn't mention: you need your login program to authenticate against your directory. And/or your webserver, ftpserver, whatever. If you put all your user info in a postgres database, will your portal software authenticate against it? Will you need to write the glue code, or does it exist already? If you are using PAM for logins, will PAM support it?

NIS and LDAP are both widely used for login information. NIS support is built into the GNU C library, so that any properly-written program need not be aware of whether NIS is used or not. This includes the login program. More recently, though, PAM handles authentication. It will support both NIS and LDAP. I have no idea if it supports any relational databases. Apache will auth against NIS or LDAP. Plone will auth against LDAP (among others).

So you can't use just any old thing for authentication information, unless you are willing to modify client code.

Red Hat's directory server

Posted Jun 6, 2005 0:22 UTC (Mon) by giraffedata (subscriber, #1954) [Link]

One thing the other posters didn't mention: you need your login program to authenticate against your directory. And/or your webserver, ftpserver, whatever.

That's what I took the comments about there being a standard for directory services to mean. While there's no reason there couldn't be a standard for authenticating by using a relational database server, there isn't. The protocols that existing login programs, etc. use are directory protocols.

Of course that means a directory server isn't really what you need. What you need is an LDAP server, or a server of whatever other directory protocol your programs use.

The only comment I've seen that says directory servers are useful per se is the one that suggests for a simple directory lookup, a directory server can be more efficient than a general purpose relational database server and a directory protocol easier to use than SQL.

Easiness rather than enterprise features!

Posted Jun 9, 2005 10:07 UTC (Thu) by ringerc (guest, #3071) [Link]

It probably isn't. The issue is coming up with a way to store and access the config that's:
- simple enough for simple apps, from and admin *and* developer PoV
- flexible enough for the needs of complex apps
- admin friendly (you can diff it, use version control, it's easy to see documentation on each and every setting, it's viewable and editable, settings are easy to find, etc)
- developer friendly (easy to use for simple things, doesn't make hard things impossible or horifically ugly, clean & stable client library API shipped as standard with major distros, doesn't make being portable harder)
- relatively easy to port existing apps to
- not going to conflict horribly with the config schemes on other platforms (.plist for OS/X; windows registry) and cause admins to gag in horror at your "weird" app
- ... and no doubt more.

IOW, it's hard. Even once you come up with a good one, you have to convince the devs of existing apps that it's worth their time to port over to support, and that it won't cost them existing flexibility or cause problems for their users. Yeah... not easy.

Three cheers

Posted Jun 9, 2005 10:02 UTC (Thu) by ringerc (guest, #3071) [Link]

As a network admin, this has me mopping up a puddle of drool. We've had OpenLDAP for ages, which does its job very well. Unfortunately, it's (a) it almost feels like it fights you every step of the way when configuring things - to the point where tcpdump is the easiest way to debug most LDAP issues, and (b) it's a screaming nightmare to make most things talk to and work with an LDAP directory.

RH putting in real effort to get everybody using sensible and where possible CONSISTENT schema and concepts would be awesome. It sounds like they do plan do to just that, in terms of being proactive with projects and encouraging better LDAP support. This is where OpenLDAP has always fallen down from the admin perspective - it's a great tool, but often hard to see how to use well in your apps, and there's no "push" from the OpenLDAP folks to encourage more - and better - adoption.

Even things that are *obvious* candidates for LDAP use weird, inconsistent, and under-documented approaches. Find me two MTAs that use the same scheme for aliases - where the admin doesn't have to write the schema themselves first. Then there's Evolution, with it's LDAP write support for address books - but only with an evo specific schema, and Thunderbird, which solves that by just not being able to write to LDAP.

Any reduction in this frustration would be fantastic. I don't know about a full "settings-in-ldap" system ... it'd need a way to store the documentation with the settings, like a commented config file, and it'd need to avoid the limitations gconf has (and the consequent crime of apps just lobbing XML blobs into gconf). Hell, most apps are still a nightmare to configure centrally at all, in any way.

Something for general policy would just be awesome, though ... easy to set global defaults, icon visibility / quicklaunch contents, WM styles, search paths, etc etc.

I also do a bit of app development, so I'll be watching this with interest. Any sort of config library - so long as it's TOOLKIT AGNOSTIC, flexible, not too complicated for simple things, and ideally can even be used on other platforms - will be viewed with extreme interest.