Weasel's Dedicated-Server Management Scripts, (for Linux) - v1

OBSOLETE:

!!! Do NOT use !!! See the NEW system (and guide) instead!!!!

• New (v2) guide on Steam:
  Weasel's Game-Administrator / Server-Manager (wGASM), for Linux - v2
  
• New (v2) content on GitHub:
  Weasel's Game-Administrator / Server-Manager (wGASM), for Linux - v2[github.com]

---

About the Scripts:

The sample scripts provided allow for easily completing many tasks associated with hosting dedicated game-servers. This includes things such as:

• Installing the game-servers in a consistent manner.
  
• Running the game-servers interactively at the console for testing / troubleshooting.
  
• Starting the game-servers as disconnected / back-ground processes - so that they can run unattended.
  
• Stopping the disconnected / back-ground processes of the game-servers.
  
• Manually updating the game-servers if needed.
  
• Checking for updates available for the game-servers, and conditionally updating the game-servers, restarting them only if an update is needed.
  
• Monitoring game-servers running under GNU screen for fatal errors, and automatically restarting - only if needed.
  
• Making backups of the game-servers.
  
• Generating lists of "stock" content to exclude from backups.

About the Author:

I have been hosting dedicated game-servers for various Valve software game titles, since late 1999 or early 2000 - long before there was any such thing a "Steam". I switched from attempting to host game-servers on Windows to Linux, some time in the early 2000's (circa 2007?).

I recently completely re-wrote all my Linux (bash) scripts used for management of my dedicated game-servers, in the last couple of months (early 2024). When I re-wrote everything, I tried to make them less proprietary, and more easily re-usable by other people needing similar scripts.

If you find this guide and/or the related scripts useful, please click the "thumbs-up" button to like it. Optionally, please feel free to let me know you are using them. If you do not find them useful, no need to post anything or reach-out. Good luck in your endeavors.

---

LICENSE: Please feel free to share this "Guide", and of course the scripts themselves freely. As far as I am concerned, they are now public-domain[en.wikipedia.org]. Credit is requested where appropriate, but certainly not required.

---

#Weasel, #WeaselsLair, #WeaselsLair.com,
#GoldSrc, #HLDS, #HLDedicatedServer,
#Source, #SRCDS, #SourceDedicatedServer,
#Linux, #Debian, #bash, #webmin

0. Revision History

Be sure to check here for anything that may have changed, since the last time you read-through or used this guide.

NOTE: Latest updates at the top,

Revision Date	Revision Notes
20240417a	Completed the section regarding "cron" scripts.
20240415b	Expanded the section(s) about the related Example VPS. Added information regarding downloading the Example VPS via "BitTorrent".
20240415a	Updated the Example VPS sections to note that the virtual machine image will now be made available for two ( 2 ) virtualization systems: VirtualBox [www.virtualbox.org] VMWare Player [en.wikipedia.org]
20240412a	Added and completed a new section documenting the " monitor "scripts. Added a placeholder for a new section regarding the " cron "scripts.
20240411a	Be sure to grab the latest version of the scripts from GitHub. Latest revision is available HERE [github.com] Recent improvements to the scripts (in release v1.1.2): Fixes to "check" scripts for games running the Source game-engine (TF2, CSS,DoDS,FoF), to perform the check query using the AppID of the game-client (while the update/install will actually happen with the AppID of the dedicated-server ). Improvement to "update" scripts, so that it only stops/restarts a game-server if it was already running, otherwise it just runs the "install" script to update it off-line and leave it offline (un-started). This allows for game-server to be updated without accidentally launching them unintentionally. Improvement to "monitor" script, so that it only stops/restarts a game-server if it was already running. This allows for game-servers being off-line for maintenance or other reasons. Improvement to "monitor" script, so that in addition to monitoring for "fatal error" and "segmentation fault" conditions, it will now also monitor for game-servers running under screen whos screen log output is not showing any console output for a certain threshold (typically 15 minutes).
20240408b	Expanded the section about Package Dependencies , to include some important stuff used in the related Example VPS.
20240408a	Added note in Planning section regarding allowing of hyphens (" - ") in gameserverid 's. Fixed dates in the revision history with the incorrect year (2025 instead of 2024). Fixed various typographical and/or grammatical errors (still more of them to come!)
20240405b	Finished expanding/updating section(s) regarding example VPS. Upload of updated example VPS (dated 20240330 b ) is in progress
20240405a	Updated main start script ( start-game.sh ) to instruct GNU Screen utility to log game-server console output to a file (inside the ~/logs folder), named for the game-server started (e.g. ~/logs/gameserverid-screen.logs ). Latest release available on GitHub: here [github.com] .
20240330a	Started expanding/updating section(s) regarding example VPS.
20240329a	Fixed sample exclude-all script (exclude-all-example.sh).
20240327a	Added new section for newly-uploaded sample virtual machine / example VPS.
20240325d	Moved revision history to its own guide section, and converted to table format.
20240325c	Updated scripts.tar.gz on GitHub, besure to download the latest version with the latest fixes included (https://github.com/Mecha-Weasel/game-server-scripts/raw/main/scripts.tar.gz)
20240325b	Added note regarding GoldSrc game installs possibly requiring multiple passes to fully install.
20240325d	Added note regarding creating possible missing folders under "Installing SteamCMD" section.
20240323e	Added note regarding autoexec.cfg to "run" scripts section.
20240323d	Added public-domain / license note.
20240323c	Fixed several typographical errors.
20240323b	Added hashtags.
20240323a	Initial publication.

1. Planning Requirements (READ THIS)

---

WARNING: Do NOT skip this section! Everything else in this guide is dependent on it!

---

For each game server you are planning to host (even if its just a single game-server), you will need to plan ahead with three (3) pieces of information:

1. A unique alphanumeric "gameserverid". This is basically a short name that the scripts will use to identify which specific game-server you are trying to operate on. This could be as simple as "gameserverid1", or more complex such as "hl1server1", "hl1server2, "cs1server1", "cs1server2", etc. These names must be unique to each server instance, and must be entirely lower-case alpha-numeric: Only containing characters a-z and/or 0-9, no upper-case letters, no spaces nor any punctuation allowed. Given that file systems on Linux are generally case-sensitive, keeping all of these lower-case prevents a wide-range of possible issues. Update: Technically, the scripts generally allow for a hyphen ("-") in the gameserverid also. But that is the only punctuation allowed.
   
   
2. A unique numeric network port number for each game-server. Obviously, this must be an all numeric value - Only containing characters 0-9, no letters, spaces or any punctuation allowed. The default is typically 27015. if you are hosting multiple game-servers, they must each have their own unique port number assigned. They can not all be 27015. Generally, a value somewhere in the 27000-27999 range is typical for these types of game-servers. However, any number in the 1024-49151 range should work, assuming that number is not already used by some other process on your Linux host. Due to some bugs / features of how some game-engines work, it is recommended to skip at least one number between game-servers. A typical pattern might be something like this:
   
   

   Server	Port Number
   First game-server	27015
   Second game-server	27017
   Third game-server	27019
   Fourth game-server	27021

   
   
3. The Steam AppID for that game, and it's dedicated server AppID. In some cases, the AppID of the game and its dedicated server are the same. In other cases, they are different. Where possible, the sample "install" scripts provided already have this information properly included. But, you should be familiar with it. If you need to customize the scripts for a new game or mod, you will need such information.
   
   Steam AppID's for some common game titles are included in the table below:
   
   

   Game (Valve)	Game AppID	Server AppID
   Half-Life (Hl1)	70	90
   Deathmatch Classic (DMC)	40	90
   Team Fortress Classic (TFC)	20	90
   Team Fortress 2 (TF2)	440	232250
   Counter-Strike 1.6 (CS1)	10	90
   Counter-Strike:Source (CSS)	240	232330
   Counter-Strike 2 (CS2)	730	730
   Day of Defeat (DoD)	30	90
   Day of Defeat:Source (DoDS)	300	232290
   Game (3rd-party)	Game AppID	Server AppID
   Fistful of Frags (FoF)	265630	295230

2. Knowledge Requirements

To effectively implement and utilize the sample scripts, the user will need to know how to perform certain (common) actions on Linux. These include:

• Know how to login to the host Linux installation using SSH or some other mechanism to access the Linux command-line.
  
• Know how to install and update packages for your host operating system. Typically, this is accomplished with various "apt" commands.
  
• Know how to navigate the folder structure, at the command-line. Typically, this involves commands such as "pwd" and "cd".
  
• Know how to change permissions on files. Typically, this involves commands such as "chmod +x", or through a web-interface such as "webmin".
  
• Know how to upload files (such as the scripts) to the appropriate folders of your Linux installation. This may be accomplished any number of ways, including: "wget" to pull files directly from the internet, "scp" over and SSH session, or web-interfaces such as "webmin".
  
• Know how to edit text files. You will be doing this quite a lot. This typically involves using either command-line editors such as "nano", or editing files through a web-interface such as "webmin".
  
• Know how to create symbolic links[wiki.debian.org]. You may need to know how to create symbolic links to work-around bugs in the SteamCMD installation process. Sometimes, it does not automatically create all the symbolic links to various .so files that the game-servers require. Typically symbolic links are created either at the command-line using the "ln -s" command, or through a web-interface such as "webmin".

3. Assumptions

• All examples assume the distribution (flavor) of Linux being used is Debian[www.debian.org].
  
• All of the sample scripts are designed to run under the common Linux command-line shell called "bash". All examples here assume everything is being done under Linux. None of this is likely to work under Windows. Do not even ask about it.
  
• These examples generally assume all package dependencies have been installed previously using "root" or a sudo-enabled account - except for SteamCMD itself.
  
• The SteamCMD utility and the game-servers will be running under a different Linux account - something other than "root" - and that does not have sudo-access. The examples here assume this account will be named: "game-servers".
  
• This scripts only work with common Valve games using either the older "Source" (HL2-ish) game-engine, or the even older/ancient "GoldSrc" (HL1-ish) game-engine. Accommodation for Source2-based Counter-Strike 2 is included - but is somewhat experimental.
  
• It should be possible to adapt these scripts to any other games that are based upon either the Source or GoldSrc game-engines, as well as any 3rd-party total-conversion "mods" of such games.

4. Package dependencies

The following requirements generally must be completed logged-in as "root" or some other sudo-enabled account.

SteamCMD, Game-Server & Script-Related:

The SteamCMD utility requires that 32-bit architecture must be enabled. This might already be enabled. However, it is best to be certain it is enabled - before proceeding. For reference, this is typically accomplished with a command such as:

sudo dpkg --add-architecture i386;

The SteamCMD utility requires some additional packages. They can be installed with this command:

sudo apt-get install -y lib32gcc-s1;

Many of the scripts discussed here require the screen[en.wikipedia.org] utility. It can be installed with this command:

sudo apt-get install -y screen;

The backup scripts discussed here require the Linux version of 7-Zip[en.wikipedia.org]. It can be installed with this command:

sudo apt-get install -y p7zip-full;

The update scripts discussed here require the curl[en.wikipedia.org] utility to interact with the Steam API, using web-based protocols. It can be installed with this command:

sudo apt-get install -y curl;

Downloading the scripts directly to the server using the command-line, will require the Linux command-line git[en.wikipedia.org] client. It can be installed with this command:

sudo apt-get install -y git;

Several scripts utilize various Linux command-line text-processing tools. These include commands such as: cat, echo, cut, tr, sed, awk, tail, and grep. These are likely already installed. However, even if they are already installed, running the commands to install them will not hurt anything. They can be installed with this command:

sudo apt-get install -y coreutils grep;

If you are going to be hosting games based on the (ancient) GoldSrc[en.wikipedia.org] game-engine (HL1, DMC, TFC, CS1, DoD, etc.), it will be handy to have ncompress[ncompress.sourceforge.io] installed to make/manage .ztmp files. It can be installed with this command:

sudo apt-get install -y ncompress;

If you are going to be hosting games based on the Source[en.wikipedia.org] game-engine (HL2, TF2, CSS, FoF, etc.), it will be handy to have bzip2[sourceware.org] installed to make/manage .bz2 files. There is a good chance that it is already installed. However, if needed, it can be installed with this command:

sudo apt-get install -y bzip2;

Used in the example VPS:

NOTE: Depending on your Linux installation, many (if not most) of these may already be installed. However, even if they are already installed, running the commands to install them will not hurt anything.

Some additional packages were used in the building of the example VPS (near the end of this guide), that go beyond the minimum required above. These include:

The ifconfig[en.wikipedia.org] utility, to show the status of the computer's network interface (typically included with net-tools package). It can be installed with this command:

sudo apt-get install -y net-tools;

The netstat[en.wikipedia.org] utility, to which network ports are in use on the computer's network interface (typically included with net-tools package). It can be installed with this command:

sudo apt-get install -y net-tools;

The nicstat[http//nicstat] utility, to show usage statistics of the computer's network interface. It can be installed with this command:

sudo apt-get install -y nicstat;

The common Linux text editor nano[en.wikipedia.org]. It can be installed with this command:

sudo apt-get install -y nano;

The Linux command-line utility htop[en.wikipedia.org], think of it like a text-mode equivalent to Windows Task Manager. It can be installed with this command:

sudo apt-get install -y htop;

The Linux command-line utility wget[en.wikipedia.org] to directly download stuff from the Internet. It can be installed with this command:

sudo apt-get install -y wget;

Updating all packages:

Obviously, updates for all packages installed on the host should be applied. This is typically accomplished with a command such as:

sudo apt-get update;sudo apt-get upgrade -y;sudo apt-get autoremove -y --purge;

5. Installing SteamCMD (manually)

NOTE: These actions should be performed logged-in as the non-root / non-sudo Linux account (presumably "game-servers") - which all of the game-server instances will also be running under. The example scripts later in this guide, assume that SteamCMD utility is installed into the ~/steamcmd folder (presumably /home/game-servers/steamcmd). Putting it any other place, may break the functionality of the scripts.

The instructions below are a variation of the official instructions from: https://developer.valvesoftware.com/wiki/SteamCMD#Manually

You can use these commands to download, and install the SteamCMD utility:

mkdir ~/steamcmd;
cd ~/steamcmd;
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz;
tar -zxvf steamcmd_linux.tar.gz;
chmod +x steamcmd.sh;

Run SteamCMD the first time to have it update itself:

./steamcmd.sh;

Once the initial update is completed, you will get to a prompt like this:

Steam>

Enter the "quit" command to exit SteamCMD:

Steam>quit

Fixing some possible missing symbolic links:

In some cases, people have encountered issues with the SteamCMD utility not creating one or more symbolic links automatically. This seems to vary based on Linux distribution (Debian, Ubuntu, Mint, etc.). The commands to fix the two (2) I have noticed most commonly are included below:

Manually create these folders if they do not already exist, using these commands:

mkdir ~/.steam;
mkdir ~/.steam/sdk32;
mkdir ~/.steam/sdk64;

Fix possible missing ~/.steam/sdk32/steamclient.so file:

ln -s ~/steamcmd/linux32/steamclient.so ~/.steam/sdk32/steamclient.so;

Fix possible missing ~/.steam/sdk64/steamclient.so file:

ln -s ~/steamcmd/linux64/steamclient.so ~/.steam/sdk64/steamclient.so;

If using either of those commands results in an error message such as "failed to create symbolic link 'blah-blah-blah 'File exists", that is probably a good thing.

6. Additional requirements

The following requirements must be completed logged-in as the Linux account that the game-servers will actually be running under. Generally, this should not be "root", nor any other sudo-enabled account. It should be a completely non-privileged / non-administrator account. As mentioned previously, this Linux account is presumed to be "game-servers".

All the example scripts operate entirely within this non-privileged / non-administrator account. None of the scripts should require any administrative privileges to the host operating system (Linux).

Again, the examples here will assume the account is named "game-servers". However, the scripts themselves do not require the account to have that name. They will automatically use the name of whatever account is logged-in.

There are several folders that must be created (by you), branched directly from the "home" folder for that user account. These folders include:

Folder	Purpose
logs	Each of the scripts logs various activities to plain-text text files, located in this folder.
backups	Each of the backup scripts, outputs its backups in .zip format, into this folder.
temp	The 7-zip utility will use this folder for temporary files during the compression process.
tempwork	Some more advanced scripts, use this as a staging area.
scripts	All the example scripts are located within sub-folders here.
scripts/install	Scripts that are used to install / update game-servers.
scripts/run	Scripts that run game-servers directly / interactively in the foreground.
scripts/start	Scripts that start game-servers as a disconnected / background process.
scripts/stop	Scripts that stop game-servers already running as a disconnected / background process.
scripts/update	Scripts that update game-servers that are already running as a disconnected / background process.
scripts/check	Scripts that check if an update is available for a game-server, and if so update it.
scripts/backup	Scripts that perform backups of game-server content, using 7-zip (but outputting to .zip format for greater compatibility).
scripts/exclude	Scripts that generated exclusion files to reduce backup-file sizes.
scripts/monitor	Scripts that will monitor for various fatal conditions and restart servers if needed..
scripts/cron	Scripts that may be invoked by the Linux "cron" job-scheduler to perform various tasks (such as running the "monitor", "check" and/or "backup" scripts automatically).

Please note that on Linux, file and folder names are case-sensitive. Be sure to create them entirely lower-case.

The required folders may be created with commands such as these:

mkdir ~/logs;
mkdir ~/backups;
mkdir ~/temp;
mkdir ~/tempwork;
mkdir ~/scripts;
mkdir ~/scripts/install;
mkdir ~/scripts/run;
mkdir ~/scripts/start;
mkdir ~/scripts/stop;
mkdir ~/scripts/update;
mkdir ~/scripts/check;
mkdir ~/scripts/backup;
mkdir ~/scripts/exclude;
mkdir ~/scripts/monitor;
mkdir ~/scripts/cron;

7. Downloading the Scripts

The entire contents of the sample ~/scripts folder has been tar-balled, g-zipped, and uploaded to a public GitHub.

NOTE: The latest versions of the scripts are available on GitHub: HERE[github.com].

Make sure you put the scripts folder directly into the non-root / non-sudo user's "home" folder. Putting it any other location will break functionality.

You can download the scripts-latest.tar.gz archive file, using these commands:

cd ~/;
wget -O scripts-latest.tar.gz https://github.com/Mecha-Weasel/game-server-scripts/raw/main/scripts-latest.tar.gz;

You can extract the scripts folder from the archive, using these commands:

cd ~/;
tar -xvzf scripts-latest.tar.gz;

8. The "install" scripts

NOTE: These scripts do the work of using the SteamCMD utility to install your game-server(s) in an orderly and consistent fashion. However, after the game-server is "installed", it will still need additional work to be playable, such as:

• Creating / editing various .cfg files to configuration various settings.
  
• In particular autoexec.cfg is typically required for any startup parameters that might otherwise be required at the command-line. This includes things such as which map to load at startup, enable secure-mode, etc.
  
• Also typically, there is an existing server.cfg file, which may need to be edited to adjust other settings - many of which are game-specific.
  
• In some rare cases, creating symbolic links for .so files that might not be correctly setup by default.

As the names imply, these scripts are intended to install dedicated game-servers easily. There are two types of install scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.

There is one script for each type of game to install, as noted in the following table:

Script	Game it installs
~/scripts/install/install-game-hl1.sh	Half-Life (Hl1)
~/scripts/install/install-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/install/install-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/install/install-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/install/install-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/install/install-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/install/install-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/install/install-game-dod.sh	Day of Defeat (DoD)
~/scripts/install/install-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/install/install-game-fof.sh	Fistful of Frags (FoF)

Using the game-type install scripts directly:

• Each game-type script requires a single command-line parameter: gameserverid
  
• Each game-type script will create a folder with a name matching the gameserverid passed, directly in the user's "home" folder (example: /home/game-servers/gameserverid/).
  
• Each game-type script has internal variables defined for the particular game / mod to be installed, This should make it easy to modify for different game types in the future.
  
• Each of those game-type scripts may be run directly from the command-line, with the required gameserverid passed as a parameter.
  
• However, the game-type install scripts exist primarily to be called from the server-specific install scripts (which you will create, based on the example provided).

Creating and using server-specific install scripts:

These scripts will exist, In order to facilitate easily re-installing and/or updating the game-servers later, as well as calling the appropriate install script for any particular server from other scripts (such as the update scripts, later in this guide).

• For each individual game-server that will exist, create a new copy of the sample install-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server install script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server install script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• These additional server-specific scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related update scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/install/*.sh;).

NOTE: GoldSrc game installations may require multiple passes to fully "install"! This is a known issue, that Valve has not yet addressed in the back-end content-management system, and is unlikely to ever truly fix.

While trying to run a newly-installed game-server, you may get a message such as this:

FATAL ERROR (shutting down): W_LoadWadFile: couldn't load gfx.wad

You will need to use the server-specific install script for that server again. This is a known bug with SteamCMD and the installation of games running the ancient "GoldSrc" game-engine. This includes games such as: HL1, DMC, TFC, DoD and CS 1.6.

Sample server-specific install script:

Name: ~/scripts/install/install-gameserverid1.sh

#!/bin/bash
#
# Define some variables ...
#
GAME_SERVER="gameserverid1";      # name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";   # base folder where various related scripts are located.
#
# Install/update the server ...
# Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/install/install-game-hl1.sh $GAME_SERVER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/install/install-game-dmc.sh $GAME_SERVER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/install/install-game-tfc.sh $GAME_SERVER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/install/install-game-tf2.sh $GAME_SERVER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/install/install-game-cs1.sh $GAME_SERVER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/install/install-game-css.sh $GAME_SERVER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/install/install-game-cs2.sh $GAME_SERVER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/install/install-game-dod.sh $GAME_SERVER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/install/install-game-dods.sh $GAME_SERVER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/install/install-game-fof.sh $GAME_SERVER;   # Fistful of Frags (FoF)

9. The "run" scripts

NOTE: GoldSrc game installations may require multiple passes to "install"!
While trying to run a newly-installed game-server, you may get a message such as this:

FATAL ERROR (shutting down): W_LoadWadFile: couldn't load gfx.wad

If so, you will need to use the server-specific install script for that server again. This is a known bug with the installation of games running the ancient "GoldSrc" game-engine. This includes games such as: HL1, DMC, TFC, DoD and CS 1.6.

As the names imply, these scripts are intended to run dedicated game-servers (interactively, in the foreground) easily. There are two types of run scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.

There is one script for each type of game to run, as noted in the following table:

Script	Game it runs
~/scripts/run/run-game-hl1.sh	Half-Life (Hl1)
~/scripts/run/run-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/run/run-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/run/run-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/run/run-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/run/run-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/run/run-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/run/run-game-dod.sh	Day of Defeat (DoD)
~/scripts/run/run-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/run/run-game-fof.sh	Fistful of Frags (FoF)

Server start-up options and "autoexec":

The run scripts are designed to use the minimal possible parameters passed at the command-line to the underlying dedicated game-server executables (HLDS and/or SRCDS).

For any additional start-up parameters you want passed to the dedicated game-server, you must create and use autoexec.cfg files. These are files with various game-server settings, which are automatically applied when the game-server first starts.

For GoldSrc[en.wikipedia.org] / HLDS games (such as HL1, DMC, CS1, TFC and DoD), the autoexec.cfg file is stored in the game-servers mod-folder (gameserverid/valve/, gameserverid/cstrike/, etc.). If it does not already exist, just create it with any text editor.

For Source[en.wikipedia.org] / SRCDS games (such as TFC, CSS, DoDS and FoF), the autoexec.cfg file is stored in the cfg sub-folder of the game-servers mod-folder (gameserverid/valve/cfg/, gameserverid/cstrike/cfg/, etc.). If it does not already exist, just create it with any text editor.

NOTE: Be sure that the last line in the autoexec.cfg file contains the "map" command, followed by whatever map you want the server to run at start-up.

Using the game-type run scripts directly:

• Each game-type script requires two (2) command-line parameters: gameserverid & portnumber
  
• Each game-type script will start the game stored in folder with a name matching the gameserverid passed (example: /home/game-servers/gameserverid/).
  
• Each game-type script has internal variables defined for the particular game / mod to be run. This should make it easy to modify for different game types in the future.
  
• Each of those game-type scripts may be run directly from the command-line, with the required gameserverid and portnumber both passed parameters.
  
• However, the game-type run scripts exist primarily to be called from the server-specific run scripts (which you will create, based on the example provided).

Creating and using server-specific run scripts:

These scripts will exist, in order to facilitate easily running the game-servers later, as well as calling the appropriate run script for any particular server from other scripts (such as the start scripts).

• For each individual game-server that will exist, create a new copy of the sample run-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server run script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server run script, and alter the "PORT_NUMBER" value to match the actual portnumber for that game-server.
  
• Edit the new individual game-server run script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• These additional server-specific scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related start scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/run/*.sh;).

Sample server-specific run script:

Name: ~/scripts/run/run-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";     # name/Id of the game-server to be installed.
PORT_NUMBER="27015";             # network port number for game-server to use.
SCRIPTS_FOLDER="$HOME/scripts";  # base folder where various related scripts are located.
#
#	Run the server ...
#	Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/run/run-game-hl1.sh $GAME_SERVER $PORT_NUMBER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/run/run-game-dmc.sh $GAME_SERVER $PORT_NUMBER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/run/run-game-tfc.sh $GAME_SERVER $PORT_NUMBER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/run/run-game-tf2.sh $GAME_SERVER $PORT_NUMBER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/run/run-game-cs1.sh $GAME_SERVER $PORT_NUMBER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/run/run-game-css.sh $GAME_SERVER $PORT_NUMBER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/run/run-game-cs2.sh $GAME_SERVER $PORT_NUMBER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/run/run-game-dod.sh $GAME_SERVER $PORT_NUMBER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/run/run-game-dods.sh $GAME_SERVER $PORT_NUMBER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/run/run-game-fof.sh $GAME_SERVER $PORT_NUMBER;   # Fistful of Frags (FoF)

10. The "start" scripts

As the names imply, these scripts are intended to start dedicated game-servers easily - as a disconnected / background process using the GNU "Screen" utility. There are three types of start scripts:

• The main start-game.sh script - which uses the GNU "Screen" utility to launch game-servers as a disconnected background process.
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" start scripts used to restart multiple game-servers in one command.

Using the main start script directly:

• Unlike some of the other scripts, the main start script (start-game.sh) does not need to know the game-type of the server it is going to start. It only needs to know the gameserverid to start. It will automatically call the appropriate server-specific run script for the gameserverid specified.
  
• The main start script (~/start/start-game.sh) requires only a single command-line parameter: gameserverid
  
• However, the main start script exists primarily to be called from the server-specific start scripts (which you will create, based on the example provided).

Creating and using server-specific start scripts:

These start scripts will exist, in order to facilitate easily starting the game-servers as a disconnected background process. And maybe be called from other scripts which depend upon them (such as the update scripts).

• For each individual game-server that will exist, create a new copy of the sample start-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server start script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• These additional server-specific start scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related update scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/start/*.sh;).

Sample server-specific start script:

Name: ~/scripts/start/start-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";	# name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";	# base folder where various related scripts are located.
#
#	Install/update the server ...
#
cd $SCRIPTS_FOLDER;
$SCRIPTS_FOLDER/start/start-game.sh $GAME_SERVER;

Sample start-all script:

Name: ~/scripts/start/start-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Start all dedicated game servers
#	============================================================================
#	Created:       2024-03-06, by [e-mail]        
#	Last modified: 2024-03-23, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Purpose:
#	
#		Start all dedicated games servers listed below ...
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#	
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
echo "";
date;
echp "Listing running 'screen' sessions, before starting/restarting game-servers ...";
screen -ls;
echo "Invoking each game-server 'start' script ...";
#$SCRIPTS_FOLDER/start/start-gameserverid1.sh;	#	example game server #1
#$SCRIPTS_FOLDER/start/start-gameserverid2.sh;	#	example game server #2
#$SCRIPTS_FOLDER/start/start-gameserverid3.sh;	#	example game server #3
#$SCRIPTS_FOLDER/start/start-gameserverid4.sh;	#	example game server #4
echo "Listing running 'screen' sessions, after starting/restarting game-servers ...";
screen -ls;
date;
#
#	Display end of stuff ...
#
echo "";
echo "[End of script: ${0##*/}]";

11. The "stop" scripts

As the names imply, these scripts are intended to easily stop dedicated game-servers currently running as a disconnected / background process using the GNU "Screen" utility. There are three types of start scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" stop scripts used to stop multiple game-servers in one command.

There is one script for each type of game to stop, as noted in the following table:

Script	Game it stops
~/scripts/stop/stop-game-hl1.sh	Half-Life (Hl1)
~/scripts/stop/stop-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/stop/stop-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/stop/stop-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/stop/stop-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/stop/stop-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/stop/stop-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/stop/stop-game-dod.sh	Day of Defeat (DoD)
~/scripts/stop/stop-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/stop/stop-game-fof.sh	Fistful of Frags (FoF)

Using the game-type stop scripts directly:

• Each game-type stop script requires only a single command-line parameter: gameserverid
  
• Each game-type stop script will stop the game stored in folder with a name matching the gameserverid passed (example: /home/game-servers/gameserverid/).
  
• Each game-type stop script has internal variables defined for the particular game / mod installed. This should make it easy to modify for different game types in the future.
  
• Each of those game-type stop scripts may be run directly from the command-line, with the required gameserverid parameter.
  
• However, the game-type stop scripts exist primarily to be called from the server-specific stop scripts (which you will create, based on the example provided).

Creating and using server-specific stop scripts:

