hjcVAGtb

1#
2# Galaxy is configured by default to be usable in a single-user development
3# environment.  To tune the application for a multi-user production
4# environment, see the documentation at:
5#
6#  http://usegalaxy.org/production
7#
8
9# Throughout this sample configuration file, except where stated otherwise,
10# uncommented values override the default if left unset, whereas commented
11# values are set to the default value.  Relative paths are relative to the root
12# Galaxy directory.
13#
14# Examples of many of these options are explained in more detail in the wiki:
15#
16#   https://wiki.galaxyproject.org/Admin/Config
17#
18# Config hackers are encouraged to check there before asking for help.
19
20# ---- HTTP Server ----------------------------------------------------------
21
22# Configuration of the internal HTTP server.
23
24[server:main]
25
26# The internal HTTP server to use.  Currently only Paste is provided.  This
27# option is required.
28use = egg:Paste#http
29
30# The port on which to listen.
31port = 8080
32
33# The address on which to listen.  By default, only listen to localhost (Galaxy
34# will not be accessible over the network).  Use '0.0.0.0' to listen on all
35# available network interfaces.
36host = 0.0.0.0
37
38# Use a threadpool for the web server instead of creating a thread for each
39# request.
40use_threadpool = True
41
42# Number of threads in the web server thread pool.
43#threadpool_workers = 10
44
45# Set the number of seconds a thread can work before you should kill it
46# (assuming it will never finish) to 3 hours.  Default is 600 (10 minutes).
47threadpool_kill_thread_limit = 10800
48
49# ---- Filters --------------------------------------------------------------
50
51# Filters sit between Galaxy and the HTTP server.
52
53# These filters are disabled by default.  They can be enabled with
54# 'filter-with' in the [app:main] section below.
55
56# Define the gzip filter.
57[filter:gzip]
58use = egg:Paste#gzip
59
60# Define the proxy-prefix filter.
61[filter:proxy-prefix]
62use = egg:PasteDeploy#prefix
63prefix = /galaxy
64
65# ---- Galaxy ---------------------------------------------------------------
66
67# Configuration of the Galaxy application.
68
69[app:main]
70
71# -- Application and filtering
72
73# The factory for the WSGI application.  This should not be changed.
74paste.app_factory = galaxy.web.buildapp:app_factory
75
76# If not running behind a proxy server, you may want to enable gzip compression
77# to decrease the size of data transferred over the network.  If using a proxy
78# server, please enable gzip compression there instead.
79#filter-with = gzip
80
81# If running behind a proxy server and Galaxy is served from a subdirectory,
82# enable the proxy-prefix filter and set the prefix in the
83# [filter:proxy-prefix] section above.
84#filter-with = proxy-prefix
85
86# If proxy-prefix is enabled and you're running more than one Galaxy instance
87# behind one hostname, you will want to set this to the same path as the prefix
88# in the filter above.  This value becomes the "path" attribute set in the
89# cookie so the cookies from each instance will not clobber each other.
90#cookie_path = None
91
92# -- Database
93
94# By default, Galaxy uses a SQLite database at 'database/universe.sqlite'.  You
95# may use a SQLAlchemy connection string to specify an external database
96# instead.  This string takes many options which are explained in detail in the
97# config file documentation.
98#database_connection = sqlite:///./database/universe.sqlite?isolation_level=IMMEDIATE
99
100# If the server logs errors about not having enough database pool connections,
101# you will want to increase these values, or consider running more Galaxy
102# processes.
103#database_engine_option_pool_size = 5
104#database_engine_option_max_overflow = 10
105
106# If using MySQL and the server logs the error "MySQL server has gone away",
107# you will want to set this to some positive value (7200 should work).
108#database_engine_option_pool_recycle = -1
109
110# If large database query results are causing memory or response time issues in
111# the Galaxy process, leave the result on the server instead.  This option is
112# only available for PostgreSQL and is highly recommended.
113#database_engine_option_server_side_cursors = False
114
115# Log all database transactions, can be useful for debugging and performance
116# profiling.  Logging is done via Python's 'logging' module under the qualname
117# 'galaxy.model.orm.logging_connection_proxy'
118#database_query_profiling_proxy = False
119
120# By default, Galaxy will use the same database to track user data and
121# tool shed install data.  There are many situations in which it is
122# valuable to separate these - for instance bootstrapping fresh Galaxy
123# instances with pretested installs.  The following option can be used to
124# separate the tool shed install database (all other options listed above
125# but prefixed with install_ are also available).
126#install_database_connection = sqlite:///./database/universe.sqlite?isolation_level=IMMEDIATE
127
128# -- Files and directories
129
130# Dataset files are stored in this directory.
131#file_path = database/files
132
133# Temporary files are stored in this directory.
134#new_file_path = database/tmp
135
136# Tool config files, defines what tools are available in Galaxy.
137# Tools can be locally developed or installed from Galaxy tool sheds.
138# (config/tool_conf.xml.sample will be used if left unset and
139# config/tool_conf.xml does not exist).
140#tool_config_file = config/tool_conf.xml,config/shed_tool_conf.xml
141
142# Enable / disable checking if any tools defined in the above non-shed
143# tool_config_files (i.e., tool_conf.xml) have been migrated from the Galaxy
144# code distribution to the Tool Shed.  This setting should generally be set to
145# False only for development Galaxy environments that are often rebuilt from
146# scratch where migrated tools do not need to be available in the Galaxy tool
147# panel.  If the following setting remains commented, the default setting will
148# be True.
149#check_migrate_tools = True
150
151# Tool config maintained by tool migration scripts.  If you use the migration
152# scripts to install tools that have been migrated to the tool shed upon a new
153# release, they will be added to this tool config file.
154#migrated_tools_config = config/migrated_tools_conf.xml
155
156# File that contains the XML section and tool tags from all tool panel config
157# files integrated into a single file that defines the tool panel layout.  This
158# file can be changed by the Galaxy administrator to alter the layout of the
159# tool panel.  If not present, Galaxy will create it.
160#integrated_tool_panel_config = integrated_tool_panel.xml
161
162# Default path to the directory containing the tools defined in tool_conf.xml.
163# Other tool config files must include the tool_path as an attribute in the
164# <toolbox> tag.
165#tool_path = tools
166
167# Path to the directory in which tool dependencies are placed.  This is used by
168# the tool shed to install dependencies and can also be used by administrators
169# to manually install or link to dependencies.  For details, see:
170#   https://wiki.galaxyproject.org/Admin/Config/ToolDependencies
171# If this option is not set to a valid path, installing tools with dependencies
172# from the Tool Shed will fail.
173#tool_dependency_dir = None
174
175# The dependency resolves config file specifies an ordering and options for how
176# Galaxy resolves tool dependencies (requirement tags in Tool XML). The default
177# ordering is to the use the tool shed for tools installed that way, use local
178# Galaxy packages, and then use conda if available.
179# See https://github.com/galaxyproject/galaxy/blob/dev/doc/source/admin/dependency_resolvers.rst
180# for more information on these options.
181#dependency_resolvers_config_file = config/dependency_resolvers_conf.xml
182
183# Following conda dependeny resolution options are experimental as of early
184# 2016. These will change the defaults for each conda resolver, but multiple
185# resolvers can be configured independently and these options overridden in
186# dependency_resolvers_config_file.
187#conda_prefix = <tool_dependency_dir>/_conda
188# Override the conda executable to use, it will default to the one on the
189# PATH (if available) and then to <conda_prefix>/bin/conda
190#conda_exec =
191# Pass debug flag to conda commands.
192#conda_debug = False
193# conda channels to enable by default (http://conda.pydata.org/docs/custom-channels.html)
194#conda_ensure_channels = r,bioconda,iuc
195# Set to True to instruct Galaxy to look for and install missing tool
196# dependencies before each job runs.
197#conda_auto_install = False
198# Set to True to instruct Galaxy to install conda from the web automatically
199# if it cannot find a local copy and conda_exec is not configured.
200#conda_auto_init = False
201
202# File containing the Galaxy Tool Sheds that should be made available to
203# install from in the admin interface (.sample used if default does not exist).
204#tool_sheds_config_file = config/tool_sheds_conf.xml
205
206# Set to True to enable monitoring of tools and tool directories
207# listed in any tool config file specified in tool_config_file option.
208# If changes are found, tools are automatically reloaded.  Watchdog (
209# https://pypi.python.org/pypi/watchdog ) must be installed and
210# available to Galaxy to use this option. Other options include 'auto'
211# which will attempt to watch tools if the watchdog library is available
212# but won't fail to load Galaxy if it is not and 'polling' which will use
213# a less efficient monitoring scheme that may work in wider range of scenarios
214# than the watchdog default.
215#watch_tools = False
216
217# Enable automatic polling of relative tool sheds to see if any updates
218# are available for installed repositories.  Ideally only one Galaxy
219# server process should be able to check for repository updates.  The
220# setting for hours_between_check should be an integer between 1 and 24.
221#enable_tool_shed_check = False
222#hours_between_check = 12
223
224# Enable use of an in-memory registry with bi-directional relationships between
225# repositories (i.e., in addition to lists of dependencies for a repository,
226# keep an in-memory registry of dependent items for each repository.
227#manage_dependency_relationships = False
228
229# XML config file that contains data table entries for the
230# ToolDataTableManager.  This file is manually # maintained by the Galaxy
231# administrator (.sample used if default does not exist).
232#tool_data_table_config_path = config/tool_data_table_conf.xml
233
234# XML config file that contains additional data table entries for the
235# ToolDataTableManager.  This file is automatically generated based on the
236# current installed tool shed repositories that contain valid
237# tool_data_table_conf.xml.sample files.  At the time of installation, these
238# entries are automatically added to the following file, which is parsed and
239# applied to the ToolDataTableManager at server start up.
240#shed_tool_data_table_config = config/shed_tool_data_table_conf.xml
241
242# Directory where data used by tools is located, see the samples in that
243# directory and the wiki for help:
244#   https://wiki.galaxyproject.org/Admin/DataIntegration
245#tool_data_path = tool-data
246
247# Directory where Tool Data Table related files will be placed
248# when installed from a ToolShed. Defaults to tool_data_path.
249#shed_tool_data_path = tool-data
250
251# File containing old-style genome builds
252#builds_file_path = tool-data/shared/ucsc/builds.txt
253
254# Directory where chrom len files are kept, currently mainly used by trackster
255#len_file_path = tool-data/shared/ucsc/chrom
256
257# Datatypes config file(s), defines what data (file) types are available in
258# Galaxy (.sample is used if default does not exist).  If a datatype appears in
259# multiple files, the last definition is used (though the first sniffer is used
260# so limit sniffer definitions to one file).
261#datatypes_config_file = config/datatypes_conf.xml
262
263# Disable the 'Auto-detect' option for file uploads
264#datatypes_disable_auto = False
265
266# Visualizations config directory: where to look for individual visualization
267# plugins.  The path is relative to the Galaxy root dir.  To use an absolute
268# path begin the path with '/'.  This is a comma separated list.
269# Defaults to "config/plugins/visualizations".
270#visualization_plugins_directory = config/plugins/visualizations
271
272# Interactive environment plugins root directory: where to look for interactive
273# environment plugins.  By default none will be loaded.  Set to
274# config/plugins/interactive_environments to load Galaxy's stock plugins
275# (currently just IPython).  These will require Docker to be configured and
276# have security considerations, so proceed with caution. The path is relative to the
277# Galaxy root dir.  To use an absolute path begin the path with '/'.  This is a comma
278# separated list.
279interactive_environment_plugins_directory = config/plugins/interactive_environments
280
281# Interactive tour directory: where to store interactive tour definition files.
282# Galaxy ships with several basic interface tours enabled, though a different
283# directory with custom tours can be specified here. The path is relative to the
284# Galaxy root dir.  To use an absolute path begin the path with '/'.  This is a comma
285# separated list.
286#tour_config_dir = config/plugins/tours
287
288# Each job is given a unique empty directory as its current working directory.
289# This option defines in what parent directory those directories will be
290# created.
291#job_working_directory = database/job_working_directory
292
293# If using a cluster, Galaxy will write job scripts and stdout/stderr to this
294# directory.
295#cluster_files_directory = database/pbs
296
297# Mako templates are compiled as needed and cached for reuse, this directory is
298# used for the cache
299#template_cache_path = database/compiled_templates
300
301# Set to false to disable various checks Galaxy will do to ensure it
302# can run job scripts before attempting to execute or submit them.
303#check_job_script_integrity = True
304# Number of checks to execute if check_job_script_integrity is enabled.
305#check_job_script_integrity_count = 35
306# Time to sleep between checks if check_job_script_integrity is enabled (in seconds).
307#check_job_script_integrity_sleep = .25
308
309
310# Set the default shell used by non-containerized jobs Galaxy-wide. This
311# defaults to bash for all jobs and can be overidden at the destination
312# level for heterogenous clusters. conda job resolution requires bash or zsh
313# so if this is switched to /bin/sh for instance - conda resolution
314# should be disabled. Containerized jobs always use /bin/sh - so more maximum
315# portability tool authors should assume generated commands run in sh.
316#default_job_shell = /bin/bash
317
318# Citation related caching.  Tool citations information maybe fetched from
319# external sources such as http://dx.doi.org/ by Galaxy - the following
320# parameters can be used to control the caching used to store this information.
321#citation_cache_type = file
322#citation_cache_data_dir = database/citations/data
323#citation_cache_lock_dir = database/citations/lock
324
325# External service types config file, defining what types of external_services
326# configurations are available in Galaxy (.sample is used if default does not
327# exist).
328#external_service_type_config_file = config/external_service_types_conf.xml
329
330# Path to the directory containing the external_service_types defined in the
331# config.
332#external_service_type_path = external_service_types
333
334# Tools with a number of outputs not known until runtime can write these
335# outputs to a directory for collection by Galaxy when the job is done.
336# Previously, this directory was new_file_path, but using one global directory
337# can cause performance problems, so using job_working_directory ('.' or cwd
338# when a job is run) is encouraged.  By default, both are checked to avoid
339# breaking existing tools.
340#collect_outputs_from = new_file_path,job_working_directory
341
342# -- Data Storage (Object Store)
343#
344# Configuration file for the object store
345# If this is set and exists, it overrides any other objectstore settings.
346# object_store_config_file = config/object_store_conf.xml
347
348
349# -- Mail and notification
350
351# Galaxy sends mail for various things: subscribing users to the mailing list
352# if they request it, password resets, notifications from the Galaxy Sample
353# Tracking system, reporting dataset errors, and sending activation emails.
354# To do this, it needs to send mail through an SMTP server, which you may
355# define here (host:port).
356# Galaxy will automatically try STARTTLS but will continue upon failure.
357#smtp_server = None
358
359# If your SMTP server requires a username and password, you can provide them
360# here (password in cleartext here, but if your server supports STARTTLS it
361# will be sent over the network encrypted).
362#smtp_username = None
363#smtp_password = None
364
365# If your SMTP server requires SSL from the beginning of the connection
366# smtp_ssl = False
367
368# On the user registration form, users may choose to join a mailing list. This
369# is the address used to subscribe to the list. Uncomment and leave empty if you
370# want to remove this option from the user registration form.
371#mailing_join_addr = galaxy-announce-join@bx.psu.edu
372
373# Datasets in an error state include a link to report the error.  Those reports
374# will be sent to this address.  Error reports are disabled if no address is
375# set.  Also this email is shown as a contact to user in case of Galaxy
376# misconfiguration and other events user may encounter.
377#error_email_to = None
378
379# Email address to use in the 'From' field when sending emails for
380# account activations, workflow step notifications and password resets.
381# We recommend using string in the following format:
382# Galaxy Project <galaxy-no-reply@example.com>
383# If not configured, '<galaxy-no-reply@HOSTNAME>' will be used.
384#email_from = None
385
386# URL of the support resource for the galaxy instance.  Used in activation
387# emails.
388#instance_resource_url = https://wiki.galaxyproject.org/
389
390# E-mail domains blacklist is used for filtering out users that are using
391# disposable email address during the registration.  If their address domain
392# matches any domain in the blacklist, they are refused the registration.
393#blacklist_file = config/disposable_email_blacklist.conf
394
395# Registration warning message is used to discourage people from registering
396# multiple accounts.  Applies mostly for the main Galaxy instance.
397# If no message specified the warning box will not be shown.
398#registration_warning_message = Please register only one account - we provide this service free of charge and have limited computational resources. Multi-accounts are tracked and will be subjected to account termination and data deletion.
399
400
401# -- Account activation
402
403# User account activation feature global flag.  If set to "False", the rest of
404# the Account activation configuration is ignored and user activation is
405# disabled (i.e. accounts are active since registration).
406# The activation is also not working in case the SMTP server is not defined.
407#user_activation_on = False
408
409# Activation grace period (in hours).  Activation is not forced (login is not
410# disabled) until grace period has passed.  Users under grace period can't run
411# jobs (see inactivity_box_content).  Default is 3.  Enter 0 to disable grace
412# period.
413# Users with OpenID logins have grace period forever.
414#activation_grace_period = 0
415
416# Used for warning box for inactive accounts (unable to run jobs).
417# In use only if activation_grace_period is set.
418#inactivity_box_content = Your account has not been activated yet.  Feel free to browse around and see what's available, but you won't be able to upload data or run jobs until you have verified your email address.
419
420
421
422# Galaxy Session Timeout
423# This provides a timeout (in minutes) after which a user will have to log back in.
424# A duration of 0 disables this feature.
425#session_duration = 0
426
427
428# -- Analytics
429
430# You can enter tracking code here to track visitor's behavior
431# through your Google Analytics account.  Example: UA-XXXXXXXX-Y
432#ga_code = None
433
434# -- Display sites
435
436# Galaxy can display data at various external browsers.  These options specify
437# which browsers should be available.  URLs and builds available at these
438# browsers are defined in the specifield files.
439
440# If use_remote_user = True, display application servers will be denied access
441# to Galaxy and so displaying datasets in these sites will fail.
442# display_servers contains a list of hostnames which should be allowed to
443# bypass security to display datasets.  Please be aware that there are security
444# implications if this is allowed.  More details (including required changes to
445# the proxy server config) are available in the Apache proxy documentation on
446# the wiki.
447#
448# The list of servers in this sample config are for the UCSC Main, Test and
449# Archaea browsers, but the default if left commented is to not allow any
450# display sites to bypass security (you must uncomment the line below to allow
451# them).
452#display_servers = hgw1.cse.ucsc.edu,hgw2.cse.ucsc.edu,hgw3.cse.ucsc.edu,hgw4.cse.ucsc.edu,hgw5.cse.ucsc.edu,hgw6.cse.ucsc.edu,hgw7.cse.ucsc.edu,hgw8.cse.ucsc.edu,lowepub.cse.ucsc.edu
453
454# To disable the old-style display applications that are hardcoded into
455# datatype classes, set enable_old_display_applications = False.
456# This may be desirable due to using the new-style, XML-defined, display
457# applications that have been defined for many of the datatypes that have the
458# old-style.
459# There is also a potential security concern with the old-style applications,
460# where a malicious party could provide a link that appears to reference the
461# Galaxy server, but contains a redirect to a third-party server, tricking a
462# Galaxy user to access said site.
463#enable_old_display_applications = True
464
465# -- Next gen LIMS interface on top of existing Galaxy Sample/Request
466# management code.
467
468use_nglims = False
469nglims_config_file = tool-data/nglims.yaml
470
471# -- UI Localization
472
473# Show a message box under the masthead.
474#message_box_visible = False
475#message_box_content = None
476#message_box_class = info
477
478# Append "/{brand}" to the "Galaxy" text in the masthead.
479#brand = None
480
481# Format string used when showing date and time information.
482# The string may contain:
483# - the directives used by Python time.strftime() function (see
484#   https://docs.python.org/2/library/time.html#time.strftime ),
485# - $locale (complete format string for the server locale),
486# - $iso8601 (complete format string as specified by ISO 8601 international
487#   standard).
488# pretty_datetime_format = $locale (UTC)
489
490# URL (with schema http/https) of the Galaxy instance as accessible within your
491# local network - if specified used as a default by pulsar file staging and
492# IPython Docker container for communicating back with Galaxy via the API.
493#galaxy_infrastructure_url = http://localhost:8080
494
495# If the above URL cannot be determined ahead of time in dynamic environments
496# but the port which should be used to access Galaxy can be - this should be
497# set to prevent Galaxy from having to guess.  For example if Galaxy is sitting
498# behind a proxy with REMOTE_USER enabled - infrastructure shouldn't talk to
499# Python processes directly and this should be set to 80 or 443, etc... If
500# unset this file will be read for a server block defining a port corresponding
501# to the webapp.
502#galaxy_infrastructure_web_port = 8080
503
504# The URL of the page to display in Galaxy's middle pane when loaded.  This can
505# be an absolute or relative URL.
506#welcome_url = /static/welcome.html
507
508# The URL linked by the "Galaxy/brand" text.
509#logo_url = /
510
511# The URL linked by the "Wiki" link in the "Help" menu.
512#wiki_url = https://wiki.galaxyproject.org/
513
514# The URL linked by the "Support" link in the "Help" menu.
515#support_url = https://wiki.galaxyproject.org/Support
516
517# The URL linked by the "How to Cite Galaxy" link in the "Help" menu.
518#citation_url = https://wiki.galaxyproject.org/CitingGalaxy
519
520#The URL linked by the "Search" link in the "Help" menu.
521#search_url = http://galaxyproject.org/search/usegalaxy/
522
523#The URL linked by the "Mailing Lists" link in the "Help" menu.
524#mailing_lists_url = https://wiki.galaxyproject.org/MailingLists
525
526#The URL linked by the "Videos" link in the "Help" menu.
527#screencasts_url = https://vimeo.com/galaxyproject
528
529# The URL linked by the "Terms and Conditions" link in the "Help" menu, as well
530# as on the user registration and login forms and in the activation emails.
531#terms_url = None
532
533# The URL linked by the "Galaxy Q&A" link in the "Help" menu
534# The Galaxy Q&A site is under development; when the site is done, this URL
535# will be set and uncommented.
536#qa_url =
537
538# Serve static content, which must be enabled if you're not serving it via a
539# proxy server.  These options should be self explanatory and so are not
540# documented individually.  You can use these paths (or ones in the proxy
541# server) to point to your own styles.
542#static_enabled = True
543#static_cache_time = 360
544#static_dir = static/
545#static_images_dir = static/images
546#static_favicon_dir = static/favicon.ico
547#static_scripts_dir = static/scripts/
548#static_style_dir = static/june_2007_style/blue
549#static_robots_txt = static/robots.txt
550
551# Incremental Display Options
552
553#display_chunk_size = 65536
554
555# -- Advanced proxy features
556
557# For help on configuring the Advanced proxy features, see:
558# http://usegalaxy.org/production
559
560# Apache can handle file downloads (Galaxy-to-user) via mod_xsendfile.  Set
561# this to True to inform Galaxy that mod_xsendfile is enabled upstream.
562#apache_xsendfile = False
563
564# The same download handling can be done by nginx using X-Accel-Redirect.  This
565# should be set to the path defined in the nginx config as an internal redirect
566# with access to Galaxy's data files (see documentation linked above).
567#nginx_x_accel_redirect_base = False
568
569# nginx can make use of mod_zip to create zip files containing multiple library
570# files.  If using X-Accel-Redirect, this can be the same value as that option.
571#nginx_x_archive_files_base = False
572
573# If using compression in the upstream proxy server, use this option to disable
574# gzipping of library .tar.gz and .zip archives, since the proxy server will do
575# it faster on the fly.
576#upstream_gzip = False
577
578# The following default adds a header to web request responses that
579# will cause modern web browsers to not allow Galaxy to be embedded in
580# the frames of web applications hosted at other hosts - this can help
581# prevent a class of attack called clickjacking
582# (https://www.owasp.org/index.php/Clickjacking).  If you configure a
583# proxy in front of Galaxy - please ensure this header remains intact
584# to protect your users.  Uncomment and leave empty to not set the
585# `X-Frame-Options` header.
586#x_frame_options = SAMEORIGIN
587
588# nginx can also handle file uploads (user-to-Galaxy) via nginx_upload_module.
589# Configuration for this is complex and explained in detail in the
590# documentation linked above.  The upload store is a temporary directory in
591# which files uploaded by the upload module will be placed.
592#nginx_upload_store = False
593
594# This value overrides the action set on the file upload form, e.g. the web
595# path where the nginx_upload_module has been configured to intercept upload
596# requests.
597#nginx_upload_path = False
598
599# Galaxy can also use nginx_upload_module to receive files staged out upon job
600# completion by remote job runners (i.e. Pulsar) that initiate staging
601# operations on the remote end.  See the Galaxy nginx documentation for the
602# corresponding nginx configuration.
603#nginx_upload_job_files_store = False
604#nginx_upload_job_files_path = False
605
606# Have Galaxy manage dynamic proxy component for routing requests to other
607# services based on Galaxy's session cookie.  It will attempt to do this by
608# default though you do need to install node+npm and do an npm install from
609# `lib/galaxy/web/proxy/js`.  It is generally more robust to configure this
610# externally managing it however Galaxy is managed.  If True Galaxy will only
611# launch the proxy if it is actually going to be used (e.g. for IPython).
612dynamic_proxy_manage=True
613
614# As of 16.04 Galaxy supports multiple proxy types. The original NodeJS
615# implementation, alongside a new Golang single-binary-no-dependencies
616# version. Valid values are (node, golang)
617dynamic_proxy=node
618#
619# The NodeJS dynamic proxy can use an SQLite database or a JSON file for IPC,
620# set that here.
621dynamic_proxy_session_map=database/session_map.sqlite
622
623# Set the port and IP for the the dynamic proxy to bind to, this must match
624# the external configuration if dynamic_proxy_manage is False.
625dynamic_proxy_bind_port=8800
626dynamic_proxy_bind_ip=172.17.0.1
627
628# Enable verbose debugging of Galaxy-managed dynamic proxy.
629dynamic_proxy_debug=True
630
631# The dynamic proxy is proxied by an external proxy (e.g. apache frontend to
632# nodejs to wrap connections in SSL).
633#dynamic_proxy_external_proxy=True
634
635# Additionally, when the dynamic proxy is proxied by an upstream server, you'll
636# want to specify a prefixed URL so both Galaxy and the proxy reside under the
637# same path that your cookies are under. This will result in a url like
638# https://FQDN/galaxy-prefix/gie_proxy for proxying
639#dynamic_proxy_prefix=gie_proxy
640
641# The Golang proxy also manages the docker containers more closely than the
642# NodeJS proxy, so is able to expose more container management related options
643
644# This attribute governs the minimum length of time between consecutive HTTP/WS
645# requests through the proxy, before the proxy considers a container as being
646# inactive and kills it.
647#dynamic_proxy_golang_noaccess = 60
648
649# In order to kill containers, the golang proxy has to check at some interval
650# for possibly dead containers. This is exposed as a configurable parameter,
651# but the default value is probably fine.
652#dynamic_proxy_golang_clean_interval = 10
653
654# The golang proxy needs to know how to talk to your docker daemon. Currently
655# TLS is not supported, that will come in an update.
656#dynamic_proxy_golang_docker_address = unix:///var/run/docker.sock
657
658# The golang proxy uses a RESTful HTTP API for communication with Galaxy
659# instead of a JSON or SQLite file for IPC. If you do not specify this, it will
660# be set randomly for you. You should set this if you are managing the proxy
661# manually.
662#dynamic_proxy_golang_api_key = None
663
664# -- Logging and Debugging
665
666# If True, Galaxy will attempt to configure a simple root logger if a
667# "loggers" section does not appear in this configuration file.
668#auto_configure_logging = True
669
670# Verbosity of console log messages.  Acceptable values can be found here:
671# https://docs.python.org/2/library/logging.html#logging-levels
672#log_level = DEBUG
673
674# Print database operations to the server log (warning, quite verbose!).
675#database_engine_option_echo = False
676
677# Print database pool operations to the server log (warning, quite verbose!).
678#database_engine_option_echo_pool = False
679
680# Turn on logging of application events and some user events to the database.
681#log_events = True
682
683# Turn on logging of user actions to the database.  Actions currently logged
684# are grid views, tool searches, and use of "recently" used tools menu.  The
685# log_events and log_actions functionality will eventually be merged.
686#log_actions = True
687
688
689# Fluentd configuration.  Various events can be logged to the fluentd instance
690# configured below by enabling fluent_log.
691#fluent_log = False
692#fluent_host = localhost
693#fluent_port = 24224
694
695# Sanitize all HTML tool output.  By default, all tool output served as
696# 'text/html' will be sanitized thoroughly.  This can be disabled if you have
697# special tools that require unaltered output.  WARNING: disabling this does
698# make the Galaxy instance susceptible to XSS attacks initiated by your users.
699#sanitize_all_html = True
700
701# Whitelist sanitization file.
702# Datasets created by tools listed in this file are trusted and will not have
703# their HTML sanitized on display.  This can be manually edited or manipulated
704# through the Admin control panel -- see "Manage Display Whitelist"
705#sanitize_whitelist_file = config/sanitize_whitelist.txt
706
707# By default Galaxy will serve non-HTML tool output that may potentially
708# contain browser executable JavaScript content as plain text.  This will for
709# instance cause SVG datasets to not render properly and so may be disabled
710# by setting the following option to True.
711#serve_xss_vulnerable_mimetypes = False
712
713# Return a Access-Control-Allow-Origin response header that matches the Origin
714# header of the request if that Origin hostname matches one of the strings or
715# regular expressions listed here. This is a comma separated list of hostname
716# strings or regular expressions beginning and ending with /.
717# E.g. mysite.com,google.com,usegalaxy.org,/^[\w\.]*example\.com/
718# See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
719#allowed_origin_hostnames = None
720
721# Set the following to True to use IPython nbconvert to build HTML from IPython
722# notebooks in Galaxy histories.  This process may allow users to execute
723# arbitrary code or serve arbitrary HTML.  If enabled, IPython must be
724# available and on Galaxy's PATH, to do this run
725# `pip install jinja2 pygments ipython` in Galaxy's virtualenv.
726#trust_ipython_notebook_conversion = False
727
728# Debug enables access to various config options useful for development and
729# debugging: use_lint, use_profile, use_printdebug and use_interactive.  It
730# also causes the files used by PBS/SGE (submission script, output, and error)
731# to remain on disk after the job is complete.
732#debug = False
733
734# Check for WSGI compliance.
735#use_lint = False
736
737# Run the Python profiler on each request.
738#use_profile = False
739
740# Intercept print statements and show them on the returned page.
741#use_printdebug = True
742
743# Enable live debugging in your browser.  This should NEVER be enabled on a
744# public site.  Enabled in the sample config for development.
745use_interactive = True
746
747# Write thread status periodically to 'heartbeat.log',  (careful, uses disk
748# space rapidly!).  Useful to determine why your processes may be consuming a
749# lot of CPU.
750#use_heartbeat = False
751
752# Control the period (in seconds) between dumps. Use -1 to disable. Regardless
753# of this setting, if use_heartbeat is enabled, you can send a Galaxy process
754# (unless running with uWSGI) SIGUSR1 (`kill -USR1`) to force a dump.
755#heartbeat_interval = 20
756
757# Heartbeat log filename. Can accept the template variables {server_name} and
758# {pid}
759#heartbeat_log = heartbeat_{server_name}.log
760
761# Log to Sentry
762# Sentry is an open source logging and error aggregation platform.  Setting
763# sentry_dsn will enable the Sentry middleware and errors will be sent to the
764# indicated sentry instance.  This connection string is available in your
765# sentry instance under <project_name> -> Settings -> API Keys.
766#sentry_dsn = None
767
768# Log to statsd
769# Statsd is an external statistics aggregator (https://github.com/etsy/statsd)
770# Enabling the following options will cause galaxy to log request timing and
771# other statistics to the configured statsd instance.  The statsd_prefix is
772# useful if you are running multiple Galaxy instances and want to segment
773# statistics between them within the same aggregator.
774#statsd_host=
775#statsd_port=8125
776#statsd_prefix=galaxy
777
778# -- Data Libraries
779
780# These library upload options are described in much more detail in the wiki:
781#   https://wiki.galaxyproject.org/Admin/DataLibraries/UploadingLibraryFiles
782
783# Add an option to the library upload form which allows administrators to
784# upload a directory of files.
785#library_import_dir = None
786
787# Add an option to the library upload form which allows authorized
788# non-administrators to upload a directory of files.  The configured directory
789# must contain sub-directories named the same as the non-admin user's Galaxy
790# login ( email ).  The non-admin user is restricted to uploading files or
791# sub-directories of files contained in their directory.
792#user_library_import_dir = None
793
794# Add an option to the admin library upload tool allowing admins to paste
795# filesystem paths to files and directories in a box, and these paths will be
796# added to a library.  Set to True to enable.  Please note the security
797# implication that this will give Galaxy Admins access to anything your Galaxy
798# user has access to.
799#allow_library_path_paste = False
800
801# Users may choose to download multiple files from a library in an archive.  By
802# default, Galaxy allows users to select from a few different archive formats
803# if testing shows that Galaxy is able to create files using these formats.
804# Specific formats can be disabled with this option, separate more than one
805# format with commas.  Available formats are currently 'zip', 'gz', and 'bz2'.
806#disable_library_comptypes =
807
808# Some sequencer integration features in beta allow you to automatically
809# transfer datasets.  This is done using a lightweight transfer manager which
810# runs outside of Galaxy (but is spawned by it automatically).  Galaxy will
811# communicate with this manager over the port specified here.
812#transfer_manager_port = 8163
813
814# Search data libraries with whoosh
815#enable_whoosh_library_search = True
816# Whoosh indexes are stored in this directory.
817#whoosh_index_dir = database/whoosh_indexes
818
819# Search data libraries with lucene
820#enable_lucene_library_search = False
821# maximum file size to index for searching, in MB
822#fulltext_max_size = 500
823#fulltext_noindex_filetypes = bam,sam,wig,bigwig,fasta,fastq,fastqsolexa,fastqillumina,fastqsanger
824# base URL of server providing search functionality using lucene
825#fulltext_url = http://localhost:8081
826
827# -- Toolbox Search
828
829# The following boosts are used to customize this instance's toolbox search.
830# The higher the boost, the more importance the scoring algorithm gives to the
831# given field.  Section refers to the tool group in the tool panel.  Rest of
832# the fields are tool's attributes.
833# tool_name_boost = 9
834# tool_section_boost = 3
835# tool_description_boost = 2
836# tool_label_boost = 1
837# tool_stub_boost = 5
838# tool_help_boost = 0.5
839
840# Limits the number of results in toolbox search.  Can be used to tweak how many
841# results will appear.
842# tool_search_limit = 20
843
844# -- Users and Security
845
846# Galaxy encodes various internal values when these values will be output in
847# some format (for example, in a URL or cookie).  You should set a key to be
848# used by the algorithm that encodes and decodes these values.  It can be any
849# string.  If left unchanged, anyone could construct a cookie that would grant
850# them access to others' sessions.
851# One simple way to generate a value for this is with the shell command:
852#   python -c 'import time; print time.time()' | md5sum | cut -f 1 -d ' '
853#id_secret = USING THE DEFAULT IS NOT SECURE!
854
855# User authentication can be delegated to an upstream proxy server (usually
856# Apache).  The upstream proxy should set a REMOTE_USER header in the request.
857# Enabling remote user disables regular logins.  For more information, see:
858#   https://wiki.galaxyproject.org/Admin/Config/ApacheProxy
859#use_remote_user = False
860
861# If use_remote_user is enabled and your external authentication
862# method just returns bare usernames, set a default mail domain to be appended
863# to usernames, to become your Galaxy usernames (email addresses).
864#remote_user_maildomain = None
865
866# If use_remote_user is enabled, the header that the upstream proxy provides
867# the remote username in defaults to HTTP_REMOTE_USER (the 'HTTP_' is prepended
868# by WSGI).  This option allows you to change the header.  Note, you still need
869# to prepend 'HTTP_' to the header in this option, but your proxy server should
870# *not* include 'HTTP_' at the beginning of the header name.
871#remote_user_header = HTTP_REMOTE_USER
872
873# If use_remote_user is enabled, anyone who can log in to the Galaxy host may
874# impersonate any other user by simply sending the appropriate header.  Thus a
875# secret shared between the upstream proxy server, and Galaxy is required.
876# If anyone other than the Galaxy user is using the server, then apache/nginx
877# should pass a value in the header 'GX_SECRET' that is identical to the one
878# below.
879#remote_user_secret = USING THE DEFAULT IS NOT SECURE!
880
881# If use_remote_user is enabled, you can set this to a URL that will log your
882# users out.
883#remote_user_logout_href = None
884
885# If your proxy and/or authentication source does not normalize e-mail
886# addresses or user names being passed to Galaxy - set the following option
887# to True to force these to lower case.
888#normalize_remote_user_email = False
889
890# If an e-mail address is specified here, it will hijack remote user mechanics
891# (``use_remote_user``) and have the webapp inject a single fixed user. This
892# has the effect of turning Galaxy into a single user application with no
893# login or external proxy required. Such applications should not be exposed to
894# the world.
895#single_user =
896
897# Administrative users - set this to a comma-separated list of valid Galaxy
898# users (email addresses).  These users will have access to the Admin section
899# of the server, and will have access to create users, groups, roles,
900# libraries, and more.  For more information, see:
901#   https://wiki.galaxyproject.org/Admin/Interface
902#admin_users = None
903
904# Force everyone to log in (disable anonymous access).
905#require_login = False
906
907# Show the site's welcome page (see welcome_url) alongside the login page
908# (even if require_login is True)
909#show_welcome_with_login = False
910
911# Allow unregistered users to create new accounts (otherwise, they will have to
912# be created by an admin).
913#allow_user_creation = True
914
915# Allow administrators to delete accounts.
916#allow_user_deletion = False
917
918# Allow administrators to log in as other users (useful for debugging)
919#allow_user_impersonation = False
920
921# Allow users to remove their datasets from disk immediately (otherwise,
922# datasets will be removed after a time period specified by an administrator in
923# the cleanup scripts run via cron)
924#allow_user_dataset_purge = False
925
926# By default, users' data will be public, but setting this to True will cause
927# it to be private.  Does not affect existing users and data, only ones created
928# after this option is set.  Users may still change their default back to
929# public.
930#new_user_dataset_access_role_default_private = False
931
932# Expose user list.  Setting this to True will expose the user list to
933# authenticated users.  This makes sharing datasets in smaller galaxy instances
934# much easier as they can type a name/email and have the correct user show up.
935# This makes less sense on large public Galaxy instances where that data
936# shouldn't be exposed.  For semi-public Galaxies, it may make sense to expose
937# just the username and not email, or vice versa.
938#expose_user_name = False
939#expose_user_email = False
940
941# -- Beta features
942# Enable new run workflow form
943#run_workflow_toolform_upgrade = False
944
945# Enable Galaxy to communicate directly with a sequencer
946#enable_sequencer_communication = False
947
948# Separate tool command from rest of job script so tool dependencies
949# don't interfer with metadata generation.
950# Despite the name, this feature is enabled by default
951# in 16.01 and the option will go away in the future.
952#enable_beta_tool_command_isolation = True
953
954# Enable the new interface for installing tools from Tool Shed
955# via the API. Admin menu will list both if enabled.
956#enable_beta_ts_api_install = False
957
958
959# Set the following to a number of threads greater than 1 to spawn
960# a Python task queue for dealing with large tool submissions (either
961# through the tool form or as part of an individual workflow step across
962# large collection). The size of a "large" tool request is controlled by
963# the second parameter below and defaults to 10. This affects workflow
964# scheduling and web processes, not job handlers.
965#tool_submission_burst_threads = 1
966#tool_submission_burst_at = 10
967
968# Enable beta workflow modules that should not yet be considered part of Galaxy's
969# stable API.
970#enable_beta_workflow_modules = False
971
972# Force usage of Galaxy's beta workflow scheduler under certain circumstances -
973# this workflow scheduling forces Galaxy to schedule workflows in the background
974# so initial submission of the workflows is signficantly sped up. This does
975# however force the user to refresh their history manually to see newly scheduled
976# steps (for "normal" workflows - steps are still scheduled far in advance of
977# them being queued and scheduling here doesn't refer to actual cluster job
978# scheduling).
979# Workflows containing more than the specified number of steps will always use
980# the Galaxy's beta workflow scheduling.
981#force_beta_workflow_scheduled_min_steps=250
982# Switch to using Galaxy's beta workflow scheduling for all workflows involving
983# ccollections.
984#force_beta_workflow_scheduled_for_collections=False
985
986# Enable authentication via OpenID.  Allows users to log in to their Galaxy
987# account by authenticating with an OpenID provider.
988#enable_openid = False
989# .sample used if default does not exist
990#openid_config_file = config/openid_conf.xml
991#openid_consumer_cache_path = database/openid_consumer_cache
992
993# XML config file that allows the use of different authentication providers
994# (e.g. LDAP) instead or in addition to local authentication (.sample is used
995# if default does not exist).
996#auth_config_file = config/auth_conf.xml
997
998# Optional list of email addresses of API users who can make calls on behalf of
999# other users.
1000#api_allow_run_as = None
1001
1002# Master key that allows many API admin actions to be used without actually
1003# having a defined admin user in the database/config.  Only set this if you
1004# need to bootstrap Galaxy, you probably do not want to set this on public
1005# servers.
1006#master_api_key = changethis
1007
1008# Enable tool tags (associating tools with tags).  This has its own option
1009# since its implementation has a few performance implications on startup for
1010# large servers.
1011#enable_tool_tags = False
1012
1013# Enable a feature when running workflows.  When enabled, default datasets
1014# are selected for "Set at Runtime" inputs from the history such that the
1015# same input will not be selected twice, unless there are more inputs than
1016# compatible datasets in the history.
1017# When False, the most recently added compatible item in the history will
1018# be used for each "Set at Runtime" input, independent of others in the Workflow
1019#enable_unique_workflow_defaults = False
1020
1021# The URL to the myExperiment instance being used (omit scheme but include port)
1022#myexperiment_url = www.myexperiment.org:80
1023
1024# Enable Galaxy's "Upload via FTP" interface.  You'll need to install and
1025# configure an FTP server (we've used ProFTPd since it can use Galaxy's
1026# database for authentication) and set the following two options.
1027
1028# This should point to a directory containing subdirectories matching users'
1029# identifier (defaults to e-mail), where Galaxy will look for files.
1030#ftp_upload_dir = None
1031
1032# This should be the hostname of your FTP server, which will be provided to
1033# users in the help text.
1034#ftp_upload_site = None
1035
1036# User attribute to use as subdirectory in calculating default ftp_upload_dir
1037# pattern. By default this will be email so a user's FTP upload directory will be
1038# ${ftp_upload_dir}/${user.email}. Can set this to other attributes such as id or
1039# username though.
1040#ftp_upload_dir_identifier = email
1041
1042# Python string template used to determine an FTP upload directory for a
1043# particular user.
1044#ftp_upload_dir_template = ${ftp_upload_dir}/${ftp_upload_dir_identifier}
1045
1046# This should be set to False to prevent Galaxy from deleting uploaded FTP files
1047# as it imports them.
1048#ftp_upload_purge = True
1049
1050# Enable enforcement of quotas.  Quotas can be set from the Admin interface.
1051#enable_quotas = False
1052
1053# This option allows users to see the full path of datasets via the "View
1054# Details" option in the history.  Administrators can always see this.
1055#expose_dataset_path = False
1056
1057# Data manager configuration options
1058# Allow non-admin users to view available Data Manager options.
1059#enable_data_manager_user_view = False
1060# File where Data Managers are configured (.sample used if default does not
1061# exist).
1062#data_manager_config_file = config/data_manager_conf.xml
1063# File where Tool Shed based Data Managers are configured.
1064#shed_data_manager_config_file = config/shed_data_manager_conf.xml
1065# Directory to store Data Manager based tool-data; defaults to tool_data_path.
1066#galaxy_data_manager_data_path = tool-data
1067
1068# -- Job Execution
1069
1070# To increase performance of job execution and the web interface, you can
1071# separate Galaxy into multiple processes.  There are more than one way to do
1072# this, and they are explained in detail in the documentation:
1073#
1074#   https://wiki.galaxyproject.org/Admin/Config/Performance/Scaling
1075
1076# By default, Galaxy manages and executes jobs from within a single process and
1077# notifies itself of new jobs via in-memory queues.  Jobs are run locally on
1078# the system on which Galaxy is started.  Advanced job running capabilities can
1079# be configured through the job configuration file.
1080#job_config_file = config/job_conf.xml
1081
1082# In multiprocess configurations, notification between processes about new jobs
1083# must be done via the database.  In single process configurations, this can be
1084# done in memory, which is a bit quicker.
1085#track_jobs_in_database = True
1086
1087# This enables splitting of jobs into tasks, if specified by the particular tool
1088# config.
1089# This is a new feature and not recommended for production servers yet.
1090#use_tasked_jobs = False
1091#local_task_queue_workers = 2
1092
1093# Enable job recovery (if Galaxy is restarted while cluster jobs are running,
1094# it can "recover" them when it starts).  This is not safe to use if you are
1095# running more than one Galaxy server using the same database.
1096#enable_job_recovery = True
1097
1098# Although it is fairly reliable, setting metadata can occasionally fail.  In
1099# these instances, you can choose to retry setting it internally or leave it in
1100# a failed state (since retrying internally may cause the Galaxy process to be
1101# unresponsive).  If this option is set to False, the user will be given the
1102# option to retry externally, or set metadata manually (when possible).
1103#retry_metadata_internally = True
1104
1105# Very large metadata values can cause Galaxy crashes.  This will allow
1106# limiting the maximum metadata key size (in bytes used in memory, not the end
1107# result database value size) Galaxy will attempt to save with a dataset.  Use
1108# 0 to disable this feature.  The default is 5MB, but as low as 1MB seems to be
1109# a reasonable size.
1110#max_metadata_value_size = 5242880
1111
1112# If (for example) you run on a cluster and your datasets (by default,
1113# database/files/) are mounted read-only, this option will override tool output
1114# paths to write outputs to the working directory instead, and the job manager
1115# will move the outputs to their proper place in the dataset directory on the
1116# Galaxy server after the job completes.
1117#outputs_to_working_directory = False
1118
1119# If your network filesystem's caching prevents the Galaxy server from seeing
1120# the job's stdout and stderr files when it completes, you can retry reading
1121# these files.  The job runner will retry the number of times specified below,
1122# waiting 1 second between tries.  For NFS, you may want to try the -noac mount
1123# option (Linux) or -actimeo=0 (Solaris).
1124#retry_job_output_collection = 0
1125
1126# Clean up various bits of jobs left on the filesystem after completion.  These
1127# bits include the job working directory, external metadata temporary files,
1128# and DRM stdout and stderr files (if using a DRM).  Possible values are:
1129# always, onsuccess, never
1130#cleanup_job = always
1131
1132# For sites where all users in Galaxy match users on the system on which Galaxy
1133# runs, the DRMAA job runner can be configured to submit jobs to the DRM as the
1134# actual user instead of as the user running the Galaxy server process.  For
1135# details on these options, see the documentation at:
1136#
1137# https://wiki.galaxyproject.org/Admin/Config/Performance/Cluster
1138#
1139#drmaa_external_runjob_script = scripts/drmaa_external_runner.py
1140#drmaa_external_killjob_script = scripts/drmaa_external_killer.py
1141#external_chown_script = scripts/external_chown_script.py
1142
1143# File to source to set up the environment when running jobs.  By default, the
1144# environment in which the Galaxy server starts is used when running jobs
1145# locally, and the environment set up per the DRM's submission method and
1146# policy is used when running jobs on a cluster (try testing with `qsub` on the
1147# command line).  environment_setup_file can be set to the path of a file on
1148# the cluster that should be sourced by the user to set up the environment
1149# prior to running tools.  This can be especially useful for running jobs as
1150# the actual user, to remove the need to configure each user's environment
1151# individually.
1152#environment_setup_file = None
1153
1154# Optional file containing job resource data entry fields definition.
1155# These fields will be presented to users in the tool forms and allow them to
1156# overwrite default job resources such as number of processors, memory and
1157# walltime.
1158#job_resource_params_file = config/job_resource_params_conf.xml
1159
1160# If using job concurrency limits (configured in job_config_file), several
1161# extra database queries must be performed to determine the number of jobs a
1162# user has dispatched to a given destination.  By default, these queries will
1163# happen for every job that is waiting to run, but if cache_user_job_count is
1164# set to True, it will only happen once per iteration of the handler queue.
1165# Although better for performance due to reduced queries, the tradeoff is a
1166# greater possibility that jobs will be dispatched past the configured limits
1167# if running many handlers.
1168#cache_user_job_count = False
1169
1170# ToolBox filtering
1171
1172# Modules from lib/galaxy/tools/toolbox/filters/ can be specified in
1173# the following lines.  tool_* filters will be applied for all users
1174# and can not be changed by them.  user_tool_* filters will be shown
1175# under user preferences and can be toogled on and off by
1176# runtime.  Example shown below are not real defaults (no custom
1177# filters applied by defualt) but can be enabled with by renaming the
1178# example.py.sample in the filters directory to example.py.
1179
1180#tool_filters =
1181#tool_label_filters =
1182#tool_section_filters =
1183#user_tool_filters = examples:restrict_upload_to_admins, examples:restrict_encode
1184#user_tool_section_filters = examples:restrict_text
1185#user_tool_label_filters = examples:restrict_upload_to_admins, examples:restrict_encode
1186
1187# The base modules that are searched for modules as described above
1188# can be modified and modules external to Galaxy can be searched by
1189# modifying the following option.
1190#toolbox_filter_base_modules = galaxy.tools.toolbox.filters,galaxy.tools.filters
1191
1192# Galaxy Application Internal Message Queue
1193
1194# Galaxy uses AMQP internally TODO more documentation on what for.
1195# For examples, see http://ask.github.io/kombu/userguide/connections.html
1196#
1197# Without specifying anything here, galaxy will first attempt to use your
1198# specified database_connection above.  If that's not specified either, Galaxy
1199# will automatically create and use a separate sqlite database located in your
1200# <galaxy>/database folder (indicated in the commented out line below).
1201
1202#amqp_internal_connection = sqlalchemy+sqlite:///./database/control.sqlite?isolation_level=IMMEDIATE
1203
1204
1205
1206# ---- Galaxy External Message Queue -------------------------------------------------
1207
1208# Galaxy uses Advanced Message Queuing Protocol (AMQP) to receive messages from
1209# external sources like barcode scanners.  Galaxy has been tested against
1210# RabbitMQ AMQP implementation.  For Galaxy to receive messages from a message
1211# queue, the RabbitMQ server has to be set up with a user account and other
1212# parameters listed below.  The 'host' and 'port' fields should point to where
1213# the RabbitMQ server is running.
1214
1215[galaxy_amqp]
1216
1217#host = 127.0.0.1
1218#port = 5672
1219#userid = galaxy
1220#password = galaxy
1221#virtual_host = galaxy_messaging_engine
1222#queue = galaxy_queue
1223#exchange = galaxy_exchange
1224#routing_key = bar_code_scanner
1225#rabbitmqctl_path = /path/to/rabbitmqctl