Дорабатываем Linksys NSLU2: универсальная платформа Linux – THG.RU

Введение

Рис. 1. Linksys NSLU2.

Нас заинтересовало сетевое хранилище, которое недавно побывало в нашей лаборатории, – Linksys NSLU2. Компактный корпус, бесшумная работа, низкая цена и все необходимые функции по сетевому хранению и резервированию файлов – чего ещё может желать пользователь?

К сожалению, согласно документации, устройство может работать только с клиентами под управлением Microsoft Windows, и, кроме того, использует собственную файловую систему.

Подсоединив внешний жёсткий диск, мы вышли в web-интерфейс NSLU2 с помощью браузера и настроили устройство. Вопреки документации Linksys, сетевое хранилище можно использовать и с системами под управлением MacOS X и Linux, поскольку обе они поддерживают протокол Microsoft SMB. Но это было только начало.

Дело в том, что внутри этой маленькой коробочки работает Linux – а раз так, то можно по максимуму использовать весь потенциал NSLU2. Устройство с двумя портами Hi-Speed USB и портом 10/100, определённо, способно на большее. Как насчёт NFS? Или сервера печати?

Переходник с USB на последовательный порт позволит автоматизировать некоторые домашние функции. Сетевая карта USB преобразует NSLU2 в маршрутизатор, а беспроводная карта USB 802.11b/g – в беспроводную точку доступа. Возможность полноценной работы с портами USB позволит открыть новые горизонты использования устройства, осталось только узнать, как это сделать.

Предупреждение. Исследование NSLU2 через просмотр внутренней структуры файлов любым способом, который не изменяет код, не повлечёт за собой лишение гарантии. Однако любое изменение структуры автоматически лишает гарантии.

Сайт Tom’s Hardware Guide Russia и авторы не несут ответственности за повреждение оборудования. Вы используете приведённые ниже инструкции на свой страх и риск.

Перед тем, как начинать, советуем скачать последнюю прошивку. И не пытайтесь обращаться в службу поддержки Linksys, если что-то пойдёт не так.

“Потайная дверь”

Сканирование портов не показало ничего интересного. Просмотр всех стандартных меню также оказался бесплоден.

Стандартным способом входа в такие устройства являются “потайные двери” (back door). Разработчикам они нужны для контроля параметров системы при её настройке и тестировании. Иногда для этого требуется специальное оборудование, но в ряде случаев разработчики пользуются тем же сетевым интерфейсом.

Первое, с чего стоит начать, – web-интерфейс. Мы заметили, что страницы администрирования находятся в папке “Management”. Мы знаем, что web-серверы иногда позволяют просматривать содержимое каталога, поэтому мы решили перейти по адресу http://192.168.3.77/Management/. Сработало! Мы увидели все файлы этого каталога.

Примечание. Возможность просмотра каталогов была устранена в прошивке V2.3R25 NSLU2.

Среди множества картинок и html-файлов мы смогли обнаружить telnet.cgi. Потенциальная точка входа найдена! После запуска скрипта мы увидели следующий экран.

Рис. 2. Экран включения Telnet.

Посмотрев на предупреждение, мы нажали на кнопку “Enable Telnet”. Страница обновилась, и мы увидели сообщение о том, что Telnet активирован! Переходим к следующему этапу.

Получаем доступ к Telnet

В окне терминала мы попробовали использовать учётную запись, заданную при настройке NSLU2.

Близко, но не то, что требовалось. Сервер Telnet работал, имя и пароль были приняты, но каталог по умолчанию учётной записи оказался /dev/null. Тем не менее, это уже говорит о том, что учётные записи, заданные через web-интерфейс, являются учётными записями Linux, но их права ограничены. Это традиционный подход, когда пользователи могут работать со службами, но не могут выполнять вход в систему.

Мы попробовали выполнить вход под именем root (стандартная учётная запись в Linux), но не удалось – пароль был неизвестен и не был из серии простейших (admin, root и другие). Настало время взглянуть на проблему под другим углом.

В документации Linksys утверждалось, что жёсткий диск, инициализированный NSLU2, может использоваться только с паре с устройством. Мы решили это проверить. Файловая система – достаточно сложная штука, и вряд ли Linksys создала для NSLU2 новую. Многие источники указывали на то, что в NSLU2 используется файловая система Linux ext3 (это, кстати, подтвердил представитель Linksys), но никто не пытался её подключить.

Конечно, можно было подключить диск к системе Mandrake Linux, но мы скачали драйверы ext2 (подмножество ext3) для MacOs X iBook и подключили диск к порту USB.

Совет.Драйверы для Mac OS X ext2 можно скачать с сайта ext2 for Mac OS X SourceForge. Там же можно найти драйвер чтения ext2 для Windows NT/2000/XP, который использовался для того, чтобы создать скриншот, показанный на Рис. 3.

Мы увидели два раздела: большой с нашими данными и маленький с файлами конфигурации, включая passwd.

Рис. 3. Файлы конфигурации.

Как мы и ожидали, в файле passwd содержались сведения о созданных нами учётных записях с каталогом по умолчанию /dev/null. Но там же мы увидели ещё две нормальные учётные записи: root и весьма интересную – ourtelnetrescueuser, которая нам показалась именно тем, что нужно, то есть учётной записью для отладки и восстановления.

Конечно, для того, чтобы воспользоваться ими, необходимо знать пароли. Мы решили не заниматься взломом, а просто отредактировать файл passwd, заменив зашифрованный хэш одним из созданных нами! Можно было также добавить оболочку к нашим учётным записям, но мы решили просто задать новый пароль для администратора, а всё остальное оставить, как есть.

Как успехи?

При перезагрузке устройства мы опасались, что внесённые изменения будут перезаписаны, или сработает какая-либо защита. NSLU2 мог бы отказаться подключать диск или, к примеру, переформатировать его.

Но, всё прошло гладко, и мы услышали звуковой сигнал, сообщивший о том, что система готова к работе. После активации Telnet, мы попытались выполнить следующий вход:

Готово! Мы получили командную строку, что полностью раскрыло перед нами устройство. Теперь можно расширить набор функций. Поскольку NSLU2 использует жёсткий диск, то можно создавать собственные сценарии, файлы и устанавливать необходимые драйверы.

Добавляем поддержку NFS

Поскольку устройство работает под управлением одной из версий ОС Linux, то для него можно найти множество дополнительных модулей, которые можно установить и использовать. Можно расширить возможности до полноценного web-, ftp-сервера или сервера secure shell – для замены Telnet. Но в первую очередь мы решили установить поддержку другой сетевой файловой системы.

Изначально NSLU2 поддерживает только SMB – протокол сетевой файловой системы Microsoft Windows. Поскольку наша сеть состоит, в большей степени, из UNIX-машин, таких как Apple Mac OS X и Linux, мы решили установить поддержку NFS – сетевой файловой системы UNIX.

Однако перед тем, как начать установку, необходимо преодолеть несколько трудностей. Первое – это установить инструментарий разработчика, так как мы должны скомпилировать необходимые модули. Будем считать, что вы уже включили Telnet на NSLU2.

Определение процессора

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

Первое, что нужно сделать в его настройке, – определить процессор, для которого будет выполняться компиляция. Согласно полученной информации, в NSLU2 используется процессор Intel IXP420.

Теперь мы можем войти в систему, а значит можем узнать текущий процессор. Для этого обратимся к файлу /proc/cpuinfo.

Ничего особого нового мы не узнали – лишь подтвердили, что в NSLU2 используется процессор IXP425. Для дальнейшей работы нужно использовать другой подход. Воспользуемся утилитой file, которая изучает файл и сообщает, к чему он относится.

На NSLU2 нет утилиты file, зато есть ftp. С помощью ftp мы можем перенести исполняемый файл на систему Mandrake. Начнём с файла telnet.cgi в каталоге /home/httpd/html/Management. После того, как он будет скопирован, можно запустить утилиту file.

Уже лучше. Теперь мы знаем, что используется процессор ARM, поэтому нужно установить компилятор для него.

Собираем Toolchain

Сама мысль об установке межплатформенного Toolchain вселяет страх в сердца многих разработчиков. Представьте, нужно скомпилировать компилятор, библиотеки C и т.д. К счастью, в эпоху Интернета можно воспользоваться готовыми результатами чужого труда.

Дан Кегель (Dan Kegel) занимается созданием межплатформенных компиляторов gcc, при этом он предлагает огромный скрипт, который начинает работу со сборки всего необходимого. Он скачивает требуемый исходный код, при необходимости патчи к ним, и создаёт готовый Toolchain – и так для множества различных процессоров. Мы уже использовали скрипты для создания компилятора под Linksys WRT54G, основанного на процессоре MIPS. Как мы полагали, скрипты Дана смогут помочь и с NSLU2 – они создадут Toolchain, с помощью которого мы сможем создавать исполняемые файлы NSLU2.

Кажется, что Linksys неохотно предоставляет исходный код, требуемый по лицензии GPL. Многие устройства этой компании используют Linux, но их наборы GPL сильно отличаются. Некоторые модели включают полный набор окружения, тогда как другие, например NSLU2, этим не отличаются.

Диск, который поставляется в комплекте NSLU2, содержит достаточно большую часть исходного кода, но без Toolchain. К счастью, в арсенале Linksys есть и другое устройство, использующие Linux – WRV54G. Этот беспроводной широкополосный маршрутизатор 802.11g, по всей видимости, выполнен на той же системе Intel IXP425. Linksys выпустила Toolchain для этого продукта, поэтому им мы и воспользуемся. Для начала нужно скачать файл объёмом 125 Мбайт и распаковать его (tar).

В нашем случае мы распаковали его в папку:

В ней можно найти файл toolchain.tgz. Мы распаковали его в тот же домашний каталог. После этого там можно найти все необходимые компиляторы, линкеры, модули и прочее.

Исполняемые файлы находятся в каталоге usr/local/openrg/armsaeb/bin и у всех есть префикс armv4b-hardhat-linux-. Этот каталог мы добавили в $PATH, чтобы каждый раз не указывать полный путь.

Тестирование компилятора

Теперь необходимо проверить компилятор – будет ли исполняемый код работать на тестовой платформе. Первое, что пишет любой уважающий себя программист, – “Hello World”. Так и мы, создали файл hello.c.

Затем откомпилировали его.

И проверили тип файла.

Всё в порядке. Теперь можно скопировать файл на NSLU2 по ftp и запустить его там. Не забудьте включить двоичную передачу ftp (binary) и пометить файл как исполняемый. После этого можно запускать.

Работает! Теперь мы можем создавать и запускать любые программы на NSLU2. При этом не забудьте сохранять данные на жёсткий диск, поскольку домашняя папка учётной записи root располагается на RAM-диске. Создайте новый каталог стандартным способом и скопируйте туда файл.

Изменение и компиляция Portmapper

Теперь можно приступать к серьёзным делам. Первое, что нам нужно сделать, – это установить и настроить дерево исходных файлов Linux для того, чтобы добраться до необходимых модулей include. Дерево можно найти в архиве snapgear tar на диске, поставляемом с NSLU2.

Затем нужно распаковать архив. Поскольку мы не собираемся перекомпилировать ядро, мы пропустим настройку для архитектуры ARM. Создайте и запустите следующий скрипт в каталоге snapgear/linux-2.4.x:

NFS основана на архитектуре удалённого вызова процедур (Remote Procedure Call). Для работы RPC необходимо запустить вспомогательную службу (демон) portmapper. Исходный код службы мы нашли здесь, а сервера NFS – здесь. После распаковки деревьев исходного кода вы получите папки portmap_4, snapgear и nfs-server-2.2beta47, а также имеющуюся gpl_code_2.03.

Далее необходимо откомпилировать portmapper. Нам пришлось сделать несколько изменений для упрощения компиляции makefile. Во-первых, мы закомментировали строчку HOSTS_ACCESS= -DHOSTS_ACCESS, чтобы уменьшить зависимость от внешних библиотек. По той же причине мы закомментировали все строки со ссылками на libwrap.a. Для большей защиты можно вернуть всё обратно, но тогда потребуются дополнительные библиотеки.

После этого мы изменили строку CFLAGS, указав в ней расположение дерева исходного кода snapgear:

В верхнюю часть makefile мы добавили следующую строчку для вызова межплатформенного компилятора:

Кроме изменений в makefile мы подправили и исходный код. В файле portmap.c, задана функция perror, переопределяющая стандартную функцию perror. Мы изменили параметр const char на __const char, чтобы он совпадал со значением, определённым в stdio.h.

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

Добавление служб NFS

Компиляция завершена, идём дальше. Теперь настала очередь самих служб (демонов) NFS. Процесс создания демонов NFS требует запуска скрипта BUILD. Никаких межплатформенных параметров в нём нет, поэтому мы запустили его и получили результат. Во время выполнения скрипта приходится отвечать на множество вопросов, и на все надо отвечать по умолчанию, единственное исключение – следующий вопрос:

На этот вопрос следует ответить “no” , поскольку у нас нет необходимой библиотеки. После завершения, придётся исправить файл makefile, чтобы он мог работать с межплатформенным компилятором. В начале файла есть три переменных CC, AR и RANLIB. Там необходимо добавить префикс компилятора. Например, в нашем случае переменная CC приняла вид:

Затем, нужно добавить путь к модулям include в строке CFLAGS. У нас она стала выглядеть так:

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

После всего этого команда “make” даст два необходимых файла: rpc.mountd и rpc.nfsd. Теперь можно приступить к запуску NFS.

Для этого следует скопировать все три полученных файла (portmap, rpc.mountd и rpc.nfsd) на NSLU2. Мы решили скопировать их на раздел conf, чтобы они хранились отдельно от данных. Мы создали три новых каталога в папке /share/hdd/conf – bin, etc и rc.d, как и в обычном дереве каталогов.

Двоичные файлы отправились в каталог bin, скрипты – в rc.d, файлы конфигурации – в каталог etc. В нашем случае единственным необходимым конфигурационным файлом является exports. В нём хранится информация, какие каталоги доступны в NFS и для кого. В нашем случае файл exports выглядел следующим образом:

Параметр insecure предназначен для системы Mac OS X, которая использует незащищённые порты. Вам, вероятно, потребуется создать свой файл для вашей сетевой конфигурации. Подробнее об этом можно узнать в документации NFS.

Проверка

Теперь осталось всё установить. Сервер NFS ищет файл exports в каталоге /etc, поэтому необходимо сделать ссылку на новый файл, находящийся в каталоге /share/hdd/conf/etc:

Теперь необходимо позаботиться о скриптах загрузки для всех новых служб. На NSLU2 скопируйте скрипт rc.samba из каталога /etc/rc.d в новый каталог rc.d и внесите пару изменений: создать скрипты rc.portmap и rc.nfsd. Скрипт rc.nfsd должен запускать rpc.mountd и rpc.nfsd.

Осталось создать ещё один скрипт, который будет всё это делать: создавать ссылку, запускать скрипты portmap и nfsd именно в таком порядке. Его придётся выполнять при каждом запуске системы. К сожалению, как поставить автоматическое выполнение – мы не знаем.

Пробуем запустить скрипт, выполняющий все необходимые действия. После этого ps -ax на NSLU2 должен показать, что появились три новах процесса: portmap, rpc.mountd и rpc.nfsd. Сообщения об ошибках и системных событиях сохраняются в файле /var/log/messages.

Попытайтесь смонтировать NSLU2 с клиентской машины. На нашей тестовой системе Mandrake мы выполнили следующее (с правами root):

На системе Mac OS X, мы использовали опцию “Connect to Server” в Finder, указав сервер следующим образом:

Если у вас возникли проблемы с запуском демонов или подключением, то проверьте файл /var/log/messages на NSLU2. Отметим, что запуск NFS никак не влияет на SMB, они мирно сосуществуют.

Совет.Если у вас нет желания самому заниматься компиляцией, и вы хотите использовать готовые файлы, которые можно будет загрузить на NSLU2 (редактировать файл etc/exports всё равно придётся), то можете скачать архив объёмом ~57 кбайт отсюда.

Добавляем сервер iTunes

Наверное, все сталкивались с проблемой, когда коллекция музыки занимает слишком много места на жёстком диске. Было бы прекрасно переложить обязанности по хранению музыки на другое устройство, а ещё лучше, если бы оно было общим. Сейчас мы попробуем проверить, сможет ли NSLU2 играть роль музыкального сервера. Маленькое и бесшумное устройство может хранить столько информации, сколько вместит подключённый жёсткий диск. Выглядит многообещающе!

Сервер iTunes называется mt-daapd. Использование его на NSLU2 позволит не только хранить музыку, но и слушать её с компьютеров Mac OS X и Windows при помощи iTunes.

Интересно, что mt-daapd использует Rendezvous для объявления себя в локальной сети. Это означает, что сервер NSLU2 будет автоматически обнаруживаться в сети другими системами. Необходимо лишь запустить iTunes на машине с Windows или Mac OS X, и сервер автоматически покажет свою музыкальную библиотеку. Сразу отметим, что установка mt-daapd будет сложнее, чем NFS, но мы будем с вами и поможем преодолеть все препятствия.

Поиск исходного кода

Как и прежде, будем работать с оболочкой bash. Компиляцией займёмся на машине с Mandrake. Однако теперь мы будем использовать диск NFS на NSLU2, чтобы не заниматься излишним копированием.

Первое, что нужно сделать, – подготовить место для работ. Мы создали каталог iTunes в домашнем каталоге на NSLU2. Далее нам нужно найти все необходимые пакеты с исходным кодом. Мы начали с исходного кода mt-daapd, который взяли здесь.

Из документации мы узнали, что нам потребуется библиотека чтения ID3 libid3tag и менеджер баз данных GUN gdbm. Мы также выяснили, что потребуется и библиотека сжатия zlib. libid3tag мы взяли здесь, gdbm – здесь и zlib – здесь. Все модули мы поместили в каталог iTunes. После распаковки вы получите каталоги gdbm-1.8.3, libid3tag-0.15.1b, mt-daapd-0.2.0 и zlib-1.2.1.

Перед началом межплатформенной компиляции нужно задать переменные окружения. Все модули настраиваются одинаково, при помощи GNU Autoconf. Модуль считывает расположение компилятора и других файлов их переменных окружения.

Мы создали файл setup.sh следующего содержания:

Обратите внимание, что строчка export TOOLSBASE и следующая являются единой, без переноса и пробела.

BASE указывает на папку верхнего уровня нашей рабочей области, а LINUX – на папку дерева исходного кода snapgear Linux. TOOLSBASE – инструментарий межплатформенного компилятора, CC, STRIP и RANLIB – пути исполняемых файлов. LDFLAGS и CFLAGS используются при компиляции. Перед компиляцией нужно создать такой же файл с вашими параметрами. Затем выполните “точку”, то есть . setup.sh, после чего переменные будут занесены в окружение. Теперь можно перейти непосредственно к компиляции.

Начнём с простого

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

Параметр prefix указывает Autoconf, куда будут помещаться откомпилированные файлы. При запуске скрипта вы увидите несколько строк выходных данных и ссылки на компилятор arm-gcc. Теперь, когда всё настроено, осталось выполнить следующее:

После завершения компиляции нескольких файлов и создания библиотеки, результаты скопируются в основной каталог. Всё просто! Одна часть сделана, осталось ещё три.

Переходим к gdbm. Здесь также нет внешних зависимостей, но нужно указать ещё пару моментов, касающихся конфигурации. В каталоге gdbm нужно выполнить следующее:

Здесь Autoconf запросит архитектуру – и параметр host отвечает как раз за это. После запуска строки появится более длинный список, чем в предыдущем случае, однако всё должно завершиться за несколько секунд. Теперь нужно выполнить следующее:

Произойдёт долгая компиляция, затем ldconfig будет “жаловаться” на общую библиотеку, которая не поддерживает двоичные файлы arm. Нас это не заинтересовало, поскольку мы не собирались использовать библиотеки на NSLU2. Можно также встретить ошибку об изменении владельца gdbm.h. Она для нашего случая абсолютно безобидна.

Приступим к libid3tag. В каталоге libid3tag выполним:

Как и прежде, длинный список, затем:

Процесс заканчивается, как и прежде, с ошибкой ldconfig. Тем не менее, наши библиотеки готовы. Просто, не так ли? Сейчас будет немного посложнее – переходим к mt-daapd.

Компилируем mt-daapd

Как мы и говорили, создание mt-daapd более запутанно. Но, не стоит волноваться, мы опишем всё достаточно подробно.

В каталоге mt-daapd нужно выполнить следующую команду:

Обратите внимание: это одна строка, с пробелом между $BASE и LIBS.

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

Подробнее рассмотрев скрипт, мы заметили, что параметр LIBS может использоваться для добавления дополнительных библиотек. Что мы и сделали. Это можно считать взломом, но именно благодаря этому нам не пришлось вносить изменения в скрипт.

Ещё один новый параметр ac_cv_func_setpgrp_void также можно считать взломом. При первом запуске скрипта конфигурации мы встретили ошибку, которая возникла при попытке запуска тестовой программы, исполняющей поведение какой-то функции. Конечно, при межплатформенной компиляции мы не можем компилировать и запускать программы локально. При установке этого параметра во время конфигурирования, мы, по сути, “говорим” скрипту, что тест прошёл и результат его получен. Однако для этого нам пришлось самостоятельно найти правильный ответ и также указать его в командной строке.

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

После запуска указанной выше команды нам придётся сделать ещё пару исправлений. Во-первых, для упрощения установки, нужно удалить общие библиотеки, которые мы только что создали. После их удаления ссылка будет вновь указывать на статические версии. Благодаря этому мы избавимся от дополнительных библиотек, которые не используют никакие другие процессы. Если вы заметите, что другим процессам нужны эти библиотеки, то можно пропустить этот шаг и оставить библиотеки. Выполните команду в каталоге mt-daapd.

Затем необходимо внести изменения, связанные с характером работы компилятора arm. По умолчанию, компилятор arm выравнивает структуры по 16-битным границам. В обычных случаях это не вызывает проблем, однако у нас структуры считываются и записываются непосредственно из сети. С другой стороны сетевого подключения находится программа iTunes, которая не поддерживает выравнивание, что приводит к искажению. Нам нужно изменить файл src/mDNSClientAPI.h, в нём необходимо добавить директиву компилятора __attribute__ ((packed)).

Для следующих типов также нужно добавить атрибуты packed.

• mDNSOpaque16
• mDNSOpaque32
• mDNSOpaque128
• mDNSAddr
• rdataSRV
• rdataMX

После внесения изменений, скажем, mDNSOpaque16 будет иметь следующий вид:

Примечание: это одна строчка, а между } и __ пробел отсутствует.

Между typedef и фигурной скобкой находятся специальные атрибуты компиляции. Мы рассказали об этих изменениях авторам mt-daapd, однако они специфичны для компилятора gcc arm и в следующей версии могут и не появиться.

После добавления атрибутов, выполните “make install”, после чего результат появится в ../sbin/. Осталось только сократить размер файла:

Готово!

Установка сервера iTunes на NSLU2

Настало время заняться установкой. Сначала нужно изменить файл mt-daapd.conf, находящийся в каталоге contrib. Файл достаточно подробно документирован, поэтому его легко настроить под ваши параметры и указать необходимые пути. В нашем случае, мы создали каталог верхнего уровня mt-daapd: /share/hdd/data/mt-daapd.

В него мы скопировали каталог admin-root, используемый для конфигурирования через web-интерфейс. Мы создали вложенный каталог cache для базы песен и скопировали contrib/mt-daapd.playlist в каталог mt-daapd, естественно, не забыв подкорректировать файл config. Для самой базы музыки мы создали каталог верхнего уровня MP3 и внесли соответствующие изменения.

После того, как вы отредактировали файл конфигурации, его нужно скопировать в каталог /share/hdd/conf/etc и создать ссылку из etc.

Теперь нужно скопировать двоичный файл src/mt-daapd в /share/hdd/conf/bin/. Затем для проверки скопировать несколько песен. Мы заметили, что сервер воспринимает файлы MP3 и AAC и может сканировать дерево каталогов, а не просто отдельный каталог. Мы скопировали файлы, используя для этого NFS, но вы также можете прибегнуть к помощи SMB или ftp.

Как и в случае с сервером NFS, здесь также нужно создать скрипт rc, который будет создавать ссылку и запускать процесс. Мы использовали для этого /etc/rc.d/rc.samba. Его нужно скопировать в /share/hdd/conf/rc.d/rc.mt-daapd, изменить для mt-daapd и запустить:

Просмотрев журнал /var/log/mt-daapd.log,можно увидеть несколько сообщений о состоянии, а команда ps -ax покажет работающий mt-daapd. Не пугайтесь, если увидите множество строчек в psoutput для mt-daapd.mtобозначает многопоточный (multi-threaded), а Linux показывает каждый поток отдельно.

Наслаждаемся музыкой

Настало время настоящей проверки – прослушивание музыки на компьютере. Сервер поддерживает версии iTunes для Windows и Mac OS X. В левой части, на панели “Source” в окне “iTunes”, можно заметить небольшой синий значок с названием сервера, указанным в файле конфигурации mt-daapd. Просто. Никакого поиска, настройки, ничего, всё работает само по себе.

Думаем, не стоит говорить, что делать дальше. Выбрать синюю иконку, посмотреть список музыки, выбрать и включить! Нам удалось без проблем слушать музыку одновременно на трёх ноутбуках, использующих беспроводные соединения. У этой маленькой коробочки гораздо больший потенциал, чем изначально реализовала Linksys!

iTunes в действии

Совет.Если у вас нет желания самому заниматься компиляцией, и вы хотите сразу получить готовые файлы, которые можно загрузить на NSLU2, то можете скачать архив объёмом ~185 кбайт отсюда.

Пока мы ограничивали себя лишь добавлением новых модулей NSLU2. Далее приготовьтесь выбросить гарантийный талон, копнуть немного глубже и внести более существенные изменения. Мы зальём собственную прошивку – и сможем запускать новые процессы автоматически.

Вносим изменения в прошивку

Мы уже успели “выжать” из NSLU2 достаточно много, но нет предела совершенству… К сожалению, при каждой перезагрузке наши новые процессы, такие как Telnet, NFS и mt-daapd, не запускаются автоматически. Конечно же, у нас есть готовое решение, которое позволит запускать все эти процессы автоматически при загрузке, как на обычном компьютере.

На обычном компьютере достаточно включить соответствующие скрипты в автозагрузку. На Linux нужно просмотреть последовательность запуска, начиная с первого процесса init и дальше по каталогу rc. Нам нужно запускать полученный скрипт где-то после инициализации сети. Однако, у NSLU 2 это не так-то просто. Последовательность загрузки находится на RAM-диске, поэтому при перезагрузке все изменения теряются.

Мы потратили довольно много времени, пытаясь найти на диске файл, к которому можно было бы добавить ссылку на наш файл. Один из вариантов – использовать файл crontab, который на Unix-системах задаёт время запуска процессов. К сожалению, на NSLU2 файл crontab также находится на виртуальном диске в ОЗУ.

Единственное, что могло подойти для наших нужд, – файл конфигурирования Samba. Samba позволяет запускать сторонние процессы, указанные в конфигурационном файле, но, в конечном счёте, это также ни к чему не привело. Мы планировали расширить функциональность без изменения стандартной прошивки Linksys, однако простого способа нам найти не удалось.

К счастью, пока мы раздумывали над тем, как перехватить процесс загрузки, другие исследователи NSLU2 предложили свои варианты. Они пытались найти возможность изменить саму прошивку Linksys. Если удастся изменить прошивку, то можно будет дополнить список загружаемых процессов теми, которые необходимы. Конечно, с первого взгляда это может показаться чересчур сложным, но поскольку система базируется на Linux, то структура образа флэш-диска достаточно стандартна и ясна.

План действий

В случае NSLU2 флэш-память разделена на четыре части.

• Redboot
• System Configuration
• Kernel
• RAM disk

Часть Redboot, по сути, очень схожа с обычным BIOS: она инициализирует аппаратное обеспечение при включении питания. System Configuration – это место хранения постоянных параметров устройства, например IP адреса. Kernel – образ операционной системы Linux, а RAM disk – место хранения всех библиотек, конфигурационных файлов, скриптов и исполняемых модулей, таких, как web-сервер. Для автоматического запуска новых процессов нам как раз и нужно изменить RAM-диск.

Мы планируем взять образ прошивки, разбить его на компоненты, изменить содержимое RAM-диска, собрать и закачать обратно. На словах всё просто, на самом же деле – нет. Любая ошибка может превратить технологичное устройство в бесполезный кусок пластмассы.

Примечание. Способ установки последовательного порта на NSLU2 описан в документации. При помощи последовательного порта можно выполнить восстановление работоспособности устройства даже при проблемах с прошивкой. Установка порта требует пайки, а описание процесса выходит за рамки этой статьи.

Совет.Мы не описали также способ подключения к загрузчику RedBoot через Telnet. Он может помочь при восстановлении прошивки – без необходимости разбирать устройство и заниматься пайкой. Подробнее о восстановлении прошивки посредством порта или интерфейса Telnet, можно узнать здесь.

На нашей машине под управлением Mandrake Linux мы создали рабочий каталог myFlash. Конечно, с тем же успехом можно использовать и любой другой каталог. В него нужно скачать прошивку с сайта Linksys. После распаковки вы увидите документацию со списком изменений и образ прошивки: NSLU2_V23R25.bin.

Теперь нам нужен инструмент, который позволит разбить этот файл на части. Мы использовали splitnslu, созданный Брайаном Ланцом (Brian Lantz). Кстати, копию файла мы разместили на сайте. Её можно найти здесь. После распаковки tar вы получите файлы README, .c и Makefile. Можно было бы использовать Makefile, но мы будем производить все изменения вручную.

Распаковка и изменения

