You are on page 1of 21

Wer ist online?

Ein TeamSpeak-ServerQuery-Bot oder Einen Einblick in das wohl schlechteste Protokoll der Welt

Anforderung
Mach mal, dass man sehen kann, wer auf dem TeamSpeak-Server drauf ist, auf einer Website oder so

Vorberlegung

Gibt es bereits fertige Lsungen? Funktionieren die fertigen Lsungen auch? Kann ich das selbst vlt. Besser?

Gibt es bereits fertige Lsungen?

Tatschlich:

TSViewer.com TeamSpeak 3 Webinterface von PsychoKiller Munin-Plugin

TSViewer.com : Fazit

Fremder Dienst Inakzeptabel


Serverdaten in fremden Hnden Privatsphre? Ohne nhere Betrachtung: Was darf und viel mehr was kann dieser Dienst dann so alles anstellen?

Nach Oberflchlicher Suche kein funktionierendes Beispiel gefunden Inakzeptabel, daher von der weiteren Betrachtung ausgeschlossen

TeamSpeak 3 Webinterface von Psychokiller

Anwendung die auf dem eigenen Server luft

Wahrscheinlich keine Beeintrchtigung der Sicherheit und Privatsphre, ausser eine Backdoor ist vorhanden

Backdoor lsst sich dank OpenSource berprfen (Macht man aber in der Praxis dann wohl doch eher nicht)

Keine prinzipbedingten Mngel Evaluationsfhig

TeamSpeak 3 Webinterface

1. Fazit: Sieht doof aus

Template-System relativiert dies allerdings

2. Fazit: Funktioniert nicht: Anmeldung wird abgelehnt trotz korrekter Zugangsdaten, IP-Ban nach probieren

Problem: TS3-Webinterface versteht aktuelle TSProtokoll-Version nicht mehr Schneller Bugfix frdert noch viel mehr Probleme an den Tag

TeamSpeak 3 Webinterace finales Fazit

Mglichkeit A:

Bugs fixen und aktuelles Problem lsen


In grausam formatierten Code einlesen? keine Lust Setzt vorraus, das TS3-Protokoll zu verstehen dann kann ich auch gleich selbst etwas bauen

Mglichkeit B:

Von weiterer Betrachtung ausschlieen

Erspart wahrscheinlich viel Kummer

Entscheidung auf Basis Kosten/Nutzen-Rechnung: Mglichkeit B Problem gelst.

Munin Plugin

Server-MonitoringSoftware Ausgabe mithilfe von Graphen Plugins einfach zu schreiben in Skriptsprachen

Munin Plugin

Pro:

Funktioniert, ist simpel Zeigt nur Anzahl der Clients, nicht welche Benutzer online sind Alle 5 Minuten kommt ein Benutzer online der dann wieder verschwindet suboptimal weil nervig

Contra:

Fazit: unschn, aber funktioniert

Funktionieren die fertigen Lsungen auch?


Schon (1 von 3) aber sie sind nicht das, was ich will.

Kann ich das selbst vlt. Besser?

Aus Prinzip: Ja. Gesunde Realittsdissonanz lst unberwindbare Probleme automatisch. Ziel: In PHP entwickeltes Interface, welches Channels und Benutzer anzeigt Quintessenz: Automatische Aktualisierung

Ergebnis:

Realisierung?

Entwicklung eines TS3-Bots in PHP als Konsolenanwendung Erstellt ein Socket und verbindet zum TS-Server Wartet Handshake ab Whlt virtuellen Server aus Liest Informationen ber sich selbst aus zwecks Fernsteuerung Aktivierung eines Event-Listeners auf private Nachrichten

Realisierung?

Integration eines Timerbasierten Prozesses

Ruft alle 2 Minuten die Channel-Liste und die Benutzer-Liste ab (Polling)

Problem: Datenspeicherung? bertragung der Daten zum Webfrontend?

Lsung A: MySQL-Datenbank

Vorteil:

Daten auch verfgbar, wenn Bot nicht aktiv Synchronisation mit TS3-eigener SQLite-Datenbank mglich

Warum nicht gleich aus der eigenen DB lesen?

Weil gelocked, ausserdem selten aktuell

Nachteil:

Vieeeel Traffic und Overhead Inakzeptabel

Lsung B: MemCacheD

Arbeitsspeicherbasierter Schlssel-WerteSpeicher Perfekte Untersttzung seitens PHP, geringer Overhead Skaliert ber Serverfarmen sehr gut Nachteile:

Daten haben Ablaufdatum (mitunter Vorteil) Daten nicht persistent

Realisierung?

Client legt Daten in Arrays ab, die serialisiert auf dem MemCacheD gespeichert werden Webfrontend ruft Daten aus dem MemCacheD ab AJAX-Backend liefert ebenfalls Daten aus dem MemCacheD als JSON zurck Ziel erfllt Perfekt?

Probleme

Unzufriedenheit, da der Eventlistener Ergebnisse liefern kann, whrend Daten geliefert werden:

Client: channellist Server: [kanalliste] Server: notifytextmessage invokerid=42 msg=test Server: error id=0 msg=No\sError

Problemlsung?

Daten auf gngige Events prfen und anschlieend annehmen, dass es Nutzdaten sind?

Inakzeptabel, da nicht Aufwrtskompatibel

Daten einmal abrufen und dann aus Events beziehen?

Versuch zeigt auf, dass Events nicht immer reagieren (!) Unschn inakzeptabel

2 Verbindungen, eine fr Daten, eine fr Events?

Folge:

Annahme, dass TS3 ServerQuery ein grausames Protokoll ist, das


Wenig praxistauglich ist Der Grund dafr ist, dass kaum etwas real funktioniert

Darauf hoffen, dass niemand in der aktuellen Lsungen den Bot anschreibt, whrend Daten abgerufen werden Nutzer war bereits mit der aktuellen Lsung vollauf zufrieden