Git in the School of Informatics

Git is a version control system which has become very popular within Informatics. In fact it has become so popular that we are now offering no less that three different Git related services within the School! At this point, if you are familiar with Git, you may be wondering why we bother since it is trivial for any user to set up a Git repository in their home directory with a couple of simple commands. This is true, and indeed may be all you need if you are the only person using that repository. Setting up a Git repository to be used by others is trickier and it is this need which the School Git services aim to meet.

First up, we have and its close associate, the longest running of the three service and the closest to a “classic” Git service. This supports Git over the git:// and ssh:// protocols. So far, so nothing special but as the second URL suggests, this Git service is run in conjunction with a Gerrit instance. Gerrit is a web based code collaboration tool. Because it is web based, it means that external collaborators can access repositories by creating an iFriend account and, after visiting the gerrit URL (which automatically creates an account for them), register one or more ssh public keys allowing them to contribute to the Gerrit repositorys if they have the necessary permissions. This last condition is necessary because Gerrit provides fine grained control over what access registered users have to a project. Finally, Gerrit provides code review which may be important for some projects. You can find out more about the Git/Gerrit service here.

One issue with Gerrit is that it can be tricking to configure and manage permissions for, and contributions to, a project. In an effort to provide a multi-user Git service which would offer many of the advantages of Gerrit without all the complexities, we have introduced The main feature which makes the git2 service stand out is that the Git repositories are located on AFS file space. When a repository is set up (and another advantage of git2 is that repositories can be set up by users, there is no need to request Computing Support to set up a repository), two AFS groups are set up, one giving read access to the repository and the other write access. The repository owner can therefore control access to the repository by putting users in the appropriate groups. Access is via the file:// protocol (though repositories may also be made readable via the git:// protocol if desired). It will be seen therefore that for a user to be able to access a repository, they must have AFS access. iFriend accounts can be given AFS credentials allowing external collaborators to access repositories though they can do so only through an AFS client. Find out more about this service here.

Finally, we have, a local Gitlab-CE instance and intended as a short term stand in until a mooted college-wide Gitlab service comes along. This is very much a test service at the moment and as such does not feature some aspects which would normally be expected of a DICE service such as integrated sign-in via Cosign. Instead, you must currently create your own account when you first connect to the service and will have to set up a password which is unconnected to any other School or University password (and please don’t reuse an existing password!). Access to the Gitlab Git repositories is currently only available via the http:// protocol. External users can make use of this service but will also need to create an account. As mentioned, this is a test service which will continue to be developed and is subject to withdrawal at very short notice if necessary (for example if there are security concerns). This Gitlab service can be found at

So which Git service should you use? If you absolutely must have code review, then Git/Gerrit is the one to use. If you want a straightforward self-service Git service and all your external collaborators who will need to contribute to the repository have access to an AFS client, then git2 may be a good fit for your needs. And if you would like to try a web based development environment and can live with the possibility that it may disappear at short notice, then why not give Gitlab a try?

Questions and suggestions about how these services might be improved are welcome. Please use the support form to make contact.

Posted in Uncategorized | Leave a comment

Staff SSH server upgrade

We need to upgrade the staff SSH server (brendel) to SL7. We plan to do this at 9am on Tuesday 9th August. We expect the service to be unavailable for most of that morning, we will send out another message when the work has been completed.

During the period of downtime the alternative SSH server – – will be available.

If you have any queries regarding this please use the User Support form.

Posted in Uncategorized | Leave a comment

New certificate

The x509 certificate used to secure communications with changed this morning.

The authenticated SMTP service uses an automatically generated certificated, ultimately signed by the University’s root CA. The service certificates only last a year, and this morning it was automatically replaced with a new certificate.

        Version: 3 (0x2)
        Serial Number: 3811 (0xee3)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=GB, ST=Scotland, O=The University of Edinburgh, OU=Informatics, CN=Automated Server Key CA
            Not Before: Jun 28 02:49:21 2016 GMT
            Not After : Jun 28 02:49:21 2017 GMT
        Subject:, OU=Informatics, O=The University of Edinburgh, L=Edinburgh, ST=Scotland, C=GB

If you have previously had to accept a warning from your mailer indicating that you trust the certificate, you will probably have to do so again for this updated certificate.

Our apologies for not warning you in advance.


Posted in Uncategorized | Leave a comment

SL7 Software Collections

We have recently added support for the Redhat Software Collections (2.1) on SL7 DICE machines. Redhat describes these as:

