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

[yhm57878@cndps]

Тест Гилева какое значение показал?
на основном моем компе Тест Гилева показал результат 82 "попугая", и ни разу не упала "HASP has been lost!" (оно же KEYWASLOST)
Я достал старенький ноут HP-550, вот на нём прекрасно ловится крах "HASP has been lost!" (вылеченная платформа на WinXP - будем "посмотреть" на механику происходящего).
Если платформа "не вылечена" и ключик ловится по сети, то тест Гилева на HP-550 не падает, выдает 25 "попугаев" (таймауты NH_SESSION и NH_SEND_RCV в nethasp.ini не понадобились).

У меня тест выдает 44. А у меня вылеченная так не ругается. Наоборот за эти дни не было замечено вылета ниразу.

[vfp7]

Проблему так и не решил. Пjставил на 64-битный убунту 32-битный сервер с клиентом. Взломал backbas.so патчером rbc. Сначала убрал галочку в настройках "Аппаратный ключ защиты". Запустил - спрашивает лицензию. Потом вернул галочку, хасп запущенный стоит, запускаю:
Текущая:
Локальный HASP4 ORGL8 10, получило клиентское приложение
Информационная база:
Локальный HASP4 ORGL8 500
Локальный HASP4 ORGL8 100.
Уже другая лицензия стоит клиентская. Тест Гилева прошел на УРА. Пока полет нормальный.
Вообще это правильно устанавливать 32битное приложение на 64битное? Есть ли последствия? Или можно спокойно работать, пока не изобретут вакцину для 64битной?

1. Насколько помню там был момент что требовалось возвращать в систему файл который получался с расширением .bak, но может и не факт так как глубоко не копал в сторону 32-бит, - этот момент весьма интересен.
2. 32 бит использовать можно и иногда даже приходится, но так же можно нарваться на ограничения самой архитектуры, и дополнительно ощутить снижение производительности.
3. Я бы поглубже покопал почему Ваша конфигурация брыкается, подозреваю что дело как раз может быть в конфигурации которая требует 32 бит? У меня к примеру есть несколько баз в которых вызываются дополнения работающие только в 32 битном режиме, и из за этого приходится держать зоопарк версий и релизов.
ps: Про момент с тестом и отваливанием ключа - насколько помню мелькало что отваливался ключ из за высокой загрузки компьютера на котором запускали тест, и в итоге компьютер просто не успевал обновить результат перепроверки наличия ключа. Опять же насколько помню решали проблему через распределение приоритетов ресурсов.

[yhm57878@cndps]

1. Насколько помню там был момент что требовалось возвращать в систему файл который получался с расширением .bak, но может и не факт так как глубоко не копал в сторону 32-бит, - этот момент весьма интересен.
2. 32 бит использовать можно и иногда даже приходится, но так же можно нарваться на ограничения самой архитектуры, и дополнительно ощутить снижение производительности.
3. Я бы поглубже покопал почему Ваша конфигурация брыкается, подозреваю что дело как раз может быть в конфигурации которая требует 32 бит? У меня к примеру есть несколько баз в которых вызываются дополнения работающие только в 32 битном режиме, и из за этого приходится держать зоопарк версий и релизов.
ps: Про момент с тестом и отваливанием ключа - насколько помню мелькало что отваливался ключ из за высокой загрузки компьютера на котором запускали тест, и в итоге компьютер просто не успевал обновить результат перепроверки наличия ключа. Опять же насколько помню решали проблему через распределение приоритетов ресурсов.

На счет приоритетов, данным способом думаю можно просто повысить порог когда сработает ошибка, но не исправить. Вдруг сидишь такой что-то пишешь там и бац ошибка)

[vfp7]

На счет приоритетов, данным способом думаю можно просто повысить порог когда сработает ошибка, но не исправить. Вдруг сидишь такой что-то пишешь там и бац ошибка)

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

Fragster
Это проблема hasplm при недостаточности процессорных ресурсов. Лечится выделением машины с hasplm на отдельный хост с гарантированной производительностью (не очень большой), у менеджера лицензий должен быть условно реалтайм приоритет."
.. "

[HPDX2300]

Проблему так и не решил. Пjставил на 64-битный убунту 32-битный сервер с клиентом. Взломал backbas.so патчером rbc.
Сначала убрал галочку в настройках "Аппаратный ключ защиты".
Запустил - спрашивает лицензию. Потом вернул галочку, хасп запущенный стоит....

