30 January 2014 – Thursday

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:

Leave a Reply

You must be logged in to post a comment.