The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Friday, March 27, 2009


Yup. “Last Call with Carson Daly bumped Joe Lo Truglio to tonight's show. It was an okay interview, but no homemade movies.

Joe did, however, plug his site where, if you poke around you will find the films of The Early Years (which, are amusing in that “middle school tastelessly amusing” type of way—and yes, when we were kids we didn't have no fancy schmancy digital video recorders with THX Surround Sound Recording™ capabilities—nope, we had steeeenking 3′40″ of silent Super8 film and we liked it, up hill, both ways, in the snow!).

The animation is my friend Hoade all the way (who also makes a few appearances in this magnum opus, by the way, along with Hoade's sister).

Don't say I didn't warn you.

I swear I heard someone once say that control panels supposedly made things easier


Just received the following ticket:

Client uploaded their own work on the site and need to change the document root for the domain: XXXXXXXXXXXXXX

Please set it from “/var/www/html/” to “/var/www/html/app/webroot/”

The site is on: XXXXXX

No problem, right? Just go into the Apache configuration file and change DocumentRoot for the virtual domain in question. Trivial.

Only, the server the site is on has a <shudder> control panel on it, and whenever there is a <shudder> control panel involved, even the most trivial of changes suddenly involves rocket science [I thought I wrote about redirects involving a control panel, but I've yet to find an entry that does. Guess what's coming up next? —Sean]

Just for laughs, I decided to change DocumentRoot on the virtual site in question and make a change via the <shudder> control panel and just as I expected, my changes did not survive Insipid's mucking about.

A few searches revealed this bit of wisdom:

The following FAQ discusses how you can change httpd.conf on a per-site basis or globally such that the changes are not wiped out by XXXXXXXXXXX.


Wonderful! I thought. That's exactly what I need. I click on the link—


Oh, lovely I thought. I check the date on the answer I found, and it's dated July 8th, 2002. I guess Insipid doesn't quite realize that cool URLs don't change.

So, I go to the Insipid site and try searching on “FAQ”. The results of that search were:


But I was at some subdomain of the Insipid site. Okay, I went to the main page, searched for “FAQ” and got much better results. Apparently, the Insipid subdomain uses some now dead search engine, while the main Insipid site uses Google. Ah, I see a link labeled “Insipid Forum—FAQ” and click that.

I'm right back at the main Insipid page. Brilliant! Instead of serving up a “Page Not Found” page, they simply redirect to the main page. Wunderbar!

Poking around some more, it seems that the inspired leadership at Insipid has felt that there is no longer any need for any forums at their site, and thus, it's gone. I keep getting the main page.

So far, my searches have lead to pages that are either missing, or selling support, or are simply nothing more than link farms—ah wait! It seems Insipid was bought out by the company Perpendicular. Okay, try their site and look for “Insipid FAQ”.

And nothing that will help me.

Oh wait, this seems promising:

Document Root Problem with Ensim

February 8, 2006

I am trying to point the default /var/www/html folder to a subfolder of the site. I am trying to acomplish this by doing the following:

# pico /etc/httpd/conf/virtual/siteXX

<VirtualHost XXX.XXX.XXX.XXX:80>

DocumentRoot /home/virtual/siteXX/fst/var/www/html/toanother/folder
RewriteEngine on

# /etc/rc.d/init.d/httpd restart

After Apache restarts I am placed in the new folder structure, but the PHP code on the page is not being parsed.

I am at a loss as to what the problem may be. Any help is appreciated.

Okay … where are the answers? Answers? Um … answers? Nothing on that page. Go up one level, find the link to that page, and see “Replies: 0”.

Well XXXX! In three years no one has answered this person's cry for help!

On a lark, I decided to try the following:

GenericRootPrompt# ls -l
total 20
total 20
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 cgi-bin
drwxr-xr-x  9 admin229 admin229 4096 Mar 25 01:06 html
drwxr-xr-x  2 root     root     4096 May 27  2008 icons
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 interpreters
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 usage
GenericRootPrompt# mv html html.orig
GenericGootPrompt# ln -s html.orig/app/webroot/ html
GenericRootPrmopt# ls -l
total 20
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 cgi-bin
lrwxrwxrwx  1 root     root       22 Mar 27 16:19 html -> html.orig/app/webroot/
drwxr-xr-x  9 admin229 admin229 4096 Mar 25 01:06 html.orig
drwxr-xr-x  2 root     root     4096 May 27  2008 icons
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 interpreters
drwxr-xr-x  2 admin229 admin229 4096 May 27  2008 usage

It was a nice try, but it didn't work.

Can somebody remind me why we're using control panels?

It's the simple things that are impossible to do

I briefly mentioned in my last post something about <shudder> control panels and redirects requiring rocket science. It's true.

Several months ago a client wanted to improve their search engine rankings with Google. Their current configuration at the time was:


Their site reponds to both and, and while we can see they're the same site, technically speaking, search engines treat them as two separate sites. In fact, they pretty much have to, as they're, again, technically, under two different names and in theory, there could be a different site under each name.

Now the problem—while Google can probably figure this out, there's no indication to Google as to which “site” is the proper location, so it calculates the page rank for separately from, thus diluting the pagerank for the entire site.

There is a way of telling Google which site is considered “the site” and it involves redirecting requests at “the lesser site” to “the site.” The easiest way of doing this, using Apache, is:

  Redirect   permanent


And now every request to a page at will be redirected to “the site” at Simple, trivial, and therefore, impossible to do via a control panel!

When I tried that very method on the webserver (which has a <shudder> control panel on it), I broke the entire webserver!

And sadly, there is no option to set this up under the <shudder> control panel. Sure, you can set an alias for the site, but that gets slapped under the ServerAlias directive, which is not what the client wanted (as that's what the client had currently and wanted changed).

We got it working, but it involves a secondary webserver (without a XXXXXXXXX control panel on it) and changes to DNS files. Here's how it works.

The client tells us which address is “the site” and which should be redirected. For our example, we're redirecting to We then edit the DNS file for their domain and set the IP address for to our non-control panel webserver.

Then, on our non-control panel webserver, we add:

  Redirect   permanent

to the configuration. It works, and it's only slightly Rube Goldbergesque.

And yes, there's a solution that could be done on the server with the <shudder> control panel, but that involves mucking with mod_rewrite (and the horrors involved in debugging that) and .htaccess files, so it's a toss-up which method is more Rube Goldbergesque.

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2019 by Sean Conner. All Rights Reserved.