- galaxy-dev - lists.galaxyproject.org

Version String
by SHAUN WEBB 09 Dec '11

09 Dec '11

Hi. I am using the tag: <version_string>path to tool --version</version_string> In my xml file. I would expect the tool version to be printed in the information window for each dataset but the version field is blank. I am running the latest Galaxy dist, is there anything else I need to do? I have tried using <version_command> also. Thanks Shaun -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

3 2

Genome indices, NFS and I/O
by Louise-Amélie Schmitt 09 Dec '11

09 Dec '11

Hello, We're planning on using our lab's cluster for running jobs, but we have to copy genome indices on the local disk where the job is run to avoid too much I/O over the NFS. Since we know Cloudman exists and works fine, we were wondering how the indices are managed in this case, and if there would be a way for us to use a similar solution. Thanks, L-A

2 1

Cloudman and parameterized launching
by Scott Cain 08 Dec '11

08 Dec '11

Hi Guys, This is only sort of a Galaxy question, in the sense of "how did you guys do that so I can too" sort of way. I'm trying to clean up some code written by an undergrad for the GBrowse2 cloud machine, where he used less than secure methods of doing things. I gather from the page on Cloudman that it uses a parameterized launch, where the user provides both halves of his API key, so that the Cloudman master node can do things like provision storage and start other instances. Since I need to be able to do essentially the same thing (but in perl!), I was wondering if you could direct me to the resources you used to implement that and point out any gotchas that you can think of. Thanks much and keep up the good work! Scott -- ------------------------------------------------------------------------ Scott Cain, Ph. D. scott at scottcain dot net GMOD Coordinator (http://gmod.org/) 216-392-3087 Ontario Institute for Cancer Research

2 1

January 2012 Galaxy Events: Dec 15 Deadline for Czech Republic Workshop
by Dave Clements 08 Dec '11

08 Dec '11

Hello all, The January Events <http://wiki.g2.bx.psu.edu/Events> email is going out a little early this month, mainly because of a *December 15 deadline for the Galaxy Developer Workshop in the Czech Republic<http://evomics.org/workshops/galaxy-developer-workshop/> *. There are Galaxy-related events on (at least) 3 continents next month: * Date * * Topic/Event * * Venue/Location * * Contact * January 8-21 *2012 Workshop on Genomics<http://evomics.org/workshops/workshop-on-genomics/2012-genomics-cesky-kruml…> * Features Galaxy and much more. Český Krumlov, Czech Republic James Taylor <http://wiki.g2.bx.psu.edu/JamesTaylor> January 14-18 *Galaxy Session<http://pag.confex.com/pag/xx/webprogrampreliminary/Paper2350.html>@ GMOD Workshop<http://pag.confex.com/pag/xx/webprogrampreliminary/Session1123.html> *, and *The Galaxy Platform: Running Analyses in the Cloud<http://pag.confex.com/pag/xx/webprogrampreliminary/Paper4623.html>@ Cloud Computing Session<http://pag.confex.com/pag/xx/webprogrampreliminary/Session1139.html> * PAG 2012 <http://wiki.g2.bx.psu.edu/Events/PAG2012>, San Diego, California, United States Dave Clements <http://wiki.g2.bx.psu.edu/DaveClements> Dannon Baker January 17 *Reproducible workflows for next generation sequencing analysis<http://www.nowgen.org.uk/facilities/events/event.php?id=30> * Nowgen <http://www.nowgen.org.uk/>, University of Manchester<http://www.manchester.ac.uk/>, United Kingdom Tom Hancocks <training(a)nowgen.org.uk> January 23 *Galaxy Developer Workshop<http://evomics.org/workshops/galaxy-developer-workshop/> Application deadline is December 15.* Český Krumlov, Czech Republic <http://www.ckrumlov.info/php/>, immediately following the Workshop on Genomics<http://evomics.org/workshops/workshop-on-genomics/2012-genomics-cesky-kruml…>, (which also features Galaxy content) James Taylor <http://wiki.g2.bx.psu.edu/JamesTaylor> January 26 *今回の講習会では，「Next-Generation Sequencer(NGS) 微生物解析と Galaxy ツール」を中心に講義と実習を行ないます。講義内容をよりよく理解して頂くために，PC を使用した実習を行ないます。<http://www.ddbj.nig.ac.jp/ddbjing/ddbjing.html#DDBJ> * (Next-Generation Sequencing (NGS) and microbiological analysis with Galaxy) DNA Data Bank of Japan (DDBJ), National Institute of Genetics<http://www.ddbj.nig.ac.jp/> DDBJ <http://www.ddbj.nig.ac.jp/addresses-j.html> And I apologize in advance if I messed up the translation of the event at DDBJ <http://www.ddbj.nig.ac.jp/ddbjing/ddbjing.html#DDBJ>! Thanks, Dave C. -- http://galaxyproject.org/ http://getgalaxy.org/ http://usegalaxy.org/ http://galaxyproject.org/wiki/

1 0

Re: [galaxy-dev] FTP GALAXY
by James Boocock 08 Dec '11

08 Dec '11

Hi We have set up galaxy in a production environment and our galaxy users can connect to the FTP and upload files. No worries. The settings in the universe file seem correct and are. ftp_upload_dir = /home/galaxy/galaxy-dist/database/ftp It creates the directory and uploads the file. But when the user signs into galaxy they cannot view their file in the get data -> from files on my computer. Proftp config is listed below. Cheers James Boocock ServerName "Public Galaxy FTP" ServerType standalone DefaultServer on Port 21 Umask 077 SyslogFacility DAEMON SyslogLevel debug MaxInstances 30 User nobody Group nogroup DisplayConnect /etc/opt/local/proftpd_welcome.txt # Passive port range for the firewall PassivePorts 30000 40000 # Cause every FTP user to be "jailed" (chrooted) into their home directory DefaultRoot ~ # Automatically create home directory if it doesn't exist CreateHome on dirmode 1700 # Allow users to overwrite their files AllowOverwrite on # Allow users to resume interrupted uploads AllowStoreRestart on # Bar use of SITE CHMOD <Limit SITE_CHMOD> DenyAll </Limit> # Bar use of RETR (download) since this is not a public file drop <Limit RETR> DenyAll # Do not authenticate against real (system) users AuthPAM off # Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1 SQLPasswordEngine on SQLPasswordEncoding hex # Set up mod_sql to authenticate against the Galaxy database SQLEngine on SQLBackend postgres SQLConnectInfo galaxydb galaxyftp 1234 SQLAuthTypes SHA1 SQLAuthenticate users # An empty directory in case chroot fails SQLDefaultHomedir /var/opt/local/proftpd # Define a custom query for lookup that returns a passwd-like entry. UID and GID should match your Galaxy user. # Do not authenticate against real (system) users AuthPAM off # Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1 SQLPasswordEngine on SQLPasswordEncoding hex # Set up mod_sql to authenticate against the Galaxy database SQLEngine on SQLBackend postgres SQLConnectInfo galaxydb galaxyftp 1234 SQLAuthTypes SHA1 SQLAuthenticate users # An empty directory in case chroot fails SQLDefaultHomedir /var/opt/local/proftpd # Define a custom query for lookup that returns a passwd-like entry. UID and GID should match your Galaxy user. SQLUserInfo custom:/LookupGalaxyUser SQLNamedQuery LookupGalaxyUser SELECT "email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash' FROM galaxy_user WHERE email='%U'" SQLUserInfo custom:/LookupGalaxyUser SQLNamedQuery LookupGalaxyUser SELECT "email,password,'512','512','/home/galaxy/galaxy-dist/database/ftp/%U','/bin/bash' FROM galaxy_user WHERE email='%U'" </Limit>

2 1

Re: [galaxy-dev] Configuring Toolsheds
by Greg Von Kuster 08 Dec '11

08 Dec '11

Hi Zachary, On Dec 8, 2011, at 10:11 AM, Zachary Charlop-Powers wrote: > Greg, > > I thought I sent the e-mail below last night. Sorry. I reinstalled Galaxy and ran into the same issue. Since I can modify my own tools and the Toolsheds are not strictly necessary for what we are doing I am going to stop trying for a bit. I am a little confused that it doesn't work, however, and wonder if there is not an issue in one of the scripts. I don't know which script would be responsible for making a local copy of the Galaxy Toolshed tools but when I "grep" for "repository" in the /galaxy-dist/ folder the only non-template file you get is lib/galaxy/webapps/community/controllers/repository.py I glanced through that file but I didn't see a part of the script that had the exact order of the error message I was receiving - but perhaps I didn't know the file very well? It seems you have a bit of a misunderstanding about the main Galaxy tool shed (http://toolshed.g2.bx.psu.edu/) and the mercurial repositories that are available in it as well as the motivation for hosting your own local Galaxy tool shed. The mercurial repositories that are currently available in the main Galaxy tool shed can be "hg cloned" individually or "automatically installed" individually as a means of making their contents (Galaxy tools, workflows, data, etc) available to your local Galaxy instance. So if you configure and host your own local Galaxy tool shed, your shed will not initially contain anything until you add your own locally developed tools to it. Starting up a local tool shed does not result in the mercurial repositories currently available in the main galaxy tool shed being automatically made available in the local tool shed. The intent of the main Galaxy tool shed is to enable sharing of tools between the many local Galaxy instances around the globe. But again, the mercurial repositories containing these tools must be individually installed into your local Galaxy instance. There are many way to go about doing this - all documented in the tool shed wiki at http://wiki.g2.bx.psu.edu/Tool%20Shed. This provides flexibility to those hosting their own local Galaxy instances in that they can install only those tools in which they have interest, and are not forced to get all of them in order to get any one of them. In the near future, we will begin to move the tools currently included in the Galaxy distribution to the Galaxy main tool shed. > > In any event I agree with you that it is not a server error nor a community_wsgi.ini error (since I didn't do anything to them in this new install) but something small in the setup where the repository is not being told the correct location to install its tools. If you have any suggestions I am happy to try some small things but I have to give up for a bit because its amazing how much time you can spend tracking these things down. I would strongly suggest that you eliminate the use of proxying Galaxy behind apache as your proxy configuration is certainly the cause of the issues you are seeing. > > > thanks again for your time and your efforts to the creation of this great tool. > zach cp > > > > > > > Greg, > > I've been looking very carefully at http://wiki.g2.bx.psu.edu/Tool%20Shed#Automatic_installation_of_Galaxy_tool… to make sure that I have been doing this right. > > After encountering the initial error (directory not found) I : > > 1. prematurely attempted to setup a local Galaxy toolshed. > 2. started to get a new series of issues related to community_wsgi.ini and nginx.conf. > > Clearly this was incorrect and I can restore the default configuration of these files. However the initial error which is that default Galaxy installation procedure did not allow me to use the main Galaxy Toolshed Tools remains. According to the webpage above this should be a very simple procedure, akin to the main Galaxy setup. > > > I think the best thing to do is to do a totally clean install, use the Apache config files you guys have included for port forwarding and not mess with any other files. If that is the case I should be able to install Galaxy Tools via the web without starting up a second server. I think thats probably the best way to proceed - not too hard since I don;t really have any data or history on the server yet. > > Just clean out the galaxy user home folder, create a new Postgresql database and configure Apache. If I still have problems after that I will let you know. > > thanks Greg, > zach cp > > > > > > > > > > On Dec 7, 2011, at 12:18 PM, Greg Von Kuster wrote: > >> Based on the following requests from the bottom of your paster log, you are attempting to access the Galaxy main tool shed, not a locally running tool shed. SInce this is the case, you do not need to do anything with community_wsgi.ini! >> >> serving on http://127.0.0.1:8080 >> 129.85.185.149 - - [07/Dec/2011:11:46:11 -0400] "GET / HTTP/1.0" 200 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:11 -0400] "GET /history HTTP/1.0" 200 - "http://bradybeast/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:11 -0400] "GET /root/tool_menu HTTP/1.0" 200 - "http://bradybeast/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:11 -0400] "POST /root/user_get_usage HTTP/1.0" 200 - "http://bradybeast/history" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:17 -0400] "GET /admin HTTP/1.0" 200 - "http://bradybeast/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:17 -0400] "GET /admin/center?status=done&message=&webapp=galaxy HTTP/1.0" 200 - "http://bradybeast/admin" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:37 -0400] "GET /admin/browse_tool_sheds HTTP/1.0" 200 - "http://bradybeast/admin" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> 129.85.185.149 - - [07/Dec/2011:11:46:38 -0400] "GET /admin/browse_tool_shed?tool_shed_url=http%3A%2F%2Ftoolshed.g2.bx.psu.edu%2F HTTP/1.0" 302 - "http://bradybeast/admin/browse_tool_sheds" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a2) Gecko/20111206 Firefox/10.0a2" >> >> >> If you are trying to get your requests to proxy to something like /galaxy/bradybeast/... then you need to uncomment the following filter-with setting in your universe_wsgi.ini file. You will also need to configure your nginx the same way. Make sure to follow the directions precisely as documented in our wiki at http://wiki.g2.bx.psu.edu/Admin/Config/Apache%20Proxy. >> >> # If running behind a proxy server and Galaxy is served from a subdirectory, >> # enable the proxy-prefix filter and set the prefix in the >> # [filter:proxy-prefix] section above. >> #filter-with = proxy-prefix >> >> >> On Dec 7, 2011, at 10:49 AM, Zachary Charlop-Powers wrote: >> >>> Sure. I'm the same guy who was on the IRC yesterday. >>> >>> thanks again for your time. >>> zach cp >>> >>> >>> >>> >>> <community_wsgi.ini><universe_wsgi.ini> >>> >>> >>> >>> >>> On Dec 7, 2011, at 10:35 AM, Greg Von Kuster wrote: >>> >>>> Hello Zach, >>>> >>>> Are you trying to get a local install of Galaxy to communicate with a local tool shed? If so, can you send me your universe_wsgi.ini file and your community_wsgi.ini file? >>>> >>>> Greg Von Kuster >>>> >>>> >>>> On Dec 7, 2011, at 10:20 AM, Zachary Charlop-Powers wrote: >>>> >>>>> Hello Galaxy, >>>>> >>>>> I have been having trouble getting Toolsheds to work on a local install of Galaxy. Based on the error messages I think that I have not correctly modified the nginx server port forwarding and/or the community_wsgi.ini file. If anyone has successfully setup a local toolshed repository I would love to hear from you. >>>>> >>>>> thanks >>>>> zach cp >>>>> >>>>> >>>>> >>>>> ___________________________________________________________ >>>>> 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: >>>>> >>>>> http://lists.bx.psu.edu/ >>>> >>>> Greg Von Kuster >>>> Galaxy Development Team >>>> greg(a)bx.psu.edu >>>> >>>> >>>> >>> >> >> Greg Von Kuster >> Galaxy Development Team >> greg(a)bx.psu.edu >> >> >> > Greg Von Kuster Galaxy Development Team greg(a)bx.psu.edu

1 0

Toolshed fasta-section down?
by Bossers, Alex 08 Dec '11

08 Dec '11

Hi The fasta-manipulation section on toolshed seems to be down (http://toolshed.g2.bx.psu.edu/) Am I the only one experiencing this? IE just returns me a blank error page not found. FF returns me another unhelpful error: Server Error An error occurred. See the error logs for more information. (Turn debug on to display exception reports here) Alex

1 0

bwa setting metadata
by SHAUN WEBB 08 Dec '11

08 Dec '11

Hi, I am running bwa using reference sacCer2. I have locally installed data for sacCer2 and the following line in builds.txt: sacCer2 S. cerevisiae June 2008 (sacCer2) This seems to work fine for other tools (e.g extracting genomic sequence). When I run bwa the job runs correctly but the database field is not set properly. I get the following instead: Project-Id-Version: PACKAGE VERSION Report-Msgid-Bugs-To: POT-Creation-Date: 2008-09-21 18:33+0900 PO-Revision-Date: 2009-03-17 03:55-0400 Last-Translator: FULL NAME Language-Team: en Plural-Forms: nplurals=2; plural=(n != 1) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Generated-By: Babel 0.9.4 Any ideas where this is coming from? Thanks Shaun Webb -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Send data to Galaxy from external websites.
by Vishal R Patel 07 Dec '11

07 Dec '11

Hi, I searched the docs and mailing list but could not figure out how to export data from my website directly to the *Main* public galaxy. My webserver creates a bed file and has meta information like build, genome etc. I would like to provide users with a button that allows them to directly send data to the public instance of galaxy for further analysis. I read about the synchronous method that Galaxy provides. But to me it looked like the user has to navigate to the webpage from within Galaxy. What I am looking for is some method which allows me to build a url of the form http://main.g2.bx.psu.edu/?import_data=URL_FOR_DATA&genome=GENOME&build=BUI… or something like that! So galaxy can grab the data from the URL_FOR_DATA and import it directly to the users current workspace. Is this possible? Thanks, Vishal

1 0

SICER bug in Workflow
by Susan Newman 07 Dec '11

07 Dec '11

I'm working on a SOLiD ChIP-Seq workflow in which I want to use SICER for peak detection. In attempting to add SICER to the workflow, I've run into some difficulty: 1) My input is an interval file which I've created using Convert SAM. In order to connect to the SICER module, I had to use a trick by setting up the connection with the Convert SAM set to BED. The SICER algorithm fails to run when tested with the bed file. If I then change the connected Convert SAM to interval, SICER will run. 2) I need to change the default run parameters but they are not saved in the workflow. There is always reversion to the default values. I get a Server error notice. This workflow also contains Bowtie and MACS. Parameter changes for these algorithms are saved correctly. 3) I would like to run SICER twice in the workflow with different parameters. Is it allowable to load SICER a second time? May I run from the same interval conversion file? I tried this and again could not get the input file recognized as a valid connection. Thanks in advance, Susan Susan S. Newman, Laboratory Manager Genomics Core Facility, L2012 Pennington Biomedical Research Center 6400 Perkins Road Baton Rouge, LA 70808 225-763-0255 (o) 225-763-0257 (lab) http://gcf.pbrc.edu

2 1