Why not use rsync to distribute the built maps?- perfectly acceptable way to do it
- nsscache does validation of the generated data, so you know the cache database is sound and hasn't been corrupted in transit
- jaq didn't care to build an rsync server
Can't you just fix nscd and send the patches upstream?- People have tried.
- This doesn't fix the underlying issue within POSIX that we can't tolerate anything but 100% reliability.
How does nsscache affect PAM?- NSS is not PAM! login yes, PAM NO
- PAM defines how and where to authenticate or access things, i.e. checking passwords or if you are allowed to login
- NSS is also hit on login -- but to find your home directory, your group membership, etc.
- it can affect auth -- if you don't exist, often pam_unix won't let you in :-)
Do you store passwords in nsscache?- No. We don't do PAM.
- nsscache binds anonymously to LDAP unless you tell it otherwise, so hopefully your LDAP ACLs prevent access to userPassword ;-)
- okay, well, you could store stuff in shadow map and sync it down
- pam lets you ignore pam_unix for auth is our point
What about a faster (sqlite, tdb, etc) backend?- Sounds great, send patches.
- We are super happy with plain text; it's magnitudes faster than Berkeley DB for our purposes and expect it to scale another order of magnitude before we have to worry about access time.
- jaq should post some performance charts on here.
|
Sign in to add a comment
