Thanks Greg, In case you are not aware of it, the Galaxy tool shed wiki explains the
tool shed: http://wiki.g2.bx.psu.edu/Tool%20Shed
I am aware, thanks, although I won't exclude the possibility that I've misunderstood something ... I've "inherited" a galaxy setup from someone (details: a contractor set it
up but left it unfinished so I'm completing the job while discovering and documenting what was done). The catch: it's setup as a twin galaxy instance with one as a front-end web-server and the other as the job runner.
Just to confirm, you have set up a single Galaxy instance (with a single database on the back-end) with multiple web front-ends - is this correct?
Right - a single database with one web front-end and one job-runner. And here's a detail that I forgot and may be important ... they're on different machines. They share the db and a shared data space but are on different VMs. The Galaxy tool shed is a separate application that has no dependencies on
a Galaxy instance (and vice-versa), although a Galaxy instance and a tool shed instance can each communicate with the other, so your question is a bit confusing. A single Galaxy tool shed can be used by any number of Galaxy instances, so if you create a repository in a tool shed instance and upload tools to it, any number of Galaxy instances will be able to access that tool shed and install the repositories from it.
Right - but setting up the toolshed is not the confusing point for me. It's how the job-runner gets to use a tool installed from a toolshed when it's on a different machine to the front-end. The tool has to be installed into the job-runner as well, right? As said, I inherited this system, so I'm discovering how it's been setup. cheers p -- Paul Agapow (pma@agapow.net)