On Thu, Dec 22, 2011 at 10:12, Simo Sorce <s...@redhat.com> wrote:
> On Wed, 2011-12-21 at 17:39 -0500, Dan Scott wrote:
>> This is possible... oops. I tried a few times to add another replica
>> (fileserver3) which failed as I mentioned above. The replication
>> process got most of the way through and showed up on one of the
>> servers, but not the other, so I removed the replica. It's possible
>> that I force removed fileserver2 by mistake.
> In this case the only way out is to reinstall fileserver2.
Which would be fine, if I were confident of being able to create a new
replica. However, my attempts to create new replicas are failing
miserably as explained previously. I'm extremely reluctant to wipe
fileserver2 unless I can get another replica of fileserver1 up and
If I can get another replica up and running I would be fine. However, the
slapi_ldap_bind - Error: could not perform interactive bind for id 
mech [GSSAPI]: error -1 (Can't contact LDAP server)
error is causing problems during replication.
When a replica is initialised, I guess that it replicates only from
the master server? So I need to figure out the replication problem
first, then I can re-install fileserver2
>> > Can you look into cn=config and see if you have references toi
>> > fileserver2 ?
>> > Maybe it is just a bug in displaying actually active replicas.
>> I'm using 'jxplore' LDAP browser (my command line LDAP skills aren't
>> very good, I can't seem to get the kerberos authentication working
>> properly. In any case, I'm having trouble authenticating because of
>> the problems mentioned above) and did an unauthenticated search for
>> cn=config on fileserver1, no results.
> cn=config is a separate tree within DS it is not a subtree of the data
> partition, you need to use that as the basedn in jxplore.
OK, thanks. cn=config only contains a SNMP entry, no references to the
Freeipa-users mailing list