Обновление УТМ 1.0.15 [Тестовый контур]

[pantonov]

Сегодня тестовый УТМ обновился с версии 1.0.14b000957 до версии 1.0.15b001001. После этого перестала стартовать служба транспорта. В логах:

2016-12-26 15:14:46,026 INFO es.programador.transport.Transport - Загрузка конфигурации
2016-12-26 15:14:46,086 INFO es.programador.transport.a.a - Загрузка файла настроек: C:\TT6\transporter\conf\transport.properties
2016-12-26 15:14:46,096 INFO es.programador.transport.a.a - Периодичность перезагрузки настроек выставлена в 10001 мс
2016-12-26 15:14:46,230 INFO es.programador.transport.Transport - Чтение конфигурации
2016-12-26 15:14:46,421 INFO es.programador.transport.l - Проверка состояния Transport Updater
2016-12-26 15:14:46,485 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]
2016-12-26 15:14:46,486 WARN es.programador.transport.l - Версия Transport Updater имеет невалидное значение: устарело.
2016-12-26 15:14:46,487 INFO es.programador.transport.Transport - Повторная проверка начнется через [60] сек.
2016-12-26 15:15:46,489 INFO es.programador.transport.l - Проверка состояния Transport Updater
2016-12-26 15:15:46,549 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]
2016-12-26 15:15:46,550 WARN es.programador.transport.l - Версия Transport Updater имеет невалидное значение: устарело.
2016-12-26 15:15:46,550 INFO es.programador.transport.Transport - Завершение работы

Как с этим бороться?

[QuiteOldOrange]

2016-12-26 15:14:46,485 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]
...
2016-12-26 15:15:46,549 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]

Ткну пальцем в небо, предположив что у вас в папке с УТМ стоит солянка из разных версий(2.0.2). Думаю как в большинстве непонятных ситуаций - самое действенное это переустановка УТМ.

[Operator 4]

Сегодня тестовый УТМ обновился с версии 1.0.14b000957 до версии 1.0.15b001001. После этого перестала стартовать служба транспорта. В логах:

2016-12-26 15:14:46,026 INFO es.programador.transport.Transport - Загрузка конфигурации
2016-12-26 15:14:46,086 INFO es.programador.transport.a.a - Загрузка файла настроек: C:\TT6\transporter\conf\transport.properties
2016-12-26 15:14:46,096 INFO es.programador.transport.a.a - Периодичность перезагрузки настроек выставлена в 10001 мс
2016-12-26 15:14:46,230 INFO es.programador.transport.Transport - Чтение конфигурации
2016-12-26 15:14:46,421 INFO es.programador.transport.l - Проверка состояния Transport Updater
2016-12-26 15:14:46,485 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]
2016-12-26 15:14:46,486 WARN es.programador.transport.l - Версия Transport Updater имеет невалидное значение: устарело.
2016-12-26 15:14:46,487 INFO es.programador.transport.Transport - Повторная проверка начнется через [60] сек.
2016-12-26 15:15:46,489 INFO es.programador.transport.l - Проверка состояния Transport Updater
2016-12-26 15:15:46,549 INFO es.programador.transport.l - Версия Transport-Updater: [2.0.2b000127]
2016-12-26 15:15:46,550 WARN es.programador.transport.l - Версия Transport Updater имеет невалидное значение: устарело.
2016-12-26 15:15:46,550 INFO es.programador.transport.Transport - Завершение работы

Как с этим бороться?

Можете целиком папку l приложить?

[pantonov]

Можете целиком папку l приложить?

Я уже удалил старый УТМ и установил новый.
Теперь падает ошибка

2016-12-26 17:14:59,913 DEBUG es.programador.transport.a.b - Ошибка получения PKCS11
2016-12-26 17:14:59,916 ERROR es.programador.transport.updater.h - Ошибка запуска системы обновления
java.lang.IllegalStateException: java.io.IOException: load failed
at es.programador.transport.a.b.b(Unknown Source)
at es.programador.transport.updater.Main.a(Unknown Source)
at es.programador.transport.updater.Main.main(Unknown Source)
Caused by: java.io.IOException: load failed
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:763)
at java.security.KeyStore.load(Unknown Source)
... 3 more
Caused by: javax.security.auth.login.FailedLoginException
at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1234)
at sun.security.pkcs11.P11KeyStore.login(P11KeyStore.java:849)
at sun.security.pkcs11.P11KeyStore.engineLoad(P11KeyStore.java:753)
... 4 more
Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_PIN_INCORRECT
at sun.security.pkcs11.wrapper.PKCS11.C_Login(Native Method)
at sun.security.pkcs11.SunPKCS11.login(SunPKCS11.java:1222)
... 6 more
2016-12-26 17:14:59,946 INFO es.programador.transport.updater.h - Завершение работы (ShutdownHook)
2016-12-26 17:14:59,946 DEBUG es.programador.transport.updater.h - Остановка работы с RSA-криптографией
2016-12-26 17:14:59,947 INFO es.programador.transport.a.b - Начало вызова методов финализации
2016-12-26 17:14:59,947 INFO es.programador.transport.a.b - Используется библиотека от ЦентрИнформ
2016-12-26 17:15:00,448 INFO es.programador.transport.a.b - Завершение вызова методов финализации

[QuiteOldOrange]

Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_PIN_INCORRECT

Либо у вас нестандартный пин, либо помирающий ключ(по крайней мере у меня на практике такие внезапные ошибки с пинкодом означали).

Кстати, уважаемый оператор! Центринформ какие нибудь исследования проблемы "помирающих джакарт" проводил\проводит? Мы от нее когда нибудь избавимся или так и будем с этим жить и терять часть данных в системе? У некоторых организаций под моим присмотром так 800 чеков не ушло за пару месяцев, потому что ключ полудохлый и УТМ внутри крешился с исключениями и не мог их отослать, перезапись ключа вроде бы помогла, но руки не дошли допроверить. Мы с руководителем хотим уже даже провести исследование - собрать тестовый стенд и дописать 1Ску чтобы та автоматически отправляла чеки каждую минуту, и посмотреть на чем ключи(УТМ на windows,УТМ на linux, или УТМ-хаб) помрут быстрей или не помрут - кто нибудь подобные нагрузочные тесты ключей проводил, есть ли смысл?

И по поводу моей проблемы с непониманием документации к последнему УТМ - предлагаю поставить вопрос так: прошу привести пример на любом языке программирования как отправлять чек в новой схеме обработки чеков, с точки зрения именно программного кода, пример должен заведомо быть рабочий - достаточно ту часть где сформирован XML документ чека и производится отправка, печать на фискальном регистраторе и действия учетной системы для ясности можно отобразить псевдокодом. Чтобы в случае чего этому коду можно было скормить настоящие данные и он их правильно вышлет в УТМ.

Язык еще раз повторюсь не важен - C,C++,java,C#,delphi,pascal, что угодно, даже функциональные типа лиспа и эзотерические подойдут - если понадобится то пару дней поизучаю синтаксис языка. Но 1С, C#,C,C++ предпочтительней.

[Operator 4]

Подскажите, у Вас установлена версия 1.0.15? Вы наблюдаете подобную проблему?

Я тестировал на версии 1.0.14, документация по 15-й версии в этом плане не поменялась поэтому думаю что и для этой версии тоже актуален вопрос. Сейчас у меня сложности с тестовым токеном, поэтому пока я временно отошел от этого дела.

Проблемы как таковой на практике пока нет - она кроется в неполной документации к УТМ - упоминается механизм
что "если УТМ потеряет соединение с кассой то он отменит отправку чека", при этом что конкретно подразумевается под соединением - нигде не сказано. В текущей ситуации на моем тестовом компьютере новая схема обработки чеков на старой 1С-ке работает вполне нормально, но я на 100% уверен что это из-за того что мой компьютер достаточно быстродействующий чтобы УТМ успел отправить данные до того как 1С разорвет соединение с ним. Если под там соединением понимается все таки имеется ввиду открытый сокет, то проблемы начинаются в тот момент когда мы на стороне 1С захотим этот сокет держать открытым - там нельзя явно управлять этим - сокет открывает в момент отправки запроса к УТМ, и закрывается в тот момент когда срабатывает сборщик мусора(проверял утилитами мониторинга сети). Поэтому если механизм в таком виде попадет в рабочий контур, то пользователи 1С начнут по неволе играть в "русскую рулетку" - у кого то УТМ успеет отправить чек, у кого то нет.

Поэтому, для решения этой проблемы считаю нужным:
а) Подробно объяснить в документации что подразумевается под соединением между УТМ и кассой.
б) Если мои догадки верны - то переделать механизм проверки соединения на механизм команд транзакций, как более универсальный и простой.

Для анализа нужен конкретный пример с полным описанием проблемы.
И, прошу заметить, что на данном форуме Вам отвечает поддержка, поэтому примеров кода не будет.

[Operator 4]

Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_PIN_INCORRECT

Либо у вас нестандартный пин, либо помирающий ключ(по крайней мере у меня на практике такие внезапные ошибки с пинкодом означали).

Кстати, уважаемый оператор! Центринформ какие нибудь исследования проблемы "помирающих джакарт" проводил\проводит? Мы от нее когда нибудь избавимся или так и будем с этим жить и терять часть данных в системе? У некоторых организаций под моим присмотром так 800 чеков не ушло за пару месяцев, потому что ключ полудохлый и УТМ внутри крешился с исключениями и не мог их отослать, перезапись ключа вроде бы помогла, но руки не дошли допроверить. Мы с руководителем хотим уже даже провести исследование - собрать тестовый стенд и дописать 1Ску чтобы та автоматически отправляла чеки каждую минуту, и посмотреть на чем ключи(УТМ на windows,УТМ на linux, или УТМ-хаб) помрут быстрей или не помрут - кто нибудь подобные нагрузочные тесты ключей проводил, есть ли смысл?

И по поводу моей проблемы с непониманием документации к последнему УТМ - предлагаю поставить вопрос так: прошу привести пример на любом языке программирования как отправлять чек в новой схеме обработки чеков, с точки зрения именно программного кода, пример должен заведомо быть рабочий - достаточно ту часть где сформирован XML документ чека и производится отправка, печать на фискальном регистраторе и действия учетной системы для ясности можно отобразить псевдокодом. Чтобы в случае чего этому коду можно было скормить настоящие данные и он их правильно вышлет в УТМ.

Язык еще раз повторюсь не важен - C,C++,java,C#,delphi,pascal, что угодно, даже функциональные типа лиспа и эзотерические подойдут - если понадобится то пару дней поизучаю синтаксис языка. Но 1С, C#,C,C++ предпочтительней.

По вопросам ключей в этой теме не буду ничего отвечать, так как в нулевом посте написано, что тема для обсуждения обновления на 1.0.15. Воспользуйтесь поиском по форуму. Вот, например.

[QuiteOldOrange]

Для анализа нужен конкретный пример с полным описанием проблемы.
И, прошу заметить, что на данном форуме Вам отвечает поддержка, поэтому примеров кода не будет.

Еще раз повторяюсь - конкретного примера пока нет. Проблема в поверхностном описании схемы обработки чеков в документации, и если копать глубже и выдвигать теории - то новую схему обработки чеков невозможно будет правильно реализовать в учетных системах на платформе 1С. Поэтому нужно подробное описание схемы, с точки зрения программного кода и опровержение\подтверждение моей теории и в случае подтверждения - поиск решения проблемы поддержки соединения.

Касаемо примеров кода - очень жаль, тогда вопрос перетекает в такой - кто может привести примеры кода? С разработчиками УТМ более-менее прямые каналы связи есть, на каких форумах их искать?

По вопросам ключей в этой теме не буду ничего отвечать, так как в нулевом посте написано, что тема для обсуждения обновления на 1.0.15. Воспользуйтесь поиском по форуму. Вот, например.

Я поискал по сайту алладина в поисках рекомендаций, но в итоге нашел вот тут - http://www.aladdin-rd.ru/support/forum/ ... essage6813 сообщение относительно свежее и там камни в огород центринформа:

УТМ написан на коленках и элемантарной защиты "от дурака" нет!!! Он вместо того чтоб
остановиться при сбое, переспросить и т.п. прсото долбит как дятел ключ и тем самым ведёт себя как нарушитель который якобы подбирает пароль...
А ключ SE (мы про него говорим) выполняет то что ГОСТ требовал и "умные" ФСБшники требовали (лучше бы проверили как УТМ коряво написан, типа серьёзная система а на батниках работает...) - и как итог блокирует зловреда.

Ну вот интересно насколько прав человек и если он прав - насколько эта проблема будет актуальная для версии 1.0.15 - какие нибудь работы по оптимизации работы УТМ с ключом в этой части велись? В злосчастной новой документации например это не упоминается, но вдруг там забыли написать?

[Operator 4]

Для анализа нужен конкретный пример с полным описанием проблемы.
И, прошу заметить, что на данном форуме Вам отвечает поддержка, поэтому примеров кода не будет.

Еще раз повторяюсь - конкретного примера пока нет. Проблема в поверхностном описании схемы обработки чеков в документации, и если копать глубже и выдвигать теории - то новую схему обработки чеков невозможно будет правильно реализовать в учетных системах на платформе 1С. Поэтому нужно подробное описание схемы, с точки зрения программного кода и опровержение\подтверждение моей теории и в случае подтверждения - поиск решения проблемы поддержки соединения.

Касаемо примеров кода - очень жаль, тогда вопрос перетекает в такой - кто может привести примеры кода? С разработчиками УТМ более-менее прямые каналы связи есть, на каких форумах их искать?

По вопросам ключей в этой теме не буду ничего отвечать, так как в нулевом посте написано, что тема для обсуждения обновления на 1.0.15. Воспользуйтесь поиском по форуму. Вот, например.

Я поискал по сайту алладина в поисках рекомендаций, но в итоге нашел вот тут - http://www.aladdin-rd.ru/support/forum/ ... essage6813 сообщение относительно свежее и там камни в огород центринформа:

УТМ написан на коленках и элемантарной защиты "от дурака" нет!!! Он вместо того чтоб
остановиться при сбое, переспросить и т.п. прсото долбит как дятел ключ и тем самым ведёт себя как нарушитель который якобы подбирает пароль...
А ключ SE (мы про него говорим) выполняет то что ГОСТ требовал и "умные" ФСБшники требовали (лучше бы проверили как УТМ коряво написан, типа серьёзная система а на батниках работает...) - и как итог блокирует зловреда.

Ну вот интересно насколько прав человек и если он прав - насколько эта проблема будет актуальная для версии 1.0.15 - какие нибудь работы по оптимизации работы УТМ с ключом в этой части велись? В злосчастной новой документации например это не упоминается, но вдруг там забыли написать?

Вот Вы говорите "я ничего не ставил и не пробовал, но я ПРЕДПОЛАГАЮ". А я прошу Вас привести реальный пример с полным описанием проблемы. Если Вы пример происходящего с установленным 1.0.15 УТМ приведёте, то я разработчикам передам, если проблема действительно имеет место быть.
Остальные вопросы даже комментировать не буду, только скажу, что будет выдано предупреждение, если будет продолжаться обсуждение ключей в этой теме.

[QuiteOldOrange]

Вот Вы говорите "я ничего не ставил и не пробовал, но я ПРЕДПОЛАГАЮ". А я прошу Вас привести реальный пример с полным описанием проблемы. Если Вы пример происходящего с установленным 1.0.15 УТМ приведёте, то я разработчикам передам, если проблема действительно имеет место быть.
Остальные вопросы даже комментировать не буду, только скажу, что будет выдано предупреждение, если будет продолжаться обсуждение ключей в этой теме.

Еще раз повторяю - проблема в неполной документации, из нее уже растет мое предположение - это второй вопрос. Если мы найдем с вами ответ на первый вопрос, предположение либо отпадет само - я не исключаю вариант что я с ним не прав, либо я смогу тогда предоставить конкретный пример. Сейчас главная проблема - неполная документация к УТМ.