$1500 for a new ESXi server for vSphere 4.1 is a bit high. Unlike this guy, I have a lab in the basement so decibles aren’t as important as capex and opex costs.
Plus, to have a lab in the basement where I can do things with a cluster would require two of these beasties. Running a second on the iMac i7 probably won’t cut it. Last time I needed a lab for something it was because a network change crapped out 1/4 of my primary vSwitch.
I think I’d like to do a mock-up of the vCluster configs we have at work, then randomly shoot components to see how it fails. The network change issue was unexpected. Losing 1 out of the 4 strands of the portchannel going to a vswitch should not have cause the outage, however brief it was.
Meet My ESXi Server, the BabyDragon. | Error404 – Its A Blog.
So a few months ago I started thinking about virtualization and the future of my profession (System Administration). So much of the hassle we have involves software compatibility issues with libraries and the code that runs on it.
My thoughts were that is would be much easier if, instead of big OSes with lots of services running on it, we had a micro-distribution running just a single application. A DNS or Mail server could be shipped as a virtual appliance with some form of hooks for shared storage via NFS or MySQL for its configuration information.
Welp, the folks monitoring the chip in my head took that idea and created JeOS (pronounced Juice). Just Enough OS is the term for my micro-distribution. And trolling though Ubuntu’s site today I discovered they’ve got a JeOS version.
With the accelerated nature of the Virtualization Project I’ve got going at work I’m not gonna propose JeOS at this time. Heck, I’m not sure I’ll even have time to bring the P2V’ed servers up to the latest LTS release, much less split up services and migrate to a different edition. But I do plan to play with it some, and may propose it to IT for the radius server we’ll need to build.
So I run the Atlanta Linux Enthuisasts’ list on mailman. Recently the server has been running loads between 5 and 8 – way more than it should be. Doing a top showed python using most of my CPU. I tracked it back to mailman and the config.pck file which as 50M.
The problem came about due to spam sent to the ale-* administrative addresses. Each time a spammer sent an email to that list, it would add an entry to the hold_and_cmd_autoresponses variable in the config.pck file. Every time python needs to access the ale config, it had to decrypt the config.pck file which uses lots of CPU.
The solution is to overwrite that vaiable with a null. Its possible doing this could break someone trying to subscribe to the list, but eh, its a free list, they can re-try.
Create a file with the following in it:
hold_and_cmd_autoresponses={}
then run the following command from your mailman root:
bin/config_list -i /tmp/foo ale
/tmp/foo is the file I created and ale is the list I needed to fix. It dropped my 50M config.pck to 1.8M and my load issues have gone down dramatically.