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

Spis tresci czesci 2.:

Konfiguracja serwera news

Jak podlaczyc serwer news do sieci usenet?

Jak skonfigurowac serwer news (grupy pl.*)

Plik active

Plik newsfeeds

Uwagi dotyczace serwerow majacych feedy zagraniczne

Plik moderators

Plik distrib.pats

Plik distributions

Plik newsgroups

Plik control.ctl

Co robic z listami typu "checkgroups"?

Jak skonfigurowac mail2news i news2mail

mail2news z uzyciem procmaila

Newsfeed za pomoca UUCP

Kompresja batchow za pomoca gzip

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

Inne mozliwosci przyspieszania transmisji

Podlaczanie nowych serwerow

• W sieci Usenet-PL serwery dziela sie na tzw. huby i liscie. Hub to serwer, ktory ma lacze z wieloma innymi serwerami i oprocz udostepnianai artykulow swoim uzytkownikom, sluzy takze do transferu danych pomiedzy serwerami, z ktorymi ma lacznosc. Serwerami takimi sa przewaznie duze serwery news w sieciach akademickich, a takze news.tpi.pl, news.onet.pl i kilka innych. Wszystkie pozostale (w tym takze twoj) jest lisciem -- tzn. powinien zajmowac sie wylacznie otrzymywaniem artykulow, obslugiwaniem swoich uzytkownikow oraz wysylaniem listow pochodzacych od tych uzytkownikow do swojego sasiada (lub sasiadow).

  Jesli masz tylko jednego sasiada, sprawa jest prosta, jesli jednak skonfigurowales (lub masz zamiar w przyszlosci) uzyskac takze inne lacze/feed, to po pierwsze musi to byc feed od innego huba (a nie liscia), po drugie - w pliku newsfeeds musisz zadbac o to, by nie przesylac artykulow pomiedzy tymi hubami. Zajrzyj do przykladow opisujacych plik newsfeeds, a takze informacje dotyczace list wykluczeniowych w przypadku feedow zagranicznych, bo to jest praktycznie ta sama sytuacja.

  W przypadku wykrycia lisci, ktore liscmi nie sa, bo przesylaja artykuly takze innym serwerom, sa one odcinane do czasu wyjasnienia sytuacji i naprawienia problemu.

• Autoryzacja dostepu Twoj serwer news nie powinien dawac dostepu do news "wszystkim", lecz tylko wybranej grupie uzytkownikow, ktora mozna zidentyfikowac w razie problemow. Moze to byc dostep na haslo wymagajacy wszesniejszej rejestracji (i pozwalajacej na uniemozliwienie ponownej rejestracji osobom uporczywie przeszkadzajacym innym przez wysylanie spamow lub inne naduzycia) albo dostep dla waskiej klasy adresow IP ograniczonej do wlasnej firmy/sieci osiedlowej itp. Takze w tym drugim przypadku powinna byc mozliwosc identyfikacji pojedynczego uzytkownika -- jesli w sieci lokalnej uzywasz dynamicznych adresow nadawanych np. przez DHCP, powinienes takze zadbac o archiwizowanie logow serwera pozwalajacych na identyfikacje komputera/uzytkownika, ktory laczyl sie z twoim serwerem news. Dane takie powinny umozliwiac znalezienie winnych w przypadku naduzyc co najmniej 1-2 tygodnie wstecz.
• Bramki www-news Obecnie nie jest dozwolone tworzenie zadnych bramek www-news pozwalajacych na wysylanie artykulow do systemu usenet news. Z reguly bramki takie nie umozliwiaja zadnej autoryzacji dostepu, albo maja ja zaimplementowana w sposob trywialny do obejscia, staja sie wiec szybko zrodlem spamow i innych naduzyc. Sa tez zrodlem mnostwa innych problemow, takich jak niepoprawnie formatowane naglowki, brak w naglowkach informacji pozwalajacych na identyfikacje nadawcy (jego adresu IP, nazwy konta, itp.), czy wrecz petle wysylajace do newsow artykuly pochodzace z newsow, zwrotow o niemoznosci dostarczenia jakichs listow, czy calej masy innego smiecia. Aby uruchomic taka bramke, wymagane byloby zmudne przetestowanie, czy spelnia ona wszystkie wymagania zwiazane ze wspolpraca z serwerami news, a nawet i wtedy podlaczenie newsow do serwera WWW powoduje z reguly zalew grup dyskusyjnych nowymi "newbie", nie zdajacymi sobie sprawy z tego, czym sa grupy dyskusyjne, jakie w nich obowiazuja zasady i ze kazda grupa ma swoja scisle okreslona tematyke, a nie jest kolejna ikonka na pulpicie, sluzaca za miejsce do gadania o wszystkim.

