Questa FAQ tenta di offrire aiuto agli amministratori delle gerarchie Usenet, ovvero coloro che provano a gestire le liste canoniche dei newsgroups nelle gerarchie. È rivolta agli amministratori delle gerarchie, piuttosto che agli amministratori delle news e tenta di sintetizzare le cose da considerare per rendere più facile agli amministratori delle news il compito di portare una gerarchia sui loro server.
Se state leggendo questo su Usenet, questa FAQ è formattata come digest minimo, cosicché se il vostro programma per la lettura delle news o delle e-mail ha delle capacità di digest, potete utilizzarle per navigare tra le sezioni. Nella variante rn, potete usare Ctrl-G per saltare la prossima sezione; in Gnus, premete Ctrl-D per spezzare ogni sezione in articoli separati
Per favore mandate commenti, suggerimenti, aggiornamenti a rra@stanford.edu. Ricordate, quando mandate una e-mail, che ricevo circa 800 messagi via mail al giorno e talvolta ho un ampio backlog di e-mail personali.
Questa FAQ e' postata mensilmente in news.admin.hierarchies ed e' disponibile sul web in inglese presso
http://www.eyrie.org/~eagle/faqs/usenet-hier.html .
[[TableOfContents]]
= Introduzione e lessico =
Questa FAQ presume una familiarità di base con Usenet (ci sono altri documenti che ne spiegano meglio i principi fondamentali), ma ci sono alcuni concetti addizionali che sono particolarmente importanti per chi amministra una gerarchia Usenet
Una gerarchia Usenet è, ridotta alla sua essenza, un insieme di newsgroups di Usenet che condividono uno comune prefisso nella denominazione, per esempio tutti i gruppi inizianti per "comp." o tutti i gruppi inizianti per "de." I nomi dei newsgroups di Usenet definiscono una gerarchia, con "." usato come separatore tra i suoi differenti livelli, come accade anche per i nomi di dominio. A differenza però di quanto accade per questi ultimi, qui la parte più significativa del nome è messa per prima. La prima componente della denominazione è dunque speciale e più significativa rispetto al resto, poiché definisce la gerarchia Usenet del piu' alto livello, a cui quel gruppo appartiene.
Generalmente ogni gerarchia del piu' alto livello è completamente indipendente dalle altre (sebbene vi siano alcune eccezioni quando diverse gerarchie condividano le stesse procedure di gestione). Le modalità con cui la lista dei newsgroups in una specifica gerarchia viene mantenuta, variano considerevolmente, dall'una all'altra, dalla completa anarchia di alt.*, al sistema altamente formalizzato usato da comp.*, o semplicemente per decisioni di creazione prese dall'organizzazione che gestisce la gerarchia, come con microsoft.*. Quale metodo di mantenimento dobbiate utilizzare per la vostra
gerarchia è estraneo allo scopo di queste FAQ; Questo documento riguarda il come pubblicare il risultato di questo metodo, presupponendo che vogliate avere una singola lista canonica di newsgroups con cui chiunque porti la gerarchia possa concordare. Se non volete questo (se la vostra gerarchia e' come alt.*, per esempio), allora gran parte di questo documento non vi riguarda.
I newsgroups di Usenet sono creati e rimossi per mezzo di messaggi formattati in modo speciale, chiamati "control messages" (messaggi di controllo), che dicono al news server di fare qualcosa. Una gerarchia dovrebbe avere un'amministratore che sia responsabile per seguire qualsiasi procedura sia stata concordata per la modifica della lista dei gruppi in quella gerarchia e quindi per pubblicare i risultati utilizzando messaggi di controllo. La struttura dei messaggi di controllo è spiegata negli Usenet News Standard e in molte FAQs e pagine web, cosicché non sara' di nuovo spiegata qui. (Alcuni siti,
per varie ragioni, non usano messaggi di controllo e pertanto è meglio pubblicare i risultati anche per mezzo di altri metodi, come sarà spiegato piu' oltre).
Oltre ai messaggi di controllo "newgroup" (crea un newsgroup) e "rmgroup" (rimuovi un newsgroup), c'è anche un messaggio di controllo chiamato "checkgroups", che offre una lista completa dei newsgroups di una gerarchia, comprese brevi descrizioni. Con il termine "checkgroups" pertanto si intende anche la lista completa dei newsgroups di una gerarchia. Il formato di questa lista è un elenco di gruppi, uno per linea, con il nome del gruppo, un tab, e una corta descrizione. Se il newsgroup è moderato, la descrizione deve terminare con questo testo, copiato letteralmente: "(Moderated)". (Si, non è possibile tradurre la parola in un altra lingua. E' una spiacevole necessità del protocollo di comunicazione).
In origine i messaggi di controllo erano autenticati solo dal sender (mittente) del messaggio, facilmente alterabile, cosa che funzionava quando Usenet era piccola, ma si rivelò ingestibile non appena divenne più grande. Come risultato, molte gerarchie ora firmano i propri messaggi di controllo utilizzando PGP, uno standard aperto di crittografia per chiavi pubbliche, che permette al sito che riceve di verificare che il messaggio di controllo sia effettivamente stato mandato dalla persona da cui risulta provenire.
= Amministrazione di base di una gerarchia =
L'amministratore di una gerarchia ha tre separati interlocutori che
dovrebbe tenere a mente quando pubblica informazioni riguardo ad
una gerarchia di Usenet: gli Utilizzatori, che potrebbero essere
interessati a leggere o a postare nella gerarchia, gli amministratori
delle news che attualmente non portano la gerarchia nei loro servers
e desiderano farlo, gli amministratori delle news che stanno gia'
portando la gerarchia e vogliono tenersi aggiornati sui suoi
cambiamenti.
L'interlocutore piu' importante e' rappresentato probabilmente dagli
utilizzatori, ma si tratta anche dell'interlocutore riguardo al quale e' piu'
difficile fare affermazioni generali, poiche' il modo di comunicare con i
potenziali utilizzatori varia abbastanza tra le gerarchie. L'utilizzatore
sara' in primo luogo interessato ad una descrizione degli intenti della
gerarchia, ad una lista dei suoi gruppi, a qualsiasi regola valida
universalmente al suo interno, ai manifesti dei newsgroups e alla
loro procedura di creazione. In genere parleranno la stessa lingua
utilizzata nella gerarchia (poiche' se non la parlassero, probabilmente
non sarebbero interessati a leggerla).
Gli amministratori delle news che attualmente non portano la
gerarchia non saranno probabilmente interessati ai dettagli come
regole particolari o manifesti dei gruppi, ma saranno anche loro
interessati agli intenti generali della gerarchia e ad ogni regola
che riguardi specificamente i siti che portino i gruppi. Avranno in
particolare bisogno della lista dei newsgroups presenti nella gerarchia
nel formato checkgroups, comunque, e preferibilmente come un file
plain-text che possano scaricare e inserire nel proprio software per le
news. Avranno inoltre bisogno di istruzioni su come processare i
messaggi di controlloper aggiornare i cambiamenti alla gerarchia,
generalmente come parte di INN control.ctl. Infine gli amministratori
delle news potrebbero non parlare la lingua della vostra gerarchia
(potrebbero per esempio gestire un news server per un grande ISP
internazionale), così potreste trovare necessario fornire le specifiche
istruzioni per gli amministratori delle news anche in inglese, se la
lingua della vostra gerarchia non e' gia' l'inglese.
Gli amministratori delle news che stanno gia' portando la gerarchia
sono soprattutto interessati a ricevere notizia dei cambiamenti operati
su di essa (di solito per mezzo dei messaggi di controllo). Desiderano
inoltre modi per controllare la loro lista dei gruppi con quella
aggiornata, in modo da poter essere di nuovo sincronizzati se
avessero perso per caso qualche aggiornamento.
Detto questo, ecco ora poche raccomandazioni specifiche:
* Abbiate un sito web. Tentate di essere sicuri che la URL per il
sito della vostra gerarchia sia stabile e non cambi, poiche' la
URL comparira' in diverse FAQs e files di configurazione che
sopravvivono per anni. Mettete tutte le informazioni riguardo la
gerarchia sul sito web e accertatevi che il sito sia attivo.
puo' essere disponibile come sito
hosting per il vostro sito web.
* Ogni volta che create un gruppo, lo rimuovete o lo rinominate
(operazione che sara' fatta tramite una creazione e una rimozione),
oppure ne cambiate lo status di moderazione, mandate
l'appropriato messaggio di controllo. Cercandolo in
sotto la vostra gerarchia, potrete controllare che il messaggio di
controllo sia stato propagato. I messaggi di controllo dovrebbero
avere nel Newsgroups header, il gruppo che viene creato o rimosso
(anche per i messaggi di "newgroup"; sara' propagato lo stesso,
nonostante il fatto che il gruppo non sia stato ancora creato
effettivamente, in quanto i messaggi "newgroup" hanno regole
speciali di propagazione), eccetto, ovviamente, i messaggi di
checkgroups, che dovrebbero normalmente essere postati al
gruppo amministrativo della vostra gerarchia e possibilmente
mandati in crosspost a news.admin.hierarchies. Non mettete un
Distribution header nel vostro messaggio di controllo, a meno che
non intendiate realmente limitare la disponibilita' dei gruppi ai siti
configurati per accettare tale distribuzione (che nella maggior
parte dei casi comunque non funziona).
* Mandate periodicamente un messaggio di controllo di
checkgroups. Se lo fate, non avrete bisogno di mandare doppi
messaggi di controllo per i cambiamenti; se qualcuno perdera' un
cambiamento, saranno aggiornati automaticamente dal successivo
messaggio di checkgroups.
Nel messaggio di controllo di checkgroups (e idealmente anche
negli altri vostri messaggi di controllo), includete un header X-* che
punti al sito web della vostra gerarchia, cosicche' la gente possa
li' trovare maggiori informazioni sulla vostra gerarchia. Non mettete
un Supersedes header nei vostri messaggi di checkgroups; alcuni
siti filtreranno e non faranno passare qualsiasi messaggio che
contenga insieme un Control header e un Supersedes header.
* Mettete la lista checkgroups *aggiornata* sul vostro sito web, come
file di plain-text (terminare il nome del file con .txt dara' questa
informazione alla maggior parte dei servers web), in modo che
possa essere agevolmente scaricato dagli amministratori delle
news.
Accertatevi che questo file sia costantemente aggiornato. Avere
una lista separata in un bel formato HTML e' spesso utile per gli
utilizzatori, ma per favore, accertatevi di fornire anche il file in
plain-text e nel formato del messaggio checkgroup, dato che la
versione HTML e' quasi del tutto inutile per gli amministratori delle
news che tentino di aggiungere la vostra gerarchia.
* Scrivete una guida per gli amministratori delle news su come
portare la gerarchia, che includa una descrizione generale.
Accertatevi che sia chiaramente indicato dove trovare le liste
checkgroups per la gerarchia. Postate periodicamente questa
guida su news.admin.hierarchies (ma non piu' spesso di una volta
al mese, e una volta ogni pochi mesi e' probabilmente ancora
meglio) e mettetela anche sul vostro sito web. Se la vostra
gerarchia usa una lingua diversa dall'inglese, scrivete questa guida
sia nella vostra lingua che in inglese, visto che l'inglese sembra al
momento essere di fatto il linguaggio internazionale degli
amministratori delle news. (Almeno, tentate di utilizzare il termine
"checkgroups", letteralmente scritto, sul sito web nella pagina
iniziale, come link per la lista checkgroups aggiornata; questa e'
l'informazione principale che la gente cerchera' e in questo modo
gli amministratori delle news potranno trovarla anche se non
fossero in grado di leggere il resto del sito).
* Scrivete una control.ctl entry per la vostra gerarchia e pubblicatela
sul vostro sito web, nella sezione per gli amministratori delle news e
nella guida. Per una gerarchia che non firmi con chiave PGP i
messaggi di controllo, questa apparira' come:
## EXAMPLE (Example Hierarchy, Olympus Mons, Mars)
# Contact: news@example.org
# URL: http://www.usenet.example.org/
checkgroups:news@example.com:example.*:doit
newgroup:news@example.com:example.*:doit
rmgroup:news@example.com:example.*:doit
La prima linea contiene il nome della vostra gerarchia, in tutte
lettere maiuscole, e poi, tra parentesi, una descrizione della vostra
gerarchia, compresa la collocazione geografica applicabile, se si
tratta di una gerarchia regionale. Poi vengono le informazioni
riguardo chi contattare riguardo la gerarchia e la URL del vostro sito
web. Infine le linee senza commento specificano il tipo di messaggi
di controllo, il sender (mittente, che dovrebbe corrispondere agli
header From e Sender dei vostri messaggi di controllo), la struttura
dei gruppi nella vostra gerarchia e la parola "doit", che dice di agire
in base a questi messaggi di controllo.
Gli amministratori delle news possono dunque semplicemente fare
copia&incolla di questi dati nei files di configurazione del loro
news server e iniziare ad onorare i vostri messaggi di controllo. Se
usate invece PGP, vedete la sezione su questo argomento.
* Usate PGP per firmare i vostri messaggi di controllo. Questo non e'
necessario per piccole gerarchie, ma se capitasse qualche contesa
sulla vostra gerarchia, o per qualche ragione questa attirasse
attenzione ostile, la gente potrebbe facilmente causare un'enorme
confusione se i vostri messaggi di controllo non sono firmati. Ci
sono piu' oltre altre informazioni riguardo questo argomento.
* Accertatevi che le informazioni sul vostro sito web siano
aggiornate! In particolare, siate *sicuri* che la lista checkgroups sul
vostro sito web sia accurata, perche' quella e' la lista da cui molta
gente partira'. Talvolta e' inoltre piu' conveniente per qualcun
processare la lista checkgroups da un sito web che processare un
messaggio di controllo (uno puo' usare per farlo strumenti come
actsync, per esempio), coi' se non e' accurata un amministratore
delle news potrebbe annullare tutti i vostri messaggi di controllo,
ricavando invece le informazioni dal sito web.
Alcune gerarchie hanno anche un news server pubblicamente
disponibile che porta quella gerarchia (questo e' particolarmente
comune per le gerarchie intese come supporto per i prodotti di una
determinata societa'). Se lo fate, siate sicuri di indirizzare ad esso sia
gli utilizzatori, sia gli amministratori delle news. Gli utilizzatori potranno
utilizzare quel server se il loro server locale non portasse la vostra
gerarchia, e gli amministratori delle news potranno utilizzare quel server
per ottenere la lista aggiornata dei newsgroups nella gerarchia,
utilizzando strumenti come actsync. Se avete un tale server
aggiungete, alla vostra control.ctl entry, la linea:
# Syncable server: news.example.org
che punta al server.
------------------------------
Soggetto: 3. Messaggi di controllo firmati con PGP
La maggior parte delle gerarchie firma in PGP i propri messaggi di
controllo. La firma PGP e' visibile nel X-PGP-Sig Header del
messaggio di controllo. Informazioni di base e istruzioni (ora in
qualche modo superate) sono a:
e il corretto formato della firma e' a:
Non avete bisogno di comprendere le informazioni contenute in
quest'ultimo link, tuttavia, almeno se state usando Unix e potete
utilizzare lo strumento esistente per generare messaggi di controllo
firmati.
Per firmare i messaggi di controllo avrete bisogno di tre cose: una
coppia di chiavi PGP, che userete per firmare e verificare i messaggi,
un implementazione PGP che possiate utilizzare, e un qualche
software per generare il giusto tipo di firma per i messaggi di controllo
per Usenet.
Se non avete ancora familiarita' con la crittografia a chiave pubblica,
questa e' una breve sintesi: una coppia di chiavi PGP consiste di due
chiavi, una pubblica e una privata. Voi firmate il vostro messaggio con
la chiave privata, che dovete tenere segreta e protetta, dato che
chiunque sia in suo possesso puo' pretendere di essere
l'amministratore della gerarchia. Darete invece la chiave pubblica a
tutti, e tutti con la chiave pubblica potranno controllare una firma e
verificare che e' stata apposta dalla chiave privata (senza poter
firmare messaggi loro stessi).
La maggior parte dei siti news di Usenet che onorano i messaggi di
controllo sono configurati per verificare i messaggi firmati con un
algoritmo chiamato RSA, che era l'algoritmo utilizzato dall'originale
implementazione PGP. Sfortunatamente, questo algoritmo e' ora
piuttosto obsoleto. Le attuali implementazioni PGP usano un algoritm
piu' recente e piu' sicuro per generare la firma (sebbene la sicurezza
addizionale sia probabilmente inutile per i messaggi di controllo di
Usenet, almeno allo stato attuale). Mentre questo non crea problemi
per la firma dei messaggi (le attuali implementazioni PGP possono ancora
utilizzare le vecchie chiavi RSA per firmare qualcosa), questo causa
problemi se iniziate ora, perche' le chiavi generate dalle
implementazioni attuali non funzioneranno con le vecchie versioni di
PGP.
Tutto cio' significa che dovete compiere alcune difficili scelte al
momento di selezionare un'implementazione PGP e di generare la
vostra iniziale coppia di chiavi. Potete usare GnuPG
, che e' probabilmente la migliore
implementazione PGP disponibile, e non occuparvi affatto di una
eventuale chiave RSA. Questo significhera' sfortunatamente che solo
i siti che anch'essi utilizzano GnuPG o un'altra attuale implementazione
PGP potranno verificare i vostri messaggi di controllo. Oppure potete
andare a , scaricare una vecchia versione di
PGP (qualcosa come la versione 2.6), e utilizzarla per firmare i vostri
messaggi di controllo: funzionera' con tutte le versioni di PGP, ma
potrebbe essere difficile da usare. (Potete anche usare una vecchia
versione di PGP solo per generare la chiave iniziale, e quindi importarla
in GnuPGP e utilizzare GnuPG per firmare i messaggi di controllo, ma
questa operazione e' complessa, e non raccomandabile per persone
che non abbiano mai toccato PGP prima d'ora. Ci sono comunque
delle istruzioni nel sito web GnuPG.)
Qualsiasi scelta facciate, seguite la documentazione della vostra
implementazione PGP per generare una coppia di chiavi. Ponete
particolare attenzione all'user ID che metterete nella vostra chiave.
Perche' funzioni con Usenet, questo user ID non deve contenere
spazi. Le due piu' comuni chiavi ID utilizzate per firmare i messaggi di
controllo di Usenet sono il nome del gruppo di amministrazione della
gerarchia (come example.config) o il sender del messaggio di controllo
(come news@example.org). Quest'ultima scelta e' la pratica migliore ed
e' raccomandata per le nuove gerarchie, sebbene sia necessario
accertarsi che l'indirizzo e-mail sia stabile e che sarete in grado di
utilizzarlo per decenni a venire.
Se state usando GnuPG, per non avere nessuno spazio nell'user ID,
dovete non immettere un nome o commento, solo un indirizzo e-mail.
(Questo ovviamente favorisce un user ID corrispondente all'indirizzo
e-mail del sender).
Resistete alla tentazione di mettere altri user IDs addizionali nella
vostra chiave. La vostra chiave dovrebbe avere un solo user ID, quello
che sara' utilizzato nelle control.ctl entries. Se c'e' qualsiasi user ID
addizionale, questo potrebbe confondere i processo di verifica PGP
con alcune implementazioni PGP e causare che i vostri messaggi di
controllo vengano ignorati.
Se state usando un'implementazione PGP recente, firmera'
automaticamente la chiave pubblica (questa e' chiamata una
"self-signature"). Se state usando un'implementazione PGP piu'
vecchia, accertatevi di fare voi lo stesso, seguendo le istruzioni del
vostro software. Le chiavi senza self-signature possono essere corrotte
in vari modi, e le recenti implementazioni PGP rifiuteranno di importarle
o di onorarle.
Ora siete pronti a creare e a firmare un messaggio di controllo. Sono
a conoscenza di due grandi implementazioni del glue software per
effettuare l'atto della firma:
signcontrol
Questa e' l'implementazione originale, di David Lawrence, del
protocollo dei messaggi di controllo firmati. Lo script che controlla
la firma e' uno script in Perrl che funziona con pgp. Richiedera'
un qualche editing per settare le informazioni sulla vostra
gerarchia. C'e' anche una shell implementation nella stessa
directory.
News::Article
Un modulo Perl, e dunque assolutamente utile se state scrivendo
il vostro software per la vostra gerarchia in Perl. Compie meno
controlli rispetto a signcontrol e in generale fa meno cose, giusto
l'atto di apporre la firma, che puo' essere la cosa piu' conveniente.
Richiede il modulo PGP::Sing del CPAN; vedere la vostra
documentazione Perl per come installarlo.
Segnalazioni di altre implementazioni, e in particolare istruzioni per
utilizzatori Windows, sono davvero benvenute. Attualmente e' di gran
lunga piu' facile firmare i messaggi di controllo su Unix perche' molti
degli utili software per farlo funzionano solo su Unix.
Una volta che avete un messaggio di controllo firmato, controllatelo
per accertarvi che venga verificato correttamente. Potete farlo con il
programma pgpverify, che viene con INN o nella stessa directory di
signcontrol, piu' sopra.
Se avete compiuto tutto questo lavoro, dovreste mettere la chiave
pubblica PGP nella nostra guida per gli amministratori di news. Per
vedere esempi di chiavi pubbliche PGP di varie gerarchie, vedere:
Dovreste anche rendere disponibile la chiave pubblica per essere
scaricata dal vostro sito web, preferibilmente come file in plain text
(far terminare il nome del file con .txt dara' questa informazione alla
maggior parte dei servers web), che puo' essere facilmente scaricato.
Inoltre cambiate la control.ctl entry che avete sul vostro sito web in
modo che ora abbia un aspetto simile al seguente:
## EXAMPLE (Example Hierarchy, Olympus Mons, Mars)
# Contact: news@example.org
# URL: http://www.usenet.example.org/
# Key URL: http://www.usenet.example.org/pgpkey.txt
# Key fingerprint = G7 11 96 E8 34 32 7E 78 01 0D 69 99 A3 8F 34 B8
# *PGP* See comment at top of file.
checkgroups:news@example.com:example.*:verify-news@example.org
newgroup:news@example.com:example.*:verify-news@example.org
rmgroup:news@example.com:example.*:verify-news@example.org
Il campo per la URL della chiave e' la URL della chiave pubblica PGP
in plain text, disponibile sul vostro sito web. La fingerprint e' il risultato
ottenuto da gpg --fingerprint o da pgp-kvc (a seconda di quale versione
di PGP state utilizzando) e viene utilizzata come controllo per essere
sicuri che la chiave scaricata sia quella giusta. Il commento *PGP*
prende senso nel contesto dello standard del file control.ctl, che ha
informazioni in cima sui messaggi di controllo firmati con PGP. E notate
che la stringa "doit" sul messaggio di controllo e' stata sostituita da
"verify", seguito dall'user ID della vostra chiave PGP (qualsiasi questo
sia)
Ora semplicemente utilizzate la vostra nuova procedura per la firma
ogniqualvolta mandate un messaggio di controllo per la vostra
gerarchia. Oh, e se state variando dall'inviare messaggi di controllo non
firmati a messaggi firmati, accertartevi di annunciarlo in
news.admin.hierarchies.
------------------------------
Soggetto: 4. Mantenere i Gruppi Moderati
Se nella vostra gerarchia esistono gruppi moderati, questo comporta
un po' di lavoro aggiuntivo rispetto ai gruppi non moderati. Piuttosto
che semplicemente contrallare se il newsgroup c'e' o no, gli
amministratori delle news debbono anche accertarsi che lo status di
moderazione sia correttamente settato, in modo che gli utilizzatori
possano postare, e i news servers devono sapere a quale indirizzo
e-mail inviare i posts in modo che raggiungano il moderatore.
Nella gestione dei gruppi moderati, e' necessario accertarsi di includere
sempre il corretto segnalatore di moderazione nel vostro messaggio di
controllo newgroup, e accertarvi che la linea della vostra lista
checkgroups termini per i gruppi moderati con "(Moderated)". (Si,
letteralmente. Non puo' essere tradotta: i software per le news allo
stato attuale cercano esattamente questa stringa). E' tuttavia utile
inviare alcuni messaggi di controllo duplicati nel caso in cui capiti di
convertire un gruppo non moderato in un gruppo moderato o
viceversa, poiche' e' piu' difficile cogliere questo cambiamento piuttosto
che la semplice creazione di un gruppo nuovo. Aspettatevi di avere
diversi utilizzatori frustrati, i cui news providers semplicemente non
riescono a fare correttamente la modifica. Potreste trovare desiderabile
redigere un messaggio standard da inviare a questi providers
spiegando chi siete e che portano gruppi della vostra gerarchia
configurati in modo non corretto.
Infine, dovete occuparvi di far arrivare i posts al moderatore. Ci sono
due modi principali di gestire questo compito, che possono anche
essere combinati. Uno e' tener aggiornato il relay system centrale di
moderators.isc.org, e l'altro e' configurare un vostro proprio relay
system che accetti le mail indirizzate al nome del newsgroup con tutti
i punti sostituiti da hypehs @ un sistema sotto il vostro controllo e
poi trasmettere questa mail al vero moderatore.
Quasi tutti i news servers che tentano di gestire di default i gruppi
moderati trasmettendo qualsiasi messaggio postato a un gruppo
moderato al nome del gruppo con tutti i punti rimpiazzati da hyphens
@moderators.isc.org. Il relay system dietro questo record DNS,
trasmette poi questi messaggi al vero moderatore. Per creare uno
di questi indirizzi, o per cambiarel'indirizzo verso cui trasmette i
messaggi, scrivere a moderators-request@isc.org. Questi cambiamenti
devono essere fatti manualmente e c'e' spesso un backlog; per
risparmiare tempo, per favore identificatevi come l'amministratore della
gerarchia per quella gerarchia e mandate preferibilmente la mail
dall'indirizzo di contatto per la vostra gerarchia (e potreste anche
trovare desiderabile firmare con PGP il messaggio se potete farlo
facilmente). Cio' nonostante siate preparati al fatto che il cambiamento
possa richiedere un certo tempo.
E' possibile configurare i news servers per trasmettere una mail da
qualche parte che non sia moderators.isc.org, ed e' ancora piu' facile
farlo come wildcard entries per le gerarchie che trasmettono tutti i post
dei propri gruppi moderati ad un particolare host invece che a
moderators.isc.org (di nuovo con il punto che cambia in hyphen).
Alcune gerarchie preferiscono fare cosi', in modo da non dover
aspettare per i cambiamenti da effettuare in moderators.isc.org, ma
rende le cose piu' difficile per gli amministratori delle news che debbono
tener traccia di questi casi speciali. Se fate cosi', dovete comunicare a
tutti gli amministratori news di aggiungere una linea come:
example.*:%s@example.org
al loro file dei moderatori, dove la prima parte e' il percorso che
identifica il gruppo nella vostra gerarchia e la seconda parte e'
l'indirizzo e-mail a cui si debbono inviare i post (% sara' sostituito
dal nome del gruppo, con i punti rimpiazzati da hyphens). Se questo
host per la trasmissione capiti che cessi l'attivita', oppure se capiti che
voi dobbiate cambiarlo, questo sara' un compito di grande peso e ci
vorra' veramente molto tempo per acchiappare tutte le occorrenze.
Quello che fanno molti amministratori di gerarchie e' di combinare
questi due approcci. Configurano il loro proprio sistema di trasferimento,
sul quale hanno diretto controllo, inmodo da poter cambiare i moderatori
di qualsiasi gruppo esistente senza avere la necessita' di contattare
moderators-request@isc.org, e chiedono ai siti di moderators.isc.org
solo di trasmettere l'indirizzo appropriato a quel server. Poi, le uniche
cose che hanno bisogno di far conoscere a moderators-request sono i
nuovi gruppi moderati o la rimozione di gruppi moderati. Questo significa
tuttavia che i posts per i gruppi moderati passano da due hops prima di
raggiungere il moderatore, invece che per uno solo, e questo puo'
causare problemi leggermente piu' difficili da diagnosticare.
Sfortunatamente, a causa del modo in cui sono distrubuite e utilizzate, le
liste alias per moderators.isc.org non possono contenere wildcard entries,
cosicché non e' possibile chiedere semplicemente di trasmettere tutti i
post di qualsiasi gruppo moderato example.* a example.org. Ciascun
gruppo deve sempre essere configurato separatamente e ciascun nuovo
gruppo moderato deve ancora essere inviato a moderators-request@isc.org
per essere processato manualmente. Si
spera che in futuro ci sia qualche sistema automatizzato facilitato per
gestire questo compito.
------------------------------
Soggetto: 5. Circa la Lista dei Newsgroups della ftp.isc.org
Mantenuta presso:
e' una copia di un file control.ctl con listate quante piu' possibili gerarchie
pubbliche che siano attivamente mantenute, insieme con la lista dei
newsgroups in un file attivo e in formato checkgroups, mantenuta con il
processare messaggi di controllo utilizzando le regole del control.ctl.
Anche, mantenuta dalle stesse informazioni, e' una raccolta di chiavi
pubbliche delle gerarchie perche' gli amministratori delle news le possano
raccogliere da un'unica fonte, in:
Queste due possono essere valide risorse per voi come amministratori di
una gerarchia in un paio di modi differenti.
Per prima cosa, alcuni utilizzatori e alcuni siti di news usano queste liste
di newsgroups per determinare quali newsgroups portare, sia utilizzando
la lista verbatim, controllando la lista per vedere se un newsgroups e' gia'
elencato prima di accingersi a aggiungerlo, o sincronizzando particolari
gerarchie per mezzo di questa lista. Avere qui la vostra gerarchia puo'
dunque aumentare il numero dei siti che portano la vostra gerarchia e
puo' rendere piu' facile per gli utilizzatori interessati raggiungere i gruppi
aggiunti al loro sito locale.
In secondo luogo, particolarmente se state utilizzando messaggi di
controllo con firma PGP, questa lista puo' essere utilizzata come verifica
che i vostri messaggi di controllo stiano funzionando correttamente. La
lista viene aggiornata una volta ogni ora, cosi' se mandate un messaggio
di controllo e dopo qualche ora il risultato non si rilfette nella lista della
ftp.isc.org, qualcosa puo' non aver funzionato (forse avete dimenticato
un Approved header, oppure per qualche ragione la firma PGP non era
valida).
Infine, molti amministratori delle news, anche se non utilizzano la
lista dei
newsgroups, usano i files di control.ctl e il file delle chiavi PGP per
configurare i loro news servers. Questo file control.ctl, e' anche compreso
tra le edizioni del INN.
Per ottenere che la vostra gerarchia sia elencata in questi files, mandate
una mail a usenet-config@isc.org. Per favore, includete la vostra
control.ctl entry, come sopra descritta, e anche la vostra chiave pubblica
PGP, o un URL da cui possa essere ottenuta (preferibile quest'ultima
opzione). Fornite anche un puntatore all'attuale lista dei newsgroups in
formato checkgroups, in modo che possano essere aggiunti alla lista
nello stesso tempo. usenet-config@isc.org ha talvolta un po' di arretrati,
cosi', per favore, calcolate un paio di settimane per una risposta.
------------------------------
Soggetto: 6. Altre risorse
Qui sono elencate alcune altre risorse di cui e' bene essere a
conoscenza se state mantenendo una gerarchia.
news.admin.hierarchies
La maggior parte delle discussioni sulle nuove gerarchie e
sull'amministrazione delle gerarchie in generale, ha luogo qui.
Normalmente non ci sono molte discussioni, solo le FAQs delle
gerarchie, ma molte persone leggono il gruppo e possono dare
aiuto e suggerimenti se postate.
news.software.nntp
Il gruppo di discussioni tecniche per i software per le news e per
i loro protocolli. I lettori di questo gruppo possono essere
capaci di
aiutarvi se avete domande riguardo la configurazione di un news
server o riguardo i dettagli del sistema con firma PGP per i messaggi
di controllo.
Archivio dei messaggi di controllo
Un archivio di tutti i messaggi di controllo newgroup o rmgroup,
utilizzato da alcuni siti per controllare se un gruppo richiesto
ha un
messaggio di controllo valido e utile come test per essere sicuri che
i vostri messaggi di controllo sono stati diffusi.
L'archivio delle liste dei newsgroups
Una raccolta di control.ctl files (che e' anche inclusa in INN) e
le liste
dei newsgroups mantenuti entro queste regole. Comprende anche
un file che descrive alcune linee guida per nominare i newsgroups,
per il formato checkgroups e su come scrivere le descrizioni dei
newsgroups.
pgpcontrol
Gia' menzionato diverse volte piu' sopra, questo e' il sito
centrale di
riferimento per l'implementazione del protocollo PGP per la firma dei
messaggi di controllo. Ha anche una lista di chiavi pubbliche degli
amministratori delle gerarchie e informazioni su come permettere la
verifica PGP dei messaggi di controllo.
news-admin.org
Un servizio di hosting per gli amministratori delle gerarchie e
per le
gerarchie Usenet che potreste considerare di utilizzare, come anche
una buona raccolta di esempi di siti web di varie gerarchie.
Config Files FAQ
Una FAQ in parte superata, che conteneva una raccolta di files
control.ctl (non utilizzate quello che c'e' ora), ma che contiene anche
utili informazioni a cui pensare se state pensando di creare una
nuova gerarchia Usenet.
Liberamente tradotto dal testo originale in inglese di:
Russ Allbery (rra@stanford.edu)