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 at gmail.com> 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 at redhat.com> 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>: 1 >>> >> >> Looks 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 master >>> >>> Note: 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 at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >
