Voxelius server hosting tutorial

Because you The Reader can host your own Voxelius server anywhere at any time, I decided to publically showcase how is the public test server being operated and also provide a bunch of scenarios in which additional setup can be needed.

NOTE: this tutorial is focused on setting up a Voxelius server using systemd services and as a consequence is for Linux only; if you’re hosting a public server on Windows (how perverted!), you’d have to do things yourself!

Prerequisites

A server running a Linux distribution that uses systemd
Access to the server console (for remote/monitor-less servers SSH is the industry standard, but you can also just slap a dumb terminal to an RS-232 port and use it to set the server up, I’m not your mom)
Basic knowledge of Linux administration and Linux filesystem hierarchy

Filesystem hierarchy

For some reason, systemd freaks out whenever the running user’s home directory is touched in any way, but only when the directory resides in /home/, so we’re not going to run the server from there and instead make a new directory in /opt/ which, according to FHS, hosts applications that do not necessarily follow FHS/UNIX filesystem hierarchy and store things however they want:

# mkdir -o /opt/voxelius

For the sake of general safety, we need a specific user to run the server as; and because we don’t really need to login as that user, we set their shell to be /sbin/nologin which immediately ends a session as soon as the user logs in:

# useradd -d /opt/voxelius -s /sbin/nologin voxelius

Now we transfer ownership of the directory to the pseudo-user:

# chown -R voxelius:voxelius /opt/voxelius

Then, sudo into the user (NOTE: this requires sudo to be installed, and if it isn’t, please ensure to install it with your system’s package manager)

# sudo -u voxelius -s ${SHELL}
$ cd /opt/voxelius

Downloading binaries

On a desktop, navigate to https://github.com/untolabs/voxelius/releases and go to the latest available release, then copy the download link for a zip archive that ends with your preferred platform and CPU architecture

Then, on the server, navigate to /opt/voxelius/ and download your chosen binary release archive (NOTE: this requires wget to be installed, and if it isn’t, please ensure to install it with your system’s package manager)

$ wget https://github.com/untolabs/voxelius/releases/download/0.0.1.2453/voxelius-0.0.1.2453-linux64.zip

Unpack the archive (NOTE: this requires unzip to be installed, and if it isn’t, please ensure to install it with your system’s package manager)

$ unzip voxelius-0.0.1.2453-linux64.zip

NOTE: if you’re using this tutorial to upgrade the existing server and you were also using this tutorial to set it up in the first place, the directory /opt/voxelius/server should already exist, so make sure to rename it to something that the service script won’t touch, like /opt/voxelius/server.old

Rename the unpacked directory and name it server

$ mv voxelius-0.0.1.2453-linux64 server

Exit the pseudo-user session by typing exit and pressing ENTER, or use a keyboard shortcut Ctrl+D to send EOF and terminate the session this way;

Service script

Create a file /etc/systemd/system/voxelius-server.service with the following contents:

[Unit]
Description=Voxelius Server
Wants=network-online.target
After=network-online.target

[Service]
User=voxelius
Group=voxelius
WorkingDirectory=/opt/voxelius/server
ExecStart=/opt/voxelius/server/vserver --use-syslog --verbose --userpath /opt/voxelius/instance
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

The script would run the server and set its write path to /opt/voxelius/instance; the write path (user path) is a location to which the client/server executable will save things like configuration, world saves and other things. By default it should be located in /opt/voxelius/.voxelius but I don’t feel like it’s a good place for a server.

Refresh the daemon cache:

# systemctl daemon-reload

Start and enable the server:

# systemctl enable --now voxelius-server.service

Observe server logs in real-time:

# journalctl -fu voxelius-server.service

Updating configuration

Stop the server:

# systemctl stop voxelius-server.service

The server has created a configuration file located at /opt/voxelius/instance/server.conf and it should look somewhat like this:

game.password =
game.listen_port = 43103
game.status_peers = 4
game.view_distance = 8
worldgen.seed = 42
sessions.max_players = 16
whitelist.filename = whitelist.txt
whitelist.enabled = false
server.tickrate = 30

And here’s a list of all the options you can edit:

game.password: sets global server access password; if whitelist is enabled, entries without a password set will use this value as a password for connecting;
game.listen_port: the UDP port the game server listens for connections on and clients use to connect to the server; the game doesn’t allow ports below 1024;
game.status_peers: the amount of available peer slots to receive status requests;
game.view_distance: a quote-unoquote “RADIUS” in chunks in which server-bound chunk request packets are accepted and responded to with a loaded chunk;
worldgen.seed: world generator seed (I think it’s unused and just found its way into release config by mistake, my apologies);
sessions.max_players: the amount of available peer slots for client sessions;
whitelist.filename: sets the filename at which the server looks for whitelist entries; ignored when whitelist.enabled is false;
whitelist.enabled: sets whether to use whitelist to filter out players or not;
server.tickrate: the server will try to simulate the world at this rate;

The whitelist

If you want to only allow players with specific usernames to connect to the server, set whitelist.enabled to true and create a new file named whitelist.txt in the same directory as the server config (if you changed whitelist.filename then use that instead of the default path).

Here’s an example of a server whitelist; I will explain it line-by-line below:

pqcraft:gaspassword
untodesu

This whitelist allows only two players (untodesu and pqcraft) to connect; while the player named untodesu can connect to the server using the global password (that is set by game.password value in config), the player named pqcraft can only connect to the server using gaspassword as a password string.

Finishing up

After you’re done tinkering with configuration, start the server again and ensure your server can actually listen on the UDP port you chose (might be a matter of opening a port in your hosting provider’s dashboard or, if you self-host, might be a matter of opening up your router’s control panel and setting up some port forwarding rules)

If you have any questions, issues, encountered a bug or want to suggest a feature, feel free to create an issue in the project’s issue tracker