So you’ve had to replace a main board in your IBM blade, we’ve all been there. Generally, should you have asked for your friendly neighborhood tech to come out, he will kindly update your fresh motherboard with the original machines serial number and machine type/model number. If you’ve ever watched him do his work, you know on earlier blades he used the BIOs update utility from IBMs website to update that information. Well times have changed, this is no longer an option on UEFI and IMM based blades. Before you go and call IBM, you can use IBM’s ASU utility to update them. When I called they actually sent me an in house bootable ISO, which ended up just booting Linux and running a shell script that ran the following two commands:
Read more…
So you want to move your Linux workstations to RHEL5 but still use Insight II? If you have tried (and I know you have), you know that because of the jump in the version of GLIBC to version 2.5, Insight II won’t run. As much as we wish Accelrys would go and compile it against RHEL5, that won’t happen either. So, what does it take to get it to run? RHEL4… No, really. But we are going to be cute about it. Since all Insight needs is a few libraries to run, its just a matter of putting it in a place where it can get to them. My solution to this was making a small chroot environment in which to start up Insight in. Read more…
Since I failed to find a good description of how to do this on the web, I thought I’d share my recipe for using puppet to manage tripwire. This method will take care of running the initialization on the first puppetd run on a new machine, and update the policy file if its changed. It also has puppet managing your site.key, twcfg.txt, twpol.txt, and the daily cron to run the checks. Its an extremely simple setup, but gets the job done.
I’ll start with the tripwire.pp file for puppet, in this file you’ll define your tripwire class and associated files and packages:
Read more…
I recently ran into an issue where my I had Xymon clients on a network which was unpingable from the Xymon server. The clients could could send data to the server, but they were hidden behind network address translation and only on a local network. I had one box (the gateway for the unreachable clients), that saw both networks. I played with the idea of running bbproxy on it, but didn’t really want an entire Xymon server and it really was not necessary since the other clients could get their data out. Looking at hobbitlaunch.cfg I noticed it was really just a larger clientlaunch.cfg, which gave me the idea of just copying over bbnet and using on a client install – which worked perfectly. Read more…