Server cfg ��� linux

Основные конфигурационные файлы Linux

Операционная система Linux в отличие от Windows не имеет общего реестра для хранения настроек системы, все настройки хранятся в конфигурационных файлах. Большинство этих файлов размещено в папке /etc/.

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

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

Конфигурационные файлы Linux

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

Как я уже сказал, большинство файлов размещено в /etc. Название этой папки расшифровывается как «et cetera», что с латинского означает «и другие» или «и так далее». Сначала давайте посмотрим содержимое каталога /etc Linux:

Здесь достаточно много различных файлов. Дальше мы рассмотрим назначение многих из них. Список отсортирован по алфавиту.

1. /etc/adjtime

Этот конфигурационный файл отвечает за настройку формата системного времени и читается службой systemd-timedated. Время может быть представлено в двух вариантах: LOCAL — время текущего часового пояса и UTC — время по Гринвичу. Вы можете вручную менять значение или воспользоваться утилитой timedatectl.

2. /etc/bash.bashrc

Этот файл принадлежит командной оболочке bash. Это не совсем конфигурационный файл — а скрипт, его содержимое выполняется при запуске каждого экземпляра bash для настройки оболочки. Точно так же выполняется содержимое файла

/.bashrc для каждого пользователя.

3. /etc/crontab

Crontab — файл настройки планировщика cron. Здесь записываются все задания, которые должен выполнить планировщик, а также время и периодичность. Этот файл не принято редактировать напрямую. Для этого используется утилита crontab -e.

4. /etc/environment

Здесь содержатся переменные окружения, которые будут загружены для каждого сеанса терминала, независимо от того запущен он на локальной машине или по ssh. Файл читается скриптами Bash во время инициализации оболочки.

5. /etc/fstab

Наверное, все уже знают файл /etc/fstab. Здесь выполняется настройка монтирования файловых систем во время загрузки. В современных системах он читается systemd и все записи на ходу транслируются в юнит-файлы, с помощью которых уже выполняется монтирование. Смотрите также: автоматическое монтирование fstab.

6. /etc/group

В этом файле хранятся все группы пользователей, которые есть в системе. С помощью него вы можете посмотреть список групп, их идентификаторы или добавить новые. Но добавлять группы с помощью редактирования файла не принято, для этого есть утилита usermod.

7. /etc/hostname

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

8. /etc/hosts

Файл /etc/hosts позволяет задавать псевдонимы для различных сетевых узлов. Таким образом, компьютер не обращается к DNS для получения IP домена, а берет его из hosts. Это позволяет, например, заблокировать доступ к нежелательным сайтам просто перенаправив их на localhost или же получить доступ к сайту по ip, которому еще не присвоен домен.

9. /etc/hosts.allow и /etc/hosts.deny

С помощью этих двоих файлов можно настраивать права доступа ко всем локальным службам. Например, вы можете разрешить доступ к службе apache только с локального компьютера. Это очень сильно повысит безопасность системы, если ваш компьютер подключен к публичной сети.

10. /etc/issue и /etc/issue.net

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

11. /etc/ld.so.conf

В этом файле содержатся пути к папкам, в которых компоновщик linux ld.so будет искать динамические библиотеки во время запуска программ. Папки /lib64, /lib, /usr/lib64 и /usr/lib будут проверены автоматически.

12. /etc/localtime

Это символическая ссылка, которая указывает на файл часового пояса в папке /usr/share/zoneinfo/. Редактировать файл не нужно, а для изменения настроек нужно создать символическую ссылку на другую временную зону.

13. /etc/login.defs

Файл /etc/login.defs отвечает за настройку поведения утилиты управления пользователями и параметры входа в систему. Вы можете настроить какой минимальный и максимальный id нужно выдавать, что делать с папкой пользователя при удалении и многое другое, количество попыток входа и таймаут, а также многое другое.

14. /etc/mime.types

В этом файле содержатся общесистемные правила преобразования расширений файлов в понятные системе MIME типы данных. Затем уже система выбирает, чем открыть тот или иной тип данных.

15. /etc/modprobe.d/

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

16. /etc/modules-load.d/

Папка /etc/modules-load.d/ содержит файлы со списками модулей, которые должны быть загружены при запуске системы. Имя файла не важно, но он должен иметь расширение .conf.

17. /etc/nsswitch.conf

Этот файл задает настройки порядка разрешения имен в системе для всех программ, написанных на Си или С++. Например, нужно сначала просматривать локальную сеть и систему, или сразу же отправлять запрос к DNS.

18. /etc/ntp.conf

Файл ntp.conf отвечает за настройку службы синхронизации времени — ntpd. В файле указаны адреса ntp серверов, с которых служба будет получать время, а также общие настройки.

19. /etc/os-release

Отображает очень подробную информацию об установленном дистрибутиве:

20. /etc/passwd

Файл содержит список всех зарегистрированных в системе пользователей, а также дополнительные настройки для них, например, оболочку, дату смены пароля и дату отключения аккаунта, кроме самого пароля. Напрямую файл лучше не редактировать, а использовать утилиту для управления пользователями adduser или deluser.

21. /etc/profile

Файл /etc/profile, точно так же как и /etc/environment загружается и выполняется при запуске любой командной оболочки в системе. Но в отличие от environment, это скрипт, а значит, он может задавать не только переменные, но и выполнять различные команды для инициализации оболочки.

22. /etc/resolv.conf

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

23. /etc/sddm.conf

Это конфигурационный файл Linux для настройки менеджера входа sddm, для других менеджеров входа будут свои файлы настройки. Здесь можно изменить максимальный и минимальный ID пользователя, который может войти в систему, например, чтобы разрешить авторизацию root, изменить тему, добавить вход без пароля и многое другое.

24. /etc/shadow

Раньше пароли пользователя содержались в файле /etc/passwd, но поскольку к нему мог получить доступ любой пользователь, это было небезопасно, несмотря на то, что пароли зашифрованы. Поэтому все пароли были вынесены в /etc/shadow. Вы можете изменить пароль пользователя.

25. /etc/sudoers

/etc/sudoers — это файл настройки прав доступа к утилите sudo. Эта утилита позволяет выполнять команды от имени других пользователей, в том числе от имени суперпользователя. Но использовать ее могут только те пользователи, которые прописаны в этом файле.

26. /etc/sysctl.conf

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

27. /etc/vconsole.conf

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

28. /boot/grub/grub.cfg

Этот конфигурационный файл Linux находится не в /etc из-за своего особого предназначения. Здесь содержатся все настройки загрузчика, пункты меню и другие параметры, поэтому он должен быть доступен еще до того как была подключена корневая файловая система.

Выводы

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

Источник

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

Записи

Записи (Replays) в Team Fortress 2 — это возможность, на стороне сервера — создания записи последней жизни игрока, а на стороне клиента — её просмотра, редактирования, сохранения и публикации. Является расширением SourceTV.

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

Настройка веб-сервера

Для наглядности мы заведём в DNS отдельный поддомен replay.example.org, создадим каталог /var/www/replay.example.org, и для удобства вынесем запись логов в отдельные файлы и предоставим возможность пользователю game читать их.

Из-под root создаём каталоги, устанавливаем владельца (game:game) и права — пользователю game на запись, остальным (веб-серверу) — на чтение. Можно заодно сделать символьные ссылки для удобства. Данный веб-сервер будет общим для обоих игровых серверов, но каждый из них будет использовать отдельные каталоги для выкладывания записей.

В нашей конфигурации по умолчанию все логи веб-сервера имеют владельца nginx:adm и права 640, то есть они недоступны обычным пользователям. Корректируем это для данного случая:

Таким образом пользователю game наши логи станут доступны для чтения. Но только до первой их ротации. Исправляем и это. В каталоге /etc/logrotate.d копируем файл nginx в srcds-nginx, в нём прописываем путь к логам и в строчке create 640 nginx adm исправляем маску прав доступа с 640 на 644:

Здесь мы в путях для ротации указали заодно каталоги с логами от сервера статистики HLstatsX и от сервера Fast Download.

Из-под root создаём файл конфигурации веб-сервера, /etc/nginx/conf.d/replay.example.org.conf:

