Galaxy Installation and Configuration

Installation of Galaxy

Setting up the Python Environment

$ cd /opt/sw/Galaxy
$ mkdir MERCURIAL
$ cd MERCURIAL
$ virtualenv --no-site-packages PYTHON-ENV
New python executable in PYTHON-ENV/bin/python
Installing distribute...................done.
Installing pip...............done.
$ mkdir galaxy-python
$ ln -s $PWD/PYTHON-ENV/bin/python galaxy-python
$ . PYTHON-ENV/bin/activate

Cloning the Galaxy Repository

$ hg clone https://bitbucket.org/galaxy/galaxy-dist/
destination directory: galaxy-dist
requesting all changes
adding changesets
adding manifests
adding file changes
added 7829 changesets with 30613 changes to 6311 files
updating to branch default
3926 files updated, 0 files merged, 0 files removed, 0 files unresolved

Configuration and Testing

Configuring the Main Galaxy Server

$ mkdir galaxy-IMPORT
$ cd galaxy-dist
$ cp universe_wsgi.ini{.sample,}
$ cp tool_shed_wsgi.ini{.sample,}

Edit universe_wsgi.ini. Configure the server:main section, adding new variable assignments as follows:

[server:main]
port = 9007
host = 0.0.0.0

If you chose a different port number than 9007 when you were setting up the permissions sections of your StarCluster configuration file, then you need to reflect that in the port variable in the Galaxy configuration.

Configure the app:main section, adding new variable assignments as follows:

[app:main]
library_import_dir = /opt/sw/Galaxy/MERCURIAL/galaxy-IMPORT
allow_library_path_paste = True

Testing the Main Galaxy Server

Start the Galaxy server with the run.sh script:

$ ./run.sh
... bunch of text ...
Starting server in PID 3139.
serving on 0.0.0.0:9007 view at http://127.0.0.1:9007

On the computer where you have the StarCluster tools installed, you can get the DNS name of your Galaxy server. (Replace the sctest argument in the command pipeline below with the name of your EC2 cluster.)

$ starcluster lc | grep -A10 sctest | grep 'master running'
master running i-060c047b ec2-23-20-53-82.compute-1.amazonaws.com

From this information form, a HTTP URL with the DNS name of the Galaxy server and port 9007. For example, http://ec2-23-20-53-82.compute-1.amazonaws.com:9007. Point your favorite web browser at this URL. If all has gone according to plan, then you should see be able to bask in the glow of a running Galaxy instance. But, don’t get too cocky because there are still plenty of opportunities for failure in the work that remains to be done.

While you are at the Galaxy web page, click on the User dropdown menu in the menu bar along the top of the web page and select the Register menu item. Setup an account for yourself. You will want to do this so that you can add yourself to the administrators list for the server.

After you have setup an account for yourself, you will want to stop the Galaxy server so that you can continue configuring it. (Technically, a --reload argument can be supplied to the run run.sh script which allows the server to monitor configuration files for changes and reload its state on-the-fly. But, it is still safer to perform a shutdown and restart of it.)

Stopping the Main Galaxy Server

Unfortunately, the Galaxy server is not guaranteed to stop via a keyboard interrupt. You may have noticed that near the end of the server initialization output to your terminal that the PID of the server was provided. You can use this PID to kill the server process. If you cannot find the process identifier, then it is fairly safe to use a command such as pkill or killall with python as the argument. For example:

$ kill 3139

Or:

$ pkill python

Configuring the Galaxy Tool Shed Server

Edit the tool_shed_wsgi.ini file. In the server:main section, ensure that the following assigment is made:

[server:main]
host = 0.0.0.0

In the app:main section, ensure that the database_file assignment is uncommented:

[app:main]
database_file = database/community.sqlite

Testing the Galaxy Tool Shed Server

Start the Galaxy tool shed server with the run_community.sh script.

$ sh run_tool_shed.sh

Compose a HTTP URL for your web browser, as you did to access the main Galaxy server, using port 9009 or whatever port number you chose instead. (E.g., http://ec2-23-20-53-82.compute-1.amazonaws.com:9009.) Point your web browser at this URL and check out your newly erected tool shed (if everything went well). Shiny, isn’t it?

While you are at the Galaxy tool shed web page, click on the User dropdown menu in the menu bar along the top of the web page and select the Register menu item. Setup an account for yourself. You will want to do this so that you can add yourself to the administrators list for the server.

After you have setup an account for yourself, it is recommended that you stop the tool shed server.

Securing the Galaxy Servers

Assuming that you have created an account for yourself on both the main server and the tool shed server, you are now ready to elevate yourself to an administrative role.

Edit the universe_wsgi.ini and community_wsgi.ini files and provide the following assignments in their app:main sections.

[app:main]
admin_users = em@msu.edu
require_login = True
allow_user_creation = False

Note

In the above, the value of the admin_users assignment should be changed to the email address which you provided when you registered your Galaxy account.

Connecting the Galaxy Tool Shed to the Main Server

Once you have developed tools in your Galaxy tool shed, you may wish to transport those tools to your main server to perform proper integration testing. Galaxy provides a transport mechanism for this purpose.

$ mkdir ../galaxy-SHED

Edit tool_sheds_conf.xml and add a new tool_shed entry, replacing the value of the url assignment with the HTTP URL for your tool shed server:

<?xml version="1.0"?>
<tool_sheds>
    <tool_shed name="Galaxy main tool shed" url="http://toolshed.g2.bx.psu.edu/"/>
    <tool_shed name="Galaxy test tool shed" url="http://testtoolshed.g2.bx.psu.edu/"/>
    <tool_shed name="My Tool Shed" url="http://ec2-23-20-53-82.compute-1.amazonaws.com:9009/"/>
</tool_sheds>

Note

You cannot use localhost in the HTTP URL for your toolshed server. This is possibly because the URL is used on a web page rendered on your client web browser and Galaxy processes the submitted URL in such a way that localhost would be considered relative to your client rather than the Galaxy server. Unfortunately, the limitation forces you to update this configuration file every time you are working with a new instance or else break the connection between the main server and the tool shed server.

Edit shed_tool_conf.xml (not the same as the above file - don’t blame me for the confusing nomenclature) and change the value of the tool_path assignment to the path to your tool shed directory (../galaxy-SHED is used in this documentation).

<?xml version="1.0"?>
<toolbox tool_path="../galaxy-SHED">
</toolbox>

Edit universe_wsgi.ini and add the following assignment to the app:main section:

[app:main]
tool_config_file = tool_conf.xml,shed_tool_conf.xml

Testing the Tool Shed Connection

Fire up the Galaxy main and tool shed servers with their respective scripts, run.sh and run_community.sh. Once and if they are up, login to the main Galaxy server. Click on the Admin menu in the menu bar across the top of the web page. A sidebar with various administrative tasks will present itself. Find the Tool sheds section and click on the Search and browse tool sheds link. You should see a button labeled My Tool Shed. Click on this button and select Browse valid repositories from the ensuing dropdown menu. If this task is completed without error, then you should be good to go.

Onward to actually developing and deploying tools....

Resuming Galaxy on a New EC2 Instance

From time to time, you may need to stop your EC2 instance and then start a new one at a later point. Some steps will need to be done to restart the Galaxy servers. There are recapitulated below:

cd /opt/sw/Galaxy/MERCURIAL/galaxy-dist
. ../PYTHON-ENV/bin/activate
bash run.sh &
bash run_community.sh &