Hello Howard, at first, thank you for your very interesting answers !
> Sepp wrote: > >> Hello, >> >> here is our three-level concept for replication, >> 1 provider, 2 subproviders, 10 consumers: >> * the provider should replicate most of his subtrees to both subproviders >> * a few subtrees should be replicated from the 2 subproviders to the provider >> * subprovider no1 should replicate his whole tree to 5 consumers >> * subprovider no2 should replicate his whole tree to the other 5 consumers >> * a few user entries (eg. the replication manager) should be replicated from >> subprovider no.1 to subprovider no.2, and from 1 consumer to the other 9 >> comsumers >> >> Here are the questions concerning this config: >> >> 1.) Is the best (and perhaps only ?) way for an implementation >> to devide the DITs in subordinate databases with the according syncrepl >> statements (similar to openldap-2.3.28/tests/data/slapd-glue-syncrepl*.conf, >> we have a successful test config for that) >> > > For now that is the only way. > > >> 2.) Do we need the glue overlay in this context (I don't think so) ? >> > > You only need glue if you want the overall database to appear unified, > i.e. such that a subtree search from the root will return results from > all of the databases. > > This was the point of my question: I have no "overlay glue" directive in my slapd.conf, but with the following command I get the values of all description attributes in all subordinates: ldapsearch -x -h localhost -p 389 -b "o=test,c=de" "description=*" LDAP Browsing over all subordinate limits is no problem either. Did I get you right that this should not really work without "overlay glue" ? >> 3.) Is it necessary that one subordinate have all indexes from all other >> subordinates (I do think so, to prevent "index_param failed" error messages >> when searching from top level) >> > > Every database should have whatever indexing configured as needed for > whatever queries it will have to answer. > > >> 4.) Sorry, when that's a FAQ: Is it a must that the updatedn is not the >> same like the rootdn or is it only a recommendation ? Is this for security >> reasons or why ? >> > > In terms of syncrepl there is no updatedn, so the question is moot. In > terms of slurpd it's to prevent confusion when an administrator attempts > to write on a slave; if the rootdn and updatedn are identical then the > write will be allowed even though it may be improperly formatted. > > In older manpages of slapd.conf (and in one new book) I found that syncrepl has the option updatedn=<dn> and that there is another "updatedn" which is only applicable when using slurpd. This is obsolete ? Btw, why is the very important option "exattrs" not part of the syncrepl description in the slapd.conf-Manpage ? >> 5.) With slurpd it is possible to replicate more than one subtrees >> from one database with several "suffix"-statements. How can I do >> that with syncrepl ? I didn't find a way to define more than >> one "searchbase" per "syncrepl rid" or to define more than one >> "syncrepl rid" per "database". >> > > The feature allowing multiple syncrepl targets in a single database was > present in OpenLDAP 2.2 but dropped for 2.3 because it never worked in > 2.2. Since there were so many usability issues with syncrepl in 2.2 we > decided to simplify it in 2.3 just to get it to a stable working state. > In 2.4 we will probably re-introduce support for multiple targets, but > that code has not been written yet. > Thanks !
