Bug 9425

Нужен вывод
# eterkeytest --hasp

Также вашего сообщения не ясно, какая версия 1С, какой ключ (локальный/сетевой).

Антон, подтверждаешь: hasp не видит вставленный ключ до перезапуска.
Там у нас используется имитация /proc/bus/usb, может быть она оказывается статической?

(В ответ на comment #2)
> Антон, подтверждаешь: hasp не видит вставленный ключ до перезапуска.
> Там у нас используется имитация /proc/bus/usb, может быть она оказывается
> статической?

Если ключ вынимался/вставлялся, то да, успешных случаев, что он тут же подхватывался - не было. Перезапускали haspd - все становилось в порядке.

(В ответ на comment #3)
> (В ответ на comment #2)
> > Антон, подтверждаешь: hasp не видит вставленный ключ до перезапуска.
> > Там у нас используется имитация /proc/bus/usb, может быть она оказывается
> > статической?
> 
> Если ключ вынимался/вставлялся, то да, успешных случаев, что он тут же
> подхватывался - не было. Перезапускали haspd - все становилось в порядке.

а может как-то принудительно рестарт делать haspd ? после втыкания. и обнаружения на шине ключа

Курю udev rules...

http://www.reactivated.net/writing_udev_rules.html
http://rus-linux.net/lib.php?name=MyLDP/sys-conf/udev.html
http://www.opennet.ru/base/sys/udev_review.txt.html
http://lists.altlinux.org/pipermail/community/2011-April/670700.html

(В ответ на comment #5)
> Курю udev rules...
Лучше бы выяснили, когда перестало работать, и от чего это зависит.
А строить костыли вокруг, пока неизвестно, от чего перестало работать...

(В ответ на comment #6)
> Лучше бы выяснили, когда перестало работать, и от чего это зависит.
> А строить костыли вокруг, пока неизвестно, от чего перестало работать...

Вообще-то поддержка hotplug в haspd нигде не указана. Неужели когда-то работало ???

(Ответ Anton Agapov на комментарий7)
> (В ответ на comment #6)
> > Лучше бы выяснили, когда перестало работать, и от чего это зависит.
> > А строить костыли вокруг, пока неизвестно, от чего перестало работать...
> 
> Вообще-то поддержка hotplug в haspd нигде не указана. Неужели когда-то
> работало ???

Думаю, что никогда не работало. И чинить пока что не будем.
Хотя идея вписать в правила для udev перезапуск сервиса не так плоха.
Если это действительно необходимо.

Обнаружил
* Пт ноя 29 2013 Andrey Cherepanov <cas@altlinux.org> 3.3-alt7
- Add udev rules to use 1C hasp key if plugged without haspd restart
  (see eterbug #9425)

(Ответ Vitaly Lipatov на комментарий9)
> Обнаружил
> * Пт ноя 29 2013 Andrey Cherepanov <cas@altlinux.org> 3.3-alt7
> - Add udev rules to use 1C hasp key if plugged without haspd restart
>   (see eterbug #9425)

будет собран в репозитарии АЛЬТ? p7 в частности?

(Ответ Maks на комментарий10)
> (Ответ Vitaly Lipatov на комментарий9)
> > Обнаружил
> > * Пт ноя 29 2013 Andrey Cherepanov <cas@altlinux.org> 3.3-alt7
> > - Add udev rules to use 1C hasp key if plugged without haspd restart
> >   (see eterbug #9425)
> 
> будет собран в репозитарии АЛЬТ? p7 в частности?
Собран в Sisyphus и p7.

2015-Aug-23 20:17:08 :: updated /gears/h/haspd.git branch `p7'
2015-Aug-23 20:17:24 :: gears update OK
2015-Aug-23 20:17:24 :: task #147967 for p7 DONE

Обновил пакет на сервере (Кандидат: 3.3-alt9.M70P.10). Проверили заход в 1С...
...
Увы, сервис haspd таки пришлось перезапустить. После чего - ОК.

Так как на рабочей системе нежелательно "200 тестов перетыкания проводить", то больше пока ничего не скажу.

(Ответ Anton Agapov на комментарий12)
> Обновил пакет на сервере (Кандидат: 3.3-alt9.M70P.10). Проверили заход в
> 1С...
> ...
> Увы, сервис haspd таки пришлось перезапустить. После чего - ОК.
> 
> Так как на рабочей системе нежелательно "200 тестов перетыкания проводить",
> то больше пока ничего не скажу.
1. В твоей проверке ничего нет о перетыкании ключа
2. Не заметно перезапуска сервиса после обновления пакета
3. Поскольку суть в правилах udev, видимо, их нужно было как-то сказать перечитать?
4. Проверять можно через элементарный eterkeytest:

[lav@server ~]$ cd /tmp
[lav@server tmp]$ setnethasp localhost
nethasp.ini is created succesfully.
[lav@server tmp]$ eterkeytest --hasp

eterkeytest for WINE@Etersoft 2.1.3-eter8
USB:
Vendor:Product: 0665:5161 [denied], [denied]
Vendor:Product: 0529:0001 Aladdin HASP (supported):  AKS, HASP 2.17
Vendor:Product: 0529:0001 Aladdin HASP (supported):  AKS, HASP 2.17

Warning: Keys marked with 'denied' will not be accessed from wine sys drivers
HASP:
Local HASP keys drivers in 1C 8.x used in direct mode via libusb from wine, haspd service does not required.
HASP API VERSION: 8.0

HASP Local:
	USB HASP4 M4 (HASP4 is connected, key is HASP4 Net 5 licenses)
	[ 6] 1C:Accountancy v8.0

	USB HASP4 M1 (HASP4 is connected, key is local HASP4)
	[ 7] 1C:Enterprise v8.0 (Applications server)


HASP Net at host (see nethasp.ini) (press Ctrl-C to break):
..............	ERROR: Login failed (can't detect any key)


Правда сетевые ключи по сети она обнаружить не смогла.
Предлагаю проверить новую версию:
/var/ftp/pub/Etersoft/HASP/unstable/ALTLinux/p7/haspd-7.32-alt0.M70P.1.i586.rpm

(Ответ Vitaly Lipatov на комментарий13)
> (Ответ Anton Agapov на комментарий12)
> > Обновил пакет на сервере (Кандидат: 3.3-alt9.M70P.10). Проверили заход в
> > 1С...
> > ...
> > Увы, сервис haspd таки пришлось перезапустить. После чего - ОК.
> > 
> > Так как на рабочей системе нежелательно "200 тестов перетыкания проводить",
> > то больше пока ничего не скажу.
> 1. В твоей проверке ничего нет о перетыкании ключа
> 2. Не заметно перезапуска сервиса после обновления пакета
> 3. Поскольку суть в правилах udev, видимо, их нужно было как-то сказать
> перечитать?
> 4. Проверять можно через элементарный eterkeytest:

1. Переткнул (тогда) оба ключа с 5-тисекундным интервалом. Разумеется, после установки пакета и перезапуска службы.
2. Разумеется службу haspd перезапустил вручную. Хотя, судя по выводу, это было сделано при обновлении пакета самим rpm.
3. Я был уверен, что правила перечитываются каждый раз при возникновении события для udevd. (Со времен настройки мегафон-модемов...)
4. А это проверит то, что менеджер лицензий 1С тоже все увидит и будет предоставлять ключ кому положено ? Впрочем, тест полезный в любом случае.

По поводу п.3 "гуглеж" выдал:

Udev uses the inotify mechanism to watch for changes in the rules directory, in both the library and in the local configuration trees (typically located at /lib/udev/rules.d and /etc/udev/rules.d). So you don't need to do anything when you change a rules file.

и, тоже полезно:

udevadm control --reload-rules

(Ответ Anton Agapov на комментарий14)
...
> 4. А это проверит то, что менеджер лицензий 1С тоже все увидит и будет
> предоставлять ключ кому положено ? Впрочем, тест полезный в любом случае.
Да, тест ведёт себя точно так же, как 1С 7.7
 
> По поводу п.3 "гуглеж" выдал:
> 
> Udev uses the inotify mechanism to watch for changes in the rules directory,
...
> udevadm control --reload-rules
А, ну отлично.

система П7 (x64)

установили обновленный хаспд. который i586-hapsd 
$ rpm -qa| grep hasp
haspd-modules-3.3-alt4.M70P.5
i586-haspd-3.3-alt9.M70P.10


перезагрузил систему,
демон хасп - стартанул, правила для удев тоже вроде.

втыкаем ключ - облом

ЧЯДНТ?

Давайте проверим на пакете haspd 7.32
http://download.etersoft.ru/pub/Etersoft/HASP/unstable/ALTLinux/p7/

(Ответ Vitaly Lipatov на комментарий17)
> Давайте проверим на пакете haspd 7.32
> http://download.etersoft.ru/pub/Etersoft/HASP/unstable/ALTLinux/p7/

Установил haspd и haspd-modules из указанной директории, проверил: все равно требуется перезапуск службы после перетыкания ключей.

(Ответ Anton Agapov на комментарий18)
> (Ответ Vitaly Lipatov на комментарий17)
> > Давайте проверим на пакете haspd 7.32
> > http://download.etersoft.ru/pub/Etersoft/HASP/unstable/ALTLinux/p7/
> 
> Установил haspd и haspd-modules из указанной директории, проверил: все равно
> требуется перезапуск службы после перетыкания ключей.

ага, так и есть у меня тоже

Нужно посмотреть на правила udev, что не так.

(Ответ Vitaly Lipatov на комментарий20)
> Нужно посмотреть на правила udev, что не так.

"Пощупал" правила из /lib/udev/rules.d/80-hasp.rules - они применяются. Помогает команда:

# udevadm test $(udevadm info -q path -n [device name]) 2>&1

[device name] = /dev/bus/usb/003/006 например (на рабочей системе).

Я попробовал вручную выполнять команды добавления и удаления (-c и -r)... Никакой реакции на них не заметил. (Тестировал eterkeytest'ом: по сети всегда нет доступа... Локально всегда видит оба ключа.) Замечу, что в выводе aksusbd -h нет информации о -c и -r. Может, поэтому и реакции на перетыкание нет, что опции уже не поддерживаются в полном объеме (принимаются, но не выполняются)...

Нашел: https://bugs.etersoft.ru/show_bug.cgi?id=513 , где последний комментарий рождает еще больше вопросов.

Вот, что в логах /var/log/messages на команды:

[root@server ~]# /usr/sbin/aksusbd -l3 -r /dev/bus/usb/003/006 
[root@server ~]# /usr/sbin/aksusbd -l3 -c /dev/bus/usb/003/006


Sep  7 17:56:18 server aksusbd[1939]: aksusbd_req_dev_connect: write() failed: -1, Bad file descriptor 
Sep  7 17:56:25 server aksusbd: aksusbd_usb_dev_remove: device '/dev/bus/usb/003/006' 
...
Sep  7 17:56:25 server aksusbd[1939]: aksusbd_req_dev_connect: write() failed: -1, Bad file descriptor 

Пробовал найти что-нибудь в:

nohup strace -yf /usr/sbin/aksusbd -l3 -r /dev/aks/hasp/3-3

Но там только упоминается /dev/Hardlock... Причем:

open("/dev/Hardlock", O_RDWR)           = -1 ENXIO (No such device or address)

Хотя этот c-файл еще как есть !

Непонятки... Можно переписать udev-правило, чтобы оно просто перезапускало службу... В свете скупой информации о aksusbd (на официальном сайте в том числе), - это будет работающий костыль.

(Ответ Anton Agapov на комментарий21)
> Можно переписать udev-правило, чтобы оно просто перезапускало
> службу... В свете скупой информации о aksusbd (на официальном сайте в том
> числе), - это будет работающий костыль.

Это предложение осталось без внимания - умываю руки: менеджер лицензий от 1С - это разработка 1С.

Принято.