при старте ноута, запускается haspd для запуска 1С - требуется наличие ключа вставляем ключ в usb запускаем 1С -нам раlостно сообщают что ключ не обнаружен. делаем рестарт haspd с установленным ключем запускаем 1С -1С работает, ключ найден Система: Altlinux Simply 7 (branch p7: x86_64 + x86_64-i586 + noarch) #rpm -qa|grep haspd haspd-3.3-alt4.M70P.5 haspd-modules-3.3-alt4.M70P.5 $ uname -a Linux bird.localdomain 3.8.13.4-std-def-alt1.M70P.1 #1 SMP Thu Jul 4 10:02:08 UTC 2013 x86_64 GNU/Linux также: имеет ли отношение тот момент, что hapsd-3.3 отсутствует для x86_64
Нужен вывод # 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С.
Принято.
