3.3.1

Changelog

Verbesserte Handhabung von KeyboardInterrupt und sauberer Shutdown

Datum: 19.10.2024

Datei: checkpoint.py

Änderungen:

1. Abfangen von KeyboardInterrupt in der main()-Funktion:

   • Was wurde geändert?

     • Ein try...except-Block wurde um den Hauptteil der main()-Funktion hinzugefügt, um KeyboardInterrupt abzufangen.
     • Beim Erhalt eines KeyboardInterrupt werden alle laufenden asynchronen Tasks (consume_messages, consume_unban_messages, etc.) ordnungsgemäß abgebrochen.
     • Die Funktion asyncio.gather() wird mit dem Parameter return_exceptions=True aufgerufen, um sicherzustellen, dass alle Tasks korrekt beendet werden, auch wenn sie Ausnahmen auslösen.

   • Warum wurde dies geändert?

     • Um sicherzustellen, dass das Programm bei einem manuellen Abbruch durch den Benutzer (z.B. durch Drücken von Ctrl+C) die laufenden Prozesse sauber beendet und Ressourcen wie Verbindungen zu RabbitMQ ordnungsgemäß freigibt.
     • Verhindert unerwartete Ausnahmen und Fehlermeldungen während des Shutdowns.

2. Anpassung der Verbraucherfunktionen (consume_*), um asyncio.CancelledError abzufangen:

   • Was wurde geändert?

     • In jeder der consume_*-Funktionen (consume_messages, consume_unban_messages, consume_tempban_messages, consume_watchlist_messages, consume_unwatch_messages) wurde ein try...except-Block hinzugefügt.
     • Dieser fängt asyncio.CancelledError ab, das ausgelöst wird, wenn der Task abgebrochen wird.
     • Zusätzlich wird ein allgemeiner except-Block hinzugefügt, um andere unerwartete Ausnahmen zu protokollieren.

   • Warum wurde dies geändert?

     • Durch das Abfangen von asyncio.CancelledError kann jeder Task sauber beendet werden, ohne dass unhandhabte Ausnahmen auftreten.
     • Verbessert die Stabilität des Programms und ermöglicht einen kontrollierten Shutdown der einzelnen Aufgaben.

3. Hinzufügen von Logging-Meldungen:

   • Was wurde geändert?

     • Zusätzliche Logging-Meldungen wurden hinzugefügt, um den Status des Programms besser zu verfolgen.
     • Beim Start und Abbruch jeder Verbraucherfunktion wird nun eine entsprechende Meldung protokolliert (z.B. "Task consume_messages wurde abgebrochen.").
     • Beim Schließen der Verbindungen in der finally-Klausel der main()-Funktion wird eine Meldung ausgegeben ("Schließe Verbindungen...").

   • Warum wurde dies geändert?

     • Erhöht die Transparenz des Programmablaufs und erleichtert das Debugging.
     • Gibt dem Benutzer Feedback darüber, was beim Beenden des Programms passiert.

4. Anpassung des Hauptprogramms (if __name__ == '__main__'):

   • Was wurde geändert?

     • Ein zusätzlicher try...except-Block wurde um den Aufruf von asyncio.run(main()) hinzugefügt.
     • Dieser fängt KeyboardInterrupt ab, falls es außerhalb der main()-Funktion auftritt.
     • Beim Abfangen wird eine Logging-Meldung ausgegeben ("Programm wurde durch KeyboardInterrupt beendet.").

   • Warum wurde dies geändert?

     • Um sicherzustellen, dass das gesamte Programm sauber beendet wird, selbst wenn ein KeyboardInterrupt außerhalb der main()-Funktion auftritt.
     • Verhindert unhandhabte Ausnahmen und ermöglicht einen kontrollierten Shutdown.

Zusammenfassung der Vorteile:

• Sauberer Shutdown des Programms: Durch das ordnungsgemäße Abfangen von Unterbrechungssignalen und das kontrollierte Beenden von Tasks und Verbindungen wird sichergestellt, dass keine Ressourcen offengelassen oder beschädigt werden.
• Verbesserte Fehlerbehandlung: Unerwartete Ausnahmen werden abgefangen und protokolliert, was die Stabilität des Programms erhöht und das Debugging erleichtert.
• Erhöhte Transparenz: Durch detaillierte Logging-Meldungen kann der Programmablauf besser nachvollzogen werden.

Fix: SyntaxError in `api_manager.py`

Changelog

Fix: SyntaxError in api_manager.py

• Problem behoben: Ein SyntaxError trat auf, weil das Schlüsselwort async with außerhalb einer asynchronen Funktion verwendet wurde.
• Datei betroffen: api_manager.py
• Änderungen:
  • Die Methode report_api_version wurde von einer asynchronen Funktion zu einer synchronen Funktion umgewandelt.
    • Vorher: Verwendung von async def und aiohttp für asynchrone HTTP-Anfragen.
    • Nachher: Verwendung von def und requests für synchrone HTTP-Anfragen.
  • Entfernt den Import von aiohttp, da es nicht mehr benötigt wird.
  • Hinzugefügt oder sichergestellt, dass import requests und import logging am Anfang der Datei vorhanden sind.
  • Fehlerbehandlung und Logging wurden verbessert, um mögliche Ausnahmen zu erfassen und zu protokollieren.

Details der Änderung in api_manager.py:

• Alte Version der Methode report_api_version:

  async def report_api_version(self, client_id):
      url = "https://api.hackletloose.eu/update_client_version"
      timestamp = datetime.datetime.utcnow().isoformat()
      data = {
          'client_id': client_id,
          'api_version': self.api_version,
          'timestamp': timestamp
      }
      async with aiohttp.ClientSession() as session:
          async with session.post(url, json=data) as response:
              if response.status == 200:
                  logging.info(f"API-Version {self.api_version} erfolgreich gemeldet für Client {client_id} mit Timestamp {timestamp}")
              else:
                  logging.error(f"Fehler beim Melden der API-Version {self.api_version} für Client {client_id} mit Timestamp {timestamp}")

• Neue Version der Methode report_api_version:

  def report_api_version(self, client_id):
      url = "https://api.hackletloose.eu/update_client_version"
      timestamp = datetime.datetime.utcnow().isoformat()
      data = {
          'client_id': client_id,
          'api_version': self.api_version,
          'timestamp': timestamp
      }
      try:
          response = requests.post(url, json=data)
          if response.status_code == 200:
              logging.info(f"API-Version {self.api_version} erfolgreich gemeldet für Client {client_id} mit Timestamp {timestamp}")
          else:
              logging.error(f"Fehler beim Melden der API-Version {self.api_version} für Client {client_id} mit Timestamp {timestamp}")
      except Exception as e:
          logging.error(f"Fehler beim Melden der API-Version: {e}")

Konsistenz und Verbesserungen

• Konsistente Nutzung von HTTP-Bibliotheken: Alle HTTP-Anfragen innerhalb der APIClient-Klasse verwenden nun das requests-Modul, was die Wartbarkeit und Lesbarkeit des Codes verbessert.
• Fehlerbehandlung: Verbesserte Fehlerbehandlung in der Methode report_api_version, um Ausnahmen zu protokollieren und unerwartete Abstürze zu vermeiden.
• Entfernte unnötige Importe: import aiohttp wurde entfernt, da es nicht mehr benötigt wird.
• Logging: Zusätzliche Logging-Statements wurden hinzugefügt, um den Status von HTTP-Anfragen und möglichen Fehlern besser nachverfolgen zu können.

3.2.0 v10 Fixes

Changelog von Version 3.1.0 zu 3.2.0

Version 3.2.0 (Aktuelle Version)

Neue Features:

1. Dynamische Zuordnung von player_id und player_name in consume_tempban_messages:

   • Basierend auf der API-Version wird nun dynamisch entweder player_name oder player sowie player_id oder steam_id_64 zugeordnet.
   • Erhöht die Flexibilität und Kompatibilität mit unterschiedlichen API-Versionen.

2. Verarbeitung von Watchlist-Nachrichten basierend auf API-Versionen:

   • Die consume_watchlist_messages-Funktion berücksichtigt jetzt unterschiedliche API-Versionen (v10 und v9.x), um die korrekten Datenfelder (player_name und player_id vs. player und steam_id_64) zu verarbeiten.

Verbesserungen:

1. Fehlerbehandlung in connect_to_tempban_rabbitmq:

   • Besseres Error-Handling durch Einfügen eines Try-Catch-Blocks in der Funktion connect_to_tempban_rabbitmq, um Fehler beim Verbindungsaufbau zu RabbitMQ abzufangen und optional weiterzuleiten.

2. Robustheit des Message-Handling in consume_watchlist_messages:

   • Neue Logik, um zu vermeiden, dass Nachrichten mehrfach verarbeitet werden, falls ein Fehler auftritt, und zusätzliche Absicherung durch Verwendung eines Flags (processed), das den Verarbeitungsstatus der Nachricht verfolgt.

3. Fehlerhafte Nachrichtenzurückstellung:

   • Verbesserte Fehlerbehandlung in den consume_*_messages-Funktionen. Nachrichten, die nicht korrekt verarbeitet werden können, werden nun zuverlässiger wieder in die Queue gestellt oder nicht erneut eingereiht, je nach Kontext.

Fehlerbehebungen:

1. Stabilitätsprobleme beim Zurückstellen von Nachrichten:

   • Verbesserte Fehlerbehandlung bei der Wiederverarbeitung von Nachrichten in consume_watchlist_messages, um Situationen zu vermeiden, in denen Nachrichten irrtümlich als verarbeitet markiert werden.

2. Behebung von Problemen mit nicht wiederholten Nachrichten:

   • Sicherstellung, dass Nachrichten, die nicht erfolgreich verarbeitet wurden, korrekt zur Wiederholung in die Queue gestellt werden, oder aber explizit verworfen werden.

Entfernte Features:

• Keine Features wurden entfernt.

Sonstiges:

• Allgemeine Code-Bereinigung und Verbesserung der Lesbarkeit durch zusätzliche Kommentare und strukturelle Anpassungen.

3.1.0 Fix v10

Changelog: ban_client.py und api_manager.py

---

Änderungen in ban_client.py

1. Fehlerbehandlung und Logging verbessert:

   • Überprüfungen hinzugefügt:
     • Vor dem Verarbeiten von Ban-, Unban-, Tempban-, Watchlist- und Unwatch-Nachrichten werden jetzt player_name und player_id auf ihre Existenz überprüft.
   • Logging-Verbesserungen:
     • Verbesserte Log-Meldungen und detailliertere Informationen bei Fehlern.

2. Nachrichtenverarbeitung:

   • Fehlende Daten validieren:
     • Wenn player_name oder player_id in den Nachrichten fehlt, wird die Nachricht abgelehnt und nicht erneut in die Warteschlange gestellt (nack(requeue=False)).
   • Alle Versionen verwenden steam_id:
     • Unabhängig von der API-Version wird jetzt immer die steam_id (player_id) für alle Ban- und Unban-Operationen verwendet.

3. Kleinere Korrekturen und Verbesserungen:

   • Verwendeter client_id:
     • Der client_id wird konsequent bei allen RabbitMQ-Verbindungen und API-Aufrufen genutzt.
   • Timeout und Rückstellungslogik für RabbitMQ-Nachrichten:
     • Nachrichten werden nur dann erneut in die Warteschlange gestellt (requeue=True), wenn die JSON-Daten ungültig sind oder ein unerwarteter Fehler auftritt.

---

Änderungen in api_manager.py

1. API-Aufrufe optimiert:

   • Logging bei API-Anfragen:
     • Detaillierte Log-Meldungen für jeden API-Aufruf, einschließlich der gesendeten Nutzlast und der empfangenen Antwort.
   • API-Versionen unterstützt:
     • Die API-Aufrufe sind jetzt so gestaltet, dass sie sowohl mit Version 9.9.5 als auch mit Version 10 der API kompatibel sind.
     • Beispielsweise wurden URLs und Payloads je nach API-Version angepasst.

2. Verbesserte Fehlerbehandlung:

   • Erweiterte Logging bei Fehlern:
     • Fehler bei API-Aufrufen werden jetzt umfassender geloggt, um die Fehlersuche zu erleichtern.
   • Korrektur von API-Aufrufen:
     • Einige API-Endpunkte wie do_blacklist_player und do_watch_player verwenden jetzt das korrekte Format für die Payload, abhängig von der API-Version.

3. Verbesserte API-Kompatibilität:

   • Handling von Versionen:
     • Der player_id wird jetzt immer als steam_id verwendet, unabhängig von der API-Version, was die Konsistenz und Kompatibilität verbessert.
   • Neue Felder hinzugefügt:
     • Einige API-Aufrufe wurden aktualisiert, um zusätzliche Felder zu unterstützen, z.B. player_name bei der watch_player-Funktion für API v10.

