ediamo ora come implementare una replica master-master per MySQL.

Per prima cosa bisogna scaricare il database MySQL. Per questo ambiente di test scarichiamo il pacchetto binario dal sito MySQL,

Ad esempio su di una distribuzione debian-like procederemo come al solito con

aptitude search mysql
aptitude install mysql-server
Andiamo ora a creare due istanze del db.

Creiamo come root le datadir

mkdir /var/lib/mysql-mm-1
mkdir /var/lib/mysql-mm-2
Sempre come root prepariamo le configurazioni

cp -rp /etc/mysql/my.cnf /etc/mysql-mm-1/my.cnf
cp -rp /etc/mysql/my.cnf /etc/mysql-mm-2/my.cnf
Editiamo ora il file my.cnf fino ad ottenere per il nodo 1 qualche cosa come

[client]
port = 3307
socket = /var/run/mysqld/mysqld-mm-1.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqld-mm-1.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld-mm-1.pid
socket = /var/run/mysqld/mysqld-mm-1.sock
port = 3307
basedir = /usr
datadir = /var/lib/mysql-mm-1
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error-mm-1.log
server-id = 11
log_bin = /var/log/mysql/mm-1-bin.log
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]

[isamchk]
key_buffer = 16M
e per il nodo 2 qualche cosa come

[client]
port = 3308
socket = /var/run/mysqld/mysqld-mm-2.sock

[mysqld_safe]
socket = /var/run/mysqld/mysqldi-mm-2.sock
nice = 0

[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld-mm-2.pid
socket = /var/run/mysqld/mysqld-mm-2.sock
port = 3308
basedir = /usr
datadir = /var/lib/mysql-mm-2
tmpdir = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 127.0.0.1
key_buffer = 16M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 8
myisam-recover = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error-mm-2.log
server-id = 12
log_bin = /var/log/mysql/mm-2-bin.log
expire_logs_days = 10
max_binlog_size = 100M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[mysql]
[isamchk]
key_buffer = 16M
da notare in questi file:

port: ho usato porte non standard e diverse per i due nodi
server-id: ho dato due valori diversi ai due nodi
log-bin: ho abilitato i binary log
datadir: specifica per ogni nodo.
Devo ora popolare le directory dei dati:

mysql_install_db –user=mysql –defaults-file=/etc/mysql-mm-1/my.cnf
mysql_install_db –user=mysql –defaults-file=/etc/mysql-mm-2/my.cnf
Posso ora avviare i due database

mysqld_safe –defaults-file=/etc/mysql-mm-1/my.cnf &
mysqld_safe –defaults-file=/etc/mysql-mm-2/my.cnf &
Al primo avvio dovranno essere generati tutta una serie di file ma dopo un po’ i due database dovrebbero essere accessibili:

mysql –port 3307 –host 127.0.0.1 –user=root
mysql –port 3308 –host 127.0.0.1 –user=root
NB: su Ubuntu apparmor impedisce di eseguire questa procedura. Per escluderlo

aa-complain /usr/sbin/mysqld
Trattandosi di due istanze appena create non ci dobbiamo preoccupare allineare la situazione iniziale dei due nodi mysql imprtando dei backup.

Procediamo quindi a configurare il nodo mysql due come replica del nodo mysql uno.

Per prima cosa dobbiamo vedere lo stato come master del nodo uno:

mysql –port 3307 –host 127.0.0.1 –user=root
show master status\G
otterremo qualche cosa come

*************************** 1. row ***************************
File: mm-1-bin.000005
Position: 107
Binlog_Do_DB:
Binlog_Ignore_DB:
1 row in set (0.00 sec)
Nel caso avessimo ripristinato da un backup avremmo dovuto far riferimento a informazioni analoghe ma prese al momento del backup.
Abilitiamo ora la prima replica

mysql –port 3307 –host 127.0.0.1 –user=root
change master to MASTER_HOST=’127.0.0.1′, MASTER_PORT=3307 , MASTER_USER=’root’ , MASTER_LOG_FILE = ‘mm-1-bin.000005′, MASTER_LOG_POS =107;
show slave status\G
Ho qui utilizzato l’utente root. In condizioni non di test bisognerebbe utilizzare un utente con gli appositi permessi (REPLICATION_CLIENT, REPLICATION_SLAVE).
Lo stesso per l’altro nodo

mysql –port 3308 –host 127.0.0.1 –user=root
change master to MASTER_HOST=’127.0.0.1′, MASTER_PORT=3308 , MASTER_USER=’root’ , MASTER_LOG_FILE = ‘mm-2-bin.000005’, MASTER_LOG_POS =107;
show slave status\G

La posta di gmail offre uno strumento poco noto ma molto utile. Risulta essere possibile inviare posta con un sender differente dall’account con cui si è fatto login.

Questa feature di gmail può tornare utile in almeno due casi
se si hanno diverse caselle di posta sfruttando il cambio di sender e la possibilità di scaricare posta da altre caselle, per concentrare la gestione della propria posta in un unico punto.
se si gestisce un dominio con centinaia di caselle su cui con ogni probabilità verranno richieste caselle non personali di cui è fin troppo facile perdere traccia, da la possibilità di limitare gli utenti alle caselle personali e usare i gruppi per tutte le caselle funzionali come le varie webmaster, postmaster etc.. Il vantaggio è doppio: igruppi non si pagano e l’amministratore può ricostruire facilmente da chi vengono letti.

Per sfruttare questa feature bisogna
Fare login sulla webmail
entrare nei settings del proprio account
Selezionare il tab Accounts
selezionare “Add another address you own”
Sulla finestra di pop-up inserire il nome che si vuole mostrare accanto all’indirizzo nell’header From:”
Sulla finestra di pop-up inserire l’email che si vuole nel campo From
Sulla finestra di pop-up togliere il check “Treat as an alias box”
Selezionare Next Step
Si riceverà sull’altro account (o gruppo) un’email con un link di autorizzazione
Confermare selezionando il link nell’email
Tornare alla finestra di pop-up e concludere la procedura.

Da questo momento è possibile mandare la posta con un altro Sender.

Una necessità primaria dei sistemi di produzione è la raccolta e la gestione dei log.

Sempre di più i log vengono generati in enorme quantità e quando l’infrastruttura cresce oltre un certo livello diventa fondamentale passare ad un sistema che ne gestisca la centralizzazione.

Su Linux generalmente si usa una qualche versione del demone syslog (su ubuntu ad esempio ci sono tre opzioni dsyslog, rsyslog, syslog-ng) a questo scopo. Questi sistemi si occupano sia della gestione locale dei log sia della loro eventuale centralizzazione e mettono a disposizione strumenti per filtrare le informazioni più importanti o per integrarsi con sistemi di monitoraggio come nagios o con sistemi di reportistica come logstash. La scelta di un file come repository finale dei dati non è obbligata ma questi sistemi permettono di passare i dati a molti altri tipi di repository.

Farò riferimento per i dettagli a syslog-ng.

Conviene immaginare questi sistemi come a gestori di flussi di informazioni nei quali ci sono dei punti di entrata (un server apache ad esempio), delle regole di elaborazione più o meno complesse e dei punti di uscita (tipicamente un file, altri server syslog nei sistemi centralizzati, database etc..). La configurazione rispecchia questa prospettiva.

Una volta definiti delle opzioni generali si definisco le sorgenti dei log. Questa ad esempio raccoglie le informazioni che tipicamente finiscono sui log standard di sistema.

source s_src { unix-dgram(“/dev/log”); internal();
file(“/proc/kmsg” program_override(“kernel”));
};
Altre tipiche sorgenti di dati saranno delle porte in ascolto su protocolli udp o tcp

source s_udp_apache {
udp(ip(0.0.0.0) port(8515));
};
source s_tcp_apache {
tcp(ip(0.0.0.0) port(8515));
};
utili sia per la costruzione di sistemi gerarchici che permettano la centralizzazione dei log sia come sistema semplice per separare su molti canali i log.
Tra le possibili sorgenti ci sono anche i file

source s_apache_access {file(“/var/log/apache2/access.log” log_fetch_limit(100) log_iw_size(1000)); };
utili ad esempio per raccogliere i log anche di sistemi che hanno solo questa.

Il secondo elemento chiave della configurazione sono le destinazioni dei flussi di log. Anche in questo caso è possibile inviare i log su di un file locale, su un canale tcp o udp nel caso di sistemi gerarchici per la gestione di log.

destination d_auth { file(“/var/log/auth.log”); };
destination d_udp_system { udp(vip-syslog.de.prod port(8514));};
destination d_tcp_system { tcp(vip-syslog.de.prod port(8514));};
Ci sono molte possibili altre destinazioni tra cui stream unix, o mongodb.

Il terzo elemento della configurazione è filter. Come il nome lascia intuire questo elemento serve a definire delle regole per selezionare un sottoinsieme dellerighe in arrivo. L’elemento tradizionale per suddividere i log è la selezione della facility, ma filter permette di agire su svariati elementi tra cui l’host di invio, il livello del messggio (notice, warn, error…) appositi tag assegnati alla riga di log o anche regular expression sul contenuto.

filter f_err { level(err); };
filter f_mail { facility(mail) and not filter(f_debug); };
I vari elementi della configurazione devono essere poi combinati con un’ultimo elemento della configurazione:

log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_apache_extranet); destination(d_apache_extranet); flags(flow_control); };
La combinazione di questi elementi permette una grande flessibilità nella gestione del log. Tornerò su questo tema per approfondirne il filtraggio ed altre opzioni.

Dopo avere visto come configurare il nostro router per l’accesso in rete, sia in modalità cablata che Wireless, è arrivato il momento di vedere come proteggere tale connessione, in modo che altri utenti, alla portata della nostra connessione Wireless, possa intrufolarsi nella nostra rete e dunque utilizzarla per navigare gratuitamente, a nostra insaputa, e quindi avere un sovraccarico non autorizzato di banda internet.

Una volta configurato il router, accedere alla rete tramite Wireless è piuttosto semplice, basta infatti cliccare sull’icona di connessione senza fili presente nella tray icon di Windows (accanto l’orologio), cliccandoci su scandiremo la rete alla ricerca di punti d’accesso, quindi una volta identificato il nostro router basta un click per avviare il collegamento, e dunque attivare la connessione ad internet.

Ovviamente tutto questo è fattibile anche da un qualsiasi utente esterno, per tale ragione è necessario proteggere la rete utilizzando uno dei diversi metodi di protezione disponibili.

Per attivare una protezione è necessario accedere alla pagina di configurazione del nostro router, quindi, come abbiamo visto nell’articolo su come configurare il router, bisogna aprire il browser e dunque digitare l’indirizzo del router.

Ricordo che la schermata di configurazione varia da router a router, quindi le schermate visualizzate di seguito potrebbero essere differenti.

L’opzione per attivare una protezione si trova generalmente nelle impostazioni wireless.

Una volta identificata dobbiamo scegliere un’opzione di protezione tra:

WEP (Wired Equivalent Privacy)
WPA-PSK (Wi-Fi Protected Access Pre-Shared Key)
WPA2-PSK (Wi-Fi Protected Access 2 Pre-Shared Key)
Mista: WPA-PSK+WPA2-PSK
WPA-802.1x

La protezione WEP è più diffusa e compatibile, per tale ragione è anche la più attaccata e quindi soggetta ad essere infranta, la WPA2 è un ottima soluzione, tuttavia non tutti i dispositivi sono compatibili soprattutto alcune console di gioco, quindi alla fine l’unica soluzione è andare per tentativi.

Una volta scelta l’opzione di protezione dobbiamo digitare la chiave vera e propria, questa deve contenere da un minimo di 8 caratteri ad un massimo di 63 caratteri alfanumerici, inutile dire che più caratteri utilizziamo e più sarà sicura la nostra chiave.

Una volta impostata la chiave applichiamo le impostazioni e, se richiesto, riavviamo il router.

A questo punto la nostra connessione è finalmente protetta, questa volta, cliccando sul punto d’accesso Wireless relativo alla nostra connessione, Windows ci chiederà il codice di protezione, immettendolo potremo accedere alla rete e dunque navigare, chiunque tenti di connettersi al nostro router verrà accolto da una bella richiesta di codice, che ovviamente non avendolo, non potrà connettersi.

Avere una politica di backup che ci permetta di limitare i danni in caso di errori o problemi è una necessità che risale all’origine dell’informatica.

UNIX e Linux hanno ovviamente diversi tool che vengono in aiuto per questa necessità, e, almeno nel caso di una macchina singola, si possono implementare delle politiche asolutamente soddisfacenti con soli tool interni come cron ed rsync.

Come molti comandi della shell UNIX rsync è estremamente versatile. Il comando di base è:

rsync /path/to/source/file /path/to/destination
Come suggerisce il nome rsync non è un semplice tool per la copia dei file ma si occupa di sincronizzare due directory effettuando la copia dei soli file che lo richiedono.

Tendenzialmente rsync è utile soprattutto se si ha la necessità di copiare molti file e quindi sarà necessario utilizzare l’opzione -r

rsync -r /path/to/source/ /path/to/destination
rsync -r /path/to/source /path/to/destination
Ho riportato due comandi per sottolineare una particolarità di rsync. Se si copia una directory e si specifica / nel path della sorgente il contenuto della directory verrà copiato nella destinazione; se invece il path viene scritto senza / è la directory che viene copiata nella destinazione.

Rsync generalmente non ha quasi nessun output a video, il che è ottimo per script in crontab, se però si sta eseguendo il backup in real time si vorrà probabilmente un’indicazione di come sta procedendo l’attività. PEr questo si hanno due opzioni -v e –progress.

rsync generalmente controlla le dimensioni e la data di ultima modifica per capire se devono essere copiate. Sono però disponibili specifiche opzioni per fare controlli differenti. Ad esempio –size-only se si vole considerare solo le dimensioni del file o –checksum se si vuole un conformto più affidabile anche se più oneroso.

Le opzioni di questo comando sono svarite ma generalmente se si stanno effettuando dei backup -a farà si che vengano attivate le opzioni che più comunemente vengono utilizzate per questa attività.

Una mensione particolare merita l’opzione -b; in questa modalità rsync effettuerà un backup incrementale spostando i file rimossi dalla sorgente in un appositp path e scrivendo su un file tutte le operazioni effettuate. Si otterrà quindi una directory allineata a quella sorgente e si manterranno i file e le informazioni necessari per ricostruire la situazione al momento del backup precedente.

Un esempio di comando reale potrebbe quindi essere

rsync -avb –size-only –delete –log-file=/path/to/file_log/file.log –backup-dir=/path/to/directory_file_incrementali/ –progress /directory/source/ /directory/destination/