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

SL7 desktop reboots

If you have a DICE SL7 desktop you will be prompted to reboot over the next few days. This is required to make an important configuration change which can only be safely applied at boot time. We understand that reboots can be very inconvenient so you can be assured that we will only ever schedule reboots which we consider to be essential.

Student lab machines are not affected. For office machines 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.

If you have any queries they should be submitted via the Support Form.

Posted in Uncategorized | Leave a comment

SL6 DICE: sleep suspended

Some staff and postgrads who haven’t yet had their DICE desktop upgraded to SL7 have been having trouble logging in at the start of the day, after waking their machine from sleep.

We’ve been gathering evidence on this problem, but so far the cause is not fully understood. We do know that on affected machines the network is not properly operational for a few minutes after waking. Without a functioning network, the DICE login process does not work.

To minimise inconvenience we’ve stopped SL6 DICE computers from automatically falling asleep. We’ll enable sleep again once we’ve understood and fixed the problem – if there are many SL6 DICE desktops left by then!

SL7 DICE desktops continue to sleep as normal.

Posted in Uncategorized | Leave a comment

alpine on DICE

I’ve posted some information about the future of alpine on DICE on my blog. But don’t worry, it’s good news.

Posted in News | Comments Off on alpine on DICE