[SLL] overcoming NFS group limits

[Ted Stern]

On 11 May 2009 16:15:25 -0700, Derek Simkowiak wrote:
...

>     So, that 5% estimate is +/- 300%.  I'll need to run some tests of NFS vs
> SSHFS on my current servers, when I get some time...

Thank you!  I had looked into SSHFS and wasn't sure what the trade-offs
would be.  It is nice to hear of other experiences.

Ted

>
> --Derek
>
> P.S.> While Googling I was also reminded of CurlFtpFS, another FUSE solution
> based on FTP (so, no encryption).
>
> On 05/11/2009 03:12 PM, Derek Simkowiak wrote:
>
>     2) Are there any alternatives to NFS?
>
>        NFS It is the only well-established file sharing network protocol that
>     natively supports the concept of Unix UIDs and GIDs.  Samba "SMB",
>     Appletalk, WebDAV, etc. do not directly support the UIDs and GIDs of a Unix
>     filesystem.  (There are various "mapping" solutions, but they're all ugly.)
>    
>        NFS is also a nightmare.  I've seen a mis-behaving NFS mount cause
>     system failures (like server freezes) on at least three Big Production
>     Systems.  The root cause is that NFS is implemented directly in the kernel
>     (although, a user space NFS for Linux does exist).  There are various
>     options to make NFS play nice, but when problems happen, they can be very
>     serious -- like, you can't SSH in anymore kind of serious.
>    
>        You mentioned large files; if all your servers are in the same data
>     center, you may want to consider moving from a TCP/IP networked filesystem
>     to a shared backend storage, like a fiber SAN using the GFS filesystem. 
>     But that's a major architecture change, and probably not what you're
>     looking for.  (It would be a lot faster, though.)
>    
>        There is one alternative to NFS that supports the native Unix UIDs and
>     GIDs: SSHFS.  SSHFS is a FUSE filesystem.  It allows any user to remotely
>     mount a filesystem using SSH.
>        SSHFS runs in userspace, not in the kernel, so a dirty SSHFS mount won't
>     kill your server.  Like NFS, SSHFS is smart about local caching.  It's also
>     smart about intermittent network connections.  My favorite feature is that
>     SSHFS access can be controlled via SSH keys, which is light years beyond
>     what NFS can offer in terms of security and management policies (*cough*
>     "root_squash" *cough*).
>    
>        The one (and only?) drawback to SSHFS is that OpenSSH forces you to use
>     encryption.  You'll see a roughly ~5% slowdown in file transfer speeds, due
>     to the encryption and due to the fact it's user space instead of kernel
>     space.  Personally, I'm willing to live with that 5% just to get key-based
>     authentication.  The warm'n'fuzzy feeling that comes from knowing all my
>     network traffic is encrypted is just icing on the cake...
>    
>        My advice is to try SSHFS and see what happens.
>
>     --Derek
>     http://cool-st.com/
>
>     On 05/11/2009 02:14 PM, Ted Stern wrote:
>    
>         This is more of a general Unix question, but I'm looking for a
>         solution on a Linux server.
>        
>         If a user accesses an NFS-mounted disk, NFS supports only the first 16
>         groups of which that user is a member.
>        
>         This might seem ample for most small systems, but I'm at a large
>         company with lots of projects, and due to accounting rules a plethora
>         of groups were created over the years.
>        
>         We've done a major group cleanup (which should have been done anyway)
>         but there are still some users who, because of their involvement with
>         many
>         projects, have to be members of lots of groups.
>        
>         So, two questions:
>        
>         1) Is there any hope that NFS will support more than 16 groups in the
>         near future?
>
>         2) Are there any alternatives to NFS?
>        
>         3) Are there any network mountable filesystems that have support for
>         access control lists?  Note that the protocol has to be at least as
>         fast as NFS because we're supporting multi-GB file access.
>        
>         Thanks,
>        
>         Ted
>

-- 
 Frango ut patefaciam -- I break so that I may reveal