Powerful Open Source LDAP

From Port389

Developers should check out our building and install guides to see how to build and install the server from source. Then you can get working on fixing bugs, adding new features or improving our documentation. For other ideas see ways to contribute.

To browse through our backlog of development tickets, access the 389 Trac instance.

For details on checking out and building the 389 Console, see the building console page.

Or you can jump directly to instructions on installing the server.

If you want to contribute code to the project you should look at our contributing page. It contains information on the process you have to go through to be able to submit patches we will accept as well as getting a git and/or CVS account. From a more technical standpoint, before submitting a patch you should check out our coding style guide. Once your patch is approved, see the git Rules and/or CVS rules before checking anything in.

You should also be take some time to review our license.

Source Code

We use git as our SCM

As of July 2011 all of the 389 components are in git at fedorahosted.org. CVS cvs.fedoraprojet.org is deprecated. Please use git instead.

FHS style packaging

389 can be built to use FHS style, /opt FHS style, or user specified prefix - see FHS_Packaging

Directory Server Plugins

It is possible to write plugins that allow you to extend the functionality of the Directory Server. Our plugins page contains information on the API and the scope of the functionality. You might also want to look at our annotated license page for some legal information on using the plugin api.

Release Engineering

Release_Procedure

Testing

Not a coder? No problem. You can help by finding new bugs, verifying existing bugs, polishing documentation and generally improving the quality of the server.

A good way to contribute to improving the quality of the server would be to add automated tests for each of the features. Developers and contributors to the 389 Project are encouraged to write unit tests for any new features, updates and bug fixes being contributed. Where possible, the tests should be data driven. This allows for greater numbers of test cases covering more of the feature under test, to be written with minimal effort. We suggest tests be written in a scripting language like python, sh, or Perl ( Perl::Test ).

There are a number of other LDAP test tools available from other groups and companies which may be of interest:

  • DirectoryMark from Mindcraft, is an LDAP benchmarking tool
  • Slamd is a distributed LDAP load generation engine
  • Using_SystemTap - an example of using SystemTap to profile thread contention

What can you do?

Contributors