Ecco il codice di una bella funzione PHP che genera delle comode human password:

function humanPass($length = {
$password = '';
$conso=array('b','c','d','f','g','h','j','k','l','m','n','p','q','r','s','t','v','w','x','y','z');
$vocal=array('a','e','i','o','u');
srand((double)microtime()*1000000);
for($i=1; $i<=$length; $i++) {
if ($i % 2) {
$password.=$conso[rand(0,count($conso)-1)];
} else {
$password.=$vocal[rand(0,count($vocal)-1)];
}
}
return $password;
}

Che cosa fa? Genera una stringa composta da $length caratteri composta da consonanti e vocali equamente alternate.

Se certe consonanti o vocali ci sono antipatiche basta rimuoverle dai due array e non verranno usate.

Ripeto: non è un sistema per generare password sicure quindi se la vostra Bibbia detta policy ferrer ignorate questo mio post.

Premesso che MySQLTuner non fa miracoli ma semplici ottimizzazioni, vediamo come installarlo:

apt-get install mysqltuner

Adesso con un semplice mysqltuner lanciamo il nuovo tool:

>> MySQLTuner 0.9.0 - Major Hayden
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:
-------- General Statistics --------------------------------------------------
[!!] There is a new version of MySQLTuner available
[OK] Currently running supported MySQL version 5.0.51a-24+lenny4-log
[OK] Operating on 64-bit architecture
-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4M (Tables: 1311)
[--] Data in InnoDB tables: 300M (Tables: 2275)
-------- Performance Metrics -------------------------------------------------
[--] Up for: 17h 28m 59s (6M q [97.770 qps], 18K conn, TX: 11B, RX: 1B)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 2.6M per thread and 106.0M global
[OK] Maximum possible memory usage: 368.5M (9% of installed RAM)
[OK] Slow queries: 0% (2/6M)
[OK] Highest usage of available connections: 11% (11/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/4.7M
[OK] Key buffer hit rate: 99.2%
[OK] Query cache efficiency: 93.5%
[!!] Query cache prunes per day: 362758
[OK] Sorts requiring temporary tables: 0%
[!!] Joins performed without indexes: 5599
[!!] Temporary tables created on disk: 78%
[OK] Thread cache hit rate: 99%
[!!] Table cache hit rate: 0%
[OK] Open file limit used: 0%
[OK] Table locks acquired immediately: 100%
[!!] InnoDB data size / buffer pool: 300.1M/8.0M
-------- Recommendations -----------------------------------------------------
General recommendations:
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 64M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
table_cache (> 128)
innodb_buffer_pool_size (>= 300M)


Il risultato è più che eplicito.
MySQLTuner mi dice che vanno aggiunte o modificati i valori, delle seguenti variabili:


query_cache_size (> 64M)
join_buffer_size (> 128.0K, or always use indexes with joins)
tmp_table_size (> 32M)
max_heap_table_size (> 16M)
table_cache (> 128)
innodb_buffer_pool_size (>= 300M)


Edito il file di configurazione di MySQL (in Debian /etc/mysql/my.cnf) e lo modifico come suggerito.
Fatta la modifica va ovviamente riavviato il servizio MySQL.

Vedete miglioramenti?

Ecco la soluzione:

sudo add-apt-repository "deb http://archive.canonical.com/ lucid partner"
sudo apt-get update

Finito! Adesso scegliamo il package più adatto tra sun-java6-jdk e sun-java6-jre.
Io ho optato per un secco:

sudo apt-get install sun-java6-bin

Bye bye

Il database più diffuso in ambito opensource è MySQL forse perché fa parte del mitico quartetto LAMP o semplicemente perché all’epoca era il dbms più veloce della storia… Chissà quale sarà il futuro di MySQL, ma in questo post è meglio parlare del presente.

Di solito chi ha a che fare con MySQL e vuole salvare i preziosi dati contenuti al suo interno, effettua un backup del database (o dei databases) e salva il dump da qualche parte.
Nulla da eccipere a questo modus operandi.
Ma se il db è grande quanto spazio occupa un backup? Quanto tempo ci si impiega a fare un dump?
Mi è capitato che durante un backup di MySQL l’utilizzo delle risorse schizzasse alle stelle e quindi mi sono messo alla ricerca di un sistema di backup degno di chiamarsi tale e la soluzione è stata ZRM fro MySQL.
Zmanda Recovery Manager (ZRM) for MySQL è un tool che permette di:

• effettuare backup incrementali o full
• avere una gestione centralizzata dei backup
• ricevere notifiche via e-mail, RSS ed HTML sull’esito dei backup
• effettuare backup compressi e criptati
• ripristino dei backup in modo facile
• …e molto altro ancora!

Per altri features ed informazioni consiglio di leggere il WiKi.

In questo primo post vedremo come configurare un backup di un server MySQL che si trova sulla stessa macchina dove risiede MySQL. Ovviamente il backup potrà essere salvato su una partizione NFS o su una chiavetta USB ma in sostanza ZRM e MySQL sono sulla stessa macchina.Nel prossimo articolo vedremo come fare un backup di un server MySQL remoto.

Procediamo con l’installazione, ovviamente su Debian.
Nei repository Debian non c’è il pacchetto (eresiaaaa!) ma dal sito possiamo scaricare il comodissimo .deb:

http://www.zmanda.com/download-zrm.php

Basta selezionare l’ultima release (ad oggi la 2.2) e nella pagina successiva possiamo fare il download del pacchetto  mysql-zrm-client_2.2.0_all.deb.

Prima di installarlo abbiamo bisogno di alcuni software a corredo: perl-DBI e perl-XML-parser.

Installiamo:

apt-get install libxml-parser-perl libdbd-mysql-perl

Se tutto è andato a buon fine installiamo ZRM con:

dpkg -i mysql-zrm_2.2.0_all.deb

Adesso abbiamo ciò che ci serve, ma per fare i backup incrementali abbiamo bisogno che MySQL scriva il suo utilissimo logbin.
Per abilitare questa opzione, basta editare /etc//mysql/my.cnf e decommentare:

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M

Adesso il file va salvato e si deve riavviare il server MySQL.

I file di configurazione si trovano nella directory /etc/mysql-zrm, andiamo a vedere cosa c’è dentro:

• mysql-zrm.conf
• mysql-zrm-release
• mysql-zrm-reporter.conf
• RSS.header

Di vitale importanza sono i .conf, perché mysql-zrm-release ci dice che versione abbiamo e RSS.header è autoeplicativo, serve per l’RSS generato dal sistema di backup.

Dentro la directory /etc/mysql-zrm possiamo creare una nuova directory e dentro copiare i .conf appena illustrati.
Ciò ci permette di avere vari set di backup che hanno delle configurazioni proprie ed in più ereditano quelle presenti sotto /etc/mysql-zrm.
Esempio pratico: se tutti i database hanno la password di root identica possiamo specificare username e password nel file /etc/mysql-zrm/mysql-zrm.conf e non nel file mysql-zrm.conf presente nella directory del set.

Passiamo dalla teoria alla pratica.
Voglio fare in modo che venga fatto un backup di svariati server che hanno in comune:

• la password di root di MySQL
• la directory di destinazione dove salvare i file
• il tipo di backup
• uso di routines e quindi il backup delle stesse
• la directory dove sono salvati i logbin di MySQL
• la directory temporanea
• l’indirizzo e-mail sul quale riceve le notifiche
• il tipo di report
• il path dove salvare i report html
• la URL dal quale consultare i report html
• il path da dove prendere l’header per l’RSS

Detto questo avremo che il file /etc/mysql-zrm/mysql-zrm.conf conterrà (nel mio caso, mi raccomando personalizzate i parametri) questo:

backup-mode=logical
destination=/mnt/nfs/mysql-zrm
routines=1
mysql-binlog-path="/var/log/mysql"
tmpdir=/tmp
mailto="info@ideafactory.it"
html-reports=backup-status-info,backup-performance-info
html-report-directory=/var/www/mysql-zrm/reports/
webserver-url=http://backup.ideafactory.it/reports/html/
rss-header-location=/etc/mysql-zrm/

Adesso mi creo il file di configurazione per il set che chiamerò ”silver”  e quindi creerò la directory /etc/mysql-zrm/silver ed il file mysql-zrm.conf al suo interno conterrà (ripeto: nel mio caso!) :

comment=Silver
backup-level=0
all-databases=1
user="root"
password="superpasswordsegreta"
retention-policy=7D
host="localhost"
port=3306
socket=/var/run/mysqld/mysqld.sock

Ci siamo. Proviamo ad eseguire un backup di prova con:

mysql-zrm-scheduler --now --backup-set silver

Ovviamente a me il set si chiama silver…

Prima di spiegare i vari comandi penso sia il caso di illustrare i parametri di configurazione.
Maggiori dettagli si trovano nel capitolo dedicato ai parametri dell’ottimo manuale di ZRM.

Il set “silver” fa un backup completo (backup-level=0) di tutti i database (all-databases=1)  presenti sul server locale infatti ho chiamato il set silver proprio come il server così rende l’idea che il backup è di tutti i database presenti.

Adesso proviamo a dare un backup incrementale.

Non serve editare il file di configurazione del set, perché se passiamo il parametro da linea di comando backup-level=1 viene ignorato quello presente nel file di configurazione. Proviamo:

mysql-zrm-scheduler --now --backup-set silver --backup-level=1

Non vengono fuori errori? Avete ricevuto la comoda e-mail?

Adesso è il caso di fare qualche strage al database e provare a fare un ripristino ma prima vediamo un report dei backup effettuati con il comodo comando:

mysql-zrm-reporter --show backup-status-info

Sotto forma tabellare comparirà un comodissimo riassunto che qui non riporto per motivi di formattazione ma è ben visibile nella documentazione.

Bene, facciamo fuori un database! L’ho appena fatto con un DROP DATABASE…!

Adesso vediamo come ripristinarlo.

La prima domanda è “che backup ho del set a cui apparteneva il defunto database?” La risposta viene da qui:

mysql-zrm-reporter -show restore-info --where backup-set=silver

Dalla lista scelgo il backup corretto è con un semplice:

mysql-zrm --action restore --backup-set silver --source-directory /mnt/ibm/mysql-zrm/silver/20100325214251

Abbiamo riportato in vita il db defunto partendo dallo snapshot posizionato nella directory illustrata dal report!

Se abbiamo cancellato 2 database e ne vogliamo ripristinare solo uno? Beh le opzioni offerte sono molteplici e la guida sul recovery presente nella documentazione ci mostra comandi per risolvere anche i casi disperatissimi!

Fin ora abbiamo visto come fare un backup e come ripristinarlo, una volta scelta la policy più appropriata alle nostre esigenze è il caso di schedulare i backup:

mysql-zrm-scheduler --add -interval daily --start 08:00 --backup-set silver --backup-level 0
mysql-zrm-scheduler --add -interval daily --start 14:00 --backup-set silver --backup-level 1
mysql-zrm-scheduler --add -interval daily --start 19:00 --backup-set silver --backup-level 1

Con questi 3 semplici ed esplicativi comandi ho detto al mio nuovo amizo ZRM di fare 3 backup:

1. il primo alle 8.00 di mattina ed è un full backup
2. il secondo alle 14.00 ed è di tipo incrementale
3. il terzo alle 19.00 ed è sempre incrementale

Le opzioni sono svariate ed accontenteranno tutti. Una domanda sorge spontanea: ma i backup vecchi quando vengono cancellati? Questo viene deciso dal parametro retention-policy, presente nel file di configurazione.

Per questo primo episodio dedicato a ZRM è tutto, spero di aver stimolato la vostra voglia di backup e la curiosità nello spulciare le mille opzioni di questo indispensabile software.

Purtroppo non è facile stare seduti davanti ad un PC (anche se è un bel iMac) dopo un intervento al ginocchio.

Ma veniamo all’articolo. Forse il titolo non rende l’idea ma l’argomento di oggi risponde a questa domanda: avendo due connessioni ad Internet collegate alla mia Linux box che funge da router, come faccio a gestire il fail di una delle connessioni inoltrando a quella funzionante il traffico?

Per meglio comprende l’articolo, vi consiglio di spulciare velocemente due miei vecchi post:

1. iproute: load balance verso 2 gateway (IMPORTANTISSIMO!)
2. iproute: load balance verso 2 gateway della stessa rete

Rinfrescata la memoria sul routing di Linux, passiamo ad analizzare la logica di funzionamento dello script.

La strada migliore per verificare lo stato di una connessione è inoltrare verso il link qualche pacchetto e verificare che torni indietro una risposta.

Lo script non fa altro che pingare un host o in IP esterno pubblico, raggiungibile ed aperto al ping, attraverso i due link a nostra disposizione, se il ping fallisce tutto il traffico passa all’interfaccia funzionante.

Potete scaricare il file da qui e subito dopo editarlo da root per variare queste impostazioni:

# Frequenza in secondi con cui fare il check delle connessioni
SLEEPTIME=10

# IP o host esterno da pingare per effettuare le prove
TESTIP=www.google.com

# Timeout del ping in secondi
TIMEOUT=2

# Interfacce
EXTIF1=eth1
EXTIF2=eth2

# Indirizzi IP delle interfacce
IP1=192.168.1.7
IP2=192.168.0.7

# Gateway delle interfacce
GW1=192.168.1.1
GW2=192.168.0.1

# Weights del router. Nella mia guida erano entrami ad 1 per fare il round robin delle connessioni:
# Guarda questa riga: ip route add default scope global nexthop via $P1 dev $IF1 weight 1 nexthop via $P2 dev $IF2 weight 1
# Presente nell'articolo http://ideafactory.it/debian/iproute-load-balance-verso-2-gateway.html
W1=1
W2=1

# Nome dei provider utilizzati
NAME1=ngi
NAME2=fastweb

# Numero di ripetizioni di successo o di fallimento prima di cambiare lo stato alla connessione
SUCCESSREPEATCOUNT=4
FAILUREREPEATCOUNT=1


Come potete vedere utilizzo come host esterno da pingare www.google.com che ADESSO risulta raggiungibile tramite ping, vi consiglio di specificare qualche VOSTRO server così siete sicuri che il fail della connessione non sia dovuto al cambio delle regole di firewall dell’host a cui sono diretti i ping.

Io vi consiglio di salvare lo script in /usr/local/bin (ovviamente faccio riferimento a Debian) così sarà presente nel path di sistema senza specificare ogni volta il percorso assoluto per richiamarlo.

Una volta salvato nella directory che preferite vanno settati i permessi giusti:

chmod 755 /usr/local/bin/checkgw

Adesso potete eseguire lo script.

Inizialmente potete NON metterlo in background, così si può verificare il corretto funzionamento ma poi vi consiglio di lanciare lo script in questo modo:

checkgw &

Se volete che lo script venga eseguito all’avvio potete inserirlo in /etc/rc.local.

Spero che con questo articolo sia riuscito ad accontentare molti visitatori di IdeaFactory e vi ricordo che se avete bisogno di soluzioni personalizzate, avanzate, professionali e sempre funzionanti potete contattarmi.

Premetto che non basterà seguire alla lettera ciò che io descriverò per ritrovarsi una black box che una volta installata gestisce la posta fin che morte non vi separi. Dico questo perché un servizio come la posta elettronica va seguito e monitorato e spesso è necessario un sistemista (io [pubblicità progresso gratuita ]) che abbia capacità di problem solving notevoli per far sì che la fruizione del servizio non sia mai interrotta.

Cosa ci occorre per mettere su un servizio di posta elettronica con i fiocchi?

Ecco la lista della spesa:

• Un mail transfer agent (MTA)
• Un server POP3 ed IMAP
• Un validissimo sistema anti-spam
• Un aggiornatissimo sistema anti-virus
• Una moderna webmail
• Tool di corredo

Il miglior MTA? Postfix!

Nel mondo opensource c’è una vasta gamma di server SMTP ma i più famosi ed utilizzati sono:

• Postfix
• Exim
• qmail
• Sendmail

Sendmail

La documentazione di Sendmail è buona, c’è una società che ne cura la parte di servizi ed assistenza a pagamento ed ha un buon numero di adepti alla comunità.

Il file di configurazione di Sendmail è un labirinto in cui è utile solo didatticamente imbattersi. Meno contorti sono le violazioni di sicurezza che da sempre accompagnano Sendmail. E per finire, ciò che fa Sendmail viene svolto meglio da altri.

Si parla di MeTA1 nome in codice di Sendmail X che ha l’obiettivo di realizzare un MTA con specifiche del tutto simili a quelle di Postfix…Postfix c’è gia.

qmail

Sicurezza, sicurezza e sicurezza. Alla base della progettazione di qmail c’è la sicurezza. Nei tempi in cui Sendmail era un vero e proprio colabrodo, Daniel J. Bernstein realizzo qmail.

Obiettivo raggiunto, è sicuro tant’è che ci ha messo anche una taglia. La versione disponibile è la 1.03 uscita nel giugno del lontanissimo (informaticamente parlando) 1998. Da allora nessun aggiornamento, va bene così com’è, forse.

qmail ha dato una lezione a tutti ma alcuni allievi hanno superato il maestro, tant’è che qmail è stato il primo a supportare decentemente il formato Maildir, adesso però la concorrenza ha gia Maildir++ e per renderlo un server SMTP dei giorni nostri vanno applicate infinite patch. La licenza attuale di qmail? Un enigma.

Exim

E’ un MTA. Sicuro e general purpose, è tutto ciò che ci aveva Sendmail desiderava. Si configura con un file di configurazione, c’è solo un demone ed è veloce, molto veloce. Smista alla grande ma la mia descrizione finisce qui perché lo conosco davvero poco. Sorry!

Postfix

Per me Postifx è sua maestà MTA. In tre parole è: sicuro, facile (da amministrare) ed efficiente.

Come per qmail, la progettazione di questo software aveva come obiettivo la sicurezza e Wietse Venema, con circa circa 150k righe di codice, secondo me, ci è riuscito alla grande.

Postfix si compone di diversi programmi (ma meno di qmail), e dispone di un file di configurazione monolitico. Ha un forte accento sulla sicurezza, ma non fino al punto di imporre insolite pratiche di gestione Unix.Postfix segue un approccio vagamente analogo a qmail per quanto concerne la sicurezza ed il team di Sendmail riconosce espressamente Postfix come modello da seguire per la loro prossima release che sostituirà definitivamente Sendmail, MeTA1.

Il risultato impressionante è che Postfix fornisce grande flessibilità e facilità di amministrazione, nonostante il raggiungimento di obiettivi di sicurezza rigorosi. A mio avviso è più efficiente di Exim ed utilizza la stessa quantità di memoria di qmail ma a differenza di quest’ultimo utilizza meno banda perché qmail invia in solo messaggio per sessione SMTP anche se il destinatario è lo stesso host.

Postfix per me è il migliore, ed in questo articolo userò Postfix.

Guardate i risultati del Debian Popularity Contest cliccando di Postfix, vi ho convinto?

Nella prossima puntata scopriremo il miglior server POP3/IMAP…stay tuned!

Ci sono due strade percorribili, una è la Debian Way l’altra è quella maccheronica. Descriverò quella alla Debian Way e lascio ai commenti l’opportunità di descrivere quella maccheronica!:)

Con il comando update-alternatives –config editor vien fuori:

Ci sono 5 alternative che forniscono `editor'.
Selezione Alternativa
-----------------------------------------------
1 /bin/ed
+ 2 /bin/nano
3 /usr/bin/vim.tiny
4 /usr/bin/vim.basic
* 5 /usr/bin/vim.nox
Premi invio per mantenere il default[*], o inserisci il numero da selezionare:

Facile no? Ovviamente bisogna aver installato l’editor che si vuole impostare come default altrimenti la lista mostrata sarà molto misera.

Adesso chiedo a voi: qual’è il modo maccheronico per cambiare editor?

Molto probabilmente richiamando una URL inesistente o non gestita dall’applicazione che risiede sul nostro server, viene fuori qualcosa del genere:

In base a quanto descritto nell’articolo Modificare l’header di Apache, possiamo variare l’output che mostra le informazioni del server web.

Per non mostrare assolutamente niente, basta editare il file del virtualhost ad esempio /etc/apache2/sites-available/default, ed impostare la direttiva ServerSignature ad Off in questo modo:

ServerSignature Off

Ovviamente va restartato Apache prima di vedere attuata tale modifica.

Quali sono le opzioni di ServerSignature? Eccole:

• Off: Non visualizza niente nel footer
• On: Visualizza le informazioni come specificato in ServerTokens
• On: Visualizza le informazioni come specificato in ServerTokens ed aggiunge il link all’indirizzo e-mail specificato con ServerAdmin

Buon week-end a tutti.

Fatta la breve ma doverosa premessa veniamo al dunque.

Può capitare di ritrovare la propria sessione SSH terminata a causa di timeout per mancato utilizzo, come si risolve tutto ciò? Basta editare il file /etc/ssh/ssh_config (su sistemi Debian based) ed inserire questi parametri:

TCPKeepAlive yes
ServerAliveInterval 5
ServerAliveCountMax 60

Così facendo il client SSH terrà viva la connessione al server e quindi noi possiamo andarci a fare un meritato bagno caldo.

Usiamo molto spesso traceroute e quotidianamente ping, con mtr li abbiamo entrambi e l’utilità è di facile spiegazione.

Spesso capita che il nostro adorato server dedicato non è raggiungibile per problemi di rete dovuti ai molteplici router intermedi, con mtr possiamo monitorare tutti gli hop intermedi e verificare ciò che accade quando li si attraversa.

Visto che è di certo l’ultimo post del 2009, vi aguro un felice anno nuovo!

p.s.: un ringraziamento a Iuri per avermi fatto notare mtr.