InfoSys macht keine automatischen Updates

[bau]

Windows 7 hat auf C:\Program Files\ hohe Benutzerrechte.
Ich lade zwar mit wget das aktuelle InfoSys herunter, Windows sperrt die Änderung aber, so dass die alte Version wieder vorliegt.

Workaround:

• qemu-utils installieren (bitte ins nächste Image packen)
• modprobe nbd
• VDI bereitstellen mit qemu-nbd -s /dev/nbd0 /cache/Win7.vdi
• Partition 2 im VDI mounten mit mount /dev/nbd0p2 /mnt
• Neue Batchdatei reinkopieren: cp /home/teachers/bau/InfoSys.bat /mnt/Program Files/InfoSys
• umount /dev/nbd0p2
• qemu-nbd -d /dev/nbd0
• rmmod nbd

[bau]

Script muss wegen Timing-Problemen so aussehen:

modprobe nbd
sleep 1s
qemu-nbd -c /dev/nbd0 /cache/Win7.vdi
sleep 1s
mount /dev/nbd0p2 /mnt
sleep 1s
cp /home/teachers/bau/InfoSys.bat /mnt/Program\ Files/InfoSys/
umount /dev/nbd0p2
qemu-nbd -d /dev/nbd0
sleep 1s
rmmod nbd 

[bau]

rechner-lz-kup hat irgendwie Schwierigkeiten beim laden der cloops, das Win7.vdi lässt sich auf jeden Fall mal nicht mounten.

[bau]

Test im LZ: Die aktuelle WorkAround-Version lädt zuverlässig die InfoSys-Version 2019/1 herunter.

[Rüdiger Kupper]

Replying to bau:

rechner-lz-kup hat irgendwie Schwierigkeiten beim laden der cloops, das Win7.vdi lässt sich auf jeden Fall mal nicht mounten.

Stimmt, der andere Beta-Rechner (rechner-2-13) hat das gleiche Problem. Das .vdi scheint da zu sein, die VM läuft aber nicht (cannot read from Boot device). Muss ich klären.

[bau]

Leider funktioniert der Workaround nur, wenn das vdi nicht gleich anschließend wieder vom kepler--torrent korrigiert wird. Ich habe den Eintrag in der Start.conf jetzt erstmal unschädlich gemacht, damit wird die Noteneingabe möglich sein.

[Rüdiger Kupper]

Replying to bau:

Leider funktioniert der Workaround nur, wenn das vdi nicht gleich anschließend wieder vom kepler--torrent korrigiert wird. Ich habe den Eintrag in der Start.conf jetzt erstmal unschädlich gemacht, damit wird die Noteneingabe möglich sein.

Gut, die neue InfoSys.bat-Datei müsste also dauerhaft in das .vdi rein, oder? Dann brauchen wir ja eigentlich das veränderte .vdi nur von einem Rechner zurück auf den paedml zu kopieren, richtig?

[Rüdiger Kupper]

Replying to kup:

Replying to bau:

rechner-lz-kup hat irgendwie Schwierigkeiten beim laden der cloops, das Win7.vdi lässt sich auf jeden Fall mal nicht mounten.

Stimmt, der andere Beta-Rechner (rechner-2-13) hat das gleiche Problem. Das .vdi scheint da zu sein, die VM läuft aber nicht (cannot read from Boot device). Muss ich klären.

Ursache ist auch hier (ebenso wie beim nicht funktionierenden Drucker-Skript), der Nameservice, der von systemd zur Verfügung gestellt wird (systemd-resolved.service). Der ist seit Zesty Zapus (17.04) Teil von systemd und lief nun neben recolvconf, dnsmasq und Network-Manager -- und alle vier Dienste stellen DNS durch verschiedene Interfaces zur Verfügung. (Und alle wollen die /etc/resolv.conf verändern, doch dabei verstehen sie sich immerhin.)

"systemd-resolved" soll, so sagen sogar die Entwickler, eigentlich gar kein kompletter DNS-Dienst sein, sondern nur dafür sorgen, dass Nutzerprogramme Namen auflösen können, um ins Internet zu kommen.

Und hier gehen wohl die Probleme los: Je nachdem, welches Programm man verwendet, kann es verschiedene Interfaces benutzen und mit einem jeweils anderen DNS-Dienst sprechen: systemd-resolved, resolvconf, dnsmasq, NetworkManager. Die drei letzten reagieren wohl überwigend gleich, systemd-resolved aber nicht unbedingt. Beispielsweise verwaltet es getrennte DNS-Dienste für getrennte Zugänge (LAN, WLAN, WiFi, ...) und versucht herauszufinden, wie schnell die Nameserver antworten um dann immer den schnellsten zu nehmen. Das weicht deutlich von der Spezifikation ab.

systemd-resolved wird dafür sehr viel kritisiert, es erfüllt seinen Zweck auf Laptops für Einzelnutzer wohl recht gut, doch in größeren Netzwerken führt es anscheinend zu allerlei schwer zu debuggenden Problemen.

Das ist bei uns wohl auch passiert, beispielsweise betrifft das die Auflösung von Kurznamen. Beispiel:

• host paedml funktioniert, ebenso wie host paedml.kg-fds.de
• DOCH: dig +short paedml funktioniert *nicht*, dig +short paedml.kg-fds.de aber schon

Die beiden Tools verwenden verschiedene DNS-Interfaces. Weil in meinem "lehrernetz"-Skript der erste, kurze dig-Befehl steht, schlägt das nun also jedes Mal fehl. Daher startete der Torrent-Dienst nicht.

Maßnahmen: Ich habe versucht, möglichst immer und überall FQDNs zu verwenden, das wird ohnehin meist empfohlen. -> Skripte umgestellt, fstab umgestellt, Konfigurationen in /etc umgestellt.

Für die aktuelle Alpha-Version habe ich nun mal testweise resolvconf und dnsmasq entfernt. Dort gibt es also nur noch systemd-resolved und NetworkManager. Das ist die Variante, die man auch nach einer frischen Ubuntu-Installation hätte.

Läuft, allerdings tritt noch immer die race condition beim Boot auf (Netzwerk läuft, doch der DNS-Dienst noch nicht, NFS-Mount schlägt fehl).

Da ich keinen Weg finde, das zu lösen, werde ich wohl als nächstes ausprobieren, systemd-resolved zu deaktivieren (das wird allerorten emfpohlen) und wieder dnsmasq auf den Clients zu verwenden.

[bau]

Replying to kup:

Gut, die neue InfoSys.bat-Datei müsste also dauerhaft in das .vdi rein, oder? Dann brauchen wir ja eigentlich das veränderte .vdi nur von einem Rechner zurück auf den paedml zu kopieren, richtig?

Falls du dir die Mühe machen willst, das VDI auf den Server zurückzukopieren - OK.
Ich habe aktuell erstmal die start.conf verändert, so dass der torrent nicht mehr anläuft, da ich im VDI noch die Geschichte mit dem Aktivieren von Win7 lösen möchte. Außerdem lädt die InfoSys.bat im Moment nur die InfoSys.mde in der aktuellen Version herunter und nicht die module.mde, die leider statisch verlinkt in C:\Program Files\Infosys\ liegen muss. Da muss ich wahrscheinlich den Speicherort von InfoSys von C:\Program Files\Infosys\ ins User-Home umziehen :-(

I love Windoofs ;-)

[Rüdiger Kupper]

Replying to bau:

Falls du dir die Mühe machen willst, das VDI auf den Server zurückzukopieren - OK. Ich habe aktuell erstmal die start.conf verändert, so dass der torrent nicht mehr anläuft,

In der start.conf.lehrer? Was hast du da verändert? Da steht noch immer "#BaseImage? = Win7.vdi".

da ich im VDI noch die Geschichte mit dem Aktivieren von Win7 lösen möchte. Außerdem lädt die InfoSys.bat im Moment nur die InfoSys.mde in der aktuellen Version herunter und nicht die module.mde, die leider statisch verlinkt in C:\Program Files\Infosys\ liegen muss. Da muss ich wahrscheinlich den Speicherort von InfoSys von C:\Program Files\Infosys\ ins User-Home umziehen :-(

Dann machen wir das neue .vdi, wenn diese Sachen laufen.

I love Windoofs ;-)

:-)

[Rüdiger Kupper]

Der Torrent-Dienst für Win7.vdi scheint aber nicht mehr zu laufen, mein Betarechner versucht gerade vergeblich, das .vdi runterzuladen...
Hast Du den deaktiviert?

[Rüdiger Kupper]

Replying to kup:

In der start.conf.lehrer? Was hast du da verändert? Da steht noch immer "#BaseImage? = Win7.vdi".

Ach, verstehe, direkt im Cache.

[bau]

Ja, auf den Clients habe ich den ctorrent-screen geschlossen, in der Start.conf #B#aseImage=Win7.vdi reingechrieben und den patch ins VDI gepackt. Damit überstehen wir erstmal die Noteneingabe. Aktuell hat dein Rechner im LZ auch das vdi gezogen und hat nun InfoSys 2019/2 :-)

[Rüdiger Kupper]

Replying to bau:

Aktuell hat dein Rechner im LZ auch das vdi gezogen und hat nun InfoSys 2019/2 :-)

Richtig, darum habe ich mich gestern noch gekümmert. Problem war, dass sich mit systemd-resolved die Namensauflösung anders verhält und daher das "lehrernetz"-Skript abgestürzt ist. (Siehe comment:8)

Dabei fiel mir auf, dass der Bittorrent-Tracker auf dem paedml überhaupt nicht mehr lief. Wie es dazu kommen kann, weiß ich nicht. Habe den Dienst linbo-bittorrent neu gestartet und danach lief alles wie es soll.

Doch heute ist das Problem der gesperrten IPs zurück! Mein Admin-Rechner (rechner2-3-12, Schülernetz) ist heute morgen aufgewacht und hat ubuntu gebootet, doch jetzt ist er wieder nicht erreichbar.
Ich glaube, wir müssen doch genauer herausfinden, was hier schiefläuft, sonst stehen wir demnächst mit noch mehr Rechnern da, die nicht mehr erreichbar sind und dann haben wir ein Problem...

[bau]

Hast du getestet, ob das genau wie am Montag genau beim Starten des ctorrent passiert.
(Ich habe dem Testrechner eine neue IP verpasst, die Zuordnung der alten per dhcp_release gelöscht und den Rechner nach LINBO gebootet, das konnte ich auf dem paedml im log prima verfolgen, der Rechner ließ sich auch ständig anpingen - sobald ich auf den Sync+Start gedrückt habe, war die IP weg - ebenso in Ubuntu - sobald der kepler--torrent anlief, war die IP weg)

[bau]

Bitte in das Image aufnehmen: qemu-nbd!

[bau]

Wenn qemu-nbd noch nicht installiert

aptitude update
aptitude install qemu-utils
modprobe nbd
sleep 1s
qemu-nbd -c /dev/nbd0 /cache/Win7.vdi
sleep 1s
mount /dev/nbd0p2 /mnt
sleep 1s
cp /home/teachers/bau/InfoSys.bat /mnt/Program\ Files/InfoSys/
umount /dev/nbd0p2
qemu-nbd -d /dev/nbd0
sleep 1s
rmmod nbd 

[Rüdiger Kupper]

qemu-utils ist in Image.
Wie ist comment:17 gemeint, soll ich das machen oder hast Du das für Dich aufgeschrieben?
--> habe ich für mich zur Info reingeschrieben. Das muss letztendlich in ein Script, welches die VM managed

[Rüdiger Kupper]

@bau

Muss hier noch irgend etwas ins Gerhard-Image, bevor wir die finale Version ausrollen?

[bau]

Aktuell bin ich mit der neuen VM noch nicht soweit.
Beim Ausrollen sollte halt die Cachepartition nicht formatiert werden, da ich Anpassungen in der virtuellen Festplatte gemacht habe, die sollte halt erhalten bleiben.
Ganz wichtig: Auf dem rechner-lz-06 habe ich die neue virtuelle qed-Datei im Cache, diese darf auf keinen Fall verlorengehen!

[Rüdiger Kupper]

Wichtiger Hinweis, denn beim nächsten Syncen werden die Caches mit extfs formatiert! Also bitte Deine qed an einen sicheren Ort retten!!

[Rüdiger Kupper]

Dieses Ticket ist doch eigentlich erfolgreich erledigt, oder?