Difference between revisions of "File server options"

From CUC3
Jump to navigation Jump to search
import>Cen1001
import>Cen1001
Line 1: Line 1:
 
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.
 
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. It would be nice to allow other clients access too.
   
 
== Standard NFS ==
 
== Standard NFS ==
Line 6: Line 8:
 
* 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)
 
* 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
 
* 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
+
* Macs should be OK with this. Not so sure about all Windows variants. However the security problem is so severe that we cannot allow random clients to connect so this is moot
   
 
== CIFS/Samba ==
 
== CIFS/Samba ==

Revision as of 17:36, 2 February 2009

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. It would be nice to allow other clients access too.

Standard NFS

  • very stable
  • 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 random clients to connect 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
  • this also means I can't automount it for people on login using PAM
  • 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)
  • copes very well with server reboots - just reconnects
  • 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) 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