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).
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.
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.
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
I think this is an excellent idea and we should move away from people having to SSH in to do updates, restart the system, read log files and to change addon logger levels (info to debug). If they donāt work on all platforms, I see that as ok as anyone that is using an obscure Linux can probably help to add support or do not need such shortcuts.
In relation to doing updates it would be great to have a breaking change warning system that before a user updates they get a list of bindings with known breaking changes. Extra points if the list provides links on where to read more.
The idea is if I only have half a day to spare I wonāt press update on a system that lists five breaking changes, Iāll put it off till I have a full weekend and have read what needs to be done.
This file has some breaking changes in it already listed as āapt upgradeā users get a warning but it is already mid upgrade process that the warnings appear. If only the bindings that are installed get the ALERT shown this would be very useful.
I think you could read/set a system property for determining if it is a docker installation. Another possibility is to look at /etc/os-release to see if itās a supported os for doing an upgrade.
It is quite easy to determine what kind of installation it is. That is not the problem. The actual problem is creating the scripts to do the upgrade on each different type of system. So far I have developed scripts for Linux, and Windows upgrades; and these both work fine. But I will need help from others to develop scripts for other OSās and installations (e.g. Mac OS, Docker, etc.)
Docker container updates are typically managed by one of many tools like Docker Compose, Portainer, Synology DSM, Kubernetes etc. It is the responsibility of those tools to update containers. Itās a bad practice to update anything regarding OS or the application in the container itself. That goes against the mantra of building/testing the container and then shipping and running the exact same container everywhere.
Yes, I know about that. And I used it for my Windows and Linux development and testing. But my main problem is that I donāt own any computers running (say) MacOS or Docker. So I need to rely on others who have such systems.
So I need to rely on others who have such systems.