LDAP:
- There were failures in last night’s update (even beyond the code issue that was dealt with). Two new employees showed up, each with a new name that appears to be a former student. One of them is very clearly a formatting issue (Van Dyke vs VanDyke). That one is merged. The second one is likely a marriage/divorce situation, but I don’t have enough data to be certain so I have reached out to HR for confirmation that I have the correct match before doing the merge.
- code fix from last night’s double-dash debacle put into production.
- Changed the CN of a departmental account entry in LDAP for Account Services.
Backups:
- COM/IS clones (since the biggest full from last weekend is still running) completed in less than 24 hours.
- ZFS pool “athens” is down to 10.1TB! YAY! Still possible to get it cleaned off this week.
- Oh Hell’s Bells! That issue with nsrstage that I reported to EMC against 8.1sp1.0? Yeah, that one that they fixed in 8.1sp1.1? Yea, that one. It’s in 8.1.0.4. Obviously, EMC was not aware of that because they recommended that I use 8.1.0.4 instead of deploying 8.1.1.1. I’ve re-opened SR 59521968 to get a hot fix for this one to put on 8.1.0.4 (or at least to find out the NW # of the defect).
- SR #60727670: Ok… this is officially annoying. I just spent 90 minutes going back and forth with a tech person who appeared to assume that I was reporting that after installing lgtoclnt that it would not work. No, I was reporting that the rpm does not have the dependency requirements correct so that yum/rpm can even find the dependency and install it with lgtoclnt, you know, the way RPM is designed to work! UGH!
Tags: Admin