Hi Jordan,

See comments below...

On 01/26/2015 03:08 PM, Jordan, Phillip wrote:

First late me state that I have been tasked to fix and upgrade the directory due to recent issues.  I have vast experience in most other directories but not in 389 Directory space.  So I have a few questions that will help in getting the directory upgraded with the most sound configuration.  If someone can take the time to answer these brief questions it would be appreciated.

 

1.       Issues with replication – Groups and normal replication, the most active issue is that groups are not syncing but often even the regular replication fails.

Are you replicating between 389 servers, or are you replicating with Windows AD ?

 

I have read about issues with sync of groups and member\memberof attributes but this seems to be more with just replication of groups.  I looked in the error log and never found any errors but restarting the service fixes the issue but sometimes it requires a manual fix to get the member\memberof set on the affected servers.

The memberOf plugin should be working correctly on the latest version of 1.2.11, and up.  I'm not aware of any known issues.

 

This Example just shows a quick failure of basic replication: (this is a short example but has been minutes or have to restart the service to get replication working)

 

[XX/Jan/20XX:16:37:50 -0500] NSMMReplicationPlugin - agmt="cn=abc123" (abc123:389): Unable to receive the response for a startReplication extended operation to consumer (Can't contact LDAP server). Will retry later.

[XX/Jan/20XX:16:37:54 -0500] NSMMReplicationPlugin - agmt="cn=abc123" (abc123:389): Replication bind with SIMPLE auth resumed

This means that at 16:37:50 the server could not reach the remote replica at abc123:389.  <network issue or the remote server was not running> Then at 16:37:54 it was able to contact that remote replica, and resume replication.

 

2.       Issues with changelog size is too large

 

The current changelog is 1.1 gig and this seems very large considering the DB is only about 40 meg.  How can this be pruned to a decent size.

You need to use changelog trimming to keep the changelog size manageable:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/Managing_Replication-Configuring-Replication-cmd.html

 

3.       Cause of the DIRSRV stopping a lot recently after Yun OS update

 

I would assume this is due to a very outdated version and would expect that the upgrade should help with the stability.  I might add that the failures started recently after a OS Yum update.

So you did upgrade?

  I think it could be a compatibility issue and upgrading should aid in this.

What OS/version are you on?  What was the previous version of 389?

 

4.       Review configuration files that are manually done.  I have read and am good to export the directory before the upgrade but what other files would you backup?  IE DSE.LDIF?  Stop the service and backup the DB files? etc

You could export the database to LDIF (db2ldif), or run a backup (db2bak) - I would not recommend manually performing a "backup".  Are you just looking to backup the server before attempting am upgrade?  If so, checkout:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Populating_Directory_Databases-Backing_Up_and_Restoring_Data.html

5.        Issues with upgrading from 1.2.11.X to 1.3.3.5, gotchas or upgrade to 1.3 then patch to 1.3.3.5?

Again, what OS are you on.  1.3.3 might not run correctly on older OS's like Fedora 18, or even RHEL 6 due to dependency issues, etc.

6.       Other observations that users have experienced that may aid in a successful upgrade?

The server upgrade process (setup-ds.pl --update) should be sufficient depending on what version you are coming from.  Check out:
 https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Installation_Guide/Migration.html

In general you can find useful information from:

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/

Regards,
Mark

 

 

 

Phillip Jordan

Lead Engineer, Web Hosting

 

                      

555 W. Adams

Chicago, IL 60661

transunion.com

 

This email including, without limitation, the attachments, if any, accompanying this email, may contain information which is confidential or privileged and exempt from disclosure under applicable law. The information is for the use of the intended recipient. If you are not the intended recipient, be aware that any disclosure, copying, distribution, review or use of the contents of this email, and/or its attachments, is without authorization and is prohibited. If you have received this email in error, please notify us by reply email immediately and destroy all copies of this email and its attachments. 

 



--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users