[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: suffixalias not implemented in add.c

Lars Uffmann wrote:
> On Thu, Sep 27, 2001 at 05:35:14PM +0200, Pierangelo Masarati wrote:
> > Lars Uffmann wrote:
> > >
> > > I would like to be able to add a DN even if it is only a SuffixAlias:
> > >
> > > # sample slapd.conf:
> > > suffix "o=mediaways.net"
> > > suffixAlias "o=mediaways,c=de" "ou=mediaways,o=mediaways.net"
> > >
> > > # sample LDIF
> > > dn: uid=test,o=mediaways,c=de
> > > chgangetype: add
> > > [ ... ]
> > >
> > > Doing an ADD using above LDIF schould succeed, rewriting/aliasing the DN to
> > > "uid=test,ou=mediaways,o=mediaways.net"
> > >
> > > I need this to be compatible with all Applications while moving our LDAP
> > > Tree to the new suffix, this whould help a lot with the migration
> > > process.
> >
> > Your statement definitely makes sense. The point I get, from reading
> > thru the code, is that while it is easy to aliase a normalized dn, it
> > gets a bit more difficult to aliase a non-normalized dn, so the added
> > dn should be normalized and would look a bit "square".  The fix would
> > be to also store the (supposedly) non-normalized alias entered in
> > the config file and try to use it to get a non-normalized aliased
> > version of the new dn.
> This sounds reasonable. Replace the entrys DN with the second argument
> to SuffixAlias, to avoid to put uppercased, normalized DNs into
> id2entry. Allthough this would be trade-off I could live with.

I already investigated a very similar topic; the big point is merely 
a matter of style. There's no clean means to add the optional white 
space after the comma. Looking at your specific case:

suffixAlias "o=mediaways,c=de" "ou=mediaways,o=mediaways.net"

> > I'm not sure it is worth the effort; in fact
> > I remember reading about issues involving suffix aliasing in previous
> > postings, which implies subtle side-effects.  I'm not sure what was
> > the real drawback.
> At wich level do acl lookups take place? Before or after the aliasing?

Always after, to my knowledge.  The suffix aliasing is just a matter
rewriting whatever dn comes in before any operation is done.  All the
operations occur on the aliased entry.   

> > If there's a real need I'll try to work something out.
> Yes, I see adding Aliasing support for ADD ist not as straightforward as
> I thought. The feature would be a big win for us, as we are in the
> process of migrating several seperate slapd installations to a new shared
> system. We could completely seperate the application re-configuration
> from the LDAP migration, minimizing service downtime.

In this case, a backup solution would be to leave the old server as is
and access it with the new naming context thru a proxy that rewrites
the suffix on the fly.  This can be done with an altered version of the 
back-ldap (or with the even more general back-meta).  If you feel 
comfortable with devel snapshots you may try the HEAD branch (if you
in doing beta testing, of course).  In the meanwhile I'll have a look 
at the aliasing of the add operation.


Dr. Pierangelo Masarati               | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale                | fax:   +39 02 2399 8334
Politecnico di Milano                 | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy   |