как ломануть 1C 8.3 for Linux [Архив] - Страница 2 - FRB | FORUM RUBOARD

Alf500

21.04.2019, 20:13

Хм, ключ переделал, в эмулятор подгрузил, в терминале получил:

usbhasp[5155]: Loaded key 0: '1C Enterprise Server x64 Local Key', Created: 24/03/2008 23:44:14
usbhasp[5155]: USB device created usb_vhci_hcd.0 (bus# 4)
usbhasp[5155]: Port 1 is powered on -> connecting device.
usbhasp[5155]: Port 1 connected.
usbhasp[5155]: Port 1 is disabled.
usbhasp[5155]: Set device on port 1 address = 2
Процесс так и висит.. терминал закрывать, как я понимаю, не следует.

Перехожу к тестам.

Почитал, в том числе между строк... Если вкратце, нашел, собрал, запустил. Уперся в формат данных в ключе. Структура понятна... непонятно в каком виде данные должны быть? Не подскажете, в какую сторону копать?

Alf500

21.04.2019, 22:25

Структура понятна... непонятно в каком виде данные должны быть?
Пересмотрел повнимательней код... разобрался. Поднялось вроде... и сервер свою видит, и клиентам выдается.

# ./usbhasp v8-500-user.json v8-server-x64.json
usbhasp[2298]: Loaded key 0: '1C:Предприятие 8.x, 500 лицензий', Created: 21/04/2019
usbhasp[2298]: Loaded key 1: '1C Enterprise Server x64', Created: 21/04/2019
usbhasp[2298]: USB device created usb_vhci_hcd.0 (bus# 3)
usbhasp[2298]: Port 1 is powered on -> connecting device.
usbhasp[2298]: Port 1 connected.
usbhasp[2298]: Port 2 is powered on -> connecting device.
usbhasp[2298]: Port 2 connected.
usbhasp[2298]: Port 1 is disabled.
usbhasp[2298]: Set device on port 1 address = 2
usbhasp[2298]: Port 2 is disabled.
usbhasp[2298]: Set device on port 2 address = 3

Alf500

26.04.2019, 00:14

Итак... работает все в режиме "поставил и забыл"

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

Все делалось на debian-9, если у кого-то другая версия, надо будет скорректировать некоторые команды.

1. устанавливаем либы для х32 (без них работать не будет!!!)

dpkg --add-architecture i386
apt-get update
apt-get install libusb-0.1-4:i386

2. устанавливаем исходники ядра

apt-get install build-essential linux-source-4.9 linux-headers-4.9.0-8-all
cd /usr/src
tar -xf linux-source-4.9.tar.xz

3. устанавливаем "libjansson"

apt-get install libjansson-dev

4. собираем драйвер виртуального USB
Идем сюда - https://sourceforge.net/p/usb-vhci/wiki/Home/
и качаем "vhci_hcd" и "libusb_vhci"

сначала собираем драйвер 'usb_vhci'

cd vhci_hcd
mkdir -p linux/4.9.0/drivers/usb/core
cp /usr/src/linux-source-4.9/include/linux/usb/hcd.h linux/4.9.0/drivers/usb/core/

перед сборкой, в файлах "usb-vhci-hcd.c" и "usb-vhci-iocifc.c" находим "#define DEBUG" и комментируем эту строку!!!

make KVERSION=4.9.0-8-amd64 KSRC=/usr/src/linux-source-4.9
make install
загружаем полученные модули

insmod usb-vhci-hcd.ko
insmod usb-vhci-iocifc.ko
и сделаем автозагрузку модулей при старте системы

echo 'usb_vhci_hcd' >> /etc/modules
echo 'usb_vhci_iocifc' >> /etc/modules

затем собираем библиотеки 'libusb_vhci'

cd libusb_vhci
./configure
make
make install

5. собираем эмулятор UsbHasp

git clone https://github.com/sam88651/UsbHasp.git
cd UsbHasp
make
полученный эмулятор ищем в каталоге 'UsbHasp/dist/Release/GNU-Linux/'
осталось положить его куда-нибудь, туда же положить json-файлы ключей, и можно запускать

./usbhasp key1.json key2.json ... key4,json
для автозапуска делаем скрипт в /etc/init.d/ и регистрируем соужбу в systemctl

6. ключи
отличия от reg-файлов
все DWORD-параметры записаны без "0х" в начале
все HEX-параметры содержат те же массивы, но к каждому элементу надо приклеить все тот же "0х" в начало

структура ключа:

{
"HASP Key": {
"Name": "Key name",
"Created": "01/01/2001",
"Password": "00000000",
"Type": "00000000",
"Memory": "00000000",
"SN": "00000000",
"SecTable": "0x00,0x00,.........,0x00",
"NetMemory": "0x00,0x00,.........,0x00",
"Option": "0x00,0x00,.........,0x00",
"Data": "0x00,0x00,.........,0x00"
}
}

leov-001

26.04.2019, 13:37

А можно скомпилить на тестовом сервере и подсунуть модули на рабочий сервак?

Alf500

26.04.2019, 14:39

Можно. Я себе deb-пакет собрал

vfp7

26.04.2019, 19:25

Для ubuntu 18.04.2 x64 lts (4.15.0) по памяти напишу первую часть, в помощь другим даже с минимальными знаниями:

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libusb-0.1-4:i386 linux-tools-generic automake libtool linux-source-4.15.0 linux-headers-4.15.0-48 libelf-dev libjansson-dev
cd /usr/src/
sudo tar -xf linux-source-4.15.0.tar.bz2
cd ~
Качаем vhci_hcd и libusb_vhci отсюда:
http://sourceforge.net/projects/usb-vhci/files/linux%20kernel%20module/
http://sourceforge.net/projects/usb-vhci/files/native%20libraries/
Примерно так (можете вообще и с другого компьютера закачать, главное перебросьте эти файлы в папку пользователя этой машины):
wget http://excellmedia.dl.sourceforge.net/project/usb-vhci/linux%20kernel%20module/vhci-hcd-1.15.tar.bz2
wget http://excellmedia.dl.sourceforge.net/project/usb-vhci/native%20libraries/libusb_vhci-0.7.tar.bz2
Далее:
tar -xf libusb_vhci-0.7.tar.bz2
tar -xf vhci-hcd-1.15.tar.bz2
cd vhci-hcd-1.15
mkdir -p linux/4.15.0/drivers/usb/core
cp /usr/src/linux-source-4.15.0/include/linux/usb/hcd.h linux/4.15.0/drivers/usb/core/
nano usb-vhci-hcd.c
находим "#define DEBUG" и комментируем эту строку, при желании можно выделить через /* */
nano usb-vhci-iocifc.c
находим "#define DEBUG" и комментируем эту строку
добавляем строку #include <linux/uaccess.h> (просто сверху над первым #include в файле вставьте)
sudo make KVERSION=4.15.0-48-generic KSRC=/usr/src/linux-source-4.15.0
sudo make install
cd ~/libusb_vhci-0.7
./configure
make
make install
cd ~
wget http://github.com/sam88651/UsbHasp/archive/master.zip
unzip master.zip
cd cd UsbHasp-master
make

- продолжение следует ... (пока нет времени)

vfp7

29.04.2019, 13:46

Добавляю последний штрих:

sudo cp dist/Release/GNU-Linux/usbhasp /usr/local/etc
sudo /sbin/ldconfig -v
sudo nano /etc/modules
vhci-hcd
usb-vhci-hcd
usb-vhci-iocifc
..

sudo nano /usr/local/etc/initreboot.sh
#!/bin/sh
/usr/local/etc/usbhasp -d /usr/local/etc/srv.json,/usr/local/etc/ws.json
sudo systemctl start srv1cv83
exit
..

sudo chmod +x /usr/local/etc/initreboot.sh
sudo crontab -e
..
@reboot /usr/local/etc/initreboot.sh > /dev/null 2>&1
..

Переходим в папку с дистрибутивом 1с и ставим ее (если не установлена, а так же устанавливаем haspd):
( установка 1с разжевана в инете, к примеру ( i386 !, примерно аналогично делаем для x64 ) http://wiseadvice-it.ru/o-kompanii/blog/articles/prostaya-ustanovka-1s-na-linux-ubuntu/ )
sudo apt install imagemagick unixodbc libgsf-bin t1utils
sudo apt install libwebkitgtk-3.0-0
sudo apt --fix-broken install
cd ~/Folder1cDistrib (здесь должны быть минимум три файла: 1c-enterprise83-client_*_amd64.deb 1c-enterprise83-common_*_amd64.deb 1c-enterprise83-server_*_amd64.deb)
sudo dpkg -i 1c-enterprise83-*
wget http://ftp.etersoft.ru/pub/Etersoft/HASP/last/x86_64/Ubuntu/18.04/ ( качаем два haspd*.deb файла по этой ссылке или переносим их с другого компьютера )
sudo dpkg -i haspd*
sudo systemctl disable srv1cv83

sudo reboot

Про ключ (/usr/local/etc/srv.json и /usr/local/etc/ws.json) смотрим пост выше от Alf500, примечание - поле "Data" просто сделал в одну длинную строку.
На этом все.

/ подтверждаю что система работоспособна на Ubuntu 18.04.2 x64 LTS /
Если у кого есть желание и возможность может изготовить скрипт автоматической перекомпиляции этой системы при обновлении ядра, ему все явно сказали бы большое спасибо. (у меня проблемы с свободным временем)

ps: в прошлом посте в одной строке пропущен sudo - "make install", а должно быть "sudo make install" !!! (иначе система ругнется на недостаточные права)

Alf500

29.04.2019, 16:07

собрал пакет для debian (amd64) на ядре 4.9 - брать здесь (https://cloud.alfn.ru/s/jDT3Ytt2n33SSaz)

у пакета 2 зависимости: libusb-0.1-4 и libjansson4
ставим через apt (иначе зависимости не встанут)

запускаем из каталога, где лежит usbhasp.deb

apt-get update
apt-get install ./usbhasp.deb -y

после установки проверяем появление в системе виртуальных USB-устройств
можно так (нужен пакет usbutils):

lsusb
Bus 003 Device 003: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle
Bus 003 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle

либо вывод dmesg

hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
usb_vhci_iocifc: Usb bus #3
usb 3-1: new full-speed USB device number 2 using usb_vhci_hcd
usb 3-1: New USB device found, idVendor=0529, idProduct=0001
usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-1: Manufacturer: HASP HL 3.25
usb 3-2: new full-speed USB device number 3 using usb_vhci_hcd
usb 3-2: New USB device found, idVendor=0529, idProduct=0001
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 3-2: Manufacturer: HASP HL 3.25

ключи лежат в /opt/1c-key
какие ключи грузить, настраиваем в /etc/init.d/usbhasp
после изменений не забываем сделать systemctl daemon-reload

запуск: service usbhasp start
остановка: service usbhasp stop
статус: service usbhasp status

п.с.
прошу отписаться попробовавших... ибо интересно, все ли получилось как надо )))

Alf500

29.04.2019, 20:11

собрал для x32 пакет... брать там же (https://cloud.alfn.ru/s/jDT3Ytt2n33SSaz), ставить так же ;)

Djordjlee

07.05.2019, 00:06

Добрый день. Попробовал. Все хорошо, но при выполнении service usbhasp status выдает:

май 07 02:01:57 Ugolok systemd[1]: Starting LSB: USBHasp Emulator...
май 07 02:01:57 Ugolok usbhasp[5444]: Loaded key 0: '1C:Предприятие 8.x, 500 лиц
май 07 02:01:57 Ugolok usbhasp[5439]: Starting USBHasp Daemon: usbhaspd failed!
май 07 02:01:57 Ugolok systemd[1]: Started LSB: USBHasp Emulator.

То есть лицензии грузятся, а usbhaspd failed!
И соответственно 1С выдает ошибку. В чем может быть моя проблема? Да, и ядро установил 4.9.0-8-amd64. Что бы точно соответствовать

Alf500

07.05.2019, 00:14

А в syslog что при этом?

Djordjlee

07.05.2019, 00:16

Я еще новенький в Debian. Где посмотреть?

Djordjlee

07.05.2019, 00:23

Если имеете ввиду daemon.log то
May 7 02:01:54 Ugolok usbhasp[5407]: Stopping USBHasp Daemon: usbhaspd.
May 7 02:01:54 Ugolok usbhasp[5407]: /etc/init.d/usbhasp: 48: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
May 7 02:01:54 Ugolok usbhasp[5407]: kill -l [exitstatus]
May 7 02:01:54 Ugolok systemd[1]: Stopped LSB: USBHasp Emulator.
May 7 02:01:57 Ugolok systemd[1]: Starting LSB: USBHasp Emulator...
May 7 02:01:57 Ugolok usbhasp[5439]: Starting USBHasp Daemon: usbhaspd failed!
May 7 02:01:57 Ugolok systemd[1]: Started LSB: USBHasp Emulator.

Djordjlee

07.05.2019, 00:52

vfp7

07.05.2019, 11:17

май 07 02:49:41 Ugolok usbhasp[715]: Unable to create USB device. Is vhci_hcd driver loaded?

Обычно такое выдается когда нет прав, то есть запуск происходит не от root

ps: Когда разворачивал систему на боевом сервере (Ubuntu 18.04.2 LTS x64) то столкнулся с проблемой работоспособности этой системы.
Благодаря помощи Alf500 удалось найти в чем был подвох - на боевом сервере очередность старта служб отличалась от чистого тестового, и в итоге служба hasp (aksusbd) не видела ключи.
То есть запуск usbhasp должен быть после запуска aksusbd !!!
Для проверки полной работоспособности в логах должна появиться строка аналогичная: aksusbd_x86_64: aksusbd_usb_dev_connect: device '/dev/aks/hasp/3-2'
( для hasp от http://sentinelcustomer.gemalto.com/sentineldownloads/?s=&c=End+User&p=Sentinel+LDK&o=Linux&t=all&l=all# )

HPDX2300

07.05.2019, 17:06

Обычно такое выдается когда нет прав, то есть запуск происходит не от root

ps: Когда разворачивал систему на боевом сервере (Ubuntu 18.04.2 LTS x64) то столкнулся с проблемой работоспособности этой системы.
Благодаря помощи Alf500 удалось найти в чем был подвох - на боевом сервере очередность старта служб отличалась от чистого тестового, и в итоге служба hasp (aksusbd) не видела ключи.
То есть запуск usbhasp должен быть после запуска aksusbd !!!
Для проверки полной работоспособности в логах должна появиться строка аналогичная: aksusbd_x86_64: aksusbd_usb_dev_connect: device '/dev/aks/hasp/3-2'
( для hasp от http://sentinelcustomer.gemalto.com/sentineldownloads/?s=&c=End+User&p=Sentinel+LDK&o=Linux&t=all&l=all# )

"запуск usbhasp должен быть после запуска aksusbd" - systemd легко с этим справляется, ему надо правильно описать сервис (от каких он зависит)

Alf500

07.05.2019, 23:00

После перезагрузки новенькое вышло:
май 07 02:49:41 Ugolok systemd[1]: Starting LSB: USBHasp Emulator...
май 07 02:49:41 Ugolok usbhasp[715]: Loaded key 0: '1C:Предприятие 8.x, 500 лицензий', Created: 21/04/2019
май 07 02:49:41 Ugolok usbhasp[715]: Loaded key 1: '1C Enterprise Server x64', Created: 21/04/2019
май 07 02:49:41 Ugolok usbhasp[715]: Unable to create USB device. Is vhci_hcd driver loaded?
май 07 02:49:41 Ugolok usbhasp[699]: Starting USBHasp Daemon: usbhaspd failed!
май 07 02:49:41 Ugolok systemd[1]: Started LSB: USBHasp Emulator.

Как всегда ответ кроется в вопросе.
Проверьте наличие загруженного модуля, обозначенного в логе. Если модуль не грузится, Надо искать причину отказа

Alf500

07.05.2019, 23:05

"запуск usbhasp должен быть после запуска aksusbd" - systemd легко с этим справляется, ему надо правильно описать сервис (от каких он зависит)
Честно говоря, даже не предполагал, что последовательность важна. У меня в дебиан никакой разницы не замечал. Рестартовал aksusbd при работающем usbhasp... не заметил никакой зависимости. Это ж usb... все хватает на лету. Странно... на всякий случай пропишу зависимость в сервисе.
За помощь спасибо

vfp7

08.05.2019, 11:30

Подтвердилось что последовательность важна (Ubuntu 18.04.2 x64)
Если она не соблюдается то вываливается такое сообщение:
aksusbd_x86_64: open_sock: connect() failed: No such file or directory
Хотя при этом usb-key устройство создано.
Копать в чем суть этой проблемы не буду, лучше разберусь с точной очередностью старта всех служб в цепочке, так как судя по всему она может измениться в зависимости от роли сервера.
Еще момент - эта система капризная по предсказуемости работоспособности, подозреваю что эта проблема опять упирается в последовательность старта служб, и оставления "хвостов" от какой либо из служб.
Сейчас переключу внимание на эти моменты, так как на текущий момент времени у меня нет уверенности в надежности этой системы (поэтому и не ставлю ее как сервис, - пускай поработает на скриптах)

Djordjlee

08.05.2019, 11:46

Тогда вопрос. А Вы на убунту или по дебиан делаете? Или все равно? Просто интересно какую систему ставить для проверки

vfp7

08.05.2019, 12:14

Ubuntu начиная с 17.10 интенсивно изменяется, в 18.04 уже приходится обращать внимание на многие изменившиеся моменты, и то что в ранних релизах делалось на раз-два, теперь иногда вызывает дополнительные затруднения.
По стабильности и быстродействию ощущаются очень положительные изменения, но за это платишь более глубоким изучением новшеств в этой ОСи.
Так что выбор только за Вами и тем железом на котором будет работать все это (к примеру некоторые ОСи или их версии не поддерживают "из коробки" какие либо аппаратные Raid контроллеры, что для корпоративного использования будет весьма ощутимым минусом)
Опять же на чистой свежезалитой тестовой системе поднялось все это без проблем а при разворачивании на боевом сервере возникли проблемы ...
ps: кидайте монетку - орел или решка :good:

Djordjlee

08.05.2019, 18:09

НЕ. Я имел ввиду для Вашей сборки . Вы ж под Debian делали. Потом говорите про Убунту

tranger

09.05.2019, 03:38

У меня при установке вылетело

cp: target '/lib/modules/4.9.0/kernel/drivers/usb/host/' is not a directory
depmod: WARNING: could not open /lib/modules/4.9.0/modules.order: No such file or directory
depmod: WARNING: could not open /lib/modules/4.9.0/modules.builtin: No such file or directory
modprobe: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open builtin file '/lib/modules/4.9.0/modules.builtin.bin'
modprobe: FATAL: Module usb-vhci-hcd not found in directory /lib/modules/4.9.0
modprobe: ERROR: ../libkmod/libkmod.c:514 lookup_builtin_file() could not open builtin file '/lib/modules/4.9.0/modules.builtin.bin'
modprobe: FATAL: Module usb-vhci-iocifc not found in directory /lib/modules/4.9.0
chmod: cannot access '/dev/usb-vhci': No such file or directory

Djordjlee

09.05.2019, 16:43

Одним словом, спасибо ув. Alf500. Установил. Но, учитываю моя мало грамотность в Linux , получилось чисто методом научного тыка. Сперва установил ядро 4-9-0-8. Потом deb пакет. Затем по вышеуказанной инструкции по установке на debian, выполнил все шаги, с учетом новых названий папок. И у меня все заработало. Низкий поклон ув.alf500

vfp7

10.05.2019, 15:00

Отпишу про подводные камни в ubuntu 18.04.2 x64
Есть вероятность что может потребоваться дополнительно - chmod 0666 /dev/usb-vhci
Далее подводные камни касаются всех версий linux:
1. Сервис работы с внешними источниками данных через ODBC - для всех не назначать, если же используете COM то или разворачивать кластер с виндовой машиной (win10 хватит за глаза) или в помощь: http://alah-my.blogspot.com/2013/02/microsoft-sql-server-odbc-ubuntu-1204.html
2. Формат журнала регистрации - при проблемах использовать старого образца
http://www.gilev.ru/tag/%D0%B6%D1%83%D1%80%D0%BD%D0%B0%D0%BB-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D 1%86%D0%B8%D0%B8/

Сейчас у меня на боевом сервере брыкается "Сервис сеансовых данных", понять это можно по окну ошибки "Не найдено ни одного сервера с размещенным сервисом ..."
- заблокировал его до выяснения источника проблемы (блокировки сервисов 1с через "Требования назначения функциональности")

tranger

11.05.2019, 05:48

Пытаюсь поставить на Centos 7 (3.10).
vhci_hcd поставился.
А вот libusb_vhci не компилируется:

[root@localhost libusb_vhci-0.7]# make
make all-recursive
make[1]: Entering directory `/usr/src/libusb_vhci-0.7'
Making all in src
make[2]: Entering directory `/usr/src/libusb_vhci-0.7/src'
/bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -O2 -g -O2 -MT libusb_vhci_la-libusb_vhci.lo -MD -MP -MF .deps/libusb_vhci_la-libusb_vhci.Tpo -c -o libusb_vhci_la-libusb_vhci.lo `test -f 'libusb_vhci.c' || echo './'`libusb_vhci.c
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -O2 -g -O2 -MT libusb_vhci_la-libusb_vhci.lo -MD -MP -MF .deps/libusb_vhci_la-libusb_vhci.Tpo -c libusb_vhci.c -fPIC -DPIC -o .libs/libusb_vhci_la-libusb_vhci.o
libusb_vhci.c: In function 'usb_vhci_from_iso_packets_errno':
libusb_vhci.c:394:2: warning: passing argument 1 of 'usb_vhci_from_errno' makes pointer from integer without a cast [enabled by default]
return usb_vhci_from_errno(errno, 0);
^
libusb_vhci.c:362:9: note: expected 'int * (*)()' but argument is of type 'int'
int32_t usb_vhci_from_errno(int errno, uint8_t iso_urb)
^
libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -O2 -g -O2 -MT libusb_vhci_la-libusb_vhci.lo -MD -MP -MF .deps/libusb_vhci_la-libusb_vhci.Tpo -c libusb_vhci.c -o libusb_vhci_la-libusb_vhci.o >/dev/null 2>&1
mv -f .deps/libusb_vhci_la-libusb_vhci.Tpo .deps/libusb_vhci_la-libusb_vhci.Plo
source='urb.cpp' object='libusb_vhci_la-urb.lo' libtool=yes \
DEPDIR=.deps depmode=none /bin/sh ../depcomp \
/bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Weffc++ -Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wstrict-null-sentinel -fno-enforce-eh-specs -O2 -c -o libusb_vhci_la-urb.lo `test -f 'urb.cpp' || echo './'`urb.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -pthread -Wall -Weffc++ -Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wstrict-null-sentinel -fno-enforce-eh-specs -O2 -c urb.cpp -o .libs/libusb_vhci_la-urb.o
../libtool: line 1125: g++: command not found
make[2]: *** [libusb_vhci_la-urb.lo] Error 1
make[2]: Leaving directory `/usr/src/libusb_vhci-0.7/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/libusb_vhci-0.7'
make: *** [all] Error 2

tranger

11.05.2019, 06:04

Поставил 'Development Tools' и всё скомпилировалось и установилось

tranger

11.05.2019, 07:00

Всё скомпилировалось, уже обрадовался, стал usbhasp скармливать ключ и получил - Segmentation fault (core dumped)

tranger

11.05.2019, 07:15

Извиняюсь за флуд. Исправил несколько ошибок в исходниках. Всё работает. Позже выложу инструкцию по компиляции на Centos 7.

Freddy_Freeman

11.05.2019, 15:05

собрал пакет для debian (amd64) на ядре 4.9 - брать здесь (https://cloud.alfn.ru/s/jDT3Ytt2n33SSaz)

прошу отписаться попробовавших... ибо интересно, все ли получилось как надо )))

Попробовал на удачу в убунте - не встало ), однако ключи пригодились))

Freddy_Freeman

11.05.2019, 15:12

Для ubuntu 18.04.2 x64 lts (4.15.0)

Респект, alf500 и vfp7! По их инструкциям сделал за один вечер! Работает!

Freddy_Freeman

11.05.2019, 15:30

Почему то файловые базы не хотят работать с эмулятором хаспа (
Не критично, ведь серверный вариант рабочий, но всё же печаль.

HPDX2300

11.05.2019, 16:54

Опять я про программные лицухи - "чую запах крови"

читаю http://buh.ruboard.ru/public/518571/

"...
Установка библиотеки криптографии

Для работы утилиты ring необходимо установить библиотеку криптографии "Unlimited Strength Java(TM) Cryptography Extension (JCE) Policy Files" - два файла local_policy.jar и US_export_policy.jar, заменив существующие файлы с более ограниченной криптографией.

Если не установить библиотеку, то утилита выдает ошибку вида:

Ошибка получения списка лицензий.
По причине: Ошибка при работе с хранилищем лицензий.
По причине: Данный ключ не поддерживается данным крипто-провайдером.
Необходимо установить крипто-провайдер, поддерживающий алгоритм AES 256 CBC с режимом шифрования PKCS5Padding
(Например, Unlimited Strength Java(TM) Cryptography Extension (JCE) Policy Files for the Java(TM) Platform,
Standard Edition (Java SE) Runtime Environment 7).
На данный момент используется крипто-провайдер: SunJCE 1.8
..."

Итак. Если лицензия "подписана/зашифрована" (подробностей не знаю) с использованием симметричного алгоритма шифрования AES 256 CBC, то ключ шифрования должен быть внутри инструмента (license-tools + ring). Когда я его заполучу - изготовление файлов .lic будет тривиальной задачей. кто-нибудь покажет мне первые 2-3 строки проф-лицухи? Как выглядит файл запроса лицухи я видел на форуме, и его мона сформировать самому.

tranger

12.05.2019, 04:23

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

Обновляем пакеты и делаем ребут:

yum update
reboot -f

Устанавливаем исходники ядра:

yum install "kernel-devel-uname-r == $(uname -r)"

Устанавливаем пакеты:

yum install wget nano usbutils git jansson-devel
yum groupinstall "Development Tools"

Собираем драйвер виртуального USB:
Переходим на http://sourceforge.net/projects/usb-vhci/files/linux%20kernel%20module и качаем vhci-hcd-1.15.tar.gz
Переходим на https://sourceforge.net/projects/usb-vhci/files/native%20libraries/ и качаем libusb_vhci-0.7.tar.gz
Кидаем всё в /usr/src

cd /usr/src
tar xzvf vhci-hcd-1.15.tar.gz
tar xzvf libusb_vhci-0.7.tar.gz

Собираем usb_vhci:

cd vhci-hcd-1.15
mkdir -p "/usr/src/vhci-hcd-1.15/linux/$(uname -r)/drivers/usb/core"
cp "/usr/src/kernels/$(uname -r)/include/linux/usb/hcd.h" "/usr/src/vhci-hcd-1.15/linux/$(uname -r)/drivers/usb/core/"
#В файлах "usb-vhci-hcd.c" и "usb-vhci-iocifc.c" находим "#define DEBUG" и комментируем
make KVERSION="$(uname -r)" KSRC="/usr/src/kernels/$(uname -r)"
make install

Загружаем модули в ядро:

insmod "/usr/lib/modules/"$(uname -r)"/kernel/drivers/usb/host/usb-vhci-hcd.ko"
insmod "/usr/lib/modules/"$(uname -r)"/kernel/drivers/usb/host/usb-vhci-iocifc.ko"

Собираем библиотеки libusb_vhci:

cd /usr/src/libusb_vhci-0.7
./configure
make
make install
cp /usr/local/lib/*.so* /usr/lib64
ldconfig -v

Собираем эмулятор UsbHasp:

cd /usr/src
git clone https://github.com/sam88651/UsbHasp.git
cd /usr/src/UsbHasp
#В /usr/src/UsbHasp/nbproject/Makefile-Release.mk заменить "CFLAGS=" на "CFLAGS=-std=gnu99"
make
cp /usr/src/UsbHasp/dist/Release/GNU-Linux/usbhasp /usr/bin

Эмулятор готов, запускается следующим образом:

usbhasp -d key1.json key2.json ... keyN.json

Структура ключа:

{
"HASP Key": {
"Name": "Key name",
"Created": "01/01/2001",
"Password": "00000000",
"Type": "00000000",
"Memory": "00000000",
"SN": "00000000",
"SecTable": "0x00,0x00,.........,0x00",
"NetMemory": "0x00,0x00,.........,0x00",
"Option": "0x00,0x00,.........,0x00",
"Data": "0x00,0x00,.........,0x00"
}
}

Установка драйвера HASP:

cd /usr/src
wget http://ftp.etersoft.ru/pub/Etersoft/HASP/last/x86_64/CentOS/7/haspd-7.90-eter1centos.x86_64.rpm
wget http://ftp.etersoft.ru/pub/Etersoft/HASP/last/x86_64/CentOS/7/haspd-modules-7.90-eter1centos.x86_64.rpm
yum install haspd-7.90-eter1centos.x86_64.rpm
yum install haspd-modules-7.90-eter1centos.x86_64.rpm
Если ставить с помощью rpm -ihv - установка не произойдет.

Часть инструкций взята у Alf500 (https://forum.ruboard.ru/member.php/481500-Alf500) и vfp7 (https://forum.ruboard.ru/member.php/443931-vfp7).

HPDX2300

12.05.2019, 13:03

Благодарю!
Осталось ещё чуть-чуть - создать механизм автоматической пересборки модулей ядра сразу после установки нового ядра. За образец можно взять оракловый VirtualBox (кстати, говорят, что его делают наши парни в Питере, по-найму там работающие на буржуев)

tranger

12.05.2019, 17:51

Djordjlee

12.05.2019, 19:21

Ребят, может кто подскажет, что бы не проверялась конфигурация на лицензию? Под Linux. Можно под винду

sergnn52

13.05.2019, 00:57

vfp7

13.05.2019, 14:16

Читал выше, что "запуск usbhasp должен быть после запуска aksusbd". Проверил, на Centos7 x64 такой проблемы нет.
Но возникла другая проблема. У меня эмулятор ключа и haspd стоят на одном сервере, а 1С стоит на другом сервере. Если отваливается процесс с эмулятором или процесс haspd (на самом деле процессы не отваливались, я вручную убил их, так как в процессе эксплуатации всякое может быть), и в этот момент кто-то пытается подключиться - соответственно он получает ошибку, что ключ не обнаружен. Дальше заново поднимаем процесс с эмулятором. Пытаемся подключиться - ошибка не уходит. Пробовал и haspd перезапускать, и порядок запуска эмулятора и haspd менял. Только перезапуск srv1cv83 помогает.
Может кто-то знает как исправить эту проблему?

Очередность старта сервисов в Ubuntu 18.04.2 x64:
1. HaspLM, aksusbd
2. UsbHasp
3. с задержкой srv1cv83
Иначе получаются ошибки вида hasp не видит ключ, или 1С не видит ключ в hasp

По Вашей проблеме - речь идет про кластер? Вы указали не полные данные что бы понять про что идет речь. Если про кластер или его гибрид, то только перезапуск srv1cv83, так как раздача ключей клиентам проходит ее средствами.

ps: разобрался с брыкающимся "Сервис сеансовых данных" в кластере (из моего прошлого поста) - можно сказать что так в 1С и должно быть. "Требования назначения функциональности" весьма специфично работает в кластере 1С, и что бы избежать недоразумений рекомендую использовать параметр "Авто", и через приоритеты выставлять желаемую очередность. Дополнительно можно ограничить потребление памяти сервису 1С в тех же настройках серверов кластера.
Так что теперь могу сказать что и на боевом сервере получил рабочую и предсказуемую 1С на ubuntu 18.04.2 x64, причем работоспособную даже в кластере.

Alf500

14.05.2019, 22:58

Эмулятор готов, запускается следующим образом:

Этот этап можно чуть подробнее разжевать, что куда и как
0x везде рисовать ? (чуть раньше это описывалось)

Структура ключа разбита
"Data"
"EDStruct"

Верно ?

отличия от reg-файлов
все DWORD-параметры записаны без "0х" в начале
все HEX-параметры содержат те же массивы, но к каждому элементу надо приклеить все тот же "0х" в начало

{
"HASP Key": {
"Name": "Key name",
"Created": "01/01/2001",
"Password": "00000000",
"Type": "00000000",
"Memory": "00000000",
"SN": "00000000",
"Option": "0x00,0x00,.........,0x00",
"SecTable": "0x00,0x00,.........,0x00",
"NetMemory": "0x00,0x00,.........,0x00",
"EDStruct": "0x00,0x00,.........,0x00",
"Data": "0x00,0x00,.........,0x00"
}
}

threeom

15.05.2019, 11:26

поставил эмуль на centos 7, вроде заработал, но 1ска вылетает с сообщением "Ключ защиты программы больше не доступен! Работа программы завершена."

Kolhoznic

15.05.2019, 21:55

Сколько бы не пытался установить и руками и из пакета который собрал Alf500 (за что ему огромнейшее спасибо). вылетает постоянно ошибка:
systemctl status haspd
aksusbd[1075]: loaded, daemon version: 7.90.1.81737, key API (USB) version: 3.88 (parallel driver not available)
haspd[1039]: Running aksusbd... [ DONE ]
winehasp[1088]: winehasp 2.00 loaded
haspd[1039]: Running winehasp... [ DONE ]
hasplm[1097]: HASP LM v8.30 loaded
haspd[1039]: Running hasplm... [ DONE ]
hasplmd[1106]: HASP LM v22.0.1.84151 loaded
haspd[1039]: Running hasplmd... [ DONE ]
systemd[1]: Started LSB: Hasp keys support.
aksusbd[1075]:aksusbd_req_dev_connect: write() failed: -1, Bad file descriptor

aksusbd и license manager следующие:
haspd_7.90-eter1debian_amd64.deb
haspd-modules_7.90-eter1debian_amd64.deb

хотя lsusb выдает:
Bus 003 Device 002: ID 0529:0001 Aladdin Knowledge Systems HASP copy protection dongle

сначала запускаю:
systemctl start haspd
только после добавляю ключ как было сказано выше.

syslog
aksusbd[1075]: loaded, daemon version: 7.90.1.81737, key API (USB) version: 3.88 (parallel driver not available)
haspd[1039]: Running aksusbd... [ DONE ]
winehasp[1088]: winehasp 2.00 loaded
haspd[1039]: Running winehasp... [ DONE ]
hasplm[1097]: HASP LM v8.30 loaded
haspd[1039]: Running hasplm... [ DONE ]
hasplmd[1106]: HASP LM v22.0.1.84151 loaded
haspd[1039]: Running hasplmd... [ DONE ]
systemd[1]: Started LSB: Hasp keys support.
usbhasp[1125]: Loaded key 0: '1C:Предприятие 8.x, 500 лицензий', Created: 21/04/2019
kernel: [ 371.456520] usb_vhci_hcd usb_vhci_hcd.3: USB Virtual Host Controller Interface -- Version 1.15 (2019-05-14)
kernel: [ 371.456525] usb_vhci_hcd usb_vhci_hcd.3: --> Backend: USB VHCI user-mode IOCTL-interface
kernel: [ 371.456531] usb_vhci_hcd usb_vhci_hcd.3: VHCI Host Controller
kernel: [ 371.456537] usb_vhci_hcd usb_vhci_hcd.3: new USB bus registered, assigned bus number 6
kernel: [ 371.456610] usb usb6: New USB device found, idVendor=1d6b, idProduct=0002
kernel: [ 371.456613] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: [ 371.456615] usb usb6: Product: VHCI Host Controller
kernel: [ 371.456617] usb usb6: Manufacturer: Linux 4.9.0-9-amd64 usb_vhci_hcd
kernel: [ 371.456618] usb usb6: SerialNumber: usb_vhci_hcd.3
usbhasp[1125]: USB device created usb_vhci_hcd.3 (bus# 6)
kernel: [ 371.461747] hub 6-0:1.0: USB hub found
kernel: [ 371.461819] hub 6-0:1.0: 1 port detected
kernel: [ 371.462020] usb_vhci_iocifc: Usb bus #6
usbhasp[1128]: Port 1 is powered on -> connecting device.
usbhasp[1128]: Port 1 connected.
usbhasp[1128]: Port 1 is disabled.
kernel: [ 371.788771] usb 6-1: new full-speed USB device number 2 using usb_vhci_hcd
usbhasp[1128]: Set device on port 1 address = 2
kernel: [ 371.929811] usb 6-1: New USB device found, idVendor=0529, idProduct=0001
kernel: [ 371.929815] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: [ 371.929817] usb 6-1: Manufacturer: HASP HL 3.25
aksusbd: aksusbd_usb_dev_connect: device '/dev/aks/hasp/6-1'
aksusbd[1075]: aksusbd_req_dev_connect: write() failed: -1, Bad file descriptor
systemd[1]: Starting Cleanup of Temporary Directories...
systemd[1]: Started Cleanup of Temporary Directories.

Может это из-за версий 86 и 64?

Alf500

15.05.2019, 22:48

Посмотрите права на /dev/usb-vhci
Должно быть 0666

Kolhoznic

15.05.2019, 23:15

Посмотрите права на /dev/usb-vhci
Должно быть 0666

crw-rw-rw- 1 root root 248, 0 май 15 21:13 usb-vhci

Kolhoznic

15.05.2019, 23:18

Посмотрите права на /dev/usb-vhci
Должно быть 0666

Не могу понять что не так. Может установить ubuntu или centos?

Alf500

15.05.2019, 23:48

Насколько я вижу, ядро видит устройство на шине 6. Дальше демон aksusb должен его подхватить.
А в /dev/aks/hasp есть что-то вроде 6-1?
Под каким пользователем запускается aksusb? может банально прав не хватает?

Kolhoznic

16.05.2019, 10:45

vfp7

16.05.2019, 11:22

winehasp - я бы сменил на Sentinel_LDK_Ubuntu_DEB_Run-time_Installer.tar.gz

Alf500

16.05.2019, 12:46

в /etc/udev/rules.d есть правила для HASP?
что там?

HPDX2300

16.05.2019, 13:03

Не могу понять что не так. Может установить ubuntu или centos?

вот именно. с этого надо было начинать - указать на какой линух громоздишь эмулятор.
проще всего делать "как доктор прописал" - работать на "Ubuntu 18.04.2 x86-64" или "CentOS-7 x86-64"

Kolhoznic

17.05.2019, 10:43

winehasp - я бы сменил на Sentinel_LDK_Ubuntu_DEB_Run-time_Installer.tar.gz

Заменил, но LM теперь не виден в сети.

Kolhoznic

17.05.2019, 10:56

в /etc/udev/rules.d есть правила для HASP?
что там?

после замены на Sentinel_LDK_Ubuntu_DEB_Run-time_Installer.tar.gz

# HASP rules
ACTION=="add|change|bind", SUBSYSTEM=="usb", ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0001", MODE="664", ENV{HASP}="1", SYMLINK+="aks/hasp/%k", RUN+="/usr/sbin/aksusbd_x86_64 -c $root/aks/hasp/$kernel"
ACTION=="remove", ENV{HASP}=="1", RUN+="/usr/sbin/aksusbd_x86_64 -r $root/aks/hasp/$kernel"

# SENTINEL rules
ACTION=="add|change|bind", SUBSYSTEM=="usb", ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0003", KERNEL!="hiddev*", MODE="666", GROUP="plugdev", ENV{SENTINELHID}="1", SYMLINK+="aks/sentinelhid/%k"

Ошибки в syslog пропали

May 17 08:38:02 srv-keys kernel: [ 507.678282] usb_vhci_hcd usb_vhci_hcd.2: USB Virtual Host Controller Interface -- Version 1.15 (2019-05-14)
May 17 08:38:02 srv-keys kernel: [ 507.678286] usb_vhci_hcd usb_vhci_hcd.2: --> Backend: USB VHCI user-mode IOCTL-interface
May 17 08:38:02 srv-keys kernel: [ 507.678291] usb_vhci_hcd usb_vhci_hcd.2: VHCI Host Controller
May 17 08:38:02 srv-keys kernel: [ 507.678300] usb_vhci_hcd usb_vhci_hcd.2: new USB bus registered, assigned bus number 5
May 17 08:38:02 srv-keys kernel: [ 507.678416] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
May 17 08:38:02 srv-keys kernel: [ 507.678419] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
May 17 08:38:02 srv-keys kernel: [ 507.678421] usb usb5: Product: VHCI Host Controller
May 17 08:38:02 srv-keys kernel: [ 507.678423] usb usb5: Manufacturer: Linux 4.9.0-9-amd64 usb_vhci_hcd
May 17 08:38:02 srv-keys kernel: [ 507.678424] usb usb5: SerialNumber: usb_vhci_hcd.2
May 17 08:38:02 srv-keys kernel: [ 507.678841] hub 5-0:1.0: USB hub found
May 17 08:38:02 srv-keys kernel: [ 507.678853] hub 5-0:1.0: 1 port detected
May 17 08:38:02 srv-keys kernel: [ 507.679033] usb_vhci_iocifc: Usb bus #5
May 17 08:38:03 srv-keys usbhasp[658]: Port 1 is powered on -> connecting device.
May 17 08:38:03 srv-keys usbhasp[658]: Port 1 connected.
May 17 08:38:03 srv-keys usbhasp[658]: Port 1 is disabled.
May 17 08:38:03 srv-keys kernel: [ 508.004731] usb 5-1: new full-speed USB device number 2 using usb_vhci_hcd
May 17 08:38:03 srv-keys usbhasp[658]: Set device on port 1 address = 2
May 17 08:38:03 srv-keys kernel: [ 508.145772] usb 5-1: New USB device found, idVendor=0529, idProduct=0001
May 17 08:38:03 srv-keys kernel: [ 508.145777] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 17 08:38:03 srv-keys kernel: [ 508.145779] usb 5-1: Manufacturer: HASP HL 3.25
May 17 08:38:03 srv-keys aksusbd_x86_64: aksusbd_usb_dev_connect: device '/dev/aks/hasp/5-1'
May 17 08:38:03 srv-keys kernel: [ 508.145772] usb 5-1: New USB device found, idVendor=0529, idProduct=0001
May 17 08:38:03 srv-keys kernel: [ 508.145777] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
May 17 08:38:03 srv-keys kernel: [ 508.145779] usb 5-1: Manufacturer: HASP HL 3.25
May 17 08:38:03 srv-keys aksusbd_x86_64: aksusbd_usb_dev_connect: device '/dev/aks/hasp/5-1'

Но теперь LM не виден в сети. Подскажите где настройки файл настройки LMа?
И где посмотреть подключился ли ключ к демону. systemctl status выдает

systemctl status aksusbd

● aksusbd.service - Sentinel LDK Runtime Environment (aksusbd daemon)
Loaded: loaded (/etc/systemd/system/aksusbd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-05-17 08:36:26 MSK; 17min ago
Process: 623 ExecStart=/usr/sbin/aksusbd (code=exited, status=0/SUCCESS)
Main PID: 624 (aksusbd)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/aksusbd.service
└─624 /usr/sbin/aksusbd

systemd[1]: Starting Sentinel LDK Runtime Environment (aksusbd daemon)...
aksusbd[624]: loaded, daemon version: 7.90.1.81737, key API (USB) version: 3.88 (parallel driver not available)
systemd[1]: Started Sentinel LDK Runtime Environment (aksusbd daemon).

systemctl status hasplmd
● hasplmd.service - Sentinel LDK Runtime Environment (hasplmd daemon)
Loaded: loaded (/etc/systemd/system/hasplmd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2019-05-17 08:36:26 MSK; 19min ago
Process: 627 ExecStart=/usr/sbin/hasplmd -s (code=exited, status=0/SUCCESS)
Main PID: 628 (hasplmd)
Tasks: 6 (limit: 4915)
CGroup: /system.slice/hasplmd.service
└─628 /usr/sbin/hasplmd -s

systemd[1]: Starting Sentinel LDK Runtime Environment (hasplmd daemon)...
srv-keys hasplmd[628]: HASP LM v22.0.1.84151 loaded
srv-keys systemd[1]: Started Sentinel LDK Runtime Environment (hasplmd daemon).

vfp7

17.05.2019, 11:02

sudo nano /etc/hasplm/hasplm.ini
[SERVER]
ACCremote = 1
..

sudo nano /etc/haspd/hasplm.conf
..
NHS_IP_LIMIT = 127.0.0.0/8, 192.168.0.0/24
..

http://server:1947/

http://safenet-sentinel.ru/faq/dev/sentinel/acc/

Kolhoznic

17.05.2019, 13:55

leov-001

17.05.2019, 16:55

https://safenet-sentinel.ru/faq/dev/hl#6422

Почему в Sentinel Admin Сontrol Center не видно лицензий и сессий HASP HL? Подходит ли драйвер от Sentinel LDK (SRM) для HASP HL?

Sentinel Admin Сontrol Center – это web-интерфейс менеджера лицензий, встроенного в драйвер от системы защиты Sentinel LDK (SRM), ключи Sentinel (HASP) не работают с ним в рамках системы защиты HASP HL.

Для работы USB ключей защиты по сети в рамках системы защиты HASP HL существует другой менеджер лицензий - HASP License Manager 8.32, который устанавливается отдельно.

Драйвер от системы защиты Sentinel LDK (SRM) обеспечивает работу ключа Sentinel (HASP) как устройства на ПК, а для работы ключа с защищённым ПО по сети (в рамках системы защиты HASP HL) нужен ещё и менеджер лицензий 8.32, Sentinel Admin Сontrol Center при этом никак не задействуется и на отображение/не отображение в нём ключей внимание обращать не стоит.

vfp7

17.05.2019, 17:39

не .. Не получается .. ставлю убунту (был дебиан)

Не торопитесь - у Вас уже все получилось.
Теперь сделайте так:
sudo netstat -lunp | grep 475

У Вас наверняка там будет пустота ... так как Вы упустили последний штрих:

http://www.safenet-sentinel.ru/helpdesk/download-space/#tabs-1
Менеджер лицензий для Linux. Версия 8.3: hasplm_linux_8.30.tgz

Этот запускаемый файлик "hasplm" запустите сначала вручную от рута и убедитесь что открылся порт 475 что бы успокоиться :vseok: :
sudo netstat -lunp | grep 475
, а далее пропишите старт hasplm перед стартом 1С (то есть после запуска UsbHasp)
У меня к примеру вся очередность запусков прописана в скрипте, а кто то делает это через очередность в службах:
..
/usr/local/etc/hasplm
..

kissler

19.05.2019, 05:58

Для ubuntu 18.04.2 x64 lts (4.15.0) по памяти напишу первую часть, в помощь другим даже с минимальными знаниями:

- продолжение следует ... (пока нет времени)

cd ~/libusb_vhci-0.7
./configure
make

остановился над вот этим просит recompile with -fPIC

/bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Weffc++ -Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wstrict-null-sentinel -fno-enforce-eh-specs -O2 -lpthread -o libusb_vhci.la -rpath /usr/local/lib libusb_vhci_la-libusb_vhci.lo libusb_vhci_la-urb.lo libusb_vhci_la-port_stat.lo libusb_vhci_la-work.lo libusb_vhci_la-hcd.lo libusb_vhci_la-local_hcd.lo -lpthread
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o .libs/libusb_vhci_la-libusb_vhci.o .libs/libusb_vhci_la-urb.o .libs/libusb_vhci_la-port_stat.o .libs/libusb_vhci_la-work.o .libs/libusb_vhci_la-hcd.o .libs/libusb_vhci_la-local_hcd.o -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o -pthread -O2 -pthread -Wl,-soname -Wl,libusb_vhci.so.0 -o .libs/libusb_vhci.so.0.0.0
/usr/bin/ld: .libs/libusb_vhci_la-urb.o: relocation R_X86_64_PC32 against symbol `_ZTVN3usb3urbE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:432: recipe for target 'libusb_vhci.la' failed
make[2]: *** [libusb_vhci.la] Error 1

Kolhoznic

20.05.2019, 12:39

cd ~/libusb_vhci-0.7
./configure
make

остановился над вот этим просит recompile with -fPIC

/bin/bash ../libtool --tag=CXX --mode=link g++ -pthread -Wall -Weffc++ -Wold-style-cast -Woverloaded-virtual -Wsign-promo -Wstrict-null-sentinel -fno-enforce-eh-specs -O2 -lpthread -o libusb_vhci.la -rpath /usr/local/lib libusb_vhci_la-libusb_vhci.lo libusb_vhci_la-urb.lo libusb_vhci_la-port_stat.lo libusb_vhci_la-work.lo libusb_vhci_la-hcd.lo libusb_vhci_la-local_hcd.lo -lpthread
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o .libs/libusb_vhci_la-libusb_vhci.o .libs/libusb_vhci_la-urb.o .libs/libusb_vhci_la-port_stat.o .libs/libusb_vhci_la-work.o .libs/libusb_vhci_la-hcd.o .libs/libusb_vhci_la-local_hcd.o -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o -pthread -O2 -pthread -Wl,-soname -Wl,libusb_vhci.so.0 -o .libs/libusb_vhci.so.0.0.0
/usr/bin/ld: .libs/libusb_vhci_la-urb.o: relocation R_X86_64_PC32 against symbol `_ZTVN3usb3urbE' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
Makefile:432: recipe for target 'libusb_vhci.la' failed
make[2]: *** [libusb_vhci.la] Error 1

попробуй перед make сделать ./configure --disable-shared

Kolhoznic

20.05.2019, 12:47

Не торопитесь - у Вас уже все получилось.
Теперь сделайте так:
sudo netstat -lunp | grep 475

У Вас наверняка там будет пустота ... так как Вы упустили последний штрих:

http://www.safenet-sentinel.ru/helpdesk/download-space/#tabs-1
Менеджер лицензий для Linux. Версия 8.3: hasplm_linux_8.30.tgz

Этот запускаемый файлик "hasplm" запустите сначала вручную от рута и убедитесь что открылся порт 475 что бы успокоиться :vseok: :
sudo netstat -lunp | grep 475
, а далее пропишите старт hasplm перед стартом 1С (то есть после запуска UsbHasp)
У меня к примеру вся очередность запусков прописана в скрипте, а кто то делает это через очередность в службах:
..
/usr/local/etc/hasplm
..

Да ..после запуска hasplm комп действительно появился в сети
но ключей нет. А какой вы используете драйвер хасп?
Я использую этот : https://supportportal.gemalto.com/csm?id=kb_article_view&sysparm_article=KB0018315
Там внутри уже есть LM, что и ввело меня в заблуждение.

kissler

20.05.2019, 22:51

Сделал make clear и ./configure CXXFLAGS=-fPIC CFLAGS=-fPIC
Все прошло ))

kissler

26.05.2019, 09:00

А как ключик привязать к хаспу и какой кто в курсе?

vfp7

26.05.2019, 13:06

А как ключик привязать к хаспу и какой кто в курсе?

В соседней теме про Windows от мультикея (дамп), под разрядность используемого сервера 1С и/или клиентский.

HPDX2300

29.05.2019, 09:57

сервер кластера на линуксе не просит ключ, если с ним работают не более 10 сеансов - значит надо хакнуть один из исполняемых файлов сервера и заменить константу 10 на 13 :D
А то тут все про эмуляторы, для них есть отдельная тема "Эмуляторы для 1с 8.x"
Название этой темы по-смыслу ближе к "reverse engineering"

Alf500

29.05.2019, 11:49

сервер кластера на линуксе не просит ключ, если с ним работают не более 10 сеансов - значит надо хакнуть один из исполняемых файлов сервера и заменить константу 10 на 13 :D
А как быть с ограничением на 1 процесс? ))

HPDX2300

29.05.2019, 12:32

А как быть с ограничением на 1 процесс? ))

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

vfp7

29.05.2019, 20:17

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

и такой вариант развития предусмотрен ... незачем опережать события ...
ps: хотя "правильный" дистрибутив для linux x64 был бы приятен

yhm57878@cndps

30.05.2019, 12:26

HPDX2300

30.05.2019, 13:18

поставил эмуль на centos 7, вроде заработал, но 1ска вылетает с сообщением "Ключ защиты программы больше не доступен! Работа программы завершена."
у меня тоже такая ошибка вылетает после 20-30 сек работы. В чем может быть причина?

Это интересно, если тока платформа "девственница".
Опишите подробнее: платформа для линуха? какая версия? ошибка клиента или сервера? сервер файловый или кластерный? что-то делали на кленте или можно ничего не делать и через 30 сек крах (аналогично срабатыванию защиты против изменения исполняемых модулей +обнаружение эмуля vusbbus)?

Такая строка ошибки встречается в ресурсах двух модулей, backbas и backend. и её сокр.название IDS_KEYWASLOST.
Такое бывает в клиентской части, когда backbas "вылечен" унипатчем.
Когда работает эмуль, тогда платформа и клиента и сервера может быть "нелеченная" ( "девственница").

yhm57878@cndps

30.05.2019, 14:08

HPDX2300

30.05.2019, 14:28

Платформа скачана с releases.1c.ru версия 8.3.11.3133. Для линукса. Ошибка скорее клиента, Сижу в Управляемой базе вроде ничего не выходит. Открываю обычную базу, открываю отчет и выдает ошибку. Запускаю Тест Гилева и на 20% во всех случаях выдает ошибку эту. Эмуль вроде работает, ибо не запустилась бы

все происходит на CentOS-7 ?
разрядность плаформы 32 или 64 ?
а почему версия платформы такая древняя? это обусловлено используемой типовой конф-ей ?
какое название типовой конф.?
название отчета ?
если ничего не делать, то ошибка не выскочит через 30 сек ?

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

"Сижу в Управляемой базе" - т.е. тонким клиентом подключился к серверу?
"Открываю обычную базу" - открыл файловую базу толстым или тонким клиентом? (смотреть Справка -> О программе)
там же (смотреть Справка -> О программе) после слова "Лицензия" написано название ключа, по нему понятно "ключ локальный или сетевой?"

yhm57878@cndps

30.05.2019, 14:45

Ubuntu 18.04.2 LTS 64-битная. Конфигурации всегда на этой работали, вот и такую поставил. Пока не требуется обновляться. Но ради интереса, могу поставить поновее. Конфа хоть чистая, хоть какая. Правда у меня были открыты две конфигурации и два клиента. В конфигурации вылетело, когда нажал на "Открыть СКД". 30 сек это не фиксированное время. В какой-то момент определенный вылетает, когда на что-то нажимаешь.

yhm57878@cndps

30.05.2019, 14:48

Может я немного сам не догоняю... Я все никак не мог перейти на линукс, потому что 1С нужен был. А Wine мне не нравится. Ввиду моих нулевых навыков так выходит? Хотя я второй, у кого так...

yhm57878@cndps

30.05.2019, 14:59

Вот снял запись https://cloud.mail.ru/public/5pMg/3EVWpJYVX

yhm57878@cndps

30.05.2019, 15:21

Поставил 8.3.13.1865, так же вылетает

HPDX2300

30.05.2019, 16:09

Поставил 8.3.13.1865, так же вылетает

пробуй увеличить таймауты работы с ключом (NH_SESSION NH_SEND_RCV они по 1-2 сек):
редактируй или создай файл файл nethasp.ini в папке /home/_логин_ /.1cv8/1C/1cv8/

[NH_COMMON]
NH_TCPIP=Enabled
NH_SESSION=10
NH_SEND_RCV=10
[NH_TCPIP]
NH_SERVER_ADDR=192.168.56.101
NH_PORT_NUMBER=475
NH_TCPIP_METHOD=UDP
NH_USE_BROADCAST=Disabled

NH_SERVER_ADDR - это адрес компа где эмуль живет

yhm57878@cndps

30.05.2019, 16:46

пробуй увеличить таймауты работы с ключом (NH_SESSION NH_SEND_RCV они по 1-2 сек):
редактируй или создай файл файл nethasp.ini в папке /home/_логин_ /.1cv8/1C/1cv8/

[NH_COMMON]
NH_TCPIP=Enabled
NH_SESSION=10
NH_SEND_RCV=10
[NH_TCPIP]
NH_SERVER_ADDR=192.168.56.101
NH_PORT_NUMBER=475
NH_TCPIP_METHOD=UDP
NH_USE_BROADCAST=Disabled

NH_SERVER_ADDR - это адрес компа где эмуль живет

не помогло, может я все таки что-то не то сделал или пропустил?

leov-001

30.05.2019, 17:08

не помогло, может я все таки что-то не то сделал или пропустил?
Поставь дамп на 100 пользователей. На 500 сделами из 100

HPDX2300

30.05.2019, 17:21

не помогло, может я все таки что-то не то сделал или пропустил?

диспетчером файлов зайди в папку (если нет такой - создай) /home/_логин_/.1cv8/1C/1cv8/log
там все удали, если есть
диспетчером файлов зайди в папку (если нет такой - создай) /home/_логин_/.1cv8/1C/1cv8/conf
создай файл logcfg.xml
такого содержания:
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="/home/_вписать_логин_/.1cv8/1C/1cv8/log" history="96">
<event>
<eq property="name" value="LIC"/>
</event>
<event>
<eq property="name" value="HASP"/>
</event>
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="EXCPCNTX"/>
</event>
<property name="all"/>
</log>
</config>

запусти 1С и тест гилёва - поймай ошибку.

диспетчером файлов зайди в папку /home/_логин_/.1cv8/1C/1cv8/log
отсортируй по дате
зайди в новейшую папку с именем типа 1cv8_xxxxxx или 1cv8с_xxxxxx
там файл с раширением .log
включи "расширенный режим" редактирования ответа и вложи файл в ответ
файл logcfg.xml переименуй или перемести, иначе всегда техн.журннал будет создаваться и место на диске будет убывать понапрасну

yhm57878@cndps

30.05.2019, 20:10

22102211
Сделал все как написали, появились две папки с названиями 1cv8* и 1cv8c*. На всякий оба приложил

yhm57878@cndps

30.05.2019, 20:52

Поставь дамп на 100 пользователей. На 500 сделами из 100
поставил на 100, результат такой же

yhm57878@cndps

30.05.2019, 20:54

kaisar@Z500:~/Загрузки/1c$ service usbhasp status
● usbhasp.service - LSB: USBHasp Emulator
Loaded: loaded (/etc/init.d/usbhasp; generated)
Active: active (running) since Thu 2019-05-30 21:48:29 +06; 2min 32s ago
Docs: man:systemd-sysv-generator(8)
Process: 1926 ExecStart=/etc/init.d/usbhasp start (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4492)
CGroup: /system.slice/usbhasp.service
└─1953 /usr/bin/usbhaspd -d /opt/1c-key/v8-100-user.json /opt/1c-key/v8-server-x64.json

мая 30 21:48:29 Z500 usbhasp[1953]: Port 1 connected.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 2 is powered on -> connecting device.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 2 connected.
мая 30 21:48:29 Z500 usbhasp[1926]: ...done.
мая 30 21:48:29 Z500 systemd[1]: Started LSB: USBHasp Emulator.
мая 30 21:48:29 Z500 usbhasp[1953]: Port 1 is disabled.
мая 30 21:48:29 Z500 usbhasp[1953]: Set device on port 1 address = 2
мая 30 21:48:30 Z500 usbhasp[1953]: Port 2 is disabled.
мая 30 21:48:30 Z500 usbhasp[1953]: Set device on port 2 address = 3
мая 30 21:48:33 Z500 usbhasp[1953]: Port 2 is suspended.

HPDX2300

30.05.2019, 21:08

22102211
Сделал все как написали, появились две папки с названиями 1cv8* и 1cv8c*. На всякий оба приложил

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

у меня лично компу более 10 лет, но проц у меня i7 4 физических ядра, каждое с hyper threading, и оперативки 32Гига - больше мазерборд не скушает (я бы дал).
на шустром компе такое поведение может не проявиться

но это только лишь мое предположение, можно включить более подробное логирование, но мне не хватит опыта в нем разобраться.
напоследок, я бы проделал последний эксперимент, но тут нужен еще один физический комп для эмулятора:
1) поставить на него эмуль и Lic. Manager - раздавать ключи по сети
2) тест гилева выполнять в ситуации, когда локальный эмулятор не работает. ключик ловится по сети со 2-го компа
3) для ловли ключа из сети возможны болшие задержки, поэтому парни в "1 сек" ввели параметры таймаутов в hethasp.ini (смотреть пост #177). при работе с локальным ключом невозможно увеличить таймауты на операциях чтения ключа. Поэтому на слабом компе тест гилева надо выполнять с сетевым эмул-ом и hethasp.ini как в посте #177.

если крах "Ключ защиты программы больше не доступен! Работа программы завершена." ловится с эмулятором на другом компе, значит вопрос стоит того, чтобы с ним внимательно разобраться т.к. это проявление защитных механизмов платформы.

yhm57878@cndps

30.05.2019, 21:43

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

у меня лично компу более 10 лет, но проц у меня i7 4 физических ядра, каждое с hyper threading, и оперативки 32Гига - больше мазерборд не скушает (я бы дал).
на шустром компе такое поведение может не проявиться

но это только лишь мое предположение, можно включить более подробное логирование, но мне не хватит опыта в нем разобраться.
напоследок, я бы проделал последний эксперимент, но тут нужен еще один физический комп для эмулятора:
1) поставить на него эмуль и Lic. Manager - раздавать ключи по сети
2) тест гилева выполнять в ситуации, когда локальный эмулятор не работает. ключик ловится по сети со 2-го компа
3) для ловли ключа из сети возможны болшие задержки, поэтому парни в "1 сек" ввели параметры таймаутов в hethasp.ini (смотреть пост #177). при работе с локальным ключом невозможно увеличить таймауты на операциях чтения ключа. Поэтому на слабом компе тест гилева надо выполнять с сетевым эмул-ом и hethasp.ini как в посте #177.

я в другой ветке форума (https://forum.ruboard.ru/showthread.php/265303-%D0%9F%D1%80%D0%BE%D0%BF%D0%B0%D1%82%D1%87%D0%B5%D 0%BD%D0%B0%D1%8F-%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D 0%B0-1%D0%A1-8-3-%D0%9D%D0%B5-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D0%B5%D1%82?p =540507&viewfull=1#post540507) предположил, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." вызван недоработкой парней, сделавших "лекарство" unipatch (rbc_icp - это он же с добавлением лечения краха "повреждение девственности платфлормы" ). Но теперь у меня созревает подозрение, что крах "Ключ защиты программы больше не доступен! Работа программы завершена." ловят те, кто работает с локальным ключом/эмулем на относительно слабом железе.

На винде 1Ска нормально работает с rbc_icp. Запускал на Manjaro, эмулятор не смог установить, но на другой машине раздавались ключи, и в этой сети у меня тесты Гилева и другие махинации с платформой шли без каких либо ошибок. Да, вы правы, после каких либо нагрузок: загрузка отчета большого, тестирование сразу вылетает. А нельзя тайминги увеличить на локальном эмуляторе?

HPDX2300

30.05.2019, 21:59

На винде 1Ска нормально работает с rbc_icp. Запускал на Manjaro, эмулятор не смог установить, но на другой машине раздавались ключи, и в этой сети у меня тесты Гилева и другие махинации с платформой шли без каких либо ошибок. Да, вы правы, после каких либо нагрузок: загрузка отчета большого, тестирование сразу вылетает. А нельзя тайминги увеличить на локальном эмуляторе?

они в коде (захардкодены) и не настраиваются.
пожалуй, я не прав про "ловят те, кто работает с лок.эмулем на относительно слабом железе" - еще его ловят те, кто работает на платформе, вылеченной rbc_icp.
вот что я почитал в ветке про эмули:
1)
"После установки 8.3.14.1565_Windows_Repack_x86 во всех файловых базах БП 2.0 появляется ошибка KEYWASLOST через 2-3 минуты после запуска 1С"

2)
"про 8.3.14.1630:
У меня эмуляторов не было, пользовался патчерами. Режим БД MSSQL на 2016 виндовом серваке. Сутки почти - работает.
Скидывал товарищу, у него файловый режим, эмуляторов тоже не было. Не работает, через 10 минут пишет ошибку об отсутствии лицензий.
Ради эксперимента развернул его базу у себя на чистой виртуалке - у меня работает."

3)
"Подскажите как решили проблему "Ключ программы больше не доступен"?
Стояла 8.3.13.1690 с этого форума, поставил 8.3.14.1630.
В БП 2.0 постоянно вылетает такая ошибка, в БП 3.0 её нет."

т.е. БП-2.0 частенько вылетает с крахом KEYWASLOST, а БП-3 "не кашляет".

4)
"Ситуация такая. Сервер windows 2016, 1c 8.3.13.1690 (x64 + x86 для отчетов pdf) + HASP LM.
Поставил MultiKey. Aladdin монитор видит занятую лицензию
Ранее было установдено 8.3.13.1513 и пропатчено rbc_ipc.
В режиме Предприятия вопросов нет.
В конфигураторе при обновлении конфигурации, при попытке записать изменения вылетает:
"Ключ защиты программы больше не доступен! Работа программы завершена."
В логах:
NETHASP_LASTSTATUS(,prog=17,ser=ORGL8,,,,)->NStat=0,SysErr=0,stat=0,'
54:43.776000-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\CleanMemoryImpl.cpp(226):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
54:47.698008-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\CleanMemoryImpl.cpp(226):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
55:11.354000-0,EXCP,2,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=475df7fb-d939-4c96-9876-566be5a134cf,Descr='src\DBUpdaterImpl.cpp(1697):
475df7fb-d939-4c96-9876-566be5a134cf: Ключ защиты программы больше не доступен! Работа программы завершена.'
55:13.479003-1,HASP,0,process=1cv8,OSThread=3164,Txt='NETHASP_L OGOUT(,prog=17,ser=ORGL8,,,,)->,,,'
55:13.479005-1,HASP,0,process=1cv8,OSThread=3164,Txt='NETHASP_L ASTSTATUS(,prog=17,ser=ORGL8,,,,)->NStat=0,SysErr=0,stat=0,'
55:13.479007-0,EXCP,0,process=1cv8,OSThread=3980,Usr=DefUser,Ex ception=HASP has been lost!

Причем это во всех конфигурациях, даже маленькой и самописной. На платформе 8.3.13.1513 + rbc_ipc обновляет на ура."

У чела в техн.журнал упала строка "Exception=HASP has been lost!", она встречается только в теле толстого клиента (смотрел с 8.3.12 по 8.3.15).
Вообщем причины KEYWASLOST пока очень неясены.

yhm57878@cndps

30.05.2019, 22:08

Так я не лечил, с оффа взято. А я только обрадовался, что сегодня настроил хасп, можно смело на линукс с винды переходить)

HPDX2300

30.05.2019, 22:26

Так я не лечил, с оффа взято. А я только обрадовался, что сегодня настроил хасп, можно смело на линукс с винды переходить)

как следует из поста выше твоего - крах KEYWASLOST ты легко можешь получить и на винде.

vfp7

31.05.2019, 11:39

На сервере сработало обновление по безопасности и обновилось ядро, если кто не знает про этот момент с обновлениями то обратите внимание на эти два файла:
sudo nano /etc/apt/apt.conf.d/20auto-upgrades
sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Итак, перекомпиляция на Ubuntu 18.04.2:
/ Глобальную смену ядра пока не затрагиваю, так как еще не проверенно. После проверки подготовлю универсальный скрипт, а пока ручками под контролем /

..
cd ~/vhci-hcd-1.15
sudo make KVERSION=$(uname -r) KSRC=/usr/src/linux-source-4.15.0
sudo make install
cd ~/libusb_vhci-0.7
./configure
make
sudo make install
..

Далее перезагрузка сервера если не хватает знаний, или же руками подгружаете модули и запускаете эту систему.

HPDX2300

31.05.2019, 14:18

пример кода на асме - замер времени выполнения куска кода

снимок (кликни меня)
2212

кодкомментарий
call edi ; это 2-й вызов core::get_milliseconds(void)
mov ecx, eax ; сохраним результат вызова get_milliseconds в регистр ECX
sub ecx, [esi+40h] ; вычтем из него результат предыдущего вызова get_milliseconds
cmp ecx, 7D0h ; разницу сравним с 0x07D0 = 2000 т.е. 2сек.
jb short loc_1ADBCD94 ; условный переход по результату сравнения (если...то...)

HPDX2300

31.05.2019, 18:15

> когда "1 сек" решит прекратит использование HASP-ключей.

и такой вариант развития предусмотрен ... незачем опережать события ...
ps: хотя "правильный" дистрибутив для linux x64 был бы приятен

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

yhm57878@cndps

01.06.2019, 01:15

У меня на роутерер стоит Padavan (Entware). Может как-то можно туда установить эмуль, чтобы он по сети раздавал?

yhm57878@cndps

01.06.2019, 22:35

HPDX2300

02.06.2019, 13:50

Проблему так и не решил.
Пjставил на 64-битный убунту 32-битный сервер с клиентом.
Взломал backbas.so патчером rbc.
лицензия текущая:
Локальный HASP4 ORGL8 10, получило клиентское приложение
Тест Гилева прошел на УРА.

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

yhm57878@cndps

03.06.2019, 11:25

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

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

yhm57878@cndps

03.06.2019, 11:37

vfp7

03.06.2019, 12:01

Проблему так и не решил. П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

03.06.2019, 15:26

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

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

vfp7

03.06.2019, 16:31

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

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

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

HPDX2300

04.06.2019, 20:34

deniskhodus

06.06.2019, 11:45

Проблема "Ключ защиты более недоступен".
Описание: на 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) - поведение одинаковое, к сожалению.