NEWS: Neu im Admin, zentrale Verwaltung für Passwörter und Schlüssel

[OliverIO]

@Thomas-Braun

Gut, die Frage kann man sich bei jedem Adapter stellen.
Wenn man so argumentiert, darf man dann nie einen Adapter erstellen.
Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.
Wenn dann mehrere Nutzer darauf vertrauen und eventuell in zwei Jahren, das nicht mehr gewartet ist, dann wird es schwierig.

[Bluefox]

Eigentlich sollte im Admin noch apt upgrade/update -y startbar sein. Dafür werden auch viele Danke sagen

[mcm1957]

@OliverIO said:

@Thomas-Braun

Gut, die Frage kann man sich bei jedem Adapter stellen.
Wenn man so argumentiert, darf man dann nie einen Adapter erstellen.
Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.
Wenn dann mehrere Nutzer darauf vertrauen und eventuell in zwei Jahren, das nicht mehr gewartet ist, dann wird es schwierig.

ioBroker OS ist micht mit jedem Adapter vergleichbar. Wäre max mit admin javascript etc vergleichbar. Und js /ts Adapter können prinzipiell viele warten. Dass die Wartung bei vis* schon mässig ist zeigt die Erfahrung.

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

[OliverIO]

@mcm1957

Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.

was ich ja auch so geschrieben habe

[Homoran]

@OliverIO war ja auch dein Zitat 😉

[FernetMenta]

@mcm1957 sagte:

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

Ich würde unterstützen. Ich würde auch bei der Pflege des aktuellen Docker Images helfen bzw. es auch ganz übernehmen, sollte Andre keine Lust mehr haben.

[Asgothian]

@mcm1957 sagte:

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

Nicht Docker, nicht Go sondern C, C#, JS oder python, dann könnte ich mir das sogar vorstellen.

Bei Docker und Go ist dann bei mir aber schluss.

A.

[Leonie]

Hi,

Danke für eure Diskussion! :-)

Auch ich bin bei ioBroker, weil ich die Flexibilität schätze und das starre System von Home Assistant nicht zwingend bevorzuge. Zur Wahrheit gehört aber auch: Es gibt viele Nutzer, die genau diese Einfachheit suchen.

Ich möchte keineswegs „den einen neuen Weg“ für ioBroker aufzwingen. Meine Vision des ioBroker OS ist ein optionales Zusatzangebot. Primär soll und muss ioBroker genau das bleiben, was es ist: eine Node.js-Applikation, die auf jedem beliebigen System installiert werden kann. Das OS wäre eine schlüsselfertige Alternative für diejenigen, die schlicht keine Muße haben, sich mit Linux-Unterbau, Node-Updates oder Permissions auseinanderzusetzen.

Zur Wahl von Go für den OS-Agenten:
Eigentlich wollte ich die Sprache für den Agenten gar nicht festlegen, mir ist Go in der Diskussion nur als Beispiel herausgerutscht. Warum aber Go? Es ist extrem portabel, kompiliert in ein einziges statisches Binary (zero dependencies) und bietet native Leichtigkeit bei Concurrency (Goroutines). So kann eine Goroutine die Socket-Verbindung zum ioBroker-Adapter halten, während eine andere Kerneltasks oder Docker steuert.

Zu den Bedenken bzgl. OS- & Adapter-Wartung:

@Thomas-Braun sagte:

Schau dir nur mal den Tanz z. B. bei Ubuntu bei einem Release-Wechsel an.

Genau hier setzt das Container-Konzept an: Exakt dieser „Tanz“ entfällt für den Endanwender. Was auf dem Host passiert, ist vom Container entkoppelt. Solange der Linux-Kernel steht, läuft die definierte Container-Umgebung stabil durch.

@Asgothian sagte:

Als entwickler eines Hardwarenahen Adapters sehe ich dabei mehrere Fragezeichen.

Ich verstehe deine Argumentation und die Idee, den OS-Agenten entkoppelt auch für freie Debian-Systeme anzubieten, ist extrem gut.

Bei der Frage Docker vs. Nativ bin ich allerdings ehrlich: Ich bin ein absoluter Verfechter von Containern.

Der Grund, warum ich ioBroker trotz fertigem OS-Image zwingend in Docker sehe, ist die garantierte Immunität gegenüber dem Host:

• Unzerstörbare Runtime: Selbst wenn das Host-OS aktualisiert wird, bleibt die Node.js-Version, die Python-Umgebung und der ioBroker-Core im Container zu 100 % unangetastet und in einem definierten, getesteten Zustand.

