I recently wrote some code to run Galaxy jobs as a different user, and
was just merging my codebase (https://bitbucket.org/pvanheus/galaxy)
with galaxy-central when I noticed that code doing the same thing is now
part of galaxy-central. The code in galaxy-central is more
straightforward than mine, in that it uses external scripts and sudo,
whereas mine spawns daemons (each on owned by the relevant system user)
and provides a proxy object (implementing the bits of the Python DRMAA
API that Galaxy uses) to direct work to the correct daemon. In practice
the differences are, however, minor - the effect is the same: processes
running as the system user of choice control jobs using DRMAA calls.
One issue though is the question of Galaxy user to system user mapping.
The current approach (in galaxy-central) is to split the Galaxy username
at the @ sign and use everything before the @ as the system user (so
p...@sanbi.ac.za becomes pvh). If the system user does not in fact exist,
an exception (in the DRMAA job runner) will result. I don't know if
anyone will find it useful to have a different approach to Galaxy to
system user mapping? For now the current approach is fine for the setup
we have at SANBI.
Is anyone using this "run as user" code in production?
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at: