> > > > - It is impractical for us to go to NFSv4 because > our NFS clients do not support it AND v4 requires > kerberos which is also a barrier for our clients. > > v4, in its basic usage, does not require kerberos. We > run v4, and certainly not > kerberos. I'd better not say its name three times.
While what you are saying is true, that NFSv4 can run without Kerberos, the added security features, which will work around the maximum groups issue requires Kerberos (hope it's not 3 times over an entire thread). > nfsmapid handles the mapping of nfsv4 domain to local > id, using getpw* calls. > Those will talk to PAM, PAM will talk to LDAP. So, I > would be under the > impression that you can store user account > information in LDAP. We currently do store our passwords in LDAP, with scripts to manage groups and merge groups ... however I'm coming to the conclusion that ACL's on the files over the network might well be easier to manage than setting up a new Kerberos installation and learning to manage a completely new system. > But I have not tried it myself, nor do I know > specifically what --manage-gids does. "manage-gids" is a work-around/breaking of the RFC to basically trust the local machine to handle groups for the user on the local machine ... the NFSv4+Kerberos system basically gives you that level of trust, if you value security you should not trust any computer you didn't put on your network (hmm ... I think I used it 4 times ... I'm probably fsck'ed) -- This message posted from opensolaris.org _______________________________________________ nfs-discuss mailing list [email protected]
