13 Nov, 2007

4 commits

  • Make the setup command line to support properties files.
    
    Make the uninstall command line to support properties files.
    
    Support properties files in dsreplication for all the subcommand arguments.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3447 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@3445 41b1ffd8-f28e-4786-ab96-9950f0a78031
    pgamba
     
  • log file name modification needs an administrative action
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3444 41b1ffd8-f28e-4786-ab96-9950f0a78031
    lutoff
     
  • Fix a bug in the uninstall and dsreplication.  When the user connected to the servers using LDAP, a null trust manager was used to load the topology (so all certificates were accepted).  The code has been fixed to prompt the user to accept non trusted certificates.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3443 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

12 Nov, 2007

2 commits

  • …ttributes.  It is up to the tools using this attribute to add it.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3436 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • …of menus and in the order that questions to connect to the servers.
    Update the upgrade to use the same menus as the other command-lines.
    Do some minor changes in the uninstall command-line in order to be more consistent with dsconfig in the order where the connection parameters are provided.
    Fix a bug in ApplicationTrustManager related to the accepted certificates when there is a mismatch between the certificate and the host name.
    Do some refactorization of the code and remove the CliApplicationHelper class so that we use ConsoleApplication everywhere.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3435 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

09 Nov, 2007

6 commits


08 Nov, 2007

5 commits

  • in schema backend files and is not returned when searching.
    
    This code fixes the problem and also generalize the ability to store
    user attributes in the schema backend.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3427 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     
  • The problem is that there is a timeout when reading the monitoring informations 
    on the server and the code did not handle this properly.
    
    I have made the method Utils.getMessage to handle properly the case when a Topol
    ogyCacheException has not a Throwable cause.  In addition to that the method ret
    urns a specific message when a timeout occurs.  Finally the timeout thresold has
     been risen from 10 to 30 seconds to be able to read the topology.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3426 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • cate since this can break some clients.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3425 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • Fix the copy/paste errors in the description of the destination server arguments for the dsreplication initialize sub-command.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3424 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • …up and status command-lines in the formatting and in the format used to present certificates to the user.
    
    Fix some bugs in the way the ADS was updated when an instance is uninstalled.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3423 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

07 Nov, 2007

5 commits


06 Nov, 2007

1 commit

  • The attributes :
     ds-cfg-max-receive-queue,
     ds-cfg-max-receive-delay,
     ds-cfg-max-send-queue,
     ds-cfg-max-send-delay
     
    were left from some prototyping I did a while ago and not usefull
    for now.
    
    I've therefore removed them from the configuration of the
    Replication Domain.
    
      
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3415 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     

05 Nov, 2007

6 commits


02 Nov, 2007

5 commits


01 Nov, 2007

1 commit


31 Oct, 2007

1 commit

  • … attributes with options and subtypes correctly when they are being indexed. 
    With this fix:
    - All values of an indexed attribute type will be indexed correctly on modifies, adds, and deletes. 
    - Updates to subordinate types will now update the superior type if its indexed. 
    - Adding and deleting superior attribute types that are not allowed by any object classes (ie. name) will be correctly handled
    - Deleting all values from an attribute with no options will no longer delete the values from the same attribute but with options.
     
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3395 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     

30 Oct, 2007

1 commit

  • 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
     

29 Oct, 2007

1 commit


26 Oct, 2007

1 commit


25 Oct, 2007

1 commit