Friday, September 24, 2010

Doom server management 101

After having spent a considerable amount of time running servers of my own, I have happened upon a process for putting Doom servers up that I would like to share with any who care to listen. This allows me to get servers up and running rather quickly, without having to fiddle around with a directory full of shell scripts or whatever else most server owners use. I will give everything to you on a silver platter at the end of this post, but I think it's important to comprehend the fundamentals behind my organization first, otherwise it will make no sense to you.

1. Split your configuration up


How many times have you wanted to start a generic Deathmatch server, or a generic TDM server, or a generic CTF server, and simply copied the config file from another server? Now, assume that a new version of your port of choice comes out and suddenly, there is a neat new flag or feature that you want to enable on every single server. Or lets say that after some experimentation your players demand a change to a gametype (for example, changing the fraglimit on your TDM servers). You could go back through every single one of your config files and add those configuration pieces to every single file, hoping you don't skip one. Or you could harness the power of exec.

exec is a simple command that executes another config file, and is usually used at the end of a server startup string. However, it's just as usable inside of a configuration file. To wit:

doom2-coop.cfg


// Execute base Team Deathmatch params
exec "/opt/skulltag/cfg/coop.cfg"
sv_hostname "[MS] My Servers || Doom 2 Cooperative"

Just keep all your TDM configuration inside of tdm.cfg, and you're golden.

2. Abuse the "working directory"


Now you're probably wondering. "That's awesome. However, what if I move my configuration files? Then they'll all break again!" Yep, absolute paths will do that do you. However, before you embark on using relative paths, you need to know something that will catch you off guard. If you specify a path in a config file and it references something other than an absolute path (i.e. one with a C:\ or / at the beginning), it will attempt to use a path relative to the location that the program was started. This is not necessarily the same thing as the directory the server binary is located in either, as you can run programs from any directory. For example:

$ cd /opt/skulltag
$ ./bin/98c/skulltag-server +exec "cfg/doom2-coop.cfg"


This will load /opt/skulltag/cfg/coop.cfg, not /opt/skulltag/bin/98c/cfg/coop.cfg, all because you started it from /opt/skulltag.

Neat-o, right? However, this doesn't just work for configuration files. It works for anything that uses a path. Observe:

$ cd /opt/skulltag
$ ./bin/98c/skulltag-server -iwad "wad/doom2.wad" +sv_banfile "list/banlist.txt" +exec "cfg/doom2-coop.cfg"


Now you're cooking with gas. Your server binaries are separated from your wad files, which are separated from your banlists, which are separated from your config files.

Putting it all together


Here is a sample skeleton config file that I use for my own servers. I put this in /opt/skulltag/cfg/skeleton.cfg and whenever I need a new server I simply copy the config file and then +exec it from the command line.

cfg/skeleton.cfg


// SKULLTAG SERVER CONFIGURATION FILE
// by AlexMax

// INCLUDE FILES
// Do not remove any of these commands.
exec "cfg/include/reset.cfg"
exec "cfg/include/global.cfg"
exec "cfg/include/alias.cfg"

// GAMEPLAY INCLUDES
// Uncomment one of the following commands to select which flavor of doom
// gameplay you wish to use.
//exec "cfg/include/os.cfg" // Oldschool settings (-deathmatch)
//exec "cfg/include/os-altdeath.cfg" // Oldschool settings (-altdeath)
//exec "cfg/include/ns.cfg" // Newschool settings
//exec "cfg/include/st.cfg" // Skulltag settings

// GAMETYPE INCLUDES
// Uncomment one of the following commands to determine which gametype you
// wish to play.
//exec "cfg/include/duel.cfg"
//exec "cfg/include/dm.cfg"

// ADDITIONAL SETTINGS
// If there is a setting that is either not covered by the above includes or
// is a setting you wish to overide, you should place such settings here.
// Please read the Skulltag Wiki for a full list of possible server settings.

// MAP ROTATION
clearmaplist

// Shuffle Maplist. If set, maps will be picked randomly from the available
// added maps.
sv_randommaprotation false

// Add any maps that you would like to be included in the map rotation
// to the section below.
// -- START MAPLIST --
addmap map01
addmap map02

addmap map03
addmap map04

addmap map05
// -- END MAPLIST --

// Set the map that you want to be loaded when the server starts here.
map map01

cfg/include/reset.cfg


// RESET CONFIGURATION FILE
// by AlexMax

// There should never be a reason to edit this file. This merely sets up sane
// defaults so your configuration doesn't keep any residual cvars from other
// servers.

crashlogs 2
crashlog_dir "crashlogs/"
duellimit 0
fraglimit 0
pointlimit 0
timelimit 0
winlimit 0

sv_adminlistfile "list/adminlist.txt"
sv_banexemptionfile "list/whitelist.txt"
sv_banfile "list/banlist.txt"
sv_banfilereparsetime 60
sv_broadcast false
sv_colorstripmethod 1
sv_defaultdmflags false
sv_disallowbots true
sv_enforcemasterbanlist true
sv_enforcebans true
sv_forcepassword false
sv_forcejoinpassword false
sv_joinpassword ""
sv_logfile_append true
sv_logfilenametimestamp false
sv_logfiletimestamp true
sv_logfiletimestamp_usedate true
sv_maprotation true
sv_markchatlines true
sv_minvoters 1
sv_password ""
sv_pure true
sv_timestamp true
sv_timestampformat 0
sv_updatemaster true

cfg/include/global.cfg


// GLOBAL CONFIGURATION FILE
// by AlexMax

// Put your configuration changes that you want to see across all servers
// in this file. You should keep this file hidden, for obvious reasons.

// Server title. This is used anytime you forget to set the hostname from
// the command line or another config file. I suggest using your server name,
// followed by "Skulltag Server" or something equally vague.
set sv_hostname "My Skulltag Server Farm || Skulltag Server"

// Host e-mail. If you want your users to be able to contact you via e-mail,
// put it here. Anybody who queries the server in a server browser can see
// this e-mail, so make sure it is an e-mail address that you don't mind
// being public-facing and unobfuscated.
sv_hostemail "user@example.com"

// Message of the day. This message will display to your users when they join
// your servers. Line breaks can be used here by using \n.
sv_motd "Welcome to Skulltag!\n\nHave fun!"

// RCON password. This is used to obtain access to the Skulltag server
// console while you're playing on the server as a client or through an
// RCON utility.
sv_rconpassword "changeme"

// Server website. If your server has any custom WAD files and you wish for
// them to be downloaded by server browsers such as Odalauncher, IDE or
// Doomseeker when connecting to your server, put the URL where the files can
// be located here.
sv_website "http://www.example.com/"


Take a good look at these config files so you can tell where files belong and what other config files you need to populate yourself, such as cfg/include/os.cfg and cfg/include/duel.cfg.

Finally, you need to start the server. I don't actually use shell scripts, but here's a sample one that ought to work, just substitute in your server parameters, and put it in the "root" directory of your skulltag installation.

Sample shell script


#/bin/sh
cd /opt/skulltag
./bin/98c/skulltag-server -iwad wads/doom2.wad -file wad/WADNAME.WAD -useip YOURIP -port PORT +sv_hostname "YOUR SERVER NAME" +exec cfg/CONFIG.CFG +logfile log/LOGFILE.LOG

1 comment:

  1. Above the review is very helpful to install Doom server in my system.I get it clear idea about your topic.Above all the points are explained very clearly.web hosting companies

    ReplyDelete