This is an old revision of the document!
Hosting a Crossfire Server
This guide outlines useful information for installing, running and maintaining a crossfire server.
Make sure you have the following available to you:
Hardware that can handle hosting a Crossfire server
Any hardware that can run or handle a relatively modern desktop OS
should be adequate
One should estimate 10kbps down (in) and 20kbps up (out) per user (kbps = kilo bits per second)
The above should be consider an absolute minimum as data may be required in bursts (especially for clients downloading images)
An ISP that allows for server hosting
A hostname that is a Fully Qualified Domain Name (FQDN)
Network security to allow remote connections and communication to the metaserver (if a public server).
The watchdog feature can be enabled manually in the server/include/config.h at server_compiling as #define WATCHDOG 1 .
The watchdog port number is hardcoded inside void watchdog(void) located in the server/socket.loop.c source file as 13325 .
The watchdog feature may not work as it should currently until incl. server v1.70.0 to create
Further it would create an additional socket, and that may lead to problems that the code does not work to add a new client. You may better not enable that feature!
Installing a Crossfire Server from a Binary
Visit the Crossfire website for the latest binarys here
Compiling a Crossfire Server from source code
After your server and network is setup and configured, there are additional steps to consider.
The files referenced below are in the installroot/etc/crossfire directory - for example, if you used -prefix=/usr/games on the configure step, these would be in /usr/games/etc/crossfire.
Be sure to update the files in /usr/games/etc/crossfire not those found in your source files (if you follow this guide
for example, /home/<username>/server.svn/):guide server.svn)
Some file changes will take effect immediately, while others require the server to restart before they take effect.
Hosting the Server
Edit and update the MOTD (Message of the Day) information (filename motd)
Edit and update the Server Rules file (filename rules) to include all appropriate rules (See section Social Management)
Edit and update the Server News file - players like to know about new maps, bug fixes, special events, etc. (filename news)
Look over the settings (filename settings)
The default settings file will work just fine, and is most supported
The file controls many aspects of play - permadeath or not, number of starting stat points, etc.
Player account information is stored in the /var directory (on linux this is usually /usr/games/crossfire/var/crossfire/).
The account file in the var directory includes account name and password information.
The accounts file is linked to each player file in the file with the same name stored in /account
Each player file is stored within the directory /players
You will need to back up each of these in order to be able to keep an archive for your players. It is generally a good idea to set up an automatic archiving script such that if something gets broken any account or player may be recovered.
master:topsecret:* (name must be master, password is topsecret, allow any host)
*:notelling:* (only matches password)
One weakness of the crossfire-server binary is that any fatal error will result in your server going offline. To avoid lengthy delays whilst attending to other less important work, most server hosts choose to run the crossloop script. This handy script will restart the server if a crash occurs and create handy log files in the directory of your choosing. Crossloop is usually located within the server install directory (e.g. for linux /usr/games/crossfire/bin/).
crossloop.web is similar to crossloop, but also e-mails a stack trace and makes data available on the web. To use, some variables at the top of the file need to be changed. Note that make install will overwrite this file, so you will want to make a copy of it.
The script files assume that the core file will just be called core. If the name is different, eg, core.pid, crossloop will not be able to properly save the core files (but the fact that the name is fairly unique does mean it is less likely they will be overwritten)
NOTE : Make sure, that the crossloop script, if it is a #!/bin/bash script,
ulimit -c <SIZE> command ready;
Bash ulimit actually creates the core file by the -c argument, not the crossfire-server binary by itself. Until at least crossfire-server v.1.12.0 the ulimit -c unlimited line was not included in crossloop .
-c the maximum size of core files created
core file size (blocks, -c) 0
ulimit -c unlimited
core file size (blocks, -c) unlimited
To start crossloop create a folder for the log files:
$ mkdir crossloop_dump
Change directory to crossloop_dump
$ cd crossloop_dump
You can now run crossloop simply by:
$ nohup /usr/games/crossfire/bin/crossloop
You can check that the server is running by running ps aux:
$ ps aux|grep cross
You should see something like:
username 1069 0.0 0.0 13696 2360 pts/40 S+ 21:53 0:00 grep --color=auto cross
username 32126 0.0 0.0 4476 708 pts/39 S 21:37 0:00 /bin/sh /usr/games/crossfire/bin/crossloop
username 32129 0.6 0.0 284264 26240 pts/39 Sl 21:37 0:05 /usr/games/crossfire/bin/crossfire-server -d -tmpdir /tmp/crossfire -log /tmp/crossfire/crossfire-2016-04-18-21:37.log
Start crossloop on reboot
Crossloop does not of itself provide a means of starting crossfire upon a system reboot. Due to power failures and other uncontrolled reboots it is generally wise to include this in your system start-up to avoid server downtime. just make sure it su's to the appropriate user before running.
More Linux instructions
explain how to create init.d entry.
Other helpful automation considerations
Have an automated and remote backup of player files and unique map files in case of hardware failure, data corruption or accident
All crossfire files are text, so generally easy to back up and restore. Since files are text, one can even attempt to repair damaged/corrupted files.
Consider using Munin (http://munin-monitoring.org/
) for monitoring and tacking server resources, more of a server host or administration benefit
If you want to attract players and build a community on your server - your server will need to be reliable, which means:
Available on a consistent basis
Available for the long term - at least several months (maybe longer)
Adequate bandwidth for usage and performance
Adequate hardware to handle server load
The catch-22; you need players online to attract and keep new players
Have a trustworthy DM (or two) to help players and address related issues
Become very, very familiar with the DM commands and how to use them
If you intend to ban players who exploit bugs, PK other players, disrupt gameplay for others, etc. - say so in the server rules file so if/when something like this happens you can take action and avoid the long “debate” afterwards (filename rules)
There are two approaches to banning problematic player(s) and/or network(s)
Use the ban_file (filename ban_file)
The ban_file can be used to ban certain IP addresses or IP ranges - this may be easier than modifying firewall rules. Note that the check is done at connection time, so would not cause players already connected to get dropped.
This can be done in game while in DM mode (command: banish)
Create firewall rules for the extremely problematic player(s) and/or network(s)