If you’ve got next to no memory and CPU available to run a Minecraft server, don’t fret. Cuberite is what you’re after. At them moment, Cuberite isn’t bug-free, nor indiscernible from a genuine Minecraft server, but it’s quite usable – and instead of needing 4GB+ of RAM, it needs less than 300MB. And it needs next to no processing power: some people run Cuberite on their Raspberry Pi and have plenty of CPU available.
I would at this point go on about how this is a significant point of difference between C++ and Java, but Java optimizes for something different to C++. I got into an interesting discussion with Cathy about this after reading a question someone had about what Java was trying to be good at. I used to think that VB was the new COBOL, but clearly Java is the new COBOL; those Java programs are going nowhere, they’re verbose and easy to understand and maintain.
A point to note: The Minecraft protocols are bandwidth heavy, I found if I wanted to run a server at home I’d be able to have one, perhaps two players. Thus is Internet in Australia. Instead I’ve dropped this onto a free AWS VPS instance and bandwidth is no problem.
Still, it’s a random piece of software off the Internet, so we’re going to give it its own user account for our own safety. Let’s install the software:
curl -sSfL https://download.cuberite.org | sh
sudo mv Server /usr/local/cuberite
cd /usr/local/cuberite
Cuberite allows configuration through a web interface. We now enable webadmin.ini
[User:admin]
; Please restart Cuberite to apply changes made in this file!
Password=yourstrongpassword
[WebAdmin]
Ports=8080
Enabled=1
Port 8080 is the alternative html port (http/https). You could cd into webadmin and run GenerateSelfSignedHTTPSCertUsingOpenssl.sh and get https serving, but your browser will barf on the certificate. Instead, let’s use a LetsEncrypt certificate, one that we installed earlier. First we make our one-line shell script for running the daemon:
sudo useradd -c "Cuberite server" -f -1 -M -r cuberite
chown -R cuberite:`whoami` /usr/local/cuberite/
sudo nano /etc/init.d/cuberite.sh
#!/bin/sh
### BEGIN INIT INFO
# Provides: cuberite
# Required-Start: $local_fs $network
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: cuberite
# Description: Cuberite server, a Minecraft server lookalike
### END INIT INFO
cd /usr/local/cuberite
sudo -u cuberite /usr/local/cuberite/Cuberite -d &
Next we set it going when the box starts up:
sudo chmod +x /etc/init.d/cuberite.sh
sudo update-rc.d cuberite.sh defaults
Before we can go to the website we need to allow user cuberite to get to the certificates:
sudo groupadd privkey_users
sudo usermod -aG privkey_users cuberite
sudo sudo chmod g+rx /etc/letsencrypt/live/
sudo sudo chmod g+rx /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/cert1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/chain1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/privkey1.pem
sudo chown root:privkey_users /etc/letsencrypt/archive/example.com/fullchain1.pem
sudo chown root:privkey_users /etc/letsencrypt/live/
sudo chown root:privkey_users /etc/letsencrypt/live/example.com/
sudo -u cuberite ln -s /etc/letsencrypt/live/example.com/cert.pem /usr/local/cuberite/webadmin/httpscert.crt
sudo -u cuberite ln -s /etc/letsencrypt/live/example.com/privkey.pem /usr/local/cuberite/webadmin/httpskey.pem
Changing these permissions doesn’t affect apache2’s ability to get them.
The reason we’ve used a group here is to allow both Cuberite and any other app (for example, exim) to access the private keys; just add any other user that needs to use the private keys to the privkey_users group.
Remember to punch a firewall hole for port 8080. Fire up Cuberite now:
sudo service cuberite restart
And check if that worked, there should be about one entry:
ps -aux | grep cuberitps -aux | grep cuberit
If not, you can check in the logs directory to see what’s wrong.
So now:
sudo lsof -i :8080
https://example.com:8080/
should be secure. Note the https is mandatory, as your browser will use http if you fail to specify a protocol.
