Ich wuerde gerne mal Python 2 soweit es geht vom Server verbannen, sonst rennen wir da frueher oder spaeter in Probleme... Es gibt ein paar Skripte zur Lobby (chat, game listing), die krieg ich vermutlich hin. Aber was machen wir mit dem watchdog (upload problem)? Der basiert auf diesem hornalten pycap - mitportieren oder auf was neues setzen? Oder das Skript in C++ neu mit pcap?
Achtung Spoiler:
Gibt es einen Grund warum du lieber C++ als Python3 bevorzugen würdest? Mir fiele jetzt nur ein, dass das Programm mit Zugriff auf Netzwerktraffic/Sudo-Rechten damit klein gehalten wird.
Für die Konvertierung zu Python3 gäbe es mindestens zwei Wrapper, die aktuell aussehen. Sind wir da vor ein paar Jahren schon mal in Probleme gelaufen?
https://pypi.org/project/libpcap/
https://pypi.org/project/pcap-ct/
Die anderen Skripte, die ich sonst auf dem Server verwende, sind auf Python3 umgestellt. Nur Civ4 sticht da mit der uralten Version heraus. D.h. da bleibt dann immer noch eine Python 2.4 Schnittstelle bestehen.
Andere Sache: Könntest du PBSpy bei Gelegenheit noch mal auf den neuesten Stand bringen. Die EMail-Benachrichtigung ist immer noch in meinem schlimmen Denglish verfasst
Das darf gerne Python3 sein, ich hatte nur noch nicht nach alternativen Bibliotheken geschaut. Dieses pycap war damals (2015?) schon hornalt, aber es gab halt keine alternativen. Die beiden Bibliotheken sind neuer. Ich versteh nicht so ganz den Unterschied,(gibts da verschiedene *cap bibliotheken drunter?). Ist auch vom selben Autor. Aber bei beiden steht:Zitat von Ramkhamhaeng
Kannst du vielleicht mal bisschen testen?ATTENTION: currently works and tested only for Windows.
C++ waere die Variante wenn's keine funktionierenden Python lib/bindings gibt.
Naja die ist ja in Civ eingebettet, das zieht also keine Systemabhaengigkeiten nach.
Mach ich die Tage mal mit.Andere Sache: Könntest du PBSpy bei Gelegenheit noch mal auf den neuesten Stand bringen. Die EMail-Benachrichtigung ist immer noch in meinem schlimmen Denglish verfasst
Achtung Spoiler:
@Zulan: Da ich ohne Sudo-Rechte, glaube ich, auf dem Server keinen Zugriff auf die Logs habe wollte ich mal nachfragen ob du in diesen Zugriffe auf bestimmten Ports erkennen kannst. Bei den Realms Beyond-Spielen stürzen mir regelmäßig die Spiele auf Port 2048 und 2049. Ich hatte erst einen Spieler in Verdacht, der sich öfter mit der falschen Mod-Version einloggt, aber mittlerweile weist alles darauf hin, dass es eher ein automatischer Port-Scan ist, der die Spiele crasht.
Ich lege die Spiele jetzt auf Port 8048/8049. Eeine Bestätigung der Vermutung wäre nat. die beste Lösung.
In den Logs sehe ich nichts zu den Ports - wuesste aber auch nicht was da im log auftauchen sollte. Wenn da tatsaechlich ein portscan laeuft, dann merkt das auch nur der civ server der auf dem port laeuft.
Achtung Spoiler:
Aha, ok. Hatte vermutet so was wird vom System global mitgeloggt. Manuell einen Scan des Traffics aufzusetzen würde aber vermutlich zu aufwändig für das Problem sein. Mal sehen ob&wann die Spiele nun mit den neuen Portnummern crashen.
Ich glaube nun ein gutes Python-Paket gefunden zu haben und werde die Portierung damit mal versuchen.
Es heißt 'scapy' und scheint recht leichtgewichtig zu sein. Erst war ich auf 'pyshark' gestoßen aber dessen
Abhängigkeit zu tshark hatten bei mir >100MB Abhängigkeiten installiert.
@Zulan:
Ich habe jetzt die neue Watchdog-Version ins Repo gepusht (unstable-branch) und
unter /home/civpb/watchdog2 abgelegt.
Problematisch ist wieder wie wir mit dem Programm auf die Netzwerkschnittstelle zugreifen können ohne es mit Superuser-Rechten auszuführen.
Ausgehend von den Änderungen, die ich auf meinem Laptop machen musste, wäre dies mein Vorschlag:
Ob ich mit diesen Rechten auch Pakete senden kann, habe ich noch nicht ausgetestet.Code:# Abhängigkeiten installieren sudo apt install tcpdump sudo python3 -m pip install scapy # Verzeichnis vom neuen Watchdog cd /home/civpb/watchdog2 # Python3 Netzwerkzugriff geben (das ist noch wie beim letzten mal) cp /usr/bin/python3 . sudo setcap cap_net_raw=+ep ./python3 # tcpdump braucht auch noch Zugriff auf die Netzwerkschnittstellen: # Laut https://askubuntu.com/questions/530920/tcpdump-permissions-problem sudo groupadd pcap sudo usermod -a -G pcap ramkhamhaeng sudo chgrp pcap /usr/sbin/tcpdump sudo chmod 750 /usr/sbin/tcpdump sudo setcap cap_net_raw=ep /usr/sbin/tcpdumpDas war notwendig, um dem PBServer Antworten der Clients vorzugaukeln, damit er die Verbindung schließt.
Falls das in etwa das ist, was du dir vorgestellt hast können wir uns die Tage ja mal im Discord treffen.
Edit²: Jetzt läuft es.
Geändert von Ramkhamhaeng (08. Juni 2020 um 19:39 Uhr)
Das mit den binaries ist halt doof bei updates. Python bekommt keine in /usr weiss ich nicht ob die bei updates am leben bleiben.@Zulan:
Ich habe jetzt die neue Watchdog-Version ins Repo gepusht (unstable-branch) und
unter /home/civpb/watchdog2 abgelegt.
Problematisch ist wieder wie wir mit dem Programm auf die Netzwerkschnittstelle zugreifen können ohne es mit Superuser-Rechten auszuführen.
Ausgehend von den Änderungen, die ich auf meinem Laptop machen musste, wäre dies mein Vorschlag:
Ob ich mit diesen Rechten auch Pakete senden kann, habe ich noch nicht ausgetestet.Code:# Abhängigkeiten installieren sudo apt install tcpdump sudo python3 -m pip install scapy # Verzeichnis vom neuen Watchdog cd /home/civpb/watchdog2 # Python3 Netzwerkzugriff geben (das ist noch wie beim letzten mal) cp /usr/bin/python3 . sudo setcap cap_net_raw=+ep ./python3 # tcpdump braucht auch noch Zugriff auf die Netzwerkschnittstellen: # Laut https://askubuntu.com/questions/530920/tcpdump-permissions-problem sudo groupadd pcap sudo usermod -a -G pcap ramkhamhaeng sudo chgrp pcap /usr/sbin/tcpdump sudo chmod 750 /usr/sbin/tcpdump sudo setcap cap_net_raw=ep /usr/sbin/tcpdump
Falls das in etwa das ist, was du dir vorgestellt hast können wir uns die Tage ja mal im Discord treffen.
Edit²: Jetzt läuft es.
Wie waers mit systemd / ambient capabilities? https://www.freedesktop.org/software...l#Capabilities
Ich hab die gamespy Sachen auch alle als Services laufen (ohne capabiltiies).
Ping mich jederzeit im Discord an.
Achtung Spoiler:
Habt ihr schonmal über Dockercontainer nachgedacht? Da müsste es doch entspannter sein, so nem Tool su-Rechte zu geben.
@Zulan: Im Discord kann ich dir keine Chat-Nachricht senden. (Keine Reaktion auf [Return]), daher hier.
Ich habe eine Unit für Systemd erzeugt, aber wenn ich sie als User ausführe, hat die Zeile
keine Auswirkung (oder hat sie schon, aber das Python-Binary erbt die Eigenschaft nicht?!).Code:CapabilityBoundingSet=CAP_NET_RAW
In der von dir verlinkten Dokumentation steht gleich ganz oben die Warnung
Daher weiß ich jetzt erst einmal nicht weiter und beende die Sache für heuteThese options are only available for system services and are not supported for services
running in per-user instances of the service manager.Aktueller Stand ist gepusht und in /home/civpb/watchdog2 abgelegt.
@Zulan: Zu gestern diskutierten Frage mit dem Mausklicks habe ich die Logik jetzt wieder verstanden.
Die Idee war genau dann zu reagieren, wenn ein Spieler sich einloggen möchte. Dazu wurde probiert, eine simple Regel aufzustellen, die
a) genau das zweite Paket des Clients detektiert. (vorheriges Paket ist weniger als 22 Sekunden her. Früherer Login soll keine Rolle spielen)
22 Sekunden sind ein guter Wert, weil der Client es alle 20 Sekunden probieren wird.
b) Der Server hat nicht auf das erste Paket reagiert. (aka keine Nachricht des Servers innerhalb der letzten 18 Sekunden.
Nun zur Antwort warum das so vermutlich öfter mal ausschlägt obwohl der Server nicht durch ein Popup blockiert ist:PHP-Code:# Filter out previous player login (== last paket long time ago recv.)
bSameLoginSession = (now - self.time_last_incoming_packet < 22)
# Server has not replied for long amount of time
bNoServerReply = (now - self.watchdog_last_active_server_ts > 18)
if (bSameLoginSession and bNoServerReply):
logger.debug(f"{self!r} - detected no network reply.")
game.no_network_reply()
Der Client sendet schneller ein zweites Paket als erwartet. Entweder weil das erste Paket, was gesendet wird, doppelt ankommt (ist ja UDP?!) oder der User probiert zwei Verbindungsversuche innerhalb von 22 Sekunden:
1. User loggt sich aus. Sein letztes Netzwerkpaket setzt self.time_last_incoming_packet
2. User loggt sich nach 19-21 Sekunden erneut ein.
Dann sind beide Bedingungen schon beim ersten Paket der Session erfüllt.
Ich habe es noch nicht durch anderen Code ersetzt, da ich leider das Popup nicht provozieren kann
Wir können den automatischen Mausklick mal komplett deaktivieren. Ich weiß gar nicht ob das Problem auf dem neuen Server überhaupt schon mal aufgetreten ist. Die Screenshots zur Dokumentation hab ich leider schon gelöscht.
Aber es wird doch garnicht verhindert, dass es beim dritten, vierten, ... Client->Server Paket triggert, oder übersehe ich da was?
Achtung Spoiler:
Wenn der Server einmal antwortet, ist 'bNoServerReply' für eine Weile False.
Ohne Server-Antwort hast du recht. Da sollte es aber auch mehrfach ausgelöst werden, da dann jeweils die verschieden Strategien ausprobiert werden. Beim ersten mal der Mausklick, dann der Restart (nicht implementiert), ect.
Ich denke mal ändere es so ab, dass ich nicht auf die User-Verbindungen warte und stattdessen
selber an den PBServer ein 'Ping' sende.
Berechtigungen
Zitieren