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):

 

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

1. Download the latest Raspbian-Image
2. Plug-in your SD card into your PC
3. Download Win32 Disk Imager
4. Choose the Raspbian-Image (a), select the SD card’s drive letter (b), click „write“ (c)

Connect to your Raspberry

1. Connect your Raspberry with the Router via an ethernet cable
2. Plug-in the written SD card into your Raspberry
3. 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)
4. Download Putty (SSH client)
5. Open Putty and fill in the identified IP-address
   
6. Enter Login-information. Username: pi / Password: raspberry
7. sudo nano /etc/network/interfaces (open interface configuration)
8. 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?

1. Our experience showed us that GIT is harder to understand, especially for non-programmers
2. Only two of us are effectively changing files on the SVN-server, so merging is not that hard
3. SVN also allows branching
4. 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!