Использование нескольких однотипных hasp-ключей на одном компьютере с 1С
Давно известный факт, что нельзя корректно использовать два и более однотипных hasp-ключа ( в частности для 1С) установленные на одном копмьютере. Софт просто отказывается их видеть и использует тот или иной по своему странному усмотрению. Путей решения проблемы несколько:
1. Разнести ключи по разным компьютерам и распределить рабочие станции по ним;
2. Обменять два однотипных ключа на один более емкий;
3. Заменить один или оба ключа (два, три и более в зависимости от ситуации) на программные лицензии;
но вот возникла реальная потребность в решении такой задачи. У пользователя есть 5-ти и 10-ти пользовательские ключи и один компьютер, выступающий в роли сервера для 1С. Заводить второй компьютер для второго ключа мне не захотелось, т.к. это собственно нужно собрать или найти какой-нить второй компьютер и строго настрого научить бухгалтеров его держать всегда включенным, либо выкл/вкл синхронно с сервером, при этом он будет жрать эл/энергию, греть помещение, гудеть и т.д. и ради чего...? Поменять в фирме 1С эти два ключа на один можно только с доплатой, т.к. нет 15-ти пользовательского ключа. Опять же 5-ти пользовательский идет как основная поставка, а 10-ти - как доп. лицензии. В общем все это хлопотно, затратно по времени и финансам. Замена на программные лицензии - таже песня. Жизнь таки показала, что если использовать два ключа на одном компьютере нельзя, но очень хочется, то можно. Идем дальше...
Если честно, то все же я выбрал вариант №1, но второй компьютер было решено "поднять" виртуально на единственном сервере 1С. Всего то и делов - оставляем один ключ на физическом компьютере и пробрасываем второй ключ на виртуальную машину. Звучит просто, но оказалось не просто реализовать.
Исходные данные:
Компьютер Core I7-3770 3.4 Ghz
RAM 16 Gb
Windows 7 prof
3 usb hasp-ключа (для 7.7 многопользовательский - он не мешает работать, но мешает настраивать, 5-ти и 10-ти пользовательский для для 8-ки)
Загружаем и устанавливаем систему виртуализации VirtualBox https://www.virtualbox.org/wiki/Downloads , это отдельная тема, останавливаться не буду, инфы полно в интернете.
В качестве гостевой ОС мною была выбрана Ubuntu 13.10 server http://releases.ubuntu.com/, т.к. я ее знаю лучше других бесплатных ОС, на нее можно поставить hasp-ключ, она не имеет gui из коробки. Выделил ей 512 mb ОЗУ, один виртуальный сетевой адаптер и включил usb-контроллер. Хорошо бы включить vrdp-если все это делается удаленно. В общем пока все тривиально. При установке ОС выбрал лишь ssh-сервер из доп. плюшек для удаленки. Версия выбрана не последняя не случайно, нужно еще запилить драйвера и менеджер лицензий под hasp-ключи.
После установки гостевой ОС по желанию можно поставить на нее гостевые дополнения. Далее ставим софт для hasp-ключа. Есть конечно родные драва на сайте производителя, но он давно забил на свои ключи и довести дело до ума не получится. Обратимся к труду компании Этерсофт ftp://ftp.etersoft.ru/pub/Etersoft/HASP/3.3/Ubuntu/13.10/ , загружаем два deb-файла и ставим их:
root@ubuntu-13-10:~# apt-get install *.deb
root@ubuntu-13-10:~# service haspd status
Hardware protection keys support bundle. Etersoft (c) 2008-2012
HASPD package 3.3 with /dev/bus/usb support
Aladdin HASP 4/HL/SRM driver status:
kernel module aksparlnx is not loaded (WARNING: HASP LPT keys support is disabled! Run service haspd build if needed.)
aksusbd is running
winehasp is running
hasplm is running
hasplmd is running
Daemon version: 1.14 (#7779) - key API (USB) version: 3.88 (parallel driver not available)
/proc/bus/usb workaround is enabled
Smartkey 3 USB/LPT driver status:
skeyd is stopped
SafeNet Sentinel status:
usbsentinel is stopped
SntlKeysSrvrlnx is stopped
Use $ eterkeytest [--hasp] [--sentinel] [--eutron] for test key presence
Все это в моем случае делается из под
sudo mc
Миднайт командер установил ранее и все дальнейшая работа ведется через него.
После этих манипуляций на нашей виртуальной машине работает менеджер лицензий, о чем нужно убедиться запустив Aladdin monitor, в моем случае видно два Hasp License Manager'а. Если бы это было проделано на железном компьютере, то осталось бы подключить hasp-ключ в usb-порт, перезапусить менеджер лицензий
service haspd restart
и получился бы вполне себе работоспособный вариант, но вся тонкость с виртуальной машиной в том, что просто так туда оказалось очень сложно пробросить нужный ключ из трех близнецов. При попытке добавить hasp-ключ как usb-устройство через gui virtualboxa в выпадающем списке устройств я вижу три близнеца hasp 2.17. Кликая по любому из них, получаю разный по своей плачевности результат, либо ничего не происходит, либо подключается не нужный мне ключ, либо подключается нужный. Все очень случайно. Нужно упорядочить. Для этого в диспетчере устройство, в разделе Контроллеры USB попеременным отключением/включением выясняем какой же из близнецов каким ключем является. Переписываем из св-в Aladdin USB Key с закладки "сведений" значений свойств Путь к экземпляру устройства и ключ драйвера.
Дальнейшая логика работы выглядит следующим образом:
1. отключаем те ключи, которые должны остаться на хостовой ОС (в моем случае это 10-ти пользовательский ключ для 8ки и многопользовательский ключ для 7.7 - они не конфликтуют)
2. включаем виртуальную машину и пробрасываем в нее оставшийся ключ, она его должна "подхватить" после рестарта haspd
3. включаем отключенные ранее ключи.
цель достигнута, но все это работает только после ручных действий, нужно автоматизировать.
Заходим в каталог установки virtualbox на хостовой системе и смотрим список виртуальных машин
vboxmanage list vms
"Ubuntu 13.10" {26f58a3f-72d6-4d6e-a6db-d94a0941b497}
"Ubuntu 13.10-2" {3ea37d52-9e62-4428-8d1f-ce5fa32cca38}
нужная ВМ первая в списке, для ее старта необходимо выполнить
vboxmanage startvm "Ubuntu 13.10" --type headless
для проброса ключа нужно выполнить следующее
vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} usbattach {36fc9e60-c465-11cf-8056-444553540000}\0015
параметр после usbattach был выписан ранее для нужного нам ключа из Ключ драйвера, также его можно увидеть вот так
vboxmanage list usbhost
Host USB Devices:
UUID: 2b126c69-6c57-40c2-8f6d-e24474a9df77
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/2
Manufacturer: AKS
Product: HASP 2.17
Address: {36fc9e60-c465-11cf-8056-444553540000}\0011
Current State: Busy
UUID: 48b913a4-910f-4807-86c9-a25318511ac5
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/1
Manufacturer: AKS
Product: HASP 2.17
Address: \\?\usb#vid_80ee&pid_cafe#5&2fa0c562&0&4#{00873fdf-cafe-80ee-aa5e-00c04fb1720b}
Current State: Captured
UUID: 18876e3a-ee93-46e3-a29b-689c3f5f6b56
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/2
Manufacturer: AKS
Product: HASP 2.17
Address: {36fc9e60-c465-11cf-8056-444553540000}\0020
Current State: Busy
это адрес второго ключа, но в данном скрине ключ уже захвачен ВМ и потому не соответствует первоначальным данным
{36fc9e60-c465-11cf-8056-444553540000}\0011 и {36fc9e60-c465-11cf-8056-444553540000}\0020 - два прочих ключа
Осталось как-то через консоль научится отключать usb-устройства, для этого от компании microsoft есть утилита devcon и отключение выглядит вот так
devcon disable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
где после disable прописывается Путь к экземпляру устройства
В итоге получаем вот такой bat-файл
@echo %date% %time% Виртуальная машина включается >> autostart-vms.log
rem devcon enable "@USB\VID_0529&PID_0001\5&2FA0C562&0&4" - это пробрасываемый ключ, его не трогаем
devcon disable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
devcon disable "@USB\VID_0529&PID_0001\6&182A12DA&0&5"
vboxmanage startvm "Ubuntu 13.10" --type headless
vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} usbattach {36fc9e60-c465-11cf-8056-444553540000}\0015
devcon enable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
devcon enable "@USB\VID_0529&PID_0001\6&182A12DA&0&5"
@echo %date% %time% Виртуальная машина включена >> autostart-vms.log
прописываем запуск этого bat-файла в планировщик задач, для события - включение компьютера. Т.е. сразу после включения хоста будет стартовать виртуальная машина и получать нужный ей ключ. Это еще не все - при подключении usb-ключа к убунте, менеджер лицензий сможет его увидеть только если стартует раньше подключения usb. При холодном старте системы так оно и получится. Но нужно предусмотреть ситуацию выключения хостовой машины. Создадим еще один bat-файл
@echo %date% %time% Виртуальная машина выключается >> autostop-vms.log
rem vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} savestate
@echo %date% %time% Виртуальная машина выключена >> autostop-vms.log
Здесь для выключения применен параметр - savestate, т.е. ВМ просто замораживается с записью состояния ОЗУ на диск, это происходит очень быстро в отличие от acpipowerbutton, когда убунта около минуты себя выключает. Предусмотреть корректное отключение ВМ просто необходимо, инача после очередного сброса ВМ она может не загрузиться с поломкой ФС. Также нужно прописать этот bat-файл в политике, в скрипты выключения хоста. Для этого выполняем gpedit.msc -> конфигурация компьютера -> конфигурация windows -> сценарии запуск/завершение. Этим самым мы себя относительно обезопасили от холодного рестарта ВМ. Т.е. при выключении хоста будет сохранено состояние ВМ, при включении хоста будет выполнен очень быстрый старт ВМ. Но внутри ВМ этого будет незаметно, всего лишь прыгнут вперед часы и произойдет переподключение проброшенного usb-ключа. После переподключения usb-ключа нужно как-то выполнить перезапуск менеджера лицензий. Предлагаю следующий вариант. Нужно создать правило для Udev и разместить его в /ect/udev/rules.d (к примеру /ect/udev/rules.d/haspd-restart.rules, не забыть проверить права на файл) со следующим содержанием:
ACTION=="add", ATTR{manufacturer}=="AKS", ATTR{product}=="HASP 2.17", RUN+=/home/sergey/haspd-restart.sh"
после рестарта Udev
restart udev
остается создать /home/sergey/haspd-restart.sh
#!/bin/sh
service haspd restart
не забываем дать права на исполнение. Т.е. в случае подключения нового устройства с определенными атрибутами произойдет рестарт службы менеджера лицензий. Стоит заменить что выборка этих атрибутов оказалась также весьма не простой. Для начала нашел в /dev/bus/usb/002/024 признак моего ключа
Затем через udevadm выловил присущие ключу атрибуты
root@ubuntu-13-10:/dev/bus/usb/002# udevadm info -a -p $(udevadm info --query=path --name=/dev/bus/usb/002/024)
...
ATTR{manufacturer}=="AKS"
ATTR{removable}=="unknown"
ATTR{idProduct}=="0001"
ATTR{bDeviceClass}=="ff"
ATTR{product}=="HASP 2.17"
...
Для проверки того, правильно ли составлено правило можно выполнить следующее
udevadm info --query=path --name=/dev/bus/usb/002/024
/devices/pci0000:00/0000:00:06.0/usb2/2-1
получаем путь, добавляем к нему /sys и выполняем
root@ubuntu-13-10:/dev/bus/usb/002# udevadm test /sys/devices/pci0000:00/0000:00:06.0/usb2/2-1
в конце вывода видим нечто вроде
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/024
DEVNUM=024
DEVPATH=/devices/pci0000:00/0000:00:06.0/usb2/2-1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=HASP_2.17
ID_MODEL_ENC=HASP\x202.17
ID_MODEL_FROM_DATABASE=HASP v0.06
ID_MODEL_ID=0001
ID_REVISION=0217
ID_SERIAL=AKS_HASP_2.17
ID_USB_INTERFACES=:ff0000:
ID_VENDOR=AKS
ID_VENDOR_ENC=AKS
ID_VENDOR_FROM_DATABASE=Aladdin Knowledge Systems
ID_VENDOR_ID=0529
MAJOR=189
MINOR=151
PRODUCT=529/1/217
SUBSYSTEM=usb
TYPE=255/0/0
UDEV_LOG=6
USEC_INITIALIZED=401565464
run: '/home/sergey/haspd-restart.sh'
unload module index
значит с параметрами угадали. Система должна работать.
Из ньюансов нужно помнить что монитор менеджеров лицензий показывает ключ на менеджере, только после того, как занята хотя бы одна лицения клиентским подключением. Очень важно что после этой настройки нельзя переподключать Usb-ключи, т.к. они могу поменять свои свойства и потребуется правка bat-файла автозагрузки. Ну а на ВМ можно за дарма еще поднять dhcp-сервер, samba-сервер (особо важно если в маленькой сети нет серверой ОС и в сетевом окружении творится неладное). Не забываем распределять клиенские приложения по разным серверам с помощью Nethasp.ini
1. Разнести ключи по разным компьютерам и распределить рабочие станции по ним;
2. Обменять два однотипных ключа на один более емкий;
3. Заменить один или оба ключа (два, три и более в зависимости от ситуации) на программные лицензии;
но вот возникла реальная потребность в решении такой задачи. У пользователя есть 5-ти и 10-ти пользовательские ключи и один компьютер, выступающий в роли сервера для 1С. Заводить второй компьютер для второго ключа мне не захотелось, т.к. это собственно нужно собрать или найти какой-нить второй компьютер и строго настрого научить бухгалтеров его держать всегда включенным, либо выкл/вкл синхронно с сервером, при этом он будет жрать эл/энергию, греть помещение, гудеть и т.д. и ради чего...? Поменять в фирме 1С эти два ключа на один можно только с доплатой, т.к. нет 15-ти пользовательского ключа. Опять же 5-ти пользовательский идет как основная поставка, а 10-ти - как доп. лицензии. В общем все это хлопотно, затратно по времени и финансам. Замена на программные лицензии - таже песня. Жизнь таки показала, что если использовать два ключа на одном компьютере нельзя, но очень хочется, то можно. Идем дальше...
Если честно, то все же я выбрал вариант №1, но второй компьютер было решено "поднять" виртуально на единственном сервере 1С. Всего то и делов - оставляем один ключ на физическом компьютере и пробрасываем второй ключ на виртуальную машину. Звучит просто, но оказалось не просто реализовать.
Исходные данные:
Компьютер Core I7-3770 3.4 Ghz
RAM 16 Gb
Windows 7 prof
3 usb hasp-ключа (для 7.7 многопользовательский - он не мешает работать, но мешает настраивать, 5-ти и 10-ти пользовательский для для 8-ки)
Загружаем и устанавливаем систему виртуализации VirtualBox https://www.virtualbox.org/wiki/Downloads , это отдельная тема, останавливаться не буду, инфы полно в интернете.
В качестве гостевой ОС мною была выбрана Ubuntu 13.10 server http://releases.ubuntu.com/, т.к. я ее знаю лучше других бесплатных ОС, на нее можно поставить hasp-ключ, она не имеет gui из коробки. Выделил ей 512 mb ОЗУ, один виртуальный сетевой адаптер и включил usb-контроллер. Хорошо бы включить vrdp-если все это делается удаленно. В общем пока все тривиально. При установке ОС выбрал лишь ssh-сервер из доп. плюшек для удаленки. Версия выбрана не последняя не случайно, нужно еще запилить драйвера и менеджер лицензий под hasp-ключи.
После установки гостевой ОС по желанию можно поставить на нее гостевые дополнения. Далее ставим софт для hasp-ключа. Есть конечно родные драва на сайте производителя, но он давно забил на свои ключи и довести дело до ума не получится. Обратимся к труду компании Этерсофт ftp://ftp.etersoft.ru/pub/Etersoft/HASP/3.3/Ubuntu/13.10/ , загружаем два deb-файла и ставим их:
root@ubuntu-13-10:~# apt-get install *.deb
root@ubuntu-13-10:~# service haspd status
Hardware protection keys support bundle. Etersoft (c) 2008-2012
HASPD package 3.3 with /dev/bus/usb support
Aladdin HASP 4/HL/SRM driver status:
kernel module aksparlnx is not loaded (WARNING: HASP LPT keys support is disabled! Run service haspd build if needed.)
aksusbd is running
winehasp is running
hasplm is running
hasplmd is running
Daemon version: 1.14 (#7779) - key API (USB) version: 3.88 (parallel driver not available)
/proc/bus/usb workaround is enabled
Smartkey 3 USB/LPT driver status:
skeyd is stopped
SafeNet Sentinel status:
usbsentinel is stopped
SntlKeysSrvrlnx is stopped
Use $ eterkeytest [--hasp] [--sentinel] [--eutron] for test key presence
Все это в моем случае делается из под
sudo mc
Миднайт командер установил ранее и все дальнейшая работа ведется через него.
После этих манипуляций на нашей виртуальной машине работает менеджер лицензий, о чем нужно убедиться запустив Aladdin monitor, в моем случае видно два Hasp License Manager'а. Если бы это было проделано на железном компьютере, то осталось бы подключить hasp-ключ в usb-порт, перезапусить менеджер лицензий
service haspd restart
и получился бы вполне себе работоспособный вариант, но вся тонкость с виртуальной машиной в том, что просто так туда оказалось очень сложно пробросить нужный ключ из трех близнецов. При попытке добавить hasp-ключ как usb-устройство через gui virtualboxa в выпадающем списке устройств я вижу три близнеца hasp 2.17. Кликая по любому из них, получаю разный по своей плачевности результат, либо ничего не происходит, либо подключается не нужный мне ключ, либо подключается нужный. Все очень случайно. Нужно упорядочить. Для этого в диспетчере устройство, в разделе Контроллеры USB попеременным отключением/включением выясняем какой же из близнецов каким ключем является. Переписываем из св-в Aladdin USB Key с закладки "сведений" значений свойств Путь к экземпляру устройства и ключ драйвера.
Дальнейшая логика работы выглядит следующим образом:
1. отключаем те ключи, которые должны остаться на хостовой ОС (в моем случае это 10-ти пользовательский ключ для 8ки и многопользовательский ключ для 7.7 - они не конфликтуют)
2. включаем виртуальную машину и пробрасываем в нее оставшийся ключ, она его должна "подхватить" после рестарта haspd
3. включаем отключенные ранее ключи.
цель достигнута, но все это работает только после ручных действий, нужно автоматизировать.
Заходим в каталог установки virtualbox на хостовой системе и смотрим список виртуальных машин
vboxmanage list vms
"Ubuntu 13.10" {26f58a3f-72d6-4d6e-a6db-d94a0941b497}
"Ubuntu 13.10-2" {3ea37d52-9e62-4428-8d1f-ce5fa32cca38}
нужная ВМ первая в списке, для ее старта необходимо выполнить
vboxmanage startvm "Ubuntu 13.10" --type headless
для проброса ключа нужно выполнить следующее
vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} usbattach {36fc9e60-c465-11cf-8056-444553540000}\0015
параметр после usbattach был выписан ранее для нужного нам ключа из Ключ драйвера, также его можно увидеть вот так
vboxmanage list usbhost
Host USB Devices:
UUID: 2b126c69-6c57-40c2-8f6d-e24474a9df77
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/2
Manufacturer: AKS
Product: HASP 2.17
Address: {36fc9e60-c465-11cf-8056-444553540000}\0011
Current State: Busy
UUID: 48b913a4-910f-4807-86c9-a25318511ac5
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/1
Manufacturer: AKS
Product: HASP 2.17
Address: \\?\usb#vid_80ee&pid_cafe#5&2fa0c562&0&4#{00873fdf-cafe-80ee-aa5e-00c04fb1720b}
Current State: Captured
UUID: 18876e3a-ee93-46e3-a29b-689c3f5f6b56
VendorId: 0x0529 (0529)
ProductId: 0x0001 (0001)
Revision: 2.23 (0223)
Port: 0
USB version/speed: 2/2
Manufacturer: AKS
Product: HASP 2.17
Address: {36fc9e60-c465-11cf-8056-444553540000}\0020
Current State: Busy
это адрес второго ключа, но в данном скрине ключ уже захвачен ВМ и потому не соответствует первоначальным данным
{36fc9e60-c465-11cf-8056-444553540000}\0011 и {36fc9e60-c465-11cf-8056-444553540000}\0020 - два прочих ключа
Осталось как-то через консоль научится отключать usb-устройства, для этого от компании microsoft есть утилита devcon и отключение выглядит вот так
devcon disable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
где после disable прописывается Путь к экземпляру устройства
В итоге получаем вот такой bat-файл
@echo %date% %time% Виртуальная машина включается >> autostart-vms.log
rem devcon enable "@USB\VID_0529&PID_0001\5&2FA0C562&0&4" - это пробрасываемый ключ, его не трогаем
devcon disable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
devcon disable "@USB\VID_0529&PID_0001\6&182A12DA&0&5"
vboxmanage startvm "Ubuntu 13.10" --type headless
vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} usbattach {36fc9e60-c465-11cf-8056-444553540000}\0015
devcon enable "@USB\VID_0529&PID_0001\5&2FA0C562&0&3"
devcon enable "@USB\VID_0529&PID_0001\6&182A12DA&0&5"
@echo %date% %time% Виртуальная машина включена >> autostart-vms.log
прописываем запуск этого bat-файла в планировщик задач, для события - включение компьютера. Т.е. сразу после включения хоста будет стартовать виртуальная машина и получать нужный ей ключ. Это еще не все - при подключении usb-ключа к убунте, менеджер лицензий сможет его увидеть только если стартует раньше подключения usb. При холодном старте системы так оно и получится. Но нужно предусмотреть ситуацию выключения хостовой машины. Создадим еще один bat-файл
@echo %date% %time% Виртуальная машина выключается >> autostop-vms.log
rem vboxmanage controlvm {26f58a3f-72d6-4d6e-a6db-d94a0941b497} savestate
@echo %date% %time% Виртуальная машина выключена >> autostop-vms.log
Здесь для выключения применен параметр - savestate, т.е. ВМ просто замораживается с записью состояния ОЗУ на диск, это происходит очень быстро в отличие от acpipowerbutton, когда убунта около минуты себя выключает. Предусмотреть корректное отключение ВМ просто необходимо, инача после очередного сброса ВМ она может не загрузиться с поломкой ФС. Также нужно прописать этот bat-файл в политике, в скрипты выключения хоста. Для этого выполняем gpedit.msc -> конфигурация компьютера -> конфигурация windows -> сценарии запуск/завершение. Этим самым мы себя относительно обезопасили от холодного рестарта ВМ. Т.е. при выключении хоста будет сохранено состояние ВМ, при включении хоста будет выполнен очень быстрый старт ВМ. Но внутри ВМ этого будет незаметно, всего лишь прыгнут вперед часы и произойдет переподключение проброшенного usb-ключа. После переподключения usb-ключа нужно как-то выполнить перезапуск менеджера лицензий. Предлагаю следующий вариант. Нужно создать правило для Udev и разместить его в /ect/udev/rules.d (к примеру /ect/udev/rules.d/haspd-restart.rules, не забыть проверить права на файл) со следующим содержанием:
ACTION=="add", ATTR{manufacturer}=="AKS", ATTR{product}=="HASP 2.17", RUN+=/home/sergey/haspd-restart.sh"
после рестарта Udev
restart udev
остается создать /home/sergey/haspd-restart.sh
#!/bin/sh
service haspd restart
не забываем дать права на исполнение. Т.е. в случае подключения нового устройства с определенными атрибутами произойдет рестарт службы менеджера лицензий. Стоит заменить что выборка этих атрибутов оказалась также весьма не простой. Для начала нашел в /dev/bus/usb/002/024 признак моего ключа
Затем через udevadm выловил присущие ключу атрибуты
root@ubuntu-13-10:/dev/bus/usb/002# udevadm info -a -p $(udevadm info --query=path --name=/dev/bus/usb/002/024)
...
ATTR{manufacturer}=="AKS"
ATTR{removable}=="unknown"
ATTR{idProduct}=="0001"
ATTR{bDeviceClass}=="ff"
ATTR{product}=="HASP 2.17"
...
Для проверки того, правильно ли составлено правило можно выполнить следующее
udevadm info --query=path --name=/dev/bus/usb/002/024
/devices/pci0000:00/0000:00:06.0/usb2/2-1
получаем путь, добавляем к нему /sys и выполняем
root@ubuntu-13-10:/dev/bus/usb/002# udevadm test /sys/devices/pci0000:00/0000:00:06.0/usb2/2-1
в конце вывода видим нечто вроде
ACTION=add
BUSNUM=002
DEVNAME=/dev/bus/usb/002/024
DEVNUM=024
DEVPATH=/devices/pci0000:00/0000:00:06.0/usb2/2-1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=HASP_2.17
ID_MODEL_ENC=HASP\x202.17
ID_MODEL_FROM_DATABASE=HASP v0.06
ID_MODEL_ID=0001
ID_REVISION=0217
ID_SERIAL=AKS_HASP_2.17
ID_USB_INTERFACES=:ff0000:
ID_VENDOR=AKS
ID_VENDOR_ENC=AKS
ID_VENDOR_FROM_DATABASE=Aladdin Knowledge Systems
ID_VENDOR_ID=0529
MAJOR=189
MINOR=151
PRODUCT=529/1/217
SUBSYSTEM=usb
TYPE=255/0/0
UDEV_LOG=6
USEC_INITIALIZED=401565464
run: '/home/sergey/haspd-restart.sh'
unload module index
значит с параметрами угадали. Система должна работать.
Из ньюансов нужно помнить что монитор менеджеров лицензий показывает ключ на менеджере, только после того, как занята хотя бы одна лицения клиентским подключением. Очень важно что после этой настройки нельзя переподключать Usb-ключи, т.к. они могу поменять свои свойства и потребуется правка bat-файла автозагрузки. Ну а на ВМ можно за дарма еще поднять dhcp-сервер, samba-сервер (особо важно если в маленькой сети нет серверой ОС и в сетевом окружении творится неладное). Не забываем распределять клиенские приложения по разным серверам с помощью Nethasp.ini