When run in the background, remove the container in "builder_stop",
this should make it easier to print logs between starting and
stopping the container.
Check that passing `--cert` as a command line option works, for
this we use real working certificates because this will actually
be parsed by requests.
Check we can handle a single cert properly, i.e. pass it as a
plain string to requests. Also check that if three components
are specified, an ValueError is thrown.
The ssl_verify config option can be a string, i.e. a path to the
certificate authority for the server side certificate. Check
that we handle that properly.
The requests cert argument accepts a tuple with the key and the
cert, or one string as a path to a combination of both. Create
a new helper and use that to parse the "ssl_cert" configuration
option as well as the command line option. Change the latter
into a string.
Use a global constant `DEFAULT_CONFIG_FILES` for the default
plugin configuration files. Besides giving it more visibility
it also makes it easier to test, because in the unit test,
this can easily be overwritten.
Add a separate unit test to do a compose for a RHEL based image,
but then restrict the execution of test_compose_{disto} to the
distribution the test is running on, since currently cross-
distribution builds can be problematic.
This is right when PR-952 landed, which is what we are updating
from. This will use SSL certification and also re-enable auto
kerberos authorization via config files for composer.
Instead of manually copying credentials around, use the new
copy-creds.sh script. Also don't manually initialize kerberos,
because that is now done automatically by the worker and the
builder.
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.
This will create the a certificate authority (CA) and then create
a cert for composer and another one for the worker. The worker
one can also be used by the koji plugin.
The configuration file is needed to get subjectAltName working.
Add support for client side certificates via a new configuration
option: "ssl_cert", which should be a path to the certificate or
a comma separated list of paths to certificates.
Additionally, the "ssl_verify" option controls how the server
certificate is validated. This can either be a boolean ("True",
"False") or a path to a CA file.
NB: The url for the composer host must contain "https" for the
ssl/tls engine to kick in.
When used as a stand-alone koji API client, two new command
line options are provided, --cert and --ca. See their help
text for a description.
Use the standard session and options mock object together with the
new composer mock object to simulate a successful compose:
the mock composer will accept the request and also status calls
for it, which will immediately return with success. The plugin
should then return and indicate a successful compose.
Use httpretty to mock composer responses. Create a helper method
to configure a session object that should result in a valid
compose request. Simulate a bad request by asking for an arch
that the mock composer will refuse and check the correct exception
is thrown in the builder plugin.
Use the requests python package, which is more convenient to use,
and also supports sessions, where global options, like TLS certs
can be set.
Adapt the container and the spec file to install and require
the python package.
Add the requests and httpretty packages to the test environment.
The former will be used in the builder plugin and the latter for
mocking http requests.
Create a new plugintest.PluginTest class that shares the plugin
loading code that is common to all plugin testing. Adapt the
existing (hub, builder) tests.
Also correct the name for test_builder.TestHubPlugin to
TestBuilderPlugin.
