At 02:48 PM 5/24/2006, Quanah Gibson-Mount wrote:
--On Wednesday, May 24, 2006 2:04 PM -0700 Jed Donnelley
<[EMAIL PROTECTED]> wrote:
Hello Openldap,
I currently have an openldap configuration with a master server running
opendlap 2.2.29 and slaves running 2.2.23, 2.2.24, 2.2.28, and
2.2.29 (5 replicas total
on systems under various administrative controls).
Getting the following error:
May 24 13:21:42 sbuild3 slapd[8127]: slap_global_control:
unrecognized control: 1.3.6.1.4.1.4203.1.9.1.1
Did you load the syncprov overlay, as is required in 2.3?
Thanks. That was the key to my problem. Once I started down that
path I ran into a number
of problems that I eventually found others had run into. E.g. when
doing the make config
for openldap23-server it was important not only to turn on SYNPROV,
but also to turn
<off> SHELL. If SHELL is left on (the default) then threading is
turned off resulting in:
/libexec/ld-elf.so.1: /usr/local/lib/libldap_r-2.3.so.2: Undefined
symbol "pthread_getconcurrency"
I'll note you probably want to be running 2.3.23, there were a
number of syncrepl related bug fixes since 2.3.21 was released.
I also made the above update per your suggestion. That update ended
up updating much of
the world (bdb, perl, x11, ...), but other than that and the issues
with SYNPROV it went
pretty smoothly. My configuration:
2.2.29 Master production ldap ----> 2.3.23 Slave | Master
sbuild3 -----> 2.2.30 Slave sbuild5
| \
existing replicated slaves
now seems to be working with syncprel (refresh-only) happening at both levels.
One thing concerns me a bit. When we first started using syncrepl
openldap was at 2.2.28.
Things worked - sort of. We had occasional hangs. We heard that the
upgrade to 2.3
was motivated partly to fix up problems with syncrepl. So 2.3 came
out and went through
various revisions and we're now up to 2.3.23. However, if you say
that "a number of
ryncrepl related bug fixes" were fixed in 2.2.23 since 2.2.21 was
released, doesn't that
suggest that syncrepl is still a bit unstable? Is this production
quality code?
I'm wondering if we shouldn't switch our production services back to
slurpd until syncrepl
is production ready? Switching back all our replicas would be a real
pain, so I'm willing
to try just upgrading the master and then even upgrading the replicas
one at a time if needed.
However, if we still have problems then I'm thinking that we might be
better off going
back to slurpd.
Does anybody else have any experience to share regarding the
production quality of
the sync-repl code?
--Jed http://www.nersc.gov/~jed/
