Staffmail moves

All Professional Services staff and a few other staff within Informatics have already successfully moved from staffmail to Office 365. With the retiral of the staffmail service, IS are now in a position to complete the move of all remaining staffmail accounts to office365.

They will commence the process at the end of this month, continuing into December. The plan is to move non teaching staff first. Academic staff will not be migrated during Semester, unless they so wish. The moves will take place overnight and will be scheduled twice a week (Tuesday and Thursday). This will mean a short period of time without email (from 5pm until around 11 am the following morning) but with ample prior notification, previous users have not found this a major issue. Support will also be available before and after the move to answer questions and help with any issues.

It is expected that Academic accounts will be moved between Semester 1 and Semester 2 but if anyone would prefer to move sooner, then please let me know.

We will schedule account moves over the 12 possible slots and you will receive an email from IS about 2 weeks prior to your date giving a little more information. You will also receive further confirmation from them a few days before the move.

All those who have already expressed an interest in moving as soon as possible will be included in the first batch on 27th October and will receive an email from IS shortly.

There is local documentation on our computing.help pages which will be updated regularly.

There is comprehensive documentation on office365 mail on the IS website.

If you have any questions regarding the move, please feel free to contact me.

Posted in Uncategorized | Leave a comment

Security of shared web services

As the likes of homepages.inf.ed.ac.uk and groups.inf.ed.ac.uk are shared user services, anyone using some sort of authentication/authorisation to restrict access, has to trust the other users of those web services.

A lot of the web’s security model relies on the “same origin policy”.

* https://en.wikipedia.org/wiki/Same-origin_policy

which limits the access scripts have to data (particularly authentication data) served to/from different sites. So if a potential victim is using homepages.inf, but is duped into executing a script from badguy.org, that script would not have access to browser data relating to homepages.inf.

However if the “badguy” script is served by a homepages URL, then it would have access to any other browser data associated with homepages.inf, eg authentication data, as it would be within the “same origin”.

All users of the computing systems are bound by the University’s Computing Regulations

* https://www.ed.ac.uk/information-services/about/policies-and-regulations/computing-regulations

and intercepting and impersonating someone else on a computing system is an offense

* https://www.legislation.gov.uk/ukpga/1990/18/contents

so none of that should be going on our servers, but users of a shared web service, like homepages.inf and groups.inf should be aware of this if they are relying on authentication to limit access to sensitive or important data.

In the future we will probably look at providing equivalent homepages.inf and groups.inf services, where the hostname is unique between users and groups, so each user/group have their own “origin”, but that’s unlikely to happen in the near future.

In the meantime if you are making use of authentication/authorisation on a shared web service and wish to discuss your options, please use the support form

* https://www.inf.ed.ac.uk/systems/support/form/

to contact us.

Neil

Posted in Information | Tagged , | Leave a comment

*.remote.inf.ed.ac.uk change

We’re changing the *.remote.inf.ed.ac.uk Remote Desktop service to remove some of the machines. However, everybody will still be able to use the service as before.

Back in the spring, we made ten machines available for remote desktop sessions under the name UUN.remote.inf.ed.ac.uk where UUN is your University username. (For instance, my username is cc so I can run a remote desktop session on cc.remote.inf.ed.ac.uk.)

The service is still being used, but we can now run it with fewer machines. We’ll go from ten machines to five.

If you use one of the machines we’re keeping (they’re called james17.inf.ed.ac.uk, james18.inf.ed.ac.uk, james19.inf.ed.ac.uk, james20.inf.ed.ac.uk and james21.inf.ed.ac.uk) then nothing will change for you.

If you use one of the machines we’re removing (these machines are james12.inf.ed.ac.uk, james13.inf.ed.ac.uk, james14.inf.ed.ac.uk, james15.inf.ed.ac.uk and james16.inf.ed.ac.uk) then your remote.inf.ed.ac.uk address will now point to one of the remaining machines. We’ll make that change at about 5pm today (Wednesday 15 July). After that you’ll be able to start a new session just as you did before, to the same address – it’ll just be on a different machine from before.