• Sauberes Resetting / Rollback: Geht bei Adapter-Experimenten oder im Dateisystem etwas schief, zieht man das Container-Image neu hoch – ohne dass OS-Reste oder verwaiste npm-Pakete den Host zumüllen.

• Zusatzdienste: Wenn Docker für Grafana, InfluxDB oder Z2M sowieso auf dem Host läuft, ist der Schritt, auch ioBroker als Container laufen zu lassen, architektonisch nur konsequent.

Ein fertiges Image drumherum braucht es schlichtweg für Einsteiger und reine Anwender: Sie bekommen damit das Beste aus beiden Welten – ein vorbereitetes System mit passendem Handling auf Host-Ebene und eine echte Plug-and-Play-Erfahrung ohne SSH-Zwang.

Zum Thema Langzeit-Pflege & Bus-Faktor:
Dass ich irgendwann nicht mehr die Zeit oder Lust haben könnte, das Projekt alleine zu stemmen, sehe ich keineswegs als Vorwurf, sondern als realistischen Fakt. Kein Einzelner kann eine Applikation ewig alleine pflegen.

Genau deshalb habe ich diese Diskussion gestartet: Ich wollte abklopfen, ob überhaupt ein grundsätzlicher Bedarf in der Community besteht und ob sich Gleichgesinnte finden, die Lust haben, an einem solchen Konzept mitzuentwickeln. Ein Tool kann technisch noch so elegant sein – ohne Nutzer und Co-Maintainer macht es langfristig keinen Sinn.

Liebe Grüße

[Thomas Braun]

@Leonie sagte:

Genau hier setzt das Container-Konzept an: Exakt dieser „Tanz“ entfällt für den Endanwender.

Aber (wie bei allen dieser Tools) auch nur vordergründig. Der Docker/Container/was auch immer läuft genau wo angedockt? Die Basis muss ja auch aktuell gehalten werden.

Das ganz grundlegende 'Problem' und warum ich das eigentlich gar nicht gerne sehe und warum ich auch ganz lange mit dem 'iob nodejs-updater' gezögert habe ist:

Es wird eine Einfachheit vorgegaukelt, die nicht vorhanden ist und nur 'wegabstrahiert' wird.
Dann muss der user sich (vermeintlich) auch nicht mehr mit den absoluten Basics auseinandersetzen, fährt dann aber trotzdem irgendwann vor die Klippen.
Und deswegen sehe ich auch z. B. sowas hier durchaus kritisch:
https://forum.iobroker.net/topic/62489/proxmox-updater-host-lxc-vm-auch-iobroker-pihole-etc

In anderen Projekten wird das übrigens ganz ähnlich gesehen. Hier mal ein Thread zu dem von mir verwendeten Betriebssystem:

https://forum.endeavouros.com/t/introducing-neoarch-v3-a-unified-package-and-system-manager-for-arch-linux/81344

Da kommt auch jemand mit einer tollen 'einfach mal klicken - Fertig'-Lösung an.
Bewertung dazu:

Tools like this have their place but should be reserved for those who are already familiar with Arch and its Packaging system and Yet that will be the last group to use such a tool as this.

Und das ist auch für den ioBroker anwendbar. Solche Tools sind nur für Anwender sinnvoll, die ein Grundverständnis über das System und wie es funktioniert mitbringen oder zumindest erlangen wollen. Und wenn man das notwendige Grundverständnis hat braucht man die Tools nicht mehr. Im Gegenteil, die stehen dir dann eher im Weg.

Vermutlich wäre statt des nächste 'One-Klick-for-all'-Dings Arbeit an der Dokumentation sinnvoller.

[OliverIO]

@Thomas-Braun sagte:

Und das ist auch für den ioBroker anwendbar. Solche Tools sind nur für Anwender sinnvoll, die ein Grundverständnis über das System und wie es funktioniert mitbringen oder zumindest erlangen wollen. Und wenn man das notwendige Grundverständnis hat braucht man die Tools nicht mehr. Im Gegenteil, die stehen dir dann eher im Weg.

also dann auch für iobroker os? :)
sorry, polemisch.

ich sag meist, einfach probieren
wer weiß ob auf dem weg noch Fallstricke lauern
ein disclaimer rein, das das ein experiment ist (etwas softer formuliert, nicht das experiment gleich abschreckt)

