Difference between revisions of "Centralized Authentication Proposal"
| Line 2: | Line 2: | ||
| + | ''Arguments For'' | ||
| + | * More easily managed users | ||
| + | * consistent home directories over NFS | ||
| + | ** SSH keys always there | ||
| + | ** Test builds stored on network drive/doesn't take up space on builders | ||
| + | * More modern approach to user management | ||
| + | * Less inconsistencies throughout builders | ||
| + | |||
| + | ''Arguments Against'' | ||
| + | * Additonal services running on Honkgong | ||
| + | * Increased network traffic | ||
| + | * additonal point of failure | ||
| + | |||
| + | |||
| + | ''Means and methods'' | ||
'''NIS/NIS+''' | '''NIS/NIS+''' | ||
| + | * Pros | ||
| + | ** Quick and easy | ||
| + | ** | ||
| + | * Cons | ||
| + | ** | ||
'''OpenLDAP/389 Directory''' | '''OpenLDAP/389 Directory''' | ||
| + | - Standard | ||
'''Kerberos/Heimdall''' | '''Kerberos/Heimdall''' | ||
'''Other''' | '''Other''' | ||
Revision as of 17:01, 23 April 2012
While implementing the BCFG2 configuration management system on the build farm, the prospect of having a passwd, shadow and group file controlled by the utility was brought up several times. While this is one method of managing a consistent set of users and groups across the build farm, I feel that there is other software available that would be better suited for this task.
Arguments For
- More easily managed users
- consistent home directories over NFS
- SSH keys always there
- Test builds stored on network drive/doesn't take up space on builders
- More modern approach to user management
- Less inconsistencies throughout builders
Arguments Against
- Additonal services running on Honkgong
- Increased network traffic
- additonal point of failure
Means and methods
NIS/NIS+
- Pros
- Quick and easy
- Cons
OpenLDAP/389 Directory - Standard
Kerberos/Heimdall
Other
