Login page blank

[JDtheHutt]

I have setup a container to run in my Kubernetes cluster. I at first could not get the mongodb part to load but realised it really did not like my NFS volume provisioner and would only actually fire up if it used a direct filepath on the host. It now claims to have loaded in the logs and I get a response when accessing the login page URL, with it detecting the self-signed certificate provided by the system defaults, but the login page stubbornly remains blank. This is the case for http and https on the manage and portal ports. I also tried different browsers just in case it was a Firefox issue, but Chrome was the same. I also tried on an amd64 and arm64 setup, as well as different Omada versions, but with the same result.

The below is all that is shown in the omada logs. Are you able to advise please?

INFO: Time zone set to 'Europe/London'
INFO: Database directory missing; creating '/opt/tplink/EAPController/data/db'
done
INFO: Starting Omada Controller as user omada
tail: cannot open '/opt/tplink/EAPController/logs/server.log' for reading: No such file or directory
tail: '/opt/tplink/EAPController/logs/server.log' has appeared; following new file
2021-04-16 15:30:22 [log4j-thread] [INFO]-[SourceFile:29] - success to load configuration omada.properties
2021-04-16 15:30:23 [main] [INFO]-[SourceFile:75] - going to start local mongod.
2021-04-16 15:30:23 [main] [INFO]-[SourceFile:158] - mongodb process id is 34
2021-04-16 15:30:23 [main] [INFO]-[SourceFile:139] - Mongo DB server started
2021-04-16 15:30:25 [main] [WARN]-[AbstractConnector.java:205] - Acceptors should be <= availableProcessors: ServerConnector@14fc5f04{HTTP/1.1,[http/1.1]}{0.0.0.0:0}
2021-04-16 15:30:25 [main] [WARN]-[AbstractConnector.java:205] - Acceptors should be <= availableProcessors: ServerConnector@6a4f1a55{HTTP/1.1,[http/1.1]}{0.0.0.0:0}
2021-04-16 15:31:10 [main] [INFO]-[SourceFile:35] - monitor context initialing...
2021-04-16 15:31:15 [main] [INFO]-[SourceFile:299] - restart all customize tasks.
2021-04-16 15:31:18 [device-discovery-server] [INFO]-[SourceFile:54] - Start device discovery server
2021-04-16 15:31:18 [device-manage-server] [INFO]-[SourceFile:111] - Start device manage server
2021-04-16 15:31:18 [device-adopt-server] [INFO]-[SourceFile:82] - Start device adopt server
2021-04-16 15:31:20 [main] [INFO]-[SourceFile:126] - no need to compatible db.
2021-04-16 15:31:20 [main] [INFO]-[SourceFile:20] - Omada Controller started
2021-04-16 15:31:43 [scheduled-pool-6] [INFO]-[SourceFile:105] - Controller has not bound owner, cancel online checking Firmware tasks.

[mbentley]

A k8s manifest/however you are deploying it would be helpful from a reproduction standpoint. I haven't tried it on k8s but there is no reason it should work. Also, the flavor and high level environment details about k8s could also be useful.

Also, it should be mentioned that if you are not able to specifically specify the ports in which are going to be exposed where it matches the container to where it is exposed on the host, it won't work. I think there is something janky with how they deal with the ports and you probably will see redirection attempts to go to the specific port, even if you re-map it via your k8s service.

[mbentley]

Here is a great example of the port binding remapping not working:

docker run -d \
  --name omada-controller \
  --restart unless-stopped \
  -p 8089:8088 \
  -p 8044:8043 \
  -p 8844:8843 \
  -p 29810:29810 \
  -p 29810:29810/udp \
  -p 29811:29811 \
  -p 29811:29811/udp \
  -p 29812:29812 \
  -p 29812:29812/udp \
  -p 29813:29813 \
  -p 29813:29813/udp \
  -e MANAGE_HTTP_PORT=8088 \
  -e MANAGE_HTTPS_PORT=8043 \
  -e PORTAL_HTTP_PORT=8088 \
  -e PORTAL_HTTPS_PORT=8843 \
  -e SHOW_SERVER_LOGS=true \
  -e SHOW_MONGODB_LOGS=false \
  -e SSL_CERT_NAME="tls.crt" \
  -e SSL_KEY_NAME="tls.key" \
  -e TZ=Etc/UTC \
  -v omada-data:/opt/tplink/EAPController/data \
  -v omada-work:/opt/tplink/EAPController/work \
  -v omada-logs:/opt/tplink/EAPController/logs \
  mbentley/omada-controller:4.2

It works fine if the internal and external ports match but you get a 404 if they do not. This is something the application seems to be doing from what I can tell. This is probably going to be problematic for running it in k8s as it would need to be mapped to a set of known high ports for you to be able to run it with the appropriate environment variables.

[JDtheHutt]

Ahh, thank you. That likely explains it. Honestly, I am still very new to k8s and my yamls are pretty janky in themselves. I need to find time to work out ports in more detail as I am currently doing a horribly rough NodePort system and just mapping those things all over the place. I will give that a go and see if a cleaner solution that retains the intended ports works and confirm that in case it helps others do the same. Did you want me to close this for now or keep it open till I take a look at that? I can't give an exact time though, have 3 kids and so could be a couple of weeks before I am done.

[mbentley]

Up to you - it's a somewhat of a known problem. I don't get bent out of shape over open issues and just clean them every once and a while if there is no activity.

...and I know how the kid thing goes 👍

[JDtheHutt]

Well, they were all asleep and I decided now was as good as any! I did a rough hostPort setup to just expose the container on one specific node using the exact ports mapped. And the controller login page can now be accessed perfectly, so you were spot on. It will do me for now till I can work out a more elegant k8s solution if there is one. Thank you for the advice and the docker setup. I can finally get this all up and running and hopefully end the family rage on dodgy wifi spots in the house.

[mbentley]

Glad to help, good luck in your wifi adventures!

[simon-kolkmann]

Hey @JDtheHutt, did you ever get the device discovery to work with kubernetes? I'm currently mapping the containerPorts to a specific nodes hostPorts just like you did. I can access the web ui too, but the controller does not discover my access points.

The discovery works fine when I run the container locally with docker-compose.

Any help would be much appreciated!

[JDtheHutt]

Hey @JDtheHutt, did you ever get the device discovery to work with kubernetes? I'm currently mapping the containerPorts to a specific nodes hostPorts just like you did. I can access the web ui too, but the controller does not discover my access points.

The discovery works fine when I run the container locally with docker-compose.

Any help would be much appreciated!

I can certainly try though due to the delights of work and children I am still running my very messy yaml. It has worked perfectly though, even through a few cluster version upgrades. Could you post your yaml please and I can see how it compares to mine? You can send to me direct if you would rather not publish it fully even with any personal redactions. I shall have a look and see if I can spot anything I worked out for mine.

[simon-kolkmann]

Thank you, I'll attach my yamls! I removed everything that's not absolutly necessary (e.g. volume mounts).
I'm mapping only the ports I found here and this works fine with compose. I nevertheless tried including 29811-29813/udp in the pod spec, but it didn't make a difference.

I also noticed some warnings which only occur inside the pod, but I don't know if this is related to my problem.

2021-09-12 15:40:34 [main] [WARN]-[AbstractConnector.java:205] - Acceptors should be <= availableProcessors: ServerConnector@387a8303{HTTP/1.1,[http/1.1]}{0.0.0.0:0}
2021-09-12 15:40:34 [main] [WARN]-[AbstractConnector.java:205] - Acceptors should be <= availableProcessors: ServerConnector@1224144a{HTTP/1.1,[http/1.1]}{0.0.0.0:0}
[...]
2021-09-12 15:40:54 [site-event-bus-0] [WARN]-[SourceFile:439] - restart hotspot task failed, site : Default, timeZone : null

Anyway, here you go:

Compose

version: "3.1"

services:
   omada-controller:
     container_name: omada-controller
     image: mbentley/omada-controller:4.4
     ports:
      - 8043:8043
      - 29810:29810/udp
      - 29811:29811
      - 29812:29812
      - 29813:29813
     environment:
      - TZ=Europe/Berlin
      - MANAGE_HTTPS_PORT=8043
      - PORTAL_HTTPS_PORT=8043

Kubernetes

apiVersion: apps/v1
kind: Deployment
metadata:
  name: omada
  labels:
    app: omada
spec:
  replicas: 1
  selector:
    matchLabels:
      app: omada
  template:
    metadata:
      labels:
        app: omada
    spec:
      nodeName: [...]
      containers:
        - name: omada
          image: mbentley/omada-controller:4.4
          imagePullPolicy: Always
          env:
            - name: TZ
              value: Europe/Berlin
            - name: MANAGE_HTTPS_PORT
              value: '8043'
            - name: PORTAL_HTTPS_PORT
              value: '8043'
          ports:
            - containerPort: 8043
              hostPort: 8043
              protocol: TCP
            - containerPort: 29810
              hostPort: 29810
              protocol: UDP
            - containerPort: 29811
              hostPort: 29811
              protocol: TCP
            - containerPort: 29812
              hostPort: 29812
              protocol: TCP
            - containerPort: 29813
              hostPort: 29813
              protocol: TCP