Howard Chu wrote:
No. If the Bind with updateDN was successful this error will never appear.
It certainly appears that binding with the updateDN was successful from the logs -- could it be because I am using the rootDN as the updateDN?
Tony Earnshaw wrote:
However, one would still need a chain directive in the last consumer, which I don't think I saw. It should then update the provider, not the "pivot" - unless the "pivot" were also configured to chain to the original provider.
But my consumer is supposed to be a read-only slave -- I don't want any updates coming from it, and anyway it won't be able to reach the master provider through our internal firewalls. I'm not even sure why I needed the updateref configuration directive, but it seemed to fix things. I'm going to mess with my configuration and see if I can narrow down the problems some more...
Incidentally, I should probably mention that this is debian etch's OpenLDAP 2.3.30 (but there is no possibility of changing this, unfortunately).
Nevertheless, this is getting away from my main issue, which is that of removing the posixAccount and shadowAccount objectClasses from the replicated user data (unless I am attempting to solve the wrong problem).
Cheers, --alex