Some right reserved
Scegli come ricevere gli ultimi articoli:
Sondaggio in corso
Ti piacerebbe avere una rubrica dedicata alle domande dei lettori?
- Si (93%, 25 Votes)
- No (7%, 2 Votes)
Total Voters: 27
Loading ...
errori Archive
-
The BOFH’s return
Posted on agosto 25, 2009 | 6 commenti
Fine delle ferie, si ritorna alla solita vita, stress, e cagate varie...
Purtroppo è anche giunto il ritorno dei clienti e dei relativi sviluppatori, ed io mi sono dovuto adattare di conseguenza.
The BOFH's return...
-
Go Away Scriptkiddie!!
Posted on luglio 21, 2009 | 5 commenti
Piccolo suggerimento per difendersi ulteriormente dalla marea di "disturbatori della quite pubblica" che ogni giorno tentano invano di sfondare le nostre difese.
Suggerimento valido anche per web server Apache.
-
Sedicenti Hacker crescono
Posted on luglio 11, 2009 | 11 commenti
O almeno credono di esserlo (hacker)..
Perchè ho la netta impressione che quello che sta tutt'ora provando a bucarmi il server abbia un quoziente intellettivo più o meno come quello di un paguro...
-
Creare un relay antispam – parte 2°
Posted on luglio 10, 2009 | Nessun commento
Seconda parte del tutorial per la creazione di un relay antispam per un migliore filtraggio della posta in entrata.
-
La cultura della “pezza”..ovvero come rimandare i problemi…
Posted on giugno 22, 2009 | 16 commenti
...invece che risolverli, perchè sforzare le meningi prima quando si può benissimo sprecare altro tempo dopo?
Anche se già ebbi un presentimento domenica di questa giornata, che sarebbe stata particolare...
-
Emergency Emergency….no scherzavo…
Posted on giugno 18, 2009 | 4 commenti
Solitamente questo cartello viene messo davanti la nostra porta...
-
Backup dei dati con Bacula
Posted on gennaio 9, 2009 | 3 commenti
Un viaggio alla scoperta di Bacula, la più completa suite di network backup multipiattaforma.
Con questo tutorial abbastanza articolato vedremo cosa è Bacula e come effettuare il backup dei nostri files in maniera automatizzata ed efficace.
-
Ferie finalmente
Posted on agosto 2, 2008 | 5 commentiDa oggi sono iniziate anche per me le tante desiderate ferie estive...
-
RAID, impariamo cos’è ed utilizziamolo su Ubuntu (2° Parte – I restanti livelli del raid)
Posted on luglio 21, 2008 | 7 commentiVisto il risultato della prima parte della guida appena tornato a casa mi sono subito messo al lavoro per pubblicare la seconda parte :D
Abbiamo visto in generale cosa è il raid e i primi due livelli di questa tecnologia, adesso vediamo altri livelli con i quali si può utilizzare il raid. Abbiamo anche visto come tra il livello 0 e l'1, per motivi evidenti, l'ultimo è quello più utilizzato, e adesso vedremo anche come alcuni dei livelli che seguiranno sono basati invece sul raid 0 con qualche feature in più...
Raid 2
Il raid-2, derivato dal raid 0, utilizza sempre la tecnica dello striping dei dati, dividendo questi però a livello di bit (anzichè a livello di blocco), ma non è tutto; il raid-2 è ECC Capable, vale a dire che adotta un codice di Hamming ((Prende il nome dal suo inventore ed è un codice per la correzione degli errori, permette la rilevazione e la correzione di errori semplici (1 bit), e la sola rilevazione di errori doppi (2 bit), la sua formula è![\left[\frac{q^m-1}{q-1},q^m-m,3\right]](http://upload.wikimedia.org/math/f/2/9/f29c5aca22be85c3621c92e77dadb727.png)
, dove q sta per il numero di lettere dell'alfabeto in uso (stiamo parlando di linguaggio informatico quindi binario, quindi 2 :D ) ed m il numero di lettere (quindi bit) utilizzati, per maggiori informazioni vi rimando alla wikipedia )), per il controllo e la correzione degli errori. Lavorando a livello più basso del raid 1, ed adottando questo algoritmo, ne deriva che il raid 2 è adatto per sistemi critici con alte percentuali di errori, in quanto l'affidabilità del dato è praticamente totale...
Raid 3
Anche questo è derivato dal raid 0, ma opera ad un livello un pò più superiore del raid 2, divide i dati infatti a livello di byte.
Inoltre in aggiunta ai dischi dedicati al raid, necessità di un disco dedicato alla parità ((Il raid 3 oltre allo striping è anche pensato per un certo livello di fault tolerance, i dati infatti verratto scritti byte per byte in round robin sui dischi raid, mentre sull'ultimo disco verranno scritti i dati di parità, in caso di guasto di uno dei dischi dell'array, grazie ai dischi residui, ed ai frammenti di dati presenti sul disco di parità, il sistema può continuare a lavorare ricostruendo i dati necessari. Quando il disco in failure verrà sostituito, sempre grazie ai dati di parità, questo potrà essere ricostruito per l'array. )) Contrariamente da quanto possa sembrare, il raid 3 è scarsamente utilizzato in quanto non è capace di gestire richieste multiple; questo a causa del fatto che il dato viene ripartizionato su tutti i dischi dell'array e quindi per le operazioni di I/O sarà necessario impiegare per forza tutti i dischi.
Raid 4
Questo sistema è molto simile al raid di livello 3, opera infatti con n dischi, uno dei quali dedicato alla parità. La differenza dal raid 3 sta nel fatto che come il raid 0, opera a livello di blocco, questo permett di elaborare richieste multiple quando viene effettuata una richiesta per un singolo blocco. Per esempio prendendo in esame la figura a lato, ponendo che è in corso una richiesta per il blocco A0, un eventuale richiesta per il blocco B0 verrebbe messa in coda, una richiesta per il blocco A1 invece potrebbe essere evasa dal disco 2.
Raid 5
Il raid 5 usa la divisione dei datia livello di blocco, ma i dati di parità vengono distribuiti in tutti i dischi dell'array.
Ogni volta che un insieme di blocchi (stripe) deve essere scritto nell'array, un blocco di parità viene generato all'interno della stripe (1 byte ogni 8), se la stripe viene modificata, magari con l'aggiunta o la rimozione di un blocco, il byte di parità viene ricalcolato e riscritto in un altro disco, in questo modo i byte di parità vengono distribuiti su tutti i dischi dell'array.
Il raid 5 si guarda bene dall'utilizzare i byte di parità durante le operazioni di lettura, si avrebbe solo un calo di prestazioni, questi byte vengono utilizzato solo qualora durante la lettura un settore generi un errore CRC.
In tal caso vengono utilizzati i byte rimanenti, più quelli di parità per ricostruire il dato corrotto, stessa cosa nel caso venga sostituito un disco in failure e debba quindi essere ricostruito. Da notare che in caso di errore di CRC, il computer che effettua la chiamata non si accorge minimamente che c'è qualcosa che non va, le operazioni di lettura saranno completamente trasparenti per lui, solo saranno leggermente rallentate a causa del ricalcolo del dato corrotto.
In via del tutto teorica un raid 5 potrebbe gestire un numero infinito di dischi, ma è buona norma in genere non superare mai un array di 14 dischi gestito col raid 5 con un solo blocco di parità per stripe, perchè?
Per la solita faccenda dell'affidabilità media dei dischi, bisogna tenere a mente che la stripe viene suddivisa in tutti i dischi dell'array, quindi se due dischi vanno in failure avremo una perdita irrecuperabile dei dati. Premettendo questo, dobbiamo sapere che la probabilità che due dischi vadano in failure uno dopo l'altro aumenta con l'aumentare dei dischi (ovviamente), quindi in un sistema raid 5 con un grande numero di dischi, mano mano che il numero dei dischi cresce, l'affidabilità media del sistema si abbassa, potrendo addirittura raggiungere un livello inferiore di quello di un singolo disco.
Come si fa a sapere se nel nostro raid 5 l'affidabilità media (MTBF ndr.) raggiunge livelli critici? Bisogna calcolare la probabilità che uno dei restanti dischi (senza contare quello rotto quindi) si rompa, tra il tempo che noi ci accorgiamo, sostituiamo, e ricreiamo il disco; questa infatti non deve essere inferiore all'MTBF di un singolo disco. ((L'angolo della curiosità: Oltre a tutti questo dobbiamo tenere a mente che tanti dischi affiancati aumentano il calore complessivo, che abbassano l'MTBF del sistema. Inoltre i produttori (seri) di server, hanno come regola quella di affiancare in un server raid capable, quello di inserire dischi si identici, ma mai costruiti con numeri di serie consecutivi o identici, vale a dire costruiti nello stesso posto e in periodi ravvicinati, questo perchè dischi prodotti insieme, possono raggiungere la fine della loro vita...insieme :D ))
Raid 6
Ok bella tutta sta menata sul raid 5, ma io ho bisogno di un array di 24 dischi come faccio? Semplice adotti il raid 6! Il raid 6 è un evoluzione del raid 5, effettua sempre la divisione a blocchi, ma i byte di parità vengono scritti sia nella stripe che in una stripe dedicata, ed in un disco diverso, con l'adozione di questa tecnica - chiamata con molta fantasia, a doppia parità - il raid 6 risulta essere molto più ridondante del raid 5, di contro è scarsamente efficiente con un numero di dischi limitato. Per adesso basta, abbiamo visto praticamente tutti i livelli di raid singoli, domani vedremo l'implementazione di livelli di raid annidati.
-
*BSD&Linux, ovvero: come ti tiro su una vpn tra OpenBSD e Linux (debian)
Posted on luglio 1, 2008 | Nessun commentoIeri al lavoro ho imparato come creare un tunnel VPN tra una macchina OpenBSD e una macchina Linux...
La macchina linux in questione è una Debian Etch equipaggiata con OpenSWAN, mentre l'altro endpoint del canale sarà una macchina OpenBSD 4.1 ed utilizzeremo ipsecctl. Ovviamente il tunnel sarà di tipo IPSec.
Riassumiamo le macchine che utilizzeremo per l'esempio: ((Gli indirizzi sono ovviamente inventati, non mi assumo responsabilità qualora adesso, od in futuro, possa succedere qualcosa ad eventuali macchine equipaggiate con tali ip))
ip pubblico linux : 194.173.80.21 subnet vpn : 192.168.168.0/24 ip pubblico openbsd: 213.95.53.44 subnet vpn : 192.168.167.0/24
In IPSec possiamo impostare il collegamento di tipo Tunnel o Transport, noi utilizzeremo il primo, mentre per le fasi di criptazione utilizzeremo:-
3des-md5,modp1024 per la fase 1
-
3des-md5 per la fase 2
Parte 1° Configuriamo OpenSWAN
Creiamo dentro la cartella /etc/ipsec.d/ una cartella che conterrà le configurazioni delle nostre connessioni, io la chiamerò VPN-ATTIVE. Dentro questa cartella creiamo un file che avrà per nome quello della connessione, ad esempio con-bsd-linux, e dentro inseriamoci questi parametri:conn con-bsd-linux type=tunnel left=194.173.80.21 leftsubnet=192.168.168.0/24 leftnexthop=%defaultroute right=213.95.53.44 rightsubnet=192.168.167.0/24 rightnexthop=%defaultroute pfs=no keyexchange=ike auth=esp esp=3des-md5 auto=start authby=secret
Adesso dobbiamo editare /etc/ipsec.conf per includere il file di configurazione del tunnel aggiungendo:include /etc/ipsec.d/VPN_ATTIVE/con-bsd-linux
Adesso dobbiamo definire una PSK da includere nel file /etc/ipsec.secrets noi utilizzeremo per questo esempio "megapassword"194.173.80.21 213.95.53.44 : PSK "megapassword"
Se non ci sono altre vpn attive possiamo restartare il demone ipsec con /etc/ipsec.d/ipsec restart; altrimenti possiamo utilizzare il comando:ipsec auto --add con-bsd-linuxe poi terminiamo la configurazione lato linux con:ipsec auto --rereadsecretsche non fa altro che ricaricare le PSK.Parte 2° Configurazione ipsecctl su OpenBSD
Editiamo il file /etc/ipsec.conf inserendo:ike esp from 192.168.167.0/24 to 192.168.168.0/24 peer 194.173.80.21 \ main auth hmac-md5 enc 3des group modp1024 \ quick auth hmac-md5 enc 3des group none psk "megapassword"
Adesso dobbiamo ri/avviare isakmpd col comando:isakmpd -K -d
con questo comando vediamo se ci sono eventuali errori e non demonizziamo isamkpd, se tutto va bene possiamo rilanciare il comando senza l'opzione -d (eventualmente se è già attivo ricordiamoci di killarlo prima con pkill isakmpd) Adesso possiamo passargli l'intero file di configurazione con il comando:ipsecctl -vv -f /etc/ipsec.conf
Nell'output che segue dovremmo vedere che ipsecctl tenta di stabilire le due fasi del tunnel, qui vediamo anche eventuali errori, se alla fine della fase due vediamo una riga del tipo:C add [Phase 2]:Connections=IPsec-192.168.167.0/24-192.168.168.0/24
allora tutto dovrebbe essere ok, per verificarlo possiamo, lato linux, utilizzare il comando:ipsec auto --stats | grep "SA est"che dovrebbe ritornare un output simile:000 #515: "con-bsd-linux":500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 27017s; newest IPSEC; eroute owner 000 #444: "con-bsd-linux":500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 1325s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0)
su OpenBSD invece usiamo ipsecctl -s all e dovremmo avere:FLOWS: flow esp in from 192.168.168.0/24 to 192.168.167.0/24 peer 194.173.80.21 srcid 213.95.53.44/32 dstid 194.173.80.21/32 type use flow esp out from 192.168.167.0/24 to 192.168.168.0/24 peer 194.173.80.21 srcid 213.95.53.44/32 dstid 194.173.80.21/32 type require SAD: esp tunnel from 194.173.80.21 to 213.95.53.44 spi 0x0d936978 auth hmac-md5 enc 3des-cbc esp tunnel from 213.95.53.44 to 194.173.80.21 spi 0x37236b26 auth hmac-md5 enc 3des-cbc
Ok abbiamo creato la VPN :mrgreen: Adesso per rendere possibile il traffico interessante la vpn dobbiamo creare sui due endpoint due interfaccie virtuali con ip interni alle subnet della vpn: Su linux quindi:ifconfig eth0:1 192.168.168.1 netmask 255.255.255.0 route add -net 192.168.167.0/24 gw 192.168.168.1
Su OpenBSD:ifconfig bnx0 inet alias 192.168.167.1 netmask 255.255.255.0 route add 192.168.168.0/24 192.168.167.1
Ricordatevi di fissare la configurazione nel file /etc/network/interfaces di Linux e nel file /etc/hostname.bnx0 (nel nostro caso) per OpenBSD (per OpenBSD si veda http://www.openbsd.org/faq/faq6.html). Adesso la configurazione del tunnel è completa e funzionante, restano da gestire eventuali mascheramenti ed aperture sui firewall, ma sono operazioni che dipendono dalle vostre necessità e che esulano dall'obiettivo di questo how-to, armatevi quindi di tcpdump e molta pazienza ;) -
-
bash: pushd e popd not found… come risolvere…
Posted on giugno 2, 2008 | 3 commentiChi è abituato a compilare i sorgenti dei software che utilizza, sicuramente oramai si sarà fatto l'abitudine a schiantarsi contro errori improponibili che rendono l'operazione una cosa abbastanza noiosa a volte ((ma che ci volete fare il bello di linux è questo, altrimenti c'è sempre il caro "clicca ed installa" Windows))
Ad esempio ieri mentre tentavo di compilare amule per rilasciare i pacchetti, non si riusciva nemmeno a finire l'autogen.sh perchè al lancio dell'automake restituiva:
bash: pushd: not foundbash: popd: not founde quindi andavano a mancare file importanti per la compilazione (al livello di makefile inesistenti, o script di configure, mica pizza e fichi)... Prima di tutto cerchiamo di capire cosa cavolo sono e a cosa servono quei comandi... Prima di tutto inizio col dire che sono comandi precostituiti della shell ((non sapete cosa significa? cercare comando precostituito in questo blog e già che ci siete iniziate a leggervi le guide perchè ne avete bisogno ;) )) e servono a sostituire quello che normalmente utilizziamo per spostarci tra le directory: cd cd è comodo per l'utilizzo di tutti i giorni, ma quando dobbiamo creare script che hanno a che fare con centinaia/migliaia di livelli di directory, il suo utilizzo diventa via via sempre più complesso e meno comodo. Questi due comandi servono a creare uno stack ((Da wikipedia: In informatica, il termine stack o pila viene usato in diversi contesti per riferirsi a strutture dati le cui modalità d'accesso seguono una politica LIFO (Last In First Out), ovvero tale per cui i dati vengono estratti (letti) in ordine rigorosamente inverso rispetto a quello in cui sono stati inseriti (scritti). Il nome di questa struttura dati è infatti la stessa parola inglese usata, per esempio, per indicare una "pila di piatti" o una "pila di giornali", e sottende per l'appunto l'idea che quando si pone un piatto nella pila lo si metta in cima, e che quando si preleva un piatto si prelevi, analogamente, quello in cima (da cui la dinamica LIFO), anche se è possibile inserire o prelevare elementi anche dalla coda, infatti più in generale la pila è un particolare tipo di lista in cui le operazioni di inserimento ed estrazione si compiono dallo stesso estremo. Per maggiori informazioni su cosa è uno stack, in particolare per capire i processi di push e pop, cliccare qui )) di directory, che possiamo maneggiare per richiamare un determinato percorso senza dover scrivere "cd" seguito da n ((con n tendente ad infinito :mrgreen: )) ../../ o peggio ancora slogandoci il dito mignolo (io uso quello) battendo TAB all'impazzata per scrivere l'intero percorso che mi interessa. Con il push inseriamo il percorso corrente nello stack, con popd richiamiamo l'ultimo percorso dello stack, o quello che ci interessa, per entrarci poi dentro. Per capire l'utilizzo vi consiglio di digitare:info pushdinfo popdcapirete cosi l'utilizzo dei comandi con le relative opzioni. Bene perchè in ubuntu questo non va? Per una politica di canonical che ha scelto di linkare il comando sh con il comando dash, che altro non è che un tipo di shell come la bash. In molte distribuzioni infatti se digitiamo "ls -l /bin/sh" vedremo che questo è linkato su /bin/bash, su ubuntu invece no, ed è questa la causa del problema, perchè come detto prima pushd e popd sono comandi precostituiti della shell bash. Risolvere è quindi semplice, basta relinkare sh a bash...$ sudo rm -f /bin/sh $ sudo ln -s /bin/bash /bin/sh ed ecco pushd e popd che tornano a funzionare automagicamente.
Update: (Grazie Oracolo)
Come gentilmente oracolo mi fa notare nel suo commento, la via più corretta da seguire sarebbe quella di dare: sudo dpkg-reconfigure dash e rispondere "no" alla domanda "Si vuole utilizzare dash come sostituto di sh?", in questa maniera in effetti si evita che ogni futuro aggiornamento vada a ricreare il link costringendoci a doverlo ri-modificare.Effetti collaterali:
Pensavate fosse cosi semplice? NA vi siete sbagliati :mrgreen: in generale questo non dovrebbe causare problemi, ma può darsi che qualche script creato da un sistema ubuntu in special modo, e pensato da usarsi su ubuntu, potrebbe non funzionare a causa di questo link modificato, basterà modificare lo script in questione è dirgli di usare bash e non dash. -
Rsyncbackup per avere backup schedulati su debian etch
Posted on maggio 18, 2008 | Nessun commentoOggi vedremo come effettuare backup schedulati, incrementali o statici, con rsyncbackup, un comodo script in perl che in collaborazione con l'utile comando rsync ci permetterà di effettuare il mirroring dei dati...
Perchè innanzitutto effettuare il backup? Beh chi lavora in ambientazione server saprà sicuramente il perchè bisogna farlo, i crash dovuti a dischi che se ne vanno sono quasi all'ordine del giorno, se ci si trova a dover gestire un parco macchine di modeste dimensioni. I backup ci salvano la vita, è sempre meglio schedularli settimanalmente o mensilmente in base alle nostre necessità, perchè quando avremo dei problemi ci basterà effettuare un ripristino e nel peggiore dei casi la perdita di dati sarà esigua. Ci sono svariati tool su linux che permettono di farlo, anche se secondo molti "dd" è il migliore per effettuare backups a livello più basso; ((con dd infatti avremo una copia esatta dei dati, con settori, numero di cilindri ecc, con rsync invece avremo un mirroring a livello più alto, dei file cioè, potremo infatti avere al massimo una copia dei file con i relativi permessi)) noi oggi però vedremo come effettuare un mirroring dei dati tra un server di produzione e un server di backup. Per l'esempio di oggi poniamo che il server di produzione abbia indirizzo ip uguale a 10.0.0.1 mentre il server di backup 10.0.0.2
Installazione del software:
Procediamo con l'installazione dei pacchetti necessari sul server di produzione:apt-get install openssh-client openssh-server rsync unzip
e quindi sul server di backup:
apt-get install openssh-client openssh-server rsync
Chiavi SSH
con rsync faremo uso di ssh per il trasferimento dei files di backup tra i server, sarà quindi necessario creare le apposite chiavi per l'autenticazione: Sul server di backup:ssh-keygen -b 4096 -t rsa -C "Chiave RSA per il server di Backup"Durante la creazione della chiave dovremmo avere queste domande:Enter file in which to save the key (/root/.ssh/id_rsa): Created directory '/root/.ssh'. Enter passphrase (lasciamo il campo vuoto per non impostare una password): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_rsa. Your public key has been saved in /root/.ssh/id_rsa.pub. The key fingerprint is: 23:e5:b2:2e:86:2f:e9:bc:76:56:83:6a:8d:f0:d6:23 Chiave RSA per il server di Backup
Adesso dobbiamo aggiungere questa chiave pubblica alla lista delle chiavi autorizzate:cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keysAdesso dobbiamo copiare questa chiave sul server di produzione:scp /root/.ssh/id_rsa root@10.0.0.1:/root/.ssh/adesso concludiamo il lavoro sul server di backup creando le cartelle necessarie ad ospitare i dati:mkdir -p /backups/configs/ mkdir /backups/logs/ /backups/manual/Operazioni sul server di produzione:
Adesso testiamo la connessione, se tutto è andato bene dovremmo poter loggarci sul server di backup senza problemi:ssh -i /root/.ssh/id_rsa root@10.0.0.2se tutto va bene possiamo sloggarci e cominciare a scaricare rsyncbackup sul server di produzione:cd /usr/src wget http://rsync-backup.googlecode.com/files/rsyncbackup.zip unzip -d rsyncbackup rsyncbackup.zipUna volta scaricato lo script dobbiamo copiare alcuni file in determinate cartelle:cp /usr/src/rsyncbackup/rsyncbackup/rsyncbackup /usr/local/bin/ chmod 700 /usr/local/bin/rsyncbackupe quindi creare i files di configurazione:mkdir /etc/rsyncbackup/ mkdir /var/log/rsyncbackup/ touch /etc/rsyncbackup/config.conf /etc/rsyncbackup/destinations.conf \ /etc/rsyncbackup/sources.conf /etc/rsyncbackup/backupset.conf ln -s /var/log/rsyncbackup/ /etc/rsyncbackup/logsLa configurazione:
Andiamo a modificare il file /etc/rsyncbackup/config.conf che contiene le opzioni generali per tutti i backups, in modo che il suo contenuto sia simile a questo: ((notare che queste non sono altro che le opzioni da passare a rsync, potete anche utilizzare la sintassi compressa, tipo -p per --perms))
Adesso inseriamo in /etc/rsyncbackup/sources.conf le "sorgenti" ossia le cartelle che dovrebbero essere soggette a backup: ((Sintassi: tag|local:path|condizione, come vediamo per i log abbiamo scelto la tag "logs" con path "/var/log" e con condizione "true", cioè abilitato al backup, viceversa avremmo usato "false"))--stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
configs|local:/etc|true| logs|local:/var/log|true|
Ed ora nel file /etc/rsyncbackup/destinations.conf inseriamo le destinazioni, cioè dove i backup dovranno essere memorizzati:store_configs|ssh[key=id_rsa,incremental=7,tag=increment]:root@10.0.0.2:/backups/configs/|/usr/bin/traceroute -m 2 10.0.0.2|--bwlimit=300 --delete store_logs|ssh[key=id_rsa,incremental=7,tag=increment]root@10.0.0.2:/backups/logs/|/usr/bin/traceroute -m 2 10.0.0.2|--bwlimit=300 --delete store_manual|ssh[key=id_rsa]:root@10.0.0.2:/backups/manual/|/usr/bin/traceroute -m 2 10.0.0.2|
Con questo set di istruzioni, ad esempio la prima riga, noi indichiamo al server di produzione di autenticarsi al server di backup con la chiave ssh privata, terremo 7 bakcup incrementali che avranno nel nome la tag "increment" per indicare a quale stato di incrementazione siamo arrivati, inoltre abbiamo aggiunto un comando shell che indica di effettuare un traceroute verso il server di backup, se il server è attivo (quindi raggiungibile) ed è almeno a 2 hop dopo il server di produzione, il backup partirà, abbiamo settato anche un limite di banda per il trasferimento, ed infine aggiunto l'opzione delete, che indica che i file che vengono eliminati sul server di produzione, col prossimo incremento di backup, dovranno essere eliminati anche sul server di backup. Per finire dobbiamo modificare il file /etc/rsyncbackup/backupset.conf in modo che il suo interno sia simile a questo:[manual] configs,logs|store_manual|true| [daily] logs|store_logs|true| [weekly] configs|store_configs|true|
Adesso che tutti i file di configurazione sono stati creati possiamo procedere al test di funzionamento: Digitandorsyncbackup -x /etc/rsyncbackup -vv -d -s manualDovremo ottenere un output di questo generePATH DIR:/etc/rsyncbackup/ LOG DIR:/etc/rsyncbackup/logs CONFIG_FILE:/etc/rsyncbackup/config.conf SOURCE FILE:/etc/rsyncbackup/sources.conf DESTS_FILE:/etc/rsyncbackup/destinations.conf BACKUPSET_FILE:/etc/rsyncbackup/backupset.conf BACKUPSET:manual Backup set 1 configs to store_manual Source : configs Source dir : [local] /etc Source opts : Source cond : true Destination : store_manual Destination dir : [ssh] root@10.0.0.2:/backups/manual/ [key=id_rsa,sshport=22] Destination opts: Destination cond: /usr/bin/traceroute -m 2 192.168.0.102 Config options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup Backupset opts : true All options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup All conditions : /usr/bin/traceroute -m 2 10.0.0.2 true true Backup set 2 logs to store_manual Source : logs Source dir : [local] /var/log Source opts : Source cond : true Destination : store_manual Destination dir : [ssh] root@10.0.0.2:/backups/manual/ [key=id_rsa,sshport=22] Destination opts: Destination cond: /usr/bin/traceroute -m 2 10.0.0.2 Config options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup Backupset opts : true All options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup All conditions : /usr/bin/traceroute -m 2 10.0.0.2 true true
E' andato tutto liscio? ok allora siamo arrivati al momento magico, diamo il via al nostro primo backup:rsyncbackup -x /etc/rsyncbackup -b -s manualOk scheduliamolo nel nostro crontab:crontab -einserendo:# m h dom mon dow command # Backups 00 02 * * * /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s daily >> /var/log/rsyncbackup/backup.daily.log 00 04 * * 0 /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s weekly >> /var/log/rsyncbackup/backup.weekly.log
Vi ricordate che nel file backupset.conf abbiamo settato tre direttive, manual, daily e weekly? Servivano proprio a questo, con la prima stringa richiameremo il backup set daily ogni giorno alle 2 di notte, mentre il weekly ogni domenica alle ore 04:00 (con la seconda stringa). Non vi basta? non vi fidate? aggiungete allora il comando -e casella@dominio.it al comando rsyncbackup (prima degli >> per intenderci), e se ci saranno errori avrete una mail che parte in automatico che ve lo notifica. ;)
