Overhaul on our TS3 Setup

[Brett]

Our TS3 system has not been maintained properly through updates for quite some time, and we are now seeing a lot of tickets coming in about users being able to kick admins, among other permission related problems.

 

Our current setup involves about 6 different voice machines, each using an SQLite database to store the virtual servers settings and permissions locally. As we are about to have to do a complete overhaul on the whole setup before this gets anymore out of whack, we are considering the idea of setting up a MySQL database on the same machine as our TCAdmin Master, and keeping a single database for all TS3 servers (if this is possible) or at the very least, a single database per each location, but based on the single machine for easier access and management.

 

What I am wondering is if it would be worth doing this considering how badly out of whack our system is currently, or would something along the lines of http://docs.planetteamspeak.com/ts3/php/framework/ be a better bet for just trying to fix the servers as they currently are?

 

The problem with doing a complete overhaul and switching to remote MySQL database(s) is that we have a LOT of TS3 clients, and there services would have to be reinstalled. We are looking at compensation for the issue, but this is really problematic anyway we look at it.

[ECF]

Have you contacted TS3 support to see if they can point you to the best option?

[PhantomYoda]

We are working with them as well, just also wanted to check here since our TS3 is integrated into TCAdmin and we wanted to make sure if we do a central DB if it would work.

 

Our prior owner was in some discussions about it here, and was pro SQLite, while some other members were pro centralized MySQL. We are leaning towards a central DB now.

[KingJ]

We had the same issue, everyone was able to kick everyone - the entire permissions system was disregarded.

 

The issue stems from a change in Beta 21 (or around there) where an update was made to the permission system. However, you needed to perform some modifications to the server using the serveradmin interface rather than just updating the binaries as with most updates. This was in the changelog, but quite a few people (including ourselves) skipped over it and didn't apply the required modifications.

 

The kicking issue appeared to manifest in beta 29/30 where another change in the permissions system occurred. If you have made the Beta 21 changes then the permissions system should have been autoupdated for the beta 29/30 permissions changes, but since we hadn't no permissions where changed when updating to beta 29/30 which then caused the entire permissions system to be disregarded.

 

After looking into the issue further, we found it was going to take a lot of manual work on the database to resolve this issue with no assurances that similar issues wouldn't occur in the future. Therefore, we decided to wipe our database and recreate all the servers from scratch, which only took a few hours. Obviously this inconvenienced customers, but we offered compensation and didn't loose a single one. Indeed, some ended up upgrading their slot counts because of how well we kept up communication with them during this issue.

 

So basically, start from scratch with the latest beta. It'll take you a few hours (or more depending on how many servers you host) but at least you'll be starting from fresh and know that the issue is resolved for sure. Don't forget to use the TS3 ATHP Defaults SQL when re-creating your servers to ensure that permissions are set up correctly for an ATHP system - the defaults allow users to change their slot count for example.

 

Good luck!

[Brett]

Thank you very much King!

[ECF]

Thank sucks Brett. Hopefully starting fresh will get you back on track.