[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
architecture and DIT change strategy
- To: openldap-software@openldap.org
- Subject: architecture and DIT change strategy
- From: Guillaume Rousse <Guillaume.Rousse@inria.fr>
- Date: Tue, 09 Feb 2010 17:16:46 +0100
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100122 Mandriva/3.0.1-2mdv2010.1 (2010.1) Thunderbird/3.0.1
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 ?
--
BOFH excuse #193:
Did you pay the new Support Fee?