Half-Life Elite - Virtual Administration 2.0

By: [LMS]007

kyle@hl-elite.com

Concept

To create a layer of abstraction between the administrators and the server owner. The principle behind virtual admin is to give sub administration rights to players by assigning them to a virtual administration group which can restrict or advance any number of server commands or variables without yielding the potentially dangerous rcon_password.

Functionality

Virtual administration works much like windows NT in the sense that you can create groups and assign players to a group. Each group has its own permissions and or restrictions which are in a sense “rights” given to each member in that particular group.

Virtual administration uses a text file to load and save its previous groups and group settings. The settings for this file can be edited in the game or outside the game. The text file is more like a script file. Server admins can create groups and add permissions or restrictions or passwords to each group. The method in which client members can use vadmin is by using the string “vrcon” before the command they which to send to the server via the console. For example “vrcon mp_timelimit 30”

The file (vadmin.txt)

Here is an example of vadmin.txt file located inside your hle directory

GROUP ( NAME "admin" )
{
MEMBERS
{
"1:418088"
}
PERMISSIONS ( ALL ) { }
}
GROUP ( NAME "mod" )
{
MEMBERS
{
"0:1801522"
"0:3907"
"0:56377"
"0:74005"
"0:86936"
"1:1419695"
"1:420928"
"1:45960"
"1:515501"
"1:68965"
"1:694157"
"1:716784"
"1:86844"
"1:87766"
"1:90073"
"1:90835"
}
PERMISSIONS ( ALL ) { }
RESTRICTIONS
{
"add"
"rcon"
"rcon_password"
"remove"
"vadministration admin"
}
}
GROUP ( NAME "users" )
{
MEMBERS
{
"1:520732"
}
PERMISSIONS ( ALL ) { }
RESTRICTIONS
{
"add"
"ban"
"create"
"eject"
"emit"
"kick"
"rcon"
"rcon_password"
"remove"
"sv_"
"vadministration admin"
"vadministration mod"
}
}
GROUP ( NAME "everyone", PASSWORD "efilflah" )
{
RESTRICTIONS ( ALL ) { }
}

From this file, you can see each group is defined by a set of parameters surrounded by parenthesis ( ) and a set of contents which is surrounded by braces { }. This is much the way a C++ or C or Java function would look like.

The file is completely editable. You can add anything you like so long as it’s valid syntax or remove any part you like without invalidating the syntax. Keywords are in caps. There are two types of keywords, Functional keywords and Parameterized keywords. Functional keywords may or may not have parameters. However each functional keyword must be followed by a set of braces like this { }. They may be empty, or have contents. For example MEMBERS { }

Parameter keywords are contained between a pair of parenthesis like this ( ). Each Parameter keyword should be followed by string a text relative to the keyword. The string a text much be wrapped by quotes “ “. For example NAME “group”. Note that this is also valid by not necessary MEMBERS ( ) { }. Parameters are optional for all Functional keywords expect GROUP. Therefore this would be invalid GROUP { }. The GROUP keyword must at least have the NAME parameter like such: GROUP (NAME “xyz”) { }. Certain keywords only work inside other keywords. MEMBERS and RESTRICTIONS and PERMISSIONS will only have a purpose inside of a GROUP. For example

GROUP ( NAME “test” )
{
PERMISSIONS
{}
RESTRICTIONS
{}
}

The keyword ALL. Is sort of a short cut. If you wanted all the possible contents of a Functional keyword then you use the keyword ALL inside the parameters, for example:

GROUP ( NAME “test” )
{
PERMISSIONS ( ALL )
{}
RESTRICTIONS
{}
}

Would grant access to anything a member of that group would type. There is a logical order as to how the permissions and restrictions are dealt with.

Here is how the simple algorithm works in this exact order

If ( the command is a permission )
Give authorization
Else If ( the command is a restriction )
Fail authorization
Else If ( the all commands are NOT blocked )
Give authorization
Else
Fail authorization

So what does that really mean? I think it would be best to just look at a few examples.

GROUP ( NAME “test” )
{
PERMISSIONS ( ALL )
{}
RESTRICTIONS
{
“rcon_password”
}
}

Remember to use commands a member needs to use the prefix “vrcon” before each command. If a member of the group “test” typed vrcon rcon_password 123 in the console they would be denied the writes for this commend to work. They would get an error message in the console. However any other command they type will work because ALL permissions are accepted. However if the group looked like this

GROUP ( NAME “test” )
{
PERMISSIONS ( )
{}
RESTRICTIONS
{}
}

No commands would work. This group would not be very beneficial to anyone. Essentially all permissions are banned unless otherwise explicitly stated or the ALL parameter is assigned to the permission keyword parameter list. Let’s run through some more examples

GROUP ( NAME “test” )
{
PERMISSIONS ( )
{
“changelevel”
}
RESTRICTIONS
{}
}

The only command a member of this group would be allowed to use is changelevel every other command would be rejected. You may notice that the key word ALL would not really matter if it was applies in the RESTRICTIONS parameter list. However we will include it for simplification. Therefore

GROUP ( NAME “test” )
{
PERMISSIONS ( )
{
“changelevel”
}
RESTRICTIONS ( ALL )
{}
}

Is essentially the exact same group as before. Likewise if you omit the entire keyword RESTRICTIONS …

GROUP ( NAME “test” )
{
PERMISSIONS ( )
{
“changelevel”
}
}

You would still have the exact same group. This just emphasizes that fact that all commands are restriction unless otherwise stated. So why do we have a RESTRICTIONS key word? Well this is to add some flexibility to the group. You can create a group where all keywords are accepted unless otherwise restricted like this:

GROUP ( NAME “test” )
{
PERMISSIONS (ALL)
{}
RESTRICTIONS
{
“rcon_password”
}
}

We used this example once before. Everyone is accepted expect rcon_password. You can also use partial strings to restriction or admit commands. Let’s look at some examples of this

GROUP ( NAME “test” )
{
PERMISSIONS (ALL )
{}
RESTRICTIONS
{
“sv_”
“mp_”
“r”
}
}

So what does that do? Basically any member of that group would be allowed to type any command exact commands that started with “mp_” “sv_” or “r”. Which would rule out all multiplayer cvars, server cvars, and words like rcon or rcon_password and whatever other commands started with an “r”. If “r” was too generic, one might try to lengthen the string to target more specific commands. For example “rcon”

Likewise you can increase the length of the string and even add spacing to target specific commands for example

GROUP ( NAME “test” )
{
PERMISSIONS (ALL )
{}
RESTRICTIONS
{
“changelevel boot_camp”
}
}

No member could change the level to boot_camp. Normally this would be impossible to prevent because boot_camp can not be removed from the server. However, if someone really did not want the map being played, they could prevent it. Any admin should also be away of vote.txt which prevents votes from being called by clients. “changelevel boot_camp” is a poor example. A better example is “vadministration groupname” which we will get to later.

Now lets take a look at the keyword MEMBERS

GOUP ( NAME “test” )
{
PERMISSIONS (ALL)
{}
RESTRICTIONS
{
“rcon_password”
}
MEMBERS
{
“0:123456”
“1:789123”
}
}

Again, each member in the group is a text string surround by quotes. Members are defined by their appropriate STEAM ID’s. To find your steam id, type either status or users in the console when you are playing online on any server other then your own.

Any player who joins a server will be automatically added to a group if they are a member. No other players will be allowed to use that group’s functionality unless they enter the group’s PASSWORD if there even is one.

Using the parameter keyword ALL with the functional keyword MEMBERS would put any player in the server in that group. This would not be wise is the groups permissions were very powerful, but it might be useful for a group with some simple server commands that you wish all players who care to, to be able to manipulate. The syntax would look like this MEMBERS (ALL ) { }

Now lets take a look at the last keyword PASSWORD. This is a parameter keyword which can only be used in a GROUP’s parameter list like this:

GROUP ( NAME “test” , PASSWORD “123” )

Notice the comma which separates the password and name. The comma is required.

The password is used as an alternative for clients to join groups. A client may be using another PC and may wish to join the group he or she is normally in but can’t because the STEAM id does not match. Using the client command vrcon_password 123 would put that client into the group (so long as the password matches) until the server restarts or map changes. It’s more of a temporary solution. Group passwords are not required.

One last note about the vdmin.txt file. Spacing, tabs, or returns do not matter so long as they are not inside quotes.

GROUP(NAME”test”,PASSWORD”123”){}

would be just as valid as…

GROUP
( NAME “test” ,
PASSWORD “123”
)
{
}

In game server commands and manipulation

Everything you can do in the file you can do in the game. Some things are convent for editing in the game like adding members to a group because you have their STEAM ID on hand. Let’s take a look at some of the basic server commands

add

This command is useless on its own. It’s normally followed by several other commands. Without talking to much about this, lets just look at the possibilities

add permission <group name> <permission>

Where <group name> and <permission> would be the group and permission you wish to add to that group. For example add permissions test changelevel. Note that the chevron arrows are only used to indicate that those words should be replaced. You should not type the arrows when using the command.

add restriction <group name> <permission>

Works the same way as add permissions

add password <group name> <password>

Sets the password to the specified group. Example: add password test 123

add member <group name> <player name or steam id>

This command works the same as the rest; however you can either submit the players screen name or his or her steam id if the name is too hectic to type. To find a player steam id, type users in the console.

Example: add member test 0:123456 or… add member test Player

add blockall <group name>

This command is a special command to remove the ALL parameter from the permissions list. Note that it removes the ALL command even though you are adding it. Essentially you are adding a restriction

Likewise with add, there is remove. The remove commands work nearly the same as add

remove permission <group name> <permission>

remove restriction <group name> <permission>

remove password <group name> <password>

add member <group name> < steam id>

Note that only the steam id will work for move, the players name will not.

remove blockall <group name>

In game client commands

vrcon

this works just like rcon. It is your gateway into your vadmin group. If you are not a vadmin you will not be allowed to use this command.

vrcon_passoword

This is a client command which sets a client’s password, and assigns him or her to the group matching that password

vgroup <group name>

This shows your current groups permissions and restrictions.

Example: vgroup users

vadministration <group name>

This command shows the groups admin won ID and there name (if they are in the server) and the groups password.

Example: vadministration admin

vgroup and vadministration are the only two client commands that work like server commands. Therefore they can be blocked just like any other command. It is wise to block vadministration from lower group levels as they could see the password to higher group levels for example, if “admin” was your highest group and “mod” was just below that, then a restriction for “mod” should be “vadministration admin”. Likewise if “users” was a group below “mod” then two restrictions for “users” should be “vadministration admin” and “vadministration mod”. Keep in mind that there is no hierarchy with groups. It is merely how you implement them based on restrictions and permissions. It is up to the server administrator to developer a group scheme that works in some sort of hierarchical order. The default vadmin.txt file is set up in this fashion.

The default vadmin.txt config is a good foundation for you as an admin to begin with. You can modify that file to you needs and use examples from that file as references. If you have any further questions please post them on the hle forums at

http://www.rage-board.com/rageboard/index.php?showforum=3

or email me at

kyle@hl-elite.com