Обновление и настройка WD MyBook Live и MyBook Live Duo

Так получилось, что я много писал про свой Seagate Wireless Plus, в частности, про то, как я над ним измывался, добавляя всяческие фичи. Но, исторически, первыми моими устройствами, на которых был установлен урезанный, но Linux, были два диска от Western Digital.

Первым появился MyBook Live. Это была модель на два терабайта. Я сразу перегнал на нее имеющийся у меня архив фильмов и музыки и, видимо, именно из-за этого, не пришлось долго ждать момента, когда диск заполнится полностью. Правда, незадолго до того, как это произошло, я разжился вторым диском от WD.

На этот раз, это была модель с двумя дисками, из-за чего, в полном названии, появилось слово Duo - MyBook Live Duo. Мое устройство было снабжено двумя дисками по два терабайта каждый, предоставляя, таким образом, до четырех терабайт. Почему я использовал слово "до"? Потому, что устройство может работать в двух режимах: в одном - представляя два диска, как один большой, а в другом - зеркалируя диски.

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

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

Мой ветеран WD MyBook Live

Оба устройства работают у меня уже довольно давно, о чем можно судить по картинке: 23 464 часов работы - это почти 978 дней, но, конечно, до трех лет не дотягивает. Оба служат в качестве домашнего хранилища чего угодно: фильмов, сериалов, музыки, книг, софта. Так почему же я про них ничего не писал?

 

Основная причина заключается в том, что по этим устройствам есть хорошее и живое, до сих пор еще, сообщество пользователей. На практически любой возникавший у меня вопрос я находил ответ. Например, захотел я поставить на оба устройства midnight commander - пожалуйста, нет проблем. Хотите, чтобы они использовались в качестве качалки торрентов - да пожалуйста. Есть даже руководство, как установить на устройство более свежую версию Linux и пользоваться ею при помощи chroot. Также, есть и поддерживается альтернативная прошивка. Есть очень неплохой FAQ. Не буду скрывать, часть этих ответов даже легло в основу моих экспериментов с диском Seagate. Но сейчас не об этом.

 

Собственно, то, что я решил сейчас написать об этих устройствах даже не сильно то и связанно с самими устройствами. Скорее, причина завязана на Linux, и на мое слабое его знание. А так как одной из задач этого блога (важнейшей, если не единственной) является служение в качестве шпаргалки и напоминалки мне, любимому (или, бестолковому?), о возникавших когда либо проблемах и методах их преодоления, то эта запись и родилась. Итак, вот хронология событий.

 

Довольно долгое время для данных устройств прилетали обновления. Прилетали они с завидным постоянством и периодичностью. Естественно, чем дальше, тем реже это происходило. Не хочу врать и называть какую-то цифру, но последние обновки приходили довольно давно. За это время я установил, для своего удобства, на обоих устройствах midnight commander и жил - не тужил. 

Но, на позапрошлых выходных, неожиданно, пришло оповещение о том, что есть новые версии прошивки. Почитал внимательно, что поправили. Вроде, ничего особенного, в принципе, можно и не обновляться. Терпел, наверное, дня три, потом, все таки, не выдержал - решил, что, для порядка, буду обновляться. Так как кроме midnight commander-а на устройствах больше ничего установлено не было, посчитал, что не буду делать копию каталога opt - кроме этого каталога надо будет сохранить еще пару-тройку файлов конфигурации, потом все это восстанавливать по разным каталогам... Так что, подумалось, что проще будет установить все (midnight commander) заново, плюс, надо, все таки, заставить себя, на будущее, написать командные файлы для сохранения и восстановления состояния устройств.

Сказано - сделано. Тяжело вздохнув, запустил процессы обновления на обоих устройствах, и, через минут десять, выполнял последовательность шагов по установке и настройке midnight commander-а на одном из них - на MyBook Live Duo. На втором, вернее, на первом, простом MyBook Live, обновление устанавливаться отказалось, сославшись на малое количество свободного места на диске. Во как я плотненько забил-то его! Ладно, не проблема, перенесу при помощи midnight commandera какие-нибудь фильмы на двухдисковое устройство, освободив несколько гигов, и повторю попытку.

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

Я зашел по SSH на MyBook Live, чтобы посмотреть, сколько места есть на нем. Запустил mc (midnight commander),  убедился, что свободно порядка двухсот мегабайт, и тут же решил перенести парочку фильмов на MyBook Live Duo. Midnight Commander уже запущен, поэтому пытаюсь в одной из панелей открыть удаленное устройство. Ведь делал это множество раз, а сейчас - ну никак не соединяется, пишет, что невозможно подключиться, и все тут. 

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

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Please contact your system administrator.
Add correct host key in ~/.ssh/known_hosts to get rid of this message.
Offending key in ~/.ssh/known_hosts: N
Permission denied (publickey,password).

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

Ну конечно! А чего, собственно, я ждал? Ведь я только что установил на том устройстве, к которому собирался подключиться, новую прошивку. Конечно, там все поменялось, а локальное устройство "помнит" параметры старой прошивки, вот конфликт и возникает.

Теперь разрешить проблему не должно составить труда. В приведенном сообщении имеется отсылка к файлу и номеру строки в этом файле, которые отвечают за эту неправильную  "память", достаточно внимательно прочитать предпоследнюю строку приведенного примера текста. Я специально изменил номер строки на "N", так как он будет отличаться для каждого конкретного случая. Для меня, например, это была двойка (2). Таким образом, все что нужно сделать, каким-то образом удалить из указанного файла строку с нужным номером.

Когда я заглянул в файл known_hosts, то понял, почему так важен номер строки: вся информация зашифрована. Но, к счастью, все равно, в текстовом виде. Так что, удалить строчку можно любым текстовым редактором, главное, не ошибиться с номером строки. Если же переживаете за свою аккуратность, внимательность, или, как я, сомневаетесь, начинать отсчитывать строки с первой или с нулевой (ну, кто тут программист?), можете воспользоваться средствами, предоставляемыми Linux. Я, например, так и поступил - воспользовался командой sed:

sed -i '2d'

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

После проделанной операции, попытка подключиться с помощью ssh прошла по сценарию, характерному для самого первого подключения к новому хосту: меня спросили, доверяю ли я ему, предупредили о грозящих опасностях, после чего допустили до ввода имени и пароля. В общем, все прошло удачно... Кроме того, ради чего я, собственно, и затеял всю эту канитель - скопировать файлы на удаленное устройство я не сумел, все из-за той ошибки, которую уже как-то описывал. Тогда я эмпирически вычислил, что могу безошибочно копировать при помощи mc любой объем информации с удаленного устройства на локальное, но не наоборот. Что ж, память надо тренировать...

Вроде, можно и заканчивать писать о том, что и так всем известно, кроме меня. Но в завершении... Когда, после всех действий по обновлению прошивок, установок и настроек mc и ssh, я попытался подключиться к устройству WD из ssh консоли своего WiFi диска Seagate, я знал, что получу ошибку, но мне нужен был номер строки, которую надо будет удалить из файла known_hosts. И что же я увидел? Правильно, сообщение об ошибке, но, немного не то, которое ожидал:

ssh: connection to user@host:port exited:
Host key mismatch for host !
Fingerprint is md5 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Expected md5 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
If you know that the host key is correct you can
remove the bad entry from ~/.ssh/known_hosts

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

Объясняется это различие, видимо, другим, более глубинным, что ли, различием - на устройствах стоят разные shell и разные клиенты и серверы ssh. На Seagate Wireless Plus в качестве ssh клиента используется dropbear, который, наверное, имеет свое мнение о том, как должен быть организован файл known_hosts. Хотя, может, это опять сказывается недостаток знаний у меня, и dropbear можно настроить на шифрование имен хостов, и тогда сообщение примет другой вид? Не знаю, возможно. Углубление своих знаний в этом направлении я решил чуть-чуть отложить...