• Edukacja uzytkownikow Uzytkownicy twojego serwera news powinni otrzymywac informacje na temat systemu Usenet news - jak z niego korzystac, jakie w nim obowiazuja zasady, co jest dozwolone, a co zabronione. Mozesz w tym celu odsylac ich do dokumentacji dostepnej pod adresem http://www.usenet.pl/doc/ (w szczegolnosci do informacji o FAQ-bocie i regulach dotyczacych wysylania artykulow w grupach pl.* oraz do artykulow FAQ mozliwych do znalezienia w pl.answers, a takze do Netykiety wysylanej periodycznie do pl.answers i pl.news.nowe-grupy. Zajrzyj takze na http://faq-bot.usenet.pl/ -- jest tam wiele informacji dotyczacych zasad obowiazujacych w poszczegolnych grupach.

Konfigurowanie serwerow

Poza tym wiekszosc zainstalowanych serwerow (i w Polsce i na swiecie) to wlasnie INN. Instalacja pozostalych (takich jak DNEWS na przyklad) wymaga zdecydowanie wiecej samozaparcia, a efektem bardzo czesto jest serwer, ktorego i tak nie mozna podlaczyc do sieci Usenet News z powodu wad w implementacji protokolu NNTP i spustoszenia. jakie to sieje w sieci (np. redystrybucja starych artykulow z nowymi Message-Id:) 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)

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

        ctlinnd reload active ''
        ctlinnd go ''

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

'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:

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

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

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

Drugi krotki i z zycia wziety przyklad (wg mapki z pierwszej czesci FAQ). newsfeeds na okapi: uw 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.pl,uw.edu.pl,plonk.apk.net\
            :*,!pwr.*,/!local,!pwr,!wroc\
            :Tm:cocos

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

        cocos:!*:Tf,Wnm:

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

Uwagi dotyczace serwerow majacych feedy zagraniczne

Mozna tego uniknac odpowiednio definiujac reguly wykluczania w pliku newsfeeds (po znaku "/" w nazwie feedu). Do tego potrzebna jest jednak znajomosc wszystkich polaczen Polski ze swiatem i tego, co zagraniczne serwery news wpisuja w polu Path:

news.uoregon.edu,hammer.uoregon.edu,arclight.uoregon.edu,fu-berlin.de

news.nacamar.de,newsfeed.nacamar.de,news.apfel.de,news.maxwell.syr.edu

Serwery w USA i Niemczech, wymieniajace BIG 8, pl.* i inne grupy z serwerem w ICM.

news.apk.net (aka plonk.apk.net, ale to pierwsze wystarczy)

Serwer w USA (Cleveland, Ohio), wymieniajace BIG 8 i pl.* z serwerem news.uw.edu.pl, a takze comp, news i pl z serwerem news.ict.pwr.wroc.pl (gzipowane batche UUCP).

newscore.univie.ac.at

Serwery w Austrii, znane poprzednio (przed 12.01.1998) jako 01-newsfeed.univie.ac.at i 02-newsfeed.univie.ac.at, a jeszcze wczesniej jako newsfeed.ACO.net, wymieniajace BIG 8, de.*, pl.* i inne grupy z serwerem NASK

newsfeed.sunet.se

Serwer w Szwecji wymieniajacy BIG 8, de.*, pl.* i inne grupy z serwerem UW. Wczesniej znany jako sunic

news.icmp.lviv.ua

Serwer na Ukrainie. Polaczenie przez NASK. Sam takze otrzymuje newsy innymi drogami (z USA i Europy), dlatego dobrze jest takze umiescic go na liscie.

news.cistron.nl

Serwer w Holandii, wymieniajacy wylacznie grupy linux.* z serwerem news.uw.edu.pl.

news.miracle.net

nntp.uio.no

Serwery news w USA (Connecticut) i Norwegii (Oslo), wymieniajace z serwerem news.ict.pwr.wroc.pl niewielkie feedy zawierajace hierarchie pl.* i linux.*.

jakis-feed/news.apk.net,newsfeed.sunet.se,\
        news.icmp.lviv.ua,news.cistron.nl,news.micro-net.net,\
        news.uoregon.edu,hammer.uoregon.edu,arclight.uoregon.edu,\
        newsfeed.nacamar.de,news.nacamar.de,news.apfel.de,\
        news-spur1.maxwell.syr.edu,\
        www.nntp.primenet.com,nntp.primenet.com,\
        fu-berlin.de,fci-se,newscore.univie.ac.at\
	: ......

                pl.*:%s@usenet.pl

usenet.pl jest adresem klasy MX wskazujacym na hosty utrzymujace pelna liste wszystkich 'moderatorow' grup pl (obecnie sa to galaxy.uci.agh.edu.pl i okapi.ict.pwr.wroc.pl). Domena ta powstala na poczatku sierpnia 1995, zastepujac stosowana uprzednio domene moderators.fuw.edu.pl.

Plik distrib.pats

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

        30:pl.listserv.email-d:pwr

Plik distributions

        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

Plikow tego mozna uzyc do sprawdzenia, czy lista grup na serwerze jest aktualna w nastepujacy sposob:

    lynx -source http://www.usenet.pl/doc/pl.newsgroups | \
    $inn/control/checkgroups

    lynx -source http://www.usenet.pl/doc/news-pl-faq.3 | \
    sed -e '1,/^=== /d' -e '/^--- /d' | \
    $inn/control/checkgroups

Aby byl sprawdzany podpis PGP, potrzebne jest oczywiscie odpowiednie oprogramowanie na serwerze - sam program pgp oraz skrypty 'pgpverify' i poprawiony 'parsecontrol' serwera news. Znajduja sie one w dytrybucji INN poczawszy od wersji 1.5, a dla poprzednich wersji (a takze serwerow CNEWS) mozna sciagnac z sieci odpowiednie poprawki. Wiecej informacji na ten temat mozna przeczytac pod adresem ftp://ftp.pwr.wroc.pl/pub/networking/news/misc/pgpcontrol/ (mirror strony z ftp.uu.net). Tam mozna takze znalezc klucz PGP uzywany w hierarchii pl.

Jesli jednak na serwerze nie jest dokonywana weryfikacja PGP, musi wowczas wystarczyc metoda "tradycyjna", jako ze artykuly specjalne podpisane przez PGP sa tez poprawnie rozpoznawane, gdy PGP nie ma na serwerze (ale oczywiscie nie da sie wtedy zweryfikowac ich autentycznosci).

Trzeba pamietac, ze OSTATNI pasujacy opis zostaje uzyty, tak wiec w okolicach konca pliku nalezy dopisac dla grup pl.*:

        ##  PL newsgroups  - bez weryfikacji kluczem PGP
        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

    ##  PL newsgroups - weryfikacja kluczem PGP
    newgroup:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.newgroups
    rmgroup:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.newgroups
    checkgroups:newgroup@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.newgroups

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

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

        sendsys:*@adm.usenet.pl:*:doit=miscctl
        version:*@adm.usenet.pl:*:doit=miscctl

Nie nalezy sie obawiac, ze uruchomienie docheckgroups cokolwiek zmieni lub cos "zepsuje". 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 -

• Spod adresu http://www.usenet.pl/doc/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.

        "|/usr/lib/news/sendnews"

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), moze to jednak powodowac zamieszanie na liscie dyskusyjnej.

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 mial zostac wlaczony do INN v1.5, ale tak sie nie stalo), jest bowiem na razie w wersji 'beta' (choc trwa to juz od konca 1993 roku), nalezy sie wiec skontaktowac z autorem (Rich Salz - rsalz@uunet.uu.net), by otrzymac jego kopie. Dobrze jest takze skontaktowac sie ze mna (pod adresem tsurmacz@ict.pwr.wroc.pl), aby uzyskac poprawki do tego programu, zapewniajace wlasciwe traktowanie naglowkow "Content-Type:" i innych, ktore wystepuja w listach/artykulach zawierajacych polskie znaki diakrytyczne. Istnieje takze (na razie w fazie zaawansowanych 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, nalezy uzywac tego drugiego), 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 administratora news 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 listserv@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"

        % cat > test.posting
        From: uzytkownik@serwer.news.pl
        To: pl-nowa-grupa
        Message-ID: test-1@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

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

        # cat | /usr/lib/sendmail -fpl-nowa-grupa@serwer.news.pl listserv@plearn.edu.pl
        From: pl-nowa-grupa@serwer.news.pl
        To: listserv@plearn.edu.pl

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

        set nowa-lista full
        set nowa-lista noack

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-nowa-grupa@serwer.news.pl plearn.edu.pl

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

Poza tym 'From:' zawsze zawiera adres z pola '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 w sposob pewny 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 poczawszy od wersji 8.7.1 ponownie jest respektowana), np:

        DT root uucp news

    From news.test@cyber.ict.pwr.wroc.pl Sat Aug  6 18:05:02 1994
    Return-Path: <news.test@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: tsurmacz@sprocket.ict.pwr.wroc.pl (Tomasz Surmacz)
    Message-Id: <320c32$ena@cyber.ict.pwr.wroc.pl>
    Sender: news.test@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.test@cyber.ict.pwr.wroc.pl asic

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

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

