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)
2.) Do we need the glue overlay in this context (I don't think so) ?
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)
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 ?
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".
I thank you for help in advance !
Regards
Sepp
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.
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.
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.
I thank you for help in advance !
Regards
Sepp
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 !
Sepp wrote:
Hello Howard,
at first, thank you for your very interesting answers !
Sepp wrote:
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" ?
I must have misunderstood your question. If you have the databases declared as "subordinate" then the glue overlay is used automatically. In that case, you only need to specify it explicitly if you need to control its position in the overlay stack. Otherwise it works without you specifying it.
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 ?
Yes, it is obsolete. Whatever new book you're referring to is providing outdated information.
Btw, why is the very important option "exattrs" not part of the syncrepl description in the slapd.conf-Manpage ?
An oversight. Perhaps you could submit a patch for this to the ITS.
openldap-software@openldap.org
-
Howard Chu -
Sepp