Friday, March 27, 2009
JAWS PARTY
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
Sigh.
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.
http://www.XXXXXXXXX/support/wpls/faqs/3.6.html
Wonderful! I thought. That's exactly what I need. I click on the link—
404
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:
404
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/htmlfolder 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> ServerName XXX.XXX.XXX.XXX ServerAdmin me@mysite.com DocumentRoot /home/virtual/siteXX/fst/var/www/html/toanother/folder RewriteEngine on
# /etc/rc.d/init.d/httpd restartAfter 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 GenericRootPrompt#
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:
<VirtualHost 10.10.10.10:80> ServerName www.example.com ServerAlias example.com ... </VirtualHost>
Their site reponds to both www.example.net and
example.net, 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 example.net separately from
www.example.net, 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:
<VirtualHost 10.10.10.10:80> ServerName example.com Redirect permanent http://www.example.com/ </VirtualHost> <VirtualHost 10.10.10.10:80> ServerName www.example.com ... </VirtualHost>
And now every request to a page at example.com will
be redirected to “the site” at www.example.com. 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 example.com to
www.example.com. We then edit the DNS file for their domain and set the IP address for example.net
to our non-control panel webserver.
Then, on our non-control panel webserver, we add:
<VirtualHost 10.10.10.10:80> ServerName example.com Redirect permanent http://www.example.com/ </VirtualHost>
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.
![[The future's so bright, I gotta wear shades]](https://www.conman.org/people/spc/about/2023/1023.t.jpg "The future's so bright, I gotta wear shades")