Please read the AUP carefully.

The AUP

The SCRTP acceptable use policies exist to safeguard the performance, reliability and integrity of our systems for all users.

0. University policies and regulations

   1. All computing facilities provided by the SCRTP are subject to University regulations and policies.

1. Support

   1. All formal support requests should be made through bugzilla. Where attempts are made to use other communication channels, such as email, SCRTP system administration are likely to ask that the issue be placed on bugzilla. This allows us to track, prioritise and manage support requests.

   2. Informal support is also offered via the SCRTP Slack channel and weekly drop-in sessions. In some cases this will need longer or more detailed support than can be provided via this mechanism and we will ask that a bugzilla request be made instead.
   3. SCRTP support staff may need to contact users about workload running on SCRTP systems. Users who have submitted jobs to batch queues or left processes running on SCRTP-managed workstations/servers must be reachable via their University of Warwick email address during their normal working hours. SCRTP system administration may need to terminate running processes without further warning if the user owning those processes cannot be contacted.

2. Account

   1. University regulations do not allow sharing your account. It is not possible to distinguish sharing with innocent intentions from unauthorised access by a third-party. Therefore, in order to protect your data, SCRTP computing staff may lock your account if they see a violation of that policy. This is for data security of your own as well as other users data.

   2. Logged-in machines should not be left unattended with the screen unlocked, especially in public, open or shared work areas and offices. To do so exposes your account to the risk of unauthorised access. If SCRTP computing staff see unattended machines with the screen unlocked they may lock your account to protect data.

3. Remote access

   1. When using secure shell (ssh) with public/private keys, to access SCRTP HPC and/or desktop systems remotely, the private key must be protected (encrypted) with a strong passphrase. Private keys without a passphrase are unencrypted and their use is not normally permitted on SCRTP systems. SCRTP staff may: revoke/remove any unencrypted keys present on SCRTP systems; grant exceptions from time to time where there is a use case for unencrypted private keys.

4. Network

   1. Unauthorised devices may not be attached to SCRTP-managed network ports. This means SCRTP-managed desktops should not be powered off or unplugged from the network, or other devices connected without the prior authorisation of SCRTP system administration. If in doubt, check first since unauthorised devices present a security threat and will be removed and blocked from the network.

   2. Self-managed machines should not be attached to SCRTP-managed network ports since doing so presents a security risk. Violations of this policy will result in network access being blocked and further action may be taken, in accordance with University procedures, if there are reasonable grounds to suspect a security violation has occurred.

   3. If you wish to remove your machine from the SCRTP-managed network or re-use a network port assigned to the SCRTP, there isn't a problem provided you obtain, in advance, the authorisation of SCRTP system administration.

5. Software

   1. Software installed and managed by the SCRTP should not be removed, uninstalled or overwritten, regardless of who owns the hardware, without prior authorisation from SCRTP system administration.

   2. Use of BitTorrent on SCRTP-managed machines is permitted for legitimate purposes only. Using BitTorrent for copyright infringement is forbidden by both University and SCRTP policies. Where we receive notice alleging copyright infringement, we will investigate it and if potentially infringing files are found, access to them will be blocked and the name of the associated user account will be passed to the appropriate Head of Department for further consideration.

   3. Dropbox file synchronisation software must not be run on SCRTP-managed systems. We do provide an alternative that can also act as a proxy to your Dropbox account.

   4. It is not permitted for the users to install or run third-party, unapproved remote access tools on their accounts. Any and all remote access tools need to be installed and maintained centrally and their installation requested via Bugzilla.

      Examples of such third party remote access software include, but aren't limited to, TeamViewer.

   5. Users must not modify or attempt to reconfigure SCRTP-installed remote access tools to circumvent authentication requirements.

6. Storage

   1. Users should utilise SCRTP-managed storage in accordance with the guidance provided by SCRTP system administration. Specifically storage intended for work or scratch should not be used for long term data retention since to do so exposes those data to risk of being lost; backed-up storage should not be used as a work or scratch area for temporary data since this may cause those data to be unnecessarily backed up.

   2. Users should not utilise /tmp for long term data storage; /tmp directories are subject to periodic clean-up and cannot be relied upon for anything other than temporary scratch storage.

   3. All pseudo-filesystems (sshfs, encfs and other fuse-based, user-controllable filesystems) must be mounted inside /var/tmp/$USER/ where $USER is the shell variable containing the username for the current login session.

      Network filesystem mount points (i.e. inside /home, /cold or /storage) are strictly forbidden as they interfere with mount/unmount operations during a system restart.

      When users are detected using network-filesystem mountpoints to attach pseudo-filesystems, a policy similar to one outlined in paragraph 6. will be applied.

   4. Usual block device mount points (optical media, flash cards, external drives) will be auto-mounted in /media and are not affected by this restriction.

7. Shared remote desktop server and HPC login nodes

   1. This concerns the shared remote desktop server godzilla.csc.warwick.ac.uk, and the HPC login nodes avon.scrtp.warwick.ac.uk and orac.csc.warwick.ac.uk. These are intended to provide convenient remote access to SCRTP Linux (godzilla) and a frontend to the HPC clusters (avon and orac). They are explicitly not intended to run compute jobs, even for relatively short periods of time or for test purposes. All compute jobs should be run through the available batch system and not on these servers directly.

      When users are detected using login nodes for computation, or in any manner which restricts usability to other users, the following policy applies:

      • Level 1: Anyone detected using a login node for computation will have their access temporarily revoked. A notification email will be sent to your SCRTP-registered email address. Only access to the specific login node will be revoked; access to your SCRTP account through other systems will not be affected. For a first occurrence, if you respond as directed in the notification email, it will usually be possible restore access straight away.
      • Level 2: In case of a more severe violation or a recurrence of a Level 1 violation, your access will be revoked, with notification, and a 24 hour cooling off period will be put in place before your access is restored.
      • Level 3: In the unlikely event of a third repeat or a severe violation of the AUP, your global SCRTP account will be locked (all systems, not just login nodes) pending further investigation into the justification of unlocking the account.

   SCRTP reserves the right to terminate compute processes running on login nodes without notification to the user and apply each level in proportion to the severity of the violation. Please note that any late Friday or weekend revocations may not be addressed until the following Monday.