[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: improve taler-merchant manual
|
From: |
gnunet |
|
Subject: |
[taler-docs] branch master updated: improve taler-merchant manual |
|
Date: |
Sun, 21 May 2023 21:19:01 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new 209fbdea improve taler-merchant manual
209fbdea is described below
commit 209fbdea5bde39fa66bee2238fd823f001107b64
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sun May 21 21:18:57 2023 +0200
improve taler-merchant manual
---
frags/installing-trisquel.rst | 2 +-
frags/semver.rst | 26 +++
taler-exchange-manual.rst | 11 +-
taler-merchant-manual.rst | 417 +++++++++++++-----------------------------
4 files changed, 154 insertions(+), 302 deletions(-)
diff --git a/frags/installing-trisquel.rst b/frags/installing-trisquel.rst
index 4ca8bcc5..f431b120 100644
--- a/frags/installing-trisquel.rst
+++ b/frags/installing-trisquel.rst
@@ -1,4 +1,4 @@
To install the GNU Taler Trisquel packages, first ensure that you have
the right Trisquel distribution. Packages are currently available for
Trisquel GNU/Linux 10.0. Simply follow the same instructions provided
-for Ubuntu 20.04 LTS (Focal Fossa).
+for Ubuntu.
diff --git a/frags/semver.rst b/frags/semver.rst
new file mode 100644
index 00000000..8fc78b38
--- /dev/null
+++ b/frags/semver.rst
@@ -0,0 +1,26 @@
+..
+ This file is part of GNU TALER.
+
+ Copyright (C) 2014-2023 Taler Systems SA
+
+ TALER is free software; you can redistribute it and/or modify it under the
+ terms of the GNU Affero General Public License as published by the Free
Software
+ Foundation; either version 2.1, or (at your option) any later version.
+
+ TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+ WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+ A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
details.
+
+ You should have received a copy of the GNU Affero General Public License
along with
+ TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
+
+ @author Christian Grothoff
+
+GNU Taler components version numbers follow the ``MAJOR.MINOR.MICRO`` format.
+The general rule for compatibility is that ``MAJOR`` and ``MINOR`` must match.
+Exceptions to this general rule are documented in the release notes.
+For example, Taler merchant 1.3.0 should be compatible with Taler exchange
1.4.x
+as the MAJOR version matches. A MAJOR version of 0 indicates experimental
+development, and you are expected to always run all of the *latest* releases
+together (no compatibility guarantees).
+
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 750be35a..ffc1e125 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -350,15 +350,8 @@ the GNU Taler exchange from source.
The package sources can be find in our
`download directory <http://ftpmirror.gnu.org/taler/>`__.
-GNU Taler components version numbers follow the ``MAJOR.MINOR.MICRO`` format.
-The general rule for compatibility is that ``MAJOR`` and ``MINOR`` must match.
-Exceptions to this general rule are documented in the release notes. For
-example, according to the general rule, a Taler merchant 1.3.0 should be
-compatible with Taler exchange 1.4.x as the MAJOR version matches. A MAJOR
-version of 0 indicates experimental development, and you are expected to
-always run all of the *latest* releases together (no compatibility
-guarantees).
-
+.. include:: frags/semver.rst
+
First, the following packages need to be installed before we can compile the
backend:
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index a12b1d7e..7dbd7218 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -1,4 +1,22 @@
-.. _ffoobar:
+..
+ This file is part of GNU TALER.
+
+ Copyright (C) 2014-2023 Taler Systems SA
+
+ TALER is free software; you can redistribute it and/or modify it under the
+ terms of the GNU Affero General Public License as published by the Free
Software
+ Foundation; either version 2.1, or (at your option) any later version.
+
+ TALER is distributed in the hope that it will be useful, but WITHOUT ANY
+ WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
+ A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
details.
+
+ You should have received a copy of the GNU Affero General Public License
along with
+ TALER; see the file COPYING. If not, see <http://www.gnu.org/licenses/>
+
+ @author Christian Grothoff
+
+.. _taler-merchant-backend-operator-manual:
GNU Taler Merchant Backend Operator Manual
##########################################
@@ -209,10 +227,10 @@ purchase the same product.
To prevent unauthorized wallets from claiming an order, merchants can specify
that claims require authorization in the form of a *claim token*. This is
useful in case the order ID is predictable (say because an existing order ID
-scheme from the merchant frontend is used) and at the same time malicious
-actors claiming orders is problematic (say because of limited stocks). The use
-of claim tokens is optional, but if a claim token is used, it must be provided
-to the wallet as part of the order URI.
+scheme with predictable order IDs from the merchant frontend is used) and at
+the same time malicious actors claiming orders is problematic (say because of
+limited stocks). The use of claim tokens is optional, but if a claim token is
+used, it must be provided to the wallet as part of the order URI.
Additionally, when stocks are limited, you can configure Taler to set a
*product lock* on items (say, while composing the shopping cart). These
@@ -220,23 +238,28 @@ locks will ensure that the limited stock is respected
when making offers
to consumers.
A wallet may *pay* for a claimed order, at which point the order turns into a
-(paid) contract. Orders have an configurable expiration date (the
+(paid) *contract*. Orders have a configurable expiration date (the
``pay_deadline``) after which the commercial offer expires and any stock of
products *locked* by the order will be automatically released, allowing the
-stock to be sold in other orders.
+stock to be sold in other orders. When an unpaid order expires, the customer
+must request a fresh order if they still want to make a purchase.
Once a contract has been paid, the merchant should fulfill the contract. It
is possible for the merchant to *refund* a contract order, for example if the
contract cannot be fulfilled after all. Refunds are only possible after the
customer paid and before the exchange has *wired* the payment to the
merchant. Once the funds have been wired, refunds are no longer allowed by the
-Taler exchange. The *wire deadline* specifies the latest time by which an
-exchange must wire the funds, while the (earlier) *refund deadline* specifies
-the earliest time when an exchange may wire the funds.
+Taler exchange. The *wire deadline* specifies the latest point in time by
+which an exchange must wire the funds, while the (earlier) *refund deadline*
+specifies the earliest point in time when an exchange may wire the funds.
+Thus, refunds are always possible between the time of purchase and the
+refund deadline, but may remain possible until the wire deadline.
+
+Contract information is kept for legal reasons in the merchant database. The
+main legal reason is typically to provide tax records in case of a tax audit.
+After the *legal expiration* (by default: a decade), contract information is
+deleted when running the garbage collector using ``taler-merchant-dbinit``.
-Contract information is kept for legal reasons, typically to provide tax
-records in case of a tax audit. After the *legal expiration* (by default a
-decade), contract information is deleted.
Transfers
---------
@@ -245,11 +268,13 @@ Transfers
.. index:: wire transfer
The Taler backend can be used to verify that the exchange correctly wired all
-of the funds to the merchant. However, the backend does not have access to the
-incoming wire transfers of the merchant's bank account. Thus, merchants must
-manually provide the backend with wire *transfer* data that specifies the wire
-transfer subject and the amount that was received. Given this information, the
-backend can detect and report any irregularities that might arise.
+of the funds to the merchant. However, if no `Taler Bank Merchant HTTP API
+<taler-bank-merchant-http-api>`_ was provided for the respective bank account,
+the backend does not have access to the incoming wire transfers of the
+merchant's bank account. In this case, merchants must manually provide the
+backend with wire *transfer* data that specifies the *wire transfer subject*
+and the amount that was received. Given this information, the backend can
+detect and report any irregularities that might arise.
Tipping
-------
@@ -267,6 +292,13 @@ can create tips, it must establish a reserve. Once a
reserve has been
established, the merchant can *grant* tips, allowing wallets to *pick up*
the tip.
+ ..note::
+
+ Tipping is an optional feature, and exchanges may disable tipping (usually
+ if they see compliance issues). In this case, the tipping feature will
+ not be available.
+
+
Reserves
--------
@@ -281,6 +313,9 @@ exchange.
An exchange will automatically *close* a reserve after a fixed period of time
(typically about a month), wiring any remaining funds back to the merchant.
+While exchange APIs exists to (1) explicitly *open* a reserve to prevent it
+from being automatically closed and to (2) explicitly *close* a reserve at any
+time, the current merchant backend does not make use of these APIs.
Installation
@@ -299,13 +334,7 @@ merchant backend from source.
The package sources can be find in our
`download directory <http://ftpmirror.gnu.org/taler/>`__.
-GNU Taler components version numbers follow the ``MAJOR.MINOR.MICRO`` format.
-The general rule for compatibility is that ``MAJOR`` and ``MINOR`` must match.
-Exceptions to this general rule are documented in the release notes.
-For example, Taler merchant 1.3.0 should be compatible with Taler exchange
1.4.x
-as the MAJOR version matches. A MAJOR version of 0 indicates experimental
-development, and you are expected to always run all of the *latest* releases
-together (no compatibility guarantees).
+.. include:: frags/semver.rst
First, the following packages need to be installed before we can compile the
backend:
@@ -363,17 +392,15 @@ How to configure the merchant’s backend
The installation already provides reasonable defaults for most of the
configuration options. However, some must be provided, in particular the
-database account and bank account that the backend should use. By
-default, the file ``$HOME/.config/taler.conf`` is where the Web shop
-administrator specifies configuration values that augment or override
-the defaults. The format of the configuration file is the well-known INI
-file format. You can edit the file by hand, or use the ``taler-config``
-commands given as examples.
+database that the backend should use. By default, the file
+``$HOME/.config/taler.conf`` is where the Web shop administrator specifies
+configuration values that augment or override the defaults.
+Note that when using our binary packages, the systemd service files
+force the use of ``/etc/taler.conf`` as the main configuration file.
.. include:: frags/configuration-format.rst
-
.. include:: frags/using-taler-config.rst
@@ -394,8 +421,8 @@ Backend options
.. index:: wire format
The following table describes the options that commonly need to be
-modified. Here, the notation ``[$section]/$option`` denotes the option
-``$option`` under the section ``[$section]`` in the configuration file.
+modified. Here, the notation ``[$SECTION]/$OPTION`` denotes the option
+``$OPTION`` under the section ``[$SECTION]`` in the configuration file.
Service address
@@ -406,13 +433,13 @@ merchant backend:
.. code-block:: ini
- [MERCHANT]/SERVE = TCP | UNIX
+ [MERCHANT]/SERVE = tcp | unix
-If given,
+If this option is set to
-- ``TCP``, then we need to set the TCP port in ``[MERCHANT]/PORT``
+- ``tcp`` then we need to set the TCP port in ``[MERCHANT]/PORT``;
-- ``UNIX``, then we need to set the unix domain socket path and mode
+- ``unix`` then we need to set the unix domain socket path and mode
in ``[MERCHANT]/UNIXPATH`` and ``[MERCHANT]/UNIXPATH_MODE``. The
latter takes the usual permission mask given as a number, e.g. 660
for user/group read-write access.
@@ -426,7 +453,7 @@ To run the Taler backend on TCP port 8888, use:
.. code-block:: console
- $ taler-config -s MERCHANT -o SERVE -V TCP
+ $ taler-config -s MERCHANT -o SERVE -V tcp
$ taler-config -s MERCHANT -o PORT -V 8888
.. note::
@@ -434,13 +461,12 @@ To run the Taler backend on TCP port 8888, use:
When using the Debian/Ubuntu packages, these options are already
configured in the ``/etc/taler/conf.d/merchant.conf`` configuration file.
- If you need to change them, you should edit
``/etc/taler/merchant-overrides.conf``,
- for example by passing ``-c /etc/taler/merchant-overrides.conf`` to the
- ``taler-config`` commands above. By default, the Taler merchant
- package when installed on Debian/Ubuntu will use a UNIX domain socket
- at ``/run/taler/merchant-httpd/merchant-http.sock``. For the best possible
- security, it is recommended to leave this in place and configure a reverse
- proxy (nginx or Apache) as described below.
+ If you need to change them, you should edit
+ ``/etc/taler/merchant-overrides.conf``. By default, the Taler merchant
+ package will use a UNIX domain socket at
+ ``/run/taler/merchant-httpd/merchant-http.sock``. For the best possible
+ security it is recommended to leave this in place and configure a reverse
+ proxy (Nginx or Apache) as described below.
@@ -454,9 +480,9 @@ specified using the option
[TALER]/CURRENCY
-For testing purposes, the currency MUST match “KUDOS” so that tests
-will work with the Taler demonstration exchange at
-https://exchange.demo.taler.net/:
+When testing with the Taler demonstration exchange at
+https://exchange.demo.taler.net/ you must set this
+value to ``KUDOS``:
.. code-block:: console
@@ -492,21 +518,21 @@ DBMS-specific options to access the database.
When using the Debian/Ubuntu packages, the database should already
be configured in the ``/etc/taler/secrets/merchant-db.secret.conf``
- configuration file. The ``talermerchant`` database is also already
- configured (unless you answered ``no`` when asked the question during
- installation), so you can skip everything in this section.
+ configuration file. The ``talermerchant`` database should also already
+ be configured, so you should be able to skip everything in this section
+ when using our binary packages.
-For the ``postgres`` backend, you need to provide:
+For the ``postgres`` backend, you need to specify:
.. code-block:: ini
- [MERCHANTDB-postgres]/CONFIG
+ [MERCHANTDB-postgres]
+ CONFIG = "postgres://..."
-This option specifies a postgres access path using the format
-``postgres:///$DBNAME``, where ``$DBNAME`` is the name of the
-PostgreSQL database you want to use. Suppose ``$USER`` is the name of
-the user who will run the backend process. Then, you need to first
-run:
+This option specifies a PostgreSQL access path, typicallly using the format
+``postgres:///$DBNAME``, where ``$DBNAME`` is the name of the PostgreSQL
+database you want to use. Suppose ``$USER`` is the name of the user who will
+run the backend process. Then, you need to first run:
.. code-block:: console
@@ -523,30 +549,19 @@ as ``$USER`` run:
to create the backend’s database. Here, ``$DBNAME`` must match the
database name given in the configuration file.
-To configure the Taler backend to use this database, run:
-
-.. code-block:: console
-
- $ taler-config -s MERCHANTDB-postgres -o CONFIG \
- -V postgres:///$DBNAME
-
-Now you should create the tables and indices. To do this, run as ``$USER``:
+Now you should be able to create the tables and indices. To do this, run as
+``$USER``:
.. code-block:: console
$ taler-merchant-dbinit
-
-You can improve your security posture if you now REVOKE the rights to CREATE,
+You may improve your security posture if you now REVOKE the rights to CREATE,
DROP or ALTER tables from ``$USER``. However, if you do so, please be aware
that you may have to temporarily GRANT those rights again when you update the
merchant backend. For details on how to REVOKE or GRANT these rights, consult
the PostgreSQL documentation.
-Commands, like ``taler-merchant-dbinit``, that support the ``-l LOGFILE``
-command-line option, send logging output to standard error by default.
-See :doc:`manpages/taler-merchant-dbinit.1` for more information.
-
.. include:: frags/db-stores-sensitive-data.rst
@@ -562,95 +577,42 @@ section, the following options need to be configured:
- The ``EXCHANGE_BASE_URL`` option specifies the exchange’s base URL.
For example, to use the Taler demonstrator, specify:
- .. code-block:: console
+ .. code-block:: ini
- $ taler-config -s MERCHANT-EXCHANGE-demo \
- -o EXCHANGE_BASE_URL \
- -V https://exchange.demo.taler.net/
+ [MERCHANT-EXCHANGE-demo]
+ EXCHANGE_BASE_URL = "https://exchange.demo.taler.net/";
- The ``MASTER_KEY`` option specifies the exchange’s master public key
in base32 encoding. For the Taler demonstrator, use:
- .. code-block:: console
+ .. code-block:: ini
- $ taler-config -s MERCHANT-EXCHANGE-demo \
- -o MASTER_KEY \
- -V FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0
+ [MERCHANT-EXCHANGE-demo]
+ MASTER_KEY = "FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0"
- The ``CURRENCY`` option specifies the exchange’s currency.
For the Taler demonstrator, use:
- .. code-block:: console
+ .. code-block:: ini
+
+ [MERCHANT-EXCHANGE-demo]
+ CURRENCY = "KUDOS"
- $ taler-config -s MERCHANT-EXCHANGE-demo \
- -o CURRENCY \
- -V KUDOS
Note that multiple exchanges can be added to the system by using different
-tokens in place of ``demo`` in the examples above. Note that all of the
-exchanges must use the same currency: If the currency does not match the main
-currency from the ``TALER`` section, the exchange is ignored. If you need to
-support multiple currencies, you need to configure a backend per currency.
+identifiers in place of ``demo`` in the example above. Note that all of the
+exchanges actually used will use the same currency: If the currency does not
+match the main ``CURRENCY`` option from the ``TALER`` section, the respective
+``MERCHANT-EXCHANGE-`` section is automatically ignored. If you need support
+for multiple currencies, you need to deploy one backend per currency.
.. note::
Manually setting up exchanges is only recommended under special
- circumstances. In general, GNU Taler will include trustworthy
- auditors (for each currency) in the default configuration, and
- there is rarely a good reason for trusting an exchange without
- an accredited auditor.
-
-
-
-Auditor
-^^^^^^^
-
-To add an auditor to the list of trusted auditors (which implies
-that all exchanges audited by this auditor will be trusted!)
-you create a section with a name that starts with “MERCHANT-AUDITOR-”. In
-4that section, the following options need to be configured:
-
-- The ``AUDITOR_BASE_URL`` option specifies the auditor’s base URL.
- For example, to use the Taler demonstrator's auditor, specify:
-
- .. code-block:: console
-
- $ taler-config -s MERCHANT-AUDITOR-demo \
- -o AUDITOR_BASE_URL \
- -V https://exchange.demo.taler.net/
-
-- The ``AUDITOR_KEY`` option specifies the auditor's public key
- in base32 encoding. For the Taler demonstrator, use:
-
- .. code-block:: console
-
- $ taler-config -s MERCHANT-AUDITOR-demo \
- -o AUDITOR_KEY \
- -V DSDASDXAMDAARMNAD53ZA4AFAHA2QADAMAHHASWDAWXN84SDAA11
-
-- The ``CURRENCY`` option specifies the auditor’s currency.
- For the Taler demonstrator, use:
-
- .. code-block:: console
-
- $ taler-config -s MERCHANT-AUDITOR-demo \
- -o CURRENCY \
- -V KUDOS
-
-
-Note that multiple auditors can be added to the system by using different
-tokens in place of ``demo`` in the examples above. Note that all of the
-auditors must use the same currency: If the currency does not match the main
-currency from the ``TALER`` section, the auditor is ignored. If you need to
-support multiple currencies, you need to configure a backend per currency.
-
-.. note::
-
- Manually adding auditors is only recommended under special
- circumstances. In general, GNU Taler will include trustworthy
- auditors (for each currency) in the default configuration, and
- there is rarely a good reason for adding an auditor that is
- not coordinating its activities with the Taler developers.
+ circumstances. In general, GNU Taler distributions will include trustworthy
+ exchanges (for each currency) in the default configuration, and there is
+ rarely a good reason for trusting an exchange that has no relationship
+ with the GNU Taler development team.
.. _Sample-backend-configuration:
@@ -682,23 +644,13 @@ The following is an example for a complete backend
configuration:
# will be ignored!
CURRENCY = KUDOS
- [merchant-auditor-NAME]
- AUDITOR_BASE_URL = https://auditor.demo.taler.net/
- AUDITOR_KEY = DSDASDXAMDAARMNAD53ZA4AFAHA2QADAMAHHASWDAWXN84SDAA11
- # If currency does not match [TALER] section, the auditor
- # will be ignored!
- CURRENCY = KUDOS
-
-Given the above configuration, the backend will use a database named
-``donations`` within PostgreSQL.
+Given the above configuration, the backend will use a PostgreSQL database
+named ``donations`` running on the same host.
The backend will deposit the coins it receives to the exchange at
https://exchange.demo.taler.net/, which has the master key
``FH1Y8ZMHCTPQ0YFSZECDH8C9407JR3YN0MF1706PTG24Q4NEWGV0``.
-Please note that ``doc/config.sh`` will walk you through all
-configuration steps, showing how to invoke ``taler-config`` for each of
-them.
.. _Launching-the-backend:
@@ -713,12 +665,21 @@ merchant backend as ``$USER`` using
.. code-block:: console
- $ taler-merchant-httpd
+ $ taler-merchant-httpd &
+ $ taler-merchant-webhook &
+ $ taler-merchant-wirewatch &
-To ensure the process runs always in the background and also after rebooting,
-you should use systemd, cron or some other init system of your operating
-system to launch the process. Consult the documentation of your operating
-system for how to start and stop daemons.
+You only need to run ``taler-merchant-webhook`` if one of the instances is
+configured to trigger web hooks. Similarly, ``taler-merchant-wirewatch`` is
+only required if instances have accounts configured with automatic import of
+wire transfers via a bank wire gateway.
+
+To ensure these processes runs always in the background and also after
+rebooting, you should use systemd, cron or some other init system of your
+operating system to launch the process. You should also periodically re-start
+these services to prevent them from exhausing the memory utilization of the
+PostgreSQL database. Consult the documentation of your operating system for
+how to start and stop daemons.
.. note::
@@ -742,7 +703,8 @@ If everything worked as expected, the command
should return some basic configuration status data about the service.
-Please note that your backend is right now likely globally reachable. You can
either:
+Please note that your backend might then be globally reachable without
+any access control. You can either:
* Use the ``--auth=$TOKEN`` command-line option to set an access token to be
provided in an ``Authorize: Bearer $TOKEN`` HTTP header. Note that this can be
used at anytime to override access control, but remains only in effect until a
first instance is created or an existing instance authentication setting is
modified.
* Set the ``TALER_MERCHANT_TOKEN`` environment variable to ``$TOKEN`` for
the same effect. This method has the advantage of ``$TOKEN`` not being visible
as a command-line interface to other local users on the same machine.
@@ -1381,135 +1343,6 @@ The database scheme used by the merchant looks as
follows:
-Configuration format
---------------------
-
-.. index:: configuration
-
-In Taler realm, any component obeys to the same pattern to get
-configuration values. According to this pattern, once the component has
-been installed, the installation deploys default values in
-``${prefix}/share/taler/config.d/``, in ``.conf`` files. In order to override
-these defaults, the user can write a custom .conf file and either pass
-it to the component at execution time, or name it ``taler.conf`` and place
-it under ``$HOME/.config/``.
-
-A config file is a text file containing sections, and each section
-contains its values. The right format follows:
-
-.. code-block:: ini
-
- [section1]
- value1 = string
- value2 = 23
-
- [section2]
- value21 = string
- value22 = /path22
-
-Throughout any configuration file, it is possible to use ``$``-prefixed
-variables, like ``$VAR``, especially when they represent filesystem
-paths. It is also possible to provide defaults values for those
-variables that are unset, by using the following syntax:
-``${VAR:-default}``. However, there are two ways a user can set
-``$``-prefixable variables:
-
-by defining them under a ``[paths]`` section, see example below,
-
-.. code-block:: ini
-
- [paths]
- TALER_DEPLOYMENT_SHARED = ${HOME}/shared-data
- ...
- [section-x]
- path-x = ${TALER_DEPLOYMENT_SHARED}/x
-
-or by setting them in the environment:
-
-.. code-block:: console
-
- $ export VAR=/x
-
-The configuration loader will give precedence to variables set under
-``[path]``, though.
-
-The utility ``taler-config``, which gets installed along with the
-exchange, serves to get and set configuration values without directly
-editing the ``.conf``. The option ``-f`` is particularly useful to resolve
-pathnames, when they use several levels of ``$``-expanded variables. See
-``taler-config --help``.
-
-Note that, in this stage of development, the file
-``$HOME/.config/taler.conf`` can contain sections for *all* the
-components. For example, both an exchange and a bank can read values from
-it.
-
-The `deployment repository <https://git.taler.net/deployment>`_ contains
examples of
-configuration file used in our demos. See under ``deployment/config``.
-
- **Note**
-
- Expectably, some components will not work just by using default
- values, as their work is often interdependent. For example, a
- merchant needs to know an exchange URL, or a database name.
-
-.. _Using-taler_002dconfig:
-
-Using taler-config
-^^^^^^^^^^^^^^^^^^
-
-.. index:: taler-config
-
-The tool ``taler-config`` can be used to extract or manipulate
-configuration values; however, the configuration use the well-known INI
-file format and can also be edited by hand.
-
-Run:
-
-.. code-block:: console
-
- $ taler-config -s $SECTION
-
-to list all of the configuration values in section ``$SECTION``.
-
-Run:
-
-.. code-block:: console
-
- $ taler-config -s $section -o $option
-
-to extract the respective configuration value for option ``$option`` in
-section ``$section``.
-
-Finally, to change a setting, run:
-
-.. code-block:: console
-
- $ taler-config -s $section -o $option -V $value
-
-to set the respective configuration value to ``$value``. Note that you
-have to manually restart the Taler backend after you change the
-configuration to make the new configuration go into effect.
-
-Some default options will use ``$``-variables, such as ``$DATADIR`` within
-their value. To expand the ``$DATADIR`` or other ``$``-variables in the
-configuration, pass the ``-f`` option to ``taler-config``. For example,
-compare:
-
-.. code-block:: console
-
- $ taler-config -s PATHS \
- -o TALER_DATA_HOME
- $ taler-config -f -s PATHS \
- -o TALER_DATA_HOME
-
-While the configuration file is typically located at
-``$HOME/.config/taler.conf``, an alternative location can be specified
-to ``taler-merchant-httpd`` and ``taler-config`` using the ``-c``
-option.
-
-
-
Advanced experimental features
==============================
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-docs] branch master updated: improve taler-merchant manual,
gnunet <=