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 student2.compute.inf.ed.ac.uk.
Students can login to it like this:

ssh student2.compute.inf.ed.ac.uk

We’ve done this because in recent days the student compute server (student.compute.inf.ed.ac.uk) 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:

ssh student2.compute.inf.ed.ac.uk
Posted in Uncategorized | Leave a comment

Changes to the SSH service

The way in which SSH login services are provided for the School of Informatics will soon be changing.

Continue reading

Posted in Uncategorized | Leave a comment

Virtual DICE for 2021-22

The 2021-22 version of Virtual DICE is now available.

Virtual DICE is like the School of Informatics’ DICE Linux environment, except that you can run it on your own computer in a virtual machine.

If your computer can run VirtualBox, and has an Intel architecture, then Virtual DICE should run on it.

We’ve just released the latest version of Virtual DICE, and it’s free for you to download and install. You can read all about it on the Virtual DICE help pages.

It comes in two editions. If you want to use Virtual DICE for coursework, you should choose the teaching edition. To learn more, see the Virtual DICE help pages.

Posted in Uncategorized | Leave a comment

Access to ifile.inf.ed.ac.uk restricted

Access to the ifile.inf.ed.ac.uk service has been restricted to the University (and therefor also the Informatics) networks.

Previously you could directly access ifile.inf.ed.ac.uk from anywhere, but now if you are at home, for example, you will first need to connect to the University or Informatics VPN service to make your device look like it is within the University network.

We have had to do this because the software that provides the ifile service is no longer maintained, and relies on an out of date web framework. With the increasing concern about the vulnerability of old, out of date software, which are often used as attack routes by hackers, this restriction will remove the ability for the bad guys on the outside to keep picking and prodding away trying to gain access.

Admittedly this restriction somewhat reduces the usefulness of the ifile service. If we do find a current, maintained equivalent software package, then we can look at upgrading ifile and removing this restriction.

Remember that if you have an ssh access to an Informatics machine, you could use scp/sftp to access the AFS file system.

Neil
Services Unit

Posted in Information, Service Update | Leave a comment

Login Problems

Are you having problems logging in?

Use your username

When you login to a DICE Linux computer, use your DICE username.
That username is the same as your University Username (“UUN” for short). For students it’s the letter “s” followed by your matriculation number.

For example, if your username is s2345678 then you type this to login: s2345678

Do not type: UUN

Do not type: [s2345678]

Do not type: 2345678

Do not type: [2345678]

Do not type: [UUN]

Do not type: dice-username

Do not type: [dice-username]

Do not type: ed\\s2345678

Every year, people try to login with these wrong usernames.

Beware of Spaces

When you’re in front of a computer, and you want to log in to it, do not press the space bar to wake it up. Pressing the space bar types a space character – and your username does not begin with a space character, so your login will fail.

If you must press a key, press some other key – for instance the Control key or the Shift key.

Before you login, press the Delete key a few times, to remove spaces which somebody else might have typed. You can’t see spaces in the login box, but if they are there, they will make your login fail.

This blog post is also available as a page on computing.help.

Posted in Uncategorized | Leave a comment

IPv6 and self-managed servers

We’ve had IPv6 enabled on the “self-managed server” subnets (164 and 197) for quite a while now, and mostly it has been trouble-free.  Recently, however, we’ve had reports of login slowness to some self-managed servers following a system upgrade.

What we expect to happen is that your machine will automatically set its IPv6 address based on its ether MAC address, together with the prefix that our routers multicast every few seconds (a “SLAAC address”).  We have that MAC address registered in our host-configuration system, so we can create DNS forward and reverse entries using it, with the result that you can refer to your machine by name and the IPv4 or IPv6 address will be used as appropriate.  What seems to have happened is that these upgrades have somehow enabled IPv6 “privacy” addresses instead.

Privacy addresses are a good idea for a laptop which is roaming, as they mean that you can’t be tracked based on the fixed (“IID”) part of your IPv6 address.  However, they make little sense for a server, which is not expected to move around, but is expected to be contactable by its clients.  Ideally you would fix your login slowness by turning these privacy addresses off again, but unfortunately we haven’t yet got a relable set of instructions for doing so.

As a workaround while we find out how to turn off privacy addresses cleanly, what we propose is this: we will leave IPv6 enabled on the subnets, as we know there has been a demand for it; and we will change our DNS configuration so that we generate reverse entries for the IPv6 addresses we expect you to have, but we will stop generating the forward entries by default, so that when a client asks for your machine’s address it won’t be told the IPv6 one that isn’t working in quite a few cases.

