CatABMS

CatABMS (Catware Advanced Bot Manipulating System, Расширенная Система Управления Ботами Catware) - разработанный Catware, и до сих пор не вышедший в свет (почти) синхронный фреймворк для создания ботов для социальной сети ВКонтакте. Имеет несколько ответвлений.

Структура системы

Система выполнена в стандарте CFHS - Catware File Hierarhy System, аналог для FHS:

chains - файлы CatABMS Chains

chats - БД чатов

commands - исполняемые файлы и конфиги команд

configs - конфигурационные файлы CatABMS

corerc - Файлы CoreRC (Core Running Commands), выполняющиеся при получении сообщения.

exf - исполняемые файлы CatShell

json - модифицируемые системой конфигурационные файлы

lib - библиотеки, необходимые для работы ядра или иных компонентов системы

modules - конфигурационные файлы системы модулей

services - исполняемые файлы Catware Autostart, выполняющиеся при старте бота

tmp - временные файлы, которые удаляются CoreRC-модулем CSM (Catware Space Manager).

users - БД пользователей

catenv.py - файл с взаимосвязанными DEFами, необходимыми для работы системы - фактически API системы.

core.py - ядро, обрабатывающее входящие сообщения

faststart.py - загрузчик системы

Структура: Загрузчик

Идёт начальная загрузка модулей: sys, os, psutil.

Далее идёт загрузка CatENV. Файл загружается в память, выполняется и удаляется.

Активируется система автономности: установщик модулей, который за вас установит и импортирует все модули, следуюя логике сетов модулей. Сет модулей состоит из:

1. Списка модулей, которые необходимо установить через PIP
2. Строк, которые необходимо выполнить через exec, наподобии import ...
3. Скрипт иницилизации модулей, которые требуют обозначения их обьекта

Если какой-то из модулей импортировать не удалось, то идёт переустановка всего сета модулей.

Всего их 3:

1. base-system (Базовые пакеты, которые даже устанавливать не надо)
2. media (В основном, это модули, работающие с API/парсеры некоторых сервисов)
3. network (В основном, это те, что коим-то боком работают с сетевым стеком.)

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

Выполняются функции CatENV - getreportban, getban, getmuted, gettroll.

Определяется операционная система, исходя из значения os.name.

Далее идёт подготовка к запуску ядра.

Система авторизуется во ВКонтакте, бесконечно дёргая при этом метод авторизации, пока не получится залогиниться во ВКонтакте.

Когда залогиниться наконец получается, то управление косвенно передаётся ядру: при нажатии Ctrl+C ядро выгружается из памяти и активируется CatShell - оболочка командой строки, работающая с EXF-файлами (CatShell EXecutable Files)

По команде exit, ядро вновь начинает свою загрузку.

Когда управление передаётся ядру:

Структура: Ядро

Когда управление передано ядру, оно занимается загрузкой библиотек:

1. detectfull, чтобы при обработке картинок качество не шакалилось
2. surrogate-manager, ныне не рабочая библиотека
3. CUMv2 - Catware User Manager второй версии. Работает с БД пользователей и чатов.
4. generrorcode - генератор индивидуальных кодов ошибок

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

Затем загружаются CoreRC файлы, и выполняется Catware Autostart

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

Начинается оно с очистки лишних переменных компонентом Catware MemGun.

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

Сообщается всем администраторам о запуске бота: сообщается IP сервера, операционная система и хостнейм.

Ядро начинает слушать LongPoll-сервера ВКонтакте на события.

Если получен обьект нового/отредактированного сообщения, полученного НЕ ОТ ГРУППБОТА, то начинается разбор текста сообщения. Если же оно пустое/некорректное, то на событие ставится метка о невыполнении, дабы освободить ядро от лишних нагрузок.

Если же обьект события полностью корректен, то получается следующая информация:

- ID пользователя

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

- Обьект получателя

- Переданная команда

- Переданные параметры

- Переданные флаги

- ID чата, если получено в беседе

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

1. Начинается проверка на наличие переданной команды в списке команд
2. Запускаются модули CoreRC
3. Проверка на реплаи: если обнаружен реплай и не передан параметр, то текст из реплайнутого сообщения будет использоваться как параметр
4. Проверка вложений в сообщении
5. Проверка на значение выполняемого идентификатора цепочки
6. Если всё соответствует ПЕРВОМУ случаю, то выполняется команда
7. Если обнаружен ВТОРОЙ случай (команда из списка потенциально оскорбительных команд), проверяется согласие пользователя на то, чтобы выполнить эту команду, если же пакет подключен - она выполняется.
8. Если обнаружен ТРЕТИЙ случай (команда для тестеров), проверяется наличие метки тестера у пользователя, если она имеется - команда запускается, если нет - пользователь получает соответствующее уведомление и приглашается в программу бета-тестирования
9. Если же команда при выполнении крашнулась, то багрепорт отправляется админам в нём сообщается вызванная команда, полный Traceback, ID диалога, идентификатор команды, время вызова команды, код ошибки, а пользователю остаётся видеть сообщение об ошибке.
10. Если обнаружена ошибка, связанная с правами администрирования в том или ином чате, но у бота нет админки в беседе, отправляется соответствующее сообщение
11. Если обнаружен ЧЕТВЁРТЫЙ СЛУЧАЙ, то задействуется модуль цепочки, указанный у юзера в параметре stage.
12. Если обнаружен ПЯТЫЙ случай (выход из цепочки), параметр stage попросту обнуляется.
13. Если же пользователь обнаружен в забаненых, то ничего не выполняется, а пользователь посылается нахуй.

Далее идёт проверка других типов событий:

1. GROUP_LEAVE = отписавшемуся пользователю пишется в Л/С требование обьяснить своё действие, в целях улучшения бота.
2. GROUP_JOIN = благодарность за подписку в Л/С.
3. MESSAGE_REPLY = логирование и подсчёт отправленных сообщений
4. WALL_POST_NEW = в беседу группы отправляется новая запись на стене бота.
5. Также идёт проверка нагрузки на оперативную память, если занято больше 90% - сообщается об этом админам.
6. Очистка памяти инструментом MemGun (Memory Gun)

-- Продолжение следует --