Questo è un piccolo HowTo che vi permetterà di avere INN funzionante in poco tempo (speriamo ;-)).
INN (InterNet News) è un server news molto potente e configurabile, usato da molti news server importanti (news.bofh.it e fino a poco tempo fa news.tin.it, ad esempio). Però, proprio per la sua configurabilità potrebbe mettere in difficoltà gli utenti meno esperti.
In questo articolo do per scontato che INN sia già stato correttamente installato.
Prima di iniziare con la configurazione vera e proprio bisogna scegliere con quale metodo archiviare gli articoli ed il formato del database di overview.
Gli articoli possono essere memorizzati con 4 differenti metodi:
Io consiglio di usare il metodo timecaf, visto che fornisce il migliore rapporto velocità/facilità di manutenzione (il metodo cnfs è più complesso da amministrare).
Il database di overview contiene le informazioni principali sugli articoli (mittente, oggetto, newsgroups) che vengono inviate al news reader. Solo in seguito (se il reader lo richiederà) verrà recuperato l'articolo vero e proprio.
Dei 3 metodi disponibili io scarterei subito ovdb, visto che richiederebbe la configurazione di un database (Berkeley DB) addizionale. Gli altri due metodi sono: tradindexed, ogni newsgroups è indicizzato con due files. Il metodo è abbastanza veloce per il client, ma crea un certo overhead sul server. Buffindexed, i dati sono posti in grossi buffer preconfigurati; è leggermente più lento del precedente.
Sul mio computer io uso il metodo buffindexed, ma visto che il server che stiamo configurando non gestirà certo centinaia di MB di news al giorno, la scelta di uno dei due metodi dovrebbe essere ininfluente.
Nota: tutte le operazioni sotto indicate devono essere eseguite dall'utente news, se non indicato diversamente.
Questo è il file di configurazione principale e
contiene molte opzioni. Per un elenco completo consultate la
relativa man page (man -M ~news/man inn.conf). Le
opzioni più importanti sono:
Il resto del file dovrebbe contenere già valori ragionevoli.
Questo file contiene le indicazioni su come smistare gli articoli ai relativi moderatori. Prima dell'ultima riga inserite queste due linee:
linux.*:linux-%s@news.lameter.com
it.*:%s@moderators.news.nic.it
Questo è il file più complesso e definisce in che modo gli articoli verranno smistati. Assicuratevi di commentare tutte le linee eventualmente non commentate nel file.
La prima riga da inserire e` questa:
ME:*,!local*,!control,!junk::
Essa serve per distinguere i gruppi locali da quelli
remoti.
Le rige successive indicano come smistare gli articoli ai server remoti. Per il server tin serve questo blocco:
tin/news-in.tin.it,news-out.tin.it,news.tin.it\
:!*,alt.hackers*,it.*\
:Tf,Wnm:
La prima riga indica un nome (tin) che servirà in seguito ed una serie di dominii di esclusione; in pratica se nel path di un articolo compare uno dei dominii l'articolo non viene spedito a questo server, visto che proviene proprio da lì.
La seconda riga specifica quali gruppi sono accettati dal server. Nell'esempio ho indicato che il server non li accetta tutti (!*), ma solo quelli sotto alt.hackers e la gerarchia it.*. Ovviamente potete aggiungere altri gruppi, a condizione che si trovino sul server in questione.
L'ultima riga indica cosa fare degli articoli che soddisfano le condizioni precedenti. Tf indica che la destinazione è un file (il nome è il primo parametro della prima riga, tin). Wnm indica che nel file verranno scritti solo il message-id ed il token corrispondente all'articolo.
Per ogni news server aggiuntivo dovrette replicare una sezione come questa.
Questo file va editato solo se si è scelto il metodo di archiviazione CNFS.
Le opzioni che è possibile specificare sono:
cycbuffupdate:numero articoli
refreshinterval:intervallo di aggiornamento
cycbuff:NOME:/path/completo/buffer:dimensione
metacycbuff:NOME:BUFFER1,BUFFER2
cycbuffupdate: indica dopo quanti articoli memorizzati l'header del buffer viene aggiornato. Se la linea è omessa viene utilizzato il valore di default (25).
refreshinterval: indica dopo quanti secondi dall'apertura l'header del buffer verrà riletto. Se la linea è omessa viene utilizzato il valore di default (30).
cycbuff: definisce un buffer ciclico. Il primo campo definisce un nome simbolico (massimo 7 caratteri) che identifica il buffer. Il secondo campo è il nome completo di path del buffer, mentre il terzo campo specifica la dimensione in KB del buffer (1MB = 1024Kb, 1KB = 1024B).
Per creare i buffer si puo` utilizzare dd. Ad esempio, per creare
un buffer di 20MB si utilizzerà questo comando:
dd if=/dev/zero of=nome_buffer bs=1024 count=20480
dove 20480 è 20 * 1024.
metacycbuff: definisce un meta-buffer, composto da uno o piu` buffer ciclici. Il primo parametro indica il nome del meta-buffer; questo è anche il nome che verrà utilizzato nel file storage.conf. Il secondo parametro è una lista dei buffer ciclici (separati da una virgola) che compongono il meta-buffer. Esiste un terzo parametro opzionale che specifica la modalità di riempimento del buffer. I valori possibili sono due: INTERLEAVE (predefinito, gli articoli vengo suddivisi in ogni buffer ciclico secondo lo schema round robin) oppure SEQUENTIAL (viene prima riempito il primo buffer, poi il secondo e così via).
Nota: per controllare lo stato dei buffer è possibile utilizzare il comando cnfsstat.
In questo file si imposta il metodo di archiviazione degli articoli.
Dopo aver commentato tutte le righe, bisogna aggiungere
questa sezione:
method timecaf {
newsgroups: *
class: 1
size: 0,1000000
}
Questo imposta a timecaf il metodo di storage per tutti i newsgroups.
Per utilizzare il metodo di archiviazione CNFS bisogna indicare
il nome del meta-buffer da usare tramite la voce options:
method cnfs {
newsgroups: *
class: 2
size: 0,1000000
options: NOME
}
NOME è il nome del meta-buffer, specificato nel file cycbuff.conf. class deve indentificare in maniera univoca il gruppo, quindi va adattato di conseguenza.
Ovviamente si possono suddividere i newsgroups su vari buffer in modo che quelli a traffico elevato non sovrascrivano quelli con meno traffico. È anche possibile utilizzare una soluzione ibrida, mescolado i vari tipi di memorizzazione dei messaggi.
Se si suddividono i newsgroups su vari buffer, o se si utilizzano
diversi metodi di archiviazione, è consigliabile lasciare
alla fine del fine queste linee:
method timecaf {
newsgroups: *
class: 3
}
Questo assicura che vengano memorizzati anche gruppi che sono stati tralasciati oppure che sono appena stati aggiunti.
Questo file indica dopo quanto tempo gli articoli vengono eliminati.
/remember/:10
*:A:7:15:60
alt.hackers:9:18:60
La prima riga indica il tempo (giorni) minino durante il quale il Msg-ID viene mantenuto nella history. La seconda è una regola generale (valida per tutti i newsgroups); indica che gli articoli devono essere mantenuti minimo per 7 giorni (anche se l'header Expire indica diversamente) e devono essere cancellati dopo 18 giorni. Se l'articolo contiene l'header Expire, allora questo verrà mantenuto fino alla data indicata o dopo 60 giorni (quello che viene prima). L'ultima riga è riferita ad un singolo ng (nel mio caso alt.hackers, ma potete metterci qualunque cosa) di particolare interesse, per il quale i tempi di expire sono più lungi.
Nota: questo file non influenza i post memorizzati all'interno dei buffer ciclici, che vengono automaticamente sovrascritti quando il buffer risulta pieno.
Se avete scelto il formato tradindexed potete saltare questa sezione.
In questo file vengono definiti il numero e la dimensione dei buffer per l'overview. Io uso due buffer da 15MB per circa 20.000 articoli, e sono ampiamente sovradimensionati.
Il formato del file è:
indice:path/completo/buffer:dimensione in KB
Nel caso di due buffer da 15MB le due righe sarebbero:
0:/var/news/spool/overview/OV1:15360
1:/var/news/spool/overview/OV2:15360
Il path va ovviamente adeguato alla vostra installazione. Se volete variare le dimensioni il numero da inserire è: dimensioni in MB * 1024.
Adesso i buffer vanno creati. Dopo esservi spostati nella
directory giusta (nel mio caso /var/news/spool/overview),
bisogna usare il seguente comando per ogni buffer (variando
ovviamente il nome):
dd if=/dev/zero of=OV1 bs=1024 count=15360
OV1 è il nome del buffer, mentre 15360 e` la dimensione che avete indicato nel file di configurazione.
Nota: se sul vostro server tenete più articoli ed i
buffer vi vanno stretti, basta aggiungere un nuovo buffer nel
file di configurazione e crearlo. Lo spazio usato è
visualizzabile tramite il comando inndf -o
Questo file si trova nella directory ~news/db e contiene i newsgroups presenti sul server; deve essere inizializzato prima che il server possa partire. Esistono due alternative per la creazione di questo file:
control 0000000000 0000000001 n
control.cancel 0000000000 0000000001 n
control.checkgroups 0000000000 0000000001 n
control.newgroup 0000000000 0000000001 n
control.rmgroup 0000000000 0000000001 n
junk 0000000000 0000000001 n
Tutti i newsgroups che si vogliono seguire andranno
aggiunti in seguito tramite il comando ctlinnd
newgroup nome_gruppo y per i gruppi non moderati e
ctlinnd newgroup nome_gruppo m per i gruppi
moderati.
Adesso è necessario creare ed inizializzare alcuni file di INN. La procedura è la seguente:
cd ~news/db
touch history
~news/bin/makedbz -i
mv history.n.dir history.dir
mv history.n.pag history.pag
chmod 0644 *
chmod 0664 active
Il file è /etc/syslog.conf e la modifica deve essere eseguita dall'utente root.
Questo file indica dove devono essere inseriti i messaggi di log generati dal server. Le rige necessarie sono:
news.err /var/news/log/news.err
news.crit /var/news/log/news.crit
news.notice /var/news/log/news.notice
I file quindi vanno creati (come utente news):
touch /usr/local/news/log/news.crit
touch /usr/local/news/log/news.err
touch /usr/local/news/log/news.notice
chown news /usr/local/news/log/news.*
chgrp news /usr/local/news/log/news.*
Adeguate il path se necessario.
Come ultima cosa bisogna impostare l'expire giornaliero
degli articoli. Digitate crontab -e ed inserite
questa riga:
0 15 * * * /usr/local/news/bin/news.daily expireover
lowmark
Questa indica che il controllo dello spool avverrà alle 15.00 (primi due parametri, nel formato minuti ore). Adeguate l'orario ed il path alle vostre esigenze.
A questo punto INN dovrebbe essere configurato e pronto a
partire. Avviatelo con il comando rc.news
start
Ora dovrebbe essere possibile provare il nuovo server:
kronos:~$ telnet 127.0.0.1 119
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
200 dreamland.darkstar.net InterNetNews server INN 2.3.1 ready
quit
205 .
Connection closed by foreign host.
Se ottenete un messaggio di errore controllate i file di log alla ricerca di indizi e ricontrollate i file di configurazione. Non preoccupatevi se non riuscite al primo tentativo, io ho impiegato una settimana!
INN da solo non è in grado di scaricare o inviare articoli (a dire il vero potrebbe inviare, ma con il comando IHAVE). Per lo scaricamento delle news è possibile usare suck o newsx, mentre per l'invio sono disponibili rpost (pacchetto di suck) e kpost (eheheh).
Ultimo aggiornamento: 02/05/2001
Copyright (C) 2000 Luca "Kronos" Tettamanti
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with no Invariant Sections, with no Front-Cover Texts, and with
no Back-Cover Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".