Ostatnia uwaga, dotyczaca uruchamiania roznych bramek -- powyzszy opis ma za zadanie pomoc w konfiguracji bramek uruchamianych dla wlasnych lokalnych potrzeb, niedostepnych z zewnatrz i dla "wszystkich". Pojawiajace sie ostatnio (2001-2003) jak grzyby po deszczu bramki wrzucane do roznorakich serwisow www i nie wymagajace zadnej autoryzacji dostepu (przez co szybko staja sie zrodlem spamow, trolli i innych abuserow), beda tepione z cala surowoscia.

Jesli na serwerze news zainstalowanych jest kilka bramek mail2news, mozna je wszystkie obslugiwac za pomoca jednego pliku z regulkami procmaila, separujac odpowiednie listy na grupy news po naglowkach To: lub innych, mozna tez dla kazdej grupy stworzyc osobny alias z osobnym plikiem .rc, zakladajac, ze plik ten obsluguje wylacznie jedna liste dyskusyjna, polaczona z jedna bramka mail2news. Jako ze roznica polega jedynie na wpisaniu odpowiednich regulek, w dalszej czesci opisu nie ma znaczenia, ktory z tych sposobow zostal wybrany.

Wszystkie pliki .rc bramek najlepiej umiescic w jednym katalogu, np. ~news/mail2news. Program procmail, wywolywany posrednio przez plik /etc/aliases uruchamiany bedzie z opcja -m, oznaczajaca, ze ma dzialac jako filtr poczty, czytajac konfiguracje z jawnie podanego pliku konfiguracyjnego z regulami filtrowania poczty. W tym trybie procmail zachowuje sie jednak roznie, zaleznie od tego, w jakim katalogu znajduje sie ten plik. Jesli jest to plik, ktorego pelna sciezka rozpoczyna sie od /etc/procmailrcs/ i nie zawiera w nazwie odwolan posrednich w gore (czyli do katalogow `..'), to poczta bedzie dostarczana z prawami uzytkownika, ktory jest wlascicielem tego pliku. Dopuszczalne sa dowiazania symboliczne, ale nie zawierajace w sciezce katalogow `..'. Jezeli te warunki nie sa spelnione, albo program procmail nie ma ustawionego bitu suid, poczta bedzie dostarczana w standardowy sposob, tzn. z takimi prawami uzytkownika, jakie zostana ustawione przez agenta pocztowego wywolujacego procmail (czyli zwykle program sendmail), bedzie to wiec zazwyczaj uzytkownik daemon i grupa mail (tak naprawde zalezy to jednak od tego, co jest wpisane w konfiguracji sendmail.cf).

Wlasciwe prawa dostepu do katalogu, zawierajacego pliki z regulami filtrowania poczty, do samych plikow z tymi regulami oraz wszystkich innych plikow, potrzebnych procmailowi do zapisywania logow itp., sa kluczowe dla prawidlowego dzialania calosci. Jesli wystepuja jakiekolwiek bledy, najprawdopodobniej sa one spowodowane wlasnie tym, ze procmail wykonywany jesy jako inny uzytkownik i nie ma prawa odczytu konfiguracji lub zapisu logow.

Najlepiej, aby procmail wykonywany byl jako uzytkownik news, dlatego z katalogu /etc/procmailrcs dobrze jest utworzyc dowiazanie symboliczne do odpowiedniego katalogu posiadanego przez uzytkownika news lub tworzyc pliki konfiguracyjne jako uzytkownik newss bezposrednio w podkatalogu /etc/procmailrcs.

Nalezy wiec wykonac jedna z dwoch rzeczy:

	mkdir /etc/procmailrcs
	cd /etc/procmailrcs
	ln -s ~news/mail2news mail2news
lub:
	mkdir /etc/procmailrcs
	cd /etc/procmailrcs
	mkdir mail2news
	chown news mail2news
	chgrp news mail2news
	chmod 2755 mail2news

	PATH=/bin:/usr/bin:/usr/local/bin
	HOME=/home/news
	MAILDIR=$HOME/mail2news
	DEFAULT=$MAILDIR/Default	#completely optional
	LOGFILE=$MAILDIR/from		#recommended

	:0:
	* From.*MAILER-DAEMON
	warning

	:0
	*
	|/usr/local/news/bin/mail2news -o'Lista xxx' -npl.xxx xxx

Ostatnia rzecza do zrobienia jest wpisanie lub modyfikacja odpowiedniego aliasu w pliku /etc/aliases, a powinien on wygladac nastepujaco:

	news.xxx: "|/usr/local/bin/procmail -m /etc/procmailrcs/mail2news/xxx.rc"

0. Dlaczego?

Przeslanie jednego artykulu odbywa sie w nastepujacy sposob:

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

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.

I. Konfiguracja uucp

Standardowe UUCP

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 poslac do inetd sygnal 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 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 uruchamianie programu uudemon.hour co 30 minut. Warto - zwlaszcza do testow na poczatek - uruchamiac go czesciej.

Taylor UUCP

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 pakietu 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" uudemon.crontab, 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

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
   

   
   

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

   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 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:

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

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

W systemie Solaris 2.3, przy korzystaniu ze "standardowego" UUCP nalezy zwrocic uwage na parametr _PATH_COMPRESS w pliku config.data serwera, a jesli jest juz na to za pozno, w pliku sendbatch 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). Linie z parametrami programu uux nalezy poprawic zawsze, gdyz 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.

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

