Нет нам покоя. После установки SSH сервера dropbear на Seagate Wireless Plus (SWP), работа с midnight commander на этом устройстве стала, безусловно, более удобной. Копирование, перемещение, переименование, редактирование файлов в mc, запущенном в ssh консоли, мышка, клавиши функциональные... И все это - нормально работает!
Помощь midnight commander в организации файлов на диске просто неоценима. Создать папку "Русский рок" и перетащить туда каталоги с альбомами "Альфа", "Динамик", "Стайер" - нет проблем, все быстро и замечательно. И для этого уже не нужно подключать SWP к USB порту, гася на время точку доступа - особенность SWP, а, может, и не только его одного - или соединение по USB, или работа с WiFi. Пока вы не выходите за границы устройства - проблем нет никаких. Но, хорошего понемножку. И этот момент настал. Я имею в виду тот момент, когда идиллия рушится.
Захотелось мне скопировать на устройство дискографию Джорджа Бенсона (George Benson). Я уже не помню, то ли с диска что-то использовалось по WiFi, то ли просто было лень лезть за USB шнуром, но я решил, что смогу сделать это в ssh консоли при помощи mc. Дело в том, что указанная дискография хранилась у меня на домашнем сетевом накопителе MyBook Live Duo. Поэтому я запустил Putty и подключился к SWP, и уже из консоли запустил mc. Пока все нормально, но это мы на исследованной территории, исхоженной вдоль и поперек. Посмотрим, что будет далее. Но сначала - небольшое и скучное отступление, за которое истинные фанаты Linux меня, в лучшем случае, просто станут игнорировать.
Захотелось мне скопировать на устройство дискографию Джорджа Бенсона (George Benson). Я уже не помню, то ли с диска что-то использовалось по WiFi, то ли просто было лень лезть за USB шнуром, но я решил, что смогу сделать это в ssh консоли при помощи mc. Дело в том, что указанная дискография хранилась у меня на домашнем сетевом накопителе MyBook Live Duo. Поэтому я запустил Putty и подключился к SWP, и уже из консоли запустил mc. Пока все нормально, но это мы на исследованной территории, исхоженной вдоль и поперек. Посмотрим, что будет далее. Но сначала - небольшое и скучное отступление, за которое истинные фанаты Linux меня, в лучшем случае, просто станут игнорировать.
Midnight commander обладает некоторыми способностями работать с удаленными компьютерами. Вот только эти способности сильно зависят от версии mc. Не будем забывать, что я имею дело с урезанными и довольно устаревшими версиями Linux. Как следствие, версии программ, устанавливаемые из дистрибутивов ipkg, тоже довольно старенькие.
Одной из многих замечательных черт Linux является то, что многое, очень многое, имеет исходные тексты, и, если ты крут, и можешь собрать из исходников нужное тебе ПО - все просто здорово. Надо отметить, что под словом собрать я понимаю не просто скомпилировать исходники, а заставить работать софт на нужном устройстве, то есть, скомпилировать, подобрать нужные версии библиотек, возможно, даже слегка попрограммировать. И вот тут я, увы, не крут - в мире Linux мне не хватает практических навыков, да и теоритических знаний тоже. А раз так, то мне остается только воспользоваться тем, что кто-то крутой собрал и подготовил для таких, как я. И сказать спасибо.
Пока у крутых парней есть интерес к определенным версиям Linux и определенным же устройствам, у ламеров нет проблем - более-менее свежие и актуальные версии прикладного ПО можно найти и использовать. Но время идет, устройства устаревают, новые версии Linux производители для них не адаптируют, прошивки от знатоков тоже перестают выходить, количество заинтересованных в портировании программ на эти платформы неуклонно снижается, пока, в какой-то момент, не достигает вполне ожидаемого минимума - нуля.
Никто больше, из продвинутых пользователей, более не заинтересован, или же, просто не нуждается в поддержании актуальных версий программ для этих, еще совсем недавно, топовых устройств. Да и усилий на это надо тратить все больше и больше. Ведь чем дальше уходит в своем развитии основная ОС и само прикладное ПО вместе с библиотеками, тем труднее становится заставить работать все это новое богатство на застывшей в прошлом программно-аппаратной платформе. Таков естественный ход развития событий.
Вот и получается, что, спустя некоторое время, обновлений становится все меньше, выходят они все реже, пока, в один прекрасный момент, не прекращаются вовсе. В результате, на устройствах (я имею в виду SWP и WD MyBook Live Duo) установлен mc версии 4.7.5.5-1 при готовящейся к выпуску версии 4.8.14.
Вот это да! Перечитал сейчас несколько предшествующих абзацев и понял, что уже писал такое в одном из предыдущих постов. Чтобы быть хоть чуточку оригинальным, добавлю немного нытья из другой оперы, но - на ту же тему, а именно, как трудно живётся Linux-овому ламеру. Готовы? Приступим.
Вот это да! Перечитал сейчас несколько предшествующих абзацев и понял, что уже писал такое в одном из предыдущих постов. Чтобы быть хоть чуточку оригинальным, добавлю немного нытья из другой оперы, но - на ту же тему, а именно, как трудно живётся Linux-овому ламеру. Готовы? Приступим.
Но и все выше сказанное - это еще не полная картина. На моих устройствах установлен разный Linux с разными shell, и так далее и тому подобное. Как следствие, даже одна и та же версия midnight commander работает на них по разному. Ну вот такой простой пример. На WD MyBook Live в качестве shell работает bash, а на SWP ash. Как результат, комбинация клашиш Ctrl-O (скрыть панели mc) работает на устройстве от WD, как ожидается - скрывает панели, давая доступ к командной строке и показывая содержимое консоли, а на SWP - просто показывает содержимое консоли, без доступа к командной строке.
Говорят, в некоторых версиях mc можно в панелях отображать и работать с содержимым SMB ресурсов удаленных компьютеров. Версия 4.7.5.5-1 этого не умеет. Она умеет работать с удаленными ресурсами по протоколу FTP и по некоему протоколу FISH. Протокол FISH, как утверждает Wikipedia, и был разработан специально для midnight commander.
Для работы с удаленными ресурсами по FTP протоколу нужен поднятый FTP сервер, которого на SWP нет. Хотя поднять его, в принципе, не сложно. Но это - теперь, когда получены кое-какие зачатки знаний. Для работы же по протоколу FISH достаточно иметь поднятый SSH сервер и несколько стандартных утилиток shell. Сервер SSH - dropbear - я на SWP уже поднял. На WD MyBook Live Duo SSH сервер тоже запущен. Так что, выбор протокола FISH для передачи файлов кажется вполне уместным и логичным.
Что ж, раз выбор сделан, приступим к копированию файлов. Соединяюсь по протоколу SSH с диском Seagate, запускаю midnight commander, и пытаюсь на одной из панелей открыть содержимое диска WD. В подсказках mc указан формат строки, которая должна определить, какой удаленный ресурс мы собираемся отобразить в панеле. Ничего сложного:
Я все так и указал, после чего сразу же получил сообщение об ошибке. На всякий случай еще раз сверился со справкой, опять вбил адрес в нужном формате, все перепроверил. Результат - все то же сообщение об ошибке.
username@hostipaddress:pathЯ все так и указал, после чего сразу же получил сообщение об ошибке. На всякий случай еще раз сверился со справкой, опять вбил адрес в нужном формате, все перепроверил. Результат - все то же сообщение об ошибке.
 |
| Таков результат попытки соединения |
Может, этот протокол вообще не работает? Есть только один способ проверить. Захожу по протоколу SSH в консоль диска от WD. Запускаю mc и пытаюсь отобразить на одной из панелей содержимое диска Seagate. Набираю адресную строку, жму Enter и ... О чудо, на одной панели содержимое MyBook, на другой - содержимое SWP.
То есть, протокол, все-таки, работает, но, как-то, выборочно: с устройства WD на диск Seagate попасть можно, а вот в другом направлении - проезд закрыт. Улица-то с односторонним движением! Скорее всего, тут в силу вступили те самые различия в наполнении устройств, о которых я говорил. Может быть, на SWP можно что-нибудь такое эдакое установить, и все заработает и с него. Но вот что? Эх, если б кто-нибудь подсказал... Решение этой задачки я все-таки нашёл, напишу о нем чуть позже. Сейчас же продолжу сказ о своих похождениях.
Ладно, нам ли, как говорится, быть в печали. Всем ведь известно, что от перемены мест слагаемых сумма не меняется. Что, находясь в консоли на SWP, копировать информацию с диска WD, что, находясь в консоли на MyBook Live, копировать файлы на диск Seagate... Разницы ведь никакой - в конце концов, дискография окажется на нужном мне устройстве, и я буду в счастье.
Итак, я выбрал каталог с дискографией Джорджа Бенсона, нажал F5, и тут же получил сообщение об ошибке. Надо честно признать - эта ситуация была неприятной, но я ожидал чего-то такого.
 |
