znowu rc-scripts (fwd)

[Tomasz Kłoczko]

On Thu, 29 Apr 1999, Grzegorz Stanislawski wrote:
[..]
> > > PLD to nie wolna amerykanka, kazdy ma swoj odcinek frontu i trzeba robic
> > > tak zeby ci co na nim operuja nie byli zaskakiwani rajdami z innych stron.
> > Jak się wszyscy zaczną ograniczać to nic nigdy nie zrobimy.
> > Ja co kolwiek robię staram się dać na listę i staram się, żeby to co
> > robię w miarę regularnie wrzucać do CVS - w ten sposób każdy widzi co
> > się dzieje i może zareagować zanim wejdę w jakieś maliny 
> > 
> A jak bedzie totalny burdel to tym bardziej nic nie zrobimy.
> Przez jakis czas nie interesowalem sie specem do rc-scriptsow, nie uwazam
> sie za speca od specow, efekt byl tego taki ze w cvs'ie bylo jedno a w
> specu i na ftp co innego.

Tylko spokojnie.
Też zacząłem się bliżej przyglądać zawartości CVSa jeśli chodzi o
rc-scripts. Kilka uwag.

Po pierwsze nie do przyjęcia jest to co się stało czyli, że zostały
usunięte pliki z obecną obsługą i na to miejsce nie zostało włożone
dokładnie nic. Zaraz przesunę ręcznie pliki z
sysconfig/network-scripts/Attic katalog wyżej i trzeba będzie kontynuować
to co było. Tam jest sporo rzeczy już zrobionych które tezeba
przegrupowywać, pouzypełniać ale na pewno nie wycinać całokowicie.

Po drugie. Pojawił się katalog sysconfig/interfaces. Niby dobrze ale
jak na razie nie ma opracowanego sposobu przejścia z opisu interfejsów
jakie jest w RH na nowy. Też nie do przyjęcia. Przy opracowywaniu
rc-csripts trzeba pamiętać o tym żeby instalacja rc-scripts o ile opis
interfejsów będzie inny zapewniała automatycznie konwersję do nowego opisu
międzymordzi.

Po trzecie. Jeszcze raz trzeba podsumować założenia opisu interfejsów i
zacząć już normalną pracę w momencie keidy uznamy, że ten pis jest
kompletmy. Reszta szczegółów wyjdzie na etapie implementowania. Zaraz
poszukam tamtego listu jaki wtedy wysłałem i spróbuję jeszcze raz podesłać
to uwzględniając wnioski jakie wtedy wyszły w dyskusji.

Po czwarte. Nie zapominajcie o jednym żeby nie robić czegoś co jest
kompletnie inne w porówniau do tego co już jest (rozwiązanie RH). Tam
gdzie można takie podobieństwo rozwiązań/wyglądu/opisu interfejsów powinno
być zachowane. Wszelkie zmiany jeżeli już mają być wprowadzane to tylko
dlatego, że inaczej się nie da lub z powodu tego, że rozwiązanie oparte o
trzymanie się poprzedniego modelu ewidentnie łamie spójność całości.

Po piąte. Całość powinna być prosta. Każda rzecz którą można zrobić
prościej taką należy zrobić. Przykład poprzedniego listu z uwagą dotyczącą
ADDR.

Po szóste. W całość Jacek próbuje od razu zapakować obsługe FW. IMHO nie
potrzebnie. Skrypty do FW mogą i wzwiązku z tym powiny być kompletnie
niezależnie od rc-scripts. Nie róbmy rozwiązania typu KombajnBizon. Tutaj
decydujące jest założenie prostoty i modularności. Przykład to
firewall-init do ipfwadm jakie RH nie wprowadził nie wiedzieć czemu do RH
5.x. I kolejna sprawa w tym temacie .. dobrze by było skrypty do FW
szykować tak samo jak rc-scripts tzn. nie bezpośrednie wołania (tam)
ifconfig/route/.. czy ipchans (tu) tylko wprowadzić pliki z opisami regół
FW. To się przydaw momencie kiedy pojawi się np. wsparcie do TIS czy moze
jeszcze jkiś innych rzeczy. Dzięki temu będziemy mieli czyste regóły które
będzie można pakować w różne mechanizmy FW. Dobrym przykładem jest tu
firewall-init, który według tych regół mniej więcej był tworzony (przez
przypadek choć może i nie :). I kolejna sprawa która jest konsekwencją
powyższego .. nazwy plików i katalogów w związku z tym nie powinny być
związane z narzędziem (tak jak to Jacek obecnie zaproponował gdzie jest
sysconfig/ipchains.d).

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*