Wirenboard 5 в работе на удаленном объекте с конца 2019г.
Питание бесперебойное, не пропадало.
В один момент заметили, что перестали обрабатываться правила. (Вкл/откл камина)
Управление вручную через веб интерфейс работает.
На странице с правилами ошибка.
Подключиться через тфтп не удается.
Такое чувство, что сдохла база данных, но иногда правила могут и начать обрабатываться на некоторое время.
Прошу подсказать, как реанимировать устройство, при попадании на объект.
А работает ли wb-rules?
TFTP на контроллере не стоит по умолчанию.
А что в логах контроллера?
Здравствуйте ещё раз.
Ошибочно описал способ подключения - извиняюсь.
Раньше подключались ко всем контроллерам через WinSCP по протоколу SFTP. Сейчас этот способ не работает.
Движок правил работает, но не видит сами правила.
Сегодня попробую подключиться через консоль. Скажите пожалуйста, каким образом предоставить дополнительную информацию.
Дополнено: ssh доступ тоже не функционирует, хотя контроллер пингуется, веб морда работает.
Что можно сделать через неё?
Проверил историю, данные также перестали сохраняться с определенной даты.
Это немного взаимоисключающие утверждения.
Логи, можно сюда файлами.
если ssh не работал бы - то сработал watchdog. А как именно “не функционирует”? Не отвечает на своем порту?
Чепрез веб-интерфейс - только собрать диагностическую информацию.
Вообще адо смотреть на доступное место на разделах.
“Движок правил работает, но не видит сами правила.” -
речь о том, что когда в разделе скриптов отображаются составленные ранее правила, то они исполняются и все работает. Когда при попытке открыть этот раздел отображается ошибка - то правила не видны, они не работают. Контроллер при этом не перегружается. Т.е. он может в определенный момент времени ожить, отображать все составленные ранее правила и начать работать, как раньше, но этот промежуток очень мал. Поймать это время и попытаться подключиться к нему не удается.
Перезагрузка ничего не меняет.
“Дополнено: ssh доступ тоже не функционирует, хотя контроллер пингуется, веб морда работает.” -
Речь о том, что подключение через putty по протоколу ssh установить не удается.
Обычное предложение с вводом логина \ пароля не отображается.
Каким образом можно предоставить логи, если к контроллеру не удается подключиться через ssh или sftp ?
К вопросу о свободном месте -
Эксплуатируется несколько контроллеров, настроенных одинаково по шаблону (не нами). У всех стоит принудительная очистка истории и логов по достижению определенного размера.
Завтра попытаюсь добраться до объекта физически и если удастся подключиться напрямую. Можно ли каким-то образом переписать на него прошивку или базу данных с аналогичного работающего контроллера?
P.S. мы не являемся специалистами по автоматизации и Linux, контроллеры используются для надзора за состоянием помещений, где установлено эксплуатируемое нами оборудование, так что прошу извинить за дилетантские вопросы.
Я предположил, что файловая система наелась, но, раз машинка грузится, значит, хотя бы корневая жива. Усб в отладочный порт, сохранять, что удастся вытащить. Потом разбираться.
1 лайк
Побывал на объекте. Попытки подключиться к блоку напрямую результата не дали.
Команда перезагрузки через веб интерфейс визуально отрабатывала, но ничего не менялось.
Перезагрузил по питанию и как ни странно всё заработало. Что это могло быть?
Теперь главный вопрос, как скопировать всё с блока, чтобы при его окончательной кончине можно было перенести всю конфигурацию на другой блок ?
Попытки в лоб слить все файлы через winSCP завершились неудачей. Часть файлов не копируется.
Я бы не использовал для работы с контроллером любой софт в названии которого есть win. Просто потому что настроить так, чтобы корректно отрабатывали симлинки, права - тоже задача.
проще собрать все данные в архив прямо на контроллере и уже архив выкачать.
Если файловая жива. Я бы в текущем случае сильно побоялся на нее писать. Сильно.
Ну тут вроде профи собрались, какие к черту форточки. )
1 лайк
Не надо на сам контроллер. Подмонтировать что-то, воткнуть флешку.
Вот да. Если корневая цела, должно подхватить.
Спасибо большое за советы. Буду разбираться, как это сделать правильно. Направление понял.
К сожалению в связи с ситуацией в настоящий момент экспериментировать с оборудованием невозможно.
Но как только появится возможность продолжу попытки. Надеюсь, что блок доживёт до этого…
Если проблема не в ФС а в самом чипе EMMC - то на контроллер дйствует гарантия.
Проблема временно была решена внешним сторожевым независимым таймером, жестко передергивающим питание контроллера. Ситуация повторялась уже трижды. При этом все файлы после загрузки на месте и работоспособность восстанавливается в полном объеме.
Больше похоже на аппаратный глюк или наводки от других устройств, приводящие к такому ступору.
Как корректно перенести / сохранить копию контроллера для восстановления на аналогичном или более новом нам недопользователям Unixовых систем совершенно до сих пор непонятно.
Поиск по форуму показывает, что это проблема массовая и ее однозначного решения не существует, если пользователь не обладает глубокими познаниями в этой области.
Очень глубоких познаний и не нужно, достаточно скопировать конфигурационные файлы из /mnt/data/etc/ (если нет дополнительного ПО).
Вы писали
Конфиг /mnt/data/etc/wb-hardware.conf аппаратно зависим, его нельзя переносить между контроллерами разных версий. Модули проще настройить на контроллере вручную.
В нашем случае придется переносить конфигурацию на WB6, так как WB5 уже нет. Что необходимо дополнительно сделать в этом случае?
Ну и главный вопрос, какие именно команды необходимо выполнить , чтобы
Перенести конфигурацию следующим методом: tar cvzf /mnt/data и распаковать этот файл на другом WB.
Небольшая кнопка Backup/Restore в веб-интерфейсе для создания и выгрузки архива позволила бы решить множество ненужных вопросов от обычных пользователей.
Лучше всего именно wb-hardware.conf создать вручную.
Прочие конфиги - если версии ПО одинаковы - можно переносить.
Архив не нужен (хотя и проще всего), в общем случае, как именно копировать файлы неважно, можно и наприямую через scp.
1 лайк
Что-то перенести удалось предложенным способом.
Для тех, кто также как никогда не имел отношения к Debian:
-создание архива с настройками
cd /mnt/data
tar cvzf backup.tar.gz /mnt/data
-распаковка
tar xzvf backup.tar.gz
Модули ожидаемо не заработали.
Также на WB5 был отключен Wi-Fi с помощью указанного в Вики способа управления питанием порта. Соответственно на WB6 эта настройка не перенеслась и вероятно отключилось что-то другое…
Можно ли перенести каким-либо способом zabbix agent с его настройками ? К сожалению инструкции, как его установить из пакета без интернета не нашлось тут…
Модули - да, их проще и лучше сконфигурировать.
Настройки - в стандартном конфиге агента, это обычный .conf файл.
А “переносить бинарники” - нет.
В чем проблема просто его поставить?
Просто поставить - это и непонятно… Даже притащив контроллер и подключив его к точке доступа Wifi не удалось выполнить самый первый шаг инструкции
root@wirenboard-ANNI3HZE:~# apt-get install zabbix-agent -y
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package zabbix-agent
Аналогичный вопрос с тем, куда скопировать source файлы wb-mqtt-zabbix v0.2 для установки без интернета… Всего одна строчка из инструкции “Нужно поставить zabbix-agent:” вызывает ступор у человека, который не работал раньше в unix.
Интернет вроде при этом исправен
root@wirenboard-ANNI3HZE:~# ping ya.ru
PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=244 time=80.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=244 time=79.0 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=244 time=62.0 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=4 ttl=244 time=60.5 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=5 ttl=244 time=63.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=6 ttl=244 time=64.8 ms