File server options - Revision history

import>Cen1001: Replaced content with "See http://www-co.ch.cam.ac.uk/facilities/fileservers/#theory-fs.ch.private.cam.ac.uk"

2014-06-04T10:09:53Z

Replaced content with "See http://www-co.ch.cam.ac.uk/facilities/fileservers/#theory-fs.ch.private.cam.ac.uk"

← Older revision		Revision as of 10:09, 4 June 2014
Line 1:		Line 1:
			See
	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.

			http://www-co.ch.cam.ac.uk/facilities/fileservers/#theory-fs.ch.private.cam.ac.uk
	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. This means you will essentially have one password for Chemistry services.

	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 <i>extremely</i> trusted clients with NFS.

	Comments welcome. It's probably best if they're put at the end, or at least at the end of the list of pros and cons for the method you're commenting on.

	== 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. This is copable with if we only allow a very small list of trusted clients that we'll notice any problem with fast (eg chimaera). Allowing workstations, never mind personal machines, is much more problematic. (NB this does not affect the current NFS service, which is read-only- you can easily read all the data but not modify or delete it)
	* 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 second 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
	* Even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.
	* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS
	* works very well for Windows and Mac clients
	* Could set the server up to use the AD password and use fileserver access as a carrot to get people using the AD, prior to moving the workstations over to AD passwords

	== 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. ssh key logins are not an issue as they can worked around.
	* 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. Can be worked around by using rsync or scp for big transfers but needs people to remember that.
	* 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?

import>Cen1001: /* sshfs */

2009-02-04T15:28:59Z

sshfs

← Older revision		Revision as of 15:28, 4 February 2009
Line 35:		Line 35:
	* uses the underlying Unix authentication method, so works with whatever we choose to use for workstations (currently LDAP but wish to migrate to AD)		* 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		* copes very well with server reboots - just reconnects
	* can be made to automount on login with some scripting and PAM. ssh key logins are not an issue.		* can be made to automount on login with some scripting and PAM. ssh key logins are not an issue as they can worked around.
	* some standard query commands don't work with it: df and probably quota		* 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. Can be worked around by using rsync or scp for big transfers but needs people to remember that.		* 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. Can be worked around by using rsync or scp for big transfers but needs people to remember that.

import>Cen1001: /* CIFS/Samba */

2009-02-04T15:26:38Z

CIFS/Samba

← Older revision		Revision as of 15:26, 4 February 2009
Line 25:		Line 25:
	* I can't automount it for people on login using PAM while the clients are using LDAP.		* I can't automount it for people on login using PAM while the clients are using LDAP.
	* the second 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		* the second 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
	* ~~And even~~ if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.		* Even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.
	* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS		* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS
	* works very well for Windows and Mac clients		* works very well for Windows and Mac clients

import>Cen1001: /* CIFS/Samba */

2009-02-04T15:26:23Z

CIFS/Samba

← Older revision		Revision as of 15:26, 4 February 2009
Line 24:		Line 24:
	* can use the AD password		* can use the AD password
	* I can't automount it for people on login using PAM while the clients are using LDAP.		* 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		* the second 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
	* And even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.		* And even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.
	* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS		* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS

import>Cen1001: /* CIFS/Samba */

2009-02-04T15:24:14Z

CIFS/Samba

← Older revision		Revision as of 15:24, 4 February 2009
Line 28:		Line 28:
	* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS		* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS
	* works very well for Windows and Mac clients		* works very well for Windows and Mac clients
			* Could set the server up to use the AD password and use fileserver access as a carrot to get people using the AD, prior to moving the workstations over to AD passwords

	== sshfs ==		== sshfs ==

import>Cen1001: /* sshfs */

2009-02-03T14:50:23Z

sshfs

← Older revision		Revision as of 14:50, 3 February 2009
Line 36:		Line 36:
	* can be made to automount on login with some scripting and PAM. ssh key logins are not an issue.		* can be made to automount on login with some scripting and PAM. ssh key logins are not an issue.
	* some standard query commands don't work with it: df and probably quota		* 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		* 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. Can be worked around by using rsync or scp for big transfers but needs people to remember that.
	* 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		* 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

import>Cen1001: /* sshfs */

2009-02-03T14:49:33Z

sshfs

← Older revision		Revision as of 14:49, 3 February 2009
Line 34:		Line 34:
	* uses the underlying Unix authentication method, so works with whatever we choose to use for workstations (currently LDAP but wish to migrate to AD)		* 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		* copes very well with server reboots - just reconnects
	* can be made to automount on login with some scripting and PAM		* can be made to automount on login with some scripting and PAM. ssh key logins are not an issue.
	* some standard query commands don't work with it: df and probably quota		* 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		* 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

import>Cen1001: /* CIFS/Samba */

2009-02-03T14:49:02Z

CIFS/Samba

← Older revision		Revision as of 14:49, 3 February 2009
Line 26:		Line 26:
	* 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		* 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
	* And even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.		* And even if we use AD passwords it won't automount if people use ssh key logins, because I can't have PAM send the password to the server if the user didn't enter one in the first place.
	* not sure how it copes with server reboots - have read things implying it ~~doesn't~~		* not sure how it copes with server reboots - have read things implying it has similar problems to Linux NFS
	* works very well for Windows and Mac clients		* works very well for Windows and Mac clients

import>Cen1001: /* Standard NFS */

2009-02-03T14:47:57Z

Standard NFS

← Older revision		Revision as of 14:47, 3 February 2009
Line 14:		Line 14:
	* can easily be made to mount automatically on boot or access - ie the user doesn't have to think about it		* 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)		* 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. This is copable with if we only allow a very small list of trusted clients that we'll notice any problem with fast (eg chimaera). Allowing workstations, never mind personal machines, is much more problematic.		* 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. This is copable with if we only allow a very small list of trusted clients that we'll notice any problem with fast (eg chimaera). Allowing workstations, never mind personal machines, is much more problematic. (NB this does not affect the current NFS service, which is read-only- you can easily read all the data but not modify or delete it)
	* 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.		* 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.

import>Cen1001 at 14:45, 3 February 2009

2009-02-03T14:45:55Z

← Older revision		Revision as of 14:45, 3 February 2009
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. 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.		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. This means you will essentially have one password for Chemistry services.

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