summaryrefslogtreecommitdiff
path: root/taler-auditor-manual.rst
diff options
context:
space:
mode:
Diffstat (limited to 'taler-auditor-manual.rst')
-rw-r--r--taler-auditor-manual.rst31
1 files changed, 16 insertions, 15 deletions
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index d81b7ce8..be55ae9a 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -223,7 +223,7 @@ offline key, it is only used for a few cryptographic signatures and
thus the respective code can be run on modest hardware, like a
Raspberry Pi.
-The following values are to be configured in the section [auditor]:
+The following values are to be configured in the section ``[auditor]``:
- ``AUDITOR_PRIV_FILE``: Path to the auditor’s private key file.
@@ -238,7 +238,7 @@ Serving
The auditor can serve HTTP over both TCP and UNIX domain socket.
-The following values are to be configured in the section [auditor]:
+The following values are to be configured in the section ``[auditor]``:
- ``serve``: must be set to ``tcp`` to serve HTTP over TCP, or ``unix`` to serve
HTTP over a UNIX domain socket
@@ -266,7 +266,7 @@ documentation for details.
Database
--------
-The option ``DB`` under section [auditor] gets the DB backend’s name the
+The option ``DB`` under section ``[auditor]`` gets the DB backend’s name the
exchange is going to use. So far, only ``DB = postgres`` is supported. After
choosing the backend, it is mandatory to supply the connection string
(namely, the database name). This is possible in two ways:
@@ -276,15 +276,15 @@ choosing the backend, it is mandatory to supply the connection string
- via configuration option ``CONFIG``, under section ``[auditordb-BACKEND]``.
For example, the demo exchange is configured as follows:
-.. code-block:: ini
+ .. code-block:: ini
- [auditor]
- ...
- DB = postgres
- ...
+ [auditor]
+ ...
+ DB = postgres
+ ...
- [auditordb-postgres]
- CONFIG = postgres:///auditordemo
+ [auditordb-postgres]
+ CONFIG = postgres:///auditordemo
If an exchange runs its own auditor, it may use the same database for
the auditor and the exchange itself.
@@ -335,8 +335,7 @@ The equivalent step must be performed by the exchange operator.
Here, the exchange operator must use the ``taler-exchange-offline``
tool to add the auditor's public key, base URL and (business) name
to the list of approved auditors of the exchange. For details,
-see the exchange operator manual.
-# FIXME-ttn: add link please?
+see :ref:`Auditor-configuration` in the exchange operator manual.
.. _SigningDenominations:
@@ -349,14 +348,14 @@ Signing Denominations
This step must be performed regularly whenever the exchange is
deploying new denomination keys. After the exchange operator
has signed new keys using the ``taler-exchange-offline`` tool,
-each auditor should run
+each auditor should run:
.. code-block:: console
$ taler-auditor-offline download > input.json
to import the latest set of denomination keys. The key data
-should then be inspected using
+should then be inspected using:
.. code-block:: console
@@ -384,6 +383,8 @@ on its offline system) using:
The resulting ``output.json`` should then be copied to an online system,
and from there uploaded to the exchange using:
+.. code-block:: console
+
$ taler-auditor-offline upload < output.json
The contents of ``output.json`` can again be public and require no special
@@ -541,7 +542,7 @@ When an auditor detects that the private key of a denomination key pair has
been compromised, one important step is to revoke the denomination key. The
exchange operator includes the details on how to revoke a denomination key, so
the auditor should only have to report (and possibly enforce) this step.
--- FIXME-ttn: link to exchange chapter on revocations here?
+For more information, see :ref:`Revocations` in the exchange operator manual.
If all denominations of an exchange are revoked, the exchange includes logic
to wire back all returned funds to the bank accounts from which they