Posts tagged ‘dreamhost’

SSL at Dreamhost

I have been wanting to secure my websites with SSL/TLS since the day I signed up with Dreamhost, but gave up after realizing I would have had to pay quite a bit extra on top of hosting and domains. Back then I would have needed to buy both static IPs, and the certificates. A few years back we started getting free certificates that were recognized by most browsers, but Dreamhost was still requiring the purchase of a static IP. Next Dreamhost stopped requiring a static IP, and I actually started the process of obtaining a free certificate, but eventually gave up due to the whole process requiring more time than I had available.

When Let’s Encrypt entered the field I got quite excited. I was even prepared to do the work this time around to write the certificate renewal automation myself. But when I finally got the time to do the work, I realized that Dreamhost had actually done all the work for me, and provided really easy setup through their management panel.

The hardest part turned out to be to find and fix all the non-https links. Dreamhost has good wiki pages about secure hosting in general, how Let’s Encrypt works at Dreamhost, how to force SSL everywhere, and how to configure WordPress for SSL. The instructions worked for the most part. Even after going through all the steps for WordPress I found non-https links when viewing the blog, and had to look for them in the templates and so on.

Next I went through my external links and converted many to https links. Of all the domains that I link to and can support SSL, Amazon seems to be the only one that redirects from https to plain http in some cases, or provides mixed environment if you follow an https link. The astore that used to work in an iframe no longer worked like that, and had to become a regular link. Hopefully Amazon fixes their end sooner rather than later.

Turbogears2 on Dreamhost

It has been almost two years since I tested Turbogears 1 on Dreamhost. Back then it was quite difficult for me to get it running. But some additional personal experience and improvements in Turbogears2 have made it a breeze. I tested with Turbogears 2.0 although I upgraded to 2.1a2 at some point.

First you need to get virtualenv installed, which is pretty simple after you have downloaded and unpacked the source tarball: python2.5 $HOME. (I wanted it installed in $HOME, but you could use alternative locations as well.) This will install setuptools, but somehow not virtualenv. Then you just do easy_install virtualenv. You will also need PasteDeploy so do: easy_install PasteDeploy.

Next steps might be different for installing a Turbogears2 egg/application, but I used these instructions to install the wiki-20 tutorial in development mode. (To install a properly packaged app you probably just need to do: easy_install app_tarball; paster make-config yourapp production.ini and follow the instructions from FastCGI onwards.)

After that you just follow tg2 automatic installation instructions.

Then use paster quickstart to create a new project template. cd to the created directory, and run python develop to download any missing dependencies and set things up for debugging and development.

Edit as instructed in the tutorial. Then python setup-app development.ini.

After that it is time to create the production ini: paster make-config Wiki20 production.ini.

Next step is getting this running with FastCGI. Create wiki20.fcgi in the webroot directory:

from fcgi import WSGIServer # you could also use flup etc.
from paste.deploy import loadapp
real_app = loadapp('config:/home/your-username/path/to/production.ini')
def myapp(environ, start_response):
    environ['SCRIPT_NAME'] =  # get rid of the .fcgi in urls
    return real_app(environ, start_response)
server = WSGIServer(myapp)

There are a couple of points of note here:

  • I am using which seems to be slightly more reliable than flup on Dreamhost. You’d better edit so that you won’t show private information to everyone in case of errors.
  • There is a trick to get rid of the .fcgi part from the URLs.

Next we’ll need a .htaccess file:

# Enable Dreamhost stats
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/(stats|failed_auth\.html).*$ [NC]
RewriteRule . - [L]
# FastCGI
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wiki20\.fcgi/ - [L]
RewriteRule ^(.*)$ wiki20.fcgi/$1 [L]

Now when you go to your site, first time it is going to take a while to load your app, but after that things will be snappy as long as the app stays in memory.

Site Breakage Fixed

Last Sunday Dreamhost went and switched the host on which all of my sites run to a different machine. There was no advance notice, just an email after the fact informing me the change occurred and hopefully they did not break anything. As it turns out, they changed quite a bit. I am not sure if the old host was 64 bit or not, but the new one definitely is. Some of the apps I had compiled myself no longer run, complaining about wrong architecture. Some paths were different, some Apache settings were different, and mail filtering through procmail broke. As a consequence, my blog, M2Crypto Tinderbox and all my Python web applications broke. Those are the things that I know of, because I have now fixed all of them as far as I can tell. It was reasonably straight forward to recompile everything (luckily I had saved the previous configure options), find and change the changed paths, and google the Apache error. The procmail filter started working after I redid the mail filtering settings through the Dreamhost panel.

