• Install MetaMod and SourceMod
  
  • Install MetaMod: Source
  • Install SourceMod
• Autostart game servers
• Logs
  
  • Cron logs
  • Steam client logs
  • Web server logs
  • Log SourceMod
  • Game server logs
  • Log server statistics
• Binding to Steam and QuickPlay
  
  • Server account
  • Quickplay

Install MetaMod and SourceMod

It is time to bring a fresh stream into the process of setting up the coexistence of our servers, namely, add MetaMod and SourceMod.

Install MetaMod: Source

First, install the MetaMod: Source plugin, which does not add any game functions, but only provides the interface between the Source engine, the game and other plugins.

Homepage - http://www.metamodsource.net/

Download the latest version and unpack the archive.

$ wget http://cdn.probablyaserver.com/sourcemod/mmsource-1.10.6-linux.tar.gz $ tar -xvzf mmsource-1.10.6-linux.tar.gz -C ~/tf2/tf 

In the ~ / tf2 / tf directory, the addons subdirectory will be created (we will install other mods in it), and the metamod directory with a number of files for various Source games, including Team Fortress 2, will be created in it:

  addons/ addons/metamod.vdf ... addons/metamod/bin/metamod.2.tf2.so addons/metamod/bin/server.so ... addons/metamod/metaplugins.ini 

The srcds game server at startup checks the presence of the ~ / tf2 / tf / addons directory, searches for * .vdf files in it, in which the paths to the plug-in libraries should be specified in the "file" parameter. In our case, just in this file ~ / tf2 / tf / addons / metamod.vdf the MetaMod plugin is connected: Source as "addons / metamod / bin / server" (the path is indicated relative to ~ / tf2 / tf /).

Now we will install SourceMod and connect it to MetaMod.

Install SourceMod

Homepage - http://www.sourcemod.net/

Go to http://www.sourcemod.net/downloads.php?branch=stable , download the latest version for Linux and unpack the archive

  $ wget https://sm.alliedmods.net/smdrop/1.8/sourcemod-1.8.0-git5947-linux.tar.gz $ tar -xvzf sourcemod-1.8.0-git5947-linux.tar.gz -C ~/tf2/tf 

The sourcemod directory appeared in ~ / tf2 / tf / addons, the sourcemod directory in ~ / tf2 / tf / cfg /, and in
~ / tf2 / tf / addons / metamod - sourcemod.vdf file.

  addons/metamod/sourcemod.vdf addons/sourcemod/ addons/sourcemod/scripting/ addons/sourcemod/configs/core.cfg ... cfg/sourcemod/sm_warmode_off.cfg cfg/sourcemod/sm_warmode_on.cfg cfg/sourcemod/sourcemod.cfg 

Since a single SourceMod installation cannot simultaneously serve several servers, we need to expand by the number of servers. In the addons directory, we rename sourcemod to sourcemod1 and copy it with all content to sourcemod2, having first run dos2unix for the configuration files for convenience:

  $ mv ~/tf2/tf/addons/sourcemod ~/tf2/tf/addons/sourcemod1 $ cd ~/tf2/tf/addons/sourcemod1/configs $ dos2unix *.cfg *.ini *.txt $ cp -r ~/tf2/tf/addons/sourcemod1 ~/tf2/tf/addons/sourcemod2 

MetaMod finds and connects SourceMod thanks to the file addons / metamod / sourcemod.vdf. But this file is one, and we need two different ones for each server. MetaMod has a parameter pointing to the directory (not the file!) With the configuration, so we will create two directories cfg1 and cfg2 and put sourcemod.vdf there, which we will edit.

  $ mkdir ~/tf2/tf/addons/metamod/cfg{1,2} $ dos2unix ~/tf2/tf/addons/metamod/sourcemod.vdf $ mv ~/tf2/tf/addons/metamod/sourcemod.vdf ~/tf2/tf/addons/metamod/cfg1/sourcemod.vdf $ cp ~/tf2/tf/addons/metamod/cfg1/sourcemod.vdf ~/tf2/tf/addons/metamod/cfg2/sourcemod.vdf 

We edit these files, correcting the paths to the SourceMod installations (also relative to ~ / tf2 / tf):

~ / tf2 / tf / addons / metamod / cfg1 / sourcemod.vdf:

 "Metamod Plugin" { "alias" "sourcemod" "file" "addons/sourcemod1/bin/sourcemod_mm" } 

~ / tf2 / tf / addons / metamod / cfg2 / sourcemod.vdf (fix 1 -> 2):

 "Metamod Plugin" { "alias" "sourcemod" "file" "addons/sourcemod2/bin/sourcemod_mm" } 

For convenience, we make symbolic links to directories with settings and logs:

  $ ln -s ~/tf2/tf/addons/metamod/cfg1 ~/cfg/mm1 $ ln -s ~/tf2/tf/addons/metamod/cfg2 ~/cfg/mm2 $ ln -s ~/tf2/tf/addons/sourcemod1/configs ~/cfg/sm1 $ ln -s ~/tf2/tf/addons/sourcemod2/configs ~/cfg/sm2 $ ln -s ~/tf2/tf/addons/sourcemod1/logs ~/log/sm1 $ ln -s ~/tf2/tf/addons/sourcemod2/logs ~/log/sm2 

You do not need to register any separate commands to start MetaMod - the game server will launch it automatically, but we need to specify various directories to download SourceMod.

In the file ~ / cfg / autoexec1.cfg for the first server we append to the end:

 //... // Load SourceMod instance No 1 mm_basedir addons/metamod/cfg1 

For the second server in ~ / cfg / autoexec2.cfg it is the same, only instead of "cfg1" -> "cfg2":

 //... // Load SourceMod instance No 2 mm_basedir addons/metamod/cfg2 

Now MetaMod knows where to download SourceMod, but the latter does not know where to get its settings from. Let's write the paths for each SourceMod. Unlike MetaMod, the parameters we have to specify as much in the command line to start the server. Neither in autoexec.cfg, nor in server.cfg they work.

In the start1.sh and start2.sh start scripts, in the CMDLINE we add:

 CMDLINE="... +sm_basepath addons/sourcemod1 +sm_corecfgfile addons/sourcemod1/configs/core.cfg \ ... 

This is for the first server. For the second server it is similar, only instead of "sourcemod1" -> "sourcemod2":

 CMDLINE="... +sm_basepath addons/sourcemod2 +sm_corecfgfile addons/sourcemod2/configs/core.cfg \ ... 

The sm_corecfgfile parameter is required, since the path to core.cfg is not taken from the sm_basepath, which would be logical to assume.

To check, you can start the first game server and when it starts up completely, enter it in its console (commands are marked with angle brackets):

  >>> meta version Metamod:Source version 1.10.6 Built from: https://github.com/alliedmodders/metamod-source/commit/9fed12f Build ID: 946:9fed12f Loaded As: Valve Server Plugin Compiled on: Sep 12 2015 Plugin interface version: 15:14 SourceHook version: 5:5 http://www.metamodsource.net/ >>> mm_basedir "mm_basedir" = "addons/metamod/cfg1" ( def. "addons/metamod" ) singleplayer - Metamod:Source Base Folder >>> meta list Listing 4 plugins: [01] SourceMod (1.8.0.5907) by AlliedModders LLC [02] TF2 Tools (1.8.0.5907) by AlliedModders LLC [03] SDK Hooks (1.8.0.5907) by AlliedModders LLC [04] SDK Tools (1.8.0.5907) by AlliedModders LLC >>> meta info 1 Plugin 1 is running. Name: "SourceMod" by AlliedModders LLC Version: 1.8.0.5907 Description: Extensible administration and scripting system License: See LICENSE.txt URL: http://www.sourcemod.net/ Details: API 015, Date: Apr 26 2016 File: /home/game/tf2/tf/addons/sourcemod1/bin/sourcemod_mm_i486.so >>> sm_basepath "sm_basepath" = "addons/sourcemod1" ( def. "addons/sourcemod" ) - SourceMod base path (set via command line) >>> sm_corecfgfile "sm_corecfgfile" = "addons/sourcemod1/configs/core.cfg" ( def. "addons/sourcemod/configs/core.cfg" ) - SourceMod core configuration file >>> sm plugins list [SM] Listing 17 plugins: 01 "Admin Menu" (1.8.0.5907) by AlliedModders LLC ... 17 "Player Commands" (1.8.0.5907) by AlliedModders LLC >>> sm exts list [SM] Displaying 9 extensions: [01] Automatic Updater (1.8.0.5907): Updates SourceMod gamedata files ... [09] SQLite (1.8.0.5907): SQLite Driver 

Well, all the paths to directories and files are correct, seventeen standard plug-ins and nine extensions are running. Later we will analyze who does what, but for now we will continue.

If, on entering commands, errors of the following type are issued:

  >>> meta list Listing 1 plugin: [01] <FAILED> >>> sm_basepath Unknown command "sm_basepath" 

That means MetaMod could not download SourceMod. We must look for what is the matter.

List of MetaMod console commands: Source - Console Commands (SourceMM)

Extensions are located in the ~ / tf2 / tf / addons / sourcemod {1,2} / extensions directory - for all supported games on the Source engine, not just TF2.

Compiled plugins are located in the ~ / tf2 / tf / addons / sourcemod {1,2} / plugins directory. If you want to disable any plugin, then you can simply move it to the disabled subdirectory. The source code for the plugins is in the ~ / tf2 / tf / addons / sourcemod {1,2} / scripting directory. There is also a compiler and compile.sh script that compiles the sources and places the compiled plugins in the compiled subdirectory, from where they can be transferred to ~ / tf2 / tf / addons / sourcemod {1.2} / plugins - and they will be available for use by SourceMod.

You can now configure SourceMod for each server by editing the core.cfg files in ~ / tf2 / tf / addons / sourcemod {1,2} / configs. In our case, we are satisfied with the default settings. Please note that with this option "DisableAutoUpdate No" the auto update of the SourceMod game data in the ~ / tf2 / tf / addons / sourcemod {1,2} / gamedata directories is enabled.

It is also possible to set the "LogMode" parameter in the core.cfg of the "game" value - then the logs will not be written to separate files, but to the logs of the game server. Read more in the section "Logs"

Other configuration files will be analyzed later.

However, there is another configuration file - ~ / tf2 / tf / cfg / sourcemod / sourcemod.cfg - it runs every time the cards follow the server.cfg and is common to all SourceMod installations. Therefore, we leave in sourcemod.cfg only commands common to both servers, and the individual ones are transferred into separate files for each server.

  $ dos2unix ~/tf2/tf/cfg/sourcemod/sourcemod.cfg $ cp ~/tf2/tf/cfg/sourcemod/sourcemod.cfg ~/cfg/sourcemod_default.cfg $ ln -s ~/tf2/tf/cfg/sourcemod ~/cfg/sm 

We edit ~ / tf2 / tf / cfg / sourcemod / sourcemod.cfg, we traditionally add the output "echo", fix the "sm_show_activity" and set the usual date / time format in "sm_datetime_format".

 echo "*** ~/tf2/tf/cfg/sourcemod/sourcemod.cfg" // SourceMod Configuration File // This file is automatically executed by SourceMod every mapchange. // Specifies how admin activity should be relayed to users. sm_show_activity 28 // Default datetime formatting rules when displaying to clients. sm_datetime_format "%d %b %Y - %H:%M:%S" 

Everything. The rest is deleted. Later, when you want to set your own parameters for servers, you can take them from the saved ~ / cfg / sourcemod_default.cfg and specify them in some server configuration file. Why you can not leave everything as it is - in the original sourcemod.cfg? And because it is executed every time there is a change of cards following server {1,2} .cfg - that is, any settings, for example, regarding backup slots, specified in server {1,2} .cfg will be overwritten by default values ​​from this file. And we will configure the same backup slots for our servers in different ways.

When installing SourceMod plug-ins, their configuration files can be automatically created in ~ / tf2 / tf / cfg / sourcemod / and become common to both SourceMod installations. Actually, there is already a file with settings for the plugin funcommands.smx

Also SourceMod by default periodically downloads from its server (update.sourcemod.net) updates of files with game data, which will be reflected in the logs. Using the example of the first server (~ / tf2 / tf / addons / sourcemod1 / logs /), lines 3,4,5:

  L 03/21/2014 - 14:52:41: SourceMod log file session started (file "L20140321.log") (Version "1.5.3") L 03/21/2014 - 14:52:41: -------- Mapchange to cp_well -------- L 03/21/2014 - 14:52:56: [UPDATER] Successfully updated gamedata file "sdkhooks.games/engine.csgo.txt" L 03/21/2014 - 14:52:56: [UPDATER] Successfully updated gamedata file "sdktools.games/engine.csgo.txt" L 03/21/2014 - 14:52:56: [UPDATER] Successfully updated gamedata file "sm-cstrike.games/game.csgo.txt" L 03/21/2014 - 14:52:56: [UPDATER] SourceMod has been updated, please reload it or restart your server. L 03/21/2014 - 14:55:26: SourceMod log file session started (file "L20140321.log") (Version "1.5.3") L 03/21/2014 - 14:55:26: -------- Mapchange to cp_well -------- 

SourceMod documentation - setup , management , small FAQ (eng).

Since the next Team Fortress 2 updates may break the fragile interaction between the game and SourceMod, it makes sense to keep track of new versions and builds and be updated regularly.

Continuation with the description of plug-in settings and interactive interaction of players with the server is described in the "SourceMod plug-ins" section, but for now let's move on to setting up the launch of servers.

Autostart game servers

Our game servers are already old enough to include them in autorun. For systems with System V init, you can redo the previously created startup scripts, or use the examples from the TF2 Wiki . For systems with systemd, like ours, we are doing two service files, plainly called srcds1.service and srcds2.service.

For reference, to refresh the material: After all the additions (Records, SourceMod), the startup script of the same first ~ / start1.sh server in its complete set should look something like this:

 #!/bin/sh # #   . #     ,    srcds_run GAMEFOLDER=/home/game/tf2 CMDLINE="+sv_pure 2 -game tf +maxplayers 24 \ -pidfile ${GAMEFOLDER}/tf/srcds1.pid \ -ugcpath ${GAMEFOLDER}/steamapps/workshop1 \ -replay reply1.cfg -replayserverdir server1 \ +exec autoexec1.cfg +servercfgfile server1.cfg \ -port 27015 -steamport 26900 +clientport 27005 +tv_port 27020 -strictportbind \ +sm_basepath addons/sourcemod1 +sm_corecfgfile addons/sourcemod1/configs/core.cfg" #    ${GAMEFOLDER}/srcds_run ${CMDLINE} 

We have become accustomed to the srcds_run script, so we will continue to use it. It is only necessary to attend to automatic restart of the game server when executing commands quit , _restart . Now the script restarts the server only if it ended abnormally with a non-zero exit code, or zero if auto-update is enabled.

Several options. The first is that you can simply enable the standard auto update (section "Automatic" in the section "Update servers"). The second is to create a copy of the script with a different name and correct it for the eternal restart of the server (you should not edit the original script - it can be replaced during the upgrade) and use it in the future. Third, if you plan to update the server yourself, then you can enable auto-update by adding -autoupdate and its two satellite parameters to the launch command line, but using ~ / cfg / tf2_quit, which consists of only one line with the quit command, as an auto-update script that is, in fact, updates will not be checked.

