curl: (58) unable to set private key
Warning: Problem (retrying all errors). Will retry in 1 seconds. 8 retries
Warning: left.
curl: (58) unable to set private key
Warning: Problem (retrying all errors). Will retry in 1 seconds. 7 retries
Warning: left.
curl: (58) unable to set private key
Warning: Problem (retrying all errors). Will retry in 1 seconds. 6 retries
Warning: left.
Возможно проблема связана с заменой контроллера? У меня был старый контроллер подключенный к облаку. Его заменили на новый по гарантии. Все настройки были перенесены на новый согласно официальной инструкции. Возможно, сертификат на новом повредился после переноса настроек?
попробуйте сначала сделать
проверить дату и время на контроллере
apt update ; apt -y upgrade
Затем перезагрузить контроллер
Проверить дату и время на контроллере
Вот тут лучше подробней что за “официальная” инструкция? Если имеется в виду восстановление из бэкапа - то она не предназначена для восстановления на дроугой контроллер.
Ну и настройки соединения с облаком - индивидуальны для каждого контроллера.
То есть:
Jan 10 19:06:16 wirenboard-AKWGH45O wb-cloud-agent[12869]: RuntimeError: Cert /var/lib/wb-cloud-agent/device_bundle.crt.pem and key ATECCx08:00:02:C0:00 seem to be inconsistent (possibly because of CPU board missmatch)!
говорит о попытке подключения с другими данными.
Рекомендую удалить провайдера и снова его добавить, это должно помочь.
root@wirenboard-AKWGH45O:~# wb-cloud-agent del-provider wirenboard.cloud
Warning: The controller on the remote server could not be detached due to network problems.
Unbind it manually using the command: 'wb-cloud-agent cloud-unbind https://wirenboard.cloud'
Provider wirenboard.cloud successfully deleted
root@wirenboard-AKWGH45O:~# wb-cloud-agent cloud-unbind https://wirenboard.cloud
Warning: The controller on the remote server could not be detached due to network problems.
Unbind it manually using the command: 'wb-cloud-agent cloud-unbind https://wirenboard.cloud'
root@wirenboard-AKWGH45O:~# wb-cloud-agent
No one provider was found
root@wirenboard-AKWGH45O:~# wb-cloud-agent add-provider https://wirenboard.cloud
Provider wirenboard.cloud successfully added
root@wirenboard-AKWGH45O:~# wb-cloud-agent
| Provider | Controller Url / Activation Url |
|------------------|-----------------------------------------|
| wirenboard.cloud | No connect to: https://wirenboard.cloud |
wb-cloud-agent последней версии (apt-get update/upgrade запускал)
Попробовал аналогичное (загрузить конфиги с другого контроллера).
Что-то простого способа не вижу. Проще, скорее всего сделать сброс и включить контроллер в облако штатным методом. Ну и восстановить (нужные) конфиги из бэкапа.
Не совсем правильный подход, лучше “восстановить” только нужные.
То есть вот из списка сервисов взять то что настроено,используется и только эти конфиги скопировать.
Думаю, проще все-таки исключить только те, которые заведомо содержат настройки специфичные для конкретного экземпляра контроллера.
У меня в целом все работает после переноса конфигов, проблема возникла только с облачным сервисом.
А почему бы его не делать с именем соответствующим оригинальному номеру контроллера?
Тогда при восстановлении таким образом перезатираться сертификат не будет …
При создании симлинков по идее должен проверить валидность сертификата …
И вообще. Замена контроллера не такая “редкая” операция. Контроллер по идее должен восстанавливаться в идеале “одной кнопкой” (из облака или со флешки …). Имхо
Контроллер - это набор произвольного количества сервисов. То есть они не может быть дополнительное ПО. Плюс - провайдеров облачных может быть больше одного и “стандартного” может не быть вообще.
То есть это конечно хорошо бы, но задача уровня “сделать бэкап-восстановление сервера” который сконфигурирован неизвестно как.
Это даже в большом IT не реализовано.
Задача “вышел из строя сервер - нужно срочно заменить (при этом железо будет отличаться)” реализована и прекрасно работает.
Бэкап запросто разворачивается … в том числе с восстановлением МАС адресов …
По опыту из сложностей это драйвера жесткого диска (при этом решается и разными путями - я рекомендую устанавливать все драйвера такие на все целевые серверы чтобы попадало в бэкап …) + сетевые карты (они могут быть совсем другими … но по факту нужно только сопоставить (тут я предпочитаю руками - но можно и автоматически)
В вашем случае обоих проблем нет.
Также вы можете делать бэкап и восстановление только “вашего” и “поддерживаемого” (это будет “понятное” ограничение)
Но согласен что это отдельная и не такая простая задача (как “кажется”). Но бэкап и восстановление вы уже начали делать.
Учитывая что контроллер это “обычный ПК” на “обычном линуксе” (но очень устаревшем и большей частью не поддерживаемый и с кучей уязвимостей из-за этого) думаю использовать “стандартные” средства восстановления … и бэкапа дополнительно у себя.
но вот особенности с аппаратным шифрованием … и может что еще … нужно обрабатывать по “особому”
Да, все это возможно.
Но - это довольно большая работа.
Как делаю я: Зная, что именно у меня на каждом контроллере сконфигурировано и используется (вот прямо в описании контроллера в проекте список сервисов) просчто беру их конфиги. Все.
.