inn+suck - instalacja. inn+suck - instalacja. Rafał Czeczótkav4.11, 18 sierpień 2000 Tekst ten opisuje procedurę instalacji lokalnego serwera news (inn), sposób wymiany postów (suck) oraz metodę kompresji newsów w drodze (ssh). Oryginał tego dokumentu można znaleźć na stronie www.amg.gda.pl/~michu/linux.html. Zostało użyte kodowanie ISO-8859-2. 1. Wstęp 1.1 Przedmowa Impulsem do napisania tego tekstu były moje początkowo nieudane próby instalacji oraz nikły odzew na moje posty na grupie pl.comp.os.linux (pewnie jak zwykle moje zapytania zaginęły gdzieś w potoku informacji i zapytań docierających tu codziennie). Nie mam zamiaru pretendować do miana fachowca od konfiguracji serwerów news (po prostu u mnie już to działa), tym nie mniej mam nadzieję, że opis działającej konfiguracji będzie dla kogoś przydatny. Całą treść tego dokumentu stanowi opis mojej instalacji duetu inn+suck w systemie RedHat 6.2, w oparciu o pakiety inn-2.2.2-3 i suck-4.2.2-1. Jeśli dysponujesz inną wersją systemu i/lub pakietów to mogą występić pewne różnice w konfiguracji, mniemam jednak, że nie powinno to stanowić najmniejszego problemu już dla średnio zaawansowanego miłośnika Linux'a. Wszelkie sugestie i poprawki są mile widziane i należy je wysyłać pod adres [e-mail]. Jestem skory do pomocy, proszę jednak o uszanowanie mojego czasu i nie wysyłanie mi listów o lakonicznej treści typu "nie działa mi, CO ROBIĆ???" czy magabajtowych załączników z konfiguracją. Jeśli widzisz, że nic Ci nie wychodzi, to sprawdź czy wykonałeś dokładnie wszystkie kroki (z dokładnością do różnych wersji pakietów/dystrybucji). Jeśli po paru podejściach nadal masz poważne problemy, to lepiej na razie sobie odpuść i spróbuj ponownie za jakiś czas. W tym dokumencie w paru miejscach porównuję inn'a do leafnode'a, którego wcześniej używałem. 1.2 Podziękowania Następujący ludzie przyczynili się do powstania tego dokumentu, taką czy inną drogą, świadomie lub nieświadomie (w kolejności alfabetycznej): Ariadna - wyjechała służbowo na dwa tygodnie, dzięki czemu mogłem m.in. spokojnie spłodzić ten dokument ;-) oraz po powrocie poprawiła wiele literówek (kobiety bywają czasem przydatne :-) Andrzej Radecki ([e-mail]) - podał sposób czytania lokalnego archiwum, Bartosz Maruszewski z JTZ ([e-mail]) - nadesłał dołączony skrypt do dodawania zasubscribowanych grup do inn'a, wspierał mnie moralne (z czego pewnie nie zdawał sobie sprawy :) oraz przekodował ten dokument do SGML, Jacek Czerwiński ([e-mail]) - podał rozwiązanie likwidujące problem odsyłania postów, Jakub Bogusz ([e-mail]) - podał jeszcze jeden sposób, w jaki można rozwiązać problem odsyłania postów, Krzysztof Zietara ([e-mail]) - rozwiązał problem ze ściąganiem (a raczej jak ich nie ściągać) grup control, control.cancel, junk, test i to oraz nadesłał inne uwagi, Maciej Miechowicz ([e-mail]) - dokonał przełożenia niniejszego tekstu na język angielski, Marcin Kasperski ([e-mail]) - dodał parę uwag dotyczących instalacji na Debian'ie, wymiany postów z wieloma serwerami oraz podesłał całą sekcję na temat grup moderowanych, Michal Kaczmarek ([e-mail]) - podał kilka istotnych uwag, Michał Tyrała ([e-mail]) - pomógł w rozwiązaniu problemów z wpuszczaniem postów do inn'a przy transferze z kompresją oraz nadesłał odpowiedni skrypt, Radosław Gancarz ([e-mail]) - rozwiązał problemy z odrzucaniem niektórych postów (zmiany w newsfeeds), Tomasz Sienicki ([e-mail]) - podał ciekawego URL'a związanego z tematem, Tomasz Szymczak ([e-mail]) - podał sugestię dotyczącą opcji -M w suck'u, Inni, nie wymienieni z nazwiska, zwrócili uwagę na parę drobnych niedomówień, niedociągnięć, potknięć i nieścisłości. 2. Słowo o programach, instalacja i konfiguracja 2.1 Co to jest inn i suck Inn jest to "InterNetNews daemon" czyli program umożliwiający wielu użytkownikom korzystanie z zasobów news. Suck jest to zasysacz newsów; pośredniczy on w wymianie newsów pomiędzy dwoma serwerami: naszym i zdalnym (emulując zachowanie normalnego czytnika; protokół wymiany postów pomiędzy serwerami (wbudowany w inn'a) odbywa się na trochę innej zasadzie i wymaga specjalnej konfiguracji po obu stronach, czego chcemy uniknąć). 2.2 Kiedy instalować inn+suck Jeśli uważasz, że spełnione są poniższe warunki: Nudzi Ci się i potrzebujesz jakiejś odmiany (warunek konieczny, bo przecież tak naprawdę jeśli potrzebujesz lokalnego serwera newsów, to z pewnością wystarczy Ci dużo prostszy w konfiguracji i używaniu leafnode, poza tym ten eksperyment może Cię kosztować sporo czasu i nadszarpniętych nerwów), Z newsów na twoim komputerze korzysta więcej niż jeden użytkownik (bo dla jednego usera zupełnie wystarczające są rozwiązania typu rtin -SQ) ewentualnie "twój" komputer służy jako serwer news dla całej sieci (np. w firmie), Możliwości leafnode'a już Ci nie wystarczają (potrzebujesz killfile'i, różnych ograniczeń na ściąganą pocztę newsową, ...), Ściąganie newsów trwa u Ciebie zbyt długo i potrzebujesz ich kompresji, to znaczy, że powinieneś zainstalować duet inn+suck. Jeśli już będziesz chciał zainstalować to oprogramowanie, to będą Ci potrzebne następujące (lub inne wersje) pakiety: cleanfeed (np. cleanfeed-0.95.7b-7, wymagany tylko w RedHat, aby spełnić zależności RPM'a), inn (np. inn-2.2.2-3), perl-MD5 (np. perl-MD5-1.7-2, podobnie jak cleanfeed wymagany tylko w RedHat), suck (np. suck-4.2.2-1). 2.3 Wady i zalety tego rozwiązania Zalety inn+suck: Szybki (piekielnie), Znaczne możliwości (killfile, ...), choć tu należy raczej patrzeć na możliwości suck'a (ponieważ dopiero po ściągnięciu pliki są przesyłane do inn'a a jak coś już w całości przeszło przez modem, to moim zdaniem niech już zostanie), Można tak skonfigurować inn+suck, że newsy są ściągane skompresowane, czyli czas transmisji można skrócić parokrotnie, Można grep'ować pliki z zawartością grup bez żadnych "skutków ubocznych" (ta uwaga odnosi się do dużo prostszego leafnode'a, gdzie czas do expire jest liczony od daty ostatniego dostępu do pliku, więc jeśli "to się zrobiło", to czas ten oczywiście przedłużał się), Instalując ten serwer jesteś "wśród najlepszych" (większość dużych serwerów news działa właśnie na inn'ie). Wady inn+suck: Dość pogmatwana konfiguracja i hermetyczna dokumentacja (przynajmniej na początek) ale ten dokument powstał właśnie aby wyeliminować tę niedogodność, Pamięciożerność: Proces innd cały czas pozostaje w pamięci (leafnode wywoływany jest "na żądanie"), Na dysku zajmuje więcej miejsca niż leafnode (choć jest to do przyjęcia). 2.4 Podstawowa instalacja i konfiguracja UWAGA!!! W zależności od dystrybucji i wersji pakietów wymienione poniżej pliki konfiguracyjne mogą występować w innych katalogach (np. /var/lib/suck/, /usr/lib/suck/, /etc/suck/, ...). Proces instalacji i "konfiguracji" jest prosty (przynajmniej do pierwszego "ruszenia", ale o tym, bez tego wstępu, przeciętny zjadacz newsów możne przekonać się dopiero po parodniowych dociekaniach): Zainstalować inn i suck (i jeszcze parę wymienionych wcześniej drobiazgów), UWAGA!!! Ponieważ inn bardzo źle znosi wszelkie zmiany atrybutów plików (jest to przyczyna większości niepowodzeń), najlepiej je gdzieś zapisać: ----- ciach ----- ls -ld `rpm -ql inn` > ~/jakiś_plik_z_atrybutami ----- ciach ----- a wszelkie operacje wykonywać jako użytkownik news. W pliku /etc/news/newsfeeds dodać własną sekcję z feeds, tj.: ----- ciach ----- ... news.task.gda.pl\ :!junk,!test,!to\ :Tf,Wnm: ... ----- ciach ----- gdzie news.task.gda.pl to nazwa mojego serwera news, oraz do definicji dystrybucji akceptowanych przez nasz serwer dodać polską: ----- ciach ----- ... ME\ :*,!junk,!control*,!local*,!foo.*\ /pl,world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\ :: ## ^^ - to jest to pl ... ----- ciach ----- W pliku /var/lib/suck/get.news.inn (w Debiani'e jest to plik /etc/suck/get-news.conf) wstawić nazwę serwera news (np. REMOTE_HOST=news.task.gda.pl) oraz "sajtu" (tego samego co przy definicji feed'u, tj. SITE=news.task.gda.pl), W suck'u w pliku /var/lib/suck/sucknewsrc zapisać wszystkie interesujące nas grupy i numery postów, od których ma się zacząć "ściąganie", np. aby ściągnąć ostatnich 100 postów należy podać: ----- ciach ----- ... pl.comp.ogonki -100 pl.comp.os.linux -100 ... ----- ciach ----- Jeśli istnieją pliki /etc/cron.daily/inn-cron-rnews oraz /etc/cron.hourly/inn-cron-nntpsend, to należy je usunąć (ich funkcje przejmuje suck), Jeśli w pliku /etc/news/nnrp.access nie ma wpisu localhost: to należy go dodać, Teraz możemy już wystartować serwer np. poleceniem /etc/rc.d/init.d/innd start. Można/trzeba także dodać odpowiednie linki do katalogów /etc/rc.d/rc[0-6].d/ (np. poleceniem ntsysv), Dodać grupy do inn'a. Można to zrobić ręcznie poleceniem ctlinnd newgroup nazwa.grupy lub skorzystać z poniższego skryptu: ----- ciach ----- #!/bin/bash # # Ten skrypt tworzy automatycznie grupy w inn'ie, które podałeś w pliku # /var/lib/suck/sucknewsrc - konfiguracyjnym dla suck-a. # UWAGA !!! # Wymagany format tego pliku to: ############################ # nazwa.grupy numer.artykulu ############################ # # Możesz podać inna lokalizacje SUCK_FILE=/var/lib/suck/sucknewsrc # # Podaj ścieżkę do programu ctlinnd. Skrypt spróbuje sam zgadnąć, ale # lepiej podaj jak wiesz. CTLINND=`which ctlinnd` cat ${SUCK_FILE} | while read ln; do set -e $ln >/dev/null ${CTLINND} newgroup $1 if [ $? -eq 1 ]; then echo Błąd podczas zakładania grupy $1 !!! exit fi done ----- ciach ----- Aby nie ściągać grup control, control.cancel, junk, test ani to (z pewnością nam się nie przydadzą), musimy stworzyć plik /var/lib/suck/get.news.inn: ----- ciach ----- control control.cancel junk test to ----- ciach ----- Oczywiście grup tych nie należy umieszczać w pliku /var/lib/suck/sucknewsrc, Wymianę newsów ze zdalnym serwerem inicjujemy skryptem /var/lib/suck/get.news.inn (lub /var/sbin/get-news na Debian'ie), Aby czytać newsy musimy ustawić zmienną środowiskową NNTPSERVER. Dla bash'a będzie to komenda: export NNTPSERVER=localhost 2.5 Kompresja newsów w drodze Ponieważ newsy są danymi tekstowymi, więc ich kompresja zdecydowanie skraca czas transmisji, dzięki czemu z pewnością zaoszczędzimy trochę pieniędzy kosztem naszego operatora telekomunikacyjnego (pieniądze te mogą być wysłane do autora powyższego tekstu, za ewentualne straty autor oczywiście nie bierze żadnej odpowiedzialności ;-). Osobiście wydaje mi się, że przedstawione tu rozwiązanie jest najbardziej naturalne i elastyczne. Nie oznacza to oczywiście, że nie można tego zrobić lepiej. Podczas eksperymentów okazało się także, że zwykłe tunelowanie komunikacji w skompresowanym kanale ssh nie daje oczekiwanych rezultatów, stąd wyniknęła potrzeba wywołania suck'a na zdalnym komputerze (po prostu komunikacja pomiędzy komputerami jest na tyle duża, że po uwzględnieniu opóźnień występujących w trakcie transferu, niemal całkowicie niweczony jest efekt zmniejszonej objętości danych). Opisując poniższe rozwiązanie zakładam, że masz już poprawnie zainstalowane i skonfigurowane pakiety inn+suck. Aby z niego korzystać niezbędne nam także będą: na domowym komputerze musi być zainstalowny klient ssh, musimy mieć dostęp do konta na zdalny komputerze z zainstalowanym systemem Unix'opodobnym, podłączony w miarę szybkim łączem stałym do internetu, z zainstalowanym suck'iem oraz uruchomionym demonem ssh. Cała przedstawiona poniżej idea opiera się na możliwości uruchomienia suck'a na zdalnym komputerze tak, aby wiadomości były wysyłane w postaci strumienia danych, który jest przesyłany w skompresowanym kanale ssh (opcja -C). Dopiero później, lokalnie, za pomocą skryptu filter2rnews, strumień ten jest dzielony na poszczególne wiadomości, które są wpuszczane za pomocą programu rnews do lokalnego serwera innd. W tym celu musimy: Usunąć z pliku /var/lib/suck/get.news.inn całą sekcję służącą do ściągania wiadomości, czyli skrypt ten powinien być postaci: ----- ciach ----- #!/bin/sh #BEFORE USING - check to ensure all the paths defined below are correct!! #NOTE: this script probably needs to be run by root. Most systems will # not let a normal user run ctlinnd REMOTE_HOST=news.task.gda.pl LOCAL_HOST=localhost SPOOLDIR=/var/spool/news/articles # base directory for articles to be rposted NEWSDIR=/usr # base directory for news binaries BASEDIR=/var/lib/suck # base directory for scripts and data files CTLINND=${NEWSDIR}/bin/ctlinnd # location of binary SHLOCK=${NEWSDIR}/bin/shlock # location of binary TMPDIR=${BASEDIR} # location for suck.* files MSGDIR=${BASEDIR}/Msgs # where to put MultiFile messages when getting them SITE=news.task.gda.pl # name of site from newsfeeds file OUTGOING=${SPOOLDIR}/../outgoing/${SITE} # location of the list of articles to upload OUTGOINGNEW=${OUTGOING}.new # file to contain the list temporarily OUTGOINGFAIL=${OUTGOINGNEW}.fail # file with failed xfers SCRIPT=${BASEDIR}/put.news # my filter for rpost OUTFILE=/tmp/tmp$$ # used by rpost as article after it is filtered LOCKFILE=${BASEDIR}/getnews.lock # lock file to prevent multiple instances of script NEWSGROUP=news # which group owns the file in out.going, typically either news or uucp. TESTHOST=testhost RPOST=rpost SUCK=suck HISTORY=/var/lib/news/history # location of history file # if we are already running, abort trap 'rm -f ${LOCKFILE} ; echo "Aborting" ; exit 1' 1 2 3 15 ${SHLOCK} -p $$ -f ${LOCKFILE} if [ $? -ne 0 ]; then echo "Already running, can't run two at one time" exit fi # now upload messages if [ -s ${OUTGOING} -o -s ${OUTGOINGNEW} ]; then ${TESTHOST} ${REMOTE_HOST} -s if [ $? -ne 0 ]; then echo "Remote posting host not responding" else # this is needed by INND so that the outgoing file will be # properly flushed and we have a new blank file to work with # when we are done # First mv the current one to a new file name # Since innd already has the file open, it doesn't care # about the rename. # The flush will ensure that all messages to be posted have # been written out, close off the old one (already renamed) # and create a new one. # if the outgoingnew already exists, it means we aborted last time # so don't try to do it again if [ ! -s ${OUTGOINGNEW} ]; then mv ${OUTGOING} ${OUTGOINGNEW} ${CTLINND} flush ${SITE} fi # outgoing messages to post ${RPOST} ${REMOTE_HOST} -d -b ${OUTGOINGNEW} -p ${SPOOLDIR} -f \$\$o=${OUTFILE} ${SCRIPT} \$\$i ${OUTFILE} ERRLEV=$? if [ ${ERRLEV} -eq 0 ]; then echo "Remotely posted articles" rm ${OUTFILE} elif [ ${ERRLEV} -eq 1 ]; then echo "Error posting a message" elif [ ${ERRLEV} -eq 2 ]; then echo "Unable to do NNTP authorization with remote server" elif [ ${ERRLEV} -eq 3 ]; then echo "Unexpected answer from remote server to a command while doing NNTP authorization" elif [ ${ERRLEV} -eq -1 ]; then echo "Fatal error" fi if [ -f ${OUTGOINGFAIL} ]; then mv ${OUTGOINGFAIL} ${OUTGOINGNEW} # so we can re do it chown news.${NEWSGROUP} ${OUTGOINGNEW} chmod 664 ${OUTGOINGNEW} fi fi echo "You can hang up the modem now" fi rm -f ${LOCKFILE} ----- ciach ----- Oczywiście należy pamiętać o właściwym ustawieniu zmiennych REMOTE_HOST i SITE. Skopiować z lokalnego katalogu /var/lib/suck/ pliki active-ignore, suck.killlog, suckkillfile oraz sucknewsrc do zdalnego katalogu $HOME/suck/ (jeśli nie jest tam zainstalowany suck, a tamta maszyna ma taką samą architekturę jak nasza, to możemy skopiować tam także program /usr/bin/suck). Stworzyć możliwość logowania się na zdalnym komputerze za pomocą ssh bez użycia hasła (tylko na podstawie znajomości klucza RSA): wygenerować parę kluczy RSA komendą ssh-keygen (w pass phrase nie podawać hasła), następnie skopiować plik $HOME/.ssh/identity.pub na zdalny komputer do pliku $HOME/.ssh/authorized_keys. UWAGA!!! Należy zdawać sobie sprawę z tego, że mimo, iż takie rozwiązanie jest o wiele bezpieczniejsze od logowania się za pomocą hasła, to krytyczną rolę dla bezpieczeństwa odgrywa tutaj nie ujawnianie zawartości pliku $HOME/.ssh/identity, czyli prywatnej połowy klucza. Istnieje także rozwiązanie umożliwiające wygenerowanie klucza z hasłem i podawanie go tylko raz na sesję (patrz program ssh-agent). Utworzyć skrypt /usr/local/bin/filter2rnews: ----- ciach ----- #!/usr/bin/perl -w while (not eof STDIN) { @POST = (); while (<>) { last if /^\.$/; push @POST, $_; } $dlug = length(join('',@POST)); print "#! rnews $dlug\n"; print @POST; } ----- ciach ----- Po dokonaniu wszystkich powyższych kroków możemy już pobierać newsy komendą: ----- ciach ----- ssh -C -l username serwer.name \ '~/suck/suck news.task.gda.pl -dd ~/suck -dt ~/suck -M -c' | \ filter2rnews | rnews -N -vvv -S localhost ----- ciach ----- gdzie username to nazwa użytkownika na komputerze serwer.name a news.task.gda.pl jest nazwą naszego serwera news. Wiadomości wysyłamy tak jak poprzednio, czyli za pomocą skryptu /var/lib/suck/get.news.inn. Pomocnym będzie uaktualnienie bazy overview (rnews nie robi tego automatycznie): ----- ciach ----- su news -c 'expireover -s -a' ----- ciach ----- 2.6 CNFS Krótka chrakterystyka CNFS Domyślnie inn skonfigurowany jest w taki sposób, że artykuły przechowywane są w postaci oddzielnych plików, w strukturze katalogów odpowiadającej pozycji grupy w hierarchii. Podstawową zaletą tego rozwiązania jest prostota oraz wynikająca z niej łatwość tworzenia rozwiązań pomocniczych. Jednak taki sposób przechowywania ma co najmniej dwie poważne wady. Pierwszą jest to, że artykuły przechowywane są z użyciem mechanizmów systemu operacyjnego, które to nie są zoptymalizowane do obsługi wielu plików o małym rozmiarze, konsekwencją czego jest wolny dostęp i duża ilość zmarnowanego miejsca. Drugą wadą jest to, że nigdy nie wiemy, jak dużo miejsca będą nam zajmowały newsy, co grozi przepełnieniem partycji. Wymienione powyżej niedogodności tradycyjnego przechowywania plików eliminuje CNFS (Cyclic News File System). Ten sposób przechowywania artykułów polega na tym, że zapisywane są one w pliku o specjalnym formacie. Gdy skończy się miejsce, nowe artykuły automatycznie nadpisują najstarsze. Rozwiązanie takie jest bardzo szybkie i nie grozi nam już przepełnienie partycji. Jedyną jego wadą jest to, że teraz utrudniony jest "samodzielny" dostęp do pojedynczych artykułów. Instalacja i konfiguracja CNFS Aby zainstalować CNFS należy (wszystkie te czynności oczywiście najlepiej wykonać jako użytkownik news): W pliku /etc/news/inn.conf ustawić opcję storageapi na on, W pliku /etc/news/newsfeeds: Wyrzucić wpis crosspost:..., Zmienić wpis overview na: ----- ciach ----- overview!:*:Tc,Ao,WhR:/usr/bin/overchan ----- ciach ----- W pliku /etc/news/cycbuff.conf umieścić definicję naszego bufora cyklicznego, np.: ----- ciach ----- cycbuff:ONE:/var/spool/news/one:131072 metacycbuff:BIGAREA:ONE ----- ciach ----- gdzie ONE jest symboliczną nazwą bufora, /var/spool/news/one jest plikiem bufora, 131072 rozmiarem bufora a BIGAREA jest nazwą metabufora cyklicznego, W /etc/news/storage.conf definiujemy jakie artykuły mają być przechowywane w buforze. Ponieważ my mamy tylko jeden bufor, gdzie powinny znaleźć się wszystkie artykuły, to u nas ten plik będzie wyglądał następująco: ----- ciach ----- method cnfs { newsgroups: * class: 1 size: 0,1000000 options: BIGAREA } ----- ciach ----- Z poziomu shell'a tworzymy bufor zdefiniowany w pliku /etc/news/cycbuff.conf: ----- ciach ----- dd if=/dev/zero of=/var/spool/news/one bs=1k count=131072 chmod 0664 /var/spool/news/one ----- ciach ----- Ponieważ teraz do treści artykułów nie dostaniemy się przez nazwę pliku (np. komendą cat) lecz token (program sm), to musimy w konfiguracji suck'a: W skrypcie /var/lib/suck/get.news.inn usunąć w wywołaniu rpost'a parametr -p nazwa_katalogu, Zamienić skrypt put.news na put.news.sm (powinien być w przykładach lub źródłach), I możemy zaczynać ściągać news'y. Podstawowe różnice Podstawową różnicą w stosunku do standardowego sposobu przechowywania artykułów jest to, że nie ma potrzeby ich expirowania, teraz dzieje się to automatycznie, bez naszej pomocy (czasem być może wbrew naszej woli ;-). Inną konsekwencją jest to, że pewne czynności wykonuje się w zupełnie inny sposób. Np. do odtworzenia bazy overview należy zamiast komendy expireover używać komendy expireindex (baza overview znajduje się teraz w katalogu /var/spool/news/uniover/). Ponieważ nie mamy teraz bezpośredniego dostępu do artykułów, czasem jest potrzeba wspomożenia się komendą makehistory (więcej informacji w manualach). 2.7 Grupy moderowane [ RCz: sekcja napisana w całości przez Marcina Kasperskiego ] W normalnej konfiguracji inn+suck grupy moderowane traktowane są tak samo, jak wszystkie pozostałe: wysyłane na nie artykuły trafiają od razu na lokalne grupy (bez akceptacji moderatora) i są wysyłane do serwera z którego pobieramy newsy. Dopiero ten serwer przesyła posty do moderatora. Sprawia to następujące problemy: nie wiemy, czy nasze posty naprawdę trafiły na grupę, czy nie (tj. czy moderator je zaakceptował czy odrzucił - i kiedy) jeśli wymieniamy suck'iem posty z kilkoma serwerami, możemy podpaść moderatorom bo będziemy wysyłać po kilka razy ten sam list (każdy z serwerów sforward'uje post do moderatora) część grup moderowanych jakoś nie jest dobrze obsługiwana (nie udało mi się przez tpnet wysłać listu na comp.lang.perl.moderated) jeśli z naszego hosta korzysta grupa osób, widzą one grupę inaczej niż pozostali, mogą wysyłać odpowiedzi zanim moderator zaakceptował pytanie itp. Problemy te możemy rozwiązać konfigurując grupy jako moderowane na naszym własnym serwerze. Wówczas inn nie będzie automatycznie umieszczał na grupie wysyłanych postów a zamiast tego wyśle je pocztą do moderatora. Zaakceptowane posty "spłyną" do nas kiedyś tam suck'iem - tak jak to się dzieje normalnie. W celu takiej konfiguracji należy (lokalizacje plików poniżej odpowiadają Debianowi): Tworzymy plik /etc/news/moderators z następującą treścią: # Uniwersalny adres moderatorów grup polskich pl.*:[e-mail] # Uniwersalny adres moderatorów grup światowych *:[e-mail] W pliku /etc/news/inn.conf ustawiamy fromhost na adres jakiejś maszyny widocznej w światowym DNS'ie (nasz host maskaradujący, nasz provider, my sami jeśli jesteśmy wbici). Najlepiej, jeśli jesteśmy w stanie czytać pocztę dostawaną przez konto news na tym hoście (listy które nie doszły) ale nie jest to zdaje się absolutnie konieczne. Przy konfiguracji poczty smarthost najlepiej nadaje się tu adres naszego serwera mailowego. Mój plik inn.conf zawiera pola organization, server (prawdziwa nazwa mojego serwera) i fromhost (nazwa serwera pocztowego). Uwaga: straciłem dobry dzień zgadując czemu moje posty nie dochodzą póki na to nie wpadłem - miałem wcześniej jako fromhost pewien adres z sieci lokalnej i jakiś mailer po drodze wywalał pocztę do kosza - nie przysyłając żadnej informacji zwrotnej, bo nie miał jak. Sprawdzamy dla pewności, czy jesteśmy w stanie wysłać pocztę z palca z konta news, przy pomocy sendmail'a na jakieś konto w internecie (np. na friko), ustawiając jako From news@to-co-wpisaliśmy-jako-fromhost. Charakteryzujemy grupy jako moderowane ----- ciach ----- ... ctlinnd changegroup pl.rec.humor.najlepsze m ctlinnd changegroup comp.lang.c++.moderated m ... ----- ciach ----- Próbujemy coś wysłać - najlepiej na grupę z której przychodzą powiadomienia o zakolejkowaniu. 2.8 Uwagi i kruczki Jeśli coś może pójść źle, to z pewnością pójdzie Bardzo pomocnym programem jest inncheck, który sprawdza poprawność konfiguracji, atrybuty plików oraz wyświetla potencjalne źródła problemów. Jeśli coś nam nie działa to diagnostykę powinniśmy zacząć właśnie od uruchomienia tego programu. W razie problemów należy także sprawdzić właścicieli oraz prawa dostępu do plików z pakietu inn'a (np. z plikiem ~/jakiś_plik_z_atrybutami który czujnie zrobiliśmy na początku instalacji). Jeśli podczas ściągania newsów pojawi się komunikat GROUP command not recognized, try the -M option oczywiście dodaj w pliku /var/lib/suck/get.news.inn opcję -M do wywołania suck'a. Jeśli wysyłane przez nas posty nie pojawiają się w naszej kolejce wyjściowej (tzn. pliki w katalogu /var/spool/news/outgoing/ są puste), to może pomóc dodanie wpisu *, w pliku /etc/news/newsfeeds: ----- ciach ----- ... news.task.gda.pl\ :*,!junk,!test,!to\ :Tf,Wnm: ... ----- ciach ----- Jeśli nasz serwer odsyła z powrotem ściągnięte posty do zdalnego serwera, to przyczyną może być to, że nazwa zdalnego feed'u (np. news.task.gda.pl) jest inna niż nazwa umieszczona w polu Path: (np. tasknews.task.gda.pl). Aby temu zaradzić należy sprawdzić jaka nazwa jest w tym polu (najbardziej z lewej) i zmodyfikować plik /etc/news/newsfeeds w następujący sposób: ----- ciach ----- ... news.task.gda.pl/tasknews.task.gda.pl\ :!junk,!test,!to\ :Tf,Wnm: ... ----- ciach ----- Innym rozwiązaniem tego problemu jest dodanie parametru H1 do opcji feedu, czyli :Tf,Wnm,H1:. Inn na co dzień, czyli rzeczy o których warto wiedzieć Usuwanie grup odbywa się przez ctlinnd rmgroup nazwa.grupy (jeśli wywołujemy suck'a lokalnie, to on sam usunie taką grupę z pliku sucknewsrc, jeśli zdalnie (patrz kompresja) to musimy to zrobić ręcznie), UWAGA!!! Nie należy usuwać grup control, control.cancel, junk, test ani to, inn bardzo źle to znosi. Opisy grup można dodawać w pliku /var/lib/news/newsgroups, np.: ----- ciach ----- ... pl.comp.ogonki O polskich literkach w komputerach. pl.comp.os.linux Linux - system operacyjny dla kazdego. ... ----- ciach ----- Możemy je ściągnąć np. komendą testhost news.task.gda.pl -d > jakiś_plik (jeśli na serwerze z którego ściągamy opisy jest dużo grup (może być ich nawet parędziesiąt tysięcy), to może to potrwać parę minut). Dane o przeterminowaniach (nie dotyczy CNFS) są w pliku /etc/news/expire.ctl, usuwanie przeterminowanych postów można wymusić uruchamiając skrypt /etc/cron.daily/inn-cron-expire (przecież nie każdy ma włączony komputer całą dobę). Aby usunąć limit linii dla postów ściągniętych przez inn'a (już po zaakceptowaniu przez suck'a) należy dodać w pliku /etc/rc.d/rc.news do opcji FLAGS flagę -l0. Jeśli nie chcemy aby inn odrzucał stare posty, powinniśmy zwiększyć wartość parametru artcutoff w pliku /etc/news/inn.conf. Od czasu do czasu można wyczyścić skrytkę pocztową użytkownika news np. z konta root'a komendą su - news -c pine. W pliku /etc/news/inn.conf możemy zmienić parametry organization (bo napis A poorly-installed InterNetNews site w postach wygląda nieelegancko) oraz ustawić pathhost (ułatwia czytanie logów). Jeśli przy próbie połączenia z inn'em pojawia się komunikat You have no permision to talk. Goodbye należy zaktualizować zawartość pliku /etc/news/nnrp.access, np. poniżej dodaliśmy możliwość dostępu z sieci 192.168.1.0: ----- ciach ----- # Default to no access *:: -no- : -no- :!* # Allow access from localhost localhost:Read Post:::* 192.168.1.0/24:Read Post:::* ----- ciach ----- Jeśli chcemy założyć lokalną (local) hierarchię, to wystarczy założyć odpowiednie grupy local.* oraz zmienić wpis w /etc/news/newsfeeds: ----- ciach ----- ... news.task.gda.pl\ :!junk,!test,!to,!local.*\ :Tf,Wnm: # ^^^^^^^^^ ten wpis ... ----- ciach ----- aby nasze lokalne posty nie wędrowały gdzieś po świecie. Jeśli ściągamy newsy z kilku serwerów, to wystarczy jeśli umieścimy w pliku /etc/news/newsfeeds odpowiednie wpisy: ----- ciach ----- ... news.task.gda.pl/news.tpnet.pl,news.icm.edu.pl\ :!junk,!test,!to\ :Tf,Wnm: news.tpnet.pl/news.task.gda.pl,news.icm.edu.pl\ :!junk,!test,!to\ :Tf,Wnm: ... ----- ciach ----- Jeśli przy uruchomieniu suck'a pojawia się komunikat typu Can not open /usr/news/db/history, Skipping warto podlinkować /usr/news/db/ do katalogu z bazą history (zazwyczaj /var/lib/news/). Jeśli zdarza nam się używać kilku serwerów, to suck nie będzie ponownie ściągał postów, które już są w naszym serwerze. Sprawdzenie kolejki postów wychodzących można dokonać poniższym skryptem (jest to przerobiony skrypt newsq z pakietu leafnode): ----- ciach ----- #!/usr/bin/perl use MIME::Words qw(:all); $spooldir = "/var/spool/news"; if ( chdir "$spooldir/outgoing" && opendir( DIR, "." ) ) { @sites = readdir( DIR ); closedir( DIR ); foreach (@sites) { if ( open(F, "< $_") ) { while(<F>) { push @posts, (split)[0]; } close F; } } undef $/; foreach (@posts) { if ( open(F, "< $spooldir/articles/$_") ) { # if ( open(F, "sm $_ |") ) { # zamienić te linie dla CNFS undef $subject, $newsgroups, $from; $_ = <F>; close F; s/\n\n.*//s; s/\r//gs; s/\n\s+/ /sg; foreach ( split( /\n/, $_ ) ) { $subject = $1 if ( /^Subject:\s+(.*)/i ); $newsgroups = $1 if ( /^Newsgroups:\s+(.*)/i ); $from = $1 if ( /^From:\s+(.*)/i ); } if ( $subject ne "" && $from ne "" && $newsgroups ne "" ) { $from=decode_mimewords($from); $newsgroups=decode_mimewords($newsgroups); $subject=decode_mimewords($subject); print $from . " in " . $newsgroups . "\n\t" . $subject . "\n"; } } } } ----- ciach ----- Jeśli chcemy aby było robione lokalne archiwum (np. grup z hierarchii pl.comp), to wystarczy jeśli dopiszemy do pliku /etc/news/newsfeeds: ----- ciach ----- source-archive:!*,pl.comp.*\ :Tc,Wn\ :/usr/bin/archive -i /var/spool/news/archive/INDEX ----- ciach ----- Archiwum to możemy czytać używając tin'a, np.: export TIN_SPOOLDIR=/var/spool/news/archive export TIN_LIBDIR=/var/lib/news tin Jeśli mamy już wcześniej ściągnięte pliki z postami, to możemy spróbować przenieść te zasoby do inn'a, np. komendą: ----- ciach ----- (for i in [0-9]*; do cat $i; echo .; done) \ | filter2rnews | rnews -N -vvv -S localhost ----- ciach ----- wykonywaną po kolei w każdym katalogu (z postami). 3. Inne dokumenty związane z tematem Dokumentacja dostarczana z pakietem (część może być dostępna tylko z pakietem ze źródłami), INN FAQ, Newsy w Polsce, Newsy na świecie, Pakiet załatwiający modemowcom sprawę "inn+suck z kilku serwerów" tak, że prościej nie można, Pakiet umożliwiający ściąganie skompresowanych paczek newsów przez WWW. 4. Do zrobienia Transport newsów po UUCP. 5. Prawa autorskie/legalność Prawa autorskie należą do © Rafała Czeczótki. Dokument ten jest rozpowszechniany na podstawie GPL (Gnu Public License). Aby otrzymać kopię tej licencji napisz do Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. Znaki towarowe należą do ich właścicieli. Nie ma żadnych gwarancji co do dokładności czy przydatności informacji zawartych w tym dokumencie.