29 Aug, 2007

1 commit

  • alternate repositories.  The current implementation is still the default
    server-wide mechanism using the config/schematokens.dat file, but it will be
    possible to use this API to create alternate implementations (e.g., one for the
    JE backend that stores the tokens in the database).
    
    This provides the first part of the fix for issue #2158.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2838 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

28 Aug, 2007

8 commits

  • 1. replace getNewServerAdsProperties(getUserData()) with ServerDescriptor to:
    a. align with new ReplicationCliMain
    b. allow implementing publicKeyCertificate entry independent of CLI/GUI.
    
    2. inline getRemoteServerProperties (single caller)
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2835 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • Instead of closing the environment, deleting the files, and re-opening the
    environment, we are keeping the environment open and just truncating the
    databases.  This dramatically reduces the amount of memory required to run the
    unit tests, apparently as a result of a memory leak in the Berkeley DB JE when
    the environment is repeatedly opened and closed.
    
    Note that the latest release of Berkeley DB JE (3.2.44, which we aren't yet
    using) claims to have a fix for a similar problem (JE issue #15444 as described
    in http://forums.oracle.com/forums/thread.jspa?messageID=1782659) but testing
    with that JE version didn't appear to resolve the problem so it is likely that
    the issue still exists.  However, while it was causing a significant problem in
    our test cases, it is unlikely to cause problems in production environments
    because the JE environment should not be repeatedly opened and closed in the
    same JVM instance.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2834 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • Clean up duplicate code in Installer.updateADS in preparation for adding instance public-key certificate to properties. External behavior (e.g., registeredNewServerOnRemote) should be unchanged.
    
    Ran precommit tests and various setup hand tests.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2832 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@2830 41b1ffd8-f28e-4786-ab96-9950f0a78031
    coulbeck
     
  • There is a new backend representing the certificate trust store, which allows the setup code to query and populate the trust store over protocol. However, we are using blind trust until that piece of the setup code is ready.
    
    The encryption settings are currently global to the server instance in a new crypto manager config entry. Authentication will always be performed so the main setting is whether to use encryption or not. In the future (post 1.0) we will need to allow encryption to be configured on or off depending on which replication server we are connecting to but we need some discussion on the best way to specify that in configuration.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2829 41b1ffd8-f28e-4786-ab96-9950f0a78031
    coulbeck
     
  • Update the function that created the Message to be displayed to return a String instead of a Message object.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2827 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@2826 41b1ffd8-f28e-4786-ab96-9950f0a78031
    lutoff
     
  • send e-mail messages whenever an account status notification is generated.  The
    message can be sent to the end user impacted by the notification (based on an
    attribute in the user's entry) and/or a fixed set of recipients.
    
    The messages that will be generated are created from template files, which can
    include tokens that will be replced with things like:
    
    - The name of the notification type
    - The notification message
    - The DN of the target user's entry
    - Attribute values from the target user's entry
    - Values of account status notification properties, which may vary based on the
      type of notification
    
    This change also includes a fix for a problem that could allow password
    expiration warning messages to be sent to a client even if the bind was not
    successful.
    
    
    OpenDS Issue Number:  581
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2824 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

27 Aug, 2007

9 commits

  • - Implemented as virtual attributes
       - They are enabled by default
       - numSubordinates and hasSubordinates methods added to the backend API and implemented for all existing backends
       - JE implementation uses the id2children index to keep count of the number of subordinates for each entry.
       - The behavior of exceeding the index-entry-limit (ALL-IDs) has changed to store a 8 byte entry ID set count with the most significant bit 
    set to 1 instead of a 0 byte array to signify the index-entry-limit has been exceeded. The previous format is still compatible but all requests 
    for numSubordinates will return undefined (-1).
       - The DBTest tool is also included in this fix. This can be used to list root containers, entry containers, database containers, index 
    status, as well as dumping a database with or without decoding the data. 
    
    Fix for issues 43 and 72
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2820 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@2819 41b1ffd8-f28e-4786-ab96-9950f0a78031
    coulbeck
     
  • Test case:
    
    1. Create initial instance as stand-alone (no replication or ADS);
    2. Create second instance as part of replication toplogy, specifying instance created in step 1.
    
    Configuration of instance 2 hangs in registering server with ADS.
    
    Works after this change; however, now get on OS X:
    
    $ ./setup
    Launching graphical setup...
    2007-08-27 12:11:07.058 java[3932] CFLog (0): CFMessagePort: bootstrap_register(): failed 1103 (0x44f), port = 0x12503, name = 'java.ServiceProvider'
    See /usr/include/servers/bootstrap_defs.h for the error codes.
    2007-08-27 12:11:07.061 java[3932] CFLog (99): CFMessagePortCreateLocal(): failed to name Mach port (java.ServiceProvider)
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2818 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • rename "ds-cfg-ads-certificate" to "ds-cfg-public-key-certificate"
    use "ds-cfg-public-key-certificate;binary"
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2817 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • …t directly from Java core methods and replaced them with comments derived in most part from the parent methods
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2815 41b1ffd8-f28e-4786-ab96-9950f0a78031
    kenneth_suter
     
  • Cleanup around requesting instance public-key certificate from truststore backend.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2814 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • When debugging 2097 I've noticed that during a replication total update,
    if the updated server fails, the publisher thread on the other server hangs.
    
    The hang happens because normally the publisher thread never tries to reconnect
    after a protocol session failure but waits for the receiver threads to do the job but
    here the publishing activity is done in a receiver thread that holding the session lock
    and therefore prevent the other thread from doing there job.
    
    The solution is to move this work outside of the lock.
    
    I've tested this manually as it is difficult to automate.
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2811 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     
  • The updates done to the task entry during an initialize task was 
    sometime causing ConcurrentModificationException because they 
    were done in an internal thread that can be in concurrence
    with the operation threads.
    
    The fix is to use the taskScheduler lock when updating the task entry
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2810 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     
  • Update the code so that the log messages we received are written to the installer log file and also add some code to supress the output of certain operations in the progress dialog of the installer (in the case of the creation of the top entry).
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2809 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

26 Aug, 2007

10 commits


25 Aug, 2007

2 commits

  • allow for backend-compact-encoding property, enabled by default.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2796 41b1ffd8-f28e-4786-ab96-9950f0a78031
    abobrov
     
  • This is a followup to commit r2774.
    
    Secure replication depends on ADS containing at least the instance-to-be-initialized's instance key public-key certificate in the ADS-based truststore because the existing replication domain server requires it to "trust" the new server. (The new server trusts the domain server by some future ADSContext code that will fetch the domain host's public-key certificate and write it into the new server's truststore backend - all via LDAP.)
    
    Subsequent to commit r2774, we discovered that configuring replication results in the replication server opening its server socket and configuring it for TLS. The TLS configuration requires the local truststore to be initialized with the local instance key and the instance key of any to-be-replicated servers must be added. Hence, the Installer's ADS configuration step must be run before its replication configuration step.
    
    In the current implementation of the ADS configuration step, ADS replication is configured and initialized (distinct from the suffixes specified by the user). These changes 1) move the ADS replication configuration and initialization from the ADS configuration step, and merge them into the code that handles configuring and initializing replication of the user specified suffixes (Installer.java); and 2) move the invocation of the ADS configuration ahead of the replication configuration (OfflineInstaller,WebStartInstaller.java).
    
    M      src/quicksetup/org/opends/quicksetup/installer/offline/OfflineInstaller.java
    M      src/quicksetup/org/opends/quicksetup/installer/webstart/WebStartInstaller.java
    M      src/quicksetup/org/opends/quicksetup/installer/Installer.java
    
    Tests:
    
    In addition to the precommit target, I've run the following setup scenarios using the OfflineInstaller:
    
    1) Setup standalone server with data; setup new server as part of existing replication. Then the new server setup configures replication, ADS, and initializes suffixes on both instances.
    
    2) Setup initial replicated server with data; setup new server as part of existing replication.
    
    I'm not sure how to test the WebStartInstaller, but the code and changes are identical to the OfflineInstaller, so perhaps it is ok.
    
    ---
    Thanks to Josu for reviewing.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2795 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     

