Hi,
I have several backend databases on my master servers, and need to present a combined view to clients on slaves (Unix authentication) I think this a common question/issue...
Scenario: 5 backend DB's, 2 of these are needed on each slave server Each of these has an ou=Groups,ou=Nodes, ou=People etc.
--- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org
So one of the slaves uses companyA, common and shared another one uses companyB, commmon and shared and the last one companyC, common and shared
all slaves represent this as "dc=example,dc=org"
The easiest way seems using meta backend, but I've the feeling this has drawbacks??? You can't use cn=config, performance?
Maybe there is an approach with chain or glue? I can change my DIT if necessary.
Sincerely, Pieter
On Tue, 17 Jul 2012, Pieter Baele wrote:
Given databases:
--- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org
all slaves represent this as "dc=example,dc=org"
it looks like a really good situation for a simple glue configuration using the "subordinate" keyword; see slapd.conf(5).
One method also worth putting on the table is hosting the single backend "dc=example,dc=org" on your master and selectively replicating appropriate portions of the DIT using appropriate filters. (Howard recently posted to the list on the best practices to execute this.)
Honestly, you could probably achieve (close to?) desired behavior using any of the methods you mentioned ... it's just a question of complexity and overhead/speed. "subordinate" keeps it really simple; personally I'd start there and ramp up only if testing/needs dictate.
On 17 July 2012 16:06, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Tue, 17 Jul 2012, Pieter Baele wrote:
Given databases:
--- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org
all slaves represent this as "dc=example,dc=org"
it looks like a really good situation for a simple glue configuration using the "subordinate" keyword; see slapd.conf(5).
What lives under ou=CompanyA etc? User accounts? Something we do for this to keep the DIT level shallow, is to keep all user accounts in ou=Users and filter based on o=CompanyA which is an attribute on that user entry. Then you can use slapo-dynlist to create company groups etc.
Not sure what ACLs you've got or the overall function of your directory server to advise a new DIT.
Thanks.
On Tue, Jul 17, 2012 at 7:42 PM, Gavin Henry ghenry@suretecsystems.com wrote:
What lives under ou=CompanyA etc? User accounts? Something we do for this to keep the DIT level shallow, is to keep all user accounts in ou=Users and filter based on o=CompanyA which is an attribute on that user entry. Then you can use slapo-dynlist to create company groups etc.
Each backend (or 1 if I keep everything together on the master) has indeed an ou=People (or Users, doesn't matters) with PosixAccount and an ou=groups (using rfc2307bis to combine posixGroup and groupOfNames)
Indeed, I want the DIT level to be kept shallow. Maybe I can try something with slapo-dynlist, as I will use the overlay to create dynamic groups with memberURL anyway.
Not sure what ACLs you've got or the overall function of your directory server to advise a new DIT.
For the moment I have no special ACL's.
OT: In the end, my goal is to provide an integrated directory service, for three affiliated companies. Primary goal for Linux authentication/authorization, puppet node configs, netgroups, sudo and ssh.... Secondary goal app data or users.
Not easy if you want the directory to be perfect ;-)
Thx a lot for the very useful responses!
On Tue, Jul 17, 2012 at 5:06 PM, Aaron Richton richton@nbcs.rutgers.edu wrote:
On Tue, 17 Jul 2012, Pieter Baele wrote:
Given databases:
--- dc=common,dc=example,dc=org --- dc=shared,dc=example,dc=org --- dc=companyA,dc=example,dc=org --- dc=companyB,dc=example,dc=org --- dc=companyC,dc=example,dc=org
all slaves represent this as "dc=example,dc=org"
it looks like a really good situation for a simple glue configuration using the "subordinate" keyword; see slapd.conf(5).
Had some problems configuring subordinate, a conflict, because of the suffix. Can you give an example based on my example? :-S
I plan to do some contributions
One method also worth putting on the table is hosting the single backend "dc=example,dc=org" on your master and selectively replicating appropriate portions of the DIT using appropriate filters. (Howard recently posted to the list on the best practices to execute this.)
So partial/subtree replication? That's a nice idea, as the clients don't have access to the master. But then an extra containers or attribute is necessary.
"subordinate" keeps it really simple; personally I'd start there and ramp up only if testing/needs dictate.
I tried that approach, but can I combine "Users/People" ou's from 2 backends this way?
On Wed, 18 Jul 2012, Pieter Baele wrote:
Had some problems configuring subordinate, a conflict, because of the suffix. Can you give an example based on my example? :-S
Ordering counts. The OpenLDAP test suite test012 is a worked example; run that and read testrun/slapd.1.conf to get started.
"subordinate" keeps it really simple; personally I'd start there and ramp up only if testing/needs dictate.
I tried that approach, but can I combine "Users/People" ou's from 2 backends this way?
Depends on the overall system (including the clients). But typically, you'd configure clients with the baseDN closest to the root (perhaps "dc=example,dc=com") and the client will do a subentry-scope search that implies coverage across all the various subordinates.
openldap-technical@openldap.org
-
Aaron Richton -
Gavin Henry -
Pieter Baele