Unable to install the demo

Manager UI
1

Dear community members,

I kindly ask you for your help. I am struggling to run at least the very basic Openremote instance demo version, not mentioning I also tried the custom deployment with the same result. I read the wiki, I searched for hints and tips all over.

This is my docker-compose.yml

version: '3'

services:
  openremote-keycloak:
    image: openremote/keycloak:latest
    container_name: openremote_keycloak
    environment:
      DB_VENDOR: postgres
      DB_ADDR: <postgis host>
      DB_PORT: 5432
      DB_DATABASE: postgres
      DB_USER: postgres
      DB_PASSWORD: <postgres password>
      DB_SCHEMA: public

      KEYCLOAK_PASSWORD: secret
      KEYCLOAK_FRONTEND_URL: https://<public domain>/auth

      # without this env I saw errors in the log but it let me login, so this is not the source of the problem for sure
      HTTPS_ENABLED: true
    networks:
      - backend
    restart: always

  openremote-manager:
    image: openremote/manager:latest
    container_name: openremote_manager
    environment:
      OR_ADMIN_PASSWORD: secret
      OR_SETUP_TYPE: demo
      OR_DEV_MODE: false
      OR_SETUP_RUN_ON_RESTART: true
      OR_SSL_PORT: 443
      OR_HOSTNAME: <public.domain>

      OR_WEBSERVER_LISTEN_HOST: 0.0.0.0
      OR_WEBSERVER_LISTEN_PORT: 8080

      OR_DB_VENDOR: postgres
      OR_DB_HOST: <postgis host>
      OR_DB_PORT: 5432
      OR_DB_NAME: postgres
      OR_DB_SCHEMA: openremote
      OR_DB_USER: postgres
      OR_DB_PASSWORD: <postgres password>

      OR_IDENTITY_PROVIDER: keycloak
      OR_KEYCLOAK_HOST: openremote_keycloak
      OR_KEYCLOAK_PORT: 8080
      KEYCLOAK_FRONTEND_URL: https:/<public domain>/auth

    networks:
      - backend
    depends_on:
      openremote-keycloak:
        condition: service_healthy
    restart: always

networks:
  backend:

Keycloak

I am able to login to Keycloak without any issues whatsoever. Accessing the URL https://<public domain>/auth correctly forwards me to the Keycloak homepage from where I can login.

I can login without Openremote installed with the default Keycloak login page; when Openremote is run too, I get Openremote login page and the Smartcity real is created and visible in the administration.

Manager

I am unable though to make Openremote running no matter what I try. When I go to https://<public domain>, it forwards me to https://<public domain>/manager as it is set by default. All I see though is a blank page.

This is the logged message visible in the docker console:

2022-07-08 15:47:19.579  WARN    [WebService task-2             ] org.keycloak.adapters.KeycloakDeployment : Failed to load URLs from http://openremote_keycloak:8080/auth/realms/master/.well-known/openid-configuration
java.lang.Exception: Internal Server Error
	at org.keycloak.adapters.KeycloakDeployment.getOidcConfiguration(KeycloakDeployment.java:233)
	at org.keycloak.adapters.KeycloakDeployment.resolveUrls(KeycloakDeployment.java:182)
	at org.keycloak.adapters.KeycloakDeployment.getAuthUrl(KeycloakDeployment.java:251)
	at org.keycloak.adapters.OAuthRequestAuthenticator.getRedirectUri(OAuthRequestAuthenticator.java:175)
	at org.keycloak.adapters.OAuthRequestAuthenticator.loginRedirect(OAuthRequestAuthenticator.java:213)
	at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
	at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:138)
	at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
	at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:268)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
	at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
	at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
	at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
	at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2019)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1449)
	at java.base/java.lang.Thread.run(Thread.java:833)

Then this is the Chrome debug console info:

image
image1278×329 13.5 KB

It is just a demo following the instructions in the Wiki. I also tried the custom deployment and uploaded different manager_config.json files into the /deployment in the container folder but saw no difference at all.

Could someone please help me out running at least the demo from where I believe I could go further. At this point though I have no idea where to start.

2

HI,

When you say demo I don’t know if you’re referring to starting an empty system or starting with what we call the smart city demo (some example assets based around the Rotterdam region); to start an empty system then you just need to use the default docker compose profile from the main repo:

If you are interested in running with the smartcity demo then you just need to set the OR_SETUP_TYPE env variable to demo on the manager container, as shown here.

3

Hello Rich,

thank you for reaching out. I am in fact trying to run the smartcity demo to see and understand the folder structure in order to later do the custom deployment. I installed the demo.yml and it worked fine but I still experienced issues with my own deployment.

Anyways I spent quite a lot of hours trying to find the issue and I found it, it might be bug or a feature, you please tell me.

setup

This is the docker-compose.yml I am using as a test deployment, which has as little variables as possible:

version: '3'

services:
  openremote-proxy:
    image: openremote/proxy:latest
    container_name: docker-openremote_proxy_1
    ports:
      - "80:80"
      - "443:443"
      - "8883:8883"
    volumes:
      - ./data/proxy:/data/proxy
    environment:
      DOMAINNAME: <public.hostname>
      # USE A CUSTOM PROXY CONFIG - COPY FROM https://github.com/openremote/proxy/blob/main/haproxy.cfg
      HAPROXY_CONFIG: '/data/proxy/haproxy.cfg'
    networks:
      - backend
    restart: always

  openremote-postgresql:
    image: openremote/postgresql:latest
    container_name: docker-openremote_postgresql_1
    volumes:
      - ./data/postgres:/var/lib/postgresql/data
    networks:
      - backend
    restart: always

  openremote-keycloak:
    image: openremote/keycloak:latest
    container_name: ${CUSTOM_KEYCLOAK_NAME}
    environment:
      DB_ADDR: docker-openremote_postgresql_1
      KEYCLOAK_PASSWORD: secret
      KEYCLOAK_FRONTEND_URL: https://<public.hostname>/auth
    networks:
      - backend
    depends_on:
      openremote-postgresql:
        condition: service_healthy
    restart: always

  openremote-manager:
    image: openremote/manager:latest
    container_name: docker-openremote_manager_1
    environment:
      OR_DB_HOST: docker-openremote_postgresql_1
      OR_HOSTNAME: <public.hostname>
      OR_KEYCLOAK_HOST: ${CUSTOM_KEYCLOAK_NAME}
      KEYCLOAK_FRONTEND_URL: https://<public.hostname>/auth
    networks:
      - backend
    # depends_on:
    #   openremote-keycloak:
    #     condition: service_healthy
    restart: always

networks:
  backend:
    name: docker-backend

The only lines I changed in the haproxy.cfg are to fit the testing scenario

backend manager_backend
  #server proxy_backend_host "${MANAGER_HOST}":"${MANAGER_WEB_PORT}" resolvers docker_resolver
  server proxy_backend_host "docker-openremote_manager_1":"8080" resolvers docker_resolver

backend keycloak_backend
  #server proxy_backend_host "${KEYCLOAK_HOST}":"${KEYCLOAK_PORT}" resolvers docker_resolver
  server proxy_backend_host "docker-openremote_keycloak_1":"8080" resolvers docker_resolver

In comparison with the default docker-compose.yml in the repo I also use container_name to better suit my needs. That turned out to be a problem. The only variable in the .yml file here is CUSTOM_KEYCLOAK_NAME. I thought setting it to container_name would work but it did not.

Well, it did, once I did not use any underscores in the name.

scenario 1

This is a working compose line:

CUSTOM_KEYCLOAK_NAME=custom-keycloak-1 docker-compose up -d

and accessing the main manager page I see in the manager container log this line:

2022-07-13 23:28:36.738  INFO    [WebService task-1             ] org.keycloak.adapters.KeycloakDeployment : Loaded URLs from http://custom-keycloak-1:8080/auth/realms/master/.well-known/openid-configuration

scenario 2

Launching the container with

CUSTOM_KEYCLOAK_NAME=custom_keycloak_1 docker-compose up -d

I get this error log at the manager container though

2022-07-13 23:25:26.285  WARN    [WebService task-1             ] org.keycloak.adapters.KeycloakDeployment : Failed to load URLs from http://custom_keycloak_1:8080/auth/realms/master/.well-known/openid-configuration
java.lang.Exception: Internal Server Error
	at org.keycloak.adapters.KeycloakDeployment.getOidcConfiguration(KeycloakDeployment.java:233)
	at org.keycloak.adapters.KeycloakDeployment.resolveUrls(KeycloakDeployment.java:182)
	at org.keycloak.adapters.KeycloakDeployment.getAuthUrl(KeycloakDeployment.java:251)
	at org.keycloak.adapters.OAuthRequestAuthenticator.getRedirectUri(OAuthRequestAuthenticator.java:175)
	at org.keycloak.adapters.OAuthRequestAuthenticator.loginRedirect(OAuthRequestAuthenticator.java:213)
	at org.keycloak.adapters.OAuthRequestAuthenticator.authenticate(OAuthRequestAuthenticator.java:275)
	at org.keycloak.adapters.RequestAuthenticator.authenticate(RequestAuthenticator.java:138)
	at org.keycloak.adapters.undertow.AbstractUndertowKeycloakAuthMech.keycloakAuthenticate(AbstractUndertowKeycloakAuthMech.java:110)
	at org.keycloak.adapters.undertow.ServletKeycloakAuthMech.authenticate(ServletKeycloakAuthMech.java:92)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:245)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:268)
	at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:231)
	at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:125)
	at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:99)
	at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:92)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
	at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.keycloak.adapters.undertow.ServletPreAuthActionsHandler.handleRequest(ServletPreAuthActionsHandler.java:69)
	at io.undertow.servlet.handlers.SendErrorPageHandler.handleRequest(SendErrorPageHandler.java:52)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:387)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:841)
	at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2019)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1558)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1449)
	at java.base/java.lang.Thread.run(Thread.java:833)

For some reason the variable OR_KEYCLOAK_HOST does not accept anything with an underscore. Is this a bug?

4

I just noticed the Keycloak image was upgraded to v18 with many env variables changing. I don’t think this will have an impact on what I described above, as the issue seems to be coming from the Manager image rather than from Keycloak.

5

I think underscores are invalid characters for hostname according to RFC 822.

I don’t understand why you are changing container names, you just use the -p STACK_NAME option with docker compose to prefix docker container names with whatever you want, the internal container names should not need changing unless you can give me a good reason.

6

Indeed I just pushed an update to work with Keycloak v18+ and unfortunately env variable names have changed but generally only the following should be important:

OR_HOSTNAME
OR_SSL_PORT
7

I use Portainer most of the time for deployment and it likes to use odd names sometimes for containers so I prefer to name it the way I need.

Also I use multiple stacks. You are right I might not need to change the container names but I do that for easier container management. Never had a similar problem though. Basically calling a container from another container using its container_name always worked fine even with underscores in the name. But if you say it’s an illegal character even within docker, okay, I respect that.

8

Well docker might not mind but HAProxy might (probably does from what you’ve written).

9

I used HAProxy and Caddy and both did have the same problem. I use Caddy in general, as it’s very simple to setup.

Anyways I browsed a little bit and underscores should be okay in hostnames: dns - Can (domain name) subdomains have an underscore "_" in it? - Stack Overflow

EDIT: My bad. Domain names are okay, while host names are not. Openremote calls a domain name as I see in the log though (using the URI scheme).

10

Caddy is indeed very simple and easy to use but last time I checked it only supports HTTP whereas we use HAProxy to handle TLS termination for any TCP traffic (including MQTT).

11

Oh, okay. I see. I prefer to do it by exposing the MQTT port to other containers on the same server and keep the MQTT server accessible locally only but I get the point.

12
13

Or this one.

1 Like