Frequently Asked Questions

There are a number of ways, the easiest is to use our Brightbox Capistrano recipes.

Login over SSH as the rails user and run commands using the sudo tool, which asks for your rails user password and then runs the command as root:

sudo /etc/init.d/apache restart

We recommend running each command you need using the sudo command, but if you need to get a root shell to run a number of commands, just run the bash command with sudo

sudo bash

See the SSH support page for more information on setting up an ssh key for direct root access.

You can issue a “soft” or “hard” reboot to any of your Brightboxes within the Control Panel.

A soft reboot is the safest way to reboot your Brightbox and is equivalent to running the shutdown -r command via the command line, which ensures everything has been shutdown nicely before restarting. You should always try to soft reboot your Brightbox first.

If your Brightbox has become unresponsive and the soft reboot does not work, you will need to issue a hard reboot.

A hard reboot is equivalent to pulling the power cable from a server, then starting it. It does not guarantee processes are shut down nicely or that data has been written to disk.

If you prefer to perform the reboot from your Brightbox server, run the following command via ssh:

sudo shutdown -r now

Each Brightbox comes with two virtual network interfaces each one on a separate physical network segment. eth0 is Internet facing and carries your web and remote access traffic. eth1 is a private network and is used to access local services, such as the MySQL and backup servers. Having these separate helps with security and performance. The Brightbox Network page has more details.

Dedicated MySQL services are available with all Brightbox hosting packages. The MySQL Cluster page has more information on configuring your Rails app to use them.

All Brightboxes are protected by our firewall with only a limited set of ports open. If you require additional ports to be opened for your Brightbox, please submit a request with the Help Desk. The Brightbox Network page has more information about the firewalls.

All Brightboxes have access to a dedicated smtp relay.

You can configure the Cron daemon to run any commands you like whenever you like.

By default PHP isn't supported, but you can easily install it. See the PHP documentation for more details.

Coming soon.

The most common cause of this is stale Mongrel pid files. You just need to delete the stale mongrel pid files from the log directory.

Stop your app using the stop_mongrel_cluster task.

ssh into your Brightbox and run the command:

rm /home/rails/myappname/current/log/*.pid

Then start up your app again using the start_mongrel_cluster task.

Mongrel is partially threaded. It has one thread to manage inbound http connections, one thread to run the Rails application and a third thread to handle large file uploads so that the main Rails thread doesn't block.

What you are seeing on the process list is all these threads due to the way that Linux implements threading (by using 'process cloning'). If you run 'ps uxf' you will see the way the mongrel threads are linked to each other in two distinct sets of three.

So yes it is correct, when you start a mongrel you'll get three processes.

SSH is incredibly fussy about file permissions and file ownership. Make sure that you have followed the instructions about installing a new public key.

Check that

• you have put the key in ~/.ssh/authorized_keys. Note the 'z' and plural 'keys'.
• all the files are owned by the user.
• the file permissions on the ~/.ssh directory are set correctly (no group or other write).
• the file permissions on the home directory ~ are set correctly. (no group or other write).
• that you have specified the name of the key on the ssh command line with the -i option if you are not using the default key name.
• that you have put your key in your agent with ssh-add and are using the correct Agent forwarding option (-A on Ubuntu) if you are logging in with another machine as the gateway.

If you're running Rubygems less than v1.2.0 you may experience problems installing gems. This is because old versions of rubygems tried to keep an entire index locally and that index is now too big for 256Mb (and even some 512Mb) machines to cope with.

In this case you will not be able to update rubygems using the usual gem update –system and you will need to upgrade by hand.

• First download the rubygems tar file by hand from the Rubyforge website into a suitable temporary directory.

  wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
  tar xvf rubygems-1.3.1.tgz
  cd rubygems-1.3.1
  

• Then run the setup program via sudo.

  sudo ruby setup.rb

• Check the version of RubyGems

  gem -v

  and see if the version you expected is actually installed.

• If you get an error, or the wrong version then you might need to re-symlink the gem executable
• First check that a file exists called /usr/bin/gem1.8
• If it does, then remove the original gem executable

  sudo rm /usr/bin/gem

• Relink the new executable

  sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

• Recheck the RubyGems version

  gem -v

Rails 2.1.1 and Rails 2.2 include a fix for a potential Denial of Service attack caused by the REXML XML processing library. When an application is deployed, the code checks the REXML library's version to see if it needs the fix.

Unfortunately, Ruby 1.8.4, which ships with Ubuntu Dapper, has the version constant incorrectly named - it should be REXML::VERSION but is actually REXML::Version. Meaning that when you try to deploy your application, it cannot find the constant and falls over.

The quick fix for this is to edit the REXML library by hand, as described here: http://blog.brightbox.co.uk/posts/uninitialized-constant-rexmlversion-with-rails-211-and-rails-22. We are evaluating more permanent solutions.