Re: [galaxy-dev] sender address of galaxy tool report

[Rémy Dernat]

Hello,

That was quite easy; Just changing:

diff lib/galaxy/tools/errors.py.orig lib/galaxy/tools/errors.py
116c116
 frm = to_address
---
 #frm = to_address
119a120,123
 if email is not :
 frm = email
 else:
 frm = to_address


Best,

Remy

2015-05-06 10:28 GMT+02:00 Rémy Dernat remy...@gmail.com:

 Hi,

 We run a galaxy server locally. When a user want to send an error through
 galaxy GUI Report this error to the Galaxy Team . We do not have any
 anonymous/guest users (not allowed). So we are sure that the content of the
 email textbox is always effective.

 The problem is that we use a remote helpdesk program that is using email
 piping to retrieve the email and convert it to a ticket. When we want to
 process galaxy ticket GALAXY TOOL ERROR REPORT the sender address is
 always the address error_email_to from the configuration file galaxy.ini
 / universe.ini
 So we can not replay into our helpdesk program, because the answer would
 be send to the address error_email_to and not to the user.

 Is there a way to get the real email address from the user who reported
 the error instead of this address ?
 Or, if it is not possible, could it be plan in the future galaxy release ?
 Or, eventually, if this is easy to do, what python file should I modify ?


 Best regards,

 Remy

___
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/mailinglists/

[galaxy-dev] LDAP auth_conf.xml and search-filter condition

[Rémy Dernat]

Hi list,

I would like to enable a multiple search on (Open)LDAP to check if a user
is also a member of a specific "galaxy" group. I did not find anything
about this in the documentation.

Indeed, we do not want that all the LDAP users to be able to login to
galaxy and we do not want to change the LDAP structure because it is
already used by many applications.

I have a complex search-filter which is:
(((mail={email})(uid={username}))((cn=galaxy)(objectClass=posixGroup)(memberUid={username})))

However, this search filter gave me two answers. It is normal because I am
searching for the user, and then, if he belongs to a particular
(posix)group. So the bind failed (because it needs only one answer).

The basic one (to only bind) is working:
((mail={email})(uid={username}))

I also tried with 2 search-filter conditions but galaxy seems to keep only
the last one.

Is there any project to allow that in the (near) future versions (*) ? Or
is there any hidden xml tag (not in documentation) which can permit to
search the memberUid/memberOf value in LDAP ?

In the meantime we will change the default quota (like just some bytes) for
users to allow LDAP login (for all users already present in it).


Best,

Remy


(*) Alternatively, what code should I change in Galaxy ? I would be happy
to program it if I have enough time...
___
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/mailinglists/

Re: [galaxy-dev] Upload issue in local installation

[Rémy Dernat]

Hi,

Sorry about that but we get that error too "Failed: Request Entity Too
Large (413)" on Firefox (43.0) but not on chrome (47.0.2526.106 (64-bit)).
The trick to disable "ajax-upload" parameter (set it to false) does not
seem to work (the window is still open and nothing changed).

Any iadea would be greatful

Best,

Remy

2012-10-23 16:23 GMT+02:00 Nate Coraor :

> On Oct 23, 2012, at 10:06 AM, Peter Briggs wrote:
>
> > In case this is of use to someone else: I've been experiencing a
> similar-sounding issue to that described below - the symptoms were that
> only very small (e.g. 40kb) files could be uploaded successfully.
> >
> > The problem seemed to be caused by the SecRequestBodyLimit directive in
> Apache's mod_security.conf file putting a very low limit on the size of
> files. The fix (for me) was simply to up the limit to something more
> appropriate.
>
> Hi Peter,
>
> Thanks for finding this, I've added this information to our documentation.
>
> --nate
>
> >
> > Disabling the ajax uploads as described by Dan didn't fix the problem
> but it did make the source more obvious, as Galaxy immediately reported the
> error message "413 Request Entity Too Large" (with the clue about
> mod_security turning up in the Apache log).
> >
> > I don't think this is the same problem as previously reported but maybe
> this info will help someone else.
> >
> > Best wishes
> >
> > Peter
> >
> > On 03/08/12 14:58, David Roquis wrote:
> >> Hi Dan,
> >>
> >> It works like a charm! Thanks a lot! I have been looking for a
> >> workaround for this issue for almost a month!
> >>
> >> Once again, thanks you so much!
> >>
> >> David
> >>
> >>
> >> 
> >> Subject: Re: [galaxy-dev] Upload issue in local installation
> >> From: d...@bx.psu.edu
> >> Date: Fri, 3 Aug 2012 09:24:43 -0400
> >> CC: bat...@gmail.com; galaxy-...@lists.bx.psu.edu
> >> To: david_roq...@hotmail.com
> >>
> >> Hi David and Bastal,
> >>
> >> We have been able to reproduce this behavior under certain conditions
> >> and are working on a fix. Until this fix is available, you can disable
> >> ajax uploads, which should allow the upload tool to work properly.
> >> In tools/data_source/upload.xml change
> >>
> >>  >> ajax-upload="true" help="TIP: Due to browser limitations, uploading
> >> files larger than 2GB is guaranteed to fail.  To upload large files, use
> >> the URL method (below) or FTP (if enabled by the site administrator).">
> >>
> >> to
> >>
> >>  >> ajax-upload="False" help="TIP: Due to browser limitations, uploading
> >> files larger than 2GB is guaranteed to fail.  To upload large files, use
> >> the URL method (below) or FTP (if enabled by the site administrator).">
> >>
> >>
> >> Please let us know if this workaround doesn't work for you.
> >>
> >>
> >> Thanks for using Galaxy,
> >>
> >> Dan
> >>
> >>
> >> On Aug 3, 2012, at 4:20 AM, David Roquis wrote:
> >>
> >>Hi Batsal,
> >>
> >>I have the exact same problem, on 2 different instances of Galaxy,
> >>on two different servers. I can replicate this problem on a cloned
> >>instance with no modification, and one using multiple galaxay
> >>server, nginx proxy and postgresql, both instances being on
> >>different machines (one on fedora 13, the other one on fedora 17).
> >> From what I have seen, it seems to be browser related. I can
> >>sometimes (rarely) upload data with firefox, chrome or safary, but
> >>for me it has worked ALL the time using internet explorer 8/9. The
> >>thing is that when you start the upload, the browser shows you that
> >>it is uploaded, but the upload.py script is never launched, and
> >>hence, the upload seems to be running forever. Seems we are not the
> >>only ones with this problem, but no real solution until now.
> >>
> >>Two options for you at the moment
> >>- try using IE 8/9 to upload the data
> >>- upload your data using data libraries under the admin menu (this
> >>works on any browser).
> >>
> >>Keep me in touch if you find a solution
> >>
> >>David
> >>
> >>
> >>
> >>> From:bat...@gmail.com 
> >>> Date: Thu, 2 Aug 2012 15:48:40 -0400
> >>> To:galaxy-...@lists.bx.psu.edu  >
> >>> Subject: [galaxy-dev] Upload issue in local installation
> >>>
> >>> I installed galaxy locally in a linux server. However, I cannot
> upload the files (no matter how small, I have tried few kb size fasta
> files). When I try to upload, the link to the file shows up in the History
> and gets a new number (purple box). When I click on the link I get 'Dataset
> is uploading' forever.
> >>>
> >>> In the terminal window where I start galaxy, I get the following
> error report:
> >>>
> >>> 92.17.41.13 - - [02/Aug/2012:15:33:32 -0400] "GET / HTTP/1.1" 200
> - "-" "Mozilla/5.0 (Windows NT 5.2; rv:13.0) Gecko/20100101 Firefox/13.0.1"

Re: [galaxy-dev] Upload issue in local installation

[Rémy Dernat]

Ok, I answer to myself:

It works with nginx last stable version (1.8.1) whereas it did not work on
nginx 1.7.4 (same configuration).

Best,
Remy

2016-01-05 10:28 GMT+01:00 Rémy Dernat <remy...@gmail.com>:

> Hi,
>
> Sorry about that but we get that error too "Failed: Request Entity Too
> Large (413)" on Firefox (43.0) but not on chrome (47.0.2526.106 (64-bit)).
> The trick to disable "ajax-upload" parameter (set it to false) does not
> seem to work (the window is still open and nothing changed).
>
> Any iadea would be greatful
>
> Best,
>
> Remy
>
> 2012-10-23 16:23 GMT+02:00 Nate Coraor <n...@bx.psu.edu>:
>
>> On Oct 23, 2012, at 10:06 AM, Peter Briggs wrote:
>>
>> > In case this is of use to someone else: I've been experiencing a
>> similar-sounding issue to that described below - the symptoms were that
>> only very small (e.g. 40kb) files could be uploaded successfully.
>> >
>> > The problem seemed to be caused by the SecRequestBodyLimit directive in
>> Apache's mod_security.conf file putting a very low limit on the size of
>> files. The fix (for me) was simply to up the limit to something more
>> appropriate.
>>
>> Hi Peter,
>>
>> Thanks for finding this, I've added this information to our documentation.
>>
>> --nate
>>
>> >
>> > Disabling the ajax uploads as described by Dan didn't fix the problem
>> but it did make the source more obvious, as Galaxy immediately reported the
>> error message "413 Request Entity Too Large" (with the clue about
>> mod_security turning up in the Apache log).
>> >
>> > I don't think this is the same problem as previously reported but maybe
>> this info will help someone else.
>> >
>> > Best wishes
>> >
>> > Peter
>> >
>> > On 03/08/12 14:58, David Roquis wrote:
>> >> Hi Dan,
>> >>
>> >> It works like a charm! Thanks a lot! I have been looking for a
>> >> workaround for this issue for almost a month!
>> >>
>> >> Once again, thanks you so much!
>> >>
>> >> David
>> >>
>> >>
>> >>
>> 
>> >> Subject: Re: [galaxy-dev] Upload issue in local installation
>> >> From: d...@bx.psu.edu
>> >> Date: Fri, 3 Aug 2012 09:24:43 -0400
>> >> CC: bat...@gmail.com; galaxy-...@lists.bx.psu.edu
>> >> To: david_roq...@hotmail.com
>> >>
>> >> Hi David and Bastal,
>> >>
>> >> We have been able to reproduce this behavior under certain conditions
>> >> and are working on a fix. Until this fix is available, you can disable
>> >> ajax uploads, which should allow the upload tool to work properly.
>> >> In tools/data_source/upload.xml change
>> >>
>> >> > >> ajax-upload="true" help="TIP: Due to browser limitations, uploading
>> >> files larger than 2GB is guaranteed to fail.  To upload large files,
>> use
>> >> the URL method (below) or FTP (if enabled by the site administrator).">
>> >>
>> >> to
>> >>
>> >> > >> ajax-upload="False" help="TIP: Due to browser limitations, uploading
>> >> files larger than 2GB is guaranteed to fail.  To upload large files,
>> use
>> >> the URL method (below) or FTP (if enabled by the site administrator).">
>> >>
>> >>
>> >> Please let us know if this workaround doesn't work for you.
>> >>
>> >>
>> >> Thanks for using Galaxy,
>> >>
>> >> Dan
>> >>
>> >>
>> >> On Aug 3, 2012, at 4:20 AM, David Roquis wrote:
>> >>
>> >>Hi Batsal,
>> >>
>> >>I have the exact same problem, on 2 different instances of Galaxy,
>> >>on two different servers. I can replicate this problem on a cloned
>> >>instance with no modification, and one using multiple galaxay
>> >>server, nginx proxy and postgresql, both instances being on
>> >>different machines (one on fedora 13, the other one on fedora 17).
>> >> From what I have seen, it seems to be browser related. I can
>> >>sometimes (rarely) upload data with firefox, chrome or safary, but
>> >>for me it has worked ALL the time using internet explorer 8/9. The
>> >>thing is that when you

Re: [galaxy-dev] Removing set_metadata_externally from wiki documentation?

[Rémy Dernat]

Hi Peter,

I am also quite interesting with these settings. If you achieve this
configuration please keep us inform.

Best
Remy
___
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/mailinglists/

Re: [galaxy-dev] Rocks cluster; jobs run but Galaxy can't find jobid when submitted via drmaa

[Rémy Dernat]

I forgot to point out the needs of sharing folders and checking the UID/GID
of the galaxy user between your systems (and his access to SGE).

Remy

2016-01-20 16:00 GMT+01:00 Rémy Dernat <remy...@gmail.com>:

