Hello,
for some time now, we're using openldap 2.4.11 on debian lenny and everything is fine - but: We've to scale. Up to now our root-dn is dc=abc - our new root-dn ought to be: dc=xyz, having a subtree dc=abc,dc=xyz The root-dn is set in some application's configs as base dn, furthermore, it's referenced in ldap-entries (dynamic overlay-groups).
Basically I can think of two strategies. a) Change the root-dn within the directory and in all applications depending on it (con: error prone - pro: clean result) b) Install a new server, proxy all requests to the old instance, removing dc=xyz on queries, add dc=xyz on responses. (con: complexity, pro: no changes in apps / Information depending on dc=abc)
Have you had similar problems? What did you do to solve 'em? What strategy do you recommend?
Thanks, Keep smiling yanosz
Jan Lühr openldap-list@stephan.homeunix.net writes:
Hello,
for some time now, we're using openldap 2.4.11 on debian lenny and everything is fine - but: We've to scale. Up to now our root-dn is dc=abc - our new root-dn ought to be: dc=xyz, having a subtree dc=abc,dc=xyz The root-dn is set in some application's configs as base dn, furthermore, it's referenced in ldap-entries (dynamic overlay-groups).
Basically I can think of two strategies. a) Change the root-dn within the directory and in all applications depending on it (con: error prone - pro: clean result) b) Install a new server, proxy all requests to the old instance, removing dc=xyz on queries, add dc=xyz on responses. (con: complexity, pro: no changes in apps / Information depending on dc=abc)
Have you had similar problems? What did you do to solve 'em? What strategy do you recommend?
Have you consired an empty namingContext? Something like database "" in slapd.conf
-Dieter
On Sunday, 6 June 2010 12:50:29 Jan Lühr wrote:
Hello,
for some time now, we're using openldap 2.4.11 on debian lenny and everything is fine - but: We've to scale. Up to now our root-dn is dc=abc - our new root-dn ought to be: dc=xyz, having a subtree dc=abc,dc=xyz The root-dn is set in some application's configs as base dn, furthermore, it's referenced in ldap-entries (dynamic overlay-groups).
s/root-dn/base DN/g
Basically I can think of two strategies. a) Change the root-dn within the directory and in all applications depending on it (con: error prone - pro: clean result) b) Install a new server, proxy all requests to the old instance, removing dc=xyz on queries, add dc=xyz on responses. (con: complexity, pro: no changes in apps / Information depending on dc=abc)
Why not do both? Support the transition of configurations to dc=abc,dc=xyz for (1) by implementing (2)?
Except for the dynamic groups, which I am not sure whether they will work without extra effort, the complexity of doing the equivalent of a "symlink" from dc=abc to dc=abc,dc=xyz is relatively trivial. See 'man slapd-relay'
Regards, Buchan
openldap-technical@openldap.org
-
Buchan Milne -
Dieter Kluenter -
Jan Lühr