DreamHost stuff

Below is items tagged as having to do with DreamHost.

I have two DreamHost accounts, both set up in late November, 2008.  One is for sites I host personally (most of which are community oriented) and the other is for sites that Break The Gridlock/bikegeeks host for its member organizations.

Free Tag:

Introduction of dreamhost scripts

I have completed what I think is a good start to a suite of bash shell scripts that aid in the management of DreamHost customer accounts.

For now, the scripts mainly focus on the creation of backups of important (mainly Drupal) files in the host environment.

See the scripts at http://svn.toddgee.com/dhScripts
See the README at http://svn.toddgee.com/dhScripts/README

Free Tag:

web log stats/analysis on DreamHost

I looked into web log reporting on DreamHost the other day.  DreamHost provides web log stats system called 'Analog'.  It's a) not the nicest system out there (I think it's cruder looking that Webalizer) and b) it is only accessible via the url 'domain/stats'.  Because of this, it requires munging (drupal specific) of a site's .htaccess file (if it exists) or creating on (if

Free Tag:

Sharing .bashrc/.bash_profile/.bash_logout and bin dirs with slave users -- DreamHost best practices

As previously mentioned I have a custom .bashrc/.bash_profile setup for my DreamHost accounts.  Also, because of my '_user / _web user strategy', I have multiple users that all need to have the same bash environment. 

Free Tag:

Dreamhost .bashrc/.bash_profile/.bash_logout

Like everyone else in the universe, I have my own preferred bash setup. Discussed here is the setup I use with DreamHost.

UPDATE: See 1st comment below.

I'll start with the .bash_profile file as it simply references the .bashrc file:

# ~/.bash_profile: executed by bash(1) for login shells.

if [ -f ~/.bashrc ]; then
        . ~/.bashrc

(I've always done it this way -- never having a different config for login/non-login shells.  YMMV.)

Free Tag:

Shell user logins -- DreamHost best practices

For all of my DreamHost shell users, I've made all their passwords long, random passwords that are (near) impossible to hack.  This makes them near impossible to remember as well, so I use ssh public key authentication for all shell users.

Update: See 1st comment, below.

Migrating Gallery to Dreamhost (migrate PostgreSQL -> MySQL)

One of the last things to migrate to Dream Host is my collection of Gallery2 installations.

The biggest issue is a database disparity. On whip (my old server) my gallery2 installs were done using the multisite installation scheme on a PostgreSQL database. DreamHost supports only MySQL and gallery doesn't have an import/export function. So, I had two options: reimport the albums into fresh gallery2 installs or migrate the installations along with the data. I didn't want to loose all that meta-data so I gave migration a shot. These notes are being typed after doing the process a 2nd time. Learn from my mistakes!

encfs over sshfs to DreamHost backup account

How to set up a encfs over sshfs
(using DreamHost backup space; but discussion is the same)

I wanted to combine the power of sshfs with the security of encfs to backup my personal files on DreamHost's allocated 50G of file backup space. I liked the idea of having my personal files a) backed up and b) on the Internet available for use from work.

Setting up the mount of the remote (DH backup space) directory on a local dir using sshfs:

I created a local mount point 'dreambackup' and issued the command:

Free Tag:

_user/_web strategy of DreamHost website deployment -- DreamHost best practices



When I first signed up for DreamHost account, I understood, but wasn't overly fond of the way they ran web requests.

All requests to a deployed website on DreamHost are made in the context of the user owning the website.  That is, if a website is deployed under user 'X', calls into that website are performed as user 'X'.  This allows DreamHost to isolate security breaches to the user of the (defective) website.  However, this also has security implications for the individual websites.  If there is an exploitable defect within a particular website and a site is compromised,  files within that software could be modified as the call is done as the owning user.  Setting restrictive permissions (i.e. read-only) on the site's file helps, but doesn't completely mitigate the issue, as the files are owned by the calling user and (in a truly compromised environment) the file permissions could be modified.  In a traditional (non shared) web hosting system, this would not be an issue as web-initiated calls would be made by the (highly restricted) user (e.g apache, httpd, etc.) with permission to read (and not write) only those files required to serve the web page.

What follows is the scheme with which I came up to work around this issue.  In this discussion, I'll talk about Drupal sites; but the scheme is the same regardless of what files are deployed on a site.

Subscribe to RSS - dreamhost