## ScientificLinux 7.3 upgrade

The 3rd minor update to ScientificLinux 7 (which is based on RHEL7) is now ready for deployment to the Informatics SL7 DICE office and student lab machines. 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. Lab machines will reboot overnight Wednesday/Thursday, for office desktops a delayed reboot will be scheduled. 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.3 was released on January 25th 2017 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.

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 using the support form.

## SSH Server Reboot

We need to reboot the general access SSH server (bruegel) to upgrade it to Scientific Linux 7.3. This is just a minor upgrade from SL7.2 to SL7.3 which will have very few user-visible changes. We plan to do this at 8am on Friday 9th June. We do not expect the service to be unavailable for more than about 15 minutes but it should be considered at risk until 9am.

During the period of downtime the alternative SSH server – staff.ssh.inf.ed.ac.uk – will be available for those with access
rights.

## Staff SSH server reboot

We need to reboot the staff SSH server (brendel) to upgrade it to Scientific Linux 7.3. This is just a minor upgrade from SL7.2 to SL7.3 which will have very few user-visible changes. We plan to do this at 8am on Friday 2nd June (tomorrow). We do not expect the service to be unavailable for more than about 15 minutes but it should be considered “at risk” until 9am.

During the period of downtime the alternative SSH server – ssh.inf.ed.ac.uk – will be available.

## mailman anti-spam filters

There has been a recent spate of spammers forging list member or list admin emails, and thus are able to post directly to the corresponding targeted list (as typically list members are always allowed to post to the list they are members of).

All external email passing through the University’s mail servers are given a spam rating, and headers added to the email with its spam score. eg.

X-Spam-Score: 5 X-Spam-Level: ***** X-Spam-Status: hits=5.502 tests=HEADER_FROM_DIFFERENT_DOMAINS, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,LOCAL_ACCTPHISH1l3,RP_MATCHES_RCVD,SYSADMIN version=3.4.0

A score of 4 or above is likely to be spam. The higher the number, the more likely it is to be spam. Though as the classification is an automated process, there can be false positives.

We can use mailman’s spam filter to match on any header, but in the above example the X-Spam-Score is the simplest to use.

We’ve recently added the following filters to all mailman lists that are not already filtering the mail based on the spam score.

Example of mailman spam filter page, highlighting the options you may want to change.

If your list was called “test”, then the URL for this page would be http://lists.inf.ed.ac.uk/mailman/admin/test/privacy/spam

What the two rules do is to hold for moderation any messages (regardless of who sent them) if the spam score for the message is 4 or greater (9 being the highest score). Note that the matching is actually a regular expression.

The reason they are split into two rules, is to show that you could choose to automatically discard posts with higher scores. So for example the current “[89]” rule could be changed to “Discard” (remember to press the “Submit Your Changes” button at the bottom of the page). From then on, any posts sent to the list with a spam score of 8 or 9 will silently disappear. Note there is no notification this has happened, and you cannot recover any information about what has been automatically deleted. So you should only do this if you are happy with those facts.

One last point, the “Defer” option on the filter page, actually means “disable this rule”, not “defer any matching post”.

If you want help changing any of these settings, submit a support ticket in the usual manner.

Neil

## New SSH server

On Monday 3rd April we will replace the SSH server named schiff which hosts ssh.inf.ed.ac.uk and student.ssh.inf.ed.ac.uk with a machine named bruegel.

All that will happen is that at about 08:00 on Monday we will change the DNS aliases to point to the new machine. This change can take some time to propagate so we will not switch off access to schiff immediately. It will be left running as normal until 12:00 Friday 7th April. This should also allow sufficient time for users logged in to finish their existing sessions and move to the new server.

The IP address for the service will change from 129.215.202.57 to 129.215.202.74, your SSH client may warn you about this change and request verification. For reference the new host key fingerprints are:

RSA     - e9:ca:09:89:a9:42:96:c2:08:4c:8a:1f:1b:34:ee:0c
ECDSA   - d7:5b:79:84:49:94:fb:e5:9a:c7:a3:29:83:65:e4:f8
ED25519 - f4:0e:ba:42:a5:e4:10:99:ba:67:05:e7:44:5f:9f:c2


More information regarding the SSH service can be found on our help pages. If you encounter any problems accessing the SSH service please contact us via the Support Form.

## Video Conferencing – Moving Forward

We recently polled staff and research students in the School on some approaches and suggested technologies for moving forward with better and more integrated support for Video Conferencing in the School: https://wiki.inf.ed.ac.uk/DICE/VideoConferencing. That page has now been updated with a summary of all the comments received.

The proposal now is that meeting room 5.02 in the Forum will be kitted out with generic hardware (dual monitors, camera, audio system with remote microphone pod and a computer) and made available for anyone to use. We will make at least Zoom available, and one or maybe two other systems, in this room and on School desktops. Everyone can then try these out for a while, alongside the existing Lifesize facility in 4.02.

## Informatics to host a sponsored RIPE atlas anchor

Informatics has been selected to host one of the first five sponsored RIPE atlas anchors!  The other four sites are in Macedonia, France, Romania and Albania.

The RIPE atlas system consists of several thousand network “probes” dotted around the world.  These perform a variety of standard and user-instigated measurements of hosts and services on the Internet, for research and post hoc investigations.  Informatics has hosted one of these probes for a couple of years now.  Anchors are essentially larger and more capable probes, located at sites with good stable connectivity, which can be used as the target for other probes’ queries.

As a result of hosting these systems we earn “credits” which can be use to “pay for” our own measurements.  We have spare credits, and should have many more as a result of hosting the anchor probe.  If you think it would be useful for your own work to make use of the atlas system’s capabilities, please get in touch and we’ll see what we can set up.

And, of course, it’s also good publicity for Informatics across the network operations community, and it’s a way for us to do our bit in a small way towards the smooth running of the Internet at large.

## NAS Appliances in the School of Informatics

Over the last couple of years, we have noticed that more and more of you are buying NAS appliances, boxes containing a number of commodity disks which can be attached to the network and serve that disk space to other machines on the network. This was a cause of concern to the computing staff because these appliances can raise issues of security and reliability and so in an effort to see if these boxes were meeting a need which might be equally well met by a commodity computing provision, I talked to those of you who had purchased this kind of kit in the last couple of years (and a big thanks to all those who took the time to respond to my request for information).

As expected, the biggest attraction of these devices was that they (with one or two caveats) offered substantially cheaper storage than anything offered by the School or the central University. Also attractive was the fact that people had more control over their storage, allowing them to reconfigure it as necessary, and that units could be bought with more disk slots than were required at first allowing for low cost expansion as needs dictated. These are features which would be difficult for the School to match at the moment and so it does seem that the purchase of this kind of equipment may be justified in some cases.

As mentioned above however, there are some real security and reliability concerns over these devices and so to help people decide whether a NAS appliance may be a good fit for their needs, we have created a page detailing some points to consider when contemplating purchasing one of these devices. We would encourage anyone thinking about using a NAS box to read this page and, if they require further advice, contact the computing staff in the usual way.

## User Account Creation and Expiration

Informatics is one of the few schools that maintains its own separately authenticated local user accounts (DICE) rather than using EASE/AD centrally managed accounts. Our accounts are automatically created and expired based on data we receive from the centre. However this is a much more complex process than at first might seem.

We need to pull data from a number of central sources to determine whether a local Informatics account should be generated for a user:

• EUCLID (Edinburgh University Complete Lifecycle Integrated Development) is used to provide data on which students are on our programmes, or on other School’s programmes but taking some of our courses, and we use this to create the set of “current” students that need an account. When the programme registration ends for whatever reason (hopefully the result of an award) or the course ends (effective at the end of a session) or status indicates withdrawal then the local account will enter expiry. There are plenty of issues we see with this data such as changes of programme/status, or a dependence on when the centre update key data that can all cause a lag in local account creation. We also use data from EUCLID to be informed of our “upcoming” students (principally PG students) so that the local account can be created in advance of the actual programme start date.
• OracleHR/IDM (Identity Management System) is used to provide data on which staff are associated with our School and are entitled to a local account. There are many subtle issues with this particular data set (primarily due to the fact that OracleHR at least was never intended to be a feed of live data) that means we often see a lag in account creation for staff, which we would prefer not to have. Also we see issues with new staff that have transferred from elsewhere in the University. Staff that are not “contractually” associated with our School but nevertheless for whatever reason need a local account are also problematic.
• VRS (Visitor Registration System) is used to provide data on visitors who need a local account (not all do). There are issues with this data set due to upstream bugs that have not been fixed and also with handling aspects of the UUN reconciliation process.

As a meta issue we also have to track many accounts that traverse (and change associated UUN as they do) from one data set to another. For example, a student on one of our programmes that after finishing becomes employed as a member of staff and then leaves but is kept on as a visitor. Different account types often overlap as well, temporarily while traversing or for a longer period of time (for example a member of staff who is also registered to do a PhD).

So while we deal automatically with the creation and expiration of many local accounts every day, the vast majority of the few thousand or so we have causing us no trouble, we still often have to deal with anomalies in specific edge cases. Unfortunately individual anomalies can cause a delay in account creation or can result in erroneous account expiration. Each instance must be manually investigated and progressed.

If you do have an issue with your own account or an account you have requested for someone else please contact frontline support who will be able to investigate.

## KeePassX password manager

If you sometimes struggle to remember passwords, a password manager can help. It’s a utility which can store your usernames and passwords in a strongly encrypted personal file, and which can generate random passwords for you.

DICE has keepassx2. It can save passwords to a local file, which it encrypts securely. If you need to access your passwords on another system, copy the file to that machine and download a copy of KeePassX to open it with. It’s available for Mac, Linux and Windows.

To get started, read How to: Use KeePassX, one of the Surveillance Self Defense series published by the Electronic Frontier Foundation.

Users of the older keepassx command will find that their older-format password file can be imported into keepassx2.

If you’re a Windows user you might prefer the similar .NET based project KeePass, which KeePassX was based on – although in fact nowadays both projects are available for a variety of platforms. Current versions of KeePass and KeePassX use the same file format, so you should be able to open your password file with either or both of them.

If you’d also like to use your KeePassX or KeePass file on a phone, take a look at the list of unofficial ports of KeePass on the KeePass download page.