Ich versuche es nochmal, ich weiß warum es nicht funktioniert, ich werde heute Abend einen neuen Build machen und das Problem beheben. (Ich habe noch ein paar Dinge zu erledigen, bevor es dunkel wird 
)
Danke für das Feedback.
Ich habe die CI verbessert
Neues Build => Release v1.0.3 · VonOx/gladys-pi-gen · GitHub
Noch nicht in der Praxis getestet
Erster Start
SD-Karte partitionieren
Neustart
Setup-Container, Watchtower und Gladys erstellen
Hinweis:
Bei der ersten SSH-Anmeldung müssen Sie das Passwort ändern (Standard: gladys/raspberry)
Während der Container-Erstellung ist eine Warteseite unter http://IP.DU.PI oder http://gladys verfügbar
Ich habe ein bisschen was hochgeladen, falls jemand Zeit hat, es zu testen und Feedback zu geben. Ich mache alles ein bisschen blind, weil ich kein PI zum Testen habe.
Danke im Voraus 
@VonOx Ich weiß nicht, ob du das kennst:
Damit kannst du deine Images testen 
Ansonsten gibt es Raspberry Pi, die man online mieten kann:
Das sind Raspberry Pi Cloud-Server, für 4,99 €/Monat. Du kannst einen starten, um zu testen. Ich weiß nicht, ob es möglich ist, pro Minute zu bezahlen, aber wenn ja, ist das wirklich alles-in-einem für Tests. ^^
Falls nicht, gibt es auch noch: Raspberry Pi - Mythic Beasts
Hallo. Ich habe heute Morgen mit einem RPI3A+ getestet und es hat auf Anhieb funktioniert 
Etwa 1 Minute bis zum Anzeigen der Seite:
Dann 4-5 Minuten zum Herunterladen und Installieren von Gladys (direkt die neueste Version 
)
Nur eine kleine Anmerkung, ich habe den Eindruck, dass die Warteseite sich von selbst aktualisiert, aber es gibt einen Moment (ich denke, wenn das Gladys-Bild startet), in dem die Seite einen Fehler anzeigt. Dann muss man manuell aktualisieren. Ich glaube, es wird schwer, es besser zu machen.
Ja, ich habe einen Auto-Refresh eingestellt, damit es bei Gladys landet, wenn der Container zerstört wird (60 Sekunden), vielleicht muss ich das erhöhen. Du musst genau dann reingekommen sein, als der Warteschlangen-Container zerstört wurde und Gladys noch nicht vollständig hochgefahren war (spielen Sie Lotto, denn es geht um Sekunden ^^)
Danke für das Feedback @cicoub13
Das ist eine gute Nachricht, das erspart uns das 24-stündige Warten.
Könntest du nicht eine GET-Anfrage in JS ohne Refresh machen, um zu vermeiden, dass der Benutzer auf einer „kaputten“ Seite landet?
Zum Beispiel pollst du alle 10 Sekunden den Gladys-Endpoint, um zu sehen, ob sie online ist, und refreshst, wenn es schließlich nicht mehr 404 ist.
Das Problem ist, dass Gladys nicht startet, wenn der Port (80) bereits belegt ist.
Deshalb habe ich eine automatische Aktualisierung auf der Browserseite eingerichtet, aber das ist eine etwas russisches Roulette-Methode.
Als @cicoub13 den Fehler hatte, existierte der Setup-Container nicht mehr.
Ich erkläre nochmal kurz den Ablauf des Bildes:
- Erster Start, OS-Vorbereitung (Partition erweitern / neue SSH-Schlüssel generieren usw.)
- Neustart
- Erstellung des Setup-Containers (nginx auf Port 80), die Seite aktualisiert sich alle 60 Sekunden
- Erstellung des Watchtower-Containers
- Pull des letzten Gladys-Bildes
- Wenn das Bild gepullt ist, wird der Setup-Container zerstört und Gladys auf dem gerade freigegebenen Port 80 gestartet.
Es gibt wahrscheinlich eine bessere oder intelligentere Möglichkeit. Ich bin für jeden Vorschlag offen.
Ja ja, aber wenn das Frontend bereits läuft, bleibt es im Browser des Benutzers, selbst nach dem Stoppen des Containers
Ich spreche davon, einen stummen GET-Request in JS durchzuführen (ohne die Seite neu zu laden), um genau diesen gesamten Lebenszyklus zu erkennen
OK, ich denke, ich habe den Punkt verstanden
Ich behalte den aktuellen Fluss mit den Containern, ich entferne das Refresh.
Auf der Setup-Seite ein Stück js, das refresht, wenn der Endpunkt verfügbar ist
Ja, genau das 
Aber ansonsten GG für den Rest, das wird die Installation für alle viel verständlicher machen!
Das ist erledigt, ich habe ein neues Docker-Image für den Setup-Container erstellt, kein Bedarf, ein neues Raspberry-Image zu erstellen
Der JS-Code, den ich hinzugefügt habe (Danke, Stackoverflow :D)
setInterval(detectGladysContainer, 30000);
var currentHostname = window.location.hostname;
var gladysUrl = 'http://' + currentHostname + '/signup';
function detectGladysContainer() {
var myRequest = new Request(gladysUrl);
fetch(myRequest).then(function (response) {
if (response.status == '200') {
window.location.replace(gladysUrl);
}
});
};
detectGladysContainer();
Cool, das freut mich
Wir müssen uns um den Repositorium-Transfer mit @pierre-gilles kümmern und ich muss das Raspberry-Image neu aufbauen, um das richtige Image zu ziehen.
Du könntest es meiner Meinung nach schneller als 30 Sekunden machen, 5 Sekunden wären besser! Eine kleine Anfrage wird schon nicht schaden
Was muss für den Repo-Transfer gemacht werden? Einfach den Repo kopieren?
Danach muss das CI eingerichtet werden (oder hast du das schon gemacht?)
Sonst noch Fragen:
- ist der Hostname wirklich gladys?
- was ist im Vergleich zum aktuellen Bild anders?
Sonst tolle Arbeit, ich kann es kaum erwarten, das in die Produktion zu bringen! Ich werde versuchen, morgen einen Test durchzuführen, um zu sehen, wie es läuft 
Ja, ich hatte 5 Sekunden eingestellt, aber das schien mir dann doch etwas grob 
Entweder du nimmst es so wie es ist (alles manuell und Verlust des Historie), oder ich mache einen Owner-Transfer bei GitHub (derzeit kann ich nicht auf die Org übertragen, da ich das Recht brauche, einen Repo zu erstellen).
Das CI ist bereit, aber mit meinem Dockerhub für die Tests etc. konfiguriert… aber es ist funktionsfähig.
Sowohl für das RPI-Image als auch für das Docker-Setup-Image
Ja
Der Standardbenutzer (gladys)
Notwendigkeit, das Passwort bei der ersten SSH-Anmeldung zu ändern
UDEV-Regeln (heute nicht genutzt)
Ich muss das, was du für das Sicherheitsupdate definiert hast, abrufen
Wir verlieren den Verlauf nicht, wenn ich den Repo pushe, nicht nur die Dateien git clone + git push auf ein anderes Ziel
Wollen wir das wirklich ändern?
Ich mochte die Idee, die gleichen Anmeldedaten wie das offizielle Raspberry Pi OS-Image zu behalten, damit es einfach zu verstehen ist, dass es sich um dasselbe Raspberry Pi-Image wie das offizielle handelt und dass die Anmeldedaten dieselben sind.
Ja, das ist entscheidend. Du musst nur ein Paket installieren, das ist nicht schwer
Anderer Kommentar, weißt du, ob wir eine Möglichkeit hätten, dem Docker-Image die Berechtigungen auszusetzen, um das Linux-Benutzerpasswort zu ändern?
Für mich muss man das Raspberry Pi OS-Image, das wir bereitstellen, wie ein Produkt betrachten, das wir im Einzelhandel verteilen, für ein Publikum, das nur Gladys nutzen möchte, steckt den Pi ein und fasst ihn nicht mehr an. 90% der Benutzer werden sich nie per SSH bei Gladys anmelden.
Daher, wenn wir sicherstellen wollen, dass es für alle von Anfang an sicher ist, sollten wir Gladys das Linux-Passwort beim ersten Booten ändern lassen und das Passwort dem Benutzer in der UI anzeigen (der Benutzer könnte das Passwort auch in der UI ändern). Daher müsste der Gladys-Container die Berechtigungen dafür haben.
Was denkst du?
Oder das Raspberry Pi-Image ändert selbst das Passwort und zeigt Gladys beim Start das neue Passwort an. Ich weiß nicht