Beiträge von master_d

    Einfache Möglichkeit.


    Kopiere das "files"-Verzeichnis und die entsprechenden Dateien einfach auf den anderen Server in ein Verzeichnis, dass den entsprechenden Teamspeak-Server enthält.
    Benötigt werden, wie bereits genannt, das "files"-Verzeichnis, ggf. die Ini-Datei zur Konfiguration, die Datenbank-Datei(sqlitedb), falls SQLite benutzt wird, und natürlich die Lizenzdatei. Ebenso aber auch den serverkey (serverkey.dat), und ggf. die Whitelist/blacklist-dateien. Danach sollte beim Start alles wieder so sein wie vorher.


    Falls noch detailliertere Hilfe nötig ist, bin ich auch gerne zu direkter Unterstützung bereit.

    Wenn du bereits mit Channel-Gruppen arbeitest, warum dann nicht einen kleinen Trick ansetzen.


    Entferne die Berechtigung, permanent erstellte Channel zu betreten, aus den Server-Gruppen, und setze das Recht ggf. bei den Channeln wo dies benötigt wird, in den "Channel-Rechten". Danach erstelle eine Channel-Gruppe, die ebenfalls dieses Recht enthält, so dass bei Channeln, die das entsprechende Channel-Recht nicht besitzen, nur Personen mit der entsprechenden Channel-Gruppe den Channel betreten können. Dadurch ist aber auch die Join-Power-Schranke nicht mehr existent, und man kann mit entsprechender Move-Power die Personen in den Channel ziehen.


    Ich setze ein entsprechendes Rechte-Modell selbst ein, und nutze diesen Ansatz für einen Multigaming-Server mit mehreren, sich durchaus überlappenden Gruppierungen. Falls erwünscht, leiste ich auch entsprechende Unterstützung bei der Einrichtung.

    Wenn man das ganze über Teamspeak realisieren möchte, dann muss man dazu eine Verbindung zwischen der Identität in Teamspeak und dem entsprechenden Benutzer auf deiner Website herstellen.
    Wenn dies vorhanden ist, könnte man ein entsprechendes Script erstellen, dass beim entfernen des Zugangs zur Website auch die entsprechende Gruppe auf dem Teamspeak für den entsprechenden Benutzer entfernt.

    After a short test, the server-version is right, so it might be an old client, that triggers this error. But after that, the server is available, so the problem has to be something that is not mentioned here.


    Please post the logfile of the instance, which is not available after this has happened (the log-file with _1, or _2 instead of _0 at the end).

    Die Frage, die sich mir hier stellt ist eher, ob der TS3-Server nach ändern der Whitelist neu gestartet worden ist, bzw. ob die Änderungen der Whitelist korrekt erkannt worden sind.


    Ich empfehle daher, einfach mal das Log des TS3-Servers zu prüfen, ob die eingerichteten Whitelist-Einträge korrekt erkannt worden sind. Normalerweise wird die Whitelist in regelmäßigen Abständen neu eingelesen, aber nach einem Neustart kann man dies am einfachsten am Anfang der Log-Datei ablesen.

    Da es sich um ein Plugin handelt, wird sich die "Kontrollmöglichkeit" eher im Bereich eines IPC-Mechanismus abspielen.


    Möglicherweise ein Socket, ähnlich dem Client-Query-Plugin. Dies könnte vielleicht auch die entsprechende Alternative sein, man muss halt nur schauen, ob dort die entsprechenden Möglichkeiten geboten werden.

    Der Vorschlag war eher in die Richtung, dass es für den Nutzer möglich sein sollte, solche Pattern zu erstellen, und dann selbst auch nutzen zu können. Es können zwar durchaus vorgefertigte Pattern angeboten werden, aber sollten diese auch bearbeitet werden können.


    Und ja, man könnte das als "Rechtevorlagen" verstehen.

    Auch ich hab gerade mal versucht, ein paar Informationen dazu zu finden, kann aber auch keine Quelle nennen.


    Ich denke der einfachere Weg ist solch ein Plugin selbst zu erstellen, und darin die benötigten Funktionen selbst verfügbar machen.


    Was genau möchtest du denn kontrollieren?

    Und als weitere Information, die Berechnung ist nicht "Threaded", d.h. die Berechnung wird nur in einem einzigen Prozess abgehandelt, so dass "Multi-Core-Systeme" hier keinen Vorteil bieten. Die Geschwindigkeit der Berechnung skalliert nur am Prozessor-Takt, so dass der Zeitoptimierung hier Grenzen gesetzt sind.


    Verbesserungen in diesem Bereich können nur durch "Reverse-Engineering" erzielt werden, wenn es findige "Hacker" gibt, die dafür Tools schreiben würden. Wobei dies dann aber auch die Struktur dieser "Absicherung" unterlaufen würde, und letztendlich dem normalen Nutzer mehr Probleme bereitet.

    Nachdem ich gerade wieder einmal Probleme mit entsprechenden Rechten gesehen habe, wäre es vielleicht nicht schlecht, wenn es entsprechende Berechtigungspattern für gewisse Szenarien geben würde, die man direkt auf den Server/Channel/User anwenden kann, die ggf. sogar kumulativ sind, aber auch reversibel sind, so dass man über das Webinterface die Rechte-Verwaltung noch erweitern kann.

    Ein Ansatz wäre der gern als "Multigroup-Server" bezeichnete Ansatz.


    Man verlagert unter anderem das Recht zum betreten permanenter Channel aus den Server-Gruppen in die Channel-Gruppen, so dass alle Personen eine entsprechende Channel-Gruppe besitzen müssen, um den Channel betreten zu können. Ebenfalls können dann entsprechende "Public Channel" eingerichtet werden, die zwar auch von entsprechenden Server-Gruppen abhängen können (join-Power), wobei aber die Channel selbst als "Channel-Rechte" das Recht zum betreten des Channels beinhalten müssen.


    Falls Details erwünscht sind, würde ich mich zur Verfügung stellen, das ganze mal in Form eines How-To's nieder zu schreiben, dies kann ich aber erst zum heutigen Abend leisten. Dann würde ich mal mein eigenes Server-Setup, was auf dieser Kurzbeschreibung aufgebaut ist, entsprechend ausführlich darstellen.

    Eine Erhöhung der Sicherheitsstufe ist nur im Client möglich, daher nur innerhalb der grafischen Oberfläche.


    Es ist aber durchaus möglich, wenn man einen Music-Bot installiert hat, mit ein wenig Bastelei einen solchen Client-Prozess dafür zu benutzen.
    Dafür wird ggf. etwas Wissen zu Remote-VNC-Systemen benötigt, da diese Prozesse zumeist nicht direkt extern erreichbar sind. (Die grafische Oberfläche ist zwar vorhanden, kann aber nicht direkt kontrolliert werden.)
    Alternativ ist natürlich jedes Windows-System geeignet, solche Vorgänge abzuarbeiten. Es soll ja Leute geben, die Windows auf einem Server einsetzen :D


    Und zur Praxis. Ich habe den Sinus-Bot mal mit meinem Server getestet, und habe dafür die Sicherheitsstufe erhöhen müssen. Dafür habe ich selbst die oben genannten Wege eingeschlagen, und die Identität für den Bot auf dem Server generiert, und dessen Sicherheitsstufe entsprechend erhöht.

    Wenn wirklich auch ein "Musik-Bot" mit in Planung ist, muss c++ irgendwo im Gesamtpaket vorkommen, denn das wird dort benötigt.
    Die einzige Variante für einen Musik-Bot, die mir technologisch einfällt, ist ein Client-Plugin, wo du dann zumindest diesen Teil in C++ einbringen musst.
    Es wären auch andere Sprachen möglich, die als "Shared-Object", oder bei Windows als DLL-Datei, mit einer C-kompatiblen Schnittstelle für das Plugin-Interface verwendet werden können.

    Ja, Java ist an sich "plattformübergreifend" einsetzbar, also der Middleware-Code kann auf verschiedenen Plattformen eingesetzt werden, ohne nochmalige Anpassung.
    Die größten Möglichkeiten zum erreichen verschiedenster Plattformen hat man jedoch mit C/C++. Dort ist das Ergebnis (also das fertige Programm) einfach auf die Ziel-Plattform angepasst, kann also besser mit der Plattform arbeiten.


    Und was meinen Hinweis auf die Sockets angeht, so geht es mir dabei darum, dass die Sockets verschlüsselt kommunizieren können, in meinem Fall SSL-Verschlüsselt (ähnlich https), also mit SSL-Zertifikaten abgesichert sind.
    Für Java wäre das dann die Klasse "SSLSocket". Ich bitte dabei einfach mal die "CIA" zu bedenken. http://www.informatik.uni-olde…/indexd917.html?q=node/19 :D


    Und auch Apps lassen sich mit C++ entwickeln, egal für welche Plattform. Android, iOS, Blackberry, ja selbst das M$-Phone OS werden unterstützt. Und auf Mobilgeräte ist das Ressourcenproblem wieder vordergründig. Denn da haben wir wieder das Problem der Ressourcenknappheit.

    Das mit Java wird ein Problem, denn ich implementiere mein gesamtes System auf Basis von Qt-Framework (C++).
    Also einfach gesagt, dass Framework, womit die auch Teamspeak entwickeln.


    Ich muss ganz ehrlich sagen, dass Java für meine Ideen einfach einen zu hohen Ressourcenverbrauch hat. Und außerdem habe ich mit dem Framework keine Probleme, Software für verschiedenste Plattformen zu schreiben. Ohne dass ich etwas ändern muss, kann ich einfach alles direkt für Windows und Linux anbieten. Einfach den Compiler anwerfen, und es ist einsetzbar.


    Ebenso kann ich dadurch sicherstellen, dass die Kommunikation zwischen den einzelnen Teilen abgesichert ist.
    Denn Sicherheit definiere ich anhand der Datenübertragung und Datenspeicherung. Alle Datenübertragungen sollten SSL unterstützen, sicherheitskritische Funktionen stehen nur über SSL zur Verfügung (Login, etc.) Ebenso sollten die Daten in möglichst sicherer Weise gespeichert werden (Passwort-Hashes, User-Daten möglichst anonymisieren, etc.)
    Vieles davon kann ich mit Mitteln des Frameworks direkt abbilden, so dass ich mir dort nur wenig Gedanken machen muss.


    Und was die Verknüpfung angeht, dann stell dich schonmal auf SSL-Sockets und JSON-Daten ein.