<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; godaddy</title>
	<atom:link href="http://gidden.net/tom/tag/godaddy/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Fri, 02 Jul 2010 13:00:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1-alpha-15359</generator>
		<item>
		<title>Transferred from GoDaddy to Dreamhost</title>
		<link>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</link>
		<comments>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/#comments</comments>
		<pubDate>Mon, 12 Mar 2007 19:09:02 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[dreamhost]]></category>
		<category><![CDATA[godaddy]]></category>
		<category><![CDATA[hook]]></category>
		<category><![CDATA[hooks]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[post-commit]]></category>
		<category><![CDATA[postcommit]]></category>
		<category><![CDATA[subversion]]></category>
		<category><![CDATA[svn]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</guid>
		<description><![CDATA[I finally got sick enough of GoDaddy to buy a Dreamhost account and transfer (nearly) everything over to that account.  Although I've only been using it for a few hours, I know I'm going to be far happier with it... especially the Subversion support.  Setting up a post-commit hook as described below has made maintenance a lot easier.

Writing off the $50 or so I spent on my GoDaddy account doesn't make me cry, and thanks to a handy coupon code, the new account only cost me about $90 for two years.
My main reasons for transferring over are:

Subversion support
SSH shell access
rsync support

I am so sick of running a slow and crappy ftp mirror to update my files, and a tedious process to upgrade WordPress and other packages.  With the above features, this is going to be a lot easier.
Dreamhost's web admin interface could be a bit quicker, but it's cleanly organised and full-featured.  Everything operates as expected, and it didn't take me long to get set up.
The only thing that took me more time than I would have liked is getting post-commit hooks set up on Subversion, so my web projects are kept up-to-date.  All I wanted was a simple svn update run in a few directories of the web tree whenever a commit is performed.  As this seems to be a frequently asked question, here's what I encountered:

Errors don't seem to be logged, so it's mainly just fumbling in the dark.
When accessed through http: (rather than file: or svn+ssh:), the hooks are run as dhapache, the web server user.
Simply tweaking the permissions of the checkouts to 777 doesn't seem to help that much.
The hook is going to be chown'ed to you, rather than to dhapache.  You could rename post-commit.tmpl, but then you'd have trouble chmod'ding it +x.
Running setuid (yick!) would get around that problem...
...if you could run scripts (as opposed to binaries) setuid'ed. (Yep, I forgot that one)
...or if you could be bothered to write them in C, or at least wrapper them with C.
It's all a moot point, because Dreamhost seem to be undoing setuid flags on a cron, or something similar.  Possibly on some form of pre-execution check by dhapache.  Not sure.

I tried putting the updates in post-commit itself, but found instead that it's far easier to put them in a CGI script and just use curl inside the post-commit instead.  I suspect the post-commit execution has a bogus environment in some way, so I hand it off to the CGI, which is easier to debug.

#!/bin/sh
/usr/bin/curl -O http://mywebhost.dreamhosters.com/_svn_update.cgi

The CGI is going to run as you, rather than as dhapache, so the setuid isn't necessary.  My CGI looks something like:

#!/bin/zsh
set -f
echo Content-type: text/plain
echo
foreach f (/home/mywebhost/svn/_live/*) {
        /usr/bin/svn update $f
}

Now all I need to do is put a bunch of checkouts into ~/svn/_live, and symlink them into my web directories where necessary.  I've also thrown in my zshrc file for luck.
I've chosen to use file:/// checkouts rather than http:// for performance, so it's probably best not to try to use them as read-write checkouts... mixing protocols when using hooks is not fun in my experience. Currently, this updates all checkouts if one of them changes, which isn't particularly efficient.  I'm going to rewrite it using $1 instead.
I'm sure there's probably a better way of doing all of this, without the intermediate kerfuffle, but this works fine for now.
UPDATE (March 16, 2007):  I had another play with it.  I think it's possible to get the apache user (dhapache) to correctly perform an svn update on a checkout owned by dhapache, but it doesn't do exactly what I want... I really want the checkouts executed by my user, for various reasons.  I also tried some other approaches.
Anyway, I reverted back to the old idea: that of using CGIs, and using $1 to determine the repository in question.  I've rewritten the script in Perl (and the corresponding hook), so I can use regular expressions to untaint the parameters.  I'd usually pick Perl for an obvious scripting job like this, but PHP would work fine too.
The real overhead is filesystem performance, rather than the CGI call.  As DreamHost uses an (obviously overloaded) NFS setup internally, Subversion updates are slowwww (at least this week), even when using file:///.  So, fixing the script to only update the specific repository has sped it up a bit.
Incidentally, this script could easily fail dirtily if run at the same time as other stuff going on.  I've had to manually run 'svn cleanup' on the _live checkouts.  Maybe locking will help...]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/feed/</wfw:commentRss>
		<slash:comments>-171</slash:comments>
		</item>
		<item>
		<title>GMail for your domain</title>
		<link>http://gidden.net/tom/2006/07/09/gmail-for-your-domain/</link>
		<comments>http://gidden.net/tom/2006/07/09/gmail-for-your-domain/#comments</comments>
		<pubDate>Sun, 09 Jul 2006 14:54:43 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Reviews]]></category>
		<category><![CDATA[forwarding]]></category>
		<category><![CDATA[gmail]]></category>
		<category><![CDATA[gmail-for-your-domain]]></category>
		<category><![CDATA[godaddy]]></category>
		<category><![CDATA[google]]></category>
		<category><![CDATA[mail]]></category>
		<category><![CDATA[mx]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/07/09/gmail-for-your-domain/</guid>
		<description><![CDATA[As I mentioned in a post on Underscore, last week I got an invite for GMail for your domain.  This is a new beta service where Google acts as your domain's MX.

Up until now, all my mail has gone through GoDaddy and been forwarded to GMail.  I then use Apple's Mail.app to retrieve the mail via secure POP3.  In recent weeks, I've been slightly paranoid that GoDaddy might be dropping mail.  Regardless, they're an added point-of-failure.  Right at that moment, Google send me the invite.
It was easy to set up.  They've made it even easier by detecting that my domain was served by GoDaddy, and giving me GoDaddy-specific instructions on how to set up the MX records (not that it's difficult, but it's a cute feature).  The additional SPF record suggestion was cool too, although I don't want to add that until I've fully migrated the DNS.
Now it's time for the criticism.  It came off pretty damn well, actually, with the only criticisms being quite minor:

My old GMail account can't be imported in, so I have to start fresh. Also, my normal Google login won't be fixed to this new account.
It uses a different login page, so I have to remember a new URL. Understandable for replaceable branding reasons, but I'd like to be able to my full address into the normal GMail login box and have it figure it out.
There's no facility for adding my secondary domains (eg. gidden.org, litebase.com). Bit of a shame. Means I have to keep the GoDaddy mail forwarding in place for those domains.
I can't set up proper forwards. Nicknames are almost forwards, but limited to destination addresses in the same domain. To set up a forward, I have to create a new user account, log into it, and set up normal GMail forwarding with "delete mail" set.  With all the logging in and out necessary to set this up, it's a major PITA.
The 2GB limit is fixed, rather than the ever-increasing limit of normal GMail.
The branding capability is far too limited:  you can replace the logo and that's it.  No CSS changes or anything.  Okay, the complexity of the GMail DOM layout might be a case of "No User-Serviceable Parts Inside", but they could just offer a sample stylesheet for font and colour changes.

I do still wish they'd spruce up the user interface, though.  I totally get the sparse look of Google, but I do think Yahoo's new interface is more user-friendly, and Google are practically making a point of being ugly.  I wouldn't be happy using this new service for giving accounts to non-computer-savvy clients.  I can see a market for small-business setups (in fact, small office London estate agents are just perfect for this market), but without a bit more branding capability, GMail isn't an option IMHO.
Right now, all they've done is wrap something around normal GMail. I'm sure all the hard work was in the MX stuff (although that can't really be too hard!)  For a real whole-domain email solution, they should start looking at collaborative functions. Rather than just centralised-management of separate GMail accounts.
Anyway, I've emailed them a bunch of suggestions for this, although I'm sure they've already got a good idea of where they're going with it.  (Hey, Google: make your beta feedback function more visible!)]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/07/09/gmail-for-your-domain/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>GoDaddy, mod_rewrite Update</title>
		<link>http://gidden.net/tom/2006/07/09/4-2/</link>
		<comments>http://gidden.net/tom/2006/07/09/4-2/#comments</comments>
		<pubDate>Sun, 09 Jul 2006 12:39:43 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Techie]]></category>
		<category><![CDATA[godaddy]]></category>
		<category><![CDATA[hosting]]></category>
		<category><![CDATA[htaccess]]></category>
		<category><![CDATA[htaccess_file]]></category>
		<category><![CDATA[mod_rewrite]]></category>
		<category><![CDATA[rewriterule]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/07/09/4-2/</guid>
		<description><![CDATA[It looks like GoDaddy might have tweaked their .htaccess / mod_rewrite support.  As I wrote in an earlier post, the way GoDaddy was supporting .htaccess was causing some confusion, in that even if you uploaded a correct .htaccess file, it could take some time to register.  This might have changed.

I haven't done much research or testing, but now when I make changes, they seem to activate immediately.  I don't know if this is just me, or whether they've fixed the problem, but it makes setup a lot easier.
Anyway, I've updated the original article to an extent, but have kept the possibly-obselete content in place for reference.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/07/09/4-2/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>.htaccess, mod_rewrite on GoDaddy</title>
		<link>http://gidden.net/tom/2006/05/26/4/</link>
		<comments>http://gidden.net/tom/2006/05/26/4/#comments</comments>
		<pubDate>Fri, 26 May 2006 14:01:48 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Techie]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[godaddy]]></category>
		<category><![CDATA[hosting]]></category>
		<category><![CDATA[htaccess]]></category>
		<category><![CDATA[htaccess_file]]></category>
		<category><![CDATA[mod_rewrite]]></category>
		<category><![CDATA[nucleus-cms]]></category>
		<category><![CDATA[rewriterule]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=4</guid>
		<description><![CDATA[Even though GoDaddy supports mod_rewrite, there are some definite peculiarities about their setup, with regards to .htaccess and PHP execution. Hopefully the observations I've made in this article will be of help if you're coming across the same problems I was.

UPDATE [9/Jul/2006]: .htaccess changes seem to be taking effect immediately now, at least for me.
UPDATE [3/Dec/2007]: According to comments left below, this is still an issue.  I can't verify, though, as I stopped using GoDaddy ages ago.  I've restored the stricken text, but please don't assume this information is still correct, as Your Mileage May Vary.
I was trying to set up Nucleus CMS and was having a little trouble with setting up the whole permalink / fancy URLs thing.  In particular, the mod_rewrite stuff in .htaccess didn't seem to be working correctly.
Googling for htaccess rewriterule godaddy tells me that I'm not the only one who was having issues.
I managed to get it working, and there are a few things to note:

Changes to the .htaccess file DO NOT TAKE IMMEDIATE EFFECT: I got very frustrated whem my rules were seemingly ignored, until I noticed that rules I deleted still worked.  So, after making a cup of tea, I came back to find they all worked. I'm pretty sure this is the problem most people are having.
Requests for PHP files (eg. http://gidden.net/tom/item.php) are intercepted well before .htaccess (and definitely mod_rewrite) activate. So, mod_rewrite will not work on URLs for PHP files.
However, it will allow redirections to PHP files.

Like many of GoDaddy's services, the changes aren't instant: when you change a setting in the hosting manager, it often takes 10-15 minutes to happen. At one extreme, I moved the hosting package to another (non-existent) domain while shuffling things around, and it took 24 hours before it would let me change it back.
I think they must have a weird form of file distribution where the FTP servers are not talking to the same filesystem as the webservers, and a cron job performs some sort of mirroring.  Either that, or there's some caching that doesn't get cleared correctly.
The fact that PHP files bypass .htaccess makes me think that PHP requests are separated out (possibly by some load-balancer or other magic box) and run on a different server.  It's clear that PHP is run through the CGI/FastCGI mechanism, rather than the more usual mod_php/apache way, but I wouldn't necessarily expect a large-scale shared hosting site to use mod_php.  It's a slight inconvenience, but understandable.
So, back to the Nucleus configuration.  The "normal" way of doing fancyurls (using FilesMatch and ForceType magic) doesn't work on GoDaddy, since the PHP execution mechanism is long gone by the time Apache reaches the .htaccess file and ForceType.  The alternative way listed in the documentation that uses mod_rewrite seems inadequate:  it doesn't use the "Fancy URLs" mechanism in Nucleus, and the URLs really do feel less fancy as a result.  Now that mod_rewrite seems to work correctly, we can use it to implement the extra/fancyurls files in a better way.  I configured .htaccess as follows:
Options FollowSymLinks
RewriteEngine On
RewriteRule ^member/(.*) index.php?arr=member/$1
RewriteRule ^item/(.*) index.php?arr=item/$1
RewriteRule ^category/(.*) index.php?arr=category/$1
RewriteRule ^blog/(.*) index.php?arr=blog/$1
RewriteRule ^archive/(.*) index.php?arr=archive/$1
RewriteRule ^archives/(.*) index.php?arr=archives/$1
...and then changed index.php to sort this out in a big switch statement before  handing over to selector().]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/05/26/4/feed/</wfw:commentRss>
		<slash:comments>30</slash:comments>
		</item>
	</channel>
</rss>