| Таков результат попытки копирования каталога |
При все прочем, не смотря на ошибку, каталог для дискографии был создан на диске Seagate. То есть, непосредственно само копирование завершилось успешно. Но вот потом произошло еще что-то, и ошибка - следствие этого непонятно чего.
По правде говоря, отступать совсем не хотелось. Поэтому я решил немного погрузиться в тему. К счастью, разгадка лежала не очень глубоко. В окошке midnight commander, которое появляется перед началом копирования, выставлен флажок, который можно перевести, как "Сохранить атрибуты". То есть, после копирования mc попробует применить к копии те же атрибуты, которыми обладает оригинал.
Ключевым в этих рассуждениях является словосочетание "после копирования". Проверить совсем не сложно. Я снял флажок и запустил копирование подкаталога с каким-то из альбомов. И процесс пошел! Что ж, есть еще порох в пороховницах! Осталось дождаться, когда завершится копирование выбранного каталога, а потом - разом скопировать оставшиеся.
А пока альбом копировался, у меня образовалось время немного подумать на тему причины возникновения ошибки при выставленном флажке. И вот к какому заключению я пришел.
Сам текст ошибка и, отображаемый в сообщении mc, содержит явное указание на основную причину: не удалось выполнить chown, то есть, задать пользователя для вновь созданного на SWP каталога. Почему? Ответ лежит в самой природе диска от Seagate. Этот диск можно использовать не только как WiFi диск, но и подключать к компьютеру по USB. Для того, чтобы пользователи не испытывали проблем с подключенным диском, файловая система диска должна пониматься операционной системой компьютера, желательно, без дополнительных танцев с бубном. То есть, файловая система заведомо не будет Linux-овой. А раз так, то, скорее всего, используемая на диске файловая система ничего не знает о chown и не умеет каким-то образом реагировать на требование изменить владельца. Или же midnight commander не может правильно донести нужную команду до файловой системы.
Можно долго спорить о том, чья в этом вина, и кто накосячил. Но речь сейчас не об этом. Просто примем, как факт - скопировать при помощи midnight commander файлы на SWP можно, но надо снимать флажок "Preserve attributes". Возможно, это не единственный способ, может он и не самый правильный, так как не переносятся и другие атрибуты файлов, такие, как, "архивный", "только для чтения". Но он самый быстрый, а потому - самый удобный.
Вдумчивый читатель этой незаурядной детективной истории, уже, наверное, почувствовал, что "все не спокойно в датском королевстве", и... он прав! Пока я раздумывал о высоких материях, на экране появилось новое сообщение, и тоже (вот сюрприз!) об ошибке.
Якобы на диске закончилось место. Нет, я, конечно, точно знал, что место на SWP есть, и его много, так что... Понятно, что имеем дело с очередным глюком, которые, если честно, успели слегка поднадоесть. Правда, теперь ситуация становилась близкой к угрожающей: переписать с помощью mc дискографию не получалось. А очень хотелось послушать эти замечательные альбомы на работе - ну привычка у меня такая еще со школы: я делал уроки, готовился к экзаменам, писал курсовые и диплом - все под музыку. Теперь вот работаю... И да, этот текст тоже пишу, слушая музыку.
Поэтому я решил, что обязательно разберусь с глюками... Скажем, завтра. А сейчас скопирую-ка я файлы при помощи scp. Это, конечно, шаг назад, обратно впещеры к командной строке, но что тут поделаешь. Набрал я так нелюбимую мной длиннющую командную строку, в которой команды-то - scp -r, остальное - все пути. Набрал, значит, жму Enter, а мне в ответ: scp: not found.
Если честно, в этот момент хотелось уже что-то воскликнуть, причем, то, что вертелось на языке, имело мало общего с литературным русским языком в классическом его понимании. Я находился в консоли на WD MBLD, там scp есть точно, я его многократно запускал. Значит, scp не найден на SWP. Но я ведь устанавливал туда dropbear, который, судя по рекламе, является и сервером и клиентом протокола ssh, включая, кстати, и реализацию scp.
Это ведь известный факт, что для работы scp нужно иметь эту программу на всех участниках процесса. Поэтому, исключительно из любви к научному подходу, подключаюсь к SWP, ищу scp и, ожидаемо, не нахожу его. Чешу репу, ибо этот процесс улучшает кровоснабжение, и, следовательно, улучшает работу ее содержимого. И действительно, помогает. В памяти всплывает следующий факт: после разворачивания dropbear я обратил внимание на то, что программа там всего одна - dropbearmulti, остальное - софтовые symlink-и на эту программу. А что, если создать symlink с незатейливым именем scp, направив его все на этот же единственный программный файл? Пока мысль еще оформлялась, пальцы уже набрали: ln -s и так далее. Потом быстренько scp, Enter - и на экране подсказка по использованию команды scp. Ура, товарищи!
Переключаюсь в окно с консолью WD, чтобы не набирать команду по рекурсивному копированию каталога с альбомами заново, а просто повторить ее, и, после этого повтора, снова получаю в ответ scp: not found. Опять чешу репу, вспоминаю, что создал symlink в каталоге /opt/sbin. Может, надо создать его в каталоге /opt/bin? Дурное дело нехитрое, удаляю в консоли SWP один symlink, создаю другой, проверяю выполнение команды (опять из консоли WD) - на этот раз процесс пошел.
Копирование дискографии - дело не быстрое. Пока на экране появляются и исчезают строки с именами файлов, я вновь предался размышлениям. Часть вопросов - риторические, и получить ответ на них не просто, скорее, даже, невозможно. Например, почему в дистрибутиве dropbear для некоторых программ есть симлинки, а для scp - нет? Другие вопросы - технологические, скорее всего. Почему symlink из каталога /opt/sbin не заработал, а из каталога /opt/bin - заработал? Ведь оба подкаталога добавлены в PATH. На эти вопросы ответы получить значительно реальнее - надо грызть гранит науки. Что ж, надо, так надо, буду грызть, курить мануалы и гуглить. О результатах, если они будут, сообщу. А пока...
Пока же, пришло время рассказать о решении проблемы подключения в midnight commander по протоколу FISH из консоли Seagate к устройству WD. Это первая ошибка, которую я получил, когда, еще не подозревая о подстерегающих меня трудностях, только начинал играться с копированием файлов между устройствами.
На ответ меня натолкнуло решение проблемы копирования при помощи scp. Какие у меня на руках имелись факты? Протокол FISH работает через SSH. Установленный мной dropbear является не только сервером, но и клиентом этого протокола. А что мы запускаем, когда хотим по SSH подключиться к другому устройству? Конечно, можно запускать много чего, но один из правильных ответов - команду ssh. Если вспомнить историю с scp - то, что в развернутом дистрибутиве dropbear этого файла не было, то можно прийти к тому же, к чему пришел я. Не долго думая, я (в консоли на SWP), в каталоге /opt/bin, создал symlink ssh на dropbearmulti и запустил его. В ответ, на экране появилась коротенькая инструкция по использованию ssh. После этого я запустил midnight commander и попробовал открыть на левой панели shell link на диск WD. Окно с ошибкой не появилось. Но успешной попытку назвать было нельзя. Вот что я увидел на экране.
Но стало понятно, что я на правильном пути. Надо лишь сделать еще одно небольшое усилие. И мне оно удалось.
Когда в первый раз подключаешься по протоколу ssh к удаленному устройству, то на экране высвечивается предупреждение о том, что это устройство не является доверенным, хотите ли продолжить соединение, и, лишь после утвердительного ответа, устанавливается соединение. Я предположил, что при попытке первого соединения из mc по протоколу FISH, который, в свою очередь, использует SSH, происходит то же самое, только на экран не выдаются ни предупреждение, ни вопрос. Но ответ, тем не менее, ожидается. Так и ожидают - пользователь какой-нибудь реакции софта, софт - реакции пользователя. Я завершил mc, и подключился к устройству WD напрямую через ssh. Вопрос о доверии к устройству, естественно, был задан, и, я, также естественно, ответил на него утвердительно. После этого вновь вернулся в mc и, уже в который раз, попытался открыть удаленное устройство при помощи пункта меню Shell link. И на этот раз удачно. Вот так еще одной проблемой, или загадкой, стало меньше.
Тем временем, копирование дискографии на SWP завершилось. Все еще находясь в консоли WD, я захотел скопировать на него кое-какие файлы, которые хранились на диске Seagate. Я не знаю, чем руководствовался, когда запустил mc и открыл в нем нужные каталоги на обоих устройствах. Выбрав каталог на SWP, я нажал F5. Данных было достаточно, значительно больше тех, при копировании которых в обратном направлении (с WD на SWP) возникала ошибка нехватки места. Тем не менее, копирование все продолжалось и продолжалось, пока успешно не скопировался последний файл.
Вот так дела! Я переключился в консоль Seagate и, уже там, в mc, попробовал, используя протокол FISH, скопировать несколько каталогов с устройства WD. Ошибок не было, копирование завершилось успешно. Таким образом, напрашивается вывод, что ошибка нехватки места на диске возникает только при копировании в mc на удаленную машину - либо в консоли WD при копировании с WD на Seagate, либо в консоли SWP при копировании с Seagate на WD.
Никакие догадки не посещали мою голову, не помогало даже усиленное чесание репы. Тогда я обратился к интернету. Спустя непродолжительное время, я нагуглил немного разбросанной информации, которую, после некоторого осмысления, привожу ниже.
Скорее всего, происходит следующее. При копировании midnight commander создает временные файлы. В Linux, по крайней мере в той версии, что установлена на Seagate Wireless Plus, для конфигурирования файловой системы используется файл /etc/fstab. В нем может быть сконфигурирована и tmpfs - файловая подсистема для временных файлов. Возможно, ее параметры не достаточны для удовлетворения потребностей midnight commander при копировании файлов на удаленное устройство. Возможно, если поиграться с этими параметрами, можно решить эту проблему. Но я пока просто боюсь, так как не хватает знаний. Да и вопросов еще очень много. Например, почему этих же ресурсов хватает при копировании данных с удаленного устройства?
То есть, проблемы, все же, пока остались, и есть еще, куда копать. Но перспективы не выглядят так уж безнадежно. Главное - удалось вырваться за границы устройства и работать в midnight commander с удаленными ресурсами. Такие вот дела.
 |
