Администрирование сервера CRMP — команды, игроки и логи

Основные задачи администратора сервера CRMP

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

Работа с игроками

• ответы на вопросы;
• рассмотрение жалоб;
• наблюдение за подозрительными игроками;
• предупреждения;
• временные ограничения чата;
• изоляция нарушителей;
• кики и блокировки;
• восстановление после подтверждённой ошибки.

Работа с персоналом

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

Техническое обслуживание

• проверка консоли сервера;
• анализ журналов;
• контроль MySQL;
• создание резервных копий;
• перезапуск процесса;
• проверка свободного места;
• обновление игрового мода;
• тестирование изменений.

Разделение ролей владельца и персонала

Не всем сотрудникам проекта нужен одинаковый уровень доступа.

Владелец проекта

• управляет сервером и базой данных;
• хранит RCON-пароль;
• назначает руководителей;
• утверждает обновления;
• контролирует резервные копии;
• имеет доступ к панели хостинга.

Технический администратор

• обслуживает VPS;
• работает с файлами сервера;
• проверяет нагрузку;
• устанавливает плагины;
• исправляет ошибки запуска;
• обновляет серверное окружение.

Разработчик

• изменяет PWN-код;
• работает со структурой MySQL;
• исправляет игровые ошибки;
• создаёт административные команды;
• проводит тестирование обновлений.

Главный администратор

• управляет игровым персоналом;
• проверяет наказания;
• рассматривает жалобы;
• обучает новых сотрудников;
• контролирует соблюдение правил.

Игровой администратор

• следит за игроками;
• обрабатывает репорты;
• использует ограниченный набор команд;
• не получает доступ к серверным файлам;
• не должен знать RCON-пароль.

Разница между RCON и внутриигровой администрацией

RCON

RCON относится к серверному ядру и позволяет выполнять команды управления сервером.

Внутриигровая администрация

Внутриигровая система является частью игрового мода. Она может содержать собственные уровни, команды, журналы и ограничения.

Защита RCON-пароля

Пример настройки

rcon 1
rcon_password СЛОЖНЫЙ_УНИКАЛЬНЫЙ_ПАРОЛЬ

Пароль должен

• быть уникальным для этого сервера;
• не совпадать с MySQL-паролем;
• не совпадать с паролем панели;
• не использовать название проекта;
• не передаваться обычным администраторам;
• храниться в защищённом менеджере паролей.

После утечки

1. Немедленно смените RCON-пароль.
2. Перезапустите сервер при необходимости.
3. Проверьте журнал команд.
4. Проверьте список блокировок.
5. Проверьте игровой мод и filterscripts.
6. Смените связанные пароли, если они совпадали.

Отключение RCON

rcon 0

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

Авторизация администратора в RCON

Команда в игре

/rcon login ВАШ_RCON_ПАРОЛЬ

Проверка статуса в Pawn

if (IsPlayerAdmin(playerid))
{
 SendClientMessage(
 playerid,
 -1,
 "Вы авторизованы в RCON."
 );
}

Нежелательная практика

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

Попытки входа следует контролировать

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

Не выводите пароль

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

Основные команды RCON

Список команд

/rcon cmdlist

Список текущих переменных

/rcon varlist

Список игроков

/rcon players

Сообщение от администратора

/rcon say Технический перезапуск через 5 минут.

Кик игрока

/rcon kick ID

Блокировка игрока

/rcon ban ID

Блокировка IP

/rcon banip IP_АДРЕС

Разблокировка IP

/rcon unbanip IP_АДРЕС
/rcon reloadbans

Загрузка filterscript

/rcon loadfs script_name

Выгрузка filterscript

/rcon unloadfs script_name

Перезагрузка filterscript

/rcon reloadfs script_name

Смена игрового режима

/rcon changemode roleplay

Перезапуск режима

/rcon gmx

Остановка сервера

/rcon exit

Управление игроками на сервере

Внутриигровая административная система должна предоставлять инструменты для работы с нарушениями и помощи пользователям.

