On 07/30, Pierangelo Masarati wrote: > Dieter Kluenter wrote: > >Csillag Tamas <[EMAIL PROTECTED]> writes: > >>On 07/29, Pierangelo Masarati wrote: > >>>Csillag Tamas wrote: > > > >[...] > > > >>Subordinate needs a common prefix for the two databases, do they? > >>(If I understand correctly.) > >> > > > >Yes, in principle, but but rwm might do the trick, but I'm not sure. > > > "" is common to any base.
Oh that is really simple. > > > >>That's what I was trying to avoid, with referrals. I'm ready to go the > >>way you suggest just want to make sure what and how to do it correctly. > >>dc=itk,dc=ppke is in production, dc=mkpk,dc=hu is a new suffix, I do not > >>want to make big changes in dc=itk,dc=ppke, but can move dc=mkpk,dc=hu > >>to dc=mkpk,dc=ppke. > >> > >>So I need to create a dc=ppke root element to create a common root > >>prefix. Then create dc=mkpk,dc=ppke and set the subordinate flag for > >>this database. Both must have a same rootdn. > >>If I start a search against dc=ppke I can search both databases. > >>Please correct me if I wrong. > >> > > > >This would be a better task for back-meta and rwm, although I do have > >my struggle with rwm. > > > back-meta means yet another layer (and possibly another server) in > between; slapo-glue (i.e. "subordinate") sounds better for the desired > use. But slapo-glue doesn't work too well with slapo-rwm(5). > > In this case, one could use: > > # ... > > database bdb > suffix "dc=ppke" > subordinate > # ... > > database bdb > suffix "dc=hu" > subordinate > # ... > > database bdb > suffix "" > # ... > > or, as an alternative: > > # ... > > database bdb > suffix "dc=itk,dc=ppke" > # ... > > database bdb > suffix "dc=mkpk,dc=hu" > # ... > > database meta > suffix "" > uri "ldap:///dc=itk,dc=ppke"; > uri "ldap:///dc=mkpk,dc=hu"; > # ... > > so that requests for any of the specific naming contexts get satisfied > by the appropriate database, while any other request gets routed to both > if appropriate (i.e. if the empty base is used). The second solution is > a bit less efficient, but parallelizes lookups; the first approach > serializes operations but should be much lighter. Thanks for the full explanation. Now it is clear to me. Thanks to all. -- CSILLAG Tamas (cstamas) - http://digitus.itk.ppke.hu/~cstamas
