|Line 1:||Line 1:|
Latest revision as of 10:39, 6 June 2019
|This page is scheduled for deletion because it is either redundant with information available on the CC wiki, or the software is no longer supported.|
|Note: Some of the information on this page is for our legacy systems only. The page is scheduled for an update to make it applicable to Graham.|
|Description: PRoot is a user-space implementation of chroot, mount --bind, and binfmt_misc.|
|SHARCNET Package information: see PROOT software page in web portal|
|Full list of SHARCNET supported software|
PRoot is a user-space implementation of the following superuser-only operations: chroot, mount --bind, and binfmt_misc. In practical terms, on SHARCNET, PRoot enables the users to do the following within their own account without any privileged (e.g., superuser) access:
- a user can install and run most any Linux distributions from a directory in the user's disk space (using only normal user permissions), and,
- a user can run a program that needs read/write/executable permissions for a path they cannot by mapping that path to one where they can.
In practice, item (1) means the following:
- a user can use easy-to-install programs from a specific Linux distribution,
- a user can use tools dependent on a different (modern) GLIBC,
- a user can avoid upgrading the Linux distribution once things work to avoid "breaking" or altering the program and how it works,
- a user can easily run older or newer programs that what is installed on SHARCNET,
- programs run within PRoot are largely immune to operating system and software changes made to the system.
In practice, item (2) means the following:
- a user can use programs perform read, write, or execute operations to/from locations that cannot be read, written, or executed by that user,
- NOTE: This is done by mapping the path associated with the inaccessible location to a path that the user can access (e.g., /home/username/somedirectory).
There are some non-onerous conditions:
- chroot and PRoot cannot be used within a PRoot session.
- This should only be used for programs that do not require to be run as daemons (where special privileges are required to run the daemon).
- Superuser (i.e., root) access is all fake --everything is run in the user account with only the user account's permissions. Anything that the user account is not allowed to do, is simply not allowed.
- To use PRoot with batch-oriented queuing systems (e.g., sqsub) a script is needed (i.e., see below) to run those programs (which must be run inside the PRoot shell session).
In general, however, PRoot will allow one to run virtually all programs that can be run without using any special permissions.
There remains much work to complete the below proot sharcnet documentation which will be done asap.
module load proot/5.1.0
Jobs maybe run from prooted images as will be explained.
Use of pre-existing linux distribution images will be used in this section.
There is no graphical usage component for this software package, although one is free to install graphical programs within an image.
To print the version and verify the program is working run:
ssh orca.sharcnet.ca "module load proot; proot -V | head -n 20"
A linux distribution maybe installed into a prooted images as will be explained in this section.
See below reference links or run proot --help for further information.
o PRoot Homepage: http://proot.me
o PRoot Github: https://github.com/proot-me
o PRoot Issues: https://github.com/proot-me/PRoot/issues