Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Удаленная загрузка Windows 95

Скотт С. Кэмпбелл

Вряд ли кого-то можно упрекнуть в неоправданных заверениях, что удаленная загрузка Windows 95 на бездисковых рабочих станциях -- дело простое. Этого не обещала даже сама Microsoft, намеренно или нет сделавшая и без того нетривиальную процедуру еще более сложной. Однако отдадим ей должное: как бы то ни было, фирма все-таки позаботилась о том, чтобы Windows 95 можно было загрузить удаленно.

Удаленная загрузка операционных систем DOS и Windows 3.1 в среде NetWare стала уже довольно привычной. Ее алгоритм примерно таков: ППЗУ удаленной загрузки, расположенное на сетевом адаптере Ethernet рабочей станции, запрашивает загрузочные файлы c сервера NetWare. С помощью специального ПО они считываются как с дисковода A:, и машина загружается как обычно. После того как с сервером установлено IPX-соединение, будут считаны и все остальные файлы, необходимые для окончательной загрузки ОС.

А как происходит удаленная загрузка Windows 95? В ней нет почти ничего общего с аналогичным процессом DOS или Windows 3.1, хотя понимание того, как это происходит в случае процесса загрузки DOS, здесь пригодится. Microsoft полностью реализовала установление связи с сервером удаленной загрузки для Windows 95. Правда, сама процедура в документации для этой ОС описана недостаточно. Сложность удаленной загрузки, предлагаемой Microsoft, заключается в том, что там используются механизмы защищенной работы в сети, не претерпевшие никаких улучшений с момента их появления. Однако спасибо и на этом, ведь Novell не проявляет особого интереса к удаленной загрузке Windows 95: она уже неоднократно откладывала реализацию этой технологии в своем 32-разрядном клиенте.

Теоретическая основа

Локальная сеть в нашем университете построена на основе серверов NetWare 4.11. Ее работа обеспечивается сетевыми адаптерами 3C905 Fast Ethernet фирмы 3Com, работающими в дуплексном режиме 100-Мбит/c. Файлы первичной загрузки передаются клиентам с помощью модуля Multi Server Director (MSD.NLM) фирмы Lanworks Technologies.

Клиентские машины, рассредоточенные по всем зданиям университета, подключаются к локальной сети через коммутируемые 10-Мбит/с порты и представлены самыми разными аппаратными конфигурациями -- от процессоров i486 с частотой 66 МГц до Pentium II с частотой 266 МГц и ОЗУ объемом 64 Мбайт. На всех сетевых адаптерах установлено ППЗУ удаленной загрузки фирмы Lanworks, и все они настроены на поддержку кадров типа Ethernet II. Самая важная характеристика всех наших клиентских машин -- это отсутствие на них жестких дисков. Таким образом, кратко данную среду можно охарактеризовать: ничего лишнего -- только Windows 95 и сеть.

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

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

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

Приведенная выше модель не дает представления о том, как эти многочисленные аутентификации осуществляются в среде NDS (Novell Directory Services) ОС NetWare 4.11. Мы обнаружили, что аутентификация машины будет обязательно представлять собой соединение служб справочника из-за необходимости передачи идентификатора машины в качестве первоначальной аутентификации при загрузке. Так как можно установить только одно соединение служб справочника для одного дерева, все последующие или персональные аутентификации будут проходить на основе сетевой базы данных Bindery. Применение персональных пользовательских идентификаторов для установления первичных соединений полностью устранит эту проблему. Пользователи, зарегистрировавшиеся в NDS на основании собственных учетных записей, ничем не будут отличаться от тех, кто обходится без удаленной загрузки.

Программный пакет Service for NDS фирмы Microsoft -- это единственный клиент, который в настоящее время поддерживает удаленную загрузку. В таком пакете весьма кстати оказалась бы возможность выбора типа внутренних соединений -- Bindery или NDS, но, к сожалению, клиент Microsoft не обеспечивает такой функции. Эту возможность предоставляет Client32 фирмы Novell, однако в нем отсутствует функция удаленной загрузки. В конечном счете мы были рады констатировать, что служба Microsoft отлично работала в нашей среде. Главное, в чем мы убедились -- это в том, что команда NET USE первичное соединение выполняет с NDS, а все последующие -- в режиме Bindery. Это заставляет пользователей лаборатории заново аутентифицировать каждый сетевой ресурс, к которому они имеют доступ, что противоречит самой концепции NDS.

Что об этом пишет Microsoft

Итак, где же можно прочитать о том, как осуществить удаленную загрузку Windows 95? Единственное, и притом довольно скудное, описание этой процедуры нам удалось отыскать в главе 4 руководства Windows 95 Resource Kit. В нем содержится очень важная, но далеко не полная информация. Например, отсутствует описание работы с такими индивидуальными для каждой машины компонентами, как реестр или статические и изменяющиеся каталоги наподобие Start Menu. Конечно, для организации такого сложного процесса, как совместное использование файлов при удаленной загрузке, вам необходима хотя бы первичная информация о решении этой проблемы. Однако концепция организации сетевых рабочих мест, предлагаемая фирмой Microsoft, построена на двух основных допущениях: на каждой клиентской машине установлен жесткий диск и большинство прикладных систем частично или полностью инсталлированы на него.

В документации нам бы хотелось увидеть описание перехода от обычной организации работы сети к конфигурации с удаленной загрузкой. Так, например, нелишним было бы узнать, как выйти из ситуации, когда после загрузки с электронного диска последний неожиданно исчезает, "унося с собой" реестр Windows 95, или как происходит передача управления между сетевыми драйверами обычного и защищенного режимов?

Процесс

Сам процесс удаленной загрузки начинается так же, как и в среде DOS/Windows 3.1: с запроса клиентской машиной файла начальной загрузки с файлового сервера. Последний доставляет запрошенный файл клиенту, где он и загружается в ОЗУ. Но на этом сходство двух процессов и заканчивается.

Настроить инсталляционный пакет Windows 95 для удаленной загрузки на сервере оказалось довольно просто. С этой целью мы использовали утилиту NETSETUP.EXE, которую обнаружили на компакт-диске c Windows 95. Файл MSBATCH.INF, сформированный в результате этого процесса, может быть легко модифицирован для конкретной пользовательской среды. Например, мы могли включить в нашу инсталляцию установщик UPDATES.INF из пакета Service Pack 1. Чтобы дать возможность нашим рабочим станциям найти их собственные реестры и индивидуальные сетевые диски, устанавливаемые по умолчанию, мы создали пользовательский файл MACHINES.INI с перечнем всех Ethernet-адресов рабочих станций и записей, указывающих на соответствующие системные настройки (рис.1).

Загрузка клиентской среды начинается с загрузки DOS, осуществляемой с диска A:. Чтобы и в дальнейшем можно было пользоваться сетевым диском D:, зафиксированным соответствующей записью в реестре, необходимо временно отразить его на сервер, поскольку иначе при перезагрузке системы он пропадет вместе с виртуальным диском. Имея все необходимые составляющие, мы запускали утилиту настройки Windows 95 для определенной клиентской машины, ссылаясь на измененный файл MSBATCH.INF (рис. 2).

В процессе начальной загрузки в клиентском каталоге Windows 95 создается подкаталог SUBOOT со всеми файлами, необходимыми для дальнейшей загрузки ОС. Один из них -- MSDOS.SYS указывает на каталоги, содержащие всю необходимую для удаленной загрузки информацию (рис. 3). Реальный файл начальной загрузки, названный NET$DOS.SYS, создается при запуске утилиты RPLIMAGE, расположенной в каталоге NETSETUP на компакт-диске Windows 95. Полученный файл необходимо переместить в каталог SYS:LOGIN сервера NetWare таким образом, чтобы клиент мог иметь доступ к нему, когда осуществляет первичную загрузку.

