Unattended Installation:

Instalacja automatyczna, nie wymagająca interakcji od użytkownika,
który jej dokonuje. Często możliwość takiej instalacji daje sam program,
mając wbudowane opcje umożliwiające ustawienie wszystkich informacji przed
instalacją. Jeśli program nie umożliwia takiej instalacji sam z siebie,
można spróbować samemu zbudować instalację stosując różne metody [w zależności
od programu i systemu operacyjnego]

Boot
Disk:

Dyskietka Startowa – niezwykle przydatne narzędzie w razie
problemów z systemem operacyjnym. Niezbędne, jeśli chcemy zainstalować system
w trybie Unattended.

    W niniejszym artykule znajdują
się informacje na temat dyskietki startowej do instalacji systemu operacyjnego w
trybie unattended. Część, którą obecnie masz przed sobą jest wprowadzeniem do problemu prezentując informacje ogólne. Na dole strony znajdziesz linki do pozostałych części, opisujących najważniejsze pliki najdujące się na dyskietce startowej: autoexec.bat, config.sys, system.ini, network.ini .

Przygotowanie dobrej dyskietki startowej tak, aby wszystko wykonało się automatycznie może być czasochłonne ze względu na ograniczenia DOS’a, a co za tym idzie szukania sposobu ich obejścia.
Zebranie wszystkich narzędzi oraz zbudowanie odpowiedniego flopa zajęło mi sporo
czasu – dla tego mam nadzieję, że poniższy text pomoże go komuś oszczędzić.

[W treści artykułu znajduje się link do image’ów
bootdisk’ów, które przygotowałem i które opisuję]


Co jest do zrobienia:

Na każdym komputerze musi zostać zainstalowany Linux oraz Windows. Początkowo wymagane było stworzenie partycji swap dla linuxa, primary ext2 dla linuxa, primary FAT32 dla systemu windows, i dwie partycje extended FAT32 na aplikacje i dla użytkowników. Początkowo wyglądało to więc tak:

Linux-Swap
(128Mb)
Windows-pri
(ok.1,5-2Gb)
Linux-pri

(ok. 1,5-2Gb)

Extended DOS
logical-1
(ok. 1,5Gb)
logical-2

(ok. 500Mb)

Ze względu na optymalizację oraz ułatwienie sobie życia wymyśliliśmy trochę inny system. Po pierwsze były problemy z klonowaniem partycji na ext3 [bo taki jest obecnie używany] – nawet nowy Norton Ghost 7.0 ma z tym problemy. Oddzielania aplikacji od systemu również okazało się nie mieć sensu – początkowo przeważyły przyzwyczajenia z systemów wintendo. Tak też obecnie struktura jest taka:

  • systemowa primary dla windowsa [Active]
  • primary dla userów do dowolnego wykorzystania
  • primary dla linuxa – FAT16

Partycje dla windowsa są w FAT32 ponieważ pierwsza część instacji, jak wiadomo, odbywa się w DOSie. Dla linuxa zakładana jest partycja ukryta FAT16, odpalany jest loadlin i wewnątrz [enkapsulacja systemu plików] jest ext3. Swap jest w pliku zamiast na oddzielnej partycji. Dzięki temu omija się wszystkie problemy z klonowaniem, image plików są stosunkowo małe oraz czas klonowania jest dużo mniejszy.

sys-n-apps, Windows (pri, FAT32, A)

(2,5 lub 4Gb)

3-4-users (pri, FAT32)
(1 lub 3Gb)
Linux (pri, FAT16)
(1Gb)

Przygotowanie tego za pomocą DOS’owego fdisk’a z normalnego pakietu nie jest możliwe,
ponieważ obsługuje wyłącznie partycje DOS’owe – nie da się utworzyć ani Linux-Swap
ani ext2. Poza tym, nawet jeśli nie byłoby Linuxa, to kilkunastokrotne robienie
3 partycji dosowych trwa wieki i doprowadza do choroby nerwowej. Oczywiście można
odpalić sobie Pocket Linuxa i zrobić to szybciej… Ale ponieważ zaraz potem trzeba
zacząć instalować windowsy, więc za dużo trzebaby mieć różnych dyskietek i ciągle
nimi machać.

Kolejnym problemem po utworzeniu odpowiednich partycji jest sformatowanie ich [tych
windowsowych], oraz uruchomienie instalacji workstacji w trybie unattended.

Pozostaje jeszcze kwestia tego, w jakim stanie dostaje się dany komputer – mogą już na nim istnieć jakieś partycje, które wato usunąć, co ręcznie również trwa sporo [cennego] czasu.


Jak to wszystko zrobić automatycznie?

   Najbardziej uniwersalnym rozwiązaniem jest przygotowanie sobie dyskietki z obsługą sieci, utworzenie jakiegoś share’a sieciowego, gdzie można umieścić wszystkie niezbędne programy i programiki, i uruchamiać system z takiej właśnie dyskietki.
Rozwiązanie takie ma podstawową zaletę – jest dość uniwersalne i nie mamy żadnych ograniczeń ze względu na wielkość flopa. Ma też swoją wadę – załadaownie driverów sieciowych i odpalenie sieci trwa jakiś czas [powiedzmy 2min] co może być nieco denerwujące. IMHO czas jest warty poświęcenia, biorąc pod uwagę uniwersalność takiego rozwiązania.

Mamy do dyspozycji dwa podstawowe protokoły: NetBIOS oraz TCP/IP. W dokumentacji microsoftu znalazłem swojego czasu sugestię, iż do takich celów lepiej sprawdza się NetBIOS ze względu na to, że jest szybszy [uboższe ramki etc.]. I jak większość tego typu rad z microsoftu jest to rada, której nie należy słuchać. Czemu?
Utworzyłem dyskietkę z driverem sieci oraz uruchomieniem NetBIOS’u. Drivery są na tyle małe, że na flopie udało mi się jeszcze zmieścić podstawowe narzędzia takie jak fdisk, format etc. To super – ponieważ w razie potrzeby skorzystania z tak podstawowych narzędzi można oszczędzić te 2min dłuższego startu wynikłego z ładowania sici. Niestety jednak dwie cechy takiego rozwiązania są zaporowe:

  1. po pierwsze z jakichś dziwnych i nie wyjaśnionych względów jeśli uruchomiło się kilka równoległych instalacji, kopiowanie plików niemal stawało w miejscu. I tak, jeśli instaluje się pojedyńczy komputer trwa to 10-15min, to przy dwóch czasy dochodzą do 1-2h! Nie znalazłem żadnego logicznego wyjaśnienia na to zjawisko.
  2. drugi powód to nieroutowalność NetBIOS’u. W switchowanej sieci nie nacieszymy się takim rozwiązaniem.

Z takich oto przyczyn korzystam z drugiego rozwiązania jakim jest TCP/IP. Eliminuje to dwie wymienione cechy. Jedyną wadą jest w zasadzie to, iż drivery do obsługi TCP/IP są na tyle duże, że na flopie nie mieści się nic poza własnie nimi. Stąd nawet celem użycia glupiego fdisk’a trzeba odpalać sieć. Co i tak nie jest bolesne, bo przy dobrze zrobionych skryptach unattended nie trzeba wogóle na to patrzeć. Natomiast do celów testowych zawsze można mieć drugiego flopa – narzędziowego, bez obsługi sieci.

Na dyskietce nie ma nic poza katalogiem 'net’ w którym są wszystkie drivery i programy odpowiedzialne za uruchomienie sieci, autoexec.bat, config.sys i kilka byte’ów wolnego miejsca:

 Volume in drive A is BOOTDISK
 Volume Serial Number is 58A1-BDE6

 Directory of A:

2003-07-11  13:55             1 426 AUTOEXEC.BAT
2003-02-17  14:51               440 CONFIG.SYS
1999-05-05  22:22            95 874 COMMAND.COM
1999-05-05  22:22           222 390 IO.SYS
1999-05-05  22:22                 4 MSDOS.SYS
2003-02-12  09:28	<DIR>          NET
1995-07-11  09:50           125 495 EMM386.EXE
1995-07-11  09:50            32 935 HIMEM.SYS
2003-02-12  10:49                 9 begin
               8 File(s)        478 573 bytes
               1 Dir(s)          22 016 bytes free

Image dyskietki można sobie zassać, natomiast linki do opisów autoexec.bat’a i config.sys’a są poniżej.

Przygotowanie servera instalacji

Przed przystąpieniem do samej instalacji trzeba sobie oczywiście spreparować odpowiednie środowisko. Potrzebne do tego będą:

  • użytkownik do instalacji: należy zastanowić się nad bezpieczeństwem całej instalcji. W tym celu najlepiej utworzyć sobie użytkownika, któremu jako jedynemu będzie się nadawać uprawnienia do poszczególnych katalogów instalacyjnych. Konto tego użytkownika powinno być zablokowane, i odblokowywane jedynie na czas instalacji. Można do tego celu wykorzystać standardowo tworzonego usera 'install’.
  • instalka: trzeba udostępnić w sieci katalog i386 z płyty instalacyjnej windows’a. Najlepiej aby do tego udziału dostęp miał wyłącznie użytkownik instalacyjny, oraz żeby był to udział filtrowany – czyli z '$’. Może to być np. ’2kp$’.
  • pliki unattended: potrzebne będą jeszcze pliki zawierające zbiór odpowiedzi do instalacji bezdotykowej. Pliki takie można sobie utworzyć ręcznie lub za pomocą narzędzia z płytki instalacyjnej windows [w katalogu support tools]. Tej częsci nie opisuję, ponieważ można na ten temat znaleść wiele różnych artów nawet w języku polskim [np. na infojamie], a najdokładniejszy opis znajduje się w pliku opisującym pełny zestaw parametrów i możliwości dostępny np. tu. Ze względu na to, iż pliki te mogą zawierać hasła użytkownika o uprawnieniach administratora warto umieścić je w oddzielnym katalogu, i ustawić odpowiednie uprawnienia NTFS’owe, tak aby nikt ich nie przechwycił. Można umieścić je np. w katalogu ’scripts’ wraz z instalką windowsa [\INSSERVER2kp$scripts].
  • DOSowa część instalacji: w DOSowej części instalacji, w której np. tworzone są partycje, potrzebne będzie troche programów użytkowych (np. fdsik i smartdrv), ale ponieważ dyskietka (i ten share) może służyć jako ogólno-nażędziowa warto tam sobie upchnąć kilka 'przydatków’ jak mem, xcopy etc. Podstawowe rzeczy wykorzystywane podczas instalacji to:

    fdisk (z dystrybucji freedos’a), format, choice, smartdrv, winnt oraz ins.bat (opisany w części o autoexec’u).
    Należy uczywiście stworzyć odpowiedni udział sieciowy [ np. \INSSERVERnetins ].

  • dyskietka instalacyjna: czyli odpowiednio spreparowany flop, który próbuję opisać.

A co z partycjami?

Aby automatycznie utworzyć partycje różnych rodzajów DOS’owy fdisk na pewno nie wystarczy. Można użyć do tego wielu różnorakich fdisk’ów różnych produkcji. IMHO najlepszy jest fdisk z dystrybucji FreeDOS’a, który normalnie działa ze zwykłym DOS’em. Ma on dwie podstawowe zalety: pełną obsługę z linii komend za pomocą parametrów, oraz możliwość restartu kompa – co jest przydatne po założeniu partycji. Wykożystanie w praktyce znajduje się w opisie autexec’a.


Kolejno co i jak:


To się może przydać

Czyli download do tej stronki:

  • copyNT – prosty i szybki programik do tworzenia image’ów i ich odtwarzania.
  • image dyskietki o której mowa w texcie [TCP/IP].
  • image z którego korzystałem uprzednio [NetBIOS].
-o((:: sprEad the l0ve ::))o-