org.forgerock / org.forgerock.opendj

06 Nov, 2007

1 commit

02 Nov, 2007

2 commits

30 Oct, 2007

1 commit

  • ee0ceaa1   s set of files provides the workflow configuration manual mode. ... Browse Dir » 
    Until now, the workflows were automatically configured-a wokflow
was created for each base DN in the backends. When new suffixes
were added or when a backend was added, the associated workflows
were also created (and simillarly workflows were deleted as suffixes
or backends were removed).

With the manual mode, each and every workflow in the server must
be defined explicitely in the configuration. By default, the server is
running in automatic configuration mode. To have a server running
with manual configuration mode one must set the attribute in
cn=config:

    dn: cn=config
    ...
    ds-cfg-workflow-configuration-mode: auto|manual


No attribute means "auto" mode.

The workflow configuration consist of 3 parts:
- the configuration of workfow elements
- the configuration of workfows
- the configuration of network groups


The Workflow Elements - A workflow element is a basic task in a
workflow. The workflow elements are organized in trees and the
simplest tree is made of one element. For example, the workflow
element that wraps a local backend is configured as follow:

    dn: ds-cfg-workflow-element-id=userRoot,cn=workflow elements,cn=config
    objectClass: top
    objectClass: ds-cfg-workflow-element
    objectClass: ds-cfg-local-backend-workflow-element
    ds-cfg-workflow-element-id: userRoot
    ds-cfg-enabled: true
    ds-cfg-java-class: org.opends.server.workflowelement.localbackend.LocalBackendWorkflowElement
    ds-cfg-backend: ds-cfg-backend-id=userRoot,cn=Backends,cn=config

From an admin standpoint, the local backend workflow element
is an aggregation of a single backend (attribute ds-cfg-backend).
So we cannot disable/delete a backend as long as it is used by a
local backend workflow element.


The Workflows - A workflow is a chain of processing and it's
targeting all the entries under a given baseDN. The processing
is actually identified by the root node of the task tree described
above. The configuration of a workflow looks like:

    dn: ds-cfg-workflow-id=userRoot,cn=workflows,cn=config
    objectClass: top
    objectClass: ds-cfg-workflow
    ds-cfg-workflow-id: userRoot
    ds-cfg-enabled: true
    ds-cfg-workflow-element: ds-cfg-workflow-element-id=userRoot,cn=workflow elements,cn=config
    ds-cfg-base-dn:  dc=example,dc=com

From an admin standpoint, the local workflow is an aggregation
of a single elements (attribute ds-cfg-workflow-element).
So we cannot disable/delete a workflow element as long as it is used
by a local workflow.


The Network Groups - A network group defines categories for
client connection. The network group contains a set of workflows
and each client operation is routed to one (or more) workflow(s).
By default, the server create a default network group which contains
all the workflows defined in the server. The default network group
looks like:

    dn: ds-cfg-id=defaultNetworkGroup2,cn=network groups,cn=config
    objectClass: top
    objectClass: ds-cfg-network-group
    ds-cfg-id: defaultNetworkGroup2
    ds-cfg-enabled: true
    ds-cfg-workflow: ds-cfg-workflow-id=adminRoot,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=ads-truststore,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=backup,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=config,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=monitor,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=schema,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=tasks,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=userRoot,cn=Workflows,cn=config

From an admin standpoint, the network group is an aggregation
of several workflows (attribute ds-cfg-workflow). So we cannot
disable/delete a workflow as long as it is used by a network group.


A unit test named WorkflowConfigurationTest tests the configuration
of network groups, workflows and workflow elements.



git-svn-id: https://svn.forgerock.org/opendj/trunk@3388 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jdemendi
     

23 Oct, 2007

1 commit

  • 338c53a5   Fix for issue 2505 (Provide monitoring information about the number of entries on a given base DN) ... Browse Dir » 
    The following changes are aimed to include a new attribute in the backend monitor entry to provide the number or entries per base DN. This information is used by the status, status-panel, dsreplication and graphical setup to be able to display the number of entries under a given base DN even when there are several base DNs defined in the same database.

The way the new attribute appears in the monitoring entry is:

