как узнать версию sourcemod
Как узнать версию sourcemod
SourceMod имеет весьма подробную и гибкую систему управления, она может быть достаточно сложной для пользователей. Чтобы упростить эти вещи, существуют “флаги” которые уточняют общие права, которые могут иметь администраторы.
Кроме того, в настоящее время предусмотрено два способа хранения администраторов. Один через упрощенный простой файл, а другой с помощью более сложных ветвящихся конструкций на основе нескольких файлов.
SourceMod по умолчанию предусматривает три метода аутентификации:
Steam ID – уникальный для каждого Steam аккаунта
IP Address – уникальный IP адрес полученный компьютером (хорошо использовать в локальной сети, где IP адреса статические)
Name – по имени (требуется пароль)
1.Быстрый старт
Откройте файл cstrike/addons/sourcemod/configs/admins_simple.ini навашем сервере
Добавьте новую строку и напишите в ней следующее, заменив yoursteamid на ваш SteamID (узнать можно написав в консоли status) вида STEAM_n:o:p
Сохраните файл
Перезапустите сервер
Зайдите на ваш сервер
Напишите sm_admin в консоли игры, и вернитесь в игру закрыв консоль. Вы должны увидеть админское меню.
3.Иммунитет
В SourceMod иммунитет это гибкая система основанная на уровнях иммунитета.
Каждый администратор может иметь произвольную величину иммунитета установленного у него. Но если администратор должен совершить действие над другим администратором, то успешность действия будет зависеть от величины иммунитета у администратора. Например один администратор с иммунитетом 2 захочет кикнуть администратора с уровнем иммунитета 3, но у него это не получиться, будет выдано сообщение о недостаточном количестве прав доступа и о наличие более высокого иммунитета у другого игрового администратора.
По умолчанию, администраторы с одинаковым иммунитетом, могут совершать действия друг над другом. Это может быть изменено с помощью переменной sm_immunity_mode в файле cfg/sourcemod.cfg.
4.Пароли
Для работы паролей администратор сервера должен изменить «PassInfoVar» строку в addons/sourcemod/configs/core.cfg файле.
Например:
quote=author] «PassInfoVar» «_sm1337» [/quote]
5.Простое добавление администраторов
Самый простой способ добавить администратора через конфигурационный файл admins_simple.ini.
Это простой файл, который требует два параметра в строке: проверка подлинности информации, а также флаги. Строка флагов несколько гибкая и может иметь следующую информацию:
Опционально уровень иммунитета, а затем двоеточие (‘:’);
Строка флагов;
Название группы, до него символ @.
Далее три примера:
«STEAM_0:1:16» «bce» //админ, кик, unban для этого steamID. Нет иммунитета
«!127.0.0.1» «5:z» //все права для этого IP адреса, уровень иммунитета = 5
«Andrey» «abc» «hlmod.ru» //имя Andrey, пароль «hlmod.ru»: резервный слот, админ, кик
6.Детальная настройка администраторов
Кроме того, вы можете добавить админов через конфигурационный файл admins.cfg, более продвинутый файл сохраняется в формате KeyValues. Каждый администратор имеет собственный блок внутри основного «Админского» блока. Вы можете создавать и/или модифицировать admins.cfg файлы с помощью KVManager. Формат выглядит следующим образом:
Доступные опции:
auth: Авторизация: Требуется обязательно. Моет принимать значения только steam, name или IP (если есть пользовательский метод аутентификации), это является инструкцией SourceMod’у по какому параметру идентифицировать пользователя.
identity: Идентификация: Требуется обязательно. Уникальная величина, которая позволяет SourceMod найти администратора предоставленным методом аутентификации и учета величин.
password: Пароль: Необязательный. Задает пароль пользователя, который необходимо ввести, если авторизация происходит по нику (см. выше раздел, посвященный паролям).
group: Группа: Необязательный. Определяет имя группы, которую должен унаследовать пользователь, если это возможно. Можно указывать больше чем одну группу. Там должен быть ‘@’ в качестве символа, чтобы избежать двусмысленности.
flags: Флаги: Необязательный. Флаги доступа которые пользователь должен получать по умолчанию.
immunity: Необязательный. Уровень иммунитета, получаемый пользователем.
Админское имя не является обязательным (это поле может быть пустым). Это не для внутреннего использования и предназначено для удобства пользования сторонними участниками и различных инструментов.
Admins
<
«Andrey»
<
«auth» «steam»
«identity» «STEAM_0:1:2345»
«flags» «abcdef»
«immunity» «5»
«group» «Awesome Admins»
>
Установка и настройка SourceMod
Andrey
пишу код за еду
Вы должны увидеть всплывающее меню, сгруппированное по различным группам опций.
4. Устранение неполадок
Если установка прошла неудачно, изучите следующие три пункта
4.1. Metamod докладывает NOFILE или FAILED
Если после использования команды «meta list» вы видите следующее:
Вы забыли добавить запись SourceMod в addons/metamod/metaplugins.ini файл. Или, если не удалось устранить проблему, убедитесь, что вы используете правильную сборку Sourcemod (ZIP для Windows, TAR для Linux ).
Примечание:
В последних релизах SourceMod в сборке идет *.vdf файл, который находясь в директории metamod подгружает SourceMod, то есть вам не нужно делать запись о SourceMod’e в файле metaplugins.ini.
4.3. Metamod:Source не реагирует на команды
Прочтите инструкцию по установке Metamod:Source и установите его правильно.
Учтите что один из игроков может использовать в своем нике символы к примеру @All, в этом случае действие будет произведено только на нем а не на всех, чтобы получилось на всех используйте знак #, то есть вместо @All используйте #@all
Основные команды админского плагина:
Описание основных папок:
Более подробно расписано в этой теме
Как правильно обновить SourceMod
Если какой либо плагин не работает, перекомпилируйте его используя компилятор вашей текущей версии SourceMod’a.
Базовые плагины входящие в состав SourceMod:
Подскажите как узнать версию
Стаж: 7 лет 6 месяцев
Сообщений: 220
Благодарностей: 27
Полезность: 0
Привет всем как узнать какая версия amx и какая версия мета мода
так же дайте обновленные версии того и того билд 5787
Сообщений: 491
Благодарностей: 279
Полезность: 818
Версию Metamod можно узнать командой meta version, версию AMX Mod X командой amxx version, версию модулей AMXX командой amxx modules. Все команды нужно вводить в консоли сервера.
Вместо обычного Metamod рекомендую использовать Metamod-P 1.21p37, он должен работать как на новых, так и на старых билдах. Если всё же не запустится, то используйте Metamod-P 1.19p32 (Old Binaries).
Относительно. Лучше использовать AMX Mod X 1.8.2, но он предназначен только для новых билдов. Есть вариант приспособить его и к старым, подробнее тут.
Стаж: 7 лет 6 месяцев
Сообщений: 220
Благодарностей: 27
Полезность: 0
Версию Metamod можно узнать командой meta version, версию AMX Mod X командой amxx version, версию модулей AMXX командой amxx modules. Все команды нужно вводить в консоли сервера.
Вместо обычного Metamod рекомендую использовать Metamod-P 1.21p37, он должен работать как на новых, так и на старых билдах. Если всё же не запустится, то используйте Metamod-P 1.19p32 (Old Binaries).
Относительно. Лучше использовать AMX Mod X 1.8.2, но он предназначен только для новых билдов. Есть вариант приспособить его и к старым, подробнее тут.
Настройка выделенного сервера Source под Linux, часть 3
Установка MetaMod и SourceMod
Пришла пора внести свежую струю в процесс настройки совместного сосуществования наших серверов, а именно — добавить MetaMod и SourceMod.
Установка MetaMod:Source
Сначала установим плагин MetaMod:Source, который никаких игровых функций не добавляет, а лишь обеспечивает интерфейс между движком Source, игрой и другими плагинами.
Скачиваем последнюю версию и распаковываем архив.
/tf2/tf будет создан подкаталог addons (в него мы будем устанавливать и другие моды), а в нём каталог metamod с рядом файлов для различных Source игр, в том числе и для Team Fortress 2:
Игровой сервер srcds при запуске проверяет наличие каталога
/tf2/tf/addons, ищёт в нём *.vdf файлы, в которых в параметре «file» должны быть указаны пути к библиотекам плагинов. В нашем случае, как раз в таком файле
/tf2/tf/addons/metamod.vdf подключен плагин MetaMod:Source как «addons/metamod/bin/server» (путь указывается относительно
Теперь мы установим SourceMod и подключим его к MetaMod.
Установка SourceMod
Переходим на http://www.sourcemod.net/downloads.php?branch=stable, скачиваем последнюю версию под Linux и распаковываем архив
/tf2/tf/addons появился каталог sourcemod, в
/tf2/tf/cfg/ — каталог sourcemod с файлами конфигурации, а в
/tf2/tf/addons/metamod — файлик sourcemod.vdf.
Так как одна инсталляция SourceMod не может одновременно обслуживать несколько серверов, то нам необходимо растиражировать по количеству серверов. В каталоге addons переименовываем sourcemod в sourcemod1 и копируем со всем содержимым в sourcemod2, предварительно для удобства выполнив dos2unix для файлов настроек:
MetaMod находит и подключает SourceMod благодаря файлу addons/metamod/sourcemod.vdf. Но этот файл один, а нам надо два разных, для каждого сервера. У MetaMod есть параметр, указывающий на каталог (не файл!) с конфигурацией, поэтому создадим два каталога cfg1 и cfg2 и поместим туда sourcemod.vdf, который и будем править.
Редактируем эти файлы, исправляя пути к инсталляциям SourceMod (так же, относительно
Для удобства делаем символьные ссылки на каталоги с настройками и логами:
Каких-то отдельных команд для запуска MetaMod прописывать не надо — игровой сервер запустит его автоматически, но нам надо указать различные каталоги для загрузки SourceMod.
/cfg/autoexec1.cfg для первого сервера дописываем в конец:
Для второго сервера в
Теперь MetaMod знает откуда загружать SourceMod, но последний не знает откуда ему брать свои настройки. Пропишем пути для каждого SourceMod. В отличие от MetaMod, параметры нам придётся указывать аж в командной строке запуска сервера. Ни в autoexec.cfg, ни в server.cfg они не срабатывают.
В скриптах запусках start1.sh и start2.sh, в CMDLINE дописываем:
Параметр sm_corecfgfile необходим, так как путь к core.cfg не берётся из sm_basepath, что логично было бы предположить.
Для проверки можно запустить первый игровой сервер и когда он полностью запустится, в его консоли ввести (команды выделены угловыми скобками):
Ну что же, все пути к каталогам и файлам верны, семнадцать стандартных плагинов и девять расширений запущены. Позже мы разберём кто что делает, а пока продолжим.
Если же при вводе команд выдаются ошибки вида:
То значит MetaMod не смог загрузить SourceMod. Надо искать в чём дело.
Перечень консольных команд MetaMod:Source — Console Commands (SourceMM)
Расширения находятся в каталоге
/tf2/tf/addons/sourcemod<1,2>/extensions — для всех поддерживаемых игр на движке Source, не только TF2.
Скомпилированные плагины находятся в каталоге
/tf2/tf/addons/sourcemod<1,2>/plugins. Если требуется отключить какой-нибудь плагин, то его можно просто перенести в подкаталог disabled. Сами исходные тексты плагинов находятся каталоге
/tf2/tf/addons/sourcemod<1,2>/scripting. Там же есть компилятор и скрипт compile.sh, который компилирует исходники и помещает скомпилированные плагины в подкаталог compiled, откуда их можно перенести в
/tf2/tf/addons/sourcemod<1.2>/plugins — и они станут доступны для использования SourceMod.
Теперь можно настроить SourceMod для каждого сервера, редактируя файлы core.cfg в
/tf2/tf/addons/sourcemod<1,2>/configs. В нашем случае удовлетворимся параметрами по умолчанию. Обратите внимание, что при этом параметром «DisableAutoUpdate No» включено автообновление игровых данных SourceMod в каталогах
Так же можно в core.cfg установить параметру «LogMode» значени «game» — тогда логи станут записываться не в отдельные файлы, а в логи игрового сервера. Подробнее в разделе «Логи»
Прочие файлы конфигурации разберём позже.
Однако есть ещё один файл конфигурации —
/tf2/tf/cfg/sourcemod/sourcemod.cfg — он выполняется при каждой смене карт следом за server.cfg и является общим для всех инсталляций SourceMod. Поэтому оставляем в sourcemod.cfg лишь команды, общие для обоих серверов, а индивидуальные переносим в отдельные файлы для каждого сервера.
/tf2/tf/cfg/sourcemod/sourcemod.cfg, традиционно добавляем вывод «echo», исправляем «sm_show_activity» и устанавливаем в «sm_datetime_format» привычный формат вывода даты/времени.
Всё. Остальное удаляем. Позже, когда захочется установить для серверов свои параметры, то можно взять их из сохранённого
/cfg/sourcemod_default.cfg и указать в каком-либо файле конфигурации сервера. Почему нельзя оставить всё как есть — в оригинальном sourcemod.cfg? А потому что он выполняется при каждой смене карт следом за server<1,2>.cfg — то есть любые установки, например, касающиеся резервных слотов, прописанные в server<1,2>.cfg будут перезаписаны значениями по умолчанию из этого файла. А те же резервные слоты мы будем настраивать для наших серверов по-разному.
При установке новых плагинов SourceMod, их файлы конфигурации могут автоматически создаваться в
/tf2/tf/cfg/sourcemod/ и становиться общими для обеих инсталляций SourceMod. Собственно, там уже лежит файл с настройками для плагина funcommands.smx
Так же SourceMod по умолчанию периодически скачивает со своего сервера (update.sourcemod.net) обновления файлов с игровыми данными, что найдёт своё отражение в логах. На примере первого сервера (
/tf2/tf/addons/sourcemod1/logs/), строчки 3,4,5:
Документация по SourceMod — настройка, управление, небольшой FAQ (eng).
Так как очередные обновления Team Fortress 2 могут нарушать хрупкое взаимодействие игры и SourceMod, то имеет смысл отслеживать новые версии и билды и регулярно обновляться.
Продолжение с описанием настройки плагинов и интерактивным взаимодействием игроков с сервером описано в разделе «Плагины SourceMod», а пока двинемся дальше — к настройке запуска серверов.
Автозапуск игровых серверов
Наши игровые сервера уже достаточно взрослые для того, чтобы можно было их включать в автозапуск. Для систем с System V init можно переделать ранее созданные скрипты запуска, либо использовать примеры из TF2 Wiki. Для систем с systemd, как у нас, делаем два файла служб, незатейливо именуемых srcds1.service и srcds2.service.
Справочно, для освежения материала: После всех добавлений (Записи, SourceMod), скрипт запуска того же первого сервера
/start1.sh в полной комплектации должен был выглядеть как-то так:
/cfg/tf2_quit, состоящий лишь из одной строчки с командой quit, то есть фактически, обновления не будут проверяться.
Знания умножают печали. Но выбор за вами. В нашем же случае, для первого сервера мы в файлах конфигурации ещё не прописывали критерии окончания раундов, а второй сервер вообще будет с нестандартными картами, вполне возможно, что и с бесконечными раундами, поэтому в автозапуске будем использовать третий вариант — с фиктивным автообновлением, а настоящее обновление — через регулярный запуск update.sh скрипта в crontab. Опять же, так интереснее.
Итак, файлы служб. Для удобства мы будем использовать терминальный мультиплексор tmux (желающие могут использовать вместо него screen), который будет запускать скрипт srcds_run. Параметры командной строки перешли практически неизменными из скриптов запуска, которые мы использовали до этого.
Так как игровые сервера запускаются от имени пользователя game, то по-хорошему, можно было бы создавать файлы запуска в пользовательском окружении, в
/.config/systemd/user/. Но данный раздел документации тестировался на centos 7, где запуск systemd в пользовательском режиме не функционирует, поэтому файлы служб мы создаём от имени root.
Заходим как root, создаём файл /etc/systemd/system/srcds1.service для первого сервера.
Небольшое пояснение по параметрам ExecStop и ExecReload. Для завершения работы сервера мы посылаем ему лучи любви и команду quit в консоль, ждём несколько секунд для завершения работы, и, пока всё не запустилось заново, прибиваем сессию. Схожий механизм для рестарта сервера. При желании можно добавить вывод предупреждения игрокам о грядущем рестарте — как это было в примере одного из скриптов для обновления, в соответствующем разделе.
Копируем srcds1.service в srcds2.service, корректируем пути, порты и имя tmux сокета. Сохраняем. /etc/systemd/system/srcds2.service:
Не забываем создать файлик
/cfg/tf2_quit с содержимым:
Но сейчас у нас глупая ситуация — игровые сервера стартуют при запуске нашего сервера, но пользователь game не может ими управлять стандартными способами с помощью systemctl (start, stop, reload), хотя вполне может ими «управлять» при помощи Ctrl+C в tmux сессии, с последующим запуском вручную. Исправляем несправедливость.
Разрешения на команды вида systemctl edit [—full] мы предоставлять не будем. Всё-таки безопасность должна быть… безопасной.
Выходим из-под root, проверяем из-под game:
Команды необходимо будет вводить без сокращения параметров. То есть sudo systemctl status srcds1.service — норм, а вот sudo systemctl status srcds1 — уже не торт.
Если при манипуляциях с игровыми серверами с помощью systemctl выдаётся ошибка вида «Failed to stop srcds1.service: Interactive authentication required.» — то значит вы забыли про sudo 🙂
Когда всё заработает, можно будет работать с консолями серверов уже как пользователь game, подключаясь через tmux:
Отключаться от tmux сессии — Ctrl+b, d.
Можно прописать алиасы в
По умолчанию, размер хранимой истории для tmux составляет 2000 строк, но его можно увеличить, например до 10000 строк, создав файл
Вторая команда не закрывает tmux сессию при завершении основной программы, что даёт возможность почитать её последнее прости в консоли.
Перемещаться по истории — Ctrl+b, [, а далее обычными клавишами — Up/Down, PgUp/PgDown. Выход из этого режима — q.
Логов у нас будет много и разных. А именно:
Логи cron
У нас через cron запускаются скрипты проверки обновлений, сервера статистики HLstatsX, удаления устаревших Записей, а их вывод отражается в /var/log/cron в виде
Поэтому мы в настройках демона rsyslog сделаем так, что сообщения от cron, начинающиеся с имени пользователя «(game)», перенаправляются в файл /home/game/log/cron.log, владельцем которого является пользователь game, и не попадают в дальнейшую обработку (в «cron.* /var/log/cron»)
Подробнее об использованных командах — omfile, properties.
Проверяем синтаксис, если всё ok, то перезапускаем демона и наслаждаемся свежесозданным логом.
Пока мы ещё root, настраиваем ротацию логов, создав файл /etc/logrotate.d/srcds-cron:
Логи клиента Steam
Эти логи находятся в
Логи веб-сервера
У нас с игровыми серверами сотрудничают три виртуальных веб-сервера, обслуживающих:
Ротация этих логов у нас настроена в /etc/logrotate.d/srcds-nginx, предполагается, что логи с ошибками будем просматривать самостоятельно, а логи доступа можно скармливать хоть Elasticsearch, Kibana и Logstash — но описание ELK стека вне объёма данного проекта.
Логи SourceMod
Эти логи находятся в каталогах
/tf2/tf/addons/sourcemod<1,2>/logs. Их настройки прописаны в соответствующих
Logging on
логи вкл/выкл
LogMode daily
ротация логов — ежедневная (daily), при смене карты (map), и третий режим (game) — писать в логи игрового сервера.
DebugSpew no
детализировать ли в логах обновление игровых данных
Логи игровых серверов
Логи игровых серверов находятся в
/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 соответственно. Хотя, конечно, можно было бы писать в один каталог, но с разным именованием файлов.
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, то экономия в части размеров логов невелика, но всё же спама на консоли сервера будет поменьше, без вот этого:
sv_logecho 1
дублирует вывод лога на консоль. Естественно, отключаем (0).
sv_logbans 0
при включении (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».
Учитывая это, работу с логами серверов можно организовать следующими способами:
Очень ленивый. Ничего не делать. При наличии инстинкта самосохранения всё же обеспечить удаление старых логов. Ну или просто отключить их ведение.
Попробуем настроить сохранение чата игроков первого сервера в отдельном логе. Cоздаём (из-под root) файл /etc/rsyslog.d/srcds-20-chat.conf:
При таких настройках, лог чата будет выглядеть как:
Тут стандартный формат rsyslogd — дата+время, имя сервера (железного), метка из input, и сама строчка лога. Отличие в секундах вызвано буферизацией записи игровых логов. При желании можно настроить дополнительную проверку текста сообщений на ключевые слова с немедленным извещением нас по электронной почте (модуль ommail в rsyslog)
Проверяем синтаксис, если всё ok, то перезапускаем демона.
Если новый лог будете создавать в том же каталоге, откуда считываются исходные (параметр file в секции input), то убедитесь, что его имя не попадает под маску файлов из секции input, которые мониторит rsyslogd. А то получится очень, гм… рекурсивненько.
Возвращаясь к настройкам ведения логов, стоит отметить ещё два параметра:
con_logfile «»
создаёт отдельный файл лога, куда записывается всё что выводится на консоль сервера. Имя файла указывается либо с полным путём, либо относительно каталога
В отличие от серверных логов, запись в консольный лог идёт построчно, и вполне корректно работает logrotate с параметром copytruncate.
Следует быть осторожным с включением записи этого, безусловно полезного лога. Иногда на игровой сервер что-то находит, и он начинает мощно спамить в консоль сообщениями вида:
При скорости потока, как правило
125 сообщений в секунду, такими темпами файл с консольным логом прирастает на
64 Мб в час, 1.5 Гб в сутки, что особенно неприятно в случае «долгоиграющих» карт, так как при смене карты эта ошибка обычно исчезает. Лечится либо прописыванием критериев, обеспечивающих регулярную ротацию карты, либо смирением с полуторагигабайтным логом в сутки, тем более, что сжимаются они неплохо, а хранить их можно недолго.
Настраиваем ротацию и этих логов, создав из-под root файл /etc/logrotate.d/srcds-server:
Проверяем логику работы:
Можно туда добавить костыль — строчку «compresscmd /home/game/logrotate-filter.sh», а сам
то есть в качестве архиватора будет вызываться не gzip а этот скрипт, который входной поток пропустит через grep, вырезая DataTable warning, а остальное передавая gzip, as planned.
Кстати, как вариант — можно включить дублирование лога в консоль (sv_logecho 1), выключить ведение основного лога (sv_logfile 0) и активировать запись консольного, и иметь дело только с ним. В лог будет писаться микс вида:
Единственное неудобство — дублирование меток времени у вставок из игрового лога. Можно отключить у консольного (con_timestamp 0), но это тоже не дело. Если только пропускать этот лог через rsyslog, в ruleset парсить с помощью regex и формировать новый файл с использованием своего шаблона. Но это для энтузиастов.
Логи сервера статистики
Сервер статистики HLstatsX у нас настроен так, что логи его создаются в
/stat/scripts/logs/, и по своему содержимому практически аналогичны серверным логам, поэтому после первоначальной настройки, когда покажется что всё заработало, их мы отключаем, установив в
/stat/scripts/hlstats.conf параметр «DebugLevel 0»
Привязка к Steam и QuickPlay
При запуске наших серверов наверняка бросались в глаза сообщения (строки 2 и 7):
Первое сообщение уведомляет, что наш сервер подключен к мастер-серверам 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, регистрируем новую учётную запись (п.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: