Beiträge von ScP

Ich würde hier nicht virtualserver_uptime, sondern virtualserver_created verwenden.

Nur mal zum Vergleich...

<?php


if(isset($_POST['btnResetServergroupPermissions'])) {
  try {
    $ts3 = TeamSpeak3::factory('serverquery://serveradmin:password@192.168.178.10:10011/');
    $key = $ts3->serverGetById($_POST['sid'])->permReset();

    $sqlResetPermissions = '<p>Rechte wurden zurückgesetzt... Token: ' . $key . '</p>';
  }
  catch(Exception $e) {
    $sqlResetPermissions = '<p>Rechte wurden nicht zurückgesetzt... Fehler: ' . $e->getMessage() . '</p>';
  }
}

Das Ganze könnte man auch noch weiter abkürzen.

Ich denke das Problem hängt mit der Anzahl an offenen Dateien zusammen. Was sagt "ulimit -n"?

Ich habe mir jetzt nicht den kompletten Thread durchgelesen... Fass doch mal bitte kurz folgende Infos für mich zusammen:

- Handelt es sich um einen vServer?
- Bei welchem Provider steht die Kiste?
- Wie steht es in Sachen CPU Load?
- Wieviel RAM hat der Server?
- Wie sieht es mit der Performance der Platte aus?
- Sind dem Server mehrere IPs zugewiesen (schick mir einfach mal ne PM falls du sie hier nicht posten willst)?

Grundsätzlich erscheint mir der Wert bei "Puzzle precompute time" etwas sehr hoch... Für den Test der Platten kannst du folgende Befehle verwenden (/dev/sda muss ggf. durch den korrekten Namen ersetzt werden):

sudo hdparm -tT /dev/sda
sudo hdparm -tT --direct /dev/sda

Von der Sache mit den Snapshots rate ich übrigens auch ab. Das Sichern des files Ordners ist zwar keine schlechte Sache, allerdings bekommen Server und Channels bei einem serversnapshotdeploy ggf. neue IDs... Damit ist also sämtliche Zuordnung zu den Ordnern für die Katz'...

Zitat von RootsWin

Ob das wirklich so einfach ist, Das ganze als SQLite Dump in MySQL importieren zu können?

Es ist wie mit allen Dingen im Leben... wenn du weißt was du tust, dann ist es einfach.

Mit "ohne Tabellenstruktur" in meinem letzten Posting meinte ich natürlich nur die INSERTs, da der Rest ja schon von der create_tables.sql erledigt wird... und mit "Standard SQL" wollte ich zum Ausdruck bringen, dass du den Import im ANSI-Modus (kann man glaube ich bei phpMyAdmin direkt auswählen) anstoßen musst. Dann sind auch die double-quoted Tabellennamen kein Problem.

Zitat von RootsWin

Mich würde jedenfalls die Begründung interressieren, wieso MySQL nicht schneller sein sollte als SQLite.

Pauschal kann man das auch nicht sagen. Es kommt auf den jeweiligen Anwendungsfall an. Für TeamSpeak 3 Server lohnt sich das Ganze meiner Meinung nach einfach nicht und man holt sich ggf. mehr Probleme ins Haus. Der Server läuft im produktiven Einsatz weder schneller noch stabiler.

Die einzigen Argumente für MySQL, die ich aus eurer vorherigen Diskussion ziehen kann sind "Kenne ich mich besser mit aus" und "Der Server startet schneller". Da man für SQLite aber nichts konfigurieren muss, gibt es da nicht viel zum "auskennen" und da man den Server im Normalfall nicht ständig neu startet, ist das in meinen Augen auch kein Thema. Wenn man möchte, kann man die SQLite Datenbank ja ab und an mal mit VACUUM bearbeiten um sie wieder schön geschmeidig zu machen (dabei darf der Server allerdings nicht laufen).

Ich würde generell empfehlen die einzelnen TS3 Instanzen nicht zu groß werden zu lassen, d.h. bei rund 100 Voice Servern wird eben mal eine neue Instanz gestartet. Ansonsten bekommt man irgendwann sowieso Probleme mit Dateitransfers. Die sind nämlich fest limitiert (2048 pro Instanz, 768 pro Voice Server, 10 pro Client).

Zitat von Sebbo

woher kriegt man denn die benötigte Datei? Ohne die wird es wohl nicht funktionieren.^^

Die gibts natürlich hier:

Planet TeamSpeak

Da im Titel des Threads aber explizit TS3 PHP Framework steht hab ich mir den Link gespart.

Zitat von Pagian

Wie stellst du dir denn das vor bzw wie würdest du das machen?

Einen Dump der SQLite Datenbanken machen (ohne Tabellenstruktur) und als Standard SQL in die vorher mit der create_tables.sql vorbereiteten MySQL/MariaDB Datenbank importieren. Ist im Grunde eine Sache von 5 Minuten.

Hab's nicht getestet aber das sollte so funktionieren:

<?phprequire_once("lib/TeamSpeak3/TeamSpeak3.php");try{  $ts3 = TeamSpeak3::factory("serverquery://user:pass@host:port/#use_offline_as_virtual");  foreach($ts3 as $sid => $server)  {    try    {      $server->clientListDb();    }    catch(Exception $e)    {      if($e->getCode() != 0x501) throw $e; // ERROR_database_empty_result      echo "Server " . $server . " (id:" . $sid . ") wurde nie besucht.<br />";    }  }}catch(Exception $e){  echo $e->getMessage() . "<br />";}

Grundsätzlich sollte folgendes passieren:

• Verbinden/Anmelden
• Durch Serverliste wandern
• Liste der Clients in der Datenbank abrufen und bei ERROR_database_empty_result einen ungenutzten Server melden (inkl. Name und ID).

Wenn du nur wissen möchtest, ob der Server seit dem letzten Neustart nicht genutzt wurde, sollte das so aussehen:

<?php


require_once("lib/TeamSpeak3/TeamSpeak3.php");


try
{
  $ts3 = TeamSpeak3::factory("serverquery://user:pass@host:port/#use_offline_as_virtual");


  foreach($ts3 as $sid => $server)
  {
    if(!$server->virtualserver_client_connections) echo "Server " . $server . " (id:" . $sid . ") wurde nie besucht.<br />";
  }
}
catch(Exception $e)
{
  echo $e->getMessage() . "<br />";
}

Die Migration von SQLite auf MySQL/MariaDB ist beim TeamSpeak 3 Server absolut unproblematisch... allerdings geht das Ganze andersrum nicht ohne weiteres. Ich würde daher empfehlen gründlich über einen solchen Schritt nachzudenken. Gibt es denn zu den Abstürzen Fehlermeldungen?

Für mich persönlich gibt es selbst bei großen Serverinstanzen keinen besonderen Grund um SQLite den Rücken zu kehren. Ich versuche mal ein paar Pros/Cons für einen Wechsel aufzuzählen:

+ Hosting der Datenbank auf dedizierten Servern
+ Vereinfachter gleichzeitiger Zugriff mehrerer Serverinstanzen auf die gleiche Datenbank (Stichwort machine_id)
- Keine spürbare Performancesteigerung
- Zusätzliche Abhängigkeiten (Neustart des MySQL/MariaDB Servers verursacht ggf. einen Absturz des TS3 Servers)

Es gäbe noch andere Punkte, wie z.B. den einfacheren Zugriff auf die DB durch andere Anwendungen... allerdings würde ich in keinem Fall empfehlen von "außen" an der TS3 Datenbank rumzuwürgen... und schon garnicht während der Server läuft.

Sicherlich kann mit einem MySQL/MariaDB Backend die tollsten Sachen bauen und eine wirklich gut funktionierende redundante Serverstruktur aufbauen... die Frage ist nur, ob sich der Aufwand für einen TeamSpeak 3 Server wirklich lohnt. Sicherungen lassen sich in jedem Fall sehr einfach erstellen und wenn so eine SQLite Datenbank mal kaputt geht, dann schiebt man eben die gesicherte Datei zurück und das Thema ist erledigt. Was die Performance der Sache angeht kann man sich natürlich streiten... ich habe allerdings in meiner Laufbahn noch keinen TS3 Server gesehen, der ohne SQLite höher, weiter und schneller gerannt ist. Bei einer Datenbank mit vielen INSERT und UPDATE Abfragen werden MySQL und MariaDB dem kleinen SQLite sicherlich davonrennen... bei vielen SELECTs sieht das Ganze aber wieder anders aus.

MySQL bzw. MariaDB geben sich in Sachen Performance absolut nichts. MariaDB ist zwar aktueller und wird MySQL langfristig sicher ablösen, verleiht dem Admin momentan aber lediglich ein paar Karmapunkte und kann in bestimmten Konstellationen sogar Kompatibilitätsprobleme mit bestimmter Software verursachen, wenn man wirklich alle Features nutzen möchte. Wenn also schon ein MySQL Server irgendwo "rumliegt", spricht nichts dagegen ihn auch zu benutzen (wenn es denn unbedingt sein muss).

Der Dienst unter update.teamspeak.com liefert nur die jeweils aktuellen Versionen und Buildnummern des Clients aus. Die Buildnummer ist dabei ein Unix Timestamp und gibt an, wann die entsprechende Version kompiliert wurde. Die dort angegebene Versionsinfo für den Server gibt nicht die aktuellste Version, sondern die letzte 100% zu aktuellen Clients kompatible Version an... sie wird also nur geändert, wenn die Entwickler Änderungen am Protokoll oder bestimmten Features vornehmen, die ein Serverupdate zwingend erforderlich machen.

Auf die Version des offiziellen Public Servers würde ich mich hier auch nicht verlassen, da dort auch regelmäßig interne Testversionen laufen.

Wie auch immer... um die wirklich aktuellen *STABLE* Versionen abzufragen biete ich seit einer Weile eine API an:

https://api.planetteamspeak.com/updatecheck

Das ganze ist hier halbwegs dokumentiert:

https://www.planetteamspeak.com/rest-api

Evt. kannst du dir damit ja lästige Arbeit ersparen.

Zitat von par0noid

gerade mal was Offtopic: Sven, du auch hier? Nur einmalig oder gehörst du jetzt auch mit zum Bunde? Dann hat sich das Forum den Titel "Experten-Forum" redlich verdient

Das bleibt abzuwarten...

Ja... war wohl nicht ganz die feine Art im Forum. Das Löschen des Screenshot-Links kann ich noch nachvollziehen (hat ja nicht funktioniert), aber die schlechte Repo wäre nicht nötig gewesen (wobei sich im Grunde auch niemand wirklich dafür interessiert ob da nun 3 rote oder 25 grüne Kästchen angezeigt werden).

Jedenfalls wurde das "X" vorübergehend deaktiviert, weil der neue Qt 5.x basierte Client sozusagen "unsichtbar" wurde. Das heißt der Client wurde minimiert, konnte aber nicht wieder maximiert werden. Das ist im übrigen einer dieser "schnell schnell" Fixes, die ich in meinem Posting hier bemängelt habe. Aber wie auch immer... soll ja noch korrigiert werden.