Ken Marsh wrote:

Hello,

 

Thank you everyone for your patience. I was able to get 1.0.1-4 up and running with Admin working on ES5/64 bit by simply saying “No” to one of the questions about my 7.1 DS:

 

Fedora configuration directory server? [No]:

 

Saying “yes” to this question and entering my 7.1 DS data, causes the config of the 1.0.1-4 Admin server to fail.

 

The next question, I can answer No or Yes, so I used Yes.

 

Do you want to use another directory to store your data? [Yes]:

 

So now I have a working DS with Admin, I’d like to set up Multi-Master. Using my 7.1 DS as host 1, I tried:

 

/usr/local/src/mmr.pl --host1 server1.company.com --host2 server2.company.com --host1_id 1 --host2_id 2 --bindpw 'xxxx' --repmanpw 'xxxx' --create

 

adding to string.gdrs.com -> cn=changelog5,cn=config

adding to string.gdrs.com -> cn=repman,cn=config

adding to string.gdrs.com -> cn=replica,cn="dc=company,dc=com",cn=mapping tree,cn=config

adding to ansb16.gdrs.com -> cn=changelog5,cn=config

adding to ansb16.gdrs.com -> cn=repman,cn=config

adding to ansb16.gdrs.com -> cn=replica,cn="dc=company,dc=com",cn=mapping tree,cn=config

failed to add replica entry: No such object at /usr/local/src/mmr.pl line 313, <DATA> line 339.

Unless the script isn't reporting an operation between the error and the previous line, it is probably telling you that the entry cn="dc=company,dc=com",cn=mapping tree,cn=config doesn't exist.  Check your 7.1 server's dse.ldif file, it could be something like cn="dc=company, dc=com",cn=mapping tree,cn=config where the extra space is actually significant because it's within a value, not separating DN components.

 

I tailed the error logs of both files as directed. Neither logged anything through the failure.

 

I have some questions:

 

Am I setting the Repository Manager password, or using it? If so, what is it? I have all my notes on the 7.1 install and don’t recall that role being set up and passworded. Is it the same, or called something else?

I'm not familiar with the script but the replication manager entry is usually a normal person entry (with a userPassword) which gains a special role by its DN being specified in a replica configuration.  Replication agreements use this identity to bind to peer replicas and send special extended operations to initiate replication sessions.

 

Also, any clues as to the failure? I have (I think) PERL::ldap installed.

 

Besides that, how do I get one Admin to manage the other DS, given that I didn’t allow the script to try?

 

-Ken.