я уже писал об этом, но видать не у всех отложилось в копилку.
В окне выбора базы нажмите кн."Настройка", откроется диалог параметров платформы,
самая нижняя галка "Использовать аппаратную лицензию (ключ защиты)" - её НЕ ВЫКЛЮЧАТЬ на сломанной платформе, её выключают, видимо, тока обладатели программных лицензий.
Когда она выключена платформой игнорируется часть защитных механизмов, связанная с HASP ключами, поэтому даже вылеченная платформа остается без лицензии, созданной кодом патча unipatch в памяти процесса.

[yhm57878@cndps]

Тест Гилева какое значение показал?
на основном моем компе Тест Гилева показал результат 82 "попугая", и ни разу не упала "HASP has been lost!" (оно же KEYWASLOST)
Я достал старенький ноут HP-550, вот на нём прекрасно ловится крах "HASP has been lost!" (вылеченная платформа на WinXP - будем "посмотреть" на механику происходящего).
Если платформа "не вылечена" и ключик ловится по сети, то тест Гилева на HP-550 не падает, выдает 25 "попугаев" (таймауты NH_SESSION и NH_SEND_RCV в nethasp.ini не понадобились).

У меня тест выдает 44. А у меня вылеченная так не ругается. Наоборот за эти дни не было замечено вылета ниразу.

[deniskhodus]

Проблема "Ключ защиты более недоступен".
Описание: на Linux-машине развернут Etersoft HASP (hasplm) с подключенным сетевым USB ключем на 100 пользователей. На виндовой машине AKS Monitor видит саму Linux-машину, правда в виде "0A7B9A23" (если на винде разворачивать HASP LM - машина будет выглядеть как "0A7B9A23 hostname"). По-умолчанию ключ (HASP #1) не виден в AKS Monitor.
1. Виндовый клиент 1С, НЕ ЛОМАННЫЙ, следов лома в принципе нет на машине - все оф. Файловая база (чтобы не словить лицензию с сервера предприятия). Настроенный файл nethasp.ini. Клиент запускается, по tcpdump виден обмен между машиной с 1С-клиентом и машиной с HASPLM (udp 475). Сразу в AKS Monitor появляется ключ HASP#1. Лицензия выдается, AKS Monitor ее отображает. Виндовый клиент работает примерно 2-2,5 минуты, когда timeout сессии в AKS Monitor приближается к 400-405 с - клиент 1С пишет "Ключ защиты более недоступен" и вываливается.
2. --//-- то же самое, только иногда после 2-2,5 минут вываливается с виндовым expection вида "все плохо в backbas.dll" вместо "ключ защиты более не обнаружен".
3. Виндовый клиент общается с HASPLM только при запуске, а когда вроде должен был бы keepalive послать - тишина, просто ничего нет. Соответственно, возникает мысль, что виндовый клиент 1С недопонимаем что-то у себя внутри и не может ломануться повторно с KEEPALIVE на сервер HASPLM.
4. Линуксовые клиенты 1С с этим же линуксовым сервером HASP LM работают без нареканий - просто работает и все.
5. Все виндовые варианты с виндовым HASP LM - работают без нареканий в любых вариациях.
Еще раз - это оф. Можем, конечно, написать в ИТС 1С (проплачен), но по опыту - ждать у моря погоды.
Зачем HASP LM на никсах? Потому что мы в принципе в серверной части ушли от винды (сэкономив тонны рабочего времени на разгребание проблем с ней и столько же тонн денег на лицензировании). И очередной виндовоз лишний только из-за сетевых ключей (к сожалению, файловые базы есть и перевести все на PostgreSQL - просто нереально, как факт, и нет смысла, т.к. многие из них - архивные и нужны пару раз в год) - ну это шаг назад, шаг назад. Даже если этот виндовоз вынести в отдельную подсеть и влан и оградить ACL-ками так, что доступен будет только хасп с него - ну это винда, ребят.

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

ЗЫ. HASP LM пробовал оф (SafeNet-овский, 7.92 + 8.30) - ключ просто не видится 1С-кой, и Etersoft (7.90 + 8.30) - ключ видится, но клиент вылетает с "Ключ защиты более не обнаружен". 32 и 64 бита - одинаковое поведение.
ЗЫ. Linux: Debian 9 64bit (4.9), и Ubuntu 19.04 (5.0) - поведение одинаковое, к сожалению.

[HPDX2300]

добавьте, пжлста, номер(а) версий платформы, на которых это наблюдалось.
Если возможно, покажите для ясности (без имён компов, доменов - замените на "блабла") nethasp.ini

[HPDX2300]

Проблема "Ключ защиты более недоступен".
Описание: на Linux-машине развернут Etersoft HASP (hasplm) с подключенным сетевым USB ключем на 100 пользователей. На виндовой машине AKS Monitor видит саму Linux-машину, правда в виде "0A7B9A23" (если на винде разворачивать HASP LM - машина будет выглядеть как "0A7B9A23 hostname"). По-умолчанию ключ (HASP #1) не виден в AKS Monitor.
1. Виндовый клиент 1С, НЕ ЛОМАННЫЙ, следов лома в принципе нет на машине - все оф. Файловая база (чтобы не словить лицензию с сервера предприятия). Настроенный файл nethasp.ini. Клиент запускается, по tcpdump виден обмен между машиной с 1С-клиентом и машиной с HASPLM (udp 475). Сразу в AKS Monitor появляется ключ HASP#1. Лицензия выдается, AKS Monitor ее отображает. Виндовый клиент работает примерно 2-2,5 минуты, когда timeout сессии в AKS Monitor приближается к 400-405 с - клиент 1С пишет "Ключ защиты более недоступен" и вываливается.
2. --//-- то же самое, только иногда после 2-2,5 минут вываливается с виндовым expection вида "все плохо в backbas.dll" вместо "ключ защиты более не обнаружен".
3. Виндовый клиент общается с HASPLM только при запуске, а когда вроде должен был бы keepalive послать - тишина, просто ничего нет. Соответственно, возникает мысль, что виндовый клиент 1С недопонимаем что-то у себя внутри и не может ломануться повторно с KEEPALIVE на сервер HASPLM.
4. Линуксовые клиенты 1С с этим же линуксовым сервером HASP LM работают без нареканий - просто работает и все.
5. Все виндовые варианты с виндовым HASP LM - работают без нареканий в любых вариациях.
Еще раз - это оф. Можем, конечно, написать в ИТС 1С (проплачен), но по опыту - ждать у моря погоды.
Зачем HASP LM на никсах? Потому что мы в принципе в серверной части ушли от винды (сэкономив тонны рабочего времени на разгребание проблем с ней и столько же тонн денег на лицензировании). И очередной виндовоз лишний только из-за сетевых ключей (к сожалению, файловые базы есть и перевести все на PostgreSQL - просто нереально, как факт, и нет смысла, т.к. многие из них - архивные и нужны пару раз в год) - ну это шаг назад, шаг назад. Даже если этот виндовоз вынести в отдельную подсеть и влан и оградить ACL-ками так, что доступен будет только хасп с него - ну это винда, ребят.

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

ЗЫ. HASP LM пробовал оф (SafeNet-овский, 7.92 + 8.30) - ключ просто не видится 1С-кой, и Etersoft (7.90 + 8.30) - ключ видится, но клиент вылетает с "Ключ защиты более не обнаружен". 32 и 64 бита - одинаковое поведение.
ЗЫ. Linux: Debian 9 64bit (4.9), и Ubuntu 19.04 (5.0) - поведение одинаковое, к сожалению.

без включения записи технологического журнала такая инфа оч.скудна - просто констатация факта.
если есть желание включите "отлов" крахов KEYWASLOST в техн.журнал как это написано в посте 180

[HPDX2300]

Проблема "Ключ защиты более недоступен".

3. Виндовый клиент общается с HASPLM только при запуске, а когда вроде должен был бы keepalive послать - тишина, просто ничего нет.
Соответственно, возникает мысль, что виндовый клиент 1С недопонимаем что-то у себя внутри и не может ломануться повторно с KEEPALIVE на сервер HASPLM.

обмен по сети идет только по UDP, KEEPALIVE исп. только для TCP-соединений.
вероятно, на клиенте не хватает ресурсов CPU, померяйте тестом гилева производительность клиентских машин, ловящих крах KEYWASLOST.
как связана "нехватка ресурсов CPU" с крахом KEYWASLOST ? ответ: доставка UDP-пакетов не гарантирована, сильно нагруженый клиент (перегруз CPU, очередь ожидания большая) будет терять сетевые UDP-пакеты.

и техн.журнал лучше присоединять в zip-архиве, а то впечатление что приведенный текст обрезало - толстый клиент перед крахом пишет в журнал строку "HASP has been lost!"