Hi, [EMAIL PROTECTED] writes:
> Hello, > > I'am using Openldap 2.3.7 on Redhat. > (I'am French so excuse my bad english !) > > I'am trying to define a replication architecture (with syncrepl) for > my company. > > I must make a directory for my company which have 110 subsidiary > companies . The "main" company is in Paris (France !) and the > subsidiary companies are in other cities of France. > > So the suffix for the directory is o=my-company. > Each subsidiary has the suffix ou=subsidiary_i,o=my-company > with i from 1 to 110 ! (yes 110 distinct cities under a wide area > network !). > > - Each subsidiary can write only under his suffix > ou=subsidiary_i,o=my-company. > - No one else but the subsidiary_i can write under > ou=subsidiary_i,o=my-company. > - The main company can write only under ou=main,o=my-company. > So no multi-master. > > Each subsidiary and the main company must have a local replicate of > the whole directory: Every ou=subsidiary_i,o=my-company plus > ou=main,o=my-company (110 + 1 replicates !). > > Each subsidiary ou=subsidiary_i,o=my-company has his own database (bdb). > The main company ou=main,o=my-company has also his own databse (bdb) > > Every ou=*,o=my-company is a subordinate of o=my-company > > > I would like to design a correct replication process. > > > I have a main server (star architecture) that would : > > - Pull changes (syncrepl) for ou=subsidiary_i,o=my-company from > ou=subsidiary_i,o=my-company 's subsidiary_i server with i=1 to > 110+1) --> so be a consumer, each subsidiary would be a provider for > his suffix > > - Then each subsidiary_i server would pull changes from the main > server for suffixes ou=subsidiary_j,o=my-company with j <> i and j > from 1 to 111 (other subsidiaries plus main company). > > But to do that the main server must be for ou=subsidiary_i,o=my-company first > a consumer (get the changes) then a > provider to other subsidiaries. [...] This sounds like a rather complicated und resources consuming setup.You should probably think about a back-ldap with proxycaching design. That is, a master server which holds the full data set and back-ldap proxycache in your subsidiaries which pull the relevant data only and update data to the master. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6
