как ломануть 1C 8.3 for Linux

[deniskhodus]

Добрый день.
Спасибо за ответы.
1. Про KEEPALIVE и UDP - нужно было написать "KEEPALIVE" в кавычках, т.к. я не имел в виду особенность протокола TCP (и, будучи серверным админом и сетевиком циско, как работает UDP я знаю). Под "KEEPALIVE" я имел в виду запрос-ответ от клиента к HASPLM вида "ей, я жив, ключ тоже?", который (запрос) на HASPLM, среди прочего, сбрасыват таймер таймаута "живости" клиента. Дак вот под виндой оно каждые 2,5-3 минуты проходит, а к никсовому серверу HASPLM - нет. Кроме того, обмен пакетами UDP проходит довольно весело и уверенно при запуске клиента, при этом совершенно ничего не посылается в сторону HASPLM после запуска вплоть, включая, подыхание клиента 1С (т.е. клиент 1С перед возникновением ошибки KEYWASLOST в сторону HASPLM ничего не посылает).
Для вопроизвдения:
а) Берем линуксовый HASPLM с сетевым ключем;
б) Берем чистую машинку на Windows (7,8,10, мы пробовали на 7 и на 2012) - важно виндовую, потому что линуксовый клиент 1С работает без нареканий.
в) На этой машинке, при остановленных службах вида обновлений (они жрут ресурсы), с 0,5% использования ЦП, запускаем клиент 1С и файловую базу (или серверную, но запретив пользовать лицензию с сервера предприятий)
г) Просто ждем. Делать в базе что-либо вообще не обязательно. Неважно - вы будете в базе работать или просто смотреть на стартовый экран после запуска, не нажав в клиенте ни единой кнопочки, эти 2 минуты не трогая мышку и клаву - по истечении 2х минут клиент 1С вываливается с ошибкой KEYWASLOST. Потребление ресурсов при этом на уровне плинтуса - т.е. никакого. Проверено как на живых машинах, так и на виртуалке (правда на виртуалке с 2012R2).
Если бы дело было в загрузке ЦП и невозможности время от времени клиентом отправить UDP запрос - то тогда запрос от клиента хотя бы иногда приходил бы на сервер HASPLM. Мы третий день бьемся с проблемой и в 100% случаев клиент, после запуска, не общается больше с сервером Linux HASPLM вообще, просто вываливаясь с ошибкой KEYWASLOST.

ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует. Как, например, вечная ошибка клиента 1С в том, что по IP-шнику это чудо работать не умеет (топаем в hosts и прописываем IP=hostname ибо если клиенту сказать "Сервер предприятия на 10.5.16.12", то клиент скажет "ээээ, я не могу найти сервер my1cserver12") - вот из этой же оперы - клиент втупую через жопу работает с HASP.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем. В 1С я НЕ верю.

ЗЫ. За подсказку про автономный сервер спасибо. Почитаю посмотрю. Правда это все равно пахнет нелицензионностью, если честно. А мы пытаемся не ломануть лицензии, а убрать из уравнения ненужные машины, в данном случае - на винде. И тема найдена по поиску вида "Ключ защиты более недоступен". Хотя, если честно, почитав назад - мне было довольно интересно.

Еще раз спасибо.

[daemonpnz]

Следующая проблема с серверными ключами. Раз не работает совсем ключ для x64, то пробуем ключ для x32. Для этого ставим платформу под i386, настраиваем (создаём две базы на сервере, делаем так чтобы для каждой базы запускался новый экземпляр рабочего процесса), добавляем ещё клиентский ключ на 100 пользователей, запускаем. Как результат: первая база стартует нормально, получает клиентскую лицензию от сервера, на основании чего делаем вывод, что клиентский ключ работает; вторая же база ругается на отсутствие лицензии, а конкретнее

На сервере 1С:Предприятия не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
Файл программной лцензии не найден
ENSR8 Локальный, установлен. ошибка чтения данны из ключа
EN8SA Локальный, не установлен

[leov-001]

Добрый день.
ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует. Как, например, вечная ошибка клиента 1С в том, что по IP-шнику это чудо работать не умеет (топаем в hosts и прописываем IP=hostname ибо если клиенту сказать "Сервер предприятия на 10.5.16.12", то клиент скажет "ээээ, я не могу найти сервер my1cserver12") - вот из этой же оперы - клиент втупую через жопу работает с HASP.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем. В 1С я НЕ верю.
Еще раз спасибо.

Сотанавливаем сервер 1С
Идем /home/usr1cv8/.1cv8/1C/1cv8/reg_1541 в файле 1CV8Clst.lst hostname меняем на ip-шник

[yhm57878@cndps]

Поставил на убунту PosgreSQL. Не запускается толстый клиент, а конфигуратор запускается. И все время создаютс я какие0то сеансы постоянно. Снимок экрана от 2019-06-08 14-14-40.jpg
Снимок экрана от 2019-06-08 14-14-45.jpg

[HPDX2300]

Дак вот под виндой оно каждые 2,5-3 минуты проходит, а к никсовому серверу HASPLM - нет. Кроме того, обмен пакетами UDP проходит довольно весело и уверенно при запуске клиента, при этом совершенно ничего не посылается в сторону HASPLM после запуска вплоть, включая, подыхание клиента 1С (т.е. клиент 1С перед возникновением ошибки KEYWASLOST в сторону HASPLM ничего не посылает).
Для вопроизвдения:
а) Берем линуксовый HASPLM с сетевым ключем;
б) Берем чистую машинку на Windows (7,8,10, мы пробовали на 7 и на 2012) - важно виндовую, потому что линуксовый клиент 1С работает без нареканий.
в) На этой машинке, при остановленных службах вида обновлений (они жрут ресурсы), с 0,5% использования ЦП, запускаем клиент 1С и файловую базу (или серверную, но запретив пользовать лицензию с сервера предприятий)
г) Просто ждем. Делать в базе что-либо вообще не обязательно. Неважно - вы будете в базе работать или просто смотреть на стартовый экран после запуска, не нажав в клиенте ни единой кнопочки, эти 2 минуты не трогая мышку и клаву - по истечении 2х минут клиент 1С вываливается с ошибкой KEYWASLOST. Потребление ресурсов при этом на уровне плинтуса - т.е. никакого. Проверено как на живых машинах, так и на виртуалке (правда на виртуалке с 2012R2).
Если бы дело было в загрузке ЦП и невозможности время от времени клиентом отправить UDP запрос - то тогда запрос от клиента хотя бы иногда приходил бы на сервер HASPLM. Мы третий день бьемся с проблемой и в 100% случаев клиент, после запуска, не общается больше с сервером Linux HASPLM вообще, просто вываливаясь с ошибкой KEYWASLOST.

ЗЫ. ЭТИ же клиенты, по ТОМУ же протоколу UDP, прекрасно работают с виндовым HASPLM. Эти же. И они же дохнут при наличии линуксового HASPLM. Я сильно сомневаюсь, что проблема в линуксовом хаспе. Скорее клиент 1С видит некие другие данные и неверно их интерпретирует.
Поменять что-то в клиенте мы не можем, а обойти ошибку - пробуем.

вот тут есть
Инструкция по эксплуатации программных продуктов «1C» и ключей защиты HASP
там, в частности, написано более подробно чем в доке "одинсек" про параметры таймаутов nethasp.ini:
"...Если часть маршрута между запускаемой программой и ключами HASP проходит через Интернет или на ключе более 100 лицензий, могут возникнуть проблемы с тайм-аутами при доставке
пакетов. Время ожидания ответа можно регулировать с помощью параметров NH_SESSION и NH_SEND_RCV. По умолчанию они закомментированы, и их значение составляет 30 и 5 секунд
соответственно. Таким образом, делается 6 попыток найти ключ по 5 секунд каждая. При необходимости Вы можете увеличить эти параметры...."

т.е. величина NH_SESSION кратна величине NH_SEND_RCV (NH_SESSION = NH_SEND_RCV * K, где K целое число ). Если указать величны NH_SESSION < NH_SEND_RCV , то как-бы ничего не должно перепосылаться. Этот момент совершенного не освещен в доке "одинсек".

еще вот этот момент в Working_with_HASP_and_1C.pdf :
"1C 8.x работает только по UDP. Однако ее можно заставить использовать TCP неявно. Для этого, помимо того, что описано выше, необходимо разрешить в свойствах протокола TCP/IP (Properties - Advanced - WINS) поддержку NetBios over TCP/IP на рабочих станциях, где работает защищенное приложение и на машине, где установлен ключ."



а следующий параграф ''HASP4 и "зависшие" сессии'' о многом говорит:
"Система защиты HASP4 устарела и была снята с поддержки в 2006 году, с тех пор для неё ничего не дорабатывалось. В менеджере лицензий 8.32 периодически возможно "зависание части лицензий", происходящее из-за некорректного завершения сессии с ключом."

Между исх.кодом платформы и HASP-ключом есть очевидная "прослойка" - "HASP API" (его исходники называются примерно так - "HASP SDK") + "HASP LM".
Следы "HASP API" легко находятся в либах, работающих с HASP-ключом.
Например, используя тулзу strings увидим в backbas.dll строки с названиями функций из "HASP API" (бублично доступен только .h файл с прототипами функций):
HASPAPI_VERSION
LOCALHASP_HASPSTATUS
LOCALHASP_HASPCODE
LOCALHASP_ISHASP
LOCALHASP_DECODEDATA
LOCALHASP_ENCODEDATA
NETHASP_ENCODEDATA
NETHASP_DECODEDATA
NETHASP_LASTSTATUS
NETHASP_SETIDLETIME
NETHASP_HASPCODE
NETHASP_READBLOCK
NETHASP_HASPID
NETHASP_GETPROTOCOL
NETHASP_SET_SERVER_BY_NAME
NETHASP_SET_CONFIG_FILENAME
NETHASP_HASPQUERYLICENSE
NETHASP_DEFAULTCONFIG
NETHASP_SETPROTOCOL

на сайте вендора HASP4 написано, что он похерен и не поддерживается с 2006 года - парни из "один сек" не будут париться и самостоятельно ковыряться в коде "HASP API", да ещё наверняка там не все идет в сорцах, и некоторые либы могут поставляться в скомпилированном виде - бери и используй при сборке (линковке) приложения.
Вообщем, "удаление гланд автогеном через анальное отверстие"

[deniskhodus]

Спасибо за ответ. Мы пришли к тому же выводу, найдя ровно то же сообщение от SafeNet о снятии с поддержки HASP4 с 2006 года и слегка опустили руки. Программный ключ пока использовать не шибко спешим рисковать - будем следить за форумами и ситуацией. Камень преткновения - это "слетание" программного ключа в случае использования виртуализации как самостоятельного явления (из-за, видимо, слегка люфтящих параметров машины со стороны гипервизора - например, частоты ЦП), так и технологий управления ВМ - как ручных (например, слегка поменяли объем выданного ОЗУ или количество ядер), так и автоматизированных (таких, как миграция ВМ между гипервизорами). Сообщения в форумах показывают, что, к сожалению, переактивацию приходится проходить достаточно часто (некоторые сообщения говорят о необходимости переактивации почти каждый холодный перезапуск ВМ) - в итоге, три выданных "попытки" заканчиваются.
Результат - либо мы победим параметризацией, поиграв с Вами выше описанными ключами (очень маловероятно), либо мы оставим виндовую машинку, закрыв ее отовсюду и оставив udp475 открытым, и поставим на нее ключи (вот это, вероятнее всего, и будет окончательным решением).
Еще раз спасибо.

[daemonpnz]

Кому будет интересно, благодаря пользователю Илья547 и его дампам получилось завести ключ для x64 сервера и соответстенно сам сервер. Ещё для того чтобы работали ключи в контейнерах в linux, то нужно пробросить usb и aks устройства в контейнер. Для примера часть конфиг файла для proxmox (lxc)

lxc.cgroup.devices.allow: c 189:* rwm #разрешается проброс конкретных usb устройств
lxc.mount.entry: /dev/bus/usb/005/001 dev/bus/usb/005/001 none bind,optional,create=file #проброс целой шины usb на которой висит ключ, ваши числа могут отличаться
lxc.mount.entry: /dev/bus/usb/005/002 dev/bus/usb/005/002 none bind,optional,create=file
lxc.mount.entry: /dev/aks/hasp/5-1 dev/aks/hasp/5-1 none bind,optional,create=file #проброс aks устройства через которое aksusbd (драйвер) общается с ключом, ваши числа могут отличаться

[Sprinter2000]

Инструкция для тех, кто хочет поставить эмулятор на Centos 7 x64 (Kernel 3.10.0)

Alf500[/B] и vfp7.

День добрый.
Сделал по инструкции.
Ключей не видит. lsusb выдает только USB хабы в системе. Alladin Monitor видит менеджера, но ключей не видит. После usbhasp -d /home/1.json ничего не выдает. Как сервис usbhasp не стоит, даже статус глянуть не могу.

Где я мог ошибиться?

[vfp7]

Хм ... для статуса как бы делать так, без ключа -dEMON:

usbhasp /home/1.json

[Sprinter2000]

Хм ... для статуса как бы делать так, без ключа -dEMON:

usbhasp /home/1.json

Ага, помогло.. Теперь видно, что выдает ошибку при разборе файлов json..
Понять бы в чем там ошибка, вроде по шаблону сделал.. Есть у Вас образец?