Changes between Version 15 and Version 16 of LtspServerUpdate

Timestamp:

Oct 23, 2012, 4:11:36 PM (14 years ago)

Author:

Rüdiger Kupper

Comment:

Hinweise zum Client-Upgrade

LtspServerUpdate

@@ -27 +27 @@
 
 
-== Release-Upgrades ==
+== Release-Upgrades des Servers ==
 
 Unser Ziel ist es, den halbjährlichen Zyklus der Edubuntu-Updates mitzumachen. Release-Upgrades der LtspServer müssen in einer längeren schulfreien Phase erfolgen, weil dabei (kleinere) unerwartete Effekte auftreten können, die zunächst die Funktion des LTSP-Systems beeinträchtigen.
@@ -153 +153 @@
 == Release-Upgrade der Client-Images ==
 
+ Hinweis: :: Vor dem Upgrade, egal mit welcher Methode, sollte man unbedingt die Datei lts.conf aus /var/lib/tftpboot/ltsp/i386/lts.conf sichern. Sie sollte zwar nicht überschrieben werden, aber sicher ist sicher.
 
-Der Update kann mit Hilfe des Update-Helpers `do-release-upgrade` erfolgen, auch wenn im LTSP-Manual empfohlen wird, die Client-Chroot jedes Mal neu zu erzeugen. Meine Erfahrungen damit sind aber gut.
+=== do-release-upgrade ===
+Das LTSP-Manual empfiehlt, die Client-Chroot jedes Mal neu zu erzeugen. In einigen Fällen habe ich aber gute Erfahrungen gemacht, die Client-chroot mit Hilfe des Update-Helpers `do-release-upgrade` zu aktualisieren.
+
+Das hat z.B. bei Oneiric und Precise gut funktioniert, bei Quantal allerdings nicht.
 
  Hinweis: :: Beim Upgrade mittels `do-release-upgrade` wird das Paket `ltsp-client` entfernt, das natürlich wieder nachinstalliert werden muss!
 
-TODO
+=== ltsp-create-client ===
+Mit diesem Skript erzeugt man eine neue Client-chroot. Im zugehörigen Config-File sollte stehen, dass für die Architektur i386 erzeugt werden soll.
+
+Das Skript lädt die Pakete frisch herunter, daher muss $http_proxy für den Nutzer root passend gesetzt sein.
+
+Der Vorteil dieser Methode ist, dass man eine "saubere" Client-chroot erhält. Der Nachtil ist, dass man die manuellen Anpassungen, die wir in der Chroot vorgenommen haben, auch von Hand wiederherstellen muss.
+
+Das betrifft u.a.:
+
+==== Kepler-Logo ====
+(siehe oben)
+
+==== ssh-Server ====
+Auf den clients soll ein ssh-Server laufen, damit wir sie remote herunterfahren können. Der Schlüssel von root muss in den authorized-keys gelistet sein.
+
+==== root-Account ====
+Auf den Clients muss der Login als root möglich sein, zum Debugging und ebenfalls für das shutdown-Skript.
+
+TODO: (weiteres?)
 
 ----