Update der LtspServer und der LtspClients

Die Software unserer Klassenraum- und Schülerrechner soll auf aktuellem Stand gehalten werden, um den Nutzern ein modernes und produktives System zu bieten. Gleichzeitig soll das System stabil sein, um den täglichen Betrieb (insbesondere von WebUntis) zu gewährleisten.

Als Systemadministratoren müssen wir also die (unmögliche) Aufgabe bewältigen, unser LTSP-System im laufenden Betrieb aktuell und gleichzeitig stabil zu halten.

Laufende Server-Updates

Updates können im laufenden Betrieb über den üblichen Mechanismus erfolgen:

linadmin> sudo apt-get update
linadmin> sudo apt-get dist-upgrade

Die Server sollten jedoch während des Unterrichtsbetriebes nicht neu gebootet werden, weil dazu die jeweiligen LtspClients heruntergefahren würden, an denen möglicherweise Benutzer angemeldet sind.

Die Images der LtspClients werden durch diese Updates nicht beeinflusst und müssen einzeln upgedatet werden (s.u.).

Laufende Client-Updates

TODO

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.

In jedem Fall ist vor dem Release-Upgrade eine vollständige Systemsicherung der LtspServer durchzuführen! (Siehe LtspServerBackup.)

Es ist damit zu rechnen, dass nach einem Release-Upgrade zunächst kein Login an den LtspClients möglich ist. Die Ursachen lassen sich aber meist schnell beheben.

Bekannte Probleme

In diesem Abschnitt wird dokumentiert, welche Probleme bei Release-Upgrades früher bereits aufgetreten sind, und wie sie gelöst werden.

GRUB

Die GRUB-Konfiguration der Server wird während des Updates möglicherweise überschrieben. Siehe LtspServerGrub.

NBD

Die Konfiguration des Network-Block-Device-Servers (nbd-server) wird beim Update des LTSP-Paketes möglicherweise überschrieben. Über NBD werden die Images der LtspClients verteilt.

Die Konfigurationsdatei sollte bei einem Aufruf von ltsp-update-image automatisch richtig neu erzeugt werden.

Falls nicht: Die Konfiguration steht im Verzeichnis /etc/nbd-server/. Sie besteht aus dem geneerischen Teil in config und dem Image-spezifischen Teil unter config.d/. Dort müssen die Client-Images als NBD-Devices eingetragen werden. Die Konfiguration sieht typischerweise so aus:

/etc/nbd-server/config:

[generic]
# If you want to run everything as root rather than the nbd user, you
# may either say "root" in the two following lines, or remove them
# altogether. Do not remove the [generic] section, however.
        user = nbd
        group = nbd
        includedir = /etc/nbd-server/conf.d

# What follows are export definitions. You may create as much of them as
# you want, but the section header has to be unique.

/etc/nbd-server/conf.d/ltsp_i386.conf:

[ltsp_i386]
exportname = /opt/ltsp/images/i386.img
readonly = true

Inet-Daemon

Die Konfiguration des Internet-Superservers (inetd) wird beim Update möglicherweise überschrieben. Der inetd horcht an den konfigurierten TCP-Ports und startet bei bedarf die entsprechenden Internetdienste, um die Anfragen zu bearbeiten. Für LTSP sind die TCP-Dienste ldminfod, nbdswapd und nbdrootd nötig und müssen hier konfiguriert werden. Die Konfiguration sieht typischerweise so aus:

/etc/inetd.conf:

# /etc/inetd.conf:  see inetd(8) for further informations.
#
# Internet superserver configuration database
#
#
# Lines starting with "#:LABEL:" or "#<off>#" should not
# be changed unless you know what you are doing!
#
# If you want to disable an entry so it isn't touched during
# package updates just comment it out with a single '#' character.
#
# Packages should modify this file by using update-inetd(8)
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
#:INTERNAL: Internal services
#discard                stream  tcp     nowait  root    internal
#discard                dgram   udp     wait    root    internal
#daytime                stream  tcp     nowait  root    internal
#time           stream  tcp     nowait  root    internal

#:STANDARD: These are standard services.

#:BSD: Shell, login, exec and talk are BSD protocols.

#:MAIL: Mail, news and uucp services.

#:INFO: Info services

#:BOOT: TFTP service is provided primarily for booting.  Most sites
#       run this only on machines acting as "boot servers."

#:RPC: RPC based services

#:HAM-RADIO: amateur-radio services

#:OTHER: Other services
#<off># sane-port       stream  tcp     nowait  saned:saned     /usr/sbin/saned saned

9571    stream  tcp nowait  nobody /usr/sbin/tcpd /usr/sbin/ldminfod

Flash-Plugin

Siehe #570 und #655: Das Flash-Plugin wird bei der Installation jenseits von APT heruntergeladen. Das scheitert bei uns am nicht gesetzten Proxy.

Manuelles Nachinstallieren auf den LTSP-Servern

sudo -s
export http_proxy=http://10.32.1.253:3128/
export https_proxy=https://10.32.1.253:3128/
apt-get install --reinstall flashplugin-installer
exit

Manuelles Nachinstallieren in den Client-Chroots

sudo ltsp-chroot -a i386 -dp
export http_proxy=http://10.32.1.253:3128/
export https_proxy=https://10.32.1.253:3128/
apt-get install --reinstall flashplugin-installer
exit
sudo ltsp-update-image

Zu entfernende Pakete

Folgende Pakete sollten nach einem Release-Upgrade entfernt werden, weil sie in unserer Umgebung keinen Sinn ergeben bzw. unerwünscht sind:

# sudo apt-get purge  deja-dup empathy
# sudo apt-get autoremove

Release-Upgrade der Client-Images

Achtung

Vor dem Upgrade, egal mit welcher Methode, sollte man unbedingt die Datei lts.conf aus /var/lib/tftpboot/ltsp/i386/lts.conf ins svn einchecken: source:keplertools/LTSP-setup/trunk/. Sie sollte zwar nicht überschrieben werden, aber sicher ist sicher.

Außerdem sollte in jedem Fall die aktuelle Client-Chroot in /opt/ltsp/i386 gesichert werden, bevor man einen Update versucht! Nach erfolgreichem Update kann die Sicherheitskopie wieder entfernt werden:

sudo mv /opt/ltsp/i386/ /opt/ltsp/i386-backup

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!

ltsp-build-client

Mit diesem Skript erzeugt man eine neue Client-chroot.

Vorarbeit

Diese Dokumentation geht davon aus, dass unser svn-repository source:keplertools/LTSP-setup/trunk/ ausgecheckt wurde nach /root/LTSP-setup. Also:

# svn checkout svn+ssh://paedml/srv/svn/keplertools/LTSP-setup/trunk/ /root/LTSP-setup

bzw.

# svn update /root/LTSP-setup

Neue Client-Chroot erzeugen

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. Das Skript enthält auch die Pakete, die bei uns zusätzlich installiert werden sollen. Es ist auch im svn eingecheckt unter source:keplertools/LTSP-setup/trunk/. Die Config-Dateien können also direkt aus unserer ausgecheckten SVN-Kopie verlinkt werden:

# ln -s /root/LTSP-setup/ltsp-build-client.conf /etc/ltsp/
# ln -s /root/LTSP-setup/ltsp-update-image.conf /etc/ltsp/

Überprüfen mit:

# less /etc/ltsp/ltsp-build-client.conf

Dann Clientumgebung erzeugen mit:

# ltsp-build-client --http-proxy=http://10.32.1.253:3128 --prompt-rootpass

im Lehrernetz lautet der Proxy anders:

# ltsp-build-client --http-proxy=http://129.143.4.2:8080 --prompt-rootpass

Der Vorteil dieser Methode ist, dass man eine "saubere" Client-chroot erhält. Der Nachteil ist, dass man die manuellen Anpassungen, die wir in der Chroot vorgenommen haben, auch von Hand wiederherstellen muss.

Das betrifft u.a.:

Kepler-Logo

In unserer lts.conf wird das LDM-Thema "kepler" angefordert. Dieses Thema wird folgendermaßen eingerichtet:

• /opt/ltsp/i386/usr/share/ldm/themes/ enthält die Themen
• dort wird ein Verzeichnis kepler erzeugt, das identisch mit dem aktuellen (Edubuntu-)LDM-Themenverzeichnis sein sollte.
• Lediglich die Datei logo.png, wird durch unser Logo ersetzt. Die Dateien liegen im svn unter source:keplertools/LTSP-setup/trunk/client-chroot/logos/)

Weitere Informationen siehe ​https://help.ubuntu.com/community/UbuntuLTSP/LDMThemeChange.

Also:

