In this article we will configure our server for authenticated smtp.
In the previuos part we have alredy setup database and tables.
Continue reading »
Dic 092014
Set 102014
(I have written this article in english since I wasn’t able to find any updated guide about this subject in any language).
DISCLAIMER. this is a very basic configuration. Not intended for production environment. Use at your own risk.
I have a small mailserver handling very few domains with mailboxes for may friends and relatives an it have been working fine for the last 8 years.
But it is based on the old CentOS 5 + sendmail and I think it is time to upgrade!
So, in order to test the new future configuration, I have performed a CentOS 7 minimum install on a virtual machine and tried to configure the minimum amount of packages to have it working.
Now let’s start!
Set 272013
Nell’articolo precedente abbiamo visto il modo d organizzare i filesystem delle VM come volumi LVM.
Ora vedremo come questo renda possibile effettuare backup a caldo delle VM in esecuzione.
Per effettuare un backup sarà sufficiente:
- effettuare uno snapshot del volume
- convertire lo snapshot in un immagine compressa
- rimuovere lo snapshot
Ecco un semplicissimo script nel quale a dire il vero non sono implementati controlli sui parametri passati, ma che ha l’indubbio vantaggio di funzionare perfettamente: Continue reading »
Set 252013
La virtualizzazione presenta numerosi vantaggi legati alla condivisione delle risorse fisiche.
Memoria, potenza di calcolo, storage, networking possono essere condivisi da più macchine virtuali andando a sfruttare in maniera ottimale quanto messo a disposizione dal server su cui è in esecuzione l’hypervisor.
A livello di networking la configurazione base prevede che una singola scheda di rete sia condivisa da più server logici. Continue reading »
Set 242013
Qualche giorno fa la versione 2.1 di pfSense è uscita dalla fase di “release-candidate” ed è stata finalmente rilasciata.
Al momento credo si tratti di una delle pochissime firewall-appliance a supportare pienamente IPV6 e rilasciata con licenza open-source.
In un precedente articolo avevo esplorato alcune delle caratteristiche di questo prodotto. Continue reading »
Giu 102013
Tutti gli amministratori di sistema sanno qual’è la funzione del paging (swapspace).
Nato come metodo di protezione negli anni in cui la RAM era una risorsa preziosissima sui sistemi server, ha cambiato via via connotazione, diventando uno strumento di ottimizzazione delle prestazioni.
Forsenontuttisannoche i sistemi LINUX usano una politica molto aggressiva nel tentativo di ottimizzare le risorse disponibili. Ogni risorsa non utilizzata è considerata uno spreco.
Se osservate l’occupazione di RAM in un sistema LINUX, vi accorgerete che la memoria libera è sempre poca. In effetti la memoria non utilizzata è considerata dal kernel come uno spreco e, come tale, va evitato. Per questo motivo viene impiegata come cache/buffer per aumentare le prestazioni di lettura/scrittura dello storage.
Nei kernel della serie 2.6 questo concetto si spinge oltre: non solo viene utilizzata la RAM libera, ma il sistema cerca di ottenerne altra con una politica molto aggressiva.
Tale politica consiste nel mandare in paging nella memoria virtuale alcune parti di memoria non utilizzate di recente come quella dei processi in “idle” cioè che pur essendo in esecuzione, non stanno impegnando la CPU di sistema. In questo modo si può riutilizzare la memoria precedentemente allocata per incrementare le prestazioni complessive della macchina.
L’aggressività è regolabile attraverso il parametro swappiness del kernel. La wikipedia (verificate il link precedente) riporta l’informazione errata che con un valore zero il sistema si comporta in maniera assolutamente rispettosa dei processi in idle, utilizzando il paging solo in caso di reale necessità per evitare l'”out of memory”.
Non è così. Purtroppo impostando a zero tale parametro, il sistema continua a swappare alcuni programmi im esecuzione.
Infatti il kernel calcola in questo modo la tendenza ad utilizzare lo swapping:
swap_tendency = mapped_ratio/2 + distress + vm_swappiness;
Come vedete il terzo parametro vm_swappiness azzerato non è sufficiente ad annullare la tendenza nella formula. Se la tendenza raggiunge un valore > 100 il kernel reclamerà memoria dai processi in esecuzione. Il primo parametro mapped_ratio indica la percentuale di memoria mappata, il secondo distress misura la difficoltà del kernel nel liberare memoria. Quando il kernel decide di reclamare memoria la distress sarà zero, se ci saranno successivi tentativi il valore si eleverà progressivamente fino a 100.
Come dobbiamo fare se abbiamo la necessità di inibire l’uso dello swapping se non in caso di memoria di sistema effettivamente scarsa?
Purtroppo non c’è alcun modo. Googlando su internet troverete un sacco di persone che hanno posto la stessa domanda.
La risposta standard di alcuni individui piuttosto saccenti è del tipo “Pretendete di sapere come va utilizzata la memoria meglio di chi ha scritto il kernel del vostro sistema? Lasciate che il vostro sistema si gestisca da solo e lo farà per il meglio!”.
Tali risposte sono a mio avviso di una cecità clamorosa. Non metto in dubbio l’ottimo lavoro svolto dagli sviluppatori del nostro kernel preferito.
In linea di massima il sistema fa un ottimo lavoro per sfruttare al massimo le risorse, ma non si può generalizzare.
Vi espongo un caso concreto per il quale la scelta del kernel di swappare i processi non è assolutamente una buona idea.
Siamo su un server che funge da hypervisor KVM con macchine virtuali poco attive e parametro swappiness=0.
Con riferimento al precedente articolo, ecco qual’era la situazione durante l’esportazione delle immagini delle macchine virtuali:
[root@kvm backup]# free
total used free shared buffers cached
Mem: 7801732 5711072 2090660 0 53984 1507288
-/+ buffers/cache: 4149800 3651932
Swap: 9214968 1540844 7674124
A fronte di una quantità esorbitante di memoria libera di cui una parte utilizzata per la cache, abbiamo uno swapfile che è cresciuto fino a oltre 1,5GB.
Alcuni processi in esecuzione sono stati “paginati” nella memoria virtuale.
Quali? Purtroppo la scelta del kernel è caduta su……. le macchine virtuali in esecuzione!
Ho potuto verificarlo lanciando il comando smem.
Ecco quali erano i processi che utilizzavano lo swap:
[root@kvm backup]# smem PID User Command Swap USS PSS RSS ......... ......... 14353 root /sbin/dmeventd 0 16616 16778 17904 1661 named /usr/sbin/named -u named 0 17708 17807 18752 2480 qemu /usr/libexec/qemu-kvm -name 115404 510852 511596 677636 2353 qemu /usr/libexec/qemu-kvm -name 159656 868056 868880 907940 12114 qemu /usr/libexec/qemu-kvm -name 394384 1026608 1027327 1030820 2535 qemu /usr/libexec/qemu-kvm -name 445992 1615800 1616581 2217232
Effettivamente erano processi che non stavano lavorando molto.
Ma una di queste macchine virtuali contiene il server su cui gira questo blog. Una macchina virtuale con la memoria swapping ha prestazioni talmente scarse da essere assolutamente inutilizzabile! Infatti, tentando di collegarsi via web al sito in quel momento, il browser andava in timeout.
Quindi, pur non pretendendo di di sapere come deve essere impiegata la RAM meglio di chi sviluppa il kernel, vorrei che, almeno in alcuni casi particolari, fosse possibile evitare il paging in virtuale di alcuni processi o, al limite, imporre al kernel di utilizzare lo swapspace solo in caso di critica mancanza di memoria.
Purtroppo non mi risulta che sia possibile configurare il sistema con le caratteristiche di cui sopra, quindi ho dovuto ricorrere ad una soluzione molto pericolosa: disattivare lo swap.
Con oltre 2 GB di memoria libera non mi aspetto problemi di sorta, l’hypervisor ed i pochi servizi in esecuzione non avranno mai necessità superiori.
Ma è comunque una soluzione pericolosa da non utilizzare assolutamente in server in produzione.
Il sistema gira senza paging da un paio di settimane e le prestazioni delle macchine virtuali sono tornate ad un buon livello, ma vorrei che ci fosse un modo meno rischioso per ottenere lo stesso risultato.
Fabrizio Vettore
Giu 032013
http://blog.vettore.org/
Non sono mai stato un sostenitore di LVM.
Nelle installazioni server lo evito come la peste perché, a fronte di qualche indubbio vantaggio, vi è il rischio concreto di dover profondere un impegno aggiuntivo nel recupero dei dati nelle situazioni di disaster-recovery.
Per questo motivo solitamente opto per una normalissima partizione EXT4 con il mountpoint di root :-).
Ma addentrandomi nel mondo di KVM-qemu come già visto nel mio precedente articolo, mi sono reso conto della grande utilità di gestire le immagini delle macchine virtuali come volumi logici.
Mag 242013
Nelle scorse settimane ho effettuato alcuni test di compatibilità tra nuove macchine con installato il sistema Windows 8 professional e le configurazioni del nostro dominio.
Le ultime release dei sistemi Microsoft (Windows 7, Vista) in passato non avevano evidenziato particolari problematiche e mi aspettavo che anche questa volta sarebbe filato tutto liscio.
Purtroppo non è stato così….
Primo problema: le policy relative all’impostazione del proxy server non vengono applicate. Continue reading »
Mar 252013
E’noto che il sistema documentale Alfresco è stato uno dei primi ad implementare CMIS.
Per chi non lo sapesse, CMIS (Content management interoperability service) è un protocollo standard di interscambio di dati documentali.
In teoria conoscendo tale protocollo è possibile interfacciarsi con tutti i sistemi che lo supportano e quindi, per esempio, effettuare operazioni sugli oggetti contenuti (per la maggior parte documenti o cartelle) quali modifica degli attributi, download, upload etc. etc.
Dovendo affrontare una migrazione ho immaginato che la strada più facile per trasferire il contenuto dal vecchio sistema documentale al nuovo fosse appunto l’utilizzo di CMIS.
Mettendomi all’opera mi sono subito scontrato con un problema: alcune caratteristiche del documento in Alfresco non sono definite come “properties”, ma come “aspects” (aspetti). E non sono caratteristiche trascurabili!
Parliamo, ad esempio del titolo (title) e della descrizione (summary).
Senza riuscire a trasferire tali caratteristiche sarebbe stato inutile iniziare la migrazione.
Ma qual’è il problema?
Nov 082012
In linea di massima non ho nulla contro l’anonimato su internet ed apprezzo sistemi come TOR.
Ma ci sono risorse per le quali vedo pochissime buone ragioni per accedere anonimamente e contemporaneamente tantissime cattive ragioni per farlo.
Vi faccio l’esempio di un sito di e-commerce: non vedo tanti buoni motivi per nascondere la provenienza del visitatore, anche se probabilmente ve ne è qualcuno più che lecito.
Ma so per certo che se dovessi tentare acquisti truffaldini farei di tutto per nascondere le mie tracce.
Purtroppo bloccare l’accesso ad un server dalla rete TOR non è semplice come bannare un range di IP. Tale rete è dotata di migliaia di nodi distribuiti per il mondo.
Tecnicamente l’unica difficoltà è procurarsi la lista aggiornati di tali nodi.
A questo scopo, dopo una breve ricerca su internet, ho trovato alcuni siti che visualizzano lo stato dei proxy appartenenti a TOR.
Con il semplicissimo script PHP che vedete di seguito (scritto di corsa senza badare allo stile 🙂 ) si può scaricare la lista completa in un file di testo filtrando la pagina HTML
Avendo l’elenco ci sono vari sistemi per bannare gli IP.
Per esempio si può creare un apposito file .htaccess per il sito.
Oppure se avete fretta è sufficiente da shell:
for i in `cat tor.txt`; do /sbin/iptables -I INPUT 1 -s $i -j DROP; done
Attenzione che quest’ultimo metodo se il server ha numerosi accessi può portare ad un considerevole utilizzo della CPU perchè la lista è formata da migliaia di voci e ad ogni connessione il firewall dovrà effettuare la ricerca sull’intera sequanza per decidere se il pacchetto può passare.
L’intera procedura può essere automatizzata e messa in CRON per mantenere l’elenco aggiornato.
Funziona? Direi di si: provate ad accedere a quasto sito usando TOR 🙂 (disattivato sul nuovo server)
<d>