Frank's Activity Log

Calendar: Interacting with Oracle via the TAR (4476859.993) to work out how to deal with the corruption in the calendar database. So far, we have only determined that corruption exists, not what the corruption is. We also have no idea what is causing it. This is all very black magic and I don't ever like that feeling.

Oracle has determined the problem is being caused by older versions of the desktop clients. One user in particular is causing the corruption, but all older clients should be upgraded to the newest version for their platform.

I have notified the one person and will test the upgrades Oracle has requested on the test server. Looks like an upgrade will be happening in July.

LDAP: Migrate the changes for the FERPA coverage from the production server to the test server to allow moving forward with the OpenLDAP 2.2.27/syncrepl/RHEL4/RFC2307 testing.

Posted by at 8:05 AM | Permalink | Comments (0)

LDAP: Ugh! making gecos unsearchable caused the nightly update to fail because the way the modifications are performed forces a search. Need to modify the modifications so a plain replace is done.

Blog: Found 12 attempts to post comments to my blog that were garbage. Purged.

Calendar: provide training to unix side of team, so the daily tasks can be handled while I'm on vacation; open TAR about problems in dbv.log file.
- Oracle says the database is corrupted. I should run unidbfix. But I have and it never fixed the corruption... asking for further details of how it should be able to fix it this time.

BANNER: clean up old files as requested.

Posted by at 7:04 AM | Permalink | Comments (0)

LDAP/AD: meeting with Geoff about how to deal with groups that are disappearing. Our first crack is to look into the possibility of just renaming the groups (put them in the Expired branch) for a time before they actually go away.

LDAP: FERPA! YUCK! NightMare! You can no longer search based on the gecos value. You nasty people you! ;-)

Posted by at 2:59 PM | Permalink | Comments (0)

rfc2307: work on updating ldap code to support rfc2307 as well as converting to RHEL4 and openldap 2.2.27.

IBM: meeting re ds6800 vs ds4800

Posted by at 3:16 PM | Permalink | Comments (0)

Calendar: Explain the mistake to Account Services.

LDAP: RFC2307/RHEL4

eMail: HelpLine has someone contact me directly when the real problem appears to be in the COMIS Exchange installation. Need to find out who in the HelpLine did this and educate them.

PHP: write a routine for John.

Posted by at 8:02 AM | Permalink | Comments (0)

Calendar: Clean up mistake which caused the entry to be deleted from calendar's LDAP for an existing calendar user.

CATalyst: meetings...

LDAP: RFC2307/RHEL4

DotHill: Lost another SFP in the array. WebCT services were degraded to a single path to their disk while we debugged the problem with the SFP in FC1 of the secondary controller (after hours... like that matters to WebCT).

Posted by at 8:50 PM | Permalink | Comments (0)

LDAP: found resolution to glibc induced failure on test machine. Nasty thing didn't replace a library (why?) and caused all commands to break nastily. However, slurpd didn't core dump as it should have... trying again.

LDAP: Wolverine reboot to apply maintenance (apparently, I had never put update 5 on this one???).

ERP: meetings from 8am to 6pm.

Posted by at 7:22 AM | Permalink | Comments (0)

Happy Solstice!

LDAP: "Student Employee" account. This one was again a real employee who somehow has the Student Employee designation and needed to be created.

ERP: Meeting...

New Employee... set up office

LDAP: stupid slurpd core dump is still useless... I may yet wind up building and installing without an RPM to be able to debug this blasted thing.

Calendar: generate a list of calendar accounts that do not have userid's assigned (as the first crack at determining who is inactive)

Posted by at 3:25 PM | Permalink | Comments (0)

ERP: Technology Assessment kick-off meeting (three hours)

LDAP: determine how and build a debugging version ... openldap Makefile's have hard coded that they strip the binaries! Patch that out...

Recruitment: New employee starts.

FP - email issue (lost mail folders)

Posted by at 4:46 PM | Permalink | Comments (0)

GQ: build for FC4

FP: Issue #14698 -- missing folders; Issue #14688 -- php problems (with help from Jim)

Blog: fix little bug in mkblog.pl

Posted by at 10:22 AM | Permalink | Comments (2)

