🚀 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.*)
     Co robic z listami typu "checkgroups"?
     Jak skonfigurowac mail2news i news2mail
     Newsfeed za pomoca UUCP
     Kompresja batchow za pomoca gzip
     UUCP 'posrednie' (czyli jak wykonac cyber!papaja!rnews)
     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:
                                                                   [nowosc!]
                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

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

Co robic z listami typu "checkgroups"?

Od czasu do czasu wysylany jest tzw. "checkgroups message" dla grup pl.*,
tzn. specjalny artykul naws zawierajacy liste wszystkich aktywnych grup.
Artykul taki wyrozniony jest odpowiednia linia "Control:", dzieki czemu
kazdy serwer news, ktory taki artykul otrzyma, przesyla go swojemu
administratorowi poczta e-mail. W liscie tym serwer dolacza na poczatku
komentarz mowiacy w jaki sposob nalezy z tym artykulem postapic. Jest to
zwykle polecenie postaci $inn/control/docheckgroups < PLIK.

Nie nalezy sie obawiac, ze uruchomienie docheckgroups cokolwiek zmieni.
Program ten porownuje jedynie liste grup w dostarczonym mu na wejsciu pliku
z lista grup znajdujaca sie w plikach active i newsgroups. W przypadku
niezgodnosci informacje o tym drukowane sa na standardowym wyjsciu w
formacie skryptu sh. Tak wiec mozna program docheckgroups uruchomic raz dla
sprawdzenia, czy wszystko jest ok, a nastepnie w przypadku wykrycia
niezgodnosci i zaakceptowania zmian wykonac program ponownie, jego wynik
skierowujac do programu sh (albo do pliku, a nastepnie do sh):

        $inn/control/docheckgroups < PLIK | sh -

Artykul "checkgroups" wysylany bedzie srednio co 1-2 miesiace z adresu
tsur...@okapi.usenet.pl. Jesli artykul taki potrzebny jest "od zaraz",
mozna sobie poradzic inaczej:

   * Spod adresu ftp://ftp.ict.pwr.wroc.pl/pub/faq-pl/pl.newsgroups sciagnac
     aktualna liste grup pl.* w formacie pliku newsgroups.
   * Uruchomic program docheckgroups podajac mu plik pl.newsgroups na
     wejscie.
   * To, co z niego wyjdzie zapamietac w pliku i uruchomic jako skrypt.

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

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 zwykle 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). Jezeli 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' (choc
trwa to juz od konca 1993 roku), nalezy sie wiec skontaktowac z autorem
(Rich Salz - rs...@uunet.uu.net), by otrzymac jego kopie. Istnieje takze (na
razie w fazie testow) wersja w PERLu napisana przez Piotra Piatkowskiego,
ktora dodatkowo potrafi dokonywac przekodowania z Quoted Printable na 8bit
artykulow wysylanych do newsow z poczty i odwrotnie w druga strone. W
dalszej czesci opisany jest pakiet mail2news Richa Salza.

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,
bezpieczniejsze 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/local/news/bin/mail2news -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/local/news/bin/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/local/news/bin/mail2news -=/usr/local/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 serwera news 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/local/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',
(opcja 'Trusted' jest bez znaczenia w sendmail 8.6.x, ale w 8.7.x ponownie
jest respektowana), np:

        DT root uucp news

Najlepiej oczywiscie na poczatek zamiast adresow listserwera wpisac wlasny i
przetestowac, czy artykul wyslany w news trafia 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 juz grupa zostanie takze
utworzona na innych serwerach news, wystarczy tylko przestawic dystrybucje w
aliasie:

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

na:

        pl-nowa-grupa: /usr/local/news/bin/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). Przy okazji Taylor UUCP, warto
     wspomniec, ze jezeli w pliku sys zamiast hasla mozna wpisac '\P', a
     zamiast nazwy uzytkownika - '\L', dopisac dwie opcje: 'called-login *'
     i 'called-password *', po czym te poufne dane umiescic w pliku 'call' w
     postaci trojki 'nazwa-uucp-systemu nazwa-konta haslo', czyli np.:

             omega   Ualfa   AAAAAA

     Czesto wystepujacym bledem uniemozliwiajacym poprawne polaczenie dwoch
     serwerow przez UUCP jest to, ze komputer nawiazujacy polaczenie usiluje
     ustawiac 7-bitowe wysylanie danych z kontrola 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 oraz
     zawartosci "glownego" pliku konfiguracyjnego).
     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) nalezy 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. Jezeli w przyszlosci oprocz omegi pojawia sie inne systemy, to
     takze nalezy dla nich dopisac odpowiednie linie z 'uucico', albo
     uruchamiac 'obdzwanianie' wszystkich systemow za pomoca "uucico -sall".

     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. Ostatnie dwie linijki w
     powyzszym przykladzie oznaczaja, ze 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. Jezeli
     uzywamy Taylor UUCP, to nalezy pamietac, by zamiast uudemon.hour,
     odpowiednio czesto uruchamiac z crontaba uzytkownika uucp komendy
     uucico kontaktujace sie z innym systemem, tak jak to zostalo opisane
     powyzej, albo np:

             7 8-16 * * * /usr/local/lib/uucp/uucico -somega
             7,17,37 17-23,0-6 * * * /usr/local/lib/uucp/uucico -somega

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

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
     juz w /usr/bin), a uux w systemie 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, a 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 bajtow, 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). Warto tez
     wpisac pewne ograniczenia, aby w przypadku jakiejs awarii po drugiej
     stronie nie zapchac dysku narastajacymi kolejkami batchow. Mozna to
     zrobic za pomoca opcji -m przy wywolaniu skryptu sendbatch z crontaba,
     jak ponizej:

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

     W powyzszym przykladzie batche sa kompresowane (opcja -c), kazdy z nich
     nie dluzszy niz 100kB (opcja -s), a na dodatek jezeli wielkosc
     zgromadzonych na dysku batchow przekroczy 12 tys. blokow (czyli
     zaleznie od standardowej wielkosci bloku dyskowego - 6 lub 12 MB), to
     generowanie batchow zostaje wstrzymane - identyfikatory "wychodzacych"
     newsow sa nadal gromadzone w /var/news/out.going/cocos i
     /var/news/out.going/cocos.uucp, ale plik 'cocos.uucp' zostanie uzyty do
     wygenerowania nastepnego batcha, dopiero wtedy, gdy nieco ubedzie
     batchow juz znajdujacych sie w kolejce do wyslania.

     Wielkosc podana jako argument opcji '-m' to ilosc bajtow na dysku,
     ktore moga zajac batche, ale tak jest tylko w wypadku 1024-bajtowych
     blokow na dysku (BSD, Linux, SunOS). W SysV (AIX, Solaris, IRIX)
     komenda 'df' i pokrewne podaja dane zakladajac 512-bajtowe bloki, a
     wiec jesli batche maja zajmowac nie wiecej niz 10 MB, to nalezy podac
     liczbe 20.000.000.

     Warto tez od razu zauwazyc, ze metoda ograniczania batchow nie
     zadziala, gdy transmitujemy batche uucp w sposob posredni, co zostalo
     opisane w dalszej czesci.

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

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 crontab-a.
----------------------------------------------------------------------------

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.

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

UUCP 'posrednie' (czyli jak wykonac cyber!papaja!rnews)

Spotykanym czasem problemem zwiazanym z rozsylaniem news jest jak wyslac
newsy z serwera za pomoca UUCP do systemu, z ktorym serwer nie ma
bezposredniego lacza UUCP (np. na serwerze news nie ma modemu, a newsy
trzeba przesylac przez telefon). Przykladowa sytuacja zilustrowana jest
ponizej.

             uucp/tcpip                 uucp/modem
     news  <------------>  cyber  <----- - - - - ----->  papaja
   serwer news

'papaja' oznacza system, na ktorym chcemy odbierac newsy, a ktory laczy sie
z systemem 'cyber' przez modem, uzywajac protokolow UUCP. cyber i news tez
maja polaczenie UUCP, ale oparte o TCP/IP, gdyz oba znajduja sie w sieci
lokalnej. Problem polega na takim ustawieniu systemow, by na serwerze news
generowac batche dla komputera papaja, i aby docieraly one poprawnie na
miejsce.

Jesli jest mozliwe laczenie sie komputera papaja z siecia za pomoca
protokolow SLIP lub PPP, to problem mozna rozwiazac definiujac na serwerze
news system papaja i kazac im laczyc sie bezposrednio, za pomoca UUCP/tcpip.
Inne wyjscie to skorzystac z komputera cyber wylacznie jako "przekaznika"
polaczen, tzn. zamiast 'login-shell-a' typu uucico wykonac "rlogin news" z
odpowiednim username, ktorego shellem oczywiscie bedzie uucico, ale juz na
docelowym systemie. Gorzej, gdy to cyber ma dzwonic przez telefon do systemu
papaja.

Najbardziej "klasyczne" i uniwersalne rozwiazanie to taka generacja batchow
na serwerze, by trafialy one na miejsce przeznaczenia calkowicie za pomoca
protokolow UUCP. W tym celu nalezy zmienic komende 'uux', ktorej uzywa
skrypt 'sendbatch', a najprosciej zrobic to, definiujac odpowiedni plik w
katalogu /var/news/out.going.

W "normalnym" przypadku (i w tym tez) w pliku newsfeeds serwera news znalezc
sie powinna definicja 'feedu' papaja (jako feedu UUCP!), co powoduje
utworzenie w /var/news/out.going pliku o takiej samej nazwie, uzywanego do
zapamietywania, ktore artykuly trzeba do tego komputera wyslac. Standardowa
komenda wysylajaca newsy jest "uux - -gd -n ${SITE}!rnews", gdzie '${SITE}'
zostaje zastapione nazwa uucp hosta odbierajacego batch. W przypadku braku
bezposredniego polaczenia musi tu jeszcze wejsc host posredni, a wiec
komenda powinna wygladac tak:

 "uux - -gd -n ${INTERMEDIATE_SITE}!${SITE}!rnews"

a wiec np. "uux - -gd -n cyber!papaja!rnews". Aby taka komende zdefiniowac,
wystarczy utworzyc plik o nazwie '/var/news/out.going/${SITE}.cmd', a wiec
np. /var/news/out.going/papaja.cmd, a w nim wpisac odpowiednia komende 'uux'
(podana wyzej). Tworzone w ten sposob batche przeznaczone beda (ostatecznie)
dla systemu papaja, ale ich transfer nastapi na system cyber i dopiero
stamtad trafia we wlasciwe miejsce.

Pamietac tez trzeba o okresowym generowaniu batchow za pomoca skryptu
"sendbatch" (jak to zostalo juz wczesniej opisane, oraz o tym, ze opcja '-m'
ograniczajaca wielkosc znajdujacych sie w kolejce batchow jest tutaj
bezuzyteczna. Batche te sa tutaj bowiem kolejkowane na komputer 'cyber', a
nie 'papaja', a wiec sprawdzenie wielkosci kolejki na papaje nic nie da.
----------------------------------------------------------------------------

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, mic...@adm.usenet.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, tsur...@adm.usenet.pl)

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