Hi all,
I am (trying) to run OpenHAB 3.0.1 on Kubernetes. While things work using NFS storage for persistency, I am now trying to move to Rancher Longhorn as it provides distributed block storage across my 4 nodes K8S cluster and thus my setup would be fully High Availability enabled.
I am already running other workloads like Apache-PHP, Grafana, Prometheus, MQTT and InfluxDB on the cluster but unfortunatelly I cannot get OpenHAB up and running since there is a small issue with permissions:
Longhorn.io v1.1.0 does provide read/write access to the persistent volume mounts with root:root
only.
While I got Grafana to run by setting
securityContext:
runAsUser: 472
fsGroup: 472
The same is not working for Openhab using uid: 9001 and gid: 9001 and I have tried all variants.
The error message I get when doing so is
2021-02-22T23:06:51.093692405+01:00 stderr F + echo 'Create group openhab with id 9001'
2021-02-22T23:06:51.093739052+01:00 stdout F Create group openhab with id 9001
2021-02-22T23:06:51.093751274+01:00 stderr F + groupadd -g 9001 openhab
2021-02-22T23:06:51.1007452+01:00 stderr F groupadd: Permission denied.
2021-02-22T23:06:51.100841106+01:00 stderr F groupadd: cannot lock /etc/group; try again later.
Actually this is a bit surprising to me as I expected only the following shares to be on the “root only” volumes:
- /openhab/addons > openhab-addons-pvc (which is my longhorn PersistentVolumeClaim)
- /openhab/conf
- /openhab/userdata
However, "/etc/group" should be residing on the non-persistent container storage. Does the initialization script maybe try to change /etc/group when it already is using uid 9001 gid 9001?
If so, I wonder why the script is not executed as root and only once Openhab is getting started the uid 9001 is getting activated.
I might be completely wrong. Currently I do not see a way to fix this and would be happy with some ideas.
There is a Feature request for Longhorn to define (initial) volume permissions, yet it seems to be planned for v1.1.1 (already got moved from v1.1.0) [FEATURE] add volume attribute for filesystem owner · Issue #1165 · longhorn/longhorn · GitHub
Running a bit out of ideas and would have to go back to NFS where I do have two other challenges:
- Openhab does not recognize file changes anymore on NFS shares
- my NFS server is not HA (while the Longhorn Storage system is distributed across my whole K8S cluster and thus is HA enabled
Could someone explain how the OpenHAB init script works? Would there be a possibility that the container first is doing all changes that need root access and only then move to user:group 9001:9001?
Knowing it is a bad idea, running openhab as “root” would be an option, yet the init scrip would rename root with openhab which is not that good of an idea
Thx for help/ideas.
Cheers,
Jens
- Platform information:
- Hardware: 4x RasPI Model 4, 4 GB RAM
- OS: Ubuntu 20.10 (ARM64)
- OpenHAB Version: Latest docker container from https://hub.docker.com/r/openhab/openhab