Bevor wir die RC veröffentlichen, möchte ich absolut sicher sein, dass das Raspbian-Image, das wir bereitstellen, langlebig ist und sich lebenslang ohne Benutzerinteraktion aktualisiert.
Gladys-Update
Das Docker-Container-Update von Gladys erfolgt automatisch dank Watchtower, also in dieser Hinsicht sind wir schon gut aufgestellt.
Update der Gladys-Container-Parameter
Derzeit wird Gladys mit einem docker run mit bestimmten Parametern gestartet. Allerdings möchten wir in Zukunft möglicherweise mehr Volumes freigeben oder einen Parameter ändern?
Wie können wir das bei bereits bereitgestellten Remote-Images tun?
OS-Update
Ich kenne mich mit den Best Practices für solche eingebetteten Geräte nicht aus, denn einerseits ist es riskant, Paket-Updates automatisch durchzuführen, und das ist der beste Weg, die Installation zu bricken, aber andererseits ist es nicht verrückt, Gladys ohne Updates laufen zu lassen.
Das wird kompliziert, für die Bind-Mounts muss man den Container zerstören und neu erstellen, also alles andere als reibungslos.
Die Parameter, die man „heiß“ ändern kann, sind die hier => docker container update | Docker Docs also alles, was Ressourcen betrifft. (nicht wirklich das, was uns interessiert)
Mm ok, in diesem Fall wäre es vielleicht besser, großzügig zu planen und sicherzustellen, dass das Basis-Raspbian-Image alle Volumes enthält, die wir in Zukunft benötigen.
Siehst du etwas, das im aktuellen Image fehlen könnte?
Wir haben /dev, aber fehlt uns da nicht noch etwas? Zum Beispiel für den Zugriff auf die GPIO oder die offizielle Raspberry Pi-Kamera, das Image muss mit möglichst vielen Dingen kompatibel sein, auch wenn wir sie noch nicht verwalten. Docker soll uns nicht beim Entwickeln der nächsten Schritte bremsen
Kann man die im Image, das du buildest, aktivieren?
Ich nutze es auf meinen Debian/Ubuntu-Maschinen, nie Probleme gehabt.
Falls ein Sysadmin hier vorbeikommt, denke ich, der wird das bestätigen. (Hallo @Totof)
@VonOx Eigentlich nutze ich das bereits (unattended-upgrades) auf allen meinen Servern. Es ist standardmäßig in Ubuntu 18.04 enthalten, also ja, es ist super stabil und erledigt den Job. Das können wir zum Bild hinzufügen!
Super! Du meinst, eine PR auf dem Gladys-Repo machen?
Ich weiß nicht, welche die beste Strategie zum Mergen ist (ähnlich wie deine PR zu den Docker-Images mit der Architektur).
Weil wir solange wir noch in der Beta sind, es cool ist, wenn alle laufenden Instanzen weiterhin aktualisiert werden. Allerdings baut die PR mit den Docker-Images derzeit auf dem Tag mit der Version, nicht auf dem Beta-Tag.
Hast du eine Idee?
Ansonsten informieren wir alle (solange wir noch nicht tausende Gladys 4-Nutzer sind), dass wir auf dem Version-Tag bauen werden und die Beta einstellen, aber das könnte für Unmut sorgen, weil das bedeutet, dass alle alles neu installieren müssen (laut letzter Information haben wir etwa 200 aktive v4-Instanzen).
Ich sehe nicht 36 Lösungen, alle laufen auf dem Beta-Tag, also wenn du es mergst, wird keine Instanz aktualisiert.
Wie du sagst, ein großer Kommunikationsaufwand, um den Nutzern zu sagen, wie sie manuell aktualisieren oder das letzte Image neu flaschen können.
Aber wir könnten eine Übergangszeit vorsehen, in der wir den Beta-Tag noch bereitstellen und eine Benachrichtigung in Gladys hinzufügen, wenn der Tag Beta enthält? Das wäre weniger brutal.
Ich war in letzter Zeit selten hier, ich bin gerade umgezogen ^^
Ich habe noch nie automatische Server-Updates getestet und ich glaube nicht, dass ich das tun werde.
Manchmal ändern sich Konfigurationsdateien zwischen den Versionen oder Optionen existieren nicht mehr. Ich bevorzuge die Anwendung mit Ansible und eine Reihe von Tests danach.
Aber ich frage mich, wie sich die Sicherheitsupdates verhalten, wenn Gladys in einem Docker läuft?
Sollte es auf dem Raspbian laufen, das den Docker hostet, oder?
Man sollte den Benutzer warnen oder eine Einstellungsmöglichkeit lassen. Der Raspberry wird vielleicht auch für andere Dienste verwendet.
Das Verzeichnis, das das Start-Skript von Gladys enthält, mit dem Gladys-Container freigeben, um die Container-Einstellungen zu ändern oder bei Bedarf vor dem Start neue Verzeichnisse zu erstellen.
Ein Neustart des Systems würde das Update ermöglichen.
Einen Wartungs-Container von Gladys aus starten. Dieser könnte dann den Gladys-Container stoppen-löschen, die neuen Einstellungen anwenden und Gladys neu starten.
Ich habe gerade an etwas gedacht, ohne es wirklich zu vertiefen.
Das Paket würde also auf Raspbian installiert werden, also in Bezug auf die Einstellungen eingefroren. Der Benutzer müsste zwangsläufig über SSH darauf zugreifen, um es zu ändern, insbesondere beim automatischen Neustart in der Nacht.
Gibt es keine WebUI-Lösung, mit der Updates gestartet und/oder auf die Paketeinstellungen zugegriffen werden kann?
Vor langer Zeit habe ich Webmin verwendet, ich weiß, dass es auch andere gibt.
Da der Benutzer nicht mehr über SSH zugreifen muss, denke ich, dass eine solche WebUI auch Vorteile hätte, um DHCP/statische IP zu wählen, seinen DNS-Resolver auszuwählen und Updates anzuwenden.
Der Gedanke, der mir auch gut gefällt, wäre, dass Gladys den Benutzer außerhalb von Sicherheitsupdates darüber informiert, dass ein Update durchgeführt werden muss, z. B. ein Kernel-Update, und dass der Benutzer es über eine WebUI auslöst.
Ich denke auch! Man kann weiterhin das Beta-Tag bauen, solange man nicht in der RC-Phase ist (indem man nur noch das Bild mit dem v4-Tag auf der Website bereitstellt), und dann bei der Veröffentlichung der RC kann man ankündigen, dass das Beta-Tag nicht mehr aktualisiert wird. Das erscheint sanfter
Ja, dieses Thema behandelt nur das Raspbian-Bild, nicht den Container.
Achtung, dieses Thema behandelt nicht Gladys, sondern das Raspbian-Bild, das wir für Anfänger bereitstellen, die sich wahrscheinlich nie per SSH auf dem Raspberry Pi anmelden werden.
Man muss dieses Raspbian-Bild wie ein Hersteller von IoT-Geräten (z. B. eine IP-Kamera, die auf Linux läuft) behandeln, der seinen Kunden Kameras bereitstellt: Der Kunde wird sich nie per SSH mit der Kamera verbinden, er weiß nicht einmal, was SSH, Linux usw. ist, er will nur, dass die Kamera funktioniert, Punkt.
Hier ist es dasselbe: Unser Raspbian-Bild wird auf SD-Karten geklont, eine Manipulation, die jeder mit Etcher durchführen kann, und Gladys läuft vielleicht 5 Jahre, ohne dass sich der Benutzer jemals per SSH anmeldet!
Wenn du ein fortgeschrittener Benutzer bist, besondere Konfigurationen hast, dann bist du in der Lage, die Konfiguration des Raspbian-Bildes zu ändern. Die Grundeinstellungen, die wir wählen, sind für den durchschnittlichen Benutzer und sollten gute Standardeinstellungen sein.
An sich haben wir bereits Zugriff auf den Docker-Daemon von innerhalb Gladys, also dachte ich, man könnte tatsächlich einen neuen Gladys-Container mit einem anderen Befehl neu starten
aha genau, wir hatten dieselbe Idee
Andernfalls können wir einfach den Neustart des Hosts in Gladys freigeben
Übrigens fällt mir ein, @VonOx ich denke, wir werden alle Funktionen des Pakets rpi-info wiederfinden wollen, das Piznel in Gladys 4 gemacht hat.
Stellt das aktuelle Bild genug Informationen bereit, damit wir alle Informationen haben? Ich denke, es fehlt noch etwas
Die Frage, die ich mir stelle und die wahrscheinlich präziser mit einem Beispiel wäre:
Ein Benutzer installiert Gladys, er erhält eine IP-Adresse von seinem Router und konfiguriert alles damit.
Am nächsten Tag ist der Router kaputt, und mit dem Wechsel des Routers ist es sehr wahrscheinlich, dass die dem Raspberry zugewiesene IP-Adresse nicht mehr dieselbe ist wie zu Beginn.
Natürlich findet ein durchschnittlicher Benutzer Gladys nicht mehr, und bei Recherchen oder Fragen im Forum wird er auf Begriffe wie IP usw. stoßen. Um die neue IP seines Raspberry zu finden, muss er ein IP-Scan-Software verwenden.
Genau, viele Geräte bieten bei der Konfiguration die Möglichkeit, eine feste IP-Adresse zuzuweisen oder sie per DHCP zu lassen.
Diese Arbeit ist eindeutig nicht für Gladys zuständig, deshalb habe ich an Webmin oder auch Cockpit https://cockpit-project.org/ gedacht, es gibt noch viele andere, die als Paket (daher einfache Updates) in Raspbian eingebunden werden könnten und eine Weboberfläche für Netzwerkkonfigurationen bieten könnten.
Aber in meinem Beispiel, selbst wenn es eine Weboberfläche zur Netzwerkkonfiguration gibt und der Benutzer sie nicht verwendet, ändert das nichts daran, dass er, wenn aus irgendeinem Grund der DHCP ihm keine IP-Adresse mehr zuweist, sein Gladys nicht wiederfindet.
Persönlich finde ich, dass das Festlegen einer IP-Adresse für einen solchen Dienst spätere Probleme vermeidet. Ich habe zu oft solche Probleme lösen müssen ^^
Es bleibt trotzdem reines Netzwerk, wenn der Client-Benutzer xxx.local verwendet, muss der DHCP im .local-Bereich sein, was nicht unbedingt der Fall ist.
Wenn die Box mit einem lokalen Bereich .lan konfiguriert ist, verteilt der DHCP eine IP-Adresse, und wenn er auch den Hostnamen in seiner Datenbank angibt, wird sein FQDN gladys.lan sein.
Allgemein gesagt, wird dringend empfohlen, dass alle Geräte, die Dienste verwalten (Server, Drucker, Kamera, Detektor)
eine feste IP-Adresse haben oder eine MAC-Reservierung im DHCP haben, um ihm immer dieselbe zuzuweisen, und in diesem Fall muss dies auf Ebene der Box jedes Benutzers erfolgen oder es muss erledigt werden.
Am benutzerfreundlichsten ist es, wenn der Nutzer sich immer über Gladys Plus anmeldet, sodass die URL nie wechselt (plus.gladysassistant.com), aber das gilt nur für Nutzer des kostenpflichtigen Pakets.
In jedem Fall können wir die Network-Scanner-App (iOS/Android) empfehlen, die recht benutzerfreundlich ist, um deinen Pi zu finden, falls sich seine IP geändert hat und sein Router .local/.lan nicht unterstützt. Allerdings kommt das auch nicht alle Tage vor: Die meisten Consumer-Router unterstützen .local, und im schlimmsten Fall gibt es ja noch die Network-Scanner-App
Gladys-Update
Update der Gladys-Container-Parameter
