8 дек. 2015 г.

Nethasp для сервера 1С 8.3 на Debian - старые грабли о главном - обновлено.






Да, он все так же продолжает отваливаться.
Похоже, Aladdin (или уже Sentinel?) особо не спешит решать проблему с поддержкой своего софта отличными от Windows операционками.

Пост обновлен, добавлено немного о процессах hasd, hasplmd и неоднозначности инструкций  )

Что имеется.


Имеется сервер с уже установленным 1С 8.3 + postgresql: Debian 7, 32-разрядная, драйвера nethasp от Etersoft http://download.etersoft.ru/pub/Etersoft/HASP/last/.

ВАЖНО: nethasp 7.40 работать в данной связке не будет!
Ставить версию 3.3. То есть Debian 7 i386 = nethasp 3.3

Выяснено методом тыка: файлы haspd и hasplmd в директории /usr/sbin имели нестандартный (какой-то маленький) размер. Судя по всему, просто некорректно ставятся. Подробнее разбираться не было времени.

Решение.


В моем случае cron постоянно перезапускает проблемный сервис haspd. Варварски, зато работает.

Идем в директорию cron:

#cd /etc/cron.d
#touch /etc/cron.d/hasp.sh

пишем содержимое файла:

#!/bin/bash
if [ "`/usr/sbin/haspdemo | sed -n 's/^LOCALHASP_ISHASP.* \(\-\?[0-9]*\)$/\1/p'`" == "-100" ]; then service haspd $
else exit
fi

сохраняем файл, даем ему права на запуск для пользователей и групп, редактируем crontab:

crontab -e

пишем задание для cron:

*/1 *    * * *          /etc/cron.d/./hasp.sh
*/1 *    * * *          /etc/init.d/haspd start

Вторая строчка именно такая вот почему:

Преамбула: менеджер лицензий все так же отваливался, просто вырос период отключения.
После ввода service haspd restart ключа все так же не было видно.
История почти детективная.

Мы имеем ДВА, Карл, процесса haspd: в директории /usr/sbin и /etc/init.d
Так вот, процесс /etc/init.d/haspd просто умирал., от слова "совсем", так что /etc/init.d/haspd restart выдавал no such process и ничем нам помочь не мог.
А вот /etc/init.d/haspd start отлично работал, и ключ становился виден.