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

[CDGR]

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

Давай попробуем.
Linux Mint 20 Cinnamon

$ uname -a
Linux 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Собрал по образцу вот этого скрипта эмулятор. Пропатчил vhci-hcd-1.15/Makefile и vhci-hcd-1.15/usb-vhci-iocifc.c чтобы собралось под новое ядро. Собралось и завелось нормально.
Поставил четыре последних релиза платформы

$ ls /opt/1cv8/x86_64/
8.3.15.1985  8.3.16.1502  8.3.17.1549  8.3.18.891

База локальная. Для теста использовал БП 30 КОРП и УНФ 1.6
Дампы ключей последовательно перебрал 50-100-300U
Журнал включил как написано у тебя.

Итог:
Из всех четырех платформ нормально работает только 8.3.15.1985
Остальные крашатся в течении 3-5 минут без вывода какой-либо информации на экран или в лог. Просто закрываются и всё. В логе картина абсолютно идентичная полностью работоспособной версии 8.3.15.

45:25.254001-0,EXCP,0,process=1cv8c,OSThread=8534,Usr=DefUser,Exception=DatabaseException8,Descr="Не удалось заблокировать запись. Действие (изменение, удаление или блокировка записи) не выполнено 'DATAZONEOBJECTLOCKS'"

с той лишь разницей, что 8.3.15 продолжает работать, а остальные закрываются. Причем количество таких строчек в логе может быть различным. Так что не думаю, что проблема в этом.
Файловая система ext4. SSD

Что я думаю:
Доступный мне вариант эмулятора я собрал правильно (в противном случае не работало бы ничего вообще), однако, на релизах платформы старше 8.3.16 этого не достаточно. Для дополнительной проверки этой гипотезы я ставил на чистую систему Учебную версию 8.3.17.1549 за исключением оговоренных в документации ограничений -- никаких проблем. После установки Учебной версии я понял, что платформа должна работать в принципе и приступил к проверке эмулятора на этой же системе.

Вот такую информацию я собрал. Надеюсь, поможет в размышлениях.

[HPDX2300]

Linux Mint 20 Cinnamon - читай "Дебиан" Поставил четыре последних релиза платформы 15.1985, 16.1502, 17.1549, 18.891 Из всех четырех платформ нормально работает только 8.3.15.1985 Остальные крашатся через 3-5 минут без вывода какой-либо информации на экран или в лог. Просто закрываются и всё.

вот что меня смущает - чел работает на CentOS-7 и у него "поведение" платформы правильное - падение "с визгом":

Настроил работу эмулятора на CentOS 7 ... стал ловить "нарушение целостности"

а у тебя на Минте падение молча, по-самурайски (и в dmesg ничё нет?). Elmachoe пишет про попытку изменения имени компа (на линуксе не помогает), значит он работал с 16, 17, или 18-ой (третья цифирь релиза) поделкой.

[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 - авось там падение будет с воплями, как у порядочных людей :-)

[Elmachoe]

давай попробуем собрать побольше инфы - включим техн.журнал и дождемся краха.
собирать техн. журналы надо и на стороне клиента, и на стороне сервера кластера т.к. модуль rserver, обнаружив эмуль и/или корп-патч,

С удовольствием соберу, только снёс я CentOS с машины полностью, для чистоты эксперимента подниму в ближайшее время с нуля систему и платформу накачу. Прочитал еще в этой ветке что файловую EXT4 лучше использовать и HASP от Senintela ставить, вместо Ethersoft. Или наоборот?
Еще поднял рядом в сети на Виндоуз менеджер лицензий, который успешно выдает лицензии, сперва по нему проверю на CentOS, чтобы исключить возможные косяки при установке платформы, думаю может зависимости не встали у меня нормально может.
Платформа 64разрядная, последний релиз 8.3.17.1549, чистая, с 1С скаченная.

[redhat2020]

я тут изучаю uni-patch для линуксовых backbas.so (1c8_uni2patch_lin, 1c8_uni2patch_win.exe), пропатчил 12-ое изделие, бегло проанализировал изменения в файле backbas.so - внедряемый кусок исполняемого кода идентичен тому, который внедряется в виндовый backbas.dll. И это радует - ибо дает надежду "сваять" новый uni-patch для 64-битных линуксовых backbas.so, примерно так как это делает uni-patch с backbas.dll. Понаблюдал в "Process Monitor" за тем, как rbc_icp.exe патчит backbas.dll: он извлекает из своего нутра 1c8_UP.exe и натравливает его на backbas.dll, потом грохает 1c8_UP.exe.

[A_vega]

Вы собираетесь увидеть ключи от usbhaspd, установленного в хост системе, изнутри контейнера?

Да. Потому что не удалось установить в контейнере модули ядра.

[Kellendr]

Да. Потому что не удалось установить в контейнере модули ядра.

Ну это решаемо, у меня получилось все это счастье запаковать в контейнеры, при чем я сделал Compose след вида:
1) Раздача лицензий платформы
2) Сервер 1С
3) Postgress
4) Сервер лицензирования конфигураций
5) OpenVPN (Для внешних пользователей)
И после некоторой подготовки ОС все работает кроме свойств информ. баз в диспетчере администрирования 1С. (Проблема как у zardoz)
Если у кого есть идеи как заставить сервер видеть серверную лицензию из соседнего контейнера, было бы интересно проверить (если объединить контейнер с сервером и эмулятором то все ок)

[CDGR]

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

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

[artem.ks]

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

[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-

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