← На главную

При развертывании веб-доступа к информационной базе через веб-сервер Apache или IIS системные администраторы часто сталкиваются со странной ситуацией: приобретены клиентские лицензии на 20 или более рабочих мест, однако система настойчиво пускает только 10 пользователей, а последующие подключения завершаются ошибкой нехватки лицензий. Разберем по шагам, почему возникает жесткая планка именно в 10 подключений, как расшифровать сообщения в системном журнале и как правильно настроить раздачу лицензий на сервере под управлением Linux.

В чем главная причина лимита ровно в 10 подключений

Первое предположение, которое обычно возникает у администратора, — проблема кроется в клиентских лицензиях или веб-сервере. Однако в архитектуре платформы 1С:Предприятие 8.3 заложено специальное поведение для 64-разрядного сервера на Linux: если служба кластера серверов не находит действующую лицензию на сам сервер 1С, она не прекращает работу немедленно, а переходит в демонстрационный или ограниченный режим. В этом режиме сервер разрешает установить суммарно не более 10 сеансов.

Как только открывается одиннадцатый сеанс, кластер блокирует подключение сообщением о невозможности выдачи лицензии. При этом суммарный номинал клиентских лицензий (хоть 20, хоть 100 мест) не играет никакой роли, так как лимит накладывается на уровне ядра сервера. Таким образом, ограничение в 10 подключений — это прямой симптом того, что сервер 1С не видит лицензию на сервер, а не клиентские лицензии.

Анализ системного лога: что значит ошибка программного файла

Рассмотрим характерное сообщение, которое в подобной ситуации фиксируется в технологическом журнале платформы:

Software licensing error. Program license file does not support running 1C:Enterprise server: file:///opt/1C/v8.3/x86_64/conf/20160909165320.lic

Проанализируем эту запись подробно. Она не сообщает о повреждении клиентской лицензии. Алгоритм запуска службы сервера устроен так: сервер опрашивает локальные аппаратные порты и просматривает системные каталоги лицензий в поисках серверной лицензии. Обнаружив программный файл клиентской лицензии, служба фиксирует, что данный файл не содержит прав на запуск 64-битного сервера (does not support running 1C:Enterprise server), и продолжает поиск дальше. Если в итоге ни программный пин-код сервера, ни аппаратный USB-ключ сервера не обнаруживаются, кластер активирует режим с лимитом в 10 подключений.

Диагностика аппаратного USB-ключа сервера на Linux

Если для работы сервера используется физический USB-ключ защиты (обычно зеленого или фиолетового цвета для сервера 1С), в среде Linux его работа может нарушаться по нескольким системным причинам. Проверим доступность ключа последовательно:

1. Проверка видимости устройства в шине USB: выполним в консоли команду lsusb. В выводе должно присутствовать устройство компании Aladdin Knowledge Systems или Sentinel. Если система не видит само устройство на аппаратном уровне, проверяем физическое подключение, работу USB-порта и проброс устройства, если сервер работает в виртуальной машине.
2. Проверка работы службы защиты: для взаимодействия платформы с аппаратными ключами в операционной системе должны быть установлены и запущены службы haspd или aksusbd. Проверим статус сервиса через systemctl status haspd. Без запущенного демона сервер 1С не сможет взаимодействовать с аппаратным ключом.
3. 32-битные библиотеки и зависимости: исторически компоненты службы aksusbd содержат 32-битные библиотеки. На чистых 64-разрядных дистрибутивах Linux демон может падать или работать некорректно без установленных пакетов совместимости (таких как glibc.i686 или 32-битная версия libusb).
4. Права доступа к файлам устройств: процессы кластера 1С запускаются от системной учетной записи usr1cv8. Служба сервера и демон защиты должны иметь права на чтение и запись узлов в каталоге /dev/bus/usb/. При необходимости скорректируем правила подсистемы udev.
5. Проверка через веб-интерфейс: если используется современный драйвер Sentinel LDK, откроем в браузере локальную панель управления по адресу http://localhost:1947 и проверим вкладку с доступными ключами.

Правила объединения клиентских лицензий

В исходной задаче фигурируют две лицензии по 20 рабочих мест. Разберем, как ведет себя платформа в зависимости от типа этих лицензий:

1. Если клиентские лицензии программные (файлы с расширением lic): программные лицензии отлично суммируются кластером серверов. Для этого файлы лицензий должны быть активированы на одном сервере с одинаковыми параметрами и помещены в общесистемный каталог, доступный процессам 1С, например /var/1C/licenses. В этом случае кластер объединит пулы: 20 + 20 = 40 доступных мест.
2. Если клиентские лицензии аппаратные (USB-ключи серии ORGL8): два сетевых пользовательских ключа одной серии, вставленные в один и тот же физический сервер, не суммируются. Драйвер увидит только один из них (максимум 20 мест), а второй ключ будет полностью проигнорирован.

Чтобы задействовать второй аппаратный ключ, разнесем их физически: установим второй ключ в другой компьютер локальной сети, запустим на нем HASP License Manager и настроим сетевое обращение к нему через конфигурационный файл nethasp.ini.

Особенности лицензирования веб-клиентов и параметры базы данных

При подключении пользователей через браузер необходимо учитывать специфику работы веб-сервера:

1. Сеансовый подсчет лицензий: при входе через браузер лицензия всегда тратится на конкретный сеанс, а не на компьютер. Если пользователь откроет программу в двух разных вкладках одного браузера, система спишет две клиентские лицензии.
2. Зависшие веб-сессии: если сотрудник просто закрывает вкладку браузера без нажатия кнопки выхода, его сеанс продолжает «висеть» на сервере до окончания таймаута спящего сеанса (по умолчанию около 20 минут). В консоли администрирования кластера серверов 1С полезно контролировать список активных сеансов и при необходимости сократить таймаут завершения неактивных сеансов для веб-клиентов.
3. Раздача лицензий сервером: в свойствах информационной базы параметр Разрешить выдачу лицензий сервером 1С:Предприятия должен быть установлен в значение Да, если требуется, чтобы кластер серверов сам распределял многопользовательские программные лицензии подключающимся веб-клиентам.
4. Права веб-сервера: если веб-сервер Apache настроен на самостоятельный поиск лицензий, учетная запись службы (например, www-data или apache) должна обладать правами на чтение каталогов, где расположены файлы .lic.

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