🚀 go-pugleaf

Posted-By: auto-faq 3.1.1.2
Archive-name: news-pl-faq/part2

Newsy w Polsce (FAQ) - czesc 2. - serwery news

Ponizszy tekst, to druga czesc FAQ na temat newsow w Polsce, zawierajaca uwagi
na temat konfigurowania serwerow news. Wszelkie poprawki i uzupelnienia prosze
kierowac na adres tsur...@news.ict.pwr.wroc.pl Aktualna wersje calego FAQ
mozna znalezc zawsze we Wroclawiu przez WWW:
http://www.ict.pwr.wroc.pl/doc/news-pl-faq.html, FTP:
ftp://ftp.ict.pwr.wroc.pl/pub/faq-pl/news-pl-faq.2 (druga czesc), oraz w
grupach news pl.news.admin i pl.answers.
-------------------------------------------------------------------------------

Spis tresci czesci 2.:

Konfiguracja serwera news
     Jak skonfigurowac serwer news (grupy pl.*)
     Jak skonfigurowac mail2news i news2mail
     Newsfeed za pomoca UUCP
     Kompresja batchow za pomoca gzip
     Inne mozliwosci przyspieszania transmisji

-------------------------------------------------------------------------------

Konfigurowanie serwerow

-------------------------------------------------------------------------------

Jak skonfigurowac serwer news (w Polsce)

To zalezy od samego serwera... i najlepiej wyjasnione jest w odpowiednich
README lub FAQ towarzyszacych serwerowi. Ponizej jednak pare uwag specyficznych
dla wlasciwego skonfigurowania serwera w Polsce. Z gory zastrzegam, ze dotyczy
to (na razie) praktycznie wylacznie serwera INN, gdyz tylko takiego mialem
okazje konfigurowac i na tym sie znam ;-)

Przez $inn okreslal bede katalog, w ktorym znajduja sie pliki serwera, a wiec
np. standardowym miejscem na 'active' jest $inn/active lub $inn/lib/active,
serwer news to $inn/bin/innd itp...

Plik active ($inn/active)

Plik ten zawiera spis wszystkich grup, ktore serwer otrzymuje. Jesli
uruchamiamy nowy serwer, najlepiej jest sciagnac aktualna wersje takiego pliku
z innego serwera news (ktory bedzie nas w newsy zasilal) za pomoca protokolu
nntp, lub z ftp.uu.net poprzez ftp. Pierwsze wyjscie polega na wykonaniu
'$inn/bin/getlist -h jakis.serwer.news.pl active', drugie - uzyciu 'anonymous
ftp' ale uwaga... ftp.uu.net, mimo ze od jakiegos czasu posiada takze grupy
pl.*, to nie wszystkie niestety zostaly tam poprawnie zalozone. Dlatego lepiej
skorzystac z fragmentow pliku active, dotyczacego grup pl, a znajdujacego sie
pod adresem ftp://ftp.ict.pwr.wroc.pl/pub/faq-pl/pl.active. Plik ten jest
codziennie automatycznie uaktualniany na podstawie pliku active serwera
news.ict.pwr.wroc.pl.

Po otrzymaniu takiego pliku 'active', najlepiej wyzerowac w nim numerki
oznaczajace numery artykulow prosta instrukcja:

        mv active active.old
        awk '{printf ("%s 0000000000 0000000001 %s\n", $1, $4)}' < active.old > active

nie zapominajac o tym, ze jesli serwer news juz dziala, to MUSI zostac
wczesniej zatrzymany np. przez '$inn/bin/ctlinnd pause xx' a ponowne
uruchomienie powinno nastapic przez:

        ctlinnd reload active ''
        ctlinnd go ''

Jesli dopisac trzeba pojedyncze nowe grupy w juz dzialajacym serwerze, nalezy
do tego uzyc 'ctlinnd newgroup pl.nazwa.grupy y', bez uprzedniego zatrzymywania
serwera.

Plik newsfeeds ($inn/newsfeeds lub $inn/site/newsfeeds)

Zalezy od tego, kto zasila nas w newsy i komu newsy sa dalej posylane. Jest on
naprawde dobrze udokumentowany w INND FAQ oraz na stronie manuala, wystarczy
wiec moze jedynie 2 male przyklady...

'feed' dla komputera o adresie 'news.host.pl' dopisujacego w polu 'Path:' nazwe
'news.host.somewhere.in.pl' powinien w najprostszym przypadku wygladac tak:

        xxx/news.host.somewhere.in.pl\
                :*/!local:Wnm:

gdzie xxx jest dowolnym (w miare krotkim, bo pojawia sie wielokrotnie w logach)
akronimem reprezentujacym danego hosta, wystepujacym rowniez w pliku
'nntpsend.ctl':

        xxx:news.host.pl:::-T1720 -t300

gdzie nazwa 'xxx' zostaje zwiazana z adresem internetowym 'news.host.pl'. Warto
przy okazji zwrocic uwage na parametr -T1720 (lub podobny) zamiast
'standardowego' -T1800. Parametr -Tn oznacza, ze jedna sesja nntpsend nie moze
trwac dluzej niz n sekund. W przypadku n=1800, oznaczaloby to dokladnie 30
minut. Standardowo nntpsend jest startowany z crontab-a co 10 minut, a wyglada
to mniej wiecej tak:

        0,10,20,30,40,50 * * * * /usr/lib/news/nntpsend

Gdy pojawia sie sytuacja, ze newsow jest na tyle duzo, ze nntpsend jest w
stanie pelne 30 minut wykorzystac, to konczenie tuz po tym, jak crontab
wystartowal nowego nntpsend, ktory sie skonczyl, stwierdziwszy ze poprzedni
jeszcze dziala, jest marnotrawieniem kolejnych 10 minut, czyli 25%
przepustowosci lacza. Dlatego czas dla -T powinien byc wielokrotnoscia 10
minut, pomniejszona o 1-2 minuty, by dac programowi nntpsend czas na
'posprzatanie' w momencie konczenia dzialania. Druga sprawa pozwalajaca
przyspieszyc docieranie news z jednego konca Polski w drugi jest to, by na
sasiadujacych serwerach news czasy wysylania batchow byly nieco poprzesuwane,
np. jesli 'mapka' serwerow wyglada tak:

        bilbo   <--->   okapi   <--->   sun1000

to jesli, przykladowo, na bilbo nntpsend startuje o pelnej godzinie i dalej co
10 minut, to na okapi powinno to byc np. 5 minut po pelnej godzinie i dalej co
10 minut (czyli 5,15,25,...), a na sun1000 znowu o pelnej godzinie. Natomiast
jesli jeszcze istnieje dodatkowe polaczenie bilbo <---> sun1000, to jeszcze
lepiej jest, gdy bilbo ma 0,10,..., okapi np. 3,13,23,33,... a sun1000
6,16,26,...

Drugi krotki i z zycia wziety przyklad (wg mapki z pierwszej czesci FAQ).
newsfeeds na okapi: fuw dostaje wszystkie lokalne artykuly (tzn. takie, ktore
nie byly w Warszawie ani w USA) oraz comp.security* ktore nadchodza z USA lub
lokalnie:

        cocos!all/news.nask.org.pl,fuw.edu.pl,wariat.org\
            :*,!pwr.*,/!local,!pwr,!wroc\
            :Tm:cocos

        cocos!sec/news.nask.org.pl,fuw.edu.pl\
            :!*,comp.security*,alt.security*/!local,!pwr,!wroc\
            :Tm:cocos

        cocos:!*:Tf,Wnm:

Pierwsze 2 linijki to 'wejscie lejka' o wspolnym ujsciu nazwanym 'cocos', przy
czym 'cocos' nie ma tutaj NIC wspolnego z nazwa komputera, na ktory zostanie to
wyslane. Pierwsza linijka odnosi sie do wszystkich artykulow, ktore nie
nadeszly z Warszawy ani z USA, druga - do wszystkich artykulow z grup
'security', ktore nie nadeszly z Warszawy. Ostatnia linia to 'ujscie lejka'
prowadzace do pliku 'cocos' w katalogu /var/news/out.going (lub odpowiednio
innym), gdzie zapisywane sa odsylacze do artykulow, wykorzystywane co 10 minut
przez innxmit. Symboliczna nazwa 'cocos' jest tlumaczona na rzeczywisty adres
komputera (ktorym jest 'news.fuw.edu.pl') w pliku 'nntpsend.ctl':

        cocos:news.fuw.edu.pl::-T1720 -t300

Plik moderators

Standardowy plik przychodzacy z dystrybucja INND, uzupelniony na poczatku o
linie:
linie:
                                                                        [Image]
                pl.*:%s...@usenet.pl

co powoduje wysylanie artykulow w 'moderowanych' grupach pl.* na adres typu
nazwa-grupy-z-kropkami...@usenet.pl

usenet.pl jest adresem klasy MX wskazujacym na hosty utrzymujace pelna liste
wszystkich 'moderatorow' grup pl (obecnie sa to cocos.fuw.edu.pl,
okapi.ict.pwr.wroc.pl i cyber.ict.pwr.wroc.pl). Domena ta powstala bardzo
niedawno (na poczatku sierpnia 1995), zastepujac stosowana do tej pory domene
moderators.fuw.edu.pl. Aby jednak przejscie na nowy adres bylo bezbolesne,
domena moderators.fuw.edu.pl bedzie w dalszym ciagu obslugiwana do polowy roku
1996. W ciagu tego czasu na wszystkich serwerach news powinny zostac
wprowadzone odpowiednie zmiany w pliku moderators (podobnie w control.ctl)

Plik distrib.pats

Plik ten nalezy uzupelnic o lokalne dystrybucje, tam gdzie one wystepuja, np.:

        10:pwr.*:pwr                 - We Wroclawiu
        10:umk.*:umk                 - W Toruniu

a takze ew. niektore grupy, ktore maja inna dystrybucje, niz wynika to z ich
nazwy, np. we Wroclawiu:

        30:pl.listserv.email-d:pwr

gdyz pl.listserv.email-d jest jak na razie lokalna grupa wroclawska mimo nazwy
'pl.' i artykuly poslane do tej grupy otrzymuja standardowo dystrybucje 'pwr'.
Nie jest pozadane specjalne definiowanie domyslnej dystrybucji dla grup pl.*,
gdyz powinno to byc 'world' - a dystrybucja pl ma rzeczywiscie oznaczac
rozsylanie artykulow wylacznie do serwerow w Polsce.

Plik distributions

Zawiera opisy poszczegolnych dystrybucji. To co dla Polski najwazniejsze
ponizej:

        pl        Polska
        pl-news   Polska, wylacznie news, bez list dyskusyjnych
        krakow    Krakow
        cyfronet  Krakow
        torun     Torun
        warszawa  Warszawa
        umk       UMK w Toruniu
        pwr       Politechnika Wroclawska
        wroc      Wroclaw
        world     Caly swiat
        inet      Internet
        mimuw     Wydz. Matematyki Informatyki i Mech. Uniw. Warszawskiego
        local     lokalny serwer news

Plik newsgroups

Plik z jednolinijkowymi opisami poszczegolnych grup. Opis grup pl.* wysylany
jest regularnie w trzeciej czesci tego FAQ w grupach pl.news.admin i
pl.answers. Dostepny jest takze poprzez FTP pod adresem
ftp://ftp.ict.pwr.wroc.pl/pub/faq-pl/pl.newsgroups.

Plik control.ctl

Plik ulatwiajacy 'centralne' i zautomatyzowane tworzenie nowych grup. Trzeba
pamietac, ze OSTATNI pasujacy opis zostaje uzyty, tak wiec w okolicach konca
pliku nalezy dopisac dla grup pl.*:

        ##  PL newsgroups
        newgroup:michalj@*fuw.edu.pl:pl.*:doit=newgroup
        rmgroup:michalj@*fuw.edu.pl:pl.*:doit=rmgroup
        newgroup:newgroup@usenet.pl:pl.*:doit=newgroup
        rmgroup:newgroup@usenet.pl:pl.*:doit=rmgroup

UWAGA! - Miedzy '*' a 'fuw' nie ma kropki!

Poza tym dobrze jest przy okazji sprawdzic sposob reakcji serwera na 'sendsys'.
Ponizej znajduje sie 'preferowany' sposob - automatyczna odpowiedz, jesli
podany zostal argument (czyli jesli np. komputer okapi otrzyma 'cmsg sendsys
bilbo' - to odesle fragment pliku newsfeeds dotyczacy bilbo), oraz brak
odpowiedzi, jesli argumentu nie ma (by uniknac potencjalnych bomb-maili)

        ##  SENDSYS
        sendsys:*@uunet.uu.net:*:doit=miscctl
        sendsys:*:*:doifarg

-------------------------------------------------------------------------------

Jak skonfigurowac mail2news i news2mail

mail2news i news2mail to dwa programy odpowiedzialne za spinanie ze soba (jak
sama nazwa wskazuje) newsow i maila, tzn. list dyskusyjnych. Wydawac by sie
moglo, ze w zasadzie sa one niepotrzebne, no bo coz... - wystarczyloby pewnie z
jednej strony skonfigurowac serwer news tak, by artykuly przychodzace do danej
grupy byly przekazywane bezposrednio jednemu z programow typu mail, mailx, mh
lub sendmail, w druga strone natomiast - utworzyc odpowiedni "alias" maila typu
np.

        "|/usr/lib/news/sendnews"

gdzie sendnews jest prostym skryptem dopisujacym na poczatku nazwe grupy i
posylajacym dalej calosc do programu 'inews', ktory przekaze artykul serwerowi.

Tak prosto jednak nie da sie tego zrobic. Problem polega na tym, ze kazdy
artykul wyslany na liste dyskusyjna trafilby do news, po czym z news zostalby
odeslany ponownie na liste dyskusyjna, tak wiec na liscie kazdy artykul
pojawialby sie dwukrotnie. Jesli na dodatek listserwer nie przekazuje (tzn.
gubi) 'Message-ID', moze sie okazac, ze artykul ponownie wraca do news, skad
dalej zostaje zakolejkowany do listserwera i zaczyna sie robic (nie)wesolo...
jesli 'Message-ID' jest przez listserwer przekazywany jak nalezy, sytuacja taka
nie bedzie miala miejsca, gdyz artykul poslany ponownie do news (z tym samym
Message-ID) zostanie przez serwer news odrzucony jako duplikat (i wygeneruje
list do Postmastera).

Wazne jest wiec po pierwsze zagwarantowanie by artykul trafiajacy z listserwera
do news nie zostawal wyslany z powrotem na liste, a takze by listserwer nie
gubil ani nie modyfikowal Message-ID, a takze by generowac Message-ID w
momencie przekazywania listu z e-maila do news jesli list go nie zawiera. W
miare mozliwosci nalezy takze ustawic na listserwerze opcje 'NOACK',
oznaczajaca ze listy wyslane z adresu serwera news nie sa do niego ponownie
odsylane.

Do tego wlasnie sluza oba wspomniane programy. mail2news dokonuje
przefiltrowania naglowka maila usuwajac niepotrzebne lub niezgodne z RFC822
pola (np. 'Received:' jest w newsach w ogole bez znaczenia). Jesli list nie
posiada 'Message-ID:', to jest on generowany, ponadto tworzone jest pole
'Path:' z wpisanym odpowiednim tekstem, np. 'Path: gateway', dzieki czemu w
serwerze news mozliwe jest wysylanie na liste dyskusyjna wylacznie artykulow,
ktore serwer news otrzymal od innych serwerow, a nie od mail2news (a wiec nie
majacych 'gateway' w polu 'Path:'). Opcjonalnie, mail2news potrafi takze
odfiltrowac czesto posylane na adres listy (zamiast listserwera) artykuly typu
'unsub nazwa-listy'.

W druga strone - news2mail usuwa z naglowka pola nieistniejace w e-mailu (typu
'Path:', 'Supersedes:', itd.), ignoruje wszystkie listy typu 'control', tzn.
np. kasujace poprzedni artykul, martwi sie o wlasciwe 'From:' i 'Sender:', by
byla mozliwa odpowiedz do autora a nie tylko na liste, oraz pare innych rzeczy.
No i to co najwazniejsze - przy wlasciwej konfiguracji kazdy artykul pojawia
sie dokladnie raz na liscie i raz w newsach.

Pakiet mail2news nie jest na razie dostepny na zadnym anonymous ftp (podobno ma
zostac wlaczony do INN v1.5), jest bowiem na razie w wersji 'beta', nalezy sie
wiec skontaktowac z autorem (Rich Salz - rs...@uunet.uu.net), by otrzymac jego
kopie. Przed kompilacja nalezy sprawdzic kilka parametrow - jakiego typu
program uzywany jest do wysylania poczty (sendmail czy mh), co dopisywane ma
byc w polu 'Path:' (standardowe 'gateway' czy np. 'gateway.pwr.wroc.pl'), czy
adresy 'From:' news2mail ma generowac z 'Path:', czy bezposrednio z 'From:' w
artykule (w czasach, gdy stosowanie adresow uucp staje sie przeszloscia,
bezpieczniejszce jest to drugie), oraz gdzie znajduje sie serwer news (a jesli
na tej samej maszynie - gdzie sa jego biblioteki - a dokladniej: program inews
lub rnews). Roznica pomiedzy inews a rnews moze okazac sie istotna, bowiem
inews jest tak naprawde programem przewidzianym do "interaktywnego"
przyjmowania newsow od uzytkownikow, kontroluje wiec m.in. format daty, a
czasem takze np. czy ilosc cytowanego tekstu nie jest wieksza od nowego tekstu
(jesli tak zostal skompilowany). inews informuje takze o bledach na stdout lub
stderr, co w przypadku mail2news konczy sie przekazaniem bledu dalej, czyli do
sendmaila i co za tym idzie, zwrocenie listu do nadawcy (Sender:), czyli zwykle
wlasciciela listy oraz lokalnego postmastera.

W 80% list dyskusyjnych wszystko dziala jednak jak nalezy, a wowczas inews jest
o tyle lepszy, ze poprzez zwracanie bledow w sposob natychmiastowy zwraca uwage
na to, ze cos jest nie tak. Natomiast bledy wystepujace przy dostarczaniu
artykulow za pomoca rnews sa zwykle przez ten program po cichu ignorowane, a
odbicie znajduja jedynie w logach z pracy serwera. Istotne jest jednak to, ze
mail2news umozliwia podanie 'agenta news' jako parametr przy uruchomieniu, tak
wiec bez koniecznosci rekompilacji mozna w dowolnym momencie inews zmienic na
rnews lub odwrotnie.

Po skompilowaniu mail2news pozostaje juz wlasciwie tylko skonfigurowac serwer
news i listserwer, by przesylaly sobie nawzajem artykuly. Najpierw o tym, jak
to zrobic z mail2news, bo z tym jest zwykle wiecej problemow...

Rozpatrzmy taki przyklad - tworzymy grupe "pl.nowa.grupa", ktora laczymy z
lista "nowa-lista" obslugiwana przez list...@plearn.edu.pl. Serwerem news, na
ktorym tego dokonujemy jest "serwer.news.pl". Musimy serwer news 'zapisac na te
liste', tzn. np. stworzyc w /etc/aliases serwera (lub innego koputera w
poblizu) alias:

        pl-nowa-grupa: /usr/lib/news/news2mail -npl.nowa.grupa -dlocal

Teraz wypadaloby grupe 'pl.nowa.grupa' utworzyc za pomoca 'ctlinnd newgroup
pl.nowa.grupa y' (lub zgodnie ze skladnia serwera news, to jest przyklad dla
INN) i przetestowac czy poczta wysylana na adres pl-now...@serwer.news.pl
trafia do newsow. Po pierwsze - wysylajac email-a na ten adres, a jesli cos nie
dziala - testujac recznie:

        % cat > test.posting
        From: uzytk...@serwer.news.pl
        To: pl-nowa-grupa
        Message-ID: tes...@serwer.news.pl
        Date: Mon, 1 Aug 1994, 12:00 MET

        test
        ^D
        % cat test.posting | /usr/lib/news/mail2news -npl.nowa.grupa -dlocal

(albo nagrac jakis list wyslany samemu sobie do pliku i probowac go przekazac
do mail2news).

Jesli w tym momencie chcemy przetestowac, jak z dostarczaniem newsow poradzi
sobie rnews zamias inews, wystarczy wpisac:

        % cat test.posting | \
        /usr/lib/news/mail2news -=/usr/lib/news/bin/rnews -npl.nowa.grupa -dlocal test

slowo 'test' (lub dowolne inne) na koncu jest konieczne z tego wzgledu, ze
mail2news przekazuje 'agentowi news' parametr '-h' oraz wszystkie inne, ktorych
sam nie interpretuje (czyli '-h test') - inews wymaga '-h' bez parametrow, dla
rnews po '-h' musi wystapic nazwa 'hosta' ktora zostanie zapisana w logach
serwera. Pamietac nalezy tez o tym, ze o ile mail2news wykorzystujacy inews
moze byc uruchomiony "niedaleko" serwera, to rnews da sie uruchomic wylacznie
na serwerze, albo na komputerze, ktory z serwerem news ma polaczenie via UUCP.
Jesli wszystko dziala tak jak trzeba, pozostaje zapisac serwer news jako
subskrybenta listy dyskusyjnej: albo poprosic wlasciciela listy by dopisal do
niej adres pl-now...@serwer.news.pl, albo zrobic to samemu, posylajac
e-mail z adresu pl-nowa-grupa do listserwera. Jak poslac maila z takiego
adresu? O tym chyba wszyscy wiedza, ale jakby nie, to jako root (albo jeden z
'trusted users' sendmaila - np. 'news') nalezy wykonac:

        # cat | /usr/lib/sendmail list...@plearn.edu.pl
        From: pl-now...@serwer.news.pl
        To: list...@plearn.edu.pl

        sub nowa-lista "mail to news gateway at serwer.news.pl"
        ^D

W ciagu kilku- lub kilkudziesieciu minut powinien sie w newsach pojawic
pierwszy artykul - z odpowiedzia serwera i informacja "You have now subscribed
to list nowa-lista" itd. Jesli tak, to wszystko na najlepszej drodze. Aby
poustawiac wszystkie opcje dystrybucji jak nalezy, poslij listserwerowi
(ponownie z adresu pl-now...@serwer.news.pl) list o tresci:

        set nowa-lista full
        set nowa-lista noack

Pierwsza linia oznacza, ze listserwer ma posylac pelne naglowki (a wiec
wlacznie z Message-ID), druga - ze artykuly przeslane z newsserwera nie beda do
niego ponownie wysylane. Opcje powyzsze dzialaja poprawnie w przypadku
listserwerow bitnetowych oraz 'listproc-a', inne listserwery moga wymagac nieco
innych komend, na przyklad 'set nowa-lista norepro' itp.

Jesli wszystko dziala jak nalezy, pora na wysylanie newsow na liste. W pliku
newsfeeds nalezy dopisac linie mniej wiecej nastepujacej tresci:

    nowa-lista/gateway\
        :pl.nowa.lista,/!local,!pl-news\
        :Tp:/usr/lib/news/bin/news2mail nowa-lista nowa-lista \
        pl-now...@serwer.news.pl plearn.edu.pl

(ostatnie 2 linijki w zasadzie powinny zmiescic sie w jednej.. ale dla
czytelnosci podzielilem ja na dwie - TS). Argumenty podane dla news2mail
oznaczaja ze:

   *  (1 i 4) - poczta zostanie dostarczona na adres nowa-...@plearn.edu.pl,
   *  (2 i 4) - w polu 'To:' bedzie wpisane nowa-...@plearn.edu.pl,
   *  (3) - w polu 'Sender:' bedzie wpisane pl-now...@serwer.news.pl - 4.
     argument jest tutaj ignorowany, bo w adresie juz jest '@'

Poza tym 'From:' zawsze zawiera adres z 'From:' w artykule news (chyba ze w
trakcie kompilacji wybrano opcje generowania 'From:' na podstawie 'Path:')

'Sender:' - powinien byc adresem, jakiego uzylismy zapisujac mail2news na
liste, wiekszosc z list bowiem nie akceptuje listow wysylanych przez osoby nie
bedace subskrybentami listy. Aby wiec listy wyslane w newsach trafialy
bezpiecznie na liste uzytkownik wystepujacy w polu 'Sender' lub 'From' musi byc
na liste zapisany - co latwo osiagnac definiujac wlasciwie pole 'Sender'.
Ponadto, aby 'Sender:' wpisane przez news2mail bylo respektowane przez
sendmail-a (lub innego agenta :-) pocztowego) trzeba jeszcze upewnic sie ze
uzytkownik 'news' (z tym id dziala serwer news, a wiec i news2mail przez niego
uruchamiany) jest wpisany w sendmail.cf jako 'trusted user', np: (Opcja
'Trusted' jest bez znaczenia w sendmail 8.6.x)

        DT root uucp news

Najlepiej oczywiscie na poczatek zamiast adresow listserwera wpisac wlasny i
przetestowac, czy artykul wyslany w news trafia do do e-maila jak nalezy. Po
wykonaniu 'ctlinnd reload newsfeeds' i wyslaniu artykulu do news, albo od razu
powinien on zostac dostarczony email-em, albo zakolejkowany. Wowczas
'/usr/lib/sendmail -q' przyspieszy jego dostarczenie. No a gdy juz okaze sie ze
artykul dotarl i wygladal mniej wiecej tak:

    From news...@cyber.ict.pwr.wroc.pl Sat Aug  6 18:05:02 1994
    Return-Path: <news...@cyber.ict.pwr.wroc.pl>
    Received: from cyber by asic.ict.pwr.wroc.pl (4.1/SMI-4.1)
        id AA14199; Sat, 6 Aug 94 18:05:01 +0200
    Received: from NEWS GATEWAY by cyber with netnews
        for ts@asic (ts@asic)
    From: tsur...@sprocket.ict.pwr.wroc.pl (Tomasz Surmacz)
    Message-Id: <320c32$e...@cyber.ict.pwr.wroc.pl>
    Sender: news...@cyber.ict.pwr.wroc.pl
    Subject: test news2mail

    test news2mail - wyslany przez tin-a uruchomionego na komputerze
    'sprocket' polaczonego z serwerem news 'cyber' gdzie grupa
    pwr.nowa.lista w newsfeeds opisana jest jako:

    list-test/gateway\
        :!*:pwr.nowa.lista:Tp:\
        /bin/news2mail ts ts news...@cyber.ict.pwr.wroc.pl asic

(tzn. mial wlasciwy adres From: oraz Sender:) to mozemy zmienic wlasny adres na
adres listserwera, jeszcze raz wykonac 'ctlinnd reload newsfeeds' i miec
nadzieje, ze wszystko dziala jak trzeba. Gdy natomiast grupa zostanie takze
utworzona na innych serwerach news, wystarczy przestawic dystrybucje w aliasie:

        pl-nowa-grupa: /usr/lib/news/mail2news -npl.nowa.grupa -dlocal

na:

        pl-nowa-grupa: /usr/lib/news/mail2news -npl.nowa.grupa -dworld

(lub w ogole zlikwidowac '-d' zakladajac, ze serwer nie dopisze zadnej, a wiec
bedzie szlo w swiat, ale to lepiej wtedy sprawdzic). To wszystko...
-------------------------------------------------------------------------------

Newsfeed przez uucp

0. Dlaczego?

Internetowy protokol transferu news NNTP, oprocz wielu zalet, ma tez wady.

Przeslanie jednego artykulu odbywa sie w nastepujacy sposob:

   Nadawca: mam artykul
   Obiorca: sprawdza, odpowiada: nie mam, dawaj go.
   N: nadaje, czeka.
   O: potwierdza odbior.

Taki synchroniczny sposob przesylania artykulow po jednym oznacza, ze szybkosc
transferu news moze byc znacznie mniejsza od pasma linii laczacej nadawce z
odbiorca, zwlaszcza jesli komputery polaczone sa linia satelitarna lub jesli
komputer odbiorca jest na tyle wolny, ze duzo czasu zajmuje mu sprawdzenie, czy
dany artykul juz ma. W bardzo powazny sposob mozna to poprawic stosujac tzw.
"streaming nntp", co oznacza, ze nadawca pcha strumien newsow nie czekajac na
natychmiastowe potwierdzenia, lecz uzyskujac je nieco pozniej. Do tego trzeba
jednak nowszej wersji INND (innd1.4unoff2 juz to ma).

Opoznienie wprowadzane przez linie satelitarna wynosi ok. 800ms, co oznacza, ze
nawet najszybsza linia i najszybszy komputer nie sa w stanie przeslac po takiej
linii wiecej niz ok. 100000 artykulow na dobe, przy obecnej 'dawce' rzedu
70000. W praktyce jest jeszcze gorzej, bo pozostale etapy tez trwaja.

Druga wada jest tez brak jakiejkolwiek kompresji przesylanych danych, a
doswiadczenie wykazuje, ze na zawartosci artykulow newsowych mozna osiagnac
wspolczynnik kompresji do ok. 50% pierwotnej wielkosci. Ta wada jest z kolei
bardzo istotna w przypadku lacz o malej przepustowosci.

Obu tych wad nie posiada sposob przesylania za pomoca tzw. 'compressed batches
over uucp'. Przesyla sie w paczkach - a wiec nie trzeba czekac na potwierdzenie
kazdego artykulu. Kompresuje sie - a wiec danych do przeslania jest mniej.

Oczywiscie, ten sposob tez ma wady:

   *  wymaga uruchomienia oprogramowania uucp.
   *  moze sie zdarzyc, ze w paczce przyjdzie niepotrzebnie cos, co juz mamy
     (to grozi tylko wtedy, kiedy mamy feedy z roznych miejsc).
   *  przepelnienie dysku grozi duzo powazniejszymi konsekwencjami.

Wady te sa jednak w wielu przypadkach z nawiazka rekompensowane zaletami.
-------------------------------------------------------------------------------

I. Konfiguracja uucp

Standardowe UUCP

Podaje na przykladzie standardowego UUCP w SunOS 4.1.x, na innych powinno byc
podobnie. Konfiguracja z uzyciem Taylor UUCP w nastepnym punkcie

Zakladamy, ze laczymy ze soba komputery alfa.aaa.aaa (site name AAA.aaa) i
omega.zzz.zzz (site name ZZZ.zzz). Dalsze instrukcje dotycza alfy, na omedze
wszystko tak samo, tylko odwrotnie.

1. Zalozyc nowego uzytkownika przez dopisanie do /etc/passwd

        Uomega:ZZZZZZ:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico

     gdzie ZZZZZZ jest oczywiscie zakodowanym haslem. Numer uzytkownika i grupy
     powinien byc taki jak dla uzytkownika nuucp. 'Home directory' - w zasadzie
     dowolny, np. /var/spool/uucp, itp. Wazne by nie byl to katalog z prawem
     zapisu dla 'wszystkich' (czyli 777 lub 1777)

2. Wlaczyc uucpd
     Dopisac w /etc/inetd.conf linie:

             uucp    stream  tcp     nowait  uucp    /usr/etc/in.uucpd in.uucpd

     lub jesli stosowany jest pakiet tcp_wrappers:

             uucp    stream  tcp     nowait  uucp    /usr/etc/tcpd in.uucpd

     i poslanie do inetd sygnalu HUP.

     W tym drugim przypadku warto tez pamietac o dopisanu komputera
     omega.zzz.zzz do listy tych, ktorym wolno laczyc sie z demomem "in.uucpd"

3. Pliki konfiguracyjne uucp.

     Do /etc/Systems dopisac:

             omega Any TCP - omega.zzz.zzz in:--in: Ualfa word: AAAAAA

     gdzie AAAAAA jest niezakodowanym haslem uzytkownika Ualfa na komputerze
     omega. W Solarisie 2.x plikiem tym jest /etc/uucp/Systems, natomiast w
     przypadku uzywanego czesto 'Taylor uucp' jest to oczywiscie 'sys'.
     (Podobnie z nastepnymi plikami)

     Czesto wystepujacym bledem uniemozliwiajacym poprawne polaczenie dwoch
     serwerow przez UUCP jest to, ze komputer nawiazujacy polaczenie usiluje
     ustawiac 7-bitowe wysy�anie danych z kontrol� parzystosci, podczas gdy
     "serwer" spodziewa sie danych 8-bitowych. Tak na przyklad jest na SUNach z
     SunOSem i Solarisem. Mozna temu jednak prosto zaradzic, uzupelniajac
     powyzsza linie w pliku Systems w taki sposob:

             omega Any TCP - omega.zzz.zzz "" P_ZERO in:--in: Ualfa word: AAAAAA

     Do /etc/Permissions lub odpowiednika dopisac:

             LOGNAME=Uomega MACHINE=omega VALIDATE=omega COMMANDS=/usr/local/news/rnews

     (Oczywiscie, nalezy podac prawdziwa sciezke do programu rnews).

4. Periodyczne przegladanie kolejek uucp wlacza sie przez crontab:

        su uucp
        crontab </usr/lib/uucp/uudemon.crontab

     I juz.

     Uwaga: standardowo, crontab ustawia puszczanie programu uudemon.hour co 30
     minut. Warto - zwlaszcza do testow na poczatek - puszczac czesciej.

-------------------------------------------------------------------------------

Taylor UUCP

Zakladamy, tak jak poprzednio, ze laczymy ze soba komputery alfa.aaa.aaa
(uuname - AAA.aaa) i omega.zzz.zzz (site name ZZZ.zzz). Instrukcje dotycza
alfy, na omedze wszystko tak samo, tylko odwrotnie.

1. Tak jak i w "zwyklym" UUCP - zalozyc nowego uzytkownika przez dopisanie do
/etc/passwd

        Uomega:ZZZZZZ:4:8::/var/spool/uucppublic:/usr/lib/uucp/uucico

     (ZZZZZZ - zakodowane haslo. Numer uzytkownika i grupy taki, jak dla
     uzytkownika nuucp). Zaleznie jednak od tego, jak uruchamiamy demona
     uucico, ten krok moze okazac sie zbedny. Przyjmijmy, ze uucico bedzie
     dokonywac autentykacji uzytkownikow samodzielnie. Wowczas modyfikacja
     /etc/passwd nie jest konieczna.

2. Wlaczamy demona uucp.
     Dopisujemy w /etc/inetd.conf linie:

             uucp    stream  tcp     nowait  uucp    /usr/local/lib/uucp/uucico uuciso -s -l

     lub jesli stosowany jest pakiet tcp_wrappers:

             uucp    stream  tcp     nowait  uucp    /usr/etc/tcpd /usr/local/lib/uucp/uucico -s -l

     i posylamy do inetd sygnal HUP.

     Uruchomienie uucico z opcjami '-s -l' powoduje, ze dokonywac ono bedzie
     sprawdzenia nazwy i hasla uzytkownika samodzielnie. Mozna oczywiscie
     stosowac wyjscie z in.uucpd, pamietajac jednak, ze in.uucpd ZAWSZE wola
     potem /usr/lib/uucp/uucico, nalezy wiec umiescic w tym miejscu uucico z
     Taylor uucp. Hasla i loginy, jakie uucico akceptuje, znajduja sie w pliku
     passwd, ale nie w katalogu /etc, tylko w tym, w ktorym jest cala reszta
     plikow konfiguracyjnych Taylor UUCP (zalozmy, ze jest to katalog
     /etc/uucp, ale to zalezy od parametrow kompilacji Taylor UUCP).
     I ponownie - jesli stosujemy tcpd, pamietajmy o dopisanu komputera
     omega.zzz.zzz do listy tych, ktorym wolno laczyc sie z demomem "uucico"

3. Pliki konfiguracyjne uucp.

     Do /etc/sys (A dokladniej - do pliku 'sys' w katalogu z konfiguracja
     Taylor UUCP) dopisac:

             system omega
             time Any
             port TCP
             address omega.zzz.zzz
             called-login Uomega
             call-login *
             call-password *
             chat ogin:--ogin:--ogin:--ogin: \L word: \P
             protocol tfigGa
             commands rmail rnews

     a w pliku call:

              omega    Ualfa   AAAAAA

     gdzie AAAAAA jest niezakodowanym haslem uzytkownika Ualfa na komputerze
     omega. Haslo to na omedze znalezc sie musi w /etc/uucp/password w takiej
     postaci:

             Ualfa     AAAAAA

     To, czy w pliku passwd hasla sa zakodowane, czy nie, zalezy od opcji
     kompilacji Taylor UUCP.

3. Dobrze jest sprawdzic, czy w pliku port znajduje sie definicja "portu" o
nazwie TCP, z ktorego mamy zamiar korzystac:

    port TCP
    type tcp

4. Periodyczne przegladanie kolejek uucp wlacza sie przez crontab:

        su uucp
        crontab </usr/lib/uucp/uudemon.crontab

     Jesli brak nam natomiast "standardowego" crontaba, wpisac mozemy sami:

     0,15,30,45 * * * * /usr/lib/uucp/uucico -somega
     0 7 * * * /usr/lib/uucp/uustat -Q -o 120 -y 144 -N -W "Still undelivered after 5 days"
     5 7 * * * /usr/lib/uucp/uustat -Q -o 168 -N -K -W "Still undelivered after 7 days, removed from the UUCP queue"

     I juz.

     Uwaga: 15 minut jest tu tylko orientacyjnym czasem, co jaki mozna
     przesylac kolejki uucp. Warto samemu zbadac, jaki czas bedzie najlepszy i
     dopasowac to do potrzeb serwera news. Jesli batch siedzi w kolejce 120-144
     godzin (czyli 5-6) dni, to ostrzegamy "nadawce" zadania (czyli w tym
     przypadku "news") o niemoznosci przeslania batcha, po 7 dniach (168
     godzin) niedostarczone batche usuwamy.

-------------------------------------------------------------------------------

II. Konfiguracja C News do wysylania batchow

Wszystkie operacje jako user news.

  1.  Zalozyc katalog:

             mkdir /usr/spool/news/out.going/omega

  2.  W pliku /usr/lib/news/sys wpisac:

             ZZZ.zzz:all,!control/all,!local:f:/usr/spool/news/out.going/omega/togo

     Lista wysylanych grup i dystrybucji oczywiscie do indywidualnego
     ustalenia.

  3.  W pliku /usr/lib/news/batchparms wpisac:

             omega           200000  20      batcher compcun viauux

  4.  Uruchomic wysylanie batchow przez dopisanie do crontaba linii:

             05,15,25,35,45,55 * * * * /usr/lib/newsbin/batch/sendbatches omega

     Uwaga: Mozna co 10 minut, mozna rzadziej. Dobrze jest, aby bylo to
     skorelowane z godzinami, kiedy uruchamiany jest uudemon.hour - tak, aby
     uudemon startowal zaraz po przygotowaniu paczki do wyslania. Mozna np.
     przygotowywac paczki o 00 i 30, a demona startowac o 05 i 35. Im czesciej
     bedziemy to robic, tym mniejsze beda opoznienia w rozchodzeniu sie news,
     ale nie nalezy przesadzac, zeby nie przeciazyc komputera i nie zniweczyc
     zyskow, ktore uzyskalismy dzieki paczkowaniu.

-------------------------------------------------------------------------------

III. Konfiguracja C News do odbierania batchow

Uruchamiany przez uucp program rnews nagrywa nadchodzace paczki w katalogu
/usr/spool/news/in.coming. Aby zostaly one skonsumowane przez C News, nalezy
dokonac - do wyboru - jednej z dwoch operacji:

  1.  uruchamiac co pewien czas program newsrun przez wpisanie do crontaba:

             09,19,29,39,49,49,59 * 1-31 *  0-6     /usr/lib/newsbin/input/newsrun

          (Tak dobrac, zeby sie uruchamial w pare minut po nadejsciu kazdej
     paczki.)

     albo

  2.  stworzyc plik /usr/lib/news/rnews.immed, co sprawi, ze rnews bedzie
     automatycznie uruchamiac newsrun.

     Jesli feed jest duzy i wiemy, ze za kazdym obiegiem sendbatches maszyna
     omega posyla nam srednio wiecej niz jeden batch, polecam sposob pierwszy.
     Jesli dostajemy tylko niewielkie batche, pojedyncze i nie za kazdym
     obiegiem sendbatches, polecam sposob drugi.

-------------------------------------------------------------------------------

IV. Konfiguracja INN do wysylania batchow.

1. Utworzenie feedu w pliku newsfeeds, przykladowo:

            cocos/fuw.edu.pl\
                :*,!torun.*,!umk.*,!mat.*,/!torun,!umk,!mat\
                :Tf,Wnb:

     Zwykly feed uzywa na ogol parametrow "Tf,Wnm". Feed UUCP - "Tf,Wnb" - co
     powoduje tworzenie w /var/spool/news/out.going pliku o innym formacie niz
     dla NNTP, zawierajacego sciezki do artykulow i ich wielkosci. 'cocos' to
     tutaj zarowno nazwa pliku w w katalogu out.going jak i adres UUCP
     adresata. Adres nie musi byc zarejestrowany w mapach UUCP. Identyfikatory
     do Path:_ sa te same, co dla feedu nntp. Dla porownania, ten sam feed w
     wersji nntp:

            fuw/fuw.edu.pl\
                :*,!torun.*,!umk.*,!mat.*,/!torun,!umk,!mat\
                :Tf,Wnm:

2. Poprawienie skryptu /usr/local/news/bin/sendbatch.

     Na Solaris 2.3, przy korzystaniu ze "standardowego" UUCP musialem poprawic
     linie:

             COMPRESS=/usr/ucb/compress

     i

             UUXFLAGS="- -r -n -gd"

     na

             COMPRESS=/usr/bin/compress
             UUXFLAGS="- -r -n"

     poniewaz sciezka do compress jest inna (w Solarisie 2.4 ponownie jest ju�
     w /usr/bin), a uux na Solaris nie rozumie grade 'd'.

     Aby temu zaradzic, mozna skompilowac (na Solarisie, Linuxie i innych
     systemach) "Taylor UUCP" - kompiluje sie bez problemow, poza jednym malym
     - jesli planujemy uzywac UUCP takze przez modem, trzeba KONIECZNIE w pliku
     "policy.h" zdefiniowac 'HAVE_POSIX_TERMIOS' zamiast liczyc na to, ze
     system sam zgadnie (wedlug opisu), bo w Solarisie zgaduje
     'HAVE_SYSV_TERMIO' i zle dziala z szybkimi (potrzebujacymi sprzetowej
     kontroli przeplywu) modemami. Podobnie jest na Linuxach - kompilator
     zgaduje HAVE_BSD_TERMIO zamiast stosowac HAVE_POSIX_TERMIOS.

     INN FAQ zaleca aby rozmiar pojedynczego batcha zwiekszyc z

                    DEFBYTES=50000

     do 200000 B, zarowno dla polaczen TCP jak i telefonicznych. Mozna to
     zrobic przez zmiane wartosci tej zmiennej w skrypcie lub podanie opcji
     -s200000 przy wywolaniu sendbatch w cronie.

3. Periodyczne wywolywanie sendbatch.

     Do crontab uzytkownika news nalezy dopisac:

             9,19,29,39,49,59 * * * * /usr/local/news/bin/sendbatch -c cocos >/dev/null 2>&1

     gdzie cocos to adres UUCP adresata. Czestotliwosc nie musi byc tak duza.
     Opcja -c moze byc zastapiona opcja -cg wg propozycji Michala (p. III.
     Konfiguracja INN do nadawania z kompresja gzip ponizej).

-------------------------------------------------------------------------------

V. Konfiguracja INN do odbierania batchow.

Nic nie trzeba robic - wszystko jest "wbudowane" standardowo. Nalezy jedynie
zadbac, by w /bin/rnews znalazl sie program rnews z dystrybucji innd, oraz mimo
wszystko do crontab-a uzytkownika news dopisac jednak nastepujaca linijke:

        7 0,6,12,18 * * * /bin/rnews -U

a wiec raz lub kilka razy dziennie uruchamiac program rnews z pakietu INND.
Opcja '-U' powoduje, ze rnews nie szuka batchow na wejsciu, lecz przeszukuje
katalog /usr/spool/news/in.coming . W normalnych warunkach nie jest to
konieczne, natomiast przydaje sie w sytuacjach awaryjnych, gdy z jakiegos
powodu serwer przestaje przyjmowac newsy (np. padl, albo sie zapchal), wtedy
batche UUCP (oraz newsy dostarczane przez mail2news) trafiaja wlasnie do
/usr/spool/news/in.coming. Serwer sam przeszukuje ten katalog podczas
uruchamiania, ale nie podczas odblokowywania (ctlinnd go ''), jesli
byl zapchany. Dlatego dobrze jest rnews uruchamiac takze z crontaba.
-------------------------------------------------------------------------------

Kompresowanie batchow przy pomocy gzip

Standardowy sposob kompresji programem 'compress' nie jest zbyt wydajny.
Dlatego, jesli juz mamy dzialajacy feed batchowy, proponuje uruchomienie
kompresjii za pomoca programu 'gzip'. Oczywiscie, obie strony musza sie umowic,
ze beda tego programu uzywaly, dlatego nie radze tego zmieniac globalnie, a
tylko osobno dla kazdego feedu. Mozna najpierw skonfigurowac dekompresje po
stronie odbierajacej bez zmian u nadawcy, gdyz gzip rozumie formaty .gz (gzip -
ale nie zip!), .Z (stary compress) i .z (jeszcze starszy pack).

-------------------------------------------------------------------------------

I. Konfiguracja C News do nadawania z kompresja gzip

1. Stworzyc nowy skrypt kompresujacy batche, pod nazwa
/news/lib/newsbin/batch/gzipcun

        #! /bin/sh
        # Invoke gzip, adding silly 2.11-compatible header.
        echo "#! cunbatch"
        gzip

(pamietac, zeby zrobic 'chmod +x /news/lib/newsbin/batch/gzipcun') 2. W pliku
batchparms zmienic compcun na gzipcun
-------------------------------------------------------------------------------

II. Konfiguracja C News do odbierania z dekompresja gzip

1. Poprawic program ../input/newsspool.c
-------------------------------------------------------------------------------

*** newsspool.c.orig    Tue Nov 26 16:52:21 1991
--- newsspool.c Mon Oct 17 19:05:03 1994
***************
*** 31,36 ****
--- 31,37 ----
  char *progname;

  extern void error(), exit();

  #ifdef UTZOOERR
  extern char *mkprogname();
  #else
***************
*** 237,246 ****
  #     define  GOOP7LEN        (sizeof(goop7)-1)       /* strlen(goop7) */
        static char suf7[] = ".7";
        static char comp[2] = { 037, 0235 };    /* compress's magic no. */
        register char *p;
        register int nleft;
  #     define  MINCBATCH       5               /* one character, compressed */

        nleft = count;
        p = bufp;

--- 238,249 ----
  #     define  GOOP7LEN        (sizeof(goop7)-1)       /* strlen(goop7) */
        static char suf7[] = ".7";
        static char comp[2] = { 037, 0235 };    /* compress's magic no. */
+       static char gzip[2] = { 037, 0213 };    /* gzip's magic no. */
+       static char sufg[] = ".gz";
        register char *p;
        register int nleft;
  #     define  MINCBATCH       5               /* one character, compressed */
! #     define  MINCGZIP        21              /* one character, gzipped */
        nleft = count;
        p = bufp;

***************
*** 254,259 ****
--- 257,269 ----
                return(0);
        }

+       if (p[0] == gzip[0] && p[1] == gzip[1]) {       /* gzipped */
+               if (nleft < MINCGZIP)
+                       return(count);
+               suffix = sufg;
+               return(0);
+       }

        if (*p++ != '#' || *p++ != '!')         /* doesn't start with #! */
                return(0);
        nleft -= 2;
***************
*** 268,274 ****
        if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
                p += GOOPLEN;
                nleft -= GOOPLEN;
!               suffix = suf;
        } else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
                p += GOOP7LEN;
                nleft -= GOOP7LEN;
--- 278,287 ----
        if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
                p += GOOPLEN;
                nleft -= GOOPLEN;
!               if (p[1] == gzip[0] && p[2] == gzip[1])  /* gzipped */
!                 suffix = sufg;
!               else
!                 suffix = suf;
        } else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
                p += GOOP7LEN;
                nleft -= GOOP7LEN;

-------------------------------------------------------------------------------
Skompilowac i zainstalowac jako /news/lib/newsbin/input/newsspool

W zasadzie mozna sie bez tej zmiany obejsc, wtedy newsspool blednie nadaje typ
plikom rozszerzenie .Z zamiast .gz, ale programowi gunzip (patrz nizej) to nie
szkodzi.

2. W skrypcie /news/lib/newsbin/input/newsrun zmienic nastepujaco:
-------------------------------------------------------------------------------

*** newsrun.orig        Thu Oct 27 23:14:45 1994
--- newsrun     Mon Oct 17 15:41:39 1994
***************
*** 121,127 ****
                # Decompress if necessary.
                text=$tmp
                case $f in
!               *.Z)    uncompress <$f >$text   ;;
                *.7)    c7decode <$f | uncompress >$text        ;;
                *.t)    >$tmp           # in case compress left trash
                        text=$f
--- 121,128 ----
                # Decompress if necessary.
                text=$tmp
                case $f in
!               *.gz)   gunzip <$f >$text       ;;
!               *.Z)    gunzip <$f >$text       ;;
                *.7)    c7decode <$f | uncompress >$text        ;;
                *.t)    >$tmp           # in case compress left trash
                        text=$f

-------------------------------------------------------------------------------
W zasadzie wystarczy dodac linijke z .gz, ale traktowanie plikow .Z programem
gunzip nie zaszkodzi, za to umozliwia poprawne dzialanie nawet, jesli nie
chcialo nam sie przerabiac programu newsspool.

-------------------------------------------------------------------------------

III. Konfiguracja INN do nadawania z kompresja gzip

Proponuje dodac nowa opcje do skryptu /usr/local/news/bin/sendbatch
-------------------------------------------------------------------------------

*** sendbatch.orig      Thu Oct 27 23:29:30 1994
--- sendbatch   Thu Oct 27 23:31:54 1994
***************
*** 14,19 ****
--- 14,21 ----
  COMP=
  COMPFLAGS=
  COMPRESS=/usr/ucb/compress
+ GZIP=/usr/local/bin/gzip
+ GZIPFLAGS=
  ECHO=
  ##  Not a config param since this is the remote rnews.
  RNEWS=rnews
***************
*** 75,80 ****
--- 77,87 ----
      -c)
        COMP="; exec ${COMPRESS} ${COMPFLAGS}"
        ECHO="echo '#! cunbatch'"
+       continue
+       ;;
+     -cg)
+       COMP="; exec ${GZIP} ${GZIPFLAGS}"
+       ECHO="echo '#! cunbatch'"
        continue
        ;;
      +c)

-------------------------------------------------------------------------------
W wywolaniu sendbatch (cron) zmienic -c na -cg

-------------------------------------------------------------------------------

IV. Konfiguracja INN do odbierania z dekompresja gzip

Trzeba zmienic w pliku config/config.data w zrodlach INN

            _PATH_COMPRESS          /usr/ucb/compress
            _PATH_COMPRESSEXT       .Z

na

            _PATH_COMPRESS          /usr/local/bin/gzip
            _PATH_COMPRESSEXT       .gz

lub podobnie. Potem niestety trzeba przekompilowac (make update) i na nowo
nagrac programy INN. Jesli nagramy wszystkie z ta poprawka, to cale INN bedzie
odtad uzywalo gzip do kompresji log-files itp. (Gdzieniegdzie jest to tak
wlasnie zrobione "standardowo"). Jesli chodzi nam tylko o to, zeby rnews
rozumialo batche kompresowane przez gzip, to wystarczy nagrac na nowo tylko
program rnews.

-------------------------------------------------------------------------------

Inne mozliwosci przyspieszenia transmisji News

Jezeli najwiekszym problemem sa opoznienia, a nie przepustowosc linii, to
prostym tymczasowym rozwiazaniem moze byc podzial feedu na dwa lub wiecej i
wysylanie ich jako osobnych, rownolegle dzialajacych feedow. Inne zastosowanie
feedow rownoleglych, a wlasciwie drabinkowych, to poprawienie niezawodnosci.
Jednak w przypadku zrownoleglenia feedow w ukladzie dwa komputery po jednej
stronie kabla wysylajace do dwoch po drugiej stronie, zwieksza sie nieco ilosc
duplikatow. Warto tez zwrocic uwage na maksymalny czas przesylania news przez
nntpsend (opcja -T, omowiona wczesniej) oraz godziny startowania batchow
wysylajacych newsy.

Mozna tez uruchomic stale polaczenie miedzy serwerami - nntplink, tez stosowany
w ukladzie drabinkowym.

Ale ten rozdzial napisze juz pewnie ktos inny w nastepnej wersji...

-------------------------------------------------------------------------------
Czesc pierwsza FAQ - ogolne informacje o grupach pl.*
Czesc trzecia FAQ - Lista istniejacych grup pl.*

FAQ po angielsku dla administratorow serwerow news poza Polska
-------------------------------------------------------------------------------

UUCP:
     Michal Jankowski (Michal.J...@fuw.edu.pl)
     Rafal Maszkowski (r...@oso.chalmers.se, http://www.mat.uni.torun.pl/~rzm)
Konfiguracja serwera, Taylor UUCP, wersja HTML calosci:
     Tomasz Surmacz (tsur...@ict.pwr.wroc.pl)

10.09.1995
-- 
 _________
(_   _' __) Tomasz R. Surmacz *----* Work:(071)202636 tsur...@ict.pwr.wroc.pl
  |  (__  \ http://www.ict.pwr.wroc.pl/~tsurmacz/ Home: t...@papaja.wroc.apk.net
  |__(____/ For PGP key finger tsur...@asic.ict.pwr.wroc.pl *---* irc: TomekS