[GNUnet-SVN] [taler-deployment] branch master updated: some cleaning

[gnunet]

This is an automated email from the git hooks/post-receive script.

marcello pushed a commit to branch master
in repository deployment.

The following commit(s) were added to refs/heads/master by this push:
     new ddcfb1b  some cleaning
ddcfb1b is described below

commit ddcfb1bae6ba331e20d3f6dfa11e0d3bf0b8d328
Author: Marcello Stanisci <address@hidden>
AuthorDate: Fri Apr 19 17:48:24 2019 +0200

    some cleaning
---
 doc/onboarding.texi | 274 ----------------------------------------------------
 1 file changed, 274 deletions(-)

diff --git a/doc/onboarding.texi b/doc/onboarding.texi
index 106fdec..4307a3a 100644
--- a/doc/onboarding.texi
+++ b/doc/onboarding.texi
@@ -50,289 +50,15 @@ Texts.  A copy of the license is included in the section 
entitled
 @end ifnottex
 
 @menu
-* Taler.net::                           Sysadmins notes for server at taler.net
 * Standalone deployment::               Deploy Taler in your homepage
 * Deployment on demo.taler.net::        Deploy Taler in a "blue/green" fashion
 * Testing components::                  How to make and run tests.
 * Releases::                            Releases patterns
 @end menu
 
address@hidden Taler.net
address@hidden Taler.net
-
address@hidden Landing page
-
-The 'landing' page is the first page that should be visited during a "demo 
session".
-It is statically served and hosted at @code{$USER/landing/}, where 
@code{$USER} is one
-of @address@hidden,address@hidden or @address@hidden,address@hidden  Its 
source code is
-available at the repository: @code{git://taler.net/landing}.
-
-Before being served, the site needs to be compiled, to make the i18n content.  
The
-compilation is done in the following way:
-
address@hidden
-$ cd <landing's top directory>
-$ git submodule update --force --init
-$ AUTOMAKE="automake --foreign" autoreconf -fiv
-$ ./configure
-$ cd demo/
-$ make
-
-# NOTE: the sysadmin will _hardly_ need to do this manually, as there are 
deployment
-# scripts in charge of the compilation.
address@hidden example
-
-The most interesting part of nginx's configuration that serves the landing page
-is the following one:
-
address@hidden
-
-location / @{
-  ...
-  # always default to english
-  rewrite ^/$ /en/ redirect; 
-  # explicit append of "index.html"
-  rewrite ^/(..)/$ /$1/index.html break;
-  ...
-  # NOTE: /home/test/landing and /home/demo/landing
-  # are symlinks to the currently active "blue or green" party.
-  # Next chapters explain the "blue/green" deployment technique.
-  root /home/<'test' or 'demo'>/landing/demo;
-  ...
-  @}
address@hidden example
-
address@hidden Git
-
-Git at @code{taler.net} is managed by @emph{gitolite}.  Creation and deletion
-of repositories, as well as users management, is done entirely by editing the
address@hidden file within the @code{gitolite-admin} repository.
-
-Please refer to gitolite official documentation, if more information is needed:
address@hidden://gitolite.com/gitolite/}.
-
-
-This section documents the set-up of our main server @code{taler.net}.
-
address@hidden Buildbot
-
address@hidden Note
-'worker' and 'slave' are used interchangeably
address@hidden quotation
-
-The user running the buildbot master is @emph{buildbot-master}.  The 
authentication
-credentials for the allowed users are kept in minimalistic Python module that
-should be installed before the Buildbot is run.  The location for its content
-is @code{/home/containers/buildbot/taler_bb_userpass_db}; whenever a new 
user/pass
-tuple is added, simply @code{cd} in that directory and run @code{pip install .}
-
address@hidden Start/stop workers
-
address@hidden
address@hidden
-Every worker is run by a dedicated user in the system, and runs in
-"virtualenv".  The latter is installed within
address@hidden<worker_home_dir>/buildbot/venv}. The worker setup lies into
address@hidden<worker_home_dir>/buildbot/<worker_setup>}, where 
@code{<worker_setup>}
-has an "obvious" name, like @code{worker}, @code{slave}, 
@code{<worker_username>},
address@hidden<builder_name>} or any combination of these.
-
-The following commands show how to start and stop a worker.
-
address@hidden
-# log in as the worker user.
-# cwd is $HOME.
-
-# this activated the virtualenv.
-$ source buildbot/venv/bin/activate
-
-# this starts the worker.
-$ buildbot-worker start buildbot/<worker_setup>
-
-# this stops the worker.
-$ buildbot-worker stop buildbot/<worker_setup>
-
address@hidden example
-
address@hidden quotation
address@hidden cartouche
-
address@hidden Debug worker
-
-This worker is used to test the Buildbot and it is run by the
-user @code{debug-builder}.  Its scheduler monitors @code{help.git},
-which is the repository where debug pushes have to be done.
-
-Note that this worker might not be activated all the time, as it
-is not needed by any production codebase.
-
address@hidden Python linter
-This worker is responsible for running Python static analysis, and it
-is served by the user @code{linter}.
-
address@hidden Documentation worker
-
-This worker is responsible for building all the documentation on
address@hidden://docs.taler.net}.  It is run by the user @code{docbuilder},
-whose home directory must have all the repositories with documentation
-to be built.  Namely,
-
address@hidden Demo-checks worker.
-
-This worker has the simple task of checking whether all the Web
-services offered under "*.demo.taler.net" are up and running.  It
-is run by the @code{demo} user itself.
-
address@hidden
address@hidden @emph{exchange}
address@hidden @emph{merchant}
address@hidden @emph{merchant-frontend-examples}
address@hidden @emph{deployment} - because of "onboarding" documentation
address@hidden @emph{api}
address@hidden itemize
-
address@hidden
address@hidden Note
-use the @code{--umask=022} option when creating this worker,
-because Buildbot gives default @code{077} umask to its processes
-and this makes generated files unreadable.
address@hidden quotation
address@hidden cartouche
-
address@hidden Wallet worker
-This worker is responsible for running wallet testcases.  It is run
-by the @emph{containers} user.
-
address@hidden Selenium worker
-This worker is responsible for running the Selenium wallet test:
-an automatic clicker that performs the cycle withdraw-and-spend.
-
-The @emph{containers} user is also responsible for running the Selenium
-buildbot worker.
-
address@hidden Lcov worker
-
-The worker is implemented by the @emph{lcovslave} user and is responsible
-for generating the HTML showing the coverage of our tests, then available
-on @emph{https://lcov.taler.net}.
-
address@hidden:} a Postgres "per-user" database service should always
-be running, as @emph{lcovslave} is deployed in a standalone environment.
-
-Start the database service in the following way:
-
address@hidden
-# Assuming you already sourced ~/activate
-$ taler-deployment-arm -s
-$ taler-deployment-arm -i taler-postgres-standalone
-# Stop it this way:
-$ taler-deployment-arm -k taler-postgres-standalone
-# To stop 'arm', issue:
-$ taler-deployment-arm -e
address@hidden example
-
address@hidden Switcher worker
-
-Taler.net uses a "blue/green" fashion to update the code it
-uses in demos.  Practically, there are two users: @emph{test-green}
-and @emph{test-blue}, and only one of them is "active" at any time.
-
-Being @emph{active} means that whenever nginx receives a HTTP request
-for one of the Taler services (at our demo), it routes the request
-to either test-blue or test-green via unix domain sockets.
-
-Upon any push to any of the Taler's subprojects, this worker is
-responsible for building the code hosted at the inactive user and,
-if all tests succeed, switching the active user to the one whose code
-has just been compiled and tested.
-
-The worker is implemented by the @emph{testswitcher} user. This user
-has some additional "sudo" rights, since it has to act as @emph{test-blue},
address@hidden user in order to accompish its task.
-Note that the "sudo file" is tracked in this (@emph{deployment}) repository,
-under the @emph{sudoers} directory.
-
address@hidden Auditor worker.
-This worker runs the periodic task of generating the auditing reports.
-It is run by the @code{auditor-slave} user.
-
address@hidden Wallet builder.
-TBD
-
address@hidden Selenium builder
-TBD
-
address@hidden Tip reserve topper
-This worker is also responsible to run the script which tops
-the tip reserve up; however, this task is triggered by a "periodic scheduler"
-once every 10 days.  A "force build" button is also offered to run
-this task.  The service is offered by the @emph{reserve-topper} user.
-
address@hidden Manual switch
-
-After the desired blue/green party has been compiled, it is possible to
-log-in as @emph{test} and run the script @code{$HOME/.ln-<COLOR>.sh}, in order 
to make
address@hidden<COLOR>} active.
-
address@hidden Website lcov.taler.net
-
-The directory @code{/var/www/lcov.taler.net} contains the following
-two symlinks
-
address@hidden
address@hidden exchange --> @code{/home/lcovslave/exchange/doc/coverage}
address@hidden merchant --> @code{/home/lcovslave/merchant/doc/coverage}
address@hidden itemize
-
-The pointed locations are updated by the @emph{lcovslave}.
-
address@hidden Hooks
-
-Whenever a push occurs into one of Taler repositories, Buildbot gets
-notified via the Git @emph{hooks} system.
-
-We use the hook in [1].
-
-Following a @emph{gitolite}-policy, all the hook must be committed under
address@hidden/local/hooks/repo-specific/post-receive.buildbot},
-so that gitolite will copy it in the right place -- the sysadmin does 
@strong{not}
-have to manually move it.
-
-Once the hook is versioned under gitolite, every repository meant to benefit
-from it must get the @code{option hook.pre-receive = pre-receive.buildbot}
-statement from the gitolite config file.
-
-On the Buildbot side, we need to allow the hook to connect to the build master.
-This is done by defining a @code{PBChangeSource} class in the following way:
address@hidden
-cs = changes.PBChangeSource(user='tony', passwd='hey')
address@hidden example
-NOTE: those credentials must match the ones in the hook; change the top
-level variables @code{username} and @code{auth} in the hook to suit your setup.
-
-The following line will finally "activate" the hook within the build master:
address@hidden
-c['change_source'].append(cs)
address@hidden example
-
-From now on, every buildbot scheduler will receive notifications from @code{cs}
-and verify if there is a match with the @code{ChangeFilter} driving the 
scheduler.
-If there is a match, the scheduler will fire its builders up, otherwise no 
action
-is taken.
-
-[1] 
@url{https://github.com/buildbot/buildbot-contrib/blob/master/master/contrib/git_buildbot.py}
-
address@hidden Playground
-The playground repository (@url{https://git.taler.net/playground}) contains 
various
-experiments and tests, for example to cover APIs that are not used by the 
other demo merchant
-frontends.  It also serves to test various behaviors of wallets.
-
-At present, it is only deployed on @code{test.taler.net}, but @emph{not} on 
@code{demo.taler.net}.
-
 @node Standalone deployment
 @chapter Standalone deployment
 
-
 This tecnique aims to set a thorough Taler installation up on a
 machine whose nginx configuration is configured by config files
 from @emph{https://git.taler.net/deployment.git/tree/etc/nginx}.

-- 
To stop receiving notification emails like this one, please contact
address@hidden