Mike Mercier wrote: > 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? > Should not cause any side effects. But if you add/delete/move masters, you will have to update those URL fields manually. > 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 >>> >>> >>> > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090521/6540180e/attachment.bin
