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.