[ITA]Guida: Il perfetto mirror modulare di ISPConfig con Virtualbox

backup automatico con rsync ed shh per mirror di ISPConfig in ambiente virtualeQuesto è il log AGGIORNATO della mia prossima avventura nel paese delle meraviglie (che poi sarebbe Debian) in cui utilizzerò 2 Virtual Machines, una delle quali sarà ottenuta partendo da un clone della macchina originale da tenere sotto mirroring, ed agirà da mirror venendo aggiornata 4 volte al giorno.

La macchine clone, verrà aggiornata in tutto e per tutto, configurazioni ed utenti compresi. Inoltre la procedura può essere replicata N volte senza sovraccaricare la macchina master, potendo agganciare le nuove macchine a cascata.

Chiamerò la macchina che riceve connessioni dal mondo esterno “home” e la macchina gemella che invece resta nella lan senza ricevere connessioni dall’ esterno “backup”.

Home Ha l’ indirizzo 192.168.100.4
backup Ha l’ indirizzo 192.168.100.5
Il Router inoltra tutte le connessioni in ingresso sull’interfaccia pubblica verso la macchina HOME

IMPORTANTE: Utilizzo di Virtual Machine.

Le due macchine sono virtualizzate e, come già detto nel precedente pararafo, ho ottenuto la macchina destinata al backup clonando la macchina originale così da rispettare tutti i privilegi (uid e gid) che diversamente, con una normale sincronizzazione dovrebbero invece essere aggiustati a mano.

La clonazione

Questo è molto importante poichè significa che tutti i privilegi, files e programmi sono coerenti tra le due macchine e di conseguenza non dovremo preoccuparci di fare manualmente quello che il Mac Os X chiama simpaticamente “Ripara Permessi”.
Grazie a questo escamotage, per preservare i permessi e la ownership dei files, sarà sufficiente aggiungere al comando rsync lo switch “-a” (equivalente a “-rlptgoD”) .

Clonazione e Schede di rete in Bridge mode

Detto questo va anche aggiunto che allo stato attuale, le due macchine hanno la NIC (Network Interface Card) configurata in Bridge Mode su Virtualbox il che implica che tale macchina sarà visibile sulla lan “reale”, ed avrà l’ indirizzo ip che verrà impostato dal suo “interno”, esattamente come se fosse una macchina fisica che si trova sul segmento di rete specificato nel contenuto del suo file /etc/network/interfaces.

MAC Address e Indirizzo IP

A questo punto dobbiamo affrontare la prima (e probabilmente l’ unica) delle conseguenze negative dell’ aver clonato la macchina “Backup” partendo dalla macchina “Home”.
Per prima cosa, prima di avviare la macchina per la prima volta compiamo queste 2 operazioni:

  • Dalla GUI di VirtualBox disabilitare il cavo di rete
  • Dalla GUI di VirtualBox rigenerare il MAC Address per la scheda

Riavvio senza connesisone di rete e cambio di indirizzo ed hostname

Abbiamo clonato tutti, anche l’ indirizzo IP e l’ HOSTNAME, di conseguenza, ora dovremo modificarli in qualcosa di conveniente e che non provochi malfunzionamenti sulla rete.
apriamo quindi il file /etc/network/interfaces e modifichiamo la scheda di rete eth in maniera da utilizzare un indirizzo “vicino” a quello della macchina home.
editiamo quindi il file /etc/network interface ed il fil /etc/hostname con

nano /etc/network/interfaces

e modifichiamo l’ indirizzo IP.
Salviamo il file con “ctrl+o” seguito da “Invio” e chiudiamo con “ctrl+x”.

Eventuale problema

Dopo aver passato 2 ore a capire cosa fosse capitato alla scheda eth0 o eth1 dela macchina clonata, mi sono finalmente deciso a guardare i log: et voilà, ecco la spiegazione:

root@backup:~# dmesg |grep eth
[    3.229330] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
[    7.251976] udev[235]: renamed network interface eth0 to eth2
[   13.743590] e1000: eth2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[   13.744467] ADDRCONF(NETDEV_UP): eth2: link is not ready
[   13.746123] ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
[   24.332174] eth2: no IPv6 routers present

In particolare la riga udev[235]: renamed network interface eth0 to eth2 ci dice che udev ha rinominato la scheda da eth ad eth2, il che implica che probabilmente è accaduta la stessa cosa sulla prima macchina ma con eth1, questo perchè ho clonato la Virtual machine.La soluzione è piuttosto banale ed è documentata nel mio articolo su “udev[235]: renamed network interface eth0 to eth2
Superato questo problema passiamo all’azione rinominando il nostro HOST con il nome “backup”, nel mio caso il FQDN scelto è giuseppeurso.net, per questo da console digiterò

echo backup.giuseppeurso.net > /etc/hostname

 

Riavviamo la rete con il seguente comando:

/etc/init.d/hostname.sh stop
/etc/init.d/hostname.sh start
/etc/init.d/networking restart && ifdown eth2 && ifup eth2

Testare il tutto con ifconfig ed un ping che coinvolga anche una richiesta dns come

ping www.google.com

, pingare inoltre le due macchine tra loro.

Passiamo a decidere ora quali files o cartelle tenere sincronizzate dalla macchina home.
Dovremo analizzare la cosa sotto 2 diversi punti di vista:

  • Corretto funzionamento dei servizi come web, posta, database.
  • Coerenza dal punto di vista del sistema operativo

Vediamo il dettaglio:

Corretto funzionamento dei servizi web

Per funzionare, oltre alla copia dei files, un sito web necesita probabilmente di un database, e se viene copiato per la prima volta dopo essere stato creato non ha ancora il file di configurazione del VirtualHost in /etc/apache2/sites-available. dovremo quindi, ma non è tutto, tenere sincronizzate la cartelle /etc/apache2/sites-avalable. Occorre tenere presente sempre che le due macchine hanno l’ indirizzo ip diverso e dovendo ospitare diversi siti cheh utilizzano SSL avremo bisogno di specificarlo nella configurazione di apache2 e dovremo poi modificarlo con sed sul server di backup in maniera che tutto stia in piedi.
Questo ci assicurerà che un sito sia visibile dall’ “esterno” nel caso in cui volessimo scambiare i 2 server a causa ad esempio di un attacco di cui non abbiamo ancora scoperto l’ origine.
Ma se un nuovo utente FTP tenta di connettersi non troverà la sua utenza attiva. Stesso discorso per gli utenti Email, MySql, records dns,

Coerenza del sistema operativo

Servizio FTP

Occorre quindi di preservare anche le utenze dei vari servizi in uso. Alcune delle utenze di questi servizi come il servizio FTP, sono gestiti tramite database; per questo tipo di servizi sarà sufficiente eseguire un DUMP completo del db, mentre per il servizio di posta occorre rintracciare i file coinvolti ed assicurarsi di copiarli tutti.

Servizio Email con Postfix

Per coloro che usano postfix bisogna copiare la cartella /etc/postfix, /var/vmail

DNS

