Extend the integration test with a new case, testing that direct upload
to the cloud works for Koji composes. Test this using a single cloud
provider, specifically AWS.
The test case submits a new osbuild-image build using Koji CLI,
determines the image information once the build finishes and then checks
that such image exists in AWS. The image is then deleted as part of the
test case tear-down.
The AWS credentials are now configured in the worker's configuration, if
the appropriate environment variables are set.
Update the SPEC file with a new test dependency and update the required
osbuild-composer version.
Use latest osbuild and osbuild-composer releases. This is important to
be later able to test direct uploading to the cloud for Koji composes.
Also the mock openid server had to be enhanced to be usable for testing
`koji-osbuild`.
Modify used osbuild-worker configuration to use JWT for authentication
with composer. Update configurations of both, composer and worker to
handle multi-tenancy.
Do not start any services in `schutzbot/deploy.sh`, because at that
point, none of the configuration files are in place.
Ensure that the correct units are started and masked by
`test/integration.sh` to simulate the Service scenario more closely.
This means that the local worker is masked and only remote worker is
started.
Co-authored-by: Jakub Rusz <jrusz@redhat.com>
This is similar to how other osbuild packages are testing: everything
that's needed for testing is included in the tests package or a
dependency of it. The test runner then runs every executable in
/usr/libexec/tests/<packagename>. This gives a simple test API to
projects depending on this package (notably osbuild-composer).
The local development workflow described in HACKING.md is meant to
continue to work. To ensure this, all relevant scripts gained a
TEST_DATA variable, which defaults to `./test`, but is set from $1 to
the installed path from integration.sh.
Generate the certificate to be used for koji in make-certs.sh by
the same CA that also generates the composer and client certs.
Create a single certificate that uses the SubjectAltName (SAN)
extension to cover two domains: localhost, org.osbuild.koji.koji,
which previously was done via two separate certificates; this is
the legacy usage which stopped working with go 1.15 (see previous
commit). As a consequence the apache config is modified to use
only one virtual host with a ServerAlias directive.
Rework the generation of certificates, in order to make use of
the SubjectAltName (SAN) extension, that is required for modern
usage of TLS (see RFC 2818, or [1]) and now enforced by default
for go version 1.15[2] (Fedora 33). For this a different config
file is used, originally written by Lars, and assign SANs to
the server and client certificates. Additionally, the correct
extensions are used for each of those, so that their usage is
limited to the server or client use case. The client certificate
is renamed from "worker" to "client".
The lifetime of the certificates is increased, as a side effect of
the new config file.
[1] https://github.com/urllib3/urllib3/issues/497
[2] https://golang.org/doc/go1.15#commonname
Co-authored-by: Lars Karlitski <lars@karlitski.net>
This script is intended to be called between "run-koji-container"
and "run-builder". It will copy the kerberos keytabs out of the
temporary directory generated by "run-koji-container" as well as
copying the SSL/TLS certificates from host to the share dir so
that the plugin ca use it to authenticate itself to composer.
