As part of the pandemic planning (before the real pandemic), people with a noted interest in covering for AFS were added to an email list which means they receive nightly emails reporting on the success or otherwise of AFS volume releases.
Those emails also go to the services unit general list. To cut down on the mail that people get, we could remove you from the explicit list of recipients for the volume releases, and should it be felt necessary, then in the time of pandemic cover, those people could just be added to the services-unit email list?
One of the IS mail relays started permanently deferring connections on Friday morning about 7:15am. This meant some mail was fine, but other mail remained wedged until IS fixed their problem about 3:15pm.
It's not unusual for a relay to defer connections at some point, so if we want to some how monitor this, it has to be a bit more subtle. Currently we find out by noticing that there's a bit more mail queued up than normal, or users query why a mail they've sent hasn't turned up instantly!
We have a cron that emails us in the morning and in the afternoon the state of the mail queues.
We've had a clearout of old tibs clients that have not been backed up for several weeks. Their owners where contacted, and the machines removed if no longer needed.
Only one owner has asked to remain on the list, even though his machine has failed to backup for months, as he's hoping to sort it.
Others were grateful for the prod, so they could trigger a backup.
Last week the certificate for smtp.inf was changed from an automatic University signed one, to a Let's Encrypt one. No one should/seemed to notice.
This morning (day of this meeting) at about 4am one of skelp's (www.inf, etc) RAID 1 root disks is reporting as failed. It is in the Forum, and unless some marking the drive as down, and then back up again revieves it, we will have to consider what to do. There is a DR mirror of the service at KB, that updates its copy 4 times a day.
There were plans to virtualise it in the future. Currently it has 130GB root disk, and 550GB data disk. But it is only using 10GB and 255GB respectively.
Unit meets and activities are linked from the ServicesUnitActivity wiki page.
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh