rechner2-3-12 hat zeitweile kein Netzwerk

[Rüdiger Kupper]

Rechner2-3-12 (mein Administrationsrechner in der Physik, Schülernetz) ist derzeit nicht erreichbar (no route to host).
Eben war ich dort und habe versucht, ihn neu zu starten:

• PXE-Prompt läuft durch
• Beim Versuch, GRUB vom Netzwerk zu booten, erschien dann aber "cannot determine boot server"

Nach einiger Zeit hat sich das Problem "von selbst" gelöst, dann ging der GRUB-Boot plötzlich wieder.
Bis ich hoch ins Lehrerzimmer gelaufen war, war das Problem wieder da, der Rechner ist jetzt wieder unerreichbar.

Arbeitest du gerade am Netzwerk, oder ist es mal wieder ein IP-Konflikt?

[bau]

Von der Art her scheint das eher ein IP Konflikt zu sein!

[Rüdiger Kupper]

Komischerweise erreiche ich ihn jetzt schon längere Zeit nicht mehr.
IP: 10.32.173.12

[Rüdiger Kupper]

Rechner läuft, ifconfig sieht auch normal aus (hat offenbar die richtige IP bekommen), doch ich komme von dort jetzt auch nirgends mehr hin (ping paedml -> unknown host).
Was hat der denn?

[bau]

Auf dem paedml kommt eine Anfrage an:

tail -f /var/log/syslog|grep dhcp
Jan  9 16:36:13 paedml dnsmasq-dhcp[6010]: DHCPOFFER(eth1) 10.32.173.12 d0:50:99:4d:56:db 
Jan  9 16:36:28 paedml dnsmasq-dhcp[6010]: DHCPREQUEST(eth1) 10.45.28.18 d0:50:99:4d:57:cb 

Nur bestätigt der Rechner selbst die Anfrage nicht und es erscheint folglich kein DHCPACK - oder es erscheint kurz und der Rechner fragt gleich nochmals an - komisch!

[bau]

Beim Reboot bekommt der Rechner eine IP vom Server, kann dann aber den TFTP-Server nicht erreichen.
Das Gleiche hatte ich letzte Woche an rechner-5-28-002.
Vielleicht ist wirklich die NIC kaputt?

[bau]

Ach nein, Ausweg war, dass ich dem Rechner einfach mal eine andere IP verpasst habe.
Irgendwer im Netzwerk hatte diese IP behindert.

OK, genauso ist es hier auch:
Nachdem ich dem Rechner eine andere IP verpasst habe (10.32.173.13) tut alles wie gewünscht.
Wer blockt hier im Netz seit Neuestem IP's???

[Rüdiger Kupper]

Sehr komisch! Das muss ja etwas sein, das letzte Woche neu aufgetreten ist.
Das einzige, was mir da einfällt ist, dass wir letzte Woche bereits existierende IPs zu neuen MACs zugeordnet haben.

Gibt es in unserem Netzwerk irgendwelche Bauteile, die eine Verbindung zwischen MAC und IP herstellen und diese dauerhaft speichern? Das könnten ja nur Level-3-Switche sein, oder eben der DHCP-Server selbst.

Ach nein, auch Level-2-Switche könnten dazwischenfunken: Die kümmern sich zwar nicht um die IP-Adressen, wohl aber, welche MAC auf welchen Ausgang am Switch geroutet wird (ARP).
Könnte es sein, dass wir die ARP-Tabellen unserer Switche generell mal löschen müssen?

[Rüdiger Kupper]

Heute gleiches Spiel auch mit der neuen IP-Adresse. Äußerst mysteriös!
Vielleicht doch Netzwerkkarte defekt?

[Rüdiger Kupper]

Mit dem langen Kabel zum Switch an der Decke und einer neuen IP scheint es jetzt tatsächlich zu funktionieren. Ich lasse den Rechner jetzt erstmal syncen. Morgen schauen wir dann, ob es noch immer läuft.
Und dann können wir den Gegentest machen: Wieder an die alte Dose anschließen (2.3 -- wohin führt die genau?). Falls das Problem dann wiederkommt, wissen wir, dass es auf diesem Weg liegt.

[bau]

Zum Test:

• Langes Kabel direkt in Dose stecken
• Langes Kabel auf Switch und dann von Switch zu Rechner
• Client direkt im Serverraum an den Port des Switches, (Patch-Panel-Port steht auf der Dose)

[Rüdiger Kupper]

@bau

Schlechte Nachrichten. Ich nehme mal stark an, Du warst heute Nachmittag nicht in der Physik und hast das Kabel umgestöpselt und wieder zurückgestöpselt?

Der Rechner lief seit gestern Nachmittag wie er soll, auch heute Vormittag war noch alles gut, man kam rein und raus, alles, wie es sein soll.
Heute nach dem Nachmittagsunterricht (etwa 16:00) habe ich mich von dort aus das letzte mal auf dem paedml eingeloggt, um den Torrent auf Lehrernetz umzustellen. Habe dann rechner-3-12 und rechner-lz-kup (beide Lehrernetz) gesyncht. Als ich danach zurück in die Physik kam, war rechner2-3-12 (Schülernetz) im bekannten Zustand: DHCP klappt, GRUB vom Netzwerk schlägt fehl (cannot locate Boot server). Das alles mit unverändertem Kabel am Deckenswitch, das für zwölf Stunden problemlos funktioniert hat.

[Rüdiger Kupper]

Habe heute probiert, zwei andere Schülerrechner mit dem aktuellen Image zu syncen (wollte überprüfen, ob es vielleicht mit dem aktuellen Zustand des Images zusammenhängt). Sie sind aber gar nicht bis zum syncen gekommen:
nach dem Aufwecken konnte ich sie für eine Weile anpinnen, dann hörte es auf. Eigentlich hätten sie nun nach Linbo booten sollen und dann wieder erreichbar sein. Beide haben sich aber nie mehr gemeldet.
Ev. geht es denen genauso wie dem Rechner in der Physik. In dem Fall wüssten wir, dass es Rechner im ganzen Schülernetz betreffen kann. Im Lehrernetz habe ich bislang nichts dergleichen beobachtet.

[bau]

Mist, was ist denn da los?
Ich dachte bislang an einen Einzelfall wegen einer defekten Leitung.
Nun haben wir es anscheinend mit einem generellen Defekt zu tun.

[bau]

Um welche Clients handelt es sich denn?

[Rüdiger Kupper]

On Sat, 12 Jan 2019 22:27:48 +0000, Kepler-Trac wrote:
>
>
>
1-10-01 und 1-10-02

[Rüdiger Kupper]

Rechnergruppe "schuelerbeta", die würde dann den aktuellen Stand des Gerhard-Images syncen, genau wie der Rechner in der Physik. Da sie gar nicht erst gesynct haben, kann es aber eigentlich nicht mit dem Image zusammenhängen.

[bau]

So ein Mist, die Rechner haben heute morgen gebootet, der NM zeigt auch die beiden Pfeile, aber nichts geht. Nach dem Ausstecken des Netzwerkkabels bekommen die auch keine IP mehr. Übliches Spiel:im Log finden sich zahlreiche DHCPREQUEST - DHCPOFFER - DHCPACK (alle 5Sek), aber der Rechner will sie nicht akzeptieren.

Im oberen PC Raum 5.28 war das Problem behoben, nachdem ich auf einen anderen Port umgestöpselt hatte. Außerdem habe ich dort neue Netzwerkkabel installiert. Ich werde nachher mal die Netzwerkkabel von rechnern-1-10-01 und 02 mit dem Messgerät testen und austauschen. Ebenso das lange NWKabel in der Physik.

Bei Conetis habe ich angefragt, ob die irgendwas mit checkMK an den Switchen umgestellt haben.

[Rüdiger Kupper]

Replying to bau:

So ein Mist, die Rechner haben heute morgen gebootet, der NM zeigt auch die beiden Pfeile, aber nichts geht. Nach dem Ausstecken des Netzwerkkabels bekommen die auch keine IP mehr. Übliches Spiel:im Log finden sich zahlreiche DHCPREQUEST - DHCPOFFER - DHCPACK (alle 5Sek), aber der Rechner will sie nicht akzeptieren.

Haben die denn das Gerhard-Image gesynct (gelbes Hintergrundbild)?

Im oberen PC Raum 5.28 war das Problem behoben, nachdem ich auf einen anderen Port umgestöpselt hatte. Außerdem habe ich dort neue Netzwerkkabel installiert. Ich werde nachher mal die Netzwerkkabel von rechnern-1-10-01 und 02 mit dem Messgerät testen und austauschen. Ebenso das lange NWKabel in der Physik.

Wäre schon sehr komisch, dass ausgerechnet die Rechner, die ich neu syncen wollte, ein defektes Kabel haben. Es scheint eher damit zu tun zu haben, ob man den Rechner syncen will. Denn alle anderen booten ja brav von der Platte.

Verstehen tue ich das aber nicht...

Bei Conetis habe ich angefragt, ob die irgendwas mit checkMK an den Switchen umgestellt haben.

[bau]

Nein, die haben nicht gesynct!
Ich habe dem 1-10-01 eine neue IP gegeben und dhcp_release gemacht.
Dann bekommt der Rechner eine IP und bootet problemlos den Grub und dann Ubuntu, Ubuntu erhält vom DHCP nochmals eine IP und dann ist er auch schon nicht mehr anpingbar.

[Rüdiger Kupper]

Dann wissen wir immerhin, dass es nicht mit dem neuen Image zusammenhängt. Auffällig ist, dass es nur Rechner betrifft, für die ich einen sync-Job abgesetzt habe, die also einmal Linbo vom Netz gebootet haben (bzw. booten sollten). Könnte das Problem bei Linbo liegen?

[Rüdiger Kupper]

Habe den Torrent-Dienst auf dem paedml neu gestartet und dem Physikrechner eine neue IP gegeben. Derzeit läuft er erst mal wieder. Mal sehen, ob es wieder auftaucht.

[bau]

Test an rechner-1-10-01:

• neue IP verpasst, dhcp_release
• PXE und Grub mehrmals problemlos
• LINBO problemlos
• LINBO [Sync&Start], ctorrent beginnt, bekommt nichts, IP ist weg (kein Ping mehr)
• neue IP verpasst, dhcp_release
• Ubuntu - hängt, IP ist gesperrt
• Ubuntu - kepler--torrents deaktiviert in /usr/local/sbin/kepler--torrents
• neue IP verpasst, dhcp_release
• Ubuntu bootet problemlos

Test am rechner-5-28-002:

• IP zurückgesetzt auf ursprüngliche .2
• Rechner läuft problemlos weiter

Nach einiger Zeit geben die cisco-Switche die IP wohl wieder frei.
ToDo:
IP von rechner-1-10-01 und rechner-2-3-12 wieder auf ursprüngliche IP zurücksetzen

[Rüdiger Kupper]

Alle Rechner haben jetzt wieder ihre alte IP und laufen (bisher) damit problemlos.

Sollte es wirklich ein fehllaufender Torrent-Dienst gewesen sein? Dann war die Lösung ja einfach (Dienst einmal komplett neu starten.)

Allerdings wissen wir noch immer nicht genau, was passiert ist. Ich habe gestern in den Logs des Torrentdienstes und von Linbo nach irgendwelchen Hinweisen gesucht, was da schief lief, aber ohne Ergebnis. Sah alles normal aus, keine ungewöhnlichen Anfragen, keine Fehler, ...

Es lief auf dem paedml auch definitiv nur ein einziger Torrent-Server für bionic-gerhard.cloop. Vom Lehrernetz aus konnte man auf den offenbar ja auch unproblematisch zugreifen -- der Lehrerrechner in der Physik und an meinem Arbeitsplatz liefen ohne Probleme mit dem neuen Image.

Nach wie vor wissen wir also nicht genau, was die Switche zum Abschalten der IPs veranlasst hat. Auch nicht, welcher Switch es eigentlich war.

Erst mal abwarten, ob das Problem dauerhaft weg ist.

[bau]

Nun, wir wissen SICHER, dass es der Torrent war, das habe ich gestern getestet, als ich in LINBO versehentlich auf den Sync+Start-Button geklickt habe, der CTorrent lief an, bekam nichts und gleich anschließend war die IP weg.

Wir hätten auch vorher schon draufkommen können. Im Log war Ubuntu mit der DHCP-Anfrage vertreten, dann kam der RSYNC der .torrent-Datei aus dem systemd-Job und dann ging nichts mehr. Eben wieder genau da, wo der ctrorrent anfing.

Ich glaube, das Interesse, was denn genau schieflief, ist eher akademisch. Falls sowas wieder mal vorkommt, wissen wir, dass wir den Torrent-Dienst neu starten müssen (oder aber, wie in 5.28: ein Netzwerkport auf dem Switch kaputt ist)

[Rüdiger Kupper]

Ich meine mich auch dunkel zu erinnern, dass ich mit dem Einzelstart eines Linbo-Torrents früher auch schon mal Probleme hatte und deshalb immer alle insgesamt neu gestartet habe. Das werde ich mir wohl wieder angewöhnen.

[Rüdiger Kupper]

Das Problem kehrt leider zurück, siehe comment:14:ticket:3072.

[Rüdiger Kupper]

Ich habe eben den torrent-Dienst auf rechner-1-10-32 gestartet und der Rechner ist weiterhin erreichbar.

[Rüdiger Kupper]

Okay: Der Tracker lief auch mal wieder nicht auf dem paedml. Ob er gerade da abgeschmiert ist, als ich den Dienst auf rechner-1-10-32 gestartet habe, weiß ich allerdings nicht.

-> Torrent-Dienst auf rechner-1-10-32 gestoppt
-> Bittracker auf paedml neu gestartet
-> Torrent-Dienst auf rechner-1-10-32 wieder gestartet
-> augenblicklich ist der Rechner nicht mehr erreichbar

:-( wenn ich nur verstehen würde, was da schief geht!

[Rüdiger Kupper]

Gleiches Spiel beim Versuch, rechner-1-10-31 per torrent zu syncen: Sobald der ctorrent startet, ist der Rechner nicht mehr erreichbar.

[Rüdiger Kupper]

Im Lehrernetz laufen die torrents problemlos.

[Rüdiger Kupper]

Das hier bringt uns vielleicht ein winziges bisschen weiter:

• kepler-torrents überall abgestellt, schueler, schueleralt, schuelerbeta, lehrer, lehrerbeta, admin. Es läuft nirgends mehr ein Torrent.
• Versuch, rechner-1-10-31 mit dem neuen Image zu syncen: Sobald Linbo den Torrent startet, wird die IP gesperrt (mehrmals mit neuer IP probiert)
• Versuch, mit neuer IP rechner-1-10-31 mit dem alten Image zu syncen: Klappt problemlos

=> Es liegt definitiv am Torrent des neuen Images.

16:54/0 paedml /var/linbo # ls -l xenial-falk-SRU1-win7.cloop.torrent bionic-gerhard.cloop.torrent
-rw-rw-r-- 1 root root 595110 Jan 28 16:08 bionic-gerhard.cloop.torrent
-rw-rw-r-- 1 root root 562277 Dez 22 13:55 xenial-falk-SRU1-win7.cloop.torrent

Das .torrent-File des alten Images wurde am 22. Dezember zuletzt verändert.
Hat sich seitdem etwas geändert?
Als nächstes probiere ich, die .torrent-Datei für das alte Image neu zu erzeugen, ob es auch damit geht.

[Rüdiger Kupper]

Das alte Image ist 6,9GB groß, das neue 7,3GB. Kann es an der Größe liegen?

[bau]

Warum sollte es dann im Lehrernetz funktionieren?

[Rüdiger Kupper]

Habe mit einem auf 6GB abgeschnittenen Image getestet: Gleiches Spiel.
An der Größe liegt es nicht.

[bau]

Ominös!
Das Einzige, was sich noch geändert hat seit dem letzten Image ist der Dateiname - oder gibt es da nochwas, was sich geändert hat?

[lehrer]

Tja, das wüsste ich auch gern!
Mein nächster Test wird sein, den Torrent für das Falk-Image einmal neu zu erzeugen und zu testen. Vielleicht liegt es daran. Wenn der dann normal funktioniert, fällt mir auch nichts mehr ein, außer dem Dateinamen…

[lehrer]

Wir haben es hier offenbar mit einem Heisenbug zu tun: Je genauer man hinschaut, um so weniger kann man ihn fassen ;-).

[Rüdiger Kupper]

Replying to lehrer:

Mein nächster Test wird sein, den Torrent für das Falk-Image einmal neu zu erzeugen und zu testen.

Okay, das ist wenigstens eindeutig:
Ich habe die .torrent-Datei für das alte Image neu erzeugt und versucht, einen Rechner damit zu syncen: Sobald der Torrent startet, wird die IP gesperrt.
Mit der alten .torrent-Datei klappt alles.

Offenbar hat sich beim Erzeugen der .torrent-Files etwas geändert!

[bau]

Komisch, da wir keinerlei Änderungen am bittorrent gemacht haben.
Die Torrent-Datei kann auch von ctorrent auf dem Client erzeugt werden:
​http://www.rahul.net/dholmes/ctorrent/userguide.html

Option: -t

[bau]

erweiterte Tests:

• rechner-1-10-31 gleichzeitig von rechner-1-10-29 und paedml angepingt, sobald der ctorrent unter Ubuntu gestartet wird, ist der Rechner nicht mehr vom paedml aus erreichbar, alle anderen Rechner können mit ihm kommunizieren (also auch ein ssh-Login ist möglich)!

• Kein Unterschied macht es, wo die torrent-Datei erzeugt wurde, ich habe es probiert mit
  • Original-Torrent-Datei (die, die sowieso Probleme macht)
  • einer Torrent-Datei, die ich unter LINBO erzeugt habe
  • einer Torrent-Datei, die ich unter Ubuntu erzeugt habe Problem tritt jeweils direkt beim Starten des ctorrent unter Ubuntu auf und immer nur vom paedml aus
    Die torrent-Dateien sind alle genau gleichgroß und enthalten identische Informationen

• rechner-1-10-30 hat noch das xenial-falk-Image.
  • ctorrent unter Ubuntu starten: kein Problem
  • torrent-Datei unter Ubuntu mit ctorrent neu erzeugt und ctorrent gestartet: kein Probem
  • nächster Test (nach dem Boot): torrent-Datei unter LINBO neu erzeugen

[Rüdiger Kupper]

Replying to bau:

erweiterte Tests:

• rechner-1-10-31 gleichzeitig von rechner-1-10-29 und paedml angepingt, sobald der ctorrent unter Ubuntu gestartet wird, ist der Rechner nicht mehr vom paedml aus erreichbar, alle anderen Rechner können mit ihm kommunizieren (also auch ein ssh-Login ist möglich)!

Sehr interessant! Wieder einen kleinen Schritt weiter. Das heißt vermutlich, alles, was diesseis des blockierenden Switches ist, erreicht den Rechner, nicht aber die hinter dem Switch. Kannst Du daraus schließen, welcher der Switche die IP blockt?

• Kein Unterschied macht es, wo die torrent-Datei erzeugt wurde, ich habe es probiert mit
  • Original-Torrent-Datei (die, die sowieso Probleme macht)
  • einer Torrent-Datei, die ich unter LINBO erzeugt habe
  • einer Torrent-Datei, die ich unter Ubuntu erzeugt habe

Habe ich mir auch überlegt, ich hatte ja die neue .torrent-Datei auch auf dem paedml mittels "btmakemetafile" erzeugt. Normalerweise erzeugt Linbo die ja per ctorrent-Aufruf.

Problem tritt jeweils direkt beim Starten des ctorrent unter Ubuntu auf und immer nur vom paedml aus

... oder von anderen Rechner, die sich "hinter" dem fraglichen Switch befinden? Gibt es da einen, von dem aus wir testen können?

Die torrent-Dateien sind alle genau gleichgroß und enthalten identische Informationen

Genau. Ich habe vorhin mal in Erfahrung gebracht, welches Format eine .torrent-Datei hat und wie man sie entschlüsselt. Mit einem kleinen Python-Skript habe ich mir angeschaut, was drin steht: Es sind tatsächlich genau die Informationen, die "btshowmetainfo" anzeigt, zuzüglich einer Liste von SHA-1-Hashes, je ein Hash für jedes "piece".
Eigentlich kann an einem so simplen Dateiformat gar nichts großartig falsch sein.
Die Informationen für alte und neu erzeugte Torrents sind völlig identisch -- es könnten also höchstens die Hashes verschieden sein. Doch dann müsste ctorrent doch einen entsprechenden Fehler anzeigen, statt dass die Kommunikation zusammenbricht?

• rechner-1-10-30 hat noch das xenial-falk-Image.
  • ctorrent unter Ubuntu starten: kein Problem
  • torrent-Datei unter Ubuntu mit ctorrent neu erzeugt und ctorrent gestartet: kein Probem

Das ist interessant! Hast Du das direkt auf dem Client gemacht?
Denn: Als ich die torrent-Datei auf dem paedml neu erzeugt habe (btmakemetafile) und dann versuchte, den Rechner zu syncen, klappte es nicht (das ist die Datei "xenial-falk-SRU1-win7.cloop.torrent--new").

• nächster Test (nach dem Boot): torrent-Datei unter LINBO neu erzeugen

ToDo

Herausfinden, welcher Switch/VLAN es ist, der die IP sperrt und den mal neu starten, Verbindung auf einen anderen Port legen, etc. Irgendwie habe ich einen fehlerhaften Switch im Verdacht...

[bau]

Ich habe den Rechner heute an einen anderen Switch gehängt - direkt am gleichen Cisco-Modul, an dem auch der paedml hängt. Das hat aber keinerlei Veränderung gebracht. Der Zugang zum paedml wurde gesperrt, zu allen anderen Rechnern, die am ganz anderen Switch hängen, läuft weiter.

Fazit: Problem besteht unabhängig vom Switch nur in der Kommunikation mit dem paedml!

[bau]

Testergebnis:

• btrack auf rechner-1-10-32 gestartet und diverse Clients dort angemeldet:
  • xenial-falk von LINBO aus (rechner-1-10-29)
  • bionic-gerhard von LINBO aus und download durchgeführt (rechner-1-10-29)
  • bionic-gerhard von Ubuntu aus (rechner-1-10-31 und rechner-1-10-32)
    Lief alles problemlos!

• btrack auf paedml von Hand als root gestartet, dabei nur an 10.32.1.1 gebunden, linbo-bittorrent vorher gestoppt
  • bionic-gerhard von Ubuntu aus (rechner-1-10-31) problemlos
  • linbo-bittorrent wieder gestartet
  • bionic-gerhard von Ubuntu aus (rechner-1-10-31) problemlos

• service bittorrent auf paedml wieder gestartet
  • linbo-bittorrent vorher gestoppt
  • bionic-gerhard von Ubuntu aus (rechner-1-10-31) problemlos

Anscheinend hat sich das Problem verflüchtigt?

[Rüdiger Kupper]

Das Problem taucht wieder auf:
Gestern habe ich ein neues Image hochgeladen, heute war der Tracker auf dem paedml abgestürzt. Die IP des Rechners (von dem aus ich hochgeladen hatte) wurde eben gesperrt…

[bau]

Ich habe damals den Tracker und die btdownloadcurses gestoppt, danach den Tracker wieder gestartet und von einem Client aus den ctorrent (unter Ubuntu und unter LINBO) gestartet - danach habe ich die btdownloadcurses auch wieder gestartet und das Problem war weg.

Vermutung:
wir nutzen den Tracker aus beiden Netzen
eventuell wäre ein Tracker auf einem Rechner im Lehrernetz die Lösung?

[Rüdiger Kupper]

Vermutung:
wir nutzen den Tracker aus beiden Netzen
eventuell wäre ein Tracker auf einem Rechner im Lehrernetz die Lösung?

Möglich.
Derzeit versuche ich zu verstehen, was das Problem auslöst. Ich hane jetzt eine VVermutung:

Ich vermute, dass unser Tracker auf dem paedml „wegbricht“, wenn sich eine ausgeteilte Datei ändert, aber viele peers noch die alte Datei verteilen.
Mit Erscheinen der neuen Version einer Datei werden auf einen Schlag alle bisherigen „seeders“ ungültig (weil die Checksumme nicht mehr stimmt).
Ich vermute, dass unsere Implementation (ctorrent) mit dieser Situation nicht zurecht komm und abstürzt.

[Rüdiger Kupper]

Heute habe ich bestätigt, dass das aktuelle Image so nicht verteilt werden kann.

Ich habe ein neues Image hochgeladen, in dem unser kepler--torrents-job wieder aktiviert war. Im vergangnen Image hatte ich den deaktiviert.

Erfahrung: mit dem vergangenen Image konnte ich problemlos verteilen, auf sämtlichen Schüler- und Lehrerrechnern .

Mit dem „neuen“ Image ist jeder Rechner, der den Torrente gestartet hat, sofort vom paedml ausgeschlossen worden.

Maßnahmen:

Unabhängig von der Ursachensuche habe ich unseren kepler--torrents-Dienst auf allen Rechnern deaktiviert. Der Dienst ist zwar wünschenswert und nützlich und ich glaube auch, wir haben ihn richtig umgesetzt, doch er scheint der Audlöser für unsere Problemr zu sein.

[Rüdiger Kupper]

Ich werde jetzt 24h abwaraten und dann erneut versuchen das Image zu verteilen. Funltioniert das, bleibt der Dienst bis auf weiteres deaktiviert.

[bau]

kup vermutet gerade:

• Problem tritt auf, wenn ein neues Image hochgeladen wird
• das neue Image wird vom paedml auf dem bttrack angemeldet
• das alte Image wird von den laufenden Clients auch angemeldet
• Faktisch sind also zwei verschiedene aber gleichnamige Images im Umlauf

Abhilfe:

• VOR dem Hochladen des Images alle laufenden kepler--ctorrents stoppen.
• damit das dann auch Effekt hat, muss die Zeile wieder einkommentiert werden:

  	    
  	    # die .torrent-Datei immer aktuell halten (ist eine kleine Datei)
  	    ###rsync paedml::linbo/$Image.torrent /cache/
  
  

[bau]

zu Überlegen:

• Für Testzwecke das cloop-Image mit einer Versionsnummer versehen
• Auf Testrechnern kann dann gezielt gesteuert werden, dass das neue Testimage genommen wird
• Ist der Test erfolgreich, wird das Image ohne Versionsnummer aktuell gemacht (Stoppen aller kepler--torrents oder Shutdown auf allen Maschinen)

[Rüdiger Kupper]

Vielleicht ließe sich das stoppen und starten der Torrents automatisieren. Das könnte an zwei Stellen geschehen:

• im init-Skript, das bei "service linbo-bittorrents start" aufgerufen wird (auf dem paedml gibt es noch kein systemd). Dann würden bei jedem Neustart des Trackers grundsätzlich auch alle laufenden ctorrents neu gestartet
• in dem Skript, das ich ohnehin vor dem Hochladen aufrufe, um das Image vor dem Hochladen aufzuräumen. Das läuft allerdings auf dem Rechner in der Physik, müsste aber klappen.