The Altair Community is migrating to a new platform to provide a better experience for you. In preparation for the migration, the Altair Community is on read-only mode from October 28 - November 6, 2024. Technical support via cases will continue to work as is. For any urgent requests from Students/Faculty members, please submit the form linked here
docker resolution causes RMSSOAuthenticator error, failed to load IDP config? Or something else?
Contributor IIRapidminer is installed on a VM (running docker) with valid certs for DNS "rapid.lab.bayeslearner.org".
The browser error is RMSSOAuthenticator error, failed to load IDP configuration, and the browser shows that the cert is valid.
When I ping the IP from the container rm-server-svc, I get:
rapidminer@rm-server-svc:/$ ping 192.168.1.231
The browser error is RMSSOAuthenticator error, failed to load IDP configuration, and the browser shows that the cert is valid.
When I ping the IP from the container rm-server-svc, I get:
rapidminer@rm-server-svc:/$ ping 192.168.1.231
PING 192.168.1.231 (192.168.1.231) 56(84) bytes of data.
64 bytes from 192.168.1.231: icmp_seq=1 ttl=64 time=0.476 ms
64 bytes from 192.168.1.231: icmp_seq=2 ttl=64 time=0.144 ms
64 bytes from 192.168.1.231: icmp_seq=3 ttl=64 time=0.092 ms
64 bytes from 192.168.1.231: icmp_seq=4 ttl=64 time=0.132 ms
^C
--- 192.168.1.231 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 70ms
rtt min/avg/max/mdev = 0.092/0.211/0.476/0.154 ms
When I ping using DNS name, I got the following. It seems that it is resolved to connect to one of the internal containers (wrongly?)
When I ping using DNS name, I got the following. It seems that it is resolved to connect to one of the internal containers (wrongly?)
rapidminer@rm-server-svc:/$ ping rapid.lab.bayeslearner.org
PING rapid.lab.bayeslearner.org (172.29.0.3) 56(84) bytes of data.
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=1 ttl=64 time=12.7 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=2 ttl=64 time=0.156 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=3 ttl=64 time=0.100 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=4 ttl=64 time=0.093 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=5 ttl=64 time=0.153 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=6 ttl=64 time=0.125 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=7 ttl=64 time=0.103 ms
64 bytes from rapidminer-rm-proxy-svc-1.jupyterhub-user-net-default (172.29.0.3): icmp_seq=8 ttl=64 time=0.105 ms
^C
--- rapid.lab.bayeslearner.org ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 161ms
rtt min/avg/max/mdev = 0.093/1.692/12.705/4.162 ms
When I run wget, connection is refused.
When I run wget, connection is refused.
rapidminer@rm-server-svc:/$ wget https://rapid.lab.bayeslearner.org:8443
--2022-12-20 22:28:38-- https://rapid.lab.bayeslearner.org:8443/
Resolving rapid.lab.bayeslearner.org (rapid.lab.bayeslearner.org)... 172.29.0.3
Connecting to rapid.lab.bayeslearner.org (rapid.lab.bayeslearner.org)|172.29.0.3|:8443... failed: Connection refused.
I saw in the log of rm-server-svc:
2022-12-20 21:57:24,963 WARN [org.keycloak.adapters.KeycloakDeployment] (http-/0.0.0.0:8080-1) Failed to load URLs from https://rapid.lab.bayeslearner.org:8443/auth/realms/master/.well-known/openid-configuration: java.net.ConnectException: Connection refused (Connection refused)
What did I do wrong? Also why does an internal container such as rm-server-svc try to contact an external public URL. I understand it is related to keycloak integration, but it doesn't seem to make sense to me.
Tagged:
0
Answers
https://rapid.lab.bayeslearner.org:8443/auth/admin/master/console/#/realms/master
Oh also if I hit the URL https://rapid.lab.bayeslearner.org:8443/auth/realms/master/.well-known/openid-configuration from a browser, it works:
{"issuer":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master","authorization_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/auth","token_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token","token_introspection_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token/introspect","userinfo_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/userinfo","end_session_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/logout","jwks_uri":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/certs","check_session_iframe":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/login-status-iframe.html","grant_types_supported":["authorization_code","implicit","refresh_token","password","client_credentials"],"response_types_supported":["code","none","id_token","token","id_token token","code id_token","code token","code id_token token"],"subject_types_supported":["public","pairwise"],"id_token_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"id_token_encryption_alg_values_supported":["RSA-OAEP","RSA1_5"],"id_token_encryption_enc_values_supported":["A128GCM","A128CBC-HS256"],"userinfo_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"request_object_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512","none"],"response_modes_supported":["query","fragment","form_post"],"registration_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/clients-registrations/openid-connect","token_endpoint_auth_methods_supported":["private_key_jwt","client_secret_basic","client_secret_post","tls_client_auth","client_secret_jwt"],"token_endpoint_auth_signing_alg_values_supported":["PS384","ES384","RS384","HS256","HS512","ES256","RS256","HS384","ES512","PS256","PS512","RS512"],"claims_supported":["aud","sub","iss","auth_time","name","given_name","family_name","preferred_username","email","acr"],"claim_types_supported":["normal"],"claims_parameter_supported":false,"scopes_supported":["openid","microprofile-jwt","web-origins","roles","phone","address","email","profile","offline_access"],"request_parameter_supported":true,"request_uri_parameter_supported":true,"code_challenge_methods_supported":["plain","S256"],"tls_client_certificate_bound_access_tokens":true,"introspection_endpoint":"https://rapid.lab.bayeslearner.org:8443/auth/realms/master/protocol/openid-connect/token/introspect"}have you already tried the suggestions from this post https://community.rapidminer.com/discussion/comment/69038/#Comment_69038 ?
Greetings,
Jonas
For some reason, in the rm_server_svc container, rapid.lab.bayeslearner.org is resolved to the proxy container's internal IP, not the physical host's external IP (192.168.1.231). When this happens, the docker port-mapping 8443:443 is bypassed and the request is not forwarded to the keycloak container.