ElabNET Technik Forum

starwarsfan hat geschrieben: ↑
Mit SCP ist natürlich SSH gemeint. Das könntest Du auch einfach nachinstallieren, wenn's im verwendeten Base-Image nicht mit drin ist.

Das wäre vermutlich die einfachste und eleganteste Lösung. Dafür bietet sich ja ein Container wie alpine-ssh an, der ist nur 5M gross. Das Setup wäre trivial, es muss nur wie auch beim Cometvisu-Container das Daten-Volume gemountet sowie der Port 22 (ssh) gemappt werden. Braucht man keinen ssh-Zugriff mehr, wird der Container gestoppt.

Danke - probiere ich bald mal aus.
Sollte zum config basteln reichen.
Die css-files wie custom.css erreicht man so vermutlich nicht.

Lg
Robert

starwarsfan hat geschrieben: ↑Di Okt 23, 2018 8:03 am Einziger Nachteil: Man kommt nur an die Dateien heran, die auf dem Daten-Volume des Cometvisu-Containers liegen. Die Apache-Konfig oder dergleichen kann man also nicht bearbeiten.

Das ist kein Nachteil, sondern ein Vorteil: es zwingt dazu das richtig zu machen!

Die Daten in einem Container soll man nicht nachträglich ändern, denn die gehen mit dem neuen Aufsetzen des Containers flöten.

Wer hier Änderungen will baut sich ein eigenes Dockerfile das auf den Container verweist und dann die Änderung vornimmt.

(Dem einzigen den das stört ist der Entwickler vom Container selbst - aber der kann ja den dabei so modifizieren, dass ein SSH mit drinnen ist )

Hinzugefügt nach 1 Minute 20 Sekunden:

Robert_Mini hat geschrieben: ↑Di Okt 23, 2018 9:54 pm Die css-files wie custom.css erreicht man so vermutlich nicht.

Das ist ein guter Punkt. Und mit der 0.10.2 nicht mehr lösbar.

Das müssen zukünftige Releases besser machen.

jockel hat geschrieben: ↑Di Okt 23, 2018 11:13 am Zu ssh/scp hatte ich hier vor einiger Zeit mal etwas geschrieben und darin ein Dockerfile gepostet. Damit solte es eigentlich klappen wie von Chris geschrieben: Einen zweiten Container mit ssh starten, der die gleichen Verzeichnisse mounted. Ich meine, dass hätte ich in meinem Post auch beschrieben.

Wenn ich das hier so lese, muss ich mir die CometVisu wohl noch mal anschauen. Bislang sind die Versuche damit immer an meinem nicht vorhandenen Talent zum Design gescheitert...

Danke - hab deinen Beitrag gefunden:
viewtopic.php?f=25&t=148&p=939#p939

Versteh ich das richtig, dass dein Vorgehen nicht mit Portainer umsetzbar ist, sondern man Docker in einer Linux-Umgebung braucht?

Zum Ausprobieren: am besten eine Config eines Users als Basis nehmen (gerne schicke ich auch eins von mir) und umgestalten...
Lg
Robert

Chris M. hat geschrieben: ↑Di Okt 23, 2018 9:57 pm Das ist kein Nachteil, sondern ein Vorteil: es zwingt dazu das richtig zu machen!

Die Daten in einem Container soll man nicht nachträglich ändern, denn die gehen mit dem neuen Aufsetzen des Containers flöten.

Hinzugefügt nach 1 Minute 20 Sekunden:

Robert_Mini hat geschrieben: ↑Di Okt 23, 2018 9:54 pm Die css-files wie custom.css erreicht man so vermutlich nicht.

Das ist ein guter Punkt. Und mit der 0.10.2 nicht mehr lösbar.

Das müssen zukünftige Releases besser machen.

Das wäre super!
Eventuell kann ja der Ersteller des Containers in den nightly builds der Entwicklerversion ein ssh für alle einbauen, das im Release dann wegfällt?!

Danke und Lg
Robert

Grundsätzlich ist das denkbar.

Jetzt steht erst mal die Erweiterung auf das OpenHAB Backend an (ich muss mir den Pull Request noch ansehen, sollte aber harmlos sein). Dann werden wir das ganze Richtung automatische Erstellung mit Nightly Builds erweitern. Da wäre dann durchaus denkbar so Spielereien wie SSH mit einzubauen.
Am besten wäre halt, wenn hier Docker Compose unterstützt werden würde. Oder eine andere Möglichkeit mehrere spezialisierte Container mit einer Docker-Config gleichzeitig einzurichten und zu starten.

Danke - hab deinen Beitrag gefunden:
viewtopic.php?f=25&t=148&p=939#p939

Versteh ich das richtig, dass dein Vorgehen nicht mit Portainer umsetzbar ist, sondern man Docker in einer Linux-Umgebung braucht?

Ich hab das damals mit einer Docker Installation auf einem Linuxrechner getestet, sehe aber eigentlich keinen Grund, warum das mit dem Portainer nicht gehen sollte. Die SSH Schlüssel braucht. an nicht zwingend und kann sie sonst ja auch auf einem anderen Rechner erzeugen und zusammen mit dem Dockerfile als tar Archive im Portainer hochladen.

Ich kann das gerne mal ausprobieten, werde aber wohl erst am Freitag oder am Wochenende dazu kommen.

Wo siehst Du den Probleme, das mit Portainer umzusetzen?

Eine Frage eher genereller Natur.
(Gerne Verschieben,wenn es nicht hier her passt)

Der Link für die Visu geht ja jetzt auch über den TWS.
Hierfür benötigt man ja das Zertifikat damit das als vertrauenswürdig erkannt wird.

Muss man dann auf jedem Endgerät, welches die Visu später darstellen soll das Zertifikat installieren?

Die Geräte verlangen ja aber eine Authentifizierung per Fingerprint/Muster/Pin oä.
Bei einem reinen Visu Tablet wäre mir das aber schon zuviel.

Wird das weiterhin so sein?

Hoi

Wenn ich es richtig sehe, kannst Du die Visu ohne https aufrufen.
Je nach dem wie man den Container einstellt.

jockel hat geschrieben: ↑Di Okt 23, 2018 10:51 pm
Ich hab das damals mit einer Docker Installation auf einem Linuxrechner getestet, sehe aber eigentlich keinen Grund, warum das mit dem Portainer nicht gehen sollte. Die SSH Schlüssel braucht. an nicht zwingend und kann sie sonst ja auch auf einem anderen Rechner erzeugen und zusammen mit dem Dockerfile als tar Archive im Portainer hochladen.

Ich kann das gerne mal ausprobieten, werde aber wohl erst am Freitag oder am Wochenende dazu kommen.

Wo siehst Du den Probleme, das mit Portainer umzusetzen?

Ehrlicherweise kenne ich Portainer nicht wirklich. Ich dachte Portainer braucht ein Image, das man zuvor mit Docker erstellen muss.

Robert

FabKNX hat geschrieben: ↑Mi Okt 24, 2018 7:04 am Der Link für die Visu geht ja jetzt auch über den TWS.
Hierfür benötigt man ja das Zertifikat damit das als vertrauenswürdig erkannt wird.

Muss man dann auf jedem Endgerät, welches die Visu später darstellen soll das Zertifikat installieren?

Die Geräte verlangen ja aber eine Authentifizierung per Fingerprint/Muster/Pin oä.
Bei einem reinen Visu Tablet wäre mir das aber schon zuviel.

Wird das weiterhin so sein?

Grundsätzlich: für eine HTTPS Verbindung braucht es eine Signatur des Servers. Diese Signatur wird jeweils für eine (Sub-)Domäne ausgestellt.
Auf dem Client (Web-Browser) muss diese Signatur hinterlegt sein, damit der überprüfen kann, dass der Server auch der ist, für den er sich ausgibt.
Dies wäre im Internet etwas unhandlich (vor jedem Aufruf einer Seite erst mal ein Zertifikat installieren zu müssen) und auch für die Sicherheit nicht sinnvoll, da Du ja gar nicht wissen kannst, ob das Zertifikat vor irgendeinedomain.de auch wirklich dieser Seite gehört.
Gelöst wird das dardurch, dass es Zertifizierungsstellen gibt, denen die (meisten) Browser trauen und diese Stellen dann Zertifikate (nach entsprechender Prüfung) für die Domains wie irgendeinedomain.de ausstellen.
Durch diese Kette (Browser vertraut Zertifizierungsstelle -> Zertifizierungsstelle stellt Zertifikat aus -> Server verschlüsselt mit diesem individuellen Zertifikat) wird das Vertrauen sichergestellt.
(Und wenn man, wie Symantec, dabei schludert wird man von den Browser-Herstellern, wie Google mit Chrome, als zuverlässige Zertifizierungsstelle rausgeworfen und jeder der für viel Geld dort sein Zertifikat gekauft hat schaut blöd drein...)

Das ganze geht aber leider nicht für ein privates Intranet - denn dort wird kein öffentlicher Domainnamen verwendet. Also gibt's kein öffentliches Zertifikat einer allgemein akzeptierten Zertifizierungsgesellschaft.

Die Lösung: der Server (hier Timberwolf) zertifiziert sich einfach selbst. Was aber kein Browser akzeptiert - da es ja nicht von einer allgemein akzeptierten Zertifizierungsgesellschaft signiert wurde.
Also: Du musst das Zertifikat im Browser als gültig importieren und akzeptiert dieser dieses Zertifikat und diesen Server.
Aber: das muss natürlich mit jedem Browser gemacht werden, der dieses Zertifikat akzeptieren soll. Auch der Wand-PC oder das Tablet.

Dies ist völlig unabhängig womit das Betriebssystem vor fremden Login geschützt wird (wie Passwort oder Fingerprint).

Durch das Verwenden des Timberwolf-Proxys erspart Dir der aktuelle CometVisu Container aber, dass Du für diesen Container auch noch mal ein Zertifikat importieren musst, Du kannst das Timberwolf Zertifikat einfach mitnutzen.

Alternativ, wenn Du auf HTTPS verzichten möchtest, kannst Du natürlich auch den Proxy links liegen lassen und direkt auf den CometVisu-Contianer zugreifen. Das wäre nach dieser Anleitung unter http://<URL des Timberwolf>:18080/ zu finden.
Aktuell ist das auch völlig in Ordnung (außer dass der Netzwerk-Verkehr im Klartext läuft, was aber im Heimnetz meist egal ist und von außen eh über ein VPN getunnelt werden sollte).
Aber: Es gibt Browser (mal wieder Google mit dem Chrome) die die Features die über HTTP gehen Stück für Stück einschränken um das Netz zu zwingen auf HTTPS zu gehen.
Für das Internet selbst ist das völlig i.O. - aber wir mit unserer Intranet-Anwendung müssen da drunter leiden und haben keine Möglichkeit außen herum (außer selbstsignierten Zertifikaten)