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?
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-users