Это, конечно, несколько упрощённый вариант. Так как в нашем случае веб-сервер находится на том же компьютере, что и игровые сервера и делит с ними один канал в интернет, то имеет смысл прописать дополнительные ограничения по ширине канала для отдачи записей. Но, в отличие от настроек Fast Download, устанавливать дополнительные проверки по referer нет необходимости.

Прописываем вызов replay.example.org.conf в основной файл /etc/nginx/nginx.conf если ещё не, затем тестируем конфигурацию и перезапускаем nginx.

Далее продолжаем как пользователь game.

Настройка игрового сервера

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

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

/tf2/tf/cfg есть файл replay_example.cfg, изучаем его и создаём свой собственный. Для первого сервера,

replay_name
имя специального бота для записи, как он будет виден в списке наблюдателей (spectators).

replay_local_fileserver_path
каталог, куда будут помещаться готовые файлы с записями. Должен быть индивидуальным для каждого игрового сервера и доступен для чтения веб-сервером.

replay_fileserver_offload_enable
если 1 — то записи выгружаются по ftp на другой сервер, который уже сам их раздаёт по http. Не наш случай.

если 0 — то раздачей занимается веб-сервер на нашей машине.

replay_fileserver_host
имя или ip веб-сервера

replay_fileserver_path
часть url — путь к записям, как отображается веб-сервером.

replay_enable
собственно, включает записи на сервере.

Таким образом из переменных replay_local_fileserver_path, replay_fileserver_host, replay_fileserver_path и не упомянутых здесь replay_fileserver_protocol (=»http») и replay_fileserver_port (=»80″) формируется url вида «http://replay.example.org:80/server1», который передаётся клиенту для скачивания записей. А переменная replay_local_fileserver_path задаёт фактическое местоположение каталога в файловой системе и равна root из файла конфигурации nginx + replay_fileserver_path.

Копируем этот файл в replay2.cfg, исправляем пути server1 -> server2

Делаем ссылки в

Стоит иметь в виду, что эти файлы конфигурации выполняются лишь при первоначальном запуске сервера, после autoexec.cfg. При смене карт они не задействуются.

Ещё из более-менее полезных консольных переменных:

replay_dopublishtest
проводит тест готовности сервера (игрового и веб) к записям — проверят доступность путей в файловой системе, имя веб-сервера и так далее.

replay_data_lifespan
задаёт количество дней (по умолчанию 1 сутки), по прошествии которых записи на сервере будут помечаться как «несвежие», что позволит ручной или автоматической очистке их удалить.

replay_docleanup
удаляет «несвежие» записи. С параметром ‘force’ удаляет вообще все записи.

replay_fileserver_autocleanup
по умолчанию 0 — выкл, запускает автоматическую очистку «несвежих» записей между раундами.

replay_dofileserver_cleanup_on_start
по умолчанию 1 — вкл, при старте сервера запускает автоматическую очистку «несвежих» записей, как в

/tf2/tf/replay/server<1,2>, так и в каталоге веб-сервера /var/www/replay.example.org/htdocs/server<1,2>.

replay_record_voice
по умолчанию 1 — вкл, записывать голосовой чат игроков.

Список актуальных, в данной версии движка Steam, переменных можно посмотреть, введя в консоли сервера find replay_ .

Включение

В скрипты запуска серверов start<1,2>.sh, в командную строку мы дописываем:

Для первого сервера:

Здесь команда «-replay» включает функции записи и при запуске сервера выполняет указанный файл конфигурации. Вторая команда, «-replayserverdir» в качестве параметра принимает имя каталога (от пути

/tf2/tf/replay/), в котором каждый сервер будет накапливать записи.

Всё, можно запускать сервера и пробовать. В игровом клиенте, в браузере серверов около имени нашего сервера, рядом с щитком VAC появится характерная иконка Записей.

При включении записей, на сервере появляется бот в режиме наблюдателя, который собственно и ведёт записи и при этом занимает один игровой слот. Поэтому установленное при запуске сервера максимальное количество игроков «+maxplayers 24» увеличивается на одного, то есть в нашем случае становится равным двадцати пяти (а при включении SteamTV — двадцати шести).

В старых руководствах по настройке записей обычно указывается параметр командной строки сервера «-replay_port», но мы про него и не упоминаем, так как он был отменён ещё в далёком 2011 году — store.steampowered.com/news/6282/

При использовании плагинов, облегчающих массовые действия над игроками (в том числе идущие в комплекте с SourceMod), следует аккуратно относиться к боту записей. Во всяком случае, не стоит ненароком кикать его с сервера 🙂

Обслуживание

Файлы записей, хотя и невелики по размеру, но всё же занимают место на диске, как в каталоге replay, так и в /var/www/. И бывает, что, несмотря на установленную дату старения в одни сутки (replay_data_lifespan 1) и включенную автоочистку этих каталогов (replay_dofileserver_cleanup_on_start 1), старые файлы автоматически не удаляются. Даже при ручном запуске replay_docleanup. Поэтому для подстраховки добавим принудительную очистку старых записей, запустив crontab -e и дописав в конец:

Предварительно неплохо бы убедиться, что cron использует шелл, поддерживающий расширение скобок — «<1,2>«

Чтение access.log показывает, что порой игроки, а точнее их игровые клиенты при подключении к нашему серверу пытаются сказать записи игр, в которые они играли и три недели назад.

Ещё момент — следует учитывать, что Записи кушают процессорное время. Пример загрузки приведён в конце раздела «Боты»

SourceTV

Теперь настроим SourceTV. Это пригодится для онлайн трансляций мировых чемпионатов, когда мы будем их у себя проводить.

SourceTV позволяет зрителям, посредством своих клиентов Team Fortress 2 наблюдать за ходом игры на сервере. При использовании цепочек прокси серверов, размер аудитории практически не ограничен, но в данном случае, когда трансляция игры будет осуществляться лишь силами нашего игрового сервера, количество зрителей имеет смысл лимитировать, так как каждый из них потребляет и ресурсы процессора и канал в интернет.

Так как при первоначальной настройке запуска игровых серверов мы уже указали в командной строке «+tv_port» со своим номером порта для каждого сервера, то можно сразу перейти к файлам конфигурации.

Так же как и для настройки записей, SourceTV должен быть активирован до загрузки карты, то есть команда «tv_enable 1» должна быть выполнена либо в командной строке запуска сервера либо в файле autoexec.cfg. Вдобавок, опытным путём было установлено, что аналогичное требование и у команды «tv_name».

Поскольку настройки SourceTV наших серверов фиксированы и при каждой смене карты меняться не планируются, то все общие мы включим в autoexec.cfg, индивидуальные — в autoexec<1,2>.cfg.

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

tv_title
заголовок в окне у зрителя при просмотре трансляции.

tv_password
пароль на подключение к трансляции.

tv_maxclients
максимальное количество зрителей, от 0 до 255, по умолчанию 128. Если нужна не онлайн трансляция, а только запись игры (tv_record, tv_autorecord), то можно выставить в ноль.

tv_maxrate
максимальная ширина канала на каждого игрока, по умолчанию — 8000 бит/сек, при установке в 0 — без ограничений. Параметр тесно увязан с предыдущим параметром, особенно если планируется полностью заполненный зрителями сервер.

tv_transmitall
по умолчанию («0»), зрителям передаётся лишь то, что показывает оператор SourceTV (ИИ либо специально обученный человек). При установке в «1», зрителям передаётся вся информация об игре, и они могут переключаться между POV от разных игроков, либо вообще парить над/под картой. При включении параметра в два-три раза увеличивается требуемая ширина канала для каждого зрителя.

tv_delay
задержка трансляции зрителям в секундах, по умолчанию 30. Служит для уменьшения читерства, когда зритель может давать подсказки игроку.

tv_delaymapchange
задерживать («1») или нет («0» — по умолчанию) смену карты, до тех пор, пока не закончится трансляция (из-за задержки tv_delay).

tv_delaymapchange_protect
защищает («1» — по умолчанию) или нет («0») от смены карты вручную до тех пор, пока не закончится раунд.

tv_allow_camera_man
разрешать («1» — по умолчанию) или нет («0») игрокам-наблюдателям становиться операторами SourceTV. Если «0» — то только автоматическое управление камерой.

tv_autorecord
при включении («1») автоматически начинаются записываться все игры в файлы с именами вида auto- — — .dem в каталог

/tf2/tf, например «auto-20160630-2208-koth_sawmill.dem».

