Re: new admin guide draft

[Quanah Gibson-Mount <quanah@stanford.edu>]

--On Tuesday, September 16, 2003 7:49 AM -0700 "Kurt D. Zeilenga" 
<Kurt@OpenLDAP.org> wrote:

> http://www.openldap.org/devel/admin/ has been updated.
> Most significantly, the update includes new chapters
> on Sync Replication and Proxy Cache engines.  These
> were authored by Jong Choi and Apurva Kumar, respectively.

I've been working over the syncrepl portion of the guide.  I may have some 
organization pieces I'd change, and perhaps a detail on how to convert to 
syncrepl when going from 2.1 to 2.2.

So far, from using the document, I've failed to get syncrepl to work.
My procedure so far has been:

dump my 2.1 database via slapcat -l dbfile
On the provider, do a slapadd -w -l dbfile
do a slapcat -m -l dbfile
This shows the created ldapsync objectclass:

dn: cn=ldapsync,dc=stanford,dc=edu
objectClass: top
objectClass: subentry
objectClass: syncProviderSubentry
structuralObjectClass: subentry
cn: ldapsync
contextCSN: 2003091618:18:30Z#0x008a#0#0000
subtreeSpecification: {}

So far, so good.

I now start the provider.

I find that "ldapsearch -h ldap-dev0 cn=ldapsync" returns nothing!  Since 
it is a part of the database, shouldn't I be able to see this?

Then, I have to convert this DB to a replica DB.  So, I:

sed s/ProviderSubentry/ConsumerSubentry/ dbfile > db_file.new

The above bit is a guess on my part, since the documentation doesn't 
actually specify what the consumer's objectclass is.

I then slapadd -l dbfile.new on my replica.

In my replica's slapd.conf I have:

syncrepl	id=ldap-dev2
		provider=ldap://ldap-dev0.stanford.edu:389
		updatedn="cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu"
		binddn="cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu"
		bindmethod=sasl
		saslmech=gssapi
		searchbase="dc=stanford,dc=edu"
		authcId=ldap/ldap2.stanford.edu@stanford.edu
		realm=stanford.edu
		schemachecking=on
		type=refreshAndPersist

After the load is completed, I start up the replica.

It creates a persistent connection to the provider (causing ITS#2724), and 
tries to update.  Its searches fail, with various errors.  The most 
pertinent one I think is '(entryUUID) index_param failed (18)'.  I assume 
this means that we now need to index entryUUID (eq?), which is also not 
documented.

When doing a search against this system, I also find that ldapsync is not 
present, i.e., ldapsearch -h ldap-dev2 cn=ldapsync doesn't return anything.

The replicator DN has full write into all of the replica systems.  The 
ldap-dev2 DN has full read into the provider.

There is a some use of the words "slave" and "replica" interchangeably that 
may wish to be made all one or the other.


I also find that slapd on the slave replica consistently uses 25% of the 
CPU, and grows uncontrollably (more ITS's coming up).

Has anyone gotten syncrepl to work?

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html