Adventures in the admin system from the X servers.

Talk about anything related to Unvanquished.
User avatar
Anomalous
Programmer
Posts: 318
Joined: Wed Mar 07, 2012 3:51 pm UTC

Re: Adventures in the admin system from the X servers.

Postby Anomalous » Wed Apr 03, 2013 5:18 pm UTC

I like the idea of a standard set of ban reasons. I may implement this.

Other parts of it – well, we'll see. I can see some utility in sharing ban information across servers, for a start…
Debian and Ubuntu packages (squeeze, wheezy, sid; 12.04, 12.10, 13.04) may work on derivatives

OFFEND! … no, that's not right… ATTACK!
User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: Adventures in the admin system from the X servers.

Postby kharnov » Wed Apr 03, 2013 5:43 pm UTC

A central ban database would be fantastic. It would aid in spotting potentially disruptive types so that they can be monitored accordingly.

As for stock ban reasons, they should come with default punishments that can be altered by editing the appropriate configuration. I can tell you from my experiences on US Main that people will go after you if they perceive you as being overly harsh, and I believe that this is due to the overwhelming amount of subjectivity in assigning bans, kicks, and mutes. If this is controlled by something objective, like a stock list of reasons and their associated punishments, then it becomes more uniform and it is solely up to the administrator in question to give out the appropriate sentencing. For example, I've seen administrators give between two hours to two weeks for a basenade. Why deal with that level of variability? Set a standard punishment, like six hours or a day, and be done with it. All administrators should be giving out the same exact punishments.
User avatar
Anomalous
Programmer
Posts: 318
Joined: Wed Mar 07, 2012 3:51 pm UTC

Re: Adventures in the admin system from the X servers.

Postby Anomalous » Wed Apr 03, 2013 5:55 pm UTC

It's possible that the admins in question were taking into account their knowledge of the players at fault. Repeat offenders would get longer bans; a regular who's occasionally a problem may get a shorter ban. Unknown players – yes, default is appropriate.

It is easy enough to add a /ban variant which uses stock reasons; however, some work will need to be done to /showbans to allow for translation, and there'll be still more work to make the ban list shared.

Not just bans, either – forced spectate is mentioned above, and we already have that (though it's limited to the current game). And from there, it wouldn't be much to make denybuild and mute sticky – which can be done anyway with some tweaking of the training server's longstrip handling.

The big part of this is the shared list handling.
Debian and Ubuntu packages (squeeze, wheezy, sid; 12.04, 12.10, 13.04) may work on derivatives

OFFEND! … no, that's not right… ATTACK!
User avatar
janev
Marauder
Posts: 199
Joined: Sun Sep 02, 2012 2:45 pm UTC
Location: A hovel on Niveus

Re: Adventures in the admin system from the X servers.

Postby janev » Thu Apr 04, 2013 12:13 am UTC

Are we talking about official servers of all servers? Big difference.

How would a central ban database work? I imagine it could easily be abused. It don't fancy the idea of a disagreement with one admin on one server resulting in a blanket ban from every server. That is a bit too much power to give one person. Also I think server administrators are quite capable of assigning ban duration for themselves.

I agree there is much that can be done to improve admin tools just do not do it at the expense individual server owners control rights.
Image
Little*Butterfly
Posts: 14
Joined: Sun Mar 03, 2013 4:47 pm UTC

Re: Adventures in the admin system from the X servers.

Postby Little*Butterfly » Thu Apr 04, 2013 9:08 am UTC

Hi, when I said "centralised database", I meant it was for the X Group servers. Only our highest ranking administrators have access to this database, what we call "Globals". It was desirable to have this because of repeat offenders who jump from server to server and cause trouble. Now, for example, when we Handicap a player for cheating (Aimbot/Triggerbot/Wallhack), it is automatically reflected to other servers connected to the centralised database. It is not required to have a centralised databased for the Unvanquished project as a whole but the functionality should be there for gaming groups like the X Group, who manage multiple Tremulous 1.1 servers. Either this or a very different mechanism for storing ban information, which can be synchronised between multiple servers.
User avatar
Ishq
Project Head
Posts: 1138
Joined: Tue Mar 06, 2012 8:32 pm UTC

Re: Adventures in the admin system from the X servers.

Postby Ishq » Thu Apr 04, 2013 11:03 am UTC

Right. I don't have any plans of creating a centralized ban database for Unvanquished, except, maybe for all servers controlled by us, as you said.
User avatar
ViruS
Granger
Posts: 1020
Joined: Sun Mar 11, 2012 4:24 am UTC
Location: Antartica - West Australian Post shore
Contact:

Re: Adventures in the admin system from the X servers.

Postby ViruS » Thu Apr 04, 2013 12:49 pm UTC

There's a possibility of storing the information on the same database for 1.1 with the unv server stats (ref: Sixthly's AA site) but I don't really see much point if the I.D. system is different. Having a centralized database for a number of unvanquished servers does seem reasonable, in a way it reflects on Valve's VAC automatic anti-cheat tool that they have. No system is perfect though, keep that in mind.
ImageImage[color="#000000"]You[/color][color="#FF0000"][[/color][color="#A9A9A9"]Tube[/color]Image
User avatar
Asvarox
Mantis
Posts: 104
Joined: Mon Mar 19, 2012 11:59 am UTC

Re: Adventures in the admin system from the X servers.

Postby Asvarox » Thu Apr 04, 2013 3:10 pm UTC

I actually think "centralized ban database" is an idea worth investigating. Server Operator would be able to choose servers from where his server would "fetch" bans, and use these data to at least warn online admins that "known" player is connecting
User avatar
ViruS
Granger
Posts: 1020
Joined: Sun Mar 11, 2012 4:24 am UTC
Location: Antartica - West Australian Post shore
Contact:

Re: Adventures in the admin system from the X servers.

Postby ViruS » Fri Apr 05, 2013 10:53 am UTC

That sounds more ideal the way you say it.
ImageImage[color="#000000"]You[/color][color="#FF0000"][[/color][color="#A9A9A9"]Tube[/color]Image
Little*Butterfly
Posts: 14
Joined: Sun Mar 03, 2013 4:47 pm UTC

Re: Adventures in the admin system from the X servers.

Postby Little*Butterfly » Fri Apr 05, 2013 11:51 am UTC

I understand we're calling this mechanism 'ban database' for clarity but if something is being developed to this end, I'd like it to offer way more than simple bans. Again, speaking from our experience on the X group servers, we classify player restrictions in different categories:

1. Handicap
A handicapped player means they're unable to deal any kind of damage and they take two-fold damage. This was our developer's way of dealing with repeat cheaters who use aimbots/triggerbots/wallhacks etc. Think of if as the way of shaming them rather than banning them. It is also a way to allow them to do other things like build if their appeal for cheating is under way.

2. Denybuild
It was desirable to have full support for removing build rights from whole netblocks, to catch those evading deconners and intentional grief builders.

3. Forcespec
When we have players who are real jerks by intentionally sabotaging their team, such as opening a critical door intentionally and telling the opposing team in public chat "hahaha.. door open!", we used to mute them. Then they resorted to deconning. When we added a denybuild, they resorted to intentionally blocking their teammates. We have someone very special who likes to "play" on our servers. We call him "Persi", which is one of his known handles. The problem with him is that he uses a spanish ISP which has a broad range of netblocks and low DHCP lease time. We can't ban everyone because we have regular players who log from the same ISP. What we did is put a global forcespec on as many netblocks we could identify. This way when a regular player logs on, they can't play until we manually add them to our whitelist. That was our mechanism of dealing with this abuse.

4. Mute
Speaks for itself ;-)

This restrictions database does not *need* to be in MySQL. It can be a simple, password-protected, listener daemon equipped with a plaintext file in which player restrictions are stored. I'm thinking something like

{ serial: 05042013-001;
network: 192.0.43.0/12;
restrictions: nobuild, mute;
desc: example.com netblock restrictions;
}

{serial: 05042013-002;
network: 192.0.44.12/29;
restrictions: -nobuild, -mute;
desc: allow our friends from example.com to play;
}

Whenever a client connects, the Unvanquished daemon would query this listener daemon, supplying the IP of the connecting client and fetching the restriction class for this client. To extend functionality, certain admin levels are able to edit entries. It is a thought thrown out there :-) It needs further enhancements such as fool-proofing it to prevent entries such as 0.0.0.0/0 etc. I'm no developer so I'm sure you devs can some up with something even smarter.

Return to “General Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests