Posts by Sebbo

Zusätzlich geht nicht. Man kann jedem Client nur genau eine Channelgruppe zuweisen. Du kannst einem Client jedoch mehrere Servergruppen zuweisen.

deeMcee hat oben (klick) erklärt, wie du die Channelgruppe eines Clients ändern kannst. Über den TeamSpeak Client.

In YatQA kannst du das über das Menü "Client-Channelgruppen" tun:

1. YatQA starten
2. Auf einen TeamSpeak Server verbinden, auf dem du Rechte hast, Channelgruppen eines Benutzers zu ändern
3. Tab "Rechte" öffnen
4. Seitenmenü "Client-Channelgruppen" öffnen
5. Client über das Suchfeld finden, um dessen Rechte pro Channel einzusehen
6. Channel wählen, wo du ihm andere Channelgruppen zuweisen möchtest
7. Doppelklick auf den Channel und die neue Channelgruppe wählen und mit "OK" bestätigen

Mhmm, also aus meiner Sicht ist das eigentlich alles gut und logisch strukturiert / aufgebaut. Man muss sich halt entsprechend mit der Materie erstmal auseinander setzen, damit man den Aufbau und die Funktionen versteht.

// Off-Topic

Ich muss einerseits deeMcee zustimmen:

Quote from deeMcee

Also meine Empfehlung ist ebenfalls, bevor du dich mit YatQA großartig beschäftigst, solltest du dich erstmal mit Teamspeak selber beschäftigen.

...aber andererseits muss ich auch Treptowers zustimmen:

Quote from Treptowers

Allerdings ist für mich ein Forum da um Fragen zu stellen.

Genau so sehe ich das auch. Es sind auch alles valide und gute Fragen.

Aber gegen etwas Eigeninitiative habe ich auch nichts: Schau dir ein paar Tutorials an, schau dir die Dokumentationen an, spiele etwas mit TeamSpeak rum und lerne es kennen.

Guten Abend,

YatQA hat auch eine Bedienungsanleitung: https://yat.qa/manual/

Es macht vermutlich mehr Sinn, sich diese einmal anzuschauen, als jede einzelne Funktion hier zu erfragen.

Die Channelgruppe eines Benutzers kannst du wie folgt über YatQA ändern:

1. YatQA starten
2. Auf einen TeamSpeak Server verbinden, auf dem du Rechte hast, Channelgruppen eines Benutzers zu ändern
3. Tab "Benutzers" öffnen
4. Benutzer anklicken, dessen Channelgruppe du ändern möchtest
5. Rechts oben im Bereich "Channel" auf "Gruppe" klicken
6. Im Popup Fenster die neue Gruppe auswählen, die der Benutzer erhalten soll und mit "OK" bestätigen

PS: Das kannst du übrigens im TeamSpeak Client auch machen. Das benötigt nicht extra andere Tools wie YatQA.

Hallo,

woher hast du denn die Info, dass die "Server Admin" Gruppe die Power von 75 hat? Auf die selbe Art und Weise stellst du das auch für andere Gruppen fest.

Bitte beachte, dass du das "erweiterte Rechtesystem" hierfür in deinem TeamSpeak Client aktiviert haben musst.

An sich gehst du wie folgt vor:

1. TeamSpeak Client starten
2. Auf einen TeamSpeak Server verbinden, wo du entsprechende Rechte hast, die Server Gruppen Rechte einzusehen
3. Im Menü vom TeamSpeak Client: Rechte > Servergruppen

Dort kannst du dann jede existierende Servergruppe auswählen und entsprechend prüfen, welche Rechte welche Gruppe hat. Unter anderen siehst du dort auch, welche Power jede Gruppe für welche Rechte hat.

PS: Eine Servergruppe kann auch mehrere, unterschiedliche Power-Werte haben. Es muss nicht alles z.B. 50 sein. Es kann auch sein, dass "Channel Erstellen" z.B. 75 hat, während "Group Modify" beispielsweise nur 50 und "Ban Clients" wiederum nur 40 hat.

Das deutet in der Regel auf ein falsches Passwort hin. Ich bin mir nicht sicher, ob die Meldung auch geloggt wird, wenn der Client beim Login in einen Timeout läuft.

Dann ist das Problem ein Verbindungstimeout. Der Server antwortet nicht innerhalb von 5 Sekunden.

Das ist aber sehr seltsam, weil du ja mit einem anderen ServerQuery User das Problem nicht hast.

Wie gesagt: Die Logs auf dem Server sollten dazu mehr Auskunft geben und das Problem erklären. Aber nur von der Client Seite ist das recht schwer einzugrenzen und zu debuggen.

Quote from Treptowers

gebannt bin ich auch nicht.

Ich gehe davon aus, dass du das nicht einfach nur annimmst, sondern es geprüft hast.

Nur weil User A sich anmelden kann, heißt das noch lange nicht, dass User B das dann auch kann. Kann ja trotzdem sein, dass er gebannt ist, der Login falsch ist oder dass es den Benutzer z.B. nicht mehr gibt.

Quote from Treptowers

TS ist erreichbar sonst würde ich mit dem serveradmin nicht draufkommen.

Ok, guter Punkt.

Quote from Treptowers

Flood Limit ... wenn 3 mal einloggen am Tag das bewirkt ?

Bereits einmal einloggen kann bewirken, dass man sofort gebannt wird.

Es ist immer die Frage, was das Tool/Programm im Hintergrund alles macht (z.B. Instanz-Infos, Serverliste etc. abrufen).

Quote from Treptowers

Zum anderen Part ... Du kommst ja noch auf den Server drauf

Was meinst du damit? Welcher Part und wer kommt wie wo drauf?

Was sprechen die genannten Logs vom TeamSpeak, wie bereits angefragt?

Hallo,

normalerweise hängt sich YatQA immer nur dann auf, wenn der TeamSpeak Server nicht erreichbar ist und der Verbindungsversuch quasi austimed, die Login-Daten ungültig / falsch sind oder wenn der TeamSpeak Server den Client (also dich und dein YatQA) gebannt hat, weil du z.B. das Flood Limit erreicht hast.

Da müsste man mal die Log von der Instanz, sowie des virtuellen Servers prüfen und auch mal testen, was eine normale telnet/SSH Verbindung mittels des ServerQuery Benutzers zurück liefert, wenn YatQA nicht mehr reagiert. Da sollte z.B. sowas wie "Du bist gebannt, versuche es in 299 Sekunden nochmal." kommen. In Englischer Sprache natürlich.

Hallo!

Dieser Artikel gibt eine kurze Einleitung in das Thema "TeamSpeak WebQuery API". Eine mögliche Alternative für die ts3admin.class und das TS3PHPFramework.

Quote from TeamSpeak Server CHANGELOG

## Server Release 3.12.0 18 March 2020

### Important

- New feature WebQuery that allows user to access to query system using http(s) and json.

Die WebQuery API ist seit März 2020 (TeamSpeak Server Version 3.12.0 und neuer) neben den klassischen ServerQuery Schnittstellen Telnet (query_protocols=raw; Standard Port 10011/TCP; unverschlüsselt) und SSH (query_protocols=ssh, Standard Port 10022/TCP; verschlüsselt) eine weitere Schnittstelle, um ServerQuery Befehle auszuführen.

Man kann mit Hilfe der WebQuery API zum Beispiel...

• einen neuen virtuellen Server anlegen, bearbeiten, stoppen, wieder starten und löschen
• Servereinstellungen ändern
• Statistiken, wie z.B. die Anzahl der insgesamt verbundenen Clients, Traffic, Latenzen, Packetloss und vieles mehr abfragen
• Clients ent-/bannen
• Servergruppen verwalten
• und vieles mehr.

Die WebQuery API ist dabei über einfaches HTTP (query_protocols=http; Standard Port 10080/TCP; unverschlüsselt) oder auch mit etwas Aufwand (man benötigt ein SSL Zertifikat) über HTTPS (query_protocols=https; Standard Port 10443/TCP; verschlüsselt) erreichbar. Übergeben tut man der API Header, POST/GET Variablen, JSON Datensätze und erhält eine entsprechende Antwort im JSON Format.

Insgesamt soll die WebQuery API gegenüber der klassischen raw und ssh Verbindung bei API Aufrufen um einiges schneller sein, da man dazwischen z.B. keine PHP Klasse(n) mehr benötigt und somit z.B. auch weniger Overhead beim programmieren hat.

So, aber wie fängt man jetzt an? Wie kann man diese WebQuery API benutzen?

Voraussetzung hierfür ist natürlich erstmal, dass die WebQuery API serverseitig aktiviert ist. Lest hierzu entweder in der Dokumentation vom Server nach oder fragt euren Hoster/Betreiber des TeamSpeak Servers, ob diese entsprechend aktiviert ist.

Danach benötigt ihr nur noch ein paar grundlegende Programmierfähigkeiten mit (REST) APIs, sowie einen API Key für den entsprechenden TeamSpeak Server, auf welchem ihr die API Befehle entsprechend ausführen wollt.

So einen API Key könnt ihr mittels eures ServerQuery Benutzer erstellen. Loggt euch hierfür z.B. mit SSH auf die ServerQuery Schnittstelle ein:

# ssh <ServerQuery Username>@<IP oder DNS Adresse vom TeamSpeak Server>
ssh serveradmin@mein-teamspeak.de

...und generiert euch einen API Key:

# apikeyadd scope={manage|write|read} [lifetime={days}] [cldbid={clientDBID}]
apikeyadd scope=manage lifetime=180

Das "Scope" definiert in diesem Fall die Rechte, die dieser API Key erhalten soll:

• manage: Maximaler Zugriff; Administrator-Rechte
• write: Einige Schreibrechte werden vergeben, jedoch nicht alle.
• read: Nur lesende Funktionen sind aufrufbar

Um herauszufinden, welches Scope man tatsächlich benötigt, kann man in diese Liste schauen:

Quote from davinciTS@community.teamspeak.com

{ "apikeyadd", { manage_scope, } },

{ "apikeydel", { manage_scope, } },

{ "apikeylist", { manage_scope, } },

{ "banadd", { manage_scope, write_scope, } },

{ "banclient", { manage_scope, write_scope, } },

{ "bandel", { manage_scope, write_scope, } },

{ "bandelall", { manage_scope, write_scope, } },

{ "banlist", { manage_scope, write_scope, read_scope, } },

{ "bindinglist", { manage_scope, read_scope } },

{ "channeladdperm", { manage_scope, } },

{ "channelclientaddperm", { manage_scope, } },

{ "channelclientdelperm", { manage_scope, } },

{ "channelclientpermlist", { manage_scope, write_scope, read_scope, } },

{ "channelcreate", { manage_scope, write_scope, } },

{ "channeldelete", { manage_scope, write_scope, } },

{ "channeldelperm", { manage_scope, } },

{ "channeledit", { manage_scope, write_scope, } },

{ "channelfind", { manage_scope, write_scope, read_scope, } },

{ "channelgroupadd", { manage_scope, write_scope, } },

{ "channelgroupaddperm", { manage_scope, } },

{ "channelgroupclientlist", { manage_scope, write_scope, read_scope, } },

{ "channelgroupcopy", { manage_scope, } },

{ "channelgroupdel", { manage_scope, } },

{ "channelgroupdelperm", { manage_scope, } },

{ "channelgrouplist", { manage_scope, write_scope, read_scope, } },

{ "channelgrouppermlist", { manage_scope, write_scope, read_scope, } },

{ "channelgrouprename", { manage_scope, } },

{ "channelinfo", { manage_scope, write_scope, read_scope, } },

{ "channellist", { manage_scope, write_scope, read_scope, } },

{ "channelmove", { manage_scope, write_scope, } },

{ "channelpermlist", { manage_scope, write_scope, read_scope, } },

{ "clientaddperm", { manage_scope, } },

{ "clientdbdelete", { manage_scope, write_scope, } },

{ "clientdbedit", { manage_scope, write_scope, } },

{ "clientdbfind", { manage_scope, write_scope, read_scope, } },

{ "clientdbinfo", { manage_scope, write_scope, read_scope, } },

{ "clientdblist", { manage_scope, write_scope, read_scope, } },

{ "clientdelperm", { manage_scope, } },

{ "clientedit", { manage_scope, write_scope, } },

{ "clientfind", { manage_scope, write_scope, read_scope, } },

{ "clientgetdbidfromuid", { manage_scope, write_scope, read_scope, } },

{ "clientgetids", { manage_scope, write_scope, read_scope, } },

{ "clientgetnamefromdbid", { manage_scope, write_scope, read_scope, } },

{ "clientgetnamefromuid", { manage_scope, write_scope, read_scope,} },

{ "clientgetuidfromclid", { manage_scope, write_scope, read_scope, } },

{ "clientinfo", { manage_scope, write_scope, read_scope, } },

{ "clientkick", { manage_scope, write_scope, } },

{ "clientlist", { manage_scope, write_scope, read_scope, } },

{ "clientmove", { manage_scope, write_scope, } },

{ "clientpermlist", { manage_scope, write_scope, read_scope, } },

{ "clientpoke", { manage_scope, write_scope, } },

{ "clientsetserverquerylogin", { manage_scope, write_scope, } },

{ "clientupdate", { manage_scope, write_scope, } },

{ "complainadd", { manage_scope, write_scope, } },

{ "complaindel", { manage_scope, write_scope, } },

{ "complaindelall", { manage_scope, write_scope, } },

{ "complainlist", { manage_scope, write_scope, read_scope, } },

{ "custominfo", { manage_scope, write_scope, read_scope, } },

{ "customsearch", { manage_scope, write_scope, read_scope, } },

{ "customset", { manage_scope, write_scope, } },

{ "customdelete", { manage_scope, write_scope, } },

{ "ftcreatedir", not_supported },

{ "ftdeletefile", not_supported },

{ "ftgetfileinfo", not_supported },

{ "ftgetfilelist", not_supported },

{ "ftinitdownload", not_supported },

{ "ftinitupload", not_supported },

{ "ftlist", not_supported },

{ "ftrenamefile", not_supported },

{ "ftstop", not_supported },

{ "gm", { manage_scope, } },

{ "help", { manage_scope, write_scope, read_scope, } },

{ "hostinfo", { manage_scope, write_scope, read_scope, } },

{ "instanceedit", { manage_scope, } },

{ "instanceinfo", { manage_scope, write_scope, read_scope, } },

{ "logadd", { manage_scope, write_scope, } },

{ "login", not_supported },

{ "logout", not_supported },

{ "logview", { manage_scope, write_scope, read_scope, } },

{ "messageadd", { manage_scope, write_scope, } },

{ "messagedel", { manage_scope, write_scope, } },

{ "messageget", { manage_scope, write_scope, read_scope, } },

{ "messagelist", { manage_scope, write_scope, read_scope, } },

{ "messageupdateflag", { manage_scope, write_scope, } },

{ "permfind", { manage_scope, write_scope, read_scope, } },

{ "permget", { manage_scope, write_scope, read_scope, } },

{ "permidgetbyname", { manage_scope, write_scope, read_scope, } },

{ "permissionlist", { manage_scope, write_scope, read_scope, } },

{ "permoverview", { manage_scope, write_scope, read_scope, } },

{ "permreset", { manage_scope, } },

{ "privilegekeyadd", { manage_scope, write_scope, } },

{ "privilegekeydelete", { manage_scope, write_scope, } },

{ "privilegekeylist", { manage_scope, write_scope, read_scope, } },

{ "privilegekeyuse", { manage_scope, write_scope, } },

{ "queryloginadd", { manage_scope, write_scope, } },

{ "querylogindel", { manage_scope, write_scope, } },

{ "queryloginlist", { manage_scope, write_scope, read_scope } },

{ "quit", not_supported },

{ "sendtextmessage", { manage_scope, write_scope, } },

{ "servercreate", { manage_scope, } },

{ "serverdelete", { manage_scope, } },

{ "serveredit", { manage_scope, write_scope, } },

{ "servergroupadd", { manage_scope, } },

{ "servergroupaddclient", { manage_scope, } },

{ "servergroupaddperm", { manage_scope, } },

{ "servergroupautoaddperm", { manage_scope, } },

{ "servergroupautodelperm", { manage_scope, } },

{ "servergroupclientlist", { manage_scope, } },

{ "servergroupcopy", { manage_scope, } },

{ "servergroupdel", { manage_scope, } },

{ "servergroupdelclient", { manage_scope, } },

{ "servergroupdelperm", { manage_scope, } },

{ "servergrouplist", { manage_scope, } },

{ "servergrouppermlist", { manage_scope, } },

{ "servergrouprename", { manage_scope, } },

{ "servergroupsbyclientid", { manage_scope, } },

{ "serveridgetbyport", { manage_scope, } },

{ "serverinfo", { manage_scope, } },

{ "serverlist", { manage_scope, } },

{ "servernotifyregister", not_supported },

{ "servernotifyunregister", not_supported },

{ "serverprocessstop", { manage_scope, } },

{ "serverrequestconnectioninfo", { manage_scope, write_scope, read_scope, } },

{ "serversnapshotcreate", { manage_scope, } },

{ "serversnapshotdeploy", { manage_scope, } },

{ "serverstart", { manage_scope, } },

{ "serverstop", { manage_scope, } },

{ "servertemppasswordadd", { manage_scope, write_scope, } },

{ "servertemppassworddel", { manage_scope, write_scope, } },

{ "servertemppasswordlist", { manage_scope, write_scope, read_scope, } },

{ "setclientchannelgroup", { manage_scope, write_scope, } },

{ "tokenadd", { manage_scope, write_scope, } },

{ "tokendelete", { manage_scope, write_scope, } },

{ "tokenlist", { manage_scope, write_scope, read_scope, } },

{ "tokenuse", { manage_scope, write_scope, } },

{ "use", not_supported },

{ "version", { manage_scope, write_scope, read_scope, } },

{ "whoami", { manage_scope, write_scope, read_scope, } },

Display More

Die Lifetime definiert, wie lange dieser API Key in Tagen gültig ist. 0 bedeutet, dass er nie abläuft.

Die optionale cldbid definiert dann noch, wer der Eigentümer dieses API Keys ist. Standardmäßig gehört er immer dem User, der ihn auch erstellt.

Gut. Ihr solltet jetzt einen API Key haben, der wie dieser z.B. aussieht: AQB8J1sfuvq4wFAFdo6rsfFq+jAQO9asz3zGq5X

Wie gesagt: Die API kann man auf verschiedenste Art und Weise ansprechen:

• curl
• PHP
• JavaScript
• jQuery
• NodeJS
• Postman
• ...

Wir werden das ganze von einer Befehlszeile aus machen, also nutzen wir in diesem Beispiel einfach mal curl (https://linux.die.net/man/1/curl).

Dann starten wir doch mal mit einem einfachen API Request: Wer bin ich, der sich hier per API eingeloggt hat?

❯ curl -s -H 'x-api-key: AQB8J1sfuvq4wFAFdo6rsfFq+jAQO9asz3zGq5X' 'http://127.0.0.1:10080/whoami'
{"body":[{"client_channel_id":"0","client_database_id":"1","client_id":"0","client_login_name":"<internal>","client_nickname":"","client_origin_server_id":"0","client_unique_identifier":"serveradmin","virtualserver_id":"0","virtualserver_port":"0","virtualserver_status":"unknown","virtualserver_unique_identifier":""}],"status":{"code":0,"message":"ok"}}

So, das hat schon mal funktioniert. Jetzt formatieren wir das JSON aber noch schön, damit es lesbarer ist. Das geht ganz einfach mit json_pp:

❯ curl -s -H 'x-api-key: AQB8J1sfuvq4wFAFdo6rsfFq+jAQO9asz3zGq5X' 'http://127.0.0.1:10080/whoami' | json_pp
{
   "status" : {
      "code" : 0,
      "message" : "ok"
   },
   "body" : [
      {
         "client_origin_server_id" : "0",
         "client_channel_id" : "0",
         "virtualserver_unique_identifier" : "",
         "virtualserver_id" : "0",
         "virtualserver_status" : "unknown",
         "virtualserver_port" : "0",
         "client_unique_identifier" : "serveradmin",
         "client_login_name" : "<internal>",
         "client_database_id" : "1",
         "client_nickname" : "",
         "client_id" : "0"
      }
   ]
}

Wie wir sehen, bekommen wir von der API zwei "Blöcke" zurück:

1. status: Hier kann man sehen und prüfen, ob der API Request erfolgreich war oder Fehler auftraten.
2. body: Hier werden immer die angeforderten Daten von der API zurück geliefert. In unserem Beispiel von whoami.

Holen wir uns mal die Liste aller virtuellen Server auf dieser TeamSpeak Instanz:

❯ curl -s -H 'x-api-key: AQB8J1sfuvq4wFAFdo6rsfFq+jAQO9asz3zGq5X' 'http://127.0.0.1:10080/serverlist' | json_pp
{
   "body" : [
      {
         "virtualserver_autostart" : "1",
         "virtualserver_queryclientsonline" : "1",
         "virtualserver_uptime" : "5490154",
         "virtualserver_clientsonline" : "3",
         "virtualserver_id" : "2",
         "virtualserver_machine_id" : "1",
         "virtualserver_maxclients" : "30",
         "virtualserver_port" : "9987",
         "virtualserver_status" : "online",
         "virtualserver_name" : "TEST TeamSpeak"
      },
      {
         "virtualserver_uptime" : "5490153",
         "virtualserver_autostart" : "1",
         "virtualserver_queryclientsonline" : "1",
         "virtualserver_id" : "4",
         "virtualserver_clientsonline" : "1",
         "virtualserver_machine_id" : "1",
         "virtualserver_maxclients" : "10",
         "virtualserver_status" : "online",
         "virtualserver_name" : "Mein TeamSpeak",
         "virtualserver_port" : "9988"
      },
      {
         "virtualserver_autostart" : "0",
         "virtualserver_queryclientsonline" : "1",
         "virtualserver_uptime" : "246850",
         "virtualserver_clientsonline" : "1",
         "virtualserver_id" : "5",
         "virtualserver_machine_id" : "1",
         "virtualserver_maxclients" : "10",
         "virtualserver_port" : "9989",
         "virtualserver_name" : "Best TeamSpeak EU",
         "virtualserver_status" : "online virtual"
      }
   ],
   "status" : {
      "message" : "ok",
      "code" : 0
   }
}

Und jetzt mal die clientlist vom TeamSpeak Server mit der virtualserver_id = 4:

❯ curl -s -H 'x-api-key: AQB8J1sfuvq4wFAFdo6rsfFq+jAQO9asz3zGq5X' 'http://127.0.0.1:10080/4/clientlist' | json_pp
{
   "status" : {
      "code" : 0,
      "message" : "ok"
   },
   "body" : [
      {
         "client_nickname" : "Sebbo",
         "client_database_id" : "63",
         "cid" : "52",
         "clid" : "26679",
         "client_type" : "0"
      },
      {
         "cid" : "59",
         "client_type" : "1",
         "clid" : "22469",
         "client_nickname" : "serveradmin",
         "client_database_id" : "1"
      }
   ]
}

Je nachdem, was man da jetzt alles machen möchte, muss man sich die Dokumentation der ServerQuery Befehle anschauen und seinen API Request entsprechend bauen.

Weitere Beispiele und Informationen zur WebQuery API liefert z.B. der TeamSpeak Server in der mitgelieferten doc/webquery.md Datei.

Ansonsten könnt ihr auch gerne eure persönlichen Fragen in einem neuen Thema stellen.

In diesem Sinne: Happy Coding!

Kein Problem.

Guten Abend/Morgen,

kostenlose Musikbots fallen mir gerade nur diese ein:

• Sinusbot: https://www.sinusbot.com/
• TS3AudioBot: https://github.com/Splamy/TS3AudioBot

Das Problem ist: Alle haben die Anforderung eines 64-Bit Systems. Ein 32-Bit System ist heutzutage nicht mehr üblich.

Wieso installiert ihr nicht einfach die 64-Bit Version des Betriebssystems? Ein Windows Lizenz-Schlüssel ist NICHT an 32- oder 64-Bit gebunden. Man kann damit beide Versionen aktivieren. Nur die zu installierende Windows Version und Edition ist wichtig. Also Server 2019 Standard oder Essentials z.B..

Quote from Treptowers

Hintergrund ist das der TS3 Host vom PC auf Laptop umgezogen ist wegen Stromkosten

Dann sollte man sich vielleicht gleich einen richtigen Server im Rechenzentrum mieten. Die haben eine statische (feste) IP Adresse (man braucht also kein dynamisches DNS), es wird kein NAT benötigt, sie haben eine bessere Anbindung, in der Regel auch eine bessere Verfügbarkeit und sind oftmals günstiger als wenn man Daheim irgendwas 24x7 betreibt.

Also wenn der Strompreis bei z.B. "nur" 0,25 € pro kWh liegt (ich persönlich zahle 0,27 €/kWh aktuell) und das Notebook ein sehr kleines Netzteil mit nur 45 Watt hat, dann kommt man auf Stromkosten von 7,56 € pro Monat.

Da kriege ich bei manchen Anbietern fast 8 vServer im Rechenzentrum für diese monatlichen Kosten. Je nach Anzahl von CPU, RAM und Speicher. Aber für ca. 4-5 € im Monat kriegt man meistens etwas sehr brauchbares, wo man nen TeamSpeak Server, Sinusbot und ggfs. noch etwas drauf laufen lassen kann, ohne dass der Server gleich am Hardware Limit läuft.

Natürlich muss sich dann um den Server im Rechenzentrum auch jemand kümmern, damit dieser nicht gehackt und als z.B. Botnetz Server missbraucht wird. Das kann für den Mieter des Servers (also ihr in diesem Fall) ziemlich schnell, ziemlich teuer werden, weil ihr für alles haftet, was auf und mit diesem Server passiert. Der Server sollte daher gut konfiguriert (Firewall, eingeschränkter Zugriff, ...) und regelmäßig geupdated werden.

Super, freut mich.

Guten Abend Stefan,

diese Passwörter kannst du nirgends einsehen.

Wenn du dir einen neuen ServerQuery Login mit dem selben Namen erstellst, wirst du ein neues Passwort erhalten.

Am besten notierst du dir das irgendwo.

Servus,

ich kenne mich mit dem Sinusbot nicht mehr aus, da ich ihn seit der damaligen ersten Version nicht mehr angerüht habe, aber der Cronjob sollte so in der Art aussehen:

30 6 * * * sinusbot /home/sinusbot/restart_command

Erklärung:

• 30 6 * * *: Cronjob wird jeden Tag um 06:30 Uhr morgens (in der Zeitzone des Linux Host Systems) ausgeführt
• sinusbot: Der Linux User, der den Cronjob Befehl ausführen soll
• /home/sinusbot/restart_command: Der Linux Befehl, der ausgeführt werden soll

So, wie du normalerweise den Sinusbot neustartest, kannst du den Linux Befehl einfach 1:1 in die Cronjob Datei reinpacken.

Um das ganze zu testen, empfehle ich erstmal eine Uhrzeit zu konfigurieren, die bald ist, damit du gleich verifizieren kannst, ob der Cronjob entsprechend funktioniert, wie er soll. Alternativ kannst du ihn auch einfach alle 5 Minuten z.B. neustarten lassen, um es zu testen:

*/5 * * * * sinusbot /home/sinusbot/restart_command

Mit einem tail -f /var/log/syslog | grep -i cron solltest du dann auch in der Syslog sehen, ob der Restart-Befehl entsprechend ausgeführt wurde oder nicht. Ist dies der Fall, musst du nur noch prüfen, ob der Sinusbot tatsächlich neugestartet wurde oder nicht. Wenn es nicht geklappt hat, dann liegt es meistens an einem Linux Befehl, der nicht in der PATH-Variable des Cronjobs bekannt ist. Ich empfehle daher immer die absoluten Pfade zu verwenden (Beispiel: wget -> /usr/bin/wget; findest du mit which wget raus).

Wenn alles funktioniert, wie es soll, musst du nur noch die Uhrzeit im Cronjob entsprechend setzen, wie du es gerne hättest.

PS: Eine ganz hilfreiche Seite, um Cronjob-Definitionen zu bauen: https://crontab-generator.org/

Achso, ok. Gut, dann muss er dummerweise immer manuell neu gesetzt werden.

Ohje...

Danke, ich winke mal aus ca. 40 Kilometer südlicher Entfernung zurück. Die sollte ja aktuell schön beleuchtet sein.

Hallo Stefan,

das ist letztendlich die selbe Funktion, die ich auch genannt habe.

Es gibt nur einen kleinen Unterschied:

• Einstellungen (mein Lösungsvorschlag): Der Name wird permanent im YatQA gespeichert und autom. gesetzt, sobald man sich auf einen virtuellen Server verbindet. Er ist auch noch gesetzt, wenn man YatQA schließt und wieder öffnet.
• Sonstiges (dein Lösungsanschlag): Der Name wird nur temporär durch YatQA gesetzt. Sobald man sich vom virtuellen Server trennt (oder einen anderen selektiert) oder auch einfach nur YatQA neu öffnet, ist der Name nicht mehr gesetzt und muss wieder neu gesetzt werden.

Wenn du also nicht jedes mal den Namen ändern oder an die Einstellung denken möchtest, dann solltest du den Namen in den Einstellungen hinterlegen, wie ich es beschrieben hatte.

Ja, weil du stoppst nur den virtuellen Server auf der Instanz. Die Instanz selbst läuft aber weiter und auf die verbindest du dich im YatQA.

Hallo Stefan,

öffne mal YatQA und schau da mal links im Menü nach "Einstellungen...".

Da kannst du links unten den gewünschten Namen im Feld "Eigenen Benutzernamen beim Betreten ändern zu:" setzen.

pasted-from-clipboard.png

Mittels einer CLI, also telnet (raw) oder SSH muss man folgenden Befehl ausführen, NACHDEM man sich auf einen virtuellen Server verbunden hat:

clientupdate client_nickname=Admin\sMax

Leerzeichen im Namen müssen durch \s ersetzt werden.

Hallo!

Nur, um das etwas deutlicher zu erklären:

• Du hast einen "Server", den man in der Regel auch das "Host-System" nennt (z.B. einen vServer im Rechenzentrum, ein altes Notebook Daheim, einen Raspberry Pi, oder oder oder)
• Auf diesem Host-System (z.B. vServer oder Notebook) können mehrere Dienste wie z.B. ein Webserver, Minecraft Server oder eben auch ein TeamSpeak 3 Server laufen
• Anhand eines TeamSpeak Servers: Dieser besteht aus der eigentlichen Instanz, welche einen oder mehrere virtuelle TeamSpeak Server bereitstellt. Ein virtueller TeamSpeak Server ist dabei der TeamSpeak Server, auf den sich die Benutzer (Clients) später per IP Adresse / DNS (und Port z.B. 9987) verbinden.

Wie startet man nun was neu? Da der Aufbau immer etwas anders sein kann, nachfolgend nur grob angerissen:

• Host-System (z.B. vServer oder Notebook)
  • Direkt mit Tastatur (und Maus) an das Host-System gehen (wenn physisch erreichbar, was es bei einem lokalen Notebook z.B. der Fall ist)
  • Per Remotedesktop (bei Windows Systemen)
  • Per SSH (bei Linux Systemen)
  • Je nach Betriebssystem dann entweder über eine grafische Oberfläche (z.B. Windows: Start > Power > Neu starten) oder über eine CLI (Command Line; z.B. Linux: sudo reboot)
• TeamSpeak Server Instanz (der eigentliche Service auf dem Host-System)
  • Windows: Rechts unten in der Task-Leiste z.B. den "TeamSpeak Server" Prozess beenden und dann per Doppelklick die "ts3server.exe" wieder starten (natürlich kann man sich dafür auch einen Windows-Dienst anlegen)
  • Linux: ./ts3server_startscript.sh stop und ./ts3server_startscript.sh start oder ./ts3server_startscript.sh restart
• Virtueller TeamSpeak Server
  • ServerQuery (raw (telnet) / SSH)
    • Stoppen: serverstop sid=<serverID> reasonmsg=Stop\sGrund
    • Starten: serverstart sid=<serverID>
  • Diverse Webinterfaces wie z.B. Psychokiller's Webinterface bieten diverse Start/Stop Knöpfe, um den virtuellen Server neuzustarten
  • YatQA
    • Auf die TeamSpeak Instanz verbinden
    • Oben auf "Server" klicken und dort sieht man die Liste aller verfügbaren virtuellen TeamSpeak Server auf dieser spezifischen Instanz
    • Hier einfach den virtuellen TS Server auswählen und rechts im Menü "Stoppen" und danach wieder "Starten" anklicken

Im YatQA gab es noch nie einen "Neustarten" Knopf. Nur "Stoppen" und "Starten".

Dieser "Not-Aus" Knopf auf der Statistiken-Seite direkt nach dem verbinden auf eine Instanz killt quasi den Prozess der TeamSpeak Instanz. Um ihn danach wieder zu starten, muss man sich auf das Host-System verbinden und ihn entsprechend wieder manuell starten. YatQA kann nicht mehr auf die Instanz zugreifen und kann somit praktisch gesehen auch nichts starten.