| Окошко копирования midnight commander c флажком Preserve attributes (Сохранить атрибуты) |
Ключевым в этих рассуждениях является словосочетание "после копирования". Проверить совсем не сложно. Я снял флажок и запустил копирование подкаталога с каким-то из альбомов. И процесс пошел! Что ж, есть еще порох в пороховницах! Осталось дождаться, когда завершится копирование выбранного каталога, а потом - разом скопировать оставшиеся.
А пока альбом копировался, у меня образовалось время немного подумать на тему причины возникновения ошибки при выставленном флажке. И вот к какому заключению я пришел.
Сам текст ошибка и, отображаемый в сообщении mc, содержит явное указание на основную причину: не удалось выполнить chown, то есть, задать пользователя для вновь созданного на SWP каталога. Почему? Ответ лежит в самой природе диска от Seagate. Этот диск можно использовать не только как WiFi диск, но и подключать к компьютеру по USB. Для того, чтобы пользователи не испытывали проблем с подключенным диском, файловая система диска должна пониматься операционной системой компьютера, желательно, без дополнительных танцев с бубном. То есть, файловая система заведомо не будет Linux-овой. А раз так, то, скорее всего, используемая на диске файловая система ничего не знает о chown и не умеет каким-то образом реагировать на требование изменить владельца. Или же midnight commander не может правильно донести нужную команду до файловой системы.
Можно долго спорить о том, чья в этом вина, и кто накосячил. Но речь сейчас не об этом. Просто примем, как факт - скопировать при помощи midnight commander файлы на SWP можно, но надо снимать флажок "Preserve attributes". Возможно, это не единственный способ, может он и не самый правильный, так как не переносятся и другие атрибуты файлов, такие, как, "архивный", "только для чтения". Но он самый быстрый, а потому - самый удобный.
Вдумчивый читатель этой незаурядной детективной истории, уже, наверное, почувствовал, что "все не спокойно в датском королевстве", и... он прав! Пока я раздумывал о высоких материях, на экране появилось новое сообщение, и тоже (вот сюрприз!) об ошибке.
 |
