Kształt instalatora

Śro, 11 Kwi 2001, 12:49:20 CEST

Michal Moskal <malekith w pld.org.pl> writes:

> Cześć,

> 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.

Ja już zacząłem robić takie coś bez xml bo imho sprawa jest zbyt prosta 
i xml jest tu niepotrzebny.
Natomiast przydałby się bardziej do metakonfigów.

> 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).

Asha i tak się nie pozbędziemy, może awka.
Szybkość nie ma tu najmniejszego znaczenia.
Michał ja prawdę mówiąc myślałem że doozy to będzie tylko taki
support tool - konwerter do poszczególnych konfigów, a nie samdzielne 
narzędzie. Widziałem to tak że metakonfigurator jest napisany w shellu
i tylko wywołuje 
# doozy jakiś_konfig_xml szablon_doozy >wyjściowy_config
tzn masz zbiór metakonfigów, po jednym np na każdy pliczek który trzeba wygenerować
(/etc/fstab, /etc/aliases itd)

Wogóle moja koncepcja jest taka by metakonfigurator był oddzielony od 
instalatora.

> 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.

To ja to widzę inaczej, 
mamy trzy główne moduły:

1. UI do przygotowywania pliku z opisem instalacji dla instalatora
   ew również do przygotowywania metakonfigów
2. Wsadowy instalator
3. Metakonfigurator

1.  Tym się na razie nie zajmuję ale widzę tu miejsce dla dml

2.  Sam wsadowy instalator byłby całkowicie nieinteraktywny (o
interaktywności za chwilę) już to zacząłem pisać: wrzuciłem do modułu
bootdisk, katalog batch-installer. Installer składa się z części,
każda część bierze za argument nazwę pliku z opisem instalacji np plik
example i zwyczajnie go sourcuje.  Części to:

installer-validate 
        sprawdza czy nie ma bzdur w pliku wejściowym
        ten moduł nie porównuje nic ze sprzętem, tylko sprawdza czy 
        wszystkie zmienne są zdefiniwane i czy nie ma błędów logicznych

installer-prep
        ten moduł odpowiedziany jest za dostanie się do źródła dystrybucji
        czyli w zależności od rodzaju instalacji:
        - ładuje moduły do dysków/cdromów (instalacja z dysku)
        - ładuje moduł nfs, kartę sieciową i ustawia sieć
        - ładuje kartę sieciową, ustawia sieć i sprawdza czy działa 
          połączenie ftp
        Uwaga: to jest tylko po to by się dostać do źródła - dest nie jest 
        na razie rozważane. Kiedy już uda się dostać do źródła, tam jest reszta
        instalatora, wszelkie programy i moduły potrzebne do zamontowania dest,
        partycjonowania itd.

installer-run
        i to jest właściwy instalator, ładuje moduły potrzebne dla dest,
        robi partycje, formatuje, instaluje rpmy, instaluje bootloader

3.
Matakonfigurator to byłoby coś co modyfikuje konfigi na dest
czyli ustawia hasło roota itd, możliwie z xmlowych matakonfigów

Teraz o interaktywności: interaktywny byłby pkt 1.
Wyobrażam go sobie graficznie jako długi formularz, ewentualnie
parę formularzy osiągalnych z menu. W tym formularzu miałbyś
do ustawiania opcje pliku spec dla instalatora, przy czym byłby
dostępne opisy, podpowiedzi, sprawdzanie co dostępne jest na danym systemie,
ewentualne próbne uruchomienia sieci, montowanie src itp
Przy każdej zmianie opcji plik byłby zachowywany i sprawdzany
przez install-validate.

Ten moduł byłby odpowiedzialny za takie przygotowanie pliku spec
do instalacji by możliwie przeszła ona bez niespodzianek.

Raz przygotowany spec i metakonfigi będzie można wykorzystać powtórnie,
np gdy masz parę podobnych maszyn.

Mam nadzieję że nie będzie szoku :)

Pozdrawiam,
Rafał

-- 
Rafał Kleger-Rudomin (klakier w pld.org.pl)