Во время перезагрузки должна быть полностью выполнена инсталляция загрузочных файлов, а содержимое каталогов рабочей станции D:\Win95 следует упаковать в .ZIP файл, который может быть распакован уже локально, на клиентской машине. Мы решили воспользоваться архивом .ZIP, поскольку это значительно ускоряет начальную загрузку по сравнению с передачей по сети многочисленных файлов, необходимых для загрузки ОС. Кроме того, процесс распаковки на электронном диске происходит довольно быстро.

Так как реестр Windows 95 в значительной степени привязан к конкретной конфигурации аппаратных средств, мы создали для каждой машины отдельную его копию. Возможен и другой подход -- использование единого реестра для всех ПК с последующей передачей информации, специфичной для конкретной аппаратной конфигурации уже в процессе загрузки. Это было бы удобно, если бы машины различались лишь некоторыми параметрами, например типом звуковой платы, отраженной несколькими записями в реестре, и т. п.

Заключительные штрихи

Рассматривая различные конфигурации, мы пришли к выводу, что наиболее рационально хранить как можно больше привязанных к рабочим местам файлов, таких, как реестр или файлы .INI, на локальных машинах. Однако при хранении на локальной станции кэша браузера и других аналогичных файлов вы можете проанализировать такой подход с точки зрения его стоимости и удобства.

Для выполнения поставленной цели мы создали два электронных диска -- первый -- C:, сконфигурированный на 1,44 Мбайт, и второй -- D: -- на 6,5 Мбайт. Второй электронный диск необходим по той причине, что первый, хотя по-прежнему и занимает память, становится недоступным, как только запускается Windows 95 и происходит переход в защищенный режим работы. Таким образом, первый электронный диск используется для начальной загрузки, а второй -- для хранения рабочих файлов среды Windows 95 (рис. 4).

Наша главная проблема заключалась в обеспечении процесса удаленной загрузки с момента включения питания до появления графического пользовательского интерфейса без какого-либо вмешательства пользователя. Мы позаимствовали некоторые сведения об удаленной загрузке из аналогичной процедуры в DOS и Windows 3.1 и сформировали командный файл WIN.BAT (рис. 5). Все специфические операции, необходимые для конкретной машины, мы определили с помощью переменных окружения. Отдельные операции, требующие ввода с клавиатуры, такие, как передача пользовательского имени в ответ на запросы утилиты NET USE при регистрации в сети, выполняются с помощью общедоступной утилиты.

После того как рабочая станция зарегистрирована в сети, смонтированы сетевые диски, а также сформирована своя локальная среда Windows 95 на втором (D:) электронном диске, Windows 95 вызывается через WIN.COM. Далее Windows 95 загружается как обычно. Если сеть начинает работать в защищенном режиме, то соединения обычного режима подчиняются 32-разрядной среде. Другими словами, соединения обычного режима теряются, однако их программные модули по-прежнему загружены и занимают память. Любые создаваемые в дальнейшем соединения будут работать в защищенном режиме, будто среды обычного режима никогда и не существовало.

А что, если мы добавим в рассмотренную конфигурацию рабочих станций накопители на жестких дисках? Тогда закономерно возникает вопрос: зачем вообще нужна удаленная загрузка? Вспомним, что основным преимуществом удаленной загрузки операционной системы, будь то DOS, Windows 3.1 или Windows 95, является сокращение затрат на администрирование множества клиентских машин.

К сожалению, по имеющимся у нас сведениям, удаленная загрузка на платформах Microsoft, возможно, прекратит свое существование вместе с ОС Windows 95, так как Windows 98 в своей первоначальной редакции не поддерживает этот механизм.

Примеры файлов MSBATCH.INI и MACHINES.INI

Файл MSBATCH.INI:
[network]
WorkstationSetup=1
HDBoot=0
RPLSetup=1
[setup]
SaveSuBoot=1
Файл MACHINES.INI:
[000000000000]
SysDatPath=d:\win95
h=\ \cl1\data\clusters\username


Модифицированный файл MSBATCH.INF
MAP ROOT D: = H:\
MAP W:=\ \CL1\WIN32\WIN95
D:
MKDIR WIN95
CD WIN95
W:\WIN95\SETUP MSBATCH.INF /T:H:\TEMP


Модифицированный файл MSDOS.SYS в каталоге SUBOOT
[Paths]
WinDir=d:\win95
WinBootDir=A:\
HostWinBootDrv=C

[Options]
BootMulti=0
BootGUI=0
Network=1
LoadTop=0
Logo=0

Примеры файлов CONFIG.SYS и AUTOEXEC.BAT
Файл CONFIG.SYS:
DEVICE=HIMEM.SYS
devicehigh=a:\ramdrive.sys 1440 /E
devicehigh=a:\ramdrive.sys 6144 /E
files=100

Файл AUTOEXEC.BAT:
@if not exist c:\winboot\nul mkdir c:\winboot
copy a:\system.dat c:\system.dat
echo Идет копирование загрузочных файлов ...
@copy a:\ c:\winboot > nul
c:
cd \winboot
win.bat

Пример файла WIN.BAT
@echo off
REM RAM Drive Win.bat for IBM733
set comspec=c:\winboot\command.com
set temp=d:\temp
nwrpltrm
snapshot /S /B:C /R
echo Идет подготовка к работе в сети...
net start NWRedir
net use * /d
enet > whoiam.txt
alogon.exe > nul
autokey user.txt > nul
mset USER -|
autokey cluster.txt > nul
mset CLUSTER -|
autokey SERV1.txt > nul
mset SERVER -|
@echo Регистрация и монтирование сетевых дисков...
autokey logon.txt > nul
net use f: \\ACADEMIC\DOS
autokey logon.txt > nul
net use w: \\%SERVER%\WIN32\WIN95
net use s: \\%SERVER%\DOS
net use y: \\%SERVER%\DOS\UTIL
net use z: \\%SERVER%\SYS\PUBLIC
del logon.txt > nul
c:\winboot\doskey
d:
md win95
cd win95
@echo Идет установка локальной конфигурации Windows 95...
copy w:\ibm733\windows.zip d:\
c:\winboot\pkunzip -d d:\windows.zip > nul
del d:\windows.zip > nul
call с:\winboot\settings.bat > nul
copy w:\pwlfiles\%USER%.PWL d:\win95
rem c:
PATH=w:\;w:\COMMAND;Y:;Z:
setmdir
w:\command\deltree /y h:\*.* > nul
md h:\netscape
copy w:\system.md? h:\ > nul
win.com





  
11 '1998
СОДЕРЖАНИЕ

колонка редактора

• Наперегонки со светом

локальные сети

• Внедрение приоритизации трафика в сети Ethernet

• Удаленная загрузка Windows 95

• В эпоху интеллектуальных зданий

• Консолидация информационно-вычислительных ресурсов

• Коммутаторы для рабочих групп: мал золотник, да дорог

• Цифровые мультиметры на страже безопасности

• Место коаксиальных кабелей вне локальных сетей

• Один дюйм или два?

бизнес

• О российском канале дистрибуции

• Профессор сетевых технологий

• Oracle побеждает в SQL-гонке

интернет и интрасети

• Приоритизация трафика в сетях IP

• Отладка работы PPP-соединений

• ISP все еще решают проблему пиринга

корпоративные сети

• Тестируем связующее ПО МОМ

• Платформам сетевого управления недостает лидера

услуги сетей связи

• IP-телефония: проблем хватает

• Предоставление услуг IN на сети МГТС

• Спутники облегчают доступ ко Всемирной паутине

• Мониторинг трафика Frame Relay: выгода налицо

• DSL: скорость и средства для ее контроля

• DSL: трудная дорога к стандартам

защита данных

• ИБП для централизованной системы бесперебойного гарантированного электроснабжения

системы учрежденческой связи

• Отечественные УАТС: с оптимизмом — в будущее

новые продукты

• PairView "найдет" потерянные пары; Простота и эффективность Novell Replication Services 1.21;



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх