Ataualpa for debianers nasce il 23 febbraio 2004 con l'intento di mettere a disposizione le mie briciole di conoscenza di alcuni programmi, in evidenza Mutt e Slrn, a favore della Comunità GNU/Linux ed in particolare Debian.

Il principale contributo è Il Nirvana con Mutt, una guida che ho scritto per aiutare ad utilizzare appieno Mutt, che ritengo il miglior client di posta testuale.

Ataualpa's Fortune è il mio nutrito archivio di citazioni e aforismi, utilizzabile per alimentare la generazione di signature casuali.

Se cercate spunti per la personalizzazione del vostro sistema, nella sezione Downloads trovate vari files di configurazione.

Nei Web Links ho archiviato i contenuti web di mio interesse relativi agli argomenti GNU/Linux.

La sezione Ataualpa parla di me.

Mutt Logo revisited in vari formati

Il neozelandese Malcolm Locke ha realizzato una rivisitazione, molto ben fatta a mio avviso, del logo di Mutt.

Per consentirne l'uso in contesti diversi, ha poi creato immagini del logo in diverse dimensioni (16x16, 22x22, 32x32, 48x48, 128x128).

I file sono in formato png e possono essere utilizzati nel rispetto della licenza Creative Commons Attribution-Share Alike

Per i mutter desiderosi di rinfrescare l'immagine del proprio bastardino preferito, i loghi sono disponibili al seguente indirizzo:

mutt logo 

Grazie Malcolm!

Posted
Configurazione di Procmail (aggiornamento)

La mia rivisitazione dei file di configurazione del sistema ha prodotto, anche grazie ai consigli esposti su Procmail Tips, un aggiornamento di quelli per il filtraggio e l'indirizzamento della posta tramite Procmail.

Li trovate nella sezione Downloads.

Il file di base è .procmailrc che:

  • definisce le principali variabili ed i path,
  • verifica l'esistenza di file e directory necessari ed eventualmente provvede a crearli,
  • cura l'archiviazione in formato compresso dell'intero flusso di messaggi in ingresso,
  • nel caso di presenza di messaggi duplicati, ne dirotta una copia su una mailbox apposita,
  • destina alla mailbox desiderata la posta interna generata dal sistema e destinata all'utente,
  • esegue, tramite le istruzioni contenute in 00-rapidkill.rc, il filtraggio dei messaggi di spam certo, con eliminazione diretta o indirizzamento sulla mailbox spam a seconda dei casi,
  • esegue, tramite le istruzioni contenute in 01-general.rc, controlli formali sulla struttura dei messaggi, provvedendo a correggere eventuali errori,
  • esegue, tramite le istruzioni contenute in 02-lists.rc, il dirottamento sulle specifiche mailbox dei messaggi provenienti dalle mailing list sottoscritte,
  • esegue, tramite le istruzioni contenute in 03-friends.rc, il dirottamento sulle mailbox desiderate dei messaggi che arrivano da singoli indirizzi conosciuti,
  • esegue, tramite le istruzioni contenute in 04-spam.rc, il dirottamento sulla mailbox spam dei messaggi che Procmail prima, o SpamAssassin in via residuale, hanno giudicato come email spam,
  • dirotta infine eventuali messaggi non ancora gestiti da quanto sopra alla mailbox di default.

Con questo aggiornamento, oltre all'organizzazione del processo nei passi sopra esposti, le principali novità sono:

  • una generale sistemazione e correzione delle varie regole, anche in termini di posizionamento nei vari file (il posizionamento conta!),
  • file meglio commentati, per una loro migliore comprensione,
  • l'utilizzo di whitelist (oltre alla già utilizzata blacklist) per persone conosciute e per le quali non abbiamo necessità di mailbox dedicate,
  • regole per individuare quel particolare e sempre più frequente spam costituito da email destinate al proprio indirizzo e dallo stesso apparentemente spedite,
  • ulteriori regole di Procmail dedicate all'individuazione di messaggi probabile spam, per limitare l'utilizzo (oneroso in termini di risorse di sistema) di SpamAssassin.

La raccomandazione per chiunque voglia utilizzare i file è di personalizzarli per le proprie effettive necessità, perchè le mie esigenze non sono quelle di tutti.

.bashrc, .bash_profile, .xsession e .Xresources

Ho rilavorato ai file che il sistema ed il server X leggono per conoscere le impostazioni desiderate dall'utente.

Li trovate nella sezione Downloads.

L'arricchimento riguarda soprattutto l'inserimento di alias e funzioni che ho reperito in giro per il web, in quanto da me ritenuti utili per una più rapida ed efficiente gestione del sistema a terminale.

Per ricordare i principali alias e funzioni utilizzabili, digitando bashtips si ottiene una schermata riassuntiva.

Per fare in modo che da terminale root ci siano le stesse funzionalità, consiglio di posizionarsi nella home di root e di creare un link simbolico al file .bashrc contenuto nella propria home utente.

In tal modo, ogni volta che modificherete qualcosa nel .bashrc, automaticamente avrete a disposizione lo stesso file anche per l'utente root.

Il comando da eseguire (ripeto: dopo essersi posizionati in /root) per creare il link simbolico è:

ln -s /home/vostro.nome.utente/.bashrc .bashrc

Piccola finesse: il prompt del terminale è colorato diversamente tra utente (verde) e root (rosso). Colori diversi anche per Midnight Commander, se usato come root o come utente.

Buon bashing! 

Posted
Aggiornata la piccola guida a Mutt

Luigi Carusillo ha aggiornato la PGL Mutt, nell'ambito delle sue varie PGL (Piccole Guide Linux). 

Come da lui stesso sintetizzato: "Apportati minimi ritocchi alla configurazione e ai comandi di Mutt, la maggior parte della revisione sta nella sostituzione di Sendmail con Postfix e nell'inserimento di un capitolo sull'autenticazione."

Per chi è interessato:
PGL Mutt

Posted
GTD, Inbox Zero, Mutt

Inbox Zero nell'ambito del metodo GTD

Per chi pratica o per chi ha intenzione di praticare il metodo di organizzazione del proprio lavoro, che David Allen ha illustrato nel suo Getting Things Done (pubblicato in italiano con il titolo Detto, Fatto!), uno degli obiettivi da perseguire è quello di un'adeguata gestione del flusso di posta elettronica in arrivo sul proprio client.

Secondo Allen, la posta in arrivo è stuff (materiale) che va inserito nella gestione del flusso di lavoro per essere esaminato.

Allen scrive che le informazioni che ci piombano addosso non si possono organizzare, ma solo raccogliere ed esaminare.

Secondo Allen, quello che può e deve essere fatto è, invece, l'organizzazione e l'attuazione delle attività conseguenti le decisioni che si sono prese esaminando le informazioni arrivate e raccolte.

Per la posta elettronica, Allen consiglia di attenersi ad alcune regole di principio:

  • nell'esaminare ciascun messaggio, attuare subito l'attività conseguente da compiere se sono necessari meno di due minuti per farla e poi spostare dalla inbox il messaggio relativo (cancellare, spostare in attesa di risposta, archiviare);
  • ogni volta che si esamina la inbox, svuotarla, indirizzando i messaggi in mailbox diverse a seconda della decisione presa relativamente a ogni messaggio;
  • mai rimettere (lasciare) nella inbox un messaggio in arrivo che abbiamo già esaminato: per ciascuno avremo risposto alla domanda "qual'è la prossima attività da svolgere?" e ci saremo attivati di conseguenza.

L'obiettivo è inbox zero, termine coniato da Merlin Mann che, in argomento, ha tenuto un interessante seminario ai Google TechTalks (Mann è il gestore del sito 43folders.com).

Osservando il diagramma del flusso di lavoro proposto da Allen, se vogliamo applicarlo alla posta elettronica, dobbiamo crearci delle mailbox "speciali" in cui spostare i messaggi esaminati e che necessitano di una azione futura.

Io suggerisco questa organizzazione.

  1. Per i messaggi su cui si è deciso che ci sono attività da fare ma non subito (perchè richiedono più di due minuti, chiamati Next Action da Allen), possiamo creare due mailbox:

    • Calendarized.Action, ovvero mailbox ospitante messaggi promemoria di azioni da fare in un momento già identificato;
    • Next.Action, ovvero mailbox per messaggi promemoria di azioni da fare appena possibile
  2. Per i messaggi cui abbiamo dato seguito con un'azione (immediata o successiva) e che costituiscono promemoria del fatto che stiamo attendendo un riscontro da qualcuno, possiamo creare la mailbox WaitingFor.Action.

  3. Per i messaggi dal cui esame abbiamo identificato attività e progetti che forse un giorno decidiamo di fare, ma che adesso preferiamo tenere in incubazione possiamo creare la mailbox SomeDay.Action.

  4. Per i messaggi che invece rientrano nel materiale da archiviare possiamo organizzarci come meglio crediamo, creando mailbox per argomento trattato, per soggetto mittente, per periodo di ricezione del messaggio.