4. Fehlertoleranz erhöht:

   • Fehler in API-Antworten:
     • Bei fehlgeschlagenen API-Aufrufen wird jetzt detaillierter darüber informiert, warum der Aufruf fehlschlug (z.B. durch Logging der vollständigen Antwort).

---

Dieses Changelog fasst die wesentlichen Änderungen zusammen, die in den Dateien ban_client.py und api_manager.py vorgenommen wurden. Die Updates umfassen Verbesserungen bei der Fehlerbehandlung, umfassendere Logging-Funktionen und eine bessere Kompatibilität zwischen verschiedenen API-Versionen.

3.0.0

Update 3.0.0 für Hack let Loose

Wir freuen uns, das Update 3.0.0 für Hack let Loose vorzustellen. Dieses Update bringt bedeutende Verbesserungen und neue Funktionen, die die Verwaltung von Banns und Entbannungen effizienter und transparenter machen. Mit einer klareren Struktur für jede Community und einer überarbeiteten Abstimmungslogik stellen wir sicher, dass alle Entscheidungen fair getroffen werden und die Zusammenarbeit innerhalb der Community gestärkt wird.

Changelog für das Client-Skript

1. Klarere Struktur für jede Community

Vor diesem Update wurden alle Banns und Entbannungen über ein zentrales System verwaltet, was manchmal zu Verwirrung führte. Mit dem neuen Update hat nun jede Community ihre eigene, separate Warteschlange zur Verwaltung von Banns und Entbannungen. Das bedeutet:

• Klarheit und Ordnung: Jede Community kann ihre Entscheidungen unabhängig treffen und verwalten.
• Schnellere Verarbeitung: Durch die getrennten Warteschlangen wird alles effizienter und gezielter bearbeitet.

2. Neue Abstimmungslogik

Die Abstimmungslogik wurde überarbeitet, um sicherzustellen, dass alle Stimmen fair gezählt werden und Enthaltungen nicht die Entscheidung blockieren.

• Start der Abstimmung:

  • Eine Nachricht wird im Abstimmungskanal gepostet.
  • Alle berechtigten Communities haben die Möglichkeit, abzustimmen.

• Stimmabgabe:

  • Communities stimmen durch Reaktionen ab:
    • 👍 (Daumen hoch) für Zustimmung
    • 👎 (Daumen runter) für Ablehnung
  • Die Abstimmung bleibt für einen festgelegten Zeitraum (24 Stunden) offen.
  • In dieser Zeit erhält der Spieler einen temporären Bann (24 Stunden).

• Beispiel für Stimmverteilung:

  • 5 Communities stimmen mit 👍
  • 3 Communities stimmen mit 👎
  • 6 Communities enthalten sich

• Auswertung der Stimmen:

  • Stimmen werden gezählt, und Enthaltungen werden zur Mehrheit gezählt:
    • Wenn mehr 👍-Stimmen als 👎-Stimmen vorliegen, werden Enthaltungen als 👍-Stimmen gezählt.
    • Wenn mehr 👎-Stimmen als 👍-Stimmen vorliegen, werden Enthaltungen als 👎-Stimmen gezählt.

• Ergebnis:

  • In unserem Beispiel haben 11 von 14 Communities (5 👍 + 6 Enthaltungen) für Zustimmung gestimmt.
  • Die Mehrheit entscheidet, ob der Bann oder die Entbannung durchgeführt wird.

• Berücksichtigung der 👎-Stimmen:

  • Communities, die mit 👎 stimmen, sind von der Durchsetzung des Banns oder der Entbannung ausgeschlossen.
  • Beispiel: 3 Communities stimmen mit 👎, also wird der Bann für diese 3 Communities nicht durchgesetzt, selbst wenn die Mehrheit dafür ist.

Diese Änderungen gewährleisten, dass Entscheidungen fair getroffen werden und die Stimme jeder Community zählt. Wir glauben, dass diese Verbesserungen die Zusammenarbeit und Transparenz in unserer Community weiter stärken werden.

Änderungen an der API-Unterstützung

• Unterstützung für v10 der API:

  • Neue Endpunkte und Felder: Unterstützung für player_id und player_name in der API v10.
  • Überarbeitete Methoden:
    • do_perma_ban: Unterscheidung zwischen steam_id_64 und player_id basierend auf der API-Version.
    • do_temp_ban: Anpassung der Payload je nach API-Version.
    • do_unban: Unterscheidung der Parameter basierend auf der API-Version.
    • do_blacklist_player: Anpassung der Endpunkte und Parameter für v10.
    • do_watch_player: Hinzufügen des player_name Feldes in der API v10.
    • do_unwatch_player: Anpassung der Payload für v10.
    • post_player_comment: Verwendung des korrekten Feldes (player_id vs. steam_id_64) basierend auf der API-Version.

• Fehlerbehebung und Verbesserungen:

  • Fehler beim Posten von Kommentaren wurden behoben.
  • Verbesserte Handhabung von Fehlermeldungen und Logging für bessere Nachvollziehbarkeit.
  • Sicherstellung der Kompatibilität mit beiden API-Versionen (v9.9.4 und v10).

Diese Änderungen sorgen dafür, dass das System sowohl mit der aktuellen als auch mit der neuen API-Version reibungslos funktioniert und gleichzeitig die neuen Funktionalitäten und Verbesserungen der API v10 nutzt.

Updateanweisungen

Um das Skript nach dem Update korrekt zu konfigurieren, müssen die folgenden Schritte befolgt werden:

1. .env Datei anpassen: Stellen Sie sicher, dass die .env Datei die korrekten Anmeldedaten und Konfigurationswerte enthält. Hier ein Beispiel für eine .env Datei:

BEARER_TOKEN=DEINTOKEN
API_BASE_URLS=https://xyz.domain.com
API_USER=DeinRCONuser
API_PASS=Passwort
CLIENT_ID=DeineClientID
RABBITMQ_USER=DeinRabbitMQ-Benutzer
RABBITMQ_PASS=DeinRabbitMQ-Passwort
RABBITMQ_HOST=rabbit.1bv.eu
RABBITMQ_PORT=5672

Wichtig: Die CLIENT_ID=DeineClientID muss korrekt eingetragen werden, da sie entscheidend für die Funktion des Skripts ist.

2. Anmeldedaten speichern:
   • Rolle: XYZ - Admins
   • Benutzername: user_DeineClientID
   • Passwort: DeinPasswort

Diese Anmeldedaten sind wichtig für die Anmeldung beim Skript und sollten sicher gespeichert werden.

3. Skript ausführen:

   • Stellen Sie sicher, dass alle Abhängigkeiten installiert sind.
   • Führen Sie das Skript mit den angepassten Konfigurationswerten in der .env Datei aus.

4. Client-Skript neustarten: Beim Update des CRCON muss auch das Client-Skript neugestartet werden.

Änderungen an bestehenden Funktionen

Für bestehende Clans und Communities, die das neue System nutzen möchten:

1. Anmeldedaten anzeigen: Klicken Sie auf die Schaltfläche "Anmeldedaten anzeigen" im Kanal register-server, um Ihre neuen Anmeldedaten zu erhalten.
2. .env Datei aktualisieren: Aktualisieren Sie Ihre .env Datei mit den neuen Anmeldedaten.
3. Client-Skript: Führen Sie das Skript mit den neuen Konfigurationswerten aus.

2.6.0

• Fügt einen Link mit den Beweisen den Kommentaren im RCON-Tool hinzu

2.5.0

Update 2.5.0:

• Watchliste hinzugefügt
• Unwatch Funktion hinzugefügt

2.2.0

• Blacklist hinzugefügt: Habe festgestellt, dass do_perma_ban nicht ausreicht, wenn Spieler noch nie den Server betreten haben. Nun führt das Skript auch do_blacklist_player aus. Dies sollte die Spieler bannen, die noch nie auf einem von unseren Servern waren.

2.1.0

• Unban gefixt: Zusätzlich wird nun der Befehl unblacklist_player ausgeführt, um den Spieler auch von der Blacklist zu entfernen. Bisher wurde der Spieler zwar entbannt, blieb jedoch auf der Blacklist. Das führte dazu, dass der Spieler bei einem Verbindungsversuch erneut gebannt wurde.

2.0.0

Changelog:

• Unban Funktion hinzugefügt. Das Skript empfängt nun Unban-Requests und führt diese aus.
• Temp-Ban Funktion hinzugefügt. Das Skript empfängt nun Temp-Ban Requests und führt diese aus. Es vergibt einem gemeldeten Spieler einen Temp-Ban von 24 Stunden