Erling Ringen Elvsrud wrote: > When right clicking on the win-sync agreement and selecting initiate > full re-synchronization I get these errors in > /var/log/dirsrv/slapd-xyz/errors: > > "[10/Nov/2008:08:05:52 +0100] NSMMReplicationPlugin - changelog > program - libdb: txn_checkpoint: failed to flush the buffer cache No > such file or directory > > [10/Nov/2008:08:05:53 +0100] NSMMReplicationPlugin - changelog program > - libdb: 26fdcb82-912411dd-8d71b7a1-43daa7e9_48e5d6030000ffff0000.db4: > unable to flush: No such file or directory > > [10/Nov/2008:08:05:53 +0100] NSMMReplicationPlugin - changelog program > - libdb: txn_checkpoint: failed to flush the buffer cache No such file > or directory > > [10/Nov/2008:08:05:53 +0100] NSMMReplicationPlugin - changelog program > - libdb: 26fdcb82-912411dd-8d71b7a1-43daa7e9_48e5d6030000ffff0000.db4: > unable to flush: No such file or directory > > [10/Nov/2008:08:05:53 +0100] NSMMReplicationPlugin - changelog program > - libdb: txn_checkpoint: failed to flush the buffer cache No such file > or directory" > > A dialog box also appears with the following text: > > "An error occured during the consumer initialization > The error received by the replica is '12 Total update aborted: > Replication agreement for agmnt=xyz can not be updated while the > replica is disabled > (if the suffix is disabled you must enable it then restart the server > for replication to take place).'. > To check the initialization status, go to the 'status' tab and click > on 'Replication status' in the left pane. The status of the > initialization appears in the right pane." > > Before the problems occured we temporarily disabled "domain admins" > rights for the user WIndows Sync uses to bind to AD. While the > binding-user only had read acess for the suffix we wanted to sync with > we started a full re-sync (with the errors above). The dirsrv was also > restarted. > We have re-enabled "domain admins" rights for the binding-user but the > errors still appear. The directory server is searchable and seems to > work exept for syncing. > > Could it be that the temporary changes in rights for the binding-user > could have caused this? > Could be. The bind user used by windows sync must have read and write rights to the AD subtree. But are you sure you have correctly configured Fedora DS to be a replication master with a changelog? > Also, is it absolutely needed to have domain admin rights for the > binding-user RHDS uses to connect to AD? We do not want to write any > changes back to AD and those attributes synced with Windows sync will > not be changed anyway. > I don't know if the windows sync code can handle that gracefully - it will definitely attempt to write to AD and there is no way to turn that off. I don't know if it will handle gracefully the error of not being able to write. > Thanks, > > Erling > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