Sul lavoro, la suddivisione dell'archivio per argomento e/o progetto credo sia da preferire (magari strutturando l'archivio in modo analogo a quello carteceo). Per i messaggi in ambito privato, è utile anche l'archiviazione per soggetto.

Relativamente alle mailbox dedicate alle Next Action ed alle WaitingFor Action, potremo decidere di crearne alcune specifiche per contesto e/o tipologia.

Ad esempio, se abbiamo molti messaggi cui va dato seguito con una telefonata da fare ASAP, ci potremo creare una NextAction@Telefonare.

Se, invece, la Next Action derivante dall'esame di gran parte dei messaggi ricevuti è rispondere con un'altra email, potremo creare una mailbox NextAction@Rispondere.

Oppure, se nel nostro lavoro molti dei messaggi ricevuti contengono informazioni da leggere (es.: normativa, piani, ecc...), potremo creare una mailbox Next.Action@DaLeggere.

Ancora, per i messaggi riferiti ad ASAP Action da porre in essere con il nostro collaboratore Fritz, potremmo creare una mailbox Next.Action@Fritz.

Per quelle che abbiamo invece delegato al nostro collaboratore Fritz, potremmo creare una mailbox Waiting.For@Fritz.

Nel caso invece dei messaggi che costituiscono promemoria di attività da svolgere e che vanno calendarizzate, qualora nel nostro lavoro esse costituiscano una parte importante, potremo decidere di creare una sorta di scadenzario elettronico, ad esempio con una mailbox per ogni mese, entro cui spostare il promemoria da rivedere e "azionare" all'interno del mese stesso.

La proliferazione delle mailbox a mio avviso è tuttavia sconsigliabile, in particolar modo all'inizio dell'applicazione del metodo. Sarà la pratica che porterà ad identificare eventuali sofisticazioni necessarie. Ricordiamoci del sempre valido motto: KISS! (Keep It Simple Stupid!).

Tutte queste mailbox speciali, vanno infatti esaminate periodicamente (ed approfonditamente nel corso della cosiddetta Weekly Review), per rivedere i promemoria contenuti e FARE ciò che va fatto, al tempo opportuno.

Infine, la cancellazione (definitiva o il cestino) sarà la destinazione migliore per molti dei messaggi che abbiamo esaminato, così come per quelli che hanno esaurito il loro compito di promemoria, dopo aver soggiornato nelle mailbox suscritte.

Chi è abituato ad archiviare gran parte di ciò che gli passa sotto il naso, ha mai riguardato nei successivi 12 mesi più del 10% di quanto occupa i suoi armadi? Per molti (tutti??) la risposta è no, con la conferma che il cestino può essere il nostro migliore amico: buttare via materiale significa liberare spazio fisico (o elettronico) e, soprattutto, fare spazio nella nostra testa.

Ed il cestino vale doppio se si esercita un lavoro di natura manageriale, ove l'imperativo è fare e, ancor di più, far fare, non archiviare!

Questo, in sintesi, è il quadro entro cui vogliamo operare. Ora cerchiamo di capire come renderlo operante utilizzando Mutt come client di posta elettronica.

Applicare Inbox Zero con Mutt

La strumentazione che utilizzeremo è costituita dalle macro, grazie alle quali potremo eseguire lo spostamento del messaggio nella mailbox GTD più opportuna.

Nel nostro .muttrc inseriremo pertanto:

macro index,pager e1 "<save-message>=1.Next.Action" "Sposta in NA"  
macro index,pager e2 "<save-message>=2.Calendarized.Action" "Sposta in C.A."  
macro index,pager e3 "<save-message>=3.WaitingFor.Action" "Sposta in WF.A"  
macro index,pager e4 "<save-message>=4.SomeDay.Action" "Sposta in SD.A"  

Se abbiamo bisogno di creare delle mailbox GTD ulteriori, aggiungeremo le relative macro, seguendo lo stesso schema.

Come nota, numerando le mailbox otteniamo di farle stare in massima evidenza nell'elenco.

Impostiamo un ulteriore automatismo: quando decidiamo di delegare a qualcuno un'attività identificata esaminando un messaggio, probabilmente gli inoltreremo il messaggio stesso con la nostra richiesta di occuparsene.

Il messaggio spedito a chi deve farsi carico di un'attività è opportuno che venga automaticamente salvato nella mailbox WaitingFor.Action al momento stesso dell'invio.

In tal modo avremo nella mailbox dedicata il promemoria che ci ricorda che abbiamo delegato un compito, del cui esito attendiamo riscontro.

La strada per me più semplice per realizzare tale automatismo è quella di impostare un fcc-hook. Tale tipo di hook rientra tra quelli che richiedono un matching pattern definito sugli header del messaggio.

Pertanto, andando in editing del campo subject, inseriamo in coda al soggetto del messaggio una sigla (io ho deciso che sia WF) che possa essere riconosciuta dal fcc-hook.

Nel .muttrc inseriremo prima dell'ultimo fcc-hook (che contiene la regola di default), un fcc-hook come questo:

fcc-hook '~s ^.*WF'  =3.WaitingFor.Action

Abbiamo terminato, il resto tocca a noi!

In verità, a tale semplice gestione qualcuno aggiunge anche il labelling dei messaggi, introducendo cioè in Mutt la possibilità di abbinare ad un messaggio una stringa di testo che può essere utilizzata nella gestione successiva del messaggio (ricerche, elenchi filtrati, ecc..).

Ad introdurre tale funzionalità in Mutt, tramite una patch al codice, è stato David Champion, nel lontano marzo 2000.

Successivamente, Alberto Bertogli ha realizzato uno script che consente di utilizzare tale funzionalità senza patchare il codice di Mutt.

Prendendo spunto dal lavoro di Alberto Bertogli, Frank Barknecht ha modificato lo script per renderlo GTD-compliant.

Personalmente non sento l'esigenza del labelling dei messaggi, ma per chi vuole provare ho fornito gli indirizzi web a cui puntare. (pagine scomparse, ricercare...)

Buon lavoro con Mutt e GTD! 

Portali con raccolte di articoli sul GTD

Posted
Epson Stylus D68: collegamento tramite eth/usb print server

Ho appena acquistato un print server, grazie al quale tutti i miei PC, tramite il collegamento in rete, possono stampare sull'unica stampante di casa.

Nel resto dell'articolo spiego, per quanti volessero adottare questa soluzione, come settare il server di stampa (CUPS) ed il print server.

Il print server oggetto dell'articolo è l'Atlantis Land NetServer (codice A02-PSU).

La stampante è una Epson Stylus D68.

I PC sono equipaggiati con Debian. Buon apprendimento!

Presupponiamo che la stampante sia già regolarmente settata e funzionante quando viene collegata direttamente ad uno dei PC, tramite cavo usb.

Per inciso, la Epson D68 dispone di supporto sia tramite il driver Gutenprint (escp2-d68), sia tramite i driver Epson. L'uso degli uni o degli altri non fa differenza per quanto riguarda il funzionamento tramite il print server.

Il print server non richiede settaggio, se non la definizione di un indirizzo IP e di Subnet Mask fissi. Tale modifica può avvenire tramite una comoda interfaccia web, collegandosi all'indirizzo IP predefinito (192.168.0.1). Preciso che non è rilevante valorizzare l'indirizzo IP del Default Gateway, mentre è importante che l'IP Address e la Subnet Mask siano impostati nello stesso range di indirizzi della nostra rete locale.

Le istruzioni contenute nella confezione del print server non illustrano invece il settaggio del nostro server di stampa (CUPS) ed è qui che arriva il contributo a quanti seguiranno le mie orme.

Apriamo il frontend di configurazione di CUPS, selezioniamo Aggiungi Stampante e quindi:

  • valorizziamo a piacere i campi nome stampante (es.: EpsonD68-printserver), location (es.: Geek Cavern) e description (Stampante collegata a Print Server), poi clicchiamo Continua;
  • selezioniamo, da menu a tendina, AppSocket/HP JetDirect, come dispositivo, poi clicchiamo Continua;
  • valorizziamo il campo URI del dispositivo con la seguente stringa socket://hostname:9100, dove sostituiamo hostname con l'indirizzo IP assegnato al nostro print server (es: 192.168.1.3) e poi clicchiamo Continua;
  • selezioniamo la nostra stampante dai menu a tendina (prima la marca, poi il modello) se vogliamo utilizzare il driver Gutenprint, oppure navighiamo nel nostro disco per selezionare il file ppd del driver proprietario Epson (eksc67.ppd), se preferiamo quest'ultimo;
  • completiamo tutto cliccando su Aggiungi Stampante.

Per una verifica, sempre dal frontend di configurazione di CUPS, clicchiamo su Stampa pagina di prova.

Se funziona abbiamo finito.

Se non funziona, verifichiamo che il firewall non sia stato impostato in maniera troppo severa....

Letta così sembra una passeggiata. Purtroppo per me non è stata tale, visto che i pochissimi esempi in rete, riferiti ad altri print server (Netgear PS121), parlavano di impostare la stampante in CUPS come dispositivo IPP (e definendo l'URI del dispositivo come ipp://indirizzo:porta) o come dispositivo LPD/LPR (e definendo l'URI come lpd://indirizzo/P1/).

Poichè le feature del print server (supporta la stampa tramite IPP e LPR) sembravano confermare che il settaggio dovesse essere uno dei due, è passato un giorno prima di sbloccare l'empasse.

L'illuminazione mi è venuta utilizzando il classico coltellino svizzero: nmap. Eseguendo nmap sull'indirizzo IP del print server, ho rilevato le porte/servizi offerti da quest'ultimo:

port: 80/tcp state:open service: http  
port: 515/tcp state: open service: printer  
port: 9100/tcp state: open service: jetdirect.

In un primo momento ho pensato di aver risolto impostando su 515 la porta per l'indirizzo ipp, ma ancora niente (CUPS otteneva in risposta che il print server era occupato...??).

Ho quindi tentato l'impostazione suscritta, che alla fine si è rivelata funzionante e che lo stesso CUPS suggerisce di adottare preferenzialmente. Peccato che di tale possibile settaggio il manuale del print server non faccia alcun cenno!

Googlando alla disperata, ho anche scoperto che l'Atlantis Land A02-PSU è un rimarchiato: si tratta in effetti del LinkPro PS-1000U. Lo segnalo perchè sul sito della LinkPro, ci sono alcune pagine che potrebbero interessare (le FAQ e i driver).

Per quanti non dovessero ancora riuscire nell'impresa, suggerisco di far riferimento al servizio assistenza di Atlantis Land: sempre disponibile e professionale nelle due occasioni in cui l'ho contattato (una volta per un consiglio tecnico nella scelta del mio primo router, la seconda per la rottura dell'alimentatore, prontamente sostituito e da poco pensionato stante il passaggio ad altro router, sempre Atlantis Land).

Posted
Inserita nel Nirvana la spiegazione per Htag

Ho aggiornato ulteriormente il Nirvana con Mutt, arricchendo il capitolo dedicato alla scrittura, con l'illustrazione di come utilizzare Htag per far sì che il nostro messaggio di posta disponga in calce di una signature generata dinamicamente.

Vai al capitolo sulla scrittura del Nirvana con Mutt

PS A chi ha già navigato il Nirvana, suggerisco di far ricaricare le pagine al browser, altrimenti continuerà a vedere le vecchie pagine cachate.

Il Nirvana Con Mutt - Major Release (1.4)

Oggi vede la luce un ulteriore aggiornamento sostanziale della mia guida Il Nirvana con Mutt.

I nuovi argomenti trattati sono:

Il prossimo passo sarà l'integrazione, all'interno del capitolo dedicato alla scrittura, di un mio recente post sull'utilizzo di htag per gestire la generazioni di signature casuali (attualmente è già presente la spiegazione di come utilizzare sgrotum o fortune).

Sempre grazie a quanti scrivono per migliorare il mio lavoro e suggerire i prossimi territori da esplorare con il Nirvana.

ciao Ataualpa

PS A chi ha già navigato il Nirvana, suggerisco di far ricaricare le pagine al browser, altrimenti continuerà a vedere le vecchie pagine cachate.

Slrn, il ritorno di John E. Davis

Lo scorso 7 ottobre, la comunità di utilizzatori di slrn ha letto, sulla mailing list slrn.announce, un post di Thomas Schultz che informava di due notizie molto importanti:

  • la prima, che aveva lasciato la conduzione dell'attività di sviluppo del newsreader slrn,
  • la seconda, che a riprendere in mano il progetto sarebbe stato lo stesso John E. Davis, sviluppatore originale di slrn e suo manutentore fino alla versione 0.9.6.4.

Per chi, come me, utilizza quotidianamente slrn, si supera il timore che il progetto slrn, fermo alla versione 0.9.8.1 da molto tempo, potesse rimanere definitivamente bloccato.   Un ringraziamento a Thomas per il grande lavoro svolto ed un grazie sentito, per essersi ripreso in carico il lavoro, al prof. Davis, quale nuovo (vecchio) maintainer.

Posted