Еще один сайт о игровых серверах
FREE PYTHON MASTERSERVER
Бесплатный Masterserver На Python от jesuspunk
Всем привет, выкладываю свои наработки по мастерсерверу, работает на питоне(python 2.4 — 2.7), т.е. можно спокойно запустить как на Windows так и на Linux.
На данный момент реализовано:
1) Резолвинг домена в ip
2) Веб-статистика уникальных IP адресов
3) Возможность отключить сортировку по пингу, т.е. вы можете полностью контролировать порядок выдачи серверов клиенту, аля буст.
4) Интеграция с популярными веб скриптами lightmon и amxmonitoring
5) Авто обновления списка серверов через заданное время
6) Работа с Mysql (образец mysql таблицы есть) и файлами со списками серверов.
7) Логирование запросов в файл(статистика не реализована), в mysql(для вебстатистики)
8) Отдельные списки для игр: HL 1, HL 2 DM, CS:S, CS 1.6, Battlefield vietnam/1942, Medal of honor AA, crysis wars, Quake 3(68 протокол патч 1.32)
9) Поддержка до 10к серверов в каждом списке.
10) Возможность включения рандомной загрузки списков серверов при каждом обновление серверов.
11) Примитивная защита от DDOS атак, задержки до 1-3 секунд после 1к — 1.4к запросов в секунду на 3 ghz процессоре.
12) Встроенная проверка на новые версии при старте или обновление списка серверов.
13) Добавлена поддрежка скрипта буст от Мирора(не проверял.)
14) Восстановлена поддержка monengine
15) Теперь можно откулючить через конфиг не нужные протоколы поставив напротив порта OFF
16) Режим CMQ — Custom Mysql Query — Собственные sql запросы, для интеграции мастер сервера с вашей веб системой.
17) Режим URL загрузки списков файлов по ссылки.
18) Веб панель со статистикой.
Рекомендую хостинг(VDS/VPS) от Бери хост промокод B1-358, большой выбор образов, низкие цены, в общем я в восторге!
Установка для версии 0.50+(0.5.0+):
1) Устанавливаем нужные пакеты:
apt-get install ia32-libs
#для Debian 7 возможно нужно будет ввести 2 команды:
dpkg —add-architecture i386
apt-get update
apt-get install screen
apt-get install unzip
2) Качаем мс: wget http://non-steam.ru/…ads/ms062a3_linux32.zip
3) Распаковываем архив unzip ms061a1.zip
4) Заходим в папку с мс и устанавливаем права:
chmod +x mslauncher
chmod +x ms.so
chmod +x msstats.so
chmod +x cpsocket.so
chmod +x mswebcp.so
chmod 777 msstats.db
chmod +x start_ms_screen.sh
4)Запускаем:
./start_ms_screen.sh
5) Заходим по домену или ip http://ip:8888/ пароль/админ admin/admin и настраиваем мс, чтобы применились настройки, нужно выкл/вкл мс.
Если не запустился и в screen -ls ничего нету, для проверки пишем в папке с мс: ./mslauncher и смотрим что за ошибка. Расшифровка ms.cfg для версии 0.6+
Установка и настройка версий 0.4.8 alpha 6 — 0.4.9:
Скачать под вашу оперционную версию скомпелированный дистрибутив(для linux x64 нужно установить ia32 libs,(debian: apt-get install ia32-libs)).
Настроить ms.cfg под себя и запустить!
Под линуксом не забыть дать права на запуск chmod +x ms, так же установить screen если нету .
Установка и настройка для версии ниже 0.4.8 alpha 6:
Windows 32 битная и 64 битная версия:
Для работы мастер сервера нужен python 2.4-2.7 и python mysqldb module(важно какая у вас стоит версия python! 32 битная или 64. файлы прикреплны к посту) — для работы с базой данных, без этого модуля будет только файловый режим.
Произвести настройки ms.cfg
Запуск start.bat
1) Установка screen:
CentOS: yum install screen
Debian: apt-get install screen
Ubuntu: sudo apt-get install screen
2) Установка pyhton:
CentOS: yum install python
Debian: apt-get install python
Ubuntu: sudo apt-get install python
3) Установка pyhton mysqldb module:
CentOS: yum install python-mysqldb(yum install MySQL-python)
Debian: apt-get install python-mysqldb
Ubuntu: sudo apt-get install python-mysqldb
Источник
Развёртывание и настройка Icinga 2 на Debian 8.6. Часть 4. Инициализация Master-сервера и подключение Linux-клиентов Icinga (классический вариант)
В этой части мы немного поговорим о возможных вариантах мониторинга удалённых хостов в системе мониторинга Icinga 2 и рассмотрим процедуру подключения хостов на базе CentOS и Debian Linux к ранее развёрнутому серверу мониторинга c помощью установки агента Icinga.
О видах мониторинга Icinga
Сервер Icinga может выполнять как безагентный (agent less) мониторинг удалённых хостов, так и мониторинг хостов, на которые установлены разные виды агентов. В роли агентов может выступать как экземпляр Icinga, настроенный на удаленном сервере, так и дополнительное ПО, умеющее отправлять результат проверок на сервер мониторинга, но об этом чуть далее.
При безагентном мониторинге сервер Icinga может получать информацию об удалённом хосте как с помощью активных проверок (Active Check), запускаемых на самом сервере Icinga, так и с помощью пассивных проверок (Passive Check), инициируемых самим удалённым хостом с отправкой уведомлений на сервер Icinga.
Примерами безагентного активного мониторинга могут быть:
- периодический опрос сервером Icinga удалённого хоста на предмет доступности того или иного TCP-порта или ответа, получаемого от удалённого хоста при обращении на какой-либо порт (например разбор HTTP заголовков, получаемых в ответе от веб-сервера на удалённом хосте);
- опрос сервером Icinga состояния служб, работающих на удалённом хосте по протоколу SNMP (для Linux/Windows-систем, для сетевого оборудования) или таким протоколам, как WMI (для Windows-систем).
- получение информации сервером Icinga о состоянии аппаратной части оборудования через управляющие интерфейсы IPMI (HP iLO, IBM RSA, Dell DRAC и т.д.).
Примером безагентного пассивного мониторинга может быть получение от удалённого хоста SNMP-трапов, из которых можно получить информацию о проблемах с тем или иным сервисом на хосте. К слову о SNMP-трапах, стоит отметить тот факт, что сама по себе Icinga не занимается ловлей SNMP-трапов, а занимается обработкой результатов работы сторонних приложений, которые отвечают за расстановку SNMP-ловушек и ловлю SNMP-трапов.
Несмотря на то, что с помощью безагентной схемы можно решить множество сценариев мониторинга, использование агента мониторинга даёт свои дополнительные преимущества:
- возможность автоматизации управления конфигурацией хоста со стороны сервера;
- возможность исполнения проверок или команд на агенте по команде сервера, например, возможность использования обработчиков событий (Event handlers), с помощью которых можно автоматизировать восстановление работоспособности проблемного сервиса;
- шифрование канала передачи данных между сервером и агентом и т.д. при помощи SSL
Мониторинг Icinga с помощью агентов можно разделить на несколько разных реализаций:
- «родной» пакет Icinga2 в режиме клиента для Linux-систем
- NRPE Client — агент для Linux-систем (на стороне сервера требуется плагин check_nrpe) (например из пакета nagios-nrpe-server)
- NSClient++ — агент для Windows-систем, завернутый MSI-пакет (предпочтительней использовать check_nt или nscp_local, также может работать через плагин check_nrpe)
- NSCA-NG (но это уже устаревший вариант, хотя и активно применяемый в ряде конфигураций)
Есть мнение о том, что с точки зрения здравого смысла и вопросов безопасности, лучше вообще отказаться от реализаций NRPE ниже 3 версии и NSCA.
В рамках цикла наших заметок об Icinga будут рассматриваться примеры использования как безагентного мониторинга сетевых устройств, так и мониторинга с использованием агента, в качестве которого будет выступать стандартный пакет Icinga2 в режиме клиента для Linux-систем.
Клиент-серверная архитектура
С точки зрения клиент-серверной архитектуры в Icinga 2 различается три основные сущности – Master, Satellite, Client.
- Master — это серверный экземпляр Icinga 2 на верхнем уровне иерархии. Master-узел в простых развёртываниях один, в высоко-доступных развёртываниях Master-узлов может быть несколько (кластер).
- Satellite – вспомогательный узел, который способен выступать в качестве распространителя конфигурации Icinga для рядовых клиентов и позволяет рядовым клиентам не замечать недоступности основного Master-узла. Satellite-узлы могут быть полезны в больших развёртываниях, где требуется децентрализация основной конфигурации, например, когда требования к мониторингу одних и тех же служб различаются на разных площадках.
- Client – обычный клиентский узел, который получает конфигурацию мониторинга с родительского узла (Master или Satellite).
Приведу простую схему из документа, в котором описаны возможные архитектурные варианты Distributed Monitoring with Master, Satellites, and Clients :
Развёртывание любой из трёх перечисленных сущностей Icinga 2 сводится, как минимум, к установке пакета icinga2 и выполнению мастера конфигурирования узла с помощью команды:
В моём примере будет рассматриваться простая конфигурация с единственным Master-узлом и некоторым количеством клиентских узлов, то есть без участия Satellite-узлов. Таким образом, сначала мы рассмотрим конфигурирование Master-узла, а затем пример настройки пары клиентских Linux-систем.
Режимы работы клиента Icinga
Клиентская часть Icinga может работать в двух режимах: Top Down и Bottom Up.
В режиме Top Down сервер (Master) инициирует исполнение команд проверки на клиенте и/или может передавать конфигурацию клиенту. Как пример подобной конфигурации мы будем рассматривать развертывание хостов и сервисов в Icinga Director.
В режиме Bottom Up клиент самостоятельно (по собственному расписанию) выполняет проверки (рассылает уведомления) и отправляет результаты на Master-сервер. Этот вариант мы будем рассматривать далее в статье.
Обратите внимание на то, что режим Bottom Up на сегодня уже может считаться нерекомендуемым к использованию (Deprecated), так будет поддерживаться до конца следующего года, а начиная с версии Icinga 2.8 — 2.9 этот режим работы клиента работать перестанет. Подробнее об этом можно прочитать здесь: Feature #13255 — Deprecation of cluster/client mode «bottom up» w/ repository.d and node update-config
Инициализация Master-узла
На сервере, где мы ранее уже развернули Icinga 2 и Icinga Web 2 , запускаем мастер конфигурирования узла:
Последует ряд вопросов, на которые нам нужно будет ответить…
На первый вопрос мастера вводим n, чтобы перевести мастер конфигурирования в режим настройки Master-узла.
Затем нам будет предложено ввести имя Common Name (CN). Это имя будет использоваться для генерации SSL-сертификата, который будет использоваться для защиты соединений между сервером и его клиентами. По умолчанию в качестве CN предлагается FQDN-имя нашего сервера. Соглашаемся с этим именем, нажав Enter.
Так как в прошлой статье мы уже запускали процедуру активации Icinga API (выполняли команду icinga2 api setup ), то уже тогда на нашем сервере был создан локальный Центр сертификации (certificate authority) и сгенерирован этим ЦС SSL-сертификат (в каталоге /etc/icinga2/pki/ ) на имя нашего сервера. Поэтому в данном случае мастер конфигурирования узла обнаружит этот сертификат и подхватит его.
Также мастер обнаружит, что поддержка API в Icinga уже включена, а API user уже создан, и лишь предложит добавить информацию о Bind Host и Bind Port, где мы ничего не вводим, а просто нажимаем Enter для продолжения работы мастера.
В завершающей стадии мастер выполнит обновление некоторых конфигурационных файлов Icinga.
Здесь у нас появляются такие понятия, как «зона» (Zone) и «конечная точка» (Endpoint). Если упростить, то, «зона» является границей доверия и распространения конфигураций в «конечные точки», а «конечная точка» – это точка подключения клиентов к TCP-прослушивателю Icinga API (то есть конечная точка однозначно ассоциируется с каким-либо серверным узлом Icinga и характеризуется его FQDN именем). В одну зону может входить любое множество конечных точек.
Различается три основных типа зон: локальная, родительская, глобальная. С точки зрения исполнения команд, конечная точка способна принимать команды из своей локальной или родительской зоны. А с точки зрения приема конфигураций, конечная точка способна принимать конфигурации из родительской или глобальной зоны.
О дополнительных аспектах взаимодействия зон, понимания глобальной зоны и исполнения команд проверок мы поговорим в следующий статьях, посвящённых Icinga Director.
Вернёмся к нашему Master-узлу. В нашем случае и Zone и Endpoint будут иметь одно и тоже имя – FQDN-имя нашего сервера мониторинга.
Заглянем в файл /etc/icinga2/constants.conf и убедимся в наличии записи о зоне, относящейся к нашему, только что созданному, Master-серверу:
В файле /etc/icinga2/zones.conf впишем в качестве Zone и Endpoint — FQDN имя Master-сервера:
Для вступления изменений конфигурации в силу, перезапустим службу icinga2:
Таким нехитрым образом мы инициировали работу Master-сервера, теперь переходим к установке клиентов.
Установка Icinga на Client-узел
В качестве примера развёртывания Linux-клиента я буду использовать системы на базе Debian 8.6 и CentOS 7.2.
В то время, когда мастер конфигурирования узла Icinga будет запущен на клиентской Linux-системе, он отправит запрос на получение клиентского сертификата на Master-узел (а мы помним о том, что на нашем Master-узле работает Центр сертификации). И для того, чтобы Master-узел автоматически мог ответить такому клиенту на запрос, то есть сразу выдать сертификат, нам предварительно потребуется создать специальный «тикет» для этого клиента на Master-узле с помощью команды:
Теперь переходим на клиентскую Linux-систему и выполняем установку пакетов icinga2 и nagios-plugins c последующей активацией службы icinga2.
На сервере с Debian 8.6 последовательность действий будет выглядеть так:
На сервере с CentOS 7.2 это будет выглядеть следующим образом:
Дальнейшие действия будут одинаковы и как для Debian-клиентов, так и для CentOS-клиентов.
После установки пакетов запускаем мастер настройки узла Icinga:
Обратите внимание на то, что запуск мастера настройки узла – это классический вариант подключения клиента Icinga к Master-серверу. При использовании модуля расширения Icinga Director у нас появляется ещё один вариант подключения клиента к серверу, о чём мы поговорим в дальнейшем при рассмотрении примеров использования Icinga Director.
Также, как и при инициализации Master-сервера, здесь нам потребуется ответить на несколько вопросов, но вопросов будет уже больше:
- На первый вопрос введём Y, чтобы перевести мастер в режим настройки клиента.
- Затем нам будет предложено ввести имя Common Name (CN). Это имя будет использоваться для генерации SSL-сертификата клиента на стороне ЦС, который работает на Master-сервере. По умолчанию в качестве CN предлагается FQDN-имя нашего сервера. Соглашаемся с этим именем, нажав Enter.
- Следующим пунктом нам нужно ввести СN-имя конечной точки Endpoint на стороне Master-сервера. В нашем случае это FQDN-имя сервера мониторинга.
- На вопрос, хотим ли мы установить соединение с Master-узлом с этого клиента, отвечаем утвердительно – вводим Y
- Затем снова введём имя сервера Master endpoint host, а порт Master endpoint port оставим предложенный по умолчанию, так как именно этот (TCP 5665) порт у нас используется для Icinga API на стороне нашего Master-сервера.
- На вопрос, хотим ли мы настроить дополнительные подключения к другим Master-серверам (клиент Icinga может работать с несколькими серверами одновременно), ответим отрицательно, так как в нашем случае используется всего одни сервер – вводим N.
- Далее нас спросят о том, через какое Master-соединение можно отправить запрос на генерацию сертификата. По умолчанию здесь будут предложены уже введенные ранее данные об имени и порте Master-сервера, поэтому просто два раза нажмём Enter.
C Master-узла будет запрошен сертификат сервера и показаны нам для проверки его данные, в частности отпечаток Fingerprint. Это не более, чем дополнительная проверка для повышения уровня безопасности процесса подключения клиента к серверу. Проверив информацию о сертификате, вводим согласие о том, что информация корректна —Y
После этого с сервера Icinga у нас будет запрошен «тикет«, который мы сгенерировали ранее на Master-сервере для клиента с именем KOM-AD01-APP31.holding.com . Используя этот «тикет» мастер конфигурирования запросит у Центра сертификации Icinga на сервере мониторинга SSL-сертификат для клиента и, получив его от ЦС, сохранит в каталоге /etc/icinga2/pki/ .
На вопросы о Bind Host и Bind Port просто жмём Enter.
Затем будет задан вопрос о принятии конфигурации и разрешении принятия команд с Master-сервера Accept config / commands from master. Отвечаем утвердительно — Y. После этот Icinga-клиент обновит локальную копию информации о зонах и настройках полученных с Master-сервера и завершит свою работу. 
Теперь нам нужно обновить локальный файл зон Icinga, добавив туда информацию о клиенте:
После работы мастера конфигурации узла Icinga в этом файле уже будет присутствовать информация о Master-узле и нам останется только заменить значения NodeName и ZoneName последних двух секций добавив туда FQDN-имя нашего клиента
После этого перезапустим на нашем клиенте службу icinga2:
Инициализация Client-узла на Master-узле
После настройки наш клиент Icinga 2 будет периодически отправлять на Master-сервер копию своей локальной конфигурации. Чтобы проверить то, что информация о конфигурации клиентских служб успешно передаётся на сервер, выполним на стороне сервера команду:
Эта команда выведет информацию о всех узлах, которые выполняют периодические подключения к серверу с отправкой на него своей конфигурации:
Чтобы обновить конфигурацию сервера, загрузив в него информацию о конфигурации подключающихся клиентов, выполним команды:
Обратите внимание на то, что выполнять обновление конфигурации сервера с помощью команды icinga2 node update-config нужно только в том случае, если мы планируем вручную управлять конфигурационными файлами Icinga. Если же мы планируем использовать функционал Icinga Director для управления конфигурацией Icinga, то нам лучше воздержаться от выполнения этой команды. Хотя на самом деле нет ничего страшного, если мы на данном этапе выполним эту команду и обновим конфигурацию сервера, так как в следующей части, при рассмотрении процесса настройки Icinga Director я приведу пример того, как очистить конфигурацию сервера от записей об узлах, добавленных ранее в ручной конфигурации.
Итак, после обновления конфигурации сервера, перейдём в веб-консоль Icinga (Overview > Hosts) и сможем увидеть информацию о новом клиенте, который некоторое непродолжительно время будет находится в статусе PENDING…
А затем этот хост перейдёт в статус UP, после чего станет доступна информация о текущем состоянии его служб:
Как видим, в конфигурации по умолчанию некоторые из служб на нашем клиенте имеют критический статус. В следующей отдельной заметке мы попробуем разобраться с тем, как можно изменить эту ситуацию. А в этой части мы выполнили поставленную задачу – провели инициализацию Master-сервера и подключили к нему несколько Linux-клиентов в режиме Bottom Up.
PS: Хочу выразить отдельную благодарность за помощь в написании теоретической части и редакционную поддержку Павлу Козлову.
Дополнительные источники информации:
Источник