These scripts will exist, in order to facilitate easily stopping the game-servers running as a disconnected background process, as well as calling the appropriate stop script for any particular server from other scripts (such as the update scripts).

• For each individual game-server that will exist, create a new copy of the sample stop-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server stop script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server stop script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• These additional server-specific scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related update and start scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/stop/*.sh;).

Sample server-specific stop script:

Name: ~/scripts/stop/stop-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";	# name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";	# base folder where various related scripts are located.
#
#	Stop the server ...
#	Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/stop/stop-game-hl1.sh $GAME_SERVER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/stop/stop-game-dmc.sh $GAME_SERVER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/stop/stop-game-tfc.sh $GAME_SERVER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/stop/stop-game-tf2.sh $GAME_SERVER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/stop/stop-game-cs1.sh $GAME_SERVER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/stop/stop-game-css.sh $GAME_SERVER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/stop/stop-game-cs2.sh $GAME_SERVER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/stop/stop-game-dod.sh $GAME_SERVER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/stop/stop-game-dods.sh $GAME_SERVER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/stop/stop-game-fof.sh $GAME_SERVER;   # Fistful of Frags (FoF)

Sample stop-all script:

Name: ~/scripts/stop/stop-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Stop all dedicated game servers
#	============================================================================
#	Created:       2024-03-06, by [e-mail]        
#	Last modified: 2024-03-23, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Purpose:
#	
#		Stops all dedicated games servers listed below ...
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#	
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
echo "";
date;
echo "Listing running 'screen' sessions, before stopping game-servers ...";
screen -ls;
echo "Invoking each game-server'stop' script ...";
#screen -A -m -d -S stop-gameserverid1 $SCRIPTS_FOLDER/stop/stop-gameserverid1.sh;	#	example game server #1
#screen -A -m -d -S stop-gameserverid2 $SCRIPTS_FOLDER/stop/stop-gameserverid2.sh;	#	example game server #2
#screen -A -m -d -S stop-gameserverid3 $SCRIPTS_FOLDER/stop/stop-gameserverid3.sh;	#	example game server #3
#screen -A -m -d -S stop-gameserverid4 $SCRIPTS_FOLDER/stop/stop-gameserverid4.sh;	#	example game server #4
echo "Listing running 'screen' sessions, after stopping game-servers ...";
screen -ls;
date;
#
#	Display end of stuff ...
#
echo "";
echo "[End of script: ${0##*/}]";

12. The "update" scripts

As the names imply, these scripts are intended to easily force an update on dedicated game-servers currently running as a disconnected / background process using the GNU "Screen" utility. There are three types of update scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" update scripts used to update multiple game-servers in one command.

There is one script for each type of game to update, as noted in the following table:

Script	Game it updates
~/scripts/update/update-game-hl1.sh	Half-Life (Hl1)
~/scripts/update/update-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/update/update-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/update/update-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/update/update-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/update/update-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/update/update-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/update/update-game-dod.sh	Day of Defeat (DoD)
~/scripts/update/update-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/update/update-game-fof.sh	Fistful of Frags (FoF)

Using the game-type update scripts directly:

• Each game-type update script requires only a single command-line parameter: gameserverid
  
• Each game-type update script will update the game stored in folder with a name matching the gameserverid passed (example: /home/game-servers/gameserverid/).
  
• Each game-type update script has internal variables defined for the particular game / mod installed. This should make it easy to modify for different game types in the future.
  
• Each of those game-type update scripts may be run directly from the command-line, with the required gameserverid parameter.
  
• However, the game-type update scripts exist primarily to be called from the server-specific update scripts (which you will create, based on the example provided).

Creating and using server-specific update scripts:

These scripts will exist, in order to facilitate easily updating the game-servers running as a disconnected background process, as well as calling the appropriate update script for any particular server from other scripts (such as the check scripts).

• For each individual game-server that will exist, create a new copy of the sample update-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server update script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server update script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• These additional server-specific scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related check scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/stop/*.sh;).

Sample server-specific update script:

Name: ~/scripts/update/update-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";     # name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";  # base folder where various related scripts are located.
#
#	Update the server ...
#	Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/update/update-game-hl1.sh $GAME_SERVER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/update/update-game-dmc.sh $GAME_SERVER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/update/update-game-tfc.sh $GAME_SERVER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/update/update-game-tf2.sh $GAME_SERVER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/update/update-game-cs1.sh $GAME_SERVER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/update/update-game-css.sh $GAME_SERVER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/update/update-game-cs2.sh $GAME_SERVER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/update/update-game-dod.sh $GAME_SERVER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/update/update-game-dods.sh $GAME_SERVER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/update/update-game-fof.sh $GAME_SERVER;   # Fistful of Frags (FoF)

Sample update-all script:

Name: ~/scripts/update/update-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Update all dedicated game servers
#	============================================================================
#	Created:       2024-03-07, by [e-mail]        
#	Last modified: 2024-03-23, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Purpose:
#	
#		Update all dedicated games servers listed below ...
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#	
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
echo "";
date;
echp "Listing running 'screen' sessions, before starting/restarting game-servers ...";
screen -ls;
echo "Invoking each game-server 'update' script ...";
#$SCRIPTS_FOLDER/update/update-gameserverid1.sh;	#	example game server #1
#$SCRIPTS_FOLDER/update/update-gameserverid2.sh;	#	example game server #2
#$SCRIPTS_FOLDER/update/update-gameserverid3.sh;	#	example game server #3
#$SCRIPTS_FOLDER/update/update-gameserverid4.sh;	#	example game server #4
echo "Listing running 'screen' sessions, after starting/restarting game-servers ...";
screen -ls;
date;
#
#	Display end of stuff ...
#
echo "";
echo "[End of script: ${0##*/}]";

13. The "check" scripts

As the names imply, these scripts are intended to check if dedicated game-servers need a new update, and if so:

• Stop that game server - assuming it is running as a disconnected background process.
  
• Update that game server.
  
• Start that game server again - as a disconnected background process.

There are three types of update scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" check scripts used to update multiple game-servers in one command.

There is one script for each type of game to check, as noted in the following table:

Script	Game it checks
~/scripts/check/check-game-hl1.sh	Half-Life (Hl1)
~/scripts/check/check-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/check/check-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/check/check-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/check/check-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/check/check-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/check/check-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/check/check-game-dod.sh	Day of Defeat (DoD)
~/scripts/check/check-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/check/check-game-fof.sh	Fistful of Frags (FoF)

Using the game-type check scripts directly:

• Each game-type check script requires only a single command-line parameter: gameserverid
  
• Each game-type check script will check the game stored in folder with a name matching the gameserverid passed (example: /home/game-servers/gameserverid/).
  
• Each game-type check script has internal variables defined for the particular game / mod installed. This should make it easy to modify for different game types in the future.
  
• Each of those game-type check scripts may be run directly from the command-line, with the required gameserverid parameter.
  
• However, the game-type check scripts exist primarily to be called from the server-specific check scripts (which you will create, based on the example provided).

Creating and using server-specific check scripts:

These scripts will exist, in order to facilitate easily updating the game-servers.

• For each individual game-server that will exist, create a new copy of the sample check-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server check script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server check script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• These additional server-specific scripts are required (i.e. they must exist and be edited appropriately), if you are intending to create a scheduled "cron" job to periodically check for updates automatically.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/check/*.sh;).

Sample server-specific check script:

Name: ~/scripts/check/check-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";     # name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";  # base folder where various related scripts are located.
#
#	Check if the game-server needs and update, and if so, update it ...
#	Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/check/check-game-hl1.sh $GAME_SERVER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/check/check-game-dmc.sh $GAME_SERVER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/check/check-game-tfc.sh $GAME_SERVER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/check/check-game-tf2.sh $GAME_SERVER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/check/check-game-cs1.sh $GAME_SERVER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/check/check-game-css.sh $GAME_SERVER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/check/check-game-cs2.sh $GAME_SERVER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/check/check-game-dod.sh $GAME_SERVER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/check/check-game-dods.sh $GAME_SERVER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/check/check-game-fof.sh $GAME_SERVER;   # Fistful of Frags (FoF)

Sample check-all script:

Name: ~/scripts/check/check-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Check all dedicated game servers for available updates
#	============================================================================
#	Created:       2024-03-08, by [e-mail]        
#	Last modified: 2024-03-23, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Purpose:
#	
#		Check all dedicated games servers listed below ...
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#	
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
echo "";
echo "Invoking each game-servers 'check' script ...";
#$SCRIPTS_FOLDER/check/check-gameserverid1.sh;	#	example game server #1
#$SCRIPTS_FOLDER/check/check-gameserverid2.sh;	#	example game server #2
#$SCRIPTS_FOLDER/check/check-gameserverid3.sh;	#	example game server #3
#$SCRIPTS_FOLDER/check/check-gameserverid4.sh;	#	example game server #4
date;
#
#	Display end of stuff ...
#
echo "";
echo "[End of script: ${0##*/}]";

14. The "backup" scripts

NOTE: Regarding the backup compression utility and format used:

• The reason that the p7zip[p7zip.sourceforge.net] utility is used, instead of other utilities more common on Linux (such as tar[en.wikipedia.org] or pkzip[en.wikipedia.org]) is because of the p7zip[p7zip.sourceforge.net] utility's ability to use text files as both include and exclude lists to build the backup's contents.
  
• Unfortunately, the p7zip[p7zip.sourceforge.net] utility does not allow the include and exclude lists features to be used, when outputting to the .tar.gz or .tar formats. Consequently, the .zip format is used instead.
  
• Athough the p7zip[p7zip.sourceforge.net] utility is used, the file format specified for the backup is the more common ".zip" format - for greater compatibility with other utilities and processes (such as automatic extraction of compressed uploads via the "webmin" file manager, etc.).

As the names imply, these scripts are intended to backup dedicated game-servers easily. There are three types of backup scripts:

• The main backup-stuff.sh script - which uses the p7zip[p7zip.sourceforge.net] utility (a Linux-based equivalent to the famous 7-Zip[www.7-zip.org] utility) to create a compressed backup file.
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" backup scripts used to backup multiple game-servers in one command.

Using the main backup script directly:

• Unlike some of the other scripts, the main backup script (backup-stuff.sh) does not need to know the game-type of the server it is going to backup. It only needs to know the gameserverid to backup.
  
• However, the main backup script requires that both an "include" and "exclude" text file exist for the gameserverid passed. Those two text files will determine exactly which files and folder to include in the backup - as well as what files or folders to explicitly exclude from the backup.
  
• The main backup script (~/backup/backup-stuff.sh) requires only a single command-line parameter: gameserverid
  
• However, the main backup script exists primarily to be called from the server-specific backup scripts (which you will create, based on the example provided).

Creating and using server-specific backup scripts:

These backup scripts will exist, in order to facilitate easily backing-up the game-servers.

• For each individual game-server that will exist, create a new copy of the sample backup-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• For each individual game-server that will exist, create a new copy of the sample backup-gameserverid1-include.txt include file, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• For each individual game-server that will exist, create a new copy of the sample backup-gameserverid1-exclude.txt exclude file, and rename it to match whatever actual gameserverid you are going to use for that server
  
• Edit the new individual game-server backup script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server include file, and add the folders and or files you want to be included in the backup. Typically this is a sub-set of whatever is in the game-server's install folder. Be very careful NOT to include the game-servers entire install folder. This will result in gigantic backups (particularly in the case of CS2) - which may quickly consume all your hosts storage space.
  
• Edit the new individual game-server exclude file, and add the folders and/or files you want to be excluded in the backup. Typically this might include stock content that can be re-installed via SteamCMD - such as the game's pack files (.vpk files), default maps (.bsp files), etc.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/start/*.sh;).

NOTE: It is possible to create an detailed exclude file, based on the contents of a default "stock" installation of the appropriate game-type in some temporary location, and then effectively dumping a file list, and parsing it appropriate for utilization in an exclude list (i.e. with the correct relative path for that game-server, etc.). The next section of this guide includes sample exclude scripts for this purpose. However, you should exercise caution when implementing such a solution. You must fully understand the storage space implications for your host Linux server.

Sample server-specific start script:

Name: ~/scripts/backup/backup-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";     # name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";  # base folder where various related scripts are located.
#
#	Call the standard game-server backup script with
#	the required game-server parameter ...
#
cd $SCRIPTS_FOLDER;
$SCRIPTS_FOLDER/backup/backup-stuff.sh $GAME_SERVER;

Sample server-specific include file:

Name: ~/scripts/backup/backup-gameserverid1-include.sh

gameserverid1/gamesubfolderhere/addons
gameserverid1/gamesubfolderhere/map/custommap1.bsp
gameserverid1/gamesubfolderhere/map/custommap2.bsp
gameserverid1/gamesubfolderhere/map/custommap3.bsp
gameserverid1/gamesubfolderhere/sound/customsound1.wav
gameserverid1/gamesubfolderhere/sound/customsound2.wav
gameserverid1/gamesubfolderhere/sound/custommusic1.mp3
gameserverid1/gamesubfolderhere/sound/custommusic2.mp3
*.cfg
*.txt
*.ini

Sample server-specific exclude file:

Name: ~/scripts/backup/backup-gameserverid1-exclude.sh

vpk
*.vpk
.dem
*.dem
'*.dem'
.log
*.log
'*.log'
log-archive.7z

Sample backup-all script:

Name: ~/scripts/backup/backup-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	7-zip backup of all game-servers
#	============================================================================
#	Created:       2024-03-06, by [e-mail]        
#	Last modified: 2024-03-23, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
#
#	Call the standard backup scripts with
#	the required backupconfig parameter ...
#
$SCRIPTS_FOLDER/backup/backup-scripts.sh;        # backup all the scripts
#$SCRIPTS_FOLDER/backup/backup-gameserverid1.sh; # example game server #1
#$SCRIPTS_FOLDER/backup/backup-gameserverid2.sh; # example game server #2
#$SCRIPTS_FOLDER/backup/backup-gameserverid3.sh; # example game server #3
#$SCRIPTS_FOLDER/backup/backup-gameserverid4.sh; # example game server #4
#
#	Display end of stuff ...
#
echo "[End of script: ${0##*/}]";

15. The "exclude" scripts, 1 of 2

NOTE: The functionality of the exclude scripts has serious implications for storage space consumption on your host Linux server. There are definite "trade-offs" in their usage. Please take the time to understand the implications before attempting to implement them.

Before even considering implementing the exclude scripts, understand how much space a default "stock" installation of your games requires, and how much space each of your game-servers consumes - including all your custom files (maps, sounds, models, textures, mods, plug-ins, etc.),

Trade-Offs:

The up-sides of using the exclude scripts:

• The exclude scripts ensure that most of the "stock" content for a game gets excluded from the resultant backup files.
  
• This ensures that the backup files are focused on backing-up custom content, and not things that can be easily re-installed via SteamCMD.
  
• This results in the backup files being as small as possible.
  
• This allows the include files for each server backup to be much simpler. Generally they may contain just the entire game/mod folder (e.g. gameserverid/valve/, gameserveris/cstrike/, gameserverid/tf/, gameserverid/fof/,etc.)

The down-sides of using the exclude scripts:

• The exclude scripts need to install a full-copy of the "stock" content for a game in a temporary folder.
  
• These temporary stock installs will be located in the ~/tempwork folders. These will have names like stock-hl1, stock-tf2, stock-cs2, stock-fof, etc.
  
• These temporary folders will only be created when the exclude script is run for a game-server that requires that type of game (e.g. won't create a stock-tf2 if you are not generating exclude files for any TF2 servers).
  
• Obviously, these temporary stock installs consume as much space as a real game-server installation would. In some cases (such as Counter-Strike 2) this can consume a significant amount of space.
  
• These temporary "stock" installs can be deleted when not in use. However, doing so will result in the the script having to re-install the "stock" content from scratch the next time - which (depending on the game) could take a significant amount of time, compared to just updating the existing "stock" install.

In summary, although the exclude script process will save you on space for backups, it will cost you on space for the temporary working space.

Consequently, before proceeding to implement the exclude scripts, ensure that you have enough extra storage space to accommodate an extra copy of each type of game-server you will be hosting.

Space Consumption Examples:

Some examples (based upon either current or previous Weasels Lair game-servers) of how small the backup (.zip files) can be - compared the the total installation footprint for the game-server, are included in the table below below for reference:

Example Game-Server	Game Type	Stock Content	Total Size	Backup Size
[WL] Teletubbies Civil War	Half-Life (HL1)	895-MB	1.2-GB	118-MB
[WL] Spirit of Christmas	Half-Life (HL1)	895-MB	1.1-GB	115-MB
[WL] Cartoon-Strike!	Counter-Strike 1.6 (CS1)	895-MB	1.7-GB	244-MB
[WL] Boomer-Strike!	Counter-Strike 1.6 (CS1)	895-MB	1.7-GB	240-MB
[WL] Unfriendly Fire!	Counter-Strike 1.6 (CS1)	895-MB	1.6-GB	239-MB
[WL] Cosplay-Strike!	Counter-Strike:Source (CSS)	2.2-GB	3-GB	293-MB
[WL] Boomer-Strike 2!	Counter-Strike 2 (CS2)	34-GB!	35-GB	223-MB
[WL] Salt-Mine	Team Fortress 2 (TF2)	11-GB	14-GB	894-MB
[WL] Orange	Team Fortress 2 (TF2)	11-GB	13.3-GB	780-MB
[WL] Quad-Faction / 4-Team	Fistful of Frags (FoF)	3.2-GB	3.9-GB	320-MB

16. The "exclude" scripts, 2 of 2

As the names imply, these scripts are intended to generate exclude-list files containing all the "stock" content for the required game-type. There are three types of exclude scripts:

• Scripts associated with each type of game (HL1, CS1, CS2, etc.).
  
• Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
  
• Optionally, one or more "all" exclude scripts used to generate exclude lists for multiple game-servers in one command.

There is one script for each type of game that an exclude-list may be generated for, as noted in the following table:

Script	Game it excludes
~/scripts/exclude/exclude-game-hl1.sh	Half-Life (Hl1)
~/scripts/exclude/exclude-game-dmc.sh	Deathmatch Classic (DMC)
~/scripts/exclude/exclude-game-tfc.sh	Team Fortress Classic (TFC)
~/scripts/exclude/exclude-game-tf2.sh	Team Fortress 2 (TF2)
~/scripts/exclude/exclude-game-cs1.sh	Counter-Strike 1.6 (CS1)
~/scripts/exclude/exclude-game-css.sh	Counter-Strike:Source (CSS)
~/scripts/exclude/exclude-game-cs2.sh	Counter-Strike 2 (CS2)
~/scripts/exclude/exclude-game-dod.sh	Day of Defeat (DoD)
~/scripts/exclude/exclude-game-dods.sh	Day of Defeat:Source (DoDS)
~/scripts/exclude/exclude-game-fof.sh	Fistful of Frags (FoF)

Using the game-type exclude scripts directly:

• Each game-type exclude script requires only a single command-line parameter: gameserverid
  
• Each game-type exclude script will generate an exclude-list for the game stored in folder with a name matching the gameserverid passed (example: /home/game-servers/gameserverid/).
  
• Each game-type exclude script has internal variables defined for the particular game / mod installed. This should make it easy to modify for different game types in the future.
  
• Each of those game-type exclude scripts may be run directly from the command-line, with the required gameserverid parameter.
  
• However, the game-type exclude scripts exist primarily to be called from the server-specific exclude scripts (which you will create, based on the example provided).

Creating and using server-specific exclude scripts:

These scripts will exist, in order to facilitate easily generating exclude-lists for game-server backup purposes.

• For each individual game-server that will exist, create a new copy of the sample exclude-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server exclude script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• Edit the new individual game-server exclude script, un-comment (remove the leading "#") the line that matches the appropriate game-type associated with this game-server.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/stop/*.sh;).

Sample server-specific exclude script:

Name: ~/scripts/exclude/exclude-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";	# name/Id of the game-server to be installed.
SCRIPTS_FOLDER="$HOME/scripts";	# base folder where various related scripts are located.
#
#	Generate the exclusion list ...
#	Un-comment (remove the leading #) the line for the game-type you want.
#
cd $SCRIPTS_FOLDER;
#$SCRIPTS_FOLDER/exclude/exclude-game-hl1.sh $GAME_SERVER;   # Half-Life (HL1)
#$SCRIPTS_FOLDER/exclude/exclude-game-dmc.sh $GAME_SERVER;   # Deathmatch Classic (DMC)
#$SCRIPTS_FOLDER/exclude/exclude-game-tfc.sh $GAME_SERVER;   # Team Fortress Classic (TFC)
#$SCRIPTS_FOLDER/exclude/exclude-game-tf2.sh $GAME_SERVER;   # Team Fortress 2 (TF2)
#$SCRIPTS_FOLDER/exclude/exclude-game-cs1.sh $GAME_SERVER;   # Counter-Strike 1.6 (CS1)
#$SCRIPTS_FOLDER/exclude/exclude-game-css.sh $GAME_SERVER;   # Counter-Strike:Source (CSS)
#$SCRIPTS_FOLDER/exclude/exclude-game-cs2.sh $GAME_SERVER;   # Counter-Strike 2 (CS2)
#$SCRIPTS_FOLDER/exclude/exclude-game-dod.sh $GAME_SERVER;   # Day of Defeat (DoD)
#$SCRIPTS_FOLDER/exclude/exclude-game-dods.sh $GAME_SERVER;  # Day of Defeat:Source (DoDS)
#$SCRIPTS_FOLDER/exclude/exclude-game-fof.sh $GAME_SERVER;   # Fistful of Frags (FoF)

Sample exclude-all script:

Name: ~/scripts/exclude/exclude-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Update backup exclusion files for all game-servers
#	============================================================================
#	Created:       2024-03-07, by [e-mail]        
#	Last modified: 2024-03-29, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
#
#	Call the standard exclude scripts ...
#
#$SCRIPTS_FOLDER/exclude/exclude-gameserverid1.sh;  # example game server #1
#$SCRIPTS_FOLDER/exclude/exclude-gameserverid2.sh;  # example game server #2
#$SCRIPTS_FOLDER/exclude/exclude-gameserverid3.sh;  # example game server #3
#$SCRIPTS_FOLDER/exclude/exclude-gameserverid4.sh;  # example game server #4
#
#	Display end of stuff ...
#
echo "[End of script: ${0##*/}]";

17. The "monitor" scripts

NOTE: One of the conditions that the monitor scripts look for, is "sale" GNU Screen logging. inferring a period of time when there is no console activity. If your game is not running bots, or goes into "hibernate" when there are no players. This might be problematic. To work around this might might need to either of these methods:

• Utilize a cron-like plugin to schedule some console command (such as "status") once a minute - to ensure there is always some console activity. For older games running AMX-Mod-X[www.amxmodx.org], this can be accomplished with the hobo_crontab[forums.alliedmods.net] plug-in. For games running SourceMod[www.sourcemod.net], this can be accomplished with the Cron Job[forums.alliedmods.net] plugin.
  
• Disable the stale-log monitoring function in the monitor-game.sh script, by altering this line:
  

  #DATESERIAL_SECONDS=$(($DATESERIAL_CURRENT-$DATESERIAL_LOG));	# difference (in seconds) between now and last log file change.
  DATESERIAL_SECONDS=0;	# difference (in seconds) between now and last log file change.
  

---

As the names imply, these scripts are intended to monitor dedicated game-servers (running as disconnected / background process using the GNU "Screen" utility) for fatal conditions that require a restart to recover from. Generally, they get invoked either via the related "cron" scripts (recommended), or perhaps directly through a scheduled Linux "cron" job.

NOTE: When setting-up any related Linux "cron" jobs, ensure that they run as the correct non-root / non-sudo user (presumably "game-servers").

There are three types of monitor scripts:

1. The main monitor-game.sh script - which does all the work of looking-for various fatal conditions - including "segmentation fault", "fatal error" or stale-screen-console-logging. Only game-servers running as a disconnected background process, will be checked. Any game-servers running interactive/directly outside of a "screen" session (e.g. not started by the related start scripts) will be ignored.
   
2. Scripts for each individual game-server instance you are going to host - which you will need to create, based on the example provided.
   
3. Optionally, one or more "all" monitor scripts used to monitor multiple game-servers in one command.

Using the main monitor script directly:

• Unlike some of the other scripts, the main monitor script (monitor-game.sh) does not need to know the game-type of the server it is going to monitor. It only needs to know the gameserverid to monitor. It will automatically call the appropriate server-specific start script for the gameserverid specified, if a fatal condition is detected.
  
• The main monitor script (~/monitor/monitor-game.sh) requires only a single command-line parameter: gameserverid
  
• However, the main monitor script exists primarily to be called from the server-specific monitor scripts (which you will create, based on the example provided).

Creating and using server-specific monitor scripts:

These monitor scripts will exist, in order to facilitate easily monitoring the game-servers. These scripts maybe be called from other scripts which depend upon them - such as the monitor-all.sh script.

• For each individual game-server that will exist, create a new copy of the sample monitor-gameserverid1.sh script, and rename it to match whatever actual gameserverid you are going to use for that server.
  
• Edit the new individual game-server monitor script, and alter the "GAME_SERVER" value to match the actual gameserverid for that game-server.
  
• These additional server-specific monitor scripts are required (i.e. they must exist and be edited appropriately), if you are intending to use the related cron scripts.
  
• Obviously, remember to mark any new server-specific scripts as "executable" (example: chmod +x ~/scripts/monitor/*.sh;).

Sample server-specific monitor script:

Name: ~/scripts/monitor/monitor-gameserverid1.sh

#!/bin/bash
#
#	Define some variables ...
#
GAME_SERVER="gameserverid1";		# name/Id of the game-server to be monitored.
SCRIPTS_FOLDER="$HOME/scripts";		# base folder where various related scripts are located.
#
#	Install/update the server ...
#
cd $SCRIPTS_FOLDER;
$SCRIPTS_FOLDER/monitor/monitor-game.sh $GAME_SERVER;

Sample monitor-all script:

Name: ~/scripts/monitor/monitor-all-example.sh

#!/bin/bash
#
#	----------------------------------------------------------------------------
#	Check monitor game-servers screen sessions for fatal conditions
#	============================================================================
#	Created:       2024-04-06, by [e-mail]        
#	Last modified: 2024-04-12, by [e-mail]
#	----------------------------------------------------------------------------
#
#	Purpose:
#	
#		Monitor all dedicated games servers listed below ...
#
#	Define some variables ...
#
SCRIPTS_FOLDER="$HOME/scripts";
#	
#	Display start of stuff ...
#
echo "[Start of script: ${0##*/}]";
echo "";
echo "Invoking each game-servers 'monitor' script ...";
#$SCRIPTS_FOLDER/monitor/monitor-gameserverid1.sh;	#	example game server #1
#$SCRIPTS_FOLDER/monitor/monitor-gameserverid2.sh;	#	example game server #2
#$SCRIPTS_FOLDER/monitor/monitor-gameserverid3.sh;	#	example game server #3
#$SCRIPTS_FOLDER/monitor/monitor-gameserverid4.sh;	#	example game server #4
date;
#
#	Display end of stuff ...
#
echo "";
echo "[End of script: ${0##*/}]";

18. The "cron" scripts

NOTE: When setting-up any related Linux cron[en.wikipedia.org] jobs, ensure that they run as the correct non-root / non-sudo user (presumably "game-servers").

---

What to run regularly:

As you have probably noticed, some of the scripts are not particularly useful if you need to invoke them manually yourself. Instead they are more useful invoked on an automated basis. These include:

• The "backup" scripts. Obviously, backups are something that should just happen on a regular basis - so that you do not have to remember to run them. Although it is also handy to be able to run them manually as well - in particular before making configuration changes.
  
• The "check" scripts. Since their purpose is to automatically detect new updates and get them applied to your server(s) as quickly as possible.
  
• The "monitor" scripts. Their entire purpose is to detect that your server(s) need a restart, so doing so as quickly as possible is desirable.

How to run stuff regularly:

On Linux systems, scheduled tasks are usually initiated by the Linux cron[en.wikipedia.org] system. However, rather than scheduling any of the other scripts directly with cron[en.wikipedia.org], I recommend instead creating scripts specifically to be scheduled in cron[en.wikipedia.org] - which will then invoke the scripts (or perform any other desired maintenance tasks). To this end, I have created some sample "cron" scripts for that purpose.

My approach is to create one script for each of the four different typical schedules they would normally be associated with:

• The Weekly script (~/scripts/cron/games-weekly.sh). As the name implies, I run this script once a week, at the time and day of the week when the player-count is lowest. I typically use this script to schedule the longest running scripts (~/scripts/backup/backup-all.sh and ~/scripts/exclude/exclude-all.sh) and perform some other maintenance - such as clearing-out the logs folder (~/home/logs/). Example scheduling details for the Weekly task might be:
  

  Description: Game-Server Maintenance: WEEKLY
  User: game-servers
  Day(s) of the week: Mondays
  Time(s) of the day: 3:00 AM
  Script to run: ~/scripts/cron/games-weekly.sh
  

• The Daily script (~/scripts/cron/games-daily.sh). Similarly, this would be any tasks that should run once every day (except the day the Weekly job runs), generally at that same low-point of player-count. This might be used to run additional backups, and perhaps do pre-emptive server restarts (~/scripts/start/start-all.sh), etc. Example scheduling details for the Dailly task might be:
  

  Description: Game-Server Maintenance: DAILY
  User: game-servers
  Day(s) of the week: Tuesdays, Wednesdays, Thursdays, Fridays, Saturdays, Sundays
  Time(s) of the day: 3:00 AM
  Script to run: ~/scripts/cron/games-daily.sh
  

• The Hourly script (~/scripts/cron/games-hourly.sh). This is scheduled to run every hour (except when Weekly or Daily scripts are scheduled). Typically, this will run Check scripts for updates (~/scripts/check/check-all.sh), and possibly run the Monitor scripts (~/scripts/monitor/monitor-all.sh) - although, at this point I run the Monitor scripts more often - in the Often script instead of just hourly. Example scheduling details for the Hourly task might be:
  

  Description: Game-Server Maintenance: HOURLY
  User: game-servers
  Day(s) of the week: Every Day
  Time(s) of the day: Every hour from 5 AM until 2 AM (leaving 3AM to 5AM unconflicted).
  Minutes of each hour:  :00 = the top of the hour.
  Script to run: ~/scripts/cron/games-hourly.sh
  

• The Often script (~/scripts/cron/games-often.sh). This script is typically schedule to run several times every hour - typically every 15 minutes - being careful not to overlap with the times the Hourly script runs (i.e. at the top of every hour). Example scheduling details for the Often task might be:
  

  Description: Game-Server Maintenance: OFTEN
  User: game-servers
  Day(s) of the week: Every Day
  Time(s) of the day: Every hour from 5 AM until 2 AM (leaving 3AM to 5AM unconflicted).
  Minutes of each hour:  :05, :20, :35, & :50
  Script to run: ~/scripts/cron/games-often.sh
  

19. Example VPS, 1 of 3

I have created (and made available on the Internet for download) a sample virtual machine that may be used a sample virtual private server (VPS), for either of these two (2) common virtualization systems:

• VirtualBox[www.virtualbox.org]
  
• VMWare Player[en.wikipedia.org]

Both of those virtualization systems are free (at least for non-commercial use), and available for multiple operating systems - generally Windows, MacOS and Linux.

This guide assumes you already have either VirtualBox[www.virtualbox.org] or VMWare Player[en.wikipedia.org] installed, and know how to use it - how to create virtual machines, where the default file locations for virtual machines are located, etc.

NOTE: It may be possible to port this sample VM from VirtualBox[www.virtualbox.org] and/or VMWare Player[en.wikipedia.org] to other virtualization platforms (such Hyper-V[en.wikipedia.org], or KVM[en.wikipedia.org]). However, doing so is beyond the scope of this guide.

---

Downloading the VPS:

The size of the VPS image (compressed with 7-zip[www.7-zip.org]) is approximately 43-GB. Both the VirtualBox[www.virtualbox.org] and VMWare Player[en.wikipedia.org] drive images are available in my public DropBox, here:

https://www.dropbox.com/sh/26x2qoxt9koynxv/AAB59xue-IEnIeJ9Of6imlqMa?dl=0

In that same DropBox folder, are also .torrent files for each of the 7-zipped virtual machine images. These may be used to download them via most "BitTorrent" clients (such as qBittorrent[www.qbittorrent.org]).

Unfortunately, the Steam Community system, does not provide a good mechanism to posting either .torrent files or "Magnet URI's". So, you will have to visit the DropBox folder, to access the "BitTorrent" download method - rather than using such features more directly.

NOTE: Be sure to download the latest available version for either virtualization system.

---

Purpose of the VPS:

I created this example VPS primarily as a learning tool. However, I suppose it could also be used to host LAN-games locally at your residence or office. It is really not intended for hosting games on the Internet. Doing that would involve additional issues, such as:

• Potential asynchronous Internet bandwidth issues. This refers to your Internet connection having a much bigger download speed, compared to upload speed. This is particularly common for residential or small-business Internet connections using cable-modems[en.wikipedia.org], DSL[en.wikipedia.org] or wireless broadband[en.wikipedia.org] connections. To host game-servers that are reasonably playable from others on the Internet, you really need good upload speed - basically matching your download speed. Otherwise, while the game may play fine for you locally, for others on the Internet it will lag too painfully to be playable.
  
• Network port-forwarding / firewall issues. This refers to your Internet connection's router/firewall feature not (by default) allowing inbound traffic for various types of servers. In the local router / firewall that connects your at home/small-office to the Internet (which might be yours, or rented from your Internet Service Provider) you will need to allow whatever "ports" are being used for your game-servers (typically 27000-27999), and ensure they are "forwarded" to the inside IP address of the VPS.

It is beyond the scope of this guide to cover either of those issues.

---

Specifications of the VPS:

The example VPS is built with just enough storage space and memory to be able to have several game-servers installed, but only one (1) or maybe two (2) running at any given time.

The specifications for the virtual machine, are as follows:

Specification	Details
Platform	VMWare Workstation Player ( Link [www.vmware.com] )
Processor	2x Virtual CPU
Network Interface	"Bridged" to host computer
Memory	4-GB
Storage	128-GB size drive. About ~ 43-GB compressed (with 7-zip) for download.

---

Features of the VPS:

The features of this sample VPS include:

Feature	Details
Base Operating System	Debian Edition 12 (no GUI) ( Link [www.debian.org] )
Linux-native Steam-based game-server installer	SteamCMD utility ( Link )
Management Scripts	Weasel's Dedicated-Server Management Scripts ( Link )
Linux management interface	Webmin ( Link [Webmin.com] ) A number of Webmin "Custom Commands" setup to start/stop example servers. NOTE : Webmin is setup running on port 8443 ( not the default of 10000)
Linux BitTorrent daemon	Transmission Daemon, with its web-interface running on its default port of 9091 . Not really related to game-server hosting - just for fun.
Default privileged user:	Username: root Password: n0t.Password! NOTE : Recommended to change this password immediately .
Default un privileged user:	Username: game-servers Password: n0t.Password! NOTE : Recommended to change this password immediately . [/tr][/table]

20. Example VPS, 2 of 3

---

Logging into the VPS:

After you get the virtual machine downloaded, extracted, placed into the proper folder, and added to VMware Workstation Player (or VMWare Workstation Pro), you can log into it's "console" directly in VMware as either of these two example Linux users:

User	Password	Description
root	n0t.Password!	System administrative user, for installing/updating packages, etc. Do NOT use for game-servers!
game-servers	n0t.Password!	All example game-servers and related management scripts should be run under this user.

Both of those users should also be able to login with SSH and through the Webmin interface in a web-browser on your host computer. To find the IP address of the virtual machine, login to it's console as "root", and use this command:

ifconfig

It should display some output like this:

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Mar 26 09:31:37 2024
root@ExampleVPS-2024b:~# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.187.132  netmask 255.255.255.0  broadcast 192.168.187.255
        inet6 fe80::20c:29ff:fe54:f843  prefixlen 64  scopeid 0x20<link>
        ether 00:0c:29:54:f8:43  txqueuelen 1000  (Ethernet)
       {more crap here}
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
       {more crap here}

Note this line in the output:

inet 192.168.187.132  netmask 255.255.255.0  broadcast 192.168.187.255

In that case, the local IP address of your virtual machine would be:

192.168.187.132

In VMware, that process will look something like this:

---

Sample Dedicated Servers:

The updated VPS implements one sample game-server for each of the ten (10) game-types that the management scripts directly support.

Although the VPS has example servers for all of the ten (10) game-types supported, it does not have sufficient memory to have more than one (1) or maybe two (2) actually running at the same time.

The gameserverid and portnumber assigned to each sample is listed in the table below:

GameServerID	Network Port	Game
server 0 hl1	27101	Half-Life
server 1 dmc	27103	Deathmatch Classic
server 2 tfc	27105	Team Fortress Classic
server 3 tf2	27107	Team Fortress 2
server 4 cs1	27109	Counter-Strike 1.6
server 5 css	27111	Counter-Strike:Source
server 6 cs2	27113	Counter-Strike 2
server 7 dod	27115	Day of Defeat
server 8 dods	27117	Day of Defeat:Source
server 9 fof	27119	Fistful of Frags

---

Accessing the "Webmin" Interface:

Once you know your virtual machine's IP address, you may login to the Webmin[webmin.com] web-based Linux management interface using a web-browser (such as Chrome) on your host PC.

The format of the URL to access Webmin[webmin.com] for your VPS will be like this:

https://{ipaddresshere}:8443

For example if the IP address of your VPS is 192.168.187.132, then the URL would be:

https://192.168.187.132:8443

The web-browser will likely warn that the web-site is "insecure". This is expected behaviour. You may need to proceed to the web-site ignoring that message.

When prompted, login as the game-server account and it's associated password.

That process, should look something like this:

---

Using the Webmin "Custom Commands" module:

Inside the Webmin[webmin.com] web-interface, there is a module called "Custom Commands". I have populated this module with several options to invoke the sample scripts directly from within Webmin[webmin.com]. This includes options such as (but not limited to):

• Listing any running game-servers.
  
• Starting game-servers.
  
• Stopping game-servers.
  
• Running backups game-servers.
  
• Checking for updates to the game-servers.
  
• Editing various important files or sample scripts.

These "Custom Commands" are really intended to be utilized logged-into Webmin as the game-servers account, and really should not be used while logged-into Webmin as root.

The "Custom Commands" module should look something like this:

---

Shutting-down the VPS:

To gracefully shut-down the VPS, you should:

• Be sure to stop any game server(s) you previously had running.
  
• Log-out of Webmin[webmin.com].
  
• Log-out of any SSH sessions.
  
• Go to the VMware console for the virtual machine.
  
• Login to the console as root.
  
• Use this command to shut-down the virtual machine:
  

  shutdown -h now;

• VMware Player will likely close automatically once the VM is successfully shut-down.

The shut-down process, will look something like this:

21. Example VPS, 3 of 3

As noted previously, this example VPS is primarily intended as a learning tool. However, if you are going to have it turned-on for an extended period of time (perhaps to host a LAN-game), you should consider some additional actions to prevent it being exploited either from other computers on the same local network, or from the Internet.

---

Changing the default passwords:

The most important basic change should be changing the default passwords for both the root and game-servers Linux logins.

This can be accomplished by

• Logging in as root to the console in VMware (or SSH), and then using the passwd[man7.org] command to change the password for root,
  
• Logging in as game-servers to the console in VMware (or SSH), and then using the passwd[man7.org] command to change the password for game-servers.

---

Host-based firewall:

Please note also that the example VPS does already have a rudimentary host-based firewall feature enabled - called IP Tables[en.wikipedia.org]. Some basic rules have been setup - which can be viewed in Webmin while logged-in as root.

This existing host-based firewall implementation does already include these restrictions:

• The SSH server (on TCP port 22) may only be accessed from local networks.
  
• The "Webmin" interface (on TCP port 8443) may only be accessed from local networks.
  
• The "transmission" web-interface (on TCP port 9091) may only be accessed from local networks.
  
• Game-servers must be assigned ports in the 27000-27999 port-range.

NOTE: Although the current IP Tables[en.wikipedia.org] setup is configured to permit game-servers operating in the 27000-27999 port-range - each of the existing example game-servers already configured, are assigned ports from a smaller subset range of 27100-27199 range. This is intended to keep any ports used by the example game- servers from interfering with local game-clients on the same network.

22. (TBD)

{work-in-progress}

[evo]

thanks, that helped me out

[анархист]

thx