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") |
||
| (24 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 |
||
| − | == 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) |
||
| − | * 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 |
||
| − | |||
| − | == 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 from the client but is a nuisance |
||
| − | * 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 |
||