User Tools

Site Tools


server:hosting

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.

Requirements

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

Installing a Crossfire Server from a Binary

Visit the Crossfire website for the latest binarys here

Compiling a Crossfire Server from source code

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

Post Deployment

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.

Server Settings

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

DM account

  • 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

Crossfire Metaserver

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

Guilds

  • 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
    • FIXME: More information on how to do this is probably desirable

Crossloop

  • crossloop (prefix/bin/crossloop) can be used to automatically restart crossfire if the program crashes.
    • It stores the core files in the current directory, so this should be run from the directory you want to store those core files.
    • 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)
    • To start, do 'cd somedir; nohup /path/to/crossloop &' - note that different shells may nohup by default - somedir is where you want all the core files to be. For example:
$ 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.
  • FIXME - core dumps from crashes
  • FIXME - 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.

Social Management

General Tips

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

Banishment

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
server/hosting.1411896011.txt.gz · Last modified: 2016/04/18 07:03 (external edit)