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?
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.
Thanks,
Erling
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
On 11/10/08, Rich Megginson rmeggins@redhat.com wrote: [...]
Could be. The bind user used by windows sync must have read and write rights to the AD subtree.
If I have for instance,
ou=Linux,ou=delegation,dc=foo, dc=bar, dc=baz in AD
and in the synchronization agreement the "Windows subtree" value is: ou=Linux,ou=delegation,dc=foo, dc=bar, dc=baz
I have tried to limit the write-permissions for the binding-user to only ou=Linux, but that causes synchronization to fail.
In which parts of the AD-tree does the binding-user need write access? Does it need write access in dc=foo and all siblings?
Thanks again,
Erling
Erling Ringen Elvsrud wrote:
On 11/10/08, Rich Megginson rmeggins@redhat.com wrote: [...]
Could be. The bind user used by windows sync must have read and write rights to the AD subtree.
If I have for instance,
ou=Linux,ou=delegation,dc=foo, dc=bar, dc=baz in AD
and in the synchronization agreement the "Windows subtree" value is: ou=Linux,ou=delegation,dc=foo, dc=bar, dc=baz
I have tried to limit the write-permissions for the binding-user to only ou=Linux, but that causes synchronization to fail.
In which parts of the AD-tree does the binding-user need write access? Does it need write access in dc=foo and all siblings?
For read access - see http://msdn.microsoft.com/en-us/library/ms677626(VS.85).aspx and http://support.microsoft.com/kb/891995 for more information about how the DirSync Search works. For write access - should only need access to ou=Linux
Thanks again,
Erling
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org