При развертывании 1С:Предприятие на операционных системах семейства Linux (в частности, RedOS 8) системные администраторы часто сталкиваются с ситуацией, когда локальный запуск тонкого клиента проходит успешно, но пользователи, подключающиеся через веб-сервер Apache, получают ошибку "Не найдена лицензия". Это особенно актуально для файловых баз данных, где функционал раздачи лицензий ложится на плечи модуля расширения веб-сервера.
В данной статье мы подробно разберем, почему возникает эта проблема, проанализируем механизм взаимодействия программных лицензий с аппаратными ключами HASP и составим пошаговый план настройки сервера для корректной работы.
Для начала проанализируем ситуацию: когда база опубликована на веб-сервере (Apache или Nginx), именно веб-сервер берет на себя роль «менеджера», который должен найти лицензию и «выдать» ее сессии пользователя. В Windows за это отвечает библиотека wsisapi.dll, а в среде Linux — её аналог wsisapi.so.
Важно понимать, что в файловом варианте у нас нет сервера приложений 1С (кластера), который мог бы централизованно управлять лицензиями. Следовательно, модуль wsisapi.so должен иметь физический доступ либо к файлам программных лицензий (.lic), либо к аппаратному USB-ключу защиты. Рассмотрим основные причины, по которым этот доступ может быть ограничен.
Выясним причину, связанную с типом лицензии. Существует специфический сценарий, когда программная лицензия активируется с привязкой к серийному номеру аппаратного ключа HASP. В этом случае для успешного запуска 1С требуются оба компонента.
Часто проблема заключается в том, что веб-сервер пытается инициализировать только аппаратный ключ, игнорируя программную лицензию, или наоборот. Проверим конфигурационный файл 1С, который находится по пути /opt/1C/v8.3/x86_64/conf/conf.cfg (путь может отличаться в зависимости от версии платформы).
Убедимся, что параметр Hasps установлен в значение 1, что разрешает использование аппаратных ключей:
Hasps=1
Multicast=1
Разберем ситуацию с правами доступа в Linux. Это самая распространенная причина сбоев. Программные лицензии обычно хранятся в директории /var/opt/1C/licenses. Если лицензия была активирована под учетной записью root, файлы могут иметь права, запрещающие чтение другим пользователям.
Проанализируем, от чьего имени запущен процесс Apache. В RedOS это обычно пользователь apache. Нам необходимо предоставить этому пользователю права на чтение файлов лицензий и на выполнение для всех родительских каталогов.
Выполним последовательно команды для установки корректных прав:
# Передаем владение папкой с лицензиями пользователю apache
chown -R apache:apache /var/opt/1C/licenses
# Устанавливаем права на чтение для файлов и выполнение для папок
chmod -R 755 /var/opt/1C/licenses
Если используется связка программной лицензии с HASP-ключом, модуль wsisapi.so должен иметь права на чтение устройства из каталога /dev/bus/usb/. По умолчанию доступ к системным устройствам ограничен.
Создадим правило udev, чтобы разрешить пользователю веб-сервера работать с ключом. Создадим файл /etc/udev/rules.d/99-hasp.rules и добавим в него настройки:
# Правило для HASP ключей Aladdin Knowledge Systems
SUBSYSTEM=="usb", ATTR{idVendor}=="0529", ATTR{idProduct}=="0001", MODE="0664", GROUP="apache"
После создания файла необходимо перезагрузить правила командой udevadm control --reload-rules и переподключить ключ.
В RedOS по умолчанию активна система безопасности SELinux, которая может блокировать попытки Apache обратиться к файлам вне стандартных путей или взаимодействовать с драйвером защиты. Рассмотрим, как проверить, является ли SELinux причиной проблемы.
Временно переведем SELinux в режим аудита:
setenforce 0
Если после выполнения этой команды лицензии начали раздаваться, значит, нам необходимо настроить политики безопасности. Вместо полного отключения SELinux, рекомендуется назначить правильный контекст безопасности папке с лицензиями:
chcon -R -t httpd_sys_content_t /var/opt/1C/licenses
Посмотрим на настройки самой публикации базы. В 1С версии 8.3.25 и выше появились дополнительные механизмы управления сессиями. Для того чтобы веб-сервер более корректно обрабатывал раздачу лицензий, мы можем принудительно включить использование разделяемых лицензий.
Откроем файл default.vrd (обычно находится в /var/www/html/название_базы/) и добавим параметр useSharedLicense:
<point name="BaseName"
alias="base"
ib="File='путь_к_базе';"
useSharedLicense="true"/>
Этот параметр сообщает модулю расширения, что он должен пытаться использовать одну многопользовательскую лицензию для нескольких соединений в рамках одной сессии, что критично для веб-клиентов.
Проанализируем состояние демона haspd. Даже если ключ вставлен, без запущенного драйвера (aksusbd) система не сможет получить его серийный номер для валидации программной лицензии. Проверим статус службы:
systemctl status haspd
Если служба не активна, запустим ее и добавим в автозагрузку:
systemctl enable --now haspd
Если вышеперечисленные шаги не помогли, воспользуемся мощным инструментом диагностики — Технологическим журналом (ТЖ). Настроим сбор событий поиска лицензий. Создадим файл /opt/1C/v8.3/x86_64/conf/logcfg.xml со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="/var/log/1c/logs" history="24">
<event>
<eq property="Name" value="LEvent"/>
</event>
<property name="AllProperties"/>
</log>
</config>
Важно: убедитесь, что у пользователя apache есть права на запись в папку /var/log/1c/logs. После попытки входа в логах появится событие LEvent, где будет детально расписано: по каким путям шел поиск, какие файлы были найдены и какая именно ошибка возникла (например, Access Denied).
Подводя итог, отметим: решение проблемы раздачи лицензий на Linux почти всегда кроется в правах доступа и контексте выполнения процесса веб-сервера. Тщательная проверка цепочки «Пользователь Apache -> Доступ к папке лицензий -> Доступ к USB-устройству» позволяет устранить ошибку в 99% случаев.