Newsy w Polsce (2/4) - konfiguracja serwerow (FAQ)
Tomasz R. Surmacz
Archive-name: news-pl-faq/part2
Newsy w Polsce (FAQ) - część 2. - serwery news
Poniższy tekst, to druga część FAQ na temat newsów w Polsce,
zawierająca uwagi na temat konfigurowania serwerów news. Wszelkie
poprawki i uzupełnienia proszę kierować na adres
tsur...@ict.pwr.wroc.pl Aktualną wersję całego FAQ można znaleźć
zawsze we Wrocławiu przez WWW:
http://www.usenet.pl/doc/news-pl-faq.htpl oraz w grupach news
pl.news.admin i pl.answers.
_________________________________________________________________
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
_________________________________________________________________
Jeśli chcesz do sieci Usenet news podłączyć własny serwer, po pierwsze
należy zastanowić się, czy skórka warta jest wyprawki. Mały serwer z
kilkunastoma lub nawet kilkuset grupami może być niewart instalacji ze
względu na czas spędzany następnie na jego konfigurowanie. Duży serwer
natomiast wymaga wręcz ogromnego pasma danych, jeśli mają na nim byc
założone wszystkie grupy. W styczniu 2003 wielkość ,,feedu''
obejmującego same grupy pl.* to około 20-40 MB/dziennie, wszystkie
grupy hierarchii BIG8 - około 1-2 GB/dziennie, wszystkie grupy
włączając w to alt.* - około 120-200 GB dziennie. I niestety z każdym
rokiem te wielkości się mniej więcej podwajają.
Musisz też u siebie zainstalować serwer news, czyli program innd,
działający w środowisku UNIX. Alternatywnym programem serwera news
jest Diablo w systemie UNIX, jednak nie ma on sensu dla niewielkich
instalacji newsowych. "Serwery news" oparte o oprogramowanie
Microsoftu nie są i nie będą podłączane do sieci Usenet i to
bynajmniej nie z powodu niechęci reszty administratorów do tej firmy,
lecz z powodu masy problemów, jakie ten "serwer" powoduje przez to, że
nie bardzo przejmuje się standardami dotyczącymi systemu news. Jeśli
nadal chcesz uruchomić u siebie serwer news, musisz uzgodnić to z
administratorem innego serwera, który "da ci feed", czyli skonfiguruje
swój serwer tak, by przesyłał do twojego wybrane grupy oraz akceptował
artykuły wysyłane z twojego serwera. Informacje jak skonfigurować
różne pliki serwera znajdziesz w następnym punkcie, natomiast przy
uzyskiwaniu feedu od innego serwera musisz przekazać jego
administratorowi kilka kluczowych informacji koniecznych do właściwego
skonfigurowania łącza po drugiej stronie. Są to m.in:
* Nazwa i adres IP twojego serwera news. Jeśli ma kilka adresów IP -
wszystkie z nich. Jeśli wysyłał będzie artykuły z innego adresu
niż adres, na jaki ten drugi serwer ma się z nim łączyć, także to
zaznacz.
* Nazwa, jaką twój serwer wpisuje w polu Path:
* Dane kontaktowe - adres email, imię i nazwisko osoby
odpowiedzialnej za sewrer news, w miarę możliwości także kontakt
telefoniczny w razie jakichś nagłych wypadków.
* Listę grup news, jakie chcesdz otrzymywać w formacie pliku
newsfeeds. Wysyłając ją w tym właśnie formacie zaoszczędzisz pracy
osobie po drugiej stronie łącza, a być może nawet jest to jedyny
sposób, by twoja prośba w ogóle została rozpatrzona.
* Jeśli już masz jakieś feedy z innych serwerów -- informację o
nich.
W odpowiedzi powinieneś dostać list zawierający podobne dane dotyczące
serwera, z którego będziesz otrzymywał i wysyłał artykuły.
Najważniejsze z nich są:
* Adres/nazwa do wysyłania news -- wpisz go do nntpsend.ctl lub
innfeed.conf.
* Adres/nazwa, z którego będziesz otrzymywał artykuły. Wpisz ją do
hosts.nntp lub incoming.conf.
* Zawartość pola Path: twojego sąsiada -- wpisz ją w odpowiednim
miejscu pliku newsfeeds. Jeśli masz kilku sąsiadów, wpisz tę nazwę
do konfiguracji dotyczącej ich wszystkich, aby nie przesyłać
artykułów między nimi.
Przeładuj pliki konfiguracyjne odpowiednią komendą ctlinnd reload i
przetestuj czy połączenie działa poprawnie (oraz poproś administratora
drugiego serwera, by przetestował, czy może się połączyć z tobą).
Bardzo ważnym aspektem uruchomienia usługi serwera news są oprócz
aspektów technicznych zasady, na jakich podłączane są nowe serwery.
Najważniejsze z tych zasad wymienione są poniżej:
* 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
_________________________________________________________________
Ogólna uwaga dotycząca wszystkich konfiguracji -- BARDZO WAŻNE!!!
Serwery news nie mogą pozwalać na pisanie do grup hierarchii pl.*
każdemu bez jakiejkolwiek autoryzacji. Jeśli serwer ma być z założenia
otwarty dla wszystkich, to musi zawierać system kont i
uwierzytelniania. Celem systemu musi być uniknięcie sytuacji
niekontrolowanego anonimowego dostępu do usenetu przez ten serwer,
gdyż takie sytuacje prędzej czy później prowadzą do nadużyć
odbijających się echem po całym usenecie.
Dotyczy to nie tylko samych serwerów news, ale i wszelkiego rodzaju
bramek z innych usług, np. email, www, wap, itp.
Jak skonfigurować serwer news (w Polsce)
To zależy od samego serwera... i najlepiej wyjaśnione jest w
odpowiednich README lub FAQ towarzyszących serwerowi. Poniżej jednak
parę uwag specyficznych dla właściwego skonfigurowania serwera w
Polsce. Z góry zastrzegam, że dotyczy to praktycznie wyłącznie serwera
INN, gdyż tylko takie miałem okazję konfigurować i na tym się znam ;-)
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)
Plik ten zawiera spis wszystkich grup, które serwer otrzymuje. Jeśli
uruchamiamy nowy serwer, najlepiej jest ściągnąć aktualną wersję
takiego pliku z innego serwera news (który będzie nas w newsy zasilał)
za pomocą protokołu nntp, lub z ftp.uu.net poprzez ftp. Pierwsze
wyjście polega na wykonaniu '$inn/bin/getlist -h jakiś.serwer.news.pl
active', drugie - użyciu 'anonymous ftp' ale uwaga... ftp.uu.net, mimo
że od jakiegoś czasu posiada także grupy pl.*, to nie wszystkie
niestety zostały tam poprawnie założone. Dlatego lepiej skorzystać z
fragmentów pliku active, dotyczącego grup pl, a znajdującego się pod
adresem http://www.usenet.pl/doc/pl.active. Plik ten jest codziennie
automatycznie uaktualniany na podstawie pliku active serwera
news.ict.pwr.wroc.pl.
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
nie zapominając o tym, że jeśli serwer news już działa, to MUSI zostać
wczesniej zatrzymany np. przez '$inn/bin/ctlinnd pause xx', a ponowne
uruchomienie powinno nastąpić przez:
ctlinnd reload active ''
ctlinnd go ''
Jeśli dopisać trzeba pojedyncze nowe grupy w już działajacym serwerze,
należy do tego użyć 'ctlinnd newgroup pl.nazwa.grupy y', bez
uprzedniego zatrzymywania serwera. Jeśli grupa jest moderowana,
zamiast 'y' powinno oczywiście pojawić się 'm'.
Plik newsfeeds ($inn/newsfeeds lub $inn/site/newsfeeds)
Zależy od tego, kto zasila nas w newsy i komu newsy są dalej posyłane.
Jest on naprawdę dobrze udokumentowany w INND FAQ oraz na stronie
manuala, wystarczy więc może jedynie 2 małe przykłady...
'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:
gdzie xxx jest dowolnym (w miarę krótkim, bo pojawia się wielokrotnie
w logach) akronimem reprezentującym dany host, wystepującym również w
pliku 'nntpsend.ctl':
xxx:news.host.pl:::-T1720 -t300
gdzie nazwa 'xxx' zostaje związana z adresem internetowym
'news.host.pl'. Warto przy okazji zwrocić uwage na parametr -T1720
(lub podobny) zamiast 'standardowego' -T1800. Parametr -Tn oznacza, że
jedna sesja nntpsend nie może trwać dłużej niż n sekund. W przypadku
n=1800, oznaczałoby to dokładnie 30 minut. Standardowo nntpsend jest
startowany z crontab-a co 10 minut, a wygląda to mniej więcej tak:
0,10,20,30,40,50 * * * * /usr/lib/news/nntpsend
Gdy pojawia się sytuacja, że newsów jest na tyle dużo, że nntpsend
jest w stanie pełne 30 minut wykorzystać, to kończenie tuż po tym, jak
crontab wystartował nowego nntpsend, który się skończył, stwierdziwszy
że poprzedni jeszcze działa, jest marnotrawieniem kolejnych 10 minut,
czyli 25% przepustowości łącza. Dlatego czas dla -T powinien być
wielokrotnością 10 minut, pomniejszoną o 1-2 minuty, by dać programowi
nntpsend czas na 'posprzątanie' w momencie kończenia działania. Drugą
sprawą pozwalającą przyspieszyć docieranie news z jednego końca Polski
w drugi jest to, by na sąsiadujących serwerach news czasy wysyłania
batchów były nieco poprzesuwane, np. jeśli 'mapka' serwerów wyglada
tak:
bilbo <---> okapi <---> sun1000
to jeśli, przykładowo, na bilbo nntpsend startuje o pełnej godzinie i
dalej co 10 minut, to na okapi powinno to być np. 5 minut po pełnej
godzinie i dalej co 10 minut (czyli 5,15,25,...), a na sun1000 znowu o
pełnej godzinie. Natomiast jeśli jeszcze istnieje dodatkowe połączenie
bilbo <---> sun1000, to jeszcze lepiej jest, gdy bilbo ma 0,10,...,
okapi np. 3,13,23,33,... a sun1000 6,16,26,...
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:
Pierwsze 2 linijki to 'wejście lejka' o wspólnym ujściu nazwanym
'cocos', przy czym 'cocos' nie ma tutaj NIC wspólnego z nazwą
komputera, na który zostanie to wysłane. Pierwsza linijka odnosi się
do wszystkich artykułów, które nie nadeszły z Warszawy ani z USA
(przez serwer plonk.apk.net), druga - do wszystkich artykułów z grup
'security', które nie nadeszły z Warszawy. WPisanie kilku nazw
(pochodzących z Path: tych serwerów) zapobiega przesyłaniu artykułów
pomiędzy nimi. Ostatnia linia to 'ujście lejka' prowadzące do pliku
'cocos' w katalogu /var/news/out.going (lub odpowiednio innym), gdzie
zapisywane są odsyłacze do artykułów, wykorzystywane co 10 minut przez
innxmit. Symboliczna nazwa 'cocos' jest tłumaczona na rzeczywisty
adres komputera (którym jest 'news.uw.edu.pl') w pliku 'nntpsend.ctl':
cocos:news.uw.edu.pl::-T1720 -t300
Uwagi dotyczące serwerów mających feedy zagraniczne
Newsy do Polski spływają kilkoma drogami i poprzez sieci różnych
operatorów (TPSA, NASK, POL-34), nie grozi nam więc sytuacja, że
wskutek awarii pojedynczego serwera news (np. chwilowego zapchania
dysku na którymś z serwerów news) zostaniemy całkiem odcięci od
dopływu nowych newsów ze świata lub zaczniemy otrzymywać je ze
znacznym opóźnieniem. Z drugiej strony jednak bez odpowiedniej
konfiguracji może to prowadzić do niepożądanego "tranzytu" newsów np.
z USA do USA przez kilka serwerów w Polsce.
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.*.
Powyższa lista nie jest pełna, jako że po raz pierwszy powstała w roku
1995, a feedy potrafią się zmieniać i co 2-3 tygodnie. W miarę
aktualna, pełna lista "excludes" powinna wyglądać następująco:
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\
: ......
Plik moderators
Standardowy plik przychodzący z dystrybucją INND, uzupełniony na
początku o linię: nowość!
pl.*:%s...@usenet.pl
co powoduje wysyłanie artykułów w moderowanych grupach pl.* na adres
typu nazwa-grupy-z-kropkami...@usenet.pl. Linia
taka znajduje się już w standardowej (tzn. rozprowadzanej wraz ze
źródłami serwera) dystrybucji INND począwszy od wersji 1.5.
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
Plik ten należy uzupełnić o lokalne dystrybucje, tam gdzie one
występują, np.:
10:pwr.*:pwr - We Wrocławiu
10:umk.*:umk - W Toruniu
a także ew. niektóre grupy, które mają inną dystrybucję, niż wynika to
z ich nazwy, np. we Wrocławiu:
30:pl.listserv.email-d:pwr
gdyż pl.listserv.email-d jest lokalną grupą wrocławską mimo nazwy
'pl.' i artykuły posłane do tej grupy otrzymują standardowo
dystrybucję 'pwr'. Specjalne definiowanie domyślnej dystrybucji pl dla
grup pl.* jest błędem, gdyż powinno to być 'world' (a w ogóle, to
najlepiej zamiast 'world' pozostawić wtedy "pustą" dystrybucję,
oznaczającą cały świat) - a dystrybucja pl ma rzeczywiście oznaczać
rozsyłanie artykułów wyłącznie do serwerów w Polsce.
Plik distributions
Zawiera opisy poszczególnych dystrybucji. To, co dla Polski
najważniejsze, poniżej:
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 newsgroups
Plik z jednolinijkowymi opisami poszczególnych grup. Opis grup pl.*
wysyłany jest regularnie w trzeciej części tego FAQ w grupach
pl.news.admin i pl.answers, a regularnie raz na dwa miesiące także w
postaci tzw. "checkgroups message". Dostępny jest także poprzez WWW
pod adresem: http://www.usenet.pl/doc/pl.newsgroups. Lista grup, wraz
z aktualnym plikiem active, dostępna jest w 3. części tego FAQ.
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
lub:
lynx -source http://www.usenet.pl/doc/news-pl-faq.3 | \
sed -e '1,/^=== /d' -e '/^--- /d' | \
$inn/control/checkgroups
Plik control.ctl
Plik ułatwiający 'centralne' i zautomatyzowane tworzenie nowych grup.
Polega ono na tym, że w pewnej hierarchii news (np. w grupach pl.*)
pewna osoba zostaje uznana za autorytatywną, jeśli chodzi o tworzenie
nowych grup i kasowanie starych, czego dokonuje przez wysłanie
odpwiednio sformatowanych artykułów news, zawierających pewne magiczne
zaklęcia. Aby zaklęcia te były zrozumiałe dla serwerów news, w ich
pliku control.ctl muszą się oczywiście pojawić odpowiednie linie
konfiguracji. Obecnie, aby zabezpieczyć się przed "podróbkami" listów,
w wielu hierarchiach news stosowana jest metoda podpisywania tych
specjalnych artykułów kluczem PGP. Tak jest w hierarchii "BIG 8"
(comp, news, rec, talk, itd.), jak i w niektórych hierarchiach
narodowych (de, fr, uk), a od października 1996, także w hierarchii
pl.
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:newg...@usenet.pl:pl.*:doit=newgroup
rmgroup:newg...@usenet.pl:pl.*:doit=rmgroup
Jeżeli natomiast serwer został skonfigurowany do weryfikacji artykułów
specjalnych przez PGP, to zamiast powyższych linii należy wpisać linie
następujące:
## PL newsgroups - weryfikacja kluczem PGP
newgroup:newg...@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.new
groups
rmgroup:newg...@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.newg
roups
checkgroups:newg...@usenet.pl|michalj@*fuw.edu.pl:pl.*:verify-pl.announce.
newgroups
UWAGA! - W obu przypadkach między '*' a 'fuw' nie ma kropki!
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
Na serwerach w Polsce dobrze jest także dopisać następujące linie:
sendsys:*@adm.usenet.pl:*:doit=miscctl
version:*@adm.usenet.pl:*:doit=miscctl
spowodują one wysłanie pliku newsfeeds lub listu zawierającego w
treści numer wersji serwera, jeżeli odpowiednio sformatowany artykuł
specjalny nadejdzie z adresu znajdującego się w domenie adm.usenet.pl.
Pozwala to na uaktualnianie informacji o serwerach news w Polsce i ich
wzajemnych połączeniach (np. w celu uaktualnienia mapki zamieszczonej
w części pierwszej tego FAQ), bez konieczności ciągłego zawracania
głowy poszczególnym administratorom serwerów news (bo serwer sam
wysyła odpowiedź, a administratora jedynie informuje w krótkim liście,
że odpowiedź została wysłana).
_________________________________________________________________
Co robić z listami typu "checkgroups"?
Od czasu do czasu wysyłany jest tzw. "checkgroups message" dla grup
pl.*, tzn. specjalny artykuł naws zawierający listę wszystkich
aktywnych grup. Artykuł taki wyróżniony jest odpowiednią linią
"Control:", dzięki czemu każdy serwer news, który taki artykuł
otrzyma, zależnie od konfiguracji - przesyła go swojemu
administratorowi pocztą elektroniczną, lub automatycznie go wykonuje i
jeśli wykryje jakieś rozbieżności pomiędzy przesłaną listą grup, a
lokalnie istniejącymi grupami w tej hierarchii, to informuje o tym
administratora. W pierwszym z tych dwóch przypadków, w liście tym
serwer dołącza na początku komentarz mówiący w jaki sposób należy z
tym artykułem postąpić. Jest to zwykle polecenie postaci
$inn/control/docheckgroups < PLIK.
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 -
Artykuł "checkgroups" wysyłany jest 2 miesiące (1 dnia miesiąca w
miesiące nieparzyste) z adresu newg...@usenet.pl. Jeśli artykuł taki
potrzebny jest "od zaraz" (np. przy konfigurowaniu nowego serwera
news), można sobie poradzić inaczej:
* 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.
Oprócz tego, co jakiś czas (ale niezbyt często) wysyłane są na nowo
specjalne artykuły "tworzące" grupy, które już dawno istnieją. Np.
pl.test, pl.news.admin i inne. Jeśli 'zakładana' grupa już istnieje na
serwerze, to serwer ignoruje taki artykuł specjalny, jeśli nie
istnieje - tworzy grupę. Nie wymaga to żadnej dodatkowej konfiguracji
ponad tę, opisaną przy okazji opisu zawartości pliku "control.ctl".
_________________________________________________________________
Jak skonfigurować mail2news i news2mail
mail2news i news2mail to dwa programy odpowiedzialne za spinanie ze
sobą (jak sama nazwa wskazuje) newsów i maila, tzn. list dyskusyjnych.
Wydawać by się mogło, że w zasadzie są one niepotrzebne, no bo cóż...
- wystarczyłoby pewnie z jednej strony skonfigurować serwer news tak,
by artykuły przychodzące do pewnej grupy były przekazywane
bezpośrednio jednemu z programów typu mail, mailx, mh lub sendmail, w
drugą stronę natomiast - utworzyć odpowiedni "alias" pocztowy typu np.
"|/usr/lib/news/sendnews"
gdzie sendnews jest prostym skryptem dopisującym na początku nazwę
grupy i posyłającym dalej całość do programu 'inews', który przekaże
artykuł serwerowi.
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 -
rs...@uunet.uu.net), by otrzymać jego kopię. Dobrze jest także
skontaktować się ze mną (pod adresem tsur...@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 list...@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"
Teraz wypadałoby grupę 'pl.nowa.grupa' utworzyć za pomocą 'ctlinnd
newgroup pl.nowa.grupa y' (lub zgodnie ze składnią serwera news --
powyższy przykład jest dla serwera INN) i przetestować, czy poczta
wysyłana na adres pl-now...@serwer.news.pl trafia do newsow. Po
pierwsze - wysyłając email-a na ten adres, a jeśli cos nie działa -
testując ręcznie:
% cat > test.posting
From: użytko...@serwer.news.pl
To: pl-nowa-grupa
Message-ID: tes...@serwer.news.pl
Date: Mon, 1 Aug 1994, 12:00 MET
test
^D
% cat test.posting | /usr/local/news/bin/mail2news -npl.nowa.grupa -dlo
cal
(albo nagrać jakis list wysłany samemu sobie do pliku i probować go
przekazać do mail2news).
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.gru
pa -dlocal test
słowo 'test' (lub dowolne inne) na końcu jest konieczne z tego
względu, że mail2news przekazuje 'agentowi news' parametr '-h' oraz
wszystkie inne, których sam nie interpretuje (czyli '-h test') - inews
wymaga '-h' bez parametrów, dla rnews po '-h' musi wystąpić nazwa
'hosta' która zostanie zapisana w logach serwera. Pamiętać należy też
o tym, że o ile mail2news wykorzystujący inews może być uruchomiony
"niedaleko" serwera, to rnews da się uruchomić wyłącznie na serwerze,
albo na komputerze, który z serwerem news ma połączenie via UUCP.
Jeśli wszystko działa tak jak trzeba, pozostaje zapisać serwer news
jako subskrybenta listy dyskusyjnej: albo poprosić właściciela listy
by dopisał do niej adres pl-now...@serwer.news.pl, albo zrobić to
samemu, posyłając e-mail z adresu pl-nowa-grupa do listserwera. Jak
posłać maila z takiego adresu? O tym chyba wszyscy wiedzą, ale jakby
nie, to jako root (albo jeden z 'trusted users' sendmaila - np.
'news') należy wykonać:
# cat | /usr/lib/sendmail -fpl-now...@serwer.news.pl listserv@plear
n.edu.pl
From: pl-now...@serwer.news.pl
To: list...@plearn.edu.pl
sub nowa-lista "mail to news gateway at serwer.news.pl"
^D
W ciągu kilku lub kilkudziesięciu minut powinien się w newsach pojawić
pierwszy artykuł - z odpowiedzią serwera i informacją "You have now
subscribed to list nowa-lista" itd. Jeśli tak, to wszystko na
najlepszej drodze. Aby poustawiać wszystkie opcje dystrybucji jak
należy, poślij listserwerowi (ponownie z adresu
pl-now...@serwer.news.pl) list o treści:
set nowa-lista full
set nowa-lista noack
Pierwsza linia oznacza, że listserwer ma posyłać pełne nagłówki (a
więc włącznie z Message-ID), druga - że artykuły przesłane z serwera
news nie będą do niego ponownie wysyłane. Opcje powyższe działają
poprawnie w przypadku listserwerów bitnetowych oraz 'listproc-a', inne
listserwery mogą wymagać nieco innych komend, na przykład 'set
nowa-lista norepro' itp.
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-now...@serwer.news.pl plearn.edu.pl
(ostatnie 2 linijki w zasadzie powinny zmieścić się w jednej, ale dla
czytelności podzieliłem ja na dwie - TS). Argumenty podane dla
news2mail oznaczają że:
* (1 i 4) - poczta zostanie dostarczona na adres
nowa-...@plearn.edu.pl,
* (2 i 4) - w polu 'To:' będzie wpisane nowa-...@plearn.edu.pl,
* (3) - w polu 'Sender:' będzie wpisane pl-now...@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
Najlepiej oczywiście na początek zamiast adresów listserwera wpisać
własny i przetestować, czy artykuł wysłany w news trafia do e-maila
jak należy. Po wykonaniu 'ctlinnd reload newsfeeds' i wysłaniu
artykułu do news, albo od razu powinien on zostać dostarczony
email-em, albo zakolejkowany. Wówczas '/usr/lib/sendmail -q'
przyspieszy jego dostarczenie. No a gdy już okaże się, że artykuł
dotarł i wyglądał mniej więcej tak:
From news...@cyber.ict.pwr.wroc.pl Sat Aug 6 18:05:02 1994
Return-Path: <news...@cyber.ict.pwr.wroc.pl>
Received: from cyber by asic.ict.pwr.wroc.pl (4.1/SMI-4.1)
id AA14199; Sat, 6 Aug 94 18:05:01 +0200
Received: from NEWS GATEWAY by cyber with netnews
for ts@asic (ts@asic)
From: tsur...@sprocket.ict.pwr.wroc.pl (Tomasz Surmacz)
Message-Id: <320c32$e...@cyber.ict.pwr.wroc.pl>
Sender: news...@cyber.ict.pwr.wroc.pl
Subject: test news2mail
test news2mail - 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...@cyber.ict.pwr.wroc.pl asic
(tzn. miał właściwy adres From: oraz Sender:), to możemy zmienić
własny adres na adres listserwera, jeszcze raz wykonać 'ctlinnd reload
newsfeeds' i mieć nadzieję, że wszystko działa jak trzeba. Gdy już
grupa zostanie także utworzona na innych serwerach news, wystarczy
tylko przestawić dystrybucję w aliasie:
pl-nowa-grupa: /usr/local/news/bin/mail2news -npl.nowa.grupa -dlocal
na:
pl-nowa-grupa: /usr/local/news/bin/mail2news -npl.nowa.grupa -dworld
(lub w ogóle zlikwidować '-d' zakładając, że serwer nie dopisze
żadnej, a więc będzie szło w świat, ale lepiej to wówczas sprawdzić).
To wszystko...
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ą.
_________________________________________________________________
mail2news z użyciem procmaila
Problemem pojawiającym się po skonfigurowaniu mail2news w sposób
opisany w powyższym punkcie jest to, że wszelkiego rodzaju błędy w
dostarczaniu poczty trafiającej z newsów na listę dyskusyjną są
przesyłane z powrotem do bramki mail2news, a więc trafiają do grup
news. Aby tego uniknąć warto skorzystać z programu procmail i
odfiltrować takie listy wyrzucając je do /dev/null lub zapisując do
odpowiedniego pliku, ale nie wysyłając do news.
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
W katalogu tym tworzymy plik xxx.rc, mający za zadanie obsługiwać
bramkę grupy pl.xxx. Plik ten powinien być posiadany przez użytkownika
news:
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
Plik ten ma za zadanie odfiltrowywać całą pocztę pochodzącą od
użytkownika MAILER-DAEMON do pliku warning, a pozostałą pocztę
przekazywać do programu mail2news, wywoływanego z odpowiednimi
parametrami (zostały one omówione w poprzednim punkcie). Informacja o
każdym liście zostaje zapisana w pliku from. Taka konfiguracja
przydatna jest do testowania działania bramki. Po sprawdzeniu
działania lepiej jest skierować listy od demona do /dev/null, wpisując
taką właśnie nazwę zamiast `warning', podobnie można także postąpić z
logiem z pracy procmaila, czyli plikiem from. Alternatywne wyjście, to
uruchomienie wykonywanego raz dziennie lub raz na tydzień z cron-a
skryptu, który będzie kasował zawartość tych plików, jako że
pozostawione całkiem bez nadzoru rosłyby ciągle, zajmując coraz więcej
miejsca na dysku.
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.r
c"
_________________________________________________________________
Newsfeed przez uucp
0. Dlaczego?
Internetowy protokół transferu news NNTP, oprócz wielu zalet, ma też
wady.
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ł
...
Taki synchroniczny sposób przesyłania artykułów po jednym oznacza, że
szybkość transferu news może być znacznie mniejsza od pasma linii
łączącej nadawcę z odbiorcą, zwłaszcza jeśli komputery połączone są
linią satelitarną lub jeśli komputer-odbiorca jest na tyle wolny, że
dużo czasu zajmuje mu sprawdzenie, czy dany artykuł już ma. W bardzo
poważny sposób można to poprawić stosując tzw. "streaming nntp", co
oznacza, że nadawca pcha strumień newsów nie czekając na
natychmiastowe potwierdzenia, lecz uzyskując je nieco później. Do tego
trzeba jednak nowszej wersji INND (innd1.4unoff2 już to ma).
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.
Wady te są jednak w wielu przypadkach z nawiązką rekompensowane
zaletami.
_________________________________________________________________
I. Konfiguracja uucp
Standardowe UUCP
Poniżej opisana jest konfiguracja standardowego UUCP w SunOS 4.1.x, na
innych powinno być podobnie. Konfiguracja z użyciem Taylor UUCP w
następnym punkcie
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/rn
ews
(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
Zakładamy, tak jak poprzednio, że łączymy ze sobą komputery
alfa.aaa.aaa (uuname - AAA.aaa) i omega.zzz.zzz (site name ZZZ.zzz).
Instrukcje dotyczą alfy, na omedze wszystko tak samo, tylko odwrotnie.
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 uuci
so -s -l
lub jeśli stosowany jest pakiet tcp_wrappers:
uucp stream tcp nowait uucp /usr/etc/tcpd /usr/local/lib/uu
cp/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 da
ys, 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
Wszystkie operacje jako user news.
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
_________________________________________________________________
III. Konfiguracja C News do odbierania batchów
Uruchamiany przez uucp program rnews nagrywa nadchodzące paczki w
katalogu /usr/spool/news/in.coming. Aby zostały one skonsumowane przez
C News, należy dokonać - do wyboru - jednej z dwóch operacji:
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
2. 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/n
ull 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 -s100
000 -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.
Nic nie trzeba robić - wszystko jest "wbudowane" standardowo. Należy
jedynie zadbać, by w /bin/rnews znalazł się program rnews z
dystrybucji innd, oraz mimo wszystko do crontab-a użytkownika news
dopisać jednak następującą linijkę:
7 0,6,12,18 * * * /bin/rnews -U
a więc raz lub kilka razy dziennie uruchamiać program rnews z pakietu
INND. Opcja '-U' powoduje, że rnews nie szuka batchów na wejściu, lecz
przeszukuje katalog /usr/spool/news/in.coming . W normalnych warunkach
nie jest to konieczne, natomiast przydaje się w sytuacjach awaryjnych,
gdy z jakiegoś powodu serwer przestaje przyjmować newsy (np. padł,
albo się zapchał), wtedy batche UUCP (oraz newsy dostarczane przez
mail2news) trafiają właśnie do /usr/spool/news/in.coming. Serwer sam
przeszukuje ten katalog podczas uruchamiania, ale nie podczas
odblokowywania (ctlinnd go ''), jeśli był zapchany. Dlatego dobrze
jest rnews uruchamiać także z crontab-a.
_________________________________________________________________
Kompresowanie batchów przy pomocy gzip
Standardowy sposób kompresji programem 'compress' nie jest zbyt
wydajny. Dlatego, jeśli już mamy działający feed batchowy, proponuję
uruchomienie kompresjii za pomocą programu 'gzip'. Oczywiście, obie
strony muszą się umowić, że bedą tego programu używały, dlatego nie
radzę tego zmieniać globalnie, a tylko osobno dla każdego feedu. Można
najpierw skonfigurować dekompresję po stronie odbierającej bez zmian u
nadawcy, gdyż gzip rozumie formaty .gz (gzip - ale nie zip!), .Z
(stary compress) i .z (jeszcze starszy pack).
_________________________________________________________________
I. Konfiguracja C News do nadawania z kompresją gzip
1. Stworzyć nowy skrypt kompresujący batche, pod nazwą
/news/lib/newsbin/batch/gzipcun
#! /bin/sh
# Invoke gzip, adding silly 2.11-compatible header.
echo "#! cunbatch"
gzip
(pamiętać, żeby zrobić 'chmod +x /news/lib/newsbin/batch/gzipcun')
2. W pliku batchparms zmienić compcun na gzipcun
_________________________________________________________________
II. Konfiguracja C News do odbierania z dekompresją gzip
1. Poprawić program ../input/newsspool.c
_________________________________________________________________
*** newsspool.c.orig Tue Nov 26 16:52:21 1991
--- newsspool.c Mon Oct 17 19:05:03 1994
***************
*** 31,36 ****
--- 31,37 ----
char *progname;
extern void error(), exit();
+
#ifdef UTZOOERR
extern char *mkprogname();
#else
***************
*** 237,246 ****
# define GOOP7LEN (sizeof(goop7)-1) /* strlen(goop7) */
static char suf7[] = ".7";
static char comp[2] = { 037, 0235 }; /* compress's magic no. */
register char *p;
register int nleft;
# define MINCBATCH 5 /* one character, compressed */
!
nleft = count;
p = bufp;
--- 238,249 ----
# define GOOP7LEN (sizeof(goop7)-1) /* strlen(goop7) */
static char suf7[] = ".7";
static char comp[2] = { 037, 0235 }; /* compress's magic no. */
+ static char gzip[2] = { 037, 0213 }; /* gzip's magic no. */
+ static char sufg[] = ".gz";
register char *p;
register int nleft;
# define MINCBATCH 5 /* one character, compressed */
! # define MINCGZIP 21 /* one character, gzipped */
nleft = count;
p = bufp;
***************
*** 254,259 ****
--- 257,269 ----
return(0);
}
+ if (p[0] == gzip[0] && p[1] == gzip[1]) { /* gzipped */
+ if (nleft < MINCGZIP)
+ return(count);
+ suffix = sufg;
+ return(0);
+ }
+
if (*p++ != '#' || *p++ != '!') /* doesn't start with #! */
return(0);
nleft -= 2;
***************
*** 268,274 ****
if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
p += GOOPLEN;
nleft -= GOOPLEN;
! suffix = suf;
} else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
p += GOOP7LEN;
nleft -= GOOP7LEN;
--- 278,287 ----
if (nleft >= GOOPLEN+1 && STREQN(p, goop, GOOPLEN)) {
p += GOOPLEN;
nleft -= GOOPLEN;
! if (p[1] == gzip[0] && p[2] == gzip[1]) /* gzipped */
! suffix = sufg;
! else
! suffix = suf;
} else if (nleft >= GOOP7LEN+1 && STREQN(p, goop7, GOOP7LEN)) {
p += GOOP7LEN;
nleft -= GOOP7LEN;
_________________________________________________________________
Skompilować i zainstalować jako /news/lib/newsbin/input/newsspool
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
_________________________________________________________________
W zasadzie wystarczy dodać linijkę z .gz, ale traktowanie plików .Z
programem gunzip nie zaszkodzi, za to umożliwia poprawne działanie
nawet, jeśli nie chciało nam się przerabiać programu newsspool.
_________________________________________________________________
III. Konfiguracja INN do nadawania z kompresją gzip
Proponuję dodać nową opcję do skryptu /usr/local/news/bin/sendbatch
_________________________________________________________________
*** sendbatch.orig Thu Oct 27 23:29:30 1994
--- sendbatch Thu Oct 27 23:31:54 1994
***************
*** 14,19 ****
--- 14,21 ----
COMP=
COMPFLAGS=
COMPRESS=/usr/ucb/compress
+ GZIP=/usr/local/bin/gzip
+ GZIPFLAGS=
ECHO=
## Not a config param since this is the remote rnews.
RNEWS=rnews
***************
*** 75,80 ****
--- 77,87 ----
-c)
COMP="; exec ${COMPRESS} ${COMPFLAGS}"
ECHO="echo '#! cunbatch'"
+ continue
+ ;;
+ -cg)
+ COMP="; exec ${GZIP} ${GZIPFLAGS}"
+ ECHO="echo '#! cunbatch'"
continue
;;
+c)
_________________________________________________________________
W wywołaniu sendbatch (cron) zmienić -c na -cg
_________________________________________________________________
IV. Konfiguracja INN do odbierania z dekompresją gzip
Trzeba zmienić w pliku config/config.data w źródłach INN
_PATH_COMPRESS /usr/ucb/compress
_PATH_COMPRESSEXT .Z
na
_PATH_COMPRESS /usr/local/bin/gzip
_PATH_COMPRESSEXT .gz
lub podobnie. Potem niestety trzeba przekompilować (make update) i na
nowo nagrać programy INN. Jeśli nagramy wszystkie z tą poprawką, to
całe INN bedzie odtąd używalo gzip do kompresji log-files itp.
(Gdzieniegdzie jest to tak właśnie zrobione "standardowo"). Jeśli
chodzi nam tylko o to, żeby rnews rozumiało batche kompresowane przez
gzip, to wystarczy zainstalować na nowo tylko program rnews.
_________________________________________________________________
UUCP 'pośrednie' (czyli jak wykonać cyber!papaja!rnews)
Spotykanym czasem problemem związanym z rozsyłaniem news jest jak
wysłać newsy z serwera za pomocą UUCP do systemu, z którym serwer nie
ma bezpośredniego łącza UUCP (np. na serwerze news nie ma modemu, a
newsy trzeba przesyłać przez telefon). Przykładowa sytuacja
zilustrowana jest poniżej.
uucp/tcpip uucp/modem
news <------------> cyber <----- - - - - -----> papaja
serwer news
'papaja' oznacza system, na którym chcemy odbierać newsy, a który
łączy się z systemem 'cyber' przez modem, używając protokołów UUCP.
cyber i news też mają połączenie UUCP, ale oparte o TCP/IP, gdyż oba
znajdują się w sieci lokalnej. Problem polega na takim ustawieniu
systemów, by na serwerze news generować batche dla komputera papaja, i
aby docierały one poprawnie na miejsce.
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
a więc np. "uux - -gd -n cyber!papaja!rnews". Aby taką komendę
zdefiniować, wystarczy utworzyć plik o nazwie
'/var/news/out.going/${SITE}.cmd', a więc np.
/var/news/out.going/papaja.cmd, a w nim wpisać odpowiednią komendę
'uux' (podaną wyżej). Tworzone w ten sposób batche przeznaczone będą
(ostatecznie) dla systemu papaja, ale ich transfer nastąpi na system
cyber i dopiero stamtąd trafią we właściwe miejsce.
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 ${INTERMEDIA
TE_SITE}!${SITE}!rnews
Zamiast /usr/bin/compress można oczywiście użyć programu gzip, o ile
tylko system docelowy potrafił będzie takie batche rozpakować.
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.
_________________________________________________________________
Inne możliwości przyspieszenia transmisji News
Jeżeli największym problemem są opóźnienia, a nie przepustowość linii,
to prostym tymczasowym rozwiązaniem może byc podział feedu na dwa lub
więcej i wysyłanie ich jako osobnych, równolegle działających feedów.
Inne zastosowanie feedów równoległych, a właściwie drabinkowych, to
poprawienie niezawodności. Jednak w przypadku zrównoleglenia feedów w
układzie dwa komputery po jednej stronie kabla wysyłające do dwóch po
drugiej stronie, zwiększa się nieco ilość duplikatów. Warto też
zwrocić uwagę na maksymalny czas przesyłania news przez nntpsend
(opcja -T, omówiona wcześniej) oraz godziny startowania batchów
wysyłających newsy.
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...
_________________________________________________________________
Część pierwsza FAQ - ogólne informacje o grupach pl.*
Część druga FAQ - konfigurowanie serwerów news
Część trzecia FAQ - Lista istniejących grup pl.*
Część czwarta FAQ - Formularz głosowania nad nowymi grupami pl.*
FAQ po angielsku dla administratorów serwerów news poza Polską
_________________________________________________________________
22.12.2003
UUCP:
Michał Jankowski (Michal.J...@fuw.edu.pl,
mic...@adm.usenet.pl)
Rafał Maszkowski (r...@oso.chalmers.se,
http://www.mat.uni.torun.pl/~rzm)
Konfiguracja serwera, Taylor UUCP, wersja HTML całości:
Tomasz Surmacz (tsur...@ict.pwr.wroc.pl,
tsur...@adm.usenet.pl)
RCS ID: $Id: news-pl-faq.2.htpl,v 2.21 2003/12/22 03:08:37 ts Exp ts $
_________________________________________________________________
[This site is vi powered!] (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 tsur...@adm.usenet.pl - może
poprawię.