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
Install the server software:
Install the client software in order to test the server and to actually play the game:
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.
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
- Server Rules
- Server News
- Server Settings
- Dungeon Masters
Seriously, all the files need to be reviewd, and most altered to make the game run the way you want, just do it.
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
crossloopto 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.bashwhich contains the following:
- 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
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
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.
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.