Web Hosting

Personal website switcharoonie

Tags: 

Since 2000 I've owned the mc-kenna.com domain. I've used it for various purposes over the years. One hope I had for the domain was that my family would be able to or interested in collaborating on it. It didn't work out that way and I ended up using it as my personal blog. That didn't quite sit right with me as I wanted the domain to be used by others, so along the way I picked up damienmckenna.com with a goal to make it my personal blog. Eight years later I've finally moved my personal blog from mc-kenna.com to damienmckenna.com, so I don't feel guilty anymore about publishing under my name.

I also plan to write more here, so lets see how this goes.

Bye bye Dreamhost & GoDaddy, hello HotDrupal, NameCheap & Google

Tags: 

After several hears calling Dreamhost the home for my website, I've moved the site to HotDrupal.com, a web hosting firm that specializes in Drupal hosting. So far, so good.

My main reasons for the move were:

  • Dreamhost throttled its web server to the point that my site was no longer able to run without throwing errors on 3/4 of logged-in pageviews, which caused rather horrid problems including causing most of the pages to stop work & menus disappear.
  • Dreamhost had no intention of changing this as it is part of their business plan - throttled, limited hosting at discounted rates.
  • While I could have gotten a VPS (virtual private server, kind of like a full server sliced into more manageable pieces) and had more, I didn't want to spend that much nor did I want to have to manage the server itself.

I'd like to say that I've never really had any problems with Dreamhost themselves, they've been very reliable over the past few years, it was just simply that with my site stopped being able to work I had to move elsewhere.

HotDrupal has been really good over the past few days while I got my account set up. They don't offer the earth, like some, instead they offer specialized yet flexible hosting and cover all of the basic needs if you don't specifically need to host a Drupal site.

I also took the opportunity to move the domain registration away from GoDaddy to NameCheap (affiliate link), a company that doesn't need to promote its services with scantily clad female racecar drivers. I've previously moved other domains to NameCheap and this was final one. Again, so far I like their services - lots of features for decent rates and they don't waste your time with tons of obstructive & annoying sales pitches on what felt every single page load like GoDaddy does.

Lastly, I've moved the domain's email hosting to Google Apps, just so that I could separate email from the website hosting, which will give me more flexibility to move it around as necessary, and avoid filling up my disk quota with my gb's of IMAP email.

I'll let you know how it goes.

Thanks to Dave Reid for the NameCheap recommendation.

Why I don't use Cygwin for SFTP

Tags: 

In the UNIXy (UNIX, BSD, Linux, OSX) world secure file transfers have been the norm for years, thanks in part to the standardization of SSH as the security protocol due to both its simplicity and power. Windows, on the other hand, has never featured security as a very important feature, evidenced by the ellaborate routes someone must take to handle SSL in IIS.

As a stop-gap measure many people have started to use the UNIX compatibility layer Cygwin, which is a wonderful system that lets you run and/or compile UNIX software on Windows. One of Cygwin's many available software packages is OpenSSH, the defacto standard SSH daemon in the UNIXy world, so by using Cygwin you can set up SSH for your Windows server. There's just one problem - it doesn't work well.

The problem with SSH, or indeed any UNIXy compatibility layer, on Windows is the age old problem that the traditional UNIXy file & directory security system is completely different to what Windows provides.

UNIX file security is based on setting the Read, Write and eXecute (thus RWX) status on any given file for both you (aka the User), anyone in your Group (or more specifically the file's assigned group) and the Other users on the computer (thus UGO). As an example, if your file is set to allow all three (UGO) to Read & Write to the file then anyone who has access to the machine can open & change the file. A common way to list these settings is in the form of octal values - Read is 4, Write is 2 and eXecute is 1, with the numbers added together for each user type, so the common setting of U=RWX,GO=RX becomes 755.

Windows file security is based on Access Control Lists (ACLs), which are basically lists of individual users and groups and their associated permissions. Rather than restricting you to only assigning permissions at three levels (UGO) you are completely open to decide what groups and users can do what to your files. This gives a great amount of flexibility as you can more easily mix 'n match security groups and group memberships. An example might be allowing both the Executive and IT groups could read a reports directory but only Accounting to modify files there.

As you can guess there's going to be issues trying to superimpose the UNIX UGO-style permissions on top of Windows' ACLs, and there are.

When you install Cygwin first it grabs a copy of the current users & groups settings from Active Directory (or your local computer, if you aren't in a domain) and saves them out as /etc/passwd and /etc/group in the standard UNIX format.

The first issue with this system is that every time the user groups and user accounts change you have to re-import the accounts settings. While, yes, you can create a cron event to automate this, the problem gets worse ...

The next issue is that it doesn't correctly handle the user's primary user group, mainly because Window's doesn't have such a thing, so instead it assigns all users to an invalid group. Now, on top of having to automate synchronizing with the Windows accounts system you have to work out how to put users into their proper groups so that their files are properly acessible.

There's another problem: when you log in through sftp any files uploaded have the file permissions set incorrectly. Thankfully there's a way of fixing this using a kludge to override the sftp defaults, but who likes kludges?

The problem gets worse with directories: all directories created are assigned the default usergroup listed, and coupled with the file permissions problem it leaves your directory structure so that only the original user can view files in the new directory. And no, there's no way to fix it using SFTP, you need to log in with a full shell session to run chown on the directory in question - not something you want your average non-technical designer doing on your production web server.

So, combine the four problems above and you end up with a really messy system that ultimate simply doesn't work cleanly.

It is for the above hassles that at work we've paid hard cash for Vandyke's VShell ssh server, which works wonderfully well by the way.

Backup script for RimuHosting

Tags: 

A handy little one - a backup script for RimuHosting that will backup your Rails app and copy it to the provided backup storage account. To use it you first have to add Geoffrey Grosenbach's backup.rake script to your lib/tasks directory, then sign up for RimuHosting's backup service, then just save out this script as e.g. "backup.sh" and add it to your crontab. Easy when you know how.

export TIMESTAMP=`date +'%Y%m%d%H%M'`
rm -f backup.zip
rake db:backup RAILS_ENV=production
zip -r -9 -q backup.zip *
lftp -u 'myaccount,mypassword' backupspace.rimuhosting.com -e "set ftp:ssl-protect-data true; put backup.zip -o backup_$TIMESTAMP.zip; exit"

RadiantCMS on Dreamhost

Tags: 

A small tip for anyone trying to install Radiant on their Dreamhost.com account.

The original instructions I found said that three ENV lines that had to be added to the dispatch.fcgi file had to be before the RailsFCGIHandler.process! line. Well it turns out they have to be before the require lines, e.g.:
[source:ruby]
ENV['RAILS_ENV'] = 'production'
ENV["GEM_HOME"]="/home/myaccount/.gems"
ENV["GEM_PATH"]="/home/myaccount.gems:/usr/lib/ruby/gems/1.8"
require File.dirname(__FILE__) + "/../config/environment"
require 'fcgi_handler'
RailsFCGIHandler.process!
[/source]

Pages

Subscribe to Web Hosting