- Testserver ist da, wie sieht das Erstellen eines sinnvollen Testszenarios aus - kein zentraler Patchmanagementserver für Windows
- sysprep und Linbo geht nicht zusammen
- golden Images regelmäßig bearbeiten
Vorstellung Update Lnm
# Planung automatisierte Updates
## 1 Anforderungen
- am besten wird die Automatisierung an allen Schulen gleich oder mindestens sehr ähnlich umgesetzt
- Canary-Deployments, um Fehler zu finden, bevor sie an allen Schulen ausgerollt werden
- Monitoring für schief gelaufene Prozesse
- atomare Aktion: wenn es nicht klappt, wird automatisch auf das alte Image zurückgerollt
- Staffelung der Updates (ein paar Minuten Unterschied in Startzeit)
## 2 Status quo an neuen Schulen
- Image wird automatisiert auf die Rechner verteilt, funktioniert auch bei Notebooks über WLAN
- neue Images werden noch händisch kontrolliert
- auf den Rechnern sieht man das Datum der letzten Synchronisierung
- Notebooks können nicht per wake on LAN hochgefahren werden
- Software-Pakete zwischendurch aktualisieren: automatisierte Updates für einzelne Pakete aktivieren
- einzelne Pakete sind nicht unbedingt kompatibel mit aktueller Linuxmuster-Version
-
- Mehrschul-Installation ist noch nicht so weit
## 3 Umsetzung
- Unterscheidung bei Images zwischen Berufsschulen und anderen Schulen
- Berufsschulen brauchen viel mehr Software als normale Schulen, + Windows
- alle anderen Schulen sollen immer übergreifend die gleiche Software bekommen
### 3\.1 Prozesse
Die Prozesse haben an allen Schulen den gleichen Ablauf, aber es muss inhaltlich zwischen Berufsschulen und anderen Schulen entschieden werden. Es gibt also trotzdem zwei Prozesse, die auszusetzen sind.
#### **3\.1.1 Prozessvorschlag für Windows-Images**
**Prozessvorschlag**:
- einmal im Quartal neues Image mit neuer Version ausrollen mit Updates (manuell)
- müssten trotzdem regelmäßig über Linbo synchronisiert werden (automatisiert einmal die Woche am Wochenende) --> zurückgesetzt auf "Werkeinstellungen"
**Zusatzinfos:**
- Windows gibt es nur auf Festrechnern.
#### **3\.1.2 Prozessvorschlag für regelmäßiges automatisiertes Synchronisieren (Zurücksetzen) der Geräte** **(Berufsschulen und andere Schulen)**
- **\--> montags und mittwochs abends**
- einmaliges Informieren per Mail
**Prozessvorschlag**:
Cronjob oder automatisiertes Skript, was montags und mittwochs abends läuft:
1. alle Rechner werden angeschaltet und via Linbo-Befehl angewiesen, das genutzte Image mit der Kopie zu überschreiben (Zurücksetzen)
2. danach werden die Rechner wieder ausgeschaltet
#### **3\.1.3 Prozessvorschlag für regelmäßige automatisierte Updates** der **Linux-Images (Berufsschulen und andere Schulen)**
**Prozessvorschlag**
1. E-Mail an Schule schicken, dass zu Zeitpunkt x (wie immer) die Updates gemacht werden und die Rechner nicht verfügbar sind
2. Cronjob oder automatisiertes Skript, was jedes Wochenende läuft:
1. startet auf Proxmox eine virtuelle Maschine mit Image
2. Updates werden installiert und Prepare-Image-Befehl wird ausgeführt
3. Erstellen eines neuen Images mittels Linbo
1. Test: Test-VM auf Stadt-Server starten
2. E-Mail an DL mit Bericht
3. Abbruch bei Fehlern
4. Hochladen auf zentralen Stadt-Server (Hetzner-Server) - Mittwoch
5. Linuxmuster/Schul-Server holen sich das neue Image vom Stadt-Server --> ab jetzt haben alle Geräte in der Schule die Möglichkeit, sich das Image runterzuladen
6. alle Rechner werden angeschaltet und via Linbo-Befehl angewiesen, das neue Image runterzuladen, danach wieder ausgeschaltet
- vielleicht sollten nicht alle Rechner gleichzeitig vom Server runterladen? Wir probieren es erst mal, mit allen Rechnern gleichzeitig und staffeln es ggf. später
3. E-Mail an Schulen schicken, dass die Updates abgeschlossen sind
4. Montags: E-Mail zu Updatedurchführung vom Schul-Server (Cronjob) (Ergebnis der Kommandozeilen)
- E-Mail vom Cronjob muss an einen Verteiler für Standort-Admins (zweiter Schritt ggf. Integration in GLPI) --> alle (Standort-Admins und DL) gucken Montag morgens in die E-Mail, entscheiden, welche Aufgabe sie übernehmen können und informieren alle anderen (Verteiler), welche Aufgaben sie nehmen
**Zusätzliche Informationen:**
- Wenn die Automatisierung gut funktioniert, können wir die Intervalle verkürzen.
- Stadt-Server auf Hetzner
- zentrale Stelle zum Austeilen der Images
- komplette Linuxmuster-Installation (für Tests und Installation neuer Software)
- zentraler Server ist sinnvoll, weil damit sicherstellen können, dass alle Schulen von der gleichen Quelle das Image ziehen können, kann für alle zentralen Dienste, die es in Zukunft geben wird, nutzen; technisch sinnvollste Umsetzung
- 60-80 € pro Monat
- Images sollten im Pull-Modus ausgeteilt werden, weil der Server sonst Schreibzugriff braucht und damit auch infizierte Software auf die Geräte gepushed werden würden
- Server sollten alle auf dem gleichen aktuellen Stand sein (halb automatisch)
- jede Schule hat einen Server
- Stadt-Server + VM mit Debian-Repo + VM zum Testen der Image-Updates
- Canary Deployments:
- Berufsschulen
- Phase 1: ein Kabinett an der Ovg
- Phase 2: alle anderen + restliche Kabinette an der Ovg
- andere Schulen
- Phase 1: ein Kabinett am Scholl-Gymnasium
- Phase 2: alle anderen + restliche Kabinette am Scholl-Gymnasium
#### **3\.1.4 Prozessvorschlag für Auslieferung neuer Software** mit den **Linux-Images**
**Prozessvorschlag:**
1. manuell zweites Image mit zweiter Hardwareklasse erstellen (oder nur in zweiter Hardwareklasse direkt auf dem Rechner?)
2. Software auf dem Image installieren (jeden Schritt dokumentieren, in vorher definierten Ordner ablegen, damit es später beim Ausrollen mit ausgeführt werden kann)
3. Image auf Testrechner ausrollen
4. Anfordernde Person informieren und zum Testen aufrufen (mit Deadline)
5. Test ist erfolgreich: aktuelles Basisimage wird durch das Testimage ersetzt
6. \--> weiter mit Update-Prozess
**Zusätzliche Informationen:**
- Testphase vor Auslieferung
- zweites, unabhängiges Image, was nur auf bestimmten Rechnern ausgerollt wird, an denen dann getestet werden kann (zweite Hardwareklasse), darf nicht automatisch aktualisiert werden
- zweites Image muss möglichst nah am eigentlichen Image sein
- Wir gehen davon aus, dass wir den regelmäßigen Update-Zyklus nicht auf dem zweiten Image fahren müssen, da sich unserer Meinung nach durch die Updates nicht allzu viel ändert, was den Test verzerren könnte.
- zweites Image bleibt manueller Prozess
- Anforderer/Lehrer muss testen und Rückmeldung über GLPI geben
- Testrechner: Wir würden vorschlagen, dass es in den Schulen Testrechner gibt, auf denen man einerseits normal arbeiten kann ("Livesystem") und sich über eine zweite Hardwareklasse auch in ein "Testsystem" einloggen kann, um die neue Software zu testen.
- Lehrer müsste konkreten Rechner oder mehrere benennen, worauf man das zum Testen ausrollt
- Wie oft wird eine neue Software gefordert?
- am Anfang kommt viel neue Software dazu, nach einem halben Jahr kommt dann nicht mehr so viel
- wahrscheinlich wird ab jetzt nicht mehr so viel neue Software, die dringend benötigt wird, dazukommen
- Testen die Leute testen?
- gemischt
- Wenn die Leute nicht testen, können wir uns mit der Funktion, die Lehrer zum Überprüfen der Schüler während einer Prüfung nutzen, auf einen Rechner einwählen und remote testen. Dies setzt voraus, dass wir die Anforderungen verstanden haben.
- Wie häufig sollte man das Ausrollen neuer Software anbieten? Frederiks Vorschlag war einmal im Quartal.
- Ausrollen auf alle Rechner abhängig vom Update-Zyklus, wir legen uns nicht auf konkrete Daten fest
- Anforderung, neue Software zu installieren, muss mindestens zwei Wochen vor Ausrollen des nächsten Updates eingekippt werden
- Wie viele Testrechner sollte es geben? Einen pro Schule? Einen pro Kabinett/Raum? Einen pro Hardwaretyp? --> abhängig von Anforderung
- Weitere Planung
- Brauchen wir eine Interimslösung bis die automatisierten Updates laufen?
- die neuen Schulen laufen schon automatisierter
- wir sollten an den automatisierten Updates arbeite bevor noch mehr Schulen dazu kommen. Sonst müssen die Standort-Admins alle zwei Wochen in die Schulen fahren und alles updaten
- **@Kevin** To Dos laut anderer Protokolle:
- Update-Prozess-Doku bei fair comp erfragen
- Wie soll initOS an Updates beteiligt sein (beim Status quo)?
- Dokumentation dazu, wie alles aufgesetzt ist und zusammenarbeitet zur Verfügung stellen.
## 4 Weitere Schritte
1. technische Umsetzung skizzieren und schätzen (mit Admins zusammen besprechen)
2. extra Budget abholen
## 5 Weitere Vorschläge
- Lehrer\*innen dazu schulen, wie man das Synchronisieren anstößt
