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

Описанная мной ранее модификация 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/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"

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

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

• строка 'PermitEmptyPasswords yes' сделает возможным вход с пустым паролем;
• а строка 'PermitRootLogin yes' разрешит подключение root-у.

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

if [ -z $net ]
  then
    echo "Not configured network!"
  exit
fi

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 равен любому адресу, отличному от нуля).

Нужно ли оговаривать, что параметр '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