LXC - Revision history

imported>Lmperry at 18:53, 9 October 2020

2020-10-09T18:53:46Z

← Older revision		Revision as of 18:53, 9 October 2020
Line 1:		Line 1:
			<span style="color:red">'''IMPORTANT UPDATE: This system is scheduled to be retired June 2021. Please plan accordingly.''' </span>


	The CNI has received funding from [http://biox.stanford.edu/biox/neuro.html BIO-X Neuroventures] for a high-powered compute server which will be used to provide computational resources to CNI users.		The CNI has received funding from [http://biox.stanford.edu/biox/neuro.html BIO-X Neuroventures] for a high-powered compute server which will be used to provide computational resources to CNI users.
	~~<span style="font-family:monospace;color:red">'''IMPORTANT UPDATE: This system is scheduled to be retired June 2021. Please plan accordingly.''' </span>~~

	== Accounts ==		== Accounts ==

imported>Lmperry at 18:53, 9 October 2020

2020-10-09T18:53:02Z

← Older revision		Revision as of 18:53, 9 October 2020
Line 1:		Line 1:
	The CNI has received funding from [http://biox.stanford.edu/biox/neuro.html BIO-X Neuroventures] for a high-powered compute server which will be used to provide computational resources to CNI users.		The CNI has received funding from [http://biox.stanford.edu/biox/neuro.html BIO-X Neuroventures] for a high-powered compute server which will be used to provide computational resources to CNI users.
			<span style="font-family:monospace;color:red">'''IMPORTANT UPDATE: This system is scheduled to be retired June 2021. Please plan accordingly.''' </span>

	== Accounts ==		== Accounts ==

imported>Lmperry at 18:56, 10 November 2015

2015-11-10T18:56:09Z

← Older revision		Revision as of 18:56, 10 November 2015
Line 29:		Line 29:
	(Remember-- you '''must''' be on the Stanford network to access your container. If you are off campus, use the [https://itservices.stanford.edu/service/vpn Stanford VPN].)		(Remember-- you '''must''' be on the Stanford network to access your container. If you are off campus, use the [https://itservices.stanford.edu/service/vpn Stanford VPN].)

	Also note that ~~/data is~~ not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.		'''Also note that the CNI containers are not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.'''

	However, the data in nimsfs are quite secure on our highly-redundant RAID server with off-site backups to another highly redundant RAID file server. That said, the nimsfs window into the CNI data archive may seem a little quirky due to it being a fusefs virtual file system. But the data in there should never go away, so if anything seems odd (like missing files) just let us know.		However, the data in nimsfs are quite secure on our highly-redundant RAID server with off-site backups to another highly redundant RAID file server. That said, the nimsfs window into the CNI data archive may seem a little quirky due to it being a fusefs virtual file system. But the data in there should never go away, so if anything seems odd (like missing files) just let us know.

imported>Lmperry: /* Allocated Containers */

2015-04-08T23:19:11Z

Allocated Containers

← Older revision		Revision as of 23:19, 8 April 2015
Line 148:		Line 148:
	* cnic6: Grill-spector Lab		* cnic6: Grill-spector Lab
	* cnic7: Gardner Lab		* cnic7: Gardner Lab
			* cnic8: Zaki Lab
			* cnic9: Wagner Lab

imported>Bobd at 23:16, 8 April 2015

2015-04-08T23:16:26Z

← Older revision		Revision as of 23:16, 8 April 2015
Line 138:		Line 138:
	File:opennx10.png \| 2. Resume Session Dialog		File:opennx10.png \| 2. Resume Session Dialog
	</gallery>		</gallery>

			==Allocated Containers==
			* cnic0: template
			* cnic1: CNI
			* cnic2: McClure Lab
			* cnic3: Gross Lab
			* cnic4: Wandell Lab
			* cnic5: McClelland Lab
			* cnic6: Grill-spector Lab
			* cnic7: Gardner Lab

imported>Bobd: /* Scratch Space */

2015-03-30T03:47:08Z

Scratch Space

← Older revision		Revision as of 03:47, 30 March 2015
Line 39:		Line 39:
	mkdir /data/scratch		mkdir /data/scratch

	''The space in this directory is shared and limited. Please do not depend on this for backing up data or storing data. ''		''The space in this directory is shared and limited. Please do not depend on this for backing up data or storing irreplaceable data. ''

	== Software ==		== Software ==

imported>Bobd: /* Data access */

2015-03-30T03:46:21Z

Data access

← Older revision		Revision as of 03:46, 30 March 2015
Line 31:		Line 31:
	Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.		Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.

	However, the data in nimsfs are quite secure on our highly-redundant RAID server with off-site backups to another highly redundant RAID file server. That said, the nimsfs window into the CNI data archive may seem a little quirky due to it being a fusefs virtual file system. But the data in there ~~are quite secure and~~ should never go away~~. So~~ if anything seems odd (like missing files), just let us know.		However, the data in nimsfs are quite secure on our highly-redundant RAID server with off-site backups to another highly redundant RAID file server. That said, the nimsfs window into the CNI data archive may seem a little quirky due to it being a fusefs virtual file system. But the data in there should never go away, so if anything seems odd (like missing files) just let us know.

	One last thing about nimsfs- by default, all raw data are hidden. E.g., if you run the scp command listed above you will only get niftis, QA reports, and physio files (if you recorded physio). You won't get tarballs of dicoms, p-files, or the nims image viewer pyramid files (since you will rarely need those). But if for some reason you do want access to any of these files, have a look in /nimsfs/raw/.		One last thing about nimsfs- by default, all raw data are hidden. E.g., if you run the scp command listed above you will only get niftis, QA reports, and physio files (if you recorded physio). You won't get tarballs of dicoms, p-files, or the nims image viewer pyramid files (since you will rarely need those). But if for some reason you do want access to any of these files, have a look in /nimsfs/raw/.

imported>Bobd: /* Data access */

2015-03-30T03:45:24Z

Data access

← Older revision		Revision as of 03:45, 30 March 2015
Line 31:		Line 31:
	Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.		Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.

	~~And~~, nimsfs may seem a little quirky due to it being a fusefs virtual file system ~~that gives you a window into the CNI data archive~~. But the data in there are quite secure and should never go away. So if anything seems odd, just let us know.		However, the data in nimsfs are quite secure on our highly-redundant RAID server with off-site backups to another highly redundant RAID file server. That said, the nimsfs window into the CNI data archive may seem a little quirky due to it being a fusefs virtual file system. But the data in there are quite secure and should never go away. So if anything seems odd (like missing files), just let us know.

	One last thing about nimsfs- by default, all raw data are hidden. E.g., if you run the scp command listed above you will only get niftis, QA reports, and physio files (if you recorded physio). You won't get tarballs of dicoms, p-files, or the nims image viewer pyramid files. If you want access to any of these files, have a look in /nimsfs/raw/.		One last thing about nimsfs- by default, all raw data are hidden. E.g., if you run the scp command listed above you will only get niftis, QA reports, and physio files (if you recorded physio). You won't get tarballs of dicoms, p-files, or the nims image viewer pyramid files (since you will rarely need those). But if for some reason you do want access to any of these files, have a look in /nimsfs/raw/.

	== Scratch Space ==		== Scratch Space ==

imported>Bobd: /* Data access */

2015-02-03T00:09:47Z

Data access

← Older revision		Revision as of 00:09, 3 February 2015
Line 19:		Line 19:
	All analysis should be done and results saved to the scratch folder located at /data (a link can be found on each user's desktop.)		All analysis should be done and results saved to the scratch folder located at /data (a link can be found on each user's desktop.)

	If you want convenient access to the raw data, or to organize it in the analysis dirs in /data, you can ''~~'use~~ sym-links rather than copying the raw data.'' E.g.,		If you want convenient access to the raw data, or to organize it in the analysis dirs in /data, you can use ''sym-links'' rather than copying the raw data. E.g.,

	ln -s /nimsfs/[group]/[experimentName]/[session]/ foo_sub001		ln -s /nimsfs/[group]/[experimentName]/[session]/ foo_sub001

imported>Bobd at 19:25, 2 February 2015

2015-02-02T19:25:13Z

← Older revision		Revision as of 19:25, 2 February 2015
Line 2:		Line 2:

	== Accounts ==		== Accounts ==
	LXContainers and accounts are created based upon scanning group membership. ~~Usernames and password are taken directly from SunetIDs~~, ~~thus you will not have to set another password -~~ you ~~will use~~ your ~~SunetID~~ and password ~~to authenticate~~.		LXContainers and accounts are created based upon scanning group membership. Authentication uses the Stanford kerberos server, so you log in securely using your normal SUNet username and password.

	If you would like an account or an LXC setup for your group, please contact us.		If you would like an account or an LXC setup for your group, please contact us.
Line 15:		Line 15:
	Users can access their data from NIMS using NIMSfs. All your NIMS data are available in /nimsfs. This means you don't need to download anything. Once you log in to your CNIC there should be a link to /nimsfs on your desktop.		Users can access their data from NIMS using NIMSfs. All your NIMS data are available in /nimsfs. This means you don't need to download anything. Once you log in to your CNIC there should be a link to /nimsfs on your desktop.

	Note that NIMSfs is a read-only filesystem, so you can't save anything there.		Note that NIMSfs is a read-only filesystem, so you can't save anything there. Also, full NIMS access control applies. So, you can give someone an account on your lxc (e.g., an RA) and use the NIMS web interface to define which datasets they will see in nimsfs when they log in to the container.

	All analysis should be done and results saved to the scratch folder located at /data (a link can be found on each user's desktop.)		All analysis should be done and results saved to the scratch folder located at /data (a link can be found on each user's desktop.)
Line 27:		Line 27:
	scp -r [YOUR_SUNetID]@[YOUR_CONTAINER_NAME]:/nimsfs/[group]/[experimentName]/[session]/ .		scp -r [YOUR_SUNetID]@[YOUR_CONTAINER_NAME]:/nimsfs/[group]/[experimentName]/[session]/ .

	(Remember-- you '''must''' be on the Stanford network to access your container. If you are on off campus, use the [https://itservices.stanford.edu/service/vpn Stanford VPN].)		(Remember-- you '''must''' be on the Stanford network to access your container. If you are off campus, use the [https://itservices.stanford.edu/service/vpn Stanford VPN].)

	Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.		Also note that /data is not backed up at the moment. It's an SSD-based RAID system, so should be reasonably reliable, but it would be wise to keep backups of anything not easily recomputed.