fluidBlog

In this post I’m going to walk you through the steps to create a Drupal based web site from the ground up starting with a newly minted Fedora 6 slice from Slicehost.

Secure the Slice

The first steps are exactly the same as my previous post, Securing a new Fedora 6 Slice. If you followed the instructions in that post you have accomplished the following

• changed root’s password
• yum updated the base installation
• yum installed sudo
• created a user with sudo privileges
• created a public key on your local machine and copied it to your slice
• disabled password authentication via ssh
• diabled challenge response authentication via ssh
• changed the ssh port
• disabled root login via ssh
• installed denyhosts (optional)
• installed and configured a firewall using iptables

Install Required Software

Now that the slice is more secure, we can install the software required by Drupal.

• Apache Web Server, httpd
• MySQL Server
• PHP
• GD
• Sendmail

Login into the slice and yum install the following packages

$ /usr/bin/sudo /usr/bin/yum -y install \
> wget \
> tar \
> gzip \
> make \
> gcc \
> openssh-clients \
> mysql \
> mysql-server \
> php \
> php-mysql \
> php-devel \
> php-gd \
> gd \
> gd-devel \
> httpd  \
> sendmail \
> sendmail-mc \
> sendmail-cf

Start the mysqld server

$ /usr/bin/sudo /etc/init.d/mysqld restart

Ensure MySQL starts at boot

$ /usr/bin/sudo /sbin/chkconfig --add mysqld
$ /usr/bin/sudo /sbin/chkconfig --level 345 mysqld on

Secure Initial MySQL Accounts

see Securing the initial MySQL accounts

$  /bin/su
# /usr/bin/mysql -u root
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
mysql> exit
# exit
$

Create a Drupal system user

$ /usr/bin/sudo /usr/sbin/useradd -r drupal

Create MySQL user account

see CREATE USER Sytnax

$ /bin/su
# mysql -p -u root
mysql> create user 'drupal'@'localhost';

Create the database for your Drupal site

mysql> create database mysite;
mysql> grant all on mysite.* to 'drupal'@'localhost';
mysql> exit;
# exit;
$

Download the Drupal software

see Download

Change directories to /usr/local/src

$ cd /usr/local/src

$ /usr/bin/sudo /usr/bin/wget \
> http://ftp.drupal.org/files/projects/drupal-5.2.tar.gz

$ /usr/bin/sudo /bin/tar xvf drupal-5.2.tar.gz

$ usr/bin/sudo /bin/cp -r drupal-5.2 /var/www/html/mysite

Make settings.php writeable by the web server user

$ cd /var/www/html/mysite

$ /usr/bin/sudo /bin/chown root.apache \
> /var/www/html/mysite/sites/default/settings.php

$ /usr/bin/sudo /bin/chmod g+w \
> /var/www/html/mysite/sites/default/settings.php

Make the files/ directory and its subdirectories writable by the web server user

$ /usr/bin/sudo /bin/mkdir files files/color files/css \
> files/images files/images/temp

$ /usr/bin/sudo /bin/chown root.apache files files/color files/css \
> files/images files/images/temp

$ usr/bin/sudo /bin/chmod g+w files files/color files/css \
> files/images files/images/temp

Set up cron

Add a shell script to /etc/cron.hourly

# !/bin/sh
# $Id: cron-curl.sh,v 1.3 2006/08/22 07:38:24 dries Exp $
curl  --silent --compressed http://mysite.com/cron.php

Get optional modules and themes

Setup Apache Web Server

edit /etc/httpd/conf/httpd.conf

#ServerName :80
ServerName www.mysite.com:80
#Listen 12.34.56.78:80
Listen your.slice.ip.addr:80

Add

<Files *.inc>
    Deny From All
</Files>
<Files *.class>
    Deny From All
</Files>
<Files MANIFEST>
    Deny From All
</Files>

See this article for tuning Apache for performance

Create a virtual host

Edit /etc/httpd/conf/httpd.conf

<VirtualHost hostname:80>
ServerAdmin webmaster@mysite.com
DocumentRoot /var/www/html/mysite
ServerName www.mysite.com

Options -Indexes +FollowSymLinks
ErrorLog logs/mysite-error_log
CustomLog logs/mysite-access_log combined
DirectoryIndex index.html index.html.var index.php

<Directory "/var/www/html/mysite">
  AllowOverride all
</Directory>
</VirtualHost>

