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

[Freddy_Freeman]

собрал пакет для debian (amd64) на ядре 4.9 - брать здесь

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

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

[Freddy_Freeman]

Для ubuntu 18.04.2 x64 lts (4.15.0)

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

[Freddy_Freeman]

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

[HPDX2300]

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

читаю 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]

Инструкция для тех, кто хочет поставить эмулятор на 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-...ernel%20module и качаем vhci-hcd-1.15.tar.gz
Переходим на https://sourceforge.net/projects/usb...e%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/...tos.x86_64.rpm
wget http://ftp.etersoft.ru/pub/Etersoft/...tos.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 и vfp7.

[HPDX2300]

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

[tranger]

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


Для удалённого подключения 1С сервера к haspd использую следующие настройки:
В /opt/1C/v8.3/x86_64/conf/nethasp.ini добавляю:

[NH_COMMON]
NH_IPX = Disabled
NH_NETBIOS = Disabled
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.0.5; IP адрес компьютера с менеджером лицензий.
NH_USE_BROADCAST = Disabled

[Djordjlee]

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

[sergnn52]

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


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

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

Верно ?

[vfp7]

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