Начнём с компиляции splitnslu.

Утилита позволяет как распаковывать, так и сжимать образ. Для получения диска RAM нужно распаковать прошивку.

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

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

Далее смонтируйте RAM-диск, для чего потребуются привилегии root.

Теперь копия RAM-диска NSLU2 подключена к каталогу nslu2. Для просмотра диска нужно перейти в соответствующий каталог при помощи команды cd, однако будьте осторожны. Любые случайные или преднамеренные изменения будут сохранены. Если вы что-то напутаете, то можете испортить прошивку.

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

Структура каталогов на RAM-диске оказалась стандартной. На NSLU2, как и на большинстве UNIX-систем, первым запускается процесс “init”. В нашем случае, мы определили, что init вызывает etc/rc, который, в свою очередь, выполняет etc/rc.sysinit, а последний – etc/rc.d/rc.1. В файле rc.1 можно увидеть все запускаемые демоны, например web-сервер. В него и следует добавить строчку для запуска нашего скрипта.

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

Перед сохранением изменений проверьте всё ещё раз. Мы создали новую строчку, просто скопировав строчку для web-сервера и изменив надпись “echo” и ссылку на rc.hook.

Сейчас нужно создать скрипт, который будет запускать файл rc.1. Скрипт будет сохраняться в каталоге rc.d и носить название rc.hook. Этот скрипт будет искать на жёстком диске другие скрипты и, если они существуют, запускать их. Ниже мы приводим наш вариант скрипта rc.hook.

Первая строка, в принципе, не нужна. Мы добавили её, чтобы сохранить единообразие с другими скриптами в этом каталоге. В следующей строке проверяется наличие запускаемого скрипта rc.custom в каталоге conf/rc.d на жёстком диске. Если файл существует, то он запускается.

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

В нашем случае скрипт rc.custom не будет обнаружен и rc.hook молча завершит работу. Убедитесь, что всё прошло, как нужно, и демонтируйте RAM-диск.

С изменением прошивки закончили. Если есть желание проверить ещё раз, то можно подключить RAM-диск снова, убедиться в том, что изменения сохранились, и затем отключить.

Запаковка и проверка

Настало время сложить все части вместе. Для этого нужно сначала запаковать файл RAM-диска.

В результате выполнения этой команды должен получиться файл ramdisk.gz. После этого необходимо создать образ при помощи параметра pack утилиты splitnslu.

После вывода нескольких строк будет создан новый образ newflash.bin. Для спокойствия рекомендуем сравнить размер получившегося файла с размером оригинала:

Размер полученного образа и оригинала должны быть одинаковыми.

Теперь, когда образ прошивки готов, можно приступать к её записи на NSLU2. Это, пожалуй, наиболее ответственная часть процесса. До сего момента мы ничего не изменяли на самом устройстве. Вы должны понимать, что рискуете испортить устройство, если в изменениях допущена ошибка.

Для обновления прошивки мы используем стандартный интерфейс Linksys. С помощью браузера следует перейти на страницу “Администрирование” (Administration) NSLU2. Далее выбрать пункт “Дополнительно” (Advanced), затем “Обновить” (Upgrade). Нажать на кнопку “Выбрать файл” (Choose File) и найти созданный файл newflash.bin. После этого, в нижней части страницы нужно нажать на кнопку “Начать обновление” (Start Upgrade).

Появится меню, после чего затаите дыхание и нажмите “OK”. При обновлении прошивки должны замигать индикаторы. Затем появится окно с сообщением о перезагрузке. Выберите “OK”. После минуты ожидания, должен прозвучать звуковой сигнал, который свидетельствует о том, что всё прошло нормально.

Теперь включаем Telnet, для чего нужно запустить стандартный скрипт Management/telnet.cgi, о котором мы говорили ранее. После этого загляните в каталог /etc/rc.d. Там появился новый скрипт rc.hook. Попробуем его запустить. Он предназначен для выполнения скрипта /share/hdd/conf/rc.d/rc.custom, которого пока ещё нет, так что его нужно создать. Сначала следует проверить, работает ли он. Мы сделали это следующим образом:

Нужно пометить его как исполняемый и попробовать запустить при помощи скрипта rc.hook.

Прозвучит сигнал, после чего выполните перезагрузку.

Примерно через минуту прозвучит стандартный сигнал запуска, а затем, ещё через несколько секунд, другой сигнал. Работает! Сейчас мы можем запускать любые процессы.

Добавляем скрипт

Пришло время создать новый файл rc.custom. После этого уже не придётся вручную запускать telnet.cgi для включения Telnet, а также скрипты NFS и mt-daapd. Последний раз активируем Telnet и входим в систему. Находим скрипт rc.custom и изменяем его для запуска упомянутых скриптов.

Для того, чтобы Telnet остался навсегда, необходимо добавить его запись в файл /etc/inittab. Поскольку мы больше не собираемся использовать SMB, скрипт удаляет соответствующий демон с диска RAM. Это удаление не постоянное, поскольку оно удаляет файлы только на RAM-диске для экономии пространства. Если вам потребуется SMB, то достаточно закомментировать строчки удаления. Следует помнить, что все команды, указанные в этом файле, либо должны выполняться в фоновом режиме, либо выполняться очень быстро, иначе процесс загрузки “зависнет”.

Ниже приведён наш вариант файла rc.custom:

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

Выполнив указанные изменения, необходимо будет снова перезагрузиться. На этот раз, после перезагрузки, доступ к Telnet должен работать сразу же – без запуска telnet.cgi. Сервер NFS тоже будет работать, а mt-daapd будет искать музыку на жёстком диске.

Теперь, когда вы знаете, как устанавливать новое ПО и менять прошивку, настало время рассмотреть ещё одну возможную модификацию. Сообщество NSLU2 выпустило специальную прошивку, которая не создаёт RAM-диск. При этом освобождается до 10 Мбайт памяти. Для системы с 32 Мбайт это немало.

Переходим на прошивку Unslung

В Интернете уже достаточно давно образовалось сообщество энтузиастов NSLU2. Поэтому вы можете найти различные службы, которые можно будет установить в систему. Нас же больше всего заинтересовала прошивка Unslung, которая расширяет возможности системы. Во-первых, она сохраняет стандартные функции Linksys, в то же время увеличивая опции по настройке. Разработчики-добровольцы хорошо “поковыряли” прошивку.

Во-вторых, прошивка добавляет стандартную схему пакетов, которая позволяет с лёгкостью устанавливать новые программные пакеты из Интернета. Наконец, прошивка освобождает до 10 Мбайт памяти. Неплохо для устройства с 32 Мбайт ОЗУ. Дополнительная память позволит запускать более требовательные приложения, например, сервер баз данных или полнофункциональный web-сервер.

Но как же разработчики смогли освободить память, нисколько не повлияв на стандартные функции Linksys и, в то же время, добавив новые возможности? Давайте посмотрим.

Альтернативы boot-time

Для начала, давайте разберёмся с архитектурой boot-time. Как мы уже упоминали, загрузка устройства начинается с RedBoot. Среди всего прочего, этот загрузчик отвечает за копирование ядра Linux и RAM-диска из флэш-памяти в ОЗУ.

Когда копирование будет завершено, управление передаётся ядру Linux. Оно стартует и монтирует RAM-диск в качестве корня или базовой файловой системы. Затем из файловой системы начинается процесс инициализации. В ходе его монтируются жёсткие диски и/или флэш-брелоки, а затем запускается web-сервер, файловый сервер и т.д. После чего устройство готово к работе.

Все базовые функции NSLU2 запускаются с RAM-диска, поскольку устройство может загружаться даже без подключённых жёстких дисков. Хорошая особенность, но слишком накладная. На 250-Гбайт жёстком диске много свободного места, но вам придётся умещать все необходимые исполняемые файлы, библиотеки, html-файлы и другую информацию на крошечном RAM-диске.

Что, если переместить все эти файлы с RAM-диска на жёсткий? Тогда можно было бы распоряжаться намного более объёмной файловой системой и освободить оперативную память, раньше занимаемую RAM-диском. Было бы неплохо сохранить обратную совместимость с процессом загрузки Linksys. Если к устройству подключён диск с файловой системой, то пусть она и используется. Если же диска нет, или нет файловой системы, то пусть создаётся RAM-диск. Именно такой подход и реализует прошивка Unslung. Теперь давайте познакомимся с ней повнимательнее.

Выбираем файловую систему

Очень часто ядро Linux компилируется с заданным идентификатором, указывающим на диск, который будет использоваться для корневой файловой системы. Он может находиться как в ядре, так и передаваться ядру загрузчиком. В случае NSLU2 Linksys зашила идентификатор в ядро, указав на RAM-диск для корневой файловой системы. Но ведь Linksys ничего другого и не предполагала. Впрочем, как и другие параметры Linux, зашитый идентификатор можно обойти.

Linux имеет возможность определения местонахождения корневой файловой системы. Эта возможность часто используется, когда одно ядро должно работать на нескольких аппаратных платформах. К примеру, одно и то же ядро может работать на системе, где корневая файловая система находится на диске IDE или SCSI. Перед тем, как Linux загрузится, система определит загрузочные диски и попытается найти нужный корень. После этого Linux смонтирует корневую файловую систему и продолжит нормальную загрузку. Эта функция и используется в Unslung.

Код Unslung для определения загрузочной файловой системы не входит в ядро. Вместо этого он включён в функцию Linux initrd. Эта функция создаёт специальный RAM-диск, который содержит пользовательский код, выполняемый до монтирования корневой файловой системы. Разработчики Unslung добавили ложный указатель корня в ядро, а затем добавили код в initrd, который проверяет диски и находит реальную корневую файловую систему. Если таковая будет обнаружена на одном из подключённых жёстких дисков, то Linux будет использовать её, а не RAM-диск. После чего 10 Мбайт RAM-диска будут освобождены для других нужд.

Установка Unslung

Ещё одна интересная особенность Unslung – богатые возможности по настройке. Как и в предыдущей части нашей статьи, Unslung добавляет ссылки на стандартные скрипты запуска – но не только. Скрипты Unslung, названные “обходными скриптами”, добавляют ссылку в каждый загрузочный скрипт. В результате, вы можете добавлять код в любой момент загрузки.

Кроме того, обходные скрипты позволяют полностью отменять стандартные функции Linksys. К примеру, если сервер SMB вам больше не нужен, обходной скрипт сделает “return 0”, в результате чего оставшаяся часть Samba в скрипте Linksys будет пропущена. Также можно запустить Samba со своими опциями или использовать свою собственную версию Samba. Подобные возможности добавлены ко всем загрузочным скриптам Linksys.

Наконец, в Unslung присутствует стандартный пакет ipkg, который изначально был разработан для наладонных систем Linux. После чего этот пакет расширили до других устройств с ограниченными ресурсами. Использование стандартного пакета позволяет легко добавлять функции к устройству.

К примеру, для добавления сервера Secure Shell достаточно будет выполнить всего одну команду. После этого пакет будет скачан из Интернета, сконфигурирован и установлен. На момент выхода статьи в Интернете уже присутствовало 19 пакетов, однако в будущем их число будет значительно расширено – ожидается более 1500 пакетов для NSLU2!

Впрочем, довольно теоретизировать – перейдём к практике. Мы предполагаем, что вы уже включили Telnet на устройстве, как показано в первой секции нашей статьи.

Если вы следовали нашим инструкциям в других разделах, то сначала нужно зарезервировать наши предыдущие изменения. Прошивка Unslung использует те же каталоги, которые были созданы нами в папке /share/hdd/conf, – это bin, etc и rc.d. Мы просто перенесём наши каталоги и позволим Unslung выполнить свою установку. А затем мы вернём наши изменения.

Поэтому зайдите на NSLU2 с помощью Telnet и переименуйте каталоги.

На этот раз мы не будем создавать собственную прошивку, использовав UNSLUNG-1.11-beta.zip (скачать можно здесь). Скачайте прошивку Unslung и распакуйте её в рабочую папку. Вы получите три файла: README и два образа прошивки. Один образ предназначен для использования USB-дисков, форматированных под Linux ext3, а второй – для системы Windows VFAT. В нашем случае мы решили использовать диски VFAT, поскольку при этом поведение устройства оказывается ближе к стандартному. Соответственно, мы взяли образ UNSLUNG-1.11-beta-V23R25.bin. В файле README содержится подробная информация о прошивке, а также инструкции по созданию собственной версии прошивки.

После распаковки выключите NSLU2 и отключите жёсткие диски. Включите NSLU2 обратно и прошейте образ Unslung с помощью стандартной утилиты модернизации Linksys. После успешного процесса и загрузки, включите Telnet, используя URL Management/telnet.cgi (как показано в первой части статьи). После этого зайдите на устройство с помощью Telnet, используя имя пользователя root и пароль uNSLUng.

Исследуем возможности Unslung

Сейчас мы используем новую прошивку, но набор функций, на первый взгляд, не изменился. Мы по-прежнему используем стандартный RAM-диск, без каких-либо новых пакетов. Теперь подключим диск к USB-порту 1. Через несколько секунд введите команду df – она должна показать смонтированный диск.

Теперь давайте создадим корневую файловую систему на нашем диске – скопируем RAM-диск. Для этого можно использовать команду:

По мере копирования RAM-диска на жёсткий диск будут выводиться кое-какие сообщения. После завершения наберите:

Устройство будет перезагружено. После загрузки вновь включите Telnet, использовав URL telnet.cgi. Введите имя пользователя и пароль. Команда df должна показать раздел conf, смонтированный в каталоге “/” и в оригинальном местоположении, где утилиты Linksys и ожидают его увидеть. Теперь у нас есть 10 Мбайт освобождённой памяти! Для проверки введите:

Вы должны увидеть небольшой объём памяти, отмеченный как free и большое количество в пунктах buffers и cached. Эта память доступна для приложений.

Теперь давайте включим Telnet через обходной скрипт. Информацию по созданию обходных скриптов можно получить из файла README, поставляемого вместе с прошивкой Unslung. Мы создали копию /etc/inetd.conf в каталоге /opt/etc/. Затем в каталоге /unslung мы создали xinetd-версию обходного скрипта, назвав её rc.xinetd.

Команда будет выполняться перед запуском inetd, просто удостоверяясь, что конфигурационный файл запустил Telnet. Строчка “return 1” разрешает выполнение остальной части стандартного скрипта. Если каталоги вас смутили, то вы должны посмотреть, как обходные вызовы осуществляются в оригинальных файлах rc, к примеру, в /etc/rc.d/rc.xinetd. Теперь, после перезагрузки, Telnet должен запускаться автоматически.

Настало время добавить несколько приложений.

Добавляем приложения

Как мы уже упоминали выше, Unslung использует систему пакетов ipkg. Сначала давайте обновим эту систему. Для этого выполните команду “ipkg” с параметром “update”.

Предупреждение. Проверьте, что NSLU2 подключён к Интернету, иначе обновление не сработает.

Команда выведет несколько строчек оповещений. Если команда ipkg выведет сообщение об ошибке, просто запустите обновление снова. Если же ошибки не исчезают, то проверьте настройку на NSLU2 шлюза по умолчанию и DNS-сервера (на стандартном экране настройки Linksys).

Теперь давайте посмотрим, какие пакеты доступны для нашего устройства.

Вы должны получить список пакетов, включающий nfs и mt-daapd. Давайте попробуем установить nfs. Сначала нам понадобится portmap.

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

В следующую перезагрузку nfs должен работать. Вы можете заметить ещё один пакет nfs в списке ipkg. Это другая версия, которая поддерживает v3 протокола nfs. Самая значительная особенность v3, по нашему мнению, – это поддержка файлов больше 2 Гбайт. У нас не было достаточно времени, чтобы выявить другие новшества. Если вы желаете попробовать nfs v3, то сначала удалите старый пакет nfs, используя функцию “remove” с ipkg.

Если вы желаете установить mt-daapd, то используйте следующую команду:

С помощью ipkg сервер iTunes устанавливается намного легче. После установки, если вы следовали нашей статье, скопируйте зарезервированные файлы в каталог /etc.

Если это ваша первая установка mt-daapd, то скопируйте конфигурационный файл из каталога /opt/etc в папку /etc. Кстати, у некоторых пользователей возникали проблемы доступа к файлам MP3. Если они у вас тоже появятся, то либо измените права на дерево MP3, либо “runas” в конфигурационном файле – чтобы там был пользователь, обладающий достаточными правами. Проверьте конфигурацию mt-daapd ещё раз, чтобы были правильные пути, – и после перезагрузки вы получите рабочий сервер iTunes!

Теперь давайте попробуем установить новый пакет. Telnet – штука полезная, но небезопасная. Пароль и имя пользователя Telnet посылаются по сети в открытом виде. Намного лучшим решением является secure shell (ssh). Для ограниченных по ресурсам устройств лучше использовать сервер dropbear. Устанавливать его очень легко.

Установка в данном случае будет более длительной, поскольку необходимо сгенерировать криптографические ключи. Когда она завершится, вы получите сервер ssh. Теперь с Linux или Macintosh OS X можно будет входить на NSLU2 по ssh.

Как только вы включите ssh, мы рекомендуем удалить скрипт Telnet из каталога /unslung.

Дальнейшее расширение возможностей NSLU2

Регулярно выполняйте обновление ipkg (ipkg update) и просматривайте доступные пакеты (ipkg list). Вы также можете присоединиться к сообществу разработчиков и предложить свой пакет.

Также вы можете поделиться с разработчиками своими отзывами. Для этого достаточно перейти на страницу NSLU2 Yahoo.

Конечно, Unslung – мощная прошивка, но это не финальный этап эволюции NSLU2. Как мы понимаем, NSLU2 постепенно из сетевого хранилища превращается в платформу с открытым исходным кодом. В следующей статье, посвящённой NSLU2, мы расскажем о других возможных применениях.

Ну, а пока мы рекомендуем отслеживать страницы Linux на NSLU2 и сайт группы разработчиков NSLU2 Linux.