ldapsearch -w s -p 1389 -b cn=monitor ds-backend-id=userRoot ds-base-dn-entry-countdn: cn=userRoot Backend,cn=monitor
ds-base-dn-entry-count: 0 dc=ta
ds-base-dn-entry-count: 1 dc=ti
ds-base-dn-entry-count: 1 dc=to

I prefer this approach because in my opinion having the number of entries is more important that the suffix.  Anyway I think the discussion around the structure of the value is not crucial as long as the value is easy to parse (which is the case).

The new attribute is defined in the schema and the new OID assigned to it is 1.3.6.1.4.1.26027.1.1.434.

In order to have a minimum impact on performances, the method backend.numSubordinates is only called when there are several base DNs defined in the database.





git-svn-id: https://svn.forgerock.org/opendj/trunk@3361 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

13 Oct, 2007

1 commit

  • 4d0792f3   No issue. ... Browse Dir » 
    CryptoManager
Step 1 to factor a CryptoManager interface from the implementation.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3303 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     

10 Oct, 2007

2 commits

09 Oct, 2007

1 commit

  • 00d8b57d   More changes for Issue 466. ... Browse Dir » 
    When importing a secret key entry from ADS into the crypto manager, if a symmetric key that can be decoded by this instance is not present then request it from another server using the Get Symmetric Key extended operation.
Tested by configuring two servers to use 3DES password storage scheme in the default password policy, enabling replication between them and verifying that a user can bind with password to both instances.

git-svn-id: https://svn.forgerock.org/opendj/trunk@3281 41b1ffd8-f28e-4786-ab96-9950f0a78031
    coulbeck
     

02 Oct, 2007

1 commit

  • e986cdcf   More changes for issue 466. ... Browse Dir » 
    - Defines the schema for secret keys.
- Keeps the crypto manager secret key cache up to date with secret keys published in ADS.

git-svn-id: https://svn.forgerock.org/opendj/trunk@3238 41b1ffd8-f28e-4786-ab96-9950f0a78031
    coulbeck
     

28 Sep, 2007

2 commits

  • f031cee6   Fix for issue 2035 (Use OpenDS specific environment variables to determine the JVM to be used.) ... Browse Dir » 
    Use two environment variables to know which is the JVM to be used by the scripts: OPENDS_JAVA_BIN and OPENDS_JAVA_HOME.

When the setup creates the file lib/set-java-home it writes the contents of OPENDS_JAVA_HOME to it (instead of JAVA_HOME which was the previous behavior).

Before these changes, the scripts used to look for JAVA_BIN, then JAVA_HOME and finally for the contents of the set-java-home file.  The problem with this approach is that if the user required to specify JAVA_HOME or JAVA_BIN to an unsupported version of the JDK (because some other program in the machine had this requirement) the scripts of OpenDS could not run.  Now the checks that we do to figure out the JVM are done in the following order:
1. Check if OPENDS_JAVA_BIN is defined in the environment.
2. Check if OPENDS_JAVA_HOME is defined in the environment.
3. Check if OPENDS_JAVA_HOME is defined in the lib/set-java-home file.
4. Check if JAVA_BIN is defined in the environment.
5. Check if JAVA_HOME is defined in the environment.
6. Check if we can figure out the java installation by executing "type java" (in UNIX environments).

If any of the above checks is positive, we will try to use the JVM found.

Extras: the uninstall script on UNIX now checks that we are using a JDK compatible with 1.5 and displays a user friendly message if it does not.




git-svn-id: https://svn.forgerock.org/opendj/trunk@3235 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • 84501a72   Add support for specifying arbitrary constraints in managed object definitions a… ... Browse Dir » 
    …nd use it within the LDAP and JMX connection handlers to enforce their SSL/StartTLS settings. This feature will be re-used for other managed object definitions as the need arises.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3233 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

27 Sep, 2007

2 commits

  • c40a66ed   Improvements to aggregation support and foundation work for expressing arbitrary… ... Browse Dir » 
    … constraints within components.

This change adds support for defining arbitrary conditions which can be used to test properties and their values. Conditions can be used within aggregations to define 1) when a referenced managed object needs enabling and 2) when it is enabled. For example, the LDAP connection handler requires that its key manager provider and trust manager provider are enabled when it is enable and when either SSL or StartTLS are enabled.

Conditions are also intended for use within the existing constraint/dependency support. For example, it should be possible to indicate that a property "min" is always less than or equal to a property "max", or that when "use-ssl" is set to true, any required SSL configuration related properties are also defined. This will be implemented in a subsequent change (this change just focuses on the work required to resolve issue 1449).

This change adds support for the following conditions:

* logical "not"
* logical "and"
* logical "or"
* logical "implies"
* contains - determines if a property contains a particular value
* is-present - determines if a property has any values (incl. defaults)

More will be added as required.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3229 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • b8aa0ce3   Fix for issue #553, ... Browse Dir » 
    As described in Neil's comments, stop-ds can now read arguments values on a properties file. 

git-svn-id: https://svn.forgerock.org/opendj/trunk@3222 41b1ffd8-f28e-4786-ab96-9950f0a78031
    lutoff
     

26 Sep, 2007

6 commits

  • 09155e12   Update the 02-config.ldif schema configuration file to compact the OID ... Browse Dir » 
    allocations after the earlier refactoring to use a more consistent naming
for our configuration properties.  I have also updated the OID registry on
our wiki to reflect these changes.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3221 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • ce559388   Remove adm:oid elements as these are no longer part of the XML schema. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3213 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • fbb7f82c   corrected reference to start-ds script ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3212 41b1ffd8-f28e-4786-ab96-9950f0a78031
    kenneth_suter
     
  • e2517750   Update the Get Symmetric Key extended operation handler so that it has its own ... Browse Dir » 
    object class and config definition rather than relying on the generic
configuration.  This makes it easier to use through dsconfig.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3211 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • 5abb86e7   Merge branches/temp-admin@3208 onto trunk@3208. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3209 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • d72d5ef1   Update the backend API to include new isIndexed methods that can be used to ... Browse Dir » 
    determine whether a given attribute is indexed in a specified manner, or that
can be used to determine whether a specified filter is indexed.  At present,
all backends except the JE backend and the replication backend are considered
always indexed for all operations.  The JE backend is only considered indexed
based on its index configuration.  The replication backend is never considered
indexed.

Update the following components to make use of this new isIndexed capability:
- The DSEE-compatible access control handler will now log a warning message at
  startup if it detects that there is no presence index for the aci attribute,
  which can make startup take a long time on a big database.
- The group manager will now log a warning message at startup if any of the
  group implementation filters are unindexed, which can make startup take a
  long time on a big database.
- The referential integrity plugin now requires that all of the attributes for
  which referential integrity is to be maintained must be configured with
  equality indexes.
- The unique attribute plugin now requires that all of the attributes for which
  uniqueness is to be enforced must be configured with equality indexes.

This commit also updates the LDIF backend so that it is possible to
indicate via configuration whether its base DNs should be registered as public
or private base DNs.  The LDIF backend used as the admin root has been
updated so that it is considered a private backend.  The replication backend
has also been updated so that it is considered a private backend.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3206 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

25 Sep, 2007

5 commits

23 Sep, 2007

1 commit

  • ef5e5493   Add support for an LDIF backend. Entries in this backend will be held in ... Browse Dir » 
    memory, and all read operations will be served from memory, but the underlying
data will be stored in an LDIF file on disk and any write operation will cause
that LDIF file to be updated.

This backend supports all major operations, including moving/renaming non-leaf
entries with the modify DN operation, and also supports the subtree delete
control and LDIF import and export operations.  Backup and restore operations
are not currently supported.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3160 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

21 Sep, 2007

1 commit

20 Sep, 2007

3 commits

19 Sep, 2007

3 commits

18 Sep, 2007

1 commit

17 Sep, 2007

1 commit

  • 539109e2   Implement a new configuration definition called "TopCfgDefn" which acts as the p… ... Browse Dir » 
    …arent of all other configuration definitions. This is analogous to the the "top" object class in LDAP.

