I have a small bug with my openhab. On my gentoo, I installed openhab to /opt/openhab2 by unzipping it (since it’s not into portage). This work perfectly, but there’s something I can’t find. The folder it try to use is always /opt/openhab2. Because of that, when I move it, it give error that it cannot find this folder.
For instance, I’m trying to move to docker, thus I copied over my files to the new userdata / conf / addons folder and load docker and map these folder per openhab docker doc. This worked, but then again, I’m getting error that it cannot find /opt/openhab2. Where could this path be?
You try to use an other folder as root folder for the OH installation instead of /opt/openhab2, right ?
How do you start the OH instance ?
Do you run <…>/runtime/bin/setenv ?
As far as I understand the code ( in setenv ) this should set all the environment variables like OPENHAB_HOME, OPENHAB_USERDATA, … by running oh2_dir_layout.
My old installation was an unzipped in /opt/openhab2. Now, in docker, from the docker doc, everything is in /openhab. Because of that, when I start openhab in docker with my old data, it’s trying to get to /opt/openhab2 for some stuff. It still boot up and stuff work, but I see these errror.
I ran the docker with the same command from the docker page:
docker run
–name openhab
–net=host
-v /etc/localtime:/etc/localtime:ro
-v /etc/timezone:/etc/timezone:ro
-v /opt/openhab/docker/conf:/openhab/conf
-v /opt/openhab/docker/userdata:/openhab/userdata
-v /opt/openhab/docker/addons:/openhab/addons
-d
-e USER_ID=249
-e GROUP_ID=248
-e OPENHAB_HTTP_PORT=9999
-e OPENHAB_HTTPS_PORT=9443
–restart=unless-stopped
openhab/openhab:latest
I doesn’t seem to be the home folder, it’s a lot of felix error. I just did something to find all instance and that’s what I got:
Does the startup in docker set the environment variables ( OPENHAB_HOME, etc. ) ?
I did not check all the files that you posted but those that I checked are not part of the zip file thus these files mustbe generated during initial startup of OH.
Yes, it set it to /openhab. But what I found out is that it’s hardcoded in the files (that’s what my command showed). What I did is run a sed to replace the string in all of the files and now no more error. Just weird that these file have hardcoded path.
It’s hardcoded in those files because of the execution of oh2_dir_layout.
The output are the files you listed containing the path detected during runtime of oh2_dir_layout.
That is only within the Docker container. Your shared volumes can point to wherever you desire. I am currently testing with /opt/openhab but may try /srv/openhab to better align with the FHS 3.0 filesystem standard. The volume location is determined in either your docker run command or your docker-compose configuration file.
That wasn’t the problem. Problem was that some file had hardcoded path in them. Since it come from an installation that was on /opt/openhab, it was looking there. All my mounts are correct on docker.
Also, I’m unsure about fhs 3.0, for me the new place was /opt, I saw everything everywhere get there in the past 2 years on all doc I saw. I’m unused to that since I used to work with Linux in the 90s.
It is hard-coded within the container but there is usually no reason to look there. The documentation on Docker Hub is quite clear in their examples.
No worries. It is a Linux standard. I like having everything in one place too but files that are changing do not belong in /opt. That is just a technicality.
It is not hardcoded in the container. It is hardcoded in files under user data. If you look at what I quoted, it’s part of files I copied over from my zip installation. I even had 3 different hardcoded path in the end because I had moved it 3 times in the past trying to make a standard until I saw all the error saying it always search for /opt/openhab2. Since now I moved to docker, it gave me the same error I had in the past and I wanted to get rid of this error.
Exact, this is the reason why you see these paths.
If you would start openHAB in docker from ‘scratch’ without these files you should get correct paths in the files under userdata as they are created during ( first ) runtime.
This is intended by design of OH and makes the paths in the files independent of OSs.
Yeah I just don’t get why these are hardcoded. It should used the homedir var like the rest. It means the installation can’t be moved because of that. At least I still have some basic skill left in my brain and was able to sed all the path to the new one and it fixed the issue. This problem is outside of docker, can be reproduce with any installation.
Forget Docker, it has nothing to do with docker in the end. The problem is, in a running instance, some file are created while running and in those file, it used an hardcoded path. If you check my log up there, I did a command to read all files and chech for the path “/opt/openhab”. It returned many files that are saved under “userdata/config/”, “userdata/tmp/instances/” and “userdata/etc”.
you can see in these file, for exemple, in the file “userdata/config/org/jupnp.config”, there is a line that says “felix.fileinstall.filename=“file:/opt/openhab2/userdata/etc/org.jupnp.cfg””
The path is hardcoded, no var. It might have been created at first with a homedir var, but now it doesn’t use it anyway. And that’s where I’m saying it’s bad, it should keep the var when there’s a var and be expended at runtime like all other var.
Nothing to do with Debian, Docker, entrypoint or anything like that. It’s just how the runtime is. Outside of docker, if I move my old installation to a new folder like I did when I switched from 2.4 to 2.5.1, it caused the same problem, out of docker.
Those files are managed by Apache Felix File Install which is a dependency of Karaf, which is a dependency of openHAB. So it is unaware of all these OH specific configuration variables.
