[389-users] [fedora-directory-users] NSMMReplicationPlugin messages in errors log

Thu May 21 15:06:24 UTC 2009

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://listman.redhat.com/archives/fedora-directory-users/attachments/20090521/6540180e/attachment.bin>