For certain applications, more recent versions of some software components are often needed in order to use their latest new features. Red Hat Software Collections is a Red Hat offering that provides a set of dynamic programming languages, database servers, and various related packages that are either more recent than their equivalent versions included in the base Red Hat Enterprise Linux system, or are available for this system for the first time.”

By default we have added gcc 5.2.1 from the Developer Toolset (4.0), others are available and can be added on request. Full details of the software collections are available and the details for the Developer Toolset are also available.

Redhat have recently announced Software Collections version 2.2 and Developer Toolset 4.1. Once that becomes available for Scientific Linux we will update DICE.

Information is available for this topic on the Computing Help site. Any questions or requests for additional software should be submitted via the usual support form.

Posted in Uncategorized | Leave a comment to be updated to 4.5.2

Our blog service,, is overdue an update. It is currently running 4.2.7 of WordPress, the current version is 4.5.2.

The plan is to update to 4.5.2 (Coleman release) next Thursday 19th May at 9am.

We’re not expecting any problems, but you can try out a test update of a clone of blog.inf taken on 10/5/2016 at Note that this site is not accessible outside of the Informatics firewall, and any changes you make to it will be lost, on or around the 19th.


Posted in News, Service Update | Tagged , | 1 Comment

Scientific Linux 7.2 Update

The 2nd minor update to ScientificLinux 7 (which is based on RHEL7) is now ready for deployment to the Informatics SL7 DICE office machines. At this point the update will NOT be deployed in the student labs, they will remain on SL7.1 until after exams have finished at the end of May. A minor update like this provides us with the opportunity to update important software and fix any bugs which are not security issues (we apply security updates as soon as they are available) in a controlled manner.

To complete this upgrade a reboot is required. A delayed reboot will be scheduled for all DICE office desktops. The delay will be 5 days, although the reboots are delayed it would be greatly appreciated if people could manually reboot their machines at their earliest convenience; the delayed reboot would then be cancelled. Upgrades for individual servers will be scheduled over the next few weeks and users affected will be contacted as necessary.

SL7.2 was released on February 5th 2016 and since then it has been thoroughly tested in our DICE environment so we are confident that this update will not cause any issues for users.

For many users the most noticeable significant change is likely to be the update to version 3.14 of the Gnome desktop (which is our default desktop environment). In particular, this has altered the location of the “Log Out” menu item, see our page for details.

Full details of the package updates are available on the LCFG wiki. For further, in depth information, there are also release notes from ScientificLinux and Redhat.

If you have any questions or problems with the upgrade please contact our User Support team through the support form.

Posted in Uncategorized | Leave a comment

Informatics Network “Requirements”

As input to a review which Information Services are conducting into EdLAN, the network which ties the University together, I have written a document which describes the Informatics network and the various “requirements” that guide its design and management.

Please feel free to read it!  I hope you don’t find the style too offputting; it was written for a specific purpose, and as a result is a bit dense in places.  If you prefer, just skip to the descriptive appendix, which starts about half way through. I’m happy to answer questions you might have, whether through the support form, inf-general or indeed in person.

The “requirements” document itself is here, and you might also find the following pages helpful:

Many thanks to the members of the Computing team who commented on previous drafts.

Posted in Uncategorized | Leave a comment

College Encryption policy – what we are doing to implement.

Most of you should now be aware that the College recently introduced a policy requiring the encryption of mobile devices and desktops, particularly where these are likely to be used for handling sensitive data.

Sensitive data can include :-

  • email from students to personal tutors or from staff to their line managers about their health
  • PDR documents
  • student assessment
  • NDA, contracts, procurement bids/quotes
  • exam scripts

Briefly – you are required to secure all devices (e.g. mobile phone, laptop) however owned, if you use these for work, or have work access credentials stored on them.

As the first stage of implementing this policy, the computing staff are :-

  • providing guidance at
  • arranging a clinic, with Information Services, in March
  • enabling encryption, before handover, of new
    • Apple and Android tablets
    • Apple Macs
  • enabling encryption of admin staff Windows PCs
  • working towards encryption for DICE desktops

If you self manage a university owned desktop or laptop, it is your responsibility to ensure that you adhere to the College policy.

Posted in Uncategorized | Leave a comment

IPv6 update

IPv6 update…

Since my previous post announcing the start of the IPv6 investigation project, good progress has been made:

  • IPv6 support has been tested on the variety of network switches that we run.  As expected, it’s generally good on our newer models, but unreliable or non-existent on our older models.  Our ongoing rolling replacement of older switches should address this over time.
  • Where supported, appropriate IPv6 configurations have been applied to the switches at all our sites.
  • IPv6 routing has been tested locally on our core switch/routers and our Linux edge routers, and functions as expected.  The next step will be to liaise with IS to enable global routing, so that we can test worldwide IPv6 connectivity.
  • Our edge firewall-rule generators are now IPv6 aware.

