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,
--
Bastian Tweddell Juelich Supercomputing Centre
phone: +49 (2461) 61-6586 HPC in Neuroscience
Attachment:
smime.p7s
Description: S/MIME cryptographic signature