The right player controls are key for your game. We’ll introduce you player controls used in action-adventure games.
Crystals play an important role in Kordex: Humanity has learned to use its power and lives in harmony with the energy.
25games‘ six team members are spread all over the country. Communication is done via Skype, Whatsapp, Slack, etc. and for the management we use calendars, Trello and other tools (see „One way to manage a team“ – coming next month). But what do you need for your data management? Our requirements are: a cheap solution and full control over the way our data is stored. In this blogpost you’ll learn how we configured a Raspberry Pi as our game developer server to meet our needs. Here’s the table of contents (hover the pulsating points):
What needs to be considered when buying a Raspberry Pi
Prepare your Raspberry Pi
Raspberry Pi – security configuration
Configure an Apache webserver
Software versioning and revision control
Creating your own file hosting service
Wiki application – no database needed
Purchase a Raspberry Pi
Raspberry Model
There are several Raspberry models available – each with it’s pros and cons:
- Raspberry Pi 3 – for projects and media tasks: comes with WLAN and Bluetooth OnBoard
- Raspberry Pi 2 Modell B – like above but without WLAN and Bluetooth OnBoard
- Raspberry Pi Modell B(+) – automation tasks
- Raspberry Pi Modell A(+) – small power usage, but poor performance
Since our Raspberry is connected via Ethernet there’s no WLAN-support needed. With about 10$ electricity costs per year we chose Raspberry Pi 2 Modell B from the list above, because we think that it provides a good trade-off between costs and performance.
Additional equipment
The Raspberry is useless on its own. You require some additional equipment:
- Micro SD Card – we are using a 32GB card like the one linked (less storage for example 16GB is also possible, but we thought more is better since the price difference is not that crucial)
- Power Supply – there’s the same power supply for European sockets here but we use this one because it seems to have better references
- Ethernet cable – the Raspberry Pi 2 has no WLAN OnBoard so you need an ethernet cable (or WLAN-stick) to connect it with your router. We chose to use a cable instead of a WLAN-stick because the server needs to be as fast as possible and it’s stationary anyways.
- External storage – it is recommended to use an external storage for your working data. We bought two 64GB USB-sticks – one is for the working data and the other one is for backups of our DokuWiki. Since ownCloud and SVN are making local copies on each PC of our team members we thought that – for the beginning – it’s enough to only make backups of the DokuWiki.
Preperation of your Raspberry Pi
Prepare SD card
- Download the latest Raspbian-Image
- Plug-in your SD card into your PC
- Download Win32 Disk Imager
- Choose the Raspbian-Image (a), select the SD card’s drive letter (b), click „write“ (c)

Connect to your Raspberry
- Connect your Raspberry with the Router via an ethernet cable
- Plug-in the written SD card into your Raspberry
- Identify the IP address of your Raspberry by taking a look into the router configuration. There should be a list of the connected devices somewhere (a detailed description would go beyond the scope of this article)
- Download Putty (SSH client)
- Open Putty and fill in the identified IP-address
- Enter Login-information. Username: pi / Password: raspberry
- sudo nano /etc/network/interfaces (open interface configuration)
- Change iface eth0 inet dhcp to
iface eth0 inet static address 192.168.x.yy # ip address in local network not in DHCP-pool; use something like 192.168.1.42... netmask 255.255.255.0 # netmask - usually 255.255.255.0 gateway 192.168.x.z # router's ip-address (mostly 192.168.1.1 or 192.168.1.254)
Security configuration
If your team members are spread all over the world like ours, you need to make your services (SVN, ownCloud, DokuWiki) available over the internet. In this section we present the most important tasks to protect your server against hacker attacks.
Replace user pi
Every hacker knows that there’s always a user „pi“ on systems, which run on Raspbian. That’s why you should replace the user „pi“ with another user. To do so firstly create the new user with administrator permissions and set a strong password:
sudo useradd -m newUser -G sudo sudo passwd newUser
Reconnect your PC with your Raspberry Pi via SSH, but login with your newly created user. Now delete the user „pi“:
sudo deluser -remove-home pi
You may realize that you need to retype your new user’s password each time you execute sudo-commands. To avoid this, use the su command to switch to the root user. Then you only have to type in the password once:
sudo su
Automatic updates
It is important to keep your Raspberry up to date. Use these commands:
sudo apt-get update sudo apt-get dist-upgrade sudo rpi-update
After rpi-update you may need to reboot your system with:
sudo shutdown -r now
For automatic updates install the packages „unattended-upgrades“ and „update-notifier-common“ by executing these commands:
sudo apt-get install unattended-upgrades update-notifier-common sudo dpkg-reconfigure -plow unattended-upgrades
Now change /etc/apt/apt.conf.d/10periodic to:
sudo nano /etc/apt/apt.conf.d/10periodic
APT::Periodic::Update-Package-Lists "1"; # daily updates APT::Periodic::Download-Upgradeable-Packages "1"; # daily updates APT::Periodic::AutocleanInterval "7"; # delete unused packages weekly APT::Periodic::Unattended-Upgrade "1"; # daily updates
Configure SSH-access
SSH is not optimally configured in the standard configuration. Open:
sudo nano /etc/ssh/sshd_config
Change the port to something over 1023:
Port 5622
Don’t allow root-login by changing the line which starts with „PermitRootLogin“ to:
PermitRootLogin no
Install the „fail2ban“ package to prevent brute force attacks against your Raspberry:
sudo apt-get install fail2ban
3 wrong logins from a device with a specific IP-address are causing a block of this address for 10 minutes by default. We changed these settings by editing the file /etc/fail2ban/jail.conf to:
sudo nano /etc/fail2ban/jail.conf
bantime = 86400 # = ban for 1 day
Then restart fail2ban:
sudo service fail2ban restart
Firewall configuration
Configure your firewall on your Raspberry Pi to:
- Allow all local connections on the loopback interface
- Drop all strange looking packages
- Accept already opened connections
- Allow SSH and HTTPS (port 8443) connections
- Reject all other connections
Use these commands to do so:
echo "Allow all local connections on the loopback interface" sudo iptables -A INPUT -i lo -j ACCEPT echo "Drop all strange looking packages" sudo iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP sudo iptables -A INPUT -f -j DROP sudo iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP sudo iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP echo "Accept already opened connections" sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT echo "Allow SSH and HTTPS connections" sudo iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 5600 -j ACCEPT sudo iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 8443 -j ACCEPT echo "Reject all other connections" sudo iptables -A INPUT -j REJECT --reject-with icmp-host-prohibited
Use sudo iptables -L to get a list of the current rules. Be aware that the line -A INPUT -j REJECT –reject-with icmp-host-prohibited is always the last rule in your iptables! Just open /etc/network/iptables to edit the rule list:
sudo nano /etc/network/iptables
After editing you always need to save the current rules:
sudo sh -c "iptables-save > /etc/network/iptables"
To automatically load the rules after restarting your server you have to create a little Pre-Up-Script and insert the following lines:
sudo nano /etc/network/if-pre-up.d/iptables
#!/bin/sh /sbin/iptables-restore /etc/network/iptables
Then make the file executable:
sudo chmod +x /etc/network/if-pre-up.d/iptables
Enable Port Forwarding
If you want to make your Apache web server reachable over the internet you need to enable port forwarding on your router. The port forwarding settings can be usually found under the firewall section of your router. But there’s no common standard for where the port forwarding configuration page can be found on the router’s web interface. Follow this link and look for your router. There you can find a detailed description for how to configure port forwarding for your specific router. Create a new rule and fill in the form like this:
In the example above Apache listens on port 8443 and forwards the packages to the device with the IP-address of 192.168.0.xy where the last octet (represented as „xy“ in the image) needs to be replaced by the address of your Raspberry Pi.
Apache with SSL
The apache server is the basis for all our services: SVN, ownCloud and DokuWiki.
Since we don’t want to unencryptedly transfer our important assets, code-files and internal information we configured our Apache server to only accept secure SSL connections.
Installation
Install the latest apache server:
sudo apt-get install apache2
For SSL you need to activate the ssl module:
sudo a2enmod ssl
For SVN we also need more modules:
sudo apt-get install libapache2-svn sudo a2enmod dav_svn
PHP is needed for the DokuWiki and ownCloud. Install these packages:
sudo apt-get install php sudo apt-get install libapache2-mod-php5 # PHP5 sudo apt-get install libapache2-mod-php7.0 # PHP7
Maybe you also need to activate PHP:
sudo a2enmod php5 # PHP5 sudo a2enmod php7.0 # PHP7
Some more packages are required for the ownCloud-Server (you’ll be prompted to create a root password for the MySQL-Database):
sudo apt-get install mariadb-server php4-apcu/trusty-backports sudo apt-get install php5-gd php5-json php5-mysql php5-curl sudo apt-get install php5-intl php5-mcrypt php5-imagick sudo apt-get install redis-server php5-redis
Additionally ownCloud needs these modules to be activated:
sudo a2enmod rewrite sudo a2enmod headers sudo a2enmod env sudo a2enmod dir sudo a2enmod mime sudo a2enmod setenvif
ports.conf
Open the file /etc/apache2/ports.conf:
sudo nano /etc/apache2/ports.conf
Delete the whole content of the file and insert:
<IfModule mod_ssl.c> Listen 8443 https </IfModule>
This tells your apache server that it should listen on port 8443 for SSL connections.
But why not using the standard port 443 for SSL? That’s because especially when you’re a non-commercial user, the most internet service providers (ISPs) only allow port forwarding on non-standard ports like 8443 (look at „Enable Port Forwarding“ for how to configure port forwarding).
SSL-certificate
Create a private key:
openssl genrsa -out /etc/ssl/private/apache.key 2048
Create ssl certificate:
openssl req -new -x509 -key /etc/ssl/private/apache.key -days 365 -sha256 -out /etc/ssl/certs/apache.crt
(Look at „Advanced configurations for your game development server“ coming in a few months)
Configure site
Open the file/etc/apache2/site-available/default-ssl.conf:
sudo nano /etc/apache2/site-available/default-ssl.conf
For our services it is sufficient to only enable one site running on port 8443. So you only need to change the /etc/apache2/site-available/default-ssl.conf to this:
<VirtualHost *:8443> ServerAdmin webmaster@localhost DocumentRoot path-to-your-document-root-dir # change this ServerName your-domain:8443 # change this SSLEngine on SSLCertificateFile path-to-certificate.crt # change this SSLCertificateKeyFile path-to-certificate.key # change this ServerSignature On CustomLog /var/log/apache2/access.log combined # can be changed if you like LogLevel warn ErrorLog /var/log/apache2/error.log # can be changed if you like # Deny access to root-directory # <Directory /> Order Deny,Allow Deny from all </Directory> # Configuration for your DokuWiki # Alias /wiki "path-to-wiki" <Directory path-to-wiki> # change this Order deny,allow Allow from all Require all granted </Directory> <LocationMatch "/(data|conf|bin|inc)/"> Order allow,deny Deny from all Satisfy All </LocationMatch> # Configuation for your ownCloud # Alias /owncloud "path-to-owncloud" # change this <Directory path-to-owncloud> # change this Options +FollowSymlinks AllowOverride All Order deny,allow Allow from all Require all granted <IfModule mod_dav.c> Dav off </IfModule> SetEnv HOME path-to-owncloud # change this SetEnv HTTP_HOME path-to-owncloud # change this </Directory> # Disallow plain text (HTTP) connections # <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> </VirtualHost>
Explanations for lines which need to be changed:
- DocumentRoot: Let’s say your wiki is in /var/www/wiki and your ownCloud in /var/www/owncloud, then your DocumentRoot should be set to /var/www/
- ServerName: Type in the domain:port of your server
- SSLCertificateFile: Type in the full path to the .crt-file, which you created here
- SSLCertificateKeyFile: Type in the full path to the .key-file, which you created here
- For each „path-to-wiki“ type in the full path to your wiki, for instance /var/www/wiki
- For each „path-to-owncloud“ type in the full path to your owncloud, for instance /var/www/owncloud
- Additionally you can change the paths to the log files, where Apache tracks all accesses and errors. For this, change the paths in the lines that start with „CustomLog“ and „ErrorLog„
Now enable the site „default-ssl“ (has only to be done once):
sudo a2ensite default-ssl
Always restart Apache after you changed something in the configuration:
sudo service apache2 restart
SVN-Server
Why did we choose SVN instead of GIT?
- Our experience showed us that GIT is harder to understand, especially for non-programmers
- Only two of us are effectively changing files on the SVN-server, so merging is not that hard
- SVN also allows branching
- Whereas there are plugins available for Unity and SVN, there are non for GIT
Since this post should only be about how to set up the SVN-server, we recommend you to follow these links for more information on how to use SVN on Linux or Windows.
Installation and Setup
Install SVN:
sudo apt-get install subversion
Create a directory where your SVN-repositories will be stored, create a SVN-repo for your game and change the permissions so that the Apache server can access the files in the repo:
sudo mkdir -p /var/svn # repo-directory sudo svnadmin create /var/svn/game # repo for your game sudo chown -R www-data:www-data /var/svn # correct permissions
For remote access you need to make Apache SVN-ready: See Apache-Installation.
Create SVN-users and permissions
You need to create SVN-Users for all your team members who will use SVN. Here’s how to create the first one (don’t use this command for adding further users!):
sudo htpasswd -c /etc/apache2/dav_svn.passwd severin
For adding more SVN-users use the same command but remove the -c parameter:
sudo htpasswd /etc/apache2/dav_svn.passwd simon
If you want to use Unity together with Unity Cloud Build, it is recommended to add a separate SVN-user only with reading permissions:
sudo htpasswd /etc/apache2/dav_svn.passwd unityCloudBuild
To change the permissions of your users, create an access control file and type in the following:
sudo nano /etc/apache2/svn-access-control
[groups] teamName = severin, simon # change team-name, add users unity = unityCloudBuild [/] * = r @teamName = rw # change team-name
You may need to enable the authz_svn – module:
sudo a2enmod authz_svn
Configuration – dav_svn.conf
Now your apache-server needs some more configuration. Open the file /etc/apache2/mods-available/dav_svn.conf:
sudo nano /etc/apache2/mods-available/dav_svn.conf
Insert this:
LoadModule authz_svn_module modules/mod_authz_svn.so <Location /svn> DAV svn SVNParentPath path-to-svn # change this AuthType Basic AuthName "Name" # change this AuthUserFile svn-user-file # change this AuthzSVNAccessFile svn-access-control-file # change this Require valid-user SSLRequireSSL </Location>
Explanation for the lines which need to be changed:
- SVNParentPath: Full path to your SVN-Repositories
- AuthName: Arbitrary name for your SVN-Repos
- AuthUserFile: Full path to your user-file (in our example above: /etc/apache2/dav_svn.passwd)
- AuthzSVNAccessFile: Full path to your access control file (in our example above: /etc/apache/svn-access-control)
Lastly restart apache:
sudo service apache2 restart
If the server can’t be restarted and prints No apache MPM package installed – then install this package:
sudo apt-get install apache2-mpm-prefork
ownCloud
Like Dropbox, ownCloud provides user and group management, version control and synchronization between as many local machines as needed. This service is especially interesting for all our members who don’t have to work with Unity and SVN – mostly for our artists. Surely, they can use SVN if they want to, but we thought a Dropbox-like service with auto-synchronization is easier to use and because of that the artists have more time for their creative work.
Installation
The section „Apache – Installation“ explains which packages need to be installed to run ownCloud on an Apache server. Download the latest ownCloud version with the command written below and unpack it (replace x.y.z with the latest ownCloud-Version):
sudo wget https://download.owncloud.org/community/owncloud-x.y.z.tar.bz2 # tar.bz2 tar -xjf owncloud-x.y.z.tar.bz2 # for tar.bz2
The latest version number can be found here:

Now copy the unpacked directory into the Apache’s document root:
sudo cp -r owncloud /var/www/owncloud
In the section „Apache – Configure site“ we explain how to modify the file /etc/apache2/sites-available/default-ssl.conf to run ownCloud on Apache with SSL.
Lastly change the ownership of the ownCloud-directory to the webserver’s user and group:
sudo chown -R www-data:www-data /var/www/owncloud/
Then you can open the graphical installation wizard via your browser by visiting the URL „https://yourserver:8443/owncloud„.
Installation Wizard
Fill in the account information to create a new administrator.
Warning: Change the ownCloud’s data-path to a path outside of the Apache’s root directory (for example /home/newUser/owncloud-data instead of /var/www/owncloud/data). Also use MySQL instead of SQLite for performance reasons. Insert the root password and finish the setup:

Security and performance
Strong directory permissions
Create a new script file:
sudo nano /home/newUser/Desktop/owncloud_permissions.sh
Insert the script below and change the content of the following variables
- ocpath (ownCloud directory in apache root directory)
- ocdatapath (data-path of your ownCloud)
- htuser (webserver’s user)
- htgroup (group of webserver’s user):
#!/bin/bash ocpath='/var/www/owncloud' # change this ocdatapath='/home/newUser/owncloud-data' # change this htuser='www-data' # change this htgroup='www-data' # change this rootuser='root' printf "Creating possible missing Directoriesn" mkdir -p $ocpath/data mkdir -p $ocpath/assets mkdir -p $ocpath/updater printf "chmod Files and Directoriesn" find ${ocpath}/ -type f -print0 | xargs -0 chmod 0640 find ${ocpath}/ -type d -print0 | xargs -0 chmod 0750 printf "chown Directoriesn" chown -R ${rootuser}:${htgroup} ${ocpath}/ chown -R ${htuser}:${htgroup} ${ocpath}/apps/ chown -R ${htuser}:${htgroup} ${ocpath}/assets/ chown -R ${htuser}:${htgroup} ${ocpath}/config/ chown -R ${htuser}:${htgroup} ${ocdatapath}/ chown -R ${htuser}:${htgroup} ${ocpath}/themes/ chown -R ${htuser}:${htgroup} ${ocpath}/updater/ chmod +x ${ocpath}/occ printf "chmod/chown .htaccessn" if [ -f ${ocpath}/.htaccess ] then chmod 0644 ${ocpath}/.htaccess chown ${rootuser}:${htgroup} ${ocpath}/.htaccess fi if [ -f ${ocdatapath}/.htaccess ] then chmod 0644 ${ocdatapath}/.htaccess chown ${rootuser}:${htgroup} ${ocdatapath}/.htaccess fi
Lastly you need to run the script:
sudo /home/newUser/Desktop/owncloud_permissions.sh
Enable HTTP Strict Transport Security
Refuse HTTP connections to ownCloud by inserting the following into /etc/apache2/sites-available/default-ssl.conf:
sudo nano /etc/apache2/sites-available/default-ssl.conf
# <VirtualHost *:8443> # ... <IfModule mod_headers.c> Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains" </IfModule> # ... # </VirtualHost>
Caching
For small teams like ours, it is sufficient to use APCu for local caching and Redis for file locking. To do so, edit /var/www/owncloud/config/config.php:
# $CONFIG = array ( # 'instanceid' => ... # 'passwordsalt' => ... # ... 'memcache.local' => '\OC\Memcache\APCu', 'filelocking.enabled' => true, 'memcache.locking' => '\OC\Memcache\Redis', 'redis' => array ( 'host' => 'localhost', 'port' => 6379, 'timeout' => 0.0, ), #);
DokuWiki
We use a wiki to store and share persistent information which won’t be changed for at least some months. E.g. we collect important knowledge which has been gained in meetings. Or we collect data about aspects of our game, for example character descriptions, storylines and quests. We want to avoid confusing text files stored on our ownCloud – everything should be stored on a central and reachable point (more about this in „One way to manage a team“ coming next month).
Installation
The section „Apache – Installation“ explains which packages need to be installed to run DokuWiki on an Apache server. Download the latest DokuWiki version from here. You can use WinSCP to copy the downloaded archive onto your Raspberry.
Unpack the archive, copy it into your webspace and change the owner of the directory:
sudo tar -xzvf dokuwiki.tgz sudo mv dokuwiki /var/www/wiki sudo chown -R www-data:www-data /var/www/wiki
Before installing the wiki, consider the security instructions below!
Then just open https://yourserver:8443/wiki/install.php and follow the steps. After the installation process the wiki is reachable at https://yourserver:8443/wiki/doku.php.
Security
Apache
Add the lines below to your default-ssl.conf to deny access to the directories ‚data‘, ‚conf‘, ‚bin‘, inc‘ (see „Apache site configuration„):
# <VirtualHost *:8443> # ... # Deny access to root-directory # <Directory /> Order Deny,Allow Deny from all </Directory> # # Configuration for your DokuWiki # # # Alias /wiki "path-to-wiki" # <Directory path-to-wiki> # Order deny,allow # Allow from all # Require all granted # </Directory> <LocationMatch "/(data|conf|bin|inc)/"> Order allow,deny Deny from all Satisfy All </LocationMatch> # ... #</VirtualHost>
Permissions
Use these commands to only let the webserver’s user be able to write to directories and files:
sudo find /var/www/wiki -type d -exec chmod 700 {} + sudo find /var/www/wiki -type f -exec chmod 600 {} +
Move DokuWiki’s directories
WARNING: If you use the installer of the DokuWiki, you need to execute the install.php script first before you can go on.
Move the folder /var/www/wiki/data to anywhere outside of the Apache’s document root:
sudo mv /var/www/wiki/data /home/newUser/data
Then you need to change the file /var/www/wiki/conf/local.php:
sudo nano /var/www/wiki/local.php
$conf['savedir'] = '/home/newUser/data'; //add this line into /var/www/wiki/conf/local.php
Move the folder /var/www/wiki/conf:
sudo mv /var/www/wiki/conf /home/newUser/conf
Add a new file /var/www/wiki/lib/preload.php with following content:
sudo nano /var/www/wiki/inc/preload.php
<?php // DO NOT use a closing php tag. This causes a problem with the feeds, // among other things. For more information on this issue, please see:w // http://www.dokuwiki.org/devel:coding_style#php_closing_tags define('DOKU_CONF','/home/newUser/conf/'); // no closing '>'!!
Lastly move the folder /var/www/wiki/bin (or delete it if you don’t have shell access on your server):
mv /var/www/wiki/bin /home/newUser/bin
Update your DokuWiki
You can manually update your wiki or install the upgrade plugin which is definitely more comfortable than the manual solution. Always create a backup of the whole DokuWiki directory before upgrading!