• A-Z
  • Directory
  • myUVM
  • Loading search...

Frank's Activity Log

24 October 2014: Friday

Posted: October 24th, 2014 by fcs

LDAP:

  • Issues:
    • Two former students from Banner – did the dance.
  • Added monitoring for the temporary insecure idiotic ldap server that Oracle will be allowed to use until they can actually do something that is worth doing.

Backups:

  • email backups continue to fail every other day because of the time it takes to move all that data to tape.
  • The new staging code (to deal with the clretent becoming the ssretent value) has not moved data off the AFTDs fast enough and one of them has filled up :(

SecurID:

  • Plan is to deploy the 8.1 appliance at the permanent home – need to resolve the Backup Space issue first.

FootPrints:

  • Another round of “what’s broken” questions from BMC concerning the root owned files per issue 332683.
  • Opening another issue – searching fails to find ip addresses now (. is a separator and ip address bytes are three characters => skip!).  Issue # 333977 opened.

23 October 2014: Thursday

Posted: October 23rd, 2014 by fcs

LDAP:

  • One issue last night – a “modifying the WRONG entry” error:
    • Employee record gained an SSN and now it matches a former student LDAP entry.  Merged the Banner info into the new HR entry (because the HR entry has the posixAccount) and purged the former student entry.
  • Rolled out updates to network services feed and banner feed processes.

Backups:

  • Weekly Clones have finished!  YAY.

SecurID:

  • 596453:  Surprise!  I called “Mark” back (he left a VM after I left yesterday) and he was in the office at 6:45AM!  Anyway… the answer is that as long as the 8.1 servers are using different names and addresses there is no reason that we cannot run the 6.1 and 8.1 servers in parallel during the cutover.  The issue will be token related (pin changes on the 6.1 servers will not be reflected on the 8.1 servers).
  • Next Steps:  Pick a famous couple (names) and a network (addresses) for the new 8.1 servers.

FootPrints:

  • BMC responded to my 332683 issue that if I want the files to not be owned by root, I should move the crontab entry to the FootPrints user crontab.  To which I called BULLSHIT!  The root crontab is created by the FootPrints install process, it is not anything that I have done.  And when we ran the 9.5 version of FootPrints it either did not generate files that were owned by root or the FootPrints code at least dealt with them without generating errors for the customer/agent to see.

22 October 2014: Wednesday

Posted: October 22nd, 2014 by fcs

LDAP:

  • No issues in last night’s update.
  • POODLE recycles.
  • POODLE (CVE-2014-3566) recycles – take two.
  • Network Services feed – updated.

Backups:

  • CoM/IS clones have about 8.5TB working and left.
  • Disk clones have about 4.3TB working and left.
  • A Windows client (big file server) hung its nsrexecd process – after it was recycled, the saves that had all listed as queued started running.

SecurID:

  • Opened case 596453 to confirm that the 8.1 appliances and the 6.1 servers can run concurrently to minimize the downtime required for moving host agents from the 6.1 servers to the 8.1 appliances.

FootPrints:

  • BMC concedes in issue 332683 that it is the root cronjob that is causing the files to be owned by root. And then they had the gall to ask if there was anything else they could do.  Uhm… yeah… fix it!

21 October 2014: Tuesday

Posted: October 21st, 2014 by fcs

LDAP:

  • No Issues last night.
  • I think I have found the solution… TLSProtocolMin 3.1

Backups:

  • Tape clones finished, the rest of them run on.
  • MED23 B continues to perform the full from the weekend.

SecurID:

  • Finally got back to the manual … have made a proposal for migration.

FootPrints:

  • No response from BMC on either of the issues I have open with them.  Darn it.

 

20 October 2014: Monday

Posted: October 20th, 2014 by fcs

LDAP:

  • One issue over the weekend.
    • A Visiting Graduate Student who didn’t match up.  Found the match and merged.

Backups:

  • Opened SR 66570742 to deal with the fact that NetWorker is not properly keeping track of what data is really stored on AFTDs.  There are some AFTDs where it is correct, but most of them are wrong (and the ones that are correct are the ones that are actually using compression)… HUH????
  • Backup System Maintenance cancelled.
  • Clones started.

SecurID:

  • Never got there today.

FootPrints:

  • I see that one of the two issues I have open (327325) got a response from BMC folks that I never saw, so I answered it on their footprints web site.  The other one (332683), I have requested that I get an update on.  I’ll call them tomorrow if nothing else happens today.

17 October 2014: Friday

Posted: October 17th, 2014 by fcs

LDAP:

  • No issues in last night’s update.

Backups:

  • Disk clones have 13T left (at 7:41AM)
  • NetWorker frozen in place.  Apparently, the “only use X% of a disk” option is too stupid to be used.  NetWorker appears to calculate the % used of a disk based on the media database and not on any actual real checking of the disk space usage.  Is it because the programmers don’t know how?
    • Live Chat with EMC about this issue:  jobkill – kill them off one by one.
    • Killed them all off – jobkill does not see them any more.  However, NMC still sees them, and they are still listed by my sessions.sh.
    • draining stage and clone commands.
    • doing another live chat with EMC – I’ve got nothing left to lose (and time to kill).
    • EMC confirms – recycle (and kill -9 any stragglers) is only way forward.
    • NetWorker put into maintenance mode – announcement sent out of impending recycle.
    • Recycle started at 2pm, back in business at 2:30.

SecurID:

  • Reading the 6.1 -> 8.1 migration guide.  I will have to touch every single Agent Host whether I change the IP address/Name of the SecurID servers or not.  So, why not go ahead and do it the right way???

16 October 2014: Thursday

Posted: October 16th, 2014 by fcs

LDAP:

  • Two one-item match, wrong surname issues in last night’s update:
    • Both PeopleSoft:
      • One is a former student – asking for confirmation of details.  HR confirms, merged and account created.
      • One is an OSP feed – problem is a space that was or was not included… merged.

Backups:

  • Disk clones still chugging, 20.8TB left to go.
  • email backups are running, so stopped the staging of the data off the data domain.

SecurID:

  • Patrick called on the 00591816 (firewall) case at 4 pm.  I called him back at 6:40 am – not surprisingly, he was not available.  He called back later.  The internal firewall is there, we can change it, RSA does not recommend changing it and may close a case if they ask us to revert our changes and we refuse.  I need to experiment.  Yes, I can update the /etc/sysconfig/iptables files and it stays put and doesn’t seem to cause problems.  Now to read up on how to migrate from 6.1 to 8.1

FootPrints:

  • Issue 332683:  I suspect it is root’s crontab entry that runs FOOTPRINTS/cgi/MRRunScheduledScripts.pl constantly that is doing this.  Asking for confirmation.

15 October 2014: Wednesday

Posted: October 15th, 2014 by fcs

LDAP:

  • No issues in last night’s update.
  • Today is Automated Account Maintenance day for October.  It ran with four reported errors (trying to add email bounce controls that already existed).
  • Cleaned up an account creation error on email servers.  The account was not completely removed when it was purged on June 15, 2012 – so a residual mess was left to be discovered today.

Backups:

  • CoM/IS clones finished up, Disk have 27.7TB left (at 6:30am).
  • Backups ran – still having one windows machine that fails to DNS resolve more often than not and one disk on one CoM/IS client that is having trouble (and CoM/IS has now told me it is officially having a problem and may be a while until it is fixed).

FootPrints:

  • Even though I fixed all of the files and directories that were owned by root yesterday, I find there are a bunch more this morning.  Time to open an issue with BMC about this bug.  Issue 332683 opened for this.

SecurID:

  • 8.1.0.0 Virtual Appliance deployed.
  • 8.1.0.5 patch applied.
  • Nessus Scan performed: 2 medium, 1 low, 20 informational.
  • Case 00591816 opened to see if there is a way to modify the internal firewall of the appliance (say to limit the addresses that can SSH into the appliance if SSH is enabled).

14 October 2014: Tuesday

Posted: October 14th, 2014 by fcs

LDAP:

  • No issues in last night’s update.

Backups:

  • Clones:  CoM/IS is almost done, Disk has about 36TB left to go.
  • DataDomain: Is working away on moving the data to tape.  I hope it frees up enough space that I can do some testing for EMC.  However, because of the way it removes duplicate data blocks, I do not know that it will free up the required space.
  • NetWorker 8.1.1.X (where X is at least 7, 8, 9) the lgtonode x86_64 package is really the lgtonode x86 (32-bit) package.  Damn you EMC! The blasted thing is a mix of 32-bit and 64-bit packages.  I’m really not sure what the heck their (EMC) game is.

SecurID:

  • Got the evaluation license for 8.1.
  • Reading through the planning guide (Zzzzzz) and the Security Guide, and the Setup & Config guide.  Almost ready to just do it – but it is still not clear (perhaps I didn’t go to the right schools to understand this legalese in these administrators guides)

Calendar:

  • Names with apostrophes in them cause the Calendar Server to not be able to provision them.  Something about quoting inside the Calendar code someplace – because OpenLDAP doesn’t give a rats backside about a single quote (it is not special according to the RFCs). The fix (for the amount of time the Oracle Calendar server will survive) is to manually update the DN of the Calendar LDAP entry to remove the apostrophe from the cn (rdn) value.

FootPrints:

  • WTF!?!?!?  There are files & directories owned by root again!  Fixed … again!

 

13 October 2014: Monday

Posted: October 13th, 2014 by fcs

LDAP:

  • Two issues over the weekend:
    • student employees that have not ssn’s yet.  Found one and merged it, asking about the other.  The second one is not a student, but a “visiting scholar” who was entered with the wrong code.  Hopefully, HR will fix the code, but the person I’m dealing with is pretty hard to deal with.

Backups:

  • Weekend plans to stage data were scuttled by BT’s 48 hour outage!  Staging of more data off the data domain starts this morning.
  • Weekly cloning kicked off.
    • Tape clones complete – 95.8 GB done.
  • stornode9 /dev/nst1 (A3141/9310278303) has a code 6.

SecurID:

  • Trying to get AM 8.1 – what a convoluted… it doesn’t work with Safari on Mac, it doesn’t work with IE 11 on Windows, it does work with Chrome on Windows and Mac…
  • Got the code… now to read the manuals and see about setting up the appliance.
Contact Us ©2010 The University of Vermont – Burlington, VT 05405 – (802) 656-3131