At this risk of getting put in my place again by Howard for lack of
authoritative knowlege, I'll make the following comments.
Justin Crabtree wanted us to know:
I know it is not recommended, but this system is halfway between testing
and production and I haven't gotten around to setting up a seperate
account for replication. I just wanted to get replication working, then
worry about doing it the right way. Plus, we kind of got pushed into
implementing our LDAP server before we had time to test everything. I
have been chasing other more critical problems and using the rootdn was
the easy way to get something working. I know that using the rootdn for
replication is not recommended, but it shouldn't be causing the problem
I am currently experiencing, should it?
I'm tempted to say yes, but as I clearly stated earlier, I know not all
that there is to know about this. What I posted works for me (tm) and
you're doing something that the manuals/gurus say not to do and are
having problems. Give the suggested method a shot before you get too
deep into this. Then you have a known starting point.
Your perl script connects as the rootdn to the mater. So you have a
situation where the rootdn is the same on the master as all the slaves,
and you are using the rootdn to replicate out from the master to the
slaves, and you're using the rootdn to bind to the master in the script.
Correct?
Can you create a user entry in your directory (where is not important, I
usually put them in the root), give that entity write access in your
ACL's to any attribute that might otherwise be restricted, then have
your script bind as that user. See if the results change.
If the answer is yes, then I'd suspect something in your master
slapd.conf that shouldn't be there, but I'm not going to just guess,
others would spot things more quickly. I'd say post your slapd.conf
files for both master and slave and let people give it a good look over
(obfuscate any passwords).