Burdel w rc-scripts.spec

[Tomasz Kłoczko]

On Thu, 18 Mar 1999, Grzegorz Stanislawski wrote:
[..]
> > Może zrobić jeden adres <-> jeden plik w /etc/sysconfig/network-scripts ?
> > W każdym pliku mógłoby być DEVICES i wiadomo by było do którego
> > co wymyślili w RH. Pliki mogłyby się wtedy nazywać:
> > Może wogóle byłoby dobrze, żeby w nazwie pliku figurowała nazwa maski
> > sieci ? (niezależnie od tego czy to jest ipv4 czy ipv6). To mogłoby
> > zwiększyć czytelność całości. Jeżeli nie konievcznie w nazwie maska to
> >
> Tylko to sie wiaze z tym, ze adresy i device'y  (i moze netmaski) powinny
> byc w takim przypadku odzyskiwane z nazwy pliku. Co wiaze sie z dosc
> powaznymi komplikacjami. Dlaczego? ano dlatego ze jakby wewnatrz takiego
> pliku byly zdefinoiwne zmienne ADDR czy NETMASK to zawsze jest szansa ze
> ich wartosci beda rozne od tych w nazwie.
> Poza tym jak sobie wyobrazasz ifcfg-ppp0 z dynamicznym ip w nazwie. 0.0.0.0?
> 
> rozwiazanie 1 adres - 1 plik nie podoba mi sie z 2 powodow:
> 1. tych plikow bedzie za duzo.
> 2. 80% danych w tych plikach bedzie sie powtarzalo. Nie chodzi mi
> bynajmniej o dyski bo te pliki sa malusienikie ale o to zeby byly one
> spojne pomiedzy soba (dotycza przeciez tego samego interfejsu)

Wporządku. Sam trochę tak na wyrost puściłem pomysł bo sam ipv6 na razie
nie używam, a wydawało mi się, że może to być coś porzytecznego. Uważasz,
że tak nie jest ? Nie będę się spierał, a jakąś ewentualną korektę
własnego zapatrywania na powyższe odłoże sobię na czas kiedy przyjdzie mi
tego używać.
Prosiłbym tylko o pamiętanie o tym, że format plików kofiguracyjnych, ich
zawartość w pewnym sensie też bedą powiązane z jakimś konfiguratorem
interakcyjnym. Powią zania ścisłego oczywiście nie musi być. Chodzi tylko
o to, że jedno ma na drugie wpływ i drobna korekta opisu konfiguracji może
mieć jakiś wpływ na łatwość zrobienia takiego nazredzia do konfiguracji.

> > PS. stanęła także dalsza dyskuja o skrypcie do inet. czy to ma w takim
> > razie oznaczać, że istnieje jakiś poziom przyzwoleia na końcowa postać
> > pomysłu ? (z mojego ostatniego listu), czy może ktoś ma jeszcze jakieś
> > inne pomysły lub przynajmniej widzi jakieś wady w tym co do tej pory było
> > ustalane ?
> >
> Mnie sie to podobalo.
> Rozumiem ze nalezy to dolozyc do rc-scriptsow.
> 
> Mysle ze powinnismy zamknac rc-scripts w tym stanie, zrobic z niego rpm'a
> i dopiero zaczac sie bawic z nowymi sprawami.

OK. inet-scripts (może byc ? standardowe trzy dni na zgłoszenie innej
propozycji nazwy, a potem wrzutka modułu do CVS ;) to raczej w coś
osobnego trzebaby to załadować gdyż nie wszędzie bedzie sieć, a
tymbardziej sieć z odpalanymi serwisami i nie wszędzie będzie to
potrzebne. Dobra dokładam obsługę kolorów do rc-scripts i biorę się za
inet.

[..]
> PS. Moze moglibysmy dostac nowa liste dyskusyjna na rc-scriptsy, zeby nie
> robic tu tloku.

To nie będzie chyba temat stały. Raczej tutaj się pomieścimy z tym
tematem.

> PS2. Teamy rc-scripts i instalator powinny sie jakos ze soba zaczac
> dogadywac, zaraz pojawi sie kwestia programow konfigurujacych.

Dokładnie. Osoby próbujące robić instalator powiny mieć tu swój udział
(choćby w postaci opinii czy nie widzą przeciwskazań). Tak czy inaczej
teraz nie ma co się martwić tym, że uda się przewidzieć czy też nie
wszystkie wpływy i powiązaniatych skryptów z innymi rzeczami. Najwyżej
będziemy potem to korygować. Ważne żeby możnabyło od czegoś już teraz
zacząć.

> PS3. Wpadl mi do glowy szatanski pomysl: Moze by PLD-config o ile
> powstanie robilby dynamicznie rpma z plikami konfiguracyjnymi i od razu
> upgradeowal nim system. Bedziemy w ten sposob mieli kontrole nad prawami,
> md5sum itd. na tych plikach oraz backupy poprzednich konfiguracji.

Łaj not ? Ja się zastanawiałem nad silniejszym powiązaniem konfiguracji
jakimś repozytorium cvs. Przynajmniej w przypadku grup stacji roboczych
miałoby to na pierwszy rzut oka sens. Po za tym jeśli chodzi o propagację
konfiguracji to jeszcze trzebaby się przyjrzeć cfengine.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*