Newsy w Polsce (FAQ) - część 2. - serwery news

Spis treści części 2.:

Konfiguracja serwera news

Jak podłączyć serwer news do sieci usenet?

Jak skonfigurować serwer news (grupy pl.*)

Plik active

Plik newsfeeds

Uwagi dotyczące serwerów mających feedy zagraniczne

Plik moderators

Plik distrib.pats

Plik distributions

Plik newsgroups

Plik control.ctl

Co robić z listami typu "checkgroups"?

Jak skonfigurować mail2news i news2mail

mail2news z użyciem procmaila

Newsfeed za pomocą UUCP

Kompresja batchów za pomocą gzip

UUCP 'pośrednie' (czyli jak wykonać cyber!papaja!rnews)

Inne możliwości przyspieszania transmisji

Podłączanie nowych serwerów

• W sieci Usenet-PL serwery dzielą się na tzw. huby i liście. Hub to serwer, który ma łącze z wieloma innymi serwerami i oprócz udostępnianai artykułów swoim użytkownikom, służy także do transferu danych pomiędzy serwerami, z którymi ma łączność. Serwerami takimi są przeważnie duże serwery news w sieciach akademickich, a także news.tpi.pl, news.onet.pl i kilka innych. Wszystkie pozostałe (w tym także twój) jest liściem -- tzn. powinien zajmować się wyłącznie otrzymywaniem artykułów, obsługiwaniem swoich użytkowników oraz wysyłaniem listów pochodzących od tych użytkowników do swojego sąsiada (lub sąsiadów).

  Jeśli masz tylko jednego sąsiada, sprawa jest prosta, jeśli jednak skonfigurowałeś (lub masz zamiar w przyszłości) uzyskać także inne łącze/feed, to po pierwsze musi to być feed od innego huba (a nie liścia), po drugie - w pliku newsfeeds musisz zadbać o to, by nie przesyłać artykułów pomiędzy tymi hubami. Zajrzyj do przykładów opisujących plik newsfeeds, a także informacje dotyczące list wykluczeniowych w przypadku feedów zagranicznych, bo to jest praktycznie ta sama sytuacja.

  W przypadku wykrycia liści, które liśćmi nie są, bo przesyłają artykuły także innym serwerom, są one odcinane do czasu wyjaśnienia sytuacji i naprawienia problemu.

• Autoryzacja dostępu Twój serwer news nie powinien dawać dostępu do news "wszystkim", lecz tylko wybranej grupie użytkowników, którą można zidentyfikować w razie problemów. Może to być dostęp na hasło wymagający wsześniejszej rejestracji (i pozwalającej na uniemożliwienie ponownej rejestracji osobom uporczywie przeszkadzającym innym przez wysyłanie spamów lub inne nadużycia) albo dostęp dla wąskiej klasy adresów IP ograniczonej do własnej firmy/sieci osiedlowej itp. Także w tym drugim przypadku powinna być możliwość identyfikacji pojedynczego użytkownika -- jeśli w sieci lokalnej używasz dynamicznych adresów nadawanych np. przez DHCP, powinieneś także zadbać o archiwizowanie logów serwera pozwalających na identyfikację komputera/użytkownika, który łączył się z twoim serwerem news. Dane takie powinny umożliwiać znalezienie winnych w przypadku nadużyć co najmniej 1-2 tygodnie wstecz.
• Bramki www-news Obecnie nie jest dozwolone tworzenie żadnych bramek www-news pozwalających na wysyłanie artykułów do systemu usenet news. Z reguły bramki takie nie umożliwiają żadnej autoryzacji dostępu, albo mają ją zaimplementowaną w sposób trywialny do obejścia, stają się więc szybko źródłem spamów i innych nadużyć. Są też źródłem mnóstwa innych problemów, takich jak niepoprawnie formatowane nagłówki, brak w nagłówkach informacji pozwalających na identyfikację nadawcy (jego adresu IP, nazwy konta, itp.), czy wręcz pętle wysyłające do newsów artykuły pochodzące z newsów, zwrotów o niemożności dostarczenia jakichś listów, czy całej masy innego śmiecia. Aby uruchomić taką bramkę, wymagane byłoby żmudne przetestowanie, czy spełnia ona wszystkie wymagania związane ze współpracą z serwerami news, a nawet i wtedy podłączenie newsów do serwera WWW powoduje z reguły zalew grup dyskusyjnych nowymi "newbie", nie zdającymi sobie sprawy z tego, czym są grupy dyskusyjne, jakie w nich obowiązują zasady i że każda grupa ma swoją ściśle określoną tematykę, a nie jest kolejną ikonką na pulpicie, służącą za miejsce do gadania o wszystkim.

• Edukacja użytkowników Użytkownicy twojego serwera news powinni otrzymywać informacje na temat systemu Usenet news - jak z niego korzystać, jakie w nim obowiązują zasady, co jest dozwolone, a co zabronione. Możesz w tym celu odsyłać ich do dokumentacji dostępnej pod adresem http://www.usenet.pl/doc/ (w szczególności do informacji o FAQ-bocie i regułach dotyczących wysyłania artykułów w grupach pl.* oraz do artykułów FAQ możliwych do znalezienia w pl.answers, a także do Netykiety wysyłanej periodycznie do pl.answers i pl.news.nowe-grupy. Zajrzyj także na http://faq-bot.usenet.pl/ -- jest tam wiele informacji dotyczących zasad obowiązujących w poszczególnych grupach.

Konfigurowanie serwerów

Poza tym większość zainstalowanych serwerów (i w Polsce i na świecie) to właśnie INN. Instalacja pozostałych (takich jak DNEWS na przykład) wymaga zdecydowanie więcej samozaparcia, a efektem bardzo często jest serwer, którego i tak nie można podłączyć do sieci Usenet News z powodu wad w implementacji protokołu NNTP i spustoszenia. jakie to sieje w sieci (np. redystrybucja starych artykułów z nowymi Message-Id:) Przez $inn określał będę katalog, w którym znajduja się pliki serwera, a więc 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 wyzerować w nim numerki oznaczające numery artykułów prostą instrukcją:

        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' dopisującego w polu 'Path:' nazwę 'news.host.somewhere.in.pl' powinien w najprostszym przypadku wyglądać 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 krótki i z życia wzięty przykład (wg mapki z pierwszej części FAQ). newsfeeds na okapi: uw dostaje wszystkie lokalne artykuły (tzn. takie, które nie były w Warszawie ani w USA) oraz comp.security* które nadchodzą 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 dotyczące serwerów mających feedy zagraniczne

Można tego uniknąć odpowiednio definiując reguły wykluczania w pliku newsfeeds (po znaku "/" w nazwie feedu). Do tego potrzebna jest jednak znajomość wszystkich połączeń Polski ze światem i tego, co zagraniczne serwery news wpisują 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, wymieniające 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), wymieniające BIG 8 i pl.* z serwerem news.uw.edu.pl, a także 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 wcześniej jako newsfeed.ACO.net, wymieniające BIG 8, de.*, pl.* i inne grupy z serwerem NASK

newsfeed.sunet.se

Serwer w Szwecji wymieniający BIG 8, de.*, pl.* i inne grupy z serwerem UW. Wcześniej znany jako sunic

news.icmp.lviv.ua

Serwer na Ukrainie. Połączenie przez NASK. Sam także otrzymuje newsy innymi drogami (z USA i Europy), dlatego dobrze jest także umieścić go na liście.

news.cistron.nl

Serwer w Holandii, wymieniający wyłącznie grupy linux.* z serwerem news.uw.edu.pl.

news.miracle.net

nntp.uio.no

Serwery news w USA (Connecticut) i Norwegii (Oslo), wymieniające z serwerem news.ict.pwr.wroc.pl niewielkie feedy zawierające hierarchie pl.* i linux.*.

jakiś-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 wskazującym na hosty utrzymujące pełną listę wszystkich 'moderatorów' grup pl (obecnie są to galaxy.uci.agh.edu.pl i okapi.ict.pwr.wroc.pl). Domena ta powstała na początku sierpnia 1995, zastępując stosowaną uprzednio domenę moderators.fuw.edu.pl.

Plik distrib.pats

        10:pwr.*:pwr                 - We Wrocławiu
        10:umk.*:umk                 - W Toruniu

        30:pl.listserv.email-d:pwr

Plik distributions

        pl        Polska
        pl-news   Polska, wyłącznie news, bez list dyskusyjnych
        krakow    Kraków
        cyfronet  Kraków
        torun     Toruń
        warszawa  Warszawa
        umk       UMK w Toruniu
        pwr       Politechnika Wrocławska
        wroc      Wrocław
        world     Cały świat
        inet      Internet
        mimuw     Wydz. Matematyki Informatyki i Mech. Uniw. Warszawskiego
        local     lokalny serwer news

Plików tego można użyć do sprawdzenia, czy lista grup na serwerze jest aktualna w następujący sposób:

    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 był sprawdzany podpis PGP, potrzebne jest oczywiście odpowiednie oprogramowanie na serwerze - sam program pgp oraz skrypty 'pgpverify' i poprawiony 'parsecontrol' serwera news. Znajdują się one w dytrybucji INN począwszy od wersji 1.5, a dla poprzednich wersji (a także serwerów CNEWS) można ściągnąć z sieci odpowiednie poprawki. Więcej informacji na ten temat można przeczytać pod adresem ftp://ftp.pwr.wroc.pl/pub/networking/news/misc/pgpcontrol/ (mirror strony z ftp.uu.net). Tam można także znaleźć klucz PGP używany w hierarchii pl.

Jeśli jednak na serwerze nie jest dokonywana weryfikacja PGP, musi wówczas wystarczyć metoda "tradycyjna", jako że artykuły specjalne podpisane przez PGP są też poprawnie rozpoznawane, gdy PGP nie ma na serwerze (ale oczywiście nie da się wtedy zweryfikować ich autentyczności).

