|
Richard, thank you for your
response! …hopefully whatever
configuration mistake I made to cause a NULL bind DN will soon come to light… > Dear List Members, > > Release:
*fedora-ds-1.0.2-1.RHEL3.i386.opt.rpm* > > A typical replication
error log entry now follows (seen repeatedly at > both fedora DS
servers): > > [28/Jun/2006:18:29:21
+0100] NSMMReplicationPlugin - agmt="cn=EDS from > server 2"
(ukstatlap:636): Unable to acquire replica: permission > denied. The *bind dn
""* does not have permission to supply > replication updates to
the replica. Will retry later. > > Believe me, I have been
investigating this one for 2 or 3 days now > (having just switched
from OpenLDAP, since multiple master replication > is required) before
sending this submission, just in case I missed a > configuration item or
work-around, but unfortunately no luck (so far). > > The only reference I
can find for SSL Client Authentication based > Multiple Master
replication (2 Linux RHEL 3 servers being used) that > supplies empty DNs, is
the Windows specific entry (whose work-around I > tried anyway, but
without success)_ > > Unable to acquire
replica: permission denied. The bind dn "" does not > have permission to
supply replication updates to the replica. Will > retry later. > To workaround the
problem, after you modify and save the replication > schedule of an
agreement, refresh the console, reconfigure the > connection settings (to
SSL client authentication) for the agreement, > and save your changes. > > http://www.redhat.com/docs/manuals/dir-server/release-notes/ds611relno > tes.html > > The mutual _Current
Supplier DNs_ are indeed set (cn=Replication >
Manager,cn=replication,cn=config) and the corresponding directory > entries do exist. > > The respective server
certificates and CA certificates are installed, > with Subject DN entries
loaded. > What are the SubjectDNs in
the server certificates? CN=<SERVERNAME>,OU=EDS,O=teligent,DC=co,C= …where “<SERVERNAME>”
is the respective server name of the replicating servers e.g. “nema2”
rather than a full domain name. The following will hopefully
also be relevant: 1)
The tree being replicated is “OU=EDS,O= 2)
certutil was used to generate the server and
CA certificates. Surprisingly (to me at least) the CA certificate was then
listed in the “Server Certs” panel on the Directory Server “Manage
Certificates” panel. 3)
I loaded the ascii version of the “other”
server’s CA Certificate directly into the “CA Certs” panel. 4)
All CA certificates have both the accept and
make connection trusts ticked. > I do _not_ have Legacy
Consumer enabled. > You don't need it. > > CertMapping is also
defined (though with a NULL DN being supplied, I > guess that will not be
kicking in just yet, though there are entries > for the exact subject
DN anyway.) > You might want to post your
certmap.conf and see here - http://directory.fedora.redhat.com/wiki/Howto:CertMapping …I must admit that
since the Bind DN was NULL I had not realized that certmap’ping would
actually take affect. certmap
nema ou=EDS,o=teligent,dc=co,c= nema:FilterComps cn nema:verifycert off certmap
default default …indeed one server
still runs with the default certmap configuration to see if it made any
difference, but both servers receive a NULL bind DN “”. > When using simple
authentication, with or without SSL, all is well > (although replication
did require both servers to Initialize the > Consumer, I thought
that only one was required e.g. ID 1 initializing > ID 2, but ID 2 then
needed to initialize ID 1 before successful 2-way > replication was
achieved). > That's odd. You should only
need to initialize once one way. …indeed, but I guess
that it can not do any harm, as the secondary server will not actually need to
supply any further updates back to the primary server and it does at least make
the mutual replication work for me – until the certificates took their
toll… Regards and thanks again, Kevin |
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
