Sono passato da Postfix a Qmail sul mio server di posta. Visto quanto se ne parla bene, ho pensato di provarlo e vedere un po’ coi miei occhi.
Debian non fornisce pacchetti binari di qmail, ma solo dei pacchetti sorgente, che sono comunque estremamente facili da installare dato che la compilazione è completamente automatica.
Anche la configurazione viene fatta, in parte, automaticamente. Avendo un po’ di conoscenza su come funziona il magico mondo dell’SMTP non ci vuole molto ad avere un sistema funzionante. Credo di averci messo più o meno mezz’ora, compilazione inclusa.
Ho avuto un problema, però. Qmail non si fa tanti problemi a lanciare parecchi processi di consegna in parallelo, normalmente fa bene, ma nel mio caso mi sono ritrovato una trentina di spamassassin che tentavano di accedere al database bayes contemporaneamente, rendendo la macchina inutilizzabile. Dopo un po’ di strage di processi sono riuscito a riprendere il controllo e ho risolto aggiungendo il locking sulla regola di procmail che chiama spamassassin, cosicché ne venga eseguito uno alla volta.
Tag Archives: Linux
Altri traslochi
Ho spostato tutto il sito e il blog su un nuovo server, con un dominio nuovo di zecca. Il mio povero server a casa non ce la faceva più, ma soprattutto non mi fidavo a tenerci sopra così tanta roba senza avere il tempo di stare dietro a tutti gli aggiornamenti di sicurezza.
Per far andare Drupal su Debian woody sono necessari diversi backport, che non è detto siano sempre aggiornatissimi in fatto di sicurezza.
Questa volta sono anche riuscito a importare i post mantenendo la data originale, o meglio prima ho ripostato tutti gli articoli, poi ho modificato il database a mano. Le date sono memorizzate in secondi dall’epoca UNIX, quindi è bastato usare date “01 gen 2005 12:10″ +%s per ottenere la data da incollare in mysql.
La mia opinione sulla questione BitKeeper
Qualche giorno fa si è scatenato l’ennesimo thread infinito su linux-kernel@vger.kernel.org sul problema che BitMover (la ditta dietro al prodotto BitKeeper) non fornisce abbastanza informazioni per ricostruire completamente la storia dei sorgenti del kernel di Linux. Io non credo che questo sia un problema reale, le patch su ftp.kernel.org hanno una granularità sufficiente per la maggior parte degli usi che mi vengono in mente.
Il problema che vedo io riguarda i piccoli sviluppatori, come me. Per noi è diventato estremamente difficile seguire lo sviluppo del piccolo pezzetto di kernel di cui ci vogliamo occupare senza utilizzare BitKeeper. Qualche mese fa mi sono trovato delle modifiche (perfettamente giuste e legittime) al driver che mantengo già incluse nella release stabile, mentre le mie povere patch faticavano a passare i molti filtri. Ho dovuto rifare le mie patch perchè non si applicavano più…
Non ha alcun senso che per mantenere un driver di 50KB io debba mantenere un albero cvs (o svn o bk) di diverse centinaia di MB contenente tutta la storia possibile. Attualmente uso una soluzione fatta in casa, quasi totalmente automatizzata che mi permette di fornire patch che si applicano all’ultimo snapshot di Torvalds. Internamente uso Subversion per mantenere la storia delle modifiche ai sorgenti. E’ un buon prodotto, decisamente migliore di cvs e più intuitivo di arch (e forse anche più avanti nello sviluppo).
Quindi il mio problema non è che la gente usi BitKeeper, a loro fa comodo, a me no. Il problema è che BitKeeper consente a chi lo usa una via rapida e veloce per includere modifiche senza che ci sia un reale controllo da parte della comunità. Si sono formate due categorie, quelli che usano BitKeeper e tutti gli altri, con questi ultimi che si sbattono con scriptini e casini vari perché non possono (o non vogliono) usare un programma che ha una licenza alquanto discutibile.
Dato che la maggior parte dei piccoli sviluppatori lo fa per hobby, più gli rendi le cose difficili e meno avranno voglia di continuare il lavoro.
Chiusura della mailing list di Zena su initd.org
Ieri sera tardi ho chiuso la lista del Gruppo Zena, di cui ero il moderatore.
E’ un altro capitolo che si chiude in un lungo elenco, sembra che Linux a Genova riesca sempre a tirar fuori il peggio delle persone, causando conflitti e scontri su argomenti in gran parte irrilevanti.
Una parte del gruppo continuerà a portare avanti le attività sotto il nome di Zena, a loro auguro una buona continuazione.