| Теперь, якобы, закончилось место на диске. |
Якобы на диске закончилось место. Нет, я, конечно, точно знал, что место на SWP есть, и его много, так что... Понятно, что имеем дело с очередным глюком, которые, если честно, успели слегка поднадоесть. Правда, теперь ситуация становилась близкой к угрожающей: переписать с помощью mc дискографию не получалось. А очень хотелось послушать эти замечательные альбомы на работе - ну привычка у меня такая еще со школы: я делал уроки, готовился к экзаменам, писал курсовые и диплом - все под музыку. Теперь вот работаю... И да, этот текст тоже пишу, слушая музыку.
Поэтому я решил, что обязательно разберусь с глюками... Скажем, завтра. А сейчас скопирую-ка я файлы при помощи scp. Это, конечно, шаг назад, обратно в
Если честно, в этот момент хотелось уже что-то воскликнуть, причем, то, что вертелось на языке, имело мало общего с литературным русским языком в классическом его понимании. Я находился в консоли на WD MBLD, там scp есть точно, я его многократно запускал. Значит, scp не найден на SWP. Но я ведь устанавливал туда dropbear, который, судя по рекламе, является и сервером и клиентом протокола ssh, включая, кстати, и реализацию scp.
Это ведь известный факт, что для работы scp нужно иметь эту программу на всех участниках процесса. Поэтому, исключительно из любви к научному подходу, подключаюсь к SWP, ищу scp и, ожидаемо, не нахожу его. Чешу репу, ибо этот процесс улучшает кровоснабжение, и, следовательно, улучшает работу ее содержимого. И действительно, помогает. В памяти всплывает следующий факт: после разворачивания dropbear я обратил внимание на то, что программа там всего одна - dropbearmulti, остальное - софтовые symlink-и на эту программу. А что, если создать symlink с незатейливым именем scp, направив его все на этот же единственный программный файл? Пока мысль еще оформлялась, пальцы уже набрали: ln -s и так далее. Потом быстренько scp, Enter - и на экране подсказка по использованию команды scp. Ура, товарищи!
Переключаюсь в окно с консолью WD, чтобы не набирать команду по рекурсивному копированию каталога с альбомами заново, а просто повторить ее, и, после этого повтора, снова получаю в ответ scp: not found. Опять чешу репу, вспоминаю, что создал symlink в каталоге /opt/sbin. Может, надо создать его в каталоге /opt/bin? Дурное дело нехитрое, удаляю в консоли SWP один symlink, создаю другой, проверяю выполнение команды (опять из консоли WD) - на этот раз процесс пошел.
Копирование дискографии - дело не быстрое. Пока на экране появляются и исчезают строки с именами файлов, я вновь предался размышлениям. Часть вопросов - риторические, и получить ответ на них не просто, скорее, даже, невозможно. Например, почему в дистрибутиве dropbear для некоторых программ есть симлинки, а для scp - нет? Другие вопросы - технологические, скорее всего. Почему symlink из каталога /opt/sbin не заработал, а из каталога /opt/bin - заработал? Ведь оба подкаталога добавлены в PATH. На эти вопросы ответы получить значительно реальнее - надо грызть гранит науки. Что ж, надо, так надо, буду грызть, курить мануалы и гуглить. О результатах, если они будут, сообщу. А пока...
Пока же, пришло время рассказать о решении проблемы подключения в midnight commander по протоколу FISH из консоли Seagate к устройству WD. Это первая ошибка, которую я получил, когда, еще не подозревая о подстерегающих меня трудностях, только начинал играться с копированием файлов между устройствами.
На ответ меня натолкнуло решение проблемы копирования при помощи scp. Какие у меня на руках имелись факты? Протокол FISH работает через SSH. Установленный мной dropbear является не только сервером, но и клиентом этого протокола. А что мы запускаем, когда хотим по SSH подключиться к другому устройству? Конечно, можно запускать много чего, но один из правильных ответов - команду ssh. Если вспомнить историю с scp - то, что в развернутом дистрибутиве dropbear этого файла не было, то можно прийти к тому же, к чему пришел я. Не долго думая, я (в консоли на SWP), в каталоге /opt/bin, создал symlink ssh на dropbearmulti и запустил его. В ответ, на экране появилась коротенькая инструкция по использованию ssh. После этого я запустил midnight commander и попробовал открыть на левой панели shell link на диск WD. Окно с ошибкой не появилось. Но успешной попытку назвать было нельзя. Вот что я увидел на экране.
 |
| Все ждем, и ждем, и ждем... |
Но стало понятно, что я на правильном пути. Надо лишь сделать еще одно небольшое усилие. И мне оно удалось.
Когда в первый раз подключаешься по протоколу ssh к удаленному устройству, то на экране высвечивается предупреждение о том, что это устройство не является доверенным, хотите ли продолжить соединение, и, лишь после утвердительного ответа, устанавливается соединение. Я предположил, что при попытке первого соединения из mc по протоколу FISH, который, в свою очередь, использует SSH, происходит то же самое, только на экран не выдаются ни предупреждение, ни вопрос. Но ответ, тем не менее, ожидается. Так и ожидают - пользователь какой-нибудь реакции софта, софт - реакции пользователя. Я завершил mc, и подключился к устройству WD напрямую через ssh. Вопрос о доверии к устройству, естественно, был задан, и, я, также естественно, ответил на него утвердительно. После этого вновь вернулся в mc и, уже в который раз, попытался открыть удаленное устройство при помощи пункта меню Shell link. И на этот раз удачно. Вот так еще одной проблемой, или загадкой, стало меньше.
Тем временем, копирование дискографии на SWP завершилось. Все еще находясь в консоли WD, я захотел скопировать на него кое-какие файлы, которые хранились на диске Seagate. Я не знаю, чем руководствовался, когда запустил mc и открыл в нем нужные каталоги на обоих устройствах. Выбрав каталог на SWP, я нажал F5. Данных было достаточно, значительно больше тех, при копировании которых в обратном направлении (с WD на SWP) возникала ошибка нехватки места. Тем не менее, копирование все продолжалось и продолжалось, пока успешно не скопировался последний файл.
Вот так дела! Я переключился в консоль Seagate и, уже там, в mc, попробовал, используя протокол FISH, скопировать несколько каталогов с устройства WD. Ошибок не было, копирование завершилось успешно. Таким образом, напрашивается вывод, что ошибка нехватки места на диске возникает только при копировании в mc на удаленную машину - либо в консоли WD при копировании с WD на Seagate, либо в консоли SWP при копировании с Seagate на WD.
Никакие догадки не посещали мою голову, не помогало даже усиленное чесание репы. Тогда я обратился к интернету. Спустя непродолжительное время, я нагуглил немного разбросанной информации, которую, после некоторого осмысления, привожу ниже.
Скорее всего, происходит следующее. При копировании midnight commander создает временные файлы. В Linux, по крайней мере в той версии, что установлена на Seagate Wireless Plus, для конфигурирования файловой системы используется файл /etc/fstab. В нем может быть сконфигурирована и tmpfs - файловая подсистема для временных файлов. Возможно, ее параметры не достаточны для удовлетворения потребностей midnight commander при копировании файлов на удаленное устройство. Возможно, если поиграться с этими параметрами, можно решить эту проблему. Но я пока просто боюсь, так как не хватает знаний. Да и вопросов еще очень много. Например, почему этих же ресурсов хватает при копировании данных с удаленного устройства?
То есть, проблемы, все же, пока остались, и есть еще, куда копать. Но перспективы не выглядят так уж безнадежно. Главное - удалось вырваться за границы устройства и работать в midnight commander с удаленными ресурсами. Такие вот дела.
Комментариев нет:
Отправить комментарий