From b6b96eebb81ff3daecced9b43218ba8eb3268cce Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Thu, 6 Jan 2022 15:56:00 -0500 Subject: s/Postgres/PostgreSQL/g --- taler-auditor-manual.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'taler-auditor-manual.rst') diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst index cf3952f8..e7aecb84 100644 --- a/taler-auditor-manual.rst +++ b/taler-auditor-manual.rst @@ -65,7 +65,7 @@ all, the goal is to detect nerfarious activity of the exchange operator, which cannot be effectively done on a machine controlled by the exchange operator. -For this, every auditor needs to operate a Postgres database. The data +For this, every auditor needs to operate a PostgreSQL database. The data collected will include sensitive information about Taler users, including withdrawals made by consumers and income received by merchants. As a result, the auditor is expected to provide high confidentiality for the database. In @@ -118,7 +118,7 @@ third parties to verify one's own work. The Taler software stack for an auditor consists of the following components: -- DBMS: Postgres +- DBMS: PostgreSQL The auditor requires a DBMS to store a local copy of the transaction history for the Taler exchange, as well as for its own internal bookkeeping and checkpointing. @@ -128,7 +128,7 @@ components: concern that must be addressed manually. The software only verifies the content of a well-formed exchange database (well-formed with respect to SQL). For now, the GNU Taler reference implementation - only supports Postgres, but the code could be easily extended to + only supports PostgreSQL, but the code could be easily extended to support another DBMS. - The auditor Web service @@ -268,7 +268,7 @@ Additionally, there are two canonical system users of relevance (which your distribution would typically create for you): * www-data --- runs the HTTPS frontend (usually nginx or Apache) - * postgres --- runs the Postgres database + * postgres --- runs the PostgreSQL database Databases and users @@ -585,7 +585,7 @@ as illustrated in the following figure: .. image:: replication.png -First, the exchange should use standard Postgres replication features to +First, the exchange should use standard PostgreSQL replication features to enable the auditor to obtain a full copy of the exchange's database. Second, the auditor should make a "trusted" local copy, ensuring that it never replicates malicious changes using ``taler-auditor-sync``. Both @@ -595,7 +595,7 @@ We note that as a result of these steps, the auditor will have three databases: its own production primary database (as configured in ``auditordb-postgres``), its on production copy of the exchange's database (``exchangedb-postgress``), and a third, untrusted "ingres" copy of the -exchange database. The untrusted database should run as a separate Postgres +exchange database. The untrusted database should run as a separate PostgreSQL instance and is only accessed via ``taler-auditor-sync`` and the replication mechanism driven by the exchange operator. @@ -607,7 +607,7 @@ Ingres operation should be done using the ``auditor-ingres`` user --- or depending on the setup parts of the operation may be done by the ``postgres`` user directly. -The full copy can be obtained in various ways with Postgres. It is +The full copy can be obtained in various ways with PostgreSQL. It is possible to use log shipping with streaming replication as described in https://www.postgresql.org/docs/13/warm-standby.html, or to use logical replication, as described in @@ -616,7 +616,7 @@ that asynchronous replication should suffice. The resulting auditor database should be treated as read-only on the auditor side. The ``taler-exchange-dbinit`` tool can be used to setup the schema, or -the schema can be replicated using Postgres's standard mechanisms. The same +the schema can be replicated using PostgreSQL's standard mechanisms. The same applies for schema upgrades: if logical replication is used (which does not replicate schema changes), ``taler-exchange-dbinit`` can be used to migrate the schema(s) in both the ingres and production copies of the exchange's @@ -640,7 +640,7 @@ Wireguard. It is also necessary to edit ``main.cf`` of the exchange and on the auditor side to enable logical replication. If an exchange has multiple auditors, it should setup multiple ``egress`` accounts. The exchange must ensure that -the following lines are in the ``main.cf`` Postgres configuration (the port +the following lines are in the ``main.cf`` PostgreSQL configuration (the port may differ) to enable replication over the network: .. code-block:: @@ -650,7 +650,7 @@ may differ) to enable replication over the network: wal_level= logical Equally, the auditor must configure logical replication in the ``main.cf`` -Postgres configuration: +PostgreSQL configuration: .. code-block:: @@ -677,7 +677,7 @@ system must subscribe: $ echo "CREATE PUBLICATION $NAME FOR ALL TABLES;" | psql taler-exchange -For details, we refer to the Postgres manual. +For details, we refer to the PostgreSQL manual. .. note:: @@ -686,9 +686,9 @@ For details, we refer to the Postgres manual. ``DROP`` operations on the tables. Hence, the auditor cannot rely upon the exchange's primary copy to respect schema constraints, especially as we have to presume that the exchange could act maliciously. Furthermore, it - is unclear to what degree Postgres database replication mechanisms are + is unclear to what degree PostgreSQL database replication mechanisms are robust against a malicious master database. Thus, the auditor should - isolate its primary copy of the exchange database, including the Postgres + isolate its primary copy of the exchange database, including the PostgreSQL process, from its actual operational data. @@ -708,7 +708,7 @@ While ``taler-auditor-sync`` could in theory be run directly against the exchange's production system, this is likely a bad idea due to the high latency from the network between auditor and exchange operator. Thus, we recommend first making an "untrusted" ingress copy of the exchange's -production database using standard Postgres tooling, and then using +production database using standard PostgreSQL tooling, and then using ``taler-auditor-sync`` to create a second "safe" copy. The "safe" copy used by the production system should also run under a different UID. -- cgit v1.2.3