inn+suck - instalacja.
Rafa³ Czeczótka <mailto:michu@amg.gda.pl>
v4.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.
______________________________________________________________________
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 Podstawowa instalacja i konfiguracja
2.5 Kompresja newsów w drodze
2.6 CNFS
2.6.1 Krótka chrakterystyka CNFS
2.6.2 Instalacja i konfiguracja CNFS
2.6.3 Podstawowe ró¿nice
2.7 Grupy moderowane
2.8 Uwagi i kruczki
2.8.1 Je¶li co¶ mo¿e pój¶æ ¼le, to z pewno¶ci± pójdzie
2.8.2 Inn na co dzieñ, czyli rzeczy o których warto wiedzieæ
3. Inne dokumenty zwi±zane z tematem
4. Do zrobienia
5. Prawa autorskie/legalno¶æ
______________________________________________________________________
11.. WWssttêêpp
11..11.. PPrrzzeeddmmoowwaa
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 "_n_i_e _d_z_i_a_³_a _m_i_, _C_O _R_O_B_I_Æ_?_?_?" 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.
11..22.. PPooddzziiêêkkoowwaanniiaa
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 (radecki@posejdon.wpk.p.lodz.pl) - poda³ sposób
czytania lokalnego archiwum,
· 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,
· Jakub Bogusz (qboosh@priv6.onet.pl) - poda³ jeszcze jeden sposób, w
jaki mo¿na rozwi±zaæ problem odsy³ania postów,
· Krzysztof Zietara (tarhim@studio.net.pl) - 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 (miechus@aurora.put.poznan.pl) - dokona³
prze³o¿enia niniejszego tekstu na jêzyk angielski,
· Marcin Kasperski (Marcin.Kasperski@softax.com.pl) - 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 (shadow@fanthom.math.put.poznan.pl) - poda³ kilka
istotnych uwag,
· 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 Sienicki (tsca@cryogen.com) - poda³ ciekawego URL'a
zwi±zanego z tematem,
· 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 s± rozwi±zania typu
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.7b-7, wymagany tylko w RedHat, aby
spe³niæ zale¿no¶ci RPM'a),
2. inn (np. inn-2.2.2-3),
3. perl-MD5 (np. perl-MD5-1.7-2, podobnie jak cleanfeed wymagany tylko
w RedHat),
4. suck (np. suck-4.2.2-1).
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.. PPooddssttaawwoowwaa iinnssttaallaaccjjaa ii kkoonnffiigguurraaccjjaa
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):
1. 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.
2. 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 -----
3. 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),
4. 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 -----
5. 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),
6. Je¶li w pliku /etc/news/nnrp.access nie ma wpisu localhost: to
nale¿y go dodaæ,
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/rc[0-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, 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 -----
9. 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/suck
newsrc,
10.
Wymianê newsów ze zdalnym serwerem inicjujemy skryptem
/var/lib/suck/get.news.inn (lub /var/sbin/get-news na Debian'ie),
11.
Aby czytaæ newsy musimy ustawiæ zmienn± ¶rodowiskow± NNTPSERVER.
Dla bash'a bêdzie to komenda:
export NNTPSERVER=localhost
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.
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 /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.
2. 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).
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 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 ujaw
nianie 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).
4. 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 -----
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
/var/lib/suck/get.news.inn.
6. Pomocnym bêdzie uaktualnienie bazy overview (rnews nie robi tego
automatycznie):
----- ciach -----
su news -c 'expireover -s -a'
----- ciach -----
22..66.. CCNNFFSS
22..66..11.. KKrróóttkkaa cchhrraakktteerryyssttyykkaa CCNNFFSS
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.
22..66..22.. IInnssttaallaaccjjaa ii kkoonnffiigguurraaccjjaa CCNNFFSS
Aby zainstalowaæ CNFS nale¿y (wszystkie te czynno¶ci oczywi¶cie
najlepiej wykonaæ jako u¿ytkownik news):
1. W pliku /etc/news/inn.conf ustawiæ opcjê storageapi na on,
2. W pliku /etc/news/newsfeeds:
a. Wyrzuciæ wpis crosspost:...,
b. Zmieniæ wpis overview na:
----- ciach -----
overview!:*:Tc,Ao,WhR:/usr/bin/overchan
----- ciach -----
3. 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± metabu
fora cyklicznego,
4. 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 -----
5. 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 -----
6. 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:
a. W skrypcie /var/lib/suck/get.news.inn usun±æ w wywo³aniu rpost'a
parametr -p nazwa_katalogu,
b. Zamieniæ skrypt put.news na put.news.sm (powinien byæ w
przyk³adach lub ¼ród³ach),
7. I mo¿emy zaczynaæ ¶ci±gaæ news'y.
22..66..33.. PPooddssttaawwoowwee rróó¿¿nniiccee
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).
22..77.. GGrruuppyy mmooddeerroowwaannee
[ 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):
1. Tworzymy plik /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
2. 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.
3. 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.
4. Charakteryzujemy grupy jako moderowane
----- ciach -----
...
ctlinnd changegroup pl.rec.humor.najlepsze m
ctlinnd changegroup comp.lang.c++.moderated m
...
----- ciach -----
5. Próbujemy co¶ wys³aæ - najlepiej na grupê z której przychodz±
powiadomienia o zakolejkowaniu.
22..88.. UUwwaaggii ii kkrruucczzkkii
22..88..11.. JJee¶¶llii ccoo¶¶ mmoo¿¿ee ppóójj¶¶ææ ¼¼llee,, ttoo zz ppeewwnnoo¶¶ccii±± ppóójjddzziiee
1. 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.
2. 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).
3. 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.
4. 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 -----
5. 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:.
22..88..22.. IInnnn nnaa ccoo ddzziieeññ,, cczzyyllii rrzzeecczzyy oo kkttóórryycchh wwaarrttoo wwiieeddzziieeææ
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, control.cancel, 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 -----
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).
3. 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ê).
4. 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.
5. Je¶li nie chcemy aby inn odrzuca³ stare posty, powinni¶my zwiêkszyæ
warto¶æ parametru artcutoff w pliku /etc/news/inn.conf.
6. Od czasu do czasu mo¿na wyczy¶ciæ skrytkê pocztow± u¿ytkownika news
np. z konta root'a komend± su - news -c pine.
7. 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).
8. 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 -----
9. 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.
10.
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 -----
11.
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.
12.
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 -----
13.
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
14.
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).
33.. IInnnnee ddookkuummeennttyy zzwwii±±zzaannee zz tteemmaatteemm
· Dokumentacja dostarczana z pakietem (czê¶æ mo¿e byæ dostêpna tylko
z pakietem ze ¼ród³ami),
· INN FAQ <ftp://ftp.xlink.net/pub/news/docs/>,
· Newsy w Polsce <http://www.usenet.pl>,
· Newsy na ¶wiecie <http://www.usenet.org>,
· Pakiet
<http://home.pages.de/~lamepage/linux/news/sp4si-0.96.tar.gz>
za³atwiaj±cy modemowcom sprawê "inn+suck z kilku serwerów" tak, ¿e
pro¶ciej nie mo¿na,
· Pakiet <http://www.media-com.com.pl/~radecki> umo¿liwiaj±cy
¶ci±ganie skompresowanych paczek newsów przez WWW.
44.. DDoo zzrroobbiieenniiaa
· Transport newsów po UUCP.
55.. PPrraawwaa aauuttoorrsskkiiee//lleeggaallnnoo¶¶ææ
Prawa autorskie nale¿± do © Rafa³a Czeczótki
<mailto:michu@amg.gda.pl>. 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.
