TeamSpeak 3 Server 3.0.0-beta5 Available

[Merlok]

These things are permissions which were already in the server setup. So they are useable, but they modified the rights.

But with Beta 5 came complete new permissions, that's why they have to be added manually.

As a good serveradmin it should be some kind of maintenance task to fix the already existing permissions manually.

On the other side, each serveradmin can configure the server on it's own. Maybe some admins want to hold the 100 rights instead of the 75 rights.

[Jaegermeist0r]

as long your server still has the same groupids, alls is fine. beyond that you will probably destroy your setup.

Is it stil a top secret project, to add these things manually by server querry, or why didn't anybody can write the querry down?

Or you just waiting for 100 people asking "How to add this permissions manually" ?

Can't understand that..

[dEMolite]

On the other side, each serveradmin can configure the server on it's own. Maybe some admins want to hold the 100 rights instead of the 75 rights.

Yea okay thats true, but an update.sql file for those who dont want to have it would be still nice for those who arent really into the permissions stuff in.
Its still a suggestion nothing more because its always better in the way "learning by doing"

[Cat3006]

in the Changelog you can find the following lines

+ added permission PERMISSION_b_virtualserver_modify_priority_speaker _dimm_modificator
you need to manually add this permission if you are upgrading the server
+ added PERMISSION_b_virtualserver_modify_log_settings
you need to manually add this permission if you are upgrading the server
! + added VIRTUALSERVER_LOG_CLIENT, VIRTUALSERVER_LOG_QUERY, VIRTUALSERVER_LOG_CHANNEL
VIRTUALSERVER_LOG_PERMISSIONS, VIRTUALSERVER_LOG_SERVER, VIRTUALSERVER_LOG_FILETRANSFER
to virtualserver properties
default logging disabled except for permissions
! default permissions are more end-user friendly

so i think with your sql code you have passed the first and the second of the permission steps. But you didn't passed the third step, so you can't activate the logging options.
You can see this, if you add yourself to the Admin Server Query group and the have a look in the TS³ Client at your VirtualServer modification Options under Protocoll.
Then the checkbox for permissions are deactivated.
There for you have to add the following lines to.
I have extracted them from a fresh created sqlite database on a beta5 server.

insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_client', '0');
insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_query', '0');
insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_channel', '0');
insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_permissions', '1');
insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_server', '0');
insert into server_properties ("server_id", "id", "ident", "value") values ('1', '1', 'virtualserver_log_filetransfer', '0');

(hope it's easy to understand, and my english isn't to worse)

[StoneBlood]

Sorry Dev Team but what about licensing problem on this beta version?
I heard more people about this problem that cause a shouting down of the server on linux server.
This is a rare bug or?

[R. Ludwig]

Sorry Dev Team but what about licensing problem on this beta version?
I heard more people about this problem that cause a shouting down of the server on linux server.
This is a rare bug or?

just fired up my own none profit license and it reports correctly. no shutdown yet.

please everybody who got this problem report this to triton with your license id and operating system.

thanks!

[Fire86]

Atm I cannot see any alternative way but adding "grant permissions" of new Permission values to the Admin Server Query group.
And the only way to do this is by running SQL statements in the database.

I think everyone agrees that Admin Server Query group defaults to server_id "0" and group_id "2" on every TS3 server.
So, why don't you at least add these statements as a standard update routine? (on startup: check if they already exist and if not add them.)

insert into perm_server_group (server_id, id1, id2, perm_id, perm_value,perm_negated, perm_skip) values (0, 2, 0, "b_PERMISSION_ID", 1, 0, 0);
insert into perm_server_group (server_id, id1, id2, perm_id, perm_value,perm_negated, perm_skip) values (0, 2, 0, "i_needed_modify_power_PERMISSION_ID", 100, 0, 0);

This way we could skip database editing completely, especially interesting for all those less skilled Server Admins out there.

---------------------------------------
(Extended) German translation to avoid misunderstandings:

Ich kenne derzeit keine andere Möglichkeit, außer der Admin Server Query Gruppe "grant Berechtigungen" für neue Permissions zuzuweisen.
Und dies ist eben nur über SQL Statements möglich, welche direkt in der Datenbank ausgeführt werden müssen.

Ich denke, niemand kann sich der Tatsache verwehren, dass die Admin Server Query Gruppe auf allen Server Instanzen die group_id "2" und die server_id "0" besitzt. (und ich sehe auch keinen Grund, warum das jemand verändern würde)
Daher verstehe ich nicht, warum ihr nicht einfach ein Standard Update Prozedere integrieren könnt, welches das Einpflegen neuer Permission Werte für eben diese Gruppe beim Start automatisch übernimmt.

Die Permissions für die restlichen Gruppen kann dann ja jeder selber über das Gui einpflegen, indem er seinen Account temporär der Admin Server Query Gruppe hinzufügt.

So bräuchte man die Datenbank nicht mehr manuell zu verändern, was sicherlich besonders für die "weniger talentierten" Server Betreiber interessant ist.

<!-- Senf
Zumal die Gefahr, die Datenbank zu schädigen, durch externe Tools sehr viel größer ist, besonders wenn man keine Ahnung hat, was man da eigentlich tut.
Senf -->

[Merlok]

I think that this is not possible in every case.

Because you can create new permanent groups. And those groups won't have all these new rights then, when you just add them to the query server admin group.

So you have to do manual steps in every case.

[Fire86]

I think you didn't get my point.
I'm just talking about the static Admin Server Query group which is the same on every server, so actually it is possible.

You would just have to add yourself to the Admin Server Query group temporarily.
Then you can use the GUI (or Server Query) to edit your custom and SA groups accordingly.
(no database touching at all)

But this is only possible if the Admin Server Query group has the power to do so.
At the moment the only way to gain this power is by touching the database (which kinda sucks imho).

[Merlok]

Hm ok, either you or me understands something wrong here.

I think I got your point and this is not working. Let me explain this a bit more.

Even if you only give the new permissions to the query server admin group and add yourself to that group, you can't grant other groups the new rights via the GUI.

Every right you can grant or revoke in the GUI needs to be registered in the database already.
As those new rights are registered only in the query server admin group (if we do it your way), the new rights are not visible in the gui when you check all other groups.
So via the GUI there would be no way.

It also makes no sense to add the new permissions to the query server admin group, because if you want to do it via the query tool, you can use the predefined admin login which was created on first server startup of your TS3 server.
So, normally there would be no need to do that for this special case.

The only ways for adding the new permissions are to edit the database files via a tool like phpmyadmin or something else, or via the query tool (but for this I don't know the commands I have to admit).

And for the query tool you don't need to regoster your own identity as query admin.

I hope that you know what I mean.

[Fire86]

Hehe, no. You mixed something up.

The Permissions itself are hardcoded.
The database is just used for storing (and controlling) the specific power-levels of each group.

Just recognized that you're from Germany, so I will briefly explain it in German, because I'm too tired for English:
----------------------------

Also es ist so, die Permissions sind bereits im Programmcode von TS3 verankert.
Sobald du deinen Server auf eine neue Version updatest, in der neue Permissions hinzugefügt wurden, sind die Permissions da (ob du willst oder nicht).
Wenn du die Permission Liste einer beliebigen Server Gruppe anzeigen lässt, kannst du sie auch sehen, aber sie sind halt noch grau.
Und das ist das Problem, sie sind bei jeder Gruppe grau, somit ist man gezwungen die Datenbank zu modifizieren und sie manuell einer beliebigen Gruppe zu geben, selbst mit Server Query geht es nicht, aufgrund der fehlenden Grant Rechte.

Genau das macht z.B. folgendes SQL Statement:

insert into perm_server_group (server_id, id1, id2, perm_id, perm_value,perm_negated, perm_skip) values (0, 2, 0, "b_virtualserver_modify_log_settings", 1, 0, 0);
insert into perm_server_group (server_id, id1, id2, perm_id, perm_value,perm_negated, perm_skip) values (0, 2, 0, "i_needed_modify_power_virtualserver_modify_log_settings", 100, 0, 0);

Die erste Zeile gibt der Admin Server Query Gruppe das Recht die Permission "b_virtualserver_modify_log_settings" (wurde in beta5 eingeführt) benutzen zu dürfen und die zweite Zeile gibt ihr die passenden Level 100 Grant Rechte dazu.
Dadurch, dass man jetzt Grant Rechte hat, kann man allen anderen Gruppen nun ebenfalls dieses Recht geben.
Das kann man entweder über Server Query (serveradmin account) machen oder ganz einfach über das GUI, indem man seinen Acc der Admin Server Gruppe hinzufügt.

Hier sind wir bei meinem Kritikpunkt angelangt:
Die Devs sagen, SQL Statements können wir nicht automatisch bei einem Update ausführen lassen, da wir nicht wissen, wie die Server-Betreiber ihre Gruppenrechte etc regeln.
Richtig soweit, ich sage allerdings, es wird kein Server-Betreiber die Admin Server Query Gruppe verändern, also wäre es wirklich sinnvoll, wenn wenigstens diese Gruppe bei einem Update mit neuen Permissions automatisch volle Grant Rechte für eben diese neuen Permissions bekommt.
Dann könnte man, wie bereits gesagt, alles weitere komplett über das GUI regeln und das ist ein Zustand, den man im Sinne der Userfreundlichkeit unbedingt anstreben sollte (auch wenn es noch beta Phase ist).

So, ist nun doch etwas länger geworden, ich hoffe, ich konnte alle Klarheiten beseitigen, hab zumindest versucht, es möglichst verständlich zu erklären.
Wenn du noch ne Frage hast oder was nicht verstehst, kannst du mir jederzeit gerne ne PM schicken.

[Merlok]

Nicht nötig. Jetzt weiss ich was Du meinst.

Da habe ich dann wohl doch was komplett falsch verstanden.