As part of the numbers game, a disturbing trend is emerging. Organizations are using numbers to justify moving their I.T. budgets into the unmeasurable.

I have no numbers to support this idea; I’ve not done any real research on the issue. (I do think it would make a worthy study for a thesis or dissertation. Of course, this subject is not theoretical enough to qualify in any computer science graduate program! Perhaps a program in communications or information systems would allow such a study.)

If you still have no idea what I mean, don’t worry: I may have no idea myself! In an attempt to explain, I offer this scenario:

An organization with ten departments, including an I.T. department is looking to reduce expenditures. Immediately, managers notice that the I.T. department costs a considerable amount of money, but does not directly contribute to productivity. A little research reveals that most of what I.T. does can be outsourced: Move all the storage and applications into the cloud; use hired guns to provide desktop support and repair; pay an outside firm to develop, host and maintain the web presence; hire programmers on contract when needed. On paper, the savings are evident and profound. My question is: does this really help the organization?

There is an immediate and measurable savings to the overall budget in salaries, space, and supplies for the now defunct I.T. department. Therefore, a real reduction in expenditure. Right?

I propose that the savings are mostly on paper rather than an actual outcome.

The first effect is that repair costs are moved from the overall company budget to the departmental budgets. The savings can be measured at the top, but produce increased costs at the departmental level. Unless departmental budgets are increased to cover these expenses, departments are negatively impacted.

The new model inevitably increases down-time, since travel time is increased for the support personnel. (Before, the in-house people were already there!) Again, on paper this is not a direct cost. Increased down-time is difficult–if not impossible–to measure directly. We can only guess how much this costs the organization, but it does have a cost!

The biggest down-time increase may occur in server down-time. Out-sourced storage and applications cannot be directly managed. When something quits, someone has to call the provider, wade through the systems–both electronic and human–to communicate the issue and begin the process of resolution. In many cases, this will cause down-time for the entire organization. This is very costly and very difficult to measure!

As for the web presence: One of the most powerful features of web publishing is immediacy. Content may transform from an idea to a published article in hours. Since distribution occurs at near light speed, a discussion in a marketing meeting before lunch could be on the consumer’s screens before dinner! In a perfect world, similar results would occur with out-sourced web hosting. The decrease in connection speed caused by moving to an outside server is negligible. As long as the new content doesn’t require a professional web developer, outsourcing the web site has virtually no impact. Of course, if the changes do require a professional web publisher, the impact may be great. Depending on the contract and the outside firm’s abilities there may be additional cost and delays. Not so immediate any more.

Finally, I have great trepidation about moving storage into the cloud. Trusting mission-critical data to people and systems that I have not personally seen scares me. My vivid imagination and tendency toward worry lead me to envision an outside storage provider holding data hostage. In the theoretical perfect world, the contract with the storage provider would guarantee the safety and availability of data and the company would fulfill the contract flawlessly. Since the world I perceive is less than perfect, the possibility of losing access to needed data because of reaching a contractual bandwidth or storage limit seems real and terrifying. If the storage provider were unscrupulous or incompetent, disaster may well ensue: corporate secrets sold to competitors, security breaches leaking sensitive information.

I freely admit that I currently make my living providing in-house I.T., so my view is skewed, but I am compelled to warn people that make decisions about budgeting to understand the difference between real savings and moving expenses into the unmeasurable. Pretty numbers in a spreadsheet provide little solace after an organization suffers grave damage from a well-intentioned mistake. Know also that the I.T. people that lose their jobs are not going to return begging when the error comes to light and the new I.T. department is hiring!

Peace,
Stu…

This drastic action comes in the wake of reports that DigiNotar was tricked (hacked) into issuing over over 200 fraudulent SSL certificates.

As of the time of this writing, Internet Explorer 9 (9.0.8112.16521, a.k.a. 9.0.2) and Opera 11.51 build 1087 both allow access to https://www.diginotar.com/ which is blocked by the latest Chrome and Firefox versions.

Update (September 6, 13:21 EDT, US): I just got a Windows Update that makes Internet Explorer 8 (8.0.60001.18702) on Windows XP reject the SSL certificate for https://www.diginotar.com. Also got an update for Windows 7 (KB2607712) that resolves the issue on IE9. We’re making progress!

Update (September 6, 19:26 EDT, US): Finally got a chance to check Internet Explorer 9 on my Vista install at home.  The same optional update (KB2607712) is available for IE 9 and resolves the issue.

On a related note, the domain mozilla.com is redirecting to mozilla.org this morning. (And yes, they are still offering Firefox 6.0.1.)

