OpenDS Weekly Builds

As a developer, I find OpenDS very easy to check out and build. However, the process of checking out the code does require you have some way of accessing our Subversion repository. The process for doing this is documented in the OpenDS Source Guide available at, but we do realize that not everyone wants to worry about checking out and building the code. To make it easy to get for people that just want to take a look at the current state of the server, we upload a pre-built version once a week (typically on Friday -- I just uploaded build 006 a few minutes ago) based on the latest version of the code. You can access our weekly builds here. To give it a spin, just follow these steps:
  1. Download the latest weekly build and unzip the contents of the file to wherever you want to put it.

  2. Go into the OpenDS-0.1-build006 directory (or whatever directory was created by the version you are using) and run ./ on UNIX-based systems, or setup.bat on Windows. Follow the prompts to create the initial configuration for the server (just pressing ENTER to accept all the defaults, other than setting the root user password, will usually result in a working configuration).

  3. Run the bin/ script (or for testing purposes you may prefer "bin/ -nodetach", which will cause the server to run in the foreground without detaching from the console) on UNIX-based systems, or "bin\\start-ds.bat" on Windows (which will automatically create a separate console output window).

At this point, the server should be running and you can try talking to it with a tool like bin/ or bin/ Note that you need to have Java SE 5 or later (it works fine with recent Java SE 6 and Java SE 7 builds as well) installed on your system. On Windows (and potentially on UNIX-based systems if the java executable isn't in the PATH) then you may need to set the JAVA_HOME environment variable to point to the directory in which Java is installed.

When we upload a weekly build, we also send a message to the mailing list, and that message includes information about some of the biggest changes included in that build. If you want to keep up on these things, you can either join the mailing list or just look through the archive every once in a while. The message that we used for this week's build is provided below:
I have just uploaded OpenDS 0.1 Build 006, built from revision 262 of 
our source tree, to our weekly builds folder.  The direct link to 
download this file is:

Notable changes that have been integrated since build 005 include:

Revision 211 (Issue #603) -- Add a mechanism that may be used to 
determine the operating system on which the server is running.  It 
includes code to try and identify the following operating systems:  AIX, 
FreeBSD, HP-UX, Linux, Mac OS X, Solaris, Windows, and z/OS.  We may be 
able to use this information to tailor the operation of the server to 
the underlying platform in certain cases.

Revision 227 (Issue #601) -- Provide a mechanism for setting file 
permissions.  On UNIX-based systems, we will attempt to use the chmod 
command if possible, which will work properly on both Java 5 and Java 6 
and will also provide the greatest flexibility.  On other systems, if 
the server is running with Java 6 then it will attempt to use the new 
methods added to the class.

Revision 230 (Issue #588) -- Add initial MakeLDIF support, which can be 
used to generate entries based on a template.  This is similar to the 
MakeLDIF tool provided with SLAMD (although it is not yet completely 
implemented, and there may be cases in which the two will not be 100% 
compatible), although this version includes better validation of the 
template before generating entries.  Further, this capability has been 
directly integrated into the import utility so that it is possible to 
import data that is being generated on the fly rather than from an 
existing LDIF file.

Revision 242 (Issue #614) -- Update the client-side tools to help 
eliminate a potential race condition that could result from the reuse of 
LDAP message IDs.  On some systems, using the StartTLS extended 
operation could cause the client to reuse a message ID of an operation 
that was still being processed by the server, which would cause the 
server to reject the new request.

Revision 655 (Issue #604) -- Update the synchronization code to provide 
initial detection and resolution for conflicts that can occur when 
making updates on multiple servers at the same time.  Some of these 
conflicts include concurrent replacement of the same attribute in the 
same entry, modifying an entry on one server while deleting or renaming 
it on another, and concurrent creation of two entries with the same DN.

Revision 261 (Issue #618) -- Fix a bug that could impact indexed subtree 
searches using subInitial filters.


Post a Comment:
Comments are closed for this entry.



Top Tags
« July 2016