rc-scripts. Logi z irc-debaty ;-)
Grzegorz Stanislawski
stangrze w open.net.pl
Wto, 4 Maj 1999, 22:22:22 CEST
Witam.
Oto logi z przeprowadzonej dzis na ircu dyskusji na temat rc-scriptsow.
Logowal moj BitychX wiec jest torszke krzaczkow. Mlego czytania.
Grzegorz Stanislawski
Open-Net / PKFL
ůíů Starting logfile IrcLog
IRC log started Tue May 4 16:35:27 1999
ůíů Value of LOG set to ON
<wiget> PEPSI: a IPV6ADDRS="3ffe:902:11::2/48 \
<wiget> 3ffe:902:10::2/126"
<wiget> shell sobie to ladnie zwinie w jedna linijkę
<PEPSI> wiget: a spacja po "\" i znowu kupa
<wiget> PEPSI: mnie się strasznie nie podoba linijka IPV6ADDRS=STOP
<PEPSI> wiget: to moze byc ADDR=END albo wogole nie byc, z tym ze skrypt
zawsze bedzie chodzil w grepa i petle
<wiget> niech wchodzi. nie będe płakał
<PEPSI> mi tez to nie przeszkadza bardzo
<wiget> PEPSI: próbowałeś może zrobić ip addr add 10.0.0.1 dev eth0 ?
<wiget> PEPSI: dziś coś takiego zrobiłem, ale nie wiem co to daje
<PEPSI> i poszlo?
<wiget> PEPSI: poszło
<PEPSI> daje aliasa na eth0 bez osobnego devica.
<PEPSI> do tego wlasnie zmierzam, zeby adresy byly bez rozdzielenia na ipv4 i
ipv6, ale chce to dobrze przecwiczyc
<wiget> [root w wiget /root]# ip addr add 10.0.0.2/24 dev eth0
<wiget> [root w wiget /root]# ip addr show ipv4 eth0
<wiget> 3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast
<wiget> link/ETHER 00:c0:df:e9:c1:64 brd ff:ff:ff:ff:ff:ff
<wiget> inet 156.17.210.110/24 brd 156.17.210.255 scope global eth0
<wiget> inet 10.0.0.1/32 scope global eth0
<wiget> inet 10.0.0.2/24 scope global eth0
<wiget> nie wiem jak sprawdzić czy to działa
<PEPSI> musisz miec druga maszyne w sieci i dac jej 10.0.0.3/24 i sprawdzic
pinga
<wiget> o nawet routing został się poprawnie ustawił :-)
<wiget> PEPSI: jak w freebsd dodaje się aliasa ? bo tylko taką maszyne mam
teraz na podorędziu
<PEPSI> nie mam pojecia, ale chyba tak samo: ifconfig eth0:0 addr up
<wiget> PEPSI: tam to nawet eth0 nie ma :-)
<PEPSI> no to nie wiem
IRC log ended Tue May 4 16:56:38 1999
ůíů Starting logfile IrcLog
IRC log started Tue May 4 16:56:40 1999
ůíů Value of LOG set to ON
<wiget> PEPSI: działa.
<PEPSI> no to fajnie
<wiget> PEPSI: tylko że ifconfigem to tego już nie ruszysz
<PEPSI> wiem ;-)
<wiget> PEPSI: chyba trzeba będzie zrobić hybryde iproute2 + net-tools tak jak proponował kloczek
ůíů kloczek [^kloczek w test2.zie.pg.gda.pl] has joined #pld
<kloczek> QQ
<kloczek> \/
<PEPSI> tylko jak? ludzie z przyzwyczajenia beda uzywac ifconfig jak bedzie a wtedy qpa
<wiget> O kloczku mowa :-)
<PEPSI> kloczek: pozwolilismy sobie zaczas troche wczesniej
<kloczek> na czym staneło ? ..
<PEPSI> na twojej hybrydzie
<wiget> kloczek: iproute2 + net-tools
<kloczek> a czy ja do czegoś tu jestem koniecznie potrzrbny ? :)
<PEPSI> no niewiem, moze powiedz jak to sobie wyobrazasz..
<kloczek> tak mi sięwłąsnieni wydawało że to będzie dobre
<kloczek> w zależności od tego co jest ustawiane to będziesię używać net-tools lub iproute2
<wiget> przed momentem sprawdziliśmy że można dodawać adresy ipv4 do dev bez robienia aliasa
<PEPSI> wlasnie wiget przecwiczyl u siebie to co wspominalaem na liscie, nie koniecznie musi byc rozdziala na IPV6ADDR i IPV4ADDR, tylko ze wtedy ifconfig jest za krotki
<kloczek> czyli ipv4 będzie domeną ipr2. To samo zdaje się z ipv6 (?)
<wiget> kloczek: ipv6 to już na pewno dla ipr2
<wiget> ipx i pozostałe przez ifconfig i popocnicze
<kloczek> dochodzi w tej chwili ipx
<PEPSI> ipv4 dla ipr2 umozliwi tez lepsze polaczenie z ipchainsami chyba
<wiget> koczek: tzn ?
<kloczek> Po za tym PLIP SLIP to też nt
<kloczek> ipx też przez nt .. tak jak napisałeś
<kloczek> czekajcie popatrzę sobie ciut na ipr2
<kloczek> a zapomniałem wczoraj wrzucić pakiet z ipr2 .. włąśnie przerzuciłem do test
<wiget> może jest nowsza wersja ;-)
<kloczek> Po za tym używająć ipr2 chyba można bawić się w QOS (?)
<wiget> QoS ? a co to ?
<PEPSI> mozna
<kloczek> Quality Of Service
<wiget> coś jak TOS ?
<kloczek> jedna dobra sprawa z ipr2 to to, że w zasadzie adewsy ipvr i ipv6 są nierozróżnialne .. przynajmniej tak mi wynika z ptzykładów użycia
<PEPSI> nie calkiem ;-) troche dluga historia, zagladnij do rfc
<wiget> PEPSI: ok
<kloczek> to znaczy, że w zasadzie nie musimy stosować różnych opisów dla ipv4 i ipv6 .. rozróznienie jest robione już na poziomie samych narzędzi ipr2
<wiget> kloczek zobacze czy w jednym cyklu można dodać adres ipv4 i ipv6
<wiget> oops. pomyliłem się. przecież na raz można dodawać jeden adres
<kloczek> jeden szczegol .. proponowałbym zeby jednak ograniczyc ilosc rzeczy wzucanyh bezposrednio do /etc
<kloczek> czyli teraz pora na ustalanie co gdzie wrzucamy
<wiget> kloczek: scrypty tak jak proponował Jacek /sbin/network-scripts
<wiget> kloczek: dane do /etc/sysconfig/interfaces
<kloczek> może być
<wiget> tzn: ifcfg-* i tunnel-*
<kloczek> teraz tak pliki rżóżne od ifcfg-* i tunnel-* w interfaces sa nie interpretowane (sposób na prostądeaktywację interfejsu
<kloczek> (sorki ale jem jeszcze loda i dośćciężko mi się stuka wkbd ;)
<PEPSI> to moze jeszcze przyjmijmy nazewnictwo tych plikow
<kloczek> ifcfg-* i tunnel-* to ogólna maska
<kloczek> w drugim członie mogłby być protokół
<wiget> IMHO tak jak podałem ifcfg-* dla opisu tego co potrzebne do szczęcia interface, a tunnel-* do tuneli
<kloczek> albo typ interfeju
<wiget> kloczek: który i tak może być olany bo wszystko jest w środku
<kloczek> zresztą można by olać pozostałe człony nazwy zakładając, że reszta opisu jest w pliku
<PEPSI> zgoda ale czy moglo by to byc ifcfg-moj_link_do_babci?
<kloczek> wiget: o .. dokładnie :)
<wiget> PEPSI: tak
<PEPSI> a tunel-w_ktorym_dziala_moj_link_do_babci tez?
<wiget> PEPSI: oczywiście
<PEPSI> fajne
<PEPSI> fajnie
<PEPSI> sprobujmy wymyslec jak powinien wygladac program konfiguracyjny
<PEPSI> pierwsza lista: ls ifcfg-* > lista z interfacami i przyciski dodaj zmien i usun.
<PEPSI> usun to rm ifcfg-costam
<PEPSI> dodaj to zapytaj o nazwe i touch ifcfg-nazwa i to samo okienko co modyfikuj
<wiget> PEPSI: ok
<PEPSI> a modyfikuj to okienko z polami jak w konfigu i lista adresow (ciurkiem bo ipv4 i ipv6 mozna teraz mieszac)
<PEPSI> aa i jeszcze przyciski dodaj usun i zmien adres
<PEPSI> w liscie
<wiget> PEPSI: no i adresy ipx
ůíů jajcus [jajcus w zeus.polsl.gliwice.pl] has joined #pld
<jajcus> Cze :-)
<PEPSI> ale nie moga byc razem z ip... moze osobny przycisk?
<wiget> PEPSI: tak
<PEPSI> spoznienie ;-)
<wiget> hi jajcus
<wiget> jajcus: 33 minuty spóźnienia :-)
<jajcus> Sorrki, mnie nie tak latwo na tego irca wejsc
<jajcus> Ominelo mnie cos waznego?
<PEPSI> poza tym ze company policy co do programu ustawiajacego iface'y to iproute2 to chyba niewiele
<wiget> jajcus: posumuwując: używamy iproute2 i net-tools. adresy ipv4 i ipv6 można mieszać bo iproute2 nie rozróżnia ich
<PEPSI> podesle ci loga
ůíů DCC No such file /home/stangrze/IrgLog exists
[dcc(SEND)] jajcus
đ kloczek/#pld is away: (Auto-Away after 10 mins) [BX-MsgLog Off]
<jajcus> PEPSI: dzieki
# ł Type ł Nick ł Percent Complete ł K/s ł File
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
#1 SEND jajcus Wait N/A IrcLog
đ wiget/#pld znika na 5 min
<PEPSI> jajcus: nie masz dcc?
<jajcus> PEPSI: Moze trudno w to uwierzyc, ale ja IRCA ni w zabbb :-) Moze lepiej na jajcus w zeus.polsl.gliwice.pl, jesli sie da
<PEPSI> napisz /dcc get PEPSI
đ wiget/#pld juz wrocil
[jajcus(jajcus w zeus.polsl.gliwice.pl)] Chyba cos nie tak ".... completed 1.055e-12 kbb/sec", a plik ma dlugosc 0 :-(
# ł Type ł Nick ł Percent Complete ł K/s ł File
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
<PEPSI> log off na chwile
IRC log ended Tue May 4 17:43:17 1999
ůíů Starting logfile IrcLog
IRC log started Tue May 4 17:43:41 1999
ůíů Value of LOG set to ON
<PEPSI> log on again ;-)
<kloczek> (musiałem odejść na chwilę) przypomniało mi się .. pliki z przykładowynmi konfiguracjami interfejsów mogłby być wg maski !* w katalogu iterfaces z %configure(missingok)
<PEPSI> jajcus: doszlo?
[jajcus(jajcus w zeus.polsl.gliwice.pl)] OK, jest :-)
<wiget> kloczek: a nie lepiej w %doc ?
<PEPSI> kloczek: tak wogole to mozna by wydobyc to wszystko z attica, i pozostawiac tam gdzie bylo, uklad plikow w paczce dystrybucyjnej ustawia sie przeciez w specu
<kloczek> wydaje mi się że przykądy lepiej mieć na miejscu, a dodanie missingok umożliwiłoby ich bezporoblemowe pozbycie się
<PEPSI> zgadzam sie.
<wiget> kloczek: ok. będom na miejscu wg !*
<kloczek> to odzyskiwanie ze stryszku jest torochę kłopotliwe .. odzyskiwać w takim razie resztę .. ??
<PEPSI> wracajac do mojego: w cvsie robimy sobie tak zeby sie dobrze pisalo, w zwiazku z tym konfigi i przyklady powinny byc razem z tym czego dotycza
<kloczek> (trzeba ręcznie modyfikować plik po przeniesieniu)
<PEPSI> a nie mozna cofnac sie o rewizje do tylu?
<wiget> kloczek: nie ma sensu. skoro wszystko jest już gdzieś to po co to zmieniać
<kloczek> fakt .. to czy pliki isysconfig/interfaces/!* zostaną zaznaczone jakoe %doc potem w specu to już jest inna kwestia .. na tym poziomie nie musimy się o to martwić
<PEPSI> i jajcus zacommituje jeszcze raz to co bylo dobrego
<jajcus> :-) Ale narozrabialem :-) ale przynajmniej sprowokowalem jakies dyskusje :-)
<kloczek> jajcus: lepszy ferment niż bezruch :)
<wiget> macie racje układ w repo jest mało istotny dla wyglądu pakietu.
<jajcus> Ja u siebie swoja wersje mam. Moge zrobic jej kopie, a wtedy mozna cofnac w CVS
<kloczek> także i to że onecnie network-scripts jest tam gdzie włożył to jajcus nie ma tu znaczenia
<wiget> PEPSI: jajcus: znacie troche autoconf/automake ?
<PEPSI> nie
<jajcus> Gozej jak wszycy zaczna przywaracac to co teraz jest dobrze. Kilka rzeczy moze sie powtorzyc
<jajcus> widget: ja troche
<kloczek> dobra to może jednak nie będę idzyskiwał plików ze stryszka i wykasuję to co częściowo próbowałem odzyskiwać (?)
<PEPSI> kloczek: cofnij rewizje do rc-scripts-0.0.3
<wiget> w rc-scripts bedzie to proste (autoconf/automake)
<PEPSI> ja mysle ze autoconf/automake to za duza armata jk na rc-scriptsy
<wiget> PEPSI: ale daje duża wygode pracy
<kloczek> PEPSI: ale jak już jest wytoczona to niech strzela :)
<jajcus> PEPSI,kloczek: Ale ponowne wrzucanie nowych rzeczy powinna robic jedna osoba, inaczej bedzie balagan
<PEPSI> kloczek: wlasnie jescze nie jest ;-)
<wiget> jajcus: widze że zgłaszasz się na ochotnika :-)
<PEPSI> a moze zrobmy sobie pliczek TODO i odfajkowywujmy go po koleii
<jajcus> widget: Oj nie wiem czy sie wyrobie. Ale w weekend moge sprobowac.
<wiget> jajcus: autoconf/automake zostaw dla mnie
<wiget> a zresztą zrobie wszystko sam :-)
<jajcus> widget: dobry pomysl, jak skonczysz to najwyzej dokonam malej korekty (o ile wogole bedzie potrzebna :-) )
<wiget> PEPSI: pisałeś o prostym programie konfiguracyjnym. możesz kontynuowac ?
<PEPSI> chyba sie juz wystrzelalem ale sprobuje
<kloczek> Dobra pliki z sysconfig/network-scripts przywrócone do postaci jak była przed modyfikacjami Jacka
<kloczek> coś jeszcze ?
<PEPSI> kloczek: IMHO wszystko do 0.0.3
<PEPSI> o zwolnila mi sie maszyna, bootne ja i pokukam (zwylke na moim develu chodzi winda)
<jajcus> Tylko niech przed kolejnym cvs update kazdy sobie zrobi kopie rc-scripts
<jajcus> Po co znowu wynajdowac kolo
<kloczek> dokładnie
<kloczek> wychodzi na to że chyba będę muusiał usunąć (fizycznie) zawartość sysconfig/{interfaces,ipchans.d} (będę maił ją w razie czego w backupie
<kloczek> usuwam sysconfig/{interfaces,ipchans.d}
<PEPSI> wracajac do programu konfigurujacego: co to powinno byc? whiptail/dialog czy cos wiekszego python/tcl/perl?
<jajcus> kloczek: Moze jeszcze nam progress-bar narysujesz :-)
<jajcus> PEPSI: Raczej dialog. Kobyly w pythonie/tcl troche mnie slabia.
<wiget> PEPSI: dialog ma ostatni jakieś problemy. może ktoś na się na tk ?
<wiget> PEPSI: chyba że newt
<PEPSI> jajcus: raczej python/tk lub tcl/tk. tk to same wigety
<kloczek> wiget: chyba newt z tymi wtyczkami do pythona/tcl jakie już Eric zrobił (w razie czego można tego użyć)
<PEPSI> grafika mogla by byc przez python/{gnome|gtk|qt}
<PEPSI> przeciaz whiptail to wlasnie newt
<jajcus> PEPSI: Na poczatku bez grafiki. Ew. potem grficzne wersje narzedzi.
<kloczek> dobra chyba wszystko gotowe. Proponuję teraz zasać rc-scripts
<jajcus> kloczek: zasysam, ale 0.0.3 to nie jest. Chyba ze wtedy autoconf nie zauwazylem..
<kloczek> autoconfa zostawiłem :)
<jajcus> kloczek: To sprytne, tylko, że nie pewne. Ale okaze sie w praniu.
đ PEPSI musi sie wziasc wkoncu za pythona, moze mi sie uda zrobic jakis python-{core|embeded} na potrzeby konfiguratora
<wiget> coś moje połączenie z repo osłabło
<jajcus> widget: U mnie pomoglo ^C i ponowna proba :-)
<wiget> kloczek: jest już glibc-2.1.1pre2, ale za jakiś dwa dni uda mi się to ściągnąć
<wiget> jajcus: s/widget/wiget/g
<jajcus> wiget: Sorry :-) wiget,wiget,wiget .... o juz umiem :-)
<wiget> jajcus :-)
<wiget> co zostało nam do ustalania ?
<kloczek> a jeszcze usunąłęm network-scripts z takalogu głównego
<jajcus> Spoznilem sie, a teraz jeszcze rozlacze sie przed koncem :-) Ale mam juz ponad godzine na liczniku i modem :-(
<jajcus> Cze wszystkim
<PEPSI> wiecie co by sie jeszcze przydalo. zeby iface'y ppp nie stawialy sie pokolei albo zeby mozna sie bylo pozbyc DEVICE=ppp{012} z ifconfiga
<PEPSI> ble. ... z ifcfg-ppp
ůíů jajcus [jajcus w zeus.polsl.gliwice.pl] has left #pld [jajcus]
<kloczek> PEPSI: tutaj jest potrzebna modyfikacja pppd i kernela żeby można było z zewnątrz podać nazwę interfejsu jaki ma być podnoszony
<wiget> na ppp to ja się nie znam
<kloczek> dobra usywam wszystkie pliki przykładkwe i dodaję je jeszcze raz pod nazwą !*
<PEPSI> tak myslalem, ciekawe natomiast czy mozna by postawic pppd baz adresow a pozniej ipr2 mu je nadac razem z labelem?
<PEPSI> kloczek: po co?
<wiget> PEPSI: co by była jasność
<PEPSI> ok, ale zachowajcie historie wersjii
<PEPSI> kloczek: jak sie robi branche?
<wiget> PEPSI: cvs tag -b nzawa_barncha
<PEPSI> ale jak zrobie commit to sie pomiesza i tak
<wiget> cvs ci -r nazwa_barancha
<kloczek> PEPSI: nowe przykłady doda się pod nazwą !*
<kloczek> dobra teraz układ skryptów .. mamy tunele i normalne interfejsy, mamy także różne typy mediów na których mogą być stawiane interfejsy
<wiget> ja znam tylko tunnele i eth. ppp slip itp są mi obce
<kloczek> może by zrobić tak że dać 2x<iolść_mediów> skryptów ? czy jakiś innych schemat po to żeby potem podzielić robotę nad poszczególnyymi częściami ?
<kloczek> czy wogóle dla wygody jakiś inny podział ?
<kloczek> przyjrzyjcie się jeszcze raz temu co zostało
<kloczek> ifcfg-lo zostawiłem
<kloczek> czy do ipv6 jest potrzebna jakaś inna definicja lo ?
<PEPSI> kloczek: ja bym to pocial wedlug iso/osi osobny skrypt dla warstwy 2 i 3
[zappa(~zappa w caffe.open.net.pl)] witam, poszedl wlasnie dysk na arzch
<wiget> {ifup,ifdown}-{ipx,ppp,ip,tunnel} co jeszcze ?
<PEPSI> tak, ::1/128
<wiget> PEPSI: tzn jak ?
<PEPSI> he, mam awarie. zaraz wracam
<kloczek> do tego wszystkiego w przyszłości mogą dojść jeszcze obsługa USB
<wiget> kloczek: iso/osi warstwa 2 to eth, ppp, slip, sl, tunnel ?
<kloczek> Moe by w takim razie interfejs lo wyciąć z opisów i traktować go jako coś podnoszonego automatycznie ?
<kloczek> czyli takie rzeczy jak plip czy slip byłyby w ip (?)
<wiget> chyba tak. lo nie powinnien być down'owany
<kloczek> czyli: jeżeli NETWORKING=yest - > to podnoś automatycznie lo0. Jak do tego miałoby się lo z ipv6 ?
đ PEPSI is back
<wiget> trzeba zrobić test ipv6 i jeśli pozytywny to dodać ::1/128 do lo
<kloczek> wiget: przypadek: nie mam wkompilowanej obsługi ipv6 .. co wtedy ?
<kloczek> wiget: kolejny przypadek: mam tylko ipv6
<PEPSI> to jest dobre. trzeba zrobic ls /proc/sys/net/ip* i zobaczyc
<wiget> prosty program z configure mrt:
<wiget> #include <sys/types.h>
<wiget> #include <sys/socket.h>
<wiget> main()
<wiget> {
<wiget> if (socket(AF_INET6, SOCK_STREAM, 0) < 0)
<wiget> exit(1);
<wiget> else
<wiget> exit(0);
<wiget> }
<wiget> a wcześniej modprobe net-pf-10
<PEPSI> a moze po prostu tak:
<PEPSI> if test -d /proc/sys/net/ipv4; then echo costam zrob; fi
<PEPSI> if test -d /proc/sys/net/ipv6; then echo costam zrob; fi
<kloczek> hmm .. jeżeli mam ipv6 lub ipv4 w module to powyższe powinno załadować te moduły
<PEPSI> no i oczywiscie else
<kloczek> PEPSI: chodzi jeszcze o przypadek kiedy obsługa protokołu jest w module i zostanie załadowana w momencie próbu jego użycai)
<PEPSI> no to najpoerw modprobe, albo na zywca add ::1/128 wtedy sie zaladuje
<kloczek> dobra czyli na początku /etc/rc.d/init.d/network jeżeli NETWORKING=yes powinny być modproby
<wiget> chyba najlepiej: ip add ::1/128 lo a moduły się same poładują
<PEPSI> tez tak mysle
<wiget> sprawdzając kod wyjścia dowiemy się czy wszystko ok
<kloczek> usuwam z network dołączanie /etc/sysconfig/network-ipv6
<PEPSI> wlasnie, nastepne bedzie /proc/sys/net/ipv{46}/all/ip_forward, i jak sie nie zaladowal ipv6 to znowu wyskoczy blad
<wiget> kloczek: i słusznie
<wiget> gdzie mają się w repo znaleść przykłady plików chat-* ?
<kloczek> Z forwardingiem to bym proponował żeby to co jest ustawione w /etc/sysconfig/network:$FORWARD_IPV4 olać
<kloczek> chodzi o to żeby przyjąć że default forward policy jest no
<kloczek> a odpowiednie odstępstwo od regóły żeby było w definicji interfejsu
<PEPSI> ok, masz racje
<wiget> kloczek: wolałbym jednak aby było brane pod uwagę. Po co mam wpisywać do wszystkich if tą samą informację ?
<kloczek> po to żeby można było to ustawić bezpośrednio przez echo "1" > /proc/sys/net/ipv{4,6}/<det_dev>
<wiget> admin będzie mógł sobie ustalić IPV4_FORWARD=no
<wiget> jak nie bedzie tego pola to by default bedzie no
<kloczek> nie wiem czy to tak działa ale w takim razie możnaby IPV{4,6}_FORWARD ustawiać w /proc/sys/net/ipv{4,6}/default/forwarding
<kloczek> przed podnoszeniem interfejsów
<kloczek> wogówl czy ktoś orientuje się jakie znaczenie mają zawartości /proc/sys/net/ipv{4,6}/all/* ?
<kloczek> i /proc/sys/net/ipv{4,6}/default/*
<kloczek> czy to jest tak jak wynika z intuicyjnego podejścia czyli all to zmienia na wszystkich interfejsach równocześnie a default to ustawienia domyślne dla nowo podnoszonego interfejsu ?
<PEPSI> pewnie tak, czy zatem, jak wpierw ustawie all=1 a pozniej eht0=0 to bedzie eth0=0?
<kloczek> (no response .. czyli trza do źródeł kernela zajrzeć :>
<wiget> nie wiem ale chyba tak (raczej /proc/sys/net/ipv[46]/conf/default
<PEPSI> w takim razie przeczytanie all/ip_forward powinno mi zwrocic watrosc nieokreslana? ale teraz to fantazjuje
<wiget> PEPSI: dalem echo 1 > all/forward; echo 0 > eth0/forward
<wiget> i jest tak jak wpisałem
<wiget> default/forward jest 1
<PEPSI> wiget a ile masz ifacow wogole?
<kloczek> dobra proponuję pierszy skrypcik network-scripts/network-init
<kloczek> tam się właduje takie rzeczy
<wiget> PEPSI: eth0 i lo
<kloczek> jak inicjacja różncych pierduł przed podnoszeniem wszystkich międzymordzi
<kloczek> chodzi o to żeby to wyciągnąć z /etc/rc.d/init.d/network
<wiget> kloczek: z touch /var/lock/subsys/network-init
<PEPSI> to wpisz jescze do lo/forward 0 i sprawdz all, a pozniej nadpisz all znowu=1 i sprrawdz w ifacach
<wiget> PEPSI: ok
<kloczek> wiget: po co ten pliczek ?
<wiget> kloczek: aby nie robić tego dwa razy
<kloczek> wiget: KPW
<wiget> PEPSI: zmiana all/forward na 1 nie znienia tego co jest w eth0/forward
<wiget> PEPSI: teraz mam defaul, lo i eth0 na 0 a all jest 1
<PEPSI> nic z tego nie kapuje
<wiget> PEPSI: ja też nie. ale jak się ustawi default/forward na jakąś wartość to nowy interface to przejmuje
<wiget> PEPSI: zastanawiam się co ipchains powiedzą na dwa adresy ipv4 na iface ?
<wiget> kloczek: wsadź do repo glibc 2.1.1pre2 z task'u
<kloczek> jeszcze jedno .. może by jednak te skrypty do międzymordzi pakować bezpośrednio do /sbin (jednak) ?
<kloczek> wiget: gdzie to leży ?
<wiget> mirror/ftp.kernel.org/pub/software/libs lub w pobliżu
<wiget> kloczek: może masz racje. /sbin/network-scripts jest nie zgodne z FHS 2.0
<PEPSI> wiget: przeciez chainsy ustawia sie po adresach ktore sa w pakietach a ni po devicach z ktorych przychodza
<wiget> PEPSI: można też po dev
<kloczek> wiget: decyzja o położeniu skryptóew jest mi teraz potrzebma do modyfikacji /etc/rc.d/init.d/network .. w takim razie (ze względu także na FHS) będzie w /sbin
<PEPSI> nie sadze aby byl z tym problem
<wiget> kloczek: to ja zmieniam w Makefile.am
<wiget> a co z network-functions ? IMHO do /lib
<PEPSI> ja muze na chwile zniknac. zoztawia sesje coby sie log dalej robil
<kloczek> network-functions chyba wogóle da się pozbyć .. tzn. że można będzie to rozparcelować po poszczególnych skryptach
<kloczek> Teraz kolejność podnoszenia .. najpierw interfejscy a potem tunele czy jest to nie istotne ?
<kloczek> czy wogóle musimy mieć jakąś kolejność podnoszenia interfejsów ?
<wiget> opisałem to w liście. jeśli if jest na tunelu to najpierw tunel
<kloczek> czy jest to potrzebne w jakis przypadkach ?
<wiget> jak tunnel ma reldev to reldev przed tunelem
<wiget> z network powiny być podnoszone tylko ifc. tunnele powinny byc podnoszone przez wywołanie w skryptach podnoszących ifc
<kloczek> czyli nie może być proste "for i in /etc/sysconfig/interfaces/ifcfg-* /etc/sysconfig/interfaces/tunel-*; do <podnoszenie> done"
<wiget> imho: for i in /etc/sysconfig/interfaces/ifcfg-* ; do <podnoszenie> done
<kloczek> ok : czyli w network powinno wystarczyć "for i in /etc/sysconfig/interfaces/ifcfg-*; do /sbin/if-up $i; done"
<wiget> właśnie tak
<kloczek> ok
<kloczek> ifup ma jeszcze drugi parametr {boot,fooboot,no} właśnie przyglądam się po co w RH to jest .. moze ktoś juz doszedł do tego ?
<wiget> jesli boot to stawiane są ifc z ustawionym BOOT=on
ůíů BitchX: Now logging messages to: /home/stangrze/.BitchX/BitchX.away
đ PEPSI is away: (Auto-Away after 10 mins) [BX-MsgLog On]
ůíů You have been marked as being away
<wiget> tzn drugim parametrem może być tylko boot.
<wiget> fooboot i no to tylko testy a nie prawdziwe paramety
<wiget> oops. zmienna to ONBOOT. Jeśli nie jest 'no' to ifc jest stawiany
<kloczek> Skoro jest /sbin/network-init to chyba w takim razie też trzeba zrobić /sbin/network-deinit (down chyba tu nie pasuje bo będzie się komuś kojarzyło z tym, że to jest do opuszczania kompletnego sieci)
<kloczek> albo uninit
<kloczek> jakoś unitit mi tu nie pasuje choć uninit też (ale mniej)
<kloczek> jakoś uninit mi tu nie pasuje choć deinit też (ale mniej)
<wiget> to network-init stop
[zappa(~zappa w caffe.open.net.pl)] co skompresowac z arzch ?
<kloczek> albo network-stop .. choć też sie za bardzo kojarzy
<wiget> dlaczego wogóle widzieliłeś network-init ?
<kloczek> chodziło o to żeby nie grzebać w /etc/rc.d/init.d/network
<kloczek> żeby zrobić prosty template na tym poziomie
<wiget> network-init {start,stop} powinnien być dobry
<kloczek> :) wiem ale to trochę wygląda tak jak w win .. chcesz zamkąć system to sięgnij do przycisku start ;-)
ůíů SignOff Nimir: #pld (bye)
<wiget> no to: /sbin/network {start,stop}
<wiget> albo network-base {start,stop}
<kloczek> wiget: to jeszcze ktoś pomyśli że to skrypt do startowania stopawania (wogóle) całej sieci .. chyba jednak lepiej będzie zostawić poroastu to w /etc/rc.d/init.d/network :)
<wiget> jasno i konsekwentnie
<kloczek> tyle, że zrobić poprostu dwie funkcje shellowe do inicjacji i deninicjacji (wsirodku network)
<wiget> może być
<kloczek> wogóle /etc/rc.d/init.d/network dobrze chyba żeby był w PATH (to znaczy żeby był link w /sbin lub odwrotnie)
<wiget> a po co ? przecież to ma mieć tylko {start,stop,status,restart}
<wiget> nie widzie innego zastosowania
<kloczek> wiget: chodziło mi o to że to się czasem przydaje mieć ten skrypt w PATH (w kilku miejscach nawet dorobiłem sobie link do /sbin)
<wiget> Jak tam nowa taczka ?
<wiget> Co robimy z pakietami dla i[56]86 ?
<kloczek> część podsumowania mam juz napisane (wczoraj zacząłem). Co do pakietów to kiedy chcasz
<wiget> Najlepiej było by jakbym brał src.rpm i robił jedynie --rebuild. Ale to wymaga wsześniejszego zwracania uwagi na %{_target} i %ifarch i386
<wiget> Wiesz może dlaczego jest tak słaby transfer wrocław <-> gdańsk ?
<kloczek> wiget: wiesz nie wiem .. w tej chwili mam straszne zakłucenia z taskeim
<kloczek> Już lepiej idzi mi komunikacja z ICM
<wiget> kloczek: na icm glibc 2.1.1pre2 są w /site/gnu-alpha/glibc
<kloczek> już dociągnąłem
<wiget> teraz tylko pytanie czy ja dociągne z repo
<kloczek> próbuj
<wiget> jeszcze glibc-thread
<wiget> przejrzałem pl.internet.komunikaty i nic nie ma na temat łącza wrocław <-> gdańsk. Pewnie problemy lokalne.
ůíů BitchX: You were /away for 0 hours 47 minutes and 55 seconds. [BX-MsgLog On]
ůíů You are no longer marked as being away
ůíů BitchX: Removed /home/stangrze/.BitchX/BitchX.away.
[ Channel ][ Nickname ][ user w host ][ level ]
[#pld ][@PEPSI ][^stangrze w stardust.open.net.pl ] [n/a]
[#pld ][@wiget ][wiget w wiget.t17.ds.pwr.wroc.pl ] [n/a]
[#pld ][@wiget_ ][wiget w zagloba.t19.ds.pwr.wroc.pl ] [n/a]
[ Channel ][ Nickname ][ user w host ][ level ]
[#pld ][ kloczek ][^kloczek w test2.zie.pg.gda.pl ] [n/a]
<PEPSI> jak tam?
<wiget> PEPSI: dobrze.
<PEPSI> wiget: dziala ci tunel do rzm'a?
<wiget> PEPSI: nie działają mi tunnele.
<wiget> PEPSI: czekam na rc-scripts aby się tym zająć
ůíů BitchX: Now logging messages to: /home/stangrze/.BitchX/BitchX.away
đ PEPSI is away: (Auto-Away after 10 mins) [BX-MsgLog On]
ůíů You have been marked as being away
đ wiget/#pld is away: (Auto-Away after 10 mins) [BX-MsgLog On]
<kloczek> siet .. musiałem się oddalić
<wiget> ok.
<wiget> ja też spadam
<wiget> kloczek: załaduj tylko glibc-linuxthreads do repo
<PEPSI> koniec filma. No to jak, puscic logi na liste?
<wiget> PEPSI: tak
ůíů SignOff wiget: #pld (*** Total uptime : 0d 7h 50m 17s)
ůíů SignOff wiget_: #pld (Leaving)
IRC log ended Tue May 4 22:16:14 1999
Więcej informacji o liście dyskusyjnej pld-devel-pl