Hello,
I’m trying to build a partial replication, but due to the structure of our ldap directory I’m wondering how to do :
I have an ou branch for people that I want to replicate (ou=people,<prefix>) I have an ou branch for groups that I want to replicate (ou=groups,<prefix>) I have an ou branche for sudo that I want to replicate (ou=sudo,<prefix>)
I guess that the setup for that is to replicate on <prefix> base and just filter on the objectClass
BUT… my problem is that I have another ou branch for some people (ou=otherPeople,<prefix>) that I don’t want to replicate, but that contains exactly the same objects than then ou=people,<prefix> branch, so I can not use a filter on objectClass, there is no specific attribut that allow to say if an object belongs to ou=otherPoeple ou to ou=People
I wonder what is the correct solution to achieve my goal.
I was wondering if I could put several olcSyncrepl on the database with the same provider but one for every ou that I want to replicate ?
Or is there a better way to do ?
Thanks in advance
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
On Tue, Jul 23, 2024 at 12:00:10PM +0200, Frédéric Goudal wrote:
Hello,
I’m trying to build a partial replication, but due to the structure of our ldap directory I’m wondering how to do :
I have an ou branch for people that I want to replicate (ou=people,<prefix>) I have an ou branch for groups that I want to replicate (ou=groups,<prefix>) I have an ou branche for sudo that I want to replicate (ou=sudo,<prefix>)
I guess that the setup for that is to replicate on <prefix> base and just filter on the objectClass
BUT… my problem is that I have another ou branch for some people (ou=otherPeople,<prefix>) that I don’t want to replicate, but that contains exactly the same objects than then ou=people,<prefix> branch, so I can not use a filter on objectClass, there is no specific attribut that allow to say if an object belongs to ou=otherPoeple ou to ou=People
I wonder what is the correct solution to achieve my goal.
I was wondering if I could put several olcSyncrepl on the database with the same provider but one for every ou that I want to replicate ?
Or is there a better way to do ?
There are three options: - what you suggest (3 syncrepl statements with different searchbases) - theoretically should work but it's not often deployed and so less tested in the wild - craft your filter accordingly (using 'entryDN:dnSubtreeMatch:=<prefix>') - use ACLs on the provider side to hide certain parts of the DIT from the consumer <- this is what I would usually do unless deltasync was needed
Regards,
Hello,
Thanks for the anwer… We are using delta sync as it seems that it is the best way to synchronise…
The filter as you describe seems to be the easiest solution so that I can select each subtree to replicate. Too bad it’s not so much documented…
Fred.
Le 23 juil. 2024 à 12:37, Ondřej Kuzník ondra@mistotebe.net a écrit :
On Tue, Jul 23, 2024 at 12:00:10PM +0200, Frédéric Goudal wrote:
Hello,
I’m trying to build a partial replication, but due to the structure of our ldap directory I’m wondering how to do :
I have an ou branch for people that I want to replicate (ou=people,<prefix>) I have an ou branch for groups that I want to replicate (ou=groups,<prefix>) I have an ou branche for sudo that I want to replicate (ou=sudo,<prefix>)
I guess that the setup for that is to replicate on <prefix> base and just filter on the objectClass
BUT… my problem is that I have another ou branch for some people (ou=otherPeople,<prefix>) that I don’t want to replicate, but that contains exactly the same objects than then ou=people,<prefix> branch, so I can not use a filter on objectClass, there is no specific
attribut that allow to say if an object belongs to ou=otherPoeple ou to ou=People
I wonder what is the correct solution to achieve my goal.
I was wondering if I could put several olcSyncrepl on the database with the same provider but one for every ou that I want to replicate ?
Or is there a better way to do ?
There are three options:
- what you suggest (3 syncrepl statements with different searchbases) -
theoretically should work but it's not often deployed and so less tested in the wild
- craft your filter accordingly (using 'entryDN:dnSubtreeMatch:=<prefix>')
- use ACLs on the provider side to hide certain parts of the DIT from
the consumer <- this is what I would usually do unless deltasync was needed
Regards,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
On Wed, Jul 24, 2024 at 09:57:41AM +0200, Frédéric Goudal wrote:
Hello,
Thanks for the anwer… We are using delta sync as it seems that it is the best way to synchronise…
The filter as you describe seems to be the easiest solution so that I can select each subtree to replicate.
Deltasync for partial replication isn't straightforward and I tend to avoid it for that reason. You will definitely have to adjust the logfilter statement as well (values of reqDN and reqNewDN).
Too bad it’s not so much documented…
This is not a common scenario, but if you find a way to encompass this e.g. in the admin guide, we'd be happy to incorporate this.
Thanks,
Hello,
It works, but it is very very slow….. Ok the provider must have 200-300k entries, and I just tried to get 7k out of them…
f.g.
Le 24 juil. 2024 à 10:05, Ondřej Kuzník ondra@mistotebe.net a écrit :
On Wed, Jul 24, 2024 at 09:57:41AM +0200, Frédéric Goudal wrote:
Hello,
Thanks for the anwer… We are using delta sync as it seems that it is the best way to synchronise…
The filter as you describe seems to be the easiest solution so that I can select each subtree to replicate.
Deltasync for partial replication isn't straightforward and I tend to avoid it for that reason. You will definitely have to adjust the logfilter statement as well (values of reqDN and reqNewDN).
Too bad it’s not so much documented…
This is not a common scenario, but if you find a way to encompass this e.g. in the admin guide, we'd be happy to incorporate this.
Thanks,
-- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP
— Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11
openldap-technical@openldap.org