You are likely to find at some point that you need to work on a department system remotely. In this tutorial, we’ll explore connecting to Snowy, the departmental server.
If you’re familiar with SSH, here are the details you need:
Snowy SSH details
snowy.cs.bris.ac.ukab12345Other available machines
snowy.cs.bris.ac.uk is not the only server/machine you have access too.
When connecting from inside the university you can use the following servers:
paris.cs.bris.ac.uklondon.cs.bris.ac.ukrome.cs.bris.ac.ukIn addition, all the lab machines in MVB 2.11 are available when using snowy as
a jump box, this involves first connecting to snowy then to the lab machine in
a chain like fashion making use of SSH’s ProxyCommand.
Lab machine addresses: it<ID>.users.bris.ac.uk where ID is in the following range:
it025956.users.bris.ac.uk – it025995.users.bris.ac.ukit052556.users.bris.ac.uk – it052595.users.bris.ac.ukOpen a Terminal/Console window, and type the following command:
(where ab12345 is replaced by your username)
Hit return, and wait for the password prompt. Type in your password and press return again. You are now logged in.
PuTTY is the easiest solution for SSH on Windows. You can either download the installer (putty-*.**-installer.msi) or putty.exe, which will run standalone.
Open PuTTY, and enter snowy.cs.bris.ac.uk in the ‘Host Name (or IP address)’ field. Make sure the ‘Port’ is set to 22. Click ‘Open’. If you are asked to trust a signature, click yes. You will be greeted by a prompt that says:
login as:
Type your university username and press return. Then type your password and press return.
You will probably end up working in a terminal a lot of the time, even on Windows. Unfortunately, the set of text-based utilities that comes with Windows is rather lacking. Several efforts exist to make these available on Windows:
Figuring out how to get one of these to work is a good exercise for any first year CS student.
Snowy (like most current Linux systems) supports a feature called X Forwarding. This lets you run graphical applications remotely but use them as if they were running natively(-ish) on your desktop.
To enable X Forwarding, add the -X option when running OpenSSH:
ssh [email protected] -X
Once logged in, you will be able to launch utilities like nautilus (the GNOME file manager) and gedit (the GNOME text editor).
Windows does not support X11, so cannot display forwarded applications natively. However, you can install third-party software that allows graphical remote desktop. One possible solution is the NoMachine client.
To copy from your computer to Snowy:
scp sourcefile [email protected]:targetfile
For example, scp ~/main.c [email protected]:~/main.c.
To copy from Snowy to your computer:
scp [email protected]:sourcefile targetfile
For example, scp [email protected]:~/main.c ~/main.c
On Windows, the easiest graphical method to transfer files is to use SFTP. There are many SFTP clients available. FileZilla is free and works nicely. Use the following settings:
snowy.cs.bris.ac.uk22If you want to do this from the terminal, PuTTY comes with a utility called psftp. Alternatively, if you have something like cygwin installed, you probably have access to scp already.
If you get tired of having to enter your password every time you connect to Snowy, don’t worry! You can create an SSH keypair to verify your identity automatically: Snowy has a copy of your public key, and anyone with access to your private key (i.e. only you) can use it to automatically authenticate.
Open a terminal and enter the following:
ssh-keygen -t rsa
The tool will walk you through the process of creating a key. By default, the keypair is saved to the .ssh directory in your home directory - for example /home/myname/.ssh/. The private key is normally called id_rsa, the public key id_rsa.pub - though you can change these if you want. You will be asked to provide a passphrase. This protects your key from viruses, theft etc., so choose something strong.
Once your key is generated, create the .ssh folder on Snowy:
ssh [email protected] 'mkdir -p .ssh'
Then append your public key to the list of authorised keys:
cat ~/.ssh/id_rsa.pub | ssh [email protected] 'cat >> .ssh/authorized_keys'
PuTTY comes with a tool called PuTTYgen for creating new SSH keys. If you have something like cygwin installed, ssh-keygen is probably available in your shell.
You can copy the public key across using FileZilla, as described above.
An example SSH config is given below:
# ~/.ssh/config
Host *
ForwardAgent yes
ForwardX11 yes
ForwardX11Trusted yes
#######################################
# University machines #
#######################################
# University of Bristol machines
# See http://www.bristol.ac.uk/it-services/locations/zones/zonee/cosc/remote-access
Host snowy
Hostname snowy.cs.bris.ac.uk
Port 22
User <USERNAME>
IdentityFile ~/.ssh/id_rsa
ForwardX11 no
ForwardX11Trusted no
# To use only for Cadence tools
Host frosty
Hostname frosty.fen.bris.ac.uk
Port 22
User <USERNAME>
IdentityFile ~/.ssh/id_rsa
ProxyCommand ssh snowy nc %h %p 2> /dev/null
# CS lab machines live on the follow ranges
#
# - 025956--025995
# - 052556--052595
#
# CentOS 6 machines:
#
# - 052569--052572
# - 052579--052582
Host cs-desktop-01
HostName it025980.users.bris.ac.uk
User <USERNAME>
ProxyCommand ssh snowy nc %h %p 2> /dev/null
Host cs-desktop-02
HostName it052573.users.bris.ac.uk
User <USERNAME>
ProxyCommand ssh snowy nc %h %p 2> /dev/null
Host cs-desktop-03
HostName it052574.users.bris.ac.uk
User <USERNAME>
ProxyCommand ssh snowy nc %h %p 2> /dev/null
So you want to write a post for the CSS website? Great! This tutorial will walk you through the process. Basic familiarity with git is assumed.
First, you will need to create a GitHub account. If you have one already, log in.
Now, navigate to the website repository. In the top-right hand corner of the page, you will see a ‘Fork’ button. Click this to create a copy of the repository in your own account.
After a few seconds, you will have your own fork of the repository.
Now, if you’re familiar with git, clone the repository and make your changes. I’ll show you how to make a post without leaving the GitHub website - but the principles are the same whether you clone the repository or use the web interface.
Let’s try writing a new blog post. First, click on the _posts folder to see the existing blog posts on the site. If you click on one, you can read and modify it.
Now let’s add a new post - click the ‘Create new file’ button:
First, name the file. The format of the name should be yyyy-mm-dd-title-of-the-post.markdown, for example 2016-05-21-pining-for-the-fjords.markdown. With the file named, we first need to provide some metadata about the post. The very first thing in the file should be something like this:
---
layout: post
title: "Pining for the fjords"
date: 2016-05-21 21:51:00 +0100
categories:
author: "John Cleese"
---
On the next line, you can start writing your post. If you hadn’t already guessed, posts are written in a very simple formatting language called Markdown. If you haven’t used it before, here’s a tutorial.
If you want to preview your post, you can click the ‘Preview’ tab at the top of the editor. Once you’re happy with the content, it’s time to commit it to your local version of the site (don’t worry, it won’t be published to the live site yet!).
Scroll down, and write a short description for your commit. Choose to commit directly to master. Now click ‘Commit new file’.
You will be taken back to the _posts folder. Notice that there is now a message: ‘This branch is 1 commit ahead of cssbristol:master’. That means we can make a pull request to have our changes merged back into the main site. Click the ‘Pull request’ button to begin the process.
GitHub should choose to do the right thing automatically. At the top, you can see a ‘base’ and ‘head’. The ‘base’ is the repository that you want to merge into (the main CSS website repository), and the ‘head’ is your local copy. Below, in green, you can see you additions.
Click ‘Create pull request’, and write a short description of your changes in the box provided. The clearer the information you provide, the easier it will be for us to merge your changes.
And now you’re done! We’ll see to it as soon as possible.
IT Services hosts a huge range of systems, many of which are well kept secrets! We’ll have a look at some of them in this article.
Every CS student has an account on the departmental server, snowy. Read the snowy tutorial.
IT Services maintain a page with other remote access information, including the addresses of lab machines that you can remote into.
If you’re doing Design Verification (COMS31700), you’ll probably need to use Frosty for remote access to Cadence tools. This machine supports NoMachine, which makes remoting a lot more pleasant.
The university VPN allows you to access university resources (e.g. journals, firewalled internal systems) from anywhere.
You can also remote into a standard university desktop from anywhere. Some commercial software that you cannot install on personal machines is available on remote desktop. IT Services record the status of each piece of software in Topdesk.
Every student has a ‘MyFiles’ filestore, which you can mount on your own device while connected through the university network (i.e. eduroam, VPN, Remote Desktop).
Rewatching (ahem) lectures for revision? Wouldn’t it be nice if you could speed them up? Well, you can - just not with Flash enabled. Append &usehtml5=true to the URL of a Mediasite video and voila: you can speed up playback.
If you’re tired of having to do this manually, then use the HTML5 mediasite userscript to automatically append it (using an extension like TamperMonkey)
While studying, you have access to various university-licensed software. This includes:
If you need help with a computer, phone or software, you can get help from the Student Laptop and Mobile Clinic, which runs in Senate House at 2pm to 5pm, Monday to Friday.
The clinic is staffed largely by current computer science students. Towards the end of the academic year, IT Services advertises for new students to staff the clinic - so keep an eye out!
The university hosts an Atlassian Confluence install, which you can use to create your own wikis.
Password tools - check that your password is working correctly. Sometimes UoB and Google passwords become desynced - you can fix it here.
The university has a couple of pages for finding study spaces. Here’s the main one.
Library staff count the number of people in each library hourly. In the exam periods this year, the university is trialling ‘Find a study desk’, which is based on this data.
Hot tip: there’s a JSON API! Here’s the building information, and here are the study space stats.
There’s also a page for finding a free computer.
Some places that aren’t officially documented. Found an obscure place to work? Open an issue and we’ll add it to this page
If you’ve done or are doing Software Product Engineering, you should have access to the Student Project Lab (‘backlab’), MVB 2.09 (just beyond 2.11). If you need a second monitor, this is the place to go. Third years and above should also have access to the Device Lab, MVB 2.10 (with the curved glass wall).
There is also a ‘quiet pod’ for one or two people on level 2 of the MVB atrium.
In Queen’s, there are a few non-library areas with seating:
The Hack Space in MVB can be used by all students who have done a short induction. Sign up for a Hack Space induction. The equipment available includes a laser cutter, 3D printer, soldering irons and a 3D carving machine. A component vending machine is being installed outside the Hack Space.
The student workshop has equipment including a laser cutter; 3D printers; a lathe and one of these. You’ll need to be trained on some of the equipment first but if you’re planning to take part in BEEES Robot Wars you’re probably going to spend a lot of time in here.
The Bristol Interaction and Graphics group has a lab on level 2 of the MVB Atrium. If you’re taking Interactive Devices, you can use this lab to work on your device.
There are a few common rooms accessible to everyone between 3 and 19 Woodland Road. These houses are joined by a corridor at the back, so you can enter at one end and walk along the whole thing.
Notes: This guide was written using an Ubuntu 16.04 image, therefore it may not work on other systems
sudo apt-get updatesudo apt-get install build-essentialsudo apt-get install gcc-4.9sudo apt-get install g++-4.8sudo rm -f /usr/bin/gccsudo rm -f /usr/bin/g++sudo ln -s /usr/bin/g++-4.8 /usr/bin/g++sudo ln -s /usr/bin/gcc-4.9 /usr/bin/gccsudo apt-get install linux-headers-genericsudo rebootcopy linkwget <your_link> where <your_link> is the link you copied in the previous stepchmod 751 <file_name> so we can run it./<file_name>
q to begin the installationsudo apt-get install nvidia-cuda-toolkitsudo rebootdeviceQuery program located in <sample_dir>/1_Utilities/deviceQueryGit is a way to store, back up and organise your code. It is one of those things that you wish you’d been taught in your first term if you discover it later on.
This tutorial assumes that you are moderately familiar with using a terminal/shell.
The lab machines should have git installed already. On your own machine, type “git” in a terminal and if you’re lucky you’ll get the help text, showing it’s installed. If you need to install it yourself:
sudo apt install git for debian and derivatives like ubuntu and mint. sudo yum install git should work on Fedora.brew install git should do it, or you can download git from the website.When you start on a new project or unit, create an empty folder, go to it in your terminal and type git init. This creates a hidden subfolder .git which is your repository - it will store the entire history of your project and every change you make, as long as you remember to commit these changes (which we’ll do soon). This not only gets you unlimited undo/redo, so you can try things out and undo them if they don’t work, but you can also maintain several different versions of your code and switch between them.
The folder containing the .git folder is your working tree - one particular version of your project.
Let’s say you’ve written some code in a file hello.c:
#include <stdio.h>
int main() {
puts("Hello World!");
return 0;
}
Type git status in your terminal. This will show that there’s an untracked change in file hello.c. If colours are set up correctly, untracked changes are red and tracked ones are green.
To tell git to track this change, run git add hello.c. Run git status again and you’ll see “new file: hello.c”, possibly in green. This means you’ve told git about this change, but it’s not committed yet (not saved in the repository). Run git commit -m 'New file'. Each commit must have a message and the -m <message> option is a way to provide this. The single quotes around the message are to do with how your shell parses arguments - basically if you put single quotes around a commit message then you can use spaces, punctuation etc. and it should work as long as there’s no single quotes in your message itself. Do git status again and you should see “nothing to commit, working tree clean” which is a good message to see.
The simplest way to work with git is this: make changes, commit changes, repeat. Git lets you undo/redo changes at the commit level so it’s helpful to make lots of small commits instead of few large ones; commit messages help you find commits when you want to e.g. revert to a particular commit.
If you make a change to your source file - perhaps add a comma after Hello - you’ll see “modified: hello.c” under a heading “Changes not staged for commit” (in red if colours are working). git add hello.c tracks the change (it now appears under “Changes to be committed” in the status text), git commit -m 'Added a comma' commits it:
$ git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: hello.c
no changes added to commit (use "git add" and/or "git commit -a")
$ git add hello.c
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: hello.c
$ git commit -m 'Added a comma.'
[master 6e7e782] Added a comma.
1 file changed, 1 insertion(+), 1 deletion(-)
$ git status
On branch master
nothing to commit, working tree clean
In summary:
git status shows you whether there are any uncommitted changes in your repos.git add FILE tracks a change, but doesn’t commit it yet.git commit -m 'MESSAGE' commits all tracked changes.If “git status” shows “working tree clean” then all your changes have been saved.
As you might have gathered already from the help text, if you’ve made changes to a file that you’ve not committed yet and you want to undo them back to the last commit, git checkout -- FILENAME reverts the file. There is a space both before and after the -- in that command.
If you’ve committed changes and want to go back to an earlier commit, the first thing you do is git log which shows you a list of all commits. If there are a lot, git log | less lets you view them one page at a time - advance with SPACE, exit with Q. git log --oneline shows just one line per commit and you can stick | less on the end of that too. Each commit has a hash value which is a long hexadecimal string. When referencing a commit, you usually only need to type the first few characters of the hash.
Let’s say I decide I don’t want a comma after “Hello” after all.
$ git log --oneline
6e7e782 Added a comma.
4f251ef New file
$ git checkout 4f25 hello.c`
The command git checkout HASH FILENAME reverts the file to the state in the given commit. The file is now in “changed and not tracked” state as if you’d edited it by hand. You can also git checkout HASH to revert all files back to an older commit.
Let’s compile our file: gcc hello.c -Wall -Werror -std=c99 -o hello. You do use -Wall -Werror on all your C programs to catch possible bugs, right?
We now have two files in the working tree: hello.c and hello (or hello.exe if we’re on windows). However we don’t want to track hello in the repository - you want your sources but not your compiled files in the repository. You can just compile the sources again whenever you need to, after all.
Create a file called .gitignore (yes, it starts with a dot) with one line hello (or hello.exe) in it. Each line in this file is treated as a pattern that matches one or more files (you can do *.exe to exclude all windows executables for example) that git should ignore. Adding the name of a folder to a gitignore file ignores that folder and everything in it. When you do git status again you’ll see that git ignores your executable file, but notices the new file .gitignore. Add that file to the repository and commit.
So far we’ve just saved our project’s history in a subfolder on our own machine. The next step is to save it in the cloud so that several people can work on it together, or you can work on it from different machines (for example, home and lab PC).
There are three big free providers of git services: gitlab, github and bitbucket. Gitlab and bitbucket offer you unlimited (within reason) free private repositories (where you control who can read/write them), github gives you one free private repository (5 if you sign up for their student pack with your university e-mail). All three providers offer unlimited free public repositories for open-source projects.
WARNING: do not under any circumstances place code that you have submitted or intend to submit as assessed coursework to a public repository on any provider. If another student finds this code and submits a copy of it, you are both in trouble for plagiarism. Yes, this has happened in the past.
The next few steps in this tutorial are based on the gitlab UI to create a remote repository, but github and bitbucket offer the same features.
You get to see your project page. The git address of your project is https://gitlab.com/USERNAME/PROJECTNAME.git, so for example my username is david-bristol and I have a project called coconut that lives at https://gitlab.com/david-bristol/coconut.git. If you access this link on the web, it’ll remove the “.git” part at the end but you need it in your terminal.
The command git clone ADDRESS downloads a repository and sets up some information so that you can synchronise the local and remote copies. For example, git clone https://gitlab.com/david-bristol/coconut.git will create a subfolder coconut with the contents of my coconut project. Since this is a public project, the files will just appear - for a private project, git will ask for your username and password first.
You can now use the following two commands to synchronise the local and remote copies:
git pull pulls any changes from the remote copy to the local one.git push pushes your local changes to the remote copy.It is advised to use these commands only when your working tree is clean.
The rough outline of setting up a git project to work together:
The commands git add and git commit add changes from your working tree to the local copy of the repository. The commands git push and git pull move committed changes from the local copy of the repository to the remote copy of the repository and back again. After pushing/pulling, all copies of the repository should be identical.
Your daily coding routine:
git pull to download any changes that your colleagues have made.git push. This uploads your changes to the server.You can save yourself a lot of trouble by only doing push/pull operations with a clean working tree, e.g. you’ve added and committed all changes to the local copy of your repository. In theory, that’s all you need. In practice, what happens if two people edit the same file?
You do not have to agree via e-mail or some other system who is currently editing which files. Git is set up to handle this situation!
What happens is that your git push will fail if someone else has pushed since your last pull. In this case, do a git pull. If you’ve both been editing different files, git will update the ones you haven’t changed with the new versions from the remote copy. Check that everything still works/compiles and then try and push again.
If you’ve both been editing the same files, git will see if there’s an obvious way to combine your changes (for example you’ve both edited different functions in the same file). If so, all is well. If not, you have a conflict. The line CONFLICT ... when you try and pull will alert you to this and tell you which files are affected (so will git status). When you open these files, you’ll see markers as follows in places where there’s a conflict (search for <<< in your text editor to find them):
<<<<<<< HEAD
puts("Hello, world!");
=======
puts("Hi world!");
>>>>>>> 31be48e8e2a86fb71b0b0b61bb08019314d87a1b
This means that you tried to change a line to read puts("Hello, world!"); but someone else changed the same line to puts("Hi world!"); since your last pull. Fix the conflict by choosing what to do with the line(s) in question and then delete the <<< === >>> marker lines and check that everything compiles and works again. Then you can add and commit the file and try to push again.
Conflicts, although annoying, are nothing to be afraid of. They can happen as part of normal git working practice in a team and you deal with them as they happen.
