При работе с многопользовательскими аппаратными ключами защиты HASP системные администраторы часто сталкиваются с неочевидным поведением платформы «1С:Предприятие». Особенно ярко это проявляется при обновлении платформы (например, на ветку 8.3.11) и переносе баз данных между тестовыми и боевыми окружениями. Классический сценарий: на одном сервере удаление конфигурационного файла nethasp.ini мгновенно приводит к потере лицензий, а на другом — сервер продолжает бесперебойно работать и раздавать лицензии клиентам через веб-сервер. В этой статье мы подробно разберем, как именно функционирует механизм поиска HASP-ключей в современных версиях 1С, и выясним истинные причины такого поведения.
Для начала проанализируем базовый алгоритм работы HASP-драйвера и сервера 1С. Когда файл nethasp.ini отсутствует в каталогах системы или в нем не заданы жесткие настройки, платформа не прекращает поиск лицензий. Вместо этого она переходит на настройки по умолчанию. Режим по умолчанию предполагает автоматический поиск менеджеров лицензий (HASP License Manager) в локальной сети.
Этот поиск осуществляется следующим образом:
475.hasplm (служба nhsewice.exe) с активным сетевым ключом, он ответит на этот запрос.Таким образом, если боевой сервер находится в одном физическом или виртуальном сегменте сети (VLAN) с сервером лицензирования, удаление файла nethasp.ini никак не повлияет на работоспособность системы — поиск по умолчанию (Broadcast) успешно отработает за доли секунды.
Рассмотрим ситуацию с тестовым сервером, который при удалении конфигурационного файла мгновенно перестал запускать пользователей через веб-сервер. Здесь ключевую роль играет сетевая архитектура:
nethasp.ini, в котором был жестко прописан IP-адрес менеджера лицензий, тестовый сервер физически не может «достучаться» до ключа с помощью широковещательного запроса. Как результат — мгновенная ошибка получения лицензии.Еще один важнейший нюанс, который часто вводит администраторов в заблуждение, — это кэширование конфигурационных файлов рабочими процессами сервера 1С (rphost и rmngr). Проанализируем, как они работают с файлом настроек:
Файл nethasp.ini считывается процессами сервера 1С только один раз — в момент их инициализации (запуска). Если боевой сервер работает под постоянной высокой нагрузкой, его рабочие процессы могут не перезапускаться сутками. Когда вы удаляете файл nethasp.ini на «живом» сервере, процессы rphost продолжают использовать старые настройки, которые уже сохранены в их оперативной памяти. Изменения вступят в силу только после перезапуска службы ragent (Агент сервера 1С:Предприятия) или после планового перезапуска рабочих процессов по таймауту.
На тестовом сервере пользователи заходят редко, процессы могут завершать работу из-за простоя или служба перезапускалась в ходе тестов вручную, поэтому там изменения применились незамедлительно.
Вы уверены, что удалили абсолютно все файлы nethasp.ini? Платформа «1С:Предприятие» имеет строго определенный приоритет каталогов для поиска файлов конфигурации HASP. Давайте разберем по шагам, где именно сервер 1С может находить дублирующие файлы настроек:
C:\Program Files\1cv8\8.3.11.XXXX\bin\conf\nethasp.ini (или аналогичный путь для x86-версии в Program Files (x86)).USR1CV8): %USERPROFILE%\AppData\Local\1C\1cv8\conf\nethasp.ini.C:\Program Files\1cv8\conf\nethasp.ini.conf.cfg.Если вы удалили файл из папки конкретного релиза, но забыли про общий каталог ...\1cv8\conf\ или профиль пользователя службы, 64-разрядный боевой сервер продолжит считывать настройки из этих резервных мест.
Не стоит забывать и о физическом расположении ключей защиты. Если многопользовательский клиентский ключ (красного цвета) или серверный ключ защиты подключен непосредственно к боевому серверу (физически в USB-порт или проброшен в виртуальную машину через USB-over-IP технологии), то сервер 1С может забирать лицензии напрямую через драйвер HASP Device Driver.
При таком сценарии служба HASP License Manager вообще не участвует в процессе, а файл nethasp.ini полностью игнорируется, так как он предназначен исключительно для управления сетевым поиском через протоколы TCP/IP или IPX.
Чтобы избежать хаотичного поиска ключей в сети и сделать поведение серверов предсказуемым, мы рекомендуем жестко прописывать параметры подключения. Рассмотрим правильную структуру файла nethasp.ini, при которой широковещательный поиск отключается, а опрос идет строго по целевому IP-адресу:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь IP-адрес вашего HASP License Manager
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP
NH_USE_BROADCAST = Disabled
Параметр NH_USE_BROADCAST = Disabled критически важен. Он запрещает забивать локальную сеть лишними UDP-пакетами и гарантирует, что если указанный сервер лицензий (в нашем примере 192.168.1.100) недоступен, 1С не начнет хаотично забирать случайные лицензии из других ключей в сети.
Если вы столкнулись с тем, что поведение вашей системы лицензирования кажется аномальным после обновления платформы на 8.3.11, выполните следующие шаги для локализации проблемы:
nethasp.ini на стороне сервера станут неактуальными.nethasp.ini на всем системном диске сервера, обращая особое внимание на папки профиля пользователя USR1CV8.ragent), чтобы очистить кэш рабочих процессов.