Crossfire RPG Setup - A New Beginning

When we were in New Jersey, I ran a local Crossfire server. This was back in the days before the Internet became the safe place it is today, so running a local server allowed the kids, their friends and me to all played cooperatively and independently without external grief. When we moved to Tennessee, I never really go around to setting it up again, until today after a 13 year hiatus. I have decided to set things up again and am going to document the steps in this post.

First of all I will be installing on a Gentoo GNU\Linux machine, Gentoo Base System release 2.6 running at the moment on a 4.19.7-gentoo kernel.

Install the server software:

 sudo emerge -DNuv crossfire-server 

Output:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] games-server/crossfire-server-1.71.0-r1::gentoo  USE="X" 0 KiB

Total: 1 package (1 new), Size of downloads: 0 KiB
 
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) games-server/crossfire-server-1.71.0-r1::gentoo
>>> Installing (1 of 1) games-server/crossfire-server-1.71.0-r1::gentoo
>>> Recording games-server/crossfire-server in "world" favorites file...
>>> Jobs: 1 of 1 complete                           Load avg: 3.26, 1.28, 0.60
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

Install the client software in order to test the server and to actually play the game:

 sudo emerge -DNuv crossfire-client 

Output:

Total: 1 package (1 new), Size of downloads: 744 KiB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) games-roguelike/crossfire-client-1.72.0::x-portage
>>> Installing (1 of 1) games-roguelike/crossfire-client-1.72.0::x-portage
>>> Recording games-roguelike/crossfire-client in "world" favorites file...
>>> Jobs: 1 of 1 complete                           Load avg: 1.38, 0.85, 0.60
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.

Configure Server.

With the server installed, now it is time to do some configuration, most of this section came from the Crossfire Wiki. I am going to be running the server as a non-privilleged user account thus limitting the damage errant code or player abuse. In order for this to work, ownership of a directory structure needs to be changed from root to match the user running the server, chuck.

sudo chown -R chuck:games /var/lib/crossfire

With directory permissions sorted there are some other server information and settings file which need to be reviewed and altered to fit my needs and expectations. On my Gentoo machine, all of these files can be found in /etc/crossfire. One note, do not chane the permissions on these files, edit them with super user rights.

Review and modify the following:

• Message of the Day motd
• Server Rules rules
• Server News news
• Server Settings settings
• Dungeon Masters dm_file

Seriously, all the files need to be reviewd, and most altered to make the game run the way you want, just do it.

Launch server

I will be launching the server on my user account logging on to the desktop. I am using the crossloop script installed with the server to launc and monitor the server, restarting it automatically if it crashes for some reason.

To do this:

• Create a directory for crossloop to run in. mkdir -p ~/projects/crossfire

Modify Window Manager to Launch Crossfire Server on Desktop Startup

• In ~/projects/crossfire directory, I created a script file called launch-crossfire.bash which contains the following:

     #!/bin/bash
     #Change to launch rirectory and run nohup
     pushd ~/projects/crossfire
       nohup crossloop &
     popd
   

• I made it executable with chmod +x launch-crossfire.sh.
• I added the line exec --no-startup-id "~/projects/crossfire/launch-crossfire.bash" to my ```~/.i3/config. Different desktop environments should have similar mechanisms for for running commands at startup, but obviously you should run i3.
• Log out of desktop and then back in.
• Test it worked with ps -aux|grep cross. You should see crossfire-server running.

Test server local

With the server running the next step it to see if the client can connect via localhost. Launch the client by runnning crossfire-client-gtk2. In the next screenshot, I have specified localhost on port 13327 for the setination and port of the server the client should connect to. Because 13327 is the default port for connecting to a Crossfire server, leaving it off and specifying onmly localhost alone also should work also.

Success, client has connected to the local server, and the screen to create an account or sign in appears, along with the news, rules and message of the day I set up for the server.

Test server Remote

Testing from client connectivity to the server on the same machine as the server is running works, but to be more useful, the server needs to be reachable from other machines on the same local network. Time to test from another machine, but first I need to adjust firewall on the machine where the server is running, allowing incoming TCP connections on port server is listening, in my case the default port 13327.

As for the approach I use for firewalling machines on my home network, I allow all outgoing onnections from a machine as well as incoming connections from established connections, and I block all incoming connections unless specifically allowed. Therefore I need to specifically allow incoming connections to the server machine on the default server port. This will allow other machines to connect. It should come with little surprise as a Linux user, I rely on iptables for mot of my firewall needs. In the master list of rules for the machine runnign the server, adding the following lines were sufficient to allow connections from remote machines on the local networks.

#crossfire port
$IPT -A SERVICES -p tcp --dport 13327 -j ACCEPT #Accept crossfire rpg server connections

After adding the new firewall rule, and reloading the firewall I attemped to connect to the server from another machine, using the server’s DNS name of setback and leaving off the port since server is listeing on default port.

And success again.

Occaisionally I like to check my firewalls still work as expected, so as a test, I commented out the line allowing access and reloaded the firewall. My expectation was that remote machines should now be unable to connect, and my expectation was satisfied. The following screen shot from antother machine on the local networ shows the client waiting without success to connect to the server because the default port is blocked by firewall rule.

Finally, I removed the comment from the firewall rule, and reloaded restoring the ability to connect to the server remotely. Satisfied things are up and running as expected, the next things I need to do are re-learn how to play the the game and do some play testing, as I suspect things may have chaned over the 13 years since I last played. But that will have to wait until another day.