znowu rc-scripts (fwd)

Pią, 30 Kwi 1999, 09:30:35 CEST

On czw, 29 kwi 1999, Tomasz Kłoczko wrote:
> On Thu, 29 Apr 1999, Grzegorz Stanislawski wrote:
> 
> 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.
Widać moje logi do CVSa były bardzo niekompletne i mylące.
Ja właściwie niczego co było używane nie usunąłem (mam nadzieję).
Najwyżej przeniosłem gdzie trzeba i uaktualniłem odpowiednie skrypty.

> 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.
Tu nic się niezmieniło. Tylko przyszło kilka opcji.
A "%post" w specu robi co trzeba, aby z network-scripts/ifcfg-* zrobić interfaces/*.
Jeśli coś jest nie tak można to jeszcze poprawić.

> 
> 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.
Pewne podsumowanie jest w plikach *.txt. Starałem się je uaktualniać na bierząco.

> 
> 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.
Według mnie trzymanie skryptów razem z plikami konfiguracyjnymi jest trochę bez sensu. A że to nie powoduje wielkich niekompatybilności (mniejsze niż kolorki przy starcie, które IMHO są super).

> 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.
I jest zrobione tak jak pisałeś.

> 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.
Sądze, że takie rzeczy spokojnie mogą być w jednym module źródłowym.
Oczywiście inne pakiety wynikowe. 
Niepotrzebne jest rozrzucanie skryptów specyficznych dla naszej dystrybucji
po różnych pakietach. Szczególnie że mogą one być dość zależne od siebie.

> 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).
Myślałem nad tym (żeby opisywać regółki). Problem w tym, że siła ipchains leży
w różnorodności funkcji jakie on daje.
Wiele regółek może nie podawać źródła, celu ani protokołu pakietu a realizować
ważne rzeczy np. accounting. Gdyby to zrobić tak jak firewall-init pliki byłyby bardzo szerokie ... i w większości puste.
Z tego też powodu wyraźnie widnieje nazwa ipchains - skrypt ten służy do konfiguracji tego potężnego mechanizmu. Jakiekolwiek uogólnianie znacznie może ograniczyć uniwersalność.
Zresztą nie widzę powodu, żeby jakieś pakiety mogły coś dodawać do tych plików
(chyba że jakieś transparent-proxy) - więc uzytkownik może mieć możliwość
wyboru między różnymi systemami.
Np. w hdparm też możnaby się pokusić nad bardziej opisowym plikiem
konfiguracyjnym, bez wpisywania opcji na sztywno. Jednak wtedy skrypt
konfigurujący byłby znacznie bardziej skomplikowany i trzebaby go było
uaktualniać dla każdej nowej wersji hdparm. Podobnie jest z ipchains.
Nawet jak zrobimy to jak firewall-setup, to będzie musiało pozostać pole
"OPTIONS", któr ciągle będzie ipchains-specific.

Taka jest moja argumentacja. Ale oczywiście można to zrobić inaczej.

Pozdrowienia,
     Jacek
-- 
+---------+--------------------------------------------------------+
!      ,  !            Jacek Konieczny, Gliwice, Poland            !      
! Jajcus  !   email: jajcus w zeus.polsl.gliwice.pl, jacek w kde.org   !
!         ! ICQ# 7149127                           WWW: none (yet) !
+---------+--------------------------------------powered-by-Linux--+