File server options

From CUC3
Revision as of 18:45, 2 February 2009 by import>Cen1001
Jump to navigation Jump to search

We have some file server hardware which can provide a large network attached space for people to store things. We have to decide how we're going to access it as all the possible methods have major disadvantages.

The majority of the clients are managed Linux workstations using the LDAP service. We also have access to a Windows Active Directory (AD) but don't currently make use of it for the Linux clients. The medium term plan is to switch to using the AD password for authentication on the Linux machines.

It would be nice to allow Windows and Mac clients, such as people's laptops, to access the system.

We can run more than one of the methods below but the system's only as secure as the least secure method. At the moment I rather like sshfs + CIFS (with cifs using Windows AD passwords and sshfs using LDAP now, to migrate to AD later) + maybe a few extremely trusted clients with NFS.

Standard NFS

  • very stable
  • can easily be made to mount automatically on boot or access - ie the user doesn't have to think about it
  • Causes problems when we reboot the file server for security patches when clients have the filesystem mounted- clients may hang or get stale filehandles (this is not supposed to happen but it always does, and sometimes only rebooting the client cures it- therefore you sometimes need a CO to fix it)
  • no security- any sufficiently determined person with physical access to the Chemistry network can read, edit or delete files on the server so must not be used for sensitive data, and must be very well backed up to be safe from vandalism
  • Macs should be OK with this. Not so sure about all Windows variants. However the security problem is so severe that we cannot allow clients we do not control to connect to NFS so this is moot.

CIFS/Samba

  • can be set up to require authentication, so much more secure than NFS
  • I believe it's pretty stable
  • cannot use Unix passwords so needs users to remember a second password for access
  • can use the AD password
  • I can't automount it for people on login using PAM while the clients are using LDAP
  • the password problem vanishes if the Linux clients got their user authentication passwords from the Windows AD, which is our medium term plan anyway, but this takes time to implement
  • not sure how it copes with server reboots - have read things implying it doesn't
  • works very well for Windows and Mac clients

sshfs

  • secure - needs authentication to access and encrypts the traffic
  • uses the underlying Unix authentication method, so works with whatever we choose to use for workstations (currently LDAP but wish to migrate to AD)
  • copes very well with server reboots - just reconnects
  • can be made to automount on login with some scripting and PAM
  • some standard query commands don't work with it: df and probably quota
  • not 100% stable- sometimes locks up at the client end if there is very high activity. This can be unwedged by the end user (ie you don't need to find a computer officer to help) but is a nuisance all the same
  • there are Windows and Mac scp clients although this is not an ideal solution. There is also sshfs for Windows but may not be Free and have not tried it myself

Kerberized NFS

  • very secure
  • Should be just as reliable as standard NFS
  • Requires a Kerberos infrastructure which we do not have and do not have time to implement
  • probably has teh same problems with server reboots as standard NFS
  • Automounting on login needs investigating- could be complex?