Rainy Days & Mondays

Karen Carpenter made the song famous for its authors, but clearly none of them were sysadmins

The rule, long known, for sysadmins is:

Never make a major change on a Friday, nor before leaving for vacation

I've been wrestling with the fallout from a violation of the sysadmin's rule by an upstream provider -- the vendor pushed in some change on Friday in the preparation of CDR -- Call Detail Records. For four days running, my sub-processes which manage the account have been failing for want of data. Those processes retrieve and apply CDR data, to emit accounting detail for customers, and have not been working

I've filed five or six sub-issue tickets which that primary change exposed, in trying to get the matter resolved: The current Firefox cannot open tickets under the current Windows XP, current SP [no problems with CentOS and FireFox or konqueror]; my 'closed' tickets were not visible; tickets were being closed by upstream before I confirmed a fix worked, so I ended up essentially re-opening the same ticket three times as each day's CDR pull failed; I was not receiving email updates of tickets; and so on. I am quite sure they consider me a 'stickler for details' and something of a pedantic pest at the moment, but dammit, I'm paying their bills. The PHB supervisor may want tickets closed quickly; but I want my issues fixed first

... as no one likes to be called into work on the weekend to revert a change, the sysadmin's rule must be faithfully applied

Getting to a x86_64 build environment

In the #centos IRC channel on freenode, today, a new user was trying to clean out the 'multi-lib' artifacts in his build environment, so that it was only generating 'x86_64' results

Tom mentioned:

10:26 Zathrus> realistically, just removing glibc.i?86 should nuke everything else...

and so I fired up a victim xen instance to test that hypothesis

sudo su -
cd /etc/xen
ls
cp centos-5-x86_64-test centos-5-x86_64-victim
joe centos-5-x86_64-victim
# the edit is to rename the instance name, and the image to be used
cd /var/lib/xen
cp centos-5-x86_64-test.img centos-5-x86_64-victim.img
xm create centos-5-x86_64-victim
virt-viewer centos-5-x86_64-victim

Then inside the instance as root, I ran:

rpm -qa --qf '%{name} \t %{arch} \n' | sort > pre-remove.txt
yum remove glibc.i?86
rpm -qa --qf '%{name} \t %{arch} \n' | sort > post-remove.txt
grep -v x86 post-remove.txt | grep -v noarch

getting the result:

gpg-pubkey (none)
libaio i386
libgcc i386
python-devel i386

That's a pretty good result for a first pass, and a quick hack. I think I'll go down for some coffee, and think about it a bit more

Revenge of the Jedi (Part II)

I wrote last week from memory about the use by the Basel II standard of a method, additively combining non-linear and correlated risk events

I see a post on the R-SIG-Fin mailing list from conference organizer Jeff Ryan, that the presentations from R/Finance 2009 are up

Page 4 on the PDF of the Klaus Rheinberger, et al. presentation nicely states the executive summary that this is 'problematic'. The work then shows a worked example

Let's call Basel II what it is -- a top down pronouncement on meaningless rules, written in a fashion that is willfully ignorant of the lessons from the US S & L 'hot money' and actuarially un-sound deposit insurance debacle 20 years ago, of LTCM as to correlated risks and 'being the market', and of the recent Credit Default Swap insurance blowup of AIG

May Day celebration

I see a tweet from KB about the monthly mailman mailing list reminder emails; I took steps long ago to use procmail to watch for these, and re-mark their subject line. I then sort my mailspool by subject in alpine, and delete this noise all in one pass.

# mailing list memberships reminder
#
:0 fw
* ^Subject: \/.*mailing list memberships reminder
*!^X-Reminder
  | formail -i "Subject: mlmr] $MATCH"     \
    -A "X-Reminder:$MATCH"    \
    -A "X-Munge: moved mailing list memberships reminder"


All power to the people