[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated: use ‘.. code-block:: console’ (88 in
|
From: |
gnunet |
|
Subject: |
[taler-docs] branch master updated: use ‘.. code-block:: console’ (88 instances) |
|
Date: |
Fri, 04 Dec 2020 10:07:49 +0100 |
This is an automated email from the git hooks/post-receive script.
ttn pushed a commit to branch master
in repository docs.
The following commit(s) were added to refs/heads/master by this push:
new ea4bfb4 use ‘.. code-block:: console’ (88 instances)
ea4bfb4 is described below
commit ea4bfb4f8903c2cb73f82b4f940323af745bf2b9
Author: Thien-Thi Nguyen <ttn@gnuvola.org>
AuthorDate: Fri Dec 4 04:06:16 2020 -0500
use ‘.. code-block:: console’ (88 instances)
---
libeufin/nexus-tutorial.rst | 166 ++++++++++++++++++++--------------------
taler-auditor-manual.rst | 30 ++++----
taler-backoffice-manual.rst | 6 +-
taler-exchange-manual.rst | 32 ++++----
taler-merchant-manual.rst | 132 ++++++++++++++++----------------
taler-merchant-pos-terminal.rst | 2 +-
taler-nfc-guide.rst | 8 +-
taler-wallet.rst | 18 ++---
8 files changed, 197 insertions(+), 197 deletions(-)
diff --git a/libeufin/nexus-tutorial.rst b/libeufin/nexus-tutorial.rst
index 82f1ba4..e919ed8 100644
--- a/libeufin/nexus-tutorial.rst
+++ b/libeufin/nexus-tutorial.rst
@@ -16,7 +16,7 @@ Obtain Nexus
============
Nexus belongs to the LibEuFin project, and can be downloaded via Git:
-.. code-block:: shell
+.. code-block:: console
$ git clone git://git.taler.net/libeufin
@@ -26,14 +26,14 @@ Install Nexus
=============
Navigate into the `libeufin` local repository, and from top-level run:
-.. code-block:: shell
+.. code-block:: console
$ ./gradlew -Pprefix=$PREFIX nexus:installToPrefix
$ ./gradlew -Pprefix=$PREFIX cli:installToPrefix
In case of success, the two following commands should be found:
-.. code-block:: shell
+.. code-block:: console
$ which libeufin-nexus
$ which libeufin-cli
@@ -43,7 +43,7 @@ Connect Nexus with a EBICS account
Use the following command to *(1) run the nexus service*:
-.. code-block:: shell
+.. code-block:: console
$ libeufin-nexus
@@ -55,7 +55,7 @@ for PostgreSQL will be provided.
At this point a *(2) superuser account needs to be activated
into the system*:
-.. code-block:: shell
+.. code-block:: console
$ libeufin-nexus superuser foo # Will interactively ask for password
@@ -75,74 +75,74 @@ creating a EBICS connection*.
set to ``foo``, and ``NEXUS_PASSWORD`` to the value given for its password
in step (2).
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connections \
- new-ebics-connection \
- --ebics-url $EBICS_BASE_URL \
- --host-id $EBICS_HOST_ID \
- --partner-id $EBICS_PARTNER_ID \
- --ebics-user-id $EBICS_USER_ID \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connections \
+ new-ebics-connection \
+ --ebics-url $EBICS_BASE_URL \
+ --host-id $EBICS_HOST_ID \
+ --partner-id $EBICS_PARTNER_ID \
+ --ebics-user-id $EBICS_USER_ID \
+ $CONNECTION_NAME
If the step above executed correctly, Nexus created all the cryptographic
material that is needed on the client side; in this EBICS example, it created
the signature and identification keys. It is therefore advisable to *(4) make
a backup copy* of such keys.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connections \
- export-backup \
- --passphrase $SECRET \
- --outputfile $BACKUP_FILE \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connections \
+ export-backup \
+ --passphrase $SECRET \
+ --outputfile $BACKUP_FILE \
+ $CONNECTION_NAME
At this point, Nexus must communicate all the details to the bank. Therefore,
it will *(5) synchronize the connection*. In this EBICS example, Nexus will
send
the *INI* and *HIA* messages to the bank.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connections \
- sync \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connections \
+ sync \
+ $CONNECTION_NAME
Once the connection is synchronized, Nexus needs to import locally the data
corresponding to the bank accounts offered by the bank connection just made.
The command below *(6) downloads the list of the bank accounts offered by the*
``$CONNECTION_NAME``.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connections \
- download-bank-accounts \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connections \
+ download-bank-accounts \
+ $CONNECTION_NAME
It is now possible to *(7) list the accounts offered by the connection*.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connections \
- list-offered-bank-accounts \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connections \
+ list-offered-bank-accounts \
+ $CONNECTION_NAME
Nexus now needs an explicit *(8) import of the accounts it needs to manage*.
This step is needed to let the user pick a custom name for such accounts.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli
- connections \
- import-bank-account \
- --offered-account-id $ACCOUNT_NATIVE_NAME \
- --nexus-bank-account-id $CUSTOM_RENAMING_FOR_ACCOUNT \
- $CONNECTION_NAME
+ $ libeufin-cli
+ connections \
+ import-bank-account \
+ --offered-account-id $ACCOUNT_NATIVE_NAME \
+ --nexus-bank-account-id $CUSTOM_RENAMING_FOR_ACCOUNT \
+ $CONNECTION_NAME
Once a Nexus user imported a bank account (``$CUSTOM_RENAMING_FOR_ACCOUNT``)
under a certain connection (``$CONNECTION_NAME``), it is possible
@@ -161,22 +161,22 @@ from the bank, and then ask it again to return the
results.
This command asks Nexus to *download the latest bank statements*:
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- accounts \
- fetch-transactions \
- $CUSTOM_RENAMING_FOR_ACCOUNT
+ $ libeufin-cli \
+ accounts \
+ fetch-transactions \
+ $CUSTOM_RENAMING_FOR_ACCOUNT
Once Nexus stored all the information in the database, the
client can ask to actually **see** the transactions:
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli
- accounts \
- transactions \
- $CUSTOM_RENAMING_FOR_ACCOUNT
+ $ libeufin-cli
+ accounts \
+ transactions \
+ $CUSTOM_RENAMING_FOR_ACCOUNT
Make a payment
==============
@@ -188,17 +188,17 @@ Payments pass through two phases: preparation and
submission.
The following command prepares a payment:
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- accounts \
- prepare-payment \
- --credit-iban $IBAN_TO_SEND_MONEY_TO \
- --credit-bic $BIC_TO_SEND_MONEY_TO \
- --credit-name $LEGAL_ENTITY_RECEIVING_THE_PAYMENT \
- --payment-amount $AMOUNT \
- --payment-subject $SUBJECT \
- $CUSTOM_RENAMING_FOR_ACCOUNT
+ $ libeufin-cli \
+ accounts \
+ prepare-payment \
+ --credit-iban $IBAN_TO_SEND_MONEY_TO \
+ --credit-bic $BIC_TO_SEND_MONEY_TO \
+ --credit-name $LEGAL_ENTITY_RECEIVING_THE_PAYMENT \
+ --payment-amount $AMOUNT \
+ --payment-subject $SUBJECT \
+ $CUSTOM_RENAMING_FOR_ACCOUNT
Note: the ``$AMOUNT`` value needs the format ``X.Y:CURRENCY``; for example
``10:EUR``, or ``1.01:EUR``.
@@ -207,13 +207,13 @@ The previous command should return a value (``$UUID``)
that uniquely
identifies the prepared payment in the Nexus system. It'll be needed
in the next step, to **send the payment instructions to the bank**:
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- accounts \
- submit-payment \
- --payment-uuid $UUID \
- $CUSTOM_RENAMING_FOR_ACCOUNT
+ $ libeufin-cli \
+ accounts \
+ submit-payment \
+ --payment-uuid $UUID \
+ $CUSTOM_RENAMING_FOR_ACCOUNT
Restore the backup
@@ -224,14 +224,14 @@ associated with one bank connection subscription. For
EBICS,
this means that the INI and HIA secret keys will be restored
for the requesting user.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- connection \
- restore-backup \
- --passphrase $SECRET \
- --outputfile $BACKUP_FILE \
- $CONNECTION_NAME
+ $ libeufin-cli \
+ connection \
+ restore-backup \
+ --passphrase $SECRET \
+ --outputfile $BACKUP_FILE \
+ $CONNECTION_NAME
Creating a Taler facade
=======================
@@ -245,14 +245,14 @@ At this moment, only the *Taler facade type* is
implemented
in the Nexus, and the command below will show how to instantiate
one under an existing bank account.
-.. code-block:: shell
+.. code-block:: console
- libeufin-cli \
- taler-facade \
- new-facade \
- --facade-name $FACADE_NAME \
- $CONNECTION_NAME \
- $CUSTOM_RENAMING_FOR_ACCOUNT
+ $ libeufin-cli \
+ taler-facade \
+ new-facade \
+ --facade-name $FACADE_NAME \
+ $CONNECTION_NAME \
+ $CUSTOM_RENAMING_FOR_ACCOUNT
At this point, the additional *taler-wire-gateway* (link here) API
becomes offered by the Nexus. The purpose is to let a Taler exchange
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index 35f5a79..8faadb6 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -221,7 +221,7 @@ to export some of the tooling required by Taler.
To download and install libgnunetutil, proceed as follows:
-::
+.. code-block:: console
$ git clone https://git.gnunet.org/gnunet/
$ cd gnunet/
@@ -237,7 +237,7 @@ which requires you to run the last step as ``root``.
To download and install the GNU Taler exchange, proceeds as follows:
-::
+.. code-block:: console
$ git clone git://git.taler.net/exchange
$ cd exchange
@@ -370,9 +370,9 @@ If this step is skipped, the auditor will malfunction at
all future
stages with a foreign key violation, as it doesn't know the exchange's
master public key.
-::
+.. code-block:: console
- taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL
+ $ taler-auditor-exchange -m $MASTER_PUB -u $EXCHANGE_BASE_URL
.. _AuditorDenominations:
@@ -392,9 +392,9 @@ receive the blob to sign (Website, manual delivery, ...).
Note that the
blob does not contain confidential data, but signing the wrong keys would
be fatal. Given the blob, the auditor would sign it using:
-::
+.. code-block:: console
- taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o
OUTPUT_FILE
+ $ taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o
OUTPUT_FILE
Those arguments are all mandatory.
@@ -467,7 +467,7 @@ Performing an audit is done by invoking the
``taler-auditor`` and
files, which can then be combined using the ``contrib/render.py``
script into the TeX report.
-::
+.. code-block:: console
$ taler-audit
@@ -510,7 +510,7 @@ several categories of failures of different severity:
the correct amount to a merchant).
- Configuration issues (such was wire fees unavailable)
-
+
.. _AuditorDatabaseUpgrades:
@@ -520,9 +520,9 @@ Database upgrades
To upgrade the database between Taler versions can be done by
running:
-::
+.. code-block:: console
- $ taler-auditor-dbinit
+ $ taler-auditor-dbinit
However, the above is the general rule. Please review the
specific release notes to ensure this is correct for the
@@ -531,7 +531,7 @@ specific upgrade.
The auditor database can be re-initialized using:
-::
+.. code-block:: console
$ taler-auditor-dbinit -r
@@ -654,7 +654,7 @@ CodeBlau reports the following checks:
coin value without fee, total deposit without refunds
- wire out fee is negative
-
+
- coin arithmetic inconsistencies
- refund (merchant) is negative
@@ -672,13 +672,13 @@ CodeBlau reports the following checks:
- wire out inconsistencies in amount
- row inconsistencies
-
+
- wire account given is malformed
- h(wire) does not match wire
- failed to compute hash of given wire data
-
+
- database contains wrong hash code for wire details
- no transaction history for coin claimed in aggregation
@@ -715,7 +715,7 @@ CodeBlau reports the following checks:
- arithmetic inconsistencies
- melt contribution vs. fee
-
+
- melt (cost)
- refund fee
diff --git a/taler-backoffice-manual.rst b/taler-backoffice-manual.rst
index d87f100..d9c57f2 100644
--- a/taler-backoffice-manual.rst
+++ b/taler-backoffice-manual.rst
@@ -26,7 +26,7 @@ The back-office Web service code is available at
``git://taler.net/backoffice``. The application can be installed in a
GNU-ish fashion.
-::
+.. code-block:: console
# Get the code:
$ git clone git://taler.net/backoffice
@@ -120,9 +120,9 @@ Launching the backoffice
The following example shows how to run the Web service.
-::
+.. code-block:: console
- # such invocation will work only if the configuration contains
+ # Such invocation will work only if the configuration contains
# a section called "[backoffice-myshop]" which looks like the
# example above.
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 0b03821..7e132d7 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -257,7 +257,7 @@ to export some of the tooling required by Taler.
To download and install libgnunetutil, proceed as follows:
-::
+.. code-block:: console
$ git clone git://git.gnunet.org/gnunet
$ cd gnunet/
@@ -273,7 +273,7 @@ which requires you to run the last step as ``root``.
To download and install the GNU Taler exchange, proceeds as follows:
-::
+.. code-block:: console
$ git clone git://git.taler.net/exchange
$ cd exchange
@@ -340,7 +340,7 @@ by defining them under a ``[paths]`` section, see example
below,
or by setting them in the environment:
-::
+.. code-block:: console
$ export VAR=/x
@@ -378,7 +378,7 @@ file format and can also be edited by hand.
Run
-::
+.. code-block:: console
$ taler-config -s $SECTION
@@ -386,7 +386,7 @@ to list all of the configuration values in section
``$SECTION``.
Run
-::
+.. code-block:: console
$ taler-config -s $section -o $option
@@ -395,7 +395,7 @@ section ``$section``.
Finally, to change a setting, run
-::
+.. code-block:: console
$ taler-config -s $section -o $option -V $value
@@ -408,7 +408,7 @@ 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 ACCOUNT-bank \
-o WIRE_RESPONSE
@@ -530,7 +530,7 @@ The command line tool taler-exchange-wire is used to create
the
follows to create all of the WIRE_RESPONSE files (in the locations
specified by the configuration):
-::
+.. code-block:: console
$ taler-exchange-wire
@@ -741,9 +741,9 @@ by the tool ``taler-exchange-keyup``. The following command
generates
denomkeys and signkeys, plus the "blob" that is to be signed by the
auditor.
-::
+.. code-block:: console
- taler-exchange-keyup -o blob
+ $ taler-exchange-keyup -o blob
*blob* contains data about denomkeys that the exchange operator needs to
get signed by every auditor he wishes (or is forced to) work with.
@@ -753,9 +753,9 @@ blob to sign (Website, manual delivery, ..). Nonetheless,
the exchange
admin can fake an auditor signature — for testing purposes — by running
the following command
-::
+.. code-block:: console
- taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o
OUTPUT_FILE
+ $ taler-auditor-sign -m EXCHANGE_MASTER_PUB -r BLOB -u AUDITOR_URL -o
OUTPUT_FILE
Those arguments are all mandatory.
@@ -775,9 +775,9 @@ option ``AUDITOR_BASE_DIR`` under the section
``[exchangedb]``. Assuming
following command will "add" the auditor identified by ``AUDITOR_URL``
to the exchange.
-::
+.. code-block:: console
- cp OUTPUT_FILE ${HOME}/.local/share/taler/auditors
+ $ cp OUTPUT_FILE ${HOME}/.local/share/taler/auditors
If the auditor has been correctly added, the exchange’s ``/keys``
response must contain an entry in the ``auditors`` array mentioning the
@@ -793,7 +793,7 @@ versions.
The exchange database can be re-initialized using:
-::
+.. code-block:: console
$ taler-exchange-dbinit -r
@@ -1008,7 +1008,7 @@ initialized using ``taler-exchange-keyup``.
You can run a first simple benchmark using:
-::
+.. code-block:: console
$ createdb talercheck # if it does not yet exist
$ taler-exchange-keyup -c benchmark.conf
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 617cc77..bf69c49 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -396,7 +396,7 @@ First, unpack the GNU Taler merchant tarball and change into
the resulting directory.
Then, use the following commands to build and install the merchant backend:
- ::
+.. code-block:: console
$ ./configure [--prefix=PFX] \
[--with-gnunet=GNUNETPFX] \
@@ -439,7 +439,7 @@ On Debian stretch, only GNU libmicrohttpd needs to be
compiled from
source. To install dependencies on Debian stretch, run the following
commands:
- ::
+.. code-block:: console
# apt-get install \
libltdl-dev \
@@ -461,7 +461,7 @@ commands:
For more recent versions of Debian, you should instead run:
- ::
+.. code-block:: console
# apt-get install \
libltdl-dev \
@@ -547,10 +547,10 @@ the backend to the network.
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 PORT -V 8888
+ $ taler-config -s MERCHANT -o SERVE -V TCP
+ $ taler-config -s MERCHANT -o PORT -V 8888
@@ -568,9 +568,9 @@ For testing purposes, the currency MUST match “KUDOS” so
that tests
will work with the Taler demonstration exchange at
https://exchange.demo.taler.net/:
- ::
+.. code-block:: console
- $ taler-config -s TALER -o CURRENCY -V KUDOS
+ $ taler-config -s TALER -o CURRENCY -V KUDOS
Database
@@ -601,33 +601,33 @@ Postgres 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
- $ sudo -u postgres createuser -d $USER
+ $ sudo -u postgres createuser -d $USER
as the Postgres database administrator (usually ``postgres``) to
grant ``$USER`` the ability to create new databases. Next, you should
as ``$USER`` run:
- ::
+.. code-block:: console
- $ createdb $DBNAME
+ $ createdb $DBNAME
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
+ $ taler-config -s MERCHANTDB-postgres -o CONFIG \
+ -V postgres:///$DBNAME
Now you should create the tables and indices. To do this, run as ``$USER``:
- ::
+.. code-block:: console
- $ taler-merchant-dbinit
+ $ taler-merchant-dbinit
You can improve your security posture if you now REVOKE the rights to CREATE,
@@ -650,29 +650,29 @@ 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
$ taler-config -s MERCHANT-EXCHANGE-demo \
- -o EXCHANGE_BASE_URL \
- -V https://exchange.demo.taler.net/
+ -o EXCHANGE_BASE_URL \
+ -V 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
$ taler-config -s MERCHANT-EXCHANGE-demo \
- -o MASTER_KEY \
- -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00
+ -o MASTER_KEY \
+ -V CQQZ9DY3MZ1ARMN5K1VKDETS04Y2QCKMMCFHZSWJWWVN82BTTH00
- The “CURRENCY” option specifies the exchange’s currency.
For the Taler demonstrator, use:
- ::
+ .. code-block:: console
$ taler-config -s MERCHANT-EXCHANGE-demo \
- -o CURRENCY \
- -V KUDOS
+ -o CURRENCY \
+ -V KUDOS
Note that multiple exchanges can be added to the system by using different
tokens in place of ``demo`` in the example above. Note that all of the
@@ -693,29 +693,29 @@ that 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/
+ -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 FIXMEBADVALUENEEDTOGETTHERIGHTVALUEHEREEVENTUALLY000
+ -o AUDITOR_KEY \
+ -V FIXMEBADVALUENEEDTOGETTHERIGHTVALUEHEREEVENTUALLY000
- 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
+ -o CURRENCY \
+ -V KUDOS
Note that multiple auditors can be added to the system by using different
@@ -783,7 +783,7 @@ Launching the backend
Assuming you have configured everything correctly, you can launch the
merchant backend as ``$USER`` using
- ::
+.. code-block:: console
$ taler-merchant-httpd
@@ -794,7 +794,7 @@ system for how to start and stop daemons.
If everything worked as expected, the command
- ::
+.. code-block:: console
$ curl http://localhost:8888/
@@ -883,7 +883,7 @@ For details, see the :ref:`contract terms <contract-terms>`
specification.
You can then create the instance using:
- ::
+.. code-block:: console
$ wget --post-file=instance.json http://localhost:8888/private/instances
@@ -916,10 +916,10 @@ Using UNIX domain sockets
To ensure that the merchant backend is not exposed directly to the network,
you *should* bind the backend to a UNIX domain socket:
- ::
+.. code-block:: console
- $ taler-config -s MERCHANT -o SERVE -V UNIX
- $ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock
+ $ taler-config -s MERCHANT -o SERVE -V UNIX
+ $ taler-config -s MERCHANT -o UNIXPATH -V /some/path/here.sock
Do not use a UNIX domain socket path in "/tmp": systemd (or other init
systems) may give Web servers a private "/tmp" thereby hiding UNIX domain
@@ -958,11 +958,11 @@ Apache
In Apache, make sure you have "mod_proxy", "mod_proxy_http" and
"mod_headers" enabled:
- ::
+.. code-block:: console
- a2enmod proxy
- a2enmod proxy_http
- a2enmod headers
+ $ a2enmod proxy
+ $ a2enmod proxy_http
+ $ a2enmod headers
Then configure your Apache reverse proxy like this (you may change the
endpoint):
@@ -1053,9 +1053,9 @@ Apache
For Apache, you should first enable "mod_rewrite":
- ::
+.. code-block:: console
- a2enmod rewrite
+ $ a2enmod rewrite
Then, you can restrict to an access control token using:
@@ -1187,17 +1187,17 @@ manual), and then install the latest version of the
code.
If you REVOKED database permissions, ensure that the rights to CREATE,
DROP, and ALTER tables are GRANTed to ``$USER`` again. Then, run:
- ::
+.. code-block:: console
- $ taler-merchant-dbinit
+ $ taler-merchant-dbinit
to upgrade the database to the latest schema. After that, you may again
REVOKE the database permissions. Finally, restart the HTTP service, either via
your systemd or init system, or directly using:
- ::
+.. code-block:: console
- $ taler-merchant-httpd
+ $ taler-merchant-httpd
.. _Tipping-visitors:
@@ -1226,9 +1226,9 @@ First, the reserve must be setup in the merchant backend.
A reserve
is always tied to a particular instance. To create a reserve with
10 KUDOS at instance "default" using the demo exchange, use:
- ::
+.. code-block:: console
- $ taler-merchant-setup-reserve \
+ $ taler-merchant-setup-reserve \
-a KUDOS:10 \
-e https://exchange.demo.taler.net/ \
-m http://localhost:8888/instances/default
@@ -1376,7 +1376,7 @@ by defining them under a ``[paths]`` section, see example
below,
or by setting them in the environment:
-::
+.. code-block:: console
$ export VAR=/x
@@ -1416,7 +1416,7 @@ file format and can also be edited by hand.
Run
-::
+.. code-block:: console
$ taler-config -s $SECTION
@@ -1424,7 +1424,7 @@ to list all of the configuration values in section
``$SECTION``.
Run
-::
+.. code-block:: console
$ taler-config -s $section -o $option
@@ -1433,7 +1433,7 @@ section ``$section``.
Finally, to change a setting, run
-::
+.. code-block:: console
$ taler-config -s $section -o $option -V $value
@@ -1446,7 +1446,7 @@ 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
@@ -1516,10 +1516,10 @@ exist before launching the benchmark. You also
will need to ensure that the Exchange's
details are setup, usually by running
- ::
+.. code-block:: console
- taler-exchange-wire -c $CONFIG_FILE
- taler-exchange-keyup -c $CONFIG_FILE
+ $ taler-exchange-wire -c $CONFIG_FILE
+ $ taler-exchange-keyup -c $CONFIG_FILE
where "$CONFIG_FILE" should be replaced by
the configuration file that is to be used.
@@ -1551,7 +1551,7 @@ Any subcommand is also equipped with the canonical
``--help`` option, so
feel free to issue the following command in order to explore all the
possibilities. For example:
-::
+.. code-block:: console
$ taler-merchant-benchmark corner --help
@@ -1610,14 +1610,14 @@ Because all of the Docker source file are kept in our
“deployment“
repository, we start by checking out the ``git://git.taler.net/deployment``
codebase:
-::
+.. code-block:: console
$ git clone git://git.taler.net/deployment
Now we actually build the merchant’s image. From the same directory as
above:
-::
+.. code-block:: console
$ cd deployment/docker/merchant/
$ docker-compose build
@@ -1625,7 +1625,7 @@ above:
If everything worked as expected, the merchant is ready to be launched.
From the same directory as the previous step:
-::
+.. code-block:: console
# Recall: the docker-machine should be up and running.
$ docker-compose up
@@ -1637,7 +1637,7 @@ message from postresql about already existing roles and
databases.
To test if everything worked as expected, it suffices to issue a simple
request to the merchant, as:
-::
+.. code-block:: console
$ curl http://$(docker-machine ip)/
# A greeting message should be returned by the merchant.
diff --git a/taler-merchant-pos-terminal.rst b/taler-merchant-pos-terminal.rst
index 8bf5031..b81eb33 100644
--- a/taler-merchant-pos-terminal.rst
+++ b/taler-merchant-pos-terminal.rst
@@ -86,7 +86,7 @@ Building from source
Import in and build with Android Studio or run on the command line:
-.. code-block:: sh
+.. code-block:: console
$ git clone https://git.taler.net/merchant-terminal-android.git
$ cd merchant-terminal-android
diff --git a/taler-nfc-guide.rst b/taler-nfc-guide.rst
index 8143387..1b3cfb1 100644
--- a/taler-nfc-guide.rst
+++ b/taler-nfc-guide.rst
@@ -48,7 +48,7 @@ using `curl <https://curl.haxx.se/docs/manpage.html>`_ to
make HTTP(S) requests.
The following :http:post:`/private/orders` request to the merchant backend
creates a
simple order:
- .. code-block:: sh
+ .. code-block:: console
$ backend_base_url=https://backend.demo.taler.net/
$ auth_header='Authorization: ApiKey sandbox'
@@ -71,7 +71,7 @@ using `curl <https://curl.haxx.se/docs/manpage.html>`_ to
make HTTP(S) requests.
2. The merchant checks the payment status of the order using
:http:get:`/private/orders/$ORDER_ID`:
- .. code-block:: sh
+ .. code-block:: console
$ backend_base_url=https://backend.demo.taler.net/
$ auth_header='Authorization: ApiKey sandbox'
@@ -97,7 +97,7 @@ using `curl <https://curl.haxx.se/docs/manpage.html>`_ to
make HTTP(S) requests.
3. The wallet processes the ``taler://pay/`` URI. In this example, we use the
command-line wallet:
- .. code-block:: sh
+ .. code-block:: console
# Withdraw some toy money (KUDOS) from the demo bank
$ taler-wallet-cli test-withdraw \
@@ -116,7 +116,7 @@ using `curl <https://curl.haxx.se/docs/manpage.html>`_ to
make HTTP(S) requests.
4. The merchant checks the payment status again:
- .. code-block:: sh
+ .. code-block:: console
$ backend_base_url=https://backend.demo.taler.net/
$ auth_header='Authorization: ApiKey sandbox'
diff --git a/taler-wallet.rst b/taler-wallet.rst
index d9f9d7f..18ae049 100644
--- a/taler-wallet.rst
+++ b/taler-wallet.rst
@@ -13,7 +13,7 @@ The command-line wallet is used primarily for testing by
developers.
Building from source
--------------------
-.. code-block:: sh
+.. code-block:: console
$ git clone https://git.taler.net/wallet-core.git
$ cd wallet-core
@@ -30,7 +30,7 @@ The wallet can also obtained via NPM, the Node Package
Manager.
To install the wallet as a global package, run:
-.. code-block:: sh
+.. code-block:: console
$ npm install -g taler-wallet
# check if installation was successful
@@ -38,7 +38,7 @@ To install the wallet as a global package, run:
To install the wallet only for your user, run:
-.. code-block:: sh
+.. code-block:: console
$ npm install -g --prefix=$HOME/local taler-wallet
# check if installation was successful
@@ -47,7 +47,7 @@ To install the wallet only for your user, run:
To use the wallet as a library in your own project, run:
-.. code-block:: sh
+.. code-block:: console
$ npm install taler-wallet
@@ -55,7 +55,7 @@ To use the wallet as a library in your own project, run:
Manual withdrawing
==================
-.. code-block:: sh
+.. code-block:: console
$ taler-wallet-cli advanced withdraw-manually \
--exchange https://exchange.eurint.taler.net/ \
@@ -67,7 +67,7 @@ WebExtension Wallet
Building from source
--------------------
-.. code-block:: sh
+.. code-block:: console
$ git clone https://git.taler.net/wallet-core.git
$ cd wallet-core
@@ -1093,7 +1093,7 @@ the subcommands. If the database file doesn't exist, it
will be created.
The following example does a simple withdrawal recoup:
-.. code-block:: sh
+.. code-block:: console
# Withdraw digital cash
$ taler-wallet-cli --wallet-db=mydb.json testing withdraw \
@@ -1140,7 +1140,7 @@ The following example does a simple withdrawal recoup:
To test refreshing, force a refresh:
-.. code-block:: sh
+.. code-block:: console
$ taler-wallet-cli --wallet-db=mydb.json advanced force-refresh "$coin_pub"
@@ -1148,7 +1148,7 @@ To test refreshing, force a refresh:
To test zombie coins, use the timetravel option. It **must** be passed to the
top-level command and not the subcommand:
-.. code-block:: sh
+.. code-block:: console
# Update exchange /keys with time travel, value in microseconds
$ taler-wallet-cli --timetravel=1000000 --wallet-db=mydb.json \
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-docs] branch master updated: use ‘.. code-block:: console’ (88 instances),
gnunet <=