Your Shameless Host
Hi! Welcome to the personal blog of Jason Stirk (Griffin) - a slightly unhinged web application developer living in Lismore, NSW (yes, that's in Australia).
I run a software consulting company called Aurora Software.
Ruby script for *NIX which assists administrators in running and managing instances of Mongrel for hosting customers. It includes the ability to restart all registered Mongrel instances on system boot, and complete ownership of the process by individual users. Intended to be simple enough for a semi-technical customer to use via SSH.
Check out my post on SwitchPipe which you may find works much better than this tool.
SwitchPipe is a Ruby proxy tool that can dynamically start, stop and manage your mongrel instances depending on how busy the site is, and is easier to configure, and has more features than this tool.
pal is intended to:
Pretty much, if you run *NIX, and have the requirements for Mongrel available, then pal will run without any problems. It's been developed specifically on Fedora Core (1 and 6), with Ruby 1.8.5-p12 and 1.8.6, and Mongrel 1.0.1, but should work in most places.
Standard tools such as su and kill are used in the script to execute some things.
Only catch is that if you plan on using the script as your root user, it must be named "root" - you can't rename your uid 0 account and have this script work.
Check out the README.txt files for any useful things before you install - it's pretty much the same as this document.
Installation is simple - just run install.sh as superuser, and it will install everything necessary. Edit /etc/pal.conf to tell it about your Mongrel instances.
The script installs itself as two parts, pal which is the main command line script, and pal_service which is installed as an init.d script and should start after Apache on boot.
pal itself is simple - just run pal help to get full details of how it works.
We're currently hosting quite a few Rails apps on our production server with pal, in both production and development mode, and our clients are quite happy about the ability to restart their own apps after making major changes. We are using an Apache 2.0 front-end and mod_proxy to pass the requests through - very similar to the Mongrel/Apache Best Practice document (see below).
This is a big enough issue to be worth noting specifically - if you plan on having your static content provided by Apache (or your web-server of choice) rather than via Mongrel (a really good idea), you need to pay particular attention to the permissions of the files in your application. Remember that whilst your app files will need to be able to be read by the user the particular Mongrel instance is running as (and some directories, especially tmp/ and log/ need to be writable too!), you also need to ensure that the user that your webserver runs as can also access your public/ directory. There are a few ways to do this, depending on server configuration and admin taste, so I'll leave it up to you to decide how to tackle this problem. It is worth keeping in mind though.
On our server, we make everything owned by the user that owns the application (eg. chown railsuser.railsuser), except for the public/ directory, which is owned by the group of our Apache service (eg. chown railsuser.apache). We find that works well for us. YMMV.
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 License, and comes with absolutely no warranties or guarantees. Use it at your own risk - always read the code before use, and if pain persists please consult a doctor.