 |
|
|
|
Автоматизация MS Windows, или AutoIt как мечта эникейщика. Часть 3
Автоматизация MS Windows, или AutoIt как мечта эникейщика Часть 3 Вы уже познакомились с возможностями AutoIt по автоматизации работ в Windows. Узнали, как с его помощью решаются рутинные задачи администрирования. Сегодня займемся созданием диска автоматической установки операционной системы и необходимых приложений. Здесь AutoIt позволит сделать выбор приложений независимым от типа инсталлятора, используемого разработчиком, и заодно настроить рабочую станцию. Создаем диск автоматической установки Если мы собираемся вас инструктировать перед обновлением программного обеспечения системы, не беспокойтесь. Мы ведь никуда не денемся, когда это закончится! За основу возьмем диск Windows XP Professional с интегрированным 2-м сервиспаком, что на сегодня является наиболее свежей версией. Это будет единственное соприкосновение с Windows в процессе производства. Все остальные действия будем совершать в среде Linux. Базовые сведения по процессу автоматической установки Windows, вы можете получить, воспользовавшись ссылками [1, 2]. Теперь перейдем от теории к практике. Сначала подготовим исходный материал для построения дистрибутивного диска. Здесь особо отмечу, что не стоит излишне демонизировать этот процесс. Дистрибутив – это обычный набор архивов, записанный вместе с установщиком на CD-диск. Совершенно не важно, какое имя имеет полученный диск, какая у него дата создания, и какая контрольная сумма у имиджа этого диска и файлов, в него входящих. Точно также не следует надеяться найти загрузчик диска в 20 секторе. Главное, чтобы установщик на таком диске нашел все нужное для своей работы. Очевидно, что изначально установщик имеет очень много встроенных возможностей. Но так как нас интересует лишь один вариант установки, то можно с уверенностью утверждать, что часть файлов с оригинального дистрибутивного диска, скорее всего, никогда не понадобится далее, значит за их счет можно выделить больше места для размещения приложений. Подготовим дистрибутивные файлы Итак, приступим. Все пути в Linux будут приводиться с использованием «/» и задавая их положение в Linux-нотации, а пути в Windows – с «» и с указанием буквы, использованного устройства или подразумевая положение от рассматриваемого корня, например от I386 (см. листинг 1). Листинг 1. Содержимое исходного диска, примонтированного в точке /cdrom /cdrom # ls –als
Выберем местом создания нового дистрибутива /heap/Windows/uawsp2. Скопируем туда часть исходного диска, исключив очевидно лишнее, и добавив то, что указано в листинге 2. Листинг 2. Рабочая директория после копирования исходного диска /heap/Windows/uawsp2 # ls –als
Прокомментирую состав файлов в корне дистрибутивного диска:
Обратите внимание, регистр символов для наименований служебных меток не имеет значения и все имена соответствуют правилу 8.3. Это верно только в отношении указанных файлов. Все остальные названия файлов уже не ограничиваются спецификацией имен древнего FAT и ортодоксальной версии ISO9660. Маркерные файлы, содержимое которых далее никак не обрабатывается, то есть может быть любым, и Bootfont.bin берем с исходного диска. Иконка имеет чисто косметическое значение (см. листинг 3). Листинг 3. Файл автозапуска /heap/Windows/uawsp2 # cat autorun.inf
Самым важным преобразованиям подвергнем директорию с дистрибутивными файлами I386. В исходном диске она содержит следующие поддиректории: Листинг 4. Поддиректории с дистрибутивными файлами /cdrom # ls -als I386 | grep dr-x
При копировании исключим те поддиректории, что относятся к вариантам установки Windows XP в режиме миграции и обновления с предыдущих версий. Получится следующее: Листинг 5. Дистрибутивные поддиректории, которые надо составить /heap/Windows/uawsp2 # ls -als I386 | grep dr-x
Это позволит сильно сократить размеры создаваемого дистрибутива и освободит место для размещения дополнительных программ. Директории $OEM$ и boot будут созданы и наполнены содержимым в процессе дальнейшей работы. В сумме получилось весьма немного: Листинг 6. Объем оставшегося дистрибутива /heap/Windows/uawsp2 # du –sh
Для дополнительных программ остается еще почти 300 Мб, а с учетом overburn еще больше. Теперь заполним директорию boot. Это техническая директория, используемая в процессе построения имиджа загружаемого диска. В нее надо будет поместить загрузчик для ISO9660 и далее указать ее же как целевую для размещения каталога диска. В собранном диске эта директория вместе с содержимым будет скрыта от просмотра. Так, в нее надо положить загрузочный сектор для Windows. Как уже было сказано, нет простого способа экстрагировать этот сектор из рабочего имиджа. Дело в том, что ISO9660 имеет структуру подобную архивному файлу, и положение загрузочного сектора определяется порядком его обхода при построении имиджа. Поэтому рекомендуется или найти этот сектор в Интернете, или загрузить прилагаемый к этой статье [3]. Загрузочный сектор в ходе своего выполнения обращается к двум другим фазам загрузки (см. листинг 7). Листинг 7. Подстроки, выделенные из загрузчика /heap/Windows/uawsp2 # strings boot/ntboot.bin
Можно понять по последней строке, что они размещены в директории I386 под именами SETUPLDR.BIN и BOOTFIX.BIN. Последний из них является тем самым программным кодом, который запрашивает разрешения загрузки с CD: Листинг 8. Подстрока сообщения, сопровождающего загрузку /heap/Windows/uawsp2 # strings I386/BOOTFIX.BIN
И в случае нажатия любой клавиши на локальной клавиатуре управление передается на SETUPLDR.BIN, который в свою очередь и производит запуск процедуры установки. Вот окончательное содержимое директории boot: Листинг 9. Содержимое директории boot /heap/Windows/uawsp2 # ls -als boot
Приступаем к установке Установка Windows XP производится в три этапа. Каждый из которых начинается с загрузки, и все, кроме последнего, завершаются перезагрузкой. Перечислю все происходящие внутри этапов технологические действия в порядке их наступления и попутно прокомментирую самое важное. Первый этап Происходит в текстовом режиме:
Первые три пункта уже были описаны. Четвертый, на котором, кстати, проверяется синтаксическая правильность используемых файлов, весьма интересен. Txtsetup.sif содержит подробное описание всех дистрибутивных файлов и дисковых меток win51ip.sp*, задает режимы запуска первой фазы «/fastdetect /noguiboot /nodebug» и многое другое. Читать это «чудище» размером в 468 Кб одно удовольствие. Модифицируя указанный текстовый файл, можно с Windows творить что угодно. В этом же файле должны быть «прописаны» и автоматически устанавливаемые драйвера. Но самый важный в контексте рассматриваемой темы – файл winnt.sif. Это тот самый файл ответов, который позволяет выполнять автоматическую установку и настройку Windows. Этот файл надо будет создать. Его кодировка, как и всех текстовых управляющих файлов, должна соответствовать кодовой странице cp866. Но так как вся разработка ведется под Linux, то первоначальный набор этого файла производится в локали среды разработки, в данном случае в koi8-r, а затем полученный файл конвертируется в нужную кодировку и размещается в директории I386 (см. листинг 10). Подготовленную версию файла вы можете посмотреть по ссылке [4]. Листинг 10. Конвертация в cp866 # iconv -f koi8-r -t cp866 WINNT.SIF.koi8r | awk "{print $0 "?15"}" > /heap/Windows/uawsp2/I386/WINNT.SIF Текст обильно снабжен комментариями. Поэтому не буду приводить его полностью. Лишь отмечу то, что имеет вариантную настройку, важную для нас. На первом этапе у нас есть выбор, сделать ли установку полностью автоматической или оставить ручной выбор раздела. Выберем последнее в секции, определяющей размещение данных: [Data] ; Включим режим ручного выбора раздела установки. AutoPartition=0 При полностью автоматической установке не произойдет ничего плохого, если все работы производятся только в рамках предприятия. Но ручной вариант позволяет применять полученный диск еще и в приватной практике, когда жесткие диски разбиваются не столь единообразно. Для этого в секции, отвечающей за режимы автоматической установки, укажем запрет автоматического переразбиения диска и автоматического преобразования файловой системы: [Unattended] ; Запрещаем автоматическое переразбиение диска. Repartition=No То есть все необходимые вопросы, касающиеся размещения устанавливаемой системы на жестком диске будут заданы персоне, присутствующей за консолью рабочей станции. Такой режим позволит избежать ошибок из-за случайно оставленных в лотках дисках автоматической установки и при необходимости избежать уничтожения локальных данных. На этом же этапе все специально подготовленные данные с дистрибутивного диска будут скопированы на целевой раздел. Дополнительные данные помещаются в директорию $OEM$. Например, как показано в листинге 11. Листинг 11. Размещение дополнительных обоев /heap/Windows/uawsp2 # ls -als $OEM$/$$/Web/Wallpaper
А если нужно добавить некоторые программные файлы так, чтобы они далее могли находиться автоматически, то следует их разместить так, как показано в листинге 12. Листинг 12.Размещение дополнительных программ /heap/Windows/uawsp2 # ls -als $OEM$/$$/System32
Другими словами, директория $OEM$/$$ соответствует директории установки ОС на целевом диске. Если следовать установкам по умолчанию, то для Windows XP это C:WINDOWS. Чтобы в директории C:Documents and Settings разместить специальную команду, которая будет далее использоваться для настройки профиля вновь создаваемых локальных пользователей, то следует сделать так: Листинг 13. Размещение дополнительных команд /heap/Windows/uawsp2 # ls -als $OEM$/$1/Documents and Settings
Все эти файлы будут на первом этапе скопированы в одноименные директории на локальном диске так, что его корень будет соответствовать директории $OEM$/$1 на дистрибутивном диске. Придерживаться правила 8.3, как и было ранее заявлено, здесь не следует. Таким же образом с создаваемого установочного диска будут переноситься дистрибутивные файлы прикладного программного обеспечения. Достаточно все нужные файлы поместить в директорию $OEM$/$1/InstData, и в процессе выполнения первого этапа установки все они будут скопированы в C:InstaData. После установки эту директорию надо будет не забыть удалить, и лучше сделать это автоматически. Второй этап Следующий этап продолжается в графическом режиме. Его основные шаги перечислены ниже. В некоторых строках записаны временные метки, соответствующие этому этапу, так называемые T-*. Кстати сказать, временная метка не имеет точного соответствия с затратами времени на процесс установки, который всецело зависит от мощности компьютера.
Это самый длительный этап установки. Он, как и следующий, будет автоматизирован полностью. Фактически, во время 2-го этапа ставится ядро операционной системы. Рассмотрим некоторые важные действия и настройки: На этом этапе задается пароль встроенного бюджета Администратор. Его можно указать в зашифрованном виде, но тогда полученный диск лишится своей универсальности, т. к. пароль, назначенный в процессе установки, носит явно временный характер, то выберем самую простую его форму. [GuiUnattended] ; Задаем пароль Администратора. AdminPassword="admin» EncryptedAdminPassword=No Второй параметр из секции, отвечающей за автоматическую установку в графическом режиме, задает число автоматических перезагрузок. Обратите внимание, на третьем этапе штатной установки будут запущены инсталляторы прикладного программного обеспечения, после чего перезагрузка будет произведена еще раз. То есть нужно установить счетчик автоматических авторизаций на 2. А если для выполнения каких-то действий, например, перезагрузки в режиме сохранения для выполнения некоторых модификаций, потребуется еще одна перезагрузка, то счетчик надо будет увеличить дополнительно. [GuiUnattended] ; Установим режим автоматического входа в систему от имени Администратора AutoLogon=Yes ; Число автоматических входов. AutoLogonCount=2 Следующий раздел отвечает за пользовательские данные. Применительно к Windows, это практически данные покупателя. Итак, мы снова вернулись к вопросу лицензирования. Рассмотрим его подробнее. В процедуре обычной установки пользователю предлагается ввести код с установочного диска. Теоретически эта проблема решается следующими строками из winnt.sif: [UserData] ; Подставляем установочный ключ для Windows XP ProductID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX Где вместо ХХХХ подставляется код лицензии. Но дело в том, что если бы защита от копирования Windows ограничивалась только эти кодом, то всякая автоматическая установка означала бы нарушение лицензии, так как приводила бы к установке одной лицензионной копии продукта на множество компьютеров. Хитроумные обитатели предместья Сиэтла отлично понимали, что загнали себя в тупик. И тогда появились специальные механизмы активации Windows или WPA (Windows Product Activation) вместе со счетчиком наработки или OOBE (Out Of Box Experience). Теперь автоматическая установка копий ОС под идентичными лицензионными ключами не снимала необходимость активации копии в течение 30 дней. Для ряда потребителей это уже достаточный уровень решения проблемы автоматической установки. Те же, кто требует большего, должны выбрать или легальный путь преодоления этой проблемы, или обходной. Как уже было сказано выше, легальным является способ использования такой лицензии, которая предусматривает серийную установку. Для MS Windows это так называемая корпоративная лицензия или VL (Volume License). Здесь надо очень тщательно следить за тем, чтобы число установок не превысило числа оплаченных копий. Обходной путь заключается в создании такого дистрибутива, чтобы механизмы защиты от несанкционированного копирования и активации копий не мешали выполнению технологических функций. При этом не исключается номинальная оплата нужного числа копий. То есть вне зависимости от выбранного технологического пути создания диска с автоматической процедурой установки и, значит, активации копии, вопросы выполнения требований законодательства по защите прав интеллектуальных собственников могут решаться совершенно бесконфликтным путем и в согласии с совестью системного администратора. Далее производится настройка сети. Предполагаем, что выбираются стандартные сетевые настройки, ориентированные на раздачу динамических адресов провайдером DHCP и соответственно случайное имя компьютера. Любой другой способ не позволит выполнить установку нескольких компьютеров одновременно. То есть при назначении или фиксированного адреса, или фиксированного имени обязательно необходимо вмешательство сисадмина для смены их на постоянные значения. Причем если со сменой имени рабочей станции нет проблем, то смена сетевого адреса из сеанса удаленного подключения к рабочему столу неминуемо приведет к разрыву соединения, что, впрочем, не фатально. [UserData] ; Задаем случайное имя. ComputerName=* [Networking] ; Зададим сетевые настройки по умолчанию InstallDefaultComponents=Yes Далее обращаю ваше внимание на раздел [Components], который управляет установкой программ, входящих в дистрибутив ОС. Обычно в этом разделе запрещают установку игрушек и прочих утилит, которые далее не предполагается использовать. В нем самое большое число строк. Настройка этого раздела всецело зависит от политики системного администрирования. Например, в отношении игрушек: разрешение установки встроенных игр, на взгляд автора, уменьшает стремление пользователей к установке игрушек сторонних производителей. Хотя всегда можно проконтролировать состав установленных на рабочей станции программ удаленно с помощью snmp. Поскольку в согласии с нашей технологией предполагается управление создаваемой рабочей станцией с удаленных терминалов, то следующая настройка просто необходима: [TerminalServices] ; разрешить RDP AllowConnections=1 Вернемся к вопросу установки дополнительного программного обеспечения. За 13 минут до завершения 2-го этапа установки запускается интерпретация команд из файла $OEM$/Cmdlines.txt. Этот файл предоставляет возможность добавления дополнительных действий по настройке, по установке обновлений MS Windows или приложений третьих производителей. Но поскольку в точке Т-13 операционная система настроена еще не в полной мере, то не все полноформатные GUI-приложения можно запускать из Cmdlines.txt. В таком режиме многие установочные процедуры не работают. Поэтому опустим описанную возможность установки, тем более, что есть способ со всех точек зрения максимально привлекательный для этого – запуск при первом логоне в систему, так называемый GuiRunOnce. Строго говоря, есть еще и третий способ, но об этом позднее. Принято считать, что этим путем удобно вносить изменения в реестр, так как ветка HCU здесь относится к пользовательскому профилю по умолчанию. Из методологических целей воспользуемся именно таким путем для добавления пользователей в систему. Очень удобно для управления компьютерами в сети использовать единого административного пользователя. Пользователи временами меняют пароли и забывают их, а так всегда есть способ даже удаленно поправить подобную проблему. Естественно, этот бюджет не должен совпадать с бюджетом администратора на серверах сети. Необходимые команды можно вписать непосредственно в Cmdlines.txt, но если туда записать обращение к внешнему командному файлу, тогда можно быть уверенным, что выполнение команд будет происходить в стандартной среде. Поэтому создадим $OEM$/Cmdlines.txt и наполним его следующим содержимым: Листинг 14. Содержимое Cmdlines.txt [Commands] "mkusers.cmd" А в файл $OEM$/mkusers.cmd запишем команды создания пользователя localadmin с неустаревающим паролем admin и присвоим этому пользователю статус локального администратора: Листинг 15. Содержимое mkusers.cmd net user localadmin admin /add net localgroup Администраторы localadmin /add net accounts /maxpwage:unlimited Теперь за 13 минут до завершения второго этапа установки будет создан служебный административный бюджет с тривиальным паролем admin, который надо не забыть сменить после завершающей настройки станции. А ещё через 40 виртуальных минут установочного времени компьютер должен перегрузиться и тогда начинается 3-й этап установки. Третий этап Последний этап установки состоит из следующих действий:
В 1-4 пунктах все очевидно. Здесь практически нечего настраивать или менять в процессе автоматической установки. Разве что запретить добавление пользовательских бюджетов: [GuiUnattended] ; Запретим запрос о создании пользовательских бюджетов AutoLogonAccountCreation=No А вот пятый пункт является ключевым. Как уже было сказано выше, здесь происходит запуск установки прикладного программного обеспечения. Все необходимые для этого команды записываются после маркера секции [GuiRunOnce] строка за строкой в обрамлении двойных кавычек. На самом деле эти команды не интерпретируются непосредственно из файла winnt.sif, а предварительно записываются в соответствующую ветвь реестра HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunonce и после выполнения удаляются из нее автоматически. И есть даже такие схемы установки, где эти данные добавляются в реестр динамически при выполнении Cmdlines.txt. Но не будем все так усложнять. Наоборот, вынесем все команды в отдельный исполняемый файл GuiRunOnce.cmd, вызов которого запишем в winnt.sif в секции GuiRunOnce. Так можно будет уменьшить число модифицируемых компонентов на создаваемом диске и сократить проблемы из-за синтаксических ошибок, поскольку ошибка во внешнем файле никак не скажется на остальной процедуре установки и тогда в аварийном случае возможен еще путь ручной установки приложений прямо с диска. Полный текст файла GuiRunOnce.cmd, можно получить по ссылке [5], естественно, в кодировке koi8-r. Теперь определимся с перечнем дополнительных действий, которые следует выполнить на этой стадии автоматической установки. Исходя из специфики применения рабочей станции, для которой создается диск автоматической установки, пусть набор действий будет следующим:
Первый шаг совершенно очевиден. Надо сделать простые настройки реестра Windows в разделах HKEY_LOCAL_MACHINE в соответствии с предполагаемой средой работы. Существует целый пласт литературы, посвященной вопросам тюнинга реестра этой чудной операционной системы. Нет смысла повторяться, поскольку авторы этого «карманного» чтива и так друг у друга все списывают «наперегонки». Каждый может выбрать, что понравилось. Отмечу лишь то, что важно в нашем контексте. Во-первых, для успешного подключения в домен на Samba внесем правочку SignOrSeal: Листинг 16. Исправление в реестре для подключения в домен на Samba [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters] "requiresignorseal"=dword:00000000 И, во-вторых, поскольку в SP2 добавлен firewall, то для того чтобы можно было управлять создаваемой рабочей станцией через подключение к рабочему столу, разрешим доступ к порту 3389 из локальной сети и подсетей, используемых как туннельные. И здесь же еще настроим доступ к snmp для снятия учетных данных. Листинг 17. Исправление в реестре для разрешения работы нужных сетевых служб [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesSharedAccessParametersFirewallPolicyStandardProfileGloballyOpenPortsList] "3389:TCP"="3389:TCP:192.168.0.0/255.255.255.0,192.168.10.0/255.255.255.0:Enabled:@xpsp2res.dll,-22009" "161:UDP"="161:UDP:LocalSubNet:Enabled:SNMP" Лучше каждую правку определенной ветви реестра сохранять в отдельном файле, и все их поместить в $OEM$/$1/InstData. И тогда можно будет манипулировать соответствующими настройками, просто комментируя команды изменения реестра. Сами же команды должны выглядеть примерно так: Листинг 18. Команда обновления реестра %systemdrive%windows egedit /s %systemdrive%InstDataWinXP_SignOrSeal.reg Для установки прикладного программного обеспечения используются заранее созданные и скомпилированные программы на AutoIt. Например, установка MS Office XP из размещенного в директории $OEM$/$1/InstData/OfficeXP дистрибутива производится командой: Листинг 19. Установка MS Office %systemdrive%InstDatainstall_office.exe %systemdrive%InstDataOfficeXPSETUP.EXE При этом путь до файла штатного установщика Office XP передается в программу AutoIt как параметр: Run ( $CmdLine[1] ) Копирование данных в «Documents and Settings» необходимо производить динамически. Если разместить в этой директории нужные поддиректории и файлы заранее, то при настройке пользовательских профилей они будут исключены из работы, так же как это происходит при установке Windows поверх старой версии. Поэтому и исправление параметров запуска Far, если, конечно, мы его используем, и добавление специальных установочных команд в директорию автозагрузки будем производить так, как указано далее: Листинг 20. Команды дополнительных настроек copy %systemdrive%\InstData\farmanag.lnk "%systemdrive%\Documents and Settings\All Users\Главное меню\Программы\FAR manager\FAR manager.lnk" /b /y copy %systemdrive%\InstData\farmanag.lnk "%systemdrive%\Documents and Settings\All Users\Рабочий стол\FAR manager.lnk" /b /y copy /Y "%systemdrive%\Documents and Settings\usersetup.cmd" "%systemdrive%\Documents and Settings\Default User\Главное меню\Программы\Автозагрузка\" copy /Y "%systemdrive%\Documents and Settings\usersetup.cmd" "%systemdrive%\Documents and Settings\Администратор\Главное меню\Программы\Автозагрузка\" copy /Y "%systemdrive%\Documents and Settings\usersetup.cmd" "%systemdrive%\Documents and Settings\localadmin\Главное меню\Программы\Автозагрузка\" Здесь важно отметить, что в первом случае правится меню и десктоп, принадлежащие всем пользователям рабочей станции. А вот добавление команды в автозагрузку надо произвести не только для профиля по умолчанию, но и для профиля Администратора, который сразу же после завершения стадии GuiRunOnce будет активирован, и для профиля пользователя, которого мы ранее создали как предполагаемый служебный бюджет. Теперь самое время вспомнить, что, кроме запуска инсталляторов прикладного программного обеспечения, надо еще не забыть удалить директорию C:InstData и для верности перезапустить компьютер. Вот это уже надо делать из секции [GuiRunOnce]. В итоге должно получиться следующее: [GuiRunOnce] ; запусим установку прикладных программ "%systemdrive%InstDataGuiRunOnce.cmd" ; удалим дистрибутивы прикладных программ "%systemdrive%WINDOWSsystem32cmd.exe /c rmdir %systemdrive%InstData /s /q" ; запустим перезагрузку компьютера "%systemdrive%WINDOWSsystem32shutdown -r -f -t 180" Длительная задержка перезагрузки нужна для того, чтобы успели пройти все остальные работы по настройке и отработал usersetup.cmd, который был скопирован в автозагрузку Администратора. Если возникает необходимость в еще одной стадии установки, например, надо перезагрузить систему в режим сохранения для выполнения каких-то действий, тогда следует создать еще один командный файл для 4-й стадии, назовем его step4.cmd. И в конец секции [GuiRunOnce] перед вызовом команды shutdown записать следующее: copy /Y %systemdrive%InstDatastep4.cmd "%USERPROFILE%Главное менюПрограммыАвтозагрузка" bootcfg /raw «"/fastdetect /safeboot:minimal /sos /bootlog /noguiboot" /id 1 После этого произойдет перезагрузка в режиме сохранения, и после автоматической авторизации будет запущен командный файл step4.cmd. Стоит учесть, что для выполнения этого действия потребуется еще одна автоматическая перезагрузка. То есть если предполагается в конце четвертого этапа снова перезагрузить компьютер, то надо будет заранее увеличить счетчик автоматических перезагрузок AutoLogonCount. Но поскольку во время этой перезагрузки снова возможен запуск step4.cmd, то надо позаботиться или об удалении командного файла step4.cmd, или о его автоматическом отключении. Собираем диск Итак, все работы по подготовке данных завершены и теперь можно создать образ загрузочного диска: Листинг 21. Сборка загрузочного диска # mkisofs -v -J -N -D -relaxed-filenames -no-iso-translate -input-charset koi8-r -P «Ivan Ivanovich» -p «Handy Man» -V «WXPSP2_RU» -A «mkisofs» -b boot/ntboot.bin -no-emul-boot -c boot/boot.catalog -hide boot -hide-joliet boot -o wxpsp2_ru.iso /heap/Windows/uawsp2 Отметим некоторые из использованных параметров. Во-первых, включаем расширение Joliet, для того чтобы на полученном диске читались длинные имена, которые были использованы в директории $OEM$ – ключ «-J». Во-вторых, укажем, что исходная локаль имен файлов koi8-r. Если в применяемой системе не так, то следует поправить – параметр «-input-charset koi8-r». В-третьих, запишем, что используется только загрузочный сектор, а не имидж флоппи-диска, и заодно запретим доступ к загрузочной информации – ряд параметров «-b boot/ntboot.bin -no-emul-boot -c boot/boot.catalog -hide boot -hide-joliet boot». Остальное все очевидно и создается в полном согласии с «man mkisofs». «Прожигание» самого диска CD-R/RW является тривиальной задачей, которая не должна вызывать вопросов, посему опустим ее описание. Точно так же каждому сисадмину должно быть ясно, что и в этой статье, и в тех скриптах и действиях, которые будут предприняты по материалам статьи, могут вкрасться ошибки. Поэтому рекомендуется сначала получить устойчивый результат на эмуляторе VMWare. В заключительной части статьи рассмотрим некоторые аспекты практического использования полученного диска и добавим к полученному программу сбора информации о конфигурации компьютера. Ссылки:
|
АЛЕКСЕЙ БАРАБАНОВКомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