Start the Web Server

$ /usr/sbin/apachectl configtest
$ /sbin/chkconfig --add httpd
$ /sbin/chkconfig --level 345 httpd on
$ /usr/sbin/apachectl start

Configure PHP

See Description of core php.ini directives

You may need to adjust uploadmaxfilesize postmaxsize There is a good security article on the Gallery2 site that is worth reading.

Install Drupal

Navigate to http://mysite.com/install.php and follow along with the online install. When finished, change permission on /var/www/html/mysite/sites/default/settings.php

$ /usr/bin/sudo /bin/chmod g-w /var/www/html/mysite/sites/default/settings.php

Setup Sendmail

Configure Linux Mail Servers is a comprehensive article, I’ll just hit the highlights.

Configure DNS correctly

Add the following records

• mail pointing to your slice’s IP,
• MX pointing to mail
• TXT pointing to v=spf1 a mx -all

Configure /etc/resolv.conf

Add the following line above the line nameserver

    domain mysite.com

Configure /etc/hosts

127.0.0.1       mysite.com localhost.localdomain localhost

Configure /etc/sendmail.mc

Make sure sendmail is listening on all interfaces (0.0.0.0)

$ /bin/netstat -an | grep :25 | grep tcp
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN

Comment out DAEMON_OPTIONS in /etc/mail/sendmail.mc if it is only listening on loopback

