I remember there previously being an additional tool that ran on a
different port from galaxy that allowed for monitoring of performance
and jobs running. Is this tool still packaged with galaxy and if so how
can it be activated.
Dear Mohamed, Karim, galaxy-dev list,
A rapid e-mail to inform you that we plan to work on this task in the upcoming weeks with Thimothée and Valentin, copied. We have had some exchanges with Eric (Rasche) and Björn (Grüning) and it seems that using the Galaxy "interactive environment" functionality is a good way to proceed. Don't hesitate to give us more informations to collaborate on it...
Wishing you a good week end.
Cheers,
Yvan
-------- Message d'origine --------
De : "Md. Rezaul Karim" <rezaul.karim(a)insight-centre.org>
Date : 26/05/2017 15:45 (GMT+01:00)
À : Mohamed Kassam <k.mamoud(a)gmail.com>
Cc : Galaxy Dev List <galaxy-dev(a)lists.galaxyproject.org>
Objet : Re: [galaxy-dev] Shiny in Galaxy
+1
On May 26, 2017 2:44 PM, "Mohamed Kassam" <k.mamoud(a)gmail.com> wrote:
Dear all,
I have a shiny application working in my RStudio, but I would like to integrate it to Galaxy that the users can call my application via Galaxy .
Thanks in Advance,
Mohamed
___________________________________________________________
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:
https://lists.galaxyproject.org/
To search Galaxy mailing lists use the unified search at:
http://galaxyproject.org/search/
Hi all,
This January before PAG on the Wednesday and Thursday before PAG (January
10-11) in San Diego we are planning a GMOD hackathon. We expect that
participants will be interested in solving problems/creating solutions
related to Tripal, JBrowse, Apollo, and Galaxy but if you're interested in
another GMOD project, by all means, let us know! We expect this hackathon
to overlap with the Tripal hackathon that is on January 11 (I'm pretty
sure; right Stephen?)
If you are interested in attending this hackathon, please let me know so I
can be sure we have an appropriately sized space. And if you're coming for
the pre-PAG hackathon, consider staying for PAG, since there is always a
lot of GMOD-related content at the meeting!
Thanks,
Scott
--
------------------------------------------------------------------------
Scott Cain, Ph. D. scott at scottcain dot
net
GMOD Coordinator (http://gmod.org/) 216-392-3087
Ontario Institute for Cancer Research
Dear experts,
I've an issue with the bam_to_bigwig (brad-chapman) tool from the ToolShed.
I've installed it using Conda to solve dependencies.
When I run it on a bam file I get this error:
Fatal error: Exit code 1 ()
File "/home/galaxy/shed_tools/
toolshed.g2.bx.psu.edu/repos/brad-chapman/bam_to_bigwig/9163e1db4c16/bam_to…",
line 41
print "Have %i references" % len(sizes)
^
SyntaxError: invalid syntax
I had a look in the job working directory. In the tool_script.sh the conda
environment set is "$CONDA_DEFAULT_ENV" =
"/export/job_work_dir/000/6/conda-env"
(just in my case). Sourcing the conda environment, the python version is
(/export/job_work_dir/000/6/conda-env) (.venv) [galaxy@vnode-0 6]$ python
--version
Python 3.6.2
Which is not compatible with the "print" code that we have in the
bam_to_bigwig.py wrapper, at line 41.
Any idea? Am I missing something?
Best regards,
Marco.
Hi all
After running the recommended update I am now on branch 17.09. As part
of the update I set up a new virtual env running an additional python
2.7.6. My previous virtual env was running 2.6.6 which is a system
requirement for Centos 6.
All dependencies were installed and Galaxy starts fine, but no tools
run. The error is always a variation of this:
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
File
"galaxy-dist/database/jobs_directory/000/418/418014/set_metadata_4LcsZv.py",
line 1, in <module>
from galaxy_ext.metadata.set_metadata import set_metadata;
set_metadata()
File "galaxy-dist/lib/galaxy_ext/metadata/set_metadata.py", line 19,
in <module>
import json
ImportError: No module named json
I put some debug output at the top of set_metadata.py and it is indeed
running the correct python version from the virtual env. Needless to say
I can import json just fine using that python version. Any ideas?
Any help is greatly appreciated.
Thanks
Ulf
--
Ulf Schaefer, PhD
Bioinformatics Scientist
Bioinformatics Unit - Infectious Disease Informatics
National Infection Service
Public Health England
61 Colindale Ave, London NW9 5EQ
ulf.schaefer(a)phe.gov.uk
http://www.gov.uk/phe
Protecting and improving the nation’s health
**************************************************************************
The information contained in the EMail and any attachments is confidential and intended solely and for the attention and use of the named addressee(s). It may not be disclosed to any other person without the express authority of Public Health England, or the intended recipient, or both. If you are not the intended recipient, you must not disclose, copy, distribute or retain this message or any part of it. This footnote also confirms that this EMail has been swept for computer viruses by Symantec.Cloud, but please re-sweep any attachments before opening or saving. http://www.gov.uk/PHE
**************************************************************************
*DESCRIPTION*
A medium severity security vulnerability in tools utilizing the Galaxy data
source protocol was recently discovered by Dan Blankenberg. This
vulnerability allows anyone able to run an external data source tool to add
to their history any file that is readable by the user running Galaxy jobs
on the host where the job runs. This is due to the Python urllib library's
ability to operate on `file://` URLs and a failure to check for such URLs
in the tool.
This vulnerability has been assigned the disclosure ID GX-2017-0003.
*AFFECTED VERSIONS*
This vulnerability affects all known versions of Galaxy.
*IMPACT*
Many such "external data source" tools are provided with the Galaxy
distribution and are enabled by default (most tools under the "Get Data"
section of the tool panel), meaning that its exploitability is fairly high,
as only one such tool needs to be enabled to be vulnerable, including any
custom data source tools (any tool that uses
`tools/data_source/data_source.py`).
What files will be readable depends entirely upon what the job's user has
access to read on the host(s) where jobs run.
*SOLUTION*
Per our security policies[1], we have created fixes for all affected
versions of Galaxy. These have been committed to the corresponding
`release_YY.MM` (and `dev`) branches in the Galaxy GitHub repository.
Releases prior to 16.07 will remain vulnerable and should be updated to a
supported release as soon as possible.
Eric Rasche recently undertook a hardening of the Galaxy code base against
common security mishaps.[2] This included changing most uses of `urllib` to
`requests`, which does not operate on `file://` URLs. Although no exploits
were identified at that time, we felt this work was of great enough
importance to production Galaxy servers that we backported it to releases
from 16.07 forward. Because of this, and the GX-2017-0001 and GX-2017-0002
vulnerabilities, administrators are strongly encouraged to update
immediately, even if they do not believe their servers are vulnerable.
*INSTRUCTIONS*
The fixes are available on the `release_16.07` through `release_17.09` and
`dev` branches in the Galaxy GitHub repository[3]. You can simply `git
pull` or use your normal update procedure to get the changes.
For the changes to take effect, *YOU MUST RESTART ALL GALAXY SERVER
PROCESSES*.
--nate (on behalf of the Galaxy Committers)
[1] https://github.com/galaxyproject/galaxy/blob/dev/SECURITY_POLICY.md
[2] https://github.com/galaxyproject/galaxy/pull/4604
[3] https://github.com/galaxyproject/galaxy/
*DESCRIPTION*
A high severity security vulnerability was recently discovered in Galaxy
Interactive Environments (GIEs) by the Galaxy Committers Team. Anyone with
a Galaxy account can exploit this vulnerability to execute arbitrary code
on the Galaxy server as the user running the Galaxy server process.
This is possible due to incorrect quoting of user-provided data passed to a
shell execution context for the GIE `docker run` command.
This vulnerability has been assigned the disclosure ID GX-2017-0002.
*AFFECTED VERSIONS*
This vulnerability affects Galaxy version 17.05 and later that have been
configured to enable Galaxy Interactive Environments.
*IMPACT*
The vulnerability only affects Galaxy servers on which Galaxy Interactive
Environments are enabled (by setting the
`interactive_environment_plugins_directory`
option in galaxy.ini). Because the vulnerability can be exploited to
execute arbitrary code, the impact for affected servers is severe.
Administrators of Galaxy servers where GIEs *are* enabled should update
immediately.
Administrators of Galaxy servers where GIEs are *not* enabled *should* update
their servers to ensure they are not vulnerable should they enable GIEs at
a later date, however, it is not critical to do so immediately.
*SOLUTION*
Per our security policies[1], we have created fixes for all affected
versions of Galaxy. These have been committed to the corresponding
`release_YY.MM` (and `dev`) branches in the Galaxy GitHub repository.
The fix switches from using shell execution to direct execution with
exec(3) and therefore is not susceptible to shell escaping exploits
*INSTRUCTIONS*
The fixes are available on the `release_17.05`, `release_17.09`, and `dev`
branches in the Galaxy GitHub repository[2]. You can simply `git pull` or
use your normal update procedure to get the changes.
For the changes to take effect, *YOU MUST RESTART ALL GALAXY SERVER
PROCESSES*.
--nate (on behalf of the Galaxy Committers)
[1] https://github.com/galaxyproject/galaxy/blob/dev/SECURITY_POLICY.md
[2] https://github.com/galaxyproject/galaxy/
*DESCRIPTION*
A medium severity security vulnerability in Galaxy Data Libraries was
recently discovered by Jelle Scholtalbers, and in the course of
investigating this vulnerability, we discovered multiple related attack
vectors.
This vulnerability allows the following unauthorized actions:
1. Any user that has been granted the permission to add datasets to a
library, library folder, or to modify an existing library dataset (an
"authorized user"), is able to import any file on the system that is
readable by the user running the Galaxy server.
2. Anyone can create libraries and library folders (but not add datasets to
them)
This is possible due to incorrect checking of admin privileges and for
symbolic links in the user's `user_library_import_dir`. Neither case can be
exploited directly through the Galaxy UI, but both can be exploited through
the API. Case #1 is not exploitable by any user who is not an "authorized
user" or if none of `library_import_dir`, `user_library_import_dir`, and
`allow_path_paste` (formerly `allow_library_path_paste`) are set in
galaxy.ini.
This vulnerability has assigned the disclosure ID GX-2017-0001.
*AFFECTED VERSIONS*
This vulnerability affects all known versions of Galaxy.
*IMPACT*
The more severe vulnerability (reading arbitrary files) can only be
exploited by users with elevated library privileges, so its exploitability
is limited to users whom the Galaxy server admin(s) presumably know and
trust. The creation of arbitrary libraries and folders is a nuisance, but
not in and of itself a security issue.
*SOLUTION*
Per our security policies[1], we have implemented fixes for versions of
Galaxy from 16.07 through the forthcoming 17.09. These have been committed
to the corresponding `release_YY.MM` (and `dev`) branches in the Galaxy
GitHub repository.
Releases prior to 16.07 will remain vulnerable and should be updated to a
supported release as soon as possible.
If your user `user_library_import_dir` or any of its parents are symlinks,
user library imports will fail. You should put the fully canonicalized
absolute path in this galaxy.ini option.
Because the fix disallows symlinks in `user_library_import_dir` which point
outside the user's particular subdirectory, and because some Galaxy admins
may have found this to be a useful ability, we have created a new
`user_library_import_symlink_whitelist` option in galaxy.ini that allows
admins to configure directories to which symlinks should be allowed.
However, please be aware that *any* user with library add/modify privileges
and the ability to create symbolic links will be able to import from any
whitelisted directory. There is no per-user restriction for whitelisted
directories.
*INSTRUCTIONS*
The fixes are available on the `release_16.07` through `release_17.09` and
`dev` branches in the Galaxy GitHub repository[2]. You can simply `git
pull` or use your normal update procedure to get the changes.
For the changes to take effect, *YOU MUST RESTART ALL GALAXY SERVER
PROCESSES*.
--nate (on behalf of the Galaxy Committers)
[1] https://github.com/galaxyproject/galaxy/blob/dev/SECURITY_POLICY.md
[2] https://github.com/galaxyproject/galaxy/
Dear developers,
The colleague of mine mistakenly deleted my Galaxy installation (rm -rf *). Unfortunately there is no backup of complete installation. I have backup only configuration files.
Is there any chance to fetch new Galaxy instance from git and to connect it to the old database? Or maybe any other suggestion what to do in such case?
Many thanks in advance!
Best,
Marija
Mag. Marija Đurđević
Core Facility Computational Bioanalytics
Medical University of Graz
Center for Medical Research
Stiftingtalstraße 24, A-8010 Graz
Austria
Phone: +43 316/385-73024<tel:%2B43%20316%2F385-73024>
Fax:+43 316/385-73009<tel:%2B43%20316%2F385-73009>
Email: marija.durdevic(a)medunigraz.at<mailto:marija.durdevic@medunigraz.at>
Email: marija.djurdjevic(a)klinikum-graz.at<mailto:marija.djurdjevic@klinikum-graz.at>
Web: https://zmf.medunigraz.at/