Релиз технологической платформы 1С:Предприятие 8.3 (8.3.22.2143)
Вариант работы: Серверный

Добрый день, столкнулись со следующей ситуацией.
Имеется три компьютера (буду называть их по IP), все три используют ОС Ubuntu:
- 192.168.51.5 (Основной сервер, в него включен сетевой HASP на 20 лицензий. В настройках баз, размещенных на нем, стоит Разрешить выдачу лицензий сервером 1С:Предприятия: Да)
- 192.168.52.5 (Другой сервер, на нем размещена одна база и используется 20 программных лицензий, также раздаются сервером)
- 192.168.51.9 (Обычный компьютер, который используется для складирования и хранения ночных бэкапов)

Также имеется ключ на 5 лицензий от сервера Mini, который раньше стоял в 192.168.52.5, но было принято решение переместить этот ключ в 192.168.51.9, т.к. в сети 192.168.51.0 периодически не хватает 20 лицензий HASP.

Проблема следующая: 5-пользовательский HASP настроен на 192.168.51.9, если прописать в сети 192.168.49.0 у любого пользователя в файле nethasp.ini адрес 192.168.51.9, то он увидит этот ключ как сетевой и использует в 1С. Также пользователи 192.168.49.0 спокойно могут брать программные лицензии 192.168.52.5.
Если же пользователю сети 192.168.51.0 прописать в nethasp.ini к 192.168.51.9, то он немного “задумается” при подключении, после ввода пароля скажет, что искал аппаратную лицензию больше 3 секунд и предложит отключить ее поиск. Если нажать Нет или Да, то в любом случае 1С задействует лицензию от HASP 20.

Т.е. пользователи сети 192.168.51.0 не могут даже принудительно взять никакие лицензии, кроме HASP 20, которые раздаются сервером (192.168.52.5 тоже никак).
Но самое интересное, что если отключить раздачу лицензий сервером 192.168.51.5 (у конкретной базы), то при попытке входа возможно 2 исхода – либо программа скажет, что лицензии вообще не обнаружено и предложит ее восстановить, либо зайдет в 1С под лицензией HASP 20.

Соответственно вопрос – почему пользователи 192.168.51.0 не могут брать лицензии ниоткуда кроме HASP 20? Может потому, что в одной сети находится два ключа HASP? Или потому, что ключ HASP 5, стоявший в сервере Mini, не сочетается с HASP 20 по сети? Или возможно что-то не так настроено в СУБД PostgreSQL? Или это какая-то ошибка платформы?

Это 100% не проблема фаерволов, т.к. пользователи 192.168.49.0 спокойно могут получить HASP 5 от 192.168.51.9, а также если у пользователя сети 192.168.51.0 отключить и брандмауэр Виндовс, и Касперский, то результат от этого не меняется.

Получается, что пользователи одной подсети видят все ключи, у них все ОК,
пользователи второй подсети не видят одного ключа.

Тут явно проблема с сетями, а не с 1с

(0) Не раздавайте ключи сервером, при наличии хаспа :)

(0) Держи, как 1С ищет лицензии

Алгоритм поиска лицензий при запуске «1С:Предприятие» 8
https://infostart.ru/1c/articles/281119/#p3

(2) Как я уже указал, в случае отключения раздачи ключей сервером у баз на сервере 192.168.51.5 пользователи либо вообще не могут зайти, либо все равно заходят под HASP 20 (даже если в файле nethasp.ini у пользователя прописать только 192.168.51.9 или только 192.168.52.5)

Есть еще предположение, что два HASPLM могут между собой как-то конфликтовать. Как это можно проверить и как отключить HASPLM в Ubuntu, чтобы ключи при этом продолжили работать?

Также в консоли администрирования кластера 192.168.51.5 видно, что сейчас используется 22 сеанса - 5 получено клиентом и 17 сервером.
А модели ключей в Алладин мониторе написаны как HASPHL (20 лицензий) и HASP4 (5 лицензий)

(1) Вам всё таки смотреть проблемы с сетями.
У нас сделано так.
1. На сервере ключ серверный HASP + программные лицензии на 20. Ещу прописаны в ini где брать клиентские. (два HASP ключа конфликтуют на сервере)
2. Мини-сервер с сетевым НАSP-50, тупо для раздачи.
3. Делал сам для пробы  сетевой на HASP-5, раздача.
4. На клиентах, прописаны в ini где брать.

Итог, если на сервере закончились клиентские, то начинаются брать из сетевых.
Клиенты и сервера в разных подсетях, всё норм.

(0) во-первых - "1С:Предприятие 8.3. Сервер МИНИ на 5 подключений" никогда не поставлялся с аппаратным ключом, он был только с программными лицензиями
во-вторых - в комплект поставки "1С:Предприятие 8.3. Сервер МИНИ на 5 подключений" входят только пинкоды для получения самой лицензии на Сервер МИНИ, никаких клиентских ключей/лицензий нет
поэтому для начала бы определиться, что это за ключ

(8) Ключ на 5 мест: H4 NET5 217-61 ORGL8

(9) во-первых - это обычный клиентский ключ на 5 пользователей, он 100% НЕ из комплекта "1С:Предприятие 8.3. Сервер МИНИ на 5 подключений"
во-вторых - ключи с микропрошивкой 2.17 [на ключе 217-61] на линуксах работать не хотят
попробуй найти комп с Windows и воткнуть туда, должно заработать

(10) Такое тоже пробовали - один день все нормально проработало, на следующий день перестало (хотя компьютер не перезагружался), поэтому было принято решение вернуть ключ на линукс. Там он хотя бы несколько дней продержался до первой перезагрузки (при этом haspd.service успешно стартовал при ребуте)

тю.
если ты раздаешь hasp 20 только сервером 1С, то убери на этом сервере менеджер лицензий - HASP LM.
вот эта твоя фраза в (0)
- 192.168.51.5 (Основной сервер, в него включен сетевой HASP на 20 лицензий. В настройках баз, размещенных на нем, стоит Разрешить выдачу лицензий сервером 1С:Предприятия: Да)!

подразумевает, что HASP LM на этом компе (192.168.1.5) тебе и даром не нужен.
соответственно, не будет на нем менеджера лицензий, никто не сможет получать этот ключик HASP 20 по сети, кроме как сервера, в который он воткнут.

ну и кроме того, в nhsrv.ini (акцентирую - не в nethasp.ini у клиента, а именно в nhsrv.ini на сервере) есть параметр
- NHS_SERVERNAMES = LM1        ; Имя менеджера лицензий

естественно, что для разных серверов и разных менеджеров имена должны быть разными. Судя по (0) - ты в nhsrv.ini не лазил, соответственно у тебя оба два менеджера лицензий светятся в сети под одинаковым именем (которое по умолчанию).

а вообще поддержу (2) - раздавать hasp сервером - ммм..., не есть айс, но может быть необходимым в случаях web-клиентов или тонких клиентов извне, то есть таких клиентов, которые не находятся в твоей сети и ключик от HASP LM по сети получить физически не могут.

(12) Хорошо, в таком случае у меня 2 вопроса:
1) Если я остановлю службу haspd.service на сервере, то сервер сможет этот ключ раздавать по сети?
2) Где в linux найти файл nhsrv.ini? На винде его легко было найти, а тут не очень...

(14)>Где в linux найти файл nhsrv.ini? На винде его легко было найти, а тут не очень...

Для ОС Linux и MacOS название конфигурационного файла и местоположение по умолчанию не определено. Имя конфигурационного файла и путь до него указывается при помощи параметра «-c», например: ./hasplm -c /etc/nhsrv.ini
https://www.online-ufa.ru/content/articles/1c-nethasp-ini/

но сомневаюсь, что параметр NHS_SERVERNAMES = LM1 в данном случае чем-то поможет

(14)>Если я остановлю службу haspd.service на сервере, то сервер сможет этот ключ раздавать по сети?

если быть точным, то сервер по сети лицензии не раздает, а дает добро на запуск и сам "списывает" лицензию с ключа, т.е. запустить можно будет только ту базу, которая именно на этом сервере, файловую базу или на другом сервере в таком случае запустить будет нельзя

(14) без понятия, это к линуксоидам.
Я в линуксе не работаю, поэтому ни как называется служба МЕНЕДЖЕРА лицензий, ни где располагается  nhsrv.ini - абсолютно не знаю.

(16) ну...как сказать, как сказать.. пробовать надо
в nethasp.ini имеется зеркальный параметр
NH_SERVER_NAME    Параметр определяет имена серверов, на которых выполняется поиск менеджера лицензий (HASP License Manager). Параметр может содержать не более 6 имен. Каждое имя не может быть длиннее 7 символов.
Возможные значения: <Name1>, <Name2>,
Пример: NH_SERVER_NAME=LM1, LM2



PS: естественно broadcast на клиенте отключить разумеется. Чтобы работали ограничения и по IP и/или по именам типа LM1/LM2, широковещательный запрос надо зарезать. насмерть.

Если смотреть на текущую систему лицензирования, то выглядит так:
на 192.168.51.5 сервер раздает лицензии HASP 20 и HASPLM тоже раздает эти же лицензии
на 192.168.51.9 1ски в принципе нет, там только HASPLM раздает лицензии на 5 мест
на 192.168.52.5 сервер раздает программные лицензии 20 штук
Т.е. насколько понимаю, на 192.168.51.5 нужно отключить либо раздачу сервером, либо HASPLM?

Поставил на двух клиентов 192.168.51.4 и 192.168.52.4 идентичные файлы nethasp.ini со следующими настройками (только незакомменченные):

[NH_COMMON]

NH_IPX = Disabled     ; Use the IPX protocol
NH_NETBIOS = Disabled    ; Use the NETBIOS protocol
NH_TCPIP = Enabled    ; Use the TCP/IP protocol

[NH_TCPIP]

NH_SERVER_ADDR = 192.168.51.9    ; IP addresses of all the NetHASP
NH_TCPIP_METHOD = TCP        ; Send a TCP packet or UDP packet
                    ; Default:  UDP
NH_USE_BROADCAST = Disabled; Use TCPI/IP Broadcast mechanism.
                    ; Default:  Enabled

Как результат с 192.168.52.4 ловит спокойно, а с 192.168.51.4 все равно берет лицензию HASP 20, причем выдаваемую HASPLM

(21) Кэши на клиентах прибей и попробуй ещё раз.

(22) тот кэш, который в Appdata лежит? или еще какой-то есть?

(23) Тот самый.
З.Ы.: И да - маска у подсети/подсетей какая/какие?

Просто:

Это как раз про маски и подсети.

(24) чистка кэша не помогла...
Маска подсети на виндовом клиенте 192.168.51.4: 255.255.255.0
На 192.168.52.4: 255.255.255.0
На ubuntu 192.168.51.9: /24 (т.е. тоже 255.255.255.0)

Еще заметил, что на 192.168.51.9 не отключен ipv6, а на клиентах отключен. Это может влиять?

Хотя на 192.168.51.5 тоже ipv6 включен и все нормально раздается...

(21) кеш тут не при чем, грохни файлик 1cv8conn.pfl,
это в нём хранится информация о ранее полученной лицензии

(28) Такого файлика не лежит, к сожалению...

Заметил следующее: если на 192.168.51.5 вообще остановить службу haspd.service, то 192.168.51.4 спокойно находит лицензию на 5 мест.
Получается, что сервер 192.168.51.5 является приоритетным.
Отсюда вопрос: будет ли hasplm со стороны 192.168.51.9 раздавать лицензии, когда они закончатся со стороны hasplm 192.168.51.5?

(29) его не может не быть, ещё раз поищи
в линуксах должен быть тут ~/.1cv8/1C/1cv8

(30) в теории должен, но есть "нюанс" - если при поиске ключа клиент столкнётся с ключом, с которого лицензии одновременно раздаёт и сервер 1С и и другие клиенты сами получают их от HASP LM, то поиск следующего ключа по сети клиентом может не осуществляться

(31) Нашёл к своему удивлению на винде в папке ProgramData

(32) Тогда в таком случае нужно что-то из двух отключить на сервере?

(30) >> Заметил следующее: если на 192.168.51.5 вообще остановить службу haspd.service, то 192.168.51.4 спокойно находит лицензию на 5 мест.

Отсюда можно сказать, что 1С на клиенте 192.168.51.4 НЕ ВИДИТ твой nethasp.ini. Отсюда можно сделать вывод, что либо на этом клиенте еще где-то лежит другой nethasp.ini с настройками по умолчанию, либо твой nethasp.ini лежит не там, где нужно.
В любом случае 1С ТВОЙ nethasp.ini НЕ ВИДИТ. А видит или другой или вообще никакой.
Так что шерсти клиента 192.168.51.4 на предмет других и на предмет правильного размещения твоего nethasp.ini.


>> Получается, что сервер 192.168.51.5 является приоритетным.

Нет. Конкретно откуда брать ключ  задаются в nethasp.ini.
Про приоритеты можно говорить только когда у тебя НЕТ настроенных nethasp.ini или их 1С не видит. Тогда все работает по умолчанию и 1С какой первый ключ схватит, тот она и запомнит и в последующем будет его считать за приоритет. Вот тут тебе совет в (28) в тему. Чтобы убить память о ранее запомненном ключе.

(4) и еще по поводу (4) только дочитал
"даже если в файле nethasp.ini у пользователя прописать только 192.168.51.9 или только 192.168.52.5"

192.168.52.5 вообще (от слова совсем) в играх с hasp не участвует.
Не надо его никуда и никогда и нигде в никаких nethasp.ini употреблять. Там на этом сервере только программные лицензии, а железки под названием ключик HASP там НЕТу. Не торчит она (железка) в заду у этого сервера.  
А раз нету ключа haspa, то и никакие nethaspы с упоминанием этого сервера неуместны.
Ибо бестолку. Так что про этот сервер 192.168.52.5 в контексте вопроса забудь.

OFF
Все-таки какая обалденная штука - возможность редактировать свои сообщения.
Вот сейчас написал, потом увидел грамматическую ошибку и быстренько исправил.
Спасибо Станиславу за эту возможность в новом движке.
Извиняюсь за OFF в этой ветке..

(9) (11) И еще просто информация... к размышлению...
Нашел старую ветку про микропрошивку 2.17 и ОС linux
1с ключ hasp net20 не определяется в админке, но работает

(35) Сейчас попробовал с 192.168.51.4 подключиться к копии базы, где специально отключил раздачу лицензий сервером, и получил вообще интересную картину:
Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине:
Поиск лицензии на клиенте:
Файл программной лицензии не найден
nethasp.ini: отсутствует, использованы настройки по умолчанию, ORGL8 Сетевой, установлен, свободные лицензии закончились, занято через менеджер лицензий 6, занято через сервер 16
Файл программной лицензии не найден
локальный ключ недоступен: Status=0, ORGL8 Локальный, не установлен
локальный ключ недоступен: Status=0, ORG8A Локальный, не установлен
локальный ключ недоступен: Status=0, ORG8B Локальный, не установлен
nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8A Сетевой, не установлен
nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8B Сетевой, не установлен
Поиск лицензии на сервере:
Выдача клиентских лицензий сервером 1С:Предприятия запрещена

(39) nethasp.ini не видит,
лицензии на ключе 20 р.м. на 192.168.51.5 закончились,
менеджера на 192.168.51.9 с ключом на 5 р.м. не нашел,
что тут интересного?

(39) >>Сейчас попробовал с 192.168.51.4

Ну русским же языком написано - "nethasp.ini: отсутствует"
Чего тебе еще надобно, старче?
Я тебе еще вчера об этом сказал в (35)

могу повторить:
"В любом случае 1С ТВОЙ nethasp.ini НЕ ВИДИТ. А видит или другой или вообще никакой. Так что шерсти клиента 192.168.51.4 на предмет других и на предмет ПРАВИЛЬНОГО размещения твоего nethasp.ini."

Проблема решилась! Что было предпринято дополнительно:

- на 192.168.51.9 был с помощью команды sudo nano -c /etc/hasplm/nhsrv.ini добавлен файл, где указано имя менеджера HASP

- был перезапущена служба haspd.service

- позавчера также была эта служба добавлена в cron, чтобы рестартовалась раз в сутки ночью

Как результат, на компьютерах в подсети 192.168.51.0, где nethasp.ini ЦЕЛИКОМ закомментирован, при запуске базы сначала ищет свободные лицензии HASP20, потом после ввода логина-пароля предлагает отключить использование аппаратных лицензий, нажимаем Нет - по итогу запускается и берет лицензию на 5 мест сетевую.

Всем большое спасибо за советы!

бггг

(42) "Как результат, на компьютерах в подсети 192.168.51.0, где nethasp.ini ЦЕЛИКОМ закомментирован,"

и лежит непонятно где, да так что 1С при запуске пишет "nethasp.ini: отсутствует"

три раза хи.

ps: И это называется "решение проблемы". Еще раз три раза ха.

(43) Это говорит о том, что проблема вообще не со стороны пользователя и nethasp.ini больше подходит когда пользователей не так много (файловая база). В клиент-серверном варианте выше шанс найти решение именно со стороны сервера. К тому же несколько HASP-ключей вместо программных лицензий в 2023 это уже не очень здорово, но имеем что имеем

Обнаружилось следующее: после перезагрузки 192.168.51.9 ключ снова не виден, но если проверить статус с помощью sudo systemctl status haspd.service, то немного задумывается и после этого лицензии раздаются. Выглядит так, как будто ключ после перезагрузки засыпает. Пока решили проблему тем, что дополнительно прописали в cron проверку статуса службы. Но почему такое странное поведение - непонятно, мб что-то с очередностью старта службы USB и службы HASP

После очередного ребута 192.168.51.9 проблема возобновилась... Многократный рестарт службы в этот раз не помог. С 192.168.49.0 видит только если указать явно в nethasp.ini, а с 192.168.51.0 нивкакую

бгг.

Мне нравится упорство этого человека :)
программа 1С ему русским языком пишет -  "nethasp.ini: отсутствует"
А он упорно что-то там в нем (в nethasp.ini) редактирует, комментирует, прописывает.

Неважно, что 1С его (nethasp.ini) в упор не видит и не находит.
:))))

Проблему с тем, что nethasp.ini не виден, решили, поменяв в файле conf.cfg путь к конфигурации. Теперь он пишет, что nethsp.ini успешно прочитан, ошибка соединения с менеджером лицензий Status=0, System Error=0, Warning=15

Выглядит так, как будто после физического ребута лицензии перестают раздаваться автоматически и требуется юзать nethasp.ini. Может, кроме haspd.service есть еще что-то, что отвечает за раздачу лицензий в автоматическом режиме (сервера 1С на 192.168.51.9 нет)?

(49) nethasp.ini никак не влияет на раздачу лицензий, он только указывает, где клиенту нужно искать менеджер лицензий

(50) Да, я знаю, я имею ввиду nethasp со стороны клиента. Получается, что и без него норм работает, потом ребут - всё, нужно что-то писать в nethasp на клиенте

(51) ничего удивительного, первым делом 1С пытается получить ту лицензию, которая использовалась при предыдущем удачном подключении,
и только если не найдёт, начинает её искать другими способами

(0) Оно само не распределяет, та как хочется :)
Либо админу руками делить сетку, т.е. пользователи слева, в один ХАСП, пользователи справа, в ДРУГОЙ :)

(47) Даже если укажет, то счастья ему не наступит :)

+(0) Либо купить один ЮЗБ, на 500 пользователей :)
Под средством обмена ключей (а).
Но тут есть казус, 1С просекли халявы в денежном эквиваленте от цифровых лицензий, и сказали всем "ЮЗБ больше нет у нас, в продаже, для вас" :)

Вроде как после переустановки драйверов начали сами подхватываться лицензии, но что будет после очередной перезагрузки - непонятно

Через nethasp.ini теперь кстати с любого места берет, но только при условии, что 1) указан айпишник 2) broadcast disabled