If you’ve left a remote session running on any of james12 to james16, it should still be there, and you can still connect to it up until noon on Friday, when these machines will be taken down for reconfiguration. However, you will have to connect to the machine by its real name, instead of by its remote.inf.ed.ac.uk name. See the remote desktop help pages to learn how to configure your remote desktop client to do this.

If you don’t know the name of the machine which you’ve been using, you can find it out in several ways:

  • For this week only, you can look it up here. Note that that page is only visible from Informatics hosts or those using OpenVPN (and there’s help with OpenVPN if you need it).
  • Just try the machines in turn (james12.inf.ed.ac.uk to james16.inf.ed.ac.uk) until you find the right one.
  • If you’re already logged in to the machine, then at a command prompt (to get one of these, start a terminal window) type hostname then press Return. That should return something like
    james13.inf.ed.ac.uk
    
  • From the command prompt on any other DICE machine, use the host command, and look at the first line of its output. For instance:

    % host cc.remote.inf.ed.ac.uk
    cc.remote.inf.ed.ac.uk is an alias for james17.inf.ed.ac.uk.
    

If you have any problems, please contact User Support using the form.

Posted in Uncategorized | Leave a comment

Update your MacOS AFS client!

Users of AFS on MacOS may be mildly perturbed to find out that the MacOS AFS client has until recently contained a couple of critical bugs which could result in permanent loss of data if triggered. For this reason, we are advising all MacOS AFS users to update to the latest version of the AFS client (currently 0.195) from the Auristor site as soon as possible. Further details on the bugs can also be found there. It’s our experience that the new client can be installed on top of the old one without any issue (but be sure to save your work first just in case).

Craig Strachan.

Posted in Uncategorized | Leave a comment

XRDP service

Prior to lockdown we only had a single “staff” server and a single “student” server but with the need to provide adequate facilities to allow working from home, we had to expand our provision. Based on the work of FreeRDP and rdesktop, xrdp uses the remote desktop protocol to present a GUI to the user. In front of that is a proxy which uses HAProxy to load balance across a cluster of machines. HAProxy is a free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.

Staff can connect using the host ‘uun.remote.inf.ed.ac.uk‘. Which machine you connect to is defined using a CNAME farm which is generated by some scripts and should not change unless, for example, something happens to the remote server. Each server is shared with other people so, as usual, please do not run processes which need a lot of memory or CPU. (For these processes you can use a remote lab computer or a compute server. Students can also access lab machines in AT via a similar mechanism using ‘uun.lab.inf.ed.ac.uk‘.

Further instructions on use can be found at:

http://computing.help.inf.ed.ac.uk/remote-desktop

Posted in Uncategorized | Leave a comment

Development GPUs in lab machines

Just before the shutdown we replaced some lab machines with desktops with lower spec GPUs These are elitedesk 800 g4s with gtx 1060 cards which can be used for development work and for short or small scale processing. Please do not run long jobs on them or your jobs will be killed. Physically the machines are located in 5.05, 6.06 and 9.02 of the Appleton Tower. When we eventually get back to normal you can identify these machines by the login screen. They are currently available for remote access and the full list is at the bottom of this post.

More information about these and other GPU machines can be found on https://computing.help.inf.ed.ac.uk/cluster-computing

currently the following machines are available.

ariane:AT-5.05
epoch:AT-5.05
glenn:AT-9.02
kubrick:AT-9.02
link:AT-5.05
mario:AT-6.06
soyuz:AT-5.05
stronsay:AT-9.02
tarantino:AT-9.02
turpie:AT-5.05
waititi:AT-9.02
wumpus:AT-9.02
yoshi:AT-6.06

Posted in Uncategorized | Leave a comment

Power to self-managed servers in the Informatics Forum

If you don’t use any servers in either of the Forum self-managed server rooms, then please ignore this blog post – and have a nice day!

However, if you do use any such machines, then it is important that you read the following, and fully understand the situation concerning power to those machines.


We are continuing to receive log messages reporting ‘power overload conditions’ from the various rack power bars which provide power to the servers in the two Forum self-managed server rooms IF-B.Z14 and IF-B.01. Under normal circumstances, we would be able to move power connections (or entire servers) around in order to better balance the power load and to sort the problem out but, as things stand under the Covid-19 lockdown, we can’t easily arrange to do that.

So, if a circuit breaker does trip as a result of an overload then, under the present circumstances, it is likely to be quite a while before we can get anybody into the Forum to reset it. And, meanwhile, your machines will be without power – with other users of the room almost certainly being affected as well.

Please therefore think carefully about power usage and, in particular, think carefully about whether it’s a really good idea to be running your power-hungry machine (or machines) flat out at the moment!

Thanks.


Note: In order that you can directly see for yourselves which rack power bars (if any) have recently been reporting ‘power overload’ conditions, we have provided the web page http://netmon.inf.ed.ac.uk/barTrapLogs which gives a processed view of the logging information we’ve recorded from all of our power bars over the previous few days, as well as a count of the total number of ‘overload’ conditions we have recently recorded.

(By the way, that web page is restricted to access from within our network for privacy reasons – so you’ll need to use to use the Informatics VPN service or similar if you want to view it from home.)

At the time of writing (Friday 24th April, 2020), we are still seeing constant power overloads being reported by rack power bar ssm012, which is one of the two power bars supplying power to Rack 6 in self-managed server room IF-B.Z14. That means that power to Rack 6 in IF-B.Z14 should be currently be considered ‘at risk’ until users of machines in that rack take steps to reduce the overall load. You have been warned!

Power-hungry machines in IF-B.Z14 Rack 6 include sigyn, cgserver, cc1 and cc2. It would be very helpful if users of those particular machines would moderate their power use now, in order to reduce the real risk of a complete loss of power.

Posted in Service Update | Tagged , , | Leave a comment

IPv6 addresses

As we prepare to enable IPv6 on the “static self-managed” wires, there are a few aspects to IPv6 addressing which you need to know.

The most obvious difference between IPv4 and IPv6 addresses is that the latter are 128 bits log.  They’re conventionally divided up into eight 16-bit chunks, written in hex and separated by colons.  Leading zeros can be omitted, and the longest consecutive run of all-zero chunks can be elided to “::”.

For global addresses, this 128-bit space is divided up into two 64-bit parts: there’s a 64-bit prefix, which essentially identifies the site and the subnet within it; and there’s a 64-bit “interface identifier” (“IID”) which identifies the host within the subnet.

So, for example 2001:630:3c1:33::1:15 has a prefix of
2001:630:3c1:33::, which itself breaks down to the University’s prefix of 2001:630:3c1:: and the subnet number 33, and an IID of ::1:15.

The prefix is fixed for the subnet, and is generally obtained automatically from the Router Advertisement packets which our switches multicast every few seconds on all of our IPv6-enabled subnets.  The IID is formed in one of three ways:

  1. It can be set explicitly by the host’s manager (in some system-specific way). We can support this, and can enter explicit addresses into the inf.ed.ac.uk domain.  We prefer not to do things this way, though, because it means liaison with machines’ managers, which can take time, and is more prone to errors.  The example above is one of these explicit addresses.
  2. The host can configure itself using StateLess Address AutoConfiguration (“SLAAC”).  This uses the host’s MAC address, transformed in a couple of simple ways, to produce an address which is unique to the machine while requiring no management intervention.  For example, 2001:630:3c1:2:4a0f:cfff:fe5b:e69a is the IPv6 address of one of the student lab machines.  Because we have the MAC addresses registered for all of the machines on the SM164 and SM197 wires we can automatically generate DNS entries in inf.ed.ac.uk, making the entire process completely automatic.  This is the mechanism we prefer.
  3. It can be a “privacy address”, generated periodically by the host in a cryptographically secure way such that it is very unlikely to duplicate any other IID on the subnet.  The reason for this type of address is that it avoids the possibility that a laptop might be tracked across networks as its owner moves from site to site, as would be the case if it were to use a fixed SLAAC-style IID.  For servers it makes little sense to use this type of address, and because it changes frequently we have no way to to add it to our DNS.  The distribution you have installed on your servers may have this turned on if its main audience is laptops and non-enterprise users.  If so, we strongly suggest you turn it off, though how you do so will be system-dependent.

There is one other form of address which your machine will have.  This is a “link-local” address, using fe80:: as its prefix and a SLAAC-style IID part.  Traffic for addresses of this form is never routed off-subnet.  Within the subnet it is just as valid an address as one of the above forms, and can be used anywhere a global address can be used.  It can’t go in the DNS, though, which makes it inconvenient for anything other than low-level network management tasks.  Your IPv6 default router address will probably be link-local, for example.

The address-search box on the netmon front page knows how to handle all of the above forms, though the information available for privacy addresses is necesarily more limited than for the other forms.

The home page for the development project which introduced IPv6 to Informatics has a number of useful links, including to the relevant RFCs.

Posted in Uncategorized | 1 Comment

IPv6 for the Forum static-self-managed subnets

Following the introduction of IPv6 for the Forum self-managed dynamic-address subnet (and the ironing out of a couple of teething problems), we would now like to roll IPv6 out to the two “static-self-managed” subnets (“SM164” and “SM197”).

We propose enabling this on Monday 10th February, at lunch-time.  To do this we will set up the routers for the subnets so that they start sending Router Advertisements, at which point we expect that IPv6-enabled hosts on the subnets will automatically configure “SLAAC” style IPv6 addresses and add the appropriate default routes.

We will then enable the generation of DNS entries to correspond with these addresses, and reconfigure the edge firewalls so that where there are holes opened for ports using IPv4 there will be corresponding holes for those same ports using IPv6.

Your machines will then start to receive IPv6 traffic, so it is important that you ensure that any access controls you have configured are correct.  You should not assume that any defaults will be reasonable!

We do have the ability to add static (non-SLAAC) IPv6 addresses if really necessary, though our experience to date has been that they very rarely are.  We can also turn off the generation of the DNS entries on a per-host basis, with any firewall holes then also disappearing.  Please contact us using the support form in the usual way to discuss this.  We do not have the ability to add “privacy” addresses to the DNS, and in any case it really doesn’t make a lot of sense to do so, so you may also have to adjust your machines’ configurations so as not to try to use these.

Reminder: the documents we produced as part of our original IPv6 investigation project are here.  In particular, there is one discussing IPv6 addressing here.  SLAAC (“StateLess Address AutoConfiguration”) addresses are defined in RFC 4862.

Posted in Uncategorized | Leave a comment

IPv6 for Forum self-managed subnets

It’s now more than three years since we implemented IPv6 for the School’s managed Linux (DICE) desktops and servers, and in that time we have seen very few issues which were specifically related to IPv6.  We were not, unfortunately, able to roll it out to the “self-managed” subnets at that time, for a few reasons, but we now believe it is time to give it a try there too.

So, on Tuesday 19th November we will be enabling IPv6 for the “DHCP” subnet.  (Specifically, we will start sending out Router Advertisements, which will cause any IPv6-aware machine on the subnet to configure itself automatically with at least one IPv6 address.)  If there are significant problems we can easily and quickly back the change out again.  Note that no DNS entries will be added for machines on this subnet.

All being well, we would then propose turning on IPv6 for the self-managed server wires SM164 and SM197 some time in the new year.  There are a couple of reasons for this: it will allow you to gain IPv6 experience with machines on the DHCP subnet in advance; and, more particularly, it will give you time to ensure that any access controls you have in place are correct for IPv6 as well as IPv4.  We’ll post more details nearer the time.

Our IPv6 deployment project’s final report is here, and the project’s home page has links to sundry IPv6 resources.

 

Posted in Uncategorized | Leave a comment