Having had its batteries replaced on Friday 6th October (apparently), our monitoring card in the "right" UPS lost its connection to the UPS. It was reported to E&B, but hasn't been fixed yet. They have been nagged yet again.
The latest round in the attempt to have BIRD not zap IPv6 device routes is for the component to generate and apply a filter to OSPF route-import based on the IPv6 addresses of each machine. Time will tell...
Some time around October 24th, or maybe 25th,
Console AKA Brown Effect" event. We first spotted
this on the 27th, as a result of a couple of root-emails. The first said:
[WARNING] openldap: slapd won't die, trying kill -KILL [FAIL] openldap: slapd refuses to die. The second said:
/etc/cron.daily/logrotate: Failed to execute operation: Connection timed out Failed to restart snortd.service: Connection timed out See system logs and 'systemctl status snortd.service' for details.
Pressing <return> on the console resulted in the usual effect,
whereby some pending text would be printed. (That text was mostly from
snortd complaining about dubious things being sent repeatedly
from a remote site to a local web-server. That remote host has now been
blacklisted, and snort output really shouldn't have been
going to the console anyway,
but that's somewhat beside the point.) Remote login was possible, and
"ps ax" showed loads of cron and ssh daemons stuck in zombie waits, amongst
others, presumably implying that the ultimate reaper
The console would probably have caught up eventually, but given all the
other problems it was obvious that a reboot would be necessary anyway.
nsu wasn't working, presumably due to LDAP
problems, and the console wasn't available, so this had to be done by
bouncing the power. After a couple of reboots for kernel upgrades and
initramfs rebuilds the machine did appear to come up cleanly.
Our remaining three SL6 machines act as "autofs" LDAP servers to avoid replication issues for any remaining SL6 machines. We don't intend doing anything with these, other than turn them off when they're no longer required for that purpose. The autofs maps will be moved to our "service" SL7 LDAP servers.
If you have items which need to be moved from place to place around the University, and they are too large and/or heavy for Internal Mail, then the Servitorial staff run a van service which can do the job. The procedure is as follows:
The service can run from 'desk to desk', if that's what you need. That is, none of us need personally to wrangle with large or heavy items: let the professionals handle that.
Please contact us with any comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh