Information and Services by Zac Hester

CounterStrike: Source on FreeBSD

High-End Game Servers Easier than Windows

Zac Hester - 2005-12-18

Table of Contents

Purpose

This guide is intended to help a person with a little Unix/Linux background start up and run a complete game server running on FreeBSD. I've found that most tutorials are very terse and only get you up and running. I've always wanted to a slightly more comprehensive resource about what you do after the server has been set up. Additionally, I've added some discussion about various security issues and different advantages/disadvantages to running a multi-purpose server (http, database, etc).

This guide makes no claims that you will actually be popular or rich after setting up a FreeBSD game server. Sorry.

Scope

This guide is intended for those people with a basic understanding of their Unix shell of choice ((t)csh, Bash, sh, etc) and their preferred shell-based text editor (vi, pico, ee, ed, etc). The FreeBSD Handbook has some fantastic introductions to using these basic applications, so it might be worth your time if you're not already familiar with the basic environment. For those of you coming from GUI backgrounds with very little shell experience, this tutorial might be a little harder to access until you're at least comfortable with basic file manipulation and editing text files.

We will also cover some basics of setting up the operating system. Knowledge of changing configuration settings, restarting services, and rebuilding the operating system from source will make this guide easier to access, but I will try to be gentle when we get into the rough spots.

For the purposes of producing a working example, we will be building a Source engine dedicated server running CounterStrike: Source. Our installation will have a few of the more popular administration and player modifications. This guide was written around FreeBSD 5.4. As 6.x matures, I may be upgrading our servers. At which point, I will update this guide to reflect any changes I find as I move to 6.x. The server will also provide http, ftp, ssh, and database services. As time allows, I hope to also include setting up a complete web-based stats system to help drive those stats-hungry gamers to your servers.

Initial Setup

Before we can run a game server, we need to get a generic Internet server running with the basic applications and services necessary to manage the server remotely. Unfortunately, if we gloss over the initial setup phase, we could be undermining our game's performance, reliability, and security.

Installing FreeBSD

For those of you with physical access to the box, you'll need to start by installing the base operating system. If you're co-locating, you may be able to just ask your provider to install FreeBSD and skip this part of the guide. Even then, you may want to send your provider's technical staff a link to this page if they have any specific questions about how you want FreeBSD installed.

As luck would have it, I try to maintain a FreeBSD installation guide that you may find useful in setting up your basic server. I am also planning on inserting a more in-depth tutorial geared towards installation for game servers, but this will have to do for now.

For game servers, you may want to expand a few partitions (since you'll probably have more than 20GB at your disposal). My current install is on a dual Xeon system with 2GB of RAM and a 120GB hard disk:

* Everyone says to double your RAM to determine swap space. Our servers undergo periodic upgrades, so I'm just planning on the maximum amount for this system (2 x 8G).

Kernel Configuration

To really turn FreeBSD loose, you'll want to rebuild the operating system's kernel. As indicated in my installation guide, you rebuild the kernel after updating the sources over CVS, so this will also make sure that your kernel has all of the latest patches.

For those of you who are serious tweakers (you enjoy reading about compiler flags and playing with /etc/make.conf), I would like to hear if you've found any settings that are especially useful for gaming applications.

While following the kernel configuration steps in my installation guide, you'll want to add the following lines to your kernel's configuration: 

options         COMPAT_LINUX
options         LINPROCFS

In addition to Linux compatibility options, I would recommend removing all USB and Firewire (unless your server somehow uses USB stuff). If you're not using SCSI drives (who is these days), remove most SCSI stuff (leave "device scbus" and "device da" as they may be used in other portions of the kernel not directly related to SCSI). Also, you can help boot times by setting the "options SCSI_DELAY" down to 10 or something small.

Also, if you're interested in running a firewall on the server, I would recommend using the OpenBSD-descendent Packet Filter (pf). It's covered pretty well in the handbook, but the reason I mention it here is that you will need to modify the kernel configuration if you're going to use a firewall. At this point, haven't installed a firewall on any game server. Instead, I try to keep track of all my listen ports and rely on application-level security (which is still critical even with a firewall).

Even with this information, my install guide won't be of much use if this is your first time installing FreeBSD. If in doubt, always consult the FreeBSD Handbook. It just might save your life! Not really. I tend to exaggerate sometimes.

Vital Applications

After you have a nice, clean build of the latest FreeBSD release, you'll need to install and set up a couple critical user applications to get everything ready for administration and game installation. This is what I use.

sshd

This is necessary for basic administration and file transport.

inetd - FTP

Game servers tend to need to transfer large files. Doing so over SSH is sometimes unnecessary and is slower than clear FTP transfers. Just don't use FTP to log in as any of your user accounts with "wheel access" and you're fine.

Linux Libraries

With binary compatibility turned on in the kernel, FreeBSD can run any simple, Linux-compiled binary. However, most interesting programs will tend to want access to some runtime libraries that are special on Linux systems. Fortunately, the FreeBSD ports collection allows you to install the libraries automatically: 

cd /usr/ports/emulators/linux_base-8
make install clean

After that's set, you'll need to just add a line to your /etc/rc.conf: 

linux_enable="YES"

Before you take your machine to co-lo...

I should mention it here that there are two things you will want to do before you take your machine to be locked in a cage and go back home.

Create a user account and make sure they have a password and are a member of the "wheel" group. If you've used FreeBSD before, you understand the concept of the "wheel" group (and you may skip the next paragraph).

An added level of security in FreeBSD is to keep any user on the system from becoming the "super user." Unlike other Unixes and Linux distributions, only members of a special group called "wheel" can even request root access (they still have to provide the root password, though). If you've installed your OS from the keyboard and monitor on the system, you will need to make sure you have a regular system user (with a password and a shell) who is a member of the wheel group. This can be accomplished through /stand/sysinstall, so it's not that tough. If you go to Configuration -> Users and Groups -> Add New User, you will see a simple form where you can enter information to create a new user account. One field at the top will be labeled "group." Leave this field blank. Another field half-way down on the page will be labeled "Member Groups." Enter "wheel" (no quotes) in this field. After filling out all the other information as you see fit (make sure to include a password), the user account will be created and you will have access to the entire system (assuming you remember your root password).

Next, you will want to make sure you have the SSH server automatically starting up at boot time. To do this, you will want to either go through /stand/sysinstall and enable the SSH service through the menus, or you can simply ensure you have this line in /etc/rc.conf: 

sshd_enable="YES"

As long as you can log in through an SSH session and become root (using su and typing the root password), you should be able to do everything else you need to set up and maintain the server remotely.

Appendix

1  Requirements Outline

To understand the reasoning behind many of these installation procedures, you may want to review the requirements for the server. If you just want to copy what I've done, don't bother with this section. If you would like to further customize your solution to your needs, or think that some of my techniques are a bit strange, perhaps quickly reviewing these requirements will help you understand why I did things this way.

Server Costs

It is my (usually overstated) opinion that a large-scale, mission-critical server should incur costs from three sources:

  1. Physical Hardware (initial build and upgrades)
  2. Physical Services (Internet access, network resources)
  3. Operations (non-automatic system administration)

Now, if you're the type that likes to account for every little detail and come from the world that Microsoft has forced on most of us, you might be saying, "Wait a minute! You forgot software costs!." Never fear, little buddy. The endlessly fascinating aspect of server-level computing is that good server software is always free. This guide is the wrong place for me to delve into my philosophy on the free exchange of all information, so we'll have to leave it at that for now.

Therefore, to meet this requirement, we will be using a free, (preferably open source) operating system and all applications will also have to be free.

Server Utilization

There are three areas that will be of greatest importance to a gaming application:

  1. Reliability (usually quantified by uptime)
  2. Performance (usually compared by relative speed)
  3. Security (Do we get hacked after we get popular?)

For OS purists, these issues could be argued at length and we would never come to a resolution. After maintaining heavily-loaded servers for many purposes using most of the popular operating systems available between 1999 and 2005 (including Windows NT4, Windows 2000 Server, SunOS/Solaris, Red Hat Linux, Debian Linux, and FreeBSD), I have always been pleasantly surprised to see FreeBSD outperform these other platforms in many areas (and, occasionally, do so on inferior hardware). To help qualify this claim, I have to say that I've mostly dealt with http, ftp, DNS, and database servers along with using a couple of these OSs as a dedicated network router. (If Windows does something better, I haven't had a use for it.)

I would also like to point out that our current co-location provider started us out on a Windows 2000 Server. At first, I frowned and shook my head, but I happily lent my services to the project and got two game servers up and running with very few installation issues (my part was actually more focused on setting up the web, database, and FTP servers). However, after about a week or two, one of the game servers would intermittently crash with a user-confirmation dialogue box. This meant that the server would never actually "die" since it was waiting for a user on the GUI to acknowledge the problem. Even if it did die and restart, though, the server died once every day or two. Now, chances are more likely that the game server was just poorly written and possibly not very friendly with the other game server we were running. However, after a lot of troubleshooting, I gave up and suggested we give FreeBSD a try. After a month of operation, neither of our game servers have had any stability problems whatsoever. Wherever the problem was, it went away when we switched to Unix, so I'm not too concerned with finding out why we had the problem.

To approach the most ideal case for this requirement, we will be using the current "Release" version FreeBSD.

Remote Management

I'm not a big fan of hosting a dedicated, multi-player game server behind my DSL connection at home. The cheapest solution otherwise (if you don't work for an ISP or a co-location company), is to co-locate your machine in someone else's data center. Thus, remote management is very important.

If you're excited about using some GUI program to access your GUI-based OS's desktop over the Internet, you're a part of a community of administrators I will probably never understand. The only reliable, widely-available, and highly-functional method of remote server management is an interactive command shell. One of the exciting parts of my experience maintaining Windows servers is that I've found it's actually easy to install an SSH server as a Windows service and log into a standard shell (csh or Bash) over SSH. Sadly, though, Windows only provides limited access to basic system functions (it chooses whether or not you can terminate a process, instead of just forcing the process down), and many Windows applications are written without console-based interactivity--they intend for everyone to use the GUI to access their application.

To meet this requirement, the operating system should provide a typical Unix management environment with a complete implementation of an interactive user shell. The system should allow full control over running processes and system configuration via the shell. In this case, it's a toss-up between any kind of Unix or Linux.

Application Compatibility

Of course, the server has to actually run the server applications. If you take a quick survey of most commercial games that offer a dedicated server for consumers' use, you will find that most games provide both a Windows-based and a Linux-based dedicated server. If we want superior remote management, Windows is right out. If we want superior reliability and security (and, in some cases, performance), we also have to exclude Linux itself. This leaves us with Solaris (running Linux emulation) or FreeBSD (which executes Linux binaries in the kernel).

Furthermore, this server is intended to provide other services besides the games server (like web and database). These applications will actually run on any of the platforms listed, but FreeBSD tends to handle load just a little better. (Actually, I wouldn't compare FreeBSD to Solaris unless they are both running on PC hardware [which is still pretty close]. On Sun hardware, though, Solaris would give FreeBSD a run for its money on load handling.)

To meet this requirement, we will be using FreeBSD. (If you didn't already guess.)

Last Modified: December 20, 2005