... has happened.
Alan writes: "I think most of the dust is due to stuff being retro fitted and there was a pile of dust under the floor at the other end of the room from your kit a while back, which has been cleaned up and hasn't reappeared but I don't know how it got there. The doors have also been fitted with seals to try and stop anything coming in from outside. If we still get dust once it's been cleaned, I'll ask E&B to try and find the source."
Following on from that, there was a power outage in the AT server room on Monday 19th, which took out our server racks as well as all of IS's. Alan writes: "The power has been restored and is stable. The reason the power was lost, was due to the emergency power off in the room being accidentally hit by one of the cleaning staff. However, they should not be held responsible as it was a genuine accident and I didn't make them aware of its existence. Although the cause was discovered relatively quickly, the electricians couldn't get access to the PDU to reset the breaker because the panel door was locked they didn't have a key! They eventually forced the lock. There are clearly lessons to be learned from this unfortunate incident but it's for another day. Apologies for the disruption to the services and the inconvenience it has caused." Still, at least it shows that the button does work...
There's now a small UPS in one of the server racks, powering otaka (the network infrastructure server) and one of the switches. This should allow us a little time to gather information in the event of another outage. Thanks to Richard for some well-timed assistance!
(We never did get an answer from E&B as to whether the 13A sockets in our comms room were also on the main UPS. Based on what the comms-rack UPSes were telling us while the rest of the room was out, apparently they're not! RT#60091.)
These are still ongoing.
DHCP-snooping has been enabled (on all the switches which support it properly) on the following VLANs:
ARP-protection has been enabled (on all the switches which support it properly) on the following VLANs:
The intention is to roll ARP-protection out to those other VLANs where this can be done without impacting on the service. The switches need time to populate their DHCP databases first though. One issue to be aware of here is that the DICE machines generally only do DHCP when they're installed, and cache the IP addresses they get back for future use.
This does seem to be doing something. The Forum switches are logging around 400-450 DHCP errors/day, and around 200-250 ARP errors/day! The nightly traplog-summaries have been enhanced to report tallies for individual MAC addresses and ports, but haven't been running nearly long enough for any kind of pattern to emerge. (The address search tool on the netmon front page has also been enhanced to support AAAAAA-BBBBBB format MAC addresses, to make cut&paste more convenient.)
A reminder of Graeme Wood's email to the ITPF on Tuesday 20th: "JANET have recently announced changes to their SSL Certificate issuing service. JANET will start charging for certificates from 1st May 2013. Single domain or multi-domain certificates can be pre-purchased in bulk and Information Services has decided to absorb the cost of these for the time being. ..."
The observant may have noticed that we have installed one of our old wireless APs downstairs in the Forum atrium. It's operating in dedicated scanning mode, to see if there's as much pollution as we suspected. And it turns out there is. Here's a non-eduroam non-central sample, from the nightly summary of last Wednesday:
78:D6:F0:95:34:23: "AndroidHotspot7598" on radio 1 channel 6 security "wpa" RSSI 9 E4:CE:8F:1A:D5:92: "nofixedabode" on radio 1 channel 11 security "wpa" RSSI 5 BC:76:70:C3:AA:55: "3MobileWiFi-aa55" on radio 1 channel 6 security "wpa" RSSI 17 18:87:96:A5:2B:FF: "HTCpsqlmnq" on radio 1 channel 7 security "wpa" RSSI 11 00:1E:C2:7F:45:22: "hpsetup" *ad-hoc* on radio 1 channel 6 security "none" RSSI 16 78:D6:F0:3C:05:AC: "agrivas" on radio 1 channel 6 security "wpa" RSSI 22 00:11:0A:2A:22:73: "IMRprivate" on radio 1 channel 13 security "wpa" RSSI 7 00:0C:76:6F:A9:B5: "RG54GS" on radio 1 channel 1 security "wpa" RSSI 25 12:C9:D0:33:8A:CF: "" on radio 2 channel 48 security "wpa" RSSI 20 90:84:0D:D6:CD:CE: "SPACE's Wi-Fi Network 5GHz" on radio 2 channel 36 security "wpa" RSSI 16"Radio 1" is 802.11g, and "radio 2" is 802.11a. We have a pending project to look at wireless coverage, a request for users' comments has just gone out to the if-people list, and there's a blog article on wireless pollution.
The annual CA certificate dance has now concluded. This means we have new CA certificates for both kx509 (used only by openvpn) and sixkts (which issues x509 certificates, typically for https web sites or cosign interaction). The process went smoothly, but has reminded us of some improvements required for the x509 component.
The LDAP master, franklin, has now been upgraded to SL6_64.
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh