By default, the canned Pbench Server deployment configures all accesses -- Server, PostgreSQL, Elasticsearch, browser, and especially Keycloak -- with the assumption that all accesses to and fro will be on localhost. This works fine for functional test, but for development (at least for me...), the client/browser is not necessarily running on the host where the servers are running. This means that the Dashboard code is served from the Pbench Server using an IPv4 address instead of localhost...which means that, for the Keycloak login dance, the redirect back from the Keycloak Server to the Dashboard has to match a valid redirect pattern which references the Dashboard using the IPv4 address of the Pbench Server and not just localhost.
This PR addresses this by enhancing the load_keycloak.sh script to generate a full list of plausible redirects. Currently, the script installs two -- a development UI server and the containerized localhost -- to which this change adds anything which hostname's -I, -A, and -f options' outputs provides (that is, any way that the host knows of in terms of how it can be addressed...including the IPv4 address which I'm using.)
Unfortunately, this covers only the return from the Keycloak server...we also need to make sure that, when the Dashboard attempts to request authentication from the Keycloak server, it uses a suitable address (i.e., in my case, an IP address rather than localhost). This is determined by the server_url option in the openid section of the pbench_server.cfg file. So, this PR also modifies run-pbench-in-a-can to set that value according to a new environment variable, PB_HOST. (This replaces the machinations based on the previous, otherwise unused PB_HOST_IP environment variable, which don't seem to have any effect.)
And, with this newly-acquired acumen for generating lists of hostnames, I decided to enhance the TLS certificate generation along the lines of the Keycloak redirect: with this PR, the certificate will now cover accesses to the host using any name or IP address which the hostname-I and -A switches produce, along with localhost and 127.0.0.1. And, the script issues a warning if the requested PB_HOST value isn't in the list of certifiable hosts/addresses.
And, while I was tweaking the pbench-server.cfg creation code, I made run-pbench-in-a-can set values for the Keycloak realm and client, so that we are assured that they will match the setup later established by the load_keycloak.sh script.
webbnh
commented
1 year ago
By default, the canned Pbench Server deployment configures all accesses -- Server, PostgreSQL, Elasticsearch, browser, and especially Keycloak -- with the assumption that all accesses to and fro will be on
localhost. This works fine for functional test, but for development (at least for me...), the client/browser is not necessarily running on the host where the servers are running. This means that the Dashboard code is served from the Pbench Server using an IPv4 address instead oflocalhost...which means that, for the Keycloak login dance, the redirect back from the Keycloak Server to the Dashboard has to match a valid redirect pattern which references the Dashboard using the IPv4 address of the Pbench Server and not justlocalhost.This PR addresses this by enhancing the
load_keycloak.shscript to generate a full list of plausible redirects. Currently, the script installs two -- a development UI server and the containerizedlocalhost-- to which this change adds anything whichhostname's-I,-A, and-foptions' outputs provides (that is, any way that the host knows of in terms of how it can be addressed...including the IPv4 address which I'm using.)Unfortunately, this covers only the return from the Keycloak server...we also need to make sure that, when the Dashboard attempts to request authentication from the Keycloak server, it uses a suitable address (i.e., in my case, an IP address rather than
localhost). This is determined by theserver_urloption in theopenidsection of thepbench_server.cfgfile. So, this PR also modifiesrun-pbench-in-a-canto set that value according to a new environment variable,PB_HOST. (This replaces the machinations based on the previous, otherwise unusedPB_HOST_IPenvironment variable, which don't seem to have any effect.)And, with this newly-acquired acumen for generating lists of hostnames, I decided to enhance the TLS certificate generation along the lines of the Keycloak redirect: with this PR, the certificate will now cover accesses to the host using any name or IP address which the
hostname-Iand-Aswitches produce, along withlocalhostand127.0.0.1. And, the script issues a warning if the requestedPB_HOSTvalue isn't in the list of certifiable hosts/addresses.And, while I was tweaking the
pbench-server.cfgcreation code, I maderun-pbench-in-a-canset values for the Keycloak realm and client, so that we are assured that they will match the setup later established by theload_keycloak.shscript.(Also, the initial commit picks a bunch of lint.)