1. Users of the system should make themselves familiar with and obey the University's Policies and Procedures including the General Conditions of Use of Computing and Network Facilities.

2. Users should protect their account with a well-chosen obscure password and not divulge that password to anyone else, or any Internet Service Provider or other organisation. If you think your account has been used by someone else then you must inform Mark Slater. Particular care must be taken when connecting from a computer outside the group. Change your password reasonably often using the passwd command at any terminal.

3. Users should use email in a responsible way: avoid unnecessary multiple mailings and don't use email to transmit large files. If you receive junk mail (spam) about any subject, don't reply to it or click on any contained links. There are ways of reporting it locally.

4. Users should only run software which is provided by the system and software directly associated with their experiments. Any other software should not be imported. You should not run any servers or services. Consult with Mark Slater if in doubt. If you need a particular package and it is not provided on our system, then approach MWS who will look into installing it.

5. You may not disconnect or connect any provided PCs on the network. Computers already on the network must only run the operating system and services agreed with MWS, via the connection point provided for that computer.

6. Generally, personal laptops do not need to be connected to the wired network. See MWS for special dispensation to connect a laptop or unmanaged device to the wired network.

7. Users should be aware that the university can monitor all web traffic, including the recording of each end of connections at the very least, and monitors all email traffic, as required by legislation.

8. Users should not display, download, or store or send, any illegal or offensive material on our computer facilities. University regulations forbid storing of pornographic material on any computers: it's a disciplinary offence. Because browsers have a cache, simply viewing implies storing.

9. The university reserves the right to do spot-checks on any computer without notice, and on previous form, will remove for several weeks equipment associated with infringements of the rules. (This would have a serious effect on research).

10. Users may have their own web pages provided through the group web server, if they wish and (for students) if their supervisor agrees. These should be in keeping with the experiments they are involved with. Don't use other's material as this infringes their copyright. Those wishing to have web pages which reflect their personal interests outside their experiment should use an external web service provider, or a social networking site.

11. Please take care of the equipment provided for you. Avoid marking it or putting stickers on it that might be difficult to remove in the future. Do not move computing items from one PC to another without consulting MWS. If there is a problem with a PC, consult MWS first. Keep equipment well-ventilated to avoid risk of fire.

12. Drinks, food and cigarettes are bad for computers, particularly keyboards. Please keep them apart. (Smoking is not allowed in university buildings in any case).

Default Shell

By default, the login shell is Bash. This can be changed by sending a request to MWS. To run commands when you login, you can put them in the file:

~/.bashrc

This will be source'd every time you login to the system. Note that if you want specific things only for opening a new terminal window/screen window, then use:

~/.bash_profile

For more info on the order of what scripts are executed and when on login/logout, see this page.

Operating Systems Available

In order to give a decent and up-to-date desktop experience, we use the Fedora distribution that is based on Red Hat. However, as a lot of the software we use is tied to the more stable RHEL releases, you can switch to using either a CentOS 7 or AlmaLinux 9 container by doing:

cc7
or
alma9

If there is specific setup you want done when you enter the container, add them to the file:

~/.bashrc_cc7
or
~/.bashrc_alma9

and this will be source'd when the shell starts.

Changing Password

To change your password (which you should do on a semi-regular basis!), you can use the command:

passwd

After giving your current password you will be able to enter a new one. Note that it needs to pass the complexity restrictions to be accepted which means it must:

• Be a minimum of 8 characters long (though the longer the better!)
• Contain upper and lowercase letters, numbers and punctuation
• Cannot include dictionary words or your username

Email

On joining the group you'll get an email address that is based on:

user@hep.ph.bham.ac.uk

This will be set to forward any group email to the forwarding address you gave when the account was created. This forwarding address can be any valid email you'd like, e.g. CERN, University, Gmail, etc. In addition, your email will automatically added to the appropriate group email lists. If you'd like to change any of these settings, please get in touch with MWS.

There are several email lists available, the most useful ones are (all are @hep.ph.bham.ac.uk):

• ppgroup, ppstaff, ppstud: the whole group, staff or students excluding ALICE members
• epgroup, epstaff, epstud: the whole group, staff or students including ALICE members
• localusers: Users with a registered office in the department
• e.g. atlasgroup, atlasstaff, atlasstud: Each group (e.g. atlas, lhcb, dune, na62, etc.) have their own group, staff and student lists
• newstud: PhD students that have joined in the last 12 months
• uglist: Any currently active undergraduates

To find out which users are on which lists, you can just grep for them:

grep ^epgroup /disk/maildisk/home/mail/share/aliases

To avoid confusion, note that your University provided email (adfusername@bham.ac.uk or adfusername@student.bham.ac.uk) is accessed through the page mail.bham.ac.uk. From this Outlook web interface, you can manage this email here or get it forwarded somewhere else (Go to 'Settings' -> 'Options' -> 'Inbox and Sweep Rules'). Again though, the login here is your University provided (or ADF) login, NOT your PP group Linux login!

Grid Certificates and Website SSL Access

It is highly likely you will need a Grid Certificate while working in the group. Your experiment may have particular rules for how to go about this, but if not you can request a CERN one from here. Alternatively, you can request a UK one from here. This will involve getting in touch with MWS to show your university ID in order to authorise your request. There is a dedicated page describing the process here: Requesting a Grid Certificate.

Printing and Scanning

To print when in the department, please use the Managed Print Service. The desktops are already setup to print to this using the 'SafeQ' printer option. After sending a print job, go to one of the printers (Coffee area 2nd floor, W333A on the 3rd floor), tap your University Card and give your central university username and password. You should then be able to print your job from the 'Waiting' Queue. You can also use these devices for photocopying or scanning to email. For more info about the service and instructions about how to set it up on a privately owned laptop, please see this KB article. Note that if you find it doesn't work, you may not have given MWS your ADF username - get in touch with it and it will be updated!

Specifications

The batch system available in the PP group is running HTCondor and consists of 4 nodes with 64 cores per node and 2GB RAM per core. In total there are a maximum of 256 cores available. A fairshare system is in place to minimise the monopoly of the cluster by any single user. To get an overview of the whole cluster and see what's currently running, use condor_status.

Submitting and Managing Jobs

There are two principle ways of submitting: Using a submission config script or direct submission of a script. The simplest option is just to submit a script using:

condor_qsub [script_name]

This will submit the job and it will wait in the queue until it's matched and then run on the given worker node. Note that you need to give an actual executable script in the above otherwise you'll get an error and the job will go on hold. If you want more control over the submission, including submitting batches of jobs, you should use a condor submission script. A basic version of this is:

Executable = [script_name]
Universe = vanilla
output = [stdout file]
error = [stderr file]
log = [condor log file]
# in MB
request_memory = 500
request_disk = 3000000
environment="TESTVAR=mytestvar"
queue


There are many more options to this subission file so please see the condor documentation for more info.

After you've submitted your job, you can view the status of it and any other jobs you've submitted using condor_q. If you want more information about a job, use condor_q -better-analyze [jobID].

Troubleshooting

If your jobs refuse to run or go immediately on to HOLD, then there are a few ways to find out what the problem is:

• Use condor_q -better-analyze [jobID] and see if that gives a reason for the failure
• Look at the produced condor log file. This will record each step of your jobs trip through the batch system and should give reasons for any failure
• If your job has run but then failed, you can check the stderr file as that may also show problems
• If your jobs are never going to run for whatever reason, please delete them using condor_rm [jobID]

If you've checked these but still can't figure out where the problem is, please get in touch with MWS.