CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
24.10.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: LiveCD

Заметки

Загрузить Linux на удалённом win-хосте

Серьёзно?

Описанная мной ранее модификация RIP для "лечения" win-машин показала себя достаточно эффективной. Тем полезнее, чем "изысканнее" malware. Антивирусы — хорошее подспорье в борьбе за "здоровье" IBM PC, но много важнее, на мой взгляд, возможность "рассмотреть" и модифицировать win-систему без её загрузки. Вот только необходимость "непосредственного контакта" утомляет. Особенно, если клиентский компьютер находится за сотни километров... Но так ли уж необходим этот "непосредственный контакт"? При наличии на компьютере клиента двух файлов, которые, собственно, и составляют RIP, — отнюдь. А что такое 85 MiB (суммарный размер файлов "полного" RIP) для современных коммуникаций? Пустяки. Тем более, что, в данном случае, можно ограничиться вариантом без Х-ов (45 MiB), а то и его сократить вдвое. Более того: об этом можно позаботиться заранее, подготавливая станцию к эксплуатации.

Загрузить — как?

Итак, будем считать, что файлы RIP (kernel и rootfs.cgz) на удалённом компьютере имеются и находятся в каталоге /RIP одного из разделов. Популярная когда-то loadlin.exe под XP/NTFS пригодится вряд ли, а вот GRUB4DOS — вполне. Из состава этого пакета нас интересует только grldr (менее 200-т KiB — никаких проблем). Повторять описание GRUB4DOS не хочется, так что напомню только, что grldr может быть запущен стандартным NT-загрузчиком (\ntldr) как альтернативная ОС. Для этого его достаточно указать в \boot.ini.

Помимо наличия загрузчика нужно правильно сконфигурировать меню (\menu.lst), используемое grldr при запуске. При наличии минимальных представлений о конфигурировании GRUB это не составляет труда. Нужно всего лишь указать местоположение тех самых двух файлов RIP. Например, так:

title Linux (rescue-RIP)
root (hd0,6)
kernel /RIP/kernel vga=normal keymap=ru4 root=/dev/ram0
initrd=/RIP/rootfs.cgz

Но если указание каталога трудности не представляет (сами же только что создавали и наполняли), то с указанием раздела (root (hd0,6)) трудности не исключены. Буквенное обозначение разделов в MS Windows, практически: её "внутреннее дело". Так что, отказавшись от загрузки этой ОС, мы заодно "хороним" в её недрах и ответ на вопрос: какой раздел стоял за незатейливым "С:" или "D:"? Если каталог /RIP создавался на загрузочном диске системы, то уточнить его номер можно в \boot.ini — для своих целей MS Windows использует численное обозначение разделов, справедливо полагая, что буквенные обозначения, сохраняемые "на память" от CP/M, в настоящее время — лишь дополнительный источник заблуждений.

А вот если каталог /RIP размещён в каком-нибудь ином разделе (что, вообще говоря, достаточно разумно), то придётся провести некоторые изыскания. В рамках Windows это проще всего сделать, на мой взгляд, с помощью утилитки diskpart. Консольной, разумеется (как это принято у M$). За описанием утилиты, пожалуйста, к MicroSoft, но если вкратце...

  • запускаем в консоли: 'diskpart', оказываемся в её "shell";
  • выбираем в качестве объекта диск: 'select disk 0' (диски у M$ нумеруются как раз с нуля);
  • смотрим, что за разделы есть на диске: 'list partition';
  • и что за тома (буквы) определены в системе: 'list volume';
  • выход — банальное 'exit'.
Интересующее число — номер раздела. А соответствие "буквам" тома предстоит определить, исходя из типа и размера разделов. Обычно это не слишком сложно. В отличие от дисков, разделы M$ нумерует, начиная с единицы. То есть номер раздела для GRUB (где вся нумерация начинается с нуля) будет на единицу меньше.

Не лишним будет, наверное, напомнить, что M$ использует сквозную нумерацию разделов, тогда как GRUB/Linux первые четыре номера резервируют за первичными разделами (включая расширенный). Только GRUB начинает нумерацию с нуля, а Linux — с единицы. Таким образом, при наличии на диске только одного первичного и одного расширенного разделов (достаточно типичная для MS Windows ситуация), первый логический раздел будет будет иметь номер "3" с точки зрения MS Windows и номера "4"/"5" с точки зрения GRUB/Linux. И так далее... Несколько витиевато, но если вы берётесь за редактирование MS Windows из-под Linux, то структура разделов винчестера уже должна представляться достаточно прозрачной.

Наличие "где-нибудь" файлов RIP, а в корневом разделе системного диска — grldr и соответственно отредактированного menu.lst являются условиями, достаточными для загрузки Linux на удалённом компьютере, работающем под управлением MS Windows. Теперь, как уже сказано выше, нужно только отредактировать файл boot.ini, находящийся в корневом каталоге системного диска, и инициировать перезагрузку. Файл boot.ini может выглядеть, например, так:

[boot loader]
timeout=1
default=C:\grldr
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional RU" /noexecute=optin /fastdetect
C:\grldr="GRUB4DOS loader"
В файле произведены два изменения: добавлена строка опции загрузки "GRUB4DOS loader" и она же объявлена опцией "по умолчанию". При старте системы на одну секунду (timeout=1) появится возможность выбора, после чего будет загружен GRUB4DOS, который в соответствии с \menu.lst загрузит RIP.

Загрузить — что?

О том, как с помощью RIP можно побороться с malware, говорилось ранее, но чтобы воспользоваться этими советами, нужно сначала получить доступ к этому самому RIP-у — ведь загружен-то он на удалённом хосте. Для этого, очевидно, предварительно нужно позаботиться об автоматическом "поднятии" сетевого интерфейса RIP и запуске в его рамках какого-нибудь сервиса, обеспечивающего удалённый доступ. Сервис SSH, входящий в состав RIP, вполне нас устроит. Для обеспечения его автоматического запуска при загрузке опять потребуется модификация образа корневой файловой системы (rootfs.cgz). На сей раз нужно сделать "исполняемым" файл /etc/rc.d/rc.sshd и "раскомментировать" две строки в файле /etc/ssh/sshd_config:

  • строка 'PermitEmptyPasswords yes' сделает возможным вход с пустым паролем;
  • а строка 'PermitRootLogin yes' разрешит подключение root-у.
Вопиющие нарушения правил безопасности, не правда ли? Но поскольку речь идёт лишь о спасательных операциях на "прибитой" вирусами системе, а RIP изначально имеет только одну учётную запись (root) и именно с пустым паролем, я предлагаю с этим смириться. Хотя никто не мешает сделать в своём варианте RIP ещё одного пользователя и именно ему разрешить доступ по ssh.

Осталось поднять сетевой интерфейс. Сами по себе команды инициации интерфейса элементарны, но как-то ещё нужно обеспечить возможность передачи сетевых настроек скрипту, выполняемому при загрузке. Для этого предлагаю файл /etc/rc.d/rc.local дополнить нижеследующими строками. Так, вот эти строки ищут в командной строке загрузки параметр net=ip_address и, если находят, то присваивают переменной net адрес ip, введённый в качестве параметра:

for x in $(cat /proc/cmdline); do
  case $x in
    net=*)
    net=${x#net=}
    ;;
 esac
done
Эти строки прекращают выполнение скрипта, если параметр 'net=ip_address' среди опций загрузки не обнаружен:
if [ -z $net ]
  then
    echo "Not configured network!"
  exit
fi
А вот эти, последние, строки будут выполняться только в том случае, если параметр 'net=ip_address' — имеет место в командной строке загрузки:
if [ $net == 0.0.0.0 ]
  then
    echo "DHCP client started for eth0..."
    /sbin/dhcpcd -q -t 30 eth0
  else
    echo "eth0 static address — $net"
    NETMASK=255.255.255.0
    BROADCAST=`/bin/ipmask $NETMASK $net|cut -f1 -d' '`
    /sbin/ifconfig eth0 $net broadcast $BROADCAST netmask $NETMASK
fi
Вариантов сетевых настроек предусматриваем только два:
  • динамический адрес, назначаемый DHCP (net=0.0.0.0);
  • статический ip-адрес (net равен любому адресу, отличному от нуля).
Очевидно, что имеет место два упрощения: конфигурируется только интерфейс eth0, а маска подсети во всех случаях предполагается равной 255.255.255.0. Но, поскольку речь идёт о компьютере офисной локальной сети, то, в подавляющем большинстве случаев, такие упрощения оправданы.

Нужно ли оговаривать, что параметр 'net=ip_address' должен стать частью \menu.lst? Мне это представляется очевидным. Но, на всякий случай, вот окончательная строка загрузки для DHCP-варианта:

...
kernel /RIP/kernel vga=normal keymap=ru4 root=/dev/ram0 net=0.0.0.0
...

Всё, собственно...

Любой файрвол, отделяющий локальную сеть от Интернет, должен обеспечивать "проброс" порта от файрвола к любой из рабочих станций. Если же файрвол работает под одной из posix-систем, то появляется альтернативная возможность: ssh-клиент может быть запущен непосредственно в его консоли.

Что касается самого ssh-клиента, то для posix-систем — это неотъемлемый компонент. Но и putty под Windows — вполне удовлетворительное решение.

Ложка "дёгтя"

Как нетрудно догадаться, по окончании "спасательных" операций \boot.ini нужно вернуть в первоначальное состояние и опять перегрузить компьютер. Это не сложно, если Linux загрузился, и вы получили к нему доступ. А если — нет? Исключить возможность столкновения с hardware, на котором загрузка не закончится или сетевая карта не найдёт должной поддержки в ядре, к сожалению, нельзя. В такой ситуации клиент, в лучшем случае, останется перед окном приглашения RIP, а в худшем — перед сообщением о kernel panic или чем-то подобным. И если в лучшем случае ему ещё можно помочь советом по телефону, то в худшем без альтернативного livecd загрузку не восстановить.

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

Если же вы хотите загрузить Linux на совсем "незнакомой" удалённой станции, то настоятельно рекомендуется ознакомиться с её аппаратной конфигурацией. Да и это поможет вам только в том случае, если вы хорошо себе представляете список поддерживаемого актуальным ядром оборудования. Так что "не всё скоту масленица"... А вы предполагали абсолютно беспроблемную загрузку "чужой" ОС на удалённом компьютере? Сожалею, но рано или поздно вы будете разочарованы.




Комментарии

hatman, Wed Feb 11 15:26:23 2009:
Спасибо, интересное описание одного из методов. надо взять на заметку.

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds