George Holbert wrote: > Thanks for the feedback Rich, > >> There are a couple of different ways to do something similar. You >> can use "smart referrals" to make the client follow the chain instead >> of the server. Class of Service can be used to generate attributes >> and values based on references to other entries. > > > > Yes, smart referrals seem like they could do pretty much the same > thing. One big difference is that a referral must include a LDAP > server in the URL it hands back to the client. The potential drawback > of this is that the referral URL should likely be different depending > on the location of the client. For example, a client in Asia should > be referred to a server in Asia, while a US client should be referred > to a US server. This means the referral data will need to be > different depending on location, so it cannot be replicated from one > central server. > > Aliases, on the other hand, wouldn't depend on a server's location, so > they could be the same regardless of where a consumer server is located. > > Do you happen to know: is there some URL variable mechanism that > would allow me to configure a referral URL which uses the "current > LDAP server" so that referral URLs would not need to include hardcoded > hostnames? Not sure. You may be able to use ldap:///<entry DN> e.g. ldap:///uid=another user,ou=people,dc=example,dc=com If not, then we should probably put this on the wishlist/roadmap. > > I'm only looking to re-direct lookups to another location in the DIT, > not to another server. It would be great to be able to do this with > one generic URL. > > Thanks again, > -- George > > Rich Megginson wrote: > >> George Holbert wrote: >> >>> >>> I've noticed that FDS and other Netscape-derived directory servers >>> (like Sun's) do not have support for LDAP aliases. >>> >>> At one point there was an IETF draft for LDAP aliases which can >>> still be found here: >>> http://www.watersprings.org/pub/id/draft-byrne-ldap-alias-00.txt >>> >>> Based on documentation snippets I've run across, it looks like some >>> LDAP servers (IBM, Novell) still support the alias schema suggested >>> in the draft. >> >> >> >> I think the latest version of Sun DS (5.2 sp 3) may support aliases. >> >>> >>> I'm wondering why the alias schema is not included in FDS? My guess >>> is that LDAP aliases turned out to be a bad idea for various >>> reasons, but I'm not exactly sure what these reasons are. >> >> >> >> I don't remember exactly why Netscape never supported aliases. There >> are a couple of different ways to do something similar. You can use >> "smart referrals" to make the client follow the chain instead of the >> server. Class of Service can be used to generate attributes and >> values based on references to other entries. >> >> If there is enough interest, we could investigate adding support to FDS. >> >>> >>> Does anyone have any philosophies to share about LDAP aliases and/or >>> why they aren't included in FDS? >>> >>> Thanks very much, >>> -- George >>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >> >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> > > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3312 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20050711/f790e508/attachment.bin
