Difference between revisions of "Remote Administration"
(Created page with "==Overview== As of build 580, the KAG server has remote RCON capabilities, when enabled. This means that you can administer your server without joining via the game client. Thi...") |
m |
||
| (7 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
==Overview== | ==Overview== | ||
As of build 580, the KAG server has remote RCON capabilities, when enabled. This means that you can administer your server without joining via the game client. This is achieved by using telnet to connect to the game port over TCP, or using a remote administration client as they become available. | As of build 580, the KAG server has remote RCON capabilities, when enabled. This means that you can administer your server without joining via the game client. This is achieved by using telnet to connect to the game port over TCP, or using a remote administration client as they become available. | ||
| + | |||
| + | With the addition of this feature, you can also type commands directly into the server CLI. The only caveat is that the interface is not asynchronous - if any output comes from the server while you are typing your command, your input will visually be disrupted. However, your command is actually not interrupted and will work fine if you finish typing it and hit enter. | ||
| + | |||
| + | '''Note:''' sv_tcpr must be enabled (as described below) for server CLI commands to work. This is because sv_tcpr enables the thread and logic which snarfs up tcp and CLI commands. As such, this also is not available on Windows | ||
==Configuration== | ==Configuration== | ||
| Line 7: | Line 11: | ||
When enabled, the KAG server will bind to sv_ip and sv_ipv6 on the game port on TCP. If only sv_ip is configured (sv_ipv6 is still blank or 0), only IPv4 will be bound. If both are configured, both addresses will be bound. If both are unconfigured (empty or 0), all IPv4 and IPv6 addresses will be bound. | When enabled, the KAG server will bind to sv_ip and sv_ipv6 on the game port on TCP. If only sv_ip is configured (sv_ipv6 is still blank or 0), only IPv4 will be bound. If both are configured, both addresses will be bound. If both are unconfigured (empty or 0), all IPv4 and IPv6 addresses will be bound. | ||
| + | |||
| + | '''Note:''' If you enable tcpr and leave it open to the Internet, unfirewalled, you should ensure you have a complex/secure RCON password that cannot be easily guessed. | ||
==Protocol== | ==Protocol== | ||
| Line 25: | Line 31: | ||
Currently the output from all commands run from any client will be sent to all other clients (including in-game admins). This is a design decision that predates the implementation of TCP Rcon and is not currently slated to be changed. As such, rich GUI frontends for TCP Rcon connections may be difficult since there is no surefire way to identify which output goes with commands sent from a specific client. | Currently the output from all commands run from any client will be sent to all other clients (including in-game admins). This is a design decision that predates the implementation of TCP Rcon and is not currently slated to be changed. As such, rich GUI frontends for TCP Rcon connections may be difficult since there is no surefire way to identify which output goes with commands sent from a specific client. | ||
| + | |||
| + | ===Safe Assumptions=== | ||
| + | The following assumptions should be safe (barring bugs and behaviors not known or understood as of this writing): | ||
| + | * Output resulting from a command executed should always begin with the command itself being echoed back (see the example below) | ||
| + | * Commands submitted by tcp admins, valid or invalid, will be displayed to all in-game and tcp admins so that it is possible to tell who executes what commands. This is also logged. | ||
| + | * Commands executed at "the same time" (or close to it) will never have their outputs mixed. Commands, once they are being executed, are done so atomically. Their output should appear atomically; that is, the output should never be interrupted by another [unrelated] message appearing in the middle of a command's output. | ||
| + | |||
| + | ==Additional Examples== | ||
| + | ryan@ubuntu:~/kagdev_local/trunk$ telnet ::1 50311 | ||
| + | Trying ::1... | ||
| + | Connected to ::1. | ||
| + | Escape character is '^]'. | ||
| + | asd | ||
| + | [23:22:53] TCP RCON Connection from [::1]:46997 is now authenticated | ||
| + | [23:29:43] New TCP RCON connection: 192.168.56.1:58910 | ||
| + | [23:29:44] TCP RCON Connection from 192.168.56.1:58910 is now authenticated | ||
| + | [23:29:47] TCP RCON command from 192.168.56.1:58910: /players | ||
| + | [23:29:47] /players | ||
| + | [23:29:47] List of Players ------ use RCON to get IP and hwid info | ||
| + | [23:29:47] | ||
| + | [23:30:29] TCP RCON Connection connection from 192.168.56.1:58910 has been closed | ||
| + | |||
| + | Here is a line-by-line explanation of the above example: | ||
| + | First a connection is opened to a server running on localhost by connecting to ip6-localhost (::1) on the server's configured game port (50311). | ||
| + | |||
| + | The telnet application shows that a connection is attempted and opened. Once we are told that the connection is open, the first thing we do is type the server's rcon password, which is "asd" | ||
| + | |||
| + | We are told that this connection is now authenticated (this message is sent to all tcp and in-game admins to let them know that a new connection has been authenticated) | ||
| + | |||
| + | Next we see that another admin at 192.168.56.1 (remote port 58910) has connected to the tcp admin port of this server and authenticated. | ||
| + | |||
| + | The user at 192.168.56.1 then executes /players. We see the output of their command which begins with the command itself being echoed. There are currently no players in this server so the list is empty. | ||
| + | |||
| + | The last line tells us that the connection from 192.168.56.1 which we just saw active has been closed (likely due to the user disconnecting). | ||
| + | |||
| + | |||
| + | |||
| + | ==Availability== | ||
| + | This feature is available in KAG >= 580. This feature is not available to servers running under Windows due to the use of low-level POSIX socket system calls. In the event that the KAG server codebase is ported to Mac or BSD, this feature should be available on them as well. | ||
| + | |||
| + | [[Category:Server]] | ||
Latest revision as of 17:35, 16 December 2012
Contents
Overview
As of build 580, the KAG server has remote RCON capabilities, when enabled. This means that you can administer your server without joining via the game client. This is achieved by using telnet to connect to the game port over TCP, or using a remote administration client as they become available.
With the addition of this feature, you can also type commands directly into the server CLI. The only caveat is that the interface is not asynchronous - if any output comes from the server while you are typing your command, your input will visually be disrupted. However, your command is actually not interrupted and will work fine if you finish typing it and hit enter.
Note: sv_tcpr must be enabled (as described below) for server CLI commands to work. This is because sv_tcpr enables the thread and logic which snarfs up tcp and CLI commands. As such, this also is not available on Windows
Configuration
This feature is enabled by setting sv_tcpr to 1 in the server configuration. If this variable is not in your configuration, it will be added after starting/stopping your server on a build >= 580, or you may add it manually (less recommended).
When enabled, the KAG server will bind to sv_ip and sv_ipv6 on the game port on TCP. If only sv_ip is configured (sv_ipv6 is still blank or 0), only IPv4 will be bound. If both are configured, both addresses will be bound. If both are unconfigured (empty or 0), all IPv4 and IPv6 addresses will be bound.
Note: If you enable tcpr and leave it open to the Internet, unfirewalled, you should ensure you have a complex/secure RCON password that cannot be easily guessed.
Protocol
Upon connecting to the port, the client must send \n-terminated string consisting of the server's rcon password.
If the password is incorrect, the server will close the connection.
If the password is correct, the server will immediately begin sending all console output to the client. The first line is usually something like that shown below. While this line will always show up, it may not be the first line sent back to the client depending on what other activity is going on in the server.
ryan@ubuntu:~/kagdev_local/trunk$ telnet ::1 50311 Trying ::1... Connected to ::1. Escape character is '^]'. asd [23:22:53] TCP RCON Connection from [::1]:46997 is now authenticated
After the connection is open and authenticated, any \n-terminated string will be handled as a console command. Adding /rcon is unnecessary, as this is a connection to the server hence all commands will be executed server-side.
Currently the output from all commands run from any client will be sent to all other clients (including in-game admins). This is a design decision that predates the implementation of TCP Rcon and is not currently slated to be changed. As such, rich GUI frontends for TCP Rcon connections may be difficult since there is no surefire way to identify which output goes with commands sent from a specific client.
Safe Assumptions
The following assumptions should be safe (barring bugs and behaviors not known or understood as of this writing):
- Output resulting from a command executed should always begin with the command itself being echoed back (see the example below)
- Commands submitted by tcp admins, valid or invalid, will be displayed to all in-game and tcp admins so that it is possible to tell who executes what commands. This is also logged.
- Commands executed at "the same time" (or close to it) will never have their outputs mixed. Commands, once they are being executed, are done so atomically. Their output should appear atomically; that is, the output should never be interrupted by another [unrelated] message appearing in the middle of a command's output.
Additional Examples
ryan@ubuntu:~/kagdev_local/trunk$ telnet ::1 50311 Trying ::1... Connected to ::1. Escape character is '^]'. asd [23:22:53] TCP RCON Connection from [::1]:46997 is now authenticated [23:29:43] New TCP RCON connection: 192.168.56.1:58910 [23:29:44] TCP RCON Connection from 192.168.56.1:58910 is now authenticated [23:29:47] TCP RCON command from 192.168.56.1:58910: /players [23:29:47] /players [23:29:47] List of Players ------ use RCON to get IP and hwid info [23:29:47] [23:30:29] TCP RCON Connection connection from 192.168.56.1:58910 has been closed
Here is a line-by-line explanation of the above example: First a connection is opened to a server running on localhost by connecting to ip6-localhost (::1) on the server's configured game port (50311).
The telnet application shows that a connection is attempted and opened. Once we are told that the connection is open, the first thing we do is type the server's rcon password, which is "asd"
We are told that this connection is now authenticated (this message is sent to all tcp and in-game admins to let them know that a new connection has been authenticated)
Next we see that another admin at 192.168.56.1 (remote port 58910) has connected to the tcp admin port of this server and authenticated.
The user at 192.168.56.1 then executes /players. We see the output of their command which begins with the command itself being echoed. There are currently no players in this server so the list is empty.
The last line tells us that the connection from 192.168.56.1 which we just saw active has been closed (likely due to the user disconnecting).
Availability
This feature is available in KAG >= 580. This feature is not available to servers running under Windows due to the use of low-level POSIX socket system calls. In the event that the KAG server codebase is ported to Mac or BSD, this feature should be available on them as well.
