srb2ms-evo

srb2ms-evo - An on-scratch rewrite of SRB2 2.1 and 2.2 master server

Install

First, install Go and Git, then run the following commands:

git clone https://codeberg.org/srb2classic/srb2ms-evo.git
cd srb2ms-evo
go install

An executable should appear at ~/go/bin/srb2ms-evo, put it at an appopriate place and run it. You can pass the -config parameter to the program to specify the path to the configuration file.

Configure

For the bridge to work, a basic configuration file is needed. The configuration file uses an INI-style format, but without the = between keys and values, as well as a more free-form format to each entry. This placeholder can be used for configuring the bridge:

[Versions]
# Legacy 2.1 configuration, ID is used to validate the version while Ver is used to denote the most recent version.
LegacyId 32
LegacyVer v2.1.27

# Classic 2.2 configuration
ClassicId 56
ClassicVer v2.2.15

# Retro 2.0 configuration
RetroId 207
RetroVer v2.0.7

# Kart configuration
KartId 11
KartVer v1.6

[Web]
# Web template used for listing servers
Template template.html

[Rooms]
# Room definitions, each room start with an "index: name" followed by it's description
# Note that it is strongly adviced to keep a blank line after the description to ensure the room ID end up in the right place!
1: Standard
Contains servers that are played similarly to singleplayer, in one form or another. Can be both cooperate and competitive.

Note that circuit also falls into this category!

2: Action
Competitive servers that focuses more on fighting and action-style gameplay rather than traditional platforming. Ringslinger servers fall into this category.

3: Other
Servers that do not fit in any other category. These are often heavily modded and are normally unconventional.

0: All
Displays servers from all rooms.

[Bans]
# Bans are listed here, containing 4 fields: start range of IPs, end range of IPs, expiration date of the ban, and the ban reason.
# Note that since ban info endpoints were removed in 2.2, the ban reason is only used in 2.1 and 2.0, but it's still good practice to specify them.
192.0.2.0 192.0.2.255 2024-08-10T00:00:00Z ban 1
198.51.100.0 198.51.100.127 2024-08-10T00:00:00Z ban 2
2001:db8::1 2001:db8::200 9999-12-31T00:00:00Z ban 3

You can specify which configuration file to use by passing -config to srb2ms-evo on startup, and can be reloaded at any time by sending SIGHUP to the process.

NOTE: 2.2 is called "Classic" for future reasons as 2.3 has been announced to be in development, so calling it "Current" would be short-sighted.

Styling

While the master server works fine on it's own, it does not automatically resolve resources. To do that, you need a reverse proxy, which can easily be configured with Apache or Nginx.

Sample configuration for Apache:

# Note that you need to enable mod_proxy and mod_proxy_http first!
<VirtualHost *:80>
	# Change localhost to your own domain
	ServerName localhost
	ProxyPassMatch "^/$" "http://[::1]:8000"
	ProxyPassMatch "^/MS/[01]/(.*)$" "http://[::1]:8000/MS/0/$1"

	Alias "/resources" "/path/to/srb2ms-evo/resources"
	<Directory /path/to/srb2ms-evo/resources>
		AllowOverride None
		Require all granted
	</Directory>
</VirtualHost>

Sample configuration for Nginx:

server {
	listen 80;
	listen [::]:80;

	# Change localhost to your own domain
	server_name localhost;

	location /resources {
		root /path/to/srb2ms-evo;
	}

	location / {
		proxy_pass http://[::1]:8000;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $host;
	}
}

Sample configuration for LigHTTPd:

server.modules += ( "mod_proxy" )

# Change localhost to your own domain
$HTTP["host"] == "localhost" {
	$HTTP["url"] =~ "^/resources/.*" {
		server.document-root = "/path/to/srb2ms-evo/"
	}

	$HTTP["url"] == "/" {
		proxy.server = ( "" => ( ( "host" => "::1", "port" => 8000 ) ) )
	}

	# The following is only necessary if Classic and/or Kart is enabled
	$HTTP["url"] =~ "^/MS/[01]/.*" {
		proxy.server = ( "" => ( ( "host" => "::1", "port" => 8000 ) ) )
	}
}

Reloading

The configuration can be reloaded on-the-fly by sending a SIGHUP to the program. If the configuration fails to load, the program will revert to the previous configuration and an error will be printed. In addition, a hot restart can be performed by sending a SIGUSR1 to the process, causing it to write it's current state to /tmp before restarting itself, and the loading the state back in after restart. This allows for software updates while still keeping server tables intact.