Per chi usa Bind copiare /etc/bind/* e /var/named/*
Inoltre sto pensando di migrare verso POWERDns come mi è stato segnalato (thanks to Harlod) e scriverò qualcosa riguardo l’uso ISPConfig e Powerdns.

Fail2Ban

Copiare il contenuto della directory /etc/fail2ban/*

Tutti i logs

Copiare /var/log/*

I backup

Copiare /var/backup/*

Siti web

Copiare /var/www/*

Elenco files da sincronizzare

  • /etc/*
  • /var/*
  • /home/*

Ricorda di aggiungere sulla macchina in produzione una riga in /etc/hosts dedicata al server “backup” in maniera da non doverla modificare ogni volta che si sincronizza.

Rimettere in ordine /etc/hostname ed /etc/network/interfaces altrimenti apache non si riavvierà non trovando l’ indirizzo originale specificato nel file di configurazione dei vari virtual hosts.

echo backup.giuseppeurso.net > /etc/hostname
/etc/init.d/hostname.sh stop && /etc/init.d/hostname.sh start
sed -i 's/192.168.100.4/192.168.100.5/g' /etc/network/interfaces
ifdown eth2 && /etc/init.d/networking restart && ifup eth2

controlla che

hostname

e con

hostname -f

restituiscano lo stesso nome Host.

Per per restanti files di configurazione non sembrano esserci problemi, almeno al momento, dovrò controllare la continuità dei report di awstats, altrimenti mi toccherà rimpiazzare eventuali indirizzi ip sbagliati e ripetere la creazione di tutti i report che è un bel lavoraccio per la CPU.

Quindi rimettendo insieme il tutto abbiamo uno script di shell simile al seguente

#/bin/bash
rsync -avz -e "ssh -p 22" root@192.168.100.4:/etc/* /etc
rsync -avz -e "ssh -p 22" root@192.168.100.4:/var/* /var
rsync -avz -e "ssh -p 22" root@192.168.100.4:/home/* /home
rsync -avz -e "ssh -p 22" root@192.168.100.4:/tmp/* /tmp
rsync -avz -e "ssh -p 22" root@192.168.100.4:/usr/bin/* /usr/bin
rsync -avz -e "ssh -p 22" root@192.168.100.4:/usr/local/bin/* /usr/local/bin
find /etc/apache2/sites-available/ -type f -exec sed -i 's/192.168.100.4/192.168.100.5/g' {} ;
sed -i 's/192.168.100.4/192.168.100.5/g' /etc/network/interfaces
/etc/init.d/networking stop && /etc/init.d/networking start && ifdown eth0 && ifup eth20
reboot

Ma se proviamo ad eseguirlo non potremo fare a meno di notare che per ogni volta che utilizzerà rsync su SSH ci verrà chiesta la password, il che è particolarmente noioso e rende impossibile automatizzare il processo attraverso cronjobs.
Motivo per cui occorre creare una chiave senza password per l’ accesso di root limitandone l’ accesso solo alla macchina tramite indirizzo ip.

Quindi posizioniamoci con la shell sulla macchina “backup” e predisponiamoci a creare la nostra chiave con

ssh-keygen -t rsa -b 2048 -f /root/backup_rsync_key
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):

NON INSERIRE LA PASSWORD, DARE INVIO INVECE!

e continuerà così

Enter same passphrase again: 
Your identification has been saved in /root/backup_rsync_key.
Your public key has been saved in /root/backup_rsync_key.pub.
The key fingerprint is:
e2:42:a2:e2:e2:2a:6a:c2:52:d2:22:8c:62:e6:2f:c2 root@backup.giuseppeurso.net
The key's randomart image is:
+--[ RSA 2048]----+
|  oo  o          |
| ..o o..         |
|   .o  E         |
|   .    .        |
|  .  . .S        |
| .    ..         |
|... .   + .      |
|...+  .+ =       |
| .. .+..=        |
+-----------------+

Spostiamo ora la parte pubblica della chiave sul server di destinazione tramite il facile comando scp, come segue:

root@backup:~# scp /root/backup_rsync_key.pub root@192.168.100.4:/root/
root@192.168.100.4's password: 
backup_rsync_key.pub                          100%  410     0.4KB/s   00:00    
root@backup:~#

Loggati sul server pubblico

Ora dobbiamo aggiungere la porzione pubblica della chiave appena generata, all’ interno el file authorized_keys nella directory .ssh nella home dell’ utente in questione quindi in /root/.shh/authorized_keys tramite il seguente comando

cd /root
touch .ssh/authorized_keys
cat backup_rsync_key.pub >> .ssh/authorized_keys

Prima di esultare occorre prestare attenzione ad una semplice ma importante misura di sicurezza per questo genere di connessioni: OpenSSH ci da infatti la possibilità di specificare l’ host dal quale accettare connessioni per l’ utente di cui si intende utilizzare la chiave. a questo proposito editiamo il file “authorized keys” ed aggiungiamo

from="192.168.100.5"

in modo da ottenere:

from="192.168.100.5" ssh-dss AAAAB3Nza......
........
........

Adesso testiamo la connessione con la nuova chiave

root@backup:~# mv /root/backup_rsync_key .ssh/
root@backup:~# ssh -l root 192.168.100.4 -i .ssh/backup_rsync_key 
Linux home.giuseppeurso.net 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Dec 23 19:11:24 2012
root@home:~#

YEEEEEEE!!!!!

TUTTO INSIEME!

Siamo in fine, l’ ultimo step è di aggiungere l’ opzione per l’ utilizzo della chiave ssh per ciascuna istanza di rsync che viene eseguita dalle righe del nostro script.
Quindi modifichiamolo in questo modo aggiungengo in fondo una query da eseguire sul db di ispconfig per aggiornare l’ indirizzo IP del server e di alcuni domini (le tabelle sono: monitor_data,server_ip,sys_datalog,web_domain). Mettiamo tutto in un paio di righe che assomigliano a questo:

#!/bin/sh
echo "update server_ip set ip_address='192.168.100.5' where ip_address='192.168.100.4'" | mysql dbispconfig  --user=root --password=`cat /root/db_p`
echo "update web_domain set ip_address='192.168.100.5' where ip_address='192.168.100.4'" | mysql dbispconfig  --user=root --password=`cat /root/db_p`

Dove /root/db_p contiene la password per l’ utente root. Il motivo? alcuni caratteri non sono utilizzabili da console per la password,inoltre è un ottimo modo per testare da terminale prima di salvare la riga in un file.

#/bin/bash
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/etc/* /etc
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/var/* /var
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/home/* /home
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/tmp/* /tmp
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/usr/bin/* /usr/bin
rsync -avz -e "ssh -p 22 -i .ssh/backup_rsync_key" root@192.168.100.4:/usr/local/bin/* /usr/local/bin
echo backup.giuseppeurso.net > /etc/hostname
/etc/init.d/hostname.sh stop && /etc/init.d/hostname.sh start
find /etc/apache2/sites-available/ -type f -exec sed -i 's/192.168.100.4/192.168.100.5/g' {} ;
sed -i 's/192.168.100.4/192.168.100.5/g' /etc/network/interfaces
service mysql restart
echo "update server_ip set ip_address='192.168.100.5' where ip_address='192.168.100.4'" | mysql dbispconfig  --user=root --password=`cat /root/db_p`
echo "update web_domain set ip_address='192.168.100.5' where ip_address='192.168.100.4'" | mysql dbispconfig  --user=root --password=`cat /root/db_p`
/etc/init.d/networking stop && /etc/init.d/networking start && ifdown eth0 && ifup eth0 && reboot

Il reboot potrebbe risultare facoltativo, occorre testare.

Ora eseguiamolo e stiamo a guardare cosa succede. 🙂

Il cronjob

ora impostiamo un cronjob per fare eseguire la sincronizzazione ogni volta che ci pare, ricordandoci che occorre trovare un compromesso tra la frequenza e le necessità. Ovviamente più frequenti sono le sincronizzazioni minore sarà la quantità di dati da spostare, questo non significa che andrà eseguita ogni 5 minuti, ma neanche una sola volta al giorno. Direi che 4 volte al giorno potrebbe bastare e non essere troppo.

quindi con il comando

crontab -e

modifichiamo il crontab di root.

0 0,6,12,18 * * * /root/script1.sh > /dev/null 2>>/var/log/mirroring.log

Per qualsiasi problema puoi contattarmi tramite i commenti di questo articolo, oppure ,se sono online, utilizzando il pulsante verde in basso a destra che aprirà una chat direttamente con il mio telefono.
Ciao!!

P.s. non ho testato ancora indirizzi di mail, dns ed utenze ftp ma non appena lo farò, aggiornerò questo articolo con tutto il necessario.

Buon Natale 2013!
😉 

(Visited 611 times, 1 visits today)

Author: Giuseppe Urso

Giuseppe lives in Haarlem now with his shiny dog, Filippa
In 1982 received his first home computer, a Commodore 64, followed by Datasette and a 1541 Floppy Disk Drive.
In 1999 he installed his first Linux distro (LRH6).
In 2006 he switched to Debian as favourite OS. Giuseppe Urso actively sustains the Free Software Fundation and his founder Richard Mattew Stallman, he speaks to people trying to convince them to join the fight now, and about how important is to use Free Software only.
He has a job as Infra Specialist at Hippo Enterprise Java Cms an Open Source Enterprise class Content Management System, one of the coolest company ever, in Amsterdam. He’s always ready to install Debian on other people computers for free.

One thought on “[ITA]Guida: Il perfetto mirror modulare di ISPConfig con Virtualbox”

  1. Hi! I realize this is kind of off-topic but I had to ask.

    Does operating a well-established blog like yours take a large amount of
    work? I’m brand new to writing a blog however I do write in my journal every day. I’d
    like to start a blog so I can easily share my personal experience and feelings online.
    Please let me know if you have any kind of recommendations or tips for new aspiring bloggers.

    Thankyou!

Leave a Reply

Your email address will not be published. Required fields are marked *