inn+suck - instalacja.
Rafa³ Czeczótka, michu@amg.gda.pl
v2.02, 1 listopad 1998
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
<http://www.amg.gda.pl/~michu/linux.html>. Zosta³o u¿yte kodowanie
ISO-8859-2.
______________________________________________________________________
Spis tre¶ci
1. Wstêp.
1.1 Przedmowa.
1.2 Podziêkowania.
2. S³owo o programach, instalacja i konfiguracja.
2.1 Co to jest inn i suck.
2.2 Kiedy instalowaæ inn+suck.
2.3 Wady i zalety tego rozwi±zania.
2.4 Instalacja i konfiguracja.
2.5 Kompresja newsów w drodze.
2.6 Uwagi i kruczki.
3. Prawa autorskie/legalno¶æ.
______________________________________________________________________
11.. WWssttêêpp..
11..11.. PPrrzzeeddmmoowwaa..
Ca³± tre¶æ tego dokumentu stanowi opis mojej instalacji duetu suck+inn
w systemie RedHat5.1, w oparciu o konkretne pakiety (inn-1.7.2-13 i
suck-3.9.4-2). 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
minimalnej, dzia³aj±cej konfiguracji bêdzie dla kogo¶ przydatny.
Wszelkie sugestie i poprawki s± mile widziane i nale¿y je wysy³aæ pod
adres michu@amg.gda.pl <mailto:michu@amg.gda.pl>.
W tym dokumencie w paru miejscach porównujê inn'a do leafnode'a,
którego wcze¶niej u¿ywa³em.
11..22.. PPooddzziiêêkkoowwaanniiaa..
Nastêpuj±cy ludzie przyczynili siê do postania 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 :-)
· Bartosz Maruszewski z JTZ (B.Maruszewski@jtz.org.pl) - 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 (klik@rubikon.net.pl) - poda³ rozwi±zanie
likwiduj±ce problem odsy³ania postów,
· Krzysztof Zietara (tarhim@alpha.net.pl) - rozwi±za³ problem ze
¶ci±ganiem (a raczej jak ich nie ¶ci±gaæ) grup "control", "junk",
"test" i "to" oraz nades³a³ inne uwagi,
· Micha³ Tyra³a (kbns@zeus.polsl.gliwice.pl) - 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 (feanor@zeus.polsl.gliwice.pl) - rozwi±za³
problemy z odrzucaniem niektórych postów (zmiany w newsfeeds),
· Tomasz Szymczak (szymczak@bg.univ.gda.pl) - 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.
22.. SS³³oowwoo oo pprrooggrraammaacchh,, iinnssttaallaaccjjaa ii kkoonnffiigguurraaccjjaa..
22..11.. CCoo ttoo jjeesstt iinnnn ii ssuucckk..
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±æ).
22..22.. KKiieeddyy iinnssttaalloowwaaææ iinnnn++ssuucckk..
Je¶li uwa¿asz, ¿e spe³nione s± poni¿sze warunki:
1. 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),
2. Z newsów na twoim komputerze korzysta wiêcej ni¿ jeden u¿ytkownik
(bo dla jednego usera zupe³nie wystarczaj±ce jest "rtin -SQ")
ewentualnie "twój" komputer s³u¿y jako serwer news dla ca³ej sieci
(np. w firmie),
3. Mo¿liwo¶ci leafnode'a ju¿ Ci nie wystarczaj± (potrzebujesz
killfile'i, ró¿nych ograniczeñ na ¶ci±gan± pocztê newsow±, ...),
4. ¦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:
1. cleanfeed (np. cleanfeed-0.95.5a-1),
2. inn (np. inn-1.7.2-13, UWAGA: oryginalny pakiet z dystrybucji RH5.1
jest niepoprawny),
3. perl-MD5 (np. perl-MD5-1.7-2),
4. suck (np. suck-3.9.4-2).
Ja skorzysta³em z ni¿ej wymienionych adresów:
· pakiety cleanfeed, inn i perl-MD5 -
ftp.task.gda.pl/pub/linux/redhat-updated/i386/RedHat/RPMS/
<ftp://ftp.task.gda.pl/pub/linux/redhat-updated/i386/RedHat/RPMS/>,
· pakiet suck ftp.task.gda.pl/pub/linux/redhat-contrib/tbird/i386/
<ftp://ftp.task.gda.pl/pub/linux/redhat-contrib/tbird/i386/>.
22..33.. WWaaddyy ii zzaalleettyy tteeggoo rroozzwwii±±zzaanniiaa..
Zalety inn+suck:
1. Szybki (piekielnie),
2. 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),
3. Mo¿na tak skonfigurowaæ inn+suck, ¿e newsy s± ¶ci±gane
skompresowane, czyli czas transmisji mo¿na skróciæ parokrotnie,
4. 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ê),
5. 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:
1. Do¶æ pogmatwana konfiguracja i hermetyczna dokumentacja
(przynajmniej na pocz±tek) ale ten dokument powsta³ w³a¶nie aby
wyeliminowaæ tê niedogodno¶æ,
2. 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).
22..44.. IInnssttaallaaccjjaa ii kkoonnffiigguurraaccjjaa..
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):
1. Zainstalowaæ inn i suck (i jeszcze parê wymienionych wcze¶niej
drobiazgów),
2. W pliku "/etc/news/innfeed.conf" usun±æ sekcjê peers,
3. 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\
:*,@alt.binaries.warez.*,!junk,!control*,!local*,!foo.*\
/pl,world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\
::
## ^^ - to jest to pl
...
----- ciach -----
4. W pliku "/usr/lib/suck/get.news.innxmit" wstawiæ nazwê serwera news
(REMOTE_HOST=news.task.gda.pl) oraz "sajtu" (tego samego co w
punkcie 3., tj. SITE=news.task.gda.pl),
5. W suck'u w pliku "/usr/lib/suck/sucknewsrc" zapisaæ wszystkie
interesuj±ce nas grupy i numery postów, od których ma siê zacz±æ
"¶ci±ganie", np.:
----- ciach -----
...
pl.comp.ogonki 1
pl.comp.os.linux 1
...
----- ciach -----
UWAGA!!! Zaczynaj±c od pierwszego postu jeste¶my nara¿eni na ¶ci±ganie
du¿ej ilo¶ci danych a co siê z tym wi±¿e znaczne koszty. W koñcu i tak
zapewne oka¿e siê, ¿e wiêkszo¶æ postów jest za stara i zostanie odrzu
cona przez inn'a. Lepiej wiêc nie zaczynaæ od pocz±tku ale od
kilku(set) postów wstecz. U mnie 57 grup (w ca³o¶ci) z dostêpem online
(ethernet "wpiêty do" TASKu, transfer osi±ga³ 160KB/sec, jednak to
by³o bardziej ograniczenie zdalnego serwera ni¿ ³±cza) ¶ci±ga³o siê
prawie godzinê,
6. Usun±æ pliki "/etc/cron.daily/inn-cron-rnews" oraz
"/etc/cron.hourly/inn-cron-nntpsend" (ich funkcje przejmuje suck),
7. 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/rc0-6].d/" (np. poleceniem ntsysv),
8. 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, ktore podales w pliku
# /usr/lib/suck/sucknewsrc - konfiguracyjnym dla suck-a.
# UWAGA !!!
# Wymagany format tego pliku to:
############################
# nazwa.grupy numer.artykulu
############################
#
# Mozesz podac inna lokalizacje
SUCK_FILE=/usr/lib/suck/sucknewsrc
#
# Podaj sciezke do programu ctlinnd. Skrypt sprobuje sam zgadnac, 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 Blad podczas zakladania grupy $1 !!!
exit
fi
done
----- ciach -----
9. Aby nie ¶ci±gaæ grup "control", "junk", "test" ani "to" (z
pewno¶ci± nam siê nie przydadz±), musimy stworzyæ plik
"/usr/lib/suck/active-ignore":
----- ciach -----
control
junk
test
to
----- ciach -----
Oczywi¶cie grup tych nie nale¿y umieszczaæ w pliku
"/usr/lib/suck/sucknewsrc",
10.
Wymianê newsów ze zdalnym serwerem inicjujemy skryptem
"/usr/lib/suck/get.news.innxmit".
22..55.. KKoommpprreessjjaa nneewwssóóww ww ddrrooddzzee..
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±:
1. na domowym komputerze musi byæ zainstalowny klient ssh,
2. 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.
Pakiety ssh w wersji miêdzynarodowej (te z literk± "i" na koñcu) mo¿na
¶ci±gn±æ z ftp.task.gda.pl/pub/linux/redhat-crypto/i386/
<ftp://ftp.task.gda.pl/pub/linux/redhat-crypto/i386/>. Podczas pisania
tego dokumentu najnowszymi wersjami by³y: ssh-1.2.26-1i, ssh-
clients-1.2.26-1i, ssh-extras-1.2.26-1i i ssh-server-1.2.26-1i.
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:
1. Usun±æ z pliku "/usr/lib/suck/get.news.innx" ca³± sekcjê s³u¿±c± do
wysy³ania 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 # base directory for articles to be rposted
NEWSDIR=/usr/lib/news # base directory for news binaries
BASEDIR=/usr/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}/out.going/${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
# 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
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"
echo "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
fi
rm -f ${LOCKFILE}
----- ciach -----
Oczywi¶cie nale¿y pamiêtaæ o w³a¶ciwym ustawieniu zmiennych
REMOTE_HOST i SITE.
2. Skopiowaæ z lokalnego katalogu "/usr/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").
3. Stworzyæ mo¿liwo¶æ logowania siê na zdalnym komputerze za pomoc±
ssh bez u¿ycia has³a (tylko na podstawie znajomo¶ci klucza RSA):
a. wygenerowaæ parê kluczy RSA komend± ssh-keygen (w pass phrase
nie podawaæ has³a),
b. nastêpnie skopiwaæ 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 ujaw
nianie zawarto¶ci pliku "$HOME/.ssh/identity", czyli prywatnej
po³owy klucza. Istnieje tak¿e rozwi±zanie umo¿liwiaj±ce wygen
erowanie klucza z has³em i podawanie go tylko raz na sesjê (patrz
program ssh-agent).
4. Utworzyæ skrypt "/usr/local/bin/filter2rnews":
----- ciach -----
#!/usr/bin/perl -w
while (not eof(STDIN)) {
@POST = "";
do {
$linia = <>;
push @POST, $linia if $linia !~ /^\.$/;
} until ($linia =~ /^\.$/);
$dlug = length(join('',@POST));
print "#! rnews $dlug\n";
print @POST;
}
----- ciach -----
5. 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
"/usr/lib/suck/get.news.innxmit".
22..66.. UUwwaaggii ii kkrruucczzkkii..
1. 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", "junk", "test" ani "to",
inn bardzo ¼le to znosi.
2. 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 -----
3. Dane o przeterminowaniach 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ê).
4. Wy³±czenie odrzucania artyku³ów przez innd (ju¿ to przecie¿ robi
suck) dokonuje siê komend± "ctlinnd perl n".
5. 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".
6. Je¶li podczas ¶ci±gania newsów pojawi siê komunikat "GROUP command
not recognized, try the -M option" oczywi¶cie dodaj w pliku
"/usr/lib/suck/get.news.innxmit" opcjê "-M" do wywo³ania suck'a.
7. Od czasu do czasu mo¿na wyczy¶ciæ skrytkê pocztow± u¿ytkownika news
np. z konta root'a komend± "su - news -c pine".
8. 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).
9. Sprawdzenie kolejki postów wychodz±cych mo¿na dokonaæ poni¿szym
skryptem (jest to przerobiony skrypt newsq z pakietu leafnode):
----- ciach -----
#!/usr/bin/perl
$spooldir = "/var/spool/news";
if ( chdir "$spooldir/out.going" && 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/$_") ) {
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 );
}
print $from, " in ", $newsgroups, "\n\t", $subject, "\n",
if ( $subject ne "" && $from ne "" && $newsgroups ne "" );
}
}
}
----- ciach -----
10.
Je¶li suck odsy³a ¶ci±gniête posty z powrotem do zdalnego serwera,
to mo¿emy zmieniæ sekcjê feeds w pliku "/etc/news/newsfeeds" w
nastêpuj±cy sposób:
----- ciach -----
...
news.task.gda.pl/news.task.gda.pl\
:!junk,!test,!to\
:Tf,Wnm:
...
----- ciach -----
UWAGA!!! Nie jestem przekonany do tego rozwi±zania, ale podobno dzia³a
(w ka¿dym razie komu¶ taki wpis rozwi±za³ problem).
11.
Je¶li zobaczymy na ekranie napis typu:
----- ciach -----
...
stdin: rejected 437 Unwanted newsgroup "pl.rec.radio" [Path:\
news.task.gda.pl!orion.cst.tpsa.pl...]
...
----- ciach -----
nie nale¿y wpadaæ w panikê. Najprawdopodobniej jest to wynik b³êdu w
zdalnym inn'ie (wersja 2.1) zwi±zanego z bazami overview.
33.. PPrraawwaa aauuttoorrsskkiiee//lleeggaallnnoo¶¶ææ..
Prawa autorskie nale¿± do (C) Rafa³a Czeczótki michu@amg.gda.pl
<mailto:michu@amg.gda.pl>. Dokument ten jest rozpowszechniany na
podstawie GPL (Gnu Public License).
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.
