2

 
 
By Jason Brooks  |  Posted 2005-09-19 Email Print this article Print
 
 
 
 
 
 
 


Red Hat Inc.s Red Hat Directory Server is an open-source, LDAP-based directory server descended from the popular and mature Netscape/iPlanet code base that Red Hat purchased from America Online Inc. last year.

While eDirectory and Active Directory have their roots in their respective operating system hosts (although eDirectory now supports multiple platforms), RHDS is born of e-commerce application roots, and these roots show.

RHDS runs on the x86 versions of RHEL 3 and 4, on Sun Microsystems Inc.s Solaris 9 for 32-bit and 64-bit SPARC platforms, and on Hewlett-Packard Co.s HP-UX 11i for HP-9000 and HP Integrity servers.

In eWEEK Labs tests of RHDS, which began shipping in June, we were impressed by the products provisions for scalability and its comprehensive graphical administration tools.

We were also pleased with RHDS extensive and well- written documentation, which provides good information not only on installing, configuring and maintaining the product but also on planning out a directory services infrastructure.

RHDS will fit best at sites with an existing Netscape/iPlanet implementation because RHDS has the same code base and ships with facilities for migrating from and interoperating with those products.

The graphical tools, documentation and replication options that impressed us may also woo The OpenLDAP Foundations OpenLDAP sites because these are some of the oft-cited gripes associated with the prominent open-source directory server project.

In addition, RHDS should prove attractive to companies that have yet to move away from Microsoft Corp. Windows NT domains or to begin deploying Microsofts Active Directory.

Speaking of active directory, one of the main functional gaps between RHEL (Red Hat Enterprise Linux) and rivals NetWare, Windows Server and even Mac OS X Server has been the absence of well-integrated directory services.

Although Red Hats Linux distributions have long come bundled with directory server software in the form of OpenLDAP, this software has never been closely integrated with RHEL in the way that Active Directory is integrated with Windows Server and Novell Inc.s eDirectory is integrated with NetWare.

The fact that Red Hat has invested in a directory services product of its own looks to be a step toward filling this integration gap, but many steps remain to be taken before RHDS can be a core part of RHEL.

For now, RHDS is even less integrated with RHEL than OpenLDAP is. To manipulate RHDS using the same rc scripts as other Linux services, we had to write them ourselves.

In addition, RHDS resides in the /opt partition, where third-party software typically goes in Linux distributions. This meant, among other things, that we had to alter our executable files to run the command-line LDAP tools that come with the product.

Nevertheless, we found RHDS rather easy to install, and once we were up and running on our test systems, we could handle nearly all configuration and management tasks through the products Java-based graphical management console.

After installing RHDS on one of our test servers—we tested on an IBM eServer 325 with VMware Inc. virtual machines running RHEL 4—we populated a database on the new directory with user information that wed created using a free sample data generation tool from Novell. (The tool is available at www.novell.com/ coolsolutions/tools/14215.html.)

The Novell data generation tool output the data in LDIF (LDAP Data Interchange Format), which we could then import into our directory from the management console. We could also export our directory data in LDIF.

We hit a snag the first time we attempted to import our sample data because of a difference in the "inetorgperson" schema used by the data generator tool and the one that comes with RHDS. Through the console application, we were able to fairly easily define a new schema in RHDS that inherited all the attributes of "inetorgperson," plus the few other attributes from our sample data.

We configured Evolution and Thunderbird mail clients to access our test RHDS instance with authentication credentials from one of the users wed created, and we could browse through the other user entries wed created, as well as modify our authenticated users information on the server.

After modifying the entry of one of our test users to include POSIX user log-in information, we were able to log our user in to a SuSE Linux 10 machine, which wed configured to use LDAP authentication, without a hitch.

RHDS enables administrators to imbue their directory services infrastructure with optimal scalability and performance through single-master, multimaster and cascading replication schemes, various combinations of which may be used depending on the sites needs.

For a particular set of directory information, RHDS supports as many as four master servers, each of which carries a read/write replica of the database in which the information is stored.

Multimaster replication has the benefit of enabling smooth failover. If one of the masters goes down, the slave replicas and client applications can continue to access and update directory data.

Because most LDAP client applications are configured to fetch data from one particular directory source, administrators must implement a separate mechanism for load balancing across RHDS servers, such as round-robin DNS (Domain Name System). It would be great to see Red Hat build a mechanism such as this into future versions of its software.

OpenLDAP does not provide for multimaster configurations, out of concern that multiple masters can lead to data inconsistency. RHDS manages the collisions that occur when separate masters receive conflicting updates by favoring the more recent change and by flagging for administrative attention the conflicts it cant resolve.

RHDS allows for scheduling replication operations—for instance, to replicate less time-sensitive data during off-hours. RHDS also allows for fractional replication, allowing administrators to hold back large or infrequently updated attributes from replication over slow links or sensitive data over potentially insecure connections.

RHDS costs $15,000 per master server per year and $3,000 per replica server per year. By comparison, Novells eDirectory is priced at $2 per user license, and Suns Java System Directory Server, which shares a common lineage with RHDS, is priced at $1,250 per 1,000 entries.

However, one of RHDS toughest rivals—in terms of feature equality and, more strikingly, price—is FDS (Fedora Directory Server), which is freely available from fedora.redhat.com. As far as we could discern, the two releases are identical except for superficial branding differences.

We tested FDS alongside RHDS and configured an instance of Fedora as a read-only replica for our RHDS master server. The two pieces of software worked together with no problems.

The main difference between the two offerings, other than cosmetic ones, is support. As with RHEL and Fedora Core, RHDS is supported by Red Hat and FDS is not—at least not through standard support agreements.

During tests, we found the participants on the FDS IRC (Internet Relay Chat) channel, some of whom were Red Hat engineers, very helpful.

Next page: Evaluation Shortlist: Related Products.



 
 
 
 
As Editor in Chief of eWEEK Labs, Jason Brooks manages the Labs team and is responsible for eWEEK's print edition. Brooks joined eWEEK in 1999, and has covered wireless networking, office productivity suites, mobile devices, Windows, virtualization, and desktops and notebooks. JasonÔÇÖs coverage is currently focused on Linux and Unix operating systems, open-source software and licensing, cloud computing and Software as a Service. Follow Jason on Twitter at jasonbrooks, or reach him by email at jbrooks@eweek.com.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Close
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel