« June 2005 | Main | August 2005 »
LDAP: RHEL4 Upgrade. Peregrine is a nasty little piece of hardware. It refused to allow the raid-1 array disk to be repartitioned. Final solution was to delete the raid-1 array and then create it again. After that, the RHEL4U1 disks installed (partitioned etc) just fine.
LDAP: Another Banner entry with lastname that begins with Delete: ... ignore it for now, as those are going to be removed from the feed.
LDAP: Continue with the mink installation:
LDAP: post rhel4 update checklist at ~fcs/ldap_rhel4.html and post to tsg mailinglist for review.
CALENDAR: worked with Account Services on a problem with provisioning new calendar accounts and found a bug in the PHP code that builds the LDAP entry required. It was not changing the surname as requested (the code was just missing).
LDAP: RHEL4 upgrade. 2/3 completed. Failed on third system (peregrine). Will try again tomorrow after the drives finish sync'ing after the bios update caused the card to think they were out of sync.
LDAP: another Student Employee problem. This time it was really fun because the person has a bogus SSN, and no barcode, birthday, pidm info to go on... Hopefully, I found the correct (the only) match with the name.
LDAP: build Mink as RHEL4/OpenLDAP 2.2.26 replica server...
Oops... missmatch... ServeRaid 7.10.18 got part way installed, but the card is still at 7.00.14... this is a problem :(
Ahhh... Figured out how and got the ServeRaid 7.10 code installed by hand! YeeHaw... use the .htm! ;-)
LDAP: I can't type! Had to fix a typo and rerun part2/3 of the nightly update. Discovered that a rename of an account didn't work yesterday.
CALENDAR: MetaLink... shutdown server... turn on debug... send more info... rinse/repeat... ARGH!
ACCOUNTS/LDAP: bug in accountrename :(... why is it sending an email address as an attribute name??? must find and fix. Have added code to make it explode in large fashion when it breaks again.
LDAP/RFC2307: UVM Directory change will be simple... and is done. Testing nss_ldap (/etc/ldap.conf) changes. YAY, it works!
scripts: perseus scripts copied... need a volunteer (or direction) to test.
SSL: timesheet certificate installed
LDAP: get mac lab configuration problem figured out. Right attributes wrong server. For some unknown reason, the mac lab machine being tested was not properly updating it's plist file so it was trying to use the UID attribute to search on ldap.uvm.edu which just isn't going to work (yet).
CALENDAR: create a calendar account for ERP.
LDAP: make certain the uvmAlt* attributes are created for all accounts as they are created (modify the update_ldap_ldif.pl and adduser scripts)
LDAP: handle a "Student Employee" primary affiliation. (adduser and modify ldap entry -- because unable to find "student" information)
CALENDAR: Toss one to John and Sharon... Oops, shouldn't have. Appears to have been user error. There was a message queued at 15:41 Friday that had no recipients. Purged the queued item (it happened before the server upgrade). Will report it to Oracle if it happens again. Used unireqdump to find/purge the item.
Calendar: prepare for tonight's updates.
LDAP: entry in ou=Expired tree unable to update via UVM Directory interface question from account services -- this is by design -- plus the attributes they desire to change are only supplied from the HRS feed.
Calendar: (5:00pm - 8:30pm) upgrade and fix db.
Web: multiple spiders sucking down the uvm webspace at the same time cause the circle of death event.
LDAP: continue with exploring the separate error log thought. Announce RFC2307 work...
VPN: Vendor access... think about it some more
WebCT: planning discussion...
Calendar: Review 12. Juli critical patch notes. No critical patches apply to calendar product, will ignore for this week.
LDAP: RFC2307 work; explore creating a true STDERR output from nightly updates.
WebCT: SSL Certificate renewal
TimeSheet: SSL Certificate renewal
FootPrints: FP7.0 webinar...
Calendar: Update TAR 4476859.993 about DB_VISTA error from Saturday night to see if this is a new concern or if it should be fixed with upgrades Friday night.
LDAP: Research HRS feed question...which turns into a bug in my code search...bug located and repaired. Updates that failed to happen on Thursday and Friday have been run and applied.
LDAP: Banner updated an entry and gave enough information that we could determine it was a duplicate of an existing employee entry. Merged the two entries and purged the one created yesterday by banner.
Calendar: started the wheels moving to get administrative permission to perform the calendar maintenance on Friday July 22 (5pm to 11pm). Hopefully, everyone will be happy with that time and the upgrade will go as smoothly as the one on the test server did yesterday (with the exception of having to call Oracle because the readme didn't include all the conf file updates that were required).
RFC2307: test server configured... I think it's ready for testing! Will make a few checks tomorrow and go from there...
Storage: meeting to discuss connectivity, etc...
LDAP: verification that nightly update process on the test server ran ok. Posting to OpenLDAP-software list asking if someone has written the code in PHP or PERL to figure out the canonical name of an attribute so the application can go after the correct attribute name (search for netid; get back uid; code go boom -- not a real cool situation)
Calendar: upgrade test server to OCAL 9.0.4.2.10 (seems to work fine) and OCAS 9.0.4.2.40 (oops... it no run -- open TAR 4494932.993 to resolve). Test unidbfix on test server. Oracle wants a web conference to work on the TAR. YAY! The problem is fixed. Seems there were some changes that needed to be made to the ocas.conf and ocwc.conf files that were NOT detailed in the 9.0.4.2.40 README.html file. Oops... minor QA issue there.. Updates saved in 9.0.4.2.40_fixit.patch in homedir.
CATalyst: Meeting about privacy...
Calendar: MODRDN/unidssync to rename the resource entry for Account Services.
Accounts: Update account-deletion-2005 project pages.
Calendar: generate the list of machines (and who is likely using them) that are running old calendar clients since June 1.
LDAP: more work on rfc2307 support. Oh the headache this is becoming.
Printer Queues: Request forwarded to Account Services -- Kent trained ;-)
LDAP: an account rename didn't work right yesterday. Had to clean up the pieces. Asked Account Services if they had noticed any error messages and notified anyone...
continued code testing for rfc2307 support.
Calendar: Opened another TAR to see how to change the name of a resource. The documentation appears to indicate it is not possible.
Accounts: Prepare for annual purge to start tomorrow.