Mike Mercier wrote:
Should not cause any side effects. But if you add/delete/move masters, you will have to update those URL fields manually.Hi, I seem to have resolved the problem by adding a URL on the replica setting to "Enter a new URL" field pointing to the other server. On Server-1: ldap://server-2.internaldomain:389/dn=pki On Server-2 ldap://server-1.internaldomain:389/dn=pki I am no longer seeing the error messages in /var/log/dirsrv/slapd-TEST/errors on either end of the replication agreement. Does anyone know if this will this cause any other side effects?
Thanks, Mike On Thu, May 21, 2009 at 8:13 AM, Mike Mercier <mmercier@xxxxxxxxx> wrote:Hi, Is there some way to resolve the timing issue/verify it is fully setup? I restarted dirsrv, and removed, re-added, and reinitialized (from server-1) the replication agreement on server-2 and here is what I see in the logs: Server-1: [21/May/2009:07:52:49 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=PKI-Replication-Agreement" (server-2:389)". [21/May/2009:07:52:52 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=PKI-Replication-Agreement" (server-2:389)". Sent 53 entries. [21/May/2009:07:57:03 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=pki: 1 Server-2: [21/May/2009:07:52:49 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [21/May/2009:07:52:52 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=pki: 1 [21/May/2009:07:52:52 -0400] - import pki: Workers finished; cleaning up... [21/May/2009:07:52:52 -0400] - import pki: Workers cleaned up. [21/May/2009:07:52:52 -0400] - import pki: Indexing complete. Post-processing... [21/May/2009:07:52:52 -0400] - import pki: Flushing caches... [21/May/2009:07:52:52 -0400] - import pki: Closing files... [21/May/2009:07:52:52 -0400] - import pki: Import complete. Processed 53 entries in 3 seconds. (17.67 entries/sec) [21/May/2009:07:52:52 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=pki is coming online; enabling replication [21/May/2009:07:57:03 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=pki: 1 Can the repl_set_mtn_referrals message be ignored? Thanks, Mike On Wed, May 20, 2009 at 4:25 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:Mike Mercier wrote:Hello, I am getting the following error on both ends of a replication agreement. The replication agreement is for the fedora dogtag CA application. Note: I had to manually do a few things to get it to work, the automated cloning was failing to setup the replication agreement. NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=<dogtag dc>: 1Looks like some sort of timing thing - like the server has not been fully started yet or fully set up yet before it receives the replication request from the other masterNote: Dogtag and fedora-ds are running on the same systems: Server-1 - fedora-ds and dogtag Server-2 - fedora-ds and dogtag clone Replication agreements between the systems for: o=NetscapeRoot userRoot dogtag dc The error *only* appears for the dogtag dc. In my dse.ldif, I do notice that there is only one nsslapd-referral for the dogtag dc (for server-1 to server-2) Server-1 dn: cn="dc=<dogtag dc>",cn=mapping tree, cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: dc=<dogtag dc> cn: "dc=<dogtag dc>" nsslapd-backend: pki nsslapd-state: Backend creatorsName: cn=directory manager modifiersName: cn=server,cn=plugins,cn=config createTimestamp: 20090520160944Z modifyTimestamp: 20090520162351Z nsslapd-referral: ldap://server-2.internaldomain:389/dc%3D<dogtag dc> numSubordinates: 1 Server-2 dn: cn="dc=<dogtag dc>",cn=mapping tree, cn=config objectClass: top objectClass: extensibleObject objectClass: nsMappingTree cn: dc=<dogtag dc> cn: "dc=<dogtag dc>" nsslapd-backend: pki nsslapd-state: Backend creatorsName: cn=directory manager modifiersName: cn=server,cn=plugins,cn=config createTimestamp: 20090520165422Z modifyTimestamp: 20090520180434Z numSubordinates: 1 Searching google doesn't really point to an explanation (or solution) to the error messages. Is it safe to do an ldapmodify to add the entry on Server-2?Yes, although the replication code is supposed to set that automatically, and may overwrite it.Thanks, Mike -- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