Основные категории команд

• получение информации об игроке;
• наблюдение;
• телепортация;
• предупреждение;
• отключение чата;
• изоляция в административной зоне;
• кик;
• временная блокировка;
• постоянная блокировка;
• разблокировка;
• восстановление после ошибки;
• просмотр истории наказаний.

Перед наказанием администратор должен проверить

• правильность ID;
• игровой ник;
• доказательства нарушения;
• пункт правил;
• допустимый срок;
• отсутствие конфликта интересов;
• состояние игрока и сервера.

После наказания необходимо записать

• администратора;
• игрока;
• тип наказания;
• причину;
• срок;
• дату;
• связанные доказательства;
• идентификатор записи.

Настройка команды кика

Кик отключает игрока, но не запрещает повторное подключение.

Пример использования

/kick ID Причина

Команда должна проверить

• уровень администратора;
• существование игрока;
• невозможность наказать старшего администратора;
• наличие причины;
• допустимую длину текста;
• ограничение повторного использования;
• запись действия в журнал.

Рекомендуемый порядок

1. Сформировать запись в журнале.
2. Сообщить игроку причину.
3. Показать сообщение персоналу.
4. Сохранить важные данные игрока.
5. Через короткую задержку выполнить отключение.

Не используйте кик

• вместо исправления серверной ошибки;
• за небольшое несогласие с администратором;
• без понятной причины;
• для скрытия собственных нарушений;
• без журналирования.

Настройка системы блокировок

Для Role Play проекта удобнее хранить блокировки в MySQL, а не только в стандартном файле samp.ban.

Пример таблицы

CREATE TABLE `bans` (
 `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
 `account_id` BIGINT UNSIGNED DEFAULT NULL,
 `player_name` VARCHAR(24) NOT NULL,
 `ip_address` VARCHAR(45) DEFAULT NULL,

 `admin_account_id` BIGINT UNSIGNED NOT NULL,
 `admin_name` VARCHAR(24) NOT NULL,

 `reason` VARCHAR(255) NOT NULL,
 `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
 `expires_at` DATETIME DEFAULT NULL,

 `is_active` TINYINT(1) NOT NULL DEFAULT 1,
 `removed_at` DATETIME DEFAULT NULL,
 `removed_by` BIGINT UNSIGNED DEFAULT NULL,
 `remove_reason` VARCHAR(255) DEFAULT NULL,

 PRIMARY KEY (`id`),
 KEY `idx_bans_account` (`account_id`),
 KEY `idx_bans_ip` (`ip_address`),
 KEY `idx_bans_active` (`is_active`, `expires_at`)
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8mb4
COLLATE=utf8mb4_unicode_ci;

Виды блокировок

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

Не полагайтесь только на IP

IP может измениться или принадлежать нескольким пользователям. Основной идентификатор наказания лучше связывать с аккаунтом.

Разблокировка должна сохраняться

Не удаляйте запись полностью. Измените её состояние и запишите, кто снял наказание и по какой причине.

Mute, jail и система предупреждений

Mute

Ограничивает использование чата или отдельных каналов.

Jail

Изолирует персонажа в административной зоне на установленное время.

Warn

Фиксирует нарушение и может участвовать в накопительной системе наказаний.

Для каждого наказания храните

• тип;
• причину;
• дату выдачи;
• дату завершения;
• администратора;
• игрока;
• статус;
• причину досрочного снятия.

Не используйте только Pawn-таймер

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

Пример проверки

if (punishmentExpiresAt > currentTime)
{
 ApplyRemainingPunishment(playerid);
}

Это архитектурный пример. Конкретная работа со временем зависит от игрового мода.

Наблюдение за подозрительными игроками

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

Пример команды

/spec ID

Административная система должна сохранить

• предыдущую позицию администратора;
• интерьер;
• виртуальный мир;
• состояние транспорта;
• здоровье и броню;
• режим наблюдения;
• ID наблюдаемого игрока.

При завершении наблюдения

/specoff

Администратор должен вернуться в сохранённое положение без появления в игровом мире наблюдаемого игрока.

Проверьте особые ситуации

• игрок отключился;
• игрок умер;
• игрок сменил интерьер;
• игрок вошёл в транспорт;
• администратор был отключён;
• начался перезапуск сервера.

Не используйте наблюдение для получения игровых преимуществ

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

Телепортация администрации

Распространённые команды

/goto ID
/gethere ID
/gotopos X Y Z
/getcar ID
/veh ID

Перед телепортацией учитывайте

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

Команда gethere должна быть ограничена

Перемещение игрока способно нарушить квест, работу, арест или сохранение транспорта. Используйте его только при необходимости.

Служебный режим администратора

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

Настройка уровней администрации

Простая система может использовать числовой уровень.

Пример

Недостаток одной числовой шкалы

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

Более гибкий вариант

Использовать роли и отдельные разрешения:

player.kick
player.mute
player.ban.temporary
player.ban.permanent
staff.manage
economy.restore
server.restart

Настройка модели разрешений

Проверка числового уровня

if (PlayerData[playerid][pAdmin] < 2)
{
 SendClientMessage(
 playerid,
 -1,
 "Недостаточно прав."
 );

 return 1;
}

Проверка отдельного разрешения

if (!HasAdminPermission(
 playerid,
 "player.kick"
))
{
 SendClientMessage(
 playerid,
 -1,
 "У вас нет доступа к этой команде."
 );

 return 1;
}

Преимущества отдельных разрешений

• точное распределение полномочий;
• временный доступ к конкретной функции;
• отсутствие лишних команд;
• удобство для разных отделов;
• проще проводить аудит;
• ниже риск злоупотреблений.

Опасные разрешения

• выдача денег;
• изменение уровня администратора;
• удаление имущества;
• перманентная блокировка;
• восстановление базы;
• выполнение произвольных SQL-команд;
• перезапуск сервера.

Такие функции должны быть доступны минимальному числу сотрудников.

Хранение персонала в MySQL

Простой вариант в accounts

ALTER TABLE `accounts`
ADD COLUMN `admin_level`
SMALLINT UNSIGNED NOT NULL DEFAULT 0;

Отдельная таблица персонала

CREATE TABLE `staff_members` (
 `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
 `account_id` BIGINT UNSIGNED NOT NULL,
 `role_name` VARCHAR(64) NOT NULL,
 `admin_level` SMALLINT UNSIGNED NOT NULL DEFAULT 0,

 `appointed_by` BIGINT UNSIGNED NOT NULL,
 `appointed_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,

 `is_active` TINYINT(1) NOT NULL DEFAULT 1,
 `removed_by` BIGINT UNSIGNED DEFAULT NULL,
 `removed_at` DATETIME DEFAULT NULL,
 `remove_reason` VARCHAR(255) DEFAULT NULL,

 PRIMARY KEY (`id`),
 UNIQUE KEY `uq_staff_account` (`account_id`),
 KEY `idx_staff_active` (`is_active`)
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8mb4
COLLATE=utf8mb4_unicode_ci;

Для отдельных разрешений

CREATE TABLE `staff_permissions` (
 `staff_id` BIGINT UNSIGNED NOT NULL,
 `permission_name` VARCHAR(100) NOT NULL,

 PRIMARY KEY (
 `staff_id`,
 `permission_name`
 )
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8mb4
COLLATE=utf8mb4_unicode_ci;

Права загружаются после авторизации

До успешной проверки пароля административные команды должны быть недоступны.

Назначение нового администратора

Перед назначением проверьте

• возраст аккаунта;
• историю наказаний;
• репутацию игрока;
• знание правил;
• отсутствие конфликта интересов;
• наличие защищённого аккаунта;
• готовность работать по журналам.

Команда назначения

/setadmin ID УРОВЕНЬ Причина

Команда должна записать

• кто назначил;
• кого назначили;
• старый уровень;
• новый уровень;
• дату;
• причину;
• IP сессии назначившего администратора.

Не изменяйте права только в памяти

Изменение должно сохраняться в MySQL и применяться после проверки результата запроса.

Испытательный срок

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

Снятие административных прав

Права необходимо снять

• в игровой памяти;
• в базе данных;
• в панели проекта;
• в служебных сообществах;
• в системе тикетов;
• в файловом хранилище;
• в SSH и панели хостинга, если доступ выдавался.

Команда

/removeadmin ID Причина

Сохраняйте историю

Не удаляйте запись персонала без следа. Измените состояние:

is_active = 0

и сохраните дату, инициатора и причину снятия.

После серьёзного инцидента

• смените общие пароли;
• аннулируйте активные сессии;
• проверьте последние действия;
• проверьте изменения экономики;
• проверьте блокировки и разблокировки;
• создайте копию журналов.

Разработка административных команд

Каждая команда должна содержать

1. Проверку авторизации.
2. Проверку административного доступа.
3. Проверку параметров.
4. Проверку цели.
5. Проверку иерархии.
6. Проверку ограничений.
7. Выполнение действия.
8. Запись в журнал.
9. Уведомление участников.

Общая схема Pawn

CMD:kick(playerid, params[])
{
 if (!PlayerData[playerid][pLoggedIn])
 {
 return 1;
 }

 if (!HasAdminPermission(
 playerid,
 "player.kick"
 ))
 {
 return SendClientMessage(
 playerid,
 -1,
 "Недостаточно прав."
 );
 }

 new targetid;
 new reason[128];

 if (sscanf(
 params,
 "us[128]",
 targetid,
 reason
 ))
 {
 return SendClientMessage(
 playerid,
 -1,
 "Использование: /kick ID Причина"
 );
 }

 if (!IsPlayerConnected(targetid))
 {
 return SendClientMessage(
 playerid,
 -1,
 "Игрок не найден."
 );
 }

 if (!CanAdminPunishPlayer(
 playerid,
 targetid
 ))
 {
 return SendClientMessage(
 playerid,
 -1,
 "Вы не можете наказать этого игрока."
 );
 }

 AdminKickPlayer(
 playerid,
 targetid,
 reason
 );

 return 1;
}

Проверка параметров административных команд

Проверяйте ID

• игрок подключён;
• это не NPC;
• цель не отключилась во время запроса;
• ID не относится к старой сессии;
• администратор не наказывает себя случайно.

Проверяйте текст причины

• причина не пустая;
• длина ограничена;
• строка корректно экранируется для MySQL;
• нет управляющих символов;
• нет паролей и персональных данных;
• формулировка соответствует правилам.

Проверяйте числовые значения

• срок наказания не отрицательный;
• сумма восстановления находится в пределах;
• уровень администратора допустим;
• идентификатор имущества существует;
• координаты не содержат некорректные значения.

Ограничивайте частоту

Административную команду нельзя выполнять сотни раз в секунду из-за ошибки интерфейса или намеренного злоупотребления.

Журнал действий администрации

Пример таблицы

CREATE TABLE `admin_logs` (
 `id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,

 `admin_account_id` BIGINT UNSIGNED NOT NULL,
 `admin_name` VARCHAR(24) NOT NULL,

 `target_account_id` BIGINT UNSIGNED DEFAULT NULL,
 `target_name` VARCHAR(24) DEFAULT NULL,

 `action_type` VARCHAR(64) NOT NULL,
 `command_name` VARCHAR(64) DEFAULT NULL,
 `details` TEXT DEFAULT NULL,

 `admin_ip` VARCHAR(45) DEFAULT NULL,
 `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,

 PRIMARY KEY (`id`),
 KEY `idx_admin_logs_admin` (`admin_account_id`),
 KEY `idx_admin_logs_target` (`target_account_id`),
 KEY `idx_admin_logs_action` (`action_type`),
 KEY `idx_admin_logs_created` (`created_at`)
)
ENGINE=InnoDB
DEFAULT CHARACTER SET=utf8mb4
COLLATE=utf8mb4_unicode_ci;

Записывайте

• кики;
• блокировки;
• разблокировки;
• mute и jail;
• изменение прав;
• выдачу денег;
• изменение имущества;
• телепортацию игроков;
• восстановление аккаунтов;
• служебные команды сервера.

Лог должен создаваться сервером

Клиент не должен самостоятельно передавать имя администратора, уровень или описание выполненного действия.

Журнал наказаний игроков

Журнал действий и журнал активных наказаний лучше разделить.

Журнал действий отвечает на вопросы

• кто применил команду;
• когда она была применена;
• какие параметры использовались;
• кто был целью;
• чем завершилась операция.

Таблица наказаний отвечает на вопросы

• какое наказание активно;
• когда оно закончится;
• по какой причине выдано;
• кто его выдал;
• было ли оно отменено;
• кто выполнил отмену.

Не изменяйте историю задним числом

Исправление ошибки должно создавать дополнительную запись о снятии или корректировке наказания.

Логи экономики и имущества

Все административные изменения экономики должны записываться особенно подробно.

Логируйте

• выдачу и изъятие денег;
• изменение банковского счёта;
• выдачу транспорта;
• удаление транспорта;
• передачу дома;
• изменение бизнеса;
• выдачу предметов;
• изменение уровня;
• восстановление после бага.

Для изменения денег храните

• значение до операции;
• размер изменения;
• значение после операции;
• причину;
• администратора;
• игрока;
• дату;
• номер обращения или жалобы.

Пример

Было: 150000
Изменение: +50000
Стало: 200000
Причина: восстановление после подтверждённого сбоя

Это позволяет обнаруживать злоупотребления и восстанавливать историю экономики.

Проверка файла server_log.txt

Основной журнал серверного ядра обычно находится в корне сборки:

server_log.txt

Ищите сообщения

• Unknown Gamemode;
• Plugin Failed;
• Run time error;
• File or function is not found;
• Access denied;
• Connection refused;
• Permission denied;
• Address already in use;
• Segmentation fault.

Просмотр последних строк Linux

tail -n 150 server_log.txt

Просмотр в реальном времени

tail -f server_log.txt

Поиск ошибок

grep -i \
-E "error|failed|warning|runtime|denied" \
server_log.txt

Перед отправкой журнала разработчику

• удалите пароли;
• скройте токены;
• скройте реквизиты MySQL;
• не публикуйте IP игроков без необходимости;
• сохраните строки до и после ошибки.

Проверка crashinfo и CrashDetect

При аварийном завершении проверьте

crashinfo.txt
server_log.txt

CrashDetect может показать

• номер runtime-ошибки;
• название функции;
• стек вызовов;
• номер строки PWN;
• название AMX;
• параметры проблемного вызова.

Для номеров строк используйте отладочную компиляцию

pawno\pawncc.exe \
gamemodes\roleplay.pwn \
-d3

После получения ошибки

1. Скопируйте полный стек.
2. Найдите первую функцию своего мода.
3. Откройте указанную строку.
4. Проверьте массивы и идентификаторы.
5. Воспроизведите проблему на тестовом сервере.
6. Исправьте код и повторно протестируйте.

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

Проверка ошибок MySQL

Распространённые сообщения

Access denied for user
Unknown database
Table doesn't exist
Unknown column
Duplicate entry
MySQL server has gone away

При ошибке проверьте

• работу MySQL-плагина;
• данные подключения;
• выбранную базу;
• структуру таблиц;
• права пользователя;
• результат запроса;
• актуальность session ID;
• последнее обновление игрового мода.

Проверка службы Linux

sudo systemctl status mysql

Последние сообщения службы

sudo journalctl \
-u mysql \
-n 100 \
--no-pager

Настройка и диагностика MySQL для CRMP

Настройка журналов в server.cfg

Отметки времени

timestamp 1
logtimeformat [%d/%m/%Y %H:%M:%S]

Логирование игрового чата

chatlogging 1

Логирование запросов к серверу

logqueries 0

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

Логи игрового мода

Отдельно полезно хранить:

logs/admin/
logs/punishments/
logs/economy/
logs/mysql/
logs/chat/
logs/security/

Не записывайте в журналы

• пароли игроков;
• RCON-пароль;
• пароль MySQL;
• токены внешних сервисов;
• полные платёжные данные;
• секреты восстановления аккаунта.

Ротация журналов

Старые файлы следует архивировать и удалять по установленному сроку, иначе они займут весь диск VPS.

Ежедневное обслуживание сервера

Проверяйте

• работает ли серверный процесс;
• доступен ли игровой порт;
• нет ли повторяющихся ошибок;
• работает ли MySQL;
• создаются ли резервные копии;
• не заполнен ли диск;
• нет ли необычной нагрузки;
• не появились ли массовые жалобы игроков.

Минимальный ежедневный порядок

1. Открыть последние строки журнала.
2. Проверить ошибки плагинов.
3. Проверить ошибки базы.
4. Проверить размер журналов.
5. Проверить резервную копию.
6. Просмотреть критические действия администрации.
7. Проверить активные блокировки.

Не перезапускайте сервер без причины

Регулярный принудительный перезапуск может скрывать утечку памяти или ошибку игрового мода. Сначала определите причину ухудшения работы.

Еженедельное обслуживание

Раз в неделю полезно

• проверять восстановление резервной копии;
• архивировать старые журналы;
• просматривать действия персонала;
• проверять неиспользуемые аккаунты администрации;
• контролировать рост базы данных;
• обновлять внутреннюю документацию;
• проверять сроки наказаний;
• удалять старые тестовые файлы;
• проверять свободное место VPS.

Проверка больших файлов

du -ah /home/crmp/server \
| sort -h \
| tail -n 30

Проверка размера каталогов

du -sh \
/home/crmp/server/*

Проверка таблиц MySQL

SELECT
 TABLE_NAME,
 TABLE_ROWS,
 DATA_LENGTH,
 INDEX_LENGTH
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'crmp_server'
ORDER BY
 DATA_LENGTH + INDEX_LENGTH DESC;

Обновление игрового мода

Перед обновлением сохраните

• текущий AMX;
• исходный PWN;
• server.cfg;
• плагины;
• include-файлы;
• scriptfiles;
• базу данных;
• последние журналы.

Безопасный порядок

1. Создать тестовую копию сервера.
2. Создать копию базы.
3. Установить обновление на тестовой среде.
4. Проверить компиляцию.
5. Проверить плагины.
6. Проверить миграции MySQL.
7. Проверить регистрацию и авторизацию.
8. Проверить административные команды.
9. Проверить сохранение данных.
10. Только после этого обновить рабочий сервер.

Не заменяйте одновременно

• игровой мод;
• все плагины;
• структуру базы;
• операционную систему;
• серверное ядро.

Большое количество одновременных изменений затрудняет поиск причины ошибки.

Правильный перезапуск сервера CRMP

Перед перезапуском

1. Предупредите игроков.
2. Закройте вход паролем при необходимости.
3. Остановите важные события.
4. Сохраните аккаунты.
5. Дождитесь критических MySQL-запросов.
6. Создайте резервную копию перед обновлением.
7. Корректно завершите процесс.

Сообщение игрокам

/rcon say Технический перезапуск через 5 минут.

Корректная остановка

/rcon exit

После запуска

• проверьте загрузку плагинов;
• проверьте игровой мод;
• проверьте MySQL;
• подключитесь тестовым аккаунтом;
• проверьте административные команды;
• уберите пароль с сервера;
• следите за журналом первые минуты.

Управление CRMP Server на Linux

Поиск процесса

ps aux \
| grep samp03svr

Запуск через screen

cd /home/crmp/server

screen -S crmp \
sudo -u crmp \
./samp03svr-cr

Просмотр screen-сессий

screen -ls

Подключение к консоли

screen -r crmp

Отключение от screen без остановки сервера

Ctrl+A
D

Не завершайте процесс через kill -9 без необходимости

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

Для постоянного сервера лучше использовать systemd

Служба может автоматически запускать сервер после перезагрузки VPS и перезапускать процесс после сбоя. Перед автоматическим восстановлением необходимо убедиться, что сервер не попадает в бесконечный цикл аварийных запусков.

Контроль ресурсов VPS

Общая нагрузка

top

Удобный монитор

htop

Оперативная память

free -h

Нагрузка системы

uptime

Сетевые порты

sudo ss -lunp

Ищите

• постоянную загрузку одного ядра;
• увеличение памяти со временем;
• активное использование swap;
• большое число зависших процессов;
• неизвестные сетевые подключения;
• неожиданный перезапуск MySQL;
• рост времени выполнения запросов.

Не оценивайте производительность только по онлайну

Пустой сервер может потреблять много ресурсов из-за бесконечного таймера, тяжёлого запроса или неправильно реализованного цикла.

Контроль свободного места

Проверка дисков

df -h

Проверка inode

df -i

Что обычно занимает место

• server_log.txt;
• логи чата;
• логи MySQL;
• резервные копии;
• core-файлы после падений;
• старые сборки;
• временные архивы;
• дампы базы.

Поиск крупных файлов

find /home/crmp \
-type f \
-size +100M \
-print

Заполненный диск может вызвать

• невозможность записи логов;
• ошибки сохранения;
• сбой MySQL;
• повреждение таблиц;
• остановку резервного копирования;
• аварийное завершение других служб.

Резервное копирование сервера

Архив серверных файлов

tar -czf \
/home/crmp/backups/server-$(date +%F).tar.gz \
/home/crmp/server

Дамп базы данных

mysqldump \
--single-transaction \
-u crmp_user \
-p \
crmp_server \
| gzip \
> /home/crmp/backups/database-$(date +%F).sql.gz

Сохраняйте отдельно

• серверные файлы;
• базу данных;
• конфигурации;
• служебные скрипты;
• логи критических действий;
• инструкцию восстановления.

Используйте несколько мест хранения

• рабочий VPS для быстрого отката;
• другой сервер;
• облачное хранилище;
• компьютер владельца;
• зашифрованный внешний архив.

Проверяйте восстановление

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

Действия при взломе или злоупотреблении

При подозрении на компрометацию

1. Ограничьте доступ к серверу.
2. Сохраните копию журналов.
3. Снимите права подозрительного аккаунта.
4. Смените RCON-пароль.
5. Смените пароль панели и SSH.
6. Смените MySQL-пароль.
7. Проверьте неизвестные файлы.
8. Проверьте изменения базы.
9. Проверьте блокировки и экономику.
10. Восстановите повреждённые данные из проверенной копии.

Не удаляйте журналы сразу

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

Проверьте

• новых администраторов;
• выданные деньги;
• изменённое имущество;
• снятые блокировки;
• изменения игровых файлов;
• добавленные плагины;
• новые задания cron;
• неизвестные SSH-ключи.

Безопасность аккаунтов персонала

Для администрации необходимо

• использовать уникальные пароли;
• не передавать аккаунты другим людям;
• не сохранять пароли в общих чатах;
• проверять необычные входы;
• ограничивать число попыток авторизации;
• немедленно сообщать об утрате доступа;
• снимать права у неактивных сотрудников.

Дополнительная проверка

Для опасных действий можно запрашивать отдельный служебный PIN или подтверждение через внешний защищённый канал.

Не привязывайте права только к IP

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

Не храните права в клиентской части

Клиент не должен решать, является ли игрок администратором. Все проверки выполняются сервером.

Правила работы администрации

Персонал должен

• указывать понятную причину наказания;
• сохранять доказательства;
• соблюдать иерархию;
• не использовать команды ради развлечения;
• не вмешиваться в RP без причины;
• не раскрывать служебную информацию;
• не выдавать имущество знакомым;
• не удалять журналы;
• не изменять наказания без записи;
• сообщать о найденных ошибках.

Запрещённые практики

• кик без причины;
• бан за личный конфликт;
• выдача денег без подтверждения;
• передача аккаунта;
• публикация IP игроков;
• использование наблюдения для игры;
• выдача прав без согласования;
• удаление записей о своих действиях.

Любое опасное действие должно быть проверяемым

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

Контрольный список администрирования CRMP

Доступ

• RCON-пароль заменён;
• обычный персонал не знает RCON;
• уровни хранятся в MySQL;
• права проверяются сервером;
• неактивные сотрудники удалены;
• опасные команды ограничены.

Команды

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

Логи

• включены отметки времени;
• действия администрации сохраняются;
• экономические операции сохраняются;
• пароли в журнал не попадают;
• старые логи архивируются;
• доступ к ним ограничен.

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

• проверяется server_log.txt;
• контролируется MySQL;
• контролируется свободное место;
• создаются резервные копии;
• проверяется восстановление;
• обновления тестируются отдельно;
• сервер корректно останавливается.

Частые вопросы по администрированию CRMP

Чем RCON отличается от игровой админки?

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

Нужно ли выдавать RCON администраторам?

Нет. Он должен оставаться у владельца и ограниченного числа технических специалистов.

Как войти в RCON?

/rcon login ВАШ_ПАРОЛЬ

Как посмотреть игроков через RCON?

/rcon players

Как кикнуть игрока через RCON?

/rcon kick ID

Как заблокировать IP?

/rcon banip IP_АДРЕС

Как снять блокировку IP?

/rcon unbanip IP_АДРЕС
/rcon reloadbans

Где хранятся стандартные IP-блокировки?

В файле samp.ban в корневой папке сервера.

Где хранить уровни администрации?

В MySQL или другой серверной базе. Не следует выдавать права простой проверкой ника в PWN.

Что лучше: уровни или отдельные разрешения?

Для небольшого проекта достаточно уровней. Для большого персонала удобнее роли и отдельные разрешения.

Какие команды нужны младшему администратору?

Ответы на репорты, наблюдение и ограниченный набор мягких наказаний.

Кому выдавать постоянный бан?

Только старшим сотрудникам с обязательным журналом и доказательствами.

Нужно ли логировать телепортацию?

Да, особенно перемещение других игроков и вмешательство в игровые ситуации.

Нужно ли логировать выдачу денег?

Обязательно. Следует сохранять значение до операции, изменение, результат и причину.

Где смотреть ошибки сервера?

В server_log.txt, а при аварийном завершении также в crashinfo.txt и выводе CrashDetect.

Как смотреть журнал Linux в реальном времени?

tail -f server_log.txt

Почему сервер выключился?

Проверьте последние строки server_log, crashinfo, загрузку плагинов, игровой AMX и состояние MySQL.

Как часто создавать резервные копии?

Регулярно, а также перед каждым обновлением, изменением базы или установкой плагина.

Можно ли хранить копии только на рабочем VPS?

Нет. Дополнительная копия должна находиться за пределами рабочего сервера.

Нужно ли часто перезапускать сервер?

Перезапуск выполняется для обслуживания или применения изменений. Постоянные перезапуски без анализа могут скрывать ошибку.

Как правильно обновлять игровой мод?

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

Что делать при злоупотреблении администратора?

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

Можно ли удалять старые административные логи?

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

Можно ли публиковать логи сервера?

Перед публикацией необходимо удалить пароли, токены, реквизиты базы и лишние персональные данные.

Официальные и технические источники

• Управление сервером и команды RCON
• Настройка server.cfg и журналов
• Распространённые ошибки серверного ядра
• Проверка авторизации RCON-администратора
• Обработка попыток входа в RCON
• Серверные адаптации CRMP