On request (send in a support ticket in the usual way) we can easily re-enable those forward entries on a per-host basis, so if you want your machine to be contactable by its clients using IPv6 then that’s no problem.  On the other hand, if you don’t want it to be, or you don’t mind either way, then you don’t need to do anything.

We propose making this change on Monday (27th) at lunch time.  Once we do have a reliable set of instructions we’ll let you know and revert to the current setup.

Posted in Uncategorized | Leave a comment

Printing changes reminder

Back in November 2020 we announced a change to the cloud printing service at Informatics. Unsurprisingly this was probably of little interest to most people as they worked from home during lockdown. Now that people are returning to the Informatics buildings, this is a quick reminder of what happened.

We are still using the University’s “cloud” based printing service, but it is now called EdPrint. The idea is the same, you send your print jobs to a virtual printer (EdPrint or EdPrintPull), but it doesn’t actually print out until you visit any EdPrint configured printer, tap/swipe your staff or student card on the reader by the printer, at which point you can “release” the print jobs you sent previously to be printed at this printer.

Similarly, if you want to scan or copy things at the printer, you need to first swipe in to access those functions.

Not all physical printers have the same capabilities, not all printers are colour, and some support A3 size paper, others are only A4.

The EdPrint system will determine if your print job is colour or mono, and you will be charged appropriately if using a colour printer. At the point you release your colour jobs on a colour printer, you can choose to print in greyscale to save toner and money.

Printing from devices

University managed Windows PCs and DICE linux machines are already configured with “EdPrintPull” and “edprint” respectively. If you are using a self-managed Mac, Windows PC, Linux, or mobile device, then the Information Services (IS) web pages have information on how to install and use EdPrint on those:

which they tend to refer to as “MobilityPrint”.

Our own computing.help.inf.ed.ac.uk/printing pages contain links to these IS pages.

Further Changes

Also mentioned in July’s Newsletter and this blog post, we are also removing the less used printers, to be redeployed elsewhere in the University. Ultimately this will mean the mono A4 printers some of which have already gone, and others will do so over time.

Neil

Posted in Information, Service Update | Leave a comment

How to avoid the remote.inf.ed.ac.uk downtime

Updated (26/08/21): this work is complete.

This is about downtime for the remote desktop service, and how you can carry on using the service while your usual server is not available.

What’s remote.inf.ed.ac.uk?

The remote desktop service gives you a remote DICE graphical session when you connect to username.remote.inf.ed.ac.uk, where username stands for your own DICE username. (For a more detailed reminder, see the remote desktop help pages.)

It’s provided by several servers, and those servers now need to be updated to keep them secure and working well. While we’re updating a server, it will not be possible to use it; and the updates may take a whole day.

When?

  • cittern, dulcimer and lute will be down on Monday 23 August.
  • cittern, guitar, theorbo and zither will be down on Thursday 26 August.

Which server do I normally use?

At a DICE command prompt, type the command: host username.remote
where username is your own DICE username. The first line of the output has the name of your usual remote desktop server. For example:
cc.remote.inf.ed.ac.uk is an alias for lute.inf.ed.ac.uk.
To get a DICE command prompt, open a terminal window.

How to avoid the downtime

On the day your usual server will be down, use the address temp.xrdp.inf.ed.ac.uk instead.
If you’ve forgotten how to configure your remote desktop software for a new host, see the remote desktop help pages.
After that day, please go back to using your usual host, because temp.xrdp.inf.ed.ac.uk is only temporary.

Comments and questions

If you have any, please send them in using the computing support form. Thanks!

Posted in Uncategorized | Leave a comment

Printer Changes in Informatics

During the recent lockdowns, new working practices have developed which place far less reliance on the printing out of materials. Recognising this, and wishing to reduce the financial and environmental impact of printing across its estate, the University has adopted a policy on sustainable printing, the implementation of which will see printers with low levels of usage in their existing locations being redeployed to areas where new printing requirements have been identified. This is being done in preference to procuring new devices for these areas.

In Informatics, the printers identified as suitable for redeployment are the small mono A4 devices located in the SW corner of each floor of the Forum and the labs on level 3 and 5 of Appleton Tower, hardly surprising since usage levels of all of these devices have been consistently low, even before lockdown. One of the Forum printers has already been moved to the Wilkie Building to accommodate Informatics students who have relocated there, and a second was recently moved to another part of the University. It’s not possible at present to say when the other devices will be removed since this will depend on when new locations are identified for them. Note that the A3 colour printers will still be available on all floors of the Forum, and that the colour printers on levels 4, 6 and 9 of Appleton tower will also remain.

Craig.

Posted in Service Update | Leave a comment