some cleaning

1 files changed, 0 insertions, 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
 
-@node Taler.net
-@chapter Taler.net
-
-@section 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 @code{test-@{blue,green@}} or @code{demo-@{blue,green@}}.  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:
-
-@example
-$ 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.
-@end example
-
-The most interesting part of nginx's configuration that serves the landing page
-is the following one:
-
-@example
-
-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;
-  ...
-  @}
-@end example
-
-@section 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
-@code{gitolite.conf} file within the @code{gitolite-admin} repository.
-
-Please refer to gitolite official documentation, if more information is needed:
-@code{http://gitolite.com/gitolite/}.
-
-
-This section documents the set-up of our main server @code{taler.net}.
-
-@section Buildbot
-
-@quotation Note
-'worker' and 'slave' are used interchangeably
-@end 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 .}
-
-@subsection Start/stop workers
-
-@cartouche
-@quotation
-Every worker is run by a dedicated user in the system, and runs in
-"virtualenv".  The latter is installed within
-@code{<worker_home_dir>/buildbot/venv}. The worker setup lies into
-@code{<worker_home_dir>/buildbot/<worker_setup>}, where @code{<worker_setup>}
-has an "obvious" name, like @code{worker}, @code{slave}, @code{<worker_username>},
-@code{<builder_name>} or any combination of these.
-
-The following commands show how to start and stop a worker.
-
-@example
-# 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>
-
-@end example
-
-@end quotation
-@end cartouche
-
-@subsection 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.
-
-@subsection Python linter
-This worker is responsible for running Python static analysis, and it
-is served by the user @code{linter}.
-
-@subsection Documentation worker
-
-This worker is responsible for building all the documentation on
-@code{https://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,
-
-@subsection 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.
-
-@itemize
-@item @emph{exchange}
-@item @emph{merchant}
-@item @emph{merchant-frontend-examples}
-@item @emph{deployment} - because of "onboarding" documentation
-@item @emph{api}
-@end itemize
-
-@cartouche
-@quotation 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.
-@end quotation
-@end cartouche
-
-@subsection Wallet worker
-This worker is responsible for running wallet testcases.  It is run
-by the @emph{containers} user.
-
-@subsection 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.
-
-@subsection 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}.
-
-@b{NOTE:} 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:
-
-@example
-# 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
-@end example
-
-@subsection 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},
-`test-gree@emph{$1}est` user in order to accompish its task.
-Note that the "sudo file" is tracked in this (@emph{deployment}) repository,
-under the @emph{sudoers} directory.
-
-@subsection Auditor worker.
-This worker runs the periodic task of generating the auditing reports.
-It is run by the @code{auditor-slave} user.
-
-@subsection Wallet builder.
-TBD
-
-@subsection Selenium builder
-TBD
-
-@subsection 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.
-
-@subsection 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
-@code{test-<COLOR>} active.
-
-@subsection Website lcov.taler.net
-
-The directory @code{/var/www/lcov.taler.net} contains the following
-two symlinks
-
-@itemize
-@item exchange --> @code{/home/lcovslave/exchange/doc/coverage}
-@item merchant --> @code{/home/lcovslave/merchant/doc/coverage}
-@end itemize
-
-The pointed locations are updated by the @emph{lcovslave}.
-
-@subsection 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
-@code{gitolite-admin/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:
-@example
-cs = changes.PBChangeSource(user='tony', passwd='hey')
-@end 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:
-@example
-c['change_source'].append(cs)
-@end 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}
-
-@section 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}.