LDAP: build debugging openldap package for slurpd problem. New package installed. slurpd running in debug mode to attempt to find failure.

Calendar: ldap server not performing logging correctly. Environment was configured badly by the -q parameter of the slapadd command and a db_recover was required.

Posted by at 2:45 PM | Permalink | Comments (0)

RHEL4: e100 driver requires autonegotiate port! Carcajou works much better now that I realized that and had Lynne fix the port in the switch.

FC4: CD's burned

Accounts: Automated account reactivation, so I don't have to do it manually anymore! One account reactivated.

LDAP: New retiree list from HR installed.

Southwick: team consensus meeting.

Posted by at 9:09 AM | Permalink | Comments (0)

scripts: gather information

rfc2307: set up test machine

slurpd: Modify reject file checking to not page when reject file is for an add of an existing entry. Determined the problem is a segfault during connection. Need to post to openldap and see if anyone else has experienced this.

Posted by at 8:17 AM | Permalink | Comments (0)

Accounts: Reactivated three (3) accounts

Posted by at 7:34 AM | Permalink | Comments (0)

Accounts: Reactivate two (2) accounts

Abuse: automate abuse reports being put into footprints.

RHEL4: up2date on carcajou.

Calendar: metalink may have solved calendar startup problem... /etc/services needs to have the calendar ports in it. Need to test the fix... Tested. It works... RHEL 3.5 update applied.

Posted by at 8:42 AM | Permalink | Comments (0)

Scripts: Analyze logs to see what is still being used

Calendar: Analyze startup failures

Posted by at 7:56 AM | Permalink | Comments (0)

Accounts: two (2) reactivations

LDAP: one "Student Employee" primary affilation; A Graduate Fellow, needed to create the account.

Calendar: Set up logrotate to rotate the local apache log files

LDAP: look into db_archive problem on calendar installation

Machine Room: Meeting on new space

Posted by at 7:21 AM | Permalink | Comments (0)

Accounts: Reactivated one account -- administrative blessing for another year for this person.

Calendar: Meeting with Account Services to go over the new procedures. Notes sent via email (and copied to team) after the meeting.

TSG meetings: lots of them today... 3 hours total. very slow going.

LDAP: slurpd code examination.

Posted by at 8:47 AM | Permalink | Comments (0)

Accounts: Reactivate one account

Calendar: move calendar LDAP server onto Calendar server

Posted by at 7:52 AM | Permalink | Comments (0)

Accounts: Reactivated four (4) accounts that were scheduled for removal on 1 Juli.

FootPrints Issue #14581: recovered an inbox

LDAP: nightly update was generating new accounts and reactivating old accounts with the real SSN instead of the UVM ID. Rats! quick code change fixed that.

Southwick (machine room expansion) meeting... and again...

FootPrints Issue #14593: not locked account

Posted by at 7:08 AM | Permalink | Comments (0)

Accounts: unlock two accounts that were reactivated overnight. Set up a process to notify all of TSG of the accounts that need to be unlocked and notified of their reactivation.

Recruitment: Attempt to contact person offer was made to via phone. Moving on... 1st alternate, offering

LDAP: one more crack at fixing ID's in account files -- looks like I missed 22 from yesterday (probably caused by using the old LDAP directory instead of the new one that was generated yesterday -- or by incorrect changes that happened with yesterday's run before I fixed it).

Giraffe: create a userid

Posted by at 8:47 AM | Permalink | Comments (0)

LDAP: reject file on RW server unable to update one of the RO servers. Turned out to be a lack of available locks on the RO server. The DB_CONFIG file had not been updated with the set_lk_max_locks 2000 "fix" that was put on the other RO servers when this happened a month or so ago. Also found out that my pager needs new batteries because it took the thing 15 minutes to wake me up rattling away on the nightstand.

Accounts: locked down 6,663 accounts for their one month "cool down" period prior to actual deletion over the July 4th weekend.

LDAP: ID in account files needs to stay in sync with affiliation of individual. And an audit needs to be run to correct the ones that are out of whack now (found 184 and fixed them).

Firewall: implemented on owl.

Posted by at 9:41 AM | Permalink | Comments (0)