While this unannounced change was definitely not cool, it is the only time (so far) when I have been really unhappy with Dreamhost since I started hosting there in early 2006. So I am still recommending them as a cheap hosting provider: for under $9/month you get unlimited bandwidth and disk space, and cheap and anonymous domain registration to boot.

Anyway, Murphy’s Law still rules, as this all happened while I was on vacation with no net or even cell phone coverage. Sorry for the extended downtime.

Tinderbox on Dreamhost

Tinderbox is a tool that helps software developers run continuous builds and tests. There are other similar tools, like Buildbot, which I actually prefer over Tinderbox. The problem with Buildbot, though, is that it requires continuously running processes and these are not allowed under Dreamhost’s shared plans. Luckily Tinderbox does not require a continuous process, so it is suitable for Dreamhost.

I wrote the Tinderbox on Dreamhost wiki page on the Dreamhost wiki detailing the instructions. Exposes Python Tracebacks by Default

I was testing a Python web application that was using FastCGI deployment on Dreamhost, when I found myself looking at a souped up Python Traceback in my browser. At first I couldn’t understand why that was happening. As far as I knew I was running with full production settings and as such I would have expected a terse internal server error message.

Looking at the HTML source of the error page I discovered reference to cgitb. But as far as my code was concerned I did not set that. I tried specifically disabling that in my script but that made no difference. In a momentary act of desperation I did a find for all files under my account and made the cgitb.enable() function do nothing. Yet I was still seeing the tracebacks.

After a bit of scratching my head and throwing different words at Google it occurred to me to take a look at the script. Oops. The [WSGI]Server class has an error() method whose docstring states that it “May and should be overridden”. No $%^, the default just plasters all the dirty little secrets for the world to see! I’d like to see something like Debug[WSGI]Server that pretty prints the error, and leave the [WSGI]Server the production class. The naming would make it clear that you should not be using the debug version in production. As it is now, I wonder how many people actually read all the way towards the bottom of the 1331 line file to discover this gem.

I also added a warning to the Dreamhost documentation regarding Python FastCGI.

Trac FastCGI Problems

I solved the locked out Trac admin problem by creating a second admin using the command line trac-admin tool, and then logged in as that admin to delete the broken admin account (it is weird that admin can not edit accounts in Trac, only delete them). I then recreated the original admin, and as I had set up outgoing email even that worked. After I confirmed everything was working I nuked the temporary admin.

I was able to get a pretty good improvement in performance by symlinking the trac/htdocs/common into my site’s chrome/common. Initial wait was still long, but all pages I tried seemed to be served under a second, compared to some taking over 20 seconds before this operation. Usable for me only although the initial wait was long, but would probably not be usable with a group of people hammering the server.

Next I looked at FastCGI. The documentation claims it should be as simple as changing index.cgi references in .htaccess to index.fcgi, which in turn differs from index.cgi only by calling trac.fcgi instead of trac.cgi. trac.fcgi seems to be invoking a variant of Allan Saddi’s fcgi module. But try as I might, I was only getting 500 internal errors with the log not being very helpful:

[Wed Jul 16 21:55:31 2008] [error] [client ...] FastCGI: comm with (dynamic) server ".../index.fcgi" aborted: (first read) idle timeout (60 sec)
[Wed Jul 16 21:55:31 2008] [error] [client ...] FastCGI: incomplete headers (0 bytes) received from server ".../index.fcgi"

I also didn’t see any *.fcgi processes, like I see with my site.

I thought maybe this was an instance where I would need to file a support ticket to see if raising Apache2 Softlimit would help, but suddenly FastCGI started working. As far as I know, I didn’t touch anything that should have made a change in this, so I am still quite clueless to what happened.

The final point about the Trac installation which I was happy to note was that my paths are pretty out of the box (no index.fcgi in the path), so I don’t need to resort to any of the path hacks mentioned in various guides on how to install Trac on Dreamhost.

Trac on Dreamhost

I am working on launching a little project, and thought about using Trac to manage the development. This is the first time I am setting up Trac, and given that people seem to be having lots of problems installing Trac on Dreamhost I figured this would be a painful experience.

First I created the and sites, and I think I actually made the installation of Trac simpler because of this. Another option would have been, which I believe would make some of the later steps harder. I also used the Dreamhost Panel to create the Subversion repository at

First of all, there is a nice script for making Trac install nearly painless on Dreamhost. Unfortunately the script is hardcoded to use the system Python 2.3, and at least one of the plugins the script installs is not compatible with 2.3. I found this out by installing, then changing the admin preferences by adding an email address which completely broke the installation: any URL would just result in a Python stack trace.

Which reminds me that I find it really strange that Trac is giving the full stack traces in the web UI; that is a security problem. Pylons for example does that only in the development mode by default, and in production mode the default puts errors only in the log (and it can also email the error to administrator if email is set up). After brief search I have not seen a way to stop the stack traces from appearing in the web UI.

I then figured I’d install Trac the hard way, by hand. How hard could it be, right?

First I needed to set up some prerequisites as was described in the official Trac installation guide (some of these at least might be installed automatically by setuptools, but I installed what I wanted in advance). I had installed Python 2.5 earlier, so that was no problem. SWIG was already high enough version so I didn’t need to do anything about that. I figured I wouldn’t need Clearsilver or SQLite. First I installed setuptools, then it was trivial to install python-mysql (mysql was already on the system), genshi, docutils, pygments and pytz. Naturally Apache was already provided by Dreamhost as well, but even though Subversion was provided I also needed to build one myself to get the Python bindings for 2.5. To make managing the repository easier, I chose to install the exact same Subversion as was the system wide version; that way I could use the Dreamhost Panel to manage the repository and give Trac access to it as well. Of course, if Dreamhost ever updates its version I will be in trouble… The build and installation were a breeze with good instructions. Finally easy_install Trac went through without a hitch. I also installed Account Manager plugin which turned out to be a mistake.

Then came a pretty hard part; how to create a Trac site. I adapted pieces of the easy Trac install script into my own setup, and managed to use trac-admin to create my site. I was also able to serve it with tracd, but this is good only for testing. Next I tried to figure out how to serve Trac as CGI. I was stopped cold by not finding the cgi-bin directory that was mentioned in the instructions. After a bit of fumbling and doing web searches I figured out how to use trac-admin deploy command (trac-admin /path/to/trac/env deploy /path/to/dump/cgi-bin-etc).

Next step was putting in the index.cgi and .htaccess files. I started from what the script install used, but it turned out all I really needed for index.cgi was:

export TRAC_ENV="/path/to/trac/env"
export PATH=/path/to/python2.5/bin:$PATH
exec /path/to/cgi-bin/trac.cgi

The cgi file naturally needs to be executable.

You will also need to make trac.cgi executable, and change the hash bang line to /usr/bin/env python – the default will pick up the old system Python. Note that trac.cgi will output stack trace to the web in case of error, so you should take out the line that does that and leave just the line that prints into log.

The last struggle was with .htaccess, which turned out like so (you may want to modify this to allow the Dreamhost stats gathering of your site):

DirectoryIndex index.cgi
Options ExecCGI FollowSymLinks
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.cgi/$1 [L]

Oh, lest I forget, I also created the admin user, admins group, and the default password for the admin using the procedure described in the easy Dreamhost installation script.

After this I was able to browse the Trac site fine. I logged in as administrator and changed the password. Then I made the mistake of putting in an email address for the administrator. Apparently (?) due to the Account Manager plugin the admin account was made limited until email verification was completed. The problem was that I had not set up outgoing email yet. And then I made another error by clearing the admin email, which resulted in getting a stack trace on every page while logged in.

I’ve since set up outgoing email, which proved simple by using a GMail account. But the admin account is still hosed, and I am too tired to figure that out right now.

Dreamhost Broke Virtual Python Installations

Yesterday I was puzzled to note my site was reporting internal server error. Looking at the server logs did not help. Running the FastCGI script by hand gave a mysterious traceback that ended with:

ImportError: /home/.../lib/python2.4/lib-dynload/ undefined symbol: _PyArg_NoKeywords

Experimenting further it seemed just importing many stdlib modules resulted in the same thing, for example import threading failed with that. It seems others have run into the same problem with their virtual python installations. I filed a support request at Dreamhost, but they responded saying Python is working just fine. And it is, it is just that virtual python installations broke.

I decided I would use this as an excuse to try and get Python 2.5 running on Dreamhost and migrate my application to that. It turned out to be easy with these instructions. I had tried compiling Python on Dreamhost before, but had always ended up with a binary that did not work. The working incantation is: ./configure --prefix=$HOME/opt/ --enable-unicode=ucs4

I guess I will need to set some kind of monitoring system for my web app so that I will know about outages sooner rather than later…