Как запустить steamcmd linux

Установка серверов через SteamCMD (Linux)

Содержание

Описание

В сравнении со старым HLDSUpdateTool типом установки серверов SteamCMD мне показался более удобным. Во многом упрощен режим установки, благодаря этому менее опытные пользователи смогут быстрее установить сервер Half-Life или Counter-Strike.

Для создания серверов Half-Life и Counter-Strike в SteamCMD нужно проделать одни и те же действия.

Требования

Системные требования для создания сервера Half-Life 1 и Counter-Strike 1.6

Процессор: 1000 МГц и больше

Оперативная память: 128 Мб и больше

Место на жестком диске: 1.5 Гб и больше

Если система 64 битная то нужна библиотека поддержки 32 битных приложений
Ее можно установить введя команду

Создание сервера

Скачиваем архив с утилитой SteamCMD

Удаляем архив, т.к. он нам больше не понадобится:

Запускаем sh файл

Начнется скачивание и проверка последних обновлений для нашего SteamCMD. После завершения обновления, мы войдем в командную строку Steam

Теперь нужно войти в аккаунт Steam

Если у Вас включен SteamGuard, то на электронную почту придет сообщение с кодом подтверждения, его нужно ввести.

Для скачивания серверов можно не входить в свой аккаунт Steam, а воспользоваться анонимом.

После этого указываем директорию, в которую нужно устанавливать сервер.

где hl — папка в которой будет находится сервер

Приступаем к установке самого сервера

где 90 — steam_app_id нашей игры, в данном случае это Half-Life Dedicated Server

Источник

Как пользоваться SteamCMD

Tranquillity

Консольный клиент Steam или SteamCMD — новая утилита для установки и обновления выделенных серверов через интерфейс командной строки. Он работает только с играми, которые переведены на контентную систему SteamPipe.

Загрузка
1. Создайте папку для SteamCMD.
C:\SteamCMD
2. Загрузите SteamCMD для Windows: https://steamcdn-a.akamaihd.net/client/installer/steamcmd.zip
3. Извлеките содержимое zip-архива в созданную папку.

Запуск SteamCMD
Запустить утилиту можно только через консольный терминал windows
1. Открываем командную строку Win+R
переходим в папку, куда извлекли steamcmd
cd C:\SteamCMD
Если вы создали папку на другом диске, то перейти туда можно командной
cd /D F:/SteamCMD
Запускаем утилиту
steamcmd
Вначале она сама себя обновит и по окончанию выведет приглашение для дальнейшей работы ( Steam> )

/steamcmd
Загрузим архив с утилитой
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
И распакуем архив
tar -xvzf steamcmd_linux.tar.gz
Запускаем утилиту
cd

/steamcmd
Загружаем архив
curl -O [URL]https://steamcdn-a.akamaihd.net/client/installer/steamcmd_osx.tar.gz[/URL]
Распаковываем содержимое
tar -xvzf steamcmd_osx.tar.gz
Запускаем утилиту
cd

Задаем директорию, куда будут закачаны файлы сервера
force_install_dir ./cs1.6/
В нашей директории, где находится steamcmd, появится поддиректория cs1.6
Выкачиваем наш сервер counter-strike 1.6 [Список всех поддерживаемых серверов]
app_update 90 -beta beta validate
* HLDS (APPID 90) в настоящее время требуется несколько прогонов app_update, прежде чем все необходимые файлы будут успешно установлены. Просто запустите app_update 90 validate несколько раз, пока приложение не будет больше обновляться.

Загрузка игрового сервера завершена.

Разработчики добавили в SteamCMD новый параметр ( @sSteamCmdForcePlatformType ), который позволяет выбрать платформу для которой необходимо скачать файлы, даже если это не та платформа на которой вы сейчас работаете.

Для загрузки Windows сервер CS: 1.6 из под Linux:

Источник

Как запустить steamcmd linux

2,358	уникальных посетителей
47	добавили в избранное

Для начало, что это такое и зачем оно нам нужно?

SteamCMD — это утилита, консоль Стима без красивого и вообще обычного интерфейса. С помощью него можно легко обновить и скачать любые игры или специальные сервера — Dedicated — это версия игры сделанная и направленная специально для работы сервера*, а не обычной игры (клиента*) из Стима.

*Клиент — компьютер обычного игрока, сам игрок.
*Сервер — компьютер, который обрабатывает запросы клиентов, благодаря ему вы можете играть вместе.

Почему именно SteamCMD?

SteamCMD работает не только в ОС* Windows, но и в Linux, Mac OS, например вы купили на месяц VPS*, а там Linux без GUI* и обычный Steam туда не поставишь, а вот SteamCMD. Запросто!

*VPS — Арендованный хостинг с ОС или без неё, но настроенный на полный доступ к неограниченной системе, то есть можно поднять (создать/запустить) сразу и сайт, и игру (игры), и файловый сервер, а не только, например, один сервер по Unturned.
*ОС — Операционная система, тупо система.
*GUI (Graphics User Interface) — Графический интерфейс, все что не похожее на командную строку (терминал).

Скриншот самого SteamCMD:

Что мы делаем теперь?

Правильно, войдём в учётную запись. или нет?
Есть два типа записей:

• anonymous
• обычный пользователь

разница между ними немного, но имеет смысл сказать об этом. В учётную запись anonymous входить с паролем не нужно, она как бы общая, но некоторые игры/сервера с помощью неё скачать нельзя, будет ошибка, но и если вы будете использовать обычного пользователя, ошибка снова может быть, так как нужна будет, наоборот, учётная запись anonymous, вот пример ошибки, когда используется не та учётная запись, которая нужна этой игре:

В обычную учётную запись нужно войти используя ваш логин, пароль и если есть SteamGuard.

и уже ниже у вас попросят пароль и SteamGuard (ну если есть).

В «анонимную» учётную запись нужно войти используя команду:

Теперь мы можем перейти к самому главному: установке игр, утилит и прочих инструментов, которые доступы в Steam.

Для начало нам нужно познакомиться с основным командами для установки:

• app_update — главная команда, она проверяет, если ли обновление на ту или иную игру** и скачивает её (игру или обновление).
• force_install_dir — команда, с помощью которой, мы можем указать местоположение той игры, которую мы будем скачивать.
• -beta — команда, которая указывает, что мы будем скачивать, не просто игру, а например старую альфу версию игры или наоборот, новейшую для тестирования.
• -betapassword — команда, которая нужна для команды -beta, если у вас есть запароленный доступ к специальной версии игры, например, если вы разработчик.
• validate — вторая главная команда, она проверяет, всё ли у вас скачалось правильно и без ошибок.
• mod — редкая команда, используется, чтобы установить игру с модификацией, после команды пишется название модификации.
• app_set_config — редкая команда, используется, чтобы установить игру c модификацией.

**игру — или же программу, утилиту или инструмент.

Теперь нам нужно узнать конкретный ID у нужной нам игры и нужную версию этой игры:

• Заходим на сайт SteamDB. [steamdb.info]
• Слева вверху в строке поиска («Search. «) пишем название игры, к примеру «HurtWorld«.
• Перед нами внизу табличка:
  • APPID — тот самый ID, который нам нужен.
  • APP TYPE — тип игры: сама игра или сервер/утилита/инструмент для неё.
  • NAME — имя: Hurtworld — сама игра, Hurtworld Dedicated Server или может быть Hurtworld DS — это наша игра, только специально сделана для сервера, как раз то, что нам нужно, а так же HurtWorld SDK — это инструменты по созданию модификаций для игры, но всё это можно скачать и в обычном Steam с нормальным интерфейсом, но это уже другая история, а точнее другое моё новое руководство.
  • LAST UPDATED — последняя дата обновления «игры».
• Запоминаем APPID, в моем случае мне нужен сервер, а не SDK или простая игра, значит мне нужен Hurtworld DS, ID у него 405100. Важная инфа: если вы делаете сервер и не нашли фразу Dedicated Server/DS в списке игр, не печальтесь, у некоторых игр нету DS версии, но они так же могут «держать» сервера на обычной версии, такая ситуация и с нашим Unturned.
• Всё бы хорошо, но мне нужная специальная версия с новым интерфейсом для игры, как мне скачать именно её? Очень даже просто: нажимаем на ID в таблице нужной нам игры, видим категории, нам нужна «Depots» и в ней ищем таблицу «Branches«, опять ищем столбец «NAME» и запоминаем нужно нам версию, для моего интерфейса это — «itemv2«.
• Теперь мы наконец-то можем скачать игру! Юху!

Почему без «-beta«, потому что там нету специальных версий, типо нового интерфейса, но есть версии игры 1.1 и 2.2.5, эти названия версий игры можно посмотреть на том же сайте — SteamDB. [steamdb.info]

Всё, как мы прописали команду началась скачиваться игра:

После того, как она скачается и проверится командой validate на целостность файлов, можно будет с чистой душой выйти из SteamCMD командой quit:

На этом моё руководство по SteamCMD заканчивается. Ниже будет «Разное» и «Ссылки«, рекомендую прочитать, если остались вопросы, и если вам захочется меня как-то поблагодарить за эту статью, делал эту статью, кстати, где-то 4 часа. Да-да.

Здесь что-то типо вопросов-ответов:

В*: Как сделать такую же красивую черно-синюю командную строку?
О*: Зажали одновременно кнопки WIN+R, написали «cmd«, ПКМ* нажали и выбрали «Свойства«, выбрали категорию «Цвета«, потыкали где смогли и нажали «ОК«.

*В — Вопрос
*О — Ответ
*ПКМ — Правая кнопка мыши

В: Почему ты не рассказал про команды force_install_dir, -betapassword, app_set_config?
О: 90% случаев неправильно прописывается путь в команде force_install_dir и из-за этого игра либо не скачивается, либо она (игра) теряется в файлах, либо это обычный «геморрой» каждый раз писать эту команду и путь при обновлении игры, а команды -betapassword и app_set_config используются крайне редко, что про них можно прочитать на этом сайте.

В: Можно ли автоматизировать этот процесс, чтобы не вводить всё это каждый раз?
О: Да, но часто люди это делают неправильно или на некоторых играх, это работает неправильно, или, вовсе, не работает, но если всё же интересно, сайт, который сверху, тебе в помощь.

Обычные ссылки на мои сообщества и прочая дичь.

Если вам не трудно и вы мне благодарны за информацию, то поставьте лайк и подпишитесь на ка. кхм. точнее добавьте в избранное, а ещё лучше и поделитесь с кем-нибудь этим руководством, спасибо.

Источник

Настройка выделенного сервера Source под Linux, часть 1

В данном руководстве будет описана установка и настройка одновременной работы нескольких выделенных игровых серверов Steam под Linux на примере игры Team Fortress 2.

• Введение
• Установка клиента Steam и сервера Team Fortress 2
• Базовая настройка серверов
  • Теория
  • Практика
  • Сетевые настройки
  • Скрипты запуска сервера
• Обновление серверов
  • Автоматическое
  • Периодическое обновление
  • Только проверка

Введение

• сервер с процессором, диском и памятью, способными потянуть все игровые сервера
• нормальный канал в интернет. Не dialup. Не ADSL.
• установленный веб-сервер, в нашем случае — nginx
• установленный sql-сервер, в нашем случае — mysql (mariadb)
• возможность запускать задачи по расписанию (cron)
• php с модулями
• root доступ на отдельных этапах настройки
• достаточно места на диске для:
  • игрового сервера — свыше шести гигабайт
  • логов (а их будет много и разных)
  • записей (replay)
  • sql баз данных
  • пользовательских карт, звуков, моделей и так далее.

Всё нижеследующее описывается применительно к отдельному серверу, физическому или виртуальному, с установленным и настроенным Linux, доступом в консоль. Во всех примерах у сервера ip адрес 192.0.2.0, у нашего клиентского компьютера 198.51.100.0

Игровому серверу для запуска и работы не нужны root полномочия, поэтому устанавливать и запускать всё будем из-под непривилегированного пользователя game. Заходим как root и добавляем пользователя:

Поскольку мы будем запускать ряд скриптов по расписанию, то проверим, может ли пользователь game создавать свой crontab файл:

Если открылось окно редактора, то хорошо, может. Если же на экран вывелось что-то вида:

то не может. Тогда, в зависимости от используемой программы cron и её настроек, разрешаем пользователю (предварительно выйдя из-под game назад в root) создавать свой crontab файл.

Итак, пользователь создан, авторизация настроена. Закрываем root сессию, продолжаем работать как game.

Установка клиента Steam и сервера Team Fortress 2

Нашу цель по установке и настройке одновременной работы нескольких игровых серверов можно достичь разными способами. В простейшем случае — создавая отдельные экземпляры серверов, каждый в своём каталоге. Это, ценой неэффективного использования дискового пространства (если файловая система или хранилище данных не используют дедупликацию) и повышенного расхода траффика на скачивание одинаковых обновлений даёт возможность независимой настройки, обновления и управления серверами, хотя при использовании одного ip адреса всеми игровыми серверами всё же придётся им использовать разные порты. Другой способ — использование единого каталога для игры, но с индивидуальными настройками игровых серверов. Этим путём мы и пойдём.

Если у нас 64-битный дистрибутив Linux, то необходимо установить дополнительные библиотеки совместимости (из-под пользователя root). Какие именно — гуглится по фразе steamcmd x64 ВАШ_ДИСТРИБУТИВ. Для Ubuntu 13.10 x64, например, apt-get install lib32gcc1 , для ArchLinux — pacman -S lib32-gcc-libs (при включённом репозитории multilib в /etc/pacman.conf), для CentOS — yum install glibc.i686 libstdc++.i686 и так далее.

Если их не устанавливать, будут выдаваться ошибка вида:

Устанавливать клиента Steam будем в одноимённый каталог в домашней директории пользователя game, а саму игру в каталог tf2. Предполагается, что в /etc/fstab раздел с /home монтируется без noexec и там достаточно свободного места.

Создаём каталоги для наших серверов и переходим в первый:

Скачиваем консольный клиент Steam, распаковываем архив.

Для большей наглядности разобьём следующий запуск steamcmd.sh на два. Сначала запустим процедуру самообновления:

Клиент Steam должен обновиться. В случае каких-то проблем читаем логи в

Теперь установим выделенный сервер игры:

Число «232250» в параметрах командной строки — это appid, идентификатор приложения, в нашем случае Team Fortress 2 dedicated server. Подробнее команды описаны в разделе «Обновление серверов».

Если всё ok, то бодренько начнётся загрузка:

Несколько минут, и у нас для Team Fortress 2 будет скачано шесть с половиной гигабайт (по состоянию на октябрь 2016 г.).

Переходим в папку

/tf2 и пробуем запустить игру вручную, посмотрим, как оно.

На консоли должно появится что-то вроде:

Можно уважить просьбу, установив библиотеку ncurses-libs.i686. А в остальном всё хорошо. Убедимся, что в строках 13 (Network: . ) и 17 (Public IP . ) сервер выбрал правильный IP.

На ошибки про «/home/game/.steam/sdk32/steamclient.so: cannot open shared object file: No such file or directory» не обращаем внимания, это нормально. Впрочем, можно и поправить:

