aboutsummaryrefslogtreecommitdiff
path: root/doc/taler-exchange.texi
blob: 350174f0345c924c9dee265c189f28c6e46cdda5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
\input texinfo   @c -*-texinfo-*-
@setfilename taler-exchange.info
@documentencoding UTF-8
@include version.texi
@settitle The GNU Taler Exchange Operator Manual
@paragraphindent 0
@exampleindent 4

@copying
This manual is for the GNU Taler Exchange
(version @value{VERSION}, @value{UPDATED}),
a payment service provider for GNU Taler.

Copyright @copyright{} 2014-2017 GNUnet e.V. and INRIA

@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts.  A copy of the license is included in the section entitled "GNU
Free Documentation License".
@end quotation
@end copying

@dircategory Network applications
@direntry
* GNU Taler Exchange: (taler-exchange).       Electronic payment system.
@end direntry


@titlepage
@title The GNU Taler Exchange Operator Manual
@subtitle Version @value{VERSION}
@subtitle @value{UPDATED}
@author Christian Grothoff (@email{grothoff@@taler.net})
@author Marcello Stanisci (@email{stanisci@@taler.net})
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@summarycontents
@contents

@ifnottex
@node Top
@top The GNU Taler Exchange Operator Manual
@insertcopying
@end ifnottex


@menu
* Introduction::
* Installation::
* Configuration::
* Deployment::
* Diagnostics::



Appendices

* GNU-AGPL::                    The GNU Affero General Public License says how you
                                can copy and share the code of the `GNU Taler Exchange'.
* GNU-FDL::                     The GNU Free Documentation License says how you
                                can copy and share the documentation of `GNU Taler'.

Indices

* Concept Index::               Index of concepts and programs.
@end menu

@node Introduction
@chapter Introduction

This manual is an early draft that still needs significant editing
work to become readable.


@section About GNU Taler

GNU Taler is an open protocol for an electronic payment system with a
free software reference implementation.  GNU Taler offers secure, fast
and easy payment processing using well understood cryptographic
techniques.  GNU Taler allows customers to remain anonymous, while
ensuring that merchants can be held accountable by governments.
Hence, GNU Taler is compatible with anti-money-laundering (AML) and
know-your-customer (KYC) regulation, as well as data protection
regulation (such as GDPR).

GNU Taler is not yet production-ready, after following this manual
you will have a backend that can process payments in ``KUDOS'', but
not regular currencies.  This is not so much because of limitations
in the backend, but because we are not aware of a Taler exchange
operator offering regular currencies today.

@section About this manual

This tutorial targets system administrators who want to install and
operate a GNU Taler exchange.

@section Organizational prerequisites

Operating a GNU Taler exchange means that you are operating a payment
service provider, which means that you will most likely need a bank
license and/or follow applicable financial regulation.

@cindex availability
@cindex backup
@cindex replication
GNU Taler payment service providers generally need to ensure high
availability and have @emph{really} good backups (synchronous
replication, asynchronous remote replication, off-site backup, 24/7
monitoring, etc.).@footnote{Naturally, you could operate a Taler
exchange for a toy currency without any real value on low-cost setups
like a Raspberry Pi, but we urge you to limit the use of such setups
to research and education as with GNU Taler data loss instantly
results in financial losses.}  This manual will not cover these
aspects of operating a payment service provider.

@cindex HSM
@cindex offline
@cindex database
@cindex operational security
We will assume that you can operate a (high-availability,
high-assurance) Postgres database.  Furthermore, we expect some
moderate familiarity with the compilation and installation of free
software packages.  You need to understand the cryptographic concepts
of private and public keys and must be able to protect private keys
stored in files on disk.  An exchange uses an @emph{offline} master
key as well as @emph{online} keys.  You are 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.@footnote{The current implementation does not make provisions
for secret splitting.  Still, the use of a hardware security module
(HSM) for protecting private keys is adviseable, so please contact the
developers for HSM integration support.}


@section Architecture overview

@cindex crypto-currency
@cindex bank
@cindex escrow
@cindex coin
Taler is a pure payment system, not a new crypto-currency. As such, it
operates in a traditional banking context.  In particular, this means
that in order to receive funds via Taler, the merchant must have a
regular bank account, and payments can be executed in ordinary
currencies such as USD or EUR.  Similarly, the Taler exchange must
interact with a bank.  The bank of the exchange holds the exchange's
funds in an escrow account.

@cindex reserve
@cindex fee
@cindex aggregator
@cindex deposit
When customers wire money to the escrow account, the bank notifies
the exchange about the incoming wire transfers.  The exchange then
creates a @emph{reserve} based on the subject of the wire transfer.
The wallet which knows the secret key matching the wire transfer
subject can then withdraw coins from the reserve, thereby draining
it.  The liability of the exchange against the reserve is thereby
converted into a liability against digital coins issued by the
exchange.  When the customer later spends the coins at a merchant,
and the merchant @emph{deposits} the coins at the exchange, the
exchange first @emph{aggregates} the amount from multiple deposits
from the same merchant and then instructs its bank to make a
wire transfer to the merchant, thereby fulfilling its obligation
and eliminating the liability.  The exchange charges @emph{fees}
for some or all of its operations to cover costs and possibly make
a profit.

@cindex auditor
@cindex accounting
@emph{Auditors} are third parties, for example financial regulators,
that verify that the exchange operates correctly.  The same software
is also used to calculate the exchange's profits, risk and liabilities
by the accountants of the exchange.

The Taler software stack for an exchange consists of the
following components:

@itemize
@cindex HTTP frontend
@item The HTTP frontend interacts with Taler wallets and
  merchant backends.  It is used to withdraw coins, deposit
  coins, refresh coins, issue refunds, map wire transfers to
  Taler transactions, inquire about the exchange's bank account
  details, signing keys and fee structure.
  The binary is the @code{taler-exchange-httpd}.
@cindex Aggregator
@item The aggregator combines multiple deposits made by
  the same merchant and (eventually) triggers wire transfers for the
  aggregate amount.  The merchant can control how quickly wire
  transfers are made. The exchange may be charge a fee per wire transfer
  to discourage excessively frequent transfers.  The binary
  is the @code{taler-exchange-aggregator}.
@cindex Auditor
@item The auditor verifies that the transactions performed by
  the exchange were done properly. It checks the various signatures,
  totals up the amounts and alerts the operator to any inconsistencies.
  It also computes the expected bank balance, revenue and risk exposure
  of the exchange operator.  The main binary is the
  @code{taler-auditor}.
@cindex Wire plugin
@item A wire plugin enables the HTTP frontend to talk to the
  bank. Its role is to allow the exchange to validate bank
  addresses (i.e. IBAN numbers), for the aggregator to execute
  wire transfers and for the auditor to query bank transaction
  histories.  Wire plugins are @emph{plugins} as there can be
  many different implementations to deal with different
  banking standards.  Wire plugins are automatically located
  and used by the exchange, aggregator and auditor.
@cindex DBMS
@cindex Postgres
@item 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 implemenation only supports Postgres,
  but the code could be easily extended to support another DBMS.
@end itemize

@c The following image illustrates the various interactions of these
@c key components:

@c @center @image{arch, 3in, 4in}


@node Installation
@chapter Installation

Please install the following packages before proceeding with the exchange compilation.

@itemize

@item
GNU autoconf >= 2.69

@item
GNU automake >= 1.14

@item
GNU libtool >= 2.4

@item
GNU autopoint >= 0.19

@item
GNU libltdl >= 2.4

@item
GNU libunistring >= 0.9.3

@item
libcurl >= 7.26 (or libgnurl >= 7.26)

@item
GNU libmicrohttpd >= 0.9.52

@item
GNU libgcrypt >= 1.6

@item
libjansson >= 2.7

@item
Postgres >= 9.6, including libpq

@item
libgnunetutil (from Git)

@item
GNU Taler exchange (from Git)
@end itemize

Except for the last two, these are available in most GNU/Linux
distributions and should just be installed using the respective
package manager.

The following instructions will show how to install libgnunetutil and
the GNU Taler exchange.

Before you install libgnunetutil, you must download and install the
dependencies mentioned above, otherwise the build may succeed but fail
to export some of the tooling required by Taler.

To download and install libgnunetutil, proceed as follows:

@example
$ git clone https://gnunet.org/git/gnunet/
$ cd gnunet/
$ ./bootstrap
$ ./configure [--prefix=GNUNETPFX]
$ # Each dependency can be fetched from non standard locations via
$ # the '--with-<LIBNAME>' option. See './configure --help'.
$ make
# make install
@end example

