[Date Prev][Date Next]
Re: Different versions play well?
I believe in general you can have mixed versions of openldap.
However, 2.1 is pretty old, so your milage may vary.
On 1/18/06, Steve Huston <email@example.com> wrote:
> I'll start by saying I searched the archives, and didn't find mention of this
> - nor did I find any documentation that warned against it. But I figured it
> best to ask here.
> We've got a single master and two slaves (one slave on our mail server for
> fast "local" lookups, and one on a beowulf cluster so it can be seen by the
> nodes on an internal network). All are running 2.1.29, master's OS is Fedora
> Core 2.
> I'm setting up a new mail server, and will be using Fedora Core 4 for the OS.
> I downloaded 2.1.29 and compiled it, but 'slapadd' segfaults instantly - an
> strace shows it looking in /etc/mtab, and then doing a 'munmap' just before it
> dies. I compared the libraries linked in to that with those on our current
> mail server (which is RedHat 8.0) and saw that the old server had no Kerberos
> libraries linked, so I removed the krb5-devel package and compiled again on
> the new system. Now it complains about the TLS configuration lines being
> "unknown directives" and still segfaults, so I guess I'll be putting krb5 back
> on there (sure enough, no SSL libraries are linked now).
> My question, has anyone run into this similar, and know of a solution? If
> not, then my big question is can I run different versions of OpenLDAP on the
> same network, in a master/slave configuration like this, and have them work
> okay? I don't know if anything has changed where it would be bad to, for
> example, run the latest OpenLDAP on the new server slaved to one running
> 2.1.29 as a master. Or maybe there's a specific version 'ceiling' where I
> could run up to a certain revision as a slave to that master without error,
> but if I go any newer it might cause problems (I'm not against staying a
> little behind in releases, if it's stable and the new versions don't add
> things that I need to operate here). In theory, I could upgrade the other
> servers to be the latest as well, but in practice that may be much more
> difficult than it sounds.
> Steve Huston - W2SRH - Unix Sysadmin, Dept. of Astrophysical Sciences
> Princeton University | ICBM Address: 40.346525 -74.651285
> 126 Peyton Hall |"On my ship, the Rocinante, wheeling through
> Princeton, NJ 08544 | the galaxies; headed for the heart of Cygnus,
> (609) 258-7375 | headlong into mystery." -Rush, 'Cygnus X-1'