Software auf die neuen LTSP-Server bringen

[Rüdiger Kupper]

Vorgehen

Hier bieten sich spontan zwei mögliche Vorgehen an:

1. Wenn die Server die gleiche Architektur wie die bestehenden haben:
   • Minimalinstallation der Server durchführen (z.B. Paket ubuntu-minimal)
   • ssh-Paket installieren
   • mittels rsync die Komplettinstallation eines der existierenden Server auf den neuen übertragen

Stolperfallen: Danach die Dinge wieder anpassen, die auf dem neuen Rechner individuell sein müssen, etwa einen individuellen ssh-host-key, individuellen hostnamen, etc.

2. Neuinstallation der gleichen Paketstruktur:
   • Minimalinstallation der Server durchführen (z.B. Paket ubuntu-minimal)
   • debfoster- und ssh-Paket installieren
   • keepers-File von einem der existierenden Server übertragen (oder aus dem svn holen)
   • mittels debfoster -f die gleichen Pakete installieren, wie auf den existierenden Servern
   • nach Einrichten der Client-Chroot-Umgebung dort ebenfalls defoster installieren, das keepers-File aus einer existierenden Client-Chroot-Umgebung kopieren und mit defoster -f die gleichen Pakete installieren.

Stolperfallen: alles, was nicht in den Paketen enthalten ist, muss von Hand installiert werden, z.B. das Shutdown-Skript, unsere angepasste lts.conf, etc. Das wird natürlich einfacher, wenn diese Sachen in einem svn-Repository liegen, vgl. #17.)

Hinweise

• Den Vorgang dokumentieren wir am besten im Wiki: LtspServerAufsetzen. (Die Seite ist noch zu schreiben)
• Dieser Vorgang lässt sich gut automatisieren. Hierfür sollte es ein Skript geben, mit dem man einen neuen Server automatisiert aufziehen kann.

[Rüdiger Kupper]

Werde den Vorgang jetzt entwerfen: --> LtspServerAufsetzen.

[Rüdiger Kupper]

Hallo Jens,

lies Dir doch bitte mal die Schritte auf der Seite LtspServerAufsetzen durch und sag mir, ob das so gehen kann. Insbesondere: Fallen Dir noch weitere Dateien ein, die beim Rüberziehen des Systems ausgeschlossen werden müssen?
(Direkter Link von extern: ​http://paedml.kg-fds.de/trac/wiki/LtspServerAufsetzen)

Danke!
Bin mal sehr gespannt, ob's klappt. Wann hättest Du Zeit, die Server aufzusetzen?

[Rüdiger Kupper]

Bin grade dabei, ein Skript zur automatischen Installation aufzusetzen.

[Rüdiger Kupper]

Zwei Fragen:

1. Die LTSP-Server haben statische IP-Adressen in /etc/network/interfaces eingetragen. Soll das so bleiben? Warum beziehen die ihre Adressen nicht über DHCP?
2. Welche IPs sollen die drei neuen Server bekommen?

Antworten:

1. Klar können wir das auf DHCP umstellen, wir haben ja einen im Netzwerk (auf dem paedml), wenn der aber ausfällt habe ich gedacht wäre bei einem Server statisch besser - ich denke, wir lassen das so - oder?

2. Die IP-Vergabe bei den alten Servern war recht unglücklich - ich denke, wir sollten die IP's neu vergeben - vielleicht die Raumnummern (also 10.32.1.118 - 10.32.1.126 - 10.32.1.138 und 10.32.1.145) Bei denen in 128 dann also 10.32.1.128 ..129 ..130 ?

[Rüdiger Kupper]

Und:

3. Welche Hostnamen sollen die Clients bekommen?

[Rüdiger Kupper]

On Thu, 2011-08-25 at 12:52 +0200, Jens Baumgärtner wrote:

Nein, dem ist nicht so.
Die Maschinen haben wie besprochen jeweils eine Platte mit 322 GB
Wir hatten gesagt, dass bei einem Ausfall ja genügend Backups da sind.

Oh, ich Depp! Na klar, hatten wir ja drüber gesprochen. Also gut, dafür weiß ich jetzt, wie mein ein LVM-über-RAID1 von Hand aufsetzt. Habe viel gelernt in den letzten Tagen ;-).

Was ich jetzt noch wissen muss, ist, welche statischen IPs die neuen Server und Clients bekommen sollen:

Bisherige Server

• LTSP-Server: 10.32.1.{248,249,250,247}
• Rembo : 10.32.1.252

Bisherige Clients

