Difference between revisions of "File server options"
Jump to navigation
Jump to search
import>Cen1001 |
import>Cen1001 (Replaced content with "See http://www-co.ch.cam.ac.uk/facilities/fileservers/#theory-fs.ch.private.cam.ac.uk") |
||
| (8 intermediate revisions by the same user not shown) | |||
| 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. |
||
| − | * 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 |
||
| − | * 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 |
||
| − | * 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? |
||