seit einem Update/Neustart vermisse ich auf meinem Server ein paar Dateien zur Image-Verteilung über Torrent. Aufgefallen ist es, weil die Verteilung nicht mehr funktionierte und die Überprüfung des Dienstestatus folgendes ergab:
root@linbo:/srv/linbo# systemctl status linbo-torrent.service
● linbo-torrent.service - Linbo torrent service
Loaded: loaded (/etc/systemd/system/linbo-torrent.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2021-09-14 14:12:23 CEST; 4h 41min ago
Main PID: 18875 (code=exited, status=1/FAILURE)
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: Textmode GUI initialization failed, cannot proceed.
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: This download interface requires the standard Python module "curses", which is unfortuna
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: You may still use "btdownloadheadless.py" to download.
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: Traceback (most recent call last):
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: File "/usr/bin/btdownloadcurses", line 205, in <module>
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: scrh, scrw = scrwin.getmaxyx()
Sep 14 14:12:23 linbo.<FQDNmaskiert> linbo-torrent[18875]: NameError: global name 'scrwin' is not defined
Sep 14 14:12:23 linbo.<FQDNmaskiert> systemd[1]: linbo-torrent.service: Main process exited, code=exited, status=1/FAILURE
Sep 14 14:12:23 linbo.<FQDNmaskiert> systemd[1]: linbo-torrent.service: Failed with result 'exit-code'.
Sep 14 14:12:23 linbo.<FQDNmaskiert> systemd[1]: Failed to start Linbo torrent service.
In der Servicekonfiguration, die ich vorerst mal deaktiviert habe, wird auf die fehlende Datei /usr/sbin/linbo-torrent verwiesen.
Wenn ich nach zugehörigen Paketen zu relevanten Pfaden suche, wird kein passendes Paket gefunden:
dpkg -S /etc/init.d/linbo-torrent
dpkg-query: Kein Pfad gefunden, der auf Muster /etc/init.d/linbo-torrent passt
Ein Symlink zur linbo-torrenthelper.sh scheint auch in keinem Paket zu existieren
dpkg -S /usr/sbin/linbo-torrent
dpkg-query: Kein Pfad gefunden, der auf Muster /usr/sbin/linbo-torrent passt
Die installierten Pakete sind:
linuxmuster-base7/now 7.0.83-0ubuntu0 all [Installiert,lokal]
linuxmuster-linbo-common7/lmn7,now 2.4.3-4 all [Installiert,automatisch]
linuxmuster-linbo-gui7/lmn7,now 7.0.3 all [installiert]
linuxmuster-linbo7/lmn7,now 2.4.3-4 all [Installiert,automatisch]
linuxmuster-prepare/lmn7,now 0.7.6-1ubuntu0 all [installiert]
linuxmuster-webui7/now 1.0.159-1 all [Installiert,lokal]
Es gibt /etc/default/linbo-bittorrent und /etc/default/bittorrent, sowie /etc/init.d/bittorrent. Es scheint auch bittorrent als Dienst zu laufen, aber die Tracker-Statusseite http://linbo:6969 zeigt mir nur einen von sechs erwarteten Torrents an.
Ist hier der Upgradepfad kaputt oder fehlt mir ein Paket? Wie komme ich wieder zu den Dateien oder einer anderweitig laufenden Verteilung mit Torrent?
Da scheint die python libcurses zu fehlen.
Allerdings scheint mir da einiges nicht in sync zu meinem system hier.
/etc/init.d/linbo-torrent exisiert hier nicht - vielleicht ein Überbleibsel des Updates?
Danke für den Hinweis, der hat mich auf die richtige Spur geführt.
Bei mir gab es in /etc/init.d/ nicht eine Datei, die mit „linbo-“ beginnt. Ich habe dann den Paketcache geleert und ein aptitude reinstall linuxmuster-linbo7 ausgeführt. Die Datei fehlte weiterhin. Letztlich habe ich die Datei manuell aus dem deb-Paket dahin kopiert. Das Verhalten hängt vielleicht damit zusammen, dass ich in der Vergangenheit aus testing die Version 4.0.0.~rc1 des Pakets mal installiert hatte. Das könnte auch erklären, wieso es bei mir in systemd zwei Servicedefinitionen gab (linbo-bittorrent.service und linbo-torrent.service) und es da zu Verwechslung kam.
Abend,
ich bin die Woche auch ueber das Torrentproblem gestolpert, das ist suboptimal geloest, zumindest bei der Begrifflichkeit.
Es gibt hier zwei systemd Service Units: bittorrent.service und linbo-bittorrent
bittorrent.service: Startet den Tracker der den Schwarm verwaltet und laeuft/hoert auf Port 6969, da kann auch man mit dem Browser nachschauen welche Torrents der Tracker verwaltet.
Der Tracker hat in der Regel keine Inhalte, er ist nur Chef des Schwarms.
Der Schwarm besteht aus Seeder(n) und Leechern, Seeder haben den Torrentinhalt zu 100%, Leecher (noch) nicht, erreicht der Leecher die 100%, wird er zum Seeder, fuettert den Schwarm aber schon vorher mit den „chunks“, die er bereits heruntergeladen hat. Chunks sind die Einzelteile aus denen der Torrentinhalt besteht.
Glaube bei uns lief der Tracker auch nicht von sich aus, bin mir aber nicht sicher.
Service Unit linbo-bittorrent: Startet die ersten Seeder, die den Torrentinhalt zu 100% haben, ohne Seeder laufen die Leecher ins Leere.
Es muss mindenstens einen Seeder geben, sonst ist der Torrent tot, da nie 100% heruntergeladen werden koennen, dieser wird auf LML durch diesen Service gestartet.
Die Benennung linbo-bittorrent gefaellt mir nicht, da sie verwirrt.
Bei uns lief der „Seeder“ per default nicht, wuerde mich wundern, wenn das bei Euch anders waere, per „systemctl enable servicename“ lassen sich diese automatisch beim Booten starten.Die Meisten werden das gar nicht bemerken, holen die cloops dann halt per rsync oder was auch immer da noch am Start ist.
Ueberpruefen kann man das auf mehreren Wegen, hier einer.
bbtrack ist der Tracker auf Port 6969
btdownloadcurses sind die zwei Seeder fuer zwei cloops
Wieso hier die ncurses-Variante von bittorrent genommen wurde, weiss ich nicht, ist aber auch nicht so wichtig. Diese laeuft in screens.
ja, das mit der Namensgebung trug bei mir auch zur Verwirrung bei.
Wenn dann auch noch in der Konfigurationsdatei für den Torrent-Client in /etc/default/linbo-bittorrent in Zeile 1 steht # default start values for LINBO bittorrent server
dann ist die Verwirrung komplett, da der Tracker in einem Bittorrent-Netzwerk die einzige Komponente ist, die man „server“ nennen könnte.
Mal leicht off-topic, aber noch zum Thema Torrent:
Gibt es eine Chance zu einem aktualisierten Torrent-Client zu kommen? Ich würde gerne mal den Super-Seeding-Modus ausprobieren, aber die aktuelle Version meckert, sie kenne den Parameter nicht. Wir haben durchaus den Bedarf mal 15 IT-Räume je 17 Rechner (255 Clients) gleichzeitig zu aktualisieren. Da könnte es ungemein helfen, wenn der seedende Client erstmal dafür sorgt, dass alle Teile mindestens einmal verteilt wurden, bevor Teile erneut verteilt werden. Aktuell ist es so, dass wir bei nur 17 gleichzeitigen Downloads per Torrent fast nie einen Torrent-Client mit Upload im IT-Raum sehen. Das führt dann oftmals sogar dazu, dass Clients auf rsync zurückfallen, weil sie längere Zeit keine Teile erhalten haben. Im Linbo-Server war MAX_UPLOADS=4 als default gesetzt, aber selbst mit MAX_UPLOADS=17 ist das Problem nur gelindert und nicht beseitigt. Lässt sich der Rückfall auf rsync auch ausschalten? Mir nützt es nämlich nix, wenn ein Client mit rsync den Uplink in den Raum dicht macht und damit mehr Torrent-Downloads verlangsamt, die dann potenziell auch alle auf rsync zurückfallen.
in so einem Setting würde ich zusätzliche Seeder aufstellen.
In manchen Schulen haben wir das schon gemacht, um einen Seeder für „das andere Gebäude“ zu haben, das nicht so dick angebunden ist.
Das geht relativ einfach: einen Client in eine Hardwareklasse stecken, in der alle benötigten Images drin sind.
Riesigen Cache einplanen.
Client starten und Cache initialisieren.
Client läuft immer.
Gibt es ein neues Image, dann gibt man dem seeder erstmal ein init cache per linbo remote und wartet, bis er fertig ist.
Wenn der soweit ist, dann kann man die Client wecken: dann hat man gleich einen zusätzlichen Seeder (außer dem Server).
Das kann man natürlich auch mit mehreren machen.
In meiner größeren Umgebungen (ich hab 100 Clients, die ein und das selbe Image haben) wecke ich die Räume um 30 Minuten Zeitversetzt direkt nach der Imageerstellung: also Nachts, mit linbo remote und einem „halt“ am Ende.
Die eigentliche Imageverteilung findet bei mir immer Nachts statt.
Aber zu deiner Frage: du meinst ein aktuelleres Torrentpaket? Also der ctorrent: 1.3.4 ist zu alt?
Da wird das Problem sein, dass das die „normale“ Version von ubuntu 18.04 ist …
danke für die Tipps. Ich werde mal schauen wie wir das umsetzen können. Wenn ich es richtig verstehe, könnte das ja auch eine Maschine sein, welche die Systempartitionen für die Images nur als Alibi mit Minimalgröße hat und die Festplatte zu 99% von der Cache-Partition belegt wird, oder? Man will ja auf der (ggf. virtuellen) Kiste die cloop-Datei nie entpacken.
Beim Super-Seeding dachte ich zuerst an den Torrent-Client auf dem Linbo-Server. Da wird das ja von btdownloadcurses übernommen und ich dachte das gehört zum Paket bittorrent bzw. bittornado? Da hatte ich die Option gefunden:
--super_seeder 0|1
whether to use special upload-efficiency-maximizing routines (only for dedicated
seeds) (defaults to 0)
Nur wird das vom init-Skript und linbo-torrenthelper.sh nicht unbedingt durchgereicht und als ich es probehalber manuell eingebaut hatte, meinte btdownloadcurses im screen super_seeder sei ein unbekannter Parameter. Die Rechner im IT-Raum brauchen den Parameter nicht unbedingt, aber ich wollte mal nachschauen, ob es einen Einluss hat, wenn der initiale Seeder nur neue Teile verteilt, dass dann die ctorrent-Clients auch mehr Teile untereinander rumreichen.
genau: die Betriebsystempartitionen auf dem seeder können Alibipartitionen geringer Größe sein.
In der start.conf sind dann vielleicht 5 Betriebsysteme mit unterschiedlichen Images definiert: wen interessierts?
Und wegen dem ctorrent: hab jetzt gesehen, dass das ein Client ist.
Ich weiß nciht, welcher bittorrent server verwendet wird.
Ich hab auf dem server nur schnell per dpkg -l | grep torr geschaut, welcher torrentserver drauf ist …
Da sind aber nur zwei Clients … der torrentserver ist wohl im linbo Paket drin … ich weiß es nicht.