Using libnss-afs is not without its disadvantages. We may want to use ldap again as the user directory for various reasons.
1. LDAP
Pros:
- Not dependent upon AFS running permitting networked user and group information to be found before the openafs client starts.
- Designed for such tasks and highly configurable
Other people maintain libnss-ldap
No need to start a large service during the rcS phase of booting just to have networked users available
Cons:
- We have to keep LDAP and the pts database synchronized
uid and gids
- home directory
- shell
- Yet another service to keep running (and a fairly complicated one at that)
- No clear advantage over using the afs pts db for our purposes
2. AFS PTS Server
Pros:
- No need to ensure the pts server information is in sync with another database
- Provides semi-readable names to AFS PAGs when queried from the group name
- DTRT with home directories and shell configuration (at least within our setup)
- We have a known good configuration
Cons:
- No networked user information is available until the openafs client starts
- If communication with the afs server is lost user and group info becomes unavailable
- We may need to keep LDAP around anyway for storing information such as the user real name
We effectively have to maintain libnss-afs (which may not be such a burden--the afs and nss interfaces are stable)