mirror of
https://github.com/galaxyproject/galaxy.git
synced 2026-09-21 13:50:20 +08:00
Update newer deployer config docs for switch to YAML config.
This commit is contained in:
John Chilton
+10
-10
@@ -53,20 +53,20 @@ galaxy_user@node1%
|
||||
```
|
||||
|
||||
|
||||
If your cluster nodes have Internet access (NAT is okay) and you want to run the data source tools (upload, ucsc, etc.) on the cluster (doing so is highly recommended), set `new_file_path` in `galaxy.ini` to a directory somewhere in your shared filesystem:
|
||||
If your cluster nodes have Internet access (NAT is okay) and you want to run the data source tools (upload, ucsc, etc.) on the cluster (doing so is highly recommended), set `new_file_path` in `galaxy.yml` to a directory somewhere in your shared filesystem:
|
||||
|
||||
```ini
|
||||
new_file_path = /clusterfs/galaxy/tmp
|
||||
```yaml
|
||||
new_file_path: /clusterfs/galaxy/tmp
|
||||
```
|
||||
|
||||
|
||||
Additionally some of the runners including DRMAA may use the ``cluster_files_directory`` for sharing files with the cluster, which defaults to ``database/pbs``. You may need to create this folder.
|
||||
|
||||
```ini
|
||||
cluster_files_directory = database/pbs
|
||||
```yaml
|
||||
cluster_files_directory: database/pbs
|
||||
```
|
||||
|
||||
You may also find that attribute caching in your filesystem causes problems with job completion since it interferes with Galaxy detecting the presence and correct sizes of output files. In NFS caching can be disabled with the `-noac` mount option on Linux (on the Galaxy server), but this may have a significant impact on performance since all attributes will have to be read from the file server upon every file access. You should try the `retry_output_collection` option in `galaxy.ini` first to see if this solves the problem.
|
||||
You may also find that attribute caching in your filesystem causes problems with job completion since it interferes with Galaxy detecting the presence and correct sizes of output files. In NFS caching can be disabled with the `-noac` mount option on Linux (on the Galaxy server), but this may have a significant impact on performance since all attributes will have to be read from the file server upon every file access. You should try the `retry_output_collection` option in `galaxy.yml` first to see if this solves the problem.
|
||||
|
||||
## Runner Configuration
|
||||
|
||||
@@ -336,9 +336,9 @@ The directory specified in `new_file_path` in the Galaxy config should be world-
|
||||
|
||||
The `outputs_to_working_directory` option in the Galaxy config **must** be set to `True`. This ensures that a tool/job's outputs are written to the temporary working directory, which (when using the real user system) is owned by the real user who submitted the job. If left set to the default (`False`), the tool will attempt to write directly to the directory specified in `file_path` (by default, `galaxy-app/database/files/`), which must be owned by the Galaxy user (and thus will not be writable by the real user).
|
||||
|
||||
For releases later than 17.05 you can configure the method how the system user is determined in `config/galaxy.ini` via the variable `real_system_username`. For determining the system user from the email adress stored in Galaxy set it to `user_email`, otherwise for determining the system user from the Galaxy user name set it to `username`.
|
||||
For releases later than 17.05 you can configure the method how the system user is determined in `config/galaxy.yml` via the variable `real_system_username`. For determining the system user from the email adress stored in Galaxy set it to `user_email`, otherwise for determining the system user from the Galaxy user name set it to `username`.
|
||||
|
||||
Once these are set, you must set the `drmaa_external_*` and `external_chown_script` settings in the Galaxy config and configure `sudo(8)` to allow them to be run. A sudo config using the three scripts set in the sample `galaxy.ini` would be:
|
||||
Once these are set, you must set the `drmaa_external_*` and `external_chown_script` settings in the Galaxy config and configure `sudo(8)` to allow them to be run. A sudo config using the three scripts set in the sample `galaxy.yml` would be:
|
||||
|
||||
```
|
||||
galaxy ALL = (root) NOPASSWD: SETENV: /opt/galaxy/scripts/drmaa_external_runner.py
|
||||
@@ -348,8 +348,8 @@ galaxy ALL = (root) NOPASSWD: SETENV: /opt/galaxy/scripts/external_chown_script
|
||||
|
||||
If your sudo config contains `Defaults requiretty`, this option must be disabled.
|
||||
|
||||
For Galaxy releases > 17.05 the sudo call has been moved to `galaxy.ini` and is thereby configurable by the Galaxy admin. This can be of interest because sudo removes `PATH`, `LD_LIBRARY_PATH`, etc. variables per default in some installations. In such cases the sudo calls in the three variables in galaxy.ini can be adapted, e.g., `sudo -E PATH=... LD_LIBRARY_PATH=... /PATH/TO/GALAXY/scripts/drmaa_external_runner.py`. In order to allow setting the variables this way adaptions to the sudo configuration might be necessary.
|
||||
Also for Galaxy releases > 17.05: In order to allow `external_chown_script.py` to chown only path below certain entry points the variable `ALLOWED_PATHS` in the python script can be adapted. It is sufficient to include the directorries `job_working_directory` and `new_file_path` as configured in `galaxy.ini`.
|
||||
For Galaxy releases > 17.05, the sudo call has been moved to `galaxy.yml` and is thereby configurable by the Galaxy admin. This can be of interest because sudo removes `PATH`, `LD_LIBRARY_PATH`, etc. variables per default in some installations. In such cases the sudo calls in the three variables in galaxy.yml can be adapted, e.g., `sudo -E PATH=... LD_LIBRARY_PATH=... /PATH/TO/GALAXY/scripts/drmaa_external_runner.py`. In order to allow setting the variables this way adaptions to the sudo configuration might be necessary.
|
||||
Also for Galaxy releases > 17.05: In order to allow `external_chown_script.py` to chown only path below certain entry points the variable `ALLOWED_PATHS` in the python script can be adapted. It is sufficient to include the directorries `job_working_directory` and `new_file_path` as configured in `galaxy.yml`.
|
||||
|
||||
It is also a good idea to make sure that only trusted users, e.g. root, have write access to all three scripts.
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ This document is a reference for the job configuration file. [Detailed document
|
||||
|
||||
**The most up-to-date details of advanced job configuration features can be found in the [sample job_conf.xml](https://github.com/galaxyproject/galaxy/blob/dev/config/job_conf.xml.sample_advanced) found in the Galaxy distribution.**
|
||||
|
||||
Configuration of where to run jobs is performed in the `job_conf.xml` file in `$GALAXY_ROOT/config/`. The path to the config file can be overridden by setting the value of `job_config_file` in `config/galaxy.ini`. Sample configurations are provided at `galaxy-dist/config/job_conf.xml.sample_basic` and `galaxy-dist/config/job_conf.xml.sample_advanced`. The job configuration file is not required - if it does not exist, a default configuration that runs jobs on the local system (with a maximum of 4 concurrent jobs) will be used. `job_conf.xml.sample_basic` provides a configuration identical to the default configuration if no `job_conf.xml` exists.
|
||||
Configuration of where to run jobs is performed in the `job_conf.xml` file in `$GALAXY_ROOT/config/`. The path to the config file can be overridden by setting the value of `job_config_file` in `config/galaxy.yml`. Sample configurations are provided at `galaxy-dist/config/job_conf.xml.sample_basic` and `galaxy-dist/config/job_conf.xml.sample_advanced`. The job configuration file is not required - if it does not exist, a default configuration that runs jobs on the local system (with a maximum of 4 concurrent jobs) will be used. `job_conf.xml.sample_basic` provides a configuration identical to the default configuration if no `job_conf.xml` exists.
|
||||
|
||||
## job_conf.xml Syntax
|
||||
|
||||
@@ -237,7 +237,7 @@ The above examples demonstrate that the dynamic job destination framework will p
|
||||
|
||||
```eval_rst
|
||||
``app``
|
||||
Global Galaxy application object, has attributes such as config (the configuration parameters loaded from ``config/galaxy.ini``) and ``job_config`` (Galaxy representation of the data loaded in from ``job_conf.xml``).
|
||||
Global Galaxy application object, has attributes such as config (the configuration parameters loaded from ``config/galaxy.yml``) and ``job_config`` (Galaxy representation of the data loaded in from ``job_conf.xml``).
|
||||
|
||||
``user_email``
|
||||
E-mail of user submitting this job.
|
||||
|
||||
@@ -37,17 +37,17 @@ nate@weyerbacher% sh run.sh
|
||||
|
||||
## Basic configuration
|
||||
|
||||
The steps to install Galaxy mostly follow those of the regular instructions at [Admin/GetGalaxy](https://getgalaxy.org). The difference is that after performing the groundwork above, you should initialize the configuration file (`cp config/galaxy.ini.sample config/galaxy.ini`) and modify it as outlined below before starting the server. If you make any changes to this configuration file while the server is running, you will have to restart the server for the changes to take effect.
|
||||
The steps to install Galaxy mostly follow those of the regular instructions at [Admin/GetGalaxy](https://getgalaxy.org). The difference is that after performing the groundwork above, you should initialize the configuration file (`cp config/galaxy.yml.sample config/galaxy.yml`) and modify it as outlined below before starting the server. If you make any changes to this configuration file while the server is running, you will have to restart the server for the changes to take effect.
|
||||
|
||||
### Disable the developer settings
|
||||
|
||||
Two options are set in the sample `config/galaxy.ini` which should not be enabled on a production server. You should set both to `False`:
|
||||
Two options are set in the sample `config/galaxy.yml` which should not be enabled on a production server. You should set both to `false`:
|
||||
|
||||
* `debug = False` - Disable middleware that loads the entire response in memory for displaying debugging information in the page. If left enabled, the proxy server may timeout waiting for a response or your Galaxy process may run out of memory if it's serving large files.
|
||||
* `use_interactive = False` - Disables displaying and live debugging of tracebacks via the web. Leaving it enabled will expose your configuration (database password, id_secret, etc.).
|
||||
* Disable `filter-with = gzip`. Leaving the gzip filter enabled will cause UI failures because of the way templates are streamed once `debug` is set to `False`. You will still be able (and are encouraged) to enable gzip in the proxy server.
|
||||
* `debug: false` - Disable middleware that loads the entire response in memory for displaying debugging information in the page. If left enabled, the proxy server may timeout waiting for a response or your Galaxy process may run out of memory if it's serving large files.
|
||||
* `use_interactive: false` - Disables displaying and live debugging of tracebacks via the web. Leaving it enabled will expose your configuration (database password, id_secret, etc.).
|
||||
* Disable `filter-with: gzip`. Leaving the gzip filter enabled will cause UI failures because of the way templates are streamed once `debug` is set to `False`. You will still be able (and are encouraged) to enable gzip in the proxy server.
|
||||
|
||||
During deployment, you may run into problems with failed jobs. By default, Galaxy removes files related to job execution. You can instruct Galaxy to keep files of failed jobs with: `cleanup_job = onsuccess`
|
||||
During deployment, you may run into problems with failed jobs. By default, Galaxy removes files related to job execution. You can instruct Galaxy to keep files of failed jobs with: `cleanup_job: onsuccess`
|
||||
|
||||
### Switching to a database server
|
||||
|
||||
@@ -61,7 +61,7 @@ To use an external database, you'll need to set one up. That process is outside
|
||||
|
||||
Once installed, create a new database user and new database which the new user is the owner of. No further setup is required, since Galaxy manages its own schema. If you are using a UNIX socket to connect the application to the database (this is the standard case if Galaxy and the database are on the same system), you'll want to name the database user the same as the system user under which you run the Galaxy process.
|
||||
|
||||
To configure Galaxy, set `database_connection` in Galaxy's config file, `config/galaxy.ini`. The syntax for a database URL is explained in the [SQLAlchemy documentation](http://docs.sqlalchemy.org/en/latest/core/engines.html).
|
||||
To configure Galaxy, set `database_connection` in Galaxy's config file, `config/galaxy.yml`. The syntax for a database URL is explained in the [SQLAlchemy documentation](http://docs.sqlalchemy.org/en/latest/core/engines.html).
|
||||
|
||||
Here follow two example database URLs with username and password:
|
||||
|
||||
@@ -81,7 +81,7 @@ mysql:///mydatabase?unix_socket=/var/run/mysqld/mysqld.sock
|
||||
|
||||
For more hints on available options for the database URL, see the [SQLAlchemy documentation](http://docs.sqlalchemy.org/en/latest/core/engines.html#database-urls).
|
||||
|
||||
If you are using [MySQL](http://dev.mysql.com/) and encounter the "MySQL server has gone away" error, please note the `database_engine_option_pool_recycle` option in `config/galaxy.ini`. If this does not solve your problem, see [this post](http://gmod.827538.n3.nabble.com/template/NamlServlet.jtp?macro=print_post&node=2354941) on the Galaxy Development [mailing list](/src/mailing-lists/index.md).
|
||||
If you are using [MySQL](http://dev.mysql.com/) and encounter the "MySQL server has gone away" error, please note the `database_engine_option_pool_recycle` option in `config/galaxy.yml`. If this does not solve your problem, see [this post](http://gmod.827538.n3.nabble.com/template/NamlServlet.jtp?macro=print_post&node=2354941) on the Galaxy Development [mailing list](/src/mailing-lists/index.md).
|
||||
|
||||
If you are using [MySQL](http://dev.mysql.com/) please make sure the database output is in UTF-8, otherwise you may encounter python TypeErrors.
|
||||
|
||||
@@ -155,11 +155,11 @@ For those readers who've already been running Galaxy on a cluster, a bit of info
|
||||
|
||||
### Tune the database
|
||||
|
||||
[PostgreSQL](http://www.postgresql.org/) can store results more efficiently than Galaxy, and as a result, reduce Galaxy's memory footprint. When a query is made, the result will remain on the Postgres server and Galaxy can retrieve only the rows it needs. To enable this, set `database_engine_option_server_side_cursors = True` in the Galaxy config.
|
||||
[PostgreSQL](http://www.postgresql.org/) can store results more efficiently than Galaxy, and as a result, reduce Galaxy's memory footprint. When a query is made, the result will remain on the Postgres server and Galaxy can retrieve only the rows it needs. To enable this, set `database_engine_option_server_side_cursors: true` in the Galaxy config.
|
||||
|
||||
If your server logs errors about the database connection pool size, you may need to increase the default minimum and maximum number of pool connections, 5 and 10. These config file options are `database_engine_option_pool_size` and `database_engine_option_max_overflow`.
|
||||
|
||||
Finally, if you are using Galaxy <= release_2014.06.02, we recommend that you instruct Galaxy to use one database connection per thread, to avoid connection overhead and overuse. This can be enabled with `database_engine_option_strategy = threadlocal`.
|
||||
Finally, if you are using Galaxy <= release_2014.06.02, we recommend that you instruct Galaxy to use one database connection per thread, to avoid connection overhead and overuse. This can be enabled with `database_engine_option_strategy: threadlocal`.
|
||||
|
||||
### Make the proxy handle uploads and downloads
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
The Galaxy framework is written in Python and makes extensive use of threads. However, one of the drawbacks of Python is the [Global Interpreter Lock](http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock), which prevents more than one thread from being on CPU at a time. Because of this, having a multi-core system will not improve the Galaxy framework's performance out of the box since Galaxy can use (at most) one core at a time. However, Galaxy can easily run in multiple separate processes, which solves this problem. For a more thorough explanation of this problem and why you will almost surely want to switch to the load balanced configuration if running for more than a small handful of users, see the [production configuration](production.html) page.
|
||||
|
||||
Just to be clear: increasing the values of `threadpool_workers` in `galaxy.ini` or the number of plugin workers in `job_conf.xml` will not make you Galaxy server much more responsive. The key to scaling Galaxy is the ability to run *multiple* Galaxy servers which co-operatively work on the same database.
|
||||
Just to be clear: increasing the values of `threadpool_workers` in `galaxy.yml` or the number of plugin workers in `job_conf.xml` will not make you Galaxy server much more responsive. The key to scaling Galaxy is the ability to run *multiple* Galaxy servers which co-operatively work on the same database.
|
||||
|
||||
A simple configuration:
|
||||
* 1 "job handler" process - responsible for starting and monitoring jobs, submitting jobs to a cluster (if configured), and for setting metadata (externally or internally).
|
||||
@@ -124,9 +124,9 @@ Using web processes as handlers is possible, but it is not recommended since han
|
||||
|
||||
### Remaining configuration options
|
||||
|
||||
If you do not have a `job_conf.xml` file, you will need to create one. There are samples for a basic configuration and an advanced configuration provided in the distribution. Please note that creating `job_conf.xml` overrides any legacy job running settings in `galaxy.ini`. See the [jobs configuration documentation](jobs.html) for more detail on job configuration.
|
||||
If you do not have a `job_conf.xml` file, you will need to create one. There are samples for a basic configuration and an advanced configuration provided in the distribution. Please note that creating `job_conf.xml` overrides any legacy job running settings in `galaxy.yml`. See the [jobs configuration documentation](jobs.html) for more detail on job configuration.
|
||||
|
||||
In `job_conf.xml`, create `<handler>` tags with `id` attributes that match the handler server names you defined in `galaxy.ini`. For example, using the configuration above, the `<handlers>` section of `job_conf.xml` would look like:
|
||||
In `job_conf.xml`, create `<handler>` tags with `id` attributes that match the handler server names you defined in `galaxy.yml`. For example, using the configuration above, the `<handlers>` section of `job_conf.xml` would look like:
|
||||
|
||||
```xml
|
||||
<handlers default="handlers">
|
||||
|
||||
@@ -168,11 +168,12 @@ To enable it, you must first install `mod_xsendfile`, this is usually available
|
||||
</Location>
|
||||
```
|
||||
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.ini` and make the following change before restarting Galaxy:
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.yml` and make the following change before restarting Galaxy:
|
||||
|
||||
```ini
|
||||
[app:main]
|
||||
apache_xsendfile = True
|
||||
```yaml
|
||||
galaxy:
|
||||
# ...
|
||||
apache_xsendfile: true
|
||||
```
|
||||
|
||||
For this to work, the user under which your nginx server runs will need read access to Galaxy's `$GALAXY_ROOT/database/files/` directory and its contents.
|
||||
@@ -184,7 +185,7 @@ For this to work, the user under which your nginx server runs will need read acc
|
||||
|
||||
### Display Sites
|
||||
|
||||
Display sites such as UCSC work not by sending data directly from Galaxy to UCSC via the client's browser, but by sending UCSC a URL to the data in Galaxy that the UCSC server will retrieve data from. Since enabling authentication will place **all** of Galaxy behind authentication, such display sites will no longer be able to access data via that URL. If `display_servers` is set to a non-empty value in `$GALAXY_ROOT/config/galaxy.ini`, this tells Galaxy it should allow the named servers access to data in Galaxy. However, you still need to configure Apache to allow access to the datasets. An example config is provided here that allows the UCSC Main/Test backends:
|
||||
Display sites such as UCSC work not by sending data directly from Galaxy to UCSC via the client's browser, but by sending UCSC a URL to the data in Galaxy that the UCSC server will retrieve data from. Since enabling authentication will place **all** of Galaxy behind authentication, such display sites will no longer be able to access data via that URL. If `display_servers` is set to a non-empty value in `$GALAXY_ROOT/config/galaxy.yml`, this tells Galaxy it should allow the named servers access to data in Galaxy. However, you still need to configure Apache to allow access to the datasets. An example config is provided here that allows the UCSC Main/Test backends:
|
||||
|
||||
```apache
|
||||
<Location "/root/display_as">
|
||||
@@ -211,7 +212,7 @@ Display sites such as UCSC work not by sending data directly from Galaxy to UCSC
|
||||
|
||||
### Proxying multiple galaxy worker threads
|
||||
|
||||
If you've configured multiple threads for galaxy in the `config/galaxy.ini` file, you will need a `ProxyBalancer` to manage sending requests to each of the threads. You can do that with apache configuration as follows:
|
||||
If you've configured multiple threads for galaxy in the `config/galaxy.yml` file, you will need a `ProxyBalancer` to manage sending requests to each of the threads. You can do that with apache configuration as follows:
|
||||
|
||||
```apache
|
||||
<Proxy balancer://galaxy>
|
||||
|
||||
@@ -10,7 +10,7 @@ Although there is no specific required server, we use [ProFTPD](http://proftpd.o
|
||||
|
||||
## Configure Galaxy
|
||||
|
||||
The first step is to choose a directory into which your users will upload files. Preferably this will be on the same filesystem as Galaxy's datasets (by default, `galaxy_dist/database/files/`). The FTP server will create subdirectories inside of this directory which match the user's email address. Likewise, Galaxy will expect to find email-named subdirectories at that path. This directory should be set in the config file (`galaxy.ini`) as `ftp_upload_dir`.
|
||||
The first step is to choose a directory into which your users will upload files. Preferably this will be on the same filesystem as Galaxy's datasets (by default, `galaxy_dist/database/files/`). The FTP server will create subdirectories inside of this directory which match the user's email address. Likewise, Galaxy will expect to find email-named subdirectories at that path. This directory should be set in the config file (`galaxy.yml`) as `ftp_upload_dir`.
|
||||
|
||||
In the config file, you'll also want to set `ftp_upload_site` to the hostname your users should connect to via FTP. This will be provided in the help text on the Upload File form.
|
||||
|
||||
@@ -38,7 +38,7 @@ GRANT
|
||||
|
||||
## Configuring ProFTPD
|
||||
|
||||
By default, Galaxy stores passwords using [PBKDF2](http://en.wikipedia.org/wiki/PBKDF2). It's possible to disable this using the `use_pbkdf2 = False` setting in `galaxy.ini`. Once disabled, any new passwords created will be stored in an older hex-encoded SHA1 format. Because of this, it's possible to have both PBKDF2 and SHA1 passwords in your database (especially if your server has been around since before PBKDF2 support was added). Although this is fine (Galaxy can read passwords in either format), ProFTPD will expect them in one format or the other (although with some amount of hackery it could probably be made to read both).
|
||||
By default, Galaxy stores passwords using [PBKDF2](http://en.wikipedia.org/wiki/PBKDF2). It's possible to disable this using the `use_pbkdf2: false` setting in the `galaxy` section of `galaxy.yml`. Once disabled, any new passwords created will be stored in an older hex-encoded SHA1 format. Because of this, it's possible to have both PBKDF2 and SHA1 passwords in your database (especially if your server has been around since before PBKDF2 support was added). Although this is fine (Galaxy can read passwords in either format), ProFTPD will expect them in one format or the other (although with some amount of hackery it could probably be made to read both).
|
||||
|
||||
Because of this, you'll need to choose one or the other in your Galaxy config (PBKDF2 is more secure and therefore preferred) and configure ProFTPD accordingly. If users cannot log in because their password is stored in the wrong format, they can simply use Galaxy's password change form to set their password, which will rewrite their password using the currently configured algorithm.
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ http {
|
||||
}
|
||||
```
|
||||
|
||||
2. The Galaxy application needs to be aware that it is running with a prefix (for generating URLs in dynamic pages). This is accomplished by configuring a Paste proxy-prefix filter in the `[app:main]` section of `config/galaxy.ini` and restarting Galaxy:
|
||||
2. The Galaxy application needs to be aware that it is running with a prefix (for generating URLs in dynamic pages). This is accomplished by configuring a Paste proxy-prefix filter in the `galaxy` section of `config/galaxy.ini` and restarting Galaxy:
|
||||
|
||||
|
||||
```ini
|
||||
@@ -198,11 +198,12 @@ http {
|
||||
}
|
||||
```
|
||||
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.ini` and make the following change before restarting Galaxy:
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.yml` and make the following change before restarting Galaxy:
|
||||
|
||||
```ini
|
||||
[app:main]
|
||||
nginx_x_accel_redirect_base = /_x_accel_redirect
|
||||
```yaml
|
||||
galaxy:
|
||||
#...
|
||||
nginx_x_accel_redirect_base: '/_x_accel_redirect'
|
||||
```
|
||||
|
||||
For this to work, the user under which your nginx server runs will need read access to Galaxy's `$GALAXY_ROOT/database/files/` directory and its contents.
|
||||
@@ -245,12 +246,13 @@ http {
|
||||
|
||||
Note the `user` directive. To ensure that Galaxy has write permission on the uploaded files, nginx's workers will need to run as the same user as Galaxy.
|
||||
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.ini` and make the following change before restarting Galaxy:
|
||||
Finally edit your `$GALAXY_ROOT/config/galaxy.yml` and make the following change before restarting Galaxy:
|
||||
|
||||
```ini
|
||||
[app:main]
|
||||
nginx_upload_store = database/tmp/upload_store
|
||||
nginx_upload_path = /_upload
|
||||
```yaml
|
||||
galaxy:
|
||||
#...
|
||||
nginx_upload_store: database/tmp/upload_store
|
||||
nginx_upload_path: '/_upload'
|
||||
```
|
||||
|
||||
When serving Galaxy with a prefix, as described in the serving Galaxy in a sub-directory section above, you will need to change one line in the `\_upload\_done` section. If your galaxy instance is available from `/galaxy`, then the first line should include this prefix:
|
||||
|
||||
@@ -8,21 +8,21 @@ Most performance tracking requires sending metrics to a metrics collection serve
|
||||
uWSGI
|
||||
-----
|
||||
|
||||
As you have certainly switched to uWSGI from the default paste server, there is some built-in uWSGI support for performance logging. You can send uWSGI's internal metrics to a carbon (Graphite) server by setting the carbon option in your galaxy.ini:
|
||||
As you have certainly switched to uWSGI from the default paste server, there is some built-in uWSGI support for performance logging. You can send uWSGI's internal metrics to a carbon (Graphite) server by setting the carbon option in your galaxy.yml:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
[uwsgi]
|
||||
socket = ...
|
||||
carbon = 127.0.0.1:2003
|
||||
uwsgi:
|
||||
socket: ...
|
||||
carbon: 127.0.0.1:2003
|
||||
|
||||
Or a StatsD server via:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
[uwsgi]
|
||||
socket = ...
|
||||
statsd-push = 127.0.0.1:8125
|
||||
wsgi:
|
||||
socket: ...
|
||||
statsd-push: 127.0.0.1:8125
|
||||
|
||||
The `official documentation <http://uwsgi-docs.readthedocs.io/en/latest/Metrics.html#stats-pushers>`__ contains further information on uWSGI and stats servers. In the `uWSGI Stats Server <http://uwsgi-docs.readthedocs.io/en/latest/StatsServer.html>` documentation, you can see an example of the sort of information that you will be able to collect.
|
||||
|
||||
@@ -31,21 +31,25 @@ API / Route Timing Statistics
|
||||
|
||||
Galaxy provides middleware to automatically log the amount of time controllers take to execute and to send that data to a stats server. Using the stats server of your choice, you can calculate the relevant statistics to ensure that your Galaxy server is performing as expected.
|
||||
|
||||
The statsD configuration requires setting the following:
|
||||
The statsD configuration requires setting the following options in the ``galaxy`` section of ``config/galaxy.yml``:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
statsd_host=127.0.0.1
|
||||
statsd_port=8125
|
||||
statsd_prefix=galaxy
|
||||
galaxy:
|
||||
#...
|
||||
statsd_host: 127.0.0.1
|
||||
statsd_port: 8125
|
||||
statsd_prefix: galaxy
|
||||
|
||||
And the graphite configuration is very similar:
|
||||
|
||||
.. code-block:: ini
|
||||
.. code-block:: yaml
|
||||
|
||||
graphite_host=127.0.0.1
|
||||
graphite_port=2003
|
||||
graphite_prefix=galaxy
|
||||
galaxy:
|
||||
# ...
|
||||
graphite_host: 127.0.0.1
|
||||
graphite_port: 2003
|
||||
graphite_prefix: galaxy
|
||||
|
||||
Most people visualize the statistics using something like `Grafana <https://grafana.com/>`__:
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ Plugin activation
|
||||
-----------------
|
||||
All webhooks that are included in the main Galaxy distribution are located in the ``config/plugins/webhooks/demo`` folder
|
||||
and are deactivated by default.
|
||||
To activate these demo webhooks make sure this path is added to ``webhooks_dir`` in your ``galaxy.ini``. You can add as many
|
||||
To activate these demo webhooks make sure this path is added to ``webhooks_dir`` in your ``galaxy.yml``. You can add as many
|
||||
webhook folders as you like as a comma separated list.
|
||||
Webhooks supports one additional layer of activating/deactivating by changing the ``activate: true`` in each config of each webhook.
|
||||
|
||||
|
||||
@@ -9,7 +9,7 @@ The contents of the tool panel are defined by the following configuration files.
|
||||
|
||||
Local tools
|
||||
~~~~~~~~~~~
|
||||
In the past, the file named by your ``tool_config_file`` configuration setting in your ``config/galaxy.ini`` file was the only file used to populate your Galaxy tool panel. The default name for this file is ``tool_conf.xml``. Since this was the only file involved in populating your Galaxy tool panel, it defined the items (tools, workflows, sections and labels) that would be displayed and the way in which they would be arranged.
|
||||
In the past, the file named by your ``tool_config_file`` configuration setting in your ``config/galaxy.yml`` file was the only file used to populate your Galaxy tool panel. The default name for this file is ``tool_conf.xml``. Since this was the only file involved in populating your Galaxy tool panel, it defined the items (tools, workflows, sections and labels) that would be displayed and the way in which they would be arranged.
|
||||
|
||||
Tool Shed tools
|
||||
~~~~~~~~~~~~~~~
|
||||
@@ -23,7 +23,7 @@ Layout
|
||||
------
|
||||
|
||||
The 3 or more files described in the previous section (``tool_conf.xml``, one or more ``shed_tool_conf.xml`` files, and ``migrated_tools_conf.xml``) are all used to load tool panel items (tools, sections, labels and workflows). A file named ``integrated_tool_panel.xml`` defines the arrangement for displaying these loaded items in your Galaxy tool panel.
|
||||
If this file does not exist in your Galaxy installation directory, it will be automatically created and populated when you start your Galaxy server. It is initially populated based on the order in which the tool panel items are loaded. The items are loaded as each tool panel configuration file is parsed and its items are loaded. The order in which these configuration files are parsed is the order of the comma-separated list of files defined in your ``tool_config_file`` setting in your ``config/galaxy.ini`` configuration file. The ``migrated_tools_conf.xml`` file is always parsed and loaded last. Let's look at an example to help clarify how this works.
|
||||
If this file does not exist in your Galaxy installation directory, it will be automatically created and populated when you start your Galaxy server. It is initially populated based on the order in which the tool panel items are loaded. The items are loaded as each tool panel configuration file is parsed and its items are loaded. The order in which these configuration files are parsed is the order of the comma-separated list of files defined in your ``tool_config_file`` setting in your ``config/galaxy.yml`` configuration file. The ``migrated_tools_conf.xml`` file is always parsed and loaded last. Let's look at an example to help clarify how this works.
|
||||
|
||||
If you uninstall a repository that contains tools, entries for those tools will automatically be removed from the shed-related tool panel config file and the integrated_tool_panel.xml file.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user