I was amused by the first request for FTP and control panel–I’m guessing this means CPanel–access to our Drupal site. We don’t use FTP–it is unnecessary  it with Drupal–and we certainly don’t use CPanel! My first estimation of the skill-level of the person making the request was quite low. I guess these folks are used to charging big bucks to set up an eight page web site using cheap shared hosting.

FTP? Seriously?!? Universities dropped plain-text password FTP protocol years ago in favor of SSH. While FTP and SFTP (via SSH) were useful back in the static HTML days, they seem useless for CMS-based sites, like those we build with Drupal and WordPress.

<aside>I understand that I am quite a snob when it comes to computers and web sites: I write web apps using vim.; I compile Apache and PHP myself, in order to tune them for the hardware and ensure that my installs have only the modules I actually need. Hell, this blog lives on a VPS machine as opposed to some silly hosting-with-training-wheels server.</aside>

OK, back to the request. The third part of the request was access to our Drupal site. Since we’re a largish public institution, we have tons of rules, laws and policies. This request was subject to our web policy, which requires that all Drupal users be vetted by the website leadership team. Of course, the team unanimously said, “no!” Partly because we have no way of knowing the skill set and trustworthiness of the individual(s) requesting access. The biggest reason was that access to the Drupal site would be little help in copying the site. It would be much easier to rip the site using wget–or whatever the Windoze equivalent might be–than trying to wade through and copy the content via the Drupal interface.

In lieu of this, in case it was beyond their mad skillz,  I offered to provide the content of the pages ripped to HTML files and zipped, guessing that .tar.bz2 and .tar.xz are meaningless to them. They asked for the rip ‘n’ zip. (Why am I not surprised?)

I wrote a script to grab the page content from the MySQL database from which Drupal generates the site and create a directory full of HTML files. Then I began an audit on the published pages, to see which ones are used and which are outdated, left-over, redundant or otherwise useless. Before I could finish the audit, I receive a message demanding the files and threatening to charge the department for whom the site is being built for copying the 100+ pages.

100+ pages? WTF?

Here I am looking that the 76 pages that are published on the site. Fine . . . no problem . . . I sent the .zip file with the 76 pages plus and index generated by my script and a couple .css files to make it all a bit prettier. Then I proceeded with my audit.

Sure enough, after my audit, my unofficial page count was 53 useful pages. I decided that, perhaps, the venerable website professionals were confused by the 59 course pages.  I attempted to explain that these pages are all generated by a single script. I can see how the appearance confused them: there are 59 different URLs.

Well, well, well . . . perhaps I should share the magic. Not with them, just yet. Rather, I’ll share it with you!

Apache web server can do really neat tricks with mod_rewrite. What I did was write a PHP script that will display information on a single course using information stored in a MySQL database. Then, using a couple of Apache configuration commands, got mod_rewrite to make this script appear as different URLs.

RewriteCond %{REQUEST_URI}  ^/DEPARTMENT.*
RewriteRule ^course/COURSE_PREFIX1(.*) /DEPARTMENT/courses?course=COURSE_PREFIX1$1 [L]
RewriteCond %{REQUEST_URI}  ^/DEPARTMENT.*
RewriteRule ^course/COURSE_PREFIX2(.*) /DEPARTMENT/courses?course=COURSE_PREFIX2$1 [L]

So, one script and two rules provides 59 URLs (not 59 different web pages).

It gets crazier: we have 7 departments. My single script along with 11 RewriteRules–one for each of the 11 course prefixes–provides 506 URLs with distinct output. But that’s not all. By adding another 11 RewriteRules, another 506 URLs display the same content with different wrapping in the “all courses” section of the college site!

So, one file on the server along with 22 RewriteRules and a database table with 506 records show up as 1012 URLs. Man, I do love PHP and Apache! (Back in the days of static HTML, this would have taken 1012 files on the server.)

I laugh at your 100+ files!

The response I received to my attempt to explain the groovy data-driveness was, “Oh, yes, I’m sure the new site won’t have any content at all. Just some graphics and happy face cartoons.” Smell the professionalism!

For the time being, I responded with a thank you for the sarcasm with the request, “Please remove me from this project and continue without my disruption.’ Then I logged on to the project management site and attempted to delete myself from the project. This, of course, was not possible.

So, I created a new alias on our mail server (devnull@oursite.edu), forwarded it to my junk mail collector account and set it as my email address on their brain-dead project management system.

It seems every day I become a bit more like the BOFL!

Update: It looks like our web professionals have decided to break university computing policy and are logging in using a faculty member’s credentials. I wonder if they figured out that I told them the truth yet!?!

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…