Перенаправление вывода журнала регистрации

Общий тренд на усиление позиций Linux в отечественной IT-индустрии стимулирует более глубокое погружение, в том числе и в 1С-ном сообществе. По себе знаю, что переключаться после многолетнего опыта работы на Windows может быть достаточно проблематично. Как обычно, самый эффективный способ - это наличие реальных практических задач. Пусть даже бессмысленных и беспощадных, но дающих возможность руками пощупать, и получить результат. Далее предлагается рассмотреть и реализовать пример такой задачи.

Как известно, в концепции Linux/Unix "всё есть файлы". Это может быть мозголомным, но по факту очень полезным отличием от привычных сущностей в Windows. Что значит "все есть файлы"? Буквально это и значит. Файлы с данными, каталоги, настройки, сокеты, устройства, счетчики ресурсов и т.д. - все это в концепции ОС является файлами, пусть и с рядом особенностей. Даже информация и настройки самого ядра тоже представлена файлами, которые можно при желании модифицировать. И базовые операции с этими файлами выполняются одинаково. По мне так это очень удобно и клёво.

Как же мы можем использовать эту концепцию для эксплуатации систем на платформе 1С?

Давайте вспомним, как платформа работает, например, с логами журнала регистрации (далее ЖР) или настройками кластера: она выводит или читает данные в файлы. Удачное совпадение. На Инфостарте достаточно много публикаций по работе с файлами ЖР: различные приемы по сбору, консолидации, анализу, визуализации и т.д. Но, если не ошибаюсь, все они направлены на постобработку данных из файлов ЖР. Т.е. сначала платформа сохранила данные в файлы ЖР, а потом мы эти файлы читаем, и обрабатываем полученную информацию. Сразу определимся, что никаких претензий к такому подходу не имеем. Знаем, любим, практикуем.

Можно ли сделать иначе? Похоже, что да. Мы можем реализовать собственное устройство, представленное файлом в операционной системе, в который можно будет писать как в обычный файл ЖР. Эту гипотезу и будем проверять в нашем эксперименте.

Подготовка

Для эксперимента используем:

• хост на Windows 11 x64
• VirtualBox 7.0.10
• гостевая ОС: образ ALT Linux Workstation 10.1 x64
• актуальная на момент эксперимента платформа 8.3.23.1782 x64

Скачиваем с официальных сайтов VirtualBox, ALT Linux Workstation, разворачиваем  виртуальную машину 3 ядра, 2 Гб ОЗУ, 50 Гб hdd. Всё по дефолту, никаких особенных настроек, создаем пользователя user, запускаем ВМ. Кстати, ALT Linux на MATE выглядит вполне себе хорошо. Взял ОС сразу с графической оболочкой, чтобы там же тестировать запуск платформы.

На всякий случай обновим ядро. Можно сделать через меню: Меню (а-ля кнопка Пуск) -> Центр управления -> Администрирование -> Центр управления системой -> Обновление ядра -> Обновить ядро.

Запускаем терминал. Для удобства работы и порядка в каталоге пользователя user создает папку под проект. Назовем проект 1cv8lgf. В этом каталоге ведем всю разработку и сборку драйвера. Создаем в каталоге файл с кодом модуля и файл с правилами сборки.

mkdir /home/user/1cv8lgf
cd /home/user/1cv8lgf
touch 1cv8lgf.c
touch Makefile

Драйвер

Примеры реализации драйвера находим в сети по запросу "linux writing character device driver". Статей для изучения вполне достаточно, но если коротко по матчасти, то писать драйвер мы будет на C; каждый драйвер вне зависимости от типа имеет точку входа и выхода; конкретно драйвер текстового устройства должен содержать обработчики событий открытия, закрытия, записи и чтения. Код файла 1cv8lgf.c ниже:

#include <linux/module.h>
#include <linux/string.h>
#include <linux/fs.h>
#include <asm/uaccess.h>

// https://appusajeev.wordpress.com/2011/06/18/writing-a-linux-character-device-driver/

// module attributes
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("1c log redirection driver");

static char msg[100]={0};
static short readPos=0;
static int times=0;

// prototypes
static int dev_open(struct inode *, struct file *);
static int dev_rls(struct inode *, struct file *);
static ssize_t dev_read(struct file *, char *, size_t, loff_t *);
static ssize_t dev_write(struct file *, const char *, size_t, loff_t *);

// structure containing callbacks
static struct file_operations fops =
{
    .read = dev_read,
    .open = dev_open,
    .write = dev_write,
    .release = dev_rls,
};

// main()
int init_module(void)
{
    int t = register_chrdev(89, "1cv8lgf", &fops);
    
    if (t<0) printk(KERN_ALERT "Device registration failed... \n");
    else printk(KERN_ALERT "Device registered...\n");
    
    return t;
};

// destructor
void cleanup_module(void)
{
    unregister_chrdev(89, "1cv8lgf");
};

// command "open"
static int dev_open(struct inode *inod, struct file *fil)
{
    times++;
    printk(KERN_ALERT "Device opened %d times", times);
    return 0;
};

// command "read"
static ssize_t dev_read(struct file *filp, char *buff, size_t len, loff_t *oll)
{
    short count=0;
    while (len && (msg[readPos]!=0))
    {
	put_user(msg[readPos], buff++);
	count++;
	len--;
	readPos++;
    }
    
    return count;
};

// command "write"
static ssize_t dev_write(struct file *filp, const char *buff, size_t len, loff_t *off)
{
    short ind = len-1;
    short count=0;
    memset(msg, 0, 100);
    readPos=0;
    while(len>0)
    {
	msg[count++] = buff[ind--];
	len--;
    }
    return count;
}

// command "close"
static int dev_rls(struct inode *inod, struct file *fil)
{
    printk(KERN_ALERT "Device closed\n");
    return 0;
}

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

Сборка

Код файла правил сборки Makefile. Обратите внимание, файл именуется с заглавной буквы.

obj-m := 1cv8lgf.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

 Далее необходимо выполнить сборку модуля, инсталлировать и запустить наше устройство. В моей версии ОС потребовалось доустановить модули сборки и ядра. Переключаемся под root.

su -

Кстати, столкнулся с тем, что не работал sudo в ALT Linux. Помогла команда

control sudowheel enabled

Обновляем пакеты

apt-get update
apt-get upgrade

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

apt-get install gcc

Доустанавливаем модули ядра

apt-cache search linux-headers
apt-cache search kernel-headers
apt-get install kernel-headers-modules*

Можно собирать модуль драйвера (вызываем команду, находясь в каталоге проекта)

make 1cv8lgf

В случае успеха получаем в каталоге проекта файлы 1cv8lgf.o или 1cv8lgf.ko. Загружаем  драйвер.

insmod 1cv8lgf.ko

Выгрузить драйвер можно через: rmmod 1cv8lgf.ko , но мы этого делать не будем, а просто возьмем на заметку. 

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

cat proc/modules

// результат
...
1cv8lgf 16384 0 - Live 0xffffffffa0693000 (OE)
...

... или через список устройств.

cat /proc/devices

// результат
...
Character devices:
...
89 1cv8lgf
...

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

chmod 666 /dev/1cv8lgf

Тестируем ввод/вывод через устройство: передаем на вход текстовую строку.

echo "test" >> /dev/1cv8lgf
cat /dev/1cv8lgf

// результат
test

При выводе содержимого получаем строку, которую и подавали на вход. Уже неплохо. Еще раз обращаю внимание на то, что с драйвером, как и со многими объектами ранее по тексту, мы работает как с обычным файлом.

Далее ставим платформу. На самом деле тут последовательность не существенна, платформу можно было поставить хоть с самого начала. Не нужен сервер и лицензии. Достаточно просто платформы. Да, при запуске мы получим сообщение об отсутствии лицензии, но запись в ЖР о новом сеансе уже все равно появится.

Тестируем устройство

Создаем новую пустую файловую базу в произвольном каталоге. Я складывал в /home/user/bases/testBase. Можно выполнить первый вход в базу, чтобы автоматически в каталоге базы создался каталог 1Cv8Log и сопутствующие файлы, а можно создать каталог руками. Если первый вход все же выполнен, то необходимо удалить из каталога /home/user/bases/testBase файл логов.

rm 1Cv8.lgf

Теперь необходимо создать ссылку на наше устройство в каталоге логов базы. Наименование ссылки будет соответствовать наименованию обычного файла логов "1Cv8.lgf", чтобы платформа находила там именно то, что и хотела. Дадим на всякий случай права на созданную ссылку.

ln -s /dev/1cv8lgf 1Cv8.lgf
chmod 666 1Cv8.lgf

В результате в каталоге /home/user/bases/testBase/1Cv8Log должен отображаться файл "1Cv8.lgf".  В интерфейсе он будет иметь небольшую стрелку в иконке, наподобие как у ярлыков в Windows. А при просмотре содержимого каталога через терминал увидим, куда ссылка ведет.

ls -l

// результат
...
... 1Cv8.lgf -> /dev/1cv8lgf
...

Запускаем нашу тестовую базу из /home/user/bases/testBase. У меня вываливалось сообщение об отсутствии лицензии, система заканчивала работу, и этого было достаточно. Проверяем, что же записалось в наше устройство ввода/вывода.

cat /dev/1cv8lgf

// результат
1CV8LOG(ver 2.0)
0524f209-de48-42e8-9df5-b183f06a26ee

{1,071523a4-516f-4fce-ba4b-0d11ab7a1893,"",1},
{2,"host-15",1},
{3,"1CV8",1},
{4,"_$Session$_.Authentication",1},
{13,1,1},
{4,"_$Session$_.Start",2},
{4,"_$Session$_.Finish",3}

Успех.

Выводы

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

- сама возможность получать логи ЖР "на лету" выглядит интересно; консолидация, мониторинг, алертинг, дата майнинг, машин лёрнинг.. Остапа понесло...

- можно сказать, что таким образом мы изобрели "новый" формат хранения ЖР ))) только для обработки и хранения кроме SQLite мы сможем использовать что душе угодно;

- как на счет редиректа логов ЖР через стандартный поток вывода из Docker?

- почему же речь только про логи ЖР? а как же технологический журнал? ведь там тоже файлы ))) кто хочет получать консолидированный поток данных логов ТЖ без необходимости "ковыряния" большого количества фалов?