If you did not specify a prefix, GNUnet will install to
@code{/usr/local}, which requires you to run the last step as
@code{root}.

To download and install the GNU Taler exchange, proceeds as follows:

@example
$ git clone git://taler.net/exchange
$ cd exchange
$ ./bootstrap
$ ./configure [--prefix=EXCHANGEPFX] \
              [--with-gnunet=GNUNETPFX]
$ # Each dependency can be fetched from non standard locations via
$ # the '--with-<LIBNAME>' option. See './configure --help'.
$ make
# make install
@end example

If you did not specify a prefix, the exchange will install to
@code{/usr/local}, which requires you to run the last step as
@code{root}.  Note that you have to specify @code{--with-gnunet=/usr/local}
if you installed GNUnet to @code{/usr/local} in the previous step.




@node Configuration
@chapter Configuration

@c In this document, we assume that @code{$HOME/.config/taler.conf} is being customized.

This chapter provides an overview of the exchange configuration.  Or
at least eventually will do so, for now it is a somewhat wild
description of some of the options.

@menu
* Keying::
* Serving::
* Currency::
* Bank account::
* Database::
* Coins (denomination keys): Coins denomination keys.
* Keys duration::

@end menu

@node Keying
@section Keying

The exchange works with three types of keys:

@itemize

@item
@cite{master key}

@item
@cite{sign keys}

@item
@cite{denomination keys} (see section @cite{Coins})
@end itemize

@cite{master key}: in section @cite{[exchange]}, edit the two following values:


@itemize

@item
@cite{master_priv_file}: Path to the exchange's master private file.

@item
@cite{master_public_key}: Must specify the exchange's master public key.
@end itemize

@cite{sign keys}: the following two options under
@cite{[exchange_keys]} section control @cite{sign keys}:


@itemize

@item
@cite{signkey_duration}: How long should one signing key be used?

@item
@cite{lookahead_sign}: How much time we want to cover with our
@cite{signkeys}? Note that if @cite{signkey_duration} is bigger than
@cite{lookahead_sign}, @cite{taler-exchange-keyup} will generate a
quantity of @cite{signkeys} which is sufficient to cover all the
gap. See keys-duration.
@end itemize


@node Serving
@section Serving


The exchange can serve HTTP over both TCP and UNIX domain socket. It
needs this configuration @emph{twice}, because it opens one connection
for ordinary REST calls, and one for "/admin" and "/test" REST calls,
because the operator may want to restrict the access to "/admin".

The following values are to be configured under the section
@cite{[exchange]} and @cite{[exchange-admin]}:


@itemize

@item
@cite{serve}: must be set to @cite{tcp} to serve HTTP over TCP, or
@cite{unix} to serve HTTP over a UNIX domain socket

@item
@cite{port}: Set to the TCP port to listen on if @cite{serve} Is
@cite{tcp}.

@item
@cite{unixpath}: set to the UNIX domain socket path to listen on if
@cite{serve} Is @cite{unix}

@item
@cite{unixpath_mode}: number giving the mode with the access
permissiON MASK for the @cite{unixpath} (i.e. 660 = rw-rw----).
@end itemize

The exchange can be started with the @cite{-D} option to disable the administrative
functions entirely.  It is recommended that the administrative API is only
accessible via a properly protected UNIX domain socket.


@node Currency
@section Currency


The exchange supports only one currency. This data is set under the respective
option @cite{currency} in section @cite{[taler]}.

@node Bank account
@section Bank account

@menu
* Wireformat::
* Incoming::
* Outgoing::

@end menu

@node Wireformat
@subsection Wireformat


The wireformat is the protocol to be used between the exchange and the
banks.  The option is @cite{wireformat}, under section
@cite{[exchange]}. The exchange currently supports the @cite{test}
wireformat. This wireformat is used for testing the system against a
fictional bank.

@cartouche
@quotation Note
The SEPA wireformat is work in progress.
@end quotation
@end cartouche

@node Incoming
@subsection Incoming


The bank account where the exchange gets money from customers is
configured under the section @cite{[exchange-wire-incoming-X]}, where
@cite{X} matches the value given to the option @cite{wireformat}. This
section contains only one option: @cite{X_response_file}, which takes
the path to a text file containing the exchange's bank account details
in JSON format.

The command line tool @cite{taler-exchange-wire} is used to create such a file.
For example, the utility may be invoked as follows:

@example
$ taler-exchange-wire -j '@{"name": "The Exchange", "account_number":
10, "bank_uri": "https://bank.demo.taler.net", "type": "test"@}' -t
test -o exchange.json
@end example

Note that the value given to option @cite{-t} must match the value in the JSON's field @code{"type"}.

The generated file will be echoed by the exchange when serving
/wire@footnote{https://api.taler.net/api-exchange.html#wire-req}
requests.

@node Outgoing
@subsection Outgoing

This exchange's bank account is used to give money to merchants, after
successful
deposits@footnote{https://api.taler.net/api-exchange.html#deposit-par}
operations. If @cite{test} is the chosen wireformat, the outcoming
bank account is configured by the following options under
@cite{[exchange-wire-outcoming-test]}:

@quotation


@itemize

@item
@cite{exchange_account_numer}: which bank account number has the exchange

@item
@cite{bank_uri}: base URL of the bank hosting the exchange bank account
@end itemize
@end quotation

@cartouche
@quotation Note
The rationale behind having two bank accounts is that the exchange operator, as a security
measure, may want to instruct the bank that the incoming bank account is only supposed to
@emph{receive} money.
@end quotation
@end cartouche



@node Database
@section Database


The option @cite{db} under section @cite{[exchange]} gets the DB backend's name the exchange
is going to use. So far, only @cite{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:


@itemize

@item
via an environment variable: @cite{TALER_EXCHANGEDB_POSTGRES_CONFIG}.

@item
via configuration option @cite{db_conn_str}, under section @cite{[exchangedb-BACKEND]}. For example, the demo exchange is configured as follows:
@end itemize

@example
[exchange]
...
db = postgres
...

[exchangedb-postgres]
db_conn_str = postgres:///talerdemo
@end example

@node Coins denomination keys
@section Coins (denomination keys)


Sections specifying denomination (coin) information start with
"coin_".  By convention, the name continues with
"$CURRENCY_[$SUBUNIT]_$VALUE", i.e. @cite{[coin_eur_ct_10]} for a 10
cent piece.  However, only the "coin_" prefix is mandatory.  Each
"coin_"-section must then have the following options:


@itemize

@item
@cite{value}: How much is the coin worth, the format is
CURRENCY:VALUE.FRACTION.  For example, a 10 cent piece is "EUR:0.10".

@item
@cite{duration_withdraw}: How long can a coin of this type be
withdrawn?  This limits the losses incurred by the exchange when a
denomination key is compromised.

@item
@cite{duration_overlap}: What is the overlap of the withdrawal
timespan for this coin type?

@item
@cite{duration_spend}: How long is a coin of the given type valid?
Smaller values result in lower storage costs for the exchange.

@item
@cite{fee_withdraw}: What does it cost to withdraw this coin?
Specified using the same format as @cite{value}.

@item
@cite{fee_deposit}: What does it cost to deposit this coin? Specified
using the same format as @cite{value}.

@item
@cite{fee_refresh}: What does it cost to refresh this coin? Specified
using the same format as @cite{value}.

@item
@cite{rsa_keysize}: How many bits should the RSA modulus (product of
the two primes) have for this type of coin.
@end itemize


@node Keys duration
@section Keys duration


Both @cite{signkeys} and @cite{denom keys} have a starting date. The
option @cite{lookahead_provide}, under section @cite{[exchange_keys]},
is such that only keys whose starting date is younger than
@cite{lookahead_provide} will be issued by the exchange.

@cite{signkeys}. The option @cite{lookahead_sign} is such that, being
@cite{t} the time when @cite{taler-exchange-keyup} is run,
@cite{taler-exchange-keyup} will generate @cite{n} @cite{signkeys},
where @cite{t + (n * signkey_duration) = t + lookahead_sign}. In other
words, we generate a number of keys which is sufficient to cover a
period of @cite{lookahead_sign}. As for the starting date, the first
generated key will get a starting time of @cite{t}, and the
@cite{j}-th key will get a starting time of @cite{x +
signkey_duration}, where @cite{x} is the starting time of the
@cite{(j-1)}-th key.

@cite{denom keys}. The option @cite{lookahead_sign} is such that,
being @cite{t} the time when @cite{taler-exchange-keyup} is run,
@cite{taler-exchange-keyup} will generate @cite{n} @cite{denom keys}
for each denomination, where @cite{t + (n * duration_withdraw) = t +
lookahead_sign}. In other words, for each denomination, we generate a
number of keys which is sufficient to cover a period of
@cite{lookahead_sign}. As for the starting date, the first generated
key will get a starting time of @cite{t}, and the @cite{j}-th key will
get a starting time of @cite{x + duration_withdraw}, where @cite{x} is
the starting time of the @cite{(j-1)}-th key.



@node Deployment
@chapter Deployment


@menu
* Standalone deployment::
* Database upgrades::
* Deployment on demo.taler.net::
@end menu


@node Standalone deployment
@section Standalone deployment


This tecnique aims to set a thorough Taler installation up on a
machine whose nginx configuration is configured by config files
from @indicateurl{https://git.taler.net/deployment.git/tree/etc/nginx}.

This installation assumes that all the steps are run with @code{$HOME}
as @code{$CWD}.

The first step is to fetch the @cite{deployment} repository, which hosts all
the needed scripts.

@example
# Adapt the repository's URI to your needs.
$ git clone /var/git/deployment.git/
@end example

The next step is to fetch all the codebases from all the components.

@example
$ ./deployment/bootstrap-standalone
@end example

If the previous step succeeded, a file named @code{activate} should be now
in the @code{$CWD}.  It contains environmental definitions for @code{$PATH} and
database names.

@cartouche
@quotation Note
Please @emph{ignore} the output from the previous script when it succeeds,
which is

@quotation

@example
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

/usr/lib/postgresql/9.5/bin/pg_ctl -D talerdb -l logfile start
@end example

The reason is that this message is generated by Postgresql's utilities and
you never need to start your database manually; it will be started by the
init script that launches all the Taler processes.
@end quotation
@end quotation
@end cartouche

Now we need to compile and install all the downloaded codebases.

@example
# We first update `@w{`}$PATH`@w{`}, in order to make all the compilation
# and configuration utilities available.
$ source activate

# Double check if the previous step worked: $PATH should
# contain $HOME/local/bin.
$ echo $PATH

# The actual compilation:
$ taler-deployment-build
@end example

The following step will generate config files for all the components.
Please @strong{note} that although a default currency will be picked up by the
script, it is possible to have a custom currency by setting the environment
variable @code{TALER_CONFIG_CURRENCY} to the wanted currency, and then running
the config generator.

@example
$ taler-deployment-config-generate
@end example

whereas the following one will place signatures inside wireformat JSON
files.

@example
$ taler-deployment-config-sign
@end example

The next step is to generate @cite{signkeys} and @cite{denomkeys}.

@example
$ taler-deployment-keyup
@end example

@c An error of "invalid currency name" might be related to the current
@c policy of 12-chars limit for currency names; which is likely going to
@c be changed.

It may be necessary to define database tables for the exchange.  The
following command does that.

@example
# Erase all the data!
$ taler-exchange-dbinit -r
@end example

As of the merchant backend, it creates tables at launch time, so it is
not required to define tables before launching it.  @cite{However}, if some
table's definition changed over the time, and there is a need to force
a redefinition of tables, then the following command accomplishes that
for the merchant:

@example
# Erase all the data!
$ taler-merchant-dbinit -r
@end example

If all previous steps succeeded, it is now possible to launch all the
processes.  That is accomplished by the following command:

@example
$ taler-deployment-start
@end example

@cartouche
@quotation Note
Please make sure your nginx works correctly with its configuration
at @code{<DEPLOYMENT-REPO>/etc/nginx}.
@end quotation
@end cartouche


@node Database upgrades
@section Database upgrades

Currently, there is no way to upgrade the database between Taler versions.

The exchange database can be re-initialized using:

@example
$ taler-exchange-dbinit -r
@end example

However, running this command will result in all data in the database
being lost, which may result in significant financial liabilities as
the exchange can then not detect double-spending.  Hence this
operation must not be performed in a production system.



@node Deployment on demo.taler.net
@section Deployment on demo.taler.net

This section describes how to upgrade the exchange deployment on the
@url{taler.net} Web site.  Here, the deployment scripts include a
``stable'' setup at @url{demo.taler.net} and an ``experimental'' setup
at @url{test.taler.net}.  This section documents the steps for moving
the ``experimental'' logic to the ``stable'' site.  It is mostly
useful for administrators of @url{taler.net}, but given that all of
the configuration files are public, it may also make a good starting
point for others.


First, make sure that the deployment @emph{AND} the deployment scripts work on the @cite{test.taler.net} deployment.

For all repositories that have a separate stable branch (currently exchange.git,
merchant.git, merchant-frontends.git, bank.git, landing.git) do:

@example
$ cd $REPO
$ git pull origin master stable
$ git checkout stable

# option a: resolve conflicts resulting from hotfixes
$ git merge master
$ ...

# option b: force stable to master
$ git update-ref refs/heads/stable master

$ git push # possibly with --force

# continue development
$ git checkout master
@end example

Log into taler.net with the account that is @emph{not} active by looking
at the @cite{sockets} symlink of the @cite{demo} account.

The following instructions wipe out the old deployment completely.

@example
$ ls -l ~demo/sockets

[...] sockets -> /home/demo-green/sockets/
@end example

In this case, @cite{demo-green} is the active deployment, and @cite{demo-blue} should be updated.
After the update is over, the @cite{/home/demo/sockets} symlink will be pointed to @cite{demo-blue}.

@example
# Remove all existing files
$ find $HOME -exec rm -fr @{@} \;

$ git clone /var/git/deployment.git
$ ./deployment/bootstrap-bluegreen demo

# set environment appropriately
$ . activate
$ taler-deployment-build

# upgrade the database!  this
# process depends on the specific version

$ taler-deployment-start

# look at the logs, verify that everything is okay
@end example

Now the symlink can be updated.



@node Diagnostics
@chapter Diagnostics

This chapter includes various (very unpolished) sections on specific topics
that might be helpful to understand how the exchange operates, which files
should be backed up.  The information may also be helpful for diagnostics.

@menu
* Configuration format::
* Reserve management::
* Database Scheme::
* Signing key storage::
* Denomination key storage::
* Auditor signature storage::
@end menu

@node Configuration format
@section Configuration format


In Taler realm, any component obeys to the same pattern to get configuration
values.  According to this pattern, once the component has been installed, the
installation deploys default values in @cite{$@{prefix@}/share/taler/config.d/}, in
@cite{.conf} files.  In order to override these defaults, the user can write a custom
@cite{.conf} file and either pass it to the component at execution time, or name it
@cite{taler.conf} and place it under @cite{$HOME/.config/}.


A config file is a text file containing @cite{sections}, and each section contains
its @cite{values}. The right format follows:

@example
[section1]
value1 = string
value2 = 23

[section2]
value21 = string
value22 = /path22
@end example

Throughout any configuration file, it is possible to use @code{$}-prefixed variables,
like @code{$VAR}, especially when they represent filesystem paths.
It is also possible to provide defaults values for those variables that are unset,
by using the following syntax: @code{$@{VAR:-default@}}.
However, there are two ways a user can set @code{$}-prefixable variables:

by defining them under a @code{[paths]} section, see example below,

@example
[paths]
TALER_DEPLOYMENT_SHARED = $@{HOME@}/shared-data
..
[section-x]
path-x = $@{TALER_DEPLOYMENT_SHARED@}/x
@end example

or by setting them in the environment:

@example
$ export VAR=/x
@end example

The configuration loader will give precedence to variables set under @code{[path]},
though.

The utility @code{taler-config}, which gets installed along with the exchange, serves
to get and set configuration values without directly editing the @cite{.conf}.
The option @code{-f} is particularly useful to resolve pathnames, when they use
several levels of @code{$}-expanded variables. See @code{taler-config --help}.

Note that, in this stage of development, the file @code{$HOME/.config/taler.conf}
can contain sections for @emph{all} the component. For example, both an exchange and
a bank can read values from it.

The repository @code{git://taler.net/deployment} contains examples of configuration
file used in our demos. See under @code{deployment/config}.

@cartouche
@quotation Note
Expectably, some components will not work just by using default values, as their
work is often interdependent. For example, a merchant needs to know an exchange
URL, or a database name.
@end quotation
@end cartouche



@node Reserve management
@section Reserve management


Incoming transactions to the exchange's provider result in the
creation or update of reserves, identified by their reserve key.  The
command line tool @cite{taler-exchange-reservemod} allows create and
add money to reserves in the exchange's database.




@node Database Scheme
@section Database Scheme


The exchange database must be initialized using @cite{taler-exchange-dbinit}.  This
tool creates the tables required by the Taler exchange to operate.  The
tool also allows you to reset the Taler exchange database, which is useful
for test cases but should never be used in production.  Finally,
@cite{taler-exchange-dbinit} has a function to garbage collect a database,
allowing administrators to purge records that are no longer required.

The database scheme used by the exchange look as follows:

@image{exchange-db,5in,,,png}


@node Signing key storage
@section Signing key storage


The private online signing keys of the exchange are stored in a
subdirectory "signkeys/" of the "KEYDIR" which is an option in the
"[exchange]" section of the configuration file.  The filename is the
starting time at which the signing key can be used in microseconds
since the Epoch.  The file format is defined by the @cite{struct TALER_EXCHANGEDB_PrivateSigningKeyInformationP}:

@example
struct TALER_EXCHANGEDB_PrivateSigningKeyInformationP @{
   struct TALER_ExchangePrivateKeyP signkey_priv;
   struct TALER_ExchangeSigningKeyValidityPS issue;
@};
@end example


@node Denomination key storage
@section Denomination key storage


The private denomination keys of the exchange are store in a
subdirectory "denomkeys/" of the "KEYDIR" which is an option in the
"[exchange]" section of the configuration file.  "denomkeys/" contains
further subdirectories, one per denomination.  The specific name of
the subdirectory under "denomkeys/" is ignored by the exchange.
However, the name is important for the "taler-exchange-keyup" tool
that generates the keys.  The tool combines a human-readable encoding
of the denomination (i.e.  for EUR:1.50 the prefix would be
"EUR_1_5-", or for EUR:0.01 the name would be "EUR_0_01-") with a
postfix that is a truncated Crockford32 encoded hash of the various
attributes of the denomination key (relative validity periods, fee
structure and key size).  Thus, if any attributes of a coin change,
the name of the subdirectory will also change, even if the
denomination remains the same.

Within this subdirectory, each file represents a particular
denomination key.  The filename is the starting time at which the
signing key can be used in microseconds since the Epoch.  The
format on disk begins with a
@cite{struct TALER_EXCHANGEDB_DenominationKeyInformationP} giving
the attributes of the denomination key and the associated
signature with the exchange's long-term offline key:

@example
struct TALER_EXCHANGEDB_DenominationKeyInformationP @{
  struct TALER_MasterSignatureP signature;
  struct TALER_DenominationKeyValidityPS properties;
@};
@end example

This is then followed by the variable-size RSA private key in
libgcrypt's S-expression format, which can be decoded using
@cite{GNUNET_CRYPTO_rsa_private_key_decode()}.


@node Auditor signature storage
@section Auditor signature storage


Signatures from auditors are stored in the directory specified
in the exchange configuration section "exchangedb" under the
option "AUDITOR_BASE_DIR".  The exchange does not care about
the specific names of the files in this directory.

Each file must contain a header with the public key information
of the auditor, the master public key of the exchange, and
the number of signed denomination keys:

@example
struct AuditorFileHeaderP @{
  struct TALER_AuditorPublicKeyP apub;
  struct TALER_MasterPublicKeyP mpub;
  uint32_t dki_len;
@};
@end example

This is then followed by @cite{dki_len} signatures of the auditor of type
@cite{struct TALER_AuditorSignatureP}, which are then followed by another
@cite{dki_len} blocks of type @cite{struct TALER_DenominationKeyValidityPS}.
The auditor's signatures must be signatures over the information of
the corresponding denomination key validity structures embedded in a
@cite{struct TALER_ExchangeKeyValidityPS} structure using the
@cite{TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS} purpose.



@c **********************************************************
@c *******************  Appendices  *************************
@c **********************************************************

@node GNU-AGPL
@chapter GNU Affero GPL
@cindex license
@include agpl.texi

@node GNU-FDL
@chapter GNU Free Documentation License
@cindex license
@include fdl-1.3.texi

@node Concept Index
@chapter Concept Index

@printindex cp

@bye