Network changes for self-managed machines

As you’ll all be aware, the University is tightening up on network security in response to outside threats.    Within Informatics we have also been looking at ways to improve our security, and one area we have identified is that of self-managed machines in offices.

For many years we have provided network ports in offices and other “closed” areas, configured so that any machine connected to them is given an IP address, without the need to register in advance.  (We can do this because our network monitoring tools provide an audit trail linking the machine’s address with the port where it has been used.)  As well as allowing access to the rest of the University and beyond, this has given mostly-unrestricted access to internal Informatics resources.  It is this latter feature which is now under review.

Since we do not know how the machines using these ephemeral connections are configured and maintained, it has been concluded that it is now unacceptably risky to allow this unrestricted access to continue.  On a date to be announced, therefore, the configuration of the Informatics firewall will be changed so that these machines move from our “inner ring” to our “outer ring”.  They will still be protected against threats from outside Informatics, but our core systems will be protected against potential threats from them.

The effect you will see on one of these self-managed machines will be as follows:

  • You will still receive a dynamically-allocated address for your machine.
  • You will have the same access to the rest of the University and beyond as you do now.
  • However, you will only have access to internal Informatics resources if they have explicit firewall arrangements in place to allow this access, or you connect through one of our login servers or use OpenVPN.  This is essentially the same level of access that you would have if you were using the University’s wireless service.

If you have any access pattern which you think might be affected by this change, please submit a support request.  We can then look at it and then either make a firewall change or advise on alternative access methods.


Posted in Uncategorized | Leave a comment

Informatics-EdLAN connectivity

As you’ll be aware by now, EdLAN is changing, though rather more slowly than was originally anticipated for various reasons, and the way that Informatics connects to it has to change too.

Under the old EdLAN, the Informatics network in the central area (Forum, Appleton Tower, Bayes and Wilkie) had a 10Gbps connection to the EdLAN AT router, which carried our “bridged” traffic and most of our “routed” traffic to and from the rest of the University and beyond, and a 1Gbps connection to the EdLAN Old College router, which carried the rest of the “routed” traffic and acted as a hot-spare for the “bridged” traffic.

Under the new EdLAN we now have a 20Gbps connection to the Appeton Tower distribution router carrying “routed” traffic for AT and Wilkie, a separate 20Gbps connection to the AT distribution router which currently carries all of our “bridged” traffic, and a 20Gbps connection to the Forum distribution router which carries our Forum and Bayes “routed” traffic.  There is also a separate 20Gbps connection to the Forum distribution router, intended for “bridged” traffic which is currently mostly idle.

What we now need to do is to transfer the “bridged” traffic originating in the Forum and Bayes, which currently traverses our internal network before making use of our AT connection, so that it uses the Forum “bridged” connection instead.  There are a couple of reasons for this.  The first is that it will make the Forum/Bayes part of our network more independent of the Appleton Tower part of our network, as well as balancing the load across the various links better.

The second reason is that as EdLAN develops, and in particular as the edge roll-out takes place, anticipated to begin later this year, a fast direct path between our Forum core and the EdLAN Forum distribution router for “bridged” traffic will be a necessary part of that transition.

Making the change can’t be done completely transparently, though.  In order to avoid creating forwarding loops, which at 20Gbps would completely break the rest of our network, we need to reconfigure the traffic which is carried on our internal links first before bringing up the new “bridged” connection.  This will cause a break of a few seconds to the Forum traffic which currently transits through Appleton Tower, and in particular wireless and phones.  Only once that has been done will it be safe to patch in the new connection and bring it into service.

We’ll monitor the network after the change, of course, and our configuration system has had some additional constraints added which should mean that loops can’t be set up by accident in future.

Posted in Uncategorized | Leave a comment

All users of the University VPN must reset their password

The Chief Information Security Officer for the University announced on Monday 21st March that all users of the University VPN service MUST reset their password. Users of the Informatics OpenVPN service are not affected. Note that, as this is a centrally provided service, any queries or support requests must be directed to Information Services. Here are the full details of the announcement message:
Continue reading

Posted in Uncategorized | Leave a comment

Be aware of phishing

Following Russia’s attack on Ukraine, the National Cyber Security Centre (NCSC) is calling on all UK organisations to increase their vigilance for cyber attacks.

It is clear that various groups are now using this crisis as an opportunity to launch new phishing email attacks. For example, there are scams asking people to "Help Ukraine" and other scams are based on fake reports of "unusual sign-on activity"

You must always be very wary of any email which wants you to enter personal details or transfer money. The NCSC provides guidance on how to spot scam emails.

If you are unsure of the safety of any emails you receive please contact the Informatics Computing Team via the support form linked from our help site.

Posted in Uncategorized | Leave a comment

Network switch reboots

It’s time for us to arrange to reboot most of our network switches again.  We need to do this for a couple of reasons.

The first is that the clocks that they use for management and reporting purposes tick in centiseconds.  That means that they wrap at just under 497 days of uptime, which in particular results in error log messages being jumbled.

The second reason is to apply firmware updates.  We apply important updates as soon as we can, of course, but this “yearly” reboot allows us to remain using a (reasonably) current version, which can be important when talking to the manufacturer or swapping individual components.

