summaryrefslogtreecommitdiff
path: root/deployment.rst
blob: c0b07e43200ffcc01b7c6df404bf5dc1f9389cfa (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
===================
Deployment Protocol
===================

------
Wallet
------

.. code-block:: none

  $ cd wallet-webex

  # check dependencies
  $ ./configure

  # edit version and version_name
  $ $EDITOR manifest.json

  $ make package-stable

The built wallet is now ready in `taler-wallet-stable-${version_name}${version}.zip`.  

FIXME:  here, we should do some semi-automated testing with selenium, to see
that everything works against `demo.taler.net`.

The package can now be uploaded to https://chrome.google.com/webstore/developer/dashboard

FIXME:  include asset links and descriptions we use in the webstore in this document

FIXME:  include instructions for other app stores


--------------------
Deploying to stable
--------------------

First, make sure that the deployment *AND* the deployment scripts work on the `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:

.. code-block:: none

  $ 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


Log into taler.net with the account that is *not* active by looking
at the `sockets` symlink of the `demo` account.

The following instructions wipe out the old deployment completely.

.. code-block:: none

  $ ls -l ~demo/sockets
  
  [...] sockets -> /home/demo-green/sockets/

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

.. code-block:: none

  # 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

Now the symlink can be updated.



------------------
Database upgrades
------------------

The exchange db can be re-initialized with

.. code-block:: none

  $ taler-exchange-dbinit -r

CAUTION: YOU WILL LOSE ALL DATA WITH THIS!


---------------------
Standalone deployment
---------------------

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

This installation assumes that all the steps are run with ``$HOME``
as ``$CWD``.

The first step is to fetch the `deployment` repository, which hosts all
the needed scripts.

.. code-block:: none
  
  # Adapt the repository's URI to your needs.
  $ git clone /var/git/deployment.git/

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

.. code-block:: none
  
  $ ./deployment/bootstrap-standalone

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

.. note::

  Please *ignore* the output from the previous script when it succeeds,
  which is

    .. code-block:: none

      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

    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.

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

.. code-block:: none

  # We first update ``$PATH``, 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

The following step will generate config files for all the components.
Please **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 ``TALER_CONFIG_CURRENCY`` to the wanted currency, and then runing
the config generator.

.. code-block:: none
  
  $ taler-deployment-config-generate

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

.. code-block:: none

  $ taler-deployment-config-sign

The next step is to generate `signkeys` and `denomkeys`.

.. code-block:: none

  $ taler-deployment-keyup

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

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

.. code-block:: none

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

As of the merchant backend, it creates tables at launch time, so it is
not required to define tables before launching it.  `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:

.. code-block:: none

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

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

.. code-block:: none

  $ taler-deployment-start

.. note::

  Please make sure your nginx works correctly with its configuration
  at ``<DEPLOYMENT-REPO>/etc/nginx``.