Запускаем у себя на компьютере Team Fortress 2, вызываем консоль (

), затем connect 192.0.2.0:27015 (Либо сразу steam://connect/192.0.2.0:27015 — можно потом создать ярлык на рабочем столе). Начинаем подключаться к игровому серверу, а на консоли сервера в это время вывелась строчка вида

Если подключиться не получилось, то проверяем, на правильном ли интерфейсе «слушает» сервер. При наличии файервола проверяем, открыты ли нужные порты согласно руководства Valve. В случае более сложных сетевых конфигураций (сервер за NAT и тому подобное) обращаемся к соответствующим руководствам.

Останавливаем игровой сервер командой quit , впечатав её в его консоль, возвращаемся в командную строку и начинаем настройку.

Базовая настройка серверов

Теория

Исторически, за годы развития, сложились различные возможности по конфигурированию сервера.

По умолчанию сервер использует несколько основных файлов с настройками, которые ищет в

/tf2/tf/cfg/: autoexec.cfg — выполняется единожды при старте сервера, server.cfg — при запуске любой карты, .cfg — при запуске соответствующей карты.

Так же, при запуске сервера, в его командной строке можно указать параметр +servercfgfile my.cfg — при этом сервер отныне будет использовать не server.cfg а my.cfg, и несколько параметров вида +exec file1.cfg +exec file2.cfg +exec file3.cfg — эти файлы будет выполнены единожды при старте сервера, сразу после autoexec.cfg.

Вдобавок, ещё до проверки основного каталога, сервер при запуске ищет в

/tf2/tf/custom файлы с расширением .vpk и структуры каталогов вида my_dir/cfg/, my_dir/maps/, my_dir/materials/ и тому подобное и найденные там файлы использует вместо одноимённых стандартных.

Но и это не всё. В обновлении Team Fortress 2 от 14 мая 2013 года появился новый параметр командной строки -insert_search_path . Он служит для добавления пользовательской структуры каталогов (аналогично custom/), но с возможностью указания абсолютного пути, то есть не обязательно внутри серверного каталога

/tf2/tf/. Раньше для это приходилось исхитряться, а сейчас достаточно в командной строке srcds_run указать -insert_search_path /var/dir1 и этот каталог будет использоваться как поисковый путь (/var/dir1/maps, /var/dir1/cfg, . ) до путей в custom/ и до основного каталога с файлами конфигураций

/tf2/tf/cfg/. В -insert_search_path можно указать несколько каталогов через запятую. Причём каталоги будут обрабатываться в том порядке, в каком они перечислены, в отличие от структуры каталогов в custom/, где они обрабатываются по алфавиту.

То есть, если у нас есть несколько файлов server.cfg в разных каталогах:

и в командной строке сервера мы вдобавок укажем -insert_search_path /var/dir1 , то при запуске сервера и выполнении в консоли и скриптах команд вида exec server.cfg , этот файл сначала будет искаться в /var/dir1/cfg, затем в custom/another/cfg/, далее в custom/my_files/cfg/ (каталоги в custom/ перебираются по алфавиту) и напоследок в основном cfg/. Это относится не только к server.cfg, но и к motd.txt, картам и пр. Подробнее про поисковые пути можно почитать (и поковырять настройки) в

/tf2/tf/gameinfo.txt — там есть и про настройки путей в зависимости от системного языка, не освещённые здесь и много всего интересного.

Посмотреть очерёдность перебора поисковых путей очень просто — достаточно в консоли запущенного сервера ввести команду path :

Так же не забываем про файлы настроек вида .cfg. Кроме того есть replay.cfg, sourcemod.cfg, ммм… да тысячи их!

Такой зоопарк позволяет при настройке индивидуальных конфигураций для серверов выстрелить себе в ногу разнообразными способами. А так как srcds — молодой, динамически развивающийся сервер, то он может доставить немало весёлых часов в поисках ответа на вопрос «А почему ВНЕЗАПНО у игроков перестали скачиваться пользовательские карты. Даже через slow download, не говоря уж о fast… Два года всё было нормально. «

Из всего предложенного богатства выбора, мы остановимся на указании файлов конфигурации в +exec и +servercfgfile в параметрах запуска.

Необходимо учитывать, что любые комплектные файлы, установленные при инсталляции в

/tf2 могут быть изменены при очередном обновлении сервера, в том числе и файлы в

/tf2/tf/cfg. Поэтому мы не будем напрямую задействовать имеющиеся файлы конфигурации, а станем создавать, пусть даже и на их основе, но свои.

То есть вместо использования уже существующего, комплектного файла со списком карт для ротации, например, +mapcyclefile mapcycle_quickplay_cp.txt , пусть даже на данный момент он нас полностью устраивает, мы скопируем его в свой mapcycle.txt и будем подключать его.

Изменённые либо удалённые нами комплектные файлы (не только конфигурации, а любые) могут быть возвращены в своё исходное состояние путём запуска обновления игрового сервера с параметром «validate» — steamcmd.sh +login anonymous +force_install_dir

/tf2/ +app_update 232250 validate +quit . Тогда, даже если как такового нового обновления для нас нет, будет осуществлена проверка контрольных сумм всех комплектных файлов, и, при несовпадении, изменённые файлы будут скачаны заново.

Практика

В нашем примере мы будем настраивать два игровых сервера:

• первый — публичный, с официальными картами, без модификаций.
• второй — приватный, с пользовательскими картами, ботами, меняющими игровой процесс модификациями. Но с включённым Valve Anti-Cheat, конечно.

Создадим каталог для хранения файлов с настройками серверов. Заодно сделаем каталог для логов. На данный момент у нас уже есть логи клиента Steam, поэтому сразу же сделаем туда ссылку:

Мы по возможности все файлы настроек будем создавать в

/cfg и символьными ссылками раскладывать в соответствующие каталоги сервера. Такое размещение позволит заметно упростить процедуру резервного копирования и восстановления сервера, и уменьшить смешивание настроек разных серверов, хотя полностью избежать этого не удастся.

Настройки можно условно сгруппировать в три категории:

1. Параметры, которые должны быть указаны только в командной строке запуска сервера. Пример — maxplayers и sv_pure при значении равном двум
2. Параметры, которые необходимо указывать до загрузки карт — либо в autoexec.cfg, либо в подключаемых в командной строке +exec file.cfg. Пример — mapcyclefile, motdfile, tv_enable, да много их
3. Все остальные, которые можно указывать в server.cfg и прочих файлах.

Но в командной строке сервера очень много не укажешь как из-за ограничения по максимальной длине, так и из соображений безопасности — при отсутствии должным образом закрученных гаек, другие пользователи на вашем Linux сервере с доступом в шелл могут видеть процессы и командные строки друг друга — cat /proc/ /cmdline с такими деликатными параметрами, как rcon_password, tf_serveridentity , sv_setsteamaccount, sv_password и так далее.

Таким образом мы для начала будем использовать всего-навсего пять файлов для наших настроек — общие настройки для обоих серверов в файле autoexec.cfg, индивидуальные настройки первого сервера — autoexec1.cfg и server1.cfg, второго — autoexec2.cfg и server2.cfg. Целесообразность разделения индивидуальных настроек по двум файлам диктуется как вышеприведённым делением параметров на три категории, так и необходимостью использования файлов (типа server.cfg), которые выполняются при каждой смене карты — для восстановления параметров, изменённых в индивидуальных файлах настроек карт, либо вручную в консоли, либо по cron’у, либо иным способом. Ведь файлы типа autoexec.cfg выполняются лишь при старте игрового сервера.

Нельзя не упомянуть три очень полезные команды. Первая — echo «Какое-нибудь сообщение, выводимое на консоль сервера» . При использовании в начале каждого файла конфигурации позволяет наглядно видеть очерёдность выполнения различных файлов, в случае анализа неочевидного поведения сервера. Вторая — differences , при вводе в консоли сервера показывает все переменные, значения которых отличны от значений по умолчанию. Облегчает поиск ответа на вопрос «Почему всё не так? Вроде всё как всегда. «. Третья — exec — позволяет вызывать одни файлы конфигурации из других. При вдумчивой настройке, да в сочетании с возможностью замены файлов по cron и вкупе с возможностью их запуска из скриптов (посредством tmux send-keys — пример в скрипте update.sh в разделе «Обновление серверов») позволяет превратить игровой сервер в живой организм, живущий собственной жизнью.

Детальная настройка внутренней конфигурации игрового сервера здесь описываться не будет — у каждого она своя, остановимся лишь на моментах, связанных с одновременной работой двух серверов.

Если у вас уже есть готовые файлы настроек для одинокого сервера, то можно начать с них, а если нет (ну, мало ли — наш первый игровой сервер), то можно погуглить по фразе настройка server.cfg для tf2. Единственно что могу посоветовать — не искать чей-нибудь максимально навороченный файл конфигурации десятилетней давности, в котором перечислены все возможные, в том числе и уже устаревшие параметры, причём подавляющее большинство — со значениями по умолчанию и описаниями, взятыми из cvarlist, а искать актуальные и максимально документированные описания, хотя это может быть непросто, да.

Вообще, лучше начинать вовсе без готового server.cfg — игровой сервер прекрасно запустится и без него, мы в этом уже убедились, а вот когда захочется что-то поменять — количество и длительность раундов, автобалансировку команд и тому подобное — то тогда уже узнавать и прописывать параметры, которые этим управляют.

Если всё же хочется узнать «все-все-все» серверные публичные команды и переменные, то в консоли запущенного сервера достаточно ввести:

/tf2/tf/allcvars.txt будут перечислены все консольные переменные, зачастую с краткими описаниями. Можно выводить только команды с определённым префиксом, например, cvarlist tf_ , cvarlist sv_ . Можно искать по подстроке — find log . При этом поиск выполняется как по имени, так и по описанию.

Итак, создаём наши файлы конфигурации.

Стоит иметь в виду, что многие команды зависят друг от друга, и в ряде случаев важна их последовательность. Так, например, если сначала включить запись логов в файл (log on), а потом начать указывать в какой каталог (sv_logsdir) и под каким именем (sv_logfilename_format) — результаты будут не соответствовать ожиданиям.

/cfg/autoexec.cfg — он выполняется первым, прописываем настройки, общие для обоих серверов:

Более подробно команды управления логами рассмотрены в разделе «Логи».

Создадим (пока) пустые файлы banned_user.cfg и banned_ip.cfg

/cfg/autoexec1.cfg прописываем настройки для первого сервера:

Про файлы motd и mapcyclefile будет сказано чуть ниже. Каталог для логов сервер создаст сам.

А на второй сервер мы установим карту cp_orange_x3, не входящую в стандартную поставку Team Fortress 2. Простейший способ установки пользовательских карт — это положить файл с картой в

/tf2/tf/maps, либо в каталог в одном из поисковых путей. Но есть ещё способ подключения сторонних карт. Если такая карта представлена в Steam Workshop, то мы можем ссылаться на неё как на «workshop/», либо «workshop/ .ugc» и в команде map и в файле mapcycle. Тогда при запуске игры наш сервер скачает её с серверов Valve, а при подключении игрока, его компьютер сам скачает карту оттуда же. При каждой смене карты, она будет проверяться на наличие обновлений. При использовании нестандартных карт только из Steam Workshop, становится ненужным включение Fast Download. Но обратная сторона медали — появляется зависимость ещё и от Workshop серверов.

Итак, открываем в браузере Steam Workshop по ссылке выше, в строке поиска вводим «cp_orange_x3», в результатах поиска переходим на страницу карты — https://steamcommunity.com/sharedfiles/filedetails/?id=454299390. Из этого url берём числовой id и прописываем его в нашем autoexec2.cfg в формате «workshop/454299390» либо «workshop/cp_orange_x3.ugc454299390». Второй вариант нагляднее.

/cfg/autoexec2.cfg прописываем настройки для второго сервера:

Ещё один маленький момент. Для каждой карты можно создать файл-спутник .cfg — для команд, выполняемых сервером при старте этой карты, сразу после выполнения server.cfg. Для стандартных карт файл должен находится в

/tf2/tf/cfg. А для карт из Steam Workshop, имя файла конфигурации должно выглядеть как » .ugc.cfg» и находиться ему полагается в

/tf2/tf/cfg/workshop. Этот каталог единый для обоих игровых серверов, что следует учитывать, если оба сервера будут использовать одну и ту же карту из Steam Workshop. Для нашей карты cp_orange_x3, у которой id 454299390, полный путь к её файлу конфигурации будет выглядеть как

Для пользовательских карт возможность выполнения некоторых команд из таких файлов конфигурации регулируется серверной командой sv_allow_point_servercommand, по умолчанию имеющей значение «official» — Allowed for valve maps only. Для разрешения выполнения для любой карты необходимо установить её значение в «always» в autoexec2.cfg

Если захочется просто скачать какую-нибудь карту из Steam Workshop, то в консоли игрового сервера достаточно ввести команду tf_workshop_map_sync . При этом начнётся отслеживание этой карты — при ручном переходе на неё с помощью changelevel wohrkshop/ так же будет проверка на предмет обновления. Посмотреть отслеживаемые карты можно с помощью команды tf_workshop_map_status , ну или в файле

/cfg/server1.cfg прописываем команды для первого сервера, которые будут выполняться при каждой смене карты:

Если мы в какой-то момент отключим ведение логов и их попадание в статистику HLstatsX (ну мало ли зачем может понадобится — на отдельной карте для выполнения достижений, либо решили потусить с ботами) командой logaddress_delall в .cfg, или в консоли или как-то ещё, то указание параметра logaddress_add в server1.cfg обеспечит восстановление трансляции логов при смене карты. А команда logaddress_delall предваряет logaddress_add во избежание ругани «logaddress_add: 192.0.2.0:27500 is already in the list»

Читы у нас и так отключены, но при каждой смене карты всё равно устанавливаем sv_cheats в «0» — на случай, если для каких-то целей (генерация навигационной сетки, например) ранее ручками устанавливали в «1».

/cfg/server2.cfg прописываем аналогичные команды для второго сервера:

Далее создаём файлы со списком карт для ротации. Для первого сервера, на котором мы будем крутить карты лишь режима Control Point, мы за основу берём уже готовый mapcycle_quickplay_cp.txt, который при желании можно подправить.

Таким образом, в

/cfg/mapcycle1.txt у нас прописаны карты для ротации на первом сервере:

Для второго сервера файл с картами

/cfg/mapcycle2.txt создадим вручную. Карту cp_orange_x3 прописываем в том же формате, что и в autoexec2.cfg — «workshop/454299390», либо «workshop/cp_orange_x3.ugc454299390»:

Теперь создадим файлы с приветственными сообщениями игрокам. Можно в текстовом формате, можно с html разметкой, можно строку с url. При этом максимальный размер файла ограничен где-то 1-2 Кб.

Для первого сервера создаём

/cfg/motd1.html с гипертекстовым содержимым:

и текстовый файл

/cfg/motd1.txt для игроков, у которых отключён показ html motd (cl_disablehtmlmotd 1):

Для второго сервера в

/cfg/motd2.txt укажем внешний url, который будет загружен у игроков в motd окне игры:

Фишка с url срабатывает лишь для motdfile. При указании в motdfile_text, url будет просто показан как текст.

В интернете можно найти различные руководства по созданию MOTD — from Jimo, как вариант ещё одно.

Всё, основные файлы конфигурации на данном этапе созданы, делаем ссылки на них в каталог cfg игрового сервера:

Сетевые настройки

При запущенном сервере без параметров (как мы делали это в самом начале), если в другом окне терминала запустить netstat -lpn | grep srcds , то мы увидим:

Каждый игровой сервер использует свои порты. Они могут задаваться следующими параметрами при запуске srcds:

UDP/27005
+clientport — Game client port

UDP/27015
-port — The port the server advertises to clients

TCP/27015
порт для удалённой консоли, RCON, номер задаётся параметром -port , но использует протокол TCP. Если управление игровым сервером планируется осуществлять исключительно посредством терминального доступа с помощью ssh (а лучше — настроить и забыть), то этот порт с протоколом TCP (не UDP!) можно закрыть, либо вовсе не открыть на файерволе. Но только аккуратно, лишь на внешнем сетевом интерфейсе. Внутри сервера удалённая консоль энергично используется сервером статистики.

UDP/27020
-tv_port — SourceTV port (описан в соответствующем разделе «SourceTV»)

UDP/26901
-steamport — Steam/VAC connection port

Таким образом, для ручной установки этих же портов, используемых по умолчанию, мы в строке запуска первого сервера укажем «-port 27015 -steamport 26900 +clientport 27005 +tv_port 27020». Порт 26900 — это не ошибка, в действительности сервер будет использовать порт на единичку выше.

Для второго сервера надо указать другие значения. В интернете есть советы, что номера портов в подобных мультисерверных конфигурациях лучше увеличивать не последовательно, а через один (27015 -> 27017 -> 27019 и так далее). Но в нашем случае будем увеличивать последовательно. Вроде и так работает.

Тогда второй сервер будем запускать с параметрами «-port 27016 -steamport 26901 +clientport 27006 +tv_port 27021».

Конечно, можно порты не указывать вовсе, ни для первого сервера, ни для второго. В таком случае сервер, стартовавший первым будет использовать порты по умолчанию, а стартовавший вторым немножко ругнётся в логах:

и будет использовать следующие по порядку. Но всё же мы будем явно указывать номера портов в командной строке, да ещё припечатаем их параметром -strictportbind (описание будет ниже).

Естественно, ничто не запрещает использовать другие номера портов, хоть «-port 50000 +clientport 50001 +tv_port 50002 -steamport 50003», и при этом сервер будет виден через ISteamApps/GetServersAtAddress интерфейс и к нему в принципе можно будет подсоединиться и играть. Но в нашем примере мы будем более традиционны.

Скрипты запуска сервера

В обычных условиях нам придётся иметь дело с двумя скриптами-обёртками:

с консольным клиентом Steam —

/Steam/steamcmd.sh, который запускает программу linux32/steamcmd. В явном виде используется нами для установки и регулярных обновлений игровых серверов;
с собственно, самим игровым сервером —

/tf2/srcds_run, который запускает лежащий тут же srcds_linux, а тот уже игру.

Для настройки и отладки, когда приходится часто запускать/останавливать сервера, мы создадим скрипты для запуска —

/start2.sh. Потом их расширим и переделаем для автозапуска. Для первого сервера,

Пояснения по параметрам (начинаются с «-«) и консольным переменным (начинаются с «+»):

-port
порт для игры. Для первого сервера — 27015. При использовании иных портов, как у нас, необходимо не забыть их открыть на файерволе

-steamport
порт для VAC (Valve Anti-Cheat). В действительности будет использоваться на единичку выше. То есть указав 26900, в действительности будет 26901

+clientport
порт для подключения игроков

+tv_port
порт для SourceTV. Если принципиально не будем пользоваться, то можно вместо +tv_port указать параметр -nohltv

-strictportbind
если вышеуказанные порты заняты, то сервер не будет автоматически выбирать следующие свободные, а будет завершаться с ошибкой «ERROR: Port 27015 was unavailable — quitting due to «-strictportbind» command-line flag!». Будет повод почитать логи и найти ошибку.

-ip
ip адрес, на котором будет сервер. Можно указать какой-то конкретный, либо 0.0.0.0 — все интерфейсы. Мы параметр не устанавливаем, так как на нашем сервере только один сетевой интерфейс, с внешним ip

-game
запускаемая игра. У нас — «tf» — Team Fortress 2.

+maxplayers
максимальное количество игровых слотов на сервере. Этот параметр указывается только в командной строке. Значение по умолчанию — 24, может быть увеличено до 32. Для Mann vs. Machine должно быть 32

-pidfile
указывает файл для хранения PID сервера.

-ugcpath
каталог для скачиваемого контента из Steam Workshop. По умолчанию —

/tf2/steamapps/workshop. Можно указывать как абсолютный путь так и относительный, от каталога

/tf2/tf. Так как считается, что использование одного workshop каталога для нескольких игровых серверов не поддерживается и может вызвать проблемы, то для каждого сервера указываем свой.

+sv_pure
предназначение этой переменной — уменьшить возможность мошенничества игроков, которые могут у себя на локальном компьютере заменить игровые файлы на читерские (прозрачные текстуры, трассеры у выстрелов, текстуры игроков и так далее). Этот параметр может принимать значения -1, 0, 1, 2. При установке значения sv_pure от 0 и выше, при подключении к нашему серверу игрока, на его компьютере будет осуществляться проверка целостности ключевых файлов его инсталляции игры (контрольная сумма, цифровая подпись), что, очевидно, несколько замедляет подключение игроков. Критерии проверки описаны в pure_server_full.txt, pure_server_minimal.txt и pure_server_whitelist_example.txt из

/tf2/tf/cfg/. Для установки максимального уровня — sv_pure 2 , параметр должен указываться в командной строке srcds_run, чтобы он смог отработать ещё до того, как сервер при запуске начнёт загружать свои .vpk файлы.

+exec
имя файла, который будет выполняться при старте сервера сразу после autoexec.cfg. Может указываться несколько раз.

+servercfgfile
имя файла, который будет использоваться вместо server.cfg — как при запуске сервера, так и при каждой смене карт

+map
имя карты (без расширения). Можно не указывать здесь, но тогда необходимо указать в файле autoexec.cfg (не server.cfg !). Если не задать карту вообще, то сервер войдёт в ступор. Бывают рекомендации указывать этот параметр последним в командной строке. Но мы его не используем, начальную карту будем указывать в autoexec.cfg

Другие параметры командной строки можно посмотреть в Valve Developer Community wiki

Копируем скрипт в

/start2.sh, корректируем CMDLINE (увеличиваем на единичку номера портов и подправляем имена файлов), сохраняем.

Делаем скрипты исполняемыми

Можно запустить первый сервер (из-под пользователя game, не root !), сразу посмотреть что-как. Наблюдаем за последовательностью отработки файлов конфигурации:

Плохо, конечно, начинать отношения со лжи. И к серверам это тоже относится. Хотя наш сервер и утверждает, что логи записываются в файл L1007000.log, на самом деле они пишутся в l1007000.log. Разница в регистре первого символа имени — но для Linux какая существенная! Но, кто предупреждён — тот вооружён. Будем критически относится к декларируемым функциям. И забегая вперёд — не напрасно.

Теперь аналогично запускаем второй сервер, любопытствуем, как он подключит нашу карту из Мастерской.

Хорошо, годно. У второго сервера ресурсы из Steam Workshop скачались в

/tf2/steamapps/workshop2, и наша карта находится по пути

/tf2/steamapps/workshop2/content/440/454299390/cp_orange_x3.bsp. В строчках выше, «[ workshop/cp_orange_x3.ugc454299390 ]» — это не путь к карте, а её имя. Подробнее описывалось ранее, когда создавали файл autoexec2.cfg

Снова запускаем на своём компьютере Team Fortress 2, «Find a game» — «Community servers» — «Избранное» — «Добавить» — вводим ip адрес сервера «192.0.2.0» — «Найти игры по этому адресу» — видим оба наших сервера. Работает :-). Добавим их в закладки.

Можно посмотреть, как видны наши сервера с точки зрения мастер-серверов Valve с помощью интерфейса Web API, открыв в браузере ссылку и указав ip нашего сервера http://api.steampowered.com/ISteamApps/GetServersAtAddress/v0001?addr=192.0.2.0 — так можно посмотреть все игровые source сервера на любом адресе, не только Team Fortress 2

Останавливаем сервера (quit, затем Ctrl+C), продолжаем настройку.

Завершать работу сервера, запущенного посредством srcds_run, как в наших скриптах, лучше всего введя сначала команду quit , а когда на экране появится завершающее работу сообщение вида «Sat Jun 18 10:28:33 VOST 2016: Server restart in 10 seconds», то тут уже Ctrl+C. Если прибить сервер без корректного выхода, то останутся недописанными логи — сервер буферизирует их вывод по 8 кб. Можно пропустить что-нибудь напоследок интересное.

Обновление серверов

Обычно процедуре обновления серверов посвящают всего десяток строчек, и, положа руку на сердце, для большинства конфигураций этого достаточно, но в нашем случае уделим этому вопросу целый раздел.

Время от времени Valve выпускает обновления как для клиентов, так и для серверов, и обновлённые клиенты зачастую отказываются подключаться к необновлённым серверам:

Обновления для серверов бывают обязательные — без установки которых обновлённые клиенты не смогут подключиться к ним, и опциональные — их (не)установка не повлияет на возможность подключения игроков. Отличить обязательные от необязательных можно очень просто — по анонсу ответственных товарищей из Valve в официальном списке рассылки https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux. Когда они пишут, что «Optional TF2 update released» — то это не обязательное обновление. А когда «Mandatory Team Fortress 2 update released» — то это обязательное. Серъезно. На момент написания, по их словам, единственный официальный способ узнать о выпуске нового обновления — это список рассылки hlds_linux.

Обновлять игровые сервера можно несколькими способами.

Автоматическое

В простейшем случае обновление игровых серверов мы можем отдать на откуп им самим — включив в параметры запуска обоих серверов строку:

-autoupdate
будут автоматически устанавливаться обновления сервера. Требует наличия двух следующих параметров

-steam_dir
путь к каталогу где лежат файлы steam.sh и steamcmd.sh

-steamcmd_script
скрипт для обновления, ищется в «-steam_dir», но можно указать с абсолютным путём

На самом деле, эта триада параметров перед каждым (пере)запуском сервера всего лишь выполняет ./srcds_run +runscript

/cfg создаём файл tf2_update — в нём укажем команды для автоматического обновления сервера. Эти команды в сущности повторяют те, которые мы указывали в командной строке при инсталляции игрового сервера.

Пояснения по командам:

@ShutdownOnFailedCommand
руководство Valve рекомендует устанавливать эту переменную в «0» при обновлении нескольких игровых серверов.

@NoPromptForPassword
данная переменная, установленная в «1», при логине в Steam отключает интерактивный запрос пароля, если он не указан в строке login. Если пароль для данного имени пользователя всё же требуется, то во входе будет отказано.

] [ ]
осуществляет логин в Steam. В данном случае должна быть указана обязательно, иначе при запуске будет выдавать ошибку «ERROR! Failed to request AppInfo update, not online or not logged in to Steam.» Первым аргументом можно указать «anonymous» — будет осуществляться анонимный вход. Применительно к выделенным игровым серверам, большинство позволяют подключаться анонимно для инсталляции и установки обновлений, но некоторые могут требовать вход по имени пользователя и паролю. Список серверов с их требованиями и некоторыми параметрами можно посмотреть в Dedicated Servers List. При неанонимном логине, как обычно при входе с нового компьютера, на электронную почту приходит код steam guard, который указывается либо здесь, либо в отдельной команде set_steam_guard_code.

set_steam_guard_code
указывается код steam guard. Для анонимного логина не используется.

force_install_dir
по умолчанию программы устанавливаются в каталог ./SteamApps/common/ . Если мы хотим установить в другой, то указываем его как параметр данной команды. Должно быть указано до команды app_update.

]
начинает скачивать (если ещё не), либо обновлять существующую инсталляцию программы. Необходимо указание appid. Возможно указание опции validate — в этом случае будет осуществляться проверка целостности инсталляции и, при необходимости, дополнительно скачиваться отсутствующие либо изменённые файлы. По факту, аналогично выполнению команды «Проверить целостность кэша. » в клиенте Steam, с той разницей, что выполняется для игрового сервера. Очевидно, что существенно замедляет обновление, и лучше её указывать вручную, когда возникает такая необходимость, как мы это делали при первоначальной инсталляции сервера.

Подробнее по командам и переменным клиента Steam можно почитать в родной справке, запустив steamcmd.sh без параметров. Работают команды help , find .

Когда в процессе своей жизнедеятельности игровой сервер получает от мастер-серверов Steam информацию о новом обновлении, он начинает каждые пять минут канючить о необходимости перезапуститься.

В консоли сервера:

При при очередных сменах карт сервера завершат работу, выполнят команды из

/cfg/tf2_update и, обновлённые, запустятся заново. При этом ничего страшного не произойдёт даже в случае одновременной смены карт и обновления.

