Dear all,
Currently, I am in the process of rethinking the way we have structured our posixAccounts in the LDAP DB. We have a centralized storage cluster which is attached to a number of compute clusters. Thus, we need to provide the same uids/gids everywhere. Whereas the homedirectory for an user may vary depending on the local mount points of the shared files systems in the cluster.
By now, this problem was solved by introducing objectClasses which basically implement posixAccounts. One oc for each compute cluster we have. Because maintaining the schema extensions on an increasingly fluctuating environment is tough work, I would like to get rid of these oc-extensions by doing the following:
- ou=TOP - ou=users: Keep attributes uid, uidNumber, gidNumber. They are unique for our site and should be used everywhere. - ou=systemA - ou=users: Keep attributes which extends entries from ou=TOP,ou=users by adding homedirectory and loginShell. They depend on the cluster configuration.
I ended up with the idea to use dynlist which automatically fetches the unique attributes from entries beneath ou=TOP,ou=users and specific attributes from the entry beneath the ou=systemA branch.
--- example ldif: --- uid=user01,ou=users,ou=TOP objectClass: posixAccount uid: user01 uidNumber: 10000 gidNumber: 10000 cn: Some Name homedirectory: n/a
uid=user01,ou=users,ou=systemA,ou=TOP objectClass: posixAccount objectClass: x-extendUnique x-extendURI: ldap:///ou=TOP,ou=users?uid,uidNumber,gidNumber?one?(uid=user01) homedirectory: /local/mount/home4711/user01 loginShell: /bin/ksh --- eop ---
--- draft slapd.conf --- overlay dynlist dynlist-attrset x-extendUnique x-extendURI --- eop ---
So the idea is, when searching for a user beneath the systemA branch, the resulting entry should be completed by attributes in the top users' branch.
Before playing around with that, I would like to ask if the way I intend to use dynlist is the proposed way?
Is there another neat way to implement that? Meaning, that a search result entry is combined from two different entries? I really would like to avoid having copies of the unique attributes at many locations in the tree.
How does schemachecking work on dynlist?
How would dynlist respond to single-valued attributes which are imported but already present in the entry? Would it overwrite the existing attribute?
Do you think, keeping multiple entries for an user is too much overhead compared to use only one entry with multiple objectClasses?
Many thanks,