Re: Intro and question

[Stephen Chan <sychan@lbl.gov>]

Howard,
   Thanks for your input - I've actually already evaluated all of these 
options, and I'll give you my thoughts on them...

Howard Chu wrote:

> > 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

   Yes, but then we would need to do additional filtering on the client 
side. I don't think the clients support this out of the box, so we would 
need to modify the client code. One of the constraints is to work with 
stock clients, so this isn't really ideal.

> >  2) distribute the information as I suggested before, and perform multiple
> > queries to construct a complete user record

   Once again, this would require client side code updates.
   A totally server side implementation I thought of was to have the 
normal people record, and then create child records of that record for 
cluster specific information. We would then have a custom handler on 
another tree (maybe written in back-perl) that would accept queries, do 
some basic rewrites and query the original tree for the parent and child 
entries and then "flatten" them before returning them.
   The same could potentially be done for option 1 above, where the 
handler looks for a "host" attribute constraint, then then transparently 
filters the results and renames the attributes.

   The problem here is that we'd be writing our own backend code, and 
it would be ideal if there was a common solution to this that had been 
tested out and validated by others.

> >  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.
   Yes, synchronizing across the subtrees is a hassle, which is why  I 
was hoping for another way.

   Steve