Addon to Update OH: Thoughts anyone?

Browsing through this forum, I sometimes see posts where users are daunted by the OH updating process; and asking if there is a UI interface to do it. So I am thinking of developing an addon that would do this. I wonder if anyone has thoughts about it?

Such an addon would shell out of the OH service, and start a script to shut down the OH service, download and install the new modules, and then restart OH. The core of the script could be the one that already exists in OpenHabian on *ix machines, but obviously Windows machines would need a different script.

I think the process would not be so different than most modern applications that can run a bootstrap self update process. But there may be issues concerning rights and authentication etc. (That’s one reason why I am thinking of making this an addon rather than part of the core; so users can decide whether or not they want this feature installed on their systems).

Any thoughts?

In addition to *ix and Windows machines, users use Apple computers & NAS In reality I believe the easiest is something based off a volume based Docker installation with all data in a single folder tree.

Update the build script ( or just use :latest) stop the container, delete the container, run the build script. Here is a script I currently use in testing OH placed in /opt/openhab/docker folder.

docker run \
--name openhab \
-p 8081:8080 \
-p 8444:8443 \
-v /etc/localtime:/etc/local
time:ro \
-v /opt/openhab/addons:/openhab/addons \
-v /opt/openhab/conf:/openhab/conf \
-v /opt/openhab/userdata:/openhab/userdata \
--env-file /opt/openhab/docker/.env \
 --privileged \
-d \
--restart=always\
 openhab/openhab:3.0.2

and the .env file

# OpenHAB service environment
USER_ID=999
GROUP_ID=994
OPENHAB_HTTP_PORT=8080
OPENHAB_HTTPS_PORT=8443
EXTRA_JAVA_OPTS=-Duser.timezone=America/New_York

I am using Docker, too.
And I think an Update-Feature via GUI would be helpful for many non-technical users.

I do do not think it would be easy to create a update script that can update a docker container while the script is started from within the container.
But then again, Docker is for advanced users or the user use a docker-GUI (like portainer) and can update via that GUI.

Someone started a web-based project (Cockpit-project module) for openHABian. I don’ t know if it will be available anytime soon, but that would be able to do this. And anything else which you can do through the openhabian-config CLI, but from a website, and you could also monitor your host server with this one.

I’m thinking it might be more complicated than that but I see no reason why it would necessarily be impossible. The challenge is usually dealing with the fact that once the openHAB process ends, all its children processes also end. The other issue will be the privilege escalation that will be required to do the upgrade.

In general I think there are a few different cases that need to be handled:

  • Linux package installation of which openHABian is a special case
  • Manual installation (which covers Linux, Windows, Mac, and Docker)
  • Docker which internally is a manual installation inside it but over all they way it’s used is different, but I see no reason why it should be impossible to treat it just like any other manual installation. Instead of updating the Image though the binding would just be able to update the container which could lead to surprising results if the user destroys the container without updating the Image first.

I don’t think we can treat Docker installations as something for advanced users. There are far too many people with low(ish) technical skills running OH in Docker on NAS systems like QNAP, Synology, and OMV. And I worry that having an update add-on might lead those users down the wrong path, but perhaps we can do our best to avoid that through the docs. “Don’t use this if running in Docker”.

Docker also has another issue as a bunch of the tools you might need to perform the upgrade might not be available in the container. For example, I think stuff like wget, curl, unzip, etc. might not be available inside the container.

I think you underestimate the complexity and overestimate usefulness of this endeavour.
We didn’t manage to expand openHABian to run on more Unices simply because it is a helluva lot of work - in particular the testing part. You will have to spend countless hours on that to make it a reliable thing. There’s just so many eventualities you need to cater for.
But who for ? Raspi and Debian users won’t need it, they have openHABian available.
On Docker you don’t upgrade but redeploy, that’s per concept.
The next best popular platform is way behind, frankly I don’t even know which one it is, Ubuntu probably, with Windows to follow. But there’s not that many people to run this in absolute figures so not that many that would benefit from such a feature.

I wouldn’t want to discourage you from embarking on this but if you would be willing to enhance/expand openHABian instead to also work on say Ubuntu that would be highly welcome and probably a better investment of your time and motivation.
Yeah or take the ball of the Cockpit web interface extension, it started promising but there hasn’t been any progress in the last two months, I’d be sorry if it died away.

Andrew
I think this might not be the most simple thing to develop but… I’m sure it would make a LOT of people very happy.
Making something that worked on every single platform folks run openHAB on could be a huge task but even if it only was for a few platforms (or only one or two), I still think it would be a HUGE contribution to openHAB.
One thing that I wonder about is back a while (like maybe two years) I remember some discussion that there needed to be a typical installation for Windows. Someone worked on it a bunch and had gotten pretty close but I think it faltered over how and what kind of java to install (license issues)
But anyhow… my thoughts are good on you for even considering such a project.
Let’s keep our minds open and kick this around a little

Hi guys. Many thanks for the feedback. I think there were more votes in favour than against. So I started to write some code (see links below).

@mstormi I take your points, but I was not intending to write new scripts for the updating; rather my intention is to automate the execution of already existing scripts from within the OH UI itself. i.e. running a script that executes the already existing scripts e.g. stop / backup / update / restart etc.

1 Like

Small suggestion - if you do rely on maven repositories, and seems you partially do, there is already a library called “Maven Resolver” or Sonatype/Eclipse Aether which allows to scan remote locations and fetch version information using standard Maven metadata files.
This library is embedded by default in openHAB if used together with Apache Karaf and mvn URIs. You can have a look on how it is used here: org.ops4j.pax.url/AetherBasedResolver.java at url-2.6.7 · ops4j/org.ops4j.pax.url · GitHub

Cheers,
Łukasz

@splatch many thanks for the tip. I was too early because I had already coded that part myself using Jetty and XmlReader so too bad.