Trzeba pamiętać, że OSTATNI pasujący opis zostaje użyty, tak więc w okolicach końca pliku należy dopisać 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 sprawdzić sposób reakcji serwera na 'sendsys'. Poniżej znajduje się 'preferowany' sposób dla standardowych zapytań - automatyczna odpowiedź, jeśli podany został argument (czyli jeśli np. komputer okapi otrzyma 'cmsg sendsys icm' - to odeśle fragment pliku newsfeeds dotyczący icm), oraz brak odpowiedzi, jeśli argumentu nie ma (by uniknąć 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 należy się obawiać, że uruchomienie docheckgroups cokolwiek zmieni lub coś "zepsuje". Program ten porównuje jedynie listę grup w dostarczonym mu na wejściu pliku z listą grup znajdującą się w plikach active i newsgroups. W przypadku niezgodności informacje o tym drukowane są na standardowym wyjściu w formacie skryptu sh. Tak więc można program docheckgroups uruchomić raz dla sprawdzenia, czy wszystko jest ok, a następnie w przypadku wykrycia niezgodności i zaakceptowania zmian wykonać program ponownie, jego wynik skierowując do programu sh (albo do pliku, a następnie do sh):

        $inn/control/docheckgroups < PLIK | sh -

• Spod adresu http://www.usenet.pl/doc/pl.newsgroups ściągnąć aktualną listę grup pl.* w formacie pliku newsgroups.
• Uruchomić program docheckgroups podając mu plik pl.newsgroups na wejście.
• To, co z niego wyjdzie zapamiętać w pliku i uruchomić jako skrypt.

        "|/usr/lib/news/sendnews"

Tak prosto jednak nie da się tego zrobić. Problem polega na tym, ze każdy artykuł wysłany na listę dyskusyjną trafiłby do news, po czym z news zostałby odesłany ponownie na listę dyskusyjną, tak więc na liście każdy artykuł pojawiałby się dwukrotnie. Jeśli na dodatek listserwer nie przekazuje (tzn. gubi) 'Message-ID', może się okazać, że artykuł ponownie wraca do news, skąd dalej zostaje zakolejkowany do listserwera i zaczyna się robić (nie)wesoło... Jeśli 'Message-ID' jest przez listserwer przekazywany jak należy, sytuacja taka nie będzie miala miejsca, gdyż artykuł posłany ponownie do news (z tym samym Message-ID) zostanie przez serwer news odrzucony jako duplikat (i zwykle wygeneruje list do Postmastera), może to jednak powodować zamieszanie na liście dyskusyjnej.

Ważne jest więc po pierwsze zagwarantowanie, by artykuł trafiający z listserwera do news nie zostawał wysłany z powrotem na listę, a także by listserwer nie gubił ani nie modyfikował Message-ID:, a także by generować Message-ID: w momencie przekazywania listu z e-maila do news, jeśli list go nie zawiera. W miarę możliwości należy także ustawić na listserwerze opcje 'NOACK', oznaczającą że listy wysłane z adresu serwera news nie są do niego ponownie odsyłane.

Do tego właśnie służą oba wspomniane programy. mail2news dokonuje przefiltrowania nagłówka maila, usuwając niepotrzebne lub niezgodne z RFC822 pola (np. 'Received:' jest w newsach w ogóle bez znaczenia). Jeżeli list nie posiada 'Message-ID:', to jest on generowany, ponadto tworzone jest pole 'Path:' z wpisanym odpowiednim tekstem, np. 'Path: gateway', dzięki czemu w serwerze news możliwe jest wysyłanie na listę dyskusyjną wyłącznie artykułów, które serwer news otrzymał od innych serwerow, a nie od mail2news (a więc nie majacych 'gateway' w polu 'Path:'). Opcjonalnie, mail2news potrafi także odfiltrować często posyłane na adres listy (zamiast listserwera) artykuły typu 'unsub nazwa-listy'.

W drugą stronę - news2mail usuwa z nagłówka pola nieistniejące w e-mailu (typu 'Path:', 'Supersedes:', itd.), ignoruje wszystkie listy typu 'control', tzn. np. kasujące poprzedni artykuł, martwi się o właściwe 'From:' i 'Sender:', by była możliwa odpowiedź do autora, a nie tylko na listę, oraz parę innych rzeczy. No i to co najważniejsze - przy właściwej konfiguracji każdy artykuł pojawia się dokładnie raz na liście i raz w newsach.

Pakiet mail2news nie jest na razie dostępny na żadnym anonymous ftp (podobno miał zostać włączony do INN v1.5, ale tak się nie stało), jest bowiem na razie w wersji 'beta' (choć trwa to już od końca 1993 roku), należy się więc skontaktować z autorem (Rich Salz - rsalz@uunet.uu.net), by otrzymać jego kopię. Dobrze jest także skontaktować się ze mną (pod adresem tsurmacz@ict.pwr.wroc.pl), aby uzyskać poprawki do tego programu, zapewniające właściwe traktowanie nagłówków "Content-Type:" i innych, które występują w listach/artykułach zawierających polskie znaki diakrytyczne. Istnieje także (na razie w fazie zaawansowanych testów) wersja w PERLu napisana przez Piotra Piątkowskiego, która dodatkowo potrafi dokonywać przekodowania z Quoted Printable na 8bit artykułów wysyłanych do newsów z poczty i odwrotnie w drugą stronę. W dalszej części opisany jest pakiet mail2news Richa Salza.

Przed kompilacją należy sprawdzić kilka parametrów - jakiego typu program używany jest do wysyłania poczty (sendmail czy mh), co dopisywane ma być w polu 'Path:' (standardowe 'gateway' czy np. 'gateway.pwr.wroc.pl'), czy adresy 'From:' news2mail ma generować z 'Path:', czy bezpośrednio z 'From:' w artykule (w czasach, gdy stosowanie adresów uucp staje się przeszłością, należy używać tego drugiego), oraz gdzie znajduje się serwer news (a jeśli na tej samej maszynie - gdzie sa jego biblioteki - a dokładniej: program inews lub rnews). Rożnica pomiędzy inews a rnews może okazać się istotna, bowiem inews jest tak naprawdę programem przewidzianym do "interaktywnego" przyjmowania newsów od użytkownikow, kontroluje więc m.in. format daty, a czasem także np. czy ilość cytowanego tekstu nie jest większa od nowego tekstu (jeśli tak zostal skompilowany). inews informuje także o błędach na stdout lub stderr, co w przypadku mail2news kończy się przekazaniem błędu dalej, czyli do sendmaila i co za tym idzie, zwrócenie listu do nadawcy (Sender:), czyli zwykle właściciela listy oraz lokalnego postmastera.

W 80% list dyskusyjnych wszystko dziala jednak jak należy, a wówczas inews jest o tyle lepszy, że poprzez zwracanie błędów w sposób natychmiastowy zwraca uwagę administratora news na to, że cos jest nie tak. Natomiast błędy występujace przy dostarczaniu artykułów za pomocą rnews sa zwykle przez ten program po cichu ignorowane, a odbicie znajdują jedynie w logach z pracy serwera. Istotne jest jednak to, że mail2news umożliwia podanie 'agenta news' jako parametr przy uruchomieniu, tak więc bez konieczności rekompilacji, można w dowolnym momencie inews zmienić na rnews lub odwrotnie.

Po skompilowaniu mail2news pozostaje juz właściwie tylko skonfigurować serwer news i listserwer, by przesyłały sobie nawzajem artykuły. Najpierw o tym, jak to zrobić z mail2news, bo z tym jest zwykle więcej problemów...

Rozpatrzmy taki przykład - tworzymy grupę "pl.nowa.grupa", którą łączymy z listą "nowa-lista" obsługiwaną przez listserv@plearn.edu.pl. Serwerem news, na którym tego dokonujemy jest "serwer.news.pl". Musimy serwer news 'zapisać na tę listę', tzn. np. stworzyć w /etc/aliases serwera (lub innego koputera w pobliżu) alias:

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

        % cat > test.posting
        From: użytkownik@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 newsów 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

Jeśli wszystko działa jak należy, pora na wysyłanie newsów na listę. W pliku newsfeeds należy dopisać linię mniej więcej następującej treści:

    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:' będzie wpisane nowa-lista@plearn.edu.pl,
• (3) - w polu 'Sender:' będzie wpisane pl-nowa-grupa@serwer.news.pl - 4. argument jest tutaj ignorowany, bo w adresie już jest '@'

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

'Sender:' - powinien być adresem, jakiego użyliśmy zapisując mail2news na listę, większość z list bowiem nie akceptuje listów wysyłanych przez osoby nie będące subskrybentami listy. Aby więc listy wysłane w newsach trafiały w sposób pewny na listę, użytkownik występujący w polu 'Sender' lub 'From' musi być na listę zapisany - co łatwo osiągnąć definiując właściwie pole 'Sender'. Ponadto, aby 'Sender:' wpisane przez news2mail było respektowane przez sendmail-a (lub innego agenta :-) pocztowego), trzeba jeszcze upewnić się, że użytkownik 'news' (z tym id działa serwer news, a więc i news2mail przez niego uruchamiany) jest wpisany w sendmail.cf jako 'trusted user', (opcja 'Trusted' jest bez znaczenia w sendmail 8.6.x, ale począwszy 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 - wysłany przez tin-a uruchomionego na komputerze
    'sprocket', połączonego 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, dotycząca uruchamiania różnych bramek -- powyższy opis ma za zadanie pomóc w konfiguracji bramek uruchamianych dla własnych lokalnych potrzeb, niedostępnych z zewnątrz i dla "wszystkich". Pojawiające się ostatnio (2001-2003) jak grzyby po deszczu bramki wrzucane do różnorakich serwisów www i nie wymagające żadnej autoryzacji dostępu (przez co szybko stają się źródłem spamów, trolli i innych abuserów), będą tępione z całą surowością.

Jeśli na serwerze news zainstalowanych jest kilka bramek mail2news, można je wszystkie obsługiwać za pomocą jednego pliku z regułkami procmaila, separując odpowiednie listy na grupy news po nagłówkach To: lub innych, można też dla każdej grupy stworzyć osobny alias z osobnym plikiem .rc, zakładając, że plik ten obsługuje wyłącznie jedną listę dyskusyjną, połączoną z jedną bramką mail2news. Jako że różnica polega jedynie na wpisaniu odpowiednich regułek, w dalszej części opisu nie ma znaczenia, który z tych sposobów został wybrany.

Wszystkie pliki .rc bramek najlepiej umieścić w jednym katalogu, np. ~news/mail2news. Program procmail, wywoływany pośrednio przez plik /etc/aliases uruchamiany będzie z opcją -m, oznaczającą, że ma działać jako filtr poczty, czytając konfigurację z jawnie podanego pliku konfiguracyjnego z regułami filtrowania poczty. W tym trybie procmail zachowuje się jednak różnie, zależnie od tego, w jakim katalogu znajduje się ten plik. Jeśli jest to plik, którego pełna ścieżka rozpoczyna się od /etc/procmailrcs/ i nie zawiera w nazwie odwołań pośrednich w górę (czyli do katalogów `..'), to poczta będzie dostarczana z prawami użytkownika, który jest właścicielem tego pliku. Dopuszczalne są dowiązania symboliczne, ale nie zawierające w ścieżce katalogów `..'. Jeżeli te warunki nie są spełnione, albo program procmail nie ma ustawionego bitu suid, poczta będzie dostarczana w standardowy sposób, tzn. z takimi prawami użytkownika, jakie zostaną ustawione przez agenta pocztowego wywołującego procmail (czyli zwykle program sendmail), będzie to więc zazwyczaj użytkownik daemon i grupa mail (tak naprawdę zależy to jednak od tego, co jest wpisane w konfiguracji sendmail.cf).

Właściwe prawa dostępu do katalogu, zawierającego pliki z regułami filtrowania poczty, do samych plików z tymi regułami oraz wszystkich innych plików, potrzebnych procmailowi do zapisywania logów itp., są kluczowe dla prawidłowego działania całości. Jeśli występują jakiekolwiek błędy, najprawdopodobniej są one spowodowane właśnie tym, że procmail wykonywany jesy jako inny użytkownik i nie ma prawa odczytu konfiguracji lub zapisu logów.

Najlepiej, aby procmail wykonywany był jako użytkownik news, dlatego z katalogu /etc/procmailrcs dobrze jest utworzyć dowiązanie symboliczne do odpowiedniego katalogu posiadanego przez użytkownika news lub tworzyć pliki konfiguracyjne jako użytkownik newss bezpośrednio w podkatalogu /etc/procmailrcs.

Należy więc wykonać jedną z dwóch 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

Ostatnią rzeczą do zrobienia jest wpisanie lub modyfikacja odpowiedniego aliasu w pliku /etc/aliases, a powinien on wyglądać następująco:

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

0. Dlaczego?

Przesłanie jednego artykułu odbywa się w następujacy sposób:

   Nadawca: mam artykuł 
   Obiorca: sprawdza, odpowiada: nie mam, dawaj go.
   N: nadaje, czeka.
   O: potwierdza odbiór.
   N: mam artykuł 
   ...

Opóźnienie wprowadzane przez linię satelitarną wynosi ok. 800ms, co oznacza, ze nawet najszybsza linia i najszybszy komputer nie są w stanie przesłać po takiej linii więcej niz ok. 100000 artykułów na dobę, przy obecnej 'dawce' rzedu 70000. W praktyce jest jeszcze gorzej, bo pozostałe etapy też trwają.

Drugą wadą jest też brak jakiejkolwiek kompresji przesyłanych danych, a doświadczenie wykazuje, że na zawartości artykułów newsowych można osiagnąć współczynnik kompresji do ok. 50% pierwotnej wielkości. Ta wada jest z kolei bardzo istotna w przypadku łącz o małej przepustowości.

Obu tych wad nie posiada sposób przesyłania za pomocą tzw. 'compressed batches over uucp'. Przesyła się w paczkach - a więc nie trzeba czekać na potwierdzenie każdego artykułu. Kompresuje się - a więc danych do przesłania jest mniej.

Oczywiście, ten sposób też ma wady:

• wymaga uruchomienia oprogramowania uucp.
• może się zdarzyć, że w paczce przyjdzie niepotrzebnie coś, co już mamy (to grozi tylko wtedy, kiedy mamy feedy z różnych miejsc).
• przepełnienie dysku grozi dużo poważniejszymi konsekwencjami.

I. Konfiguracja uucp

Standardowe UUCP

Zakładamy, że łączymy ze sobą komputery alfa.aaa.aaa (site name AAA.aaa) i omega.zzz.zzz (site name ZZZ.zzz). Dalsze instrukcje dotyczą alfy, na omedze wszystko tak samo, tylko odwrotnie.

1. Założyć nowego użytkownika przez dopisanie do /etc/passwd

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

gdzie ZZZZZZ jest oczywiście zakodowanym hasłem. Numer użytkownika i grupy powinien być taki jak dla użytkownika nuucp. 'Home directory' - w zasadzie dowolny, np. /var/spool/uucp, itp. Ważne by nie był to katalog z prawem zapisu dla 'wszystkich' (czyli 777 lub 1777).

2. Włączyć uucpd

Dopisać w /etc/inetd.conf linię:

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

lub jeśli stosowany jest pakiet tcp_wrappers:

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

i posłać do inetd sygnał HUP.

W tym drugim przypadku warto też pamiętać o dopisanu komputera omega.zzz.zzz do listy tych, którym wolno łączyć się z demomem "in.uucpd"

3. Pliki konfiguracyjne uucp.

Do /etc/Systems dopisać:

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

gdzie AAAAAA jest niezakodowanym hasłem użytkownika Ualfa na komputerze omega. W Solarisie 2.x plikiem tym jest /etc/uucp/Systems, natomiast w przypadku używanego często 'Taylor uucp' jest to oczywiście 'sys'. (Podobnie z następnymi plikami). Przy okazji Taylor UUCP, warto wspomnieć, że w pliku sys zamiast hasła można wpisać '\P', a zamiast nazwy użytkownika - '\L', dopisać dwie opcje: 'called-login *' i 'called-password *', po czym te poufne dane umieścić w pliku 'call' w postaci trójki 'nazwa-uucp-systemu nazwa-konta hasło', czyli np.:

        omega   Ualfa   AAAAAA

Często występującym błędem uniemożliwiającym poprawne połączenie dwóch serwerów przez UUCP jest to, że komputer nawiązujący połączenie usiłuje ustawiać 7-bitowe wysyłanie danych z kontrolą parzystości, podczas gdy "serwer" spodziewa się danych 8-bitowych. Tak na przykład jest na SUNach z SunOSem i Solarisem. Można temu jednak prosto zaradzić, uzupełniając powyższą linię w pliku Systems w taki sposób:

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

Do /etc/Permissions lub odpowiednika dopisać:

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

(Oczywiście, należy podać prawdziwą ścieżkę do programu rnews).

4. Periodyczne przeglądanie kolejek uucp włącza się przez crontab:

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

I juz.

Uwaga: standardowo crontab ustawia uruchamianie programu uudemon.hour co 30 minut. Warto - zwłaszcza do testów na początek - uruchamiać go częściej.

Taylor UUCP

1. Tak jak i w "zwykłym" UUCP - założyć nowego użytkownika przez dopisanie do /etc/passwd

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

(ZZZZZZ - zakodowane hasło. Numer użytkownika i grupy taki, jak dla użytkownika nuucp). Zależnie jednak od tego, jak uruchamiamy demona uucico, ten krok może okazać się zbędny. Przyjmijmy, że uucico będzie dokonywać autentykacji użytkowników samodzielnie. Wówczas modyfikacja /etc/passwd nie jest konieczna.

2. Włączamy demona uucp.

Dopisujemy w /etc/inetd.conf linie:

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

lub jeśli stosowany jest pakiet tcp_wrappers:

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

i posyłamy do inetd sygnał HUP.

Uruchomienie uucico z opcjami '-s -l' powoduje, że dokonywać ono będzie sprawdzenia nazwy i hasła użytkownika samodzielnie. Można oczywiście stosować wyjście z in.uucpd, pamiętając jednak, że in.uucpd ZAWSZE woła potem /usr/lib/uucp/uucico, należy więc umieścić w tym miejscu uucico z pakietu Taylor uucp. Hasła i loginy, jakie uucico akceptuje, znajdują się w pliku passwd, ale nie w katalogu /etc, tylko w tym, w którym jest cała reszta plików konfiguracyjnych Taylor UUCP (załóżmy, że jest to katalog /etc/uucp, ale to zależy od parametrów kompilacji Taylor UUCP oraz zawartości "głównego" pliku konfiguracyjnego).

I ponownie - jeśli stosujemy tcpd, pamiętajmy o dopisanu komputera omega.zzz.zzz do listy tych, którym wolno łączyć się z demomem "uucico"

3. Pliki konfiguracyjne uucp.

Do /etc/sys (A dokładniej - do pliku 'sys' w katalogu z konfiguracją Taylor UUCP) należy dopisać:

        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 hasłem użytkownika Ualfa na komputerze omega. Hasło to na omedze znaleźć się musi w /etc/uucp/password w takiej postaci:

        Ualfa     AAAAAA

To, czy w pliku passwd hasła są zakodowane, czy nie, zależy od opcji kompilacji Taylor UUCP.

3. Dobrze jest sprawdzić, czy w pliku port znajduje się definicja "portu" o nazwie TCP, z którego mamy zamiar korzystać:

    port TCP
    type tcp

4. Periodyczne przeglądanie kolejek uucp włącza się przez crontab:

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

Jeśli brak nam natomiast "standardowego" uudemon.crontab, wpisać możemy 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 już. Jeżeli w przyszłości oprócz omegi pojawią się inne systemy, to także należy dla nich dopisać odpowiednie linie z 'uucico', albo uruchamiać 'obdzwanianie' wszystkich systemów za pomocą "uucico -sall".

Uwaga: 15 minut jest tu tylko orientacyjnym czasem, co jaki można przesyłać kolejki uucp. Warto samemu zbadać, jaki czas będzie najlepszy i dopasować to do potrzeb serwera news. Ostatnie dwie linijki w powyższym przykładzie oznaczają, że jeśli batch siedzi w kolejce 120-144 godzin (czyli 5-6) dni, to ostrzegamy "nadawcę" zadania (czyli w tym przypadku "news") o niemożności przesłania batcha, po 7 dniach (168 godzin) niedostarczone batche usuwamy.

II. Konfiguracja C News do wysyłania batchów

1. Założyć katalog:

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

2. W pliku /usr/lib/news/sys wpisać:

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

   
   Lista wysyłanych grup i dystrybucji oczywiście do indywidualnego ustalenia.

3. W pliku /usr/lib/news/batchparms wpisać:

           omega           200000  20      batcher compcun viauux
   

   
   
4. Uruchomić wysyłanie batchów przez dopisanie do crontaba linii:

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

   
   Uwaga: Można co 10 minut, można rzadziej. Dobrze jest, aby było to skorelowane z godzinami, kiedy uruchamiany jest uudemon.hour - tak, aby uudemon startował zaraz po przygotowaniu paczki do wysłania. Można np. przygotowywać paczki o 00 i 30, a demona startować o 05 i 35. Im częściej będziemy to robić, tym mniejsze będą opóźnienia w rozchodzeniu się news, ale nie należy przesadzać, żeby nie przeciążyć komputera i nie zniweczyć zysków, które uzyskaliśmy dzięki paczkowaniu. Jeżeli używamy Taylor UUCP, to należy pamiętać, by zamiast uudemon.hour, odpowiednio często uruchamiać z crontaba użytkownika uucp komendy uucico kontaktujące się z innym systemem, tak jak to zostało opisane powyżej, 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. uruchamiać 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 dobrać, żeby się uruchamiał w parę minut po nadejściu każdej paczki.)

   albo

   stworzyć plik /usr/lib/news/rnews.immed, co sprawi, że rnews będzie automatycznie uruchamiać newsrun.

   Jeśli feed jest duży i wiemy, że za każdym obiegiem sendbatches maszyna omega posyła nam średnio więcej niż jeden batch, polecam sposób pierwszy. Jeśli dostajemy tylko niewielkie batche, pojedyncze i nie za każdym obiegiem sendbatches, polecam sposób drugi.

IV. Konfiguracja INN do wysyłania batchów.

1. Utworzenie feedu w pliku newsfeeds, przykładowo:

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

Zwykły feed używa na ogół parametrów "Tf,Wnm". Feed UUCP - "Tf,Wnb" - co powoduje tworzenie w /var/spool/news/out.going pliku o innym formacie niż dla NNTP, zawierającego ścieżki do artykułów i ich wielkości. 'cocos' to tutaj zarówno nazwa pliku w katalogu out.going jak i adres UUCP adresata. Adres nie musi byc zarejestrowany w mapach UUCP. Identyfikatory do Path:_ są te same, co dla feedu nntp. Dla porównania, 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 należy zwrócić uwagę na parametr _PATH_COMPRESS w pliku config.data serwera, a jeśli jest już na to za późno, w pliku sendbatch poprawić linię:

        COMPRESS=/usr/ucb/compress

i

        UUXFLAGS="- -r -n -gd"

na

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

ponieważ ścieżka do compress jest inna (w Solarisie 2.4 ponownie jest już w /usr/bin). Linię z parametrami programu uux należy poprawić zawsze, gdyż uux w systemie Solaris nie rozumie grade 'd'.

Aby temu zaradzić, można skompilować (na Solarisie, Linuxie i innych systemach) "Taylor UUCP" - kompiluje się bez problemów, poza jednym małym - jeśli planujemy używać UUCP także przez modem, trzeba KONIECZNIE w pliku "policy.h" zdefiniować 'HAVE_POSIX_TERMIOS', zamiast liczyć na to, że system sam zgadnie (według opisu), bo w Solarisie zgaduje 'HAVE_SYSV_TERMIO' i źle działa z szybkimi (potrzebującymi sprzętowej kontroli przepływu) modemami, a na Linuxach kompilator zgaduje HAVE_BSD_TERMIO, zamiast stosować HAVE_POSIX_TERMIOS.

INN FAQ zaleca, aby rozmiar pojedynczego batcha zwiększyć z

               DEFBYTES=50000 

do 200000 bajtów, zarówno dla połączeń TCP jak i telefonicznych. Można to zrobić przez zmianę wartości tej zmiennej w skrypcie lub podanie opcji -s200000 przy wywołaniu sendbatch w cronie.

3. Periodyczne wywoływanie sendbatch.

Do crontab użytkownika news należy dopisać:

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

gdzie cocos to adres UUCP adresata. Częstotliwość nie musi być tak duża. Opcja -c może byc zastąpiona opcją -cg wg propozycji Michała (p. III. Konfiguracja INN do nadawania z kompresją gzip poniżej). Warto też wpisać pewne ograniczenia, aby w przypadku jakiejś awarii po drugiej stronie nie zapchać dysku narastającymi kolejkami batchów. Można to zrobić za pomocą opcji -m przy wywołaniu skryptu sendbatch z crontaba, jak poniżej:

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

W powyższym przykładzie batche są kompresowane (opcja -c), każdy z nich nie dłuższy niż 100kB (opcja -s), a na dodatek jeżeli wielkość zgromadzonych na dysku batchów przekroczy 12 tys. bloków (czyli zależnie od standardowej wielkości bloku dyskowego - 6 lub 12 MB), to generowanie batchów zostaje wstrzymane - identyfikatory "wychodzących" newsów są nadal gromadzone w /var/news/out.going/cocos i /var/news/out.going/cocos.uucp, ale plik 'cocos.uucp' zostanie użyty do wygenerowania następnego batcha, dopiero wtedy, gdy nieco ubędzie batchów już znajdujących się w kolejce do wysłania.

Wielkość podana jako argument opcji '-m' to ilość bajtów na dysku, które mogą zająć batche, ale tak jest tylko w wypadku 1024-bajtowych bloków na dysku (BSD, Linux, SunOS). W SysV (AIX, Solaris, IRIX) komenda 'df' i pokrewne podają dane zakładając 512-bajtowe bloki, a więc jeśli batche mają zajmować nie więcej niż 10 MB, to należy podać liczbę 20.000.000.

Warto też od razu zauważyć, że metoda ograniczania batchów nie zadziała, gdy transmitujemy batche uucp w sposób pośredni, co zostało opisane w dalszej części.

V. Konfiguracja INN do odbierania batchów.

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

I. Konfiguracja C News do nadawania z kompresją gzip

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

2. W pliku batchparms zmienić compcun na gzipcun

II. Konfiguracja C News do odbierania z dekompresją 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 można się bez tej zmiany obejść, wtedy newsspool błędnie nadaje typ plikom rozszerzenie .Z zamiast .gz, ale programowi gunzip (patrz niżej) to nie szkodzi.

2. W skrypcie /news/lib/newsbin/input/newsrun zmienić nastepująco:

*** 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 dekompresją 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

Jeśli jest możliwe łączenie się komputera papaja z siecią za pomocą protokołów SLIP lub PPP, to problem można rozwiązać definiując na serwerze news system papaja i każąc im łączyć się bezpośrednio, za pomocą UUCP/tcpip. Inne wyjście to skorzystać z komputera cyber wyłącznie jako "przekaźnika" połączeń, tzn. zamiast 'login-shell-a' typu uucico wykonać "rlogin news" z odpowiednim username, którego shellem oczywiście będzie uucico, ale już na docelowym systemie. Gorzej, gdy to cyber ma dzwonić przez telefon do systemu papaja.

Najbardziej "klasyczne" i uniwersalne rozwiązanie to taka generacja batchów na serwerze, by trafiały one na miejsce przeznaczenia całkowicie za pomocą protokołów UUCP. W tym celu należy zmienić komendę 'uux', której używa skrypt 'sendbatch', a najprościej zrobić to, definiując odpowiedni plik w katalogu /var/news/out.going.

W "normalnym" przypadku (i w tym też) w pliku newsfeeds serwera news znaleźć się powinna definicja 'feedu' papaja (jako feedu UUCP!), co powoduje utworzenie w /var/news/out.going pliku o takiej samej nazwie, używanego do zapamiętywania, które artykuły trzeba do tego komputera wysłać. Standardową komendą wysyłającą newsy jest "uux - -gd -n ${SITE}!rnews", gdzie '${SITE}' zostaje zastąpione nazwą uucp hosta odbierającego batch. W przypadku braku bezpośredniego połączenia musi tu jeszcze wejść host pośredni, a więc komenda powinna wyglądać tak:

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

niestety, kolejnym problemem pojawiającym się po utworzeniu pliku ${SITE}.cmd jest to, że sendbatch przestaje uwzględniać opcje -c i -cg umożliwiające kompresję batchów, traktując zawartość pliku ${SITE}.cmd dosłownie, bez najmniejszych modyfikacji. Jeżeli wysyłane batche mają być kompresowane, przedstawioną powyżej komendę należy zosatąpić inną:

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

Zależnie od tego, jak w systemie uucp zdefiniowane są dozwolone czasy łączenia się z innymi systemami, pożądane jest zwykle używanie w powyższych poleceniach 'uux' opcji '-r, sprawiającej, że wykonanie uux nie będzie od razu wywoływać programu uucico, aby natychmiast połączyć się z drugim systemem. Częstą bowiem sytuacją jest zdefiniowanie, że system "domowy" może łączyć się ze swoim sąsiadem uucp o dowolnej porze, co oznacza, że w dowolnym momencie można stwierdzić, że wystarczy pisania listów i czas wykonać stosowne uucico. Brak opcji -r powodowałby natychmiastowe uruchomienie uucico po utworzeniu przez sendbatch pierwszej paczki artykułów, co może być przydatne na serwerze news tworzącym batche dla systemu "domowego", ale najprawdopodobniej nie jest pożądane na serwerze "domowym", powodowałoby bowiem natychmiastową próbę dzwonienia.

Pamiętać też trzeba o okresowym generowaniu batchów za pomocą skryptu "sendbatch" (jak to zostało już wcześniej opisane, oraz o tym, że opcja '-m' ograniczająca wielkość znajdujących się w kolejce batchów jest tutaj bezużyteczna. Batche te są tutaj bowiem kolejkowane na komputer 'cyber', a nie 'papaja', a więc sprawdzenie wielkości kolejki na papaję nic nie da.

Można też uruchomić stałe połączenie między serwerami - nntplink lub innfeed, też stosowany w układzie drabinkowym.

Ale ten rozdział napisze już pewnie ktoś inny w następnej wersji...

FAQ po angielsku dla administratorów serwerów news poza Polską

(c) 1994-2004 Tomasz R. Surmacz, Michał Jankowski, Rafał Maszkowski

Kopirajt i disclajmer:

Powyższy tekst może być w niezmienionej postaci i w całości (wszystkie części FAQ), bez ograniczeń kopiowany i drukowany *na własny użytek*, przekazywany przez news, e-maila, umieszczany w sieci Internet na serwerach WWW, FTP itp. itd.), pod warunkiem przechowywania aktualnej wersji (nie starszej niż 2-3 miesiące). Publikowanie tego tekstu w inny sposób lub dokonywanie w nim modyfikacji, skrótów, oraz rozprowadzanie zmienionej wersji tego FAQ lub jego fragmentów wymaga zgody autorów.

Aktualna wersja znajduje się 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 starają się, by wszelkie przedstawione w nim informacje były aktualne, ale gwarantować tego nie są w stanie. Jeśli po przeczytaniu tego dalej nic nie rozumiesz, program tin czyta konfigurację z jakiegoś dziwnego pliku, albo twój ulubiony serwer news właśnie się na ciebie obraził -- sorry!, C'est la vie... Jeśli błąd jest w tekście - napisz na adres tsurmacz@adm.usenet.pl - może poprawię.