We have a wiki page which collects together the various documents relating to access to and working in the server rooms post-lockdown. Note that if you do need to go to the server rooms for any reason you MUST check the bookings wiki page to ensure that you don't conflict with anyone else, and particularly with any prior bookings; and you MUST record your visit on that page.
Reminder: there is a new version of IS's AT method statement. This version reinstates the removal of kit. Please read it before you next go to the AT server room. In short you have to notify them before you go to the AT server room, if you're removing something you have to tell them what (it's probably enough just to say something along the lines of "old servers from the Informatics racks to make space for new ones"), and to take everything you remove from the racks out of the server room.
Sunday's EdLAN woes looked in our logs and graphs very like a classic loop: high levels of non-unicast packets, duplicated routing packets, that kind of thing. It'll be interesting to hear from IS what happened, if we do. Unfortunately, some of us will have received rather a lot of nagios messages as a result, for reasons which are probably due to some odd routing which normally doesn't matter.
The Fortinet certificates still being presented occasionally are apparently due to a firmware bug. IS are trying to find mitigations. The IS alert is still open.
We have an outline description document which is intended to summarise the way the new EdLAN is expected to look, various "thinking" documents linked from this index page, and a project to investigate our interaction with the new DDI. Comments and questions are always invited.
At the moment we set the default DHCP lease time for most subnets to one day, and the maximal lease time to two days. (The main exceptions are for the network and SOL management wires, where the default is 200 days.) There might be a case for increasing the lease times for the DICE client and server wires. Suggestions for reasonable values welcome.
(We would prefer not to increase the lease times for the static ("SMnnn") and dynamic self-managed wires, as this would limit our ability to push new router and nameserver values reasonably quickly.)
As well as
EdLAN+10 for OpenVPN, we have now added
EdLAN+10+efin variants. We'll update the documentation in a
few days, and probably write a blog article.
We don't have a good answer to the names not being in the "external" DNS though. Our own nameservers do carry them, but there's no easy way to persuade most OpenVPN clients use those. As a hack workaround we could probably create a sub-zone of our own which would mirror the addresses from the "real" zone, but it feels a bit unclean. It looks as though the "usual" public nameservers (126.96.36.199, 188.8.131.52, 184.108.40.206) will fetch the data from our nameservers at least some of the time, and when they do the results will be cached, but it's probably not a reliable solution.
Note that our own "external" nameservers will reply authoritatively for any zones they're configured to carry, but (deliberately) don't provide a recursive DNS-resolver service. Our internal nameservers do, but (deliberately) won't answer queries from outside. They would be accessible over OpenVPN, but we generally don't recommend their use as it's not straightforward to arrange that they're only used when a tunnel is up; and in any case we don't guarantee that their addresses will remain unchanged.
inf-unit-report.html,v 1.11 2020/11/24 14:07:58 gdmr Exp
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh