[unattended pld deploy procedure]

[Rafał Kleger-Rudomin]

Paweł Kołodziej <pawelk w pld.org.pl> writes:

> Dnia Sun, Mar 25, 2001 at 06:00:01PM +0200, Serek/GNU napisał(a):
> [...]
> > [KIND]
> > install_type=base
> > 
> > [NET]
> > inetnum=dhcp
> 
> Na razie wszystko ok.
> 
> > [X]
> > card_module=riva_tnt2
> > width=1024
> > height=768
> > color=32
> > appmanager=blackbox
> > xdm=off
> 
> BUM ! Tu juz nie wystarczy instalator (w moim, spaczonym rozumieniu tego
> słowa). Tu jest potrzebny metaKonigurator. A jak na razie (AFAIK) nikt sie
> do czegoś takiego nie przymierza. Najwiekszym problemem jest w tym wypadku
> mnogosc formatow plikow konfiguracyjnych. Moja wizja metaKonfiguratora
> jest nastepujaca (nie wiem czy odkrywam Ameryke czy nie):

I to się zgadza. 
Jednym z rozwiązań może być metakonfigurator, są jednak wady:
- konfiguruje się w ciemno, nie masz żadnej możliwości sprawdzenia czy działa
- trzeba śledzić zmiany w składni plików konfiguracyjnych (czasem autorzy wymyślają coś
  nowego)
- znowy się instalator rozbudowuje
- wprowadzamy dodatkowy sposób konfiguracji (dodatkowa dokumentacja itd)

Jest inne wyjście: 
- instalator pozostanie instalatorem tzn będzie instalował pakiety.
  konfigurować będzie na tyle ile jest potrzebne/wykonalne
- po zainstalowaniu jednej maszyny admin przystąpi do konfiguracji.
  jak wszystko uruchomi, będzie mógł dograć tę konfigurację na bootkietkę
  np. w postaci łat 

I to jest pomysł alteranatywny.

> 1. Wszytkie konfiguracje trzymamy w plikach o jednolitej skladni (podobnej
> do tej powyzej (to moze zalatwic np. "conflib").
>
> 2. Na podstawie tej konfiguracji generujemy pliki konfiguracyjne do
> różnych programów (np. z mta.conf mozna wygenerowac konfigi zarowno
> do sendmail'a, qmaila jak i zmailera itp. itd)
> 3. Generacja plików konfiguracyjnych jets oparta o temaplatey (podobne
> do xtemplates z php jub fasttemplates z perl'a). Proces generacji wyglada
> tak: program nadzrzedny wywołuje modół odpowiedzialny za konfiguracje
> danego programu przekzując mu wszystkie niezbedne ustawienia. Ten modół
> troche je miętosi (w zależności od potrzeb) i generuje z template
> odpowiedniego konfiga.
> 
> 4. Zmiana konfiguracji polega na zmianie ustawień w naszym XXXX.config i
> puszeczenu od nowa generacji konfiga dla danego programu. Mozna oczywiscie
> napisać różne frontendy do tego, ale generalne $EDITOR twoim przyjacielem
> 
> 5. Oczywiście trzeba będzie w to zaszyć jeszcze odrobine integligencji,
> żeby nie zamazać zmian wprowadzonych przez admina w międzyczasie (ale to
> raczej proste).
> 
> Zaletą tego roziwiazania jest brak konieczności parsowania 1000 różnych
> formatów plików konfiguracyjnych oraz IMHo całkiem "łatwe, proste i
> przyjemne" dodawanie nowego typu pliku konfiguracyjnego (wystarczy zmienic
> template -- to banalne, oraz napisać mały modół który raczej nie będzie
> bardzo skomplikowany).
> 
> Co wy na to ? Piszemy ?

Koncepcja metakonfiguratora też jest kusząca. Myślę że możnaby połączyć
ją z tym co napisałem powyżej i umożliwiać zarówno generowanie plików, 
jak i "sesję poprawkową" czyli dołożenie łat na podtstawie tego 
co powstało w wyniku uruchomienia systemu
 
> PS Jesli o mnie chodzi, to przez najbliższy tydzień nie będe miał czasu
> na pisanie czegokolwiek, byc moze nawet listow (tydzien w semestrze trzeba
> sie pouczyc).

Natomiast ja mam czas i chęć się tym zająć.
Jakbym to widział:

1. Edytor formularzy - okienka do tworzenia pliku dla wsadowego instalatora 
   ("formularza instalacyjnego") oraz ewentualnie do edycji konfigów.
2. Instalator wsadowy (w shellu). Nawet niepotrzebny byłby żaden lib do konfigu
   jeśli formularz byłby w formacie zmienna=wartość to mozna by zwyczajnie includować
3. Konfigurator wsadowy taki jak Paweł pisał.

Oglądałem ostatnio automatołka. Czy nie dałoby się jego rozwinąć
w tym kierunku. Co na to Michał??


Pozdrawiam,
Rafał

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