Update (September 6, 19:33 EDT, US): the redirect to mozilla.org is still active, but Firefox 6.0.2 has been officially released and is available from http://www.mozilla.org/ as has been Firefox 3.6.22 (available from http://www.mozilla.org/en-US/firefox/all-older.html).

Among the domains targeted by the SSL certificate thieves are the sites of several intelligence agencies.

According to some sources, the SSL authority’s site may have been breached in May 2011. Others conjecture that the latest hack is a second event, perhaps by a different group/individual.

All in all, Internet gets scarier every day!

Peace,
Stu…

So, what does that have to do with site redirection?

My guess is that a hacked certificate has been discovered for mozilla.com.  This morning I found that attempts to browse the site mozilla.com are being redirected to mozilla.org. Even the beloved What’s New page, redirects to mozilla.org.

So, back to the versions of Firefox that revoke the DigiNotar certificates: So far, I’ve found updated versions for Firefox 6 (6.0.2) and Firefox 3.6 (3.6.22). I tested Firefox 6.0.2 on the URL https://www.diginotar.com/, and it does block the SSL connection attempt with a message that the “Peer’s Certificate has been revoked.”

As of the time of this writing, the redirected page http://www.mozilla.org/en-US/firefox/fx/ is still offering Firefox 6.0.1 for download, however: if you hack the download URL, you it will deliver version 6.0.2!

I’ve updated my directions for building and installing the latest Firefox on Slackware64 13.37 to reflect the shiny new (as-of-yet-unreleased) version.

Considering the fraudulent SSL certificates along with recent DNS hacks in the news, the web feels a little less safe today.

