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 michu@amg.gda.pl. 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.
Następujący ludzie przyczynili się do powstania tego dokumentu, taką czy inną drogą, świadomie lub nieświadomie (w kolejności alfabetycznej):
control
,
control.cancel
, junk
, test
i to
oraz nadesłał inne uwagi,-M
w suck'u,
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ąć).
Jeśli uważasz, że spełnione są poniższe warunki:
rtin -SQ
) ewentualnie "twój" komputer służy
jako serwer news dla całej sieci (np. w firmie),Jeśli już będziesz chciał zainstalować to oprogramowanie, to będą Ci potrzebne następujące (lub inne wersje) pakiety:
Zalety inn+suck:
Wady inn+suck:
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):
----- ciach -----
ls -ld `rpm -ql inn` > ~/jakiś_plik_z_atrybutami
----- ciach -----
a wszelkie operacje wykonywać jako użytkownik news
./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 -----
/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
),/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 -----
/etc/cron.daily/inn-cron-rnews
oraz /etc/cron.hourly/inn-cron-nntpsend
, to należy je
usunąć (ich funkcje przejmuje suck),/etc/news/nnrp.access
nie ma wpisu
localhost:
to należy go dodać,/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
),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 -----
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
,/var/lib/suck/get.news.inn
(lub /var/sbin/get-news
na Debian'ie),NNTPSERVER
. Dla bash'a będzie to komenda:
export NNTPSERVER=localhost
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ą:
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:
/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
./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
).$HOME/.ssh/identity.pub
na
zdalny komputer do pliku $HOME/.ssh/authorized_keys
.$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)./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 -----
----- 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
.
----- ciach -----
su news -c 'expireover -s -a'
----- ciach -----
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.
Aby zainstalować CNFS należy (wszystkie te czynności oczywiście
najlepiej wykonać jako użytkownik news
):
/etc/news/inn.conf
ustawić opcję
storageapi
na on
,/etc/news/newsfeeds
:
crosspost:...
,overview
na:
----- ciach -----
overview!:*:Tc,Ao,WhR:/usr/bin/overchan
----- ciach -----
/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,/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 -----
/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 -----
cat
) lecz token (program
sm
), to musimy w konfiguracji suck
'a:
/var/lib/suck/get.news.inn
usunąć w
wywołaniu rpost
'a parametr -p nazwa_katalogu
,put.news
na put.news.sm
(powinien być w przykładach lub źródłach),
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).
[ 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:
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):
/etc/news/moderators
z następującą
treścią:
# Uniwersalny adres moderatorów grup polskich
pl.*:%s@usenet.pl
# Uniwersalny adres moderatorów grup światowych
*:%s@moderators.isc.org
/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. news@to-co-wpisaliśmy-jako-fromhost
.
----- ciach -----
...
ctlinnd changegroup pl.rec.humor.najlepsze m
ctlinnd changegroup comp.lang.c++.moderated m
...
----- ciach -----
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.~/jakiś_plik_z_atrybutami
który czujnie zrobiliśmy na
początku instalacji).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./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 -----
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:
.
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),control
,
control.cancel
, junk
, test
ani
to
, inn bardzo źle to znosi./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)./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ę)./etc/rc.d/rc.news
do opcji FLAGS flagę -l0
.artcutoff
w pliku
/etc/news/inn.conf
.su - news -c pine
./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).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 -----
/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./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 -----
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.
----- 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 -----
/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
----- 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).
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.