diff options
Diffstat (limited to 'taler-auditor-manual.rst')
-rw-r--r-- | taler-auditor-manual.rst | 31 |
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 |