Once we have global connectivity working in our test setup, we will start to roll out IPv6 to our managed DICE machines. This will be done gradually, to minimise the effect on our existing IPv4 deployment. As soon as our servers start to advertise IPv6 addresses, the rest of the world will expect them to Just Work, and indeed may start to prefer them over IPv4 addresses.

IPv6 for self-managed machines is, unfortunately, still some way off.  It’s dependent on the replacement of our remaining old Forum switches (likely to be F/Y 2016-17), a follow-on project to add IPv6 support to our DHCP infrastructure, and the extension of our network auding tools to handle IPv6.

Posted in Uncategorized | Leave a comment

Informatics and the CSE Data Security Plan

As you were reading Johanna’s email last month on the encryption of personal computing devices, you may have noticed that this advice is but one part of a College of Science and Engineering action plan on data security (this plan was included in Johanna’s message). There are several actions which Schools are required to perform as part of this plan. Johanna’s email, and the accompanying documentation to be found on is intended as the response to one of these actions, pointing out to School members the importance of the security of data and devices.

Another substantial requirement the plan places on Schools is to ‘produce initial registers of datasets, websites, servers and services, their primary locations and ownership, highlighting the most sensitive or vulnerable for special attention’ . To tackle this requirement, the College Computing Professionals Advisory Group (CCPAG) set up a sub-group, of which I am a member, to establish how best to create and populate this register and then establish the sensitivity of the data it contains. After much debate, this group has now come to the conclusion that there are two types of objects this register needs to track, datasets and services.

Datasets are the actual collections of related data, examples of which might be files on disks, text written on a piece of paper or entries in a database. Services are the ways in which this data is accessed, for instance a filesystem, a locked filing cabinet or a database front end. Datasets have characteristics relating to the type of data they contain, and services have characteristics relating to how access to the data is controlled. For example, a dataset might contain anonymised details of the eye colour of 10 people (this would not be considered to be terribly sensitive data) or it might contain the medical records of 10000 identifiable people (this would be very sensitive). Equally, a dataset might be accessed via an unauthenticated web form available world wide or it might only be accessible on a single machine, not attached to a network, kept in a locked room, and accessed via a hardware security device such as a fingerprint scanner. Obviously, if the medical records were accessible via the unauthenticated web site, this would be highlighted in the register as being very high risk and flagged for attention. If on the other hand, the eye colour database was accessible via the website, this might not be regarded as a cause for alarm since although the website is an insecure access method, the dataset itself does not contain terribly sensitive data. To look at the opposite example, if the medical records dataset was only accessible via the machine in the locked room, although the dataset itself is highly sensitive, the overall risk might still be assessed as being acceptable since access to the dataset was so tightly controlled.

Since datasets and services may have a many to many relationship (datasets may be accessed in more than one way and services may make use of more than one dataset), overall risk can only be assessed for a particular dataset/service combination. When datasets and services are added to the register, they are matched against a set of criteria establishing just how sensitive the data is (for datasets) and how secure access is (for services). These factors are then combined to assess the overall risk factor for each dataset/service combination. Examples of the criteria being using to establish whether a dataset contains medium or high risk data can be found in this document. Service characteristics include

• whether the service or data is hosted on a fully supported server or file store
• what the filestore is (eg. datastore, dropbox, AFS, an un‐supported device, etc …)
• what authentication to the service is used
• whether role‐based access controls to parts of the service are in place and managed appropriately
• what the total (approximate) number of users of the service is
• what the number of administrators with access to all data within the service is
• the ease with which bulk export access is enabled by the service
• whether there are any users external to the university, and what limits on access do they have
• likely end‐user patterns of usage, especially in respect of exports

As well as identifying the difference between a dataset and a service, the sub-group also identified two different classes of datasets and services. Datasets and services managed, maintained and curated by members of the administration and computing staff are class A. Computing and administration staff have been working together to identify class A datasets and services held by the School and this process is well advanced.

Datasets and services managed, maintained and curated by academic and research staff are defined as class B. Many more examples of these datasets and services exist so gathering and evaluating this data will be a considerable task, one which we hope to begin in Informatics soon after the start of the new year. Further information about how this is to be done will be circulated closer to the time. In the meantime, it would be very helpful if each and every one of you could start thinking about what data you own and which services you are responsible for now so that you have the information to hand when the time comes.

Posted in Uncategorized | Leave a comment