Latest version 4.3.7 on GitHub instead of 5.0.1(?)

[florian-h05 (Florian H.)]

@Larsen

So you’re not happy with the idea to just update the current helper script with a functionality to choose the version and do a PR at the ve-helper github?

We are referring to two different things.
My comment belongs to the referenced suggestion to put the Proxmox script on the openHAB download page.
On the openHAB download page only the officially supported (i.e. the package, script whatever is under control and maintained by the openHAB project itself) ways of installing openHAB will be listed, no externally maintained packages, script or whatever.

[Larsen (Locke)]

Yes, that’s why I asked. A helper script within proxmox would be visible for many potential users. So it should be official or at least not in contrast to the openhab conventions. So what about putting it in the openhab github (where?) and after it’s merged a PR at the helper github with the same script is started.

To be honest I have no idea how to handle stuff like that.

[Nadahar (Nadar)]

Many such decisions have more to do with where the responsibility ends up than technical limitations. If OH “has a hand in this”, does that mean that OH also has the responsibility to update it when things change at proxmox? If so, it would mean that somebody would have to fulfill that responsibility on behalf of OH. If it’s unaffiliated with OH, nobody can “blame OH” when it stops working or fails.

There are lots and lots of different “solutions” out there, so one must “pick his responsibilities with care”. What if somebody volunteers to do it, but then stops caring after a year or two?

The “will to share responsibility” shown by the members of the other project also matters. As I understand it, they haven’t exactly been reaching out their hand here, which probably makes taking on the responsibility for a working solution less tempting for OH.

From OHs POV, the best thing would probably be if somebody, unofficially, made sure that it works. That would result in “no responsibility” for OH, and happy users.

[rlkoshak (Rich Koshak)]

@BG56

think the best would be that those who do the openhab change discuss with “Proxmox VE Helper-Script”-Support how to do it.

Why is it our responsibility to change how we do business to accommodate some third party? They want to support OH. Why isn’t it their responsibility to ask us how to do it?

It’s not a small thing. All the automated scripts and docs and everything else is built around how we do releases. It’s not just a matter of flipping a toggle to change it.

The last time OH redid all that stuff it took almost a year.

@BG56

In Openhabian one user mix different applications with openhab (secure?)

This makes no sense. Every service openHABian can install and configure runs under it’s own user individual user (openHAB runs under openhab, mosquito runs under mosquito, etc). And none of those users have a shell. There is a separate login user not used by any of the running services. Pretty standard stuff. what makes you think there’s only one user? LXC did not invent this shirt if separation.

Containers are great when you have the power for the overhead. And OH officially supports a Docker image. And it’s perfectly reasonable to run openHAB or openHABian in an LXC container. one of the strengths of LXC containers is that they tend to look and act more like a full VM compared to Docker or Kubernetes where the containers consists of battle enough to run one service. Running openHABian does not onligate you to run any other third party service in the same LXC container either. You can just run openHAB if you want and run other containers for everything else.

But what it does give you is the tools necessary to easily choose which version of OH you want to run.

@Larsen

So it should be official or at least not in contrast to the openhab conventions. So what about putting it in the openhab github (where?) and after it’s merged a PR at the helper github with the same script is started.

Sure we can have such a script. But how does it get into that Proxmox LXC? They are the ones building the image. They are the ones keeping the “official” version of the image on their collection of images. The openHAB project isn’t involved in any way. We can make a script in our repos for sure, but how do we make them use it?

[Larsen (Locke)]

@rlkoshak

But how does it get into that Proxmox LXC?

The helper scripts are not part of an image. They’re just on GitHub and provided for download if being selected. I guess the PR has to be done by us. There’s no third party that wants to provide openhab in proxmox. It’s just a community.

I see people using proxmox (not me) and with it they try out home automation systems. The current script that shows up doesn’t make sense as it’s not considering the openhab versioning mechanism. So the experience is pretty bad.

The question wether to install openhabian in that container is up to the maintainer of openhabian. @mstormi : I guess that’s not advocated?

@Nadahar

What if somebody volunteers to do it, but then stops caring after a year or two?

Then it’s not updated anymore or even breaks unless or until someone takes over. Just like with any binding in openhab or functionality in openhabian.

Overall I see it a little similar as with the raspberry imager. I wanted openhab to be included, started a PR in their repo and it was accepted. Runs pretty smooth since years now (with one exception).

[mstormi (Markus Storm)]

@Larsen

The question wether to install openhabian in that container is up to the maintainer of openhabian. @mstormi : I guess that’s not advocated?

why not? For OH on x86, openHABian on top of plain (user-installed) Debian is advocated, and you can use any of its applicable options such as to disable zram at install time.
That’s much more advocated than any homemade or 3rd party originated packaging like these discussed here.

Just be aware that we maintainers don’t support any virtualized hardware.
But that doesn’t mean it doesn’t work, it just means we don’t test against and don’t help with debugging because we don’t have the systems and time to.

[florian-h05 (Florian H.)]

@Larsen

A helper script within proxmox would be visible for many potential users. So it should be official or at least not in contrast to the openhab conventions. So what about putting it in the openhab github (where?) and after it’s merged a PR at the helper github with the same script is started.

If there is someone willing to maintain it and probably someone well known to the community, where you don’t expect he is gone in one or two years, we can create a repo for the helper script or Proxmox image to live in.
But then the script would obviously have to adjust to our versioning scheme.

I have just created a Homebrew formula for openHAB a week ago, it’s not yet on the download page but soon it will be.

[Larsen (Locke)]

@florian-h05

But then the script would obviously have to adjust to our versioning scheme.

I thought about a menu to select the version like this:

Test-script

#!/usr/bin/env bash

printf "\nFetching OpenHAB version data...\n\n"

# --- Stable releases
releases_json=$(curl -s https://api.github.com/repos/openhab/openhab-distro/releases?per_page=100)
stable_tags=$(echo "$releases_json" | jq -r '.[].tag_name' | grep -E '^[0-9]+\.[0-9]+\.[0-9]+$' | sort -Vr)
latest_stable=$(echo "$stable_tags" | head -n1)

# --- Milestones
milestones=$(echo "$releases_json" | jq -r '.[].tag_name' | grep -E '^5\.[0-9]+(\.[0-9]+)?\.?M[0-9]+' | sort -Vr | head -n1)

# --- Snapshot
latest_major_minor=$(echo "$stable_tags" | grep -E '^[0-9]+\.[0-9]+' | cut -d'.' -f1-2 | sort -Vu | tail -n1)
snapshot_tag="${latest_major_minor} latest snapshot"

# --- Display menu
index=1
echo "$index) openHAB v${latest_stable} (recommended)"; ((index++))
[[ -n "$milestones" ]] && echo "$index) openHAB v${milestones} milestone"; ((index++))
[[ -n "$snapshot_tag" ]] && echo "$index) openHAB v$snapshot_tag"; ((index++))

# --- User choice
printf "\nPlease select the version to be installed:\n#? "
read choice

# --- Determine selection
sel=$( { 
    echo "openHAB v${latest_stable} (recommended)"
    [[ -n "$milestones" ]] && echo "openHAB v${milestones} milestone"
    [[ -n "$snapshot_tag" ]] && echo "openHAB v$snapshot_tag"
} | sed -n "${choice}p" )

# --- Repo channel
if [[ "$sel" == *"(recommended)"* ]]; then repo="stable"
elif [[ "$sel" == *"milestone"* ]]; then repo="testing"
elif [[ "$sel" == *"snapshot"* ]]; then repo="unstable"
else repo="stable"; fi

# --- Version tag
version_tag=$(echo "$sel" | grep -Eo '[0-9]+\.[0-9]+(\.[0-9]+)?')

# --- Dry-run summary
printf "\nSimulation summary:\n---------------------------\nSelected       : %s\nVersion Tag    : %s\nRepo Channel   : %s\nAPT Source     : https://openhab.jfrog.io/artifactory/openhab-linuxpkg %s main\nWould install  : openhab package via apt\n---------------------------\nDry-run complete, no changes made.\n" \
"$sel" "${version_tag:-unknown}" "$repo" "$repo"

It should show the latest release, milestone and snapshot to select from, like:

Fetching OpenHAB version data...

1) openHAB v5.0.1 (recommended)
2) openHAB v5.1.0.M1 milestone
3) openHAB v5.0 latest snapshot

[BG56 (Bernhard Geis)]

Beside the right Openhab version the appropriate Java version is important (in Java 5.0 is was Java 17 instead Java 21).

For an openhab upgrade I would do an apt update on the Proxmox LXC if the Java version didn’t change.

I would create a new Proxmox LXC for a new openhab version when the new openhab version would require a new Java version.

[apella12 (Bob Eckhoff)]

@BG56

Beside the right Openhab version the appropriate Java version is important (in Java 5.0 is was Java 17 instead Java 21).

Not familar with Proxmox, so may be wrong, but the OH docker images I use include the appropriate Java version. I don’t have java installed separately on my OH Rpis.

As an aside I’m also a bit baffled (again from lack of knowledge) on the added value of the LXC and Proxmox overhead, especially when it causes problems like in this thread.

I started using Docker about two years ago without any helper programs on bare metal. I have 4 containers (OH, ZUI, MQTT and MYSQL) on my Rpi5. I’m not a super techie, but the command line controls are not difficult. My OH docker compose is set to milestone and I run docker compose pull && docker compose up -dwhen I’m ready to upgrade. The only other commands I frequently use are docker exec -it openhab-openhab-1 /openhab/runtime/bin/client and docker restart openhab-openhab-1. I guess I don’t know what I have been missing

[BG56 (Bernhard Geis)]

Thank you very much for providing OpenHAB 5.0.2 as Proxmox LXC. Openhab runs on Debian 13 (Trixie) - Great!

@Larsen did you already discuss the issue with the proxmox-support team … or is it just the last provided version?

[rlkoshak (Rich Koshak)]

@BG56

@Larsen did you already discuss the issue with the proxmox-support team … or is it just the last provided version?

5.0.2 was just released this morning. It’s the version tagged with “latest” on GitHub right now.

[Larsen (Locke)]

@BG56

@Larsen did you already discuss the issue with the proxmox-support team … or is it just the last provided version?

5.0.2 is just the latest release within the openhab repo. That’s why it’s installed.

Here’s my current take — I’m definitely not an expert in this (or anything else), so feel free to correct me or share your thoughts.

As mentioned, the Proxmox helper scripts don’t have an official support team behind them. They were originally created by tteck and are now maintained by a community.

I’m starting to think that supporting OpenHAB as an LXC install might not be the best idea. I looked into some of the other scripts that would be relevant for OpenHAB, and honestly, a few of them seem a bit outdated or pretty basic. For example, Zigbee2MQTT gets installed the same way as OpenHAB — always the “latest” version — without considering the guided setup. There’s no MQTT server included, so most people would probably end up creating another LXC just for Mosquitto, which doesn’t make much sense.

At first glance it all looks super easy, but the risk is ending up with a messy or partially outdated or non-efficient setup.

On the other hand, the Docker images for OpenHAB, Zigbee2MQTT, EVCC… are all provided directly by the developers, so they’re always up to date. That’s why, if you’re running Proxmox, I think going with a Docker LXC for OpenHAB is the better option for the semi-skilled user (like me).

Nevertheless it would make sense to correct the helper script so that it allways installs the latest major version.

[BG56 (Bernhard Geis)]

The intention of my request is more to tell friends where to find the OpenHAB LXC on Proxmox. It wouldn’t be a good option if it is not clear which version they’ll get.

I started with OpenHAB in 2018 on a Pi3 with Openhabian, which was a good starting point. With more applications like MQTT, Zigbee2mqtt, InfluxDB2, Grafana, smartmeter, … and upgrades to Pi4 and Pi5, the wish started to have more independence on the application side and to have additional Openhab test systems. The problem with additional applications on Openhabian is, that you have to manage the backup of the applications (not for MQTT) and that you may run into problems during the upgrade of the additional applications … which may end that you have to restore or reinstall openhabian and the other applications (I run into such a situation with the upgrde of zigbee2MQTT). That’s why I switched to OpenHAB LXC and a container (LXC) or VM for every additional application. I first tried Docker, but I felt that Docker is too complicated for me, because I had problems with the access to ports and IPs between the different Docker applications. I decided for Proxmox which is much easier to manage. I bought a refurbished Dell 7050 Thin Client with 8GB RAM and 128GB SSD (now I have Dell Optiplex Thin Client with 16GB RAM and 256GB SSD) and installed Proxmox, Openhab and the other applications - each one on a seperate LXC. The procedure to install Openhab on Proxmox is the same as described on the Openhab download side for a Linux system. The Proxmox-Helper-Script for Openhab reduces the steps to take. For a Openhab update you only need to update the Openhab LXC - not the other applications.