> Hi Eric,
>
> Here we use both solutions: Galaxy and RocksCluster. In Galaxy, you have
> to define your jobs in "config/job_conf.xml" and you should probably source
> a file (search for "environment" in your galaxy.ini) before the submit
> process. In fact, you could have to set a DRMAA_LIBRARY_PATH to load your
> drmaa library; see
> https://wiki.galaxyproject.org/Admin/Config/Performance/Cluster#DRMAA
>
> Best,
> Remy
>
> 2016-01-19 20:28 GMT+01:00 Eric Shell <esh...@soe.ucsc.edu>:
>
>> I am trying to get a Galaxy instance running on a Rocks cluster.  I am
>> able to run jobs with the local runner at this point, but I am having an
>> issue with the drmaa runner that I haven't been able to fix.  When I submit
>> a job in Galaxy it is successfully submitted to the cluster and runs to
>> completion according to qacct, but Galaxy just reports "failure running
>> job".
>>
>> Here's what is written to paster.log when I submit a job:
>>
>> 69.181.235.240 - - [19/Jan/2016:11:24:31 -0700] "GET
>>> /api/histories/fb86c918c0d3d33b/contents?dataset_details=bae154fe2294752e%2C6fe732485990d2ac%2C604c4e6e60e997bc%2Cf015f1cb819ec50e%2C9f6f4b3cb6cf43eb%2C3d13d598882b6eb8%2C551006fddcb290ae%2C10b9bbc646c48387%2C7670dfdf35146bc5%2Ce0ec2cf59f1fc79e%2Cee30922e5e4854db%2C9e7a0ba216194210
>>> HTTP/1.1" 200 - "https://galaxy.soe.ucsc.edu/; "Mozilla/5.0 (Windows NT
>>> 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>>> Chrome/47.0.2526.111 Safari/537.36"
>>> 69.181.235.240 - - [19/Jan/2016:11:24:38 -0700] "GET
>>> /tool_runner/data_source_redirect?tool_id=ucsc_table_direct1 HTTP/1.1" 302
>>> - "https://galaxy.soe.ucsc.edu/; "Mozilla/5.0 (Windows NT 10.0; Win64;
>>> x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111
>>> Safari/537.36"
>>> galaxy.tools.actions.__init__ INFO 2016-01-19 11:24:42,801 Handled
>>> output (327.778 ms)
>>> galaxy.tools.actions.__init__ INFO 2016-01-19 11:24:43,236 Verified
>>> access to datasets (0.023 ms)
>>> galaxy.tools.execute DEBUG 2016-01-19 11:24:43,343 Tool
>>> [ucsc_table_direct1] created job [7019] (919.481 ms)
>>> 69.181.235.240 - - [19/Jan/2016:11:24:42 -0700] "POST /tool_runner
>>> HTTP/1.1" 200 - "https://genome.ucsc.edu/cgi-bin/hgTables; "Mozilla/5.0
>>> (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>>> Chrome/47.0.2526.111 Safari/537.36"
>>> galaxy.jobs DEBUG 2016-01-19 11:24:44,056 (7019) Working directory for
>>> job is: /campusdata/galaxy/galaxy/database/job_working_directory/007/7019
>>> galaxy.jobs.handler DEBUG 2016-01-19 11:24:44,070 (7019) Dispatching to
>>> sge runner
>>> galaxy.jobs DEBUG 2016-01-19 11:24:44,378 (7019) Persisting job
>>> destination (destination id: sge_default)
>>> galaxy.jobs.runners DEBUG 2016-01-19 11:24:44,403 Job [7019] queued
>>> (332.423 ms)
>>> galaxy.jobs.handler INFO 2016-01-19 11:24:44,444 (7019) Job dispatched
>>> 69.181.235.240 - - [19/Jan/2016:11:24:44 -0700] "GET /api/genomes
>>> HTTP/1.1" 200 - "https://galaxy.soe.ucsc.edu/; "Mozilla/5.0 (Windows NT
>>> 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)
>>> Chrome/47.0.2526.111 Safari/537.36"
>>> 69.181.235.240 - - [19/Jan/2016:11:24:44 -0700] "GET
>>> /api/datatypes?extension_only=False& HTTP/1.1" 200 - "
>>> https://galaxy.soe.ucsc.edu/; "Mozilla/5.0 (Windows NT 10.0; Win64;
>>> x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111
>>> Safari/537.36"
>>> 69.181.235.240 - - [19/Jan/2016:11:24:44 -0700] "GET
>>> /history/current_history_json HTTP/1.1" 200 - "
>>> https://galaxy.soe.ucsc.edu/; "Mozilla/5.0 (Windows NT 10.0; Win64;
>>> x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111
>>> Safari/537.36"
>>> galaxy.jobs.runners DEBUG 2016-01-19 11:24:46,399 (7019) command is:
>>> python /campusdata/galaxy/galaxy/tools/data_source/data_source.py
>>> /campusdata/galaxy/galaxy/database/files/011/dataset_11361.dat 0;
>>> return_code=$?; python
>>> "/campusdata/galaxy/galaxy/database/job_working_directory/007/7019/set_metadata_IaPURP.py"
>>> &quo

Re: [galaxy-dev] Restart Galaxy without interruption

[Rémy Dernat]

Hi,

Thanks Laure and Martin.

This is very interesting. However, can it handle the load balancing part as
Gildas asked ? Anyway, thanks for the tip.

Can it be possible to share /etc/supervisor/conf.d/galaxy.conf without
having to use ansible ? I downloaded the tarball, however, I did not find
this file; is it (seems to be) galaxy.j2 in the template directory ?

Best regards,
Remy

2016-11-16 16:36 GMT+01:00 Martin Čech :

> Hi Gildas,
>
> the approach which Main Galaxy takes is as described by Nate in the
> exercise document linked by Laure. Exerpt here:
>
> "In addition, you can gracefully restart the uWSGI Galaxy process with
> sudo supervisorctl signal HUP gx:galaxy. uWSGI is configured to start
> Galaxy in a "master" process and then fork the configured number of worker
> processes. Because of this, if sent a SIGHUP signal, it will kill the
> workers but the master process will hold its socket open, blocking client
> (browser) connections until new workers are forked. This prevents users
> from seeing a proxy error page during restarts."
>
> Using this, you can restart both the uWSGI server and Galaxy handlers with:
>
> $ sudo supervisorctl signal HUP gx:galaxy && sudo supervisorctl restart
> gx:handler0 gx:handler1
>
> without supervisor it would be something like $ pkill -HUP -o -u 
> uwsgi
>
> Thanks for using Galaxy,
>
> Martin
>
> On Wed, Nov 16, 2016 at 5:19 AM Laure QUINTRIC 
> wrote:
>
>> Hi Gildas,
>>
>> Have a look here : https://github.com/martenson/
>> dagobah-training/tree/master/advanced/002a-systemd-supervisor
>>
>> See ya.
>>
>>
>> Laure
>>
>> Le 14/11/2016 à 21:35, Gildas Le Corguillé a écrit :
>>
>> Hi,
>>
>> Since Galaxy need to be restarted sometime (load datatype, add ressources
>> in .loc, apply changes in the galaxy.ini), is anybody of you have solutions
>> to restart it without interrupt the service?
>>
>> We are now using nginx, uwsgi and supervisord.
>>
>> My hope is to split the Galaxy process in two group (1 uwsgi and 2 job
>> handlers per group). That way, we will be able to restart the group1 and
>> then the group2.
>>
>>
>> I was planning to set the 2 uwsgi servers and delegate the load balancing
>> to ngnix (https://www.nginx.com/resources/admin-guide/load-balancer/)
>> But maybe, some of you already implemented that and can provide me some
>> advices or warnings.
>>
>> The job handler part seems easier to deal with
>> --server-name=handler1_%(process_num)s
>> --server-name=handler2_%(process_num)s
>>
>> Thanks by advance
>>
>> Gildas
>>
>> -
>> Gildas Le Corguillé - Bioinformatician/Bioanalyste
>>
>> Plateform ABiMS (Analyses and Bioinformatics for Marine Science)
>> http://abims.sb-roscoff.fr
>>
>> Member of the Workflow4Metabolomics project
>> http://workflow4metabolomics.org
>>
>> Station Biologique de Roscoff - UPMC/CNRS - FR2424
>> Place Georges Teissier 29680 Roscoff FRANCE
>> tel: +33 2 98 29 23 81 <+33%202%2098%2029%2023%2081>
>> --
>>
>>
>>
>>
>>
>> ___
>> 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/mailinglists/
>>
>>
>> ___
>> 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/mailinglists/
>
>
> ___
> 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/mailinglists/
>
___
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/mailinglists/