Большой архив статей, книг, документации по программированию, вебдизайну, компьютерной графике, сетям, операционным системам и многому другому
 
<Добавить в Избранное>    <Сделать стартовой>    <Реклама на сайте>    <Контакты>
  Главная Документация Программы Обои   Экспорт RSS E-Books
 
Поиск по сайту


 

  Раздел: Компьютерная документация -> Операционные системы -> Linux

 

Загрузить 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 на совсем "незнакомой" удалённой станции, то настоятельно рекомендуется ознакомиться с её аппаратной конфигурацией. Да и это поможет вам только в том случае, если вы хорошо себе представляете список поддерживаемого актуальным ядром оборудования. Так что "не всё скоту масленица"... А вы предполагали абсолютно беспроблемную загрузку "чужой" ОС на удалённом компьютере? Сожалею, но рано или поздно вы будете разочарованы.

Автор: Владимир Попов
Источник: www.citkit.ru



  Добавить закладку на материал: 


Ссылки по теме
Wi-Fi. Linux. Краткий курс. часть 1
Wi-Fi. Linux. Краткий курс. часть 2
Linux... на ноутбуке?
Слово о дистрибутивах
Дистрибутивы Linux: краткий обзор
Концепция Base Linux и ее воплощение
Безопасность. Linux vs. Windows
Миграция в Линукс. Путевые заметки

Вся документация Linux

 

Компьютерная документация от А до Я - Главная

 

 
Интересное в сети
 
10 новых программ
CodeLobster PHP Edition 3.7.2
WinToFlash 0.7.0008
Free Video to Flash Converter 4.7.24
Total Commander v7.55
aTunes 2.0.1
Process Explorer v12.04
Backup42 v3.0
Predator 2.0.1
FastStone Image Viewer 4.1
Process Lasso 3.70.4
FastStone Image Viewer 4.0
Xion Audio Player 1.0.125
Notepad GNU v.2.2.8.7.7
K-Lite Codec Pack 5.3.0 Full


Наши сервисы
Рассылка новостей. Подпишитесь на рассылку сейчас и вы всегда будете в курсе последних событий в мире информационных технологий.
Новостные информеры. Поставьте наши информеры к себе и у вас на сайте появится дополнительный постоянно обновляемый раздел.
Добавление статей. Если вы являетесь автором статьи или обзора на тему ИТ присылайте материал нам, мы с удовольствием опубликуем его у себя на сайте.
Реклама на сайте. Размещая рекламу у нас, вы получите новых посетителей, которые могут стать вашими клиентами.
 
Это интересно
 

Copyright © CompDoc.Ru
При цитировании и перепечатке ссылка на www.compdoc.ru обязательна. Карта сайта.
 
Rambler's Top100