Burdel w rc-scripts.spec

Grzegorz Stanislawski stangrze w open.net.pl
Czw, 18 Mar 1999, 23:57:03 CET


On Thu, 18 Mar 1999, Tomasz Kłoczko wrote:

> On Thu, 18 Mar 1999, Grzegorz Stanislawski wrote:
> >  Dopiero teraz to do mnie dotarlo.
> > 1. Spec mowi o wersji 3.66 tymczasem w CVS'ie od poczatku bylo
> > RedHatowe 3.78
> Poprostu zamiast mówić, że coś jest do zrobienia trzeba to także próbować
> po kawałku robić.
> 
Ugh. po porostu nie interesowalem sie specem. Zreszta tym powinien zajac
sie ten kto go tam wsadzil.

> Na skryptach startowych pozostaje 754. na parametrach konfiguracyjnych o
OK. 

> > 4. %changelog zajmuje 2/3 speca. Litosci. Zreszta od trzymania changeloga
> > mamy cvs.
> Wyciąć to co stare (RH) i napisać na końcu, że nbazuje na initscripts
> <wersja> z RH. W przypadku długich %changelog gdy rzeczywiście to juz
> przeszkadza można to przyjąć.
i tak to bylo, jak go wrzucalem do cvs'a.

> > Co to uwagi kloczka na temat ipv6 po bozemu (SysV), co powiecie na:
> > osobne konfigi w stylu np i6cfg-eth0
> > przetwazane przez ifup po postawieniu odpowiedniego ipv4 (ifcfg-eth0)
> 
> 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)

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

> Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*
> 
Grzegorz Stanislawski
Open-Net / PKFL

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

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

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.




Więcej informacji o liście dyskusyjnej pld-devel-pl