Lewis' Blog Tales from the trenches of information technology


Multiple default routes / public gateway IPs under Linux

I recently had the need to configure a server for a client with multiple public IPv4 addresses routing to the internet and the requirement to switch between them at will while browsing (http traffic only).

There are a number of articles available on the net dealing with this type of situation, mainly focused on using iproute2, ToS tagging, and Squid (see references, below). However, I bumped into an issue with openSUSE 12.1 where it would stubbornly refuse to accept certain (otherwise valid) ToS (DSCP) values (see https://bugzilla.novell.com/show_bug.cgi?id=770785 for my bug report). This severely limited the number of possible values I could use, and thus, the number of possible public IP addresses.


Mass renaming files at the OS/2 command line

An interesting head scratcher to which I have been returning almost monthly for some time is the distinct lack of ability to rename files based upon a mask at the OS/2 command line (in a minute, I'll explain why this is a fairly regular occurrence). Of course, OS/2's cmd.exe is not alone in that regard; DOS' COMMAND.COM, 4DOS, 4OS2, JdeBP's 32-bit CMD, Windows' CMD, and even the *nix shells with which I'm familiar don't naturally lend themselves to this kind of flexibility (okay, I lied: you can do it with Bash, of course; see below).

Why a monthly occurrence?

I don't normally send paper invoices to clients anymore. Not only does it kill more trees than it's worth (and no, I'm not an environmental zealot; we grow new trees every day - I'm just the guy who has to buy the paper and the laser toner), but the postage has over the years become a major factor in this decision. Anyone who has to regularly bill clients for outstanding balances knows from whence I speak; send the same client a dunning notice for six months, and that $150 bill has just been whittled down to $147.36 ($0.44 * 6 = $2.64; $150 - $2.64 = $147.36). This just adds the insult to the injury.


More fixes for 64-bit OES (ConsoleOne)

I don't know. This whole 64-bit thing is a bit of a pain. Essentially, one must maintain two sets of libs: one 64-bit and one 32-bit. Yes, that's right. For those of you who haven't yet had the joy of working on a 64-bit system, there's quite a bit of fun in store for you.

Take ConsoleOne, for example. On 64-bit OES2, after fixing the iManager (Tomcat) issue (see Fixing a Broken iManager 2.7.3 install on OES2 SP1 Linux), I happened to log in again today and by chance hit the launcher I placed on the desktop for ConsoleOne. Oops...

ConsoleOne appeared to start, then gave me:

ERROR: java.lang.NoClassDefFoundError: java/lang/StringBuilder

Wasn't that nice?

Dropping to a terminal, I moved to /usr/ConsoleOne/bin and tried to start it like so:

./ConsoleOne -debug -windowout

which revealed nothing in any greater detail (although I suspect that had I taken the time to explore the output thoroughly, there was probably a bigger hint in there...somewhere).

A quick search through the Novell knowledgebase came up with TID #7002647, which was just what I needed. Indeed, ConsoleOne was trying to launch using the default JVM (64-bit) instead of the bundled 32-bit JVM.

All that was required to fix it was a quick edit of /usr/ConsoleOne/bin/ConsoleOne to add:

export  C1_JRE_HOME=/usr/lib/jvm/jre-1.5.0-ibm

to the environment for the app, and indeed, this is something of a "known" issue.

Just another one of those 64-bit annoyances...


Fixing a Broken iManager 2.7.3 Install on OES2 SP1 Linux

I had occasion a couple months ago to upgrade the last NetWare 5.0 installation (no kidding!) we had in the field. Despite everything I'd read about the NetWare to Linux migration tools being fixed and working much better than previous releases, it was sheer agony, and certainly not worth the effort for an eDirectory tree consisting of five users and 4GB of data.

I migrated the hardware from an Acer Altos 930 with dual 233MHz PII's and 512MB RAM to an HP DL380 G4 with dual Xeons and 4GB RAM. Considering that the hardware was 64-bit capable, I went ahead and (probably against my better judgment at the time) installed the 64-bit version of SLES 10 & OES2 on the new box (more on the whole 64-bit mess in another post).

I'll probably post yet another note about the agony of the migration from NetWare 5.0 to 5.1 to 6.0 to 6.5 and then to Linux, but suffice it to say that I had to re-do the install several times along the way, just to get a clean setup (I was never able to get the files to migrate; those I copied manually from a USB stick on a workstation!). Somehow, in the process, iManager broke.

I followed the steps in TID 7003152 to the letter. I even reinstalled the entire OS (no kidding; I was tired & frustrated at that point). Still, every time I would apply updates, iManager would break.

Last night, in between some other work, I had another look at the problem (hurray for VNC!). It turns out that something broke the Tomcat install as well as messing up a call to what should have been the 64-bit mod_rewrite Apache module (in the iFolder Apache confs). Tomcat was a bit tougher to figure out, but once I fixed the mod_rewrite issue and at least got to a Tomcat 503 error page when trying to access iManager, I knew I was in the home stretch.

I have a note about the fix for this here.