The principle use of the TopCfgDefn is to make it easier for applications to determine all the possible types of managed object the administration framework supports.

The TopCfgDefn is not generated automatically from XML. Instead it is located in the org.opends.server.admin package together with the base client-side and server-side interfaces (ConfigurationClient and Configuration respectively).

git-svn-id: https://svn.forgerock.org/opendj/trunk@3082 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

15 Sep, 2007

1 commit

  • 1a7e885e   Performance improvements to server-side admin framework. ... Browse Dir » 
    The strongly typed server-side APIs now retrieve and cache their property values during construction so that subsequent calls to property getters no longer have to repeatedly access the underlying ServerManagedObject. This avoids having to repeatedly perform hash-table look-ups in the ServerManagedObject and, in the case of single-valued properties, temporary construction of iterators.

I have also modified the ServerManagedObject#getPropertyValues() method to return an UnmodifiableSortedSet rather than a defensive copy and updated the javadoc in the generated server-side getters to reflect that the returned set is unmodifiable.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3078 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

14 Sep, 2007

4 commits

  • e77570a5   Add support for the groupOfEntries group type as defined in ... Browse Dir » 
    draft-findlay-ldap-groupofentries.  Entries with the groupOfEntries object
class should be treated in a manner that is virtually identical to entries with
the groupOfNames object class (technically, groupOfNames does not allow
zero-member groups, but the OpenDS implementation does allow this).

OpenDS Issue Number:  2277


git-svn-id: https://svn.forgerock.org/opendj/trunk@3076 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • 8a2aa485   Fixed error in reversion part of script ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3063 41b1ffd8-f28e-4786-ab96-9950f0a78031
    kenneth_suter
     
  • be7ddd41   Avoid managed object definition initialization dependency problems. Using featur… ... Browse Dir » 
    …es like inherited default values and aggregation properties it is quite straightforward to encounter initialization dependency problems. For example: the global configuration will contain an aggregation property which references the default password policy. This aggregation definition is defined using a managed object path which, when decoded, contains a reference to the root configuration and its "password-policy" relation. This is what happens during initialization of the root configuration:

1) load the root configuration definition class and start constructing and registering its relation definitions

2) initialize the global configuration relation definition. This forces the JVM to load the global configuration definition

3) the global configuration contains an aggregation property definition which references a default password policy. Password policies are contained in the "password-policy" relation of the root configuration. Since the aggregation property definition references the password policy via a managed object path, decoding the path forces the root configuration definition to be loaded and its "password-policy" relation definition to be retrieved

4) the lookup of the "password-policy" relation definition fails because the root configuration has not finished initializing and the relation has not been constructed yet.

The fix is to "delay" decoding of inter-component references such as these until all the associated classes are loaded and initialized. To that end, property definitions and their default behaviors now have a new method called "initialize()". In addition, each property definition and default behavior has been modified so that any managed object paths and property definitions that they depend upon are not decoded during construction. This is now performed by the initialize() method.

The admin framework class loader provider has been modified so that it now performs this two-phase initialization:

1) load and instantiate each managed object definition class, forcing all property definitions and relation definitions to be constructed and registered

2) initialize each managed object definition instance: the instance invokes initialize() on each of its property definitions and default behaviors. This will force all inter-component references to be decoded and validated.

A positive side-effect of this change is that any inter-component references which have not been specified properly in their XML definition will be flagged during server start-up, rather than on-demand.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3061 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • da262bed   Modify the aggregation definition property stylesheet to generate two server-sid… ... Browse Dir » 
    …e getter methods for each aggregation property. The first is a "default" getter of the form:

    String getXXX()
    SortedSet<String> getXXX()

Where XXX is the name of the property. This getter follows the same pattern as all other property getters. In this case it returns a String (or set of Strings) containing the common name(s) of the referenced component(s).

The second server-side getter is of the form:

    DN getXXXDN()
    SortedSet<DN> getXXXDNs()

Where again XXX is the name of the property. This getter returns the distinguished name(s) associated with the referenced component(s). It is useful on the server-side where component implementations need to retrieve referenced implementations from a DirectoryServer table based on their DN.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3060 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift