The maze book for programmers!

Algorithms, circle mazes, hex grids, masking, weaving, braiding, 3D and 4D grids, spheres, and more!

DRM-Free Ebook

The Buckblog

assorted ramblings by Jamis Buck

SwitchTower progress

26 December 2005 — 2-minute read

Well, I didn’t get nearly as far on SwitchTower over the weekend as I would have liked, but here’s what’s currently residing in the repository:

  • Custom SSH connection options (so you can specify the port, and other things)
  • The Rails rake tasks for SwitchTower now load ST directly, instead of invoking it via system. This should clear up issues with using the rake tasks on Windows.
  • You can set the :checkout variable to "export", to use export instead of checkout when deploying. (Only supported by the subversion module, currently.)

I’m still planning on implementing the following features (which should all be available by the next release of SwitchTower):

  • Verbosity settings in deploy.rb
  • Deploy via copy instead of checkout/export
  • Handle the SSH auth error that occurs when you don’t have the remote hosts in your .ssh/known_hosts yet
  • Add a setting for run vs. sudo in the restart task
  • Clean up old deployment directories

Lastly, I’m still considering what to do about the following requests. These may or may not find their way into the next release of ST. Some of them may never see the light of day in an official ST release.

  • Optionally leave the failed deployment on the server if it fails (instead of deleting it, as currently happens.)
  • Subclassing roles, so you can (for instance) have a specialized “app” role.
  • Built-in support for staging servers
  • Notification emails
  • Allow different user/pass for SVN access than for SSH access
  • Per-server deployment credentials/settings

I may try to come up with a plugin architecture (minimalistic, like Rails’ plugins) so that some of these can be addressed by third-parties in a modular fashion, but we’ll see how it all falls out.

Thanks for the suggestions, everyone!

Reader Comments

Jamis, I'd actually prioritize all of the requests on the "maybe" list before those on the "will do next" list. The way I see it, those features would tackle more "hard" restrictions than the other features would.
Um, err, maybe not *all* of them :)
There seems to be an issue with an local subversion path in the form of `file:///path/to/repo/trunk`. svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///srv/svn/repos/meinprof/trunk' svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///srv/svn/repos/meinprof' svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///srv/svn/repos' svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///srv/svn' svn: Unable to open an ra_local session to URL svn: Unable to open repository 'file:///srv' Maybe you can look into this.
Jonathan, all ST does is delegate to the svn utility. Thus, the problem is probably with your svn installation itself. (Unless I'm misunderstanding what you are reporting?)
Doing a `svn co file:///srv/svn/repos/meinprof/trunk` per hand works without a problem so I assumed that the problem lies within ST. I will email you the `rake deploy` output. Thanks, Jonathan
Hi there, I've been looking at switchtower for doing several things in addition to just deploying web apps. One of these is setting up the server software itself, from scratch, from source. The trouble is, switchtower doesn't seem to be able to remember environment variable settings, and so when compiling into a new directory (eg: for creating a standalone, customized, chrooted environment), it can't remember the alterations needed to CFLAGS, PATH, LD_LIBRARY_PATH, etc, which makes it hard to use. It would be nice if it could optionally pick up the variables from <notextile>~/.bash_profile</notextile> or <notextile>~/.bashrc</notextile>, which currently, it doesn't (at least on my systems). Also, the usage of <notextile>~/.ssh/environments</notextile> isn't really usable as it doesnt allow shell expansion and also provides an ability to user areas that shouldn't be able and don't need a facility to override environment variables at login. Whats particularly annoying is that logging in via console manually works fine and picks up <notextile>~/.bash_profile</notextile> settings, while switchtower does not. I've been investigating hacking solutions into switchtower for my problem (in mind of add a builtin variable like the 'set :application, nil') maybe called something called, maybe, 'pre_exec' which can be inserted infront of every 'ch.exec' command in the Command class in order to, in my particular case, export the environment variables I need. What's your opinion on the whole debacle?
darkliquid, Well, "debacle" is a bit strong. :) Yah, I can see how this would be annoying, but the reason the profile settings aren't picked up is because ST doesn't use a login shell--it just executes the command directly, It's the same as executing a single command via ssh, like:
  ssh localhost 'echo $RUBYOPT'
SSH, in this case, does not use a login shell, and so the profile settings are not read. This is a feature. :) If you need the environment to be initialized when using ST, you have a few options. The first is that you could throw the variables in a shell script and explicitly source the script with every command:
env = ". ~/.bash_profile"
run "#{env}; echo $RUBYOPT"
run "#{env}; echo $PATH"

# or, for multiple commands
run <<-CMD
  echo $RUBYOPT
  echo $PATH
Another option that might work (I haven't actually tried it) is to invoke your command explicitly via bash (or whatever shell), and specify that it is a login shell. Again, you'd have to do that for every command you run, though.
Hi, thanks for the quick comeback. The debacle is more my struggle than switchtower itself. I'm somewhat prone to exaggeration when I'm tearing my hair out :D That's more or less what I've come up with, but its a bit annoying having to do that every time I need to run a command with custom environment variables. I suppose I can cut down on the repeated additions to the run command by using a nice DRY bit of function to wrap it up, but I'd imagine that there is more than just me out there that would like to set some environment variables or some kind of initialisation for every command on a script global basis, which is the solution I'm tring to hack together at the moment. In what is surely a crime against coding everywhere, this little hack I've just come up with seems to do just what I want: In the SwitchTower::Command class, channel.on_success block...
my_command = @actor.configuration[:pre_exec] + ' ; ' + command.to_s if @actor.configuration[:pre_exec]
ch.exec my_command
and in the recipe:
set :pre_exec, 'export YOUR_VAR=here'
Another hack to allow different user/pass for SVN access than for SSH access: set :repository "--username user ––password pass"
@Doug: Thanks for the hints but that was not my problem. The svn checkout command in deploy.rb was correct for the server but not for the development machine. The thing is that the svn repository must be reachable for both the development box and the deployment target as both do a checkout for the deployment as Jamis stated in a private email. So `file:///` cannot work. You have to use either svn(+ssh) or http(s).
when I use svn+ssh as in the repository path and invoke rake deploy, I'll keep getting "svn: Can't create tunnel: The system cannot find the file specified" for several lines then "svn: Error resolving case of 'svn+ssh'". What's up with that? I'm developing on a Windows machine and deploying to a Dreamhost server.
Douglas, I saw your post to the rails list about that, and I'm at a complete loss. I have very, very little Ruby experience in Windows. I suspect there is something funky going on with your subversion installation, or possibly SSH... Does it work if you do @svn co svn+ssh://blahblahblah@ directly from the (windows) command line, or do you get the same error?