ElabNET Technik Forum

Hoi Andi

tger977 hat geschrieben: ↑Do Jan 02, 2020 9:17 am Also ich würde das default Passwort "123456" direkt rausnehmen und damit die ROOT_PASS Variable quasi verpflichtend machen. HOSTIP ist z.B. ja auch "verpflichtend" sonst geht zu 99% auch nichts.

Mal schauen, ob's noch weitere Meinungen dazu gibt.

tger977 hat geschrieben: ↑Do Jan 02, 2020 9:17 am Das handling mit dem private key ist m.E. noch etwas umständlich, da man z.B. für WinSCP den key noch konvertieren muss.

Das lässt sich aber nicht ändern. Ich habe noch nie verstanden, warum PuTTY ein eigenes Format für die Schlüssel verwendet. Für meine Begriffe ist das völlig daneben und macht eben genau solche Dinge unnötig kompliziert.

Die einfach(st)e Lösung wäre: Bessere Tools verwenden!

tger977 hat geschrieben: ↑Do Jan 02, 2020 9:17 am Und das Handling muss vor allem nach jedem Neubau des Containers wieder neu durchgezogen werden da sich ja auch jedesmal der private key neu ändert.

Nein, musst Du nicht. Dir ist Docker offenbar noch nicht in Fleisch und Blut übergegangen!

Du kannst einfach ein Volume anlegen und nach /root/ oder auch direkt /root/.ssh/ mounten. Nach dem ersten Start des Containers liegt dort das Keypair etc. Dieses Volume dann wie alle anderen Volumes später bei neuen Containern wiederverwenden und schon bleibt der Key immer gleich. Alles klar?

tger977 hat geschrieben: ↑Do Jan 02, 2020 9:17 am Achja: das Setzen des Root Passworts funktioniert einwandfrei!

Thx für die Rückmeldung.

Bin zwar kein Poweruser, aber ich finde default-Passwörter gut, denn damit entfällt ein Stolperstein für Neulinge.
Wichtig ist nur, dass der defaultwert gut dokumentiert ist.

Lg
Robert

Hallo Philipp

Didda93 hat geschrieben: ↑Do Jan 02, 2020 6:30 pm OK also das klingt jetzt als wäre die ARM Version von deiner Seite verschoben und nach Christians Aussage eher zu kompliziert zum Umsetzen
Darf man nun noch hoffen oder erstmal eher weniger?

Nunja, die Hoffnung stirbt bekanntlich zuletzt.

Ich bin mir noch nicht so recht im klaren darüber, wie ich nun weiter mache. Das augenscheinlichste Problem ist im Moment, dass der Visu-Refresh nicht funktioniert und ich kann mir beim besten Willen nicht vorstellen, dass das eine 64Bit-Spezialität ist. Websockets sind ja nun wirklich nichts besonderes hinsichtlich der Registerbreite einer Architektur. Aber es müsste trotzdem erstmal danach gesucht und das Problem auch gefunden werden, dann können wir weiter sehen.

Frage an die Schienenwolfbesitzer: Wie ist die Performance mit einem Raspi4 zu vergleichen? Ist der Schienenwolf performanter? Ich habe das jetzt auf einem Raspi4 unter Raspbian-Buster ausprobiert. Aber es ist eben ein Raspi, unter "Performance" kann man sich durchaus etwas anderes vorstellen...

Vielen Dank für die schnelle Antwort
Hoffen wir das Beste

Da ich leider keinen pi in Betrieb habe kann ich dies nicht beantworten

Lg

Hallo liebe EDOMI Freunde,

hier nun die versprochene Anleitung für EDOMI V2.00 mit CentOS7 und php7 auf dem Timberwolf (im Moment ist bis auf weiteres jedoch nur die AMD64 Version für die Desktopmodelle funktionsfähig):
Einen riesen Dank an Yves für diese tolle Umsetzung und die vielen Verbesserungen und Erweiterungen im Container und natürlich auch fürs reviewen der Anleitung!

@mods: könnt ihr das bitte in die KB einarbeiten und ggf. auch in den post #1 von Yves noch einbauen damit man es schneller findet?

Falls was missverständlich sein sollte oder Änderungswünsche bestehen meldet euch einfach kurz bei mir.

und alle die noch das Problem haben in EDOMI diverse Datenarchive zu haben die man gerne nun auf Grafana bzw. Timeseries per TW umziehen möchte ohne die gesamte Datenhistorie zu verlieren bitte noch diesen FR liken:

viewtopic.php?f=9&t=1801#p19183

Ein EDOMI csv Export Baustein gibt es...

starwarsfan hat geschrieben: ↑Do Jan 02, 2020 7:37 pm Frage an die Schienenwolfbesitzer: Wie ist die Performance mit einem Raspi4 zu vergleichen? Ist der Schienenwolf performanter? Ich habe das jetzt auf einem Raspi4 unter Raspbian-Buster ausprobiert. Aber es ist eben ein Raspi, unter "Performance" kann man sich durchaus etwas anderes vorstellen...

@StefanW ich machs jetzt nochmal expliziter. Meinst du nicht, dass es ein total sinnvoller Invest wäre, dem @starwarsfan einen Schienenwolf zu spendieren. Es kostet dich Hardwarekosten und Porto, aber was dabei rauskommen könnte, könnte das doch weit in den Schatten stellen.

Ist natürlich eine Wette auf die Zukunft, aber so ist es ja mit jedem Invest und dieser Invest scheint im Vergleich zu anderen sehr überschaubar zu sein.

@bluegaspode
Es ist hier weniger an Yves, etwas zu tun. Hier ist Christian als Entwickler von Edomi gefragt. Der wird hier aber kaum Interesse haben, denn es gibt ja ein hinreichend großes Ökosystem, auf dem Edomi läuft. Yves kann noch so viele Hutschienen-Server bekommen, das wird nicht helfen.
Das ist ja das große Problem an Edomi: Ein an eine Person gebundenes Projekt, das diese aus nachvollziehbaren Gründen nicht öffnen mag. Was Christian in Edomi nicht macht,macht dann eben keiner.
Es wäre daher wichtiger, dass das, was Edomi heute für dessen Anwender leistet, im Ökosytem des Timberwolf nativ zur Verfügung zu haben. Da sollte das Investment von Elabnet hingehen. Was die Community darüber hinaus noch zum Fliegen bringt, ist super, sollte aber nicht Stefans Mitarbeiters Zeit unnötig verbraten.
Wie viel fehlt denn noch, um auf Edomi verzichten zu können?

Markus

Sehe ich auch so wie Markus. Technisch sicher toll das alles in Docker laufen zu lassen, aber die Komplexität nimmt dadurch weiter zu. Wie geschrieben sollte möglichst viel nativ im TWS möglich sein. Mir persönlich fehlt zum kompletten abschalten von Edomi noch die Möglichkeiten zur Anbindung von fremden Systemen mit UDP/TCP und die ganzen Benachrichtigungsfunktionen und Szenenfunktionen für Beleuchtung.

Gruss
Dani

Hallo Dani

danik hat geschrieben: ↑Fr Jan 03, 2020 10:24 am Technisch sicher toll das alles in Docker laufen zu lassen, aber die Komplexität nimmt dadurch weiter zu.

Ist klar und liegt in der Natur der Sache.

danik hat geschrieben: ↑Fr Jan 03, 2020 10:24 am Wie geschrieben sollte möglichst viel nativ im TWS möglich sein.

Das ist ebenfalls klar, damit wird die Komplexität von Dir als Anwender zum Hersteller geschoben.

danik hat geschrieben: ↑Fr Jan 03, 2020 10:24 am Mir persönlich fehlt zum kompletten abschalten von Edomi noch die Möglichkeiten zur Anbindung von fremden Systemen mit UDP/TCP und die ganzen Benachrichtigungsfunktionen und Szenenfunktionen für Beleuchtung.

Da sieht man schön, wie unterschiedlich die Gewichtung ist. Grob gesagt könnte man Edomi von der Anwendersicht her in zwei Teile splitten: Edomi-Visu und Edomi-Logik. Zweiteres ist sicher einfacher im TW abzubilden, mglw. sogar jetzt schon. Aber die Visu mit derartigen Freiheitsgraden im TW nachzubilden, ist eine völlig andere Hausnummer. Von daher wage ich zumindest für mich zu bezweifeln, Edomi gänzlich abzuschalten. Gerade weil ich all diese vor allem geometrischen Visu's überhaupt nicht mag...