With Proxmox I have a clear Backup and Update procedure for Openhab, Openhab Test Systems and for the other applications (new application versions, new Debian versions). That’s why I like Proxmox! A Dell thin client (with RAM, SSD and case is less expensive than a Pi5 with SSD and case).

To use a Docker LXC for OpenHAB sounds to me like to use a container (LXC) within a container LXC, but it would be a good compromise as far as it runs with the other LXCs (MQTT, zigbee2MQTT, InfluxDB2, Grafana, smartmeter, …) on the system. Would a Docker LXC for OpenHAB also be required for every Openhab test system?

Thank you for your support!!!

[rlkoshak (Rich Koshak)]

@BG56

To use a Docker LXC for OpenHAB sounds to me like to use a container (LXC) within a container LXC, but it would be a good compromise as far as it runs with the other LXCs (MQTT, zigbee2MQTT, InfluxDB2, Grafana, smartmeter, …) on the system.

Yes, and that’s not an unreasonable approach since an LCX looks and behaves more like a VM than most other container approaches. LXC is a way to split up a server without the overhead of running a separate kernel for every “machine”.

Other container technologies, like Docker, focus on isolation as their main purpose. While an LXC will have login shells, SSH servers, and pretty much a nearly full OS. Docker containers usually have just enough to run one service, nothing more. And one is given the tools to choose exactly how that service is exposed to the host and the rest of your network.

So running Docker containers on a LXC poses no problem. They are two container technologies for sure, but they are complementary, not redundant.

I run a ton of Docker containers in Proxmox LXCs and am happy with the results. I’m slowly moving all my remaining Docker containers off of VMs to LXCs, but I still almost exclusively run using Docker containers.

@BG56

Would a Docker LXC for OpenHAB also be required for every Openhab test system?

I would guess so. I guess it depends on the nature of your test system. I would assume you’d want it to look and work the same as the production system.

But what you should do is set up an LXC just with Docker and any other customizations you might add to the container. Then convert that to a template. Now to spin up a new LCX that runs Docker just create an LXC based on the template. Then you can run the docker-compose command to pull and create the Docker container and you are good to go.

[BG56 (Bernhard Geis)]

Thank you very much @rlkoshak for your guidance.

I did the following steps:

• installed a new “trixie” image LXC “dockerdebian13” on my Proxmox server

• within this Proxmox container I followed the steps described at https://www.openhab.org/docs/installation/docker.html

• Now I can access the new Openhab Desktop in the WEB-Browser http://dockerdebian13:8080/overview and “docker ps” says:

  

Openhab in Docker seems to work fine on Proxmox server.

After reading some more Docker information I need to convert the created image to a template, try to create a new LCX based on the template and run it with the docker-compose command.

Thanks again!

[BG56 (Bernhard Geis)]

Sorry, I have a question because I’m not a Linux expert and not a docker expert.

I created the “openhab” user according the “openhab docker” documentation https://www.openhab.org/docs/installation/docker.html

to run the openhab docker image I need the uid and gid of openhab

the ids have been provided with “id openhab” uid=999 and gid=988

… but the openhab docker documents say

By default the openHAB user in the container is running with:

• uid=9001(openhab) gid=9001(openhab) groups=9001(openhab)the by default uid=9001

I first tried uid=999 and gid=988 in the docker run command … and I thougt everything is right as I didn’t get an error message and openhab could be started on the WEB. When I tried to get e better understanding of docker I used the command “docker logs openhab” and found the following warnings:

I stoped and removed openhab and started openhab container with run and uid=9001 and gid=9001 but again got a similar error message in the docker logs. A third try with again with uid=999 and gid=988.

I am not sure what the implication of the warnings will be … possibly some data will not be stored. Does the openhab user and group within the docker image have the same ID than on the linux system (or is it similar to the port mapping)? May I need to define the uid=9001 and gid=9001 while I create the user on the Linux system?

Sorry, this might be the problem of my “half knowledge” of docker. Could possibly avoided by a improved documentation.

Any idea what to do? Ignore the warning or fix my system and understanding? Sorry!

[rlkoshak (Rich Koshak)]

@BG56

I am not sure what the implication of the warnings will be … possibly some data will not be stored.

Nothing like that. UIDs below 1000 are usually reserved for processes to run under. When a new user is created using adduser it prints a warning reminding you that if this is a user’s account as opposed to a service’s account, it’s outside the range of UID numbers.

@BG56

Does the openhab user and group within the docker image have the same ID than on the linux system (or is it similar to the port mapping)?

It’s more like the port mapping. Each container has their own users and groups. However, when using mounted folders as volumes there is a little bit of overlap because all the files in those folders will be owned by the user as it is defined inside the container. It’s a good practice to create a user on the host with the same UID and GID as the service is running as inside the container so that you’ll see

 ls -l
total 232
drwxr-xr-x  2 openhab openhab  4096 Dec 13  2023 addons/
drwxrwxrwx  2 openhab openhab  4096 Sep 23 08:38 backup/
drwxr-xr-x  6 openhab openhab  4096 Sep 23 08:56 cache/
-rw-r--r--  1 openhab openhab 10995 Jun 18 14:10 Californium3.properties
-rw-rw-rw-  1 openhab openhab  1711 Jun 18 14:10 Californium.properties
drwxrwxrwx  6 openhab openhab  4096 Oct  8 08:56 config/
drwxrwxrwx  4 openhab openhab  4096 Jul 14 15:02 etc/
...

as opposed to

 ls -l
total 232
drwxr-xr-x  2 9001 9000  4096 Dec 13  2023 addons/
drwxrwxrwx  2 9001 9000  4096 Sep 23 08:38 backup/
drwxr-xr-x  6 9001 9000  4096 Sep 23 08:56 cache/
-rw-r--r--  1 9001 9000 10995 Jun 18 14:10 Californium3.properties
-rw-rw-rw-  1 9001 9000  1711 Jun 18 14:10 Californium.properties
drwxrwxrwx  6 9001 9000  4096 Oct  8 08:56 config/
drwxrwxrwx  4 9001 9000  4096 Jul 14 15:02 etc/
...

It becomes even more confusing if your host already has a user with the same UID as is being used inside the container. Then you might see something biuzzar like:

 ls -l
total 232
drwxr-xr-x  2 postgresql www-data  4096 Dec 13  2023 addons/
drwxrwxrwx  2 postgresql www-data  4096 Sep 23 08:38 backup/
drwxr-xr-x  6 postgresql www-data  4096 Sep 23 08:56 cache/
-rw-r--r--  1 postgresql www-data 10995 Jun 18 14:10 Californium3.properties
-rw-rw-rw-  1 postgresql www-data  1711 Jun 18 14:10 Californium.properties
drwxrwxrwx  6 postgresql www-data  4096 Oct  8 08:56 config/
drwxrwxrwx  4 postgresql www-data  4096 Jul 14 15:02 etc/
...

@BG56

May I need to define the uid=9001 and gid=9001 while I create the user on the Linux system?

It’s not required but it’s what I would recommend. Or continue to use the 999 and 998 UIDs. As long as they are not already in use, it doesn’t really matter.

@BG56

Sorry, this might be the problem of my “half knowledge” of docker. Could possibly avoided by a improved documentation.

This is more of a base Linux knowledge issue than a Docker knowledge issue.

@BG56

Any idea what to do?

I recommend:

1. create an “openhab” user on the host with UID 999 and GID 998 (which I think you’ve already done.
2. start the container passing the UID 999 and GID 998
3. make sure the userdata folder and conf folder passed into the container are owned by openhab:openhab

The container will fix all the rest of the permissions and ownership as required automatically.