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

[CDGR]

Если у кого есть идеи как заставить сервер видеть серверную лицензию из соседнего контейнера, было бы интересно проверить (если объединить контейнер с сервером и эмулятором то все ок)

Вот тебе идея.
Заведётся это в контейнере или нет я понятия не имею. Но ты же просил идею а не способ реализации ;) Попробуешь - напиши.

[Shaaarnir]

Парни, я правильно понимаю, что с 1с старше 8.3.16 стандартные танцы с бубнами вокруг раздачи лицензий не работают? Поднял на Дебиане 9 сервер 1с, на платформе 8.3.16.1296, УНФ 1.6. через несколько минут работы вываливается с визгом, мол ключей больше нет. (Файловая версия). Завтра еще попробую на Постгресе запустить БД.
Есть шансы победить это или проще откатится на что-то младше 8.13.16?

У меня работает в проде 8.3.17 по инструкции в теме. Вылетов нет.
На клиентах, чтобы не было вопросов у программы 1С нужно прописать в С:\Users\USER\AppData\Roaming\1C\1CEStart\ibases. v8i
[BASE-1C]
Connect=Srvr="10.10.10.10";Ref="BASE-1C";
AdditionalParameters=/UseHwLicenses-

это скажет клиенту брать лицензии с сервера

[Shaaarnir]

Сегодня еще на тестовом хочу попробовать 8.3.18
Если проблем со стабильностью и лицензированием не возникнет, сообщу.

[МоёИмя]

ОС: Ubuntu 18.04
Сервер 1с: 8.3.17.1549
Ключи: 1c_server_x64.json и 100user.json
License manager: haspd_7.90-eter2ubuntu_amd64.deb
Серверная база открытая на win тачке работает без проблем
Файловая база запускается, но через некоторое время вылетает на той же тачке с сообщением ключ не доступен

Кто-нибудь в курсе раздача ключей по сети с linux ещё не работает стабильно?
И ещё вопрос похоже, что 1с 8.3.17.1549 видит multikey в винде - 1с теперь видит и vusbbus и multikey ?

[Serg6006]

service haspd status
Hardware protection keys support bundle. Etersoft (c) 2008-2016
HASPD package 7.90 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


netstat -anp | grep aks
unix 2 [ ACC ] STREAM LISTENING 864438 224256/aksusbd /tmp/.aksusb
unix 2 [ ] DGRAM 864437 224256/aksusbd
unix 3 [ ] STREAM CONNECTED 864531 224256/aksusbd /tmp/.aksusb

netstat -anp | grep hasp
tcp 0 0 0.0.0.0:1947 0.0.0.0:* LISTEN 224287/hasplmd
udp 0 0 0.0.0.0:475 0.0.0.0:* 224278/hasplm
udp 0 0 127.0.0.1:2790 0.0.0.0:* 224269/winehasp
udp 0 0 0.0.0.0:56128 0.0.0.0:* 224287/hasplmd
udp 0 0 0.0.0.0:1947 0.0.0.0:* 224287/hasplmd
unix 2 [ ] DGRAM 46579 5655/usbhasp
unix 2 [ ] DGRAM 865363 224299/usbhasp
unix 2 [ ] DGRAM 862759 224278/hasplm
unix 3 [ ] STREAM CONNECTED 863612 224287/hasplmd
unix 2 [ ] DGRAM 865346 224287/hasplmd
unix 2 [ ] DGRAM 862745 224269/winehasp

Почему у 475 порта нет LISTEN?

usbkeytest --list

ID: 0529:0001, Bus: 001, Device: 003, Major: 189, Minor: 2
ID: 0529:0001, Bus: 001, Device: 002, Major: 189, Minor: 1
Один ключ на 100 юзеров, один серверный 64.
На файерволе все порты открыты.
В hasplm.conf все сети нужные прописаны

Test-NetConnection 192.168.1.xx -Port 475

ComputerName : 192.168.1.xx
RemoteAddress : 192.168.1.xx
RemotePort : 475
InterfaceAlias : Ethernet
SourceAddress : 192.168.11.2
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

Коннекта нет, а должен быть TcpTestSucceeded - True.

сканирование с UDP
nmap -sS -sU -T4 -A -v 192.168.1.xx
Scanning 192.168.1.xx [1000 ports]

Discovered open port 445/tcp on 192.168.1.xx

Discovered open port 80/tcp on 192.168.1.xx

Discovered open port 22/tcp on 192.168.1.xx

Discovered open port 139/tcp on 192.168.1.xx

Discovered open port 4998/tcp on 192.168.1.xx

Discovered open port 3333/tcp on 192.168.1.xx

Discovered open port 2121/tcp on 192.168.1.xx

Discovered open port 10000/tcp on 192.168.1.xx

Discovered open port 1947/tcp on 192.168.1.xx

Discovered open port 5432/tcp on 192.168.1.xx

Ни одного UDP

Естественно, 1с не видит менеджера лицензий.
Система CentOs8, 64.

Что можно еще посмотреть?
ps
Один раз 1с заработал и работал пол дня, но тогда я не проверял доступность портов.

[Serg6006]

У меня linux сервер и windows с клиентами в одном дата центре, но на разных физических серверах, все на виртуалках exi и хотя там скорость гигабитная такая схема как-то нехорошо влияет на пакеты udp.
Пока поборол проблему так:
На клиенте windows nethasp.ini:
[NH_COMMON]
NH_SESSION = 500
NH_SEND_RCV = 400
NH_TCPIP = Enabled
NH_IPX = Disabled
NH_NETBIOS = Disabled
[NH_IPX]
[NH_NETBIOS]
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.XX.XXX
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP
NH_USE_BROADCAST = Disabled
NH_SESSION = 500
NH_SEND_RCV = 400

для сервера
NH_SESSION = 50
NH_SEND_RCV = 40

Буду тестировать, но пока ключи не отваливаются.

На эту мысль натолкнул мануал от sentinel:
Если часть маршрута между запускаемой программой и ключами HASP проходит через
Интернет или на ключе более 100 лицензий, могут возникнуть проблемы с тайм-аутами при доставке
пакетов. Время ожидания ответа можно регулировать с помощью параметров NH_SESSION и
NH_SEND_RCV. По умолчанию они закомментированы, и их значение составляет 30 и 5 секунд
соответственно. Таким образом, делается 6 попыток найти ключ по 5 секунд каждая. При
необходимости Вы можете увеличить эти параметры.

[Serg6006]

Оказалось, не все так просто. Я устанавливал HASP с помощью скрипта install_hasp_centos78.sh с доработками под centos8. Получить сетевые ключи так и не удалось. В скрипте используется этот хасп http://download.etersoft.ru/pub/Eter...tos.x86_64.rpm
В некоторых инструкциях написано, что надо еще ставить haspd-modules-7.90-eter2centos.x86_64, но этот пакет нужен только для поддержки в Linux работы LPT-ключа, чего вряд ли можно встретить сейчас. В пакете haspd-7.90-eter2centos.x86_64.rpm есть aksusbd, вот только AKS монитор не видит сервера лицензий, видимо потому, что запускается раньше и как изменить это в haspd не понятно. Скрипт создает сервис usbhaspemul.service который запускает haspd так:
/usr/bin/sh -c 'find /etc/usbhaspkey -name "*.json" | xargs /usr/local/sbin/usbhasp'
В результате создаются виртуальные донглы с ключами из папки usbhaspkey.
Статус показывает, что все запущено
service haspd status
aksusbd is running
winehasp is running
hasplm is running
hasplmd is running
Вот только AKS монитор ничего не видит (донглы с ключами) и по сети раздать не может.
Эксперимент показал, что если после загрузки всего выполнить повторно загрузку ключей, а потом перезагрузку haspd и 1с, то ключи по сети прекрасно раздаются.
/usr/bin/sh -c 'find /etc/usbhaspkey -name "*.json" | xargs usbhasp –d'
systemctl restart haspd
/etc/rc.d/init.d/srv1cv83 restart

Чтобы автоматизировать эту процедуру я использовал таймер загрузки скрипта, в который поместил выше обозначенные команды. Скрипт срабатывает через минуту после загрузки системы.
Создадим юнит для запуска скрипта:
$ sudo nano /etc/systemd/system/1cusbhasprestart.service
Содержимое:

[Unit]
Description=Run script usbhasp emul and 1c

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/1cemul.sh
TimeoutStartSec=0

Создадим скрипт 1cemul.sh
sudo nano /usr/local/sbin/1cemul.sh
С содержимым
#!/bin/bash
/usr/bin/sh -c 'find /etc/usbhaspkey -name "*.json" | xargs usbhasp –d'
systemctl restart haspd
/etc/rc.d/init.d/srv1cv83 restart

Скрипт можно разместить куда угодно, например, в /usr/local/sbin/ и разрешить его выполнение:
chmod u+x /usr/local/sbin/1cemul.sh

Теперь создадим таймер
nano /etc/systemd/system/1cusbhasprestart.timer
С содержимым:

[Unit]
Description="Run script after 1 min after boot"
[Timer]
OnBootSec=1m
[Install]
WantedBy=multi-user.target
Где тймаут запуска 1 минута, после чего необходимо обновить конфигурацию systemd:
systemctl daemon-reload
Выключаем сервис загрузки скрипта, так как он будет грузится по таймеру:
systemctl disable 1cusbhasprestart.service

Включаем таймер:

systemctl enable 1cusbhasprestart.timer

Перезагружаем систему, смотрим состояние таймера:

systemctl status 1cusbhasprestart.timer

Если эту команду успеть выполнить менее чем за минуту от запуска системы, то можно увидеть сколько осталось времени до запуска скрипта, проверка ключей показывает, что скрипт сработал ключей будет в два раза больше.
Может и криво, но результат достигнут.

[Makar47]

ubuntu 20.10 x64 5.8.0-26-generic
1С:Предприятие 8.3 (8.3.18.1128)
Собрал с доработками по https://forum.ruboard.ru/showthread....l=1#post598287
Полет нормальный.

[HPDX2300]

yxo1987 написал в похожем форуме:

Ubuntu 18.04 + postgresql_12.4_1.1C + 1C 64_8_3_18_1128 + Apache 2.4 + HASP-эмулятор с ключами для сервера и для 300 спартанцев. Образ диска для VirtualBox. Linux-юзверь alexander, его пароль: "1qazXSWсобака" Ссылка размер архива 8,44 ГБ, пароль от архива: ru-board

вкл. автологон в консоли Linux:

$ sudo mkdir /etc/systemd/system/getty@tty1.service.d
$ sudo echo "[Service]\n" >> /etc/systemd/system/getty@tty1.service.d/override.conf
$ sudo echo "ExecStart=\n" >> /etc/systemd/system/getty@tty1.service.d/override.conf
$ sudo echo "ExecStart=-/sbin/agetty --noissue --autologin alexander %I $TERM\n" >> /etc/systemd/system/getty@tty1.service.d/override.conf
$ sudo echo "Type=idle\n" >> /etc/systemd/system/getty@tty1.service.d/override.conf

$ sudo reboot 

[HPDX2300]

...Поставил четыре последних релиза платформы 8.3.15.1985 8.3.16.1502 8.3.17.1549 8.3.18.891
База локальная. Дампы ключей последовательно перебрал 50-100-300U. Техн.журнал включил как написано у тебя.
Итог: Из всех четырех платформ нормально работает только 8.3.15.1985
Остальные крашатся в течении 3-5 минут без вывода какой-либо информации на экран или в лог. Просто закрываются и всё. В логе картина абсолютно идентичная полностью работоспособной версии 8.3.15.

Воспроизвел на Убунте 18.04, падение изделия 18.1128 по-тихому, без воплей.
толстый клиент запущен с новой пустой файловой базой, упал через 2 мин
сразу смотрим dmesg и там

[11364.748017] 1cv8[6108]

тонкий клиент, запущен с новой пустой файловой базой упал через примерно 4мин (время слегка рандомизировано), сразу смотрим dmesg и там

[ 9752.751130] traps: 1cv8c[5681] general protection ip:7f123f7b90cb sp:7ffec5e32cc8 error:0 in libtcmalloc_minimal.so.4[7f123f795000+2c000]
[10177.666748] traps: 1cv8c[5906] general protection ip:7f4d74e38a6b sp:7f4d4779d4f0 error:0 in libtcmalloc_minimal.so.4[7f4d74e24000+2c000]
[11708.025907] traps: pool[6218] general protection ip:7fbbd581da6b sp:7fbb9a620800 error:0 in libtcmalloc_minimal.so.4[7fbbd5809000+2c000]
[11968.486098] traps: 1cv8c[6295] general protection ip:7fca0a2276e1 sp:7ffc65773e90 error:0 in libwx_gtk3u-3.0.so.0.1.0[7fca09dd3000+b87000]
[12542.660148] traps: 1cv8c[6486] general protection ip:7f65fef76a6b sp:7f65d0c42d70 error:0 in libtcmalloc_minimal.so.4[7f65fef62000+2c000]

ну шо сказать - будем посмотреть в отладчике :-)
пока водрузим всё барахло внутри ВМ с ЦентОС-7 - авось там падение будет с воплями, как у порядочных людей :-)