While the approach of the previous section is simple to set up, it doesn't give you much control over which gems are offered on the server. If you want to offer gems without installing them, you have the option to create a gem server manually. In the case of Acme, where they already have Apache installed on the production machine, it makes sense to make use of that to present the gems over HTTP. This also has the advantage that Apache starts and stops with the physical machine, due to its incorporation into the init sequence (see, Apache on Linux and Mac OS X in Chapter 4); with the gem_server command, you would have to write your own start/stop script to get this happen.

To set up a gem server using Apache on Linux, follow these steps:

First, create a directory to use as the base for the gem server. To keep things simple, I created this as a sub-directory inside Apache's htdocs directory (as root):

$ mkdir /opt/apache2.2/htdocs/gemserver

Next, create the directory, which will hold the gems:

$ mkdir /opt/apache2.2/htdocs/gemserver/gems

Gems are typically available for download from Rubyforge, though they may be offered from non-standard repositories. For example, you can get the Rails gems from http://gems.rubyforge.org/gems/. We'll start by getting the Rake gem to demonstrate:

$ cd /opt/apache2.2/htdocs/gemserver/gems/
$ wget http://gems.rubyforge.org/gems/rake-0.7.3.gem

A gem is just a zip file with a nonstandard suffix (.gem). Put all the gem files you want to serve into the gems directory.

Configure Apache to serve the new directory as a virtual host by adding the following directive to /opt/apache2.2/conf/httpd.conf:

<VirtualHost *:80>
ServerName gems.company.local
DocumentRoot /opt/apache2.2/htdocs/gemserver
</VirtualHost>

You will need to add the new domain name to the DNS as appropriate: see Chapter 6, Into Production for details. Reload Apache:

$ /etc/init.d/apache2.2 graceful

The final step to enable your repository is to index the gems it contains:

$ index_gem_repository.rb -d /opt/apache2.2/htdocs/gemserver

Note that the -d switch should reference the directory above the gems directory. This adds two files, yaml and yaml.Z, and a directory, quick, to the gemserver directory. These are used by clients (like the gem command line tool) to discover gems in the repository.

Now, test that the repository responds correctly to gem from a remote machine:

$ gem list --remote --source http://gems.company.local/
*** REMOTE GEMS ***
Need to update 1 gems from http://gems.company.local/
.
complete
rake (0.7.3)
Ruby based make-like utility.

Using this technique, you can make a precise set of gems available to developers. The down side is that you need to run the index_gem_server.rb command each time you add or change gems, to update the index (or you could use cron to do this automatically); you have to maintain the repository and ensure that the dependencies between gems are satisfied; and the documentation isn't displayed if you visit http://gems.company.local/ (the gems aren't necessarily installed, so may not have documentation available).

You can set up developer machines to use the repository, as their default, as outlined in the section: Setting Your Gem Server as the Default on the previous page.