Project Selfhosting - How we can use community and developer resources more effectively

Hi :slight_smile: I created this Topic, because I think I had an Idea how we can use the time and the available resources available for OpenHab more effectively :slight_smile:

Today there was an issue with the OpenHab cloud…I saw a lot of posts and a lot of people try to solve it for a whole day and longer…as some installations depend on the cloud, this creates some time-urgency and stress under the developers and maintainers which leads to less “fun” in the development-process in opensource-software…

To avoid that, I want to come up with a (rather huge) plan to avoid having this Problem again and reducing maintainance for the community to keep the focus on the core functions, stability and enchanced functions of OpenHab :slight_smile: Therefore I would suggest the following schedule

1) Prepare everything for Selfhosting
Instead of hosting a “fully fledged” OpenHab-Cloud, it would be much easier to host “just” a ddns server, with an IP-adress determining service that tells the OpenHab-binding when to update the IP address…This may lead to much less downtime and maintainance -> maybe also lower costs regarding hosting I don’t know details about the Cloud here… This makes together with the OpenHab-Auth wich was implemented in 3.0.0 it much easier for everyone to selfhost. Maybe there is already enough opensource here, which we can use for this purpose, or adjust OpenHab-Cloud. GitHub - nsupdate-info/ Dynamic DNS service
I think we should ensure that you can only use it with an Openhab installation…

1.2)Identify Alexa-Skills and other Bindings/Skills that actually rely on the OpenHab cloud
Every skill should have the possibility to not use the Cloud easily. Therefore we should determine which skill needs the Cloud, and how we can adjust it…I opened an Issue for Alexa here: Integrate URL into settings · Issue #386 · openhab/openhab-alexa · GitHub
Maybe we have to determine if this is even possible… For the Alexa-Skill this seems not be which would be a problem…maybe someone in the community finds a solution? Otherwise this projectpoint maybe doomed…

2) Enchance security on OpenHab to make it more attractive for Selfhosting
For making OpenHab more attractive for Selfhosting, we should further enchance the security of it…like with 2fa Auth :slight_smile:

With ddns, and all skills able to point to your URL easyly, I think Selfhosting is much more attractive especially in today’s time of data-protection. Also all the maintainers and developers don’t have to do so much maintainance-work on the Server I hope.

I don’t know if I have forgotten something…but I would be really interested what the developers and the community thinks about this idea :slight_smile:. Be free to post your thoughts and ideas for saving time and stress for all the developers and maintainers who brought this wonderful program to the community.:heart:

Nevertheless this would be a huge project and I guess very time-consuming, but I hope that it can save time for all the awesome people working on OpenHab for the future :slight_smile:.

The server software has always been available for self-hosting.

The non-profit foundation running the clod server cannot charge for services and does not have the resources to improve infrastructure.

i think they would welcome somebody to host a paid instance but nobody has done that yet.

How much capacity/what exactly would they need do you know that?

Yes :slight_smile: but I meant Selfhosting the OpenHab instance directly (without Cloud companion) as for now, one would have to rewrite his own Alexa skill (or Google home skill) and host the companion, “just” to become independent from the Cloud…

The OH security model is currently no where near that level.

I know :slight_smile: that’s why I wrote point 2 :slight_smile:

I think there is a big misunderstanding. It is just a small part of our developers being involved in maintaining the cloud part. So what you suggest would not be really helpfull. Also, issues occured today were caused by our hosting provider, so nothing really causing big trouble for maintainers.

I really don‘t see any benefit in your proposal, apart from introducing security issues…

1 Like

Okay thanks for the Information :slight_smile:

Okay than it would make no sense…I mark that as solution for now if it’s not beneficial…

This was just my opinion, not necessarily common sense…

1 Like

@hmerk and @Bruce_Osborne what are the security-features you would implement to make it “fit for Selfhosting”? Is this doc still applicable? Securing Communication and Access | openHAB

Okay thanks for that :slight_smile: unmarked to keep up discussion :slight_smile:

I for myself would never expose my openHAB installation to the internet in any way. I really like our current approach where communication is initiated from openHAB to myopenHAB, which is acting like a proxy in this case.
If I need to connect to my openHAB server from out of my home, I use a VPN tunnel…


Yes, it is still valid.

1 Like

It would need a strong authentication ( who you are) and authorization ( what you can do) system with no unauthenticated access permitted, You do not want your system revealing details about your home that could be used against you for harm.

Web access needs to be secure ( HTTPS) Only. The system software also regularly needs to be audited for security vulnerabilities. Some also include penetration testng.

1 Like

Nice! I also would suggest some security-headers and additional TLS-options… personally I use for testing… nextcloud (which is meant for Selfhosting) has a nice approach here…I think Https is not really integrable in OpenHab directly right?

Even for OpenHab 3 as it has authentication build in? Or is this a system that is not meant for exposure, just for “in-home security”

I think by default it uses a self-signed certificate on port 8443. I have my OH2 instance running behind an ssl protected reverse proxy. Home NAT solutions will not work for the could access features provided by the server though. Paying for Business class Internet access to get a static ip address is insanely expensive for most people.

1 Like

As it is implemented actually, i would see it just for in-home security.

I use openHAB since about 9 years now and never had big issues using myopenHAB for remote access. Therefore I see no need for big changes.

1 Like

Me too I’m using traefik Traefik and run everything in docker as it reduces host-sytsem caused errors…

Yes I know…this also differs from country to country… therefore I’m using dyndns-providers…

Yes it’s a cool service :slight_smile: I thought it has to eat up a lot of your time supporting it… that’s why I came up with the idea of easier self-hosting :slight_smile:

Residential users are still hidden behind NAT,(Network Address Translation) or likely PAT ( Port Address Translation) with many people sharing the same public ip address.

Yes, I am a Network Engineer.

1 Like