Mailscanner è un ottimo sistema antispam largamente utilizzato in tutto il mondo e, fortuna per noi, rilasciato con licenza GPL. La configurazione che portiamo in esempio parte da una debian Lenny con abilitati i repository backports e volatile.
Installiamo tutto ciò di cui avremo bisogno, non proprio un’installazione minimale… (continua…)
GlusterFS è un file system distribuito in grado di scalare fino a molti petabytes ed è in grado di gestire migliaia di client. Ma si comporta benissimo anche in situazioni più… normali 
Vedremo due situazioni tipiche: una configurazione sulla falsa riga di un singolo server NFS, ed un’altra in cui i nostri dati saranno automaticamente replicati su due server GlusterFS, similarmente a quanto accade ad un sistema RAID1 per gli harddisk. (continua…)
Perché usare git se si è soddisfatti di subversion?
O, in generale, perché usare un sistema di versionamento distribuito in luogo di uno centralizzato?
Il principale motivo che potrebbe spingerci ad abbandonare svn (o cvs) per git è la possibilità
di lavorare anche off-line senza perdere i benefici tipici di un VC: commit, branch, consultazione
dei log, sono tutte operazioni che possiamo continuare a svolgere indipendentemente dalla presenza
di una connessione ad un server remoto.
Git permette di gestire più server remoti, utile in moti casi (ad esempio se si ha un server di integrazione);
è molto più pulito di svn: niente directory .svn sparse ovunque, ma solo una .git nella root del progetto;
è estremamente veloce sia nel fare branch che nella visualizzazione dei log.
Ovviamente è rilasciato con licenza GLP. (continua…)
Può capitare, per non dire “capita sempre”, che nell’arco di sviluppo di un progetto software ci si trovi nella situazione di dove scegliere quale versione di un dato prodotto/libreria utilizzare. Se, ad esempio, qualche mese fa, aveste deciso di sviluppare un’applicazione basata di django, potreste aver scelto di utilizzare la versione stabile 1.1. Tutto bene, tutto procede ottimamente, fino a quando non viene rilasciata la versione 1.2 del nostro framework preferito. Che fare? Aggiornare? Restare alla versione 1.1? Ma siamo sicuri che aggiornando django il nostro software continuerà a funzionare correttamente?
In casi come questo, ma non solo, virtualenv viene in nostro soccorso consentendoci di creare ambienti python isolati con specifiche versione delle nostre librerie/framework & c, in modo da poter testare in maniera pratica e sicura la nostra applicazione.
Vediamo un esempio pratico.
Giusto come promemoria.
A volte (tante) odio mac osx. Provo a copiare un file dal mio desktop al server samba e ottengo un bel errore:
Non posso completare l'operazione perché non disponi dei privilegi necessari per accedere ad alcuni elementi.
Interessante, controllo la configurazione di samba ma è tutto ok. Tanto per provare copio un file diverso e funziona!
Dopo una rapida ricerca trovo che il problema è dovuto ad attributi estesi associati al file che non dovrebbero essere un problema, visto che fino a “ieri” andava, ma di punto in bianco ora portano inevitabilmente al fallimento di ogni operazione.
Provato varie soluzioni, ma alla fine l’unica che ha funzionato è stata quella di rimuovere l’attributo incriminato
[10:51:59]stefano@han:~
→ xattr Desktop/onlisp.pdf
com.apple.metadata:kMDItemWhereFroms
[10:52:25]stefano@han:~
→ xattr -d com.apple.metadata:kMDItemWhereFroms Desktop/onlisp.pdf
Il comando xattr consente di interagire con gli attributi di un file, come intuibile il parametro ‘-d’ rimuove l’attributo specificato.
Prima o poi indagherò più a fondo.
In una rete mista windows/*nix sorge spesso la necessità di integrare le macchine *nix in un dominio Active Directory tipicamente già presente.
Nel caso in esame un server GNU/Linux eroga un servizio di condivisione tramite Samba e si utilizzeranno le caratteristiche proprie di questo
prodotto per inserirlo nel dominio ed avere così una gestione omogenea delle risorse.
Per ottenere il risultato che ci proponiamo, oltre a samba abbiamo bisogno di configurare correttamente anche kerberos, pam (che serviranno
per gestire l’autenticazione sul dominio) ed avere tutti i server con l’orario perfettamente sincronizzato.
PostgreSQL, contrariamente a MySQL, non possiede un proprio sistema di replica (atteso per la ver. 8.5 9.0), ma si può ovviare a questa mancanza utilizzando un meccanismo chiamato log shipping o warm standby.
In pratica, sfruttando la possibilità di archiviare i write ahead log (vedi qui e qui), è possibile avere un secondo sistema sincronizzato e pronto a partire nel caso il nodo primario dovesse cadere. (continua…)
Cosa fare nel caso in cui il server master, in un sistema master/slave, vada a “donnine allegre”? La cosa più semplice è promuovere lo slave al ruolo di master e, quando il sistema master tornerà on-line, ripristinare la situazione iniziale.
A seconda delle configurazione scelte ci possono essere due situazioni distinte a seconda del tempo in cui il nodo master resterà fuori linea. Nel caso in cui questo sia superiore al tempo in cui i bin-log (attivi anche sul nodo slave) rimangono disponibili, si dovrà necessariamente provvedere ad un ripristino da backup; in caso contrario sarà possibile configurare momentaneamente il server master come slave ed effettuare la sincronizzazione dei dati in maniera automatica. (continua…)
La configurazione attuale dei nostri server prevede una scheda di rete da dedicare alla parte pubblica e due schede in bonding per il traffico tra i server reali e virtuali.
L’idea è quella di configurare anche i containers in modo che rispecchino la situazione appena riportata.
Ovviamente facendo tutto o quasi attraverso l’interfaccia di proxmox. (continua…)
Tutti a mandare messaggi, fare micro blog via twitter… Perché? boh!
Ma lo faccio pure io, visto che tempo per cose più “serie” non ne ho 
Però perché proprio twitter quando ci sono alternative? E alternative Libere! Ecco che ho fatto uno stupido account su identi.ca, simile al noto sito di cui sopra, ma con licenza AGPLv3!
Almeno un po’ di coerenza