Tutorial Creating a Multiplayer server on CentOS 7

I'm gonna try this again- last time I couldn't post because of this reason or that reason..

I was trying to setup a CentOS Starbound server and I found a post by kaski and thought it would be a good idea to update it for CentOS 7. If you can follow the original post, then great! Either way, I hope this helps too.

First thing to point out is that I installed the server with as minimal a setup as I thought I could. When I was doing the Cent OS install, I selected the "Infrastructure Server" option and "Guest Agents" add-on when at the software selection screen. This means that you may have to install other packages I don't mention, or may not have to install anything else. Your mileage will vary.

A very helpful piece of information: "yum whatprovides" is you friend. When you run a piece of software during this tutorial, type "yum whatprovides <missing file>" and you will be told about the packages that you can install to get that missing file. I will write more about how to use "yum whatprovides" later.

This guide is broken down into the following steps:

1. Installing steamcmd and performing the initial Starbound install.
2. Creating the firewalld script to enable Starbound to work through the firewall (instead of turning it off).
3. Creating a systemd service script to start and stop your Starbound server as a service and set it to start with your server.
4. Creating an update script that can be used to automatically update your server and create a log manager to prevent the logs from getting hideously large.

1. Steamcmd and Starbound Installation

First, install the two 32 bit libraries that steamcmd needs. Again, you might need more depending on existing packages on your server.

Code:

sudo yum install glibc.i686 libgcc.i686

Next, select a place to store and run steamcmd and Starbound. I chose /usr/local/share, but you can pick a place more to your liking. In your chosen folder, create a folder for steamcmd, and "cd" into the new folder.

Code:

cd /usr/local/share
mkdir steamcmd
cd steamcmd

Now download the steamcmd tarball from Valve and extract it.

Code:

wget http://media.steampowered.com/installer/steamcmd_linux.tar.gz
tar zxvf steamcmd_linux.tar.gz

Update the permissions on steamcmd.sh so we can run it, then run it.

Code:

chmod +x steamcmd.sh
steamcmd.sh

At this point, you will have issues if all the 32 bit libraries that Steam needs are not installed. you will get errors like

Code:

/usr/local/share/steamcmd/linux32/steamcmd: error while loading shared libraries:
libgcc_s.so.1: cannot open shared object file: No such file or directory

This is where "yum whatprovides" comes in. I ran the following command and saw the following results:

Code:

[user@centos7 steamcmd]> yum whatprovides libgcc_s.so.1
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
* base: mirror.chpc.utah.edu
* epel: linux.mirrors.es.net
* extras: mirrors.kernel.org
* updates: mirrors.psychz.net
libgcc-4.8.2-16.el7.i686 : GCC version 4.8 shared support library
Repo        : base
Matched from:
Provides    : libgcc_s.so.1

libgcc-4.8.2-16.2.el7_0.i686 : GCC version 4.8 shared support library
Repo        : updates
Matched from:
Provides    : libgcc_s.so.1

In this case, we are told about two packages that provide this missing file. Since we want to download the most up-to-date version,we only need the name up to the dash. Since we want the 32 bit version, we add ".i686" to the end:

Code:

[user@centos7 steamcmd]> sudo yum install libgcc.i686

Repeat as necessary to get steamcmd to run.

Once you are running steamcmd, you will need to login and download Starbound. Start by logging in with your Steam username and password:

Code:

Steam>login user

Logging in user 'user' to Steam Public...
password: MyPa55W0rd

If you as paranoid as I am, you will get the following:

Code:

This computer has not been authenticated for your account using Steam Guard.
Please check your email for the message from Steam, and enter the Steam Guard
code from that message.
You can also enter this code at any time using 'set_steam_guard_code'
at the console.
Steam Guard code:

At this point, check you email, and supply the code that Steam sends you to continue. If all went well, you will see the following:

Code:

Logged in OK
Waiting for license info...OK

Steam>

Pick a place to download Starbound to. If you do not run this command, it will install Starbound into ~/Steam/steamapps/common/Starbound.

Code:

force_install_dir /usr/local/share/starbound/

Next, download the Starbound program:

Code:

app_update 211820 -beta unstable validate

NOTE: you can get the app ID by looking at the Steam store page for Starbound or looking at the Starbound shortcut properties on your Windows desktop. It is the ending number part of the URL.

You can chose to omit "-beta unstable", but that's the version you're looking for, right? If left out, you will install the current release version, which is way behind on the current development Chucklefish is working with. Unstable is much more current, but likely to have some brokenness to it. Or you can really press your luck with the nightly build by using "-beta nightly". You have been warned. Oh, and remember that your clients must be on the same version as the server, so tell your friends which version to use!

EDIT: As of Jan 29, 2015, Chucklefish has updated their stable release to Upbeat Giraffe! I'm actually now using the stable release by omitting the "-beta unstable". Don't forget to edit your update script if that is what you want to do!

At this point, the Starbound program has been installed in either your home directory at ~/Steam/steamapps/common/Starbound or at the location you specified before the download. To test run the Starbound server, use the following commands:
To start your server:

Code:

cd <where Starbound was downloaded to>/linux64
./starbound_server

You should now see your server come to life. Wait a couple of moments for the output to display this:

Code:

Info: bind [ipv4]*:21025 (9)

This is the server telling you is has grabbed a port to listen to for incoming clients. This is the point your Starbound server is ready to play!

2. Firewalld Configuration

I did mention that the firewall was still blocking your clients from accessing the Starbound server software, right? If you just tried to connect and were disappointed, hit CTRL-C to quit the server for now and let's fix the firewall. It's a piece of cake; I've done all the research for you.

Start by creating a starbound.xml file in /etc/firewalld/services (I use vi; use the text editor of your choice on the server):

Code:

cd /etc/firewalld/services
vi starbound.xml

Type the following, save, and exit the editor:

Code:

<?xml version="1.0" encoding="utf-8"?>
<service>
<short>Starbound</short>
<description>Starbound Universe Server</description>
<port protocol="tcp" port="21025"/>
<port protocol="udp" port="21025"/>
</service>

Last fix the file we just made so that firewalld doesn't ignore it:

Code:

restorecon starbound.xml
chmod 640 starbound.xml

Last, we update the firewall settings to allow the starbound server to be reached on the network:

Code:

firewall-cmd --permanent --add-service=starbound
firewall-cmd --reload

Now we can test out the server! Type the commands in the "to start your server" section above, and now your clietns should be able to connect!

3. Starbound as a Service

Now that the server runs and clients can connect, let's setup your server to run Starbound as a server. What this means is that starbound_server will start up when your server starts up and will be gently shut down when your server shuts down. This used to be a real pain in older versions of Linux; I've written init.d scripts to start Teamspeak and other software, but when I saw what was needed to get software to run as a service in CentOS 7, I was pleasantly surprised.

The new systemd software only requires the creation of a file that defines your Starbound service. If you are in a hurry, you can hurry through the directions and copy and paste as needed, but knowing what the service file does might help you troubleshoot your installation if needed. NOTE: following these directions in any way does not obligate me or anyone else to troubleshoot your server. I too am guilty of posing a n00b "it's broke" post a couple days ago- moderators forgive me.

To properly setup a service, we want to create a user account just for Starbound to run as. This protects your server in case someone should figure out how to use the Starbound server software to hack your computer. Also, set the starbound account to own the Starbound program files so when the service starts, the software can see and use the files to work properly.

Code:

sudo adduser starbound -s /sbin/nologin
sudo chown -R starbound /usr/local/share/starbound

This creates a starbound user that cannot be directly logged into and sets this account as the owner to all the files, allowing starbound_server to create, edit, read, and delete all the files if needs to in order to work correctly.

Next use your text editor to create the /etc/systemd/system/starbound.service file. This tells systemd about your new service.

Code:

vi /etc/systemd/system/starbound.service

Type and save the following to your file:

Code:

[Unit]
Description=Starbound Game Server
After=network.target

[Service]
Type=simple
User=starbound
ExecStart=/usr/local/share/starbound/linux64/starbound_server
WorkingDirectory=/usr/local/share/starbound/linux64
KillSignal=SIGINT
TimeoutStopSec=120
StandardInput=null
StandardOutput=journal
Restart=on-abort

[Install]
WantedBy=multi-user.target

The filename (with or without the .service ending) is the name of your service. The Unit section is the descriptive information displayed when your service is started or stopped and tells systemd that this service can start after the network is up. The Install section says that when the server boots into multi-user mode (is ready for people to login remotely for the OS) then start this service. The Service section deserves some discussion, but if you're in a hurry skip ahead.

The Type=simple is apparently common for these scripts. User=starbound sets the service to start as your "starbound" account. Change this to the name of the account you want to run your server as. ExecStart tells systemd what program is going to run as the service. WorkingDirectory is needed to cause the server to use the Starbound installation directory as the starting point for all of its file access. This this is not a RootJail, which would restrict the program to just that directory. If you want your server install to have that security, you're welcome to go there. KillSignal is important- it is how systemd tells your Starbound to shutdown. Normally it sends SIGTERM- which terminates the program. Chucklefish did not write their software to handle this type of signal gracefully- it effectively crash stops your server and writes no additional data to disk, which may break your universe files. The only way to gracefully shut down your Starbound server is with SIGINT- the interrupt signal, which happens when you hit CTRL-C while running the server on the command line. TimeoutStopSec gives the Starbound server 120 seconds to nicely stop itself before systemd kills it. Standardinput prevents external sources from trying to "type" into the Starbound server, and StandardOutput records the output text you'd normally see to the systemd journal, which is not a bad place to store this data. It allows you to review the server output using system commands, but the server also writes logs in unstable_storage, too. Last, Restart=on-abort will restart the Starbound server software if it genuinely crashes.

To test your service, run the following:

Code:

systemctl start starbound

If there is no immediate error, you will see no response. To verify that the Starbound server software is trying to do something, run the following:

Code:

 systemctl status starbound

As long as there is a line that reads "Active: active (running)", the Starbound server is running. This command also lists the last ten lines written by the server. Again look for the "bind [ipv4]" lines to let you know that your server is ready for connections. If you don't see this immediately but instead see lines about loading Star::Root, then wait about 30 seconds, then run the command again.

At this point, connect with your client again. If things are working fine, then the service is configured correctly.

The last thing to do is to make the service start with the computer:

Code:

systemctl enable starbound

Congratulations, your Starbound server is ready to go!

4. Updater Script

That is, until your clients update to the next version of Upbeat Giraffe, then no one can connect. So we are going to create an update script. It will check to see that no one is connected, and if no one's there it will stop the service, update the sotftware, and restart the service. As an added bonus, we can write a one-line command to cause the server to run this script daily or even hourly (my preference).

Create the a file for the script at /usr/local/share/starbound/starboundupdate.sh:

Code:

vi /usr/local/share/starbound/starboundupdate.sh

Copy the following in, and change your steam username appropriately:

Code:

#!/bin/bash
STARBOUND_LOG=/var/log/starboundupdate.log
if ! netstat -nt|grep ":21025">/dev/null; then
(
  echo Updating Starbound at `date`.
  systemctl stop starbound
  cd /usr/local/share/steamcmd
  ./steamcmd.sh +login user +force_install_dir /usr/local/share/starbound/ +app_update 211820 -beta unstable validate +quit
  chown -R starbound /usr/local/share/starbound
  systemctl start starbound
  echo Done at `date`.
) >> $STARBOUND_LOG
fi

Last, run the following command so we can run the script:

Code:

sudo chmod +x /usr/local/share/starbound/starboundupdate.sh

We can now test the update script (NOTE: you must be root so the service will start and stop):

Code:

sudo /usr/local/share/starbound/starboundupdate.sh

If a client is connected, the script should do nothing. If no clients are connected, you should have a long pause before the prompt comes back; this is the couple minutes it takes for your server to hash and verify the program files. It will take longer if there is an actual update, so please be patient! You can see the results of this command with the following:

Code:

less /var/log/starboundupdate.log

Next, we can setup a logrotate file to rotate the update log. For this, I suggest daily with a 14 day log retention. Create the file:

Code:

sudo vi /etc/logrotate.d/starboundupdate

Type and save the following:

Code:

/var/log/starboundupdate.log {
    rotate 14
    missingok
    notifempty
}

This will keep 14 days of logs and will not panic if the updater never runs.

Last, we can have the script run automatically so that the server is running the most recent version of the software as possible. How often is your call. My example will setup the server to be updated (if no one is logged in) every hour.
Run this command to automate your server updates:

Code:

ln -s  /usr/local/share/starbound/starbound.sh /etc/cron.hourly

NOTE: You can use cron.daily to run at midnight only.

This should do it! I hope you find this useful; please let me know how this could be better. Also please post if you were able to get your server up and working. It's always good to hear about others successes, too!

Wilminator

 

I was looking for a systemd guide to turn Starbound into a service. Your guide worked like a charm, many thanks to you!