evtl noch eine Ergänzung zu meiner Meinung oben:
Of hat sich gezeigt, das jemand über einen einfachen Weg den Einstieg in smart-home und auch iobroker findet. Evtl ist deswegen home-assistant auch so beliebt (neben der Bekanntheit)
So eine Möglichkeit, bei dem docker und installation web abstrahiert wird, könnte das schaffen.

Allerdings zeigt sich bei einigen Anwendern auch, wenn der Einstieg mal geschafft ist, dann wollen manche mehr. Solange das alles in Adaptergrenzen möglich ist, alles gut.
Kommt Hardware dazu und der OS-Agent bekommt die meisten Fälle hin, auch das einfachst zu konfigurieren. Auch gut.

Wenn noch mehr Anforderungen kommen, dann hilft jemanden sowas nicht mehr, dann muss er selbst frickeln und seine spezielle Lösung anpassen.

Man sieht das auch im Forum oft, wie viele ihren Raspi bis zu seinen Grenzen quälen, obwohl es eigentlich Zeit für ein größeres System wäre. Bei dieser Entscheidung tun sich einige schwer.

Wenn dann der Zeitpunkt kommt von der einfachen Lösung mit iobroker OS auf eine eigene Installation zu wechseln, kommt dann erst das lernen (und die Schmerzen).

Das sollte allen Nutzern klar sein, deswegen auch der Disclaimer.

[Thomas Braun]

@OliverIO sagte:

also dann auch für iobroker os? :)

Ja, solche Gaukeleien sind generell wenig sinnvoll.

[mcm1957]

Solange es den Usern klar ist dass das ganze - zumindest am Anfang - KEINE Kernkomponente ist würd ich mich nicht dagegen stellen. Auch wenn ichs pers nicht verwenden würde. Versuchen kann mans ja...

In jedem Fall sollte sowas unbedingt in einer github orga (neu od ev iobroker) entwickelt werden und zumindest 2 Entwickler das ganze voll verstehen / mitentwickeln. M.E kann nur so garantiert werden dass nicht in einem Jahr alles nur mehr zäh bis gar nicht weitergeht.

[Asgothian]

@Leonie sagte:

Hi,

Danke für eure Diskussion! :-)

[...snip]

@Asgothian sagte:

Als entwickler eines Hardwarenahen Adapters sehe ich dabei mehrere Fragezeichen.

Ich verstehe deine Argumentation und die Idee, den OS-Agenten entkoppelt auch für freie Debian-Systeme anzubieten, ist extrem gut.

Bei der Frage Docker vs. Nativ bin ich allerdings ehrlich: Ich bin ein absoluter Verfechter von Containern.

Ich verstehe warum Container für bestimmte Anwendungen gut und Sinnvoll sind. Sie sind aber nicht in allen Fällen die beste Option.

Der Grund, warum ich ioBroker trotz fertigem OS-Image zwingend in Docker sehe, ist die garantierte Immunität gegenüber dem Host:

Genau hier setze ich mit der Kritik an. Auf der einen Seite willst du ein vollständig isoliertes System im Container, welches auf der einen Seite einfach 'neu' aufgesetzt werden kann durch neues hochziehen des Container Images.

Auf der anderen Seite soll dieses vollständig isolierte System die Werkzeuge besitzen den Host zu managen. Damit brichst du die angesprochene Immunität auf - Die Applikation im Container kann den Host in einen instabilen Zustand bringen wenn bei der Host-Verwaltung etwas schief geht. Damit ist also der Gedanke alles was ich im Image mache kann ich durch wieder hochziehen des Image korrigieren (der den meisten Anwendern kommen wird) auf gefährliche Weise falsch.

• Unzerstörbare Runtime: Selbst wenn das Host-OS aktualisiert wird, bleibt die Node.js-Version, die Python-Umgebung und der ioBroker-Core im Container zu 100 % unangetastet und in einem definierten, getesteten Zustand.

Dieses gilt nur solange wie beim aktualiseren des Host-OS nichts schief geht. Wenn dabei der Host instabil wird ist zwar die Applikation prinzipiell weiterhin zu 100% lauffähg - muss das aber gar nicht sein, weil:

• Sauberes Resetting / Rollback: Geht bei Adapter-Experimenten oder im Dateisystem etwas schief, zieht man das Container-Image neu hoch – ohne dass OS-Reste oder verwaiste npm-Pakete den Host zumüllen.

Das ist ein durchaus reelles Argument, ist aber letztendlich auch auf das gesamt-Image anwendbar. Geht etwas richtig schief, dann zieht man ein neues gesamt-image, spielt ein Backup ein, und ist auch wieder da wo man vorher war (wenn man das System auf Stand gehalten hat)

