[unattended pld deploy procedure]

[Paweł Kołodziej]

Dnia Mon, Apr 02, 2001 at 11:01:29AM +0200, Rafał Kleger-Rudomin napisał(a):
> 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

OK. mozna dodac opcje "pokaz plik konfiguracyjny". Nie ma problemu. Tyle
że pewności również nie ma.

> - trzeba śledzić zmiany w składni plików konfiguracyjnych (czasem autorzy wymyślają coś
>   nowego)

Jak konfigurujesz wszystko z palca to musisz śledzić. Tu wystarczy, żeby
śledziła jedna - diwe osoby. Włąściwie wystarczy pryzpadkowy użytkownik
który da znak "z wersja x.y to to nie dziala".

> - znowy się instalator rozbudowuje

Instalator tak. Ale moduralny z nie monolityczny. W związku z tym nie
widze problemu. Dalej trzon można rozwijąć bez oglądania się na resztę.

> - wprowadzamy dodatkowy sposób konfiguracji (dodatkowa dokumentacja itd)

Wprowadzamy jeden, eliminujemy miliony. Np. ja gdy już raz kiedyś
sonfigurowałem sobie sendmaila, to naprawde potrzebowałem dużego kopniaka,
żeby przejść na qmail'a. Inny program, ciut inna "filozofia", całkiem inna
skądania i rozmieszczenie plików konfiguracyjnych. MetaKonfigurator by mi
w tym mógł wydatnie pomóc. W takim powiedzmy mta.conf mogą być zarówno
opcje ogólne (pasujące do każdego mta) jak i również specyficzne dla
różnych.

> Jest inne wyjście: 
> - instalator pozostanie instalatorem tzn będzie instalował pakiety.
>   konfigurować będzie na tyle ile jest potrzebne/wykonalne

toczka. Tak miało być od początku. Tzn. instalator bootkietkowy intaluje
pakiety i robi tyle knfiguracji, żeby maszyna miała jakiekolwiek szanse
wstać. Potem edytujemy sobie metokonfigi, puszczamy metaKonfigurator i mam
y działający system. Poprawki wnośimy do metaPlikówKonfiguracyjnych i
puszczamy mKonfigurator. Proste, łatwe i przyjemne.

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

OK. nie ma problemu. Ja cały czas myślałem raczej pod kątem jednej
maszynym (wiem, wątek zaczoł sie od nowych maszyN Sergiusza), ale
zwielokrotnienie tego nie jest problemem.

> I to jest pomysł alteranatywny.
> 
> > 1. Wszytkie konfiguracje trzymamy w plikach o jednolitej skladni (podobnej
> > do tej powyzej (to moze zalatwic np. "conflib").
[...]
> >
> > 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

:) super :) o to mi chodziło.

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

:) jeszcze lepiej :)

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


jak dla mnie bomba. Tylko potrzebne sa jakies templatey w C/shelu...

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

pewnie tak. IMHO DML by sie do tego dobrze nadawal.


-- 
Paweł Kołodziej 
pawelk w pld.org.pl 
I edycja konkursu na dobrą radę -- ,,WUCH 2001'' wciąż trwa
!!!    A T R A K C Y J N A   N A G R O D A  C Z E K A   N A   C I E B I E    !!!