Fahrplan Serverupdate

[Rüdiger Kupper]

Der Sync der Platte im proxmoxpaedml ist jetzt auch druch.
Wir müssen heute dann zuerst mal

• Dienste, die was verändern können anhalten (Mail, Apache, WebUntis, ...) -> vorher Kollegen informieren
• eventuell den Kontakt des paedml nach außen einschränken (Portweiterleitungen auf ipFire / proxmoxS stoppen)
• Sekundensnapshot auf dem proxmoxpaedml zur Sicherheit, ich habe gerne eine Lebensversicherung :-)
• Update auf 6.1
• Anpassungen an den Clients?

[bau]

Prima:
LVM mit zusätzlicher Platte versorgt - damit Snapshot ohne Problem erzeugt

ToDo

• Snapshot beenden
• Tauschlaufwerke in Clients einbinden (Bind-Mounts entfallen in linuxmuster.net 6.1)
• import_workstations ergänzen um ltsp_client Script

[bau]

Problem:
Nach dem Update sind die OpenVPN-Zertifikate der User auf dem ipFire weg. Ich denke, die kann man aus den .p12-Dateien in den OpenVPN-Verzeichnissen der User wiederherstellen -> komisch.

Ich habe mir ein neues gemacht, dann klappt der OpenVPN wieder aber die Push-Route

  route add -net 10.32.0.0/12 gateway 172.16.34.X

fehlt bei mir, so dass ich zwar das Gateway anpingen kann, nicht aber den paedml, wenn ich die Route von Hand eintrage, dann tut es -> prüfen.

[bau]

Problem mit der fehlenden Route habe ich mit einer zusätzlichen Zeile in der

   ipfire: /var/ipfire/ovpn/server.conf

   push "route 10.32.0.0 255.240.0.0"

behobe, damit wird dem Client die Rote ins grüne Netz gespusht.
Bei uns fehlt diese Regel, da die davon ausgehen, dass du per OpenVPN den gesamten Netzverkehr über den Tunnel jagst, das haben wir auf unseren Laptops aber abgestellt.

[bau]

MIST, auf dem IPFire liegen unter /var/ipfire/ovpn/certs für jeden Benutzer immer das .p12 und ein .pem (ich vermute mal der public-key). Man kann zwar aus dem .p12 das .pem per openssl machen, dazu braucht man dann aber das Passwort für das .p12-File.
Ich habe die Befürchtung, dass wir entweder eine Sicherung der certs finden - oder alle Benutzer müssen sich das OpenVPN-Zertifikat nochmals anlegen :-(

Bemerkung: Wir haben zwar den paedml mehrmals redundant gesichert nicht aber den IPFire!

[Rüdiger Kupper]

Ausgelagert in eigenes ticket:1816

Replying to bau:

MIST, auf dem IPFire liegen unter /var/ipfire/ovpn/certs für jeden Benutzer immer das .p12 und ein .pem (ich vermute mal der public-key). Man kann zwar aus dem .p12 das .pem per openssl machen, dazu braucht man dann aber das Passwort für das .p12-File.
Ich habe die Befürchtung, dass wir entweder eine Sicherung der certs finden - oder alle Benutzer müssen sich das OpenVPN-Zertifikat nochmals anlegen :-(

Bemerkung: Wir haben zwar den paedml mehrmals redundant gesichert nicht aber den IPFire!

[Rüdiger Kupper]

Ausgelegater in eigenes ticket:1817

Replying to bau:

• Snapshot beenden

[Rüdiger Kupper]

Ausgelagert in eigenes ticket:1818

Replying to bau:

• Tauschlaufwerke in Clients einbinden (Bind-Mounts entfallen in linuxmuster.net 6.1)

[Rüdiger Kupper]

Ausgelagert in eigenes ticket:1819

Replying to bau:

• import_workstations ergänzen um ltsp_client Script

[Rüdiger Kupper]

Alle Subtasks in eigene Tickets ausgelagert, gesammelt unter milestone:"Server-Update auf LML 6.1"

[bau]

Zu IPFire - an Sebastian mit der Bitte, das zu testen:

Ich habe mal probeweise das Zertifikat von Sebastian zurückgeholt:

   ssh ipfire
   cd /var/ipfire/ovpn/certs
   cp ../../backup/20141104-1500/var/ipfire/ovpn/certs/[benutzername]* ./
   cat ../../backup/20141104-1500/var/ipfire/ovpn/certs/index.txt | grep [benutzername] >> index.txt
   vi index.txt  *Seriennummer des Zertifikats anpassen*
   vi serial     *nächste Seriennummer anpassen*
   cd ..
   cat ../backup/20141104-1500/var/ipfire/ovpn/ovpnconfig | grep [benutzername] >> ovpnconfig
   vi ovpnconfig  *Seriennummer des Zertifikats anpassen*

Mal sehen, ob jetzt dem Sebastian sein OpenVPN-Zugang wieder gehen tut :-)

[bau]

Immer wieder taucht das Problem auf, dass nach einer Rechneraufnahme Parameter in der entsprechenden start.conf.Gruppe falsch gesetzt sind (besonders ärgerlich ist immer der Parameter AutoPartition = yes!)

Seit dem Update bringt linbo was nettes mit (siehe ​http://www.linuxmuster.net/wiki/dokumentation:techsheets:release61):

Einmal ausgeführte Onboot-Befehle mit linbo-remote

linbo-remote erhält einen neuen Parameter -p, der es ermöglicht eine Onboot-Befehlsliste mit linbo-remote-Befehlen für einen Client oder eine Clientgruppe zu erzeugen. Unter /var/linbo/linbocmd wird eine temporäre Onboot-Befehlsdatei nach dem Schema <IP-Adresse>.cmd erzeugt, die Linbo beim Start herunterlädt und abarbeitet bevor die Startseite erscheint. Nach dem Download wird die Datei auf dem Server entfernt, sodass der nächste Start des Clients wieder nach Standard abläuft.

[Rüdiger Kupper]

Klingt praktisch!

Am 31.03.2015 um 15:34 schrieb Kepler-Trac: