e9768b6bc6
* Allow exposing access to the underlying container This exposes the Container response from the Docker API, allowing consumers of the testhelper to interact with the newly started running container instance. This will be useful for two reasons: 1. Allowing radiusd container to start its own daemon after modifying its configuration. 2. For loading certificates into a future similar integration test using the PKI secrets engine. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> * Allow any client to connect to test radiusd daemon This fixes test failures of the following form: > 2022-09-07T10:46:19.332-0400 [TRACE] core: adding local paths: paths=[] > 2022-09-07T10:46:19.333-0400 [INFO] core: enabled credential backend: path=mnt/ type=test > 2022-09-07T10:46:19.334-0400 [WARN] Executing test step: step_number=1 > 2022-09-07T10:46:19.334-0400 [WARN] Executing test step: step_number=2 > 2022-09-07T10:46:29.334-0400 [WARN] Executing test step: step_number=3 > 2022-09-07T10:46:29.335-0400 [WARN] Executing test step: step_number=4 > 2022-09-07T10:46:39.336-0400 [WARN] Requesting RollbackOperation > --- FAIL: TestBackend_acceptance (28.56s) > testing.go:364: Failed step 4: erroneous response: > > &logical.Response{Secret:<nil>, Auth:<nil>, Data:map[string]interface {}{"error":"context deadline exceeded"}, Redirect:"", Warnings:[]string(nil), WrapInfo:(*wrapping.ResponseWrapInfo)(nil), Headers:map[string][]string(nil)} > FAIL > FAIL github.com/hashicorp/vault/builtin/credential/radius 29.238s In particular, radiusd container ships with a default clients.conf which restricts connections to ranges associated with the Docker daemon. When creating new networks (such as in CircleCI) or when running via Podman (which has its own set of network ranges), this initial config will no longer be applicable. We thus need to write a new config into the image; while we could do this by rebuilding a new image on top of the existing layers (provisioning our config), we then need to manage these changes and give hooks for the service setup to build it. Thus, post-startup modification is probably easier to execute in our case. Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com> |
||
---|---|---|
.. | ||
audit | ||
credential | ||
logical | ||
plugin |