[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Intro and question
> -----Original Message-----
> From: Steve Chan [mailto:sychan@lbl.gov]
> On Wed, 2003-11-12 at 17:54, Howard Chu wrote:
> Thanks - I will probably contact them as well to see what can be done
> on the client side. We want to avoid hacking up the client code, but if
> it can be handled with just configuration directives, that would be
> fine.
> I appreciate that everyone is trying to "think outside the box", but
> does this mean that there isn't a solution to the problem I've posed?
The existing nss_ldap client performs a single query to retrieve a user
entry. The schema for the user attributes does not provide any means for
differentiating values such that they may be applied to specific login
instances.
You can:
1) consolidate all the information into a single entry, with some kind of
tag to differentiate values. e.g.
homeDirectory: {host1}/home/foo
homeDirectory: {host2}/export/home/bar
2) distribute the information as I suggested before, and perform multiple
queries to construct a complete user record
3) create multiple trees with redundant information, and point each client
at the relevant subtree.
(1) and (2) require nss_ldap code changes. (3) requires no code changes, but
means keeping a lot of redundant trees in sync.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support