[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