При установке пароля («tv_password «), зрители не смогут подключиться из браузера серверов — им постоянно будет отказано с сообщением: «Disconnect: Bad spectator password», а в консоли сервера будет написано «Dropped from server (Bad spectator password)». Для подключения, зрителям надо будет в консоли (

) игры ввести password , закрыть консоль, а затем попробовать подключиться. Либо сразу в консоли ввести connect 192.0.2.0:27020; password .

/cfg/autoexec1.cfg дописываем в конец:

tv_name
имя SourceTV сервера, как оно будет показываться в браузере серверов, в закладке «Наблюдение».

tv_enable
включает («1») или нет («0», по умолчанию) SourceTV на сервере.

А вот для второго сервера мы в autoexec2.cfg отключили автоматическую запись. Существует проблема при включении автоматической записи («tv_autorecord 1») на картах, подключённых из Steam Workshop, у которых имя выглядит как «workshop/», либо «workshop/.ugc» — то есть в любом случае содержит слеш «/», что приводит к корявому формированию имени файла у tv_autorecord в схеме auto- — — .dem и ругани в логах вида:

и, как следствие, отключению записей. Как вариант, можно продумать схему с использованием «tv_record», позволяющей ручное указание имени файла для записи.

При включении SourceTV на сервере появляется бот в режиме наблюдателя, который занимается трансляцией игры и при этом занимает один игровой слот. Поэтому установленное при запуске сервера максимальное количество игроков «+maxplayers 24» увеличивается на одного, то есть в нашем случае становится равным двадцати пяти (а при включении Replay — двадцати шести).

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

Итак, в начале максимальное количество игроков на сервере было увеличено с 24 до 25 — это отработал параметр командной строки «-replay», включились записи. Затем ещё один дополнительный слот был добавлен для SourceTV — это сработал «tv_enable 1» из autoexec1.cfg. На ругань про invalid steam ID [A:1:0:1] не обращаем внимание — это наши боты записи и трансляции, ради которых сервер добавил игровые слоты. Далее началась запись демки в файл

/tf2/tf/auto-20161008-1155-cp_granary.dem — сработал параметр «tv_autorecord 1» из autoexec.cfg. И наконец нам констатировали, что SourceTV broadcast active.

Заработало. Можно заселить какую-нибудь карту ботами, подключиться зрителем и посмотреть, как выглядит трансляция при различных режимах tv_transmitall, tv_allow_camera_man.

Может случиться так, что слоты добавлены, а про «SourceTV broadcast active.» ни слова, да и при вводе в консоли сервера команда tv_status оно ругается «SourceTV not active.», хотя введённая тут же tv_enable сообщает что всё ок — «tv_enable = 1 ( def. 0 )». В таком случае надо попробовать сменить карту — changelevel . Если после смены всё заработало — то значит всё же SourceTV изначально так не активировался до загрузки первой карты — надо смотреть настройки.

Команды, которые могут пригодиться:

tv_record
начинает запись, сохраняемую в файл . Записываются все события, вне зависимости от того, что видит оператор.

tv_stoprecord
останавливает запись.

tv_clients
показывает информацию о подключённых зрителях.

tv_msg
отправить сообщение всем зрителям (появится посреди экрана).

tv_status
выводит краткую информацию о статусе сервера — время онлайн, FPS, количество зрителей, используемую полосу канала и тому подобное.

Список актуальных, в данной версии игрового сервера, переменных можно посмотреть, введя в консоли сервера find tv_ .

Ускорение скачивания контента (Fast Download)

Если мы будем использовать на своих серверах карты, модели, звуки, не входящие в стандартную поставку Team Fortress 2 и отсутствующие в Steam Workshop, то при подключении нового игрока ему необходимо будет скачать к себе на игровой компьютер наши игровые материалы (если их у него ещё нет). По умолчанию они будут скачиваться с нашего игрового сервера — этот режим называется Slow Download. Но так как игровой сервер это всё же не специализированный веб-сервер, то при частой установке новых пользовательских карт и высокой нагрузке, разумно было бы возложить функции по отдаче карт (а также звуков, моделей и так далее) на специально обученный веб-сервер. Который, по счастливому стечению обстоятельств у нас уже есть. Этот функционал и называется Fast Download.

Настройка веб-сервера

Для использования Fast Download необходимо указать веб-серверу использование каталога со структурой подкаталогов вида

где «dir» — корневой каталог для Fast Download. Создать его в /home/game мы не можем — домашний каталог у нас с правами rwx——, что не позволяет веб-серверу видеть эти файлы. Поэтому мы создадим эти каталоги где-нибудь вне пределов домашней директории пользователя game.

Для упрощения настройки, пропишем у себя в DNS отдельный поддомен fastdl.example.org, создадим каталог /var/www/fastdl.example.org, и для удобства вынесем запись логов в отдельные файлы и предоставим возможность пользователю game читать их.

Из-под root создаём каталоги, устанавливаем владельца (game:game) и права — пользователю game на запись, остальным (веб-серверу) — на чтение. Можно заодно сделать символьные ссылки для удобства. Каталог Fast Download будет общим для обоих игровых серверов.

В нашей конфигурации по умолчанию все логи веб-сервера имеют владельца nginx:adm и права 640, то есть они недоступны обычным пользователям. Корректируем это для данного случая:

Таким образом пользователю game наши логи станут доступны для чтения. Но только до первой их ротации. Исправляем и это. В каталоге /etc/logrotate.d копируем файл nginx в srcds-nginx, в нём прописываем путь к логам и в строчке create 640 nginx adm исправляем маску прав доступа с 640 на 644:

Здесь мы в путях для ротации указали заодно каталоги с логами от сервера статистики HLstatsX и от сервера с записями.

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

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

Обращаем внимание на referer. Учтём это при настройке.

Итак, принимаемся за настройку веб-сервера. Сначала сделаем определение, с правильным ли referer скачивают нашу карту. В главном файле /etc/nginx/nginx.conf, в секции http <>, перед включением файла конфигурации для нашего виртуального хоста fastdl.example.org, вписываем:

Тут всё просто. Если заголовок $http_referer соответствует одному из наших серверов, то переменная $bad_client (со значением по умолчанию 1) принимает значение 0.

Теперь создаём файл конфигурации нашего виртуального сервера /etc/nginx/conf.d/fastdl.example.org.conf.

Тут ещё проще — проверяем ту переменную $bad_client, и к нарушителям применяем санкции.

Вообще, у nginx есть директива valid_referers, но для нашего нестандартного $http_referer, с его нетипичной схемой, да и номером порта её не очень удобно применять. С map нагляднее.

Прописываем вызов fastdl.example.org.conf в основной файл nginx.conf если ещё не, затем тестируем конфигурацию и перезапускаем nginx.

Далее продолжаем как пользователь game.

Настройка игрового сервера

Пользовательские карты весьма хорошо сжимаются, поэтому их можно отдавать игрокам в архивированном виде (в формате bzip2), но при этом необходимо иметь несжатую карту (.bsp) в соответствующем каталоге игрового сервера. Например, если мы где-нибудь разжились понравившейся нам картой cp_orange_x5 (данная карта приведена только для примера — она существует в природе, но на момент написания материала её не было в Steam Workshop), то делаем следующее:

То есть нестандартные карты мы будем хранить в каталоге

/fastdl/maps, рядом с сжатыми и символьной ссылкой подключать в каталог к стандартным. Вариант, конечно, обсуждаемый, но не лучше и не хуже других. Файлы конфигураций для карт вида .cfg необходимо создавать в

/tf2/tf/cfg (ну или просто в

/cfg, а туда указывать ссылкой).

Теперь прописываем настройки игрового сервера в

Проверим как всё работает. Если сервер не запущен, то запускаем. Если он уже работает, то перезапускаем, чтобы вынудить его перечитать autoexec.cfg с нашими новыми настройками Fast Download.

Вообще-то вполне себе допускается вызов одних файлов конфигурации из других — exec или из консоли. Тогда можно те же команды Fast Download вынести в отдельный файл конфигурации, включить вызов его в autoexec.cfg, а при необходимости «освежить» настройки запускать его ручками в консоли, либо вызывать из того же server.cfg. Может быть удобно при отладке настроек, чтобы каждый раз не перегружать игровой сервер. Хотя его перезагрузка позволит отработать изменения, внесённые но забытые в тот же autoexec.cfg 🙂

У себя в игровом компьютере в каталоге SteamApps\common\Team Fortress 2\tf\download\maps\ ищем cp_orange_x5.bsp, если есть — удаляем (нам надо чтобы она скачалась заново).

Запускаем у себя игру, подключаемся к нашему серверу, смотрим, скачивается ли карта с Fast Download (в окошке должно быть написано именно «Downloading maps/cp_orange_x5.bsp.bz2» — с .bz2 расширением):

(На картинке карта _x3, но суть та же).

Естественно, предполагается что у игроков в настройках клиента разрешена загрузка контента с сервера, как минимум «Загружать только карты» (cl_downloadfilter mapsonly), иначе будет выдано сообщение «Map is missing».

Можем попробовать браузером скачать карту http://fastdl.example.org/maps/cp_orange_x5.bsp.bz2, если видим «403 Forbidden» — так и должно быть, referer не hl2://192.0.2.0 , радуемся.

Раз мы заявили возможность Fast Download (указав не пустой параметр sv_downloadurl), то при скачивании с веб-сервера, что хорошо видно в его логах, у игроков клиенты сначала пытаются скачать .bsp.bz2, в случае ошибки 404 пытаются скачать несжатую карту, без расширения .bz2 — .bsp. В случае облома и в этой попытке, игроку НЕ предоставляется возможности скачать карту с самого игрового сервера из

/tf2/tf/maps через Slow Download, а сообщается, что карта не найдена.

В Team Fortress 2 есть два типа ботов — с искусственным интеллектом и без. Боты с ИИ активно действуют в игре, их можно активировать без использования читерских команд (то есть при sv_cheats 0), на них можно зарабатывать многие достижения. Боты без ИИ — «куклы», активируются с использованием читерских команд (sv_cheats 1).

Официальная TF wiki говорит, что боты с ИИ корректно работают на большинстве карт King of the Hill ( koth_* ), некоторых Payload картах ( pl_* ), Dustbowl и Gorge, картах Capture the Flag ( ctf_* ) и Mann Manor ( cp_manor_event ). Возможно использование ботов на других картах, но с некоторой предварительной подготовкой. И при этом они не будут настолько же хороши как живые игроки. Впрочем, те же медики подлечить сумеют. Попробуем оба варианта.

Поддержваемая карта

Попробуем добавить ботов на карту koth_sawmill, которая их поддерживает by design. У нас оба сервера на 24 игрока. Точнее, на 24 игровых слота, но в данном примере эту разницу в нюансах не учитываем. Сделаем так, что если игроков меньше 24, то остальные игровые слоты сервера будут заняты ботами. Новый игрок вошёл в игру — бот исчез. Игрок вышел — бот добавился. Экспериментировать будем на втором, подопытном сервере. Чтобы каждый раз не набирать команды в консоли сервера, укажем их в файле конфигурации для данной карты

Здесь мы сделали:

tf_bot_difficulty 3
Уровень игры ботов. 0=easy, 1=normal, 2=hard, 3=expert.

tf_bot_join_after_player 0
Боты будут добавлены в игру при старте сервера (0), либо при входе первого игрока (1), а до его входа карта будет без ботов.

tf_bot_keep_class_after_death 0
После смерти, боты будут всегда возрождаться тем же классом (скаут, солдат, . ), какой получили при создании (1) или другим (0), на усмотрение ИИ.

tf_bot_quota 24
Совместно со следующим параметром, задаёт квоту ботов в игре. Используется, если следующий параметр tf_bot_quota_mode установлен в «fill» или «match», но не более количества игровых слотов, заданных +maxplayers в командной строке запуска сервера.

tf_bot_quota_mode fill
Тип применения квоты на ботов:

«normal» — сервер не будет добавлять/убирать ботов без прямой команды (tf_bot_add / tf_bot_kick)

«fill» — сервер будет поддерживать общее количество (ботов + живых игроков) в размере, заданном параметром tf_bot_quota

«match» — сервер будет поддерживать соотношение живых игроков к ботам как 1:N, где N задано параметром tf_bot_quota.

tf_bot_add [количество] [класс] [команда] [уровень] [имя]
Принудительное добавление ботов, при этом они не подвержены автоматическому регулированию квотой (но, в любом случае, не более maxplayers)

[Класс] — Demoman, Engineer, HeavyWeapons, Medic, Pyro, Scout, Soldier, Sniper, Spy

[Команда] — red или blue

[Уровень] — аналогичен tf_bot_difficulty, только для данного бота. 0=easy, 1=normal, 2=hard, 3=expert.

По нашей политике, все файлы конфигурации стараемся держать в

/cfg, поэтому делаем ссылку в

Запускаем сервер, если не запущен ранее, вводим в консоли команду смены карты: changelevel koth_sawmill . Входим в игру, быстро огребаем от двенадцати expert-lvl ботов и идём исправлять tf_bot_difficulty на 1 🙂

Пользовательсякая карта

Теперь добавим ботов на произвольную карту. В данном случае cp_orange_x3.

Копируем koth_sawmill.cfg в cp_orange_x3.cfg, учитывая что эта карта подключена из Steam Workshop:

И желательно в cp_orange_x3.ugc454299390.cfg исправить в echo имя файла, во избежание непоняток.

Меняем карту. В консоли сервера вводим changelevel workshop/cp_orange_x3.ugc454299390 . Входим в игру и видим невесёлую картину — ребята стоят, скучают:

Не отчаиваемся. В консоли игрового сервера, вводим команды: sv_cheats 1 — разрешает использование чит-команд и следом nav_generate — создаёт навигационную сетку (сохраняемую в файле .nav), используя которую боты могут двигаться. Ждём некоторое время.

После чего сервер перегружает уровень. Кстати вот тут и проявилась польза от прозорливо указанного параметра «sv_cheats 0» в server2.cfg. При смене карты, произошедшей выше, вручную включенный sv_cheats сбросился в 0, и можно не задумываться — а не забыли ли мы выключить то, что включили.

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

Но на мало-мальски сложных картах маршруты движения ботов могут быть очень неоптимальными, для исправления этого есть возможность корректировки навигационной сетки. Перечень навигационных команд приведён в Navigation Mesh Commands, а скачать уже готовые и оптимизированные файлы можно на Steam Users Forum.

Ещё есть «кукольные» боты (Puppet bots). Они обделены ИИ и могут либо стоять на месте, либо двигаться, повинуясь командам игрока. Здесь мы их не рассматриваем. Подробнее о них можно прочитать в TF Wiki, по ссылке в начале главы. А заодно и посмотреть впечатляющий ролик https://youtu.be/Dn9970dxQ2g

Следует иметь в виду, что боты, как ни странно, кушают процессорное время. В качестве демонстрационного примера, вот вывод программы top для трёх запущенных игровых серверов на хиленьком Atom N2800:

На первом сервере 24 бота с активной жизненной позицией (и сервер перегружен и ощутимо лагает, играть невозможно), на втором 12, на третьем ботов нет. Ах да, ещё на первом и третьем сервере включены Записи. Если на том же третьем их выключить, то его загрузка будет вдвое ниже, менее 7%. Ну и tf_bot_join_after_player 1 снизит нагрузку на серверах без игроков.

И, логичный, но не всегда очевидный момент — настройки ботов (да и не только их), заданные в файлах конфигурации карт (koth_sawmill.cfg и cp_orange_x3.ugc454299390.cfg в нашем примере) не сбрасываются при смене карты, а продолжают действовать и на следующих картах, при их ротации. Другое дело, что поведение ботов будет зависеть от типа карты — как было продемонстрировано в примерах выше, на каких-то картах боты могут быть активны «из коробки», на других картах, без сгенерированных .nav файлов они будут стоять на точках респауна. Поэтому, если требуется включать ботов только на некоторых картах, то имеет смысл прописать tf_bot_quota 0 в server<1,2>.cfg — при смене карты количество ботов будет равно нулю, а уже в файлах конфигурации для конкретной карты их можно включать целенаправленно.

• Часть 1 — Установка клиента Steam и сервера Team Fortress 2, базовая настройка, обновления
• Часть 3 — Установка MetaMod и SourceMod, скрипты запуска, логи, аккаунт Steam и QuickPlay
• Часть 4 — Сервер статистики HLstatsX

Источник