Lewis' Blog Tales from the trenches of information technology

28Sep/143

Updating bash to patch Shellshock on discontinued CentOS 4.8

By now, this week's news of the Shellshock vulnerability has quieted to a bit of a rumble. What a mess, and to think that this exploit has been possible for such a long time...

What to do about old Linux distros, then? Yes, the rule of thumb is that if the distro is no longer widely supported, one should move off of it, or at least put it behind something more secure. But what if there is a single application which requires just that particular old distro, and will not play nicely with anything newer, and what if that particular app is proprietary, and no longer available?

26May/130

Updating the TCPDF library in Joomla! 1.5

TCPDF is an excellent PHP class for creating PDFs from dynamic (or static, for that matter) web content. Unfortunately, the version of TCPDF bundled with Joomla! 1.5 (all 1.5 releases after at least 1.5.8 - someone please correct me if I am wrong - was version 2.6.000_PHP4, dated March 7, 2008. It's also not very PHP 5.3-friendly (there are other parts of Joomla! 1.5 which are not fully compatible with PHP 5.3, but this article will focus on TCPDF). Time to freshen up, methinks.

12May/130

Migrating a bare-metal Windows 2000 install to a VirtualBox guest

A client's sole remaining W2K box started having boot issues the other day. It had been on the slate for about a year (or two or three) for an upgrade, but somehow, it just kept chugging along, so we left it be. Well, after confirming that the drive hardware (80GB Western Digital SATA) was in good shape (I did this from a Parted Magic USB stick boot, running just some rudimentary SMART diagnostics), and yet still unable to get W2K to move beyond the first graphical screen during startup, we decided that the time had come for a change.

16Dec/115

Broken Windows updates for .NET

Ah, into the land of (broken) Windows we go...

I despise Windows. Have I said that before? Here, in case I haven't, I'll say it again. I despise Windows. That feels better. It's good to get such things off one's chest. What a hopelessly broken operating paradigm. Oh, well. It's gotten better, I guess. that is to say, it used to be even worse.

I've been spending much time of late working between zypper and yum on various flavors of Linux and now, eComStation, which has its own port of yum. Of the two, I prefer zypper, though either is head and shoulders beyond the inane Windows patching system. However, when in Rome...

7Dec/110

CRTs vs LCDs in 2011/2012

An interesting thread cropped up on the eComStation Technical mailing list on Yahoo! in the past few days. One of our list members was inquiring about the ability to set refresh rates in the Panorama video driver. Short answer: you can't (well, at least, not yet). This is covered in the VESA FAQ. Apparently, the original poster has a CRT which requires proper tuning of the driver for his monitor's refresh rate. One of the first responses to come back to him (aside from the correct answer, pointing him to the FAQ) was the obvious question: "Why are you still using a CRT?"

I suppose what has amused me the most about this little exchange was the assumption that by now, CRTs have become yester-tech, and that *all* truly modern systems (this was a fresh install of eComStation 2.1) should be outfitted with LCD monitors.

I was going to jump into the post, but instead, I'll just migrate some excerpts here, and include my own commentary at the end.

7Oct/110

Ramdom thoughts on the 2011 (and beyond?) Firefox release schedule

As I sit here at Panera Bread, catching up on some tech news, an article caught my eye concerning Mozilla's new approach to updates and, tangentially, the (revised) 2011 Firefox release schedule. This started my own wheels turning, as this has been a bit of an annoyance for me, so I thought I'd just jot down a few ideas...

Concerning Firefox's 2011 release schedule:

Why?

We (I say "we" because I do/have contribute(d) from time to time) have some bugs in Bugzilla which date back several years (some to the Netscape Communicator days, inherited by the Mozilla project - no kidding!). These have yet to be quashed, and all the while new "releases" just keep coming down the pike, bringing with them their own share of new insectoids. Wouldn't it make more sense to stay at a reasonable "release" level, and just fix it before adding new features (and after all, isn't the purpose of a new "release" to introduce new features)? We already have a mechanism in place for extending the functionality of the browser through plugins and extensions, anyway, so what's the point? (If Mozilla wants to emulate Redmond, then they should consider that under the hood, Windows 7 is NT 6.1, anyway, and Microsoft got a head start with NT growing out of OS/2 - NT started at version 3.)

18Sep/110

Updating Firefox on Linux: the Dreaded “Couldn’t load XPCOM”

I bumped into this annoyance while updating my openSUSE 11.4 workstation tonight.

There are numerous mentions of this issue on the net, and numerous suggestions for addressing it. However, none of them (which I saw) really hits on the underlying problem, which is that somewhere, somehow, XPCOM can't start.

To understand what's going on, it's important to have a basic understanding of what XPCOM is, and how it is involved with Mozilla apps. XPCOM is an acronym for  "Cross Platform Component Object Model," which is Mozilla's equivalent technology to CORBA or Microsoft's COM. Like any other "object model," XPCOM's function is to provide a modular framework vs a monolithic one. This modularization allows XPCOM to be (mostly) platform-neutral, making it possible to run the Gecko rendering engine on a variety of platforms. So, as the Gecko engine is composed of XPCOM components, if XPCOM cannot start, Gecko cannot start. If Gecko cannot start, then there is no rendering engine for the application, essentially stopping whichever Mozilla-based app one might wish to run, before it even gets started.

22Apr/111

The Telltale Hard Drive

And so it came to pass that my 160GB 5400 RPM Travelstar in my ThinkPad T43 became full. In late 2010, finding large 2.5" PATA drives was becoming more and more difficult. Searching, I found that Western Digital had just what I needed: a 320GB 5400 RPM Scorpio Blue.

I ordered the drive from a trusted supplier, never looking to find complaints about newer Scorpio or "Green" models (not that I would have necessarily viewed a Scorpio as a "green" drive, anyway). The price was acceptable, and the shipment was quickly delivered.

Using my favorite cloning utility, DFSee, I cloned much of my trusty Travelstar to the new Scorpio Blue. Some partitions needed changing, though: my handy HPFS eCS maintenance partition, for example, really needed to be migrated to a JFS volume, and my type 35 JFS data volume, consisting of two segments, really cried out to be recreated as a single type 7 JFS partition. As such, these took a little more manual work (read: xcopy /s/e/r/h/t).

Ah, the fun...

10Apr/110

Rsync error 5 may be exactly what it says

I use (and love) rsync on a variety of platforms. On Windows, about the easiest implementation I've found is DeltaCopy.

Recently, though, I've been seeing a problem at a particular client running DeltaCopy, and only for one machine (which happens to be the box running the server component, as well. Wanting to rule out the obvious, I suggested he run a full chkdsk pass against his local drive. After that, we got a slightly different error message:

@ERROR: chdir failed
rsync error: error starting client-server protocol (code 5) at /home/lapo/packaging/rsync-3.0.4-1/src/rsync-3.0.4/main.c(1504) [sender=3.0.4]
Error starting client-server protocolRsync.exe returned an error. Will try again. This is retry number 1 of 5

Well...

Various sources on the net point to bad passwords, tabs in command lines, and such. In fact, I originally suspected a bad password...until I went looking.

All of the jobs for this machine back up to an eSATA-connected RAID volume. I have one directory for each day of the week located under the root of the volume. Well, upon browsing the volume's contents, I found that all of my backup directories (virtual directories, in DeltaCopy-speak) were gone! So, apparently, chdir did indeed fail, as there was no target directory available.

I re-created all of the daily directories, set it off manually, and it is happily backing up as I write this.

Go figure.