No SVN on BlueHost

Nevermind.

SVN stopped working on BlueHost last week. After a bit of digging, I discovered that the configuration of OpenSSH had changed, limiting the $PATH for non-interactive shells to the default of /usr/bin:/bin. You can’t change it in ~/.bashrc; you can’t change it in ~/.ssh/rc.

So, I start talking to tech support. At first, they tried to be helpful, and apologized for the inconvenience. But today, I got this message:

“Openssh was upgraded for security reasons. Unfortunately the upgrade changed functionality and now some programs such as subversion and git no longer work the way they did previously.

“It appears that the old behavior may have been flawed in the first place and shouldn’t have worked. We are looking into how to restore previous functionality without any negative security impact, but we have a desire to keep our accounts and servers from being compromised and therefor any decisions on changing functionality will be made with that in mind, but for the time being we are not promising that the original functionality will be restored due to security reasons.”

Well, that’s that, then. Goodbye, BlueHost. You are no longer an adequate web host. I think I’ll give 1&1 another shot before I finally give in and go with Linode.

Update 2010-04-22: See Franklin Strube’s post below for a possible workaround. I haven’t tested his solution (I’ve already moved off of BlueHost), but it seems sound. Thank you, Mr. Strube.

6 thoughts on “No SVN on BlueHost”

  1. Last time I tried installing SVN on a shared 1&1 server I got the following email:

    It has come to our attention that you have recently executed and/or
    attempted to execute an unauthorized service on your web space:

    /htdocs/bin/.libs/lt-svnserve listening on *:3690

    Such services are not permitted to run on 1&1’s web spaces.

    This is also stated explicitly to you when you connect via SSH to your
    account:

    “Shell access is provided for web development and not for running
    irc-bots, arbitrary tcp/udp servers (e.g. gameservers) or cracking
    toolkits. Disregard leads to suspension of your contract.”

    Please remove the software at this time and do not attempt to use it
    again. Be aware that further infractions can result in the suspension or
    termination of your contract.

    Thank you for your compliance in this matter.

    This was a shared server but not sure if that made a difference.

    Post back if you know a workaround.

  2. I used DreamHost for a couple of years, but finally got fed up with the constant downtime (I think my sites were down more than they were up for the final two months). I’m definitely considering getting a DreamHost account just for SVN, though, and keeping live websites elsewhere. I’m just hoping for an all-in-one solution.

  3. There is a workaround to this. By using a public/private key for svn+ssh connections, you can execute the ~/bin/svnserve -t command. All you have to do is generate the public/private key, add the public key to ~/.ssh/authorized_keys with ‘command=”~/bin/svnserve -t” ‘ at the beginning of the line in authorized_keys.

    I wrote a blog article for setting this up: http://www.franklinstrube.com/blog/installing-subversion-on-bluehost

Comments are closed.