I. Konfiguracja C News do nadawania z kompresja gzip

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

2. W pliku batchparms zmienic compcun na gzipcun

II. Konfiguracja C News do odbierania z dekompresja gzip

*** 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;

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

*** 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)

IV. Konfiguracja INN do odbierania z dekompresja gzip

            _PATH_COMPRESS          /usr/ucb/compress
            _PATH_COMPRESSEXT       .Z

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

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

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 - -r -gd -n ${INTERMEDIATE_SITE}!${SITE}!rnews

niestety, kolejnym problemem pojawiajacym sie po utworzeniu pliku ${SITE}.cmd jest to, ze sendbatch przestaje uwzgledniac opcje -c i -cg umozliwiajace kompresje batchow, traktujac zawartosc pliku ${SITE}.cmd doslownie, bez najmniejszych modyfikacji. Jezeli wysylane batche maja byc kompresowane, przedstawiona powyzej komende nalezy zosatapic inna:

 (echo '#! cunbatch' ; exec /usr/bin/compress) | uux - - -r -n -gd ${INTERMEDIATE_SITE}!${SITE}!rnews

Zaleznie od tego, jak w systemie uucp zdefiniowane sa dozwolone czasy laczenia sie z innymi systemami, pozadane jest zwykle uzywanie w powyzszych poleceniach 'uux' opcji '-r, sprawiajacej, ze wykonanie uux nie bedzie od razu wywolywac programu uucico, aby natychmiast polaczyc sie z drugim systemem. Czesta bowiem sytuacja jest zdefiniowanie, ze system "domowy" moze laczyc sie ze swoim sasiadem uucp o dowolnej porze, co oznacza, ze w dowolnym momencie mozna stwierdzic, ze wystarczy pisania listow i czas wykonac stosowne uucico. Brak opcji -r powodowalby natychmiastowe uruchomienie uucico po utworzeniu przez sendbatch pierwszej paczki artykulow, co moze byc przydatne na serwerze news tworzacym batche dla systemu "domowego", ale najprawdopodobniej nie jest pozadane na serwerze "domowym", powodowaloby bowiem natychmiastowa probe dzwonienia.

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.

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

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

FAQ po angielsku dla administratorow serwerow news poza Polska

(c) 1994-2004 Tomasz R. Surmacz, Michal Jankowski, Rafal Maszkowski

Kopirajt i disclajmer:

Powyzszy tekst moze byc w niezmienionej postaci i w calosci (wszystkie czesci FAQ), bez ograniczen kopiowany i drukowany *na wlasny uzytek*, przekazywany przez news, e-maila, umieszczany w sieci Internet na serwerach WWW, FTP itp. itd.), pod warunkiem przechowywania aktualnej wersji (nie starszej niz 2-3 miesiace). Publikowanie tego tekstu w inny sposob lub dokonywanie w nim modyfikacji, skrotow, oraz rozprowadzanie zmienionej wersji tego FAQ lub jego fragmentow wymaga zgody autorow.

Aktualna wersja znajduje sie zawsze pod adresem http://www.usenet.pl/doc/news-pl-faq.htpl i http://www.ict.pwr.wroc.pl/doc/news-pl-faq.html

Autorzy niniejszego FAQ staraja sie, by wszelkie przedstawione w nim informacje byly aktualne, ale gwarantowac tego nie sa w stanie. Jesli po przeczytaniu tego dalej nic nie rozumiesz, program tin czyta konfiguracje z jakiegos dziwnego pliku, albo twoj ulubiony serwer news wlasnie sie na ciebie obrazil -- sorry!, C'est la vie... Jesli blad jest w tekscie - napisz na adres tsurmacz@adm.usenet.pl - moze poprawie.