Beiträge von master_d

    OK, dann erst einmal ganz allgemein.


    Für die genannten Funktionen werden folgende Dinge benötigt:

    - Ein TS3-Bot (Im Normalfall ein Query-Bot), welcher die Aktionen auf dem TS3-Server durchführt.

    - Ein Webinterface, welches mit dem entsprechenden Bot kommunizieren kann, bzw. die notwendigen Informationen verwaltet, welche der Bot für seine Aktionen verwendet.


    Da ich so etwas nicht einsetze, kann ich keine Namen, bzw. Informationen betreffend vorhandenen Systemen nennen.

    Es ist jedoch davon auszugehen, dass die entsprechenden Webseiten diese Funktionen jeweils selbst impleemntiert haben, bzw. vorhandene Systeme auf ihre Anwendungsfälle angepasst/erweitert haben.


    Dahingehend wäre von deiner Seite interessant, was genau du benötigst, bzw. umsetzen möchtest. Daran angelehnt könnten sich dann auch andere mit konkreten Vorschlägen zu ggf. bereits vorhandener Software beteiligen.

    Der Teamspeak3-Client fragt erst nach einem SRV-Record unter "_ts3._udp.<requested-domain>".

    Wenn dieser existiert, wird unter der im SRV-Record genannten FQDN ein Request für den A-Record ausgelöst, und zu der darin genannten IP eine Verbindung hergestellt.

    Andernfalls wird eine Anfrage nach einem A-Record unter "<requested-domain>" durchgeführt, und dazu eine Verbindung aufgebaut.


    Daher funktioniert natürlich "ts3.domain.de".


    Du musst deinem Provider nochmals klar machen, dass er den SRV-Record auf der Hauptdomain zu setzen hat, und zwar in der hier bereits genannten Form.

    Falscher Request-Typ.

    Du fragst in deiner Ausgabe nach einem "A"-Record, es muss aber ein "SRV"-Record sein.


    Beispiel aus meiner eigenen Installation:

    Code
    1. id 46381
    2. opcode QUERY
    3. rcode NOERROR
    4. flags QR RD RA
    5. ;QUESTION
    6. _ts3._udp.meinedomain.de. IN SRV
    7. ;ANSWER
    8. _ts3._udp.meinedomain.de. 3599 IN SRV 0 5 9987 voice01.meinedomain.de.
    9. ;AUTHORITY
    10. ;ADDITIONAL
    Code
    1. id 27698
    2. opcode QUERY
    3. rcode NOERROR
    4. flags QR RD RA
    5. ;QUESTION
    6. voice01.meinedomain.de. IN A
    7. ;ANSWER
    8. voice01.meinedomain.de. 3599 IN A 127.0.0.1
    9. ;AUTHORITY
    10. ;ADDITIONAL

    OK, dann vom Anfang.


    1. In deiner Entwicklungsumgebung sollte es die Möglichkeit geben, die Build-Optionen einzustellen, bzw. die Art des Builds zu konfigurieren.

    Normalerweise gibt es dort "Debug" und "Release" als Optionen.

    Aufgrund dessen, dass du die Sache unter Windows durchführst, gehe ich einmal von Visual Studio aus.

    Nicht gerade meine Paradedisziplin, aber dort ist in jeden Projekt entsprechendes vorhanden.


    2. Innerhalb von Visual-Studio gibt es auch einen Debugger, so dass innerhalb des Projekts eine entsprechende Debug-Konfiguration erstellt werden kann, um Teamspeak3 über den vorhandenen Debugger zu starten.


    3. Was die Ausgabe auf der Konsole angeht, so werden die Informationen bei Release-Builds mglw. nicht angezeigt.

    Bin da gerade nicht ganz sicher.

    Klingt nach einem Problem bei den übergebenen Daten.


    Hier sollte das Plugin einmal mit Debug-Optionen kompiliert werden, und danach der Teamspeak3-Client einmal per Debugger gestartet werden, um die Meldungen besser auslesen zu können, bzw. das Problem eingrenzen zu können.


    Alternativ solltest du auf jeden Fall den Teamspeak3-Client einmal aus einem Terminal (Windows: EIngabeaufforderung) starten, damit die Ausgaben beim Crash lesbar erhalten bleiben.

    Das könnte bereits einen ersten Anhaltspunkt geben, wo das Problem liegt.

    Bei einem "DS-Lite" ist keine eingehende Verbindung über IPv4 ohne Mitwirklung des entsprechenden Providers möglich.

    IPv6 ist aber bei Teamspeak bereits mötlich, so dass dich niemand daran hindert, deinen Server über IPv6 zu betreiben.

    Aktive NPL-Lizenzen können derzeit weiter verwendet werden, aber Teamspeak gibt derzeit keine neuen heraus.

    Das Lizenzmodell wird bei denen gerade umgestellt.


    Es gibt weiterhin support für aktive Lizenzen, und eine Übernahme einer vorhandenen Lizenz bei einem Wechsel des Betreuers der Community wird wohl nach den hier vorgelegten Informationen möglich sein.

    Was aus dem Text so nicht hervor geht, bzw. ein Problem werden kann, ist die Verwendung für ein anderes Projekt, als das der Lizenz zugehörige Projekt.


    Die Antwort bezieht sich, soweit für mich erkennbar, nur auf die aktive Übernahme eines bestehenden Projekts.

    Das war ja genau meine Aussage. Es geht komplett mit einer einzelnen Gruppe.


    Wenn man sich den Guide durchliest, sollte eigentlich das Thema klar ersichtlich sein. Ansonsten sagt es mir, und ich formuliere das entsprechend neu.

    Dennoch wiederhole ich es nochmals für alle, die dies hier später nochmals lesen solten.


    Es geht um die Trennung verschiedener Gruppierungen unter Verwendung von Channel-Gruppen, wobei die Channel-Gruppen eine Rechte-Struktur innerhalb der Gruppen abbilden. In der Theorie reicht eine Gruppe, wenn es nur um gewisse Basis-Rechte geht.


    Dennoch freue ich mich, dass du schnelle Hilfe gefunden hast.

    OK, sieht aus, als wäre dort ein Teamspeak3-Server als Nutzer "root" gestartet.


    Nun die Frage, ist dein TS3-Prozess zu der Zeit wo du den Befehl ausgeführt hast aktiv?

    Wenn ja, dann beende ihn und prüfe nochmals.

    Wenn dann die Datei noch da ist, dann ist ein anderer Prozess aktiv, der dich blockiert.

    Und dann bleibt nur eine entsprechende Lizenz zu erlangen/erwerben.

    Es gibt einen Weg.


    Im allgemeinen kann man die Informationen dazu meinem Guide entnehmen, welchen ich hier einmal verfasst habe.

    [Multi-Group] Rechtestrukturen im Einsatz


    Die notwendigen Informationen dazu liegen in den Posts 2 und 3.

    Server-Gruppen anpassen und dann kann man mit den Channel-Gruppen genau so arbeiten, wie bei dir erforderlich ist.

    Wobei dann sogar eine Channel-Gruppe ausreichend ist, und keine 2 unterschiedlichen Gruppen notwendig sind.


    Sollten noch Detail-Fragen offen sein, stehe ich dahingehend natürlich zur Verfügung.

    Bitte die vollständige Ausgabe posten.

    Ansonsten kann ich mit der genannten Aussage leider wenig anfangen.


    Nachfolgend ein Beispiel dessen, was ich erwarten würde (hier die Ausgabe von meinem Testsytem):

    Darin zu erkennen, die Datei welche dem Benutzer "teamspeak" gehört, welche dort abgelegt wird, wenn ein "unlizensierter" TS3-Prozess startet. Wenn dort bereits eine Datei dieser Art liegt, startet kein weiterer "unlizensierter" TS3-Server bzw. deaktiviert die Voice-Instanzen.

    Bitte mal die Informationen betreffend des Shared-Memory prüfen.


    Unter Linux wäre das "ls -laF /dev/shm".

    Darin legt Teamspeak eine Datei ab, um sicherstellen zu können, dass auf dem System nur !ein einzelner! unregistrierter Teamspeak existiert.

    Wenn bei dir dort bei deaktiviertem TS3-Server etwas existiert, ist dort keine "saubere Trennung" der virtualisierten Systeme vorhanden.

    Zitat

    ...

    2018-09-16 18:07:24.084970|WARNING |Accounting | |Unable to open licensekey.dat, falling back to limited functionality

    ...

    2018-09-16 18:07:24.590029|ERROR |Accounting | |failed to register local accounting service: Die Datei existiert bereits

    ...

    In diesen beiden Einträgen liegt dein Fehler.


    Es existiert auf dem System bereits ein "unlizensierter TS3". Möglicherweise ist die Virtualisierungsumgebung nicht dahingehend abgeschirmt, den "SHM"-Bereich sauber zu trennen, so dass ein TS3 auf einer anderen virtualisierten Instanz(vserver) auf dem Host dir dieses Problem bereitet.


    Aufgrund der Meldungen ist es normal, dass dein TS3 sich beendet.

    Klingt nach einem Problem mit dem Query-Interface.


    Ist das "zugreifende System", also das wo das Webinterface drauf läuft, bei dem TS3-Server in der Query-Whitelist eingetragen?

    Aufgrund der Beschreibung gehe ich stark von einem Problem mit der "SPAM-Protection" im Query-System aus. Einfach zu viele Befehle gesendet, ohne die entsprechende Konfiguration.

    Teamspeak ist seit 3.1 auch für IPv6 verwendbar.
    Die IPv6-Adresse ist auch von außen erreichbar, und muss nur in deinem Router freigegeben werden.
    Danach sollte auch von außen ein Zugriff auf deinen TS-Server möglich sein.


    Schau also einfach mal auf dem Rechner mit dem TS-Server nach der IPv6-Adresse, und gibt die Ports 30033/tcp und 9987/udp für den Rechner/die IPv6-Adresse in deinem Router frei.
    Danach sollten Leute von außen auf der Adresse eine Verbindung zu deinem TS-Server aufbauen können.

    Und genau das, was ich erwartet habe, ist eingetreten.


    Du hast einen Kabelanschluss, welcher zumeist über DS-Lite angesteuert wird.
    Daher hast du wahrscheinlich an deinem Anschluss keine "eigene" IPv4-Adresse mehr. Dir bleibt nur eine Nutzung der IPv6-Adresse, sollte sich dies wirklich so darstellen.
    Prüfe bitte einmal die Info-Seite deiner FritzBox, da sollten alle Informationen angezeigt werden (IPv4, falls vorhanden, IPv6-Adressen, etc).

    Bei den normalen "Internet-Anschlüssen" handelt es sich immer um "Dial-Up-Verbindungen" (Telekom sei dank, die wollten damals auch bei DSL weiter nach Zeit abrechnen ;) ). Daher ändert sich die IP (IPv4 und IPv6) mit jedem Verbindungsaubau.


    Um dein Problem genauer auffassen zu können, wäre ein wenig mehr Information erforderlich.
    - Welche Art von Internet-Anschluss ist hier das Problem (DSL/Kabel/etc.)?
    - Welcher Router ist hier im Einsatz?


    Danach kann man sich über das Problem genauer unterhalten, aber eine mögliche Lösung des Problems wäre hier "DynDNS", um der sich verändernden Adresse einen eigenen Namen zu verpassen.

    Die Frage ist, von welcher Sichtweise man das ganze betrachtet.


    Aber ja, die "Menge an Dokumentation" in diesem Bereich ist bestenfalls gerade ausreichend, eher mangelhaft.
    Auch ich habe mich durch die vorhandene Dokumentation gewühlt, und verstehe noch immer nicht alles, daher wäre potentiell ein Tutorial eine sinnvolle Ergänzung.


    Nur bei der "Fülle an Möglichkeiten" stellt sich die Frage, ob es bei einem Tutorial bleiben sollte. Ich denke eher, hier sollte einmal eher in die Richtung einer "ordentlichen Dokumentation" gedacht werden, welche das Gesamtspektrum abdeckt. Das sollte durchaus durch Beispiele, auch in Form eines Tutorials, unterstützt werden.


    Am Rande könnte man sogar die Möglichkeiten zur Nutzung anderer Sprachen mit bedenken. Bspw. werden meine Plugins eher in C++/Qt verfasst, da dies bereits durch Teamspeak verwendet wird.