Цитата: NGhost ➤ Вот в этом и проблема. Идея была в том, чтобы создать универсальный носитель (флешка, дискетка), с которым малоквалифицированный инженер тех. службы мог бы разъезжать по точкам и на месте заливать кассы. Лазить по этой флешке ему крайне не рекомендуется. При заливке 2 и более касс 1 IP для их загрузки использовать не удобно.
По дефолту если не выставлена переменная $IPADDRESS, скрипт установки вываливается в шелл, чем очень удивляет вышеупомянутого инженера тех. службы.
А зачем по флешке лазить-то? Один раз указал $IPADDRESS, по которому инсталлятор терминала заливает файлы, потом вбил другой IP адрес, по которому касса дальше будет работать - и дальше пошёл. Всё равно же ведь надо руками вбивать адрес. Тем более, что это не шелл, а самый, что ни на есть, интерактивный режим, только без рамок, кнопок и теней.
Цитата: NGhost ➤ Но разговор не об этом, предлагаю вернуться к изначальной теме.
На мой взгляд, наш спор про IP адрес как раз и свидетельствует в пользу того, что не стоит, наверное, вмешиваться в ОС и прочий функционал, не зная всех особенностей ОС и функционала кассовой системы: малая беда, если будет выполнена бесполезная работа, но гораздо большая беда, если эта работа ещё и негативно отразится на функционировании не только ПО, но и на корректном исполнении бизнес-процессов. Ещё один довод в пользу этого: линуксовый модуль sb_pilot СБРФ был готов ещё задолго до 44 версии, однако пока он не был оттестирован как следует, зелёный свет ему не давали. Потому что в таких вещах нужно до конца экспериментально удостовериться в том, что в результате любого сбоя система окажется устойчивой: деньги будут переведены куда следует, покупатель не окажется обманутым, а безопасность платежей не обнаружит уязвимостей. И даже после выхода 44й версии работу с модулем разработчики УКМ 4.0 продолжали шлифовать. Так что вот такое вот моё личное мнение.
А вот что бы я стал делать: простым копированием готовых исполняемых файлов или скриптов, запускаемых по cron или даже при помощи программ plink и pscp периодически мониторить жизненно важные компоненты системы, такие как, например, состояние жёсткого диска (smartctl) и лог MySQL на предмет наличия в нём ошибок. Ну или - максимум - простой скриптовый демон, который так же мониторил бы логи ukmclient'а, не отбирая для своей задачи ресурсов, ведь зачастую оборудованием кассовым располагаем не самым мощным... Для нашей сети магазинов я написал скрипт, который, подключившись к серверу, определит IP адреса касс магазина и в реальном времени откроет в PuTTY все их логи, буквально одним кликом мыши. По звонку из магазина я даже могу не спрашивать, на какой именно кассе проблема. Этот скрипт + средства мониторинга HDD S.M.A.R.T и MySQL = вполне достаточно для обеспечения стабильной работы касс и быстрой диагностики и решения проблем. Кроме того, начиная с 43й или 44й некоторые средства контроля ресурсов касс уже реализованы, а именно - на этапе загрузки кассы проверяется и ремонтируется БД, если касса перед этим выключалась "грубо", а также отключение автозапуска (ukmoff) ukmclient при циклическом reboot'е терминала вследствие фатальной ошибки 139 (чтобы можно было войти удалённо по SSH на терминал и произвести ремонтно-восстановительные работы). Эти две доработки были инициированы мною ещё в бытность руководителем группы внедрения УКМ 4.0 в С+. Вы же, по-момему, сервисная организация? Так обратитесь лучше в С+ с предложением о доработке, расскажите своё видение её решения, договоритесь с менеджерами о взаимовыгодном сотрудничестве, от этого должны только выиграть все! :drink_mini: