NFS/Kerberos - Revision history

Jxpryde: /* NFS */

2015-12-04T06:20:50Z

NFS

← Older revision		Revision as of 01:20, 4 December 2015
Line 9:		Line 9:
	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

	In November 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit. NFSv4, just not ready.		In November 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit. NFSv4, '''just not ready'''.

	== Troubleshooting ==		== Troubleshooting ==

Jxpryde: /* NFS */

2015-12-04T06:19:57Z

NFS

← Older revision		Revision as of 01:19, 4 December 2015
Line 9:		Line 9:
	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

	In November 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit.		In November 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit. NFSv4, just not ready.

	== Troubleshooting ==		== Troubleshooting ==

Jxpryde: /* NFS */

2015-12-04T06:18:06Z

NFS

← Older revision		Revision as of 01:18, 4 December 2015
Line 9:		Line 9:
	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

	On ~~December 3,~~ 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit.		In November 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit.

	== Troubleshooting ==		== Troubleshooting ==

Jxpryde at 06:17, 4 December 2015

2015-12-04T06:17:41Z

← Older revision		Revision as of 01:17, 4 December 2015
Line 8:		Line 8:

	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

			On December 3, 2015, we made another attempt at mounting with NFSv4 in the office. This was a huge time suck and failed sporadically. As a result, we have returned to mounting with NFSv3. NFSv4 ACLs/mapping seem to be the culprit.

	== Troubleshooting ==		== Troubleshooting ==

Ztseguin: Added troubleshooting section

2015-10-27T05:11:19Z

Added troubleshooting section

← Older revision		Revision as of 00:11, 27 October 2015
Line 8:		Line 8:

	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

			== Troubleshooting ==

			* If NFS refuses to mount, with a message similar to "Incorrect mount option was specified", ensure that the "nfs-common" service is running. This is required for Kerberos authentication with NFS.

	= ZFS =		= ZFS =

Pbarfuss at 22:25, 12 August 2013

2013-08-12T22:25:13Z

← Older revision		Revision as of 17:25, 12 August 2013
Line 1:		Line 1:
	Our user-data is stored in /users on [[Machine_List#~~ginseng~~\|~~ginseng~~]] on an LVM ~~logical~~ ~~volume~~. All of our systems NFS mount /users, and most of them do so using [[Kerberos]] for authentication.		Our user-data is stored in /users on [[Machine_List#psilodump\|psilodump]] on an ISCSI volume exported to [[Machine_List#aspartame\|aspartame]], which exports /users/ via NFS. Plans to add a layer of LVM abstraction so as to support regular snapshot backups of /users/ are currently in-place, but not yet fully implemented. All of our systems NFS mount /users, and most of them do so using [[Kerberos]] for authentication.

	We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.		We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.

Sharvey: moved User-data to NFS/Kerberos over redirect

2013-02-05T18:13:51Z

moved User-data to NFS/Kerberos over redirect

← Older revision	Revision as of 13:13, 5 February 2013
(No difference)

Mspang at 04:54, 12 May 2010

2010-05-12T04:54:39Z

← Older revision		Revision as of 23:54, 11 May 2010
Line 1:		Line 1:
	Our user-data is stored in /users on [[Machine_List#ginseng\|ginseng]] on ~~a 400 GB~~ LVM logical volume. All of our systems NFS mount /users, and most of them do so using [[Kerberos]] for authentication.		Our user-data is stored in /users on [[Machine_List#ginseng\|ginseng]] on an LVM logical volume. All of our systems NFS mount /users, and most of them do so using [[Kerberos]] for authentication.

	We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.		We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.

Jbroman: add to Services and Software categories

2010-03-23T00:15:20Z

add to Services and Software categories

← Older revision		Revision as of 19:15, 22 March 2010
Line 12:		Line 12:

	On March 15, 2008, we transitioned to ZFS. This move has since been reversed; details are preserved in [http://wiki.csclub.uwaterloo.ca/User-data?oldid=2331 a previous revision of this page]		On March 15, 2008, we transitioned to ZFS. This move has since been reversed; details are preserved in [http://wiki.csclub.uwaterloo.ca/User-data?oldid=2331 a previous revision of this page]

			[[Category:Services]]
			[[Category:Software]]

Jbroman: changed ginseng info

2010-01-19T04:36:01Z

changed ginseng info

← Older revision		Revision as of 23:36, 18 January 2010
Line 1:		Line 1:
	Our user-data is stored in /users on [[Machine_List#ginseng\|ginseng]] in a ~~RAID 1 mirror running on two~~ 400 GB ~~SATA~~ ~~disks~~. All of our systems NFS mount /users.		Our user-data is stored in /users on [[Machine_List#ginseng\|ginseng]] on a 400 GB LVM logical volume. All of our systems NFS mount /users, and most of them do so using [[Kerberos]] for authentication.

	We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.		We have also explored additional methods for replicating user-data, including AFS, Coda, and DRBD, but have found all to be unusable or problematic.
Line 8:		Line 8:

	On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.		On November 8, 2007, we experienced a major NFS failure. An analysis of the logs indicated that the fault was likely caused by NFSv4-specific code. As a result, we have returned to mounting with NFSv3.

	== NFSv4 (client-side) ==

	In order to support NFSv4 ACL's with getfacl/setfacl, you should apply the [http://www.citi.umich.edu/projects/nfsv4/linux/ NFSv4 ACL patch]. You can also compile the [http://www.citi.umich.edu/projects/nfsv4/linux/ nfs4_getfacl/nfs4_setfacl utils].

	= ZFS =		= ZFS =