Yeah, this page has been WAY neglected…
Anyway, here are the Feb MARS:
Once again, it’s all been about DNS and the preparation for the March 2nd deployment…
* Cleaned DNS zone files which lead to a reduction from 10367 lines in the main vanderbilt.edu zone to 4271 lines.
* Created vanderbilt.edu sub-zones to facilitate self serve requests for major users. This resulted in another reduction of the vanderbilt.edu to 1617 lines and the creation of 18 individual sub-zones.
For the record, those 2 above activities involved manual line by line combing through the files. Talk about time consuming and tedious…
* Install and configure the BT INS Diamond IP appliances: Not as easy as it sounds. The initial build shipped with the appliances had a small error that would not allow the management stations to install from the provided USB keys. After much hair pulling, the vendor overnighted a new build for us to use to facilitate the install. Additionally, being locked into the non-elevated privledge accounts has led to much heartache when it comes to iptables, routing, and other low level configurations.
Enough about DNS… I actually do other things too… seriously…. stop laughing now….
* Continued to work on getting Spectrum updated. With the deployment of 8.1, multiple processes managed to become broken. After multiple hox fixes and patches installed, all but one seems to be resolved. The remaining issue concerns a bug with Business Objects and the Report Manager function for Spectrum. With any of the Sun X-Server patches installed, BO decides to go blah. By blah, I mean fail to work. Computer Associates (the vendor responsible for Spectrum) is waiting on Business Objects to provide some sort of patch for this issue.
For the record once again… I don’t know HOW you did it, K-Mac, but you hooked me into BO again… somewhere in the world, little puppies or kittens are dying because of this.
* The only other notable activity for the month (I don’t include operational gunk but it’s… well… mundane operational gunk) was the re-examination of system data collection on the servers I am responsible for maintaining. Sar, for all of its pains and annoyances, is a steady standby for collecting system data. SNMP and Cacti and Nagios and blah blah blah is well and good but to rely on it exposes us to potential granular data loss. So, after spending a couple days hopping through hoops to provide CPU utilization data on systems and finding that it was (for a lack of a better term) lacking, I have jumped around and insured sar is doing its thing.
Other than that, all I have to say is "HOLY COW FEBRUARY WENT FAST!" and "HOLY COW DNS IS ALMOST HERE!"