Running rocket.chat on DC/OS

In this post I will quickly describe how to setup rocket.chat on DC/OS, which I used for a simple proof of concept.

Warning: This is example is not suitable for production use since it does not persist its data!

Requirements:

You need a up and running DC/OS Cluster with at least one instance of “Marathon-LB” nothing else is needed in first step.

Goal:

By the end of this we want to have a running rocket.chat instance including its requirements on DC/OS behind our “Marathon-LB” loadbalancer.

Setup:

rocket.chat has one simple requirement, which is mongoDB, which we have to install first.

mongoDB:

MongoDB is available in the default “Universe” repository which comes with DC/OS, which makes it very easy for us to setup a single instance for testing (if you want to go for production you should use here a full replicaset!)

  1. Choose “mongodb” from the package repository for installation
  2. Choose “Advanced Installation”
  3. I want to run the whole setup in a group called “rocket.chat” so I update the service name to contain also the group-name
  4. During testing I noticed that the default “CPU” value is a bit low, so we will increase this to at least 2
  5. If you want to go for production should also update the “Username” and “Password” in the section “database”. For the POC I will just keep the default values
  6. Start the installation by clicking “Review & Install” and on “Install” in the following window, you can monitor the process in the service overview

As soon as this has finished we can continue with rocket.chat itself.

rocket.chat:

The rocket.chat team provided a ready to use docker image which we can utilize: https://hub.docker.com/r/rocketchat/rocket.chat/

To continue we have to lookup the “Load Balanced Address” of the mongoDB installation, so we can provide the correct connection string. We find that in the “Configuration” section of the mongoDB service
With this in formation we can now deploy the rocket.chat container as a single service.

  1. Define the basic image (rocketchat/rocket.chat:latest) and it’s resources, I assign 4 CPUs and 1GB of memory, otherwise I didn’t get this running
  2. In the networking section I use the “Virtual Network” and define the default port 3000 to be mapped for external access
  3. For observing the containers I define a simple health check for the login page
  4. Finally I define the required environment variables (PORT, ROOT_URL, MONGO_URL, MAIL_URL) and the HAPROXY_GROUP for our external access. We keep “http://localhost:3000” since I don’t know the final service port upfront (rocket.chat will ask to change the URL after accessing it the first time, you can set it already to your final external URL if you know it upfront.
  5. Finalize the deployment and watch it starting 🙂

After the setup has finished you can check the “servicePort” from the rocket.chat service to know which port you need on your loadbalancer
You can now access your installation through your marathon-lb node. The first user which registers with your instance will be the administrator user!

Source-Engine Server Part1

Due to I still receive the HLDS maillinglist with a lot of update notification for the valve game servers in the last days, I decided to get back to my root off the “server administration thing” in a small simple game server project, based on my favourite source engine multiplayer game Day of Defeat: Source, but the main parts of the tutorial should also be useful for other source engine based games.

The result of this small tutorial series will be a Day of Defeat: Source Server, with Mani Admin Plugin as ingame administration tool and HLstatsX Community Edition as ranking system.

The server will be installed on a small vserver I got at Strato, based on Debian 5 Lenny, which currently only hosts the Teamspeak 3 server of my WoW guild with an small MySQL Server for the configuration storage. Well due to it’s not a powerful machine it will just host 10 to 12 slots in the end I think. But lets see what I can get out off that little box 🙂

The beginning

In the first step we will install our basic gameserver and join our first game 🙂

To start, we need the hlds update tool. It’s hidden on the steam homepage under tools, due to we are lazy admins, we download it directly to our server (mine is called minerva).

[email protected]:$ wget http://storefront.steampowered.com/download/hldsupdatetool.bin

Due to it is not executable, we give it the executable flag and start it.

[email protected]:$ chmod +x hldsupdatetool.bin && ./hldsupdatetool.bin

After you have accepted the licence with yes, the tool will extract the final steam client, which we will need to install the server.

When you run the tool the first time it will update it self to the latest version. This will probably take some time, due to the valve servers are often really slow. In the second run we let the tool show us the help output, so we see what parameters we need to install the game.

[email protected]:$ ./steam
Checking bootstrapper version ...

Use: steam -command [parameters] [flags]

Commands:

update: Install or update HLDS

parameters:
-game - Game name: use 'list' to see available games
-dir - HLDS Install dir
(if dir not specified, will use value from last run of tool)

flags:
-verify_all - Verify all HLDS files are up to date
-retry - Automatically retry every 30 seconds if the Steam Network is busy
-remember_password - Remember password (if a username is supplied)

For example: steam -command update -game cstrike -dir /hlds

version: View installed versions

list: View available games

Optional parameters for all commands:

-username - Steam account username (only needed to access limited content)
-password
- Steam account password (only needed to access limited content)

I want to install Day of Defeat: Source in the directory “/srv/dods/” (make sure you have created the target directory before you start the installation or the tool will hang at the beginning), so I need the following command (for the list of other available games use “-command list” as parameter)

[email protected]:$ ./steam update -command update -game dods -dir /srv/dods

In the following process steam will download the dedicated server files you choose. This will take some time, so pick up a cup of coffee and wait 🙂

After that, the server is installed in a very basic setup. Cause it’s not nice when the game runs as root when we start it, we will create a user for that with his home directory set to “/srv/dods”, give him the rights on the server files and just switch to that user.

[email protected]:$ useradd -d /srv/dods srcds && chown -R srcds:root /srv/dods && su srcds

Afterwards we switch to the folder in which the executable of the server is placed:

[email protected]:$ cd /srv/dods/orangebox

The server executable takes a lot of parameters, you can find a list of them in the valve developer wiki. I have choosen the following for the fist start:

[email protected]:$ ./srcds_run -game dod -autoupdate -maxplayers 10 -port 27015 +map dod_avalanche

With these parameters a server listening on port 27015 (Source-Engine games default), with the game Day of Defeat: Source, a maximum capacity of 10 players on the first map dod_avalanche will be started. The parameter “-autoupdate” allows the server to automatically download updates on startup.

Now open your Day of Defeat: Source client with the parameter “-console 1” and connect to your server 🙂

After that worked we stop the running server with “ctrl + c” switch back to root with the “exit” command and build us a small init script to start the server automatically if we have to reboot the whole server.
You can use the following which I found in the srcds.com forums.

#!/bin/sh
# Source Dedicated Server Init Script

# Server options
TITLE='Source Dedicated Server' # Script initialization title
LONGNAME='Day of Defeat Source'        # Full title of game type
NAME='dods'                          # Server handle for the screen session
DAEMON='srcds_run'                # The server daemon
STEAM='/srv/dods/orangebox'        # STEAM to Steam installation
USER='srcds'

# Game options
IP='85.214.131.53'                # IP of the server
PORT='27015'                    # Port number to
MAP='dod_avalanche'                    # Initial map to start
GAME='dod'                        # Game type (tf|cstrike|valve|hl2mp)
SIZE='10'                        # Maximum number of players

# Server options string
OPTS="-game $GAME +hostname \"$CLIENT\" +map $MAP +ip $IP -port $PORT \
-autoupdate +maxplayers $SIZE -pidfile $STEAM/$GAME/$NAME.pid"

# Screen command
INTERFACE="sudo -u $USER /usr/bin/screen -A -m -d -S $NAME"

service_start() {
# Check if the pid files currently exist
if [ ! -f $STEAM/$GAME/$NAME.pid ] && [ ! -f $STEAM/$GAME/$NAME-screen.pid ]; then
if [ -x $STEAM/$DAEMON ]; then
echo "Starting $TITLE - $LONGNAME"
echo "Server IP: $IP"
echo "Server port: $PORT"
echo "Server size: $SIZE players"
cd $STEAM
$INTERFACE $STEAM/$DAEMON $OPTS
# Prevent race condition on SMP kernels
sleep 1
# Find and write current process id of the screen process
ps -ef | grep SCREEN | grep "$NAME" | grep -v grep | awk '{ print $2}' > $STEAM/$GAME/$NAME-screen.pid
echo "$TITLE screen process ID written to $STEAM/$GAME/$NAME-screen.pid"
echo "$TITLE server process ID written to $STEAM/$GAME/$NAME.pid"

echo "$TITLE started."
fi
else
echo -e "Cannot start $TITLE.  Server is already running."
#exit 1
fi
}
service_stop() {
if [ -f $STEAM/$GAME/$NAME.pid ] && [ -f $STEAM/$GAME/$NAME-screen.pid ]; then
echo "Stopping $TITLE - $LONGNAME."
# Get the process ID from the pid file we created earlier
for id in `cat $STEAM/$GAME/$NAME-screen.pid`
do kill -9 $id
echo "Killing process ID $id"
echo "Removing $TITLE screen pid file"
rm -rf $STEAM/$GAME/$NAME-screen.pid
break
done
# Remove server pid file
echo "Removing $TITLE pid file"
rm -rf $STEAM/$GAME/$NAME.pid
# Wipe all old screen sessions
screen -wipe 1> /dev/null 2> /dev/null
echo "$TITLE stopped."
else
echo -e "Cannot stop $TITLE.  Server is not running."
#exit 1
fi
}


case "$1" in
'start')
service_start
;;
'stop')
service_stop
;;
'restart')
service_stop
sleep 1
service_start
;;
*)
echo "Usage $0 start|stop|restart"
esac

Place that script in “/etc/init.d/”, change the variables to your needs and update your servers init links. In debian for example with

[email protected]:$ update-rc.d dods defaults

You can now start your server with the init-script

[email protected]:$ /etc/init.d/dods start

That was the first part. We have now a small running server. In the next part we will configure the server and install the Mani Admin plugin.

2 Days down…. new hoster

As probably mentioned, my website was unreachable the last 2 Days. The reason for that was a filesystem crash of the server at server4you.de where my vserver was hosted on. Cause of that outage, I decided to switch my email and websites to a new hoster.

Now my website is hosted on the high-available cluster of www.packagecloud.com. They provide a high available environment with everything you need for webhosting for just 5€ per month. Very nice offer, have a look. 🙂

 

Dokuwiki with Ldap against Novell eDirectory

Cause i found only one good post with google and for personal dokumentation 🙂 ,  here is how to configure Dokuwiki using Ldap with a Novell eDirectory.

Here are the lines in /conf/local.php you have to add  to enable ldap and to access the eDirectory.

$conf['useacl']      = 1;
$conf['openregister']= 0;
$conf['authtype']    = 'ldap';

$conf['auth']['ldap']['server']      = 'ldap://ldap.domain.tld:389';
$conf['auth']['ldap']['usertree']    = 'ou=users, o=someFirm';
$conf['auth']['ldap']['grouptree']   = 'ou=groups, o=someFirm';
$conf['auth']['ldap']['userfilter']  = '(&(uid=%{user})(objectClass=person))';
$conf['auth']['ldap']['groupfilter'] = '(&(objectClass=groupOfNames)(member=%{dn}))';

Note that you have to replace the “o=” , “ou=” and “server” values and that you have ldap support enabled in your php!