I don’t know if this is possible but would having a DNS entry to always point to where ever the files are be a good idea?
That way if something like the bintray situation happens again then all is needed is a DNS change and the links would all work and no users would notice and everything would function.
Just an idea.
There are probably reasons this hasn’t been done before. Who knows?
We didn’t own Bintray and we don’t own JFrog. JFrog is a company that provides build and build artifact hosting and it’s what we use. I don’t think you can buy a DNS name that points to another DNS name as opposed to an IP address. JFrog’s IP address is unlikely to remain unchanged. And even if it isn’t, there is a whole system of certificates and certificate authorities that are based on domain name. If someone tries to securely connect to an openhab.org domain and gets served a certificate for a jfrog.com domain, the HTTPS client will raise all sorts or errors and refuse to connect.
Again, also for @drmacro
If you didn’t configure remote= in addons.cfg, UI settings will apply !
Check ‘Add-on-Management’ on main settings page.
But, the OH is dead…no UI’s. That’s why I’m working from an ssh login, it’s where I did the update from the config tool that broke it in the first place.
Moot issue at this point I’m focusing on getting a Pi4 running with OH 3…which has been fighting me every step of the way. 
Thanks Marcus. I created the addons.cfg by copying it from the demo folder and set remote=true. I cleared tmp and cache and after restart the UI is not accessible:
2021-06-25 09:03:42.657 [INFO ] [.dashboard.internal.DashboardService] - Stopped Dashboard
==> /var/log/openhab2/events.log <==
2021-06-25 09:03:42.796 [thome.event.ExtensionEvent] - Extension ‘ui-dashboard’ has been uninstalled.
==> /var/log/openhab2/openhab.log <==
2021-06-25 09:04:24.112 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing ‘openhab-misc-market, openhab-voice-marytts, openhab-misc-openhabcloud, openhab-ui-habot, openhab-binding-serial1, openhab-binding-weather1, openhab-binding-alarmdecoder1, openhab-ui-habpanel, openhab-binding-zwave, openhab-binding-mqtt1, openhab-binding-shelly, openhab-binding-chromecast, openhab-binding-mqtt, openhab-transformation-map, openhab-ui-basic, openhab-action-mail, openhab-binding-openweathermap, openhab-binding-astro, openhab-ui-paper’: Error:
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.zwave/[2.5.0,2.6)
You need to set remote=false OR not set it and use the UI. In either case, you need to have the openhab-addons package installed.
What I mean is if:
echo ‘deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main’ | sudo tee /etc/apt/sources.list.d/openhab.list
was set instead originally to something like:
echo ‘deb https://repository.openhab.org stable main’ | sudo tee /etc/apt/sources.list.d/openhab.list
And repository.openhab.org was set as a sub domain which the DNS points to the hosting server.
That means that if the hosting changes you only have to change the DNS of repository.openhab.org to point to the new hosting server.
Also the documentation wouldn’t have to change if the hosting changes because the repository.openhab.org refernces never change only the DNS.
Hope that made sense but maybe it isn’t possible.
it is more than just the DNS name that is required:
- the directory structure / base directory name of a repo is most likely not identical
- the signature key changes
- and as already mentioned in case of secure access to the repo the certifcate will not be the same
Instead of a DNS ‘alias’ it is possible to use e.g. openhabian-config. The maintainer provided a solution to do a seamless update of the apt configuration while doing an openhabian-config update.
And that’s the part that I’m pretty sure wouldn’t work. When apt tries looks up repository.openhab.org it will get the IP address for jfrog.io. When the TLS handshake takes place it will see that the domain pulled does not match the domain in the certificates and refuse the connection as insecure. The certificates are based on the domain name, not IP address.
I did this a while back.
I had a website on google sites and wanted to move it to another hosting server.
I set up an A record on of a sub domain which pointed to my new hosting so it is not an alias.
I swapped the dns to the new server IP.
Then I set up the certificates using lets encrypt on the new hosting server.
On the new hosting server there is an option to make a permanent redirect of the new DNS to specific directories.
EG if you use https://repository.openhab.org you can redirect it to https://repository.openhab.org/artifactory/openhab-linuxpkg
Anyway it was just a suggestion. I am not an expert at this.
Yes it should get the IP of jfrog.io but the dns would be http://repository.openhab.org/ so the certificate should be ok.
Like I said I am no expert and this may not be possible.
Are there any DNS experts out there?
Installing the openhab-addons package was the solution. I don’t understand why it was ever uninstalled, since my installation has been running since an earlier version. Thank you for your help!
The certificate is created by Let’s encrypt.
Their bot does a DNS lookup end up at jfrog.io … so the normal bot procedure will not install the certificate.
No because the certificate is issued to jfrog. The browser will see that you went to opebnhab.org and not jfrog.io and see that the certificate doesn’t match. Certificates are used to verify the identity of websites and they are based on domain name. If you could create your own DNS record and use some other web site’s certificates then certificates would be worthless. Their whole reason for being is to provide proof that when you access jfrog.io that you are talking to the one and only jfrog.io. But you went to openhab.org and got a certificate issued to jfrog.io. openhab.org isn’t jfrog.io so any reasonable TLS client is going to refuse to connect with a scary warning about someone trying to run a man-in-the-middle attack or something like that.
The only way to make this work is to in fact run a man-in-the-middle. In that case the clients would connect to openhab.org and we’d have our own certificate so that connection is fine. Then our server would connect to jfrog.io. That can be made to work but it’s significantly more involved than buying a DNS record and pointing it at jfrog.io. It’s also a little shady in practice and raises some red flags because it eliminates the end-to-end encryption. Instead of being encrypted from your host to jfrog.io where the artifacts reside the encryption is broken at openhab.org and then a new encrypted channel is opened to jfrog.io.
But if we set up our own server to do that, why not just host the artifacts on our servers in the first place?
It worked because you didn’t change the domains, you created a subdomain. And then you reacquired the certificates afterwords which probably wasn’t completely necessary if your domain name in fact did not change. The certificate is tied to the domain name, not the IP address so you can move the certificate between machines and as long as you use the same domain name all is fine.
What will not work is setting up a DNS record that points to a different domain because the certificate is tied to the domain. You can’t go to openhab.org and have the connection use a jfrog.io certificate, which would necessarily be the case.
DNS redirects won’t work here either because DNS redirects are limited to the same FQDN. You cannot, only through as DNS redirect, have users redirected from openhab.org to jfrog.io. That’s not allowed.
The only way to make something like this work is if we set up our own server. Then it becomes a question of whether it’s more trouble to do HTTP redirects and/or a TLS man-in-the-middle or just host the artifacts ourselves. I suspect that the fact that we are not hosting the artifacts ourselves points to the fact that it’s more trouble than it’s worth.
This particular problem has only occurred once in all the time I’ve been using OH, so it’s not a problem that occurs with any frequency.
NOTE: While I would not call myself an expert on DNS, I do know a whole lot about it as I need to understand this stuff for my job.
By default, never installed to begin with. That’s why it went off to fetch each add-on from a remote site. Meant to save unwanted bloat on your installed system.
All, ive updated the file to point to the new online respository (added JCentre), but its still trying to download bindings from here:
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.zwave/[2.5.0,2.6)
This post, says we update this: org.ops4j.pax.url.mvn.repositories but of course its not working.
How do we get around this? Right now I cant install anything .
Add on management is ON in the UI, as is remote=true in addons.cfg
Give them a clue about the version of openHAB that you are running now.
This only effects 2.x, so 2.5 dont believe it makes a difference.
hilariously, i install paperui manually (using the console and it downloading from the file edited in the start of this post) and then it uninstalls itself. I’m trying to manage bindings etc via Paperui, stuffing around with addons.cfg is the stuff of dark ages.
Cant install ANY bindings though…
18:35:58.219 [ERROR] [.core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-persistence-mapdb, openhab-binding-exec, openhab-misc-openhabcloud, openhab-binding-network, openhab-persistence-influxdb, openhab-binding-amazonechocontrol, openhab-ui-habpanel, openhab-binding-daikin, openhab-binding-mqtt1, openhab-binding-mqtt, openhab-transformation-map, openhab-ui-classic, openhab-binding-ipcamera, openhab-binding-kodi, openhab-ui-habmin, openhab-transformation-exec, openhab-binding-systeminfo, openhab-ui-paper, openhab-binding-http1, openhab-binding-networkupstools, openhab-misc-market, openhab-transformation-javascript, openhab-transformation-regex, openhab-binding-yamahareceiver, openhab-transformation-jsonpath, openhab-binding-zwave, openhab-binding-doorbird, openhab-ui-basic, openhab-binding-astro, openhab-binding-snmp': Error:
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.zwave/[2.5.0,2.6)
18:35:58.591 [INFO ] [i.dashboard.internal.DashboardService] - Stopped Dashboard
18:35:58.609 [INFO ] [smarthome.event.ExtensionEvent ] - Extension 'ui-dashboard' has been uninstalled.
Are you using addons.cfg? If so any changes you make through the console will be undone the next time it reads in /etc/openhab2/system/addons.cfg. So you must first clear out addons.cfg. If you are still seeing weird behavior like this the cached version might not have updated correctly. Go to /var/lib/openhab2/config/org/openhab and remove addons.config.
I can’t remember if OH needs to be stopped for this to work properly.
Once all the addons.cfg stuff is cleared out any changes you make through the console or the UI will stick.
1 Like
Having the same issue (running OH 2.5.12), updated the repositories source.
Add-on management set to false or true through PaperUI does not help.
Still getting the “error” in downloading binding.
It looks like only option remaining is to get the kar files manually.
Where can I find for example the “miio” kar file matching OH2.5 binding and where do I place it?
I now also get errors in the log also after reboots:
2021-08-06 13:00:46.454 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-miio': Error:
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.zwave/[2.5.0,2.6)
How do I stop it?