Re: [galaxy-dev] ProFFTPd-1.3.4d no longer able to authenticate users from Postgresql database
So I tried a new version of ProFTPd I was not able to locate lines in universe_wsgi.ini which disable PBKDF2 Lines from SQLLogFile.txt 2014-01-21 18:09:33,191 mod_sql/4.3[2275]: checking password using SQLAuthType 'sha1' 2014-01-21 18:09:33,191 mod_sql/4.3[2275]: 'sha1' SQLAuthType handler reports failure 2014-01-21 18:09:33,191 mod_sql/4.3[2275]: checking password using SQLAuthType 'sha256' 2014-01-21 18:09:33,191 mod_sql/4.3[2275]: 'sha256' SQLAuthType handler reports failure 2014-01-21 18:09:33,191 mod_sql/4.3[2275]: checking password using SQLAuthType 'pbkdf2' 2014-01-21 18:09:33,193 mod_sql/4.3[2275]: 'pbkdf2' SQLAuthType handler reports failure 2014-01-21 18:09:33,193 mod_sql/4.3[2275]: cmd_check 2014-01-21 18:09:33,193 mod_sql/4.3[2275]: cmd_auth 2014-01-21 18:13:54,383 mod_sql/4.3[2275]: entering postgres cmd_exit Proftpd.conf # Set up mod_sql to authenticate against the Galaxy database SQLEngine on SQLBackend postgres SQLConnectInfo galaxy_prod@:1234 user password SQLAuthTypesSHA1 SHA256 PBKDF2 SQLPasswordPBKDF2 SHA256 1000 24 SQLAuthenticate users Launch interactive session to test /ProFTPd-1.3.5rc3/sbin/proftpd -d9 -n Std_Out shows: opening scoreboard '/shared/app/ProFTPd-1.3.5rc3/var/proftpd.scoreboard' RELINQUISH PRIVS at mod_auth.c:132 connected - local : :::128.23.191.200:21 connected - remote : 128.23.163.166:54865 FTP session opened. dispatching PRE_CMD command 'USER gal...@musc.edu' to mod_core dispatching PRE_CMD command 'USER gal...@musc.edu' to mod_core dispatching PRE_CMD command 'USER gal...@musc.edu' to mod_delay dispatching PRE_CMD command 'USER gal...@musc.edu' to mod_auth dispatching CMD command 'USER gal...@musc.edu' to mod_auth dispatching POST_CMD command 'USER gal...@musc.edu' to mod_sql dispatching POST_CMD command 'USER gal...@musc.edu' to mod_delay dispatching LOG_CMD command 'USER gal...@musc.edu' to mod_sql dispatching LOG_CMD command 'USER gal...@musc.edu' to mod_lo dispatching PRE_CMD command 'PASS (hidden)' to mod_core dispatching PRE_CMD command 'PASS (hidden)' to mod_core dispatching PRE_CMD command 'PASS (hidden)' to mod_sql_passwd dispatching PRE_CMD command 'PASS (hidden)' to mod_sql dispatching PRE_CMD command 'PASS (hidden)' to mod_delay dispatching PRE_CMD command 'PASS (hidden)' to mod_auth dispatching CMD command 'PASS (hidden)' to mod_auth no supplemental groups found for user 'gal...@musc.edu' ROOT PRIVS at mod_auth_pam.c:338 RELINQUISH PRIVS at mod_auth_pam.c:508 mod_sql_passwd/0.6: expected 'PBKDF2$sha256$1$vHKjTtvJsQSB2BuH$dGmwtBwxQ9yAz5kxzn9nF704PKeMnReV', got '1fd439fa1297e68426765a5c0b80a6ca4591888a' mod_sql_passwd/0.6: expected 'PBKDF2$sha256$1$vHKjTtvJsQSB2BuH$dGmwtBwxQ9yAz5kxzn9nF704PKeMnReV', got '268f784ba4c2283244e9730500f2a8126c84169ef985a70313c16464358ecc5c' mod_sql_passwd/0.6: expected 'PBKDF2$sha256$1$vHKjTtvJsQSB2BuH$dGmwtBwxQ9yAz5kxzn9nF704PKeMnReV', got '5f40c627d580e898f9742508c3aa0f0fbe87850e3b389ac1' USER gal...@musc.edu (Login failed): No such user found. I upgraded to ProFTPd-1.3.5rc3 because v 1.3.4 could not authenticate users on my local Galaxy instance. I understood that Galaxy was using SHA1 SHA256 PBKDF2 authentication but the programs are not yet compatible I used a proftpd conf file based on http://dev.list.galaxyproject.org/ProFTPD-integration-with-Galaxy-td4660295 .html I get the same problems when I use the following line in profited.conf SQLPasswordPBKDF2SHA256 1 24 Why am I seeing this mismatch? I tried to create a new user to see if the extant user accounts had somehow been left over from a previous build of the Galaxy user files, but the new user had the same issues. Puzzled Starr On 1/8/14, 5:26 PM, Hazard, E. Starr haza...@musc.edu wrote: Well when I declare SQLAuthTypesSHA1 SHA256 PBKDF2 SQLPasswordPBKDF2 SHA256 1 24 (per I get this response /shared/app/ProFFTPd-1.3.4d/sbin/proftpd -d9 -n hpcc3 proftpd[31522]: using TCP receive buffer size of 87380 bytes hpcc3 proftpd[31522]: using TCP send buffer size of 16384 bytes hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'md5' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha1' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha256' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha512' SQLAuthType handler hpcc3 proftpd[31522]: disabling runtime support for IPv6 connections hpcc3 proftpd[31522]: Fatal: SQLAuthTypes: unknown SQLAuthType 'PBKDF2' on line 106 of '/shared/app/ProFFTPd-1.3.4d/etc/proftpd.conf¹ SO ProFTPd-1.3.4d does not do PBKDF2 Just saw this post http://dev.list.galaxyproject.org/ProFTPD-integration-with-Galaxy-td466029 5 .html Will move to the release candidate version of ProFTPD And try that THANKS for responding Starr On 1/8/14, 5:05 PM
[galaxy-dev] ProFFTPd-1.3.4d no longer able to authenticate users from Postgresql database
I was able to query my Postgresql Db for user authentication at one time.
I deleted and then rebuilt the postgresql DB and rebuilt the entire Galaxy
instance in early December. Since then I cannot get ProFFTPd-1.3.4d to
authenticate users from Postgresql database. At that time my existing
universe_wsgi.ini
I changed the following from postgres to postgresql
#database_connection =
postgres://galaxy:Galaxy2013@localhost:5434/galaxy_prod
database_connection =
postgresql://galaxy:galaxy2013@localhost:5434/galaxy_prod
What ftp interaction behavior changes were included in this
database_connectio method renaming? (And how can I fix them?)
My Galaxy users can login to Galaxy just fine and execute programs if I
manually load files into the designated FTP dir and then move these to
database/files .
Screen session from interactive test mode
FTP session opened.
dispatching PRE_CMD command 'USER [valid email]' to mod_core
.
.
.
dispatching CMD command 'PASS (hidden)' to mod_auth
no supplemental groups found for user '[valid email]'
ROOT PRIVS at mod_auth_pam.c:338
RELINQUISH PRIVS at mod_auth_pam.c:508
mod_sql_passwd/0.4: expected
'PBKDF2$sha256$1$1xx',got Œyy¹
I am not using either PBKDF2 or sha256 see below why are these prefixes
appended? Xxx and are NOT the same alphanumeric strings
SQLLogFile.txt excerpt:
Jan 06 17:27:49 mod_sql/4.3[29179]: query SELECT
email,password,' mailto:'ir...@musc.edu[valid email]','{UNKNOWN
TAG}',¹/PATH/galaxy-dist/database/files/
mailto:'/shared/app/Galaxy/galaxy-dist/database/files/ir...@musc.edu[vali
d email]','/bin/
bash' FROM galaxy_user WHERE email=' mailto:email='ir...@musc.edu[valid
email]'
Jan 06 17:27:49 mod_sql/4.3[29179]: enteringpostgres cmd_close
Jan 06 17:27:49 mod_sql/4.3[29179]: connection 'default' count is now 1
Jan 06 17:27:49 mod_sql/4.3[29179]: exiting postgres cmd_close
Jan 06 17:27:49 mod_sql/4.3[29179]: exiting postgres cmd_select
Jan 06 17:27:49 mod_sql/4.3[29179]: process_named_query
'LookupGalaxyUser'
Jan 06 17:27:49 mod_sql/4.3[29179]: sql_lookup
Jan 06 17:27:49 mod_sql/4.3[29179]: user UID 0 below SQLMinUserUID 999,
using SQLDefaultUID 65533
Jan 06 17:27:49 mod_sql/4.3[29179]: user GID 0 below SQLMinUserGID 999,
using SQLDefaultGID 65533
Jan 06 17:27:49 mod_sql/4.3[29179]: cache miss for user '
mailto:'ir...@musc.edu[valid email]'
Jan 06 17:27:49 mod_sql/4.3[29179]: user ' mailto:'ir...@musc.edu[valid
email]' cached
Jan 06 17:27:49 mod_sql/4.3[29179]: + pwd.pw_name : [valid email]
Jan 06 17:27:49 mod_sql/4.3[29179]: + pwd.pw_uid : 65533
Jan 06 17:27:49 mod_sql/4.3[29179]: + pwd.pw_gid : 65533
Jan 06 17:27:49 mod_sql/4.3[29179]: + pwd.pw_dir :
/PATH/galaxy-dist/database/files/
mailto:/shared/app/Galaxy/galaxy-dist/database/files/ir...@musc.edu[valid
email]
Jan 06 17:27:49 mod_sql/4.3[29179]: + pwd.pw_shell : /bin/bash
Jan 06 17:27:49 mod_sql/4.3[29179]: cmd_getpwnam
Jan 06 17:27:49 mod_sql/4.3[29179]: cmd_auth
Jan 06 17:27:49 mod_sql/4.3[29179]: enteringpostgres cmd_escapestring
Jan 06 17:27:49 mod_sql/4.3[29179]: enteringpostgres cmd_open
Jan 06 17:27:49 mod_sql/4.3[29179]: connection 'default' count is now 2
Jan 06 17:27:49 mod_sql/4.3[29179]: exiting postgres cmd_open
Jan 06 17:27:49 mod_sql/4.3[29179]: enteringpostgres cmd_close
Jan 06 17:27:49 mod_sql/4.3[29179]: connection 'default' count is now 1
Jan 06 17:27:49 mod_sql/4.3[29179]: exiting postgres cmd_close
Jan 06 17:27:49 mod_sql/4.3[29179]: exiting postgres cmd_escapestring
Jan 06 17:27:49 mod_sql/4.3[29179]: cache hit for user '[valid email]'
Jan 06 17:27:49 mod_sql/4.3[29179]: cmd_check
Jan 06 17:27:49 mod_sql/4.3[29179]: checking password using SQLAuthType
'sha1'
Jan 06 17:27:49 mod_sql/4.3[29179]: 'sha1' SQLAuthType handler reports
failure
ProFTPd conf file excerpt:
(based on https://wiki.galaxyproject.org/Admin/Config/Upload%20via%20FTP)
# Set up mod_sql_password - Galaxy passwords are stored as hex-encoded SHA1
SQLPasswordEngine on
SQLPasswordEncoding hex
# Set up SQLLogfile
SQLLogFile /PATH/ProFFTPd-1.3.4d/etc/SQLLogFile.txt
# Set up mod_sql to authenticate against the Galaxy database
SQLEngine on
SQLBackend postgres
SQLConnectInfo galaxy_prod@:5xxx galaxy galpwd # port
and password are changed here; they are correct in the working files.
SQLAuthTypesSHA1
SQLAuthenticate users
# An empty directory in case chroot fails
SQLDefaultHomedir /shared/app/ProFFTPd-1.3.4d/default
# 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,¹1233¹,'1234',¹/PATH/galaxy-dist/database/files/%U
','/bin/bash' FROM galaxy_user WHERE email='%U'
Re: [galaxy-dev] ProFFTPd-1.3.4d no longer able to authenticate users from Postgresql database
Well when I declare SQLAuthTypesSHA1 SHA256 PBKDF2 SQLPasswordPBKDF2 SHA256 1 24 (per I get this response /shared/app/ProFFTPd-1.3.4d/sbin/proftpd -d9 -n hpcc3 proftpd[31522]: using TCP receive buffer size of 87380 bytes hpcc3 proftpd[31522]: using TCP send buffer size of 16384 bytes hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'md5' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha1' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha256' SQLAuthType handler hpcc3 proftpd[31522]: mod_sql_passwd/0.4: registered 'sha512' SQLAuthType handler hpcc3 proftpd[31522]: disabling runtime support for IPv6 connections hpcc3 proftpd[31522]: Fatal: SQLAuthTypes: unknown SQLAuthType 'PBKDF2' on line 106 of '/shared/app/ProFFTPd-1.3.4d/etc/proftpd.conf¹ SO ProFTPd-1.3.4d does not do PBKDF2 Just saw this post http://dev.list.galaxyproject.org/ProFTPD-integration-with-Galaxy-td4660295 .html Will move to the release candidate version of ProFTPD And try that THANKS for responding Starr On 1/8/14, 5:05 PM, James Taylor ja...@jamestaylor.org wrote: PBKDF2 ___ 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] a galaxy of issues; Job output not returned from cluster,drmaa getting wrong LSF job id and job.o files not being found and moving files occurring before upload completes.
This is a stand alone instance of Galaxy built Nov 28 a small research cluster using LSF and built on RHEL6.2. galaxy.tools.actions.upload_common INFO 2013-12-05 14:33:01,106 tool upload1 created job id 10 Working directory for job is: /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 galaxy.jobs.handler DEBUG 2013-12-05 14:33:01,290 (10) Dispatching to drmaa runner galaxy.jobs DEBUG 2013-12-05 14:33:01,441 (10) Persisting job destination (destination id: drmaa) galaxy.jobs.handler INFO 2013-12-05 14:33:01,471 (10) Job dispatched galaxy.tools.deps DEBUG 2013-12-05 14:33:01,693 Building dependency shell command for dependency 'samtools' galaxy.tools.deps WARNING 2013-12-05 14:33:01,693 Failed to resolve dependency on 'samtools', ignoring galaxy.jobs.runners.drmaa DEBUG 2013-12-05 14:33:02,352 (10) submitting file /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10/ galaxy_10.sh galaxy.jobs.runners.drmaa DEBUG 2013-12-05 14:33:02,352 (10) command is: pythonŠ. galaxy.jobs DEBUG 2013-12-05 14:33:02,379 (10) Changing ownership of working directory with: /usr/bin/sudo -E scripts/external_chown_script.py /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 galaxy 50982 galaxy.jobs.runners.drmaa DEBUG 2013-12-05 14:33:02,528 (10) submitting with credentials: galaxy [uid: 50981] galaxy.jobs.runners.drmaa DEBUG 2013-12-05 14:33:02,574 (10) Job script for external submission is: /depot/shared/app/Galaxy/galaxy-dist/database/lsf/10.jt_json galaxy.jobs.runners.drmaa INFO 2013-12-05 14:33:02,772 (10) queued as Job 28526 is submitted to default queue medium_priority. 28526 galaxy.jobs DEBUG 2013-12-05 14:33:02,837 (10) Persisting job destination (destination id: drmaa) galaxy.jobs.runners.drmaa INFO 2013-12-05 14:33:03,237 (10/Job 28526 is submitted to default queue medium_priority. 28526) job left DRM queue with following message: code 18: invalid LSF job id: Job 28526 is submitted to default queue medium_priority. 28526 galaxy.jobs DEBUG 2013-12-05 14:33:03,303 (10) Changing ownership of working directory with: /usr/bin/sudo -E scripts/external_chown_script.py /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 galaxy 50982 128.23.163.166 - - [05/Dec/2013:14:33:05 -0400] GET /api/histories/50a7a2e81473b416/contents HTTP/1.1 200 - http://hpcc3.musc.edu:8089/root; Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0 galaxy.jobs.runners ERROR 2013-12-05 14:33:08,661 (10/Job 28526 is submitted to default queue medium_priority. 28526) Job output not returned from cluster: [Errno 2] No such file or directory: '/depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 /galaxy_10.o' galaxy.jobs DEBUG 2013-12-05 14:33:08,701 (10) Changing ownership of working directory with: /usr/bin/sudo -E scripts/external_chown_script.py /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 galaxy 50982 galaxy.jobs DEBUG 2013-12-05 14:33:09,049 finish(): Moved /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10/ galaxy_dataset_16.dat to /depot/shared/app/Galaxy/galaxy-dist/database/files/000/dataset_16.dat galaxy.jobs DEBUG 2013-12-05 14:33:09,049 finish(): Moved /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10/ galaxy_dataset_15.dat to /depot/shared/app/Galaxy/galaxy-dist/database/files/000/dataset_15.dat galaxy.jobs DEBUG 2013-12-05 14:33:09,105 setting dataset state to ERROR galaxy.jobs DEBUG 2013-12-05 14:33:09,126 setting dataset state to ERROR galaxy.jobs DEBUG 2013-12-05 14:33:09,214 job 10 ended Job output not returned from cluster² appears in History, BUT in fact files are being written to directories indicated in my universe_wsgi.ini I am having no success getting a solution to this error job left DRM queue with following message: code 18: invalid LSF job id This file No such file or directory: '/depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10 /galaxy_10.o¹ ³ exists AFTER the job finishes. SO at 2013-12-05 14:33:03 the file had not been written but does appear later. This operation is completing before the file can be uploaded and so an empty file is moved Moved /depot/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/10/ galaxy_dataset_15.dat to /depot/shared/app/Galaxy/galaxy-dist/database/files/000/dataset_15.dat From my universe_wsgi.ini: file_path = database/files new_file_path = database/job_working_directory job_working_directory = database/job_working_directory cluster_files_directory = database/job_working_directory Any troubleshooting suggestions appreciated. Starr ___ 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
[galaxy-dev] Trouble getting proftpd to use Galaxy postgresql authentication
Folks, I am new to using proftpd/Galaxy on a local cluster I am having lots of issues. Here is one. I cannot connect to the proftpd server to upload files. ./proftpd --version ProFTPD Version 1.3.4d ( so proftpd is compiled and running) I am attempting to connect from an iMAC (OSX 10.9) to a LINUX machine where the proftp server is running ftp 123.45.678.123 Connected to 123.45.678.123. 220 ProFTPD 1.3.4d Server (Public Galaxy FTP by ProFTPD server installation) [128.23.191.200] Name (123.45.678.123:hazards): hazards 331 Password required for hazards I enter a password and I get “Abort trap 6” or “421 service not available, remote server closed connection” ( this latter reply from an older mac) I presume that this means that the authentication failed. Here are the last lines of my proftpd.conf file # 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 galax...@xxx.musc.edu dbuser dbpassword SQLAuthTypesSHA1 SQLAuthenticate users # An empty directory in case chroot fails SQLDefaultHomedir /shared/app/ProFFTPd-1.3.4d/default # 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,'581','582','/shared/app/Galaxy/galaxy_dist/database/files/%U','/bin/bash' FROM galaxy_user WHERE email='%U’ I have a user named galaxy on the system and a Galaxy-user named galaxy defined within Galaxy and an owner of the postgresql database. With respect to the following line, If my Galaxy postgresql database is called “galaxydb”, are the dbuser and dbpassword to be the postgresql owner of the database? Or the system user named galaxy who has actually started the instance of galaxy with run.sh command. SQLConnectInfo galax...@xxx.musc.edu galaxy Galaxy2013 With respect to this line SQLNamedQuery LookupGalaxyUser SELECT email,password,'581','582’,…… What are the appropriate UID and GID to apply here? I have a system user “galaxy” who starts Galaxy with “run.sh”. This user’s UID and GID are 581 and 582 respectively but I am not able to login for FTP transfer If I use Chrome and paste ftp://123.45.678.123” I get “unable to load webpage because server sent no data “error code ERR_EMPTY_RESPONSE If I paste ftp://123.45.678.123/ /path/to/file And press execute in my local Galaxy GUI I get a tool error” with no Std_Out and no Std_error So I cannot use FTP via ProFTPD 1.3.4d Server to upload files. How can I test postgresql authentication via Galaxy/proftpd to get at the problem? Starr ___ 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] Trouble setting up a local instance of Galaxy
Hello, I am a new user of Galaxy. I have a Galaxy instance running (sort of) on a local research cluster. I issued the command hg update stable” today and it retrieved no files. SO presume I am up-to-date on the stable release. I start the instance as a user named “galaxy”. Right now I am still running in “local” mode. I hope to migrate to DRMAA LSF eventually. I have tried to set up ProFTP to upload files but have not succeeded so I use Galaxy Web-upload. The upload was working nicely and I had added a couple of new tools and they were working with the uploaded files. Getting LSF/DRMAA to work was giving me fits and ultimately I deleted all my history files in an effort to start over. Presently, files being uploaded appear in history as say job 1 ( in a new history) The job status in the history panel of the web GUI changes from purple to yellow then then to red indicating some sort of error. There is no viewable error text captured, but I can click on the “eye” icon and see the first megabyte of the data (for tiny files I can see the entire content and it’s intact). In the Galaxy file system, however, these files appear but have a different number , say, dataset_399.dat On my system the uploaded files appear in /PATH/galaxy-dist/database/files/000 My first question is why is the data going into the “000” subdirectory and not one “owned’ by the user who is uploading? My second question is why is the dataset being labeled as dataset_399.dat and not dataset_001.dat? My third question is why do the uploaded files not appear as selectable options ( say I have paired-end fastq files and tool wants to have choices about filenames)? This problem is present for programs that seek one input file as well. I presume that Galaxy is confused because the numbering in history is not the same as the numbering in the file upload archive (e.g. /PATH/galaxy-dist/database/files/000 in my case) so my last question is how do I “reset” my system to get the dataset and history numbers to be the same? Here’s how I launch the Galaxy instance sh /shared/app/Galaxy/galaxy-dist/run.sh -v --daemon --pid-file=Nov6Localdaemon.pid.txt --log-file=Nov6Local1639daemon.log.txt Entering daemon mode Here are the last lines of the log Starting server in PID 26236. serving on 0.0.0.0:8089 view at http://127.0.0.1:8089 galaxy.tools.actions.upload_common DEBUG 2013-11-06 16:48:49,624 Changing ownership of /shared/app/Galaxy/galaxy-dist/database/tmp/upload_file_data_QZGHm4 with: /usr/bin/sudo -E scripts/external_chown_script.py /shared/app/Galaxy/galaxy-dist/database/tmp/upload_file_data_QZGHm4 hazards 502 galaxy.tools.actions.upload_common WARNING 2013-11-06 16:48:49,750 Changing ownership of uploaded file /shared/app/Galaxy/galaxy-dist/database/tmp/upload_file_data_QZGHm4 failed: sudo: no tty present and no askpass program specified galaxy.tools.actions.upload_common DEBUG 2013-11-06 16:48:49,751 Changing ownership of /shared/app/Galaxy/galaxy-dist/database/tmp/tmpEsyGfO with: /usr/bin/sudo -E scripts/external_chown_script.py /shared/app/Galaxy/galaxy-dist/database/tmp/tmpEsyGfO hazards 502 galaxy.tools.actions.upload_common WARNING 2013-11-06 16:48:49,775 Changing ownership of uploaded file /shared/app/Galaxy/galaxy-dist/database/tmp/tmpEsyGfO failed: sudo: no tty present and no askpass program specified galaxy.tools.actions.upload_common INFO 2013-11-06 16:48:49,805 tool upload1 created job id 170 galaxy.jobs DEBUG 2013-11-06 16:48:50,678 (170) Persisting job destination (destination id: local) galaxy.jobs.handler INFO 2013-11-06 16:48:50,698 (170) Job dispatched galaxy.jobs.runners.local DEBUG 2013-11-06 16:48:50,994 (170) executing: python /shared/app/Galaxy/galaxy-dist/tools/data_source/upload.py /depot/shared/app/Galaxy/galaxy-dist /shared/app/Galaxy/galaxy-dist/database/tmp/tmpTq22ot /shared/app/Galaxy/galaxy-dist/database/tmp/tmpEsyGfO 406:/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/170/dataset_406_files:/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/170/galaxy_dataset_406.dat galaxy.jobs DEBUG 2013-11-06 16:48:51,030 (170) Persisting job destination (destination id: local) galaxy.jobs.runners.local DEBUG 2013-11-06 16:48:53,335 execution finished: python /shared/app/Galaxy/galaxy-dist/tools/data_source/upload.py /depot/shared/app/Galaxy/galaxy-dist /shared/app/Galaxy/galaxy-dist/database/tmp/tmpTq22ot /shared/app/Galaxy/galaxy-dist/database/tmp/tmpEsyGfO 406:/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/170/dataset_406_files:/shared/app/Galaxy/galaxy-dist/database/job_working_directory/000/170/galaxy_dataset_406.dat galaxy.jobs.runners.local DEBUG 2013-11-06 16:48:53,463 executing external set_meta script for job 170: /depot/shared/app/Galaxy/galaxy-dist/set_metadata.sh /shared/app/Galaxy/galaxy-dist/database/files
