Article: Installing a
Counter-Strike Server
June 21st, 2001
By Jason "MalHavoc" Nugent
(republished with permission original article can be found
here.)
Well, it's been a few
weeks, but that's mainly been because I've been super busy. At any rate, welcome
to the latest installation of "Serving with
Mal". As I mentioned last
time, this issue will deal with specifically installing a few different types of
games onto a Linux platform. By the end of this article, you will (hopefully)
have some basic understanding of a few common Linux/Unix tools, as well as the
ability to install a Counter-strike (and Halflife, by default) server. I know I
said that we'd also do Quake 3, but after thinking about it, I've decided to do
them one at a time. The article would just be too long if we did both at once.
This article will be less like me just rambling, and more like me telling you
what to type, and why. The "why" part is going to be there because just knowing
what to type isn't enough - you should walk away with an understanding of what
each command did, and why it was necessary. Let us begin.
Installing a Counter-Strike Server
I get a lot of requests for this one, so I'm going to go through this one
first. As most of you already know, Counter-Strike is a Halflife mod, which
means that in order to run a CS server, you need the Halflife server first.
If you have Halflife for the PC, you already have the Halflife dedicated
server for Windows. Our problem is, of course, that we're going to be running
this on a Linux server. So, a download is order.
You'll have to realize that this article may eventually get out of date,
although I will do my best to make sure it doesn't. The exact filenames I use
here might change when new releases or patches come out, so you might have to do
a bit of creative searching to find what you need.
The first file you will need is the HLDS (Halflife Dedicated Server) for
Linux, version 3.1.0.6. The filename for this file is hlds_l3106.tar.gz, and
here is a
link to it on FilePlanet. It is 101 megs in size, so be prepared to wait a
while. It certainly helps if you can download it right onto your Linux server,
since that's where the file will end up when you're done. If you are running an
X-window environment, you can just use Netscape. If you don't have access to an
X-window environment, you can try your hand with lynx, although I think that
FilePlanet's download manager will pretty much crush any attempt at using a
browser that doesn't support JavaScript and/or popup windows. Please, don't
blame me.
Or, cackle gleefully whilst you download it from
Blue's News, sans registration.
Once you have this file, you will then need the full Counter-Strike for Linux
install. The file name in this case is cs_11b_full.tar.gz, and you can get if
off of the downloads page
over at Counter-Strike.net. In *addition* to this file, you will also need a
server-side patch that upgrades CS to version 1.1c. This patch is not listed on
the main Counter-Strike.net download page, but here's a
link
to it's location on FilePlanet.
Alright. So, at this point, you should have three files in your posession -
the main HLDS file, the main Counter-Strike install file, and a smaller
Counter-Strike patch that upgrades your server to 1.1c. If you don't have all
three of these files, get them now.
Once you have all three of these files, upload them to your server, if they
aren't there already. Keep in mind that a game server install can consume a lot
of disk space - these files are compressed, and will easily take up the better
part of a Gb when installed. Be wary of that before you decide to proceed, since
Linux does nasty things if it runs out of disk space.
Now that we have these files up on the server, we have to decide where we're
going to put them. Traditionally, a Unix file system is broken down logically
into several sub directories or "trees". These trees have, by convention,
specific uses. For example, the /var directory typically contains a
sub directory called logs/ that normally contains system logs from
all sorts of processes or daemons (server processes) that run. In our case,
we're going to make a sub directory inside of a directory that probably already
exists - /usr/local/. Just like it sounds, this directory is
primarily responsible for containing software packages that have been installed,
by the user, on this "local" server. Occasionally, a server may be part of a
global cluster or an environment in which certain directories may be shared
across multiple machines. This directory exists primarily to ensure that
machine-specific items will not get mixed up with non-specific ones.
So, first thing we do is move into the /usr/local directory.
cd /usr/local
Then, we make a new directory in here. You will most likely need to be the
superuser (root) in order to perform this next step. I'm making the assumption
in this article that these servers belong to you, and that you can do what you
please. If you aren't root, then find a suitable directory that you're allowed
to make subdirectories in. Your home directory (/home/your-username)
is probably one such place. At any rate, let's make a directory:
mkdir halflife
After this step, we've got a home for our files. Now, just a quick word on
security. You should never, -EVER- run a game server as root. If someone were to
ever find an exploit in the game server code and gain access to your Linux
machine via your game server, they'd have full root access if the game server
process had been running as root. Make sure that you run your server as a
non-privileged user. To that end, we want to make sure that our non-privileged
user will be able to do things to the files in this directory. As such, we
should now give that user ownership of the directory we just created.
chown username:usergroup halflife
"chown" is a unix command that is short for CHange OWNer. The username is the
username of the person you want to let own this directory. By convention, all
user accounts on a Unix server are also part of at least one group. To find out
what to put for the usergroup bit, log in as the non-privileged user and type
id. It will print out a few things, one of which will be a gid
(group id). This is the value you want here.
Once you issued this command, you can put away your superuser access for now,
as you no longer need it. Log in as your regular user, and copy the
hlds_3106.tar.gz file from the place you uploaded it to the /usr/local/halflife
directory by running:
cp /path/to/original/hlds_3106.tar.gz /usr/local/halflife/
The spacing is important, so type it carefully. If it works (you'll know it
worked if you don't see any error message. Unix only says something when bad
things happen), you should be able to go into the /usr/local/halflife
directory and type ls. You should see one file listed - the hlds
file you just put there.
This file is compressed. In fact, the astute amongst you may notice that it
has two file extensions, .tar.gz. That's because two things have been done to
the contents of this archive. First, the contents of the archive were grouped
together to form one large file with no compression. The utility used to perform
this is called tar, which stands for Tape ARchive. After this step,
the file is compressed with a Unix utility called gzip. So, in
order to get what we want, we have to go backwards through this route.
Fortunately, just about all new Unix/Linux servers come with a version of
tar that can do both steps at once. The command to untar and unzip our
archive is, then:
tar xvzf hlds_3106.tar.gz
The x is for "eXtract", the v is for "verbose", so
we see the files coming out of the archive as they are extracted, z
is for "gZip", (since our archive is also zipped), and finally, f
means to assume the archive is a regular file. This last one is important since
tar normally assumes that the archive is on tape. If all goes well, you should
have a directory called hlds_l located inside of the /usr/local/halflife
directory. Like winzip for windows, the tar command restores
subdirectories and file paths for us.
If all we wanted to do is run a Halflife DM server, or a TFC server, we'd be
done with extracting files at this point. This is why I said that installing
Counter-Strike naturally gives you the ability to run a HL server as well. Since
we want to run a CS server, though, we're not quite done with files just yet.
First thing you need to do is to copy the cs_11b_full.tar.gz file into the
hlds_l directory that was created for you when you ran the
tar command. The command to do this would be:
cp /path/to/original/cs_11b_full.tar.gz /usr/local/halflife/hlds_l/
Once you've done that, cd into that directory and run the same
tar command as before, but using the new cs_11b_final.tar.gz
filename instead. It should create a directory called cstrike/.
Now, remember that there is also a small patch to install. Copy that file to
the /usr/local/halflife/hlds_l/ directory, just like you did with
the full CS install. Run the same tar command on it. If it asks you
if you want to overwrite some existing files, say "yes", since it's meant to
update a few things.
Whew. After all that work, you've got all the necessary files installed to
run a Counter-Strike game server. There's only a few small steps left, mainly
dealing with a) customizing your server so it runs the way you want it to, and
b) figuring out a way to start it and keep it up once it's up.
The main application for running a Counter-Strike server (or any Halflife-based
server, for that matter), is a program called hlds_run, located
inside of your /usr/local/halflife/hlds_l/ directory. This
application is the entry point into the server, and you can tell it what game
(or mod) to run by passing it a number of "command line arguments". A command
line argument is simply that - a way to pass in extra information to an
application via the command line. For instance, when you copy a file from one
place to another, you need to tell the cp command what file to
copy, and where to put it. These two things are specified on the command line,
and are, therefore, command line arguments.
In our case, hlds_run is going to have to be told to run a game
of Counter-Strike. To accomplish this, we need to pass in a -game cstrike
argument, which will tell it to look in the cstrike/ subdirectory
for more information and extra files. In addition to this, it'd be a good idea
if we told it what config file to use, our maximum number of players allowed, as
well as what map to start our server off with. To do this, we can pass in three
extra command line arguments, +exec server.cfg, +maxplayers
20, and +map de_dust2. So now, our command line to start our
server looks something like this:
/usr/local/halflife/hlds_l/hlds_run -game cstrike +exec server.cfg +maxplayers
20 +map de_dust2
Naturally, of course, you'd want to make sure that you've edited the
server.cfg file located in the cstrike/ directory since it will
contain things like the name of your server, whether or not you want friendly
fire on or off, etc. It's not really my goal to teach the use of a Unix text
editor in this article, but you could always experiement with some of the more
common ones - vi, emacs, or pico.
If you go ahead and run that particular command line, you'll most likely end
up getting an error that says something about not being able to find a library
called libhlwon.so. The way Unix works (and windows, actually), is
that there are only a certain number of directories that the operating system
will look inside to find specific files. An example of this is your PATH.
This is a variable which contains a colon-separated (semi-colon on windows) list
of directories that Unix will look in, each in turn, to find the command you
just typed. If it doesn't find it, it will return an error saying "command not
found".
In our case, the reason why we get an error is because Unix can't find the
libhlwon.so shared object library file. Shared object library files are a little
like DLLs from windows. They contain a set of routines that an application may
want to use. In our case, this particular library contains information on how
Halflife is supposed to contact a WON server to find out if a person should be
authorized and allowed to join. Since it can't find the library, our command
line doesn't work.
So, we have to tell Unix where that library is. There are a couple of ways to
do this, so I'll just mention two of the easiest here. First, on a Linux machine
there is a file called /etc/ld.so.conf that you can edit. Each line
in that file specifies a directory that the ldconfig utility will
look in to find .so files that applications are allowed to use. If you put
/usr/local/halflife/hlds_l in that file, be sure to run the
ldconfig command afterward. You will need to be logged in as root to
perform those two steps.
The easier way to do it is to set the LD_LIBRARY_PATH variable
right before you try executing your hlds_run command line. Right
before you run your command line, you can type this:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/halflife/hlds_l:.
which does one thing - it resets the contents of that variable so it contains
the contents of what it -used- to have (thats what the $LD_LIBRARY_PATH part is
for), and then sticks on two new directories. The first directory is the one
that actually contains the libhlwon.so file we're interested in,
and the second one is the "dot" directory, which is handy if you want to be able
to use the current directory as a source of .so files. It's very important that
you get the spacing right. There are NO spaces around the equals sign, and the
variable name is in all uppercase letters.
Now, you should be able to start up your Counter-Strike server. This time,
you should see a whole pile of stuff scroll by, mainly talking about loading
things from pak files and what not. The last three lines you should see should
mention the listen servers that your server will be listed with, provided you're
not running a LAN only server. Congratulations! You've just set up a CS server
on a Linux machine.
One fairly large issue remains. You'll notice that your command line is gone,
because you're stuck at the CS server console. This is fine, if you want to be
able to issue commands directly into the server, but it would be nice if you
could log out of the machine and come back in when you wanted to.
You can't just CTRL-C out of the process, because that will kill your server.
You can't CTRL-Z out of the process, because that would suspend it. It would be
nice if you could start your server, and somehow leave it in interactive mode so
you could come back to it later, without having to leave yourself logged in. To
accomplish this, we're going to look at a utility called screen.
screen is a utility that basically provides something called a "detacheable
tty" for an interactive process. It's usage is quite simple:
/usr/local/bin/screen -S cs-server /full/command/line/to/start/cs-server
Now, your mileage may vary with that command line. For me, that's how I'd
start one on my own servers. It may be different on your server since you might
have screen installed in a different location, or it might take
different command line arguments than the ones I've used above. The syntax
should be similar though. The first argument, -S cs-server, gives
us a way to refer to the screened process when we log back in later to kick the
guy who AWPed you in the back of the head when you were calling someone a
"cheating l4m3r". The second argument is just the full command that you want to
have start in the screened tty. In our case, it's just our hlds_run
command line.
Running that command produces the same output as before, but now you can
"detach" it and then log out. To detach a screened process, press CTRL-a then
CTRL-d. You'll get a [detached] message, and you'll be back at your shell
prompt. You can then log out normally, or do other stuff. To get back in to your
server console, you can just type:
screen -r cs-server
Which will "resume" the screen named "cs-server". If you ever forget what you
called your screened process, you can type:
screen -list
Which will list all of your screened processes. You can then connect to the
one you want.
I've come up with a number of ways over the last while to restart a crashed
game server. It -will- happen. Your server will die from time to time. It's a
fact of life. What you shouldn't just accept, though, is that your server must
remain dead until you restart it manually. Doing stuff the hard way is for
chumps.
I'm a big fan of shell scripting. Shell scripts can save you a lot of time,
and in this case, we're going to write a shell script that will restart the
server if it ever dies on us. That's a good thing.
A shell script is just a text file with a number of special directions, or
code, that the shell interpreter (bash, in this case) will execute for us. We're
going to tell bash to constantly check to make sure that our server is up, and
if it dies, to restart it after a few seconds. I'm just going to put the whole
script here at once, and then go through it line by line.
#!/usr/local/bin/bash
while true
do
/usr/local/hlds_run -game cstrike +exec server.cfg +maxplayers 20 +map
de_dust2
sleep 5
done
There are really only three important parts to this script. The first line
just tells our shell what interpreter to use to figure out what it's supposed to
do (in this case, bash is installed in /usr/local/bin/,
your shell may be in a different location). The rest of the script is a
while loop. All this loop does is perform something over and over again
while a condition is true. Inside the loop are two lines. The first line is the
command to start our server. The second command is a sleep command
which tells the shell to wait 5 seconds if the server ever dies, before
restarting it again.
See? That's not so bad.
Suppose we save this script in a file called startcs.sh. Since
this needs to be executed, we have to make it executable. To do this, we use the
chmod unix command. chmod stands for CHange MODe, and
is used to change the permissions on a file. We want it to be executable, so we
could run this:
chmod u+x startcs.sh
which would give the "user" of the file "eXecute" privileges. Since the file
belongs to us (we wrote it), we are considered the user. Now, we can run it.
Let's combine with our screen command:
/usr/local/bin/screen -S cs-server /usr/local/halflife/hlds_l/startcs.sh
assuming we put the startcs.sh shell script inside of our
/usr/local/halflife/hlds_l/ directory.
That's it. If the server were to ever die, it would only be down for a
maximum of 5 seconds, after which the shell script will just restart it. Any
time you log in to get into the console, you can just go in via screen -r
cs-server, and do whatever you want to do.
This article went on a bit longer than my other ones, mainly because I wanted
to cover some basic shell scripting and make sure that the Unix commands used
were explained in detail. The next time we set up a server, it won't be quite so
bad. I promise that we'll get to Quake 3 next time. Maybe even set up a mod,
like Urban Terror. :)
Related Links:
Serving With Mal> - 1st
Installment
Serving With Mal - 2nd
Installment
Copyright © by GameAdmins All Right Reserved.