• Zusatzdienste: Wenn Docker für Grafana, InfluxDB oder Z2M sowieso auf dem Host läuft, ist der Schritt, auch ioBroker als Container laufen zu lassen, architektonisch nur konsequent.

Ich sehe das anders. Der ioBroker ist gerade kein standard Dienst der nur über wohl definierte und standardisierte Schnittstellen mit der Aussenwelt kommuniziert. Im Gegenteil erlauben die Adapter über ganz unterschiedliche Wege (bis him zum Ausführen von Befehlen auf dem System) mit dem System und am System angeschlossener Hardware zu kommunizieren. Genau das unterscheidet den ioBroker vom dem standard Diensten (Grafana, PiHole, Influx, Nextcloud, und. so. weiter). Z2M hat eine gewisse Sonderstellung - allerdings ist gerade bei diesem Container gezielt die Weitergabe der korrekten USB Verbindung eine der häufigsten Stolperfallen bei der Inbetriebnahme.

Ein fertiges Image drumherum braucht es schlichtweg für Einsteiger und reine Anwender: Sie bekommen damit das Beste aus beiden Welten – ein vorbereitetes System mit passendem Handling auf Host-Ebene und eine echte Plug-and-Play-Erfahrung ohne SSH-Zwang.

Auch dem kann ich leider nicht zustimmen. Natürlich wird der OS-Agent nach bestem Wissen und Gewissen der Entwickler alles abdecken was die sich vorstellen können damit der Benutzer das OS administrieren kann ohne auf das OS selber herunter zu gehen. An der Stelle wird es dann aber schon etwas komisch:

• Wie administriert man Docker - Per eigener Web-Oberfläche ? Wie wird sichergestellt das diese nicht mit Adapter-Einstellungen kollidiert ?
• Was macht man wenn man von den Entwicklern nicht vorgesehene Container einsetzen will, die Konfiguration auf dem Host erfordern ?
• Was ist bei Problemen im Host-System ?

Letztendlich wäre ein vollständiges Plug&Play damit nur zu 85% gegeben. Wenn man den Benutzer von der Shell weg halten will, dann kommt man wohl eher nicht darum herum, eine GUI auf dem Basissystem zu installieren, damit auch ein unerfahrener Nutzer mit den GUI Werkzeugen den Host an den stellen administrieren kann die der Agent nicht abdeckt. Macht man das nicht muss der Nutzer ja dann doch auf die Konsole.

[SNIP]

A.

[fastfoot]

@leonie du scheinst mir nicht ausgelastet :-)

Tolle Idee! Und nein, würde ich nicht nutzen da ich keinen PI besitze und mit meiner Minimal Installation unter Docker auf WSL2 bestens zurecht komme.

Aber hier wirst Du auch nicht sehr viel Zuspruch bekommen, da sich die Leute hier für ihren iobroker sehr interessieren und damit nicht zur Klientel gehören welche Du eigentlich ansprechen willst. Die haben die Lernkurve fast alle hinter sich oder wissen wen sie fragen können. Der User, der 'nur Smarthome' haben möchte ohne tgl. 2 Std. im Forum zu verbringen tummelt sich hier erst gar nicht.

Von dem her was du auch so im Hannah Projekt schreibst würde ich dir zutrauen da etwas sehr Gutes zu erstellen, und auch die Fähigkeit so ein Projekt rechtzeitig abzubrechen, solltest du dich verkalkuliert haben.

Ich habe hier leider fast nur Bedenken gelesen und mir fehlt(e) etwas die Begeisterung für ein Projekt welches den iobroker weit nach vorne katapultieren könnte.

Mein Go hast du jedenfalls, auch wenn das natürlich keine Rolle spielt. Ich würde mich über eine Verbesserung der User experience jedenfalls sehr freuen, die ist seit Jahren überfällig (Kein Vorwurf an das Core-Team!!!).

Solltest du das Projekt starten, und wenn ich das Gefühl habe ich könnte helfen, dann werde ich das auch tun :-)

[Homoran]

Dann weiche ich die Bedenken mal auf!
Ja, ein solches System wäre für das Einstiegsklientel sicher von Interesse!

[Bedenken]
Es muss dann nur konsequent betreut werden, sonst wird's zum Bumerang
[/Bedenken]

[fastfoot]

@Homoran Müssen tut doch bei Open Source gar nichts! Ich vertraue da voll auf @bluefox , der wird sich das Konzept und die Umsetzung doch sehr genau ansehen bevor er es für 'seinen' iobroker empfiehlt und auf prominente Seiten setzt.

Will sagen, das sollte/kann doch kein Kriterium für eine Entwickler:in sein. Woher sollte @leonie jetzt schon wissen ob mind. 2 Leute dafür bereitstehen. So etwas baut man und wenn es gut ist wird es auch angenommen und auch weiterentwickelt. Scheitern kann auch ein sehr gutes Projekt, aus zig Gründen, aber davor steht doch immer erstmal der Aufbruch

[mcm1957]

Sorry

aber nur weil es gut und häufig benutzt wird wird es nicht halbwegs gesichert weiterentwickelt. Es wäre daher aus meiner Sicht gut wenn so eine potenzielle "Kernkomponent" mindestens 2 aktive Devs hat. Fällt ein Adapter aus dann kann es sehr schmerzhaft sein. Aber man kann immer noch auf den ExDev verweisen.

Wenn es da keine Redundanz gibt dann sollte das immer mit dem Hinweis nicht iffiziell / use at own risk angeboten werden. Denn wenn das plötzlich nicht mehr supported ist dann fällt das auf ioBroker als ganzes zurück.

Und ob Leonie Zeit u Lust hat das Setup hier mit ähnlich viel Aufwand wie Thomas den Linuxbereich betreut zu supporten kann nur sie beurteilen. Fragen wird es zumindest am Anfang sicher geben...

[FernetMenta]

Ich glaube die meisten hier sehen das viel zu kritisch. So ein Projekt kann auch ohne den offiziellen Segen der Kernkomponente starten. Ich habe früher Kodi (xbmc) mit etwickelt. Parallel haben sich Projekte wie OpenElec und LibereElec etabliert, die den Mediaplayer als Image angeboten haben. Irgendwann hatten die eine größere Userbase als das Coreprojekt selber.
Solange ich ioBroker benutze wird das ein Container Image sein. Mir ist es dabei völlig egal, ob da draufsteht, dass es das offizielle Image von ioBroker ist. Haupsache es funktioniert. Der Wartungsaufwand wird immer geringer sein als eine native Installation. Und wenn ich das image selber mache, was jetzt der Fall sein wird, dann ist da auch gut.

[fastfoot]

das war nicht mein Punkt. Es kann doch nicht Kriterium sein mit dem Beginn eines Projekts zu warten bis man einen 2ten Dev gefunden hat. Und auch nicht sich heute festzulegen ob man in einem Jahr noch Lust hat das zu betreuen.

Das sind ungelegte Eier. Wenn das mal ein offiziell supportetes Projekt wird dann kannst du darauf vertrauen dass Bluefox auch ein Wörtchen mitredet. Mich stören hier nur die Bedenken welche einen Start doch nur verzögern und im schlechtesten Fall verhindern. Wenn alle StartUps als Beispiel vorher sicherstellen wollten dass sie später auch erfolgreich sind dann gäbe es keine StartUps. Das ist mir Alles zu Negativ, sorry.

Du hast ja Recht damit dass das toll wäre wenn, aber hier geht es doch darum ob solch ein Konzept grundsätzlich gut sei. Die Tatsache dass Thomas hier locker eine Vollzeitstelle als Supporter haben könnte spricht doch bereits Bände. Ich bin anders als er nicht der Meinung dass man Grundlagen eines OS begreifen muss wenn man gutes(!) SmartHome haben will. Ich muss doch auch nicht tief in Windows oder Linux einsteigen wenn ich eine Tabellenkalkulation nutzen möchte. Das gehört ausgemerzt, seit Jahren. Dass das bisher nicht passiert ist, ist bei dem geringen Entwicklerstamm auch nicht verwunderlich. Jetzt kommt jemand und bietet das potentiell an, und alles was ich lese sind Bedenken dazu. Ob das dann was wird sieht man doch dann, so läuft das halt, man kann und sollte nicht alles vorherplanen. In den USA wird das tatsächlich anders gehandhabt. Die bauen auch viel Mist, aber das Mindset ist kpl. anders </Abschweifung>

[Thomas Braun]

@fastfoot sagte:

dass man Grundlagen eines OS begreifen muss wenn man gutes(!) SmartHome haben will.

Es hilft aber ENORM dabei.
Es muss ja niemand zum Linux-Guru oder Terminal-Terminator werden wollen. (Bin ich auch nicht).
Aber man muss ein wenig den 'Straßenplan' lesen können.