Friday Sep 14, 2007

OpenDS 1.0.0-build005 is now available

I have just uploaded OpenDS 1.0.0-build005, built from revision 3056 of our source tree, to our weekly builds folder. The direct link to download the core server is https://opends.dev.java.net/files/documents/4926/68459/OpenDS-1.0.0-build005.zip. The direct link to download the DSML gateway is https://opends.dev.java.net/files/documents/4926/68461/OpenDS-1.0.0-build005-DSML.war.

I have also updated the archive that may be used to install OpenDS via Java Web Start. You may launch that using the URL http://builds.opends.org/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information.

NOTE: -- Even though it is displayed as an option in the QuickSetup installer, we do not support upgrading from previous OpenDS builds to the 1.0.0-build005 release. There are some changes in this release that are not backward compatible with the configuration used by previous releases, and these changes may cause the upgrade process to fail.


Detailed information about this build is available at http://builds.opends.org/weekly-builds/1.0.0-build005/. Some of the changes that have been incorporated since OpenDS 1.0.0-build004 include:
  • Revision 2796 (Issue #2030) -- Update the filesystem entry cache to provide the ability to use a compact entry encoding.

  • Revision 2804 (Issues #2104, 2162) -- Update a number of the command-line utilities so that they operate in interactive mode rather than non-interactive mode by default.

  • Revision 2806 -- Update the account status notification handler API so that it is possible to provide additional properties along with the notification. This makes it possible to develop account status notification handlers that can act more intelligently and/or provide more useful information.

  • Revision 2811 (Issue #2097) -- Fix a problem in which total update initialization can fail to send a message to the replication cache.

  • Revision 2820 (Issues #43, 72) -- Implement support for the numSubordinates and hasSubordinates virtual attributes. Also, provide a new dbtest tool, which can be used to perform low-level debugging for the backends using the Berkeley DB Java Edition.

  • Revision 2824 (Issue #581) -- Provide an SMTP account status notification handler that can be used to send e-mail messages whenever an account status notification is generated. The notification message can be sent to the user that is the target of the notification and/or a specified set of administrators. The messages that will be sent are generated based on user-editable templates.

  • Revision 2843 (Issue #1831) -- Implement complete support for an interactive mode for dscfg. The tool now provides a menu-driven interface for examining and updating the server configuration.

  • Revision 2856 -- Update the CreateRCScript tool so that it provides the ability to specify the user that the server should run as, and also lets the user specify the JAVA_HOME and JAVA_ARGS settings that should be used. Also, update the start-ds and stop-ds commands to support a "--quiet" argument, which causes them to not generate any output. This mode will be used when starting and stopping the server through the generated RC script.

  • Revision 2877 -- Fix a memory leak that can occur when a backend based on the Berkeley DB Java Edition is disabled.
  • Revision 2879 (Issue #2180) -- Fix a problem in the JE backend in which contention on an index key might cause that key to contain an incomplete or incorrect value.

  • Revision 2882 (Issue #2205) -- Fix a problem that caused replication to behave incorrectly when a replicated change included an attribute type that was not defined in the schema of the target server.

  • Revision 2889 (Issue #2158) -- Add support for storing compressed schema representations in the JE backend and re-enabled the compact entry encoding by default.

  • Revision 2894 -- Add number of new configuration definitions for objects that were previously using "generic" definitions. This will help make it much easier for users to create new instances of these kinds of configuration objects.

  • Revision 2899 -- Add new directory environment properties that can be used to indicate whether the server should maintain a configuration archive, and if so the maximum number of archived configurations that should be maintained.

  • Revision 2900 (Issue #1945) -- Update the server so that it has the ability to save a copy of its current configuration into a ".startok" file whenever it starts successfully. Also, expose an option in the start-ds script and in the directory environment configuration that provide the ability to start the server using the "last known good" configuration rather than the current configuration.

  • Revision 2904 (Issues #1481, 2031) -- Add the ability to set any Berkeley DB JE property in the server configuration, for both backends based on the Berkeley DB Java Edition and the filesystem entry cache.

  • Revision 2913 (Issue #257) -- Implement support for a plugin that can be used to maintain referential integrity within the server. Whenever an entry is deleted or renamed, then any references to that entry in a specified set of attributes will be removed or renamed accordingly.

  • Revision 2921 -- Update the LDAP connection handler to explicitly close the selector when it is disabled or the server is shut down to prevent problems with being unable to re-bind to that port when the server is restarted.

  • Revision 2926 (Issue #139) -- Implement support for a maximum blocked write time limit in the LDAP connection handler. If an attempt to write data to the client is stalled for too long, then the client connection will be terminated.

  • Revision 2932 (Issue #261) -- Implement support for a 7-bit clean plugin, which can be used to ensure that the values of a specified set of attributes will only be allowed to contain ASCII characters.

  • Revision 2933 (Issue #2218) -- Update the LDIFPluginResult object to provide a mechanism that can be used to indicate why an entry should not be imported/exported.

  • Revision 2935 (Issue #1830) -- Implement support for secure communication in the dsconfig utility.

  • Revision 2950 (Issue #2216) -- Implement support for an LDIF connection handler, which may be configured to watch for new LDIF files to be created in a specified directory and have changes defined in those files automatically applied in the server through internal operations.

  • Revision 2955 (Issue #2181) -- Implement support for delete and modify operations in the task backend.

  • Revision 2961 -- Update a number of command-line tools that can be used to perform operations either directly against a backend or through the task backend so that if a port number and/or bind DN are provided, then the tool will default to using the tasks interface.

  • Revision 2966 -- Implement support for encryption and authentication when using replication.

  • Revision 2974 (Issue #2155) -- Update the server configuration so that a password storage scheme is referenced by its DN rather than the storage scheme name.

  • Revision 2986 -- Update the replication changelog database so that it implements the backend API. This provides the ability to backup and restore the changelog database, and provides a groundwork for future LDAP access to the changelog contents.

  • Revision 2998 (Issue #1594) -- Provide the ability to expose a monitor entry for the server entry cache.

  • Revision 2999 (Issue #2057) -- Update the server to provide a basic framework to control when plugins will be invoked. In particular, this adds the ability to indicate whether a plugin should be invoked for internal operations, and it also adds the ability to have plugins that are notified whenever changes are applied through synchronization. The unique attribute plugin has been updated so that it can detect uniqueness conflicts introduced through synchronization and generate an alert to notify administrators of the problem.

  • Revision 3006 -- Make a number of minor changes to improve server performance.

  • Revision 3008 -- Update the server configuration handler to fix a problem in which some change listeners may not be notified when the associated entry is updated.

  • Revision 3024 -- Make a number of additional changes to improve server performance.

  • Revision 3031 (Issues #1335, 1336, 1878, 2201, 2250) -- Provide new utilities that can be used to configure the server to participate in a replication environment.

  • Revision 3033 -- Upgrade the Berkeley DB Java Edition library to version 3.2.44.

  • Revision 3044 -- Make a couple of minor changes to improve server performance.

  • Revision 3048 -- Add a new tool that may be used to manage tasks defined in the server.

  • Revision 3051 (Issue #2059) -- Display SHA-1 and MD5 digests of a certificate fingerprint instead of the complete certificate when prompting the user about whether the certificate should be trusted in the status panel.

  • Revision 3054 -- Update the server so that it is possible to call EmbeddedUtils.startServer after having previously called EmbeddedUtils.stopServer. Previously, the server shutdown process did not leave the server in a sufficient state to allow it to be restarted in the same JVM.

Sunday Aug 26, 2007

OpenDS 1.0.0-build004 is now available

I have just uploaded OpenDS 1.0.0-build004, built from revision 2794 of our source tree, to our weekly builds folder. The direct link to download the core server is https://opends.dev.java.net/files/documents/4926/65720/OpenDS-1.0.0-build004.zip. The direct link to download the DSML gateway is https://opends.dev.java.net/files/documents/4926/65721/OpenDS-1.0.0-build004-DSML.war.

I have also updated the archive that may be used to install or upgrade OpenDS via Java Web Start. You may launch that using the URL http://builds.opends.org/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information.

Detailed information about this build is available at http://builds.opends.org/weekly-builds/1.0.0-build004/. Some of the changes that have been incorporated since OpenDS 1.0.0-build003 include:
  • Revision 2567 -- Update the global ACI definitions to ensure that anyone will be allowed to use the password policy request control by default.

  • Revision 2569 (Issue #2061) -- Update the "Who Am I?" extended operation handler so that it works properly in conjunction with the proxied authorization control and alternate SASL authorization identities.

  • Revision 2570 (Issue #2059) -- Update graphical panels to eliminate cases in which some panels used a different background color than the underlying window. Fix a problem in which it was necessary to click a button twice in order to accept a certificate. Make sure to display a more appropriate representation of the certificate fingerprint.

  • Revision 2584 (Issue #752) -- Implement support for subordinate modify DN plugins, which can be used to receive notification whenever an entry is renamed because of of its superiors was targeted by a modify DN operation.

  • Revision 2586 (Issue #1894) -- Provide the ability to clean up replication information in other servers when uninstalling an instance with replication configured. Also, eliminate the statuspanel.jar file to try to keep the total number of JAR files to a minimum (for easier embedded use), and minimize the number of classes that go in quicksetup.jar to reduce the initial download time when launching QuickSetup.

  • Revision 2595 -- Update the global ACI definitions to ensure that anyone will be allowed to use the authorization identity request control by default.

  • Revision 2601 (Issue #2087) -- Implement support for an identity mapper that can use regular expressions to transform the provided ID string before searching for the appropriate matching user.

  • Revision 2611 (Issue #423) -- Implement support for nested static groups. If the member/uniqueMember attribute of a static group references the DN of another group, then the members of that child group will be considered members of the parent group.

  • Revision 2612 -- Provide a new org.opends.server.util.EmbeddedUtils class that can be used to simplify the process of running the server as an embedded application. It includes methods for starting, stopping, and restarting an embedded server, as well as a means of determining whether the server is currently running.

  • Revision 2613 -- Provide a new @PublicAPI annotation type that can be used to tag code to indicate whether we consider it part of our public API, and if so what the stability level is for that code (i.e., how likely the interface is to change in an incompatible manner in the future) and the ways in which it may be accessed by third-party developers.

  • Revision 2614 (Issue #2098) -- Update the DIGEST-MD5 processing code to properly degrade to initial authentication whenever a client attempts to use subsequent authentication.

  • Revision 2619 (Issue #588) -- Implement support for the "list" tag in MakeLDIF. Note that the syntax for this implementation is not the same as the syntax used for the version of MakeLDIF provided with SLAMD, but it is more internally consistent with other tags that are part of MakeLDIF.

  • Revision 2641 -- Migrate to a new framework for message handling within the server. This will provide a much better framework for future I18n support, and moves the default English-language messages to properties files rather than having them embedded in the code.

  • Revision 2648 -- Correct a number of spelling errors identified in the English-language messages.

  • Revision 2650 -- Apply the @PublicAPI annotation to packages and classes that are part of the OpenDS codebase to indicate their anticipated role in our public API.

  • Revision 2660 -- Add a new convenience constructor for the InternalClientConnection class that makes it possible to create a connection authenticated as a given user by providing only that user's DN.

  • Revision 2664 -- Provide a new EmbeddedUtils.initializeForClientUse() method that can be used to initialize the proper internal structures so that OpenDS code can be more easily used for client-side use.

  • Revision 2687 (Issues #788, 791) -- Update the replication mechanism so that it has the ability to automatically repair inconsistencies that may be detected.

  • Revision 2706 -- Add a new internal LDAP socket implementation that provides a mechanism for leveraging third-party LDAP SDKs to perform internal operations in OpenDS. This makes it easier for applications that already support communication with external LDAPv3 directory servers to also interact with an embedded OpenDS instance. This capability has been tested with both JNDI and the Mozilla LDAP SDK for Java.

  • Revision 2707 -- Merge the installation and upgrade utilities into a single application. Now, when you launch QuickSetup via Java Web Start, you will be asked whether you want to install a new server or upgrade an existing installation.

  • Revision 2721 -- Implement support for an attribute uniqueness plugin, which can be used to ensure that the values for a specified set of attributes are all unique throughout the server (e.g., that no two users are allowed to have the same uid or e-mail address).

  • Revision 2736 (Issue #1602) -- Fix a problem in the replication code in which the removal of the entry at the root of a replication domain could cause a large number of changes to be replayed.

  • Revision 2737 (Issue #1804) -- Update the replication code so that the server can generate an administrative alert whenever a replication conflict is detected.

  • Revision 2743 -- Update the import-ldif and export-ldif tools so that they can be used to launch tasks to perform the import and export operations in addition to operating directly on the backend.

  • Revision 2748 (Issue #2134) -- Fix a problem in the configuration of VLV indexes that prevented them from being managed through the dsconfig tool.

  • Revision 2750 (Issue #2097) -- Fix a problem in the replication total update code that could cause initialization to fail if the replication code received any messages that were not related to the total update.

  • Revision 2755 (Issue #2103) -- Fix an issue with log rotation that could cause it to behave incorrectly if the time interval was changed and the new value was shorter than the previous value.

  • Revision 2757 -- Update the backup and restore tools so that they can be used to launch tasks in addition to operating directly on the backend.

  • Revision 2772 (Issue #2135) -- Add a configuration option that can be used to store entries using a more compact encoding.

  • Revision 2780 -- Update the default server configuration to ensure that the uniqueMember attribute type is indexed for equality.

  • Revision 2781 -- Add a tool that can be used to base64 encode or decode data provided as a string, contained in a file, or piped in via standard input.

  • Revision 2783 -- Update the lock manager configuration to provide a property that can be used to indicate whether fairness should be guaranteed for contended locks.

  • Revision 2784 (Issue #526) -- Add a mechanism for generating an RC script that can be installed on UNIX systems to configure the server to automatically start when the system boots. Also, update the stop-ds script so that if the server is to be stopped using a kill but no PID file is present, then the stop script will generate an error rather than trying to stop the server using a task (which is guaranteed to fail, since no credentials will have been provided).

Monday Aug 20, 2007

Internal operations in OpenDS

If you're interested in writing an extension to OpenDS (like a plugin, password validator, identity mapper, virtual attribute provider, etc.), then there's a decent chance that you'll want to be able to search for or make changes to content in the directory as part of your processing. And if you intend on using OpenDS in an embedded manner, then it's almost certainly going to be a requirement for you. One option could be to simply establish a connection to the LDAP listener and issue a request, but that's inefficient and can also have undesirable side effects (e.g., if your plugin creates a new LDAP operation, then the server will try to invoke plugins on that operation, which can create a kind of infinite recursion loop). A better alternative, however, is to perform internal operations within the server. Performing an internal operation is more efficient than creating a new external operation, and internal operations can do things that aren't allowed for external operations (e.g., update attributes marked as NO-USER-MODIFICATION) and they are also marked as internal operations so that it's possible to do things like skip plugin processing for them.


The Internal Client Connection Object

For quite a while now, OpenDS has provided the org.opends.server.protocols.internal.InternalClientConnection class, which offers a relatively simple way to perform internal operations in the server. To use it, you first need to obtain an internal client connection, which you can do in one of the following ways:
  • If you don't need to worry about enforcing access control for the internal operation, you can use the InternalClientConnection.getRootConnection() method. This will give you a connection established as an internal user with root privileges (bypass-acl, modify-acl, config-read, config-write, ldif-import, ldif-export, backend-backup, backend-restore, server-shutdown, server-restart, disconnect-client, cancel-request, password-reset, privilege-change, and unindexed-search) that can do just about anything in the server.

  • If you do want access control enforced for the internal operation (e.g., only do this operation if the authenticated user has the right to do it), then you will want to get an internal client connection as that user. To do that, you can create a new internal client connection with either the InternalClientConnection(DN) or InternalClientConnection(AuthenticationInfo) constructor.

Once you have a handle to the internal client connection, then you can use it to perform internal operations in the server. For example, to perform a simple search, you can use something like:
InternalSearchOperation searchOperation =
     internalClientConnection.processSearch("dc=example,dc=com", SearchScope.WHOLE_SUBTREE,
                                            "(uid=john.doe)");
for (SearchResultEntry matchingEntry : searchOperation.getSearchEntries())
{
  // Do something with the entry.
}

We've added lots of convenience methods in the InternalClientConnection class to help make performing internal operations easy, and we hope to have official documentation on this in the near future. For now, however, you can look at the Javadoc from our latest daily build to see what's available.


The Internal LDAP Socket

The internal operations API referenced above should be easy to use, and should allow you to do pretty much anything that you need. I would expect that someone who has ever done any programming involving an existing LDAP SDK (e.g., JDNI or the Mozilla LDAP SDK for Java) should find it especially easy to pick up. However, last week I was talking with some people who were interested in embedding OpenDS and had a bit of a dilemma because they wanted to be able to embed OpenDS and communicate efficiently with it, but they also wanted to have the ability for their application to communicate with external directory servers, and they wanted to avoid having to write all of their client code twice (once using the OpenDS internal API, and another time using the Mozilla LDAP SDK for Java which is their API of choice for external LDAP communication). I gave this a little thought and came up with a solution that I think is a rather elegant approach to the problem: I created a custom socket implementation that is able to convert LDAP requests into internal operations, process the operation, and then convert the response back into LDAP.

This code is implemented in the org.opends.server.protocols.internal.InternalLDAPSocket class, which extends the java.net.Socket superclass. Going along with this socket (and doing all the real work behind the scenes) are the InternalLDAPInputStream and InternaLDAPOutputStream classes. As long as the LDAP SDK that you are using supports the use of a custom socket factory, you can use this custom socket implementation to allow you to use that LDAP SDK to perform internal operations. Both JNDI and the Mozilla LDAP SDK for Java support this, and I've tested my implementation with both of them.

For JNDI, if you want to use this custom socket implementation, the only thing that you have to do out of the ordinary is to make sure that your environment properties have the "java.naming.ldap.factory.socket" property set to "org.opends.server.protocols.internal.InternalLDAPSocketFactory". For example:
Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY,
        "com.sun.jndi.ldap.LdapCtxFactory");
env.put("java.naming.ldap.factory.socket",
        "org.opends.server.protocols.internal.InternalLDAPSocketFactory");
env.put(Context.PROVIDER_URL, "ldap://doesntmatter:389/");
env.put(Context.SECURITY_AUTHENTICATION, "simple");
env.put(Context.SECURITY_PRINCIPAL, "cn=Directory Manager");
env.put(Context.SECURITY_CREDENTIALS, "password");

DirContext context = new InitialDirContext(env);
// Do whatever you want with the connection here

For the Mozilla LDAP SDK for Java, there's just a tiny bit more that you have to do, because it uses its own socket factory implementation (netscape.ldap.LDAPSocketFactory) instead of the one provided by the JDK (javax.net.SocketFactory, although to be fair that class didn't exist when the Mozilla SDK was written). That interface requires a single makeSocket method, which you can implement as follows:
public Socket makeSocket(String host, int port)
{
  return new InternalLDAPSocket();
}

When you're creating a connection with the Mozilla LDAP SDK for Java, then all you need to do is to use the LDAPConnection(LDAPSocketFactory) constructor to have it use that socket factory for its communication. As an example, I have written a simple EmbeddedMozillaLDAPSDKTest program that can be used to start an embedded OpenDS instance, perform some internal operations using the Mozilla LDAP SDK for Java, and shut down the server. In order to create an appropriate environment for this test, all I needed to do was:
  1. Create an empty directory to use as the server root.
  2. Copy the config directory structure from an OpenDS installation into the new server root.
  3. Create a lib directory below the new server root and copy all of the lib/\*.jar files from an OpenDS installation into it.
  4. Create empty db, logs, and locks directories below the new server root
Then, when I compiled and ran the program, it started the server, interacted with it using the Mozilla SDK, and shut it down again. Note that I could have trimmed things down even more if I wanted to put more effort into it (e.g., we don't need everything under the config directory, and if we disable loggers then we wouldn't have needed the logs directory, etc.), but I wanted to keep this example simple.


Limitations of the Internal LDAP Socket Implementation

In general, if you're using the internal LDAP socket implementation you can do pretty much anything that you could do if you were talking to OpenDS using actual LDAP network communication. However, there are a few important things to note about this implementation:
  • You can only use clear-text communication when interacting with the Directory Server. This implementation doesn't support the use of SSL or StartTLS to secure the communication, but that really shouldn't be a problem since there's no actual communication and the operations never leave the JVM.

  • This implementation does not support the use of SASL authentication, so only simple binds are allowed. Although technically it would have worked with some mechanisms (e.g., ANONYMOUS, CRAM-MD5, DIGEST-MD5, and PLAIN), others (in particular, EXTERNAL and GSSAPI) would not have worked. Again, given that all the communication is purely internal to the JVM, I really didn't see a need to use anything other than simple authentication, so that's all that is exposed.

  • Abandon operations don't do anything. OpenDS doesn't provide a mechanism for abandoning internal operations, so any abandon operation requested in this manner will simply be ignored. Although I haven't tested it, I would expect that attempts to use the LDAP cancel extended operation would probably be rejected with a "cannot cancel" result.

Friday Aug 03, 2007

OpenDS 1.0.0-build003 is now available

I have just uploaded OpenDS 1.0.0-build003, built from revision 2550 of our source tree, to our weekly builds folder. The direct link to download the core server is https://opends.dev.java.net/files/documents/4926/63458/OpenDS-1.0.0-build003.zip. The direct link to download the DSML gateway is https://opends.dev.java.net/files/documents/4926/63459/OpenDS-1.0.0-build003-DSML.war.

I have also updated the archive that may be used to install OpenDS via Java Web Start. You may launch that using the URL http://builds.opends.org/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information.

Detailed information about this build is available at http://builds.opends.org/weekly-builds/1.0.0-build003. Some of the changes that have been incorporated since OpenDS 1.0.0-build002 include:
  • Revision 2446 (Issue #1986) -- Update the graphical and command-line setup mechanisms to attempt to detect and prevent install paths into directories containing a percent sign, especially on Windows.

  • Revision 2447 (Issue #2006) -- Update QuickSetup to prevent users from choosing the same ports for different protocols (like LDAP and LDAPS).

  • Revision 2448 (Issue #221) -- Add a general framework that may be used to allow OpenDS to send e-mail messages. Also, add an SMTP alert handler that can be used to send e-mail messages in response to administrative alerts generated within the server.

  • Revision 2449 (Issue #452) -- Add a new "targetcontrol" facility to the access control framework that can be used to restrict which clients are allowed to use specified request controls.

  • Revision 2457 (Issue #1819) -- Provide the ability to define certain configuration options as "advanced". This will make it possible to hide these options in administrative interfaces like dsconfig unless the user explicitly requests to see advanced options.

  • Revision 2461 (Issue #1849) -- Fix a problem with the evaluation of the debugsearchindex operational attribute (used to provide information about index processing performed during a search) in which evaluation was not correct with double-negation (a "NOT" inside a "NOT").

  • Revision 2475 (Issue #1015) -- Update a number of the command-line tools provided with OpenDS so that they include improved debugging support. When used in "--verbose" mode, they can now trace the contents of incoming and outgoing LDAP messages and ASN.1 elements in many cases.

  • Revision 2479 (Issue #443) -- Add a new access control "extop" keyword that can be used to restrict which extended operations may be invoked for a given client.

  • Revision 2480 (Issue #1831) -- Provide initial support for an "--interactive" mode for the dsconfig tool. This provides a basic text-based, menu-driven interface for interacting with the server configuration, although there are a number of known issues that still need to be addressed with this capability.

  • Revision 2483 (Issue #1971) -- Allow partial non-append imports for a backend with multiple base DNs (i.e., allow content under one base DN to be imported without impacting content below other base DNs in the same backend).

  • Revision 2499 (Issue #38) -- Provide a mechanism for performing VLV indexing, which makes it possible to efficiently use virtual list view and server-side sorting for searches that might not otherwise be indexed and/or inefficient.

  • Revision 2500 -- Fix a problem in access control evaluation in which use of the targetattr keyword to match all attributes except a named list could incorrectly grant access to operational attributes.

  • Revision 2503 (Issue #429, 478, 2025) -- Add support for a new disconnect client task that can be used to allow an appropriately-privileged administrator (needing at least the "disconnect-client" privilege) to terminate a client connection if the need arises. Also, add a "Get Connection ID" extended operation that can be used to allow a client to get the connection ID associated with its connection.

  • Revision 2505 (Issue #2024) -- Implement support for restricting the set of tasks that can be invoked in the server. Only those tasks which are listed in the ds-cfg-allowed-task attribute in the cn=config entry may be invoked in the server.

  • Revision 2508 (Issue #1683) -- Provide a mechanism to disable privileges in the server if necessary. If a given privilege is disabled, then it will be assumed that all clients have that privilege.

  • Revision 2509 (Issue #1787) -- Provide a configuration option that makes it possible for an administrator to control whether responses to failed bind operations should be allowed to include an error message that explains the problem. By default, this message will not be included for security reasons, but administrators may configure the server to allow it to be sent to provide the client with information about the reason for the failure.

  • Revision 2512 (Issue #2027) -- Provide a way to configure each alert handler with an explicit set of alert types that will be allowed or ignored. This makes it possible to restrict the types of alerts that a given alert handler will be asked to process.

  • Revision 2514 (Issue #118) -- Update the server to provide support for an idle time limit configuration option for LDAP clients. That is, it is now possible to configure the server to automatically terminate a client connection if it has remained unused for too long. The idle time limit is a server-wide configuration option, but it can be overridden on a per-user basis.

  • Revision 2515 (Issue #2026) -- Ensure that processes launched by QuickSetup will use the same JVM as is used to run QuickSetup, even if an alternate JAVA_HOME is configured in the environment.

  • Revision 2521 -- Update the status panel utility so that it can communicate with the server over a secure communication channel. If the server certificate is not trusted, the user will be prompted about whether to accept it.

  • Revision 2529 (Issue #2033, 2034) -- Update the task backend to provide the ability to send an e-mail message whenever a task is complete. The set of recipients may be configured on a per-task basis, and it is possible to specify whether the message should always be sent or only if the task fails.

  • Revision 2533 (Issue #1991) -- Improve the "dsconfig list-properties" output and make its usage more consistent with other dsconfig subcommands.

  • Revision 2535 (Issue #2032) -- Update the password policy to ensure that the sum of the minimum password age and the password expiration warning interval should always be less than the maximum password age (if the corresponding options are configured). This will prevent undesirable configurations, like a minimum age that is greater than the maximum age, or sending expiration warning messages to the client during a time when the user is not allowed to change the password.

  • Revision 2539 -- Update the access control handler to provide the ability to control whether a smart referral (i.e., a named subordinate reference as per RFC 3296) should be returned to the client.

  • Revision 2542 -- Fix a problem with the way that the Netscape password expired control was being encoded to ensure that it always has an appropriate value.

OpenDS switching to bi-weekly builds

For the last year we have generally made pre-packaged OpenDS builds available once a week. There have been a few exceptions, but in general we've had a weekly build schedule. Starting with this week's build (or actually, with last week's lack of a build) we are changing to a bi-weekly (i.e., fortnightly -- once every two weeks, not twice a week) process. The main reason for this is that our QA team has started looking more closely at what goes into these builds and has continued to improve their test coverage. Since at least some of this isn't automated and involves manual testing, reducing the frequency of these QA-tested builds gives them more time to get other stuff done (like writing new automated test cases) in between verifying builds that we want to make public.

So what, if anything, does this change? Not a whole lot. Of course, since they have two weeks of effort instead of one, there will be a larger number of changes from one build to another. But at least for now, where you get the builds (https://opends.dev.java.net/servlets/ProjectDocumentList?folderID=5700&expandFolder=5700&folderID=0) won't change and there will still be places that refer to them as "weekly" builds, although we'll probably clean up these references at some point.

If the arrival of the latest OpenDS build is the highlight of your week and you're not sure how you'll be able to handle waiting twice as long between builds, you can always look at our daily builds (http://builds.opends.org/daily-builds/), or you can check out and build the code for yourself whenever you want. But for this week, you should be able to get your fix in a few minutes when we post OpenDS 1.0.0-build003.

Friday Jul 20, 2007

Configuring OpenDS with dsconfig

Like the Sun Java System Directory Server, the configuration in OpenDS is stored in an LDIF file rooted at "cn=config", and can be read and updated over LDAP. As of DSEE 6.0, the Directory Server also has a Web-based administration GUI, as well as a command-line utility named dsconf that can be used to manage the server configuration. For OpenDS, we don't yet have a widespread administration GUI, but starting with this week's build we have a new command-line tool named dsconfig that can be used to interact with the server configuration. On UNIX systems, you can find it at bin/dsconfig; on Windows, it's bat\\dsconfig.bat.

Matt Swift (who has done most of the development of the dsconfig tool, and the underlying administration framework) has written a document that describes the dsconfig utility and gives an overview of how to use it. You can find that on our documentation wiki at https://www.opends.org/wiki/page/ConfiguringOpenDSUsingTheDsconfigTool.

Note that the documentation page for this tool also includes a section at the bottom with some known issues and potential usability problems that we intend to fix in the near future. However, we would also appreciate any feedback that you might have (e.g., problems that you've encountered or suggestions for improvement). If you find anything, feel free to open a new issue in our issue tracker (https://opends.dev.java.net/servlets/ProjectIssues) or send an e-mail to dev@opends.dev.java.net.

OpenDS 1.0.0-build002 is now available

I have just uploaded OpenDS 1.0.0-build002, built from revision 2441 of our source tree, to our weekly builds folder. The direct link to download the core server is https://opends.dev.java.net/files/documents/4926/62416/OpenDS-1.0.0-build002.zip. The direct link to download the DSML gateway is https://opends.dev.java.net/files/documents/4926/62417/OpenDS-1.0.0-build002-DSML.war.

I have also updated the archive that may be used to install OpenDS via Java Web Start. You may launch that using the URL http://builds.opends.org/install/QuickSetup.jnlp, or visit https://www.opends.org/wiki/page/OverviewOfTheQuickSetupTool for more information.

Detailed information about this build is available at http://builds.opends.org/weekly-builds/1.0.0-build002. Some of the changes that have been incorporated since OpenDS 1.0.0-build001 include:
  • Revision 2382 (Issue #1897) -- Update the verify-index and rebuild-index utilities to include a "--countErrors" option that can be used to return a non-zero exit code if any errors are encountered.

  • Revision 2391 (Issue #1771) -- Update the entry cache implementations to ensure that they flush all entries from a backend whenever it is taken offline.

  • Revision 2405 (Issue #1988) -- Implement a monitor provider that can be used to publish information about the client connections that are currently established.

  • Revision 2422 (Issue #1953) -- Update the Berkeley DB JE backend so that if a problem occurs in the database that causes a RunRecoveryException to be thrown, the server will provide notification in the form of administrative alerts.

  • Revision 2424 (Issue #339) -- Implement support for password history functionality. The password history can be maintained either based on the number of previous passwords, or the length of time the previous passwords have been retained, or both.

  • Revision 2428 (Issue #1603) -- Make updates to the way that the server attempts to register the Windows service on Windows Vista.

  • Revision 2430 -- When running the QuickSetup installer, if there are no backends found to replicate then disable the "Replicate Suffix" option and automatically select the "Create New Suffix" option.

  • Revision 2437 (Issue #90) -- Update the server to provide more complete support for the password policy control as defined in draft-behera-ldap-password-policy.

  • Revision 2438 -- Update the graphical tools to use the term "Base DN" instead of "Suffix".

  • Revision 2439 -- Update the server so that the set of alert handlers are configurable rather than always using a hard-coded JMX alert handler.

  • Revision 2441 -- Expose the dsconfig tool in the Directory Server build.

About

cn_equals_directory_manager

Search

Top Tags
Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today