Всем известно понятие рекурсии. Не буду придумывать определений, кому интересно, может почитать, например, вики. Так или иначе, мы сталкиваемся с рекурсиями постоянно. И не только в программировании, математике и лингвистике, но и просто, в обычных жизненных ситуациях. И, чаще всего, мы даже не задумываемся, когда сталкиваемся с чем-то подобным. А я вот недавно задумался. Мне стало действительно интересно, как можно отличить, в повседневной жизни, рекурсию от чего-то другого. Причиной послужил следующий случай.
Захотел я облегчить себе жизнь и установить на Seagate Wireless Plus файловый менеджер Midnight Commander. Потратил некоторое время на то, чтобы вникнуть в тему, и на реализацию, с преодолением всевозможных непредвиденных ситуаций, тоже потратил, и уж, конечно, на описание всего этого процесса потратил так потратил.
Казалось бы, добился, чего хотел. Но опять вылезли различные... скажем так, нюансы. Например, при подключении через протокол telnet запустить mc - нет проблем, но вот мышку уже использовать нельзя. Да и с использованием функциональных клавиш не все гладко. Нет, конечно, всему есть объяснение и даже обходные пути имеются, например, использование Esc+цифра вместо функциональных клавиш, но осадочек, осадочек-то остается.
Вот и получается, что, вроде, цель достигнута, но как-то кривенько. И, из-за этой кривизны, следует, что, то ли цель была не совсем верно обозначена, то ли при реализации была достигнута не совсем та цель... В общем, Нирвана не достигнута и Шамбала так и осталась скрытой от глаз.
Захотел я облегчить себе жизнь и установить на Seagate Wireless Plus файловый менеджер Midnight Commander. Потратил некоторое время на то, чтобы вникнуть в тему, и на реализацию, с преодолением всевозможных непредвиденных ситуаций, тоже потратил, и уж, конечно, на описание всего этого процесса потратил так потратил.
Казалось бы, добился, чего хотел. Но опять вылезли различные... скажем так, нюансы. Например, при подключении через протокол telnet запустить mc - нет проблем, но вот мышку уже использовать нельзя. Да и с использованием функциональных клавиш не все гладко. Нет, конечно, всему есть объяснение и даже обходные пути имеются, например, использование Esc+цифра вместо функциональных клавиш, но осадочек, осадочек-то остается.
Вот и получается, что, вроде, цель достигнута, но как-то кривенько. И, из-за этой кривизны, следует, что, то ли цель была не совсем верно обозначена, то ли при реализации была достигнута не совсем та цель... В общем, Нирвана не достигнута и Шамбала так и осталась скрытой от глаз.
И тут возникает зуд улучшить только что полученные улучшения, чтобы убрать те шероховатости, которые мешают откинуться на спинку кресла, окинуть взглядом проделанную работу и не найти, к чему придраться.
В случае с установкой mc, довольно быстро пришло осознание необходимости переходить с протокола telnet на что-то более продвинутое. На что? Ну, тут как бы даже и задумываться не следует. Ответ напрашивается сам собой. Даже когда запускаешь Putty, например, выбор протокола по умолчанию установлен на... Правильно, на SSH. Так что, приготовьтесь читать про то, что необходимо проделать с устройством, чтобы подключиться к нему по протоколу SSH. Не забываем, что под устройством понимаем Seagate Wireless Plus - SWP.
От части проблем я уже был избавлен. Например, не надо искать, каким репозиторием пользоваться, или, как правильно устанавливать пакеты ipk. Так что, все должно было получиться чуточку проще.
Ответ на вопрос, что выбрать в качестве SSH сервера, тоже был предрешен. Я упоминал уже, что SWP - не первое мое устройство с Linux-ом на борту, пусть и урезанным. А для тех устройств, которые прошли через мои руки, знающие люди советовали использовать dropbear. Может я не прав, что прислушался к этим советам, и есть что-то значительно лучше, но... Как говорится, чем богаты.
Пакет dropbear был скачан мною без малейших колебаний на ноутбук, и далее последовала, ставшая стандартной, процедура копирования в публичный каталог на SWP и установка путем разархивирования содержащегося в ipk файле архива data.tar.
tar -xOvzf dropbear_0.52-5_arm.ipk ./data.tar.gz | tar -C / -xzvf -Но для работы SSH сервера просто установки недостаточно. Необходимо выполнить еще пару-тройку дополнительных шагов.
Во-первых, необходимо сгенерировать ключи, которые будут использоваться для установки зашифрованного канала. Остановимся на этом чуть подробнее. Надо сгенерировать пару ключей: один RSA ключ и еще один DSS ключ. Делается все это с помощью якобы программы dropbearkey. Почему я использовал уничижительную частицу "якобы"? Потому, что это обычный symlink.
Но прежде, чем броситься, сломя голову, генерировать ключи, надо понять, где они должны будут храниться. К счастью, эту информацию найти не трудно: надо создать подкаталог dropbear в каталоге /opt/etc
Но прежде, чем броситься, сломя голову, генерировать ключи, надо понять, где они должны будут храниться. К счастью, эту информацию найти не трудно: надо создать подкаталог dropbear в каталоге /opt/etc
cd /opt/etcmkdir dropbear
Далее, переходим в каталог /opt/sbin - чтобы вызывать dropbearkey без указания пути, и выполняем команды по генерации ключей:
cd /opt/sbin/./dropbearkey –t rsa –f /opt/etc/dropbear/dropbear_rsa_host_key./dropbearkey –t dss –f /opt/etc/dropbear/dropbear_dss_host_key
Вы спросите, а как я узнал, какие имена надо давать файлам, которые будут содержать сгенерированные ключи? Все просто - я узнал их в интернете, имена и пути прописаны, видимо, в коде программы. Но можно их поменять. Для этого, при старте сервера можно использовать опции командной строки -r и -d для RSA и DSS ключа соответственно. Естественно, в этом случае, указанные значения этих опций должны совпадать с теми значениями, которые указывались при генерации ключей.
А ключах достаточно, пойдем дальше. Всем, кто дочитал до этого места повествования, должно быть известно, что протокол SSH по умолчанию использует порт 22. Авторы dropbear, а может дистрибьюторы, решили в этом вопросе пойти своим путем. В поставке имеется конфигурационный файл - это /opt/etc/default/dropbear, в котором прописан параметр DROPBEAR_PORT и значение у него установлено в 2222. Этот файл можно отредактировать, заменив четыре двойки на две, или просто закомментировав строку символом # в первой колонке (после этого строка будет выглядеть так: #DROPBEAR_PORT=2222). Но можно этого и не делать, или вообще установить свой номер порта, не забыв при этом, что, подсоединяясь к этому серверу, в клиенте надо будет указывать правильный номер порта.
Продолжаем двигаться вперед. Ключи для сеансов сгенерировали, порт настроили, можно и проверить, как это все работает. Для этого я просто перешел в каталог, где находился symlink dropbear и запустил сервер:
cd /opt/sbin/./dropbear
Сервер запустился, теперь надо подключиться с какого-нибудь клиента. Тоже не вопрос: завершаю telnet коннект, на ноуте запускаю Putty, набиваю адрес SWP - тип соединения и порт Putty сам устанавливает по умолчанию в нужные значения. Все готово, жму кнопочку установки соединения. На экран выводится сообщение про то, что хост с таким ключем еще ни разу не встречался, требуется подтверждение того, что вы осознаете с кем соединяетесь и согласны продолжать. Конечно, я все осознаю, по крайней мере, мне так кажется, соглашаюсь продолжить, после чего выводится запрос имени пользователя, затем пароля. Все! Я установил SSH сессию успешно. Запустил тут же midnight commander. Что ж, все было не напрасно - мышка работает как нужно. С функциональными клавишами чуть хуже, но тоже решаемо при помощи встроенной в mc же утилитки настройки функциональных клавиш.
Дело осталось за малым. Согласитесь, это не совсем красиво, сначала открывать telnet сессию, из нее запускать SSH сервер, завершать telnet соединение, открывать SSH коннект. Надо, чтобы сервер SSH поднимался автоматически, при загрузке устройства. Как это можно организовать?
Понятно, что надо писать командный файл, который бы выполнялся при старте системы. И дела с этим обстоят значительно лучше, нежели кажется. Во-первых, пример такого файла идет в дистрибутиве, и, после установки, он находится в каталоге /opt/etc/init.d и гордо носит имя S51dropbear. Во-вторых, исследуя вопрос, куда пристроить выбор страны для работы WiFi с 13 каналом, я уже слегка познакомился с тем, как организована инфраструктура автоматического старта нужных сервисов при запуске системы. Эти знания, собственно, сводятся к следующему: чтобы автоматически стартовать на каком-то этапе, командный файл должен лежать в одном из каталогов /etc/rcX.d, где X определяет степень загрузки системы. Для загрузки всевозможных сетевых штучек X равно 5. Имя же командного файла должно начинаться с последовательности S??, где S, по всей видимости, есть указание на то, что командный файл должен быть запущен (наверное, от start), а вместо ?? следует подставить число, которое будет определять очередность запуска именно этого файла. В нашем случае, имя файлу уже дали, осталось переместить его в каталог для командных файлов, запускаемых при старте системы на этапе инициализации сетевого окружения, то есть в /etc/rc5.d.
Все бы ничего, но есть один момент, который остался для меня не совсем ясным. Дело в том, что на некоторых интернет ресурсах советуют отредактировать командный файл запуска сервера SSH. При этом, предлагается заменить строку:
killall -9 /opt/sbin/dropbear 2>/dev/null
строкой:
kill -9 $(ps | grep dropbear | awk '{print $1}') 2>/dev/null
Я заменил, но, если честно, не совсем понимаю, зачем. Точнее, почему я последовал советам, я понимаю - не хватает знаний ни встать на сторону советчиков, ни аргументированно с ними поспорить. А вот почему советуют? На этот вопрос ответа у меня нет - знаний ведь не хватает. Но есть предположение. Видимо, первая строка позволяет завершить процесс сервера SSH, если он стартовал из определенного каталога, а вторая - в любом случае. Правда, есть и более глубокая загадка: а зачем в командном файле, выполняемом при запуске системы, строки для выгрузки процесса из памяти? Эх, много еще чего надо учить и познавать... Но, раз строки для выгрузки есть, надо проверить, работают они, или нет. Вручную запускаю командный файл. Работает! Как узнал? Очень просто - запускал я его из-под SSH коннекта, и, после запуска, коннект оказался разорван. И не просто разорван, а сервер dropbear полностью выгружен - повторная попытка соединиться заканчивается сообщением, что подсоединиться просто не к чему.
После проверки в ручном режиме, что запущенный сервер SSH выгружается при выполнении командного файла, можно считать, что работа выполнена. Действительно, после перезагрузки SWP, я могу спокойно к нему подключиться по SSH протоколу и пользоваться всеми его плюшками.
Однако, под занавес, хочу рассказать еще об одном моменте, который тоже вычитал в интернете, правда, в форуме по WD MyBook Live. И дело вот в чем. Все, что я (или мы?) установили на устройство, не является составной частью программного обеспечения, которое распространяется производителем. Следовательно, как только производитель выпустит обновление ПО, а мы его установим, наши все дополнительные компоненты будут обязательно потеряны. В случае автоматического обновления, у вас и шанса не будет, чтобы как-то повлиять на этот процесс. А ведь сделано уже не мало, это не одну строчку в нужный файлик добавить. Что тут можно предпринять?
Как всегда, есть несколько решений. Можно, например, каталог opt создавать не в корне файловой системы, а в области данных, которая не перезаписывается при обновлениях (иначе бы с каждым обновлением мы бы проклинали производителя устройства). А в корне создавать symlink на этот каталог. Тогда при обновлении, вернее, после обновлений, мы просто восстановим ссылку и все будет в порядке.
Но я выбрал немного другой способ. Суть его заключается в создании backup копии каталога opt, которую можно хранить где угодно. Создается эта копия при помощи tar, физически ее удобно создавать в той же неперезаписываемой области данных.
После проверки в ручном режиме, что запущенный сервер SSH выгружается при выполнении командного файла, можно считать, что работа выполнена. Действительно, после перезагрузки SWP, я могу спокойно к нему подключиться по SSH протоколу и пользоваться всеми его плюшками.
Однако, под занавес, хочу рассказать еще об одном моменте, который тоже вычитал в интернете, правда, в форуме по WD MyBook Live. И дело вот в чем. Все, что я (или мы?) установили на устройство, не является составной частью программного обеспечения, которое распространяется производителем. Следовательно, как только производитель выпустит обновление ПО, а мы его установим, наши все дополнительные компоненты будут обязательно потеряны. В случае автоматического обновления, у вас и шанса не будет, чтобы как-то повлиять на этот процесс. А ведь сделано уже не мало, это не одну строчку в нужный файлик добавить. Что тут можно предпринять?
Как всегда, есть несколько решений. Можно, например, каталог opt создавать не в корне файловой системы, а в области данных, которая не перезаписывается при обновлениях (иначе бы с каждым обновлением мы бы проклинали производителя устройства). А в корне создавать symlink на этот каталог. Тогда при обновлении, вернее, после обновлений, мы просто восстановим ссылку и все будет в порядке.
Но я выбрал немного другой способ. Суть его заключается в создании backup копии каталога opt, которую можно хранить где угодно. Создается эта копия при помощи tar, физически ее удобно создавать в той же неперезаписываемой области данных.
tar -czf /media/sda1/optware.backup.tar.gz /optПосле же обновления ПО, при помощи все той же команды tar, backup легко и просто восстанавливается на место.
tar -xzf /media/sda1/optware.backup.tar.gz -C /Главное не забывать после установки новых компонент делать новый же backup. Ну и небольшое пояснение к приведенным выше двум командам. Первая создает файл с именем optware.backup.tar.gz в каталоге /media/sd1 (это тот самый публичный каталог с данными), упаковывая туда содержимое каталога /opt. Вторая - распаковывает содержимое ранее созданного optware.backup.tar.gz из публичного каталога с данными в корень файловой системы, создавая тем самым, подкаталог opt со всем содержимым.
Вот такая у меня получилась рекурсия. Или не рекурсия? Может, просто новый виток получения и применения знаний? Надо, все-таки, обдумать эту ситуацию еще раз. Тем более, что к теме придется возвращаться, и, быть может, не единожды. Не все еще гладко, есть пока еще неработающие нюансы. Но об этом как-нибудь в другой раз.
Комментариев нет:
Отправить комментарий