« August 2005 | Main | October 2005 »
LDAP: Re-run Active Directory feed because yesterday's problem created the problems file and I forgot to remove it after re-applying the updates (Greg had found an entry in AD that had the wrong permissions).
Blogs: Create one.
SecurID: Build new replica server.
Calendar: Purge a request that was looping sending email out and failing each try because the person typed their message in the address line.
Calendar: Finished putting the access rights back to the way they had been. And, Oracle says this problem will be fixed in the 10.2.1.0.0 version of the desktop client (THE CLIENT NOT THE SERVER!!!)
Purged two entries in the queue that were created around 2:30 Tuesday afternoon and were claiming to fail to send but were actually getting sent out every two hours. John Cooley notified me of the problem.
LDAP: AD Update broke... Greg fixed permissions on the entry that wouldn't update and the modify commands were able to complete.
Student Employee error... found/merged.
Giraffe: ncftp ... it starts counting with the systems listed in the .ncrecent file -- which really messes with batch jobs that expect "ncftp 1" to run the first machine in the .ncftprc file...
eMail: telreq requests getting bounced by new in-mailgw. It was fixed yesterday, but I was slow to get to the report.
SecurID: got remote admin working and updated one of the two admin computers.
FootPrints: Issue #16250... ":" in filename prevents windows sftp program from downloading the file.
Calendar: run uniuser command to make default for all resources that they are invitable by anyone -- this because the command Oracle gave me yesterday that was to NOT change that value on the resources in fact changed it to not-invitable.
Resources explicitly made non-invitable: 1
Installing backup from two days ago on test machine to see if I can get the calendar server to tell me what people had...
Well, the backup is installed on the test server, but uniuser seems to be unable to extract the necessary information. I've updated the TAR requesting guidance -- Oracle has appologized in the TAR that the uniuser -ex creates defaults if they are not in the resource.ini file.
Manually comparing (via the web interface) backup to the default and updating the production -- got through the resources that begin with the letter q (r-z left to go).
LDAP: Student Employee (another graduate student)
Giraffe: ncftp not working.... hmmm... it worked this morning... It last worked on 9/22 and then it works again on 9/28... something not nice going on.
Beetle: reboot.... Oracle will not start/stop if machine has been up for more than 248 days...
SecurID: install sudo on server.
Calendar: Follow directions from Oracle on TAR 4723804.993 to set defaults for resources to show the time (but not the details) of personal and confidential events.
Hold on. Looks like the directions will reset every resource to the defaults as set in the resource.ini file -- which is fine for most of them, I'm sure. However, I'm certain there will be a subset that are not booked by anyone and will need to be manually set. Posted back to the TAR asking how to not override the "anyone can book" value.
Account Services doesn't have a list of conference rooms that were requested to be set up with values different than the defaults. Seeing if I can find that information from the uniuser command.
Apparently, there is no way to determine that information except through the web interface (ugh). Therefore, Oracle provided a workaround that would not cause change the private/public booking policy.
LDAP: lock down test server... bunch of machines on 103 are talking to it... and I don't want that.
New version of ldap-stats.pl installed on servers
New version patched to report on the most popular list of attributes to request.
NERCOMP Identity Management conference in Worcester, MA.
A very good experience. Made at least one good contact with UMass Amherst.
SecurID: Gather info to call in on C0527788 at 8am.
Problem is fixed! Resolution was to go into the sdadmin program and edit the agent host entry for the agent and in there assign an acting master server and generate a new sdconf.rec file for the agent. Then copy that sdconf.rec file to the agent. It's all fat dumb and happy now!
Now it is time to upgrade the remote admin installations.
Ouch... they don't seem to work... need to open another case
Calendar: TAR 4723804.993 -- the default viewing rights prevented people from seeing the room as booked for confidential meetings. And the Oracle Calendar was therefore not realizing that the room was already booked and double-booked it. Is the Oracle product really stupid enough to let the desktop client decide whether there is a conflict or not???
SecurID: getting ready for tonight... Machine is now primed and ready to go.
Calendar: a conference room is double booked even though it isn't supposed to be able to happen. Open TAR 4723804.993 -- I bet Oracle will say to shut it down and run unidbfix again....
Catalyst: walked to Southwick to see the server location.
SecurID: giraffe didn't like the new config... C0527788 opened. We don't have 24x7, so I need to call back in on it at 8am Friday. One should also note that C0526005 (Authentication Agent 5.3.3 for PAM not working) was not a problem with the older ACE/Server 5.0 code running on deer -- but rather with the PAM agent. It still didn't work after pointing it at the ACE/Server 5.2 system. After upgrading to the newly released Authentication Agent 5.3.4 for PAM, it works with both of the servers.
SecurID: new server software configured on server. RSA answers that the old agents will still work just fine -- they'll need their sdconf.rec file updated, but they'll work with the new server!
Still need to:
SecurID: researching how to move from AIX to Solaris and upgrade from 5.0 to 6.0 on the server (to allow the SecurID PAM agent to work).
BB: add a couple machines to be monitored for Windows half of team.
Oracle: Oracle opened BUG 4616312 on Friday for TAR 4698854.993 (WinXP install
SecurID: verified that the securID server is not seeing any traffic from the test machine. Something is definately wrong with the SecurID PAM module on AIX.
IMAP: wrote script for the helpline staff to be able to check that an account at least has imapd's running on the email cluster that are likely to be stuck/hung before they enter a footprint issue to have TSG check/fix the problem.
(This is from memory --- so it may be incomplete)
Filesystem: /rack2f filled up... moved a large ugrad.
SecurID: Their test program works, but the actual pam module doesn't... need to talk with those support people again.
Accounts: finished cleaning up from the failure of a rename yesterday (the flatfile database was not updated correctly -- manually remove the old account information);
LDAP: merge two entries together because they were found to be the same person (HR finally got the real SSN of the person).
SecurID: Notifed by tech support that they will call me this AM (Pacific Time) to work through the problem.
Calendar: Oracle has opened BUG 4612781 related to TAR 4698883.993 -- the MacOS X useless dock icon after upgrade. It is currently in status 11 (being confirmed), it should be findable within a week via the MetaLink search mechanisms.
Legato: install 7.2.1 on deer for testing....
Calendar: TAR's 4698854.993 (WinXP 10.1.1.0.2 shortcut) and 4698883.993 (MacOS X 10.1.1.0.2 dock shortcut) opened. Fully expect the recommendation on both of them will be -- don't do that! I suspect the correct installation procedure for Desktop Oracle Calendar client is to uninstall the previous version and then install the new version. Sure... whatever!
LDAP: Hey, no errors today! YIPPEE....
CIO: new info to read...
Accounts: Broken LDAP update corrected. Still unsure what is causing these problems. Added code to the routine to include the actual LDAP entry in the email to root so we can hopefully find the cause.
LDAP: No Problems!
Email: forwarding of mass student mailing drove email server into the ground again.
Network problems (with internal firewalls) makes AD basically unavailable and useless.
Webmail: FP issue appears to be something with the user's browser -- not certain, requested that they take the computer to walk-in for examination.
Banner: Assist with credit card process -- opening ports for outsourced process to work on test system.
LDAP: Student Employee error from over the weekend.
Sendmail: high load on penguin1... related to sendmail. Forwarding?
LDAP: 8 Student Employee errors fixed (6 from today and 2 from yesterday).
Owl: space problem... Jim working on it.
Calendar: Windows client problem duplicating Holiday entries on the printed forms of the calendar output only... not a problem with the mac and linux clients. Oracle has received reports of this in May and closed them with "fixed in next release" code indicating that the desktop calendar client version 10 would not have this problem.
Giraffe: do samba work for Mr. G.
Calendar: TAR 4560587.992 -- calendar sending mail to people without email addresses. Oracle refuses to fix problem, instead provides workaround to ignore the sendmail code 64 error. [BIG FROWN] ... Their workaround implemented at 11:25 AM.
LDAP: account rename blew up... cleaned up the mess.
LDAP: Research userid that isn't working in AD. Fix two "Student Employee" errors. Scrap carcajou updating... cannot maintain uuid/csn values -- need to make it a full replica server, and then use sync-repl to feed into mink... problem there is can still cause a backup that will affect wolverine eventually.
SecurID: Info on problem report (Case C0526005) that will be useful once get the AIX system back. Got the system back... found the AIX 5.3 install CD's and used the maintenance shell to get the /etc/security/login.cfg and /usr/local/etc/sshd_config files fixed.
Calendar: Oracle responds to TAR 4560587.992 (sendmail being given blank addresses to deliver mail to) that if we put email addresses in for the 202 calendar users that do not presently have them the problem will go away. Well, Duh! So, I asked why the calendar program doesn't verify that the user has an email address before sending them email.... we'll see what Oracle has to say about that.
Banner: update a .htaccess redirect per request from Mr. G.
Blogs: Created two per request
LDAP: Update daily procedure on carcajou
RHEL4: respond to questions in Red Hat Service Request #656636.
SecurID: Authentication Agent 5.3.3 for PAM... installed, rebooted... can't log in... opened case C0526005 with RSA.
Perseus: Agree to assist DSV with COM AD authentication issue.
LDAP: Four more Student Employee issues in HR feed -- found all four in the Banner feed (by NAME! :( ).
web: revamp home page
SecurID: replace dead card, continue testing...
Ferret: (RH 656636) run sysreport and provide output to RH for analysis of problem.
LDAP/AD: add mail attribute to daily feed...
LDAP: Two "Student Employee" primary affiliation errors. Found one in the student entries and created an account for the other.
TSG: meeting...
SecurID: install and (attempt to) test PAM product on AIX 5.3 ML2.
job: apply for new one