• die Arbeitsstation ASx hat 10.32.200.<x>
  (bisher existierem AS1, AS2 und AS5)
• die Klassenraumrechner haben 10.32.200.<Raumnummer>
  (erste Raumnummer: 110, letzte: 149)

Vorschlag

• Bei den Servern gehen wir ab 10.32.1.246 ABWÄRTS
• Bei den Clients: ???
  Sollen vielleicht alle Raum-128-Clients in ein gemeinsames Subnetz 10.32.128.<laufende-nummer>?

Grüße,
Rüdiger

Vorschlag ist OK, sollen wir die IP's der alten Server so belassen? Oder vielleicht doch aufsteigend sortieren?

Für die Clients ist ein eigenes Subnetz sicherlich sinnvoll. Wir können ja den gesamten Bereich 10.32.X.X ausschöpfen, da hat es noch genug Platz. Ich hatte bislang die Server halt in 10.32.1.X und alles andere raumbezogen.

[Rüdiger Kupper]

Hallo Jens,
das Rüberziehen des Systems hat super funktioniert, aber diese Probleme sind aufgetreten:

• Das Netzwerk-Device der neuen Server heißt "eth1" statt "eth0". Woran liegt das? Haben die Rechner zwei Netzwerkinterfaces? Wenn ja, was ist das zweite?
• Ich kann mich vom neuen Server aus nicht am paedml einloggen: Service denied. Von den alten Servern aus geht's. Ich überschau gerade nicht, woran das liegt, aber Dir fällt's bestimmt ein :-)
• Vermutlich damit zusammenhängend: LDAP scheint auf den neuen Servern nicht zu funktionieren, d.h. man kann sich bisher nur lokal als linadmin anmelden, nicht als ein LDAP-User. Daher ist zur Zeit noch kein sinnvoller Serverbetrieb möglich.
• Die Clients booten beim Startup Linbo über's Netz. Ich weiss nicht, ob das nur der Fall back ist, solange die MAC nirgends eingetragen ist. Den Linbo-Abschnitt in der dhcpd.conf hab ich mir noch nicht näher angeschaut.

[Rüdiger Kupper]

• Die Clients booten mein Startup Linbo über's Netz.

Tippfehler, sollte natürlich heißen: Sie booten beim Startup Linbo über's Netz.

[bau]

Replying to kup:

Hallo Jens,
das Rüberziehen des Systems hat super funktioniert, aber diese Probleme sind aufgetreten:

• Das Netzwerk-Device der neuen Server heißt "eth1" statt "eth0". Woran liegt das? Haben die Rechner zwei Netzwerkinterfaces? Wenn ja, was ist das zweite?

Nein, das liegt an Ubuntu, der schreibt in /etc/udev/rules.d/70-persistent-net.rules die MAC-Zuordnung zu ethX rein. Diese Datei muss auf dem neuen Server gelöscht werden, dann tut alles!

• Ich kann mich vom neuen Server aus nicht am paedml einloggen: Service denied. Von den alten Servern aus geht's. Ich überschau gerade nicht, woran das liegt, aber Dir fällt's bestimmt ein :-)

das liegt an der Firewall der paedml. Da habe ich an der Datei /etc/init.d/linuxmuster-base einige kleine Änderungen vorgenommen. Wenn du die Datei mit mc -e öffnest, kommst du derzeit genau an die Stelle. Anschließend muss die Firewall neu gestartet werden:

/etc/init.d/linuxmuster-base restart

• Vermutlich damit zusammenhängend: LDAP scheint auf den neuen Servern nicht zu funktionieren, d.h. man kann sich bisher nur lokal als linadmin anmelden, nicht als ein LDAP-User. Daher ist zur Zeit noch kein sinnvoller Serverbetrieb möglich.

genau: firewall freischalten

• Die Clients booten beim Startup Linbo über's Netz. Ich weiss nicht, ob das nur der Fall back ist, solange die MAC nirgends eingetragen ist. Den Linbo-Abschnitt in der dhcpd.conf hab ich mir noch nicht näher angeschaut.

Ja, dass ist der default-fall. Erst wenn du einen eigenen Abschnitt in der 7etc/dhcp3/dhcpd.conf und eine eigene Config-Datei für den Server erstellt hast (DHCP natürlich neu starten) bootet der vom neuen Server

[Rüdiger Kupper]

Ah, super, das sollte die Probleme lösen, danke!

[Rüdiger Kupper]

Die neuen Server laufen, die Clients in Raum 128 booten. Es sind noch kleinere Sachen zu fixen, dafür lege ich Folgetickets an.