Jun 132012
 

This isn’t a step-by-step guide, it’s a guideline. I’ve set up a server for Counter-Strike 1.6 (cstrike) and Couter-Strike: Condition Zero (czero) in a virtual machine, using VirtualBox. The big advantage is that it can be exported, copied to another server and imported there and it will (most likely) just run. All the software used is free and completely legal, no license to pay for, the only potential cost is the hosting. Most other Valve/Steam game servers are set up the same way, with different engines having a bit different system requirements, maybe.

1. The Virtual Machine


The idea is to make it as portable as possible. I’ve set it up with each game on a different hard drive, this way I can just copy that drive image to a different machine and it will run with almost no modification required, except maybe things like changing the owner of the files.

That means the machine will have three hard disks attached, one for the OS, the main disk, and the other two for the two game servers running on it. Each disk is a 4 GB disk, dynamically allocated. The whole machine is sitting at around 3.2 GB right now on my server, cstrike takes about 800 MB, czero around 1.2 GB.

The resources I gave it:

  • RAM – 512 MB (just fine for my needs)
  • VRAM – 4 MB (could’ve probably gone even lower, administering is done over ssh, no need for VRAM beyond initial setup)
  • CPU – 1, 100% exec cap, a 1.8 GHz CPU should be enough
  • Hardware Virtulization – enabled
  • Video acceleration -off
  • Network adapter – bridged, this depends on the host. This is the setting that will probably need to be adjusted when moving the machine
  • Audio – disabled
  • USB – disabled. In order to have USB disabled, “Absolute pointing device” needs to also be disabled on System page, if using the GUI to create the machine. This shouldn’t be a problem.
  • Storage – 1 SATA controller, 1 IDE with DVDRom attached. The IDE can be removed after the OS is installed, the SATA will control the hard disks. These can be created now, or attached later.

I have converted the hard disks to writethrough, “write-through hard disks are completely unaffected by snapshots: their state is not saved when a snapshot is taken, and not restored when a snapshot is restored”. I don’t plan on taking snapshots and the normal images tend to get slower over time. Converting the HDDs:

Repeat for all HDDs. Obviously, with the virtual machine shut down.

There’s a potential problem with networking when importing the machine on a new host. Namely, there’s a “feature” of udev on Linux that it will tie a MAC to an interface name (eth0), which means that when importing on a new host if the MAC changes, networking might not be set up properly. The link between MAC and iface is established in /etc/udev/rules.d/70-persistent-net.rules, at least on Debian-like distros. So, there are several options:
1. Before exporting remove all the lines from /etc/udev/rules.d/70-persistent-net.rules, this way even if the MAC changes it doesn’t matter since the old MAC won’t be there to cause trouble.
2. When importing there’s an option in the GUI to not change the MAC. There’s probably a way from command line too, but I’m not aware of it right now.
3. Make a note of the original MAC before exporting and change it after import, either from the GUI or from command line using

where N is the interface number, starting with 1, i.e.:

2. The OS


The only requirement to run the server is GLIBC 2.3.2 or newer. That’s around the year 2003, so pretty much any Linux distro will do. I’ve used a minimal Debian install. The swap partition can be about any size, 512 MB is more than enough, if it starts swaping you’ve got other problems anyway. There should probably be sshd running, other than that it depends on what you want to set up on it.

3. The firewall / port forwarding


Port 27015 is the default port, it can be changed from the command line or server.cfg file.

The client needs:

  • UDP 1200
  • UDP 27000 to 27015
  • TCP 27030 to 27039

4. Installing the server


Official support article (why don’t people link to it in their step-by-step guides?)
Prepare the hard disk, partition it with fdisk(8), install the file system with mkfs(8), mount(8) it. The lines in fstab(5) should look something like:

Add a new user, running as root might not be such a good idea. Could add a new user for each game, a user for all games, shell access isn’t strictly needed.

The home directory can be changed later with usermod(8) -d. Make sure it’s chown(1)-ed to the proper user. Don’t let everyone read config files that have passwords in them, ‘chmod -R o-rwx /czero’ is probably overkill, but at least it’s quick.

Time to install the game. Download hldsupdatetool.bin, make it executable and run it. It will create a new file called ‘steam’. That’s ‘HldsUpdateTool.exe’ from the official knowledge base article, the Linux version. Give it executable permissions and run it like this:

The first couple of times it will update itself and say something like

keep running it again until it starts downloading. Use

to see the available games.

That should be it. Probably some addons like AMX should be added to the server, but for now check if it runs:

5. Addons


Metamod install procedure.
Manual installation of AMX, which is a plugin for metamod that in turn has a lot of plugins written for it.
Non-Steam servers allow clients without Steam to connect. Those are illegal, outdated, harder to administer and all around not worth the trouble considering the price of the games these days. Dproto is a metamod plugin, but no longer maintained, others are payed for in some form. They are dangerous, any of them could be a backdoor. Also, most administration addons use the Steam ID of the player for various tasks, which isn’t available on non-steam clients and that could lead to trouble.

To add admins to AMX Mod X edit the file amxmodx/configs/users.ini, then, client side, add to your autoexec.cfg:

where _pw is defined in amxx.cfg, amx_password_field.
Alternatively, from the console, use amx_addadmin.

6. Startup scripts


Tmux is a terminal multiplexer. What this means in practice is that you can start a program inside tmux, “detach” it to leave it running in background, “reattach” the session later from wherever else and see what happened meanwhile. Like screen, but better.
The following shell scripts will start czero and cstrike respectively in two new tmux sessions called “czero” and “cstrike” and detach the session:

runczero.sh:

runcstrike.sh:

-nomaster will make it so the server isn’t listed on steam.

The scripts should be run as users cstrike and czero. To attach one of the sessions use

Detach again with “CTRL+b, d”. The -t parameter isn’t needed if only one session is running as that user.

In order to start the games when the server starts, add to /etc/rc.local:

7. Server configuration and optimization


Official optimizing guide.
server.cfg can be found in game’s directory, as in /czero/czsrv/czero/server.cfg:

  One Response to “Counter-Strike and Condition Zero dedicated server on Linux”

  1. i dint understand your method

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

(required)

(required)