We had hoped that we could take advantage of the forthcoming electrical work in the Forum and Bayes to do these reboots for us, but unfortunately the likely timing of this now means that we can’t wait so we’ll have to schedule reboots sooner.  For Appleton Tower we usually reboot each floor’s switches first thing in the morning over a couple of days, avoiding major deadlines.

We also have six core switches, for which we always schedule reboots in advance.  These are normally done over a series of lunch-times, as the manufacturer advises that physical intervention may be required in a small number of cases.

Posted in Uncategorized | Leave a comment

Changes to University DMARC record

To make it harder for spammers and scammers to forge email claiming to originate from the domain, the University will shortly be changing the DMARC sub-domain policy (sp argument) to “reject”.

This change will tell any mail services that use DMARC and SPF  tests when validating email, that any email that fails the SPF test for any *, that it is recommended that the mail be rejected.

This, if we did nothing, could affect mail being sent as from addresses. However we have a DMARC record for which currently sets our policy as “none”, which will take precedence over the’s sp=reject.

Users are unlikely to notice any change (other than hopefully a reduction in forged email claiming to come from a legacy domain like

However if you are sending mail as coming From: an address that is not or, then mail relays may start flagging your mail as suspicious, and marking it as spam.

Similarly if you are sending mail as From: or but not using the Informatics or University relays as your outgoing SMTP server, then again other relays may see your mail as suspicious and flag it as spam.


Update 7/2/2022 – Currently this proposed change has been postponed, but will happen at some point in the future

Posted in Information, Service Update | 1 Comment

Wireless Access Point Replacement

As part of the EdLAN replacement project, contractors are working their way round all of the University’s buildings to swap out the wireless access points for new ones.  The Bayes building has already been done (on Tuesday 18th January), and the Informatics Forum is the next one where we’ll see this happen.  This is scheduled for Monday 31st January.  (Appleton Tower isn’t scheduled yet.)

On the day there will be a couple of teams working their way around the building.  They’ll swap one access point at a time, and then test it before moving on to the next one.  While they’re near you you may notice your wireless connectivity becoming a little less reliable than usual, but this should recover as each new AP comes on-line.  Our own techs will be on hand to assist them with access to restricted areas of the building.

Please note: this is a one-for-one replacement, and APs are not being relocated or additional ones added at this time.  We know there are some areas of the building where wireless coverage is less than ideal, and we expect that a subsequent phase of the project will resurvey the building and move or add APs to improve things.

IS are now publishing a “progress page“, where you can find more details on the EdLAN roll-out.

Posted in Uncategorized | Leave a comment

New student compute servers

Sometimes you need to run software which needs a lot of oomph behind it, and which can take days to run. It’s a bit impractical to run that sort of thing on a normal desktop – which is why Informatics has compute servers.

Until recently there was one for staff (called and one for students (called Postgraduate research students were able to use both of these.

However, we noticed that both machines were being heavily loaded with postgrad research student jobs, so we’ve provided several more compute servers. These ones are especially for the use of postgrad research students.

If you’re a postgrad research student, you can login to a new compute server like this:


… where yourusername is your DICE username, for example s1234567:


Edit: That command will work if you’re logging in from a DICE machine, but if you’re logging in from your own machine, you’ll also need to specify your DICE username, like this:

ssh -l yourusername

… where yourusername is your DICE username.

There are several of these new servers. Please use only the one which your address takes you to, to be fair to your fellow students.

Now that the postgrad research students have their own compute servers, is reserved for taught students (undergraduate and MSc).

There’s a help page about compute servers at:

Posted in Uncategorized | Leave a comment

log4shell security vulnerability

By now most people are probably aware of the recent discovery of multiple critical security issues in the Java log4j logging library (version 2) which have been named “log4shell“. In some circumstances, these flaws can give attackers the ability to remotely execute their code on our systems. An overview can be found on Wikipedia.

Since the issue was first announced, just over a week ago, computing staff within the School and our colleagues in IS have been working very hard to ensure that this issue does not lead to our computing infrastructure being compromised. We have scanned all externally accessible websites to look for evidence of exploitable systems. We have also scanned all home directories, group space, and local system disks for vulnerable log4j library versions. We are now in the process of contacting all those who own files that contain insecure versions of log4j. If you are contacted you must resolve the issue as soon as possible. We are happy to advise or help if you are not sure of the best course of action to take.

We are also aware of security issues in the old unsupported 1.2 series of the log4j library. Those issues are not currently considered to be as critical so we are currently focussing our efforts on version 2. In the New Year, we will begin contacting people with software that uses 1.2

The log4j library is bundled with many other Java libraries and software so it’s not always obvious that you have it installed. Software distributors are in the process of providing updates, you must apply them as soon as they become available. Most Linux distributors have already updated the version they provide. If you bundle the code with your own projects you can download the latest version from the project website.

If you have any questions about this issue or need help with fixing log4j please contact us via our Support Form.

Posted in Uncategorized | Leave a comment

A second student compute server

We’ve added a second student compute server, and it’s called
Students can login to it like this:


We’ve done this because in recent days the student compute server ( has been unresponsive at times, because it’s been used so enthusiastically.
There’s a range of things we could do to help, and we’re still looking at other options, but for the time being we’ve introduced the second compute server.
Once again – to login, type:

Posted in Uncategorized | Leave a comment