ordine Archive

  • Finalmente libertà di scelta per il browser su windows.

    Finalmente libertà di scelta per il browser su windows.

    Vi ricordate quando parlai di una possibile decisione della comunità europea, che obbligava Microsoft a preinstallare diversi browser su Windows, in nome della libertà di scelta? Bene nelle prossime settimane questo diventerà realtà.

    Full Story

  • A network cable is unplugged

    A network cable is unplugged

    Quando qualcuno va gridando che bisogna effettuare il cablaggio strutturato come dio comanda dategli retta..

    Full Story

  • Interfaces bonding su Debian

    Interfaces bonding su Debian

     

    Semplice how to per la configurazione del bonding su due o più interfaccie su Linux.

    How to testato su distribuzione Debian.

    Full Story

  • Backup dei dati con Bacula

    Backup dei dati con Bacula

    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.

    Full Story

  • Mysql master replica how-to

    Mysql master replica how-to

    Con mysql possiamo creare un cluster di ridondanza dei nodi, il tutto ci viene già fornito da mysql stesso.

    Vediamo come con questo semplice how-to.

     

    Full Story

  • Crackare una chiave WPA/WPA2 con una GPU NVIDIA

    Crackare una chiave WPA/WPA2 con una GPU NVIDIA

    Cracker (salati e non) di tutto il mondo unitevi! a quanto pare è possibile crackare una chiave wpa/wpa2 con un attacco brute force, sfruttando la cpu e la gpu nvidia del proprio pc velocizzando fino a 100 volte l'operazione.

    Full Story

  • Progettato un nuovo algoritmo di routing che promette di aumentare significativamente le prestazioni della rete internet

    Progettato un nuovo algoritmo di routing che promette di aumentare significativamente le prestazioni della rete internet

    Leggo stamani sul sito dell'università di san diego, california, che i ricercatori di suddetta università hanno sviluppato un nuovo protocollo di routing di tipo link state basato su un nuovo algoritmo, che promette di aumentare significativamente le prestazioni di internet...sono inoltre molto contento di notare che al 99% in italia questa notizia non è stata ancora pubblicata, ed il portalinux lo sta facendo per voi {#emotions_dlg.wink}

    Schema del protocollo link state OSPF

    Full Story

  • bash: pushd e popd not found… come risolvere…

    bash: pushd e popd not found… come risolvere…

    Chi è 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: cdcd è 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.

    Full Story

  • National Geographic Style: l’evoluzione del sistemista

    National Geographic Style: l’evoluzione del sistemista

    Non l'ho scritto sul blog anche perchè non credo che vi interessi :mrgreen: ma dal 16 giugno cambierò sede di lavoro e qualifica, che da allora sarà ufficialmente quella di Sistemista Linux...

    Tutto questo non per dirvi che cambierò lavoro ma per condividere una storiella che gira da tempo su internet e che a me piace molto soprattutto perchè gran parte rispecchia la realtà, buona lettura quindi ;)

    Documentario: Il sistemista Linux

    di Michele Sciabarrà ((Vi consiglio di farvi un giro sul suo sito, ci sono una marea di racconti come questo tutti divertenti)) michele@sciabarra.com da http://michele.sciabarra.com/page/Documentario_SistemistaLinuxPer la serie il mondo di Slash, il vostro Piero BSD ha realizzato in esclusiva per voi un interessante documentario che osserva la specie protetta "sistemista Linux" nel suo habitat naturale.

    Le caratteristiche

    Il sistemista Linux si è adattato nel corso dei millenni a vivere in un ambiente difficile, impervio, nel quale è perfettamente integrato. Il sistemista Linux infatti vive su hardware obsoleto e lento, ma che è capace di rendere efficiente e soddisfare la sua fonte primaria di cibo, il "datore di lavoro". La sua attitudine è quella di allignare su macchine di cinque o dieci anni, con pochi mega di ram, ottimizzando uno a uno i servizi in esecuzione e riducendo l'occupazione di memoria e lo spazio disco perche funzionino senza frullare (almeno, non troppo).Naturalmente il sistemista Linux ha dovuto subire una serie di trasformazioni evolutive per riuscire in queste straordinarie imprese, e ha sviluppato una serie di adattamenti che lo distinguono dalle specie a lui vicine, ovvero i suoi cugini sistemista Windows e sistemista AS/400.Innanzitutto ha sviluppato una resistenza incredibile alla più naturale delle intemperie della natura, la mancanza di budget. Dove il sistemista Windows sopravvive appena, con ampio uso di warez e serialz, e il sistemista AS/400 soccombe quasi all'istante per asfissia, il sistemista Linux riesce a cacciare e a portare al datore di lavoro database, mail server, e perfino applicazioni web, muovendosi nelle impervie montagne open source. I suoi cugini riescono a stento a a trovare qualche utility nelle colline shareware.Le prede dei cugini sono accettate dal datore di lavoro perché solitamente non le pagano. Il datore di lavoro si è infatti abituato a cliccare "Register Later" senza troppe domande alle schermate di registrazione, e a non scomporsi o a chiedere spiegazioni alle affermazioni "è passato un mese, occorre reinstallare". Infatti sa che le spiegazioni potrebbero creare problemi che preferisce ignorare.

    Il comportamento

    Ma per riuscire in queste imprese, il sistemista Linux ha dovuto pagare un prezzo, evolvere e adattarsi. Questi adattamenti si notano nel suo comportamento istintivo. Innanzitutto ha una caratteristica inusuale che non si trova in nessuno dei suoi cugini, chiamata "passione".Questa particolare forma di adattamento si manifesta con comportamenti alquanto bizzarri. Il sistemista Linux infatti spesso non va via dal lavoro alle cinque in punto, smettendo di lavorare mezz'ora prima, come è comune tra i suoi cugini. Invece tende a protrarre il suo orario di lavoro oltre le sei, le sette, le otto, di solito con la motivazione "devo finire di compilare il kernel per la nuova scheda di rete".Ma questo è solo il primo di una serie di comportamenti che lo distinguono da tutte le altre specie della famiglia dei sisteminidi. Per esempio, quando un utente (un protetto del suo datore di lavoro) ha un problema di stampa, non considera "far stampare un windows" il compito fastidioso che lo fa pensare alle dimissioni.Con estremo stupore degli scienziati, vede nella compatibilità Linux con Windows la sfida suprema, il fine ultimo della sua vita. E quando lotta a sangue per configurare il file server Samba, si sente appagato, è felice quando è immerso nei casini più profondi. Quando lo si vede aggirarsi tra le macchine della sala server mormorando "non funziona un ca**o", gli scienziati sono concordi nell'affermare che è immerso in una forma di estasi.Quando esce dall'estasi, il sistemista Linux ha la tendenza a eseguire un curioso rituale per comunicare al capo branco (il responsabile EDP) la vittoria. Il rituale, sempre uguale, che si tramanda da secoli e che si presume essere istintivo e non appreso (vari sistemisti Linux non in contatto tra di loro si comportano allo stesso modo), è il seguente:Il sistemista Linux entra all'improvviso nella stanza del capo, solitamente senza bussare e mentre questi sta parlando con l'amministratore delegato. Il nostro protetto reca in dono al capo alcuni fogli con su scritto "Pagina di prova della stampante". Dopodiché il sistemista urla "Funziona!!!" e esegue un balletto in cui ripete la suddetta frase (si presume di significato magico) girando in tondo tre o 4 volte. Il rituale termina quando viene buttato fuori, con minacce di licenziamento, nel preciso momento in cui si appresta a spiegare come ha fatto.

    Rapporti con i simili

    E' affascinante osservarlo quando si relaziona con i suoi simili. Tende a parlare di argomenti religiosi come il Token Kerberos che si deve prendere con il Modulo PAM. E' impressionante la sua conoscenza dei testi sacri, che recita a memoria, spiegando ai suoi cugini nel branco "quale è la differenza tra un workgroup, un dominio e un active directory per l'autenticazione".I suoi cugini infatti, che dovrebbero esserne esperti, sono abituati a ignorare del tutto queste informazioni, a saperle solo quando si devono certificare M$XE (cioè solo quando cambiano lavoro). Di solito infatti le installazioni vengono fatte (gratis) da chi gli ha venduto (a caro prezzo) la licenza. L'assenso all'acquisto viene dato quando si legge nell'offerta la frase sacra "licenza software, installazione compresa".Una caratteristica innata, che favorisce la sopravvivenza dei cugini, è che quando i sistemi hanno dei problemi di configurazione, viene rilasciata una nuova versione del software. Per questi motivo si ha la bizzarra caratteristica naturale, che il sistemista Linux è più esperto di Windows dei sistemisti Windows, e i cugini vanno a chiedere consiglio a lui.Naturalmente il subdolo cugino pone le domande sempre nel modo in cui il nostro protetto non può resistere. Ovver in forma di sfida "vuoi vedere che il tuo linux non è capace, come il mio windows, di collegare in trust il vecchio dominio"? "Certo che può" "E come fa?". Allora il sistemista Linux per esemplificare prima spiega come si fa Windows, dando la risposta alla domanda che il primo voleva, e poi rimane solo quando spiega come si fa, "in modo meno facile ma più efficiente" con Linux.

    I Predatori

    Il sistemista Linux è una specie in pericolo, continuamente minacciata da un tipo di predatore molto subdolo chiamato "Commerciale Microsoft". In realtà il predatore non cerca di cibarsi direttamente di lui, ma del cibo che viene offerto dal suo datore di lavoro, di solito su proposta dei suo cugini sistemisti Windows, che vengono a loro volta da lui cibati.Questo predatore infatti si ciba dello stesso cibo del nostro protetto, e pertanto rischia di affamarlo, allontanando da lui la fonte di cibo principale, trasformando il suo habitat in un ambiente a lui ostile, o costringendolo a mutare in uno dei suoi cugini. Mutazione che gli è, nella maggior parte dei casi, fatale. Quindi questo tipo di commerciale è il suo più temuto nemico. La lotta tra i due si tramanda da millenni e si svolge seguendo uno schema che è quasi sempre lo stesso.Solitamente al primo assalto del predatore, il nostro protetto soccombe. Infatti il commerciale generalmente va nell'ufficio del capo vestito in giacca e cravatta di tutto punto, e arriva puntuale alle 9 e 30 di mattina. Quando il sistemista Linux arriva al lavoro, solitamente la lotta per la difesa del territorio è già in parte persa.Infatti sono le 10.45, e già da più di un'ora il commerciale ha raccontato un nutrito numero di barzellette e storielle sulla gente che crede di risparmiare con Linux, e si ritrova invece a spendere una barca di soldi in gente inaffidabile, che arriva in ritardo al lavoro, parla un gergo strano e incomprensibile, è incazzosa, e ha atteggiamenti di ostilità per partito preso nei confronti di Windows.Il sistemista Linux, vestito in jeans, sporco perché è stato disteso sotto gli armadi della sala server, risponde all'attacco in modo scomposto. Cerca di giustificare il ritardo sul lavoro: di solito spiega che ha fatto tardi, perché la sera precedente ha dovuto risolvere una serie di dipendenze degli rpm: infatti ha dovuto installare la nuova versione del server apache, perché le agenzie non si connettono per colpa di un bug nell'SSL di internet explorer.Purtoppo il capo non sa cosa sono gli rpm e le dipendenze, e capisce solo che come al solito è in ritardo, che le cose non funzionano, che quello che dice è incomprensibile, e che se la sta prendendo con qualcosa di Windows (c'è ne è sempre una). Al che il commerciale osserva che "forse il bug è di Linux"; al che il sistemista Linux perde completamente la battaglia: si incazza come una iena, e comincia a inveire contro Bill Gates monopolista. A questo punto viene cortesemente fatto accomodare, perché la sua presenza non è più necessaria per la riunione.La sera viene sottoposto alla firma dell'amministratore delegato l'ordine per il nuovo Windows 2003 Server super scontato, che deve sostituire il file server samba tanto faticosamente reso funzionante dal sistemista Linux. Le motivazioni addotte sono "perché ha l'active directory che consolida i domini", indipendentemente dal fatto che esista un solo dominio e il capo non abbia idea di cosa serva l'active directory.

    Le difese naturali

    Per difendersi da questi attacchi il nostro protetto ha sviluppato una serie di sottili difese che gli consentono di sopravvivere. Innazitutto la scelta della femmina: la sua livrea nottura (l'hacker) è terribilmente attraente per femmine figlie di amministratori delegati, che si oppongono al loro potere plutocratico.Pertanto il pericolo, ovvero l'ordine per il Windows Server 2003 viene avvistato in tempo: la figlia dell'amministratore delegato è quasi sempre la sua ragazza. A quel punto, con estremo dolore, ma necessario per la sua sopravvivenza, comincia a studiare i listini Microsoft e a comunicare con i suoi fratelli con il tam-tam delle mailing list, e scopre quali programmi dovranno essere OBBLIGATORIAMENTE aggiornati con l'installazione del nuovo super server "ultra scontato".Il nostro protetto avverte quindi i suoi simili (e in particolare il suo capo) del pericolo che incombe, facendo comparire nella bacheca accanto alla macchinetta del caffè, un grafico dei costi di aggiornamento degli ALTRI software, che dovranno essere affrontati dall'azienda in conseguenza dell'acquisizione del nuovo server. In effetti il sistemista Linux è incapace di fare grafici e analisi di costi. Il grafico di solito viene fatto dalla femmina, che studia economia alla Bocconi, e per di più con Excel (cosa che gli avrebbe causato rigurgiti e problemi di vista).Ma la strategia di difesa di solito funziona: l'ordine viene annullato "su consiglio del capo, in seguito ad una più approfondita analisi what-if della dinamica dei costi". E il sistemista Linux, ancora una volta, è riescito a difendere il suo habitat dal suo predatore naturale.

    Full Story

  • Linux Bash: Operazioni di base sui file

    Linux Bash: Operazioni di base sui file

    Questa sera iniziamo a vedere i primi comandi che ci permettono di interagire con la shell linux per la gestione dei file ((Per file intenderemo sia il vero e proprio file che le directory))...

    in particolare vedremo l'utilizzo dei comandi:

    lselenca i file contenuti in una directory
    cpCopia un file
    mvRinomina o sposta un file
    rmRimuove un file
    lnCrea un collegamento ad un file
    ls [opzioni] [files]coreutils

    /binstdin stdout -file --opt --help --version
    Il comando ls elenca tutti i file contenuti in una directory, con il comando semplice, quindi senza opzioni, otterremo la lista di file e directory contenute nella posizione corrente.Possiamo anche chiedere ad ls di elencarci i file contenuti all'interno di un determinato percorso, inserendolo dopo ls:$ ls dir1 $ ls /dir1/dir2Tra tutte le opzioni disponibili con ls, che verranno elencate dopo, le più importanti sono -a e -l, vediamo perchè: Di default ls nasconde i file che iniziano con un . (punto), in quanto in ambiente linux sono file da considerare come "nascosti"; utilizzando -a otterremo l'elenco completo dei file, inclusivo dei file nascosti. Mentre con -l otterremo un elenco più dettagliato con (nell'ordine) tipologia di file, permessi, utenti e gruppi assegnati, dimensioni e data di ultima modifica/accesso.
    -rw-r--r-- 1 root root 6925 Apr 30 15:02 pkg
    Ecco quindi tutte le opzioni disponibili per questo comando:
    Opzioni Utili
    -aElenca tutti i file compresi quelli il cui nome inizia con un punto
    -lElenco esteso, completo degli attributi dei file, se si aggiunge l'opzione -h vengono visualizzate le dimensioni in Kilobyte, Megabyte, Gigabyte anziche in bytes.
    -FAggiunge alcuni simboli ai nomi per identificare i files: "/" per le directory, "*" per gli eseguibili, "@" per il link simbolici, "|" alle pipe con nome, "=" ai socket.
    -iPrepone gli inode dei files.
    -sPrepone le dimensioni in blocchi
    -RElenca il contenuto ricorsivamente (per le directory)
    -dElenca solo il nome delle directory e non il contenuto.
    cp [opzioni] files (file|dir)coreutils

    /binstdin stdout -file --opt --help --version
    Il comando cp copia un file in un altro:$ cp file1 file2oppure più file in una directory:$ cp file1 file2 file3 dirUtilizzando le opzioni -a e -r, possiamo copiare in maniera ricorsiva le directory.
    Opzioni Utili
    -pCopia non solo il contenuto, ma anche i permessi, il timestamp ed owner e gruppo.
    -aE' una combinazione delle opzioni -R -p e -d. la prima per copiare in maniera ricorsiva una directory, la seconda per copiare anche i permessi dei files, e la terza per i link tra i files.
    -iModalità interattiva, chiede conferma prima di sovrascrivere i files.
    -fForza la copia, se un file di destinazione già esiste viene copiato incondizionatamente.
    mv [opzioni] sorgente destinazione coreutils

    /binstdin stdout -file --opt --help --version
    Il comando mv può semplicemente rinominare un file:$ mv file1 file2oppure può spostare files e directory in un altra directory di destinazione:$ mv file1 file2 file3 dir4 dir5 dir_destinazionePer questo comando abbiamo solo -i e -f come opzioni che sono analoghe a quelle del comando cp.
    rm [opzioni] files|directory coreutils

    /binstdin stdout -file --opt --help --version
    con rm cancelliamo invece i files$ rm file1 file2oppure$ rm -r dir1 dir2Qui oltre ad -i e -f, come abbiamo appena visto, possiamo utilizzare anche -r per agire ricorsivamente sulle directory.
    ln [opzioni] sorgente destinazione coreutils

    /binstdin stdout -file --opt --help --version
    Con Linux possiamo effettuare, come su windows, dei collegamenti ai files; solo che a differenza di questo sistema, su linux vengono chiamati link. Un link è un riferimento, per l'appunto, ad un altro file e viene creato mediante il file ln. I link si dividono in due tipi, softlink o anche link simbolici, che fanno riferimento al file tramite il suo percorso:$ ln -s file1 softlinkBisogna fare attenzione ai link simbolici, in quanto se cancelliamo "file", softlink punterà ad un percorso non valido e quindi sarà un link orfano. Un hard link invece è una specie di copia di un file, ((Comunicazione di servizio ai puristi del settore: lo so che non è una copia, ho fatto un esempio per rendere più pratica e facile la comprensione)) a dir la verità effettivamente l'hard link è semplicemente un secondo nome dato ad un file, esso non punta al percorso come il simbolico, ma punta al suo iNode, ((Nei sistemi Unix un inode è una struttura dati sul file system che archivia le informazioni base dei file, delle cartelle o di qualsiasi altro oggetto. Le informazioni includono:* la dimensione del file e la sua locazione fisica (se risiede su un dispositivo a blocchi come, ad es., un hard disk) * il proprietario e il gruppo di appartenenza * le informazioni temporali di creazione, modifica e ultimo accesso * il numero di collegamenti fisici che referenziano l'inode * i permessi d'accessoIl termine inode normalmente si usa sui dispositivi a blocchi che gestiscono file, cartelle e collegamenti simbolici. Il concetto è particolarmente importante quando è necessario ripristinare un file system danneggiato.Ogni inode ha associato un numero univoco all'interno del dispositivo e ogni file presente è identificato come un collegamento fisico all'inode tramite il suo numero. Quando un programma cerca di accedere ad un file tramite un nome (es. documento.txt), il sistema operativo cerca l'inode corrispondente e recupera tutte le informazioni sopra descritte per operare correttamente con il file.Per recuperare le informazioni sull'inode dei file si può usare la chiamata di sistema stat. From Wikipedia.)) ciò rende possibile la cancellazione del file "padre" senza comportare un errore con il link rendendo questo orfano:$ ln file hardlinkPerchè utilizzare uno piuttosto che un altro? Non c'è una regola precisa, il tutto va in base alle proprie esigenze, bisogna tenere conto infatti che un link simbolico, che in quanto tale fa riferimento al percorso assoluto del file padre, può effere piazzato in qualsiasi partizione/dispositivo; un hard link invece no, in quanto facente riferimento all'inode del file padre, che non avrebbe significato in un altra partizione o disco. Un link simbolico può puntare ad una directory, un hard link invece è possibile puntarlo ad essa solo se si è il superutente.
    Opzioni Utili
    -sCrea un link simbolico, senza questa opzione di default viene creato un link fisico.
    -iModalità interattiva, Chiede conferma prima di sovrascrivere i file di destinazione.
    -fCondizione forzata, se il link di destinazione esiste lo sovrascrive incondizionatamente.
    -dPermette ad un superutente di creare un hard link ad una directory
    Per sapere dove punta un link simbolico possiamo utilizzare uno dei due seguenti comandi:$ readlink link1$ ls -l link

    Full Story

  • Rsyncbackup per avere backup schedulati su debian etch

    Rsyncbackup per avere backup schedulati su debian etch

    Oggi 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/logs
    La 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))
    --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
    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"))
    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: Digitando rsyncbackup -x /etc/rsyncbackup -vv -d -s manualDovremo ottenere un output di questo genere
    PATH 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:manualBackup 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 trueBackup 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. ;)

    Full Story

  • Creiamo un server DNS con Bind [Parte 4° - named.conf il file di configurazione di BIND]

    Creiamo un server DNS con Bind [Parte 4° - named.conf il file di configurazione di BIND]

    Eccoci giunti all'epilogo, questa ultima parte parla del file di configurazione di bind, già una parte l'abbiamo vista con la parte precedente...

    bind viene gestito interamente da questo file, posto generalmente in /etc/bind; al suo interno troviamo direttive e istruzioni sull'ubicazione dei file di zona all'interno del file system.

    In questo articolo vedremo le direttive principali del file di named, in quanto sono davvero tante, per chi è interessato lo invito a consultare il file di documentazione situato in /usr/share/doc/bind9.

    La sintassi di base è come quella del linguaggio C ossia ogni direttiva termina con un ";" e i commenti si distinguono per i caratteri "//" oppure per stringhe di frasi incluse tra "/*" e "*/"

    Tutte le direttive vengono inserite tra parentesi graffe "{", che a loro volta, seguono una direttiva principale. Infine, bisogna tener conto del fatto che bind legge il file named in maniera sequenziale, da sopra a sotto quindi, e pertanto quando lo si configura bisogna avere cura di farlo in un determinato ordine, le direttive più specifiche devono essere scritte prima di quelle generiche. In quanto uan direttiva più generica può far uso di una direttiva più specifica, ne consegue che quest'ultima deve essere quindi prima dichiarata per poter essere utilizzata.

    Partiamo con la prima direttiva le acl (Access control list):

    acl nome-acl { lista_di_indirizzi };
    Le acl ci sonsentono di raggruppare determinati ip o range di ip sotto un unico nome, per poter poi essere gestiti in maniera più facile in un eventuale configurazione successiva.Un altra direttiva è controls:
    controls { inet ( indirizzo_ip | * ) [ port numero_porta ] allow { acl } keys { lista_chiavi }; };
    con questa direttiva,il sistemista definisce un canale per poter gestire da remoto il servizio. All'interno di controls vediamo un parametro nuovo keys:
    key nome_chiave { algorithm stringa; secret stringa; };
    con questa direttiva definiamo una chiave condivisa, per l'autenticazione al server da remoto con connessioni "signed" (autenticate). La direttiva "algorithm" definisce con quale algoritmo la chiave viene "firmata", attualmente è possibile utilizzare solo hmac-md5. Mentre secret è una stringa a 64 bit, utilizzata da "algorithm" per effettuare il signing della chiave.All'interno di named possiamo anche includere file esterni, per l'eventuale utilizzo di ulteriori direttive, come è facile intuire, questo lo si fa con una direttiva di include:
    include nome_del_file;
    A seguire troviamo una delle direttive più estese possibili, parliamo di option, qui vi tratterò solo le direttive più importanti di option, fermo restando che nella documentazione ufficiale trovate tutto:
    option { directory /var/named; listen-on { indirizzo_interfaccia; }; ulteriori opzioni ...; };
    la prima direttiva che vediamo è directory che utilizziamo per specificare la directory di lavoro di named (include vi dice qualcosa? :P ) Poi ne troviamo una che merità particolare attenzione: "listen-on". Come è facile intuire con questa direttiva, diciamo a bind di mettersi in ascolto su un determinato indirizzo ip, questo perchè il servizio di bind, per default, appena avviato si mette in ascolto su tutte le interfacce di rete presenti; Con questa direttiva possiamo istruire bind per mettersi in ascolto su un solo indirizzo ip, nel caso avessimo un server con diverse schede di rete. Attenzione che dobbiamo inserire l'indirizzo dell'interfaccia e non il nome dell'interfaccia.Come ulteriori opzioni possiamo avere:pid-file: Si usa se si vuole utilizzare una directory differente dalla default /var/run per salvare il pid-file. Named quando parte avvia più di un processo, il pid-file è usato da alcune applicazioni per conoscere il numero del processo "parente" quello cioè che ha poi generato gli altri processi "figli".port: Serve a specificare una porta udp/tcp diversa dalla standard 53. E' inteso per l'utilizzo nei test di debug visto che un server che lavora su una porta diversa dalla 53 sarà completamente impossibilitato a comunicare con il resto del Domain Name System globale. notify: Questa opzione ha una sintassi definibile come "booleana" in quanto accetta parametri come yes o no. Serve a impedire o permettere che il server notifichi i cambiamenti dei suoi file di zona ai server presenti nel record di risorsa NS e ai server specificati con l'opzione also-notify. Può essere specificato anche come opzione per singolo file di zona. Il suo valore di default è yes. recursion: Anch'essa di sintassi booleana, se posta come yes il server cercherà di elaborare una risposta ad una query del client anche se non presente nella sua cache. Notare che se posta come no non impedisce ai client di ottenere una risposta dalla cache del servizio, l'unica cosa sarà che non vi saranno aggiunte nella cache in seguito a query dei clients. Il suo valore se non specificato è yes. Questa opzione può difendere il named da attacchi tipo DNS-poisoning che utilizzano la funzione di recursive quering. forwarders: Con questa opzione posso definire gli indirizzi di altri server DNS ai quali il named si appoggerà per le risposte a query di cui non ha autorità e solitamente si definiscono i DNS del proprio Internet Service Provider. Di norma quando il server non ha la risposta in cache si appoggia ai root servers a meno che non si sia specificata questa opzione, in questo caso si possono tranquillamente eliminare i riferimenti alla zona radice "." nel named.conf. forward: Serve a specificare la policy da usare in caso una richiesta non autoritativa non sia presente nella cache e si siano specificati dei forwarders. I suoi parametri sono first e only. allow-notify: Permette di specificare una lista di indirizzi (o anche una precedentemente definita acl) a cui è permesso notificare i cambiamenti di un file di zona. Può essere specificata come opzione di una singola direttiva di zona e in tal caso sovrascrive la direttiva globale. allow-transfer: Permette la specifica di una lista di indirizzi (o una acl) a cui è concesso effettuare un trasferimento di zona. Può essere specificato per un singolo file di zona e in tal caso sovrascrive l'opzione globale. allow-recursion: Specifica la lista di indirizzi o l'eventuale acl ai quali è concesso effettuare query ricorsive. Si ricordi che non permettere ad un host di avere risposte a query ricorsive non impedisce che le ottenga se presenti in cache.Oltre a tutto questo, l'abbiamo già visto, abbiamo la direttiva per le zone e relativi files.

    Credits:

    Per la stesura di questa guida è stato preso come riferimento, il sito openskills in particolare per questa ultima parte, che ringrazio per il contributo che da alla comunità per l'accrescimento del sapere globale.

    Full Story

Pagina 1 di 212

Canonical URL by SEO No Duplicate WordPress Plugin