cn=Directory Manager

cn=Directory Manager
All about Directory Server

All | Personal | Sun

« Previous month (Jul 2006) | Main | Next month (Sep 2006) »

Friday September 22, 2006

Improving Test Coverage in OpenDS

For the last few weeks (and still for the next couple of weeks), we're in a push to improve our test coverage for the OpenDS project. This means that we're not adding lots of new features at the same rate we had been before this push (although there are still some that are sneaking through), but it will help us to ensure that when we get back to developing new features that we've got a good test framework in place to help us catch any problems that might come up.

Two of the main tools that we're using to help us with our testing are TestNG and EMMA. TestNG is similar to JUnit, but offers additional features like the ability to define test groups, and the ability to use annotations to mark your classes and methods accordingly (I do know that JUnit has recently released a new version with some of these features, but I haven't evaluated them to see how the two stack up now). I really like the @DataProvider annotation, which makes it possible to separate your test data from the test logic, but since it treats each run with a different data element as a separate test case it does seem to inflate the number of test cases (for example, TestNG reports that we're running over 10,700 test cases, but we only have about 950 test methods). Probably my biggest complaint with TestNG at the moment is that it doesn't have an assertNotEquals method (which is easy to work around but annoying nonetheless), so I guess that says something about the framework. I also hate like the use of JavaScript in the HTML-formatted reports that it generates and on the TestNG website, but that's another matter altogether.

EMMA is a tool that makes it possible to provide code coverage analysis for Java applications. It will allow you to see what code is being called, and is especially useful in testing because it helps you see what still needs to be tested. It allows you to browse all of your source code so that you can see lines in green, yellow, and red (covered, partially covered, and not covered, respectively). It's annoying that the source code display uses a variable-width font rather than one that is fixed-width, but again that's a pretty minor grievance. I also don't really care for the way that it generates the report layout using filenames that change between runs (e.g., clicking refresh after re-running coverage tests might show me a different class), but that's also easy to work around.

We're currently up to about 41% code coverage, which I will grant you isn't as high as it should be (writing test cases was a step that we skipped early on in the project to help us get the basic framework up and running as quickly as possible), but it is rising pretty quickly since we were at only 12% a month ago. There are still big chunks of code (especially corner cases) that aren't covered, but in general things are looking pretty good. I am, however, very much looking forward to getting back to adding features once our coverage gets up where it needs to be, and in the future we will be ensuring that we provide adequate test coverage as we write the code so we don't fall behind again.

Posted by cn_equals_directory_manager ( Sep 22 2006, 05:52:34 PM CDT ) Permalink

Friday September 08, 2006

Why Run the Directory Server on Solaris?

Yesterday, someone asked why Solaris was the best platform on which to run Directory Server. While I may be a bit biased, I do believe this to be the case and feel that there is plenty of evidence to support it. This is true across the board. I'll try to list many of those benefits here, and also to avoid bashing or picking on any of the other operating systems that are available for use. Many of the other operating systems are quite capable and in some areas are able to meet or even exceed the corresponding offering from Solaris, but I don't think that any of them come close to providing the complete package.

General Platform Benefits

Solaris runs on lots of different systems, on the SPARC, x86, and x64 processors. Sun makes excellent hardware and our systems are frequently setting new world records in performance, but Solaris is certified on systems from lots of other hardware vendors and our hardware compatibility list contains more systems than most other UNIX or Linux vendors.
Compatibility and stability is taken very seriously. If you develop your applications based on public interfaces (and we have tools to help you do that) in current versions of Solaris, then they will continue to work in future versions. This is not necessarily the case on other platforms.
Solaris is available for use at no cost whatsoever if you don't need support. If you do need support, then the pricing plans are frequently less expensive than the offerings from other vendors.
Solaris is continually and rapidly improving. Solaris 10 has many significant improvements over previous releases, and it is continuing to get better.

Performance and Scalability Benefits

Solaris runs on systems with anywhere from 1 to 144 CPU cores, and anywhere from hundreds of megabytes to over a terabyte of memory. These constraints are primarily based on hardware that is currently available and not necessarily limitations in the operating system.
Solaris understands subtle but important differences between different types of hardware concurrency models (SMP, CMT, NUMA, dual/multi-core, HyperThreading, etc.) and can optimize its behavior accordingly.
Solaris has excellent resource management capabilities that make it possible to control how computing resources are allocated between processes. This can be done through fixed-size processor sets, variable-size resource pools, and through various scheduler models like the fair-share scheduler, the fixed-priority scheduler, and the real-time scheduler. An upcoming CPU cap implementation may also provide another mechanism for achieving fine-grained control.
Networking performance was significantly improved in the Solaris 10 release, and work is still ongoing to make it even faster and more scalable.
In many areas, the libumem memory manager provides dramatically improved performance (especially when compared with previous alternatives like mtmalloc), in addition to providing many features that can help identify memory leaks and other related problems. Upcoming enhancements to the virtual memory subsystem should even further improve performance, especially when working with very large caches.
UFS filesystem performance was dramatically improved in Solaris 9 updates and has been carried through to Solaris 10. In many cases (and particularly for the kinds of workloads that Directory Server has), ZFS is notably faster than UFS and offers many more attractive features like compression and snapshots that work well in a directory environment.
We do much more Directory Server testing on Solaris (both SPARC and x86/x64 systems) than on any other platform. If there is a performance problem with the server on Solaris, we are more likely to find it and fix it before it is released than on other platforms.

Security Benefits

The introduction of process rights management (also called least privilege) in Solaris 10 makes it very easy to provide the Directory Server with exactly the privileges that it needs to operate, and even to take away capabilities that it doesn't need. Even if an exploitable security hole were found in the Directory Server, least privilege can be used to severely constrain what a potential attacker could do. For older Solaris systems, role-based access control (RBAC) can be used to limit the need to have root access when starting the server, although it is not as flexible as process rights management.
Solaris containers (also called zones) can provide tightly-constrained environments for applications like Directory Server to operate in a manner that isolates it from anything else that might be running on the system. When used in conjunction with features like resource pools, containers can help limit the impact of denial-of-service attacks or other forms of resource exhaustion.
The Solaris cryptographic framework provides a centralized mechanism for encryption and message digest operations, particularly those using the PKCS#11 framework. Although the Directory Server is currently unlikely to benefit from hardware SSL acceleration in most cases, it can still use this mechanism for secure key storage using FIPS 140-2 compliant devices. In addition, future developments in hardware (e.g., the "free encryption" capabilities of the Niagara 2 processor) may provide performance benefits. Note that you will not be able to take full advantage of the Solaris cryptographic framework with the Directory Server until our upcoming 6.0 release.
Solaris BSM provides fine-grained auditing capabilities for keeping track of what happens on the system.
Additional security-related enhancements that will be available in the near future include Trusted Extensions (which adds labeling capabilities to Solaris 10), ZFS encryption, and a key management framework.
Solaris 9 has been evaluated at EAL4 for the CAPP and RBACPP protection profiles. Solaris 10 is currently under EAL4+ evaluation for the same profiles, and Solaris 10 with Trusted Extensions is also being evaluated with the LSPP protection profile.

Debugging Benefits

DTrace provides complete observability into virtually all aspects of the system in a way that is unmatched by any competing offerings. Even for external users without access to the Directory Server source code, it is very useful to be able to collect information about the underlying system and the way that the Directory Server interacts with it. For cases in which there is a problem with the Directory Server, engineering may be able to provide custom DTrace scripts for more detailed analysis of a problem without a significant impact on the running server.
All of the standard performance analysis tools are available (e.g., vmstat, iostat, mpstat, etc.), but a number of additional tools are also provided, including lockstat/plockstat, prstat, cpustat, and trapstat. These can help identify potential problems or bottlenecks that may be responsible for unnecessarily low performance.
The coreadm utility provides a mechanism for managing core file creation, and offers a way for allowing setuid/setgid processes like the Directory Server to dump core (which is not allowed by most UNIX-based operating systems).
The service management framework (SMF) provides a mechanism for ensuring that services are started appropriately when the system boots, and can also monitor processes and restart them if a failure is detected. SMF can also provide further integration with process rights management to offer greater control over what rights are granted to and removed from individual processes.
Much of the Solaris source code is available through OpenSolaris (and more code is being released all the time), which can make it easier to understand how the underlying system works. The new Solaris Internals books also go into great detail on the design and implementation of the operating system. In addition, OpenSolaris provides direct access to the engineers responsible for major components of Solaris.

Posted by cn_equals_directory_manager ( Sep 08 2006, 05:58:14 PM CDT ) Permalink

Friday September 01, 2006

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 https://opends.dev.java.net/public/docs/index.html, 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:

Download the latest weekly build and unzip the contents of the file to wherever you want to put it.
Go into the OpenDS-0.1-build006 directory (or whatever directory was created by the version you are using) and run ./setup.sh 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).
Run the bin/start-ds.sh script (or for testing purposes you may prefer "bin/start-ds.sh -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/ldapsearch.sh or bin/ldapmodify.sh. 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 builds@opends.dev.java.net 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:

https://opends.dev.java.net/files/documents/4926/39978/OpenDS-0.1-build006.zip

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 java.io.File 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.

Posted by cn_equals_directory_manager ( Sep 01 2006, 05:48:47 PM CDT ) Permalink