# ltsp-chroot -a i386 -dp
## cd /usr/share/ldm/themes/
## cp -r default/ kepler
## exit
# cp /root/LTSP-setup/client-chroot/logos/*.png /opt/ltsp/i386/usr/share/ldm/themes/kepler/
# ltsp-chroot -a i386 -dp
## cd /usr/share/ldm/themes/kepler
## rm logo.png
## ln -s logo-kepler-<hostname>.png logo.png
## exit

root-Account

Auf den Clients muss der Login als root möglich sein, zum Debugging und ebenfalls für das shutdown-Skript. Wurde bei ltsp-build-client die Option --prompt-rootpass verwendet, so sollte automatisch ein Passwort abgefragt werden. Sonst manuell nachholen.

Lokale Skripte

Lokale Skripte, die in der Clientumgebung benötigt werden, finden sich im SVN-Repository source:keplertools/LTSP-setup/trunk/client-chroot/usr-local-sbin/. Sie müssen in das Verzeichnis /usr/local/sbin der Clients ausgecheckt werden.

Es handelt sich z.B. um die nötigen Cronskripte für das automatische Ausloggen und Herunterfahren der Clients.

# rmdir /opt/ltsp/i386/usr/local/sbin/
# svn checkout svn+ssh://paedml/srv/svn/keplertools/LTSP-setup/trunk/client-chroot/usr-local-sbin/ /opt/ltsp/i386/usr/local/sbin/

(ssh-Schlüssel)

(Hinweis

Derzeit ist kein ssh-Login auf laufenden Clients nötig und möglich, siehe #1059.)

(Auf den clients soll ein ssh-Server laufen, damit wir sie remote herunterfahren können. Das Paket "ssh" ist bereits in /etc/ltsp/ltsp-build-client.confals zu installierendes Paket eingetragen. Der Schlüssel von root muss aber noch in den authorized-keys gelistet sein (TODO).)

Epoptes-Client

Der Epoptes-Client ist in /etc/ltsp/ltsp-buid-client.conf als zu installierendes Paket eingetragen. Er muss nach dem Erzeugen der Clientumgebung noch konfiguriert werden:

1. Unser derzeitiges Setup verwendet ltsp6 als "Ausgezeichneten Epoptes-Server": Alle Clients sollen eine Verbindung mit dem Epoptes-Daemon auf ltsp6 herstellen, nicht mit dem auf ihrem jeweiligen Server. Hierzu ist ein Eintrag in /etc/default/epoptes nötig, und zwar sowohl in der Client-Chroot, als auch auf dem LtspServer selbst (letzteres ist nicht offensichtlich).

Hinweis

Verbinden mit dem ltsp6 funktioniert natürlich nur für die LtspServer im Schülernetz. Für die Lehrernetzserver ist derzeit kein Epoptes-Server festgelegt.

Also:

1. # emacs -nw /opt/ltsp/i386/etc/default/epoptes-client
   

   folgende Zeile einfügen:

   SERVER=ltsp6
   

2. # emacs -nw /etc/default/epoptes-client
   

   folgende Zeile einfügen:

   SERVER=ltsp6
   

1. Dann müssen die ssh-Zertifikate, die Epoptes für die SSH-Verbindung verwendet, vom Server in die Client-Chroot kopiert werden. Das geschieht mittels:

   # ltsp-chroot -a i386 -dp
   ## epoptes-client -c
   ## exit
   

Output überprüfen, es sollte bestätigt werden, dass das Zertifikat von ltsp6 geholt wird.

Local Apps und angepasste Starter

Einige Anwendungen müssen eventuell als local apps laufen, momentan betrifft das nur guvcview für die Dokumentenkameras. Diese Anwendungen müssen in der Client-Chroot installiert werden.

Möglicherweise haben die Anwendungen angepasste Starter, wie unser source:keplertools/LTSP-setup/trunk/client-chroot/guvcview.desktop. Die müssen an die geeignete Stelle in der Client-Chroot kopiert werden (hier: /usr/share/applications/)

# cp /root/LTSP-setup/client-chroot/guvcview.desktop /opt/ltsp/i386/usr/share/applications/

TODO: (weiteres?)

ltsp-update-image

Zum Schluss das Clientimage neu erzeugen:

# ltsp-update-image

---

Die Inhalte dieser Wiki-Seite erscheinen, (wo anwendbar und nicht anderweitig angegeben), unter einer Creative-Commons-Lizenz CC BY NC SA 3.0 Germany. Urheber: Dr. Rüdiger Kupper.