[mSQL e Web] [About] [Copertina] [Device Drivers]

Articoli


Come farsi il proprio "newsfeed personale" in Linux


Chi arriva a Linux dal mondo Dos/Windows e` probabilmente abituato a leggere le news di usenet in uno di due modi...:

La lettura delle news offline permette di risparmiare parecchio tempo di collegamento, e quindi bolletta TUT (e a maggior ragione se si chiama in intersettoriale o interurbana...!), quindi e` una frequente richiesta su it.comp.linux e altri gruppi dedicati a Linux quella di "come faccio a leggere le news offline in Linux"?

Linux offre pero` anche un'architettura alternativa, piu` tradizionale, quella del "(leaf) newsfeed", che puo` essere assai preferibile ad entrambi i paradigmi suddetti. Vediamo un po' meglio cosa ci sta dietro...

Le news, come la mail e altri "sistemi" di comunicazione, hanno un'architettura a molteplici livelli; semplificando un minimo possiamo qui identificarne tre:

Naturalmente ciascuno di questi sottosistemi puo` in qualche misura arrogarsi anche i compiti di altri (o per metterla in positivo, "collaborare":-), ma concettualmente i problemi sono separati, o meglio, "separabili".

Il sottosistema "trasporto" si colloca al livello "applicazione", il piu` alto dello stack TCP/IP (che non e` completamente eguale, ricordiamolo, allo stack ISO OSI...), quindi puo` a sua volta fare uso di tutti i livelli inferiori di questo stack. Fra i protocolli offerti dallo stack TCP/IP ce n'e` uno, l'NNTP, che e` specificamente orientato al trasferimento di NetNews, ma nulla obbliga ad usare proprio solo quello; la classica alternativa ad NNTP, l'uso di pacchetti di news compresse da trasferire secondo qualsiasi protocollo di trasferimento files (ma di solito con un qualche sottoprotocollo di UUCP), presenta vantaggi e svantaggi:

slurp, suck, e altri sistemi meno evoluti (come il vecchio, semplice nna), usano NNTP come protocollo di trasporto, per cui gli host fornitori di news non hanno neppure bisogno di sapere che questi programmi esistono (si comportano come "newsreaders"); essi (almeno nelle versioni recenti) collaborano col sottosistema di gestione onde evitare duplicazioni nel trasferimento.

Una volta che le news sono arrivate sul mio sistema, occorre un qualche software di gestione che le smazzi nei vari newsgroups, mi cauteli dai duplicati, provveda all'"expire" quando occorre, e svolga le N altre funzioni che si chiedono oggi a un buon sistema news, come la generazione dei NOV "News OverView" che riassumono le caratteristiche di ciascun messaggi facilitando l'opera dei programmi di interfaccia-utente per lettura/scrittura news. I due principali programmi di gestione news (NHA, News Handling Agent) oggi diffusi sono INN e cnews. cnews ha una storia assai piu` lunga, risalendo (attraverso l'antenato B-News) agli "albori" di Usenet; ha maggior facilita` per la gestione di sistemi non pienamente connessi a Internet fulltime, e` piu` orientato alla tradizionale architettura Unix (tanti programmilli piccoli piccoli, shell script per tenerli insieme tutte le volte che cio` sia compatibile con le prestazioni); INN e` piu` nuovo, piu`, mi pare, "monolitico" -- forse meglio documentato, e piu` adatto alla gestione di siti molto grandi che non a macchine con pochi utenti (o uno solo...!) e connessioni alla rete occasionali (dial-up).

Secondo me INN si presta meno a "tampicciare", quindi resto con cnews che conosco assai bene (non di rado ho pompato news in cnews basandomi su _floppy_ come protocollo di trasporto -- "sneakernet":-) -- basta, ed e` facile!, massaggiare i dati al formato che si attende, e puoi proprio farlo funzionare, se occorre, a spago e scotch...:-). Comunque immagino che INN sia una scelta altrettanto valida, per chi lo preferisce.

