On Thursday 16 April 2009 14:18:13 Adrien Futschik wrote:
Le jeudi 16 avril 2009 14:04:44, Michael Ströder a écrit :
Adrien Futschik wrote:
I am aware I should migrate, but for the moment, the only solution I have would be to migrate to OpenLDAP 2.3.32,
Why? Please don't take this personally. But if that is because you strictly rely on Linux distribution packages I'd like to note that your operational concept is already flawed.
Because the client I am working for uses source-compiled versions of OpenLDAP and is curently running 2.3.11 or 2.3.32. There is no newer package for the moment.
It should be almost no effort to build packages of 2.3.43 if you have packages of 2.3.32 ... depending on how you build them.
We are working on a OpenLDAP 2.4.16 or newer, but, production is critical and we can not wait for this one to be released (by our team).
I know very well that many changes have been made between 2.3.11 and the latest 2.3.x and even between 2.3.32 and the latest 2.3.x, but we can not afford to migrate to 2.4.x right now.
See also: http://www.openldap.org/faq/data/cache/1456.html
At my customers I normally have a build system matching the system in production where I can compile and test OpenLDAP, SASL and BDB myself installing into a separate prefix. Given that VMware machines are pretty cheap to set up this is feasible today even if you have various i386 OS running in production.
The project that is using OpenLDAP 2.3.11 is running Solaris 10 SPARC from source.
Is it possible to use a newer version of OpenLDAP as slave ? ie. Could I use OpenLDAP 2.3.11 as master and OpenLDAP 2.3.32 a slave for a while ?
I have justed tested it. OpenLDAP 2.3.11 as master and OpenLDAP 2.3.32 as slave : it WORKS. The question is, is it reliable ?
Well, the contextCSN disappearing from the master most likely won't change if you keep running the same code on the master, so I doubt this will help you.
Regards, Buchan