Common tasks in Galaxy

by Paul Agapow
in science

tagged computational biology, galaxy

It's all there in the documentation, but sometimes it's hard to find. This document gives you another place to look.

So how do I ...

... create admin users?

Curiously, the identity of admin users is hardcoded into the Galaxy configuration file. (Which makes it secure, I guess, but separate from the rest of Galaxy's role mechanism.) Edit universe_wsgi.ini and set admin_users to a comma delimited list of user emails:

admin_users = user1@hpa.org.uk,user2@bbsrc.ac.uk

The Admin menu will then appear on the top menubar.

See https://bitbucket.org/galaxy/galaxy-central/wiki/Admin/AdminInterface

Note: The admin document is as yet, a trifle incomplete. It's unclear what happens if one of these addresses is invalid (i.e. is for a non-existent user). Also note a confusion about identifying a user - sometimes Galaxy refers to user name and sometimes to user email address.

... disable guest access?

By default, galaxy allows any jackass with a web-browser to run tools. (Although their history is not retained.) Again, edit universe_wsgi.ini and set require_login:

# Force everyone to log in (disable anonymous access).
require_login = True

... disable self-registration?

By default, any guest (visitor) can register an account on a Galaxy instance. Once again, edit universe_wsgi.ini and set allow_user_creation

# Allow unregistered users to create new accounts (otherwise,
# they will have to be created by an admin).
#allow_user_creation = True

... reset a user's password?

(Digression: of course, if a user forgets their password, they could just reset it themselves to have email sent to them. But we have a Galaxy instance without email configured an so another way is needed.)

In the admin menu, go to manage users, select the user and then "reset password". You'll come to a page where you can actually set their password.

... stop a job?

Perhaps it's a runaway job. Perhaps it's been running for too long. Maybe you're just bored. The important thing is that THE JOB MUST DIE.

When logged in as an adminstrator, go to the admin menu and then the manage jobs tool. A message can be sent to the user when this is done. This can also be used to stop new jobs from being dispatched, such as when preparing for shutdown.

... make someone an admin for this data / library / whatever and nothing else?

Can't be done. Galaxy has a fairly simple idea of admins: a superuser is a superuser is a superuser. An administrator can do _anything_. You can give someone permissions management over a data library, but that's it.

... do X by directly editing the database?

Don't. It's severely messy down there and anything could go wrong. Seriously - the schema is complex and it's hard to make even simple edits.

... maintain Galaxy?

Users are advised to run the scripts in <galaxy-dist>/scripts/cleanup_datasets/cleanup_dataset.py regularly / daily, so as to mop up old and deleted data. (Although there's so many scripts in that dir, it'd be nice to get a heads-up about which did what and were how important.) A cron'd script to call them all like this should do the job:

#!/bin/sh
cd /home/galaxy/galaxy-dist
bash ./scripts/cleanup_datasets/delete_datasets_main.sh
bash ./scripts/cleanup_datasets/delete_userless_histories_main.sh
bash ./scripts/cleanup_datasets/purge_histories_main.sh
bash ./scripts/cleanup_datasets/purge_datasets_main.sh

From Greg Von Kuster <http://lists.bx.psu.edu/pipermail/galaxy-dev/2010-February/001987.html >

... make development easier?

Strangely, there's a really useful utility for devs hidden in the Admin menu: "Reload a tool's configuration". It seesm to do what it says on the tin - reload the tooo configuration files, which normally would take an instance restart. Oddly, the reload is only offered for a subset of the installed tools, so there may be some subtleties involved here.