I had a backup. Really.

Not just a tech blog...

Pretty much what I write about here is technical, with occasional forays into California politics or other odd things, but I've been doing lots of cooking on my water smoker lately, and my friends all said I had to start a foodie blog.

Well, I guess I can do that, if only to keep the food stuff out of the technical blog (there is only a small amount of overlap in the target demographic). The Introductory Post begins:

---

Starting My Smokeblog

I've always cooked on the grill, and some years ago had gotten some experience with a smoker, but most of it went idle... until recently.

After discovering the joys of a real-deal rotisserie, after getting a good quality water smoker, and after a few entirely successful test runs, I've pretty much hit my stride. Nearly everybody who's been the benefit of my "testing" has suggested I write a food blog, so I've decided to give it a go.

My perspective will be fairly narrow: I'm not about recipes, almost never about fancy stuff, and I'm positively not an experienced cook (I'm not licensed for indoor cooking). But I do approach grilling / smoking with an engineering eye, and this perspective is different from what I find in the usual BBQ books.

I'm still (re-)gaining experience, and I hope to again challenge my brother-in-law Marty, who is fantastic with the fire. A spirit of friendly competition is good for all of us.

I hope that my experiences will help others getting started at this, encouraging them to try new stuff: at first one must take baby steps, but it doesn't take long to get your mojo and start with your own creations.

Let there be smoke!

---

Those interested can follow along at SmokeBlog.unixwiz.net

New Tech Tip: Expanding RAID1 arrays on Dell PERC 6/i Integrated RAID controllers

A customer with several modern Dell servers wanted to expand the RAID 1 arrays on each, and I was able to do this without backup-and-restore to external media: this saved a ton of time (though I did do a backup up front just-in-case).

This was useful enough that I wrote it up in a Tech Tip, in the hopes it may be helpful to others:

Extending a Dell PERC6/i RAID1 Array in place

But two important notes:

• RAID1 only — will not work with any other level
• PERC6/i only — has not been tested (or even looked at) on any other controller

Good luck!

Process-creation bug in SocksCAP

This is written for Google/Bingle — regular readers of this blog won't care about it at all.

I recently had to diagnose a problem with SocksCAP 2.40, a Windows program described as:

---

Automatically enables Windows-based TCP and UDP networking client applications to traverse a SOCKS firewall. SocksCap intercepts the networking calls from WinSock applications and redirects them through the SOCKS server without modifying the original application, the operating system software or drivers.

---

A customer of a customer was using this in a heavily locked-down environment, where all desktops were required to run through a proxy server, to enable some line-of-business software which did not honor proxy settings on its own. SocksCAP intercepted network calls to run them through the local SOCKS proxy.

The application ran fine until it attempted an app-specific auto-update. After successfully fetching the updated files to a temporary directory, it attempted to run an updater program which would install and patch the program in place. This failed every time.

At first we were sure this was a bug in the application itself, but it turned out to be SocksCAP.

SocksCAP was intercepting the CreateProcess() call from the main app so it could automatically SOCKS-ify the subprocess (definitely a helpful/useful trick), but it was not able to handle the very long command line required by the auto-updater program.

After enabling logging in SocksCAP, its logfile showed the full, correct command line, but Process Monitor from Microsoft SysInternals showed that CreateProcess() was given the corrupted command line.

It looked to me like it was blowing up after around 256 characters, so this has all the hallmarks of a fixed-length buffer with a poorly-chosen size.

Since the updater command-line included several filenames based on %TMP%, our workaround changed %TMP% to C:\T\ instead of the long Documents-and-Settings path that's the usual. This brought the command line under the blow-up limit.

I've not been able to find the source, or even recent support, for SocksCAP, so I doubt that a real fix will ever happen, but hopefully this post will help others in my place get to the bottom of this with less pain than it took me.