Interesting new features in OpenDS

As we've stated in the past, our intention is to make OpenDS better than any other directory server. This is true on multiple fronts, including performance, scalability, reliability, supportability, and feature set. All of the features that we want to include in OpenDS have been entered into the issue tracker, but I thought that I would highlight some of the more interesting new features here.

Configuration Features
  • Configuration Cloning (Issue #164) -- When creating a new instance of the server, it will be possible to clone the configuration of an existing instance.
  • Configuration Archiving (Issues #165, 166) -- The server will keep track of all of the configuration changes that are made over time and make it easy to determine who made what changes and when.

Backup/Restore and Import/Export Features
  • Incremental Backup and Restore (Issue #15) -- It will be possible to perform an incremental backup including only the database changes since the last incremental or full backup.
  • Compressed Backup and LDIF Export (Issues #16, 26) -- It will be possible to have the server compress database backups and LDIF exports, and to restore from the compressed archives.
  • Encrypted Backup and LDIF Export (Issues #17, 27) -- It will be possible to have the server encrypt database backups and LDIF exports, and to restore from the encrypted archives.
  • Hashed and/or Signed Backup and LDIF Export (Issues #18, 28) -- It will be possible to include a cryptographic digest and/or digital signature with a backup or LDIF export, and to verify that hash or signature upon performing a restore.

Backend Features
  • Index Verification Tool (Issue #42) -- We will include a tool with the server that will allow you to ensure that all of the indexes are in sync with the data.
  • Multiple Base DNs (Issue #48) -- It will be possible to include multiple base DNs in a single backend, which can help avoid the need to create a new backend for each suffix.
  • Better Database Portability (Issue #67) -- While the Sun Java System Directory Server allows for binary copy initialization in some limited cases, there will be fewer restrictions for OpenDS. In particular, there will no longer be requirements to keep the database stored in the same location on the filesystem, nor to use the same operating system or CPU architecture.
  • Database Preloading (Issue #60) -- There will be an option to allow the server to automatically preload portions of the database on startup so that the information will be read into caches for faster availability.
  • Better Debugging Options (Issues #69, 70) -- The server will make information available to clients about the processing performed as part of a search operation (e.g., how many potential candidate entries there are, and how candidate lists are merged).
  • NFS Support (Issue #566) -- The server will support the ability to store the database on an NFS volume (although it will not be supported to access the database from multiple systems concurrently).

Entry Cache Features
  • Run Without an Entry Cache (Issue #562) -- The server will provide the ability to run without any kind of entry cache (in fact, this is the default configuration).
  • Cache Filtering (Issue #563) -- The server will provide the ability to define include and exclude filters that can be used to control the kinds of entries that may be stored in the entry cache.
  • Better Memory Management Options (Issues #564,565) -- Entry cache sizing should be relatively simple and should not require much interaction from the administrator.

Connection Handler Features
  • Multiple Request Handlers (Issue #149) -- The server will provide the ability to have multiple threads used to read requests from clients, which can provide for better performance and scalability.
  • Ability to Disconnect Clients (Issue #429) -- The server will provide the ability for administrators to terminate client connections if it is deemed necessary (e.g., a particular client is sending a large number of inefficient requests to the server).
  • On-the-Fly Management (Issue #568) -- The server will provide the ability to enable, disable, create, and destroy connection handlers on the fly without the need to restart.
  • Stop Accepting without Disconnecting (Issue #150) -- The server will provide the ability to configure a connection handler so that it can stop accepting new connections without terminating existing connections, which can be used as a kind of graceful shutdown mechanism.

Security Features
  • Pluggable Keystores (Issue #412-415, 569) -- The server will provide the ability to obtain its SSL certificates from a variety of locations, including JSSE and NSS keystores, PKCS#12 files, and PKCS#11 devices. An API will also be provided to allow further extending this capability.
  • Multiple Root DNs (Issue #419) -- The server will provide the ability to have multiple root DNs in the server. This will allow for the use of different passwords (and potentially different password policies) for each root user, and will provide a better audit trail for operations performed by root users.
  • Strong Authentication for Root DNs (Issue #420) -- Root user accounts will be represented as entries, which will allow them to contain the information necessary to be used to perform SASL authentication.
  • Access Controls for Bind Operations (Issue #421, 440) -- The server will provide the ability to enforce access controls for bind operations, including binds by root users.
  • Hashed/Encrypted Compare-Only Attributes (Issue #467) -- The server will provide the ability to create attributes whose values are hashed or encrypted, and will not allow general searches against values for those attributes.
  • Scoped Privileges (Issues #468, 469) -- The server will provide a privileges capability, which can be used to assign capabilities to normal users that would normally only be available to root users. Further, those privileges may be scoped to constrain their effects in some way (e.g., a user may be exempted from access control evaluation, but only for a particular branch of the directory tree).

Password Policy Features
  • Pass-Through Authentication (Issues #294-300) -- The server will provide the ability to allow user passwords to be stored in other repositories (e.g., other directory servers, IMAP/POP3, Access Manager, Kerberos servers, etc.) and have authentication interact with that external repository to verify the user's password.
  • New Password Storage Schemes (Issues #310,312,314-318) -- The server will support a number of new password storage schemes, including the SHA-2 algorithms, as well as reversible schemes like 3DES and AES.
  • Storage Scheme Deprecation/Migration (Issue #323) -- The server will support the ability to automatically deprecate certain storage schemes so that if a user authenticates to the server and has a password encoded in one or more deprecated schemes it will be automatically re-encoded using the default schemes.
  • Idle Account Lockout (Issue #307) -- The server will provide the ability to automatically lock accounts that have not been used for longer than a specified length of time.
  • Account Expiration (Issue #543) -- The server will provide the ability to define an expiration time for accounts, so that they cannot be used after that time. This could be useful for temporary accounts like those used by contractors.
  • Pluggable Password Validators (Issues #334-341) -- The server will provide an API for defining password validators and will include a number of default implementations, including those based on the length of the password, the types of characters in the password, whether the password is in the user's password history, whether the password is contained in a given dictionary, and whether the password matches the value of any attribute in the user's entry.
  • Account Status Change Notification (Issue #483) -- The server will provide a mechanism for notifying users of significant changes to their account, including warning about an upcoming expiration, a password change or administrative reset, or a lockout due to failed attempts.

Logging Features
  • Multiple Concurrent Loggers (Issue #178) -- The server will allow administrators to configure multiple loggers of each type. For example, it will be possible to have multiple access loggers, with one capturing all information, another only logging failed operations, a third only logging write operations, etc.
  • Log Filtering (Issue #183) -- The server will make it possible to define log filters, which can be used to control which operations get written to a log.
  • Centralized Logging (Issues #180-182) -- The server will provide the ability for muultiple server instances to log to a centralized repository (e.g., to a central database, or to a shared filesystem).
  • Compressed Logging (Issue #185) -- The server will provide the ability to write log information in compressed form.
  • Encrypted Logging (Issue #186) -- The server will provide the ability to write log information in encrypted form.
  • Signed/Hashed Logging (Issue #187) -- The server will provide the ability to hash and/or sign log records as a means of tamper detection.
  • Rotation Actions (Issues #193-196) -- The server will provide the ability to perform various operations when a log file is rotated (e.g., compress on rotate, encrypt on rotate, sign on rotate, etc.).
  • Unique Message IDs (Issue #203) -- Every message that may be written to the server's error log or that may be included in a response sent to the client will be assigned a unique integer ID.

Monitoring/Alerting Features
  • Better Monitor Coverage (Issues #206-216) -- The server will provide the ability to publish more monitor information, so that it is easier to understand its performance and health state.
  • Integrating with External Systems (Issues #226-232) -- We will provide instructions that can be used to allow the server to integrate with external monitoring frameworks like Big Brother, HP OpenView, Nagios, BMC PATROL, and Tivoli Monitoring.
  • Pluggable Notification Mechanisms (Issues #219-224) -- The server will provide a notification mechanism so that administrators can be made aware of any significant problems or notable events that are encountered during processing.

Note that these aren't all of the new features that we're planning. We've got some other gems that we're thinking about as well. As I mentioned above, you can check our issue tracker for what should be a pretty complete list. If you have other ideas for features that you don't see in the list, then feel free to add them to the issue tracker yourself (anyone with the User role or higher in the project can file new issues), and if you're so inclined then you could even help us implement them.

I should point out that not everything listed in the issue tracker will necessarily be actually implemented in OpenDS, and if it is included then it might not be in the initial release. We're certainly working hard to make the server as feature-rich as possible, but we're not yet at the point at which we can make any guarantees about what will be available and when.


Post a Comment:
Comments are closed for this entry.



Top Tags
« July 2016