|author||Christian Grothoff <email@example.com>||2021-01-04 16:42:03 +0100|
|committer||Christian Grothoff <firstname.lastname@example.org>||2021-01-04 16:42:03 +0100|
fix syntax issues
Diffstat (limited to 'taler-exchange-manual.rst')
1 files changed, 4 insertions, 3 deletions
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 04213de..8cda73e 100644
@@ -59,7 +59,7 @@ license and/or follow applicable financial regulation.
GNU Taler payment service providers generally need to ensure high
availability and have *really* good backups (synchronous replication,
asynchronous remote replication, off-site backup, 24/7 monitoring,
-etc.). _ This manual will not cover these aspects of operating a
+etc.). This manual will not cover these aspects of operating a
payment service provider.
We will assume that you can operate a (high-availability,
@@ -167,13 +167,14 @@ components:
is used by the aggregator to execute wire transfers and for the
auditor to query bank transaction histories.
-.. index:: Postgres
The exchange requires a DBMS to stores the transaction history for
the Taler exchange and aggregator, and a (typically separate) DBMS
for the Taler auditor. For now, the GNU Taler reference implementation
only supports Postgres, but the code could be easily extended to
support another DBMS.
+ .. index:: Postgres
The auditor verifies that the transactions performed by the exchange
@@ -205,7 +206,7 @@ private offline key on more than one physical medium though.)
Exchange operators are strongly advised to secure your private master key and
any copies on encrypted, always-offline computers. Again, we assume that you
are familiar with good best practices in operational security, including
-securing key material. _
+securing key material.