Infine c'e` uno, o piu`, "News User Agents" -- programmi che l'utente, lettore e scrittore di news, usa direttamente per accedere al database netnews. Il piu` semplice, a seconda dell'architettura de database, potrebbe essere...:

more /var/spool/news/it/comp/linux/847

(basterebbe "cat" invece di "more", ma solo se si ha uno scroll-back sul proprio terminale...:-). Questo da per scontato che ogni post sia tenuto su di un file di testo separato, e che la struttura dei newsgroup sia riflessa in una gerarchia di directory; questa, in effetti, e` la strategia che usano sia cnews sia INN, nonche` la piu` compatibile con il tradizionale approccio Unix (altri dati ausiliari necessari alla gestione, come il NOV, la "storia" dei post ricevuti, eccetera, sono naturalmente mantenuti in altri file "paralleli" a quelli dei post veri e propri). Al limite si puo` usare un filesystem alternativo, compresso e/o ottimizzato per tenere tanti file piccolissimi, istallandolo opportunamente nel kernel (livello 2.0 e oltre) e "invisibilmente" al gestore news.

In realta` oltre all'accesso ai files i NUA forniscono molte funzioni a valore aggiunto, come tenere traccia dei messaggi gia` letti per non presentarli altre volte, i "killfiles" che permettono di non vedere neppure messaggi i cui autori o argomenti ci consentono di stabilire a priori che gia` c'interessano, e cosi` via.

Qui, comunque, la scelta resta enorme. Una volta B-News includeva un programmillo "readnews" che faceva poco di piu` del suddetto ``more'':-); ma quasi subito usci` rn, uno dei primi capolavori di Larry Wall (piu` tardi padre del Perl), e il mondo non fu piu` lo stesso.

Normalmente oggi i NUA accedono alle news via NNTP (quindi richiedono che il NHA fornisca un demone server NNTP -- in cnews, questo va istallato "in addizione" allo schema base), anche se resta possibile come ottimizzazione l'accesso diretto in lettura ai dati su disco (locale -- se e` montato NFS, e` una _pessimizzazione_ rispetto all'uso di NNTP, non una ottimizzazione:-)

Oggi normalmente i NUA *NON* conservano un complesso database di info ausiliarie sulle news, visto che il NOV esegue bene questa funzione ed e` integrato anche in NNTP -- viceversa conservano info sulle preferenze e la storia dello specifico utente, com'e` giusto (la U di NUA...:-). La scelta di fondo sta fra:

Un'altra dirimente in ciascuna categoria e` che ci sono programmi solo grafici, che quindi richiedono X (netscape, knews), altri con modalita` di solo testo, altri ancora con entrambi i tipi d'interfaccia. Le funzionalita` inoltre variano ampiamente -- strn e slrn ad esempio offrono il concetto di "scoring", cioe` la possibilita` di avere un'euristica di "punteggio" per ogni articolo basato su criteri definiti dall'utente, per presentare gli articoli piu` verosimilmente "interessanti"; altri offrono killfiles (e autoselect) molto ma molto semplificati, pero` velocissimi perche` "precompilati"; e via elencando.

Ciascuno avra` le sue proprie preferenze... io sono affezionato a nn, programma non nuovissimo ma secondo me tuttora validissimo, anche se la complessa struttura interna ne rende difficili continui aggiornamenti e di conseguenza manca di funzioni che oggi secondo me sono divenute indispensabili (ad esempio un "filtro antispam" per eliminare qualsiasi articolo che sia postato su piu` di, ad es., quattro gruppi alla volta; in trn questo si ottiene facilmente grazie alla generalita` del suo killfiling, usando come regular expression di filtro la presenza di quattro o piu` virgole sulla linea Newsgroups negli header...!).

Riassumendo, dunque, la mia soluzione preferita per avere un newsfeed dei gruppi che mi interessano sulla mia Linux Box casalinga e` composta di:

Fra i molti vantaggi di un'architettura di questo genere c'e` la possibilita` di ottenere feed dei gruppi d'interesse da _molteplici_ siti-server, garantendo grazie alla ridondanza di non perdere alcun articolo (slurp e cnews collaborano, grazie al concetto di "history", per garantire che nessun articolo verra` mai prelevato due volte).

Naturalmente, e` importante organizzare le successive "slurpate" per cercare di prendere ciascun post dal server "piu` vicino", ma slurp offre varie funzionalita` atte all'uopo. Un altro elemento che e` importante organizzare bene, in un setup di questo tipo, e` quello di garantire che i propri post vengano istradati correttamente al server preferito (meglio, qui, evitare le duplicazioni... su gruppi "moderati", in particolare, per garantire che il moderatore non si trovi nella posta molteplici copie del nostro post!), utilizzando (fuori linea e opportunamente) il "mini-inews" che fa parte del pacchetto nntpd o altro programmillo analogo (si tratta per fortuna di una funzionalita` estremamente semplice). cnews ci aiuta in questo organizzando in vari direttori 'out.going' le news destinate a essere passate a vari server, ma bisogna settare correttamente i parametri (nessun "batching", uso di uno specifico programma di trasporto, eccetera).

La ridondanza controllata del traffico delle news e` cruciale per la sua rapidita` e robustezza, e le architetture "a backbone" che sono ormai diventate quasi universali per la lettura delle news non la permettono, mentre questi "leaf newsfeed", se configurati e gestiti a puntino, si`.

Non occorre poi dire che il vantaggio e` enorme se le news su una data macchina Linux (o cluster di macchine in rete locale) le leggono un certo numero d'utenti... magari ciascuno con il suo NUA preferito, anche tutti diversi l'uno dall'altro; la macchina o cluster, arrangiando le cose in questo modo, prelevera` e terra` (per il tempo scelto, sinche non giunge il momento dell'"expire") una e una sola copia di ciascun post dei gruppi di interesse, del tutto indipendentemente dal numero di lettori.

di Alex Martelli

[mSQL e Web] [About] [Copertina] [Device Drivers]