dnl DAEMON_OPTIONS(\`Port=smtp,Addr=127.0.0.1, Name=MTA')

Make sure these lines are commented out to avoid having your server used to forward spam

dnl FEATURE(`accept_unresolvable_domains')dnl
dnl FEATURE(`relay_based_on_MX')dnl

Configure /etc/mail/access

Add your domain

# by default we allow relaying from localhost...
Connect:localhost.localdomain           RELAY
Connect:localhost                       RELAY
Connect:127.0.0.1                       RELAY
Connect:mysite.com                      RELAY

Configure /etc/mail/local-host-names

Add all aliases for your server

    mysite.com

Configure /etc/mail/virtusertable

Add email address/user pairs

    root@mysite.com myuser
    webmaster@mysite.com myuser
    postmaster@mysite.com myuser
    info@mysite.com myuser
    abuse@mysite.com myuser
    apache@mysite.com myuser

Configure /etc/aliases

Edit user that receives root’s email

    # Person who should get root's mail
    #root:           marc
    root             webmaster@mysite.com

Update /etc/sysconfig/iptables by adding

#Allow mail
-A INPUT -p tcp --dport 25 -j ACCEPT
-A OUTPUT -p tcp --dport 25 -j ACCEPT
-A INPUT -p tcp --dport 110 -j ACCEPT
-A OUTPUT -p tcp --dport 110 -j ACCEPT

Optionally Configure spam tools

see Configure Linux Mail Servers

Optionally set up POP3

If you want to read your mail using a client on your PC, you need to set up POP3.

$ /usr/bin/sudo /usr/bin/yum -y install dovecot
$ /usr/bin/sudo /sbin/chkconfig --add dovecot
$ /usr/bin/sudo /sbin/chkconfig --level 345 dovecot on
$ /usr/bin/sudo /etc/init.d/dovecot start

Edit /etc/dovecot.conf

    #protocols = imap imaps pop3 pop3s
    protocols = pop3

Configure your client to receive mail from mail.mysite.com

I don’t recommend that try to configure your slice to relay mail from your PC’s client software. Just use your ISP’s SMTP server to send mail. But if you insist, read this guide first.

Optionally install a mail client

Pine is a simple lightweight mail reader that you can use to read mail from a terminal session when you are logged on to your slice.

$ usr/bin/sudo /bin/rpm -ivh http://rpm.livna.org/livna-release-6.rpm

ensure enable=1 is set to enable=0 in the following files

    /etc/yum.repos.d/livna.repo
    /etc/yum.repos.d/livna-devel.repo
    /etc/yum.repos.d/livna-testing.repo

This will disable the livna repository for regular yum updates

Then, you can install Pine with:

$ /usr/bin/sudo /usr/bin/yum --enablerepo=livna install pine

I recently needed to change a Drupal installation from www.example.com to subdomain.example.com. Here’s how I did it. There is probably a shorter way, but these steps leave the current site untouched until you are sure the new one works.

• Get ready
• Clear Drupal cache
• Dump current Drupal database to a backup file
• Create new database and grant privileges
• Run stream editor against db backup file to fix paths
• Load new database
• Ensure current Drupal site directory is updated in svn
• Export current site from repository to new directory
• Edit files/default/settings.php to point to new db
• Configure Apache to use new directory
• Enter a new A record in DNS
• Test

To get ready, turn off css cache and make sure $base_url is commented out in your files/default/settings.php file. I also disabled clean URLs, not sure if it’s necessary. Your Drupal directory should already be under subversion control. Put up your maintenance page since we are going to clear cache.

The next step is to clear Drupal cache and dump the database to a backup file.

Put the following code in a page, and set up a menu to access it. Make sure you restrict access to admin for this menu. Don’t be lazy and do it from the command line - it’ll be faster this time and slower next.

db_query("DELETE FROM {cache} WHERE 1");
db_query("DELETE FROM {cache_filter} WHERE 1");
db_query("DELETE FROM {cache_menu} WHERE 1");
db_query("DELETE FROM {cache_page} WHERE 1");

Ok, for the command line purists, it’s like this

mysql> DELETE FROM cache WHERE 1;

Then dump the database to a backup file

$ /usr/bin/mysqldump dbname > mysite-backup.sql

Make the current site accessible again by taking down your maintenance page.

Create a new database and grant privileges

mysql> create database newdbname;
mysql> grant all on newdbname.* to 'drupaluser'@'localhost';

Before loading the new database we need to run a stream editor against the backup file and change any hard coded paths.

Check the backup file by grep’ing for the previous subdomain and path of the current install directory

$ /bin/grep -r mysite *

$ /bin/grep -r www *

Then edit something like this

$ /usr/bin/perl -pi.bak -e's/http:\/\/www.example/http:\/\/subdomain.example/g;
> s/\/html\/mysite/\/html\/mynewsite/g;' mysite-backup.sql

And load the new database

$ /usr/bin/mysql newdbname < mysite-backup.sql

My Drupal installation was in /var/www/html/mysite under subversion control. After cleaning up the working directory and checking in all changes, I exported mysite into a new working directory.

$ cd /var/www/html
$ /usr/bin/svn export file:///var/svn/repos/mysite mynewsite

Make sure the files/ directory is writable by the web server process owner.

Edit files/default/settings.php and change the name of the database, and make sure $base_url is commented out.

Configure a new virtual host in /etc/httpd/conf/httpd.conf for subdomain.example.com. Copy the <virtualhost> entry for www.example.com and change the ServerName, DocumentRoot, and log file name. If you have any Directory entries, change the path to your new directory. Check your configurations changes

$ /usr/sbin/apachectl configtest

And restart

$ /usr/sbin/apachectl graceful

Make sure you have an A record in DNS for subdomain.example.com

Finally test every page.

Within hours of a new slice’s creation, /var/log/secure will start recording brute force attack attempts to gain access to your slice unless you take steps to secure your slice. If you doubt it, login to your slice and execute lastb.

This post is a compilation of useful steps I found in the articles I’ve cited in the References. I’ve combined and adapted them for my situation which is a local server running Fedora 6 setting up a newly built remote Fedora 6 slice from Slicehost. If you have a different setup, your mileage may vary.

Lets start from the creation of a new Fedora 6 slice. You’ve received your new root login password, and Slicehost has helpfully suggested that you change it immediately after logging in. dull-thing Login from local as root

[user@localhost ~]$ /usr/bin/sudo ssh your.slice.ip.address

Change the root password to a strong password

[root@remote ~]$ /usr/bin/passwd

Next, before we disable root login via ssh, we need to create a new user id that we can use to login to the slice. If you are not going to turn off password authentication, then pick a name that you have not used publicly. Remember, we are trying to defend against a brute force attack. Therefore, don’t give the attacker an entry by using a user id that can be guessed. Its easy to guess root and that is one reason why we will be disabling root login via ssh.

[root@remote ~] /usr/sbin/useradd user_id

Change the user’s passwd

[root@remote ~] /usr/bin/passwd user_id

Your new slice doesn’t have sudo installed. Before we yum install anything, we’ll first update the system.

[root@remote ~] /usr/bin/yum -y update

Next, install sudo

[root@remote ~]$ /usr/bin/yum -y install sudo

Give the new user sudo privelage. Edit /etc/sudoers and find the line that says

root ALL=(ALL) ALL

Duplicate this line and change root to user_id.

[root@remote ~]$ /usr/sbin/visudo

Before continuing, start a new terminal on local (don’t exit your current session in case you need it) and test that you can login via your new user id, and that the new user can execute su and sudo successfully. If the user id on the remote system is different from the user id on your local system, you can use the -l switch to specify the user to login as on the remote machine.

[user@localhost ~]$ ssh -l remote_user_id the.slice.ip.address

It would be also be a good idea to make sure you can reach your slice via the console from SliceManager.

Next we are going to disable root login via ssh because a lot of attacks will start with trying to login as root. To disable root login via ssh, edit the file /etc/ssh/sshd_config and set PermitRootLogin to no.

[root@remote ssh]$ /bin/vi sshd_config

Note: Commented lines are defaults. A good practice is to duplicate the default line, uncomment the duplicate line, and edit.

#PermitRootLogin yes
 PermitRootLogin no

Restart sshd

[root@remote ssh]$  /sbin/service sshd restart

Test that you can no longer login as root.

[user@localhost ~]$ sudo ssh the.slice.ip.address

You should get the response

Permission denied, please try again.

If you don’t want your logs filled and your slice’s resources wasted by processing brute force attacks, then there are some additional things that can be done.

First we are going to set things up so that eventually we can disable password authentication for ssh and use public key cryptography.

Generate a key on your local system

[user@localhost ~]$ /usr/bin/ssh-keygen -t rsa -f ~/.ssh/id_rsa

Create .ssh directory on remote system and copy the public key you just created to the .ssh directory.

Create the directory .ssh on remote.

[user@localhost ~]$ /usr/bin/ssh user@domain
> 'mkdir ~/.ssh;chmod 700 ~/.ssh'

Note: The “>” on the second line of the command above is the system prompt when you continue the command on a new line with a backslash. Don’t type “>” before “mkdir”.

Note: The following directories on remote must be writable only by user or they will be ignored.

drwxr-xr-x  ...  /home/user
drwxr-xr-x  ...  /home/user/.ssh
-rw-r--r--  ...  /home/user/.ssh/authorized_keys

Copy your public key to the remote server. Since this is a new slice you won’t have scp installed unless you have already executed yum install openssh-clients, so we’re going to copy like a wizard using file redirection.

[user@localhost ~]$ /usr/bin/ssh user@domain cat <
> ~/.ssh/id_rsa.pub ">" ~/.ssh/authorized_keys

Note: The “>” on the second line of the command above is the system prompt … I know I need to find a better way to display these commands!

Ensure that the file authorized_keys is writable only by user

[user@localhost ~]$ /usr/bin/ssh user@domain 'chmod 600
> ~/.ssh/authorized_keys'

If ssh agent is not running on local system

[user@localhost ~]$ /usr/bin/ssh-agent $SHELL

Add key to memory on local system

[user@localhost ~]$ /usr/bin/ssh-add

Test that you can login to your slice without being prompted for a password or passphrase.

[user@localhost ~]$ ssh the.slice.ip.address
Last login: Sat Apr 14 14:35:25 2007 from ...
[user@remote ~]$

Now that we have created a user to login to the slice and set up our public key, we can turn off password authentication and passphrashe authentication, and disable the older less secure protocol 1. Edit the file /etc/ssh/sshd_config

[user@remote ~]$ /usr/bin/sudo /bin/vi /etc/ssh/sshd_config

#PasswordAuthentication yes
PasswordAutheentication no

#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

#Protocol 2,1
Protocol 2

Also if you installed openssh-clients, edit the file /etc/ssh/ssh_config and restrict it to Protocol 2 as well. sshd_config is for the daemon and ssh_config, the client. Both are restricted to Protocol 2 to ensure that a man-in-the-middle attack cannot cause both client and server to degrade to the less secure Protocol 1.

Restart sshd

[root@remote ssh]$  /sbin/service sshd restart

Again, open a new terminal and test that you can login.

Next we want to change the port that ssh listens to. This will cut down on a lot of log entries, but it doesn’t make the system more secure. Again edit /etc/ssh/sshd_config

#Port 22
Port 2222

Pick something more original than 2222. Preferably pick an unassigned port above 1000, check this list.

You might also consider changing MaxAuthTries, MaxStartups, and LoginGraceTime, see Securing SSH

Don’t forget to restart sshd after any changes.

[root@remote ssh]$  /sbin/service sshd restart

Login and test the port change

[user@local ~]$ ssh -p 2222 the.slice.ip.address

Next we want to install denyhosts and start it running

[user@remote ~]$ /usr/bin/sudo /usr/bin/yum -y install denyhosts
[user@remote ~]$ /usr/bin/sudo /sbin/chkconfig denyhosts on
[user@remote ~]$ /usr/bin/sudo /etc/init.d/denyhosts start

The default denyhosts configuration meets most needs but if you want to edit the configuration, the file is /etc/denyhosts.conf. See the documentation at DenyHosts

Next we want to setup a firewall

[user@remote ~]$ /usr/bin/sudo /usr/bin/yum -y install iptables

Edit /etc/sysconfig/iptables and paste in the following configuration from CentOS: Network Security & Django which worked for me, thanks djangojoe. Make sure to open the port that you have SSH listening on.

# By default drop all incoming and forwarded traffic
# Allow all outgoing traffic

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow returning packets
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow incoming traffic on ports 80 and 443 for web server
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow local traffic
-A INPUT -i lo -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type ping -j ACCEPT

# Allow incoming SSH
-A INPUT -p tcp --dport 2222 -j ACCEPT

COMMIT

Change permission on /etc/sysconfig/iptables to make it writable only by root

[user@remote ~]$ /usr/bin/sudo chmod 600 /etc/sysconfig/iptables

Restart the firewall

[user@remote ~]$ /usre/bin/sudo /sbin/service iptables restart

Ok, we’re done and a bit more secure. Many thanks to the authors of the following references.

References

• Securing SSH
• CentOS: Network Security & Django
• Port Numbers
• Getting Started with SSH
• DenyHosts

Like it says on the typo wiki download page, it could be as easy as

$ gem install typo

$ typo install /some/directory

For the above to work, we need to satisfy some dependencies. This post will step through what is needed to get a typo instance up and running on a new Fedora 6 Slice from Slicehost .

You need to have the rails stack in place, see my earlier post Installing Rails on Fedora 6, and download the script install_rails_fc6-sh

Assuming a brand new Fedora 6 slice from Slicehost with DNS set up, login in to your slice and change the root password.

[root@localhost ~]$ slogin example.com

On your local server, as root, copy the script to your slice

[root@localhost ~]$ ssh example.com cat < install_rails_fc6-sh ">" install_rails_fc6-sh

Log back into your slice, and execute the script

[root@localhost ~]$ slogin example.com

[root@example.com ~]$ /bin/bash install_rails_fc6-sh

Next we need sqlite3. The gem thinks sqlite3-ruby is a required dependency even if you don’t plan on using sqlite3.

Before you install sqlite3, you’ll need c++

[root@exammple.com ~]$ yum install gcc-c++

I couldn’t figure out how to yum install sqlite3, so we’ll roll our own. Change to your favorite source directory to build source

[root@example.com ~]$ cd /usr/local/src

[root@example.com src]$ /usr/bin/wget http://www.sqlite.org/sqlite-3.3.13.tar.gz

[root@example.com src]/bin/tar xvf sqlite-3.3.13.tar.gz

[root@example.com src]$ cd sqlite-3.3.13

[root@example.com sqlite-3.3.13]$ ./configure

[root@example.com sqlite-3.3.13]$ /usr/bin/make

[root@example.com sqlite-3.3.13]$ /usr/bin/make install

Now you should be able to run

[root@example.com ~]$ /usr/bin/gem install typo

[root@example.com ~]$ typo install /var/www/apps/mytypo-directory

Obviously, change mytypo-directory to whatever you’d like to call your typo install directory.

I like the apache+mongrel setup, so I followed the configuration that the excellent deprec gem uses.

Download typo.conf and move it to your slice in the directory /etc/httpd/conf/apps/.

Edit the file, replacing example.com with your hostname, change the <directory> directive, and set the balance member ports to the ones you’ll configure the cluster with.

Check your config with

[root@example.com ~]$ /usr/sbin/apachectl configtest

Configure the mongrels as shown here

Change directories to the directory where you installed typo

[root@example.com ~]$ cd /var/www/apps/mytypo-directory

[root@example.com directory]$ /usr/bin/mongrel_rails cluster::configure -e production -p 8000 -N 2 -c /var/www/apps/mytypo-directory -a 127.0.0.1

If you didn’t run install_rails_fc6-sh, you’ll need to configure mongrel to run after reboot

[root@example.com ~]$ /sbin/chkconfig --add mongrel_cluster

[root@example.com ~]$ /sbin/chkconfig --level 345 mongrel_cluster on

If the chkconfig commands fail with a don't know, make sure that you have the init script in /etc/init.d/. Copy it from the gem

[root@example.com ~]$ /bin/cp /usr/lib64/ruby/gems/1.8/gems/mongrel_cluster-0.2.1/resources/mongrel_cluster /etc/init.d/

Restart apache

[root@example.com ~]$ /usr/sbin/apachectl graceful

and login to your typo instance via your browser at the URL

http://www.example.com/admin

In this post, we installed typo directly on the slice as root to simplify the steps. You want to setup a user and install typo as that user. Also, in this post we used the default sqlite3 database.

Finally, there are a few things left to consider like backing up the database and putting your instance of typo under version control. I’ll cover these topics in a future post.

Update: 5 April

I revised the steps to make them a little clearer, and tested on my sandbox slice.

I had read some good things here and here about the deprec gem, so I thought I’d look into using it set up a new slice at Slicehost. deprec was written with Ubuntu as the target distribution. Mike Bailey, the creator of deprec, is very clear about that, so I expected some problems making it work for Fedora. I followed the instructions on the slicehost wiki.

variorum

Lets go straight to the end of the story in the same spirit of the slicehost wiki. The command 'cap installrailsstack’ will not work on Fedora because it relies on 'apt-get'. So we’ll be writing our own shell script to 'yum install' what we need. Another change we’ll need to make is in the file deprec-1.3.1/lib/deprec/thirdparty/mongrelcluster/recipes.rb. Here we need to replace 'update-rc.d' with 'chkconfig'. See the comments in the script to perform this step manually, the script doesn’t touch the deprec gem. Finally, because deprec installs apache from source into '/usr/local/apache2' and we are going to 'yum install httpd', we’ll need to set up some directories that 'cap deprec_setup' is expecting. Additionally, we’ll be setting up mysql to start at boot, and setting the ServerName to hostname in /etc/httpd/conf/httpd.conf. You still need to setup the initial database accounts and turn off root login via ssh. See the comments for the commands.

The wiki can be successfully followed after running the installrailsfc6.sh (download) by just skipping the command 'cap installrailsstack’. The comments at the top of the script walk you through the steps, so I’m not going to walk through it here. If the comments in the script are too arcane, please let me know.

You’ll note that the script must be executed as root because sudo is not available on a new FC6 slice. You may prefer to install sudo and execute the remaining commands using sudo. Please don’t download and execute the script without thoroughly confirming that it will do what you want. The script is intended to be run on a newly built slice, so don’t run it if you have already started configuring your system, I haven’t tested that scenario. I don’t recommend executing the script remotely via ssh because some of the gem install’s are interactive, and at least for me didn’t wait for input when executed remotely. I’m not the only one to comment on this feature . Move the script to your slice using ssh, see the comments in the script for the command.

Warning: Opinion Follows

My personal opinion is that setting up the Rails stack is best handled by using the shell and package manager for your distribution. This script has not improved upon the weaknesses present in deprec. Namely, hard coded versions, URLs, paths, etc. Therefore, I don’t recommend that you execute this script without reviewing it carefully precisely because it is likely to fail in the future when versions and URLs change. This is the beauty of using a package manager, all those details are handled for you. Unfortunately, not everything we need for a Rails stack can be yum installed. This script is quick and dirty and passes only the “Works on my Machine” test, where “my machine” is a Slicehost FC6 slice circa March 2007. Although I have tested the script many times, it is, nevertheless, a first pass at documenting the process (executable documentation tends to be more repeatable). OK, you’ve been warned.

Update 4 April

I retested the script today and sure enough, it was broken. For some reason, it no longer copies the init script mongrel_cluster to /etc/init.d. You’ll see these errors when the script tries to setup mongrel to start after a reboot.

error reading information on service mongrel_cluster: No such file or directory

error reading information on service mongrel_cluster: No such file or directory We need to copy

/usr/lib64/ruby/gems/1.8/gems/mongrelcluster-0.2.1/resources/mongrelcluster

to /etc/init.d/ and change permission to make it executable.

chmod 755

I’ve updated the script. IMHO, the gem package for Mongrel needs to work with the version option. The quick fix just adds to the problem by hardcoding another version …