As a starting point, I downloaded the entire build directory from slackware64-current. I chose the mirror slackware.oregonstate.edu. (I suggest using http://slackware.com/getslack/ to find a suitable mirror.) Using FileZilla, I grabbed the entire directory slackware64-current/source/xap/mozilla-firefox/ and put it in /usr/src on my workstation.

Try 1:

1. Set the SlackBuild script as executable: chmod a+x mozilla-firefox.SlackBuild
2. Run the script: ./mozilla-firefox.SlackBuild

As so often happens, I encountered a problem:

configure: error: Can't find header iwlib.h for Necko WiFi scanning (might be in package libiw-dev (Ubuntu) or wireless-tools-devel (Fedora) or libiw-devel (openSUSE)); use --disable-necko-wifi to disable
make: *** No targets specified and no makefile found.  Stop.

Since I don’t even know what necko-wifi is or does, I took the advice of the error message and added –disable-necko-wifi to the script mozilla-firefox.SlackBuild.

Try 2:

1. I used vim to edit the file and found the –disable-whatevers and added the line
   --disable-necko-wifi
just after the line:
   --disable-profilesharing \
2. Run the script: ./mozilla-firefox.SlackBuild

Sucess! Woohoo!

Being a careful and methodical–pronounced: scared and anal-retentive–person, I backed up my Firefox profile:

1. Open Firefox
2. From the Tools menu, select Clear Recent History
3. In the Clear … History dialog box, select Everything for Time range to clear
4. Under Details, make sure only Cache is checked.
5. Click Clear Now
6. Quit Firefox
7. In home directory (type: cd and press <enter> to get there), type:
   tar zcvvf /path/to/backup/dotmozilla20110904.tgz .mozilla

Now, if disaster strikes, I can get back to where I was before this exploration!

Finally, I upgraded Firefox using the new package:

su
cd /tmp
upgradepkg mozilla-firefox-6.0-x86_64-1.txz

When I ran Firefox, I was greeted with a message telling me that my version was out of date.  It seems that version 6.0.1 has been released. Back to the drawing board.

Try 3:

I snagged the Firefox source file firefox-6.0.1.source.tar.bz2 from ftp://ftp.mozilla.org/pub/firefox/releases/6.0.1/source/ and put it with the other files. Then deleted the old source file firefox-6.0.source.tar.bz2, to ensure the new one will build.

Once again, I ran the script: ./mozilla-firefox.SlackBuild

And again, success!

Now I upgrade the 6.0 version to 6.0.1 using:

su
cd /tmp
upgradepkg mozilla-firefox-6.0.1-x86_64-1.txz

Ah, life is good! WordPress no longer complains about my Firefox version and my few extensions and plug-ins work just fine. I suppose at this point, I could have quit. But what about that necko-wifi error? What is necko-wifi, anyway.

A bit of research leads me to believe that necko-wifi uses libiw-dev to do geolocation. A little more digging reveals that the Slackware package wireless-tools from the n set installs that header file. Well, I don’t use geolocation, but I decided I would try the build and install one more time, just to see . . .

Try 4:

1. Pop in the Slackware DVD and install the package wireless-tools-29-x86_64-6.txz
2. Open a shell, and edit the SlackBuild file, commenting out the line I added in step 1 of Try 1.
3. Run ./mozilla-firefox.SlackBuild for, what I hope, is the last time.

And yes! Yes! Yes! It builds!

So, I removed the package I installed in Try 3 and installed the newly-built package. Sure enough. When I browse to http://www.google.com/maps/m, I guess a message that www.google.com wants to share my location. Clicking x, I choose to congratulate myself on another puzzle completed (and not to reveal that I’m sitting in my home office/studio in front of the computer.

Happy Daze!
Stu…

http://slackware.com/security/viewer.php?l=slackware-security&y=2011&m=slackware-security.453304

NOTE: Building Mozilla Firefox depends on the package wireless-tools.  If it’s not already installed, install it from /slackware64/n/ on your Slackware CD or grab it from a Slackware mirror. (Alternatively, you can take a look at my hack to the SlackBuild file.)

NOTE: The resulting package will run whether or not wireless-tools is installed.

1. Get the SlackBuild files from slackware64-current/source/xap/mozilla-firefox/ on a Slackware mirror. You’ll need these files
   • :firefox.moz_plugin_path.diff.gz
   • firefox.png
   • mimeTypes.rdf.gz
   • mozilla-firefox-mimeTypes-fix.diff.gz
   • mozilla-firefox.SlackBuild
   • mozilla-firefox.desktop
   • slack-desc
2. Put them in a convienient place to build. (I like /usr/src/mozilla-firefox)
3. Grab the Firefox source file firefox-6.0.2.source.tar.bz2 from ftp://ftp.mozilla.org/pub/firefox/releases/6.0.2/source/ and put it with the other files.
4. Open a shell and cd to the directory in which you put the files in steps 2 and 3.
5. Set the SlackBuild file executable:chmod a+x mozilla-firefox.SlackBuild
6. Run the SlackBuild:./mozilla-firefox.SlackBuild
7. After a bit of churning and whirring, you should end up with a package in /tmp named mozilla-firefox-6.0.2-x86_64-1.txz
8. To install the package, just open a shell as root.

If you have a previous Mozilla Firefox Slackware package installed, type:

upgradepkg mozilla-firefox-6.0.2-x86_64-1.txz

If not, replace the line above with:

installpkg mozilla-firefox-6.0.2-x86_64-1.txz

Cleaning Up:

At the end of this process, you’ll be left with some extra stuff in /tmp.  To get rid of it:

1. Move (or copy) the package file mozilla-firefox-6.0.2-x86_64-1.txz to a safe place.
2. If you copied the file in step 1, delete the file mozilla-firefox-6.0.2-x86_64-1.txz
3. Delete the directories mozilla-release and package-mozilla-firefox

Happy Surfing!
Stu…

P.S. If you’re interested in how I got this to work, take a look at the journal of my journey.

P.P.S. Updated for 6.0.2 (we miss you, Mozilla.com -)

I finally got fed up with messages from places like United Way of the Bluegrass and The Lane Report who added me their lists without my permission.  Sure, I clicked the unsubscribe link in the messages, but it seemed like I was getting added to a new Constant Contact list every week.

I decided to do something: I called Constant Contact using the toll-free number on their web page. After a short wait, I spoke to Derek (no last name) and explained to him that Constant Contact clients were adding my work email address to their lists without my permission. I asked if there was a way to have my email address removed from all of their client’s lists. He told me “yes,” and transferred me to customer care.

Another short wait later, I spoke to Mike (again, no last name–perhaps they are brothers!). I told Mike that I wanted to be added to the do-not-spam list. Of course, he had never heard of this and assured me that no such list exists. Ever helpful, he suggested that I click the unsubscribe link in the messages.

I explained that I seemed to get added by yet another Persistent Prattle customer every week and that I was growing tired of the unsolicited messages.

Again, he assured me that Constant Contact does not have a do-not-spam list.

I suggested that, being postmaster@where-I-work, I should block all mail from Constant Contact. He pointed out that I might, in the future, want to receive messages from Constant Contact clients and again suggested that I should just click the oh-so-easy unsubscribe link. I told him that my work email address is for work and that if I ever did choose to be spammed by Constant-Pain-in-the-Ass, I would use my personal email address. Again, I said that the obvious answer was to block all messages from Constant Crapola on our server. Using his mad skillz in customer care, he said that he would gladly give me the list of the servers from which Constant Blah Blah Blah sends messages if only I would give him my email address. I laughed!

I carefully explained to him that I was calling to stop the email from Alliterate Annoyance and that it seemed counter-productive to give my email address to the very source of the messages I wished to terminate. I offered my assurances that I could use whois all by myself to get the netblocks I needed to shun. Once again, he asked for my email address in an heroic effort to save me the trouble of opening a shell and typing. I declined.

After saying our fond farewells, I looked at the header of the most recent message I received from Everlasting Burden and grabbed the server IP: 208.75.123.135

Using whois, to locate the netblocks, I set our mail server to reject everything from the following:

205.207.104.*
205.207.105.*
205.207.106.*
205.207.107.*
208.75.120.*
208.75.121.*
208.75.122.*
208.75.123.*

For the sane and rational among you, that is the end of the story.

For the rest . . . well . . .

Having some experience getting the iSight going with Linux, I knew that I needed to extract and install the iSight firmware. Using the Ubuntu help site’s Mactel Support Team iSight page as a reference,  I grabbed the iSight firmware tools, then extracted and installed the firmware in /lib/firmware.

The Ekiga test worked wonderfully! Much to my delight, the Cheese test also worked. I was in business . . . or was I? On reboot, Cheese no longer worked. Grrr! A bit more experimenting showed that Ekiga still worked and, after running Ekiga, Cheese worked. Poking around I found that running lsusb from the console, showed that the iSight firmware didn’t load on startup.

I wasted a bit of time trying this and that.  Over and over, the firmware did not load until I ran Ekiga: not an optimal setup.

This morning, I finally found this wonderful post by Ubuntu Forums member JerkyChew. Running the three simple commands suggested fixed the iSight! Thank you and hats off to JerkyChew!

Happy Hacking!
Stu…

I used the WordPress text widget to implement a CSS menu.  The original design used <div id=”menuname”>. Then, one of the publishers informed me that when the menu was updated, the id=”menuname” went away when the widget was saved.  Eeek!

I tried it for myself.  Sure enough, as an administrator of a sub site, one cannot use id=”menuname” in a text widget.  As the super admin, this worked fine.

No fear; the solution is simple: Just change the style sheet to use a class instead of an id and it works!

I revised the theme style sheet, making the menu as .menuname (instead of #menuname), installed the new version of the theme and updated the sites that used the menu (to use class=”menuname”).

TL/DR — Use class in WordPress text widgets because id doesn’t work for normal administrators in a multi-site install.

After wasting much time creating a Window-Specific behavior–causing my KDE theme’s minimize, maximize and close buttons to disappear–I realized that what I was looking for was actually a setting in Chrome’s options. Color me red!

To make Chrome 6.x look like it did in the 5.x days, select Options from the Customize and control Google Chrome widget (the little wrench on the right: ). Click on the Personal Stuff tab, under Appearance, select the Hide system bar and use compact borders radio button:

Ah, things are much better now . . . at least back to the way to which I have become accustomed!

Happy Hacking!
Stu…

When I checked in System Settings -> Desktop -> Desktop Effects, I saw that “Compositing has been suspended by another application . . .” I clicked the Resume Compositing button, but once again received the message and found that “Compositing is temporarily disabled.”

After a bit of searching, I found a post on the KDE Community Forums where a Kubuntu user had solved this issue by checking Disable functionality checks on the Advanced tab. Figuring it was worth a try, I checked the box and clicked the Apply button.  Oops! My desktop became pale blue nothing!

Using the CTRL+ALT+BACKSPACE key combination, I shut down X.  Then, from the shell, I poked around my .kde directory and found the setting in .kde/share/config/kwinrc as “DisableChecks=true.” So, I removed this line from the file and started X once more: still no compositing; no effects, but at least I had usable KDE. (See: there’s a good reason I don’t start the GUI automagically!)

At this point I was mildly frustrated. I couldn’t understand why upgrading Xorg server to 1.7.7 killed compositing. Heck, maybe was it the newly installed kdegraphics-4.4.3!?! Did I really want to fuss with reverting packages until the problem went away? Nope!

I figured it was time to punt, so I downloaded and installed the latest nVidia driver–as much to give my self something to do as in hopes that it would fix the problem. Once the driver was installed, I logged out as root and logged back in as myself.  Now the moment of truth! I typed startx and pressed my well-worn ENTER key. OMG! It worked! I have wobbly windows again!

So, time to check this on the MacBook which uses an nVidia 9400M. Same results: no compositing after the upgrade and upgrading the nVidia driver fixed the issue.

The TL/DR of it all is: If upgrading Slackware kills your nVidia card’s compositing, just update the nVidia driver to 256.44 and life is good!

Happy Hacking!
Stu…

P.S. I was previously using nVidia driver version 256.35.