24 Aug, 2007

9 commits

  • 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 via kill
    but no PID file is present, the stop script will generate an error instead of
    trying to invoke the stop task (which is guaranteed to fail since the attempt
    will be made anonymously, and this will give a confusing error message).
    
    OpenDS Issue Number:  526
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2788 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2787 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2786 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     
  • Each instance has an associated public-private key-pair called the "instance key". The collection of public-key certificates from all instances forms an ADS-domain truststore. Secure replication uses this truststore in its TLS setup.
    
    The instance key is maintained by the local instance using a new "truststore" backend type that manages a local keystore file. The backend is induced to generate and self-sign a key when an entry with a special dn is written to it.  Once the truststore has been so initialized, the public-key certificate can be retrieved with an LDAP search operation.
    
    This change adds a method to the ADSContext to retrieve the instance key public-key certificate from the instance to which the context is bound, and set a field in the context with the cert. The method detects if it needs to induce the backend to produce the key. A subsequent change will publish the key in ADS.  For now (until Andy commits the truststore backend code), the attempt to retrieve the key is guarded by a check for the ads-truststore backend's presence.
    
    There is also some minor cleanup of existing code, and some additional code related to upcoming CryptoManager related ADS setup.
    
    M      src/ads/org/opends/admin/ads/ADSContext.java
    
    Tests:
    
    In addition to the precommit target, I've run the following setup scenarios using the OfflineInstaller:
    
    1) Setup standalone server with data; setup new server as part of existing replication. Then the new server setup configures replication, ADS, and initializes suffixes on both instances.
    
    2) Setup initial replicated server with data; setup new server as part of existing replication.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2785 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     
  • … default, fair ordering will be used.
    
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2783 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     
  • can be provided as a string, contained in a file, or piped in via standard
    input, and the result can be sent to standard output or written to a file.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2781 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2779 41b1ffd8-f28e-4786-ab96-9950f0a78031
    abobrov
     
  • 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2776 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • Secure replication depends on ADS containing at least the instance-to-be-initialized's instance key public-key certificate in the ADS-based truststore because the existing replication domain server requires it to "trust" the new server. (The new server trusts the domain server by some future ADSContext code that will fetch the domain host's public-key certificate and write it into the new server's truststore backend - all via LDAP.)
    
    Hence, this change reverses the invocation order of Installer.initializeSuffixes and Installer.updateADS so that the latter is now run first (but still subsequent to Installer.configureReplication).  Note that Installer.updateADS does require Installer.configureReplication to have been run, since it configures replication for and initializes "cn=admin data".
    
    M      src/quicksetup/org/opends/quicksetup/installer/offline/OfflineInstaller.java
    M      src/quicksetup/org/opends/quicksetup/installer/webstart/WebStartInstaller.java
    
    Tests:
    
    In addition to the precommit target, I've run the following setup scenarios using the OfflineInstaller:
    
    1) Setup standalone server with data; setup new server as part of existing replication. Then the new server setup configures replication, ADS, and initializes suffixes on both instances.
    
    2) Setup initial replicated server with data; setup new server as part of existing replication.
    
    I'm not sure how to test the WebStartInstaller, but the code and changes are identical to the OfflineInstaller, so perhaps it is ok.
    
    --
    Thanks to Josu for the review.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2774 41b1ffd8-f28e-4786-ab96-9950f0a78031
    david_page
     

23 Aug, 2007

1 commit