Ну, может, кроме повышенного расхода траффика.

В подавляющем большинстве случаев достаточно использовать этот режим обновлений. Но бывают варианты, когда на одном из серверов карта меняться будет очень нескоро, а то и вовсе не будет. Ведь если специально не устанавливать критерии окончания игры на данной карте, ограничивая количество раундов (переменная mp_maxrounds, по умолчанию = 0), побед (mp_winlimit = 0), фрагов (mp_fraglimit = 0), таймаут (mp_timelimit = 0), и так далее, то не будет смены карты и, как следствие, обновления. Да и мало ли какие карты и игровые режимы захочется использовать на том же втором сервере, и жалко терять новых игроков из-за того, что они не могут подключиться к нашему устаревшему серверу.

Тогда на помощь приходят другие варианты.

Периодическое обновление

Мы можем зайти с другой стороны — регулярно по cron запускать steamcmd.sh с командами установки обновлений (да, «по-живому»), анализировать результаты и при успешном обновлении инициировать перезапуск игровых серверов.

Так, при запуске

/cfg/tf2_update и при отсутствии обновлений сервера, steamcmd.sh порадует нас сообщением:

При наличии обновлений, после автоматического скачивания и в случае успешной установки:

Вот на «fully installed» и будем проверять. Реализовываем. Создаём скрипт

Да, установку обновлений можно запускать, как указывая параметры в командной строке steamcmd.sh — «+login anonymous +force_install_dir

/tf2/ +app_update 232250 +quit», так и с помощью ранее созданного файлика tf2_update — «+runscript

Скрипт минималистичен и жесток, поэтому в таком виде его использовать не будем. А вот после окончательной настройки запуска игровых серверов, как в разделе «Автозапуск игровых серверов», с использованием tmux в скриптах запуска и настройки sudo, можно предварительно предупреждать пользователей о грядущем рестарте, да и выполнять его цивилизованнее. Тогда скрипт примет более приемлемый вид:

Вместо «say», если уже установлен SourceMod можно использовать его варианты команд.

Такой вариант обновления активируем через наш crontab файл, не забывая сделать сам скрипт исполняемым:

Прописываем запуск каждые полчаса:

Настройка перенаправления логов cron в лог, доступный пользователю game описано в разделе «Логи»

Только проверка

В некоторых случаях может потребоваться лишь проверить наличие обновлений, не устанавливая их прямо сейчас.

У Valve имеется Steam Web API. Проверять наличие обновлений программ можно с использованием интерфейса ISteamApps/UpToDateCheck, например, для самой игры Team Fortress 2 — http://api.steampowered.com/ISteamApps/UpToDateCheck/v1?appid=440&version=3528598, указав в параметре version текущую версию игры (либо просто какую-нибудь цифру). Но при выборе appid = 232250 (а, равно, как и для многих других выделенных серверов), выдаётся ошибка «Couldn’t get app info for the app specified.». Увы.

Но, к счастью, именно для нашего Team Fortress 2 dedicated server есть отдельный интерфейс — https://api.steampowered.com/IGCVersion_440/GetServerVersion/v1?format=json. При выполнении выдаётся что-то вида:

Формат выводимой информации можно указывать в строке запроса — json, xml, vdf. Последний — Valve Data Format, проприетарный формат Valve, очень похожий на json и легко в него конвертируемый. Используется во многих файлах — items_game.txt, в Записях, в .acf, .vdf и так далее.

Вообще, поля deploy_version и active_version используются Valve для отслеживания версий, запущенных на их собственных серверах, и они не обязаны всегда совпадать с текущими публичными версиями. Но, с учётом этих рисков, всё же можно попробовать использовать данный api.

Узнать установленную у нас версию сервера можно введя version в консоли сервера, либо посмотрев в

Таким образом, при необходимости, можно периодически проверять актуальную версию сервера через Web API, сравнивать с установленной у нас, ну а непосредственно обновление и рестарт игровых серверов были описаны выше. Например как-то так:

Всё, можно включать в crontab.

Справедливости ради, это далеко не единственные способы получения информации об обновлениях. Помимо того, что ещё скрывается в недрах Steam Web API, текущий билд нашего сервера можно посмотреть в

/tf2/steamapps/appmanifest_232250.acf, параметр «buildid». Актуальную версию можно запросить — steamcmd.sh +login anonymous +app_info_update 1 +app_info_print 232250 +quit , а там смотрим значение параметра «buildid» из пути depots -> branches -> public (иногда app_info_print тупит, показывает устаревшую закешированную информацию, не спасает даже app_info_update 1. Тогда поможет предварительное rm -f

/Steam/appcache/appinfo.vdf). Автоматически извлекать номера билдов можно как цепочкой из полудюжины grep, cut, tr и прочих команд, с известными допущениями о структуре и порядке строк, так и путём приведения исходных данных к формату json (хотя бы с помощью sed + tr) с последующим использованием стандартных инструментов.

Окончательный выбор способа обновления будет сделан в разделе «Автозапуск игровых серверов».

Источник