This guide outlines useful information for installing, running and maintaining a crossfire server.

Make sure you have the following available to you:

1. Hardware that can handle hosting a Crossfire server
   • Any hardware that can run or handle a relatively modern desktop OS should be adequate
2. Enough bandwidth
   • 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)
3. An ISP that allows for server hosting
4. A hostname that is a Fully Qualified Domain Name (FQDN)
   • Connections issues can occur within the Crossfire client if the domain name is not full qualified.
5. Network security to allow remote connections and communication to the metaserver (if a public server).
   • The server runs (by default) on port 13327
     • if you have a firewall, it will need to allow that port for incoming connections,
     • if you are running NAT, you will need to make sure that the connection to port 13327 gets routed to the correct server.
   • The metaserver runs (by default) on port 13326 and 80 (HTTP)
     • if you have a firewall, it will need to allow 13326 and 80 for incoming connections,
     • if you are running NAT, you will need to make sure that the connection to port 13326 gets routed to the correct server.
     • For metaserver2 updates, it is an outgoing connection to standard HTTP port (80), so very few firewalls should block it.

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

• a port at startup already ( but will create it after %503 ticks )
• an udp port of the number 13325 ( but some random udp-port above 32768 )

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!

Visit the Crossfire website for the latest binarys here

For information about compiling crossfire servers go to the crossfire server compile guide

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.

• 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.

• All servers should ensure that a DM account is setup and accessible
  • DM accounts are managed via the dm_file usually located in

/usr/games/crossfire/etc/crossfire/dm_file

• The server administrators can add DM access to a user, password, host address in the format user:password:host. For example:

Example entries:
master:topsecret:*    (name must be master, password is topsecret, allow any host)
*:notelling:*         (only matches password)

• Players with DM access simply login using the ingame command DM followed by their password, for example:

DM notelling

• DM's can view avaiable commands in game using the help command,

help command

The actual location of the metaserver2 file will depend on how the server was originally installed (i.e., by source or by precompiled package, dedicated user account for running the server) so be sure to check the following possible locations:

  /usr/games/crossfire/etc/crossfire/
  /etc/crossfire/metaserver2
  /home/crossfire/etc/crossfire/metaserver2

• If running a public server, you will most likely want to advertise your server via the metaserver (filename metaserver2)
  • metaserver 1 (in settings file) is obsolete
  • metaserver2_notification must be changed from off to on.
  • localhostname is critical and must be in the correct format (e.g. yourdomainname.com)
    • localhostname must resolve to the IP address from which the update originates. This means that if you have a NAT router, it will need to resolve to the router.
    • The server sends an update to the metaserver every minutes - if you do not see your server immediately, wait 5 minutes.
    • If after 5 minutes, updates are still not happening, check the logs - messages should be generated.
    • If curl is not installed on your system, metaserver2 updates will not happen, but the server will print a message stating the curl is missing when program starts up.
    • If localhostname does not match the IP address that metaserver2 sees the request coming from, it will send a message to the server but not add it. If run with crossfire -d, it will print this error to the console.
    • It is possible your subnet has been blacklisted from the metaserver - this is highly unlikely, but could result if another user from that same address block or ISP was abusing metaserver2 update policy.

• Consider limiting how many guilds are initially available
  • This will prevent a player or small group of players from buying all the guilds at once
  • This helps to make sure guilds will be available for new players who join your server later on
  • : More information on how to do this is probably desirable

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/).

Please note:

• 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,
has the 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 .

bash
help ulimit

-c the maximum size of core files created

ulimit -a

core file size (blocks, -c) 0

ulimit -c unlimited
ulimit -a

core file size (blocks, -c) unlimited

To start crossloop create a folder for the log files:

$ cd crossloop_dump/; nohup /usr/games/crossfire/bin/crossloop &

• This does not start the crossfire server in case of OS reboot. Crossfire does not include a script that does this, but generally, it is not hard to write one - just make sure it su's to the appropriate user before running.
• - core dumps from crashes
• - using Munin (http://munin-monitoring.org/) for monitoring and tacking server resources, more of a server host or administration benefit
• 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.

$ 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

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.

explain how to create init.d entry.

1. Have an automated and remote backup of player files and unique map files in case of hardware failure, data corruption or accident
2. 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.
3. 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)

1. 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)
2. Create firewall rules for the extremely problematic player(s) and/or network(s)
   • It's advised that you learn how to block (ban) networks and subnets