Hello.
I'm trying to find the best way to conduct a consequent change in our data model and servers topology, with the fewer service disturbing.
Before the reorganisation, we were a single entity, splitted on three different sites. As a consequence, we had a single database for all our users and groups:
dc=new,dc=foo,dc=tld |-users | |-site1 | |-site2 | |-site3 |-groups |-site1 |-site2 |-site3
The master server is hosted on one site, and we have slave servers on three sites
After the reorganisation, we are three different entities, and I'd like to break the tree in the three different databases, each site hosting a server acting as the master for its own base, a slave for the two others:
dc=site1,dc=foo,dc=tld |-users |-groups
dc=site2,dc=foo,dc=tld |-users |-groups
dc=site3,dc=foo,dc=tld |-users |-groups
The change also involves dropping the last part of the original suffix, which is no longer relevant.
I'm currently investigating the usage slapo-rwm to provide virtual views of the current database according to the new structure, so as to progressively migrate applications configuration first, then write an automated conversion tool, and finally convert the virtual bases to new ones. But maybe they are better strategies ?
On Tue, Feb 9, 2010 at 5:16 PM, Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
migrate applications configuration first, then write an automated conversion tool, and finally convert the virtual bases to new ones. But maybe they are better strategies ?
From my own painful experience, best scenario would be to script the
migration of users by querying them according to sites and preparing a new ldif for a test server. Trying to get into views might work but is most likely to break due to some configuration changes (triggered or not by you).
Just out of curiosity, which version of OpenLDAP are you using?
Cheers, Steph
openldap-software@openldap.org
-
FRLinux -
Guillaume Rousse