rc-scripts kontynuacja
Tomasz Kłoczko
kloczek w rudy.mif.pg.gda.pl
Czw, 29 Kwi 1999, 21:44:25 CEST
Pliki z sysconfig/network-scripts/Attic są już przesunięte w repo o
katalog wyżej. Prosiłbym ponowne zaciągnięcie modułu z rc-scripts w.
------ fragment listu jakie wysłałem odnośnie opusu międzymordzi
Oto jak wygląda ogólny pklan i kilka rzeczy które próbujemy nakreślić dla
uzyskania nowej formy (ponioższe należy traktowaź jako szkielet do
wypełnienia i rzecz do dalszej dyskusji)
1) Wszystkie interfejjsy są opisywane w plikach ifcfg-<dev>-*
2) To co jest po ifcfg-<dev>- w nazwie pliku jest nieistotne i tutaj
każdy może sobie nadawać nazwy jakie chce (np.
ifcfg-eth0-tunel_do_babci)
3) W plikach opisujących interfejsy są zmienne:
PROTOCOL=[ipv4|ipx|ipv4]
IS_TUNEL=[yes|no]
4) Interfejsy z IS_TUNEL=no są podnoszone jako pierwsze
[.wtrącenie: potem Artur wymyślił inny sposób opisu w którym punkty 3 i 4
są niepotrzebne.]
5) Przy kombinacji PROTOCOL=ipv4 i IS_TUNEL=no mamy to co jest w skryptach
RH.
6) Przy PROTOCOL=ipv6 i IS_TUNEL=no w pliku opisującym międzymordzie mogą
być zmienne:
DEVICE, IPADDR, NETMASK, NETWORK, ONBOOT
7) przy PROTOCOL=ipv6 w pliku opisującym międzymordzie moze być:
LOCALIP, REMONTEIP, TTL, REALDEV, TOS, ONBOOT
8) może być kilka plików PROTOCOL=ipv6 i IS_TUNEL=[yes|no] i tym samym
DEVICE (np. DEVICE=eth0)
Powysze dawałoby możliwość łatwego uzupełnienia obrazu o robienie tuneli
wmiędzy wszystkimi trzena rodzjami międzymordzi. Uzupełnić by trzeba opis
ipx, a także inne nie wymienione rzeczy (króre zostały pominięte).
Kwestie do rostrzygnięcia to:
- routing statyczny i jego opis.
W trakcie dyskusji także padła propozycja żeby kierowaźć się w większym
stopniu nazwą plików w celu rozróżniania rodzajów interfejsów, co
zmniejszałoby ilość otwarć plików i ich analizy.
Aliasy międzymordzi moznaby rozwiązać podobnie jak to byłoby do tej pory.
----koniec pierwszego fragmentu i kontynuacja z następnego listu:
> Aliasy międzymordzi moznaby rozwiązać podobnie jak to byłoby do tej
pory.
Wdług mnie powinno to wyglądać tak:
1. Opis interafe w pliku ifcfg-<cokolwiek> o formacie:
PROTOCOL={ipv4|ipv6|ipx}
[.wtrącenie: co do poniżeszego, które Artur dodał w nastpny liście, że
wszystko co jest w [ ] jest opcjonalne.]
if PROTOCOL=ipv4; then
[ ALIAS={no|yes} ]
if ALIAS=yes then
DEVICE=<real device name>:<aliasnumber>
else
DEVICE=<name>
[ BOOTPROTO={none|bootp|dhcp} ]
fi
ADDR=<IPv4 addres>
[ NETMASK= ]
[ NETWORK= ]
[ BROADCAST= ]
[ ONBOOT={no|yes} ]
[ MULTICAST={|no|yes} ]
elif PROTOCOL=ipv6; then
DEVICE=<name>
ADDR=<IPv6 addres>/<prefix len>
[ ADDR=<IPv6 addres>/<prefix len>
...
ADDR=STOP ]
[ ONBOOT={no|yes} ]
[ MULTICAST={|no|yes} ]
elif PROTOCOL=ipx
DEVICE=<name>
FRAMETYPE={802_2|802_3|ETHERII|SNAP}
NETNUM=
[ ONBOOT={no|yes} ]
[ PRIMARY={no|yes} ]
fi
[ MTU= ]
[ METRIC= ]
if DEVICE=eth* ; then
[ MEDIA={auto|10baseT|10base2|AUI} ]
[ MAC=<hw addres> ]
elif DEVICE=ppp* || DEVICE=slip* ; then
PERSIST=yes|no
MODEMPORT=<device, say /dev/modem>
if DEVICE=ppp* ; then
DEFROUTE=yes|no
ESCAPECHARS=yes|no
HARDFLOWCTL=yes|no (yes imples "modem crtscts" options)
PPPOPTIONS=<arbitrary option string>
PAPNAME=<"name $PAPNAME" on pppd command line>
REMIP=<remote ip address, normally unspecified>
MRU=
DISCONNECTTIMEOUT=<number of seconds, default currently 5>
RETRYTIMEOUT=<number of seconds, default currently 60>
INITSCRIPT=<modem command>
DATAFORCHAT=<list of variables>
<anything>=<anything> (for chat script)
fi
fi
2. Tunele opisane są w plikach tnlcfg-<cokolwiek> o formaci:
MODE={ipip|gre|sit|ipxip}
DEVICE=<device name>
if MODE=ipxip ; then
?
else MODE=ipip || MODE=gre || MODE=sit ; then
REMOTEADDR=<IPv4 addres>
[ LOCALADDR=<IPv4 addres> ]
[ REALDEVICE=<name of physic device>
[ TTL= ]
[ TOS= ]
[ SEQ={no|yes} ]
[ ISEQ={no|yes} ]
[ OSEQ={no|yes} ]
[ KEY= ]
[ IKEY= ]
[ OKEY= ]
[ CSUM={no|yes} ]
[ ICSUM={no|yes} ]
[ OCSUM={no|yes} ]
[ NOPMTUDISC={no|yes} ]
fi
Tunele są tworzone najpierw (aby mogły powstać odpowiednie logic device)
a póżniej konfigurowane są miedzymordzia (logiczne też).
Jeśli coś opuściłem/pominołem prosze mnie poprawić.
Ruting musi być podzielony na dwa pliki:
static-routes
static-routes-ipv6
(w kernelu też są różne tablice opisujące ruting dla róznych protokołów)
Format static-routes:
<device> <network> <netmask> <gateway> <metric> <mss> <window> <irtt>
Format static-routes-ipv6
<device> <network/prefix len> <gateway> <metric> <mss> <window> <irtt>
<mss> <window> i <irtt> byłyby opcjonalne i trzeba się zastanowić nad ich
kolejnością.
----- koniec uzupełnienia Artura
----- Potem były jeszcze uwagi Grześka
> if DEVICE=eth* ; then
>
> [ MEDIA={auto|10baseT|10base2|AUI} ]
> [ MAC=<hw addres> ]
Czy to jest potrzebne?
Moze robic problemy z pcimcia
> 2. Tunele opisane są w plikach tnlcfg-<cokolwiek> o formaci:
>
> MODE={ipip|gre|sit|ipxip}
> DEVICE=<device name>
> if MODE=ipxip ; then
> ?
Czy ktos kto zajmuje sie ipx'em mogly przecwiczyc stawiane ipx na
"standardowym" tunelu sit?
Na moj rozum powinno sie to robic identycznie jak na zwyczajnym device'ie
np eth0.
Jesli tak to MODE=ipxip stalo by sie "obsolete".
> else MODE=ipip || MODE=gre || MODE=sit ; then
> [ REALDEVICE=<name of physic device>
Niepotrzebne (IMHO)
> Ruting musi być podzielony na dwa pliki:
> static-routes
> static-routes-ipv6
Niekoniecznie, mozna dodac Address_family (-A {inet,inet6,ipx,netrom etc)
Pozostaje jeszcze kwestia czy przemieszanie ich w jednym pliku nie
spowoduje chaosu w zarzadzaniu trasami.
--- koniec Uwag Grześka
Ze swojej strony dodam jeszcze, że chyba nie jest potrzebne rozróżnienie
na tablicę routingu do ipv4 i ipv6. Tu można się pozastanawiać jeszcze.
Jeszcze jedna uwaga jaka mi się nazuwa to jest zmienienie regół ip
forwardingu. Dotąd wszędzie się to traktuje tak, że jest tylko włączenie
wyłaczenie FWD i zapomina się, że jest możliwość włączania forwardingu per
interfejs operując na /proc/sys/net/ipv{4,6}/conf/<net_dev>/forwarding
Wogóle należałoby się jeszcze przyjrzeć także włąśnie zawartości tych
plików które są w /proc/sys/net/ipv{4,6}/conf/ gdyż tutaj IMHO są jeszcze
obszary mało eksploatowane.
Co do tego co jest obecnie w /etc/sysconfig/network->FORWARD_IPV4 to można
to wrzucać do /proc/sys/net/ipv{4,6}/conf/default/forwarding przed
podnoszeniem międzymordzi traktując to jako default forward policy.
Teraz proponuję się jeszcze raz nad powyśzym zastanowić. Prosiłbym także o
uwzględnienie poprzedniego listu z punktami wyznaczającyymi taktykę zmian
i sposób podejścia do powyśzego po to żeby przedyskutować jeszcze rzeczy
wątpliwe.
Dobrze by było gdzybyśmy do jutra mieli dokument opisujący sprawy
międzymordzi ale uwzględniając to, że sprawa nie jest prosta gdyż obejmuje
sporą ilość drobnych szczegółów i to że już jest późno prosiłbym o to żeby
faktyczną dyskusję przenieść na dzień jutrzejszy pozostawiając sobie
czas jaki pozostał jeszcze dizsiaj na próby przemyślenia powyśzego.
W razie czego proponuję jutro dodatkowo jakąś drobną dyskusję na #pld.
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*
Więcej informacji o liście dyskusyjnej pld-devel-pl