AIKC - Automatic Internal Kedifa's Caucase CSR signing, which can be triggered
by option automatic-internal-kedifa-caucase-csr.

It signs all CSR which match csr_id and certificate from the nodes which needs them.

csr_id is exposed over HTTPS with short living self signed certificate,
which is transmitted via SlapOS Master. Thanks to this, it is possible to
match csr_id with certificate of given partition and take decision if it shall
be signed or not.

This is "quite secure" apporach, a bit better than blidny trusting what CSR
to sign in KeDiFa. The bootstrap information, which is short living
(certificates are valid for 5 days), resides in SlapOS Master. The csr_id
is not directly known to SlapOS Master, and shall be consumed as fast as
possible by frontend cluster operator in order to sign CSR appearing in
KeDiFa caucase. The known possible attack vector requires that attacker knows
caucased HTTP listening port and can hijack HTTPS traffic to the csr_id-url
to get the human approve his own csr_id. The second is hoped to be overcomed
by publishing certificate of this endpoint via SlapOS Master.

Unfortunately caucase-updater prefix is directly used to find real CSR, as the
one generated is just a template for rerequest, thus csr_id would be different
from really used by caucase-updater.

Use KeDiFa to store keys, and transmit the url to the requester for master
and slave partitions.

Download keys on the slave partitions level.

Use caucase to fetch main caucase CA.

kedifa-caucase-url is published in order to have access to it.

Note: caucase is prepended with kedifa, as this is that one.

Use kedifa-csr tool to generate CSR and use caucase-updater macro.

Switch to KeDiFa with SSL Auth and updated goodies.

KeDiFa endpoint URLs are randomised.

Only one (first) user certificate is going to be automatically accepted. This
one shall be operated by the cluster owner, the requester of frontend master
partition.

Then he will be able to sign certificates for other users and also for
services - so each node in the cluster.

Special trick from https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-command-line
is used for one command generation of extensions in the certificate.
Note: We could upgrade to openssl 1.1.1 in order to have it really
simplified (see https://security.stackexchange.com/a/183973 )

Improve CSR readability by creating cluster-identification, which is master
partition title, and use it as Organization of the CSR.

Reserve slots for data exchange in KeDiFa.

Improvements:

 * support CSR as a file
   Allow to pass template_csr as a file, as it is useful for some cases.

 * use dumps where needed, as it is available

 * fix rerequest internal call

OPENSSL_BINARY was backward compatibility apporach, but now modern
ERP5 code uses it only to find software home, so publish it with
SLAPOS_SOFTWARE_HOME directly.

Notes

stack/erp5

 * The service-auto-approve-amount to default is set to 1, in order that the
   only needed service is automatically approved.  As caucase is accessed
   internally (on local IPv4) only partitions on the same server will access
   caucase.

Thanks to this 'None' is used in BuildoutSerializer

ZODB/go started to use it in tests:

	kirr/neo@532d014f

It started to be used in fs1/go.

https://github.com/kisielk/og-rek/compare/dd41cde712...8b25c4cefd

- support for persistent references,
- fixes for decoder and encoder,
- allow to specify protocol on encoding,
- support for protocols 3 and 4 including added support for Python bytes,
- package-level documentation.

update pep445 patch using https://raw.githubusercontent.com/vstinner/pytracemalloc/pytracemalloc-1.4/patches/2.7.15/pep445.patch

If qemu use physical disk device instead of created qemu image disk, we skip this promise.

/reviewed-on nexedi/slapos!507

While helping @romain to review my current work we tried to build helloworld and found that it is completely broken.

It was first minimally fixed to pin eggs and the like.

Then I've added Go1.11 to our stack, so that recent-enough compiler/stdlib could be used. A note goes here that currently our lab uses go1.9 which is outdated and not supported by upstream, and other bits are still using go1.10.3 while go1.10.7 was already released some time ago with bug and security fixes. I did not touched neither  go1.10 / nor go1.9, but imho it makes sense for infrastructure people to look into appropriate upgrades.

Finally component/helloweb/ is switched to use gowork infrastructure (see 1b540151 for gowork introduction). Today gowork is used to build eveything go-related, so building go bits manually via cmmi as example is  a bit misleading. Gowork is also required in case we'll need to use any third-party or our package a helloweb-go.

/cc @luke, @alain.takoudjou
/reviewed-by @jerome, @tomo
/reviewed-on nexedi/slapos!505

- it is gowork that is now used by Go-related bits in SlapOS, so using
  gowork is preferred as example. Besides we need gowork to be able to
  use any third-party Go package.

- other languages can use helloweb repository from under gowork/ tree as
  well.

The hash of helloweb.git is changed, becuase its layout had to be too
adjusted to match gowork mode:

nexedi/helloweb@a072af78...8bfedac6

To pick up Python3 support.

nexedi/helloweb@39fd89a3...a072af78

Don't drop support for Go1.9, as, even though Go1.9 is no longer
supported, software/gitlab depends on it.

Our Go1.10.X is also too outdated, but I'm not touching it here neither.

/cc @alain.takoudjou, @luke

	2019-01-21 17:56:18 slapos[13553] INFO While:
	2019-01-21 17:56:18 slapos[13553] INFO   Installing.
	2019-01-21 17:56:18 slapos[13553] INFO   Getting section instance-profile.
	2019-01-21 17:56:18 slapos[13553] INFO   Initializing section instance-profile.
	2019-01-21 17:56:18 slapos[13553] INFO   Installing recipe slapos.recipe.template.
	2019-01-21 17:56:18 slapos[13553] INFO   Getting distribution for 'slapos.recipe.template'.
	2019-01-21 17:56:18 slapos[13553] INFO Error: Picked: slapos.recipe.template = 4.3
	2019-01-21 17:56:19 slapos[13553] ERROR Failed to run buildout profile in directory '/srv/slapgrid/slappart7/srv/runner/software/19771f7b751ffc2a88162b15750c6069'

	2019-01-21 18:01:21 slapos[26771] INFO While:
	2019-01-21 18:01:21 slapos[26771] INFO   Installing.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section helloweb-ruby.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section helloweb-ruby.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting option helloweb-ruby:input.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section helloweb-ruby-bundle.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section helloweb-ruby-bundle.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting option helloweb-ruby-bundle:make-targets.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting section bundler.
	2019-01-21 18:01:21 slapos[26771] INFO   Initializing section bundler.
	2019-01-21 18:01:21 slapos[26771] INFO   Installing recipe rubygemsrecipe.
	2019-01-21 18:01:21 slapos[26771] INFO   Getting distribution for 'rubygemsrecipe'.
	2019-01-21 18:01:21 slapos[26771] INFO Error: Picked: rubygemsrecipe = 0.2.2+slapos001

Ruby stuff was failing to download at all -> let's use the versions that
are the same as currently used in software/gitlab.

Based on patch by @romain.
Helped by @jerome.

openss1.1 caused problems with bundler:

Unable to require openssl, install OpenSSL and rebuild ruby (preferred)
or use non-HTTPS sources

/reviewed-on nexedi/slapos!504

They are dependencies of slapos.toolbox and we already agreed to put slapos.toolbox version in a shared file.

/cc @jerome @jm

/reviewed-on nexedi/slapos!502

One of solutions for random 502 errors from caddy is to fully disable
HTTP2 protocol ( https://github.com/mholt/caddy/issues/1080 )

We run Caddy with HTTP2 enabled by default, as we can enable/disable it per
each slave, but in some environments it might be just better to fully avoid
HTTP2 codepaths in Caddy.

/reviewed-on nexedi/slapos!495

The IP used by frontend can be different than the real endpoint, and unknown
for the frontend itself, so make it catch-all to allow access.

/reviewed-on nexedi/slapos!497

Because of misleading tests (Accept-Encoding with gzip was always set by
requests, fixed in "caddy-frontend/test: Workaround requests issue with
Accept-Encoding") the original commit "Fix/caddy frontend prefer gzip type
zope" did not really fixed the issue for type:zope backend.

requests set Accept-Encoding header, but in the testr environment we
want to have full control over its behaviour, thus not setting any header if
not really wanted.

As there is not known way to avoid setting the header (skip_accept_encoding is
internal to httplib) set dummy Accept-Encoding header, which is enough for our
environment.

Hopefully fix the random failure with:

```
test_connect (test.TestSSHServer) ... /srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/eggs/paramiko-2.4.2-py2.7.egg/paramiko/client.py:822: UserWarning: Unknown ecdsa-sha2-nistp521 host key for [2001:67c:1254:e:4a::7bd5]:22222: 22c41f5090433152d1e5395a85d6cb4f
  key.get_name(), hostname, hexlify(key.get_fingerprint())
FAIL

======================================================================
FAIL: test_connect (test.TestSSHServer)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/slapgrid/slappart3/srv/testnode/byx/soft/a452c8ac557f7eaea3c20f6cc373c390/parts/slapos-repository/software/seleniumserver/test/test.py", line 357, in test_connect
    self.assertIn("Welcome to SlapOS Selenium Server.", channel.recv(100))
AssertionError: 'Welcome to SlapOS Selenium Server.' not found in 'Attempt to write login records by non-root user (aborting)\r\r\n'

----------------------------------------------------------------------
```

Also publish the fingerprint of the server ssh key, which addresses this warning in the correct way (I feel) and since we can publish the fingerprint, why not.

/reviewed-on nexedi/slapos!492

Since "stack/monitor: Add auto-restart on certificate-authority section"
certificate authority is correctly exposed in supervisor with its hash.

/reviewed-on nexedi/slapos!500

/reviewed-on nexedi/slapos!499