Kształt instalatora

[Michal Moskal]

Cześć,

Na początku zaznaczam, że sen jest dla mięczaków, ale jakbym z niewyspania
jakieś bzdury zaczął wypisywać, możecie mnie spokojnie olać :^)
Ogólnie nie odkrywam tym listem Ameryki, raczej systematyzuje kilka
poprzednich wątków.

Dobra, chodzi mi o instalator, konkretnie jak to ma wyglądać.
Koncepcja jest taka, żeby odzielić cześć, która psuje sprzęt (n.p.
partycjonuje dysk czy instaluje pakiety), od części w której tylko
mówi się instalatorowi *jak* to zrobić (jakie partycje zrobić, które
pakiety zainstalować
etc.). Komunikacja między tymi dwoma częściami ma być w XMLu.
To znaczu user najpierw jest w jakiś sposób odpytywany, a na tej
podstawie tworzony jest plik .xml, wg którego się instaluje. Wtedy
taki plik po instalacji nagrywamy do (powiedzmy) /var/log/install
i mamy gotowy template.

Teraz odpowiedzi na kilka pytań. 1. Dlaczego XML? Bo taka moda ostatnio :)
A poważnie, bo jest samoopisujący, można fajnie zagnieżdżać sekcje,
a poza tym patrz 2. 2. Dobra, XML, ale jak ty to chcesz na bootdisku
upchnąć? Ano używając super-hyper-iwriiten-on-purpose-scripting-languge(tm)
by /me. Oczywiście wszyscy znają moje upodobanie do tego typu rozwiązań :^)
W zamierzeniach używanie tego języka ma doprowadzić do usunięcia
z bootdisku awk'a i ash'a -> czyli pozyskania ~150k miejsca. 
(sed|grep zostanie raczej w busybox, żeby user mógł go sobie używać z 
lash command line). Język, zgodnie z sugestią Łukasza (który chyba nie
mówił tego poważnie :^), nazywa się doozy, w takim też module należy
go szukać w CVS. W środku jest opis, czytać najlepiej zacząć od pliku
rc-inetd.doozy, który zawiera skrypt rc-inetd dla rlinetd, z duuużą
ilością komentarzy. (dzięki Rafał za sugestię :) Można również użyć
skryptu mkdoc (jest w doozym, więc trzeba najpierw zrobić doozego - make),
żeby stworzyć opis builtinów. Nie wszystkie są już opisane :<
Na przykładzie tego pliku można łatwo stwierdzić, że doozy nie jest
zbyt szybki. Ale i tak jest o rząd wielkości szybszy od shella, który
musi robić ciągłe forki i execi (n.p. dla seda).

Teraz jak nie wylać dziecka razem z kąpielą. Jest więcej niż prawdopodobne,
że większość instalacji będzie interaktywna, a na pewno większość
*trudnych* (takich w czasie których występują Problemy(tm)) instalacji.
Więc często chcemy widzieć efekty danej akcji, *zanim* powiemy jak
ma wyglądać następna. Tutaj chciałbym podzielić instalator na fazy.
Każda faza ma swoją sekcję w XML i jest w 2 osobnych plikach.

Jeden z nich jest robi walidację i wywiad z użytkownikiem. To znaczy
dostaję ścieżke, gdzie ma szukać xml'a z defaults (można mu dać /dev/null,
w razie czego) i jak czegoś nie znajdzie w defaults to się pyta.
To jest z grubsza cała walidacja jaką robi (sprawdza czy wszystkie
informacje są podane), może jeszcze z grubsza przyjżeć się spójności
danych, n.p. czy każda partycja występuje raz, czy jest /, itp.

Drugi skrypt psuje sprzęt, również na podstawie zapodanej ścieżki.
Można się zastanowić, że jeśli instlujemy w batch mode, to można
najpierw zapytać o wszystko, a potem zacząć zabawe. Oczywiście, jeśli
template był pełny, to o nic nie pytamy.

Fazy instalacji [?] - opcjonalna:
* fdisk
* mkfs + stworzenie fstaba
* moduly [?]
* hostname
* konfiguracja sieci [?]
* source-of-instllation
* wybranie zestawów pakietów
* uruchomienie prowizorki/wucha
* bootloader
* timezone
* pytania czy nagrać niektóre z ustawień (sieć)
* hasło roota
* skopiowanie logów/tampletów
* reboot

Okey. Any suggestions are welcomed :>

-- 
: Michal ``,/\/\,       '' Moskal    | |            : GCS {C,UL}++++$
:          |    |alekith      @    |)|(| . org . pl : {E--, W, w-,M}-
:                                  |                : {b,e>+}++ !tv h
: Current project:  http://aleph-0.dhs.org/ywindow/ : PLD Team member