Is tomorrow going to be the big implosion of the stock market that drags us into a global recession, or what?

I am terrified, but I just put a limit order in for SZK ;)

Guess we'll see tomorrow. Hang on tight folks.

After testing elasticdrive all week (painful and repetitive, but necessary), I stumbled upon an idea to radically improve throughput.

The original ED implementation was not a good performer for RAID5, due to it's multithreaded architecture, but the new version supports an ordered read/write model, and has a much lower cpu and memory footprint...

Turns out that when you are interfacing something to the kernel, it is a REALLY bad idea to log to stderr, ESPECIALLY if it is exceedingly rare, and only in your debug logging code. Grrr.

Just got back from the future shop (evil). While I generally loath them, I have a hard time getting angry at a $99 500G hard drive. They have literally thousands of these things lining the entire store. I cannot imagine how they even manufacture these so cheap.

It used to be (in the old days) that after moving out, the worst a nerdy young sprog had to worry about was . the occasional computer maintenance request from their parents. Times however, are changing. Nowadays parental units are far more likely to have a need for personal webmail, chat, picture management, and even a CMS.

More after the break...

So, the rant server is slowly getting moved over to my new Xen/Enomalism based, s00per chr00ted nginx/fastcgi installation. Everything is going rather well. Safe mode didn't break anything (so far), and smf forum was a breeze to set up again.

One neat thing I started working on was wildcard DNS based subdomains. Rant has a LOAD of different domains, all living in subdomains of the main vhost. The old method was a bunch of different vhost definitions, but since I didn't feel like re-entering them in the new nginx method, I figured I would come up with a better way.

More after the break...

Just a note to self. In the case of a serial console never getting around to the login prompt on a Xen DomU, even though it still displays all of the normal console boot messages, just change /etc/inittab as follows:

1:2345:respawn:/sbin/mingetty tty1

1:2345:respawn:/sbin/mingetty --noclear console

Also note: Why do we still call these things tty(s)? That is SOOO 70s!

Just a heads up, Enomalism version 0.7.2 has been released. Tonnes of bugfixes, and some new features (the Firewall module is functional now).

• New firewall module can create firewall rules in the Dom0 which do not require iptables support in the DomU. Great for additional security on insecure DomU images.
• New CentOS 5 VM image in the VMCasting feed.
• Much more extensible API, with hooks on all functions for extending Enomalism with new features.
• Widget style modules, which work with TurboGears widget system.
• Intelligent thread locking and queueing throughout entire Enomalism core to prevent blocking and deadlocks.
• Improved caching and lower utilization in all Enomalism libraries.
• Better non-blocking calls for starting and stopping virtual machines
• Improved CPU usage monitor for DomU machines
• Selenium based regression tests for UI.
• Better provisioning management tools, with feedback on space free, and

So... Twisted has an issue. A very annoying one.

Subprocess doesn't work. The reason? No idea ;) Twisted installs default signal handlers for EVERYTHING, which results in some odd behavior. The specific problem we are running into with Enomalism is here (via bug 2535):

Twisted currently needs to install a SIGCHLD handler for reactor.spawnProcess to work reliably. This is problematic when Twisted is used with other libraries that depend on SIGCHLD (e.g. the standard library's subprocess module depends on SIGCHLD being left as SIG_DFL, otherwise it can get EINTR at unexpected times). Hence the reactor can be run with the installSignalHandlers=False flag, but then reactor.spawnProcess isn't reliable.

Seriously though, launching subprocess calls from inside Twisted python is a good way to end up with a dead reactor. To get around this, make sure that you call your subprocess Popens from inside a Fork, whenever possible. This means that if you pull libraries in that need to use subprocess, the twisted web methods MUST fork before calling. You can check the return codes using return values, or redirect to a stdout file descriptor if necessary. Actually, if you want (unlike me) to not be an idiot, this little snippet completely works around the problem AFAICT except for the fact that reactor.spawnProcess will no longer work (nope. It still crashes, it just takes longer): THERE IS A COMPLETE WORKING LIBRARY POSTED WAY BELOW

I ran into some nasty bugs in RoR this weekend, so I thought I would share the fixes with you briefly, and perhaps get somebody to email me with a link to a fix to a separate nasty bug I have not been able to remedy...

This is what I was seeing on a new rails install inside of Webrick (mod_ruby/CGI/fastCGI failed to work at all):

Expected /var/www/vhosts/NAMEOFCLIENTGOESHERE/rubysite/controllers/home_controller.rb to define HomeController

No end of messing with the config would help, but I found some useful advice here: Slicehost Forum Post. Reinstall an old rails. LAME!

gem uninstall rails
gem install -v=1.1.6 rails

Admittedly, I had to rewrite some stuff with the refactorings on TurboGears, but at least I could figure it out. This rails thing was totally impenetrable.

Next, I ran against the wall trying to figure out how to get fastCGI working. FastCGI works on a new freshly created rails app, but fails utterly on this older one. IT is definitely something to do with the app specifically. Anybody seen this error before (and fixed it?):

Dispatcher failed to catch: You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.split (NoMethodError)
  /usr/lib/ruby/1.8/cgi.rb:897:in `parse'
  /usr/lib/ruby/gems/1.8/gems/actionpack-1.13.3/lib/action_controller/cgi_ext/raw_post_data_fix.rb:45:in `initialize_query'
  /usr/lib/ruby/1.8/cgi.rb:2274:in `initialize'
  /usr/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:606:in `new'
  /usr/lib/ruby/gems/1.8/gems/fcgi-0.8.7/lib/fcgi.rb:606:in `each_cgi'
  /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:141:in `process_each_request!'
  /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:55:in `process!'
  /usr/lib/ruby/gems/1.8/gems/rails-1.2.3/lib/fcgi_handler.rb:25:in `process!'
  ./dispatch.fcgi:24
killed by this error