Knowledge multiplies sadness. But the choice is yours. In our case, for the first server, we have not yet specified the criteria for the end of the rounds in the configuration files, and the second server will generally have non-standard maps, it is quite possible that with infinite rounds, so in the autorun we will use the third option - with a dummy autoupdate, and The real update is through the regular launch of the update.sh script in the crontab. Again, so interesting.

So, service files. For convenience, we will use the tmux terminal multiplexer (anyone can use screen instead), which will run the srcds_run script. The command line parameters passed almost unchanged from the startup scripts that we used before.

Since the game servers are started on behalf of the game user, then in an amicable way, it would be possible to create startup files in the user's environment, in ~ / .config / systemd / user /. But this section of the documentation was tested on centos 7, where running systemd in user mode does not function, so we create service files as root.

We go as root, create the file /etc/systemd/system/srcds1.service for the first server.

 # /etc/systemd/system/srcds1.service # # Team Fortress 2 Source Dedicated Server [Unit] Description=Team Fortress 2 Source Dedicated Server No 1 After=network.target [Service] User=game Group=game WorkingDirectory=/home/game/Steam Type=oneshot RemainAfterExit=yes PIDFile=/home/game/tf2/tf/srcds1.pid ExecStart=/usr/bin/tmux -L socket1 new-session -d '/home/game/tf2/srcds_run \ +sv_pure 2 -game tf +maxplayers 24 \ -pidfile /home/game/tf2/tf/srcds1.pid \ -ugcpath /home/game/tf2/steamapps/workshop1 \ -replay replay1.cfg -replayserverdir server1 \ +exec autoexec1.cfg +servercfgfile server1.cfg \ -port 27015 -steamport 26900 +clientport 27005 +tv_port 27020 -strictportbind \ -autoupdate -steam_dir /home/game/Steam -steamcmd_script /home/game/cfg/tf2_quit \ +sm_basepath addons/sourcemod1 +sm_corecfgfile addons/sourcemod1/configs/core.cfg' ExecStop=/usr/bin/tmux -L socket1 send-keys "quit" Enter ; /usr/bin/sleep 5s ; /usr/bin/tmux -L socket1 kill-session ExecReload=/usr/bin/tmux -L socket1 send-keys "_restart" Enter ExecStopPost=/usr/bin/rm -f /home/game/tf2/tf/srcds1.pid [Install] WantedBy=multi-user.target 

A small explanation of the parameters ExecStop and ExecReload. To shut down the server, we send him the rays of love and the quit command to the console, wait a few seconds to complete the work, and, until everything is started again, we beat the session. A similar mechanism for restarting the server. If you wish, you can add a warning message to players about the upcoming restart - as it was in the example of one of the update scripts in the appropriate section.

Copy srcds1.service in srcds2.service, adjust the paths, ports and the name of the tmux socket. We save. /etc/systemd/system/srcds2.service:

 # /etc/systemd/system/srcds2.service # # Team Fortress 2 Source Dedicated Server [Unit] Description=Team Fortress 2 Source Dedicated Server No 2 After=network.target [Service] User=game Group=game WorkingDirectory=/home/game/Steam Type=oneshot RemainAfterExit=yes PIDFile=/home/game/tf2/tf/srcds2.pid ExecStart=/usr/bin/tmux -L socket2 new-session -d '/home/game/tf2/srcds_run \ +sv_pure 2 -game tf +maxplayers 24 \ -pidfile /home/game/tf2/tf/srcds2.pid \ -ugcpath /home/game/tf2/steamapps/workshop2 \ -replay replay2.cfg -replayserverdir server2 \ +exec autoexec2.cfg +servercfgfile server2.cfg \ -port 27016 -steamport 26901 +clientport 27006 +tv_port 27021 -strictportbind \ -autoupdate -steam_dir /home/game/Steam -steamcmd_script /home/game/cfg/tf2_quit \ +sm_basepath addons/sourcemod2 +sm_corecfgfile addons/sourcemod2/configs/core.cfg' ExecStop=/usr/bin/tmux -L socket2 send-keys "quit" Enter ; /usr/bin/sleep 5s ; /usr/bin/tmux -L socket2 kill-session ExecReload=/usr/bin/tmux -L socket2 send-keys "_restart" Enter ExecStopPost=/usr/bin/rm -f /home/game/tf2/tf/srcds2.pid [Install] WantedBy=multi-user.target 

Here we specifically launch two separate copies of tmux, each for its own game server. One could, of course, get by with sessions inside a single tmux (tmux new-session -d -s tf1 and tmux new-session -d -s tf2), but then this would be an additional point for epic fail - when inadvertent Ctrl-C nailed all our servers.

Do not forget to create the file ~ / cfg / tf2_quit with the contents:

 quit 

We check that both .service files are writable only for root, then run, turn on:

  # systemctl start srcds1 # systemctl start srcds2 # systemctl enable srcds1 # systemctl enable srcds2 

But now we have a stupid situation - the game servers start when our server starts, but the game user cannot control them in standard ways using systemctl (start, stop, reload), although it can quite well be "managed" with Ctrl + C in a tmux session , followed by manual start. We correct the injustice.

While we are still root, run visudo , adjust the sudoers file by appending to the end:

 Defaults:game !requiretty game ALL= NOPASSWD: /usr/bin/systemctl start srcds1.service, /usr/bin/systemctl start srcds2.service game ALL= NOPASSWD: /usr/bin/systemctl stop srcds1.service, /usr/bin/systemctl stop srcds2.service game ALL= NOPASSWD: /usr/bin/systemctl reload srcds1.service, /usr/bin/systemctl reload srcds2.service game ALL= NOPASSWD: /usr/bin/systemctl status srcds1.service, /usr/bin/systemctl status srcds2.service game ALL= NOPASSWD: /usr/bin/systemctl enable srcds1.service, /usr/bin/systemctl enable srcds2.service game ALL= NOPASSWD: /usr/bin/systemctl disable srcds1.service, /usr/bin/systemctl disable srcds2.service 

Here we provide the game user with the ability to use sudo, without requesting a password (which he does not have), to execute the start, stop, reload, status commands and for the enable heap enable with disable for the first and second servers. And the parameter "Defaults: game! Requiretty" will allow us to run sudo from the crontab file. Optionally, you can add permission to use other commands such as is- * and others.

Permissions for commands like systemctl edit [--full] will not be granted. Still, security must be ... safe.

We leave from under root, we check from under game:

  $ sudo -l 

  Matching Defaults entries for game on this host: ... ..., !requiretty User game may run the following commands on this host: (root) NOPASSWD: /usr/bin/systemctl start srcds1.service, (root) /usr/bin/systemctl start srcds2.service (root) NOPASSWD: /usr/bin/systemctl stop srcds1.service, (root) /usr/bin/systemctl stop srcds2.service (root) NOPASSWD: /usr/bin/systemctl reload srcds1.service, (root) /usr/bin/systemctl reload srcds2.service (root) NOPASSWD: /usr/bin/systemctl status srcds1.service, (root) /usr/bin/systemctl status srcds2.service (root) NOPASSWD: /usr/bin/systemctl enable srcds1.service, (root) /usr/bin/systemctl enable srcds2.service (root) NOPASSWD: /usr/bin/systemctl disable srcds1.service, (root) /usr/bin/systemctl disable srcds2.service 

You can immediately run sudo systemctl status srcds1.service , sudo systemctl status srcds1.service it.

Commands will need to be entered without reducing the parameters. That is, sudo systemctl status srcds1.service is normal, but sudo systemctl status srcds1 is no longer a cake.

If, when manipulating game servers using systemctl, an error of the form "Failed to stop srcds1.service: Interactive authentication required." Is issued - that means you forgot about sudo :-)

When everything works, it will be possible to work with server consoles already as a game user, connecting via tmux:

  $ tmux -L socket1 attach $ tmux -L socket2 attach 

Disconnect from tmux session - Ctrl + b, d.

You can set up aliases in ~ / .bash_profile:

 alias tf1="tmux -L socket1 attach" alias tf2="tmux -L socket2 attach" 

By default, the size of the stored history for tmux is 2,000 lines, but it can be increased, for example, to 10,000 lines by creating a ~ / .tmux.conf file like this:

 set-option -g history-limit 10000 set-option -g set-remain-on-exit on 

The second command does not close the tmux session at the end of the main program, which makes it possible to read its last simple console.

Move through the history - Ctrl + b, [, and then the usual keys - Up / Down, PgUp / PgDown. The output from this mode is q.

Logs

Logs we will have a lot and different. Namely:

Cron logs

We run scripts to check for updates, HLstatsX statistics server, delete obsolete Records through cron, and their output is reflected in / var / log / cron as

  Jun 15 12:55:01 server CROND[584]: (game) CMD (cd $HOME/stat/scripts && ./run_hlstats start 2 27500 1) Jun 15 12:55:01 server CROND[583]: (game) CMDOUT (HLstatsX:CE daemon control) Jun 15 12:55:01 server CROND[583]: (game) CMDOUT (http://www.hlxce.com) Jun 15 12:55:01 server CROND[583]: (game) CMDOUT (---------------------------) Jun 15 12:55:01 server CROND[583]: (game) CMDOUT (Daemon is already running on port 27500) Jun 15 12:55:01 server CROND[583]: (game) CMDOUT (Daemon is already running on port 27501) ... 

Since no one can read / var / log / cron except the root user, which is not interesting to him, I would like to give the game user access to the logs of his crontab file. Of course, for each script at the end of the startup line you can add something like "... >> $ HOME / log / cron.log" but these "logs" will be without time stamps, and indeed, amateur work. A more cultural variant "... | / usr / bin / logger - tag srcds" doesn’t change anything - well, there will be messages not in / var / log / cron, but in / var / log / messages, the difference is.

Therefore, in the rsyslog daemon settings, we will make messages from cron starting with the user name "(game)" redirected to the file /home/game/log/cron.log, which is owned by the game user, and do not go into further processing (in "cron. * / var / log / cron")

We have rsyslogd version 8.19 installed, and in /etc/rsyslog.conf the $IncludeConfig /etc/rsyslog.d/*.conf /etc/rsyslog.d/*.conf directive is located before the cron.* /var/log/cron rule cron.* /var/log/cron , so we will intercept the messages from our scripts as the root user, the /etc/rsyslog.d/srcds-10-cron.conf file with the contents:

 # /etc/rsyslog.d/srcds-10-cron.conf if $syslogfacility-text == "cron" and $msg startswith " (game)" then { action( type = "omfile" fileOwner = "game" fileGroup = "game" file = "/home/game/log/cron.log" ) stop } 

— omfile , properties .

, ok, .

  # rsyslogd -N 2 # systemctl restart rsyslog 

root, , /etc/logrotate.d/srcds-cron:

 #/etc/logrotate.d/srcds-cron /home/game/log/cron.log { su game game daily dateext maxage 3 missingok copytruncate compress notifempty } 

Checking:

  # logrotate --debug --force /etc/logrotate.d/srcds-cron 

Steam

~/Steam/logs/. , . *.previous.txt , *.previous.txt . , - — , Valve — nobody cares...

-

-, :

• Fast Download, /var/www/fastdl.example.org/log/
• (Replay), /var/www/replay.example.org/log/
• HLstatsX, /var/www/stat.example.org/log/

/etc/logrotate.d/srcds-nginx, , , Elasticsearch, Kibana Logstash — ELK .

SourceMod

~/tf2/tf/addons/sourcemod{1,2}/logs. ~/tf2/tf/addons/sourcemod{1,2}/configs/core.cfg:

Logging on
/

LogMode daily
— (daily), (map), (game) — .

DebugSpew no

SourceMod , , core.cfg LogMode game , , - :

  L 06/20/2016 - 04:53:24: Executing dedicated server config file server1.cfg L 06/20/2016 - 04:53:32: server_cvar: "sv_tags" "HLstatsX:CE,cp,increased_maxplayers" L 06/20/2016 - 04:53:32: tf_server_identity_account_id not set; not logging into registered account L 06/20/2016 - 04:53:32: server_cvar: "sv_contact" "game@example.org" L 06/20/2016 - 04:53:33: [UPDATER] Successfully updated gamedata file "core.games/common.games.txt" L 06/20/2016 - 04:53:33: [UPDATER] Successfully updated gamedata file "sdkhooks.games/game.doi.txt" L 06/20/2016 - 04:53:33: [UPDATER] Successfully updated gamedata file "sdkhooks.games/master.games.txt" L 06/20/2016 - 04:53:33: [UPDATER] Successfully updated gamedata file "sdktools.games/game.doi.txt" L 06/20/2016 - 04:53:33: [UPDATER] Successfully updated gamedata file "sdktools.games/master.games.txt" L 06/20/2016 - 04:53:33: [UPDATER] SourceMod has been updated, please reload it or restart your server. L 06/20/2016 - 04:53:33: Connection to Steam servers successful. L 06/20/2016 - 04:53:33: Public IP is 192.0.2.0. L 06/20/2016 - 04:53:33: Assigned anonymous gameserver Steam ID [A:1:123456789:1234]. L 06/20/2016 - 04:53:33: VAC secure mode is activated. L 06/20/2016 - 04:53:34: server_cvar: "sm_nextmap" "cp_well" 

~/log/server{1,2}/. , :

log off
(on) . (sv_logfile), (sv_logecho), UDP (logaddress_add).

sv_logfile 1
(1), . sv_logsdir sv_logfilename_format.

sv_logsdir logs
. , ~/tf2/tf/logs, , /home/game/log/server1 /home/game/log/server2 . , , , .

sv_log_onefile 0
(1), (0), : l0618000.log -> l0618001.log -> l0618002.log… l0619000.log -> l0619001.log . : -, l0618000.log -> l0619000.log ; -, - log off log on, , .

sv_logfilecompress 0
, gzip <logfilename>.log.gz . , Linux . , "1" (, sv_log_onefile = "0" ), , .gz , . - — "l" vs "L", Linux:

  ---- Host_Changelevel ---- Compressing /home/game/log/server2/L0713019.log to /home/game/log/server2/L0713019000.log.gz... Success. Removing /home/game/log/server2/L0713019.log. Unable to remove /home/game/log/server2/L0713019.log! Unable to remove /home/game/log/server2/L0713019.log! Server logging data to file /home/game/log/server2/L0713020.log Applying new item schema, version 5C0BC93D 

sv_logfilename_format ""
. "log on". , l<><><000...999>.log , — <Latin Small Letter L> , , . , strftime . , "sv_logfilename_format %Y%m%d" "20160714.log". 20160714.log -> 20160714_000.log -> 20160714_001.log . , , sv_logfilecompress — .

log_verbose_enable 0
(1) . , ( log_verbose_interval) . . , , , . - http://geit.uk/blog/player-flow/ .

log_verbose_interval 3.0
. — 3 .

sv_rcon_log 1
(0), rcon ( -). rcon HLstatsX, , , :

  rcon from "192.0.2.0:60533": command "status" rcon from "192.0.2.0:60533": command "hlx_sm_psay "30" 2 "Round Over - All actions/frags are ignored <...> rcon from "192.0.2.0:60533": command "hlx_sm_psay "30" 1 "Red got 10 points for Round Win"" rcon from "192.0.2.0:60533": command "hlx_sm_psay "30" 1 "Asuka got 2 points (1,025) for Kill Assist"" 

sv_logecho 1
. , (0).

sv_logbans 0
(1) :

  L 07/13/2016 - 23:09:31: Addip: "<><><>" was banned by IP "for 10.00 minutes" by "Console" (IP "10.1.1.1") 

logaddress_add
: , UDP, HLstatsX. 192.0.2.0:27500, — 192.0.2.0:27501

logaddress_del
: .

logaddress_delall

developer 0
. — 0 ( ), 1, 2, 3...

, — , , .

3.5 — 4.0 . , 0.5 — 0.6 .

, logrotate copytruncate , ( , sv_log_onefile 0). copytruncate ( — , sv_logflush 1, , , ) , , , "Binary file (standard input) matches".

, :

1. . . . .

   
   

2. . "sv_log_onefile 0", "sv_logfilecompress 1" "sv_logfilename_format %Y%m%d", crontab find $HOME/log/server{1,2}/*.gz -type f -mtime +30 -delete , logrotate. , . "" , , — crontab tmux -L socket1 send-keys "changelevel_next" Enter .

   
   
3. . , - , rsyslog . omfile — File Output Module cron, imfile — Text File Input Module.

. C (- root) /etc/rsyslog.d/srcds-20-chat.conf:

 #/etc/rsyslog.d/srcds-20-chat.conf module(load="imfile" mode="inotify") #   *.log    input( type = "imfile" tag = "srcds1:" file = "/home/game/log/server1/*.log" ruleset = "chat-1" ) # $now -  ,    ,   YYYY-MM-DD template (name="chat1-log-name" type="string" string="/home/game/log/chat1-%$now%.log") #    (say),  (say_team),  steam id  ip ,    ruleset(name = "chat-1") { if ($msg contains [" say ", " say_team ", " connected, address "]) then { action( type = "omfile" fileOwner = "game" fileGroup = "game" dynafile = "chat1-log-name" ) } } 

, :

  Jul 23 10:40:46 server srcds1: L 07/23/2016 - 10:40:27: "Asuka<3><[U:1:12345678]><Blue>" say_team "Valar morghūlis" Jul 23 10:40:46 server srcds1: L 07/23/2016 - 10:40:34: "Rei<4><[U:1:09876543]><Blue>" say "Valar dohaeris, desu" 

rsyslogd — +, (), input, . . ( ommail rsyslog)

, ok, .

  # rsyslogd -N 2 # systemctl restart rsyslog 

, ( file input), , input, rsyslogd. , … .

, :

con_logfile ""
, . , ~/tf2/tf/ ( logs!). ".log", . -consolelog <file> — , — : ~/tf2/bin/<file> , ~/tf2/tf/<file> , ~/tf2/tf/<file>.log .

con_timestamp 0
(1), , . , +con_timestamp 1 -consolelog <file> , .

, , logrotate copytruncate.

, . - , :

  07/15/2016 - 14:59:59: DataTable warning: player: Out-of-range value (72483.898438/65536.000000) in SendPropFloat 'm_flLastDamageTime', clamping. 07/15/2016 - 14:59:59: DataTable warning: player: Out-of-range value (72492.539062/65536.000000) in SendPropFloat 'm_flLastDamageTime', clamping. 07/15/2016 - 14:59:59: DataTable warning: player: Out-of-range value (72479.742188/65536.000000) in SendPropFloat 'm_flLastDamageTime', clamping. 

, ~ 125 , ~ 64 , 1.5 , "" , . , , , , , .

, - root /etc/logrotate.d/srcds-server:

 #/etc/logrotate.d/srcds-server /home/game/log/console*.log { su game game daily dateext rotate 7 copytruncate notifempty missingok compress # compresscmd /home/game/logrotate-filter.sh } 

:

  # logrotate --debug --force /etc/logrotate.d/srcds-server 

— "compresscmd /home/game/logrotate-filter.sh", ~/logrotate-filter.sh :

 #!/bin/sh /bin/grep -v ": DataTable warning:" | /bin/gzip -6 

gzip , grep, DataTable warning, gzip, as planned.

, — (sv_logecho 1), (sv_logfile 0) , . :

  07/24/2016 - 18:50:46: DataTable warning: (class info_particle_system): Out-of-range value (-1.000000 / -1.000000) 07/24/2016 - 18:52:21: Attempted to add job to job queue that has already been completed 07/24/2016 - 18:57:11: DataTable warning: (class info_particle_system): Out-of-range value (-1.000000 / -1.000000) 07/24/2016 - 18:57:48: L 07/24/2016 - 18:57:48: "GLaDOS<20><BOT><Red>" triggered "player_builtobject" 07/24/2016 - 18:57:50: L 07/24/2016 - 18:57:50: "Companion Cube<34><BOT><Blue>" killed "GLaDOS<20><BOT><Red>" with "knife" 07/24/2016 - 19:00:24: L 07/24/2016 - 19:00:24: "AimBot<23><BOT><Red>" triggered "domination" against "DeadHead<10><BOT><Blue>" 07/24/2016 - 19:00:25: L 07/24/2016 - 19:00:25: "AimBot<23><BOT><Red>" triggered "killedobject" (object "OBJ_SENTRYGUN") 07/24/2016 - 19:00:32: DataTable warning: info_particle_system: Out-of-range value (1.000000/1.000000) 07/24/2016 - 19:00:49: DataTable warning: (class info_particle_system): Out-of-range value (-1.000000 / -1.000000) 

— . (con_timestamp 0), . rsyslog, ruleset regex . .

HLstatsX , ~/stat/scripts/logs/, , , , , ~/stat/scripts/hlstats.conf "DebugLevel 0"

Steam QuickPlay

( 2 7):

  Setting breakpad minidump AppID = 232250 No account token specified; logging into anonymous game server account. (Use sv_setsteamaccount to login to a persistent account.) ConVarRef room_type doesn't point to an existing ConVar Executing dedicated server config file server1.cfg ... Connection to game coordinator established. tf_server_identity_account_id not set; not logging into registered account *** ~/cfg/server1.cfg ... 

, - Valve "" ( , ...), . — , QuickPlay. .

, 2014 — hlds_announce , , , . — Counter-Strike: Global Offensive Team Fortress 2, . , . — , , . — Valve, ( CS:GO) , ip , Steam , . — Steam, -. CS:GO, .

. Valve 2014 api http://steamcommunity.com/dev , IGameServersService/CreateAccount . , (XXI ) http://steamcommunity.com/dev/managegameservers , . . :

• Steam .
• Steam .
• Steam .
• Steam , .
• 1000 .

, , . Steam, (.1 — ok), 5 USD (.2 — ok), (.3 — ok), Team Fortress 2 (.4 — ok). "Do VAC and Game bans apply to all accounts on a phone number?" [ ] ( https://support.steampowered.com/kb_article.php?ref=8625-WRAH-9030 ), , . , Steam Guard :

, https://steamcommunity.com/dev/managegameservers , , , . . .

, gameserver login token:

~/cfg/autoexec1.cfg:

 //... // Steam Gameserver Account sv_setsteamaccount 3A820F219B470281C00IDDQD00A4D210 

, ( 2 8):

  Setting breakpad minidump AppID = 232250 Logging into Steam game server account ConVarRef room_type doesn't point to an existing ConVar Executing dedicated server config file server1.cfg ... Connection to Steam servers successful. Public IP is 192.0.2.0. Assigned persistent gameserver Steam ID [G:1:21]. VAC secure mode is activated. 

"Assigned anonymous gameserver Steam ID [A:1:1724597452:5521]" Steam ID — [G:1:21]. "G" — GameServer, "A" — AnonGameServer. — wiki .

Team Fortress 2 , , , , . C:\Program Files\Steam\userdata\< id>\7\remote\ . serverbrowser_hist.vdf, . , ( 9):

  "Favorites" { "4" { "name" "192.0.2.0:27015" "address" "192.0.2.0:27015" "LastPlayed" "1476177442" "appid" "0" "accountid" "21" } } 

accountid , .

, "Regenerate token" , .

:

  Could not establish connection to Steam servers. (Result = 106) enum_names.cpp (136) : Assertion Failed: Missing String for EResult (106) 

, , — , . http://steamcommunity.com/dev/managegameservers , . Steam Web API Key IGameServersService — login_token is_expired.

QuickPlay

UPDATE, : the quickplay system is no longer in use for Team Fortress 2.

.

QuickPlay. , https://support.steampowered.com/kb_article.php?ref=2825-AFGJ-3513 . — , , . , , . sv_setsteamaccount , , Steam, , — , . Team Fortress 2, — ~ , cl_gameserver_create_identity. :

  cl_gameserver_create_identity Request to create a game server account sent--please wait. Game server account created successfully! Set these convars on your game server to have it log in and receive benefits: tf_server_identity_account_id 284181 tf_server_identity_token "18a>qPosnHYia?a" 

~/cfg/autoexec1.cfg:

 //... // QuickPlay tf_server_identity_account_id 284181 tf_server_identity_token "18a>qPosnHYia?a" 

, ( 2, 9, 10):

  Connection to game coordinator established. Received auth challenge; signing into gameserver account... *** ~/cfg/server1.cfg ... Connection to Steam servers successful. Public IP is 192.0.2.0. Assigned persistent gameserver Steam ID [G:1:21]. VAC secure mode is activated. Game server authentication: SUCCESS! Standing: Good. Trend: Steady Successfully logged into gameserver account 284181. For more information about gameserver accounts, visit https://support.steampowered.com/kb_article.php?ref=2825-AFGJ-3513. 

, , .

QuickPlay, autoexec1.cfg . tf_server_identity_disable_quickplay 1.

, Valve, tf_server identity .

• 1 — Steam Team Fortress 2, ,
• 2 — (Replay), SourceTV, Fast Download,
• 4 — HLstatsX