Fix websocket url load fails and added persistence

[FernandoRod13]

Fix issue #258 rcon-web-admin chart issues

Problem Description

The rcon-web-admin chart has two critical issues that prevent it from working correctly in Kubernetes environments:

Issue 1: Broken WebSocket URL Configuration

Location: Container startup script

Problem: The container's default ENTRYPOINT script attempts to:

1. Install jq via apt-get to parse Kubernetes API responses
2. Query the Kubernetes API to dynamically discover the LoadBalancer IP
3. Set RWA_WEBSOCKET_URL based on the discovered IP

This fails in most Kubernetes deployments because:

• apt-get may fail due to read-only root filesystems or permission issues
• Even if jq installation succeeds, the API call may return an empty response
• When jq fails, it outputs nothing, resulting in RWA_WEBSOCKET_URL=ws://:4327 (empty host)

Result: The web UI loads but fails to connect to the backend websocket, showing "Invalid url for WebSocket ws://:4327"

Issue 2: No Database Persistence

Location: values.yaml - persistence section

Problem: The chart uses an emptyDir volume for the database (/opt/rcon-web-admin/db), which means:

• All server configurations are lost on pod restart
• User settings are reset
• A new server ID is generated each restart, confusing clients

Result: Users must re-configure their Minecraft servers after every deployment update or pod restart.

Solution

Fix 1: Add Persistent Storage Support

Add proper PVC-based persistence to the values.yaml:

persistence:
  enabled: true
  storageClass: ""        # Uses default storage class
  accessMode: ReadWriteOnce
  size: 1Gi

This requires updating the deployment to use a PVC instead of emptyDir.

Fix 2: Add WebSocket URL Environment Variables

Add environment variable support for websocket configuration with sensible defaults:

rconWeb:
  websocketUrl: "ws://localhost:4327"      # Default for internal/LB access
  websocketUrlSsl: "wss://localhost:4327"  # Default for SSL

Why localhost:4327 works: The browser connects to the LoadBalancer IP (e.g., http://192.168.1.100:8080), which forwards traffic to the pod. The pod's port 4327 is exposed via the same service, so localhost:4327 resolves correctly when accessed through the LoadBalancer.

When to override: If using an external proxy or ingress with different hostnames, users can set custom URLs.

Fix 3: Update Deployment for Persistence

The deployment needs to conditionally use a PVC when persistence is enabled:

volumes:
  {{- if .Values.persistence.enabled }}
  - name: db
    persistentVolumeClaim:
      claimName: {{ include "rcon-web-admin.fullname" . }}-db
  {{- else }}
  - name: db
    emptyDir: {}
  {{- end }}

Fix 4: Remove deployment command

-       {{- if not .Values.ingress.enabled }}
-          command:
-            - '/bin/sh'
-            - '-c'
-            - |-
-              # Installing jq to parse k8s response
-              export DEBIAN_FRONTEND=noninteractive
-              apt-get -qq update >/dev/null && apt-get -qq install -y jq > /dev/null
-              # Configuring k8s API auth
-              APISERVER=https://kubernetes.default.svc
-              SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
-              NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
-              TOKEN=$(cat ${SERVICEACCOUNT}/token)
-              CACERT=${SERVICEACCOUNT}/ca.crt
-              # Querying for websocket service
-              WS_SERVICE="$(curl --silent --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/{{ .Release.Namespace }}/services/{{ include "rcon-web-admin.fullname" . }})"
-              {{- if contains "LoadBalancer" .Values.service.type }}
-              WS_IP="$(echo "$WS_SERVICE" | jq -r .status.loadBalancer.ingress[0].ip)"
-              WS_PORT="{{ .Values.service.wsPort }}"
-              {{- else }}
-              {{- fail "Selected service type is not supported"}}
-              {{- end }}
-              export RWA_WEBSOCKET_URL="ws://$WS_IP:$WS_PORT"
-              export RWA_WEBSOCKET_URL_SSL="wss://$WS_IP:$WS_PORT"
-             /usr/local/bin/node src/main.js start
-          {{- end}}

Workaround for Existing Deployments

Users with existing deployments can work around these issues by:

1. Patch the deployment with websocket URL (using localhost works when accessed via LoadBalancer):

kubectl patch deployment rcon-web-rcon-web-admin \
  --namespace minecraft \
  --type=strategic \
  -p '{"spec":{"template":{"spec":{"containers":[{"name":"rcon-web-admin","env":[{"name":"RWA_WEBSOCKET_URL","value":"ws://localhost:4327"},{"name":"RWA_WEBSOCKET_URL_SSL","value":"wss://localhost:4327"}]}]}}}}'

2. Add persistence:

kubectl patch deployment rcon-web-rcon-web-admin \
  --namespace minecraft \
  --type=strategic \
  -p '{"spec":{"template":{"spec":{"volumes":[{"name":"db","persistentVolumeClaim":{"claimName":"rcon-web-db"}}]}}}}'

3. Create a PVC:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rcon-web-db
spec:
  accessModes: [ReadWriteOnce]
  resources:
    requests:
      storage: 1Gi

Testing

To verify the fixes:

1. Deploy with persistence enabled
2. Configure a Minecraft server in the web UI
3. Restart the deployment: kubectl rollout restart deployment rcon-web-rcon-web-admin
4. Verify server configuration persists after restart
5. Verify websocket connection works from browser

[itzg]

Thanks for working on this. The original logic was indeed over ambitious and I'm surprised I approved the use of apt during an entry point.

[itzg]

Looks great. Please also bump the chart version.

[FernandoRod13]

Can't believe I missed it in my original commit. All done!

[itzg]

As I mentioned in the linked issue, that rcon web admin (which is not mine) doesn't seem to work most of the time. I'm guessing that's why the test deploy is failing.

[itzg]

Ah yes, that fix makes total sense

[FernandoRod13]

There are several issues on the CI side. I have tested this on my own cluster and the rcon-web is able to connect to the server.

Issues

Metallb IP Pool Allocation

The default rconHost is set to 127.0.0.1 while the Metallb ip address-pool is set to 192.168.1.240-192.168.1.250. There is no overlap so no IP would be allocated making the chart fail to complete deployment. By setting the service.type to ClusterIP we can bypass Metallb.

Alternatively we could set an IP for the rconHost within the IP pool but then there doesn't seem to be a Minecraft deployment ready to accept the required websocket connection so I think it would also fail.

No Minecraft deployment to Test RCON Connection.

Options

1. Use ClusterIP + empty rconHost (simplest for CI)
2. Deploy a test Minecraft server in the test namespace for CI
3. Add a sidecar that listens on port 25575 as a mock RCON server