Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker)
Hey Eric, The connection string dialect is as follows for TCP/IP connections: dialect+driver://username:password@host:port/database So, the host=/tmp is not necessary when are specifying a hostname (resolves to the IP) and a port because that is referring to UNIX sockets. If you were using SQL Alchemy with a unix socket to connect to the postgres server, then it would look something like this. postgresql+psycopg2://user:password@/dbname?host=/var/lib/postgresql Note that there's no hostname and port. Just the socket is specified. See http://docs.sqlalchemy.org/en/rel_0_9/core/engines.html for more info. Iyad Kandalaft Bioinformatics Programmer Microbial Biodiversity Bioinformatics Science Technology Branch Agriculture Agri-Food Canada iyad.kandal...@agr.gc.ca | (613) 759-1228 From: galaxy-dev-boun...@lists.bx.psu.edu [galaxy-dev-boun...@lists.bx.psu.edu] on behalf of galaxy-dev-requ...@lists.bx.psu.edu [galaxy-dev-requ...@lists.bx.psu.edu] Sent: May 27, 2014 12:00 PM To: galaxy-dev@lists.bx.psu.edu Subject: galaxy-dev Digest, Vol 95, Issue 25 Send galaxy-dev mailing list submissions to galaxy-dev@lists.bx.psu.edu To subscribe or unsubscribe via the World Wide Web, visit http://lists.bx.psu.edu/listinfo/galaxy-dev or, via email, send a message with subject or body 'help' to galaxy-dev-requ...@lists.bx.psu.edu You can reach the person managing the list at galaxy-dev-ow...@lists.bx.psu.edu When replying, please edit your Subject line so it is more specific than Re: Contents of galaxy-dev digest... HEY! This is important! If you reply to a thread in a digest, please 1. Change the subject of your response from Galaxy-dev Digest Vol ... to the original subject for the thread. 2. Strip out everything else in the digest that is not part of the thread you are responding to. Why? 1. This will keep the subject meaningful. People will have some idea from the subject line if they should read it or not. 2. Not doing this greatly increases the number of emails that match search queries, but that aren't actually informative. Today's Topics: 1. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) 2. Changes in admin menu - Upload files (Julien Daligault) 3. Re: Changes in admin menu - Upload files (Dannon Baker) 4. Re: New tool on TestToolShed still not tested (Greg Von Kuster) 5. Re: New tool on TestToolShed still not tested (Peter Cock) 6. Re: Main ToolShed wrong report: Repository does not have a test-data directory. (Greg Von Kuster) 7. Re: Installation failure on Test Tool Shed (Greg Von Kuster) 8. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Greg Von Kuster) 9. Re: ToolShed: Uploaded archives can only include regular directories and files (Greg Von Kuster) 10. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Peter Cock) 11. Re: ToolShed: Uploaded archives can only include regular directories and files (Peter Cock) 12. Re: Old Tool Shed URL http://community.g2.bx.psu.edu/ dead (Greg Von Kuster) 13. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Paniagua, Eric) 14. Uploading files to galaxy from a folder (Kandalaft, Iyad) 15. complex help for conditional param (Jun Fan) 16. Re: complex help for conditional param (Peter Cock) 17. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) 18. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Paniagua, Eric) 19. Re: Problem using Galaxy with a PostgreSQL database on a remote host (Dannon Baker) -- Message: 1 Date: Tue, 27 May 2014 07:40:13 -0400 From: Dannon Baker dannon.ba...@gmail.com To: Paniagua, Eric epani...@cshl.edu Cc: galaxy-dev@lists.bx.psu.edu galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Message-ID: cagn_wzn7wkihvyidhlovl0j4cbu_xeem02n1fkggo8bcnyc...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Hey Eric, It looks like you have connection info for both tcp/ip connections and unix sockets in the connection strings. If you're logging in using psql -h wigserv5.cshl.edu snip, then you only want the tcp/ip connection info. Drop the ?host=tmp off the third option you listed and I think you'll be up and running, so: postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric -Dannon On Sat, May 24, 2014 at 1:49 AM, Paniagua, Eric epani...@cshl.edu wrote: Dear Galaxy Developers, I've been banging my head against this one for a few days now. I have two Galaxy instances. One resides on a server called genomics, which also hosts the corresponding PostgreSQL installation. The second also resides on genomics, but its database is hosted
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
Hey Eric, It looks like you have connection info for both tcp/ip connections and unix sockets in the connection strings. If you're logging in using psql -h wigserv5.cshl.edu snip, then you only want the tcp/ip connection info. Drop the ?host=tmp off the third option you listed and I think you'll be up and running, so: postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric -Dannon On Sat, May 24, 2014 at 1:49 AM, Paniagua, Eric epani...@cshl.edu wrote: Dear Galaxy Developers, I've been banging my head against this one for a few days now. I have two Galaxy instances. One resides on a server called genomics, which also hosts the corresponding PostgreSQL installation. The second also resides on genomics, but its database is hosted on wigserv5. Based on the tests I just ran and code I just read, sqlalchemy (not Galaxy) is ignoring the hostname/port part of the database_connection string. For reference, the connection strings I've tried are: postgresql://glxeric:X@/glxeric?host=/tmp postgresql://glxeric:xx...@wigserv5.cshl.edu/glxeric?host=/tmp postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric?host=/tmp postgresql://glxeric:X@adgdgdfdflkhjfdhfkl/glxeric?host=/tmp All of these appear to result in Galaxy connecting to the PostgreSQL installation on genomics, as determined by Galaxy schema version discrepancies and other constraints. With each connection string, Galaxy starts up normally. I force database activity by browsing saved histories. It works every time. By all appearances, the second Galaxy instance is using the PostgreSQL database hosted on genomics, not on wigserv5. All databases and roles exist, and the databases are populated. When I comment out the database_connection line in universe_wsgi.ini, I get errors arising from the later configuration of PostgreSQL-specific Galaxy options, as expected. I can connect to the database server on wigserv5 using psql -h wigserv5.cshl.edu -d glxeric -U glxeric from the server genomics. Have you ever observed this behavior from Galaxy or sqlalchemy? Thanks, Eric ___ 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/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
Hey Dannon, Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: Traceback (most recent call last): File ./scripts/migrate_tools/migrate_tools.py, line 21, in app = MigrateToolsApplication( sys.argv[ 1 ] ) File /localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/migrate/common.py, line 59, in __init__ install_dependencies=install_dependencies ) File /localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py, line 122, in __init__ is_repository_dependency=is_repository_dependency ) File /localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py, line 506, in install_repository is_repository_dependency=is_repository_dependency ) File /localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py, line 345, in handle_repository_contents guid = self.get_guid( repository_clone_url, relative_install_dir, tool_config ) File /localdata1/galaxy/glxmaint/src/lib/tool_shed/galaxy_install/install_manager.py, line 253, in get_guid tool = self.toolbox.load_tool( full_path )! File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 671, in load_tool return ToolClass( config_file, root, self.app, guid=guid, repository_id=repository_id, **kwds ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1045, in __init__ self.parse( root, guid=guid ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1260, in parse self.parse_inputs( root ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1351, in parse_inputs display, inputs = self.parse_input_page( page, enctypes ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1655, in parse_input_page inputs = self.parse_input_elem( input_elem, enctypes ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1723, in parse_input_elem case.inputs = self.parse_input_elem( case_elem, enctypes, context ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1679, in pa! rse_input_elem group.inputs = self.parse_input_elem( elem, enc! types, c ontext ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1751, in parse_input_elem param = self.parse_param_elem( elem, enctypes, context ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/__init__.py, line 1764, in parse_param_elem param = ToolParameter.build( self, input_elem ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py, line 215, in build return parameter_types[param_type]( tool, param ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py, line 1566, in __init__ ToolParameter.__init__( self, tool, elem ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/basic.py, line 54, in __init__ self.validators.append( validation.Validator.from_element( self, elem ) ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/parameters/validation.py, line 23, in from_element return validator_types[type].from_element( param, elem ) File /localdata1/galaxy/glxmaint/src/lib/galaxy/t! ools/parameters/validation.py, line 283, in from_element tool_data_table = param.tool.app.tool_data_tables[ table_name ] File /localdata1/galaxy/glxmaint/src/lib/galaxy/tools/data/__init__.py, line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? Thanks, Eric From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 7:40 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Hey Eric, It looks like you have connection info for both tcp/ip connections and unix sockets in the connection strings. If you're logging in using psql -h wigserv5.cshl.eduhttp://wigserv5.cshl.edu snip, then you only want the tcp/ip connection info. Drop the ?host=tmp off the third option you listed and I think you'll be up and running, so: postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxerichttp://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric -Dannon On Sat, May 24, 2014 at 1:49 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edu wrote: Dear Galaxy Developers, I've been banging my head against this one for a few days now. I have two Galaxy instances. One resides on a server called genomics, which also hosts the corresponding
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric epani...@cshl.edu wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
The dataset table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edu wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible. If there's an error this time around, note it and send it on over and we can figure out where to go from there. On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric epani...@cshl.edu wrote: The dataset table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric epani...@cshl.edu mailto:epani...@cshl.edu wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
I have created a fresh dump with $ pg_dump -U galaxyprod galaxyprod This time the import proceeded cleanly. Further, using PostgreSQL 9.1, I no longer get the error regarding a read only database cursor and getting the next history item number. I am currently running a test job to confirm that things are working as expected. However, just the fact that this job is running is a very good sign. From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:58 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible. If there's an error this time around, note it and send it on over and we can figure out where to go from there. On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edu wrote: The dataset table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... From: Dannon Baker [dannon.ba...@gmail.commailto:dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edumailto:galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edumailto:epani...@cshl.edumailto:epani...@cshl.edu wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
Restarting the Galaxy server in multiple process mode appears to have helped. The test job is now running. From: Paniagua, Eric Sent: Tuesday, May 27, 2014 12:43 PM To: Dannon Baker Cc: galaxy-dev@lists.bx.psu.edu Subject: RE: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Correction. The job has entered the waiting to run phase, and doesn't appear to be leaving it. There is nothing of note in the server log. From: Paniagua, Eric Sent: Tuesday, May 27, 2014 12:41 PM To: Dannon Baker Cc: galaxy-dev@lists.bx.psu.edu Subject: RE: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host I have created a fresh dump with $ pg_dump -U galaxyprod galaxyprod This time the import proceeded cleanly. Further, using PostgreSQL 9.1, I no longer get the error regarding a read only database cursor and getting the next history item number. I am currently running a test job to confirm that things are working as expected. However, just the fact that this job is running is a very good sign. From: Dannon Baker [dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:58 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host Since the database has lost consistency, I'd really try a fresh pg_dump / import if that's possible. If there's an error this time around, note it and send it on over and we can figure out where to go from there. On Tue, May 27, 2014 at 11:48 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edu wrote: The dataset table is populated. I looked at the SQL dump file I used to copy the database, and it has create table and copy into statements for history_dataset_association, but it looks like there may have been an error while executing them. Trying to figure out how to get my data in... From: Dannon Baker [dannon.ba...@gmail.commailto:dannon.ba...@gmail.com] Sent: Tuesday, May 27, 2014 11:43 AM To: Paniagua, Eric Cc: galaxy-dev@lists.bx.psu.edumailto:galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host On Tue, May 27, 2014 at 11:26 AM, Paniagua, Eric epani...@cshl.edumailto:epani...@cshl.edumailto:epani...@cshl.edumailto:epani...@cshl.edu wrote: Thanks for pointing that out! I missed it. I am now connecting to the remote database. I ran sh manage_db.sh upgrade and it upgraded from schema 114 to 118 without error messages. I then ran sh ./scripts/migrate_tools/0010_tools.sh install_dependencies and received the following error: line 35, in __getitem__ return self.data_tables.__getitem__( key ) KeyError: 'gatk_picard_indexes' I fixed this by adding the appropriate entries to tool_data_table_conf.xml. I then reran the migrate_tools command successfully. However, now my history_dataset_association table in the database was blown away at some point. The table is now completely empty. Have you ever seen this before? I have not seen the tool migration issue before, but it seems harmless. The fact that your history_dataset_association table is empty is concerning if there was ever anything in it. Can you verify that there are datasets in the same database that *should* be associated to a history? It sounds like this galaxy instance has been used with different databases, and my hope is that the wires are crossed up here and there actually should not be any. ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Problem using Galaxy with a PostgreSQL database on a remote host
Dear Galaxy Developers, I've been banging my head against this one for a few days now. I have two Galaxy instances. One resides on a server called genomics, which also hosts the corresponding PostgreSQL installation. The second also resides on genomics, but its database is hosted on wigserv5. Based on the tests I just ran and code I just read, sqlalchemy (not Galaxy) is ignoring the hostname/port part of the database_connection string. For reference, the connection strings I've tried are: postgresql://glxeric:X@/glxeric?host=/tmp postgresql://glxeric:xx...@wigserv5.cshl.edu/glxeric?host=/tmp postgresql://glxeric:xx...@wigserv5.cshl.edu:5432/glxeric?host=/tmp postgresql://glxeric:X@adgdgdfdflkhjfdhfkl/glxeric?host=/tmp All of these appear to result in Galaxy connecting to the PostgreSQL installation on genomics, as determined by Galaxy schema version discrepancies and other constraints. With each connection string, Galaxy starts up normally. I force database activity by browsing saved histories. It works every time. By all appearances, the second Galaxy instance is using the PostgreSQL database hosted on genomics, not on wigserv5. All databases and roles exist, and the databases are populated. When I comment out the database_connection line in universe_wsgi.ini, I get errors arising from the later configuration of PostgreSQL-specific Galaxy options, as expected. I can connect to the database server on wigserv5 using psql -h wigserv5.cshl.edu -d glxeric -U glxeric from the server genomics. Have you ever observed this behavior from Galaxy or sqlalchemy? Thanks, Eric ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Problem With Galaxy
I am having an issue trying to do anything. I click on a tool, the screen pops up in the middle but then when I move my mouse over to that screen, the drop down menus all pull down in a large black screen so that I cannot get to anything. The screen also does not go away if I try to click away from it, but only if I choose one of the options from the list. I would click analyze data which would take back to where I started. This happens for every tool that I try. I did not have this problem this morning or afternoon, but I've been trying to get it to work for almost an hour. As soon as my mouse hits that center area (top, bottom, middle), the screen comes down, but only after I select a tool. Please help. Caitlin Grube ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem With Galaxy
Is this a local galaxy setup that you host ... or the public one? It sounds like a cache issue on your end (clear your browsers cache). If this is a local setup that you host, perhaps you are not loading CSS/javascript? Are those being blocked? Are you running a reverse proxy? Have the redirects been setup to handle static content? To many unknowns ~Adam -- Adam Brenner Computer Science, Undergraduate Student Donald Bren School of Information and Computer Sciences Research Computing Support Office of Information Technology http://www.oit.uci.edu/rcs/ University of California, Irvine www.ics.uci.edu/~aebrenne/ aebre...@uci.edu On Mon, Oct 28, 2013 at 3:59 PM, Caitlin Grube chg...@psu.edu wrote: I am having an issue trying to do anything. I click on a tool, the screen pops up in the middle but then when I move my mouse over to that screen, the drop down menus all pull down in a large black screen so that I cannot get to anything. The screen also does not go away if I try to click away from it, but only if I choose one of the options from the list. I would click analyze data which would take back to where I started. This happens for every tool that I try. I did not have this problem this morning or afternoon, but I've been trying to get it to work for almost an hour. As soon as my mouse hits that center area (top, bottom, middle), the screen comes down, but only after I select a tool. Please help. Caitlin Grube ___ 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/ 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: http://lists.bx.psu.edu/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
Re: [galaxy-dev] Problem configuring Galaxy with an Apache proxy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Erwan, This issue is caused by a missing trailing slash in your proxy definition. That's why the root page will load, but nothing requiring any more depth than that. # Explanation (For example, I run mine in a subdirectory) localhost:8080/galaxy The root page makes the request to localhost:8080/galaxy and that suceeds. All sub-pages (e.g., style sheets, etc) make requests that look like localhost:8080/galaxystatic/welcome.html and fail. Just add your missing slash and you'll be fine. In the future I find setting LogLevel Debug in my apache conf helpful for this sort of thing, and watching the logs as I make HTTP requests to galaxy. Cheers, Eric On 10/17/2013 08:39 AM, Erwan Delage wrote: Hello everyone, I'm having trouble setting up Galaxy with an Apache Proxy. I did edit the Apache conf file with the following lines : RewriteEngine on RewriteRule ^/static/style/(.*)/home/nate/galaxy-dist/static/june_2007_style/blue/$1 [L] RewriteRule ^/static/scripts/(.*)/home/nate/galaxy-dist/static/scripts/packed/$1 [L] RewriteRule ^/static/(.*)/home/nate/galaxy-dist/static/$1 [L] RewriteRule ^/favicon.ico/home/nate/galaxy-dist/static/favicon.ico [L] RewriteRule ^/robots.txt/home/nate/galaxy-dist/static/robots.txt [L] RewriteRule ^(.*) http://localhost:8080$1 [P] The redirection seems to work as I reach a webpage that contains some Galaxy's links but, as you can see in the attached snapshot, the webpage does not really looks like the usual Galaxy welcome page :) Did you already face that problem or do you have any idea to solve it ? Thanks, Erwan, ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/ - -- Eric Rasche Programmer II Center for Phage Technology Texas AM University College Station, TX 77843 404-692-2048 e...@tamu.edu rasche.e...@yandex.ru -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSX/vjAAoJEMqDXdrsMcpVXskP/2sE0Wi2pUASL9YWYnP9X92O p+QVecyPXzOsfYqTHvJ+oD49xWueVjNdqGhwjGRgAXEJhboQ4gzvjH6xRzwKDXIs c58b/hRq38Hshw292k24HxrDFKoy0ETYyJTTnIQ3IazkAs+OO4kW9zMHTg+IEgsf GCa8QkD2S7Om85k7JuY7XjmBC5SCtgvR1s+QnAmyXv3Atjsa1TZtyH3uFpppSKwn ufuZwcr/A7dkdX2SEakb9QDv/8/ksDe5U6SMd/hjGXgfPX7ZelWhxF6IZibYHDXT 5tG1t3q/facJFTXAFvTGl/Caif1JABeMEnBe6U/heDlO4GYMTGl6uJVYcJ1XzQWI B9a3Ui8YS72Nufce0xlGxlItpDsjz9UnHuX0b++vrPViyULCB2wZaOW4AUnBk1YY 6wK4dO4+2jXX6zuDeIWcHz/REpJDwIASak5FcvWTdVK3n9/tmz1puyF9OLUi907g Dc5MU9qyuHT1NM3NqHlxSCDSVZaX4rb6b14qNsceg/aXdE6c8NBN+PjyqYe4t7za TBMpgXwXxvq7lxnfu2sRkulte2zhZjcsZiAmDqPRfIB8Hxd9Zdwz5h/uvV4HnIzp uBns36WKuD5wJc42tb2gHxMDtwSEtr6raxNbvaNvIeISLc2Uc9tEG3Lzyw17fWT5 4ux/759O8sjh1JaoIj9p =dVoe -END PGP SIGNATURE- ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] Problem updating galaxy (No such file or directory: './shed_tool_data_table_conf.xml')
I've started up an instance using cloudman, and it seemed to be running fine. When I tried to install a tool from the toolshed I got an error, and in trying to resolve the error I used the admin console to update galaxy. Now when Galaxy tries to start I get the following error: galaxy.datatypes.registry DEBUG 2013-06-26 22:20:49,969 Loaded sniffer for datatype 'galaxy.datatypes.images:Pbm' galaxy.datatypes.registry DEBUG 2013-06-26 22:20:49,969 Loaded sniffer for datatype 'galaxy.datatypes.images:Pgm' galaxy.datatypes.registry DEBUG 2013-06-26 22:20:49,969 Loaded sniffer for datatype 'galaxy.datatypes.images:Xpm' galaxy.datatypes.registry DEBUG 2013-06-26 22:20:49,970 Loaded sniffer for datatype 'galaxy.datatypes.images:Eps' galaxy.datatypes.registry DEBUG 2013-06-26 22:20:49,970 Loaded sniffer for datatype 'galaxy.datatypes.images:Rast' galaxy.tools.data DEBUG 2013-06-26 22:20:49,988 Loaded tool data table 'all_fasta' galaxy.tools.data DEBUG 2013-06-26 22:20:49,988 Loaded tool data table 'blastdb' galaxy.tools.data DEBUG 2013-06-26 22:20:49,989 Loaded tool data table 'bowtie_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,989 Loaded tool data table 'bowtie_indexes_color' galaxy.tools.data DEBUG 2013-06-26 22:20:49,990 Loaded tool data table 'bwa_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,990 Loaded tool data table 'lastz_seqs' galaxy.tools.data DEBUG 2013-06-26 22:20:49,990 Loaded tool data table 'perm_base_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,996 Loaded tool data table 'perm_color_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,996 Loaded tool data table 'sam_fa_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,997 Loaded tool data table 'picard_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,997 Loaded tool data table 'srma_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,997 Loaded tool data table 'tophat_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,998 Loaded tool data table 'mosaik_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,998 Loaded tool data table 'sam_indexes' galaxy.tools.data DEBUG 2013-06-26 22:20:49,998 Loaded tool data table 'twobit' galaxy.tools.data DEBUG 2013-06-26 22:20:49,999 Loaded tool data table 'lift_over' Traceback (most recent call last): File /mnt/galaxyTools/galaxy-central/lib/galaxy/webapps/galaxy/buildapp.py, line 35, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File /mnt/galaxyTools/galaxy-central/lib/galaxy/app.py, line 95, in __init__ from_shed_config=False ) File /mnt/galaxyTools/galaxy-central/lib/galaxy/tools/data/__init__.py, line 56, in load_from_config_file tree = util.parse_xml( config_filename ) File /mnt/galaxyTools/galaxy-central/lib/galaxy/util/__init__.py, line 132, in parse_xml tree = ElementTree.parse(fname) File /mnt/galaxyTools/galaxy-central/eggs/elementtree-1.2.6_20050316-py2.6.egg/elementtree/ElementTree.py, line 859, in parse tree.parse(source, parser) File /mnt/galaxyTools/galaxy-central/eggs/elementtree-1.2.6_20050316-py2.6.egg/elementtree/ElementTree.py, line 576, in parse source = open(source, rb) IOError: [Errno 2] No such file or directory: './shed_tool_data_table_conf.xml' Removing PID file paster.pid How do I resolve the no such file or directory error? I found an email conversation on this that said to restart galaxy, and I've done this multiple times but the problem is persisting. Thanks, -Brad ___ 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/ To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/
[galaxy-dev] problem viewing galaxy menu items using IE, version number
Hello, 1. When we access galaxy (local installation) using IE (internet explorer) 8 and 9, we cannot expand/collapse uploaded data files visible from history window. Neither are the info and save icons visible. How do I fix this ? Also items under the main menu are not clickable (e.g. when I click on User menu item, it expands to show User and Register, but I cannot select User or Register items). I can view/click these items using Firefox browser. 2. How do I determine the version number of my installation ? I do not have the original tar file that has the version name. Appreciate your help. Sukha ___ 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/
