Paul Hutton writes: "[...]
"Week commencing 18 March:
Contractors from Uninterruptible Power Supplies Ltd (UPS Ltd) will be installing racking and batteries in room 3, along with switching the UPS over to the new batteries.
"That second piece of work will result in a loss of UPS cover for one working day. There should be some flexibility in scheduling that work, so if there are dates in that week which will cause a problem for you, please let me know.
"I appreciate that this work will cause some inconvenience and can only apologise. Moving the batteries from the man room into room 3 will allow us to keep them within their operating temperature range and should result in greater reliability and longer battery life."
If this date doesn't suit anyone, please let us know ASAP.
The Appleton Tower server wire had forward SLAAC-style addresses
enabled on Tuesday 19th. This brings us to 1239 AAAA entries in
We'll give it a couple of weeks to shake down before doing the last remaining two (S32 and S33 in the Forum). How would Tuesday 12th March sound for that? There are 367 IPv4 addresses on those two wires combined.
(In case anyone was wondering, it's just a case of changing
dns/inf6 to enable generation of the forward entries.)
Graham asked in the chatroom about
addresses. For Linux these can be enabled by setting the
use_tempaddr interface variable
networking/ip-sysctl.txt in the kernel documentation).
We hadn't expected to want to enable this:
dns/inf6and then adding the necessary
networkresources to have it take effect, as documented here. If we then wanted to make this a general feature we would really need to have some automatic way to provision them (such as deriving them from the IPv4 address in some way, and then changing the tools and the network component to set them up; or alternatively explicitly setting machines' MAC addresses and changing the necessary inventory and lcfg things to make this work). However, we would probably be required to tell anyone who asked under FoI(S)A what kind of kit we run in any case, so wouldn't actually gain a lot in practice.
Comments to the contrary (and project proposals!) are invited...
NEEDS_GATEWAYis apparently still used, so it'll be left in all the headers, with any errors being fixed.
DICE_DNS_LOCAHOST_ONLYis not set is also still neded, so will also be left in place and fixed as required.
Our list of subnets and their uses is here.
Some of the B.Z14 power bars have been replaced, with the remainder scheduled to be done soon. This gives us a few benefits:
Because we needed something like it for the EdLAN musings, there are now additional sets of graphs (Forum, AT) which show (most of) the aggregate traffic flowing into and out of the core switches. Intra-core is excluded. The y axis is in octets/second, so multiply by around 8 to 10 to convert to bits/second (the actual value depends on the encoding being used on the links).
The configuration which has been set up to drive this includes the rrd files from both the old and new core switches. Interestingly the aggregate Forum traffic increases as the old switches were replaced.
(While trawling MIBwalks, it looks as though the new core switches do at last provide some counters for the virtual VLAN interfaces, so we'll set things up to instrument and graph those at some point. Could be interesting...)
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh