opensource/galaxy
3
0
Fork 0
mirror of https://github.com/galaxyproject/galaxy.git synced 2026-09-21 13:50:20 +08:00
Code Issues Packages Projects Releases Wiki Activity

yaml_config - update admin docs for switch to YAML config.

Browse Source
This commit is contained in:
John Chilton
2017-12-06 20:28:20 -05:00
parent 7bae23e105
commit ba35d474a0
7 changed files with 57 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/source/admin/authentication.md
+16 -15
View File
@@ -33,8 +33,8 @@ of documentation on configuring these plugins.
[OpenID](https://en.wikipedia.org/wiki/OpenID) is becoming less popular and probably shouldn't be used the primary mechanism
for authentication in Galaxy but it is an available option.
Enabling OpenID requires you to edit Galaxy's configuration file and set `enable_openid` to `True`. This file is
likely located in `config/galaxy.ini` and can be created by copying Galaxy's sample `config/galaxy.ini.sample`.
Enabling OpenID requires you to edit Galaxy's configuration file and set `enable_openid` to `true`. This file is
likely located in `config/galaxy.yml` and can be created by copying Galaxy's sample `config/galaxy.yml.sample`.
Enabling this option enables OpenID and causes the OpenID form to be displayed on the login screen.
@@ -55,8 +55,8 @@ and the "external" flag should itself prohibit the traditional mechanism being u
user returns to Galaxy and is not already logged in, the details of the user are retrieved according to the identity
information supplied by the Web server.
Enabling remote user authentication requires you to edit Galaxy's configuration file and set `use_remote_user` to `True`.
This file is likely located in `config/galaxy.ini` and can be created by copying Galaxy's sample `config/galaxy.ini.sample`.
Enabling remote user authentication requires you to edit Galaxy's configuration file and set `use_remote_user` to `true`.
This file is likely located in `config/galaxy.yml` and can be created by copying Galaxy's sample `config/galaxy.yml.sample`.
Additional Galaxy configuration options related to remote user authentication are documented in Galaxy's sample
configuration file. The options ``remote_user_maildomain``, ``remote_user_header``, and ``normalize_remote_user_email`` can
@@ -75,29 +75,30 @@ How to set up this config is presented here.
### Account activation feature
In the Galaxy config file **config/galaxy.ini** there is the user activation setting that you have to turn on.
In the Galaxy config file **config/galaxy.yml** there is the user activation setting that you have to turn on.
```
user_activation_on = True
```yaml
user_activation_on: true
```
There is also the option for tracking jobs in database that is required to be turned on for the account activation to be effective. By default it is off.
```
track_jobs_in_database = True
```yaml
track_jobs_in_database: true
```
After you turn on both of these every user that will try to register after this configuration file takes effect will have the verification email sent to the email address provided. Unless the Grace period (see below) is set, the user won't be able to login before the verification happens.
Furthermore in order for this to work correctly smtp server and admin email should be set:
```
#smtp_server = some.server.edu:587
#smtp_username = example_username
#smtp_password = example_passsword
#activation_email = activation-noreply@example.com
#error_email_to = admin@example.com
```yaml
smtp_server: some.server.edu:587
smtp_username: example_username
smtp_password: example_passsword
activation_email: activation-noreply@example.com
error_email_to: admin@example.com
```
Smtp server takes care of the email sending and the activation_email email is used as the *From* address in the verification email. Furthermore the error_email_to is being shown to the user if the Galaxy detects its own misconfiguration.
doc/source/admin/conda_faq.rst
+16 -16
View File
@@ -63,19 +63,19 @@ entry should remain first. This means that tools that have specified Tool Shed p
as their dependencies will work without a change.
The most common configuration settings related to Conda are listed in Table 1.
See `galaxy.ini.sample`_ for the complete list.
See `galaxy.yml.sample`_ for the complete list.
+-------------------------+------------------------------------+---------------------------+
| Setting | Default setting | Meaning |
+-------------------------+------------------------------------+---------------------------+
| ``conda_auto_init`` | ``True`` | If ``True``, Galaxy will |
| ``conda_auto_init`` | ``true`` | If ``true``, Galaxy will |
| | | try to install Conda |
| | | (the package manager) |
| | | automatically if it |
| | | cannot find a local copy |
| | | already on the system |
+-------------------------+------------------------------------+---------------------------+
| ``conda_auto_install`` | ``False`` | If ``True``, Galaxy will |
| ``conda_auto_install`` | ``false`` | If ``true``, Galaxy will |
| | | look for and install |
| | | Conda packages for |
| | | missing tool dependencies |
@@ -99,8 +99,8 @@ admin to install and manage packages without touching Galaxy at all. Galaxy can
handle these dependencies for you, but admins are not required to use Galaxy for
dependency management.
There are a few new config options in the ``galaxy.ini`` file (see Table 1 or
`galaxy.ini.sample`_ for more information), but by default Galaxy will install
There are a few new config options in the ``galaxy.yml`` file (see Table 1 or
`galaxy.yml.sample`_ for more information), but by default Galaxy will install
Conda (the package manager) and the required packages in the
``<tool_dependency_dir>/_conda/`` directory. In this directory, Galaxy will
create an ``envs`` folder with all of the environments managed by Galaxy. Each
@@ -111,7 +111,7 @@ available before the tool is executed on your system.
To summarize, there are four ways to manage Conda dependencies for use
with Galaxy. For all of these options, Conda dependency management must
be configured in the ``dependency_resolvers_conf.xml`` and the ``galaxy.ini`` file.
be configured in the ``dependency_resolvers_conf.xml`` and the ``galaxy.yml`` file.
#. Galaxy Admin Interface (>= 16.07) - Galaxy will install Conda tool
dependencies when tools are installed from the Tool Shed if the
@@ -121,7 +121,7 @@ be configured in the ``dependency_resolvers_conf.xml`` and the ``galaxy.ini`` fi
#. Manual Install - Conda dependencies may be installed by
administrators from the command line. Conda (and thus the Conda
environments) should be installed in the location specified by the
``conda_prefix`` path (defined in ``galaxy.ini`` and by default
``conda_prefix`` path (defined in ``galaxy.yml`` and by default
``<tool_dependency_dir>/_conda/`` directory). Galaxy will search
these environments for required packages when tools are run. Conda
environment names have to follow a specific naming pattern. As an
@@ -157,11 +157,11 @@ will run on all major \*nix operating systems newer than 2007.
4. If I have Conda enabled, what do I need to do to install tools using it? For example, how can I install the latest Trinity? And how will I know the dependencies are installed?
**********************************************************************************************************************************************************************************
This depends on your ``galaxy.ini`` setting. Starting with release 16.07, Galaxy
This depends on your ``galaxy.yml`` settings. Starting with release 16.07, Galaxy
can automatically install the Conda package manager for you if you have enabled
``conda_auto_init``. Galaxy can then install Trinity along with its dependencies
using one of the methods listed in question 2 above. In particular, if
``conda_auto_install`` is ``True`` and Trinity is not installed yet, Galaxy will
``conda_auto_install`` is ``true`` and Trinity is not installed yet, Galaxy will
try to install it via Conda when a Trinity job is launched.
With release 16.07 you can see which dependencies are being used
@@ -176,7 +176,7 @@ dependency resolvers configuration with regards to what will actually be used du
the tool execution.
To check if Galaxy has created a Trinity environment, have a look at folders under
``<tool_dependency_dir>/_conda/envs/`` (or ``<conda_prefix>/envs`` if you have changed ``conda_prefix`` in your galaxy.ini file).
``<tool_dependency_dir>/_conda/envs/`` (or ``<conda_prefix>/envs`` if you have changed ``conda_prefix`` in your ``galaxy.yml`` file).
We recommend to use Conda on a tool-per-tool basis, by unchecking the checkbox
for TS dependencies during the tool installation, and for tools where there
@@ -224,7 +224,7 @@ The simple answer is: you don't need to do much to make Conda work for a tool.
The ``<requirement>`` tag in the tool XML file is enough. The name and the
version should correspond to a Conda package in the ``default``, ``r``,
``bioconda`` or ``iuc`` Conda channel (you can extend this list if you
like in your ``galaxy.ini`` ). If this is the case you are ready to go. Read
like in your ``galaxy.yml`` ). If this is the case you are ready to go. Read
more about `Conda channels`_ and browse their packages on https://anaconda.org/ url followed by the channel name (e.g.
`https://anaconda.org/bioconda <https://anaconda.org/bioconda>`__
).
@@ -328,14 +328,14 @@ message appears in your logs:
You can also use: $ conda clean --lock
First, you may wish to enable cached dependencies. This can be done by setting
``use_cached_dependency_manager`` to ``True`` in ``galaxy.ini``. Without this
``use_cached_dependency_manager`` to ``true`` in ``galaxy.yml``. Without this
option, many jobs will create a per-job Conda environment with just the
dependencies needed for that job installed.
This will be placed on the filesystem containg the job working directory. This
is an expensive operation and Conda doesn't always link environments correctly
across filesystems. Enabling this dependency caching will create a cache
directory for each required combination of requirements inside the directory
specified by ``tool_dependency_cache_dir`` in ``galaxy.ini`` (defaulting to
specified by ``tool_dependency_cache_dir`` in ``galaxy.yml`` (defaulting to
``<tool_dependency_dir>/_cache``).
The cached dependency manager was added to the 16.10 release of Galaxy (see
@@ -364,8 +364,8 @@ newer version of Conda than shipped with Galaxy as of 17.01. See the question be
on upgrading Conda if you must use this trick.
Alternatively, copying can be used when creating environments instead of links (either
symbolic or hard). To enable this set ``conda_copy_dependencies`` to ``True`` in
``galaxy.ini``. This requires at least version 16.07 of Galaxy.
symbolic or hard). To enable this set ``conda_copy_dependencies`` to ``true`` in
``galaxy.yml``. This requires at least version 16.07 of Galaxy.
More reading on this can be found at `Conda Pull Request #3870`_, `Conda Issue #3308`,
and Galaxy `Issue #3193`_.
@@ -409,7 +409,7 @@ The command can obviously be adapted to install any version of Conda.
.. _submit: https://bioconda.github.io/#step-4-join-the-team
.. _BioConda: https://bioconda.github.io
.. _contact with the IUC: https://gitter.im/galaxy-iuc/iuc
.. _galaxy.ini.sample: https://github.com/galaxyproject/galaxy/blob/dev/config/galaxy.ini.sample
.. _galaxy.yml.sample: https://docs.galaxyproject.org/en/master/admin/options.html
.. _Pull Request #3106: https://github.com/galaxyproject/galaxy/pull/3106
.. _Pull Request #3348: https://github.com/galaxyproject/galaxy/pull/3348
.. _Pull Request #3391: https://github.com/galaxyproject/galaxy/pull/3391
doc/source/admin/dependency_resolvers.rst
+1 -1
View File
@@ -92,7 +92,7 @@ installed packages. This resolver can be configured either to use the version st
The Galaxy Packages dependency resolver takes a ``base_path`` argument that specifies the path under which
it starts looking for the files it requires. The default value for this ``base_path`` is the
``tool_dependency_dir`` configured in Galaxy's ``config/galaxy.ini``. Below the base path, the Galaxy Packages
``tool_dependency_dir`` configured in Galaxy's ``config/galaxy.yml``. Below the base path, the Galaxy Packages
resolver looks for directories named after tools, e.g. ``bedtools``. As mentioned before, this resolver
works in versioned and versionless mode. The default mode is versioned, where the dependency resolver looks for a
directory named after the dependency's version string. For example, if the Galaxy tool specifies that it
doc/source/admin/reports.md
+3 -3
View File
@@ -4,12 +4,12 @@ Galaxy includes a report tool that is separate from the main process but which g
## Setup on localhost
The report tool takes its configuration settings from a file called reports.ini, which is located in the config subdirectory of the Galaxy distribution.
The report tool takes its configuration settings from a file called `reports.yml`, which is located in the ``config/` subdirectory of the Galaxy distribution.
Configuring the reports for your local setup is a case of:
* Making a copy of `reports.ini.sample` called `reports.ini`.
* Editing the `database_connection` parameter to match the one in your `galaxy.ini` file
* Making a copy of ``reports.yml.sample`` called `reports.yml`.
* Editing the `database_connection` parameter to match the one in your `galaxy.yml` file
* Optionally, editing the `port` parameter (by default the tool uses port 9001)
You should also set the 'salt' parameter `session_secret` if you intend to expose the reports via the web proxy (see below).
doc/source/admin/special_topics/bug_reports.rst
+1 -1
View File
@@ -46,7 +46,7 @@ information about the job and links to the precise locations within Galaxy.
As a plugin, nothing has changed to this functionality, though future updates
may add features. It currently takes all of its configuration from your
``$GALAXY/config/galaxy.ini``, e.g. the variables ``error_email_to`` and
``$GALAXY/config/galaxy.yml``, e.g. the variables ``error_email_to`` and
``email_from``.
JSON
doc/source/admin/special_topics/chat.rst
+7 -7
View File
@@ -23,7 +23,7 @@ This service will need to be deployed on a host that has:
- Access to the Galaxy database
- A port exposed
- A non-default ``id_secret`` set in your ``galaxy.ini``
- A non-default ``id_secret`` set in your ``galaxy.yml``
We say "access to galaxy database", this service could run on an NFS mounted
copy of Galaxy, if the host it is deployed on can access the database of the
@@ -36,16 +36,16 @@ Deploying the Server
The chat server is a very new feature in Galaxy and has been disabled by
default at a number of levels, as not all users may wish to use this feature.
Configuration is managed in ``galaxy.ini``:
Configuration is managed in ``galaxy.yml``:
.. code-block:: ini
.. code-block:: yaml
# Galaxy real time communication server settings
enable_communication_server = True
communication_server_host = http://localhost
communication_server_port = 7070
enable_communication_server: True
communication_server_host: http://localhost
communication_server_port: 7070
# persistent_communication_rooms is a comma-separated list of rooms that should be always available.
persistent_communication_rooms = NGS,RNA-Seq,Genome Annotation
persistent_communication_rooms: NGS,RNA-Seq,Genome Annotation
As you can see in this configuration, it is pointing at a service running on
the same host as Galaxy, talking to port 7070.
doc/source/admin/special_topics/interactive_environments.rst
+13 -13
View File
@@ -102,26 +102,26 @@ Galaxy runs as.
Configuring the Proxy
^^^^^^^^^^^^^^^^^^^^^
Configuration is all managed in ``galaxy.ini``. The default arguments used
Configuration is all managed in ``galaxy.yml``. The default arguments used
for the proxy are:
.. code-block:: ini
.. code-block:: yaml
dynamic_proxy_manage=True
dynamic_proxy_session_map=database/session_map.sqlite
dynamic_proxy_bind_port=8800
dynamic_proxy_bind_ip=0.0.0.0
dynamic_proxy_debug=True
dynamic_proxy_manage: true
dynamic_proxy_session_map: database/session_map.sqlite
dynamic_proxy_bind_port: 8800
dynamic_proxy_bind_ip: 0.0.0.0
dynamic_proxy_debug: true
As you can see most of these variables map directly to the command line
arguments to the NodeJS script. There are a few extra parameters which will
be needed if you run Galaxy behind an upstream proxy like nginx or
Apache:
.. code-block:: ini
.. code-block:: yaml
dynamic_proxy_external_proxy=True
dynamic_proxy_prefix=gie_proxy
dynamic_proxy_external_proxy: true
dynamic_proxy_prefix: gie_proxy
The first option says that you have Galaxy and the Galaxy NodeJS proxy wrapped
in an upstream proxy like Apache or NGINX. This will cause Galaxy to connect
@@ -139,7 +139,7 @@ second (``dynamic_proxy_prefix``) option sets the URL path that's used to
differentiate requests that should go through the proxy to those that should go
to Galaxy. You will need to add special upstream proxy configuration to handle
this, and you'll need to use the same ``dynamic_proxy_prefix`` in your
``galaxy.ini`` that you use in your URL routes.
``galaxy.yml`` that you use in your URL routes.
In the examples below, we assume that your Galaxy installation is available
at a URL such as ``https://f.q.d.n/galaxy``. If instead it is available at a
@@ -296,10 +296,10 @@ configuration file:
swarm_mode = True
You can also enable swarm mode for *all* GIE plugins by setting
``interactive_environment_swarm_mode`` in ``galaxy.ini`` to ``True``. If using
``interactive_environment_swarm_mode`` in ``galaxy.yml`` to ``True``. If using
this setting, you must still set ``docker_connect_port`` in each GIE plugin's
ini configuration file. The ``swarm_mode`` setting in individual GIE plugin
config files will override the value set in ``galaxy.ini``.
config files will override the value set in ``galaxy.yml``.
Note that your Galaxy server does not need to be a member of the swarm itself.
It can use the method outlined above in the `Docker on Another Host`_ section