[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
agree
in doing beta testing, of course). In the meanwhile I'll have a look
at the aliasing of the add operation.
Pierangelo.
--
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 |
http://www.aero.polimi.it/~masarati