TopoLinux - Vecchiomago
Transcript
TopoLinux - Vecchiomago
Anno 1 - Numero 2 Novembre 2005 TopoLinux L’e-zine italiano completamente dedicato al mondo del Pinguino Il nostro staff : Direttore: Lemoeb ([email protected]) Redattore: Neon ([email protected]) Correttore di bozza: DnDVault ([email protected]) Giornalisti Freelance: Psicomante Stonedz MGS Neo909 Versione elettronica curata da: DnDVault ([email protected]) Typeset with LATEX 2" i ©2005 TopoLinux Staff Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being Editoriale, Ringraziamenti, News da TopoLinux and Prossimamente su TopoLinux, with the Front-Cover Texts being: “Anno 1 - Numero 2 Novembre 2005 TopoLinux L’e-zine italiano completamente dedicato al mondo del Pinguino” and anything before this section, following the title itself. There are no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License. ©2005 TopoLinux Staff È garantito il permesso di copiare, distribuire e/o modificare questo documento seguendo i termini della GNU Free Documentation License, Versione 1.1 o ogni versione successiva pubblicata dalla Free Software Foundation; con le Sezioni Non Modificabili Editoriale e Ringraziamenti con i Testi Copertina: “Anno 1 - Numero 2 Novembre 2005 TopoLinux L’e-zine italiano completamente dedicato al mondo del Pinguino” Una copia della licenza è acclusa nella sezione intitolata GNU Free Documentation License. Indice Indice ii Editoriale iii Ringraziamenti iv News da Topolinux Numeri arretrati . . . Lettere alla redazione Newsletter . . . . . . Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v v v v v 1 Articoli 1.1 Scegliere una distro Linux . . . . . . . . . 1.2 Il coast to coast da Windows a Linux . . . 1.3 Installazione di Debian Sarge . . . . . . . 1.4 Gestione dei pacchetti RPM . . . . . . . . 1.5 Accelerazione 3D in X.org . . . . . . . . . 1.6 S.M.A.R.T. . . . . . . . . . . . . . . . . . . 1.7 Creare uno script di backup per un server 1.8 Splittare un file . . . . . . . . . . . . . . . 1.9 Introduzione a CVS con SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 4 7 12 14 18 21 26 32 2 Pillole 2.1 Colorare la shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Terminale confuso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 A proposito di... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 41 43 43 3 GNU Free Documentation License 3.1 GNU Free Documentation License - Italiano . . . . . . . . . . . . . . . . . . . . . . . . . . 44 49 Prossimamente su Topolinux 54 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii Editoriale Finalmente è uscito il secondo numero di TopoLinux. Abbiamo avuto molte visite in questo mese, molte più di quelle che avevamo previsto. La cosa non può che farci piacere ovviamente. Abbiamo cambiato il vestito a Topolinux e va quindi un grande ringraziamento a Uracile, l’autore di questo layout. Sono inoltre nate una serie di affiliazioni tra diversi siti e portali, la lista completa la trovate nel riquadro relativo agli affiliati. Ma ora veniamo al numero che vi apprestate a leggere. In questo numero si affronteranno diversi argomenti e soprattuto è un numero più ricco del precedente, in quanto abbiamo incrementato l’organico di due unità. Persone che si sono rivelate molto valide e che speriamo continuino a contribuire per la crescita di TopoLinux. Doveroso quindi dare il benvenuto a stonedz e neo909. Parte inoltre in via sperimentale una nuova sezione, chiamata “Le videoguide di Topolinux”. Cosa troverete in questa sezione? Per ora soltanto il filmato dell’installazione della Debian Sarge, se poi sarà cosa gradita, cercheremo di aumentarne i contenuti. Quindi fateci sapere le vostre impressioni. Dato quindi il benvenuto e fatti i ringraziamenti, non mi resta che augurarvi una buona lettura “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb iii Ringraziamenti Mi sembra più che doveroso, dopo l’editoriale passare ai ringraziamenti, quindi ringrazio: Fabiana per il nome dell’ezine; Rockaffè per tutti i suggerimenti dati; MakPaolo per il supporto con i css; AngelinoAnt per il supporto hack phpBB; Ed in particolare tutti i membri dello staff ! “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb iv News da Topolinux Numeri arretrati Chi è nuovo e capita qui per la prima volta, ma anche chi non ha fatto in tempo a leggere tutti gli articoli presenti nel precedente numero, non deve preoccuparsi. È infatti possibile scaricare il numero 1 dell’E-zine dall’apposito link, oppure visualizzare tutti gli articoli fino ad ora scritti selezionando la voce “visualizza arretrati” nell’apposito riquadro. Lettere alla redazione Abbiamo quasi finito di allestire la sezione “Lettere alla Redazione”, siamo fiduciosi di renderla disponibile già dal prossimo numero. Nel caso in cui vogliate inviare una lettera alla redazione di Topolinux prima dell’apertura dell’apposita sezione, potrete utilizzare l’indirizzo topolinux[NOSPAM]@altervista.org (va rimosso [NOSPAM] dall’indirizzo). Newsletter Vi ricordo che per rimanere sempre informati di tutte le novità relative a Topolinux abbiamo una NewsLetter. Iscriversi è semplicissimo, basta inserire il proprio indirizzo email nell’apposito riquadro e cliccare sul pulsante “Iscrivi”. Topolinux non invierà mai spam e gli indirizzi email degli iscritti non saranno ceduti a terzi. Forum Ebbene si, oltre a questa e-zine, Topolinux ha anche un forum in cui discutere su tutto quello che riguarda il mondo del pinguino. Per crescere abbiamo bisogno anche di te! Quindi cosa aspetti? Accedi al forum di Topolinux connettendoti a: http://topolinux.altervista.org/forum “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb v 1 Articoli 1.1 Scegliere una distro Linux Scrivo questo piccolo articolo per cercare di fare un minimo di chiarezza sulle tante e tante distribuzioni linux che sono presenti sul mercato libero. Premetto che non conosco tutte le distribuzioni, ce ne sono veramente tante, ma vista le crescenti domande in cui viene continuamente richiesta la migliore, la più semplice, la più intuitiva e via dicendo distribuzione: : : Bisogna partire dal presupposto che ogni utente linux ha la sua distro preferita. Quindi quando chiedete un consiglio sono tutti pronti a portare avanti la loro. Io stesso consiglio molto la SlackWare, con la quale mi sono trovato sempre bene, ma mi rendo anche conto che per una persona alle prime armi potrebbe risultare un po’ ostica. Visto che ormai siamo invasi dalle LiveDistro, cioè quelle distribuzioni che possono partire direttamente da CD, vi consgilio in primis di provare una di queste, quanto meno per cercare di capire un po’ cos’è il mondo Linux. Ne cito alcune: Knoppix: forse la più famosa livedistro. Stabile, affidabile e con un ottimo riconoscimento delle periferiche. DyneBolik: orientata al multimediale; utilizzatela se volete provare il Pinguino nel mondo del multimedia (ambiente grafico ritenuto un po’ anomalo dagli utenti alle prime armi). Slax: basata su Slackware. È molto stabile. Dopo aver giocato un po’ con queste distro allora iniziate a farvi una serie di domande per capire il motivo che vi spinge ad utilizzare il sistema del pinguino e soprattutto quanto volete impegnarvi nell’installazione e nella configurazione. Possiamo a questo punto evidenziare 3 macro gruppi: Installazione e configurazione semplice: • Mandriva; • Knoppix (oltre che Live può essere montata su disco); • Fedora Core; • Suse. 1 CAPITOLO 1. ARTICOLI 2 Installazione e configurazione intermedia: • Gentoo Stage 3; • Arch Linux. Installazione e configurazione più impegnativa: • Debian; • Slackware; • Gentoo Stage 1 e 2. Sta’ prendendo molto piede anche Ubuntu, distribuzione basata su Debian che si suddivide in Ambiente grafico Gnome e Ambiente grafico KDE (Kubuntu). Ovviamente non le ho citate tutte, ma soltanto le più conosciute. Infine scegliere una distro piuttosto che altra, può essere ricondotta a 3 fattori fondametali: 1. stabilità; 2. facilità di installazione; 3. corredo di pacchetti. Mandriva ha dei pacchetti software molto aggiornati, questo però va a discapito della stabilità, in quanto software molto recenti possono presentare bug ancora sconosciuti. Debian in versione stabile, ha un corredo di pacchetti software con versioni stabili anche se meno recenti della precedente.Questa distribuzione è di fatto una delle più stabili. SlackWare è basata essenzialmente sulla stabilità ed affidabilità. Come debian utilizza pacchetti software testati.È definita una distro pura e risulta molto ostica ad un newbie. Gentoo fonda la sua forza sulla compilazione. Installare Gentoo dallo Stage 1 significa compilare tutto sulla propria macchina, e quindi avere il massimo delle prestazioni. Concludendo: • volete installare Linux “come” avete fatto con Windowz? Allora la distro più indicata è Mandriva. • volete litigare un po’ o molto per installare e configurare linux, ma essere più partecipi durante questi processi? Allora scegliete fra Debian, Slackware e Gentoo. Ricordate che: • Linux è il kernel e non la distribuzione. Mandriva, SlackWare, Debian e via dicendo hanno sempre lo stesso kernel, salvo alcune modifiche specifiche. • Se vi sentite smanettoni e sperimentatori, non usate una distro semplice. Imparerete molto di più con le complesse. CAPITOLO 1. ARTICOLI 3 • Non gettate subito la spugna! All’inizio Linux vi sembrerà un mondo un po’ pazzo, ma con il tempo imparerete a viverci e a sfruttarne le risorse. • Leggete il più possibile! Documentarsi prima di smanettare il sistema, può evitarvi grandi emicranie. • Domandate! Ci sono tante persone pronte ad aiutarvi se ne avrete bisogno, quindi non lesinate nelle domande! “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb CAPITOLO 1. ARTICOLI 4 1.2 Il coast to coast da Windows a Linux Tratto da un post sul forum http://forum.altervista.org Ciao a tutti. Siccome ci sono già milioni di topic nei forum che ne parlano, ho pensato di scrivere questa sorta di vademecum per coloro che si affacciano per la prima volta al mondo del pinguino. Qui non parlerò delle varie distribuzioni, se siete interessati a ciò potete andarvi a leggere l’articolo “scegliere una distro linux” sempre su questo numero dell’e-zine. Allora, come premessa vediamo la domanda che tutti coloro che vogliono fare il “salto” si chiedono: è meglio Windows o Linux? La risposta è: nessuno dei due. O meglio, sono due cose estremamente diverse. Usando Windows, vi sarete sicuramente resi conto del fatto che è molto semplice e intuitivo: quasi da ebeti. Inserite due informazioni minime e cliccate duecento volte su “Avanti” fino a che non avete installato quanto vi serve. Questo è l’esempio che mi pare più calzante. Bene, non aspettatevi ciò da Linux. Linux non è un sistema “baby-sitter” come Windows: per fare le cose vi occorrerà lavorarci un po’ sopra. Ma questo è il bello del pinguino. Inoltre, l’impostazione di Linux fa si che sia infinitamente più sicuro di Windows. L’installazione dei programmi, ad esempio, può risultare ostica ai primi tentativi, ma con un minimo di applicazione e soprattutto voglia di fare, che per usare un sistema GNU/Linux è essenziale, riuscirete ad installare tutto ciò che vorrete: sia che si tratti di installare qualcosa usando tool appositi (è il caso del mitico apt delle distribuzioni basate su Debian) – facilino – oppure compilando sorgenti (con i classici configure-make-make install). In ogni caso, una cosa è certa: se sarete perseveranti, niente vi soddisferà come usare un sistema Linux. Se siete dei programmatori o aspiranti tali, Linux rappresenta per voi l’ideale, in quanto al suo interno sono già presenti compilatori/interpreti di tutti i maggiori linguaggi. Potreste anche aver deciso di provare linux per motivi filosofici (quelli che lo fanno sono pochini purtroppo), e allora non vi servono altri preamboli. Ma se avete deciso di tuffarvi insieme a Tux (il pinguino x chi non lo sapesse), allora mi sento di riassumervi alcuni indubbi vantaggi dell’utilizzo di un sistema Linux: • la sicurezza: nessun sistema è sicuro quanto Linux o un altro Unix-based. Navigare in internet da Linux vi eviterà un sacco di fastidi che invece Windows non vi risparmia, anzi forse ve li accentua. • l lato server: ormai è risaputo: nessun server batte quelli Linux: se volete usare il pinguino come server, allora siete davvero a cavallo. • il fattore economico: che non è da sottovalutare soprattutto in ambito aziendale. Linux è gratuito. Non dovrete più spendere le cifre classiche di Windows. Sistema operativo: 0 euro. Suite office (es. OpenOffice): 0 euro. Editing video (es. kino): 0 euro. Player Audio, Firewall, Antivirus, Fotoritocco, .... : 0 euro. Gli unici eventuali soldi che spenderete saranno quelli per alcune distribuzioni che offrono a pagamento delle features aggiuntive. Per il resto i vostri biglietti resteranno al calduccio nelle vostre tasche. Dopo questo lungo preambolo, veniamo alla pratica. CAPITOLO 1. ARTICOLI 5 Come migrare da Windows a Linux Tanto per cominciare, immagino vi vogliate rendere conto esattamente di cosa si tratti in realtà di questo famigerato Linux. Quindi, niente è potrebbe essere meglio di una bella distribuzione live che vi da la possibilità di provare il pinguinello senza dover andare a toccare l’hard disk. Potete procurarvi una delle varie distribuzioni live (personalmente non esco dal gregge e vi consiglio Knoppix1 ) scaricandole dai vari mirror che trovate nei siti delle stesse distribuzioni. Quando avete scaricato l’immagine della distribuzione (un file .iso di grandi dimensioni) dovete masterizzare un cd con l’immagine “bruciata” della distribuzione. Per fare ciò aprite il vostro programma di masterizzazione (nel mio caso DeepBurner) e selezionate “Scrivi disco da immagine iso” o un comando simile. Dopo aver scritto il disco, riavviate il computer e impostate il vostro BIOS affinchè come primo settore di boot abbia il lettore cd. Inserite il disco della distribuzione nel lettore cd e aspettate che venga letto. Se tutto è ok dovrebbero apparire schermate che mostrano l’avvio corretto della distribuzione. Dopo aver tentato di riconoscere le varie periferiche del vostro computer, partirà il sistema vero e proprio. Se state usando la distribuzione Knoppix, allora sarà piuttosto semplice “gironzolare” e scoprire com’è fatta: come usare i vari programmi ecc: : : In ogni caso è bene che vi leggiate uno dei vari documenti online sui comandi basilari di una shell (terminale che in windows si chiama “prompt dei comandi”) linux o di come è organizzato il disco. Se la prova con la distro live vi è piaciuta, allora potrebbe essere giunto il momento di installare sul vostro computer una distro linux. Quasi tutte le distribuzioni live possono anche essere installate sul disco rigido, ma io ve lo sconsiglio. Se siete totali neofiti o comunque non ancora esperti di Linux, potrebbe fare al caso vostro una distribuzione semplice da usare ed user-friendly che non vi faccia pesare eccessivamente il salto da Windows. Penso che la migliore in questo caso sia Mandrake (o Mandriva). Scaricate la/le immagine/i da internet come avete fatto per la live e bruciatene le immagini. Fatto ciò impostate il bios come prima e inserite il primo cd. Partirà il programma di installazione che (nel caso delle distro come Mandrake, Fedora, SuSE e da adesso anche Debian) sarà visuale e relativamente semplice da portare a termine. Se avete deciso per un dual boot Windows/Linux (è la cosa migliore per i neofiti) allora ricordatevi che all’avvio del computer dovrete scegliere se far partire il sistema Linux o Windows. Tornando al processo di installazione, mi soffermerò sul punto in cui tutti si incagliano la prima volta: il losco partizionamento. Questo tetro individuo, che in Windows non era neanche contemplato, non è altro che la suddivisione del vostro disco in tante parti più piccole in cui mettere sistemi operativi o semplicemente archiviare files. In una stessa partizione non possono stare due o più sistemi operativi, e per questo Linux ha bisogno di almeno una partizione tutta sua più un’altra partizione per il cosiddetto swap (non ne parlerò qui, ma sappiate che è necessario). I tool grafici di partizionamento delle distribuzioni ormai sono molto semplici da utilizzare e intuitivi anche per i meno “dotti”. Per prima cosa quando parte il programma di partizionamento dovrete rimpicciolire la partizione Windows, che normalmente occupa tutto il disco, usando il tool della distribuzione (prima di fare ciò vi consiglio caldamente un backup dei vostri dati). Poi generalmente dovrete fare questo: • creare nello spazio non partizionato una nuova partizione di root (’ / ’) abbastanza cicciosa (scegliete voi quanti GB, ma 5 potrebbero essere ottimi) di tipo “ext3” o “reiserfs”; • creare nello spazio non partizionato una nuova partizione per lo swap (settate il tipo come Linux swap); 1 http://www.knoppix.org CAPITOLO 1. ARTICOLI 6 • creare nello spazio non partizionato una nuova partizione home (’ /home ’) bella grassa in cui si conserveranno tutti i files degli utenti che accederanno a Linux. Sicuramente non è una guida esauriente su come partizionare, ma è un buon inizio da cui partire. Una volta finito di partizionare probabilmente dovrete scegliere quali pacchetti (programmi o librerie) installare. Fatto ciò proseguite nell’installazione fino al compimento dell’opera e ricordate di installare il boot loader (LILO o GRUB) nel vostro MBR (Master Boot Record): questo non è altro che il programma che partirà all’avvio del sistema e vi farà scegliere quale sistema fare partire. Se l’installazione arriverà alla fine senza che il computer inizi ad emettere un sospetto odore di carne bruciata, allora state allegri: avete installato il vostro sistema GNU/Linux ! Non credo ci sia altro da dire, se non questo: non smettete mai di smanettare; provate il vostro sistema Linux, usatelo, leggete documentazione e tornate a smanettare sulla vostra shell...cosa c’è di più bello al mondo? Ciao, Federico Ruggi aka Neo909 CAPITOLO 1. ARTICOLI 7 1.3 Installazione di Debian Sarge Ciao a tutti! In questa guida parleremo dell’installazione di Debian Sarge, l’ultimo rilascio stabile della comunità Debian. Prima di cominciare ad entrare nel vivo ecco una piccola panoramica: • Architettura processore: Alpha, Arm, HPPA, i386, IA64, m68k, Mips, PPC, S390, Sparc • Journaled File Systems: ext3, JFS, ReiserFS, XFS • Kde 3.3.2 • Gnome 2.8.1 • Xfree86 4.3.0 • OpenOffice 1.1.3 È disponibile nei seguenti formati: • Netinstall, una piccola immagine da 30mb o 130mb con tutto il necessario per effettuare l’installazione via rete; • CD, una serie di 14 cd contenenti tutti i pacchetti di debian; • DVD, 2 DVD con tutti i pacchetti debian. Noi analizzeremo l’installazione di debian usando CD o DVD. Partiamo! Appena inseriremo il nostro disco di installazione (netinstall, cd o dvd) la situazione che ci apparirà sarà più o meno quella di fig. 1.1. Come vedete io ho indicato linux26 affinchè l’installatore installi Figura 1.1: Schermata di boot di Debian Sarge. quella versione del kernel! CAPITOLO 1. ARTICOLI 8 Dopo varie schermate di caricamento ci verra’ chiesta la lingua e noi sceglieremo italiana, stessa risposta per il territorio e il layout della tastiera (a meno che voi non abbiate preferenze diverse!) L’installazione ora scansionerà tutto il contenuto di CD e DVD alla ricerca di pacchetti che sono installabili. Il processo varia in base alla dimensione del supporto scelto... Al termine della scansione verrà cercata un’eventuale scheda di rete e nel caso in cui venga trovata verrà tentata una configurazione automatica. Se la ricerca di un server DHCP è positiva allora vengono richiesti: Hostname. L’installatore consiglia debian ma voi potete scegliere quello che volete... Figura 1.2: Dialogo per l’inserimento del nome dell’host. Nome del dominio. Qui è proposto fastwebnet.it poiché il computer su cui è stato installato debian era collegato in rete con Fastweb. Figura 1.3: Dialogo per l’inserimento del nome del dominio. CAPITOLO 1. ARTICOLI 9 Partizionamento ATTENZIONE! ESEGUITE SEMPRE BACKUP E FATE ATTENZIONE A QUELLO CHE FATE! POTRESTE CANCELLARE DATI IMPORTANTI SE NON FATE ATTENZIONE! Quindi, oltre ai soliti backup necessari, consiglio anche se siete alle prime armi di staccare tutti i dischi con altri os e tenere solo quello destinato ad ospitare il pinguino. Il partizionamento è sicuramente l’operazione più’ difficile dell’installazione perché se sbagliamo questo passo possiamo compromettere anche altri os che sono installati sulla nostra macchina... Inoltre questa parte di installazione è particolarmente difficile da trattare visto che le situazioni in cui è un utente con i suoi dischi sono praticamente infinite... Tratteremo quindi l’opzione più semplice e comune ovvero quella di dedicare un intero disco a debian se avete bisogno di aiuto postate sul forum di topolinux.altervista.org ! Appena avviato il software per partizionare vi chiederà se volete utilizzare tutto il disco e scegliendo questa opzione vi chiederà in che modo volete utilizzare il disco. • Scegliamo di Cancellare l’intero disco e premiamo [invio] • Scegliamo “Tutti i file in una partizione” e premiamo [invio] Se abbiamo fatto tutte le operazioni correttamente otterremo qualcosa di simile a fig. 1.4 Figura 1.4: Dialogo al termine della prima fase di partizionamento. Come vedete abbiamo 2 partizioni, una di root in ext3 e una di swap. Scegliamo ReiserFS al posto di ext3 per avere un filesystem maggiormente performante! Selezioniamo quindi la partizione num1 (come da immagine) e premiamo [invio]... Come vedete in fig. 1.5 è selezionata l’opzione “Usato come: Ext3 journaling file system”... quindi non dovrete altro che premere [invio] e andare a scegliere ReiserFS. Fatto ciò tornerete nella schermata precedente, selezionate “Preparazione di questa partizione completata” e premete [invio]! Tornerete alla schermata principale di partizionamento! Scendete fino a selezionare “Terminare il partizionamento e scrivere i cambiamenti sul disco” e premete invio... Successivamente scegliete si per apportare le modifiche ai dischi e proseguire l’installazione! CAPITOLO 1. ARTICOLI 10 Figura 1.5: Dialogo per la scelta del tipo di filesystem. Installazione sistema di base Ora che i dischi sono pronti l’installazione procederà installando i pacchetti di base e il kernel sul disco fisso... Non dovete far altro che attendere pazientemente la fine di questa operazione! Al termine dell’installazione vi verrà chiesto se volete installare il bootloader grub... Rispondete di si e attendete finché il sistema chiede di riavviarsi. Togliete il CD o DVD e riavviate. Avete quindi finito la prima parte di installazione di debian! Seconda parte dell’installazione Al termine della prima partenza tornerete nella modalità di installazione per terminare le ultime configurazioni e installazioni! Fuso Orario. La prima cosa che vi verrà chiesta è se vi trovate o meno nel fuso orario GMT, rispondete di no e attendete che vi venga posta la seguente domanda, ovvero se siete nel fuso orario Europe/Rome e a questa rispondete di si! APT. L’installazione ora procedeà e vi chiederà che metodo di accesso agli archivi deve utilizzare apt. I casi in cui vi potete trovare sono 2: 1. Avete una connessione veloce (ADSL o superiore): questo vi permette di scaricare tutto il software presente nei repository debian in pochissimo tempo! 2. Non avete una connessione veloce: è sconsigliato utilizzare la rete per scaricare software in quanto sarebbe veramente lunga l’attesa... più consigliato è utilizzare i cd (12 in tutto) o i dvd (2 in tutto) Fate la vostra scelta e nel caso in cui abbiate una buona linea consiglio di scegliere i mirror fastweb. Per farlo dopo aver scelto Http cliccate su Italia e poi su debian.fastweb.it. In entrambe le scelte dovete attendere che il sistema verifichi i repository e, successivamente vi verrà chiesto che tipo di software volete installare, le scelte sono molte (Ambiente desktop, Server Web e altri) voi non fate nessuna di queste scelte e andate avanti! Ora non vi resta che attendere che l’installazione sia finita. CAPITOLO 1. ARTICOLI 11 User e password Ultimo passo dell’installazione è decidere la password di root, uno (o più user) e le loro relative password. Purtroppo non posso essere molto d’aiuto in queste scelte se non nel dirvi che le password non devo essere uguali sia per root che per user e che esse devono essere complesse (solite raccomandazioni dunque). Login e uso Debian Infine vi apparirà la finestra di login: inserite come user “root” e la relativa password! Il vostro sistema non ha nessun server grafico (quindi niente finestre per intenderci) e nessun programma... non preoccupatevi grazie ad apt basteranno un paio di righe da shell per installare il tutto! Scegliete la configurazione che volete avere! KDEBase. apt-get install x-window-system-core kdebase kdm GnomeBase. apt-get install x-window-system-core gnome-desktop-environment gdm KDE completo. apt-get install x-window-system-core kde kdm Gnome completo. apt-get install x-window-system-core gnome gdm XFCE. apt-get install x-window-system-core xfce Buon divertimento, Neon CAPITOLO 1. ARTICOLI 12 1.4 Gestione dei pacchetti RPM Il formato RPM Parliamo di gestione dei pacchetti in ambiente Linux: parliamo di RPM. Tanto per cominciare, RPM sta a RedHat come APT sta a Debian. Il nome RPM deriva da RedHat Packet Manager, in quanto fu RedHat per prima che utilizzò questo sistema per gestire in maniera efficace i propri pacchetti. Attualmente RPM è largamente utilizzato da note distribuzioni quali la superata RedHat, la sua figlioccia Fedora, Mandrake & derivate e SuSE. Il principale vantaggio di usare i gestori di pacchetti, invece delle normali tarball, è che la loro installazione/aggiornamento/rimozione è estremamente rapida e semplificata; ricordo che le tarball sono i pacchetti compressi in formato .tar.gz, .tar.bz2, .tgz che solitamente vanno installati con ./configure, make e make install, a parte su qualche distribuzione come SlackWare. I file che il sistema RPM è in grado di processare sono ovviamente quelli con estensione .rpm; questi sono file binari che contengono oltre al pacchetto anche tutte le informazioni (nome, versione, ecc..) relative ad esso. L’utilizzo di RPM è estremamente semplice ed immediato, in quanto permette agevolmente di gestire i pacchetti che vogliamo sulla nostra Linux Box. Vediamo un esempio di installazione. Per questo articolo uso come esempio il file fpc-2.0.0-0.i586.rpm scaricabile dal sito http:// www.freepascal.org che è il file RPM del Free Pascal Compiler. Dopo aver scaricato il file (più avanti si vedrà che è anche possibile scaricare e installare direttamente il pacchetto tramite RPM), apro il terminale e con un esplicativo comando ls esamino la situazione: Figura 1.6: Il pacchetto RPM FreePascal. Abbiamo quindi il .rpm nella posizione voluta. Con il sistema RPM il comando di installazione di un pacchetto è: rpm -i pacchetto Quindi non ci resta che effettuare il login come utente root tramite il comando su e lanciare RPM con i parametri detti poc’anzi (vedi fig. 1.7). Ecco fatto. Adesso il compilatore è installato e pronto all’uso. Per essere ancora più sicuri si potrebbe fare il whereis di fpc, ma non è necessario, visto che l’operazione è conclusa con successo. Gli altri comandi di RPM che ci possono servire sono questi: • rpm -U pacchetto: questo comando aggiorna (U = upgrade) il pacchetto selezionato. • rpm -e pacchetto: questo comando disinstalla il pacchetto selezionato. Ad esempio, proviamo a disistallare FPC digitando dalla shell sempre come utente root: rpm -e fpc ed il risultato è quello mostrato in fig. 1.8. CAPITOLO 1. ARTICOLI 13 Figura 1.7: Installazione di un pacchetto. Figura 1.8: Rimozione di un pacchetto. Come vedete il comando di disinstallazione è riuscito e se digito fpc (che lanciava il compilatore) il terminale mi dice che fpc non c’è: missione compiuta! Ci sono poi alcuni parametri utili che si possono passare a RPM; per conoscerli (ce ne sono tantissimi) vi rimando alla pagina del manuale di RPM, che trovate digitando come solito man rpm. Prima ho accennato al fatto che RPM può scaricare e installare automaticamente un pacchetto; è proprio così. Infatti nel comando di installazione visto in precedenza (rpm -i pacchetto) c’è la possibilità di inserire un indirizzo HTTP o FTP al posto della path del file in locale: in poche parole posso dare il comando rpm -i ftp://sito.ext/mirror/pacchetto ed RPM provvederà a scaricare il pacchetto desiderato e installarlo come si conviene. Ricordo che per poter effettuare tutto questo bisogna essere loggati come root (comando su). Alcuni ulteriori comandi utili: • rpm -i force pacchetto: questo comando forza l’installazione del pacchetto, sostituendo i file già presenti da precedenti installazioni; • rpm -q -a (o -qa): visualizza tutti i pacchetti installati; • rpm -q -f (o -qf) file: visualizza il pacchetto/i da cui deriva il file; • rpm -q -i -l pacchetto: visualizza informazioni sul pacchetto ed elenca i file presenti nel pacchetto. Ciao, Federico Ruggi aka Neo909 CAPITOLO 1. ARTICOLI 14 1.5 Accelerazione 3D in X.org Nella scorsa puntata abbiamo trattato la configurazione base di X.org, tralasciando tutta la parte dell?accelerazione 3d e degli orpelli grafici. In questo secondo articolo verrà trattata proprio la configurazione di OpenGL, il tuning dei driver binari Nvidia e la configurazione delle ombre e delle trasparenze. Un cenno sulle OpenGL OpenGL (Open Graphic Library) è uno standard aperto per la gestione della grafica. Sviluppato inizialmente da SGI per le sue workstation con sistema operativo IRIX (una versione di unix), si è lentamente evoluto ed ogni casa produttrice di schede grafiche ne implementa una propria versione. I driver che per Windows (ad esempio i forceware) sono delle librerie dll, si interfacciano tramite l’AGP alla scheda grafica, richiamando funzioni che usano VertexShader, PixelShader. Su Linux è tutto molto simile, ma bisogna avere un modulo del kernel che gestisce la comunicazione con la scheda grafica e l’accesso diretto. Le implementazioni di OpenGL sono svariate. Esistono le implementazioni native di X.org (le MesaGL), quelle di Nvidia ed ATI. Ma non si deve confondere l’implementazione delle API (Application Program Interface) OpenGL con i driver che permettono l’accesso diretto alla scheda grafica. La DRI (Direct Rendering Infrastructure) ne è un esempio: è un framework che permette l’accesso diretto all’hardware grafico in un ambiente X. Ma il DRI serve principalmente per accelerare (e quindi avere l’accesso diretto) alcune schede ATI, S3, SIS, 3dfx, Intel, Matrox, CirrusLogic e altre. Potete notare che se fate partire un’applicazione OpenGL senza driver specifici, i frames per secondo (FPS) sono molto bassi. Questo perché tutto il lavoro se lo carica la CPU. Noi invece vogliamo sfruttare la GPU per la maggior parte dei calcoli sulle trasformazioni geometriche, e altri effetti grafici. Inoltre quasi tutte le schede grafiche implementano funzioni per la gestione della grafica 2D. Usando dei driver che consentono un accesso diretto, velocizzeremo la computazione anche delle librerie 2D. Dobbiamo quindi installare i driver. Installiamo di drivers: NVidia Partiamo quindi dalle schede Nvidia che sono le più facili da usare, perché Nvidia sviluppa dei propri driver, piuttosto ben fatti e facili da installare. La procedura più semplice nelle distribuzioni a pacchetto è installare i driver tramite il software di aggiornamento: apt-get in Debian/Ubuntu come ha illustrato Neon nell’articolo del numero scorso o YasT2 in SuSE o ancora Emerge in Gentoo. Scarichiamo dalla pagina (nel momento in cui scrivo questa è l’ultima versione uscita) http:// www.nvidia.com/object/linux_display_ia32_1.0-7676.html il file, sotto forma di script eseguibile da console, NVIDIA-Linux-x86-1.0-7676-pkg1.run. Nel caso siate interessati a nuovi aggiornamenti, potete controllare su http://www.nvidia.com/object/linux_display_archive.html. Per poter effettuare correttamente l’installazione dei drivers è necessario che X.org non sia in esecuzione e quindi, una volta aperta una console di root dovremo digitare: init 3 sh NVIDIA-Linux-x86-1.0-7676-pkg1.run Questo installerà tutto il necessario sul nostro sistema. Lo script vi porrà diverse domande: nel caso vi chieda se può provare a cercare un modulo adatto per il vostro kernel nel sito nvidia rispondete si se non avete i sorgenti del kernel e non avete voglia di scaricarli, in caso contrario rispondete no. Le MesaGL saranno backuppate e potranno essere ripristinate in ogni momento. Una volta terminata l’installazione, si potrà interagire con l’installer nei seguenti modi: CAPITOLO 1. ARTICOLI 15 • nvidia-installer -uninstall: disinstallerà tutti i driver e i moduli NVidia, e ripristinerà le GLX di Mesa (le MesaGL); • nvidia-installer -latest: per conoscere l’ultima versione dei Linux Nvidia Drivers; • nvidia-installer -update: per aggiornare automaticamente i drivers. Per provare se l’installazione è stata completata con successo sarà sufficiente digitare su console: glxinfo | grep -i "direct rendering" se vediamo direct rendering: Yes allora possiamo far girare glxgears senza problemi. Inoltre per rendere effettive le modifiche al server X, ricordo che bisogna riavviarlo. Se usate un login grafico (KDM, GDM), è sufficiente premere [Ctrl + Alt + Backspace]. Nel caso non usiate nessun login grafico, riavviate X con startx. Configurazione del file xorg.conf Nella sezione Module, commentate (#) eventualmente le sezioni: Load "dri" Load "GLcore" Aggiungete invece: Load "glx" Nella sezione Device Section, cambiate: Driver "nv" con Driver "nvidia" Per quanto riguarda la comunicazione con il chipset che controlla l’AGP, di default viene caricato il modulo AGPGART, incluso nel kernel ufficale; nvidia consente di usare il suo modulo per l’agp, ovvero l’NVAGP. Per usarlo settate in Section Device: Option "NvAgp" "val" Dove val può assumere uno tra i seguenti valori: • 0 non utilizza nessun modulo agp; • 1 utilizza il modulo NvAgp, se possibile; • 2 utilizza il modulo AGPGART, se possibile; • 3 prova ad utilizzare prima l’AgpGart, e in caso di errore l’NvAgp. In genere non ci sono differenze sostanziali tra i due moduli, ma NvAGP potrebbe andare meglio con le nuove schede di Nvidia e AGPgart meno bene perché basato su un vecchio modulo reso opensource da Nvidia tempo fa. CAPITOLO 1. ARTICOLI 16 Section "Device" Identifier "Card0" Driver "nvidia" Option "NvAGP" "1" EndSection Per controllare l’AGP digitate su shell: cat /proc/driver/nvidia/agp/status L’output vi dirà a che velocità è impostato attualmente l’AGP Status: Enabled Driver: NVIDIA AGP Rate: 8x Fast Writes: Enabled SBA: Enabled Per togliere il fastidioso logo di NVidia all’avvio di X.org sarà sufficiente aggiungere l’opzione: Option "NoLogo" "1" In ultimo si può aggiungere: Option "RenderAccel" "1" per abilitare l’accelerazione hardware per l’estensione del RENDER. Questa opzione è sperimentale quindi consiglio di non abilitarla, se non per coloro che vogliono provare le performance di questa nuova feature. nVIDIA afferma che l’abilitazione di questa opzione è a nostro rischio e pericolo. Tutta la lista delle innumerevoli opzioni potete leggerla qui: ftp://download.nvidia.com/XFree86/Linux-x86/1.0-7676/README.txt Molte di queste però sono configurabili tramite il Nvidia Control Panel, che consiglio di installare perché piuttosto avanzato. È inserito nei recenti pacchetti, ma in alcune distro è necessario installarlo esplicitamente. Ad esempio: • Debian: apt-get install nvidia-settings • Gentoo: emerge nvidia-settings Per lanciare il pannello, basta digitare su console: nvidia-settings Effetti grafici (composite) con X.org Dalla versione 6.8.0 X.org supporta l’ombreggiatura e l’ombra sulle finestre. Per abilitarle dovete avere installato xcompmgr e transset. Per installare i due programmi: • apt-get install xcompmgr transset (Debian/Ubuntu); • emerge xcompmgr transset (Gentoo). CAPITOLO 1. ARTICOLI 17 Per le altre distro spero ci siano i pacchetti. :D Per usare queste nuove feature è consigliabile abilitare il RenderAccel nello xorg.conf (vedi sopra). Nello xorg.conf dovete fare alcune modifiche. Innanzitutto aggiungere le seguenti righe: Section "Extensions" Option "Composite" "Enable" Option "RENDER" "Enable" EndSection Ora riavviamo il server X dopo aver salvato il file. Digitiamo poi da linea di comando xcompmgr per avviare il programma con le opzioni di default. Invece: xcompmgr -cf abilita il fading shadow (cioè le ombre attenuate stile MacOSX) per il menù e: xcompmgr -cC disabilita le ombre per i pannelli. Per impostare il grado di trasparenza per le finestre, digitate: transset .6 Selezionate poi la finestra che volete rendere trasparente. Il valore che date come paramentro va da 0 ad 1 e rappresenta la percentuale di opacità della finestra in oggetto. 0=completamente trasparente, 1=completamente opaco. Alcune impostazioni un pò più elaborate che potete trovare: xcompmgr -r 15 -o .63 -l -20 -t -20 -I 0.015 -O 0.02 -D 5 -cCfF & xcompmgr -cCfF -r7 -o.65 -l-10 -t-8 -D7 & Buon divertimento! ;) Referenze e ringraziamenti per la stesura dell’articolo • Nvidia.com • gmpf.de • forums.gentoo.org • neowin.net Io sono vivo - e voi siete morti. Ubik, il super-spray - Philip K. Dick Psicomante katapekkia.altervista.org CAPITOLO 1. ARTICOLI 18 1.6 S.M.A.R.T. Avete paura che il vostro amato hard disk che contiene tutte le copie (rigorosamente di backup si intende) dei vostri films preferiti, da un giorno all’altro si rompa lasciandovi soli con la vostra disperazione? Allora questo articoletto fa per voi. Quanto segue è scritto basandosi su esperienze personali utilizzando un sistema GNU/Linux, ma potrebbe essere valido anche per altre piattaforme; non mi assumo nessuna responsabilità per eventuali danni causati al vostro sistema. Tutti gli hard disk delle ultime generazioni sono provvisti di un’utilissima funzione che però pochi conoscono e ancora meno sfruttano. Questa tecnologia è chiamata S.M.A.R.T. acronimo (l’ennesimo...) che sta per Self Monitoring Analysis and Reporting Technology, ovvero tecnologia per l’auto monitoraggio, analisi e resoconto. Tutte queste belle parole stanno solamente ad indicare una funzione dell’hard disk che permette all’utilizzatore di dare una stima affidabile dello stato del suo materiale, e soprattutto, di prevedere con ragionevole certezza una sua imminente disfunzione. Quello che invece non può fare è riparare un disco rotto, recuperarne i dati persi o impedire che questo si rompa. S.M.A.R.T. definisce un protocollo di comunicazione usando i canali IDE o SCSI tra l’hard disk e una applicazione. L’applicazione in questione quindi non fa altro che inviare delle richieste al disco; le richieste più comuni sono essenzialmente due: far partire un self-test (vedremo più tardi di cosa si tratta) o la richiesta di inviare lo stato corrente del dispositivo. Come detto ci vuole un’applicazione per interfacciarsi con il disco perchè si possa fare qualcosa. Per Linux ne esistono molte, la più usata è senza dubbio smartmontools. Sul sito potete anche trovare la stessa versione per Windows, *BSD e Mac OSX. Installatela a seconda del vostro sistema di pacchetizzazione o compilate i sorgenti che non richiedono librerie particolari a mia conoscenza e non dovrebbe quindi essere troppo complicato. Smartmontools comprende due “parti” separate: smartctl e smartd. La prima è quella che prenderemo in considerazione e si tratta del programma principale, mentre smartd, come lo si può evincere dalla “d” finale, è un demone che si occupa di fare controlli periodici senza bisogno dell’intervento dell’utente (che poi è la cosa più interessante, magari scriverò qualcosa in un prossimo articolo). Con il comando smartctl possiamo iniziare a vedere come stanno i nostri hard disks. Prima di tutto attiviamo il supporto S.M.A.R.T. per ogni disco (in linea di massima è attivato di default dal bios ma non si sa mai) dando il comando smartctl --smart=on --offlineauto=on --saveauto=on /dev/hdX dove la X è la lettera del vostro disco; questo comando basta darlo una volta in tutta la vita del disco in questione. Vediamo in dettaglio cosa abbiamo fatto passando quegli argomenti: • smart=on attiva semplicemente il supporto; • offlineauto=on fa svolgere ogni 4 ore un offline test automaticamente (vedremo dopo di cosa si tratta); • saveauto=on permette di salvare in automatico i risultati dell’offline test. Come già detto in precedenza S.M.A.R.T. è una tecnologia atta a diagnosticare e non a curare, quindi non pensiate che fare un test, di qualunque natura esso sia, possa impedire a un vostro disco di rompersi, semplicemente avrete modo di sapere con ragionevole certezza che quel disco sta per salutarvi oltre ad altre interessanti informazioni. Precisato questo continuiamo nella nostra prima analisi. Dopo aver attivato il supporto vogliamo ora aggiornare gli attributi del disco. Per attributi si intendono dei valori realtivi al disco stesso che possono modificarsi con l’andare avanti del tempo. È possibile aggiornare tali attributi facendo partire un offline test con il seguente comando: CAPITOLO 1. ARTICOLI 19 smartctl -t offline /dev/hdX (lo stesso test che verrà fatto automaticamente ogni 4 ore, ricordate?). La durata di ogni test che farete è fissa e non può essere modificata dall’utente: una volta lanciato il test smartctl si preoccuperà di dirvi di quanto tempo avrà bisogno per portarlo a termine e l’ora esatta in cui finirà. Durante questo tempo potete usare senza problemi il computer, la riduzione delle performances è infatti trascurabile e anche in caso di spegnimento involontario o forzato della macchina non ci saranno problemi se non quello di dovere ricominciare (sui miei hard disk il test più lungo dura 25 minuti circa). Finito l’offline test gli attributi per il vostro hard disk saranno aggiornati, vediamo ora come poterli controllare in una pratica tabella. Lanciate il comando smartctl -A /dev/hdX vi apparirà una tabella che lista tutti gli attributi supportati dal vostro disco con relativi valori attuali, valori minimi registrati, valori minimi prima della rottura e tante altre informazioni che ora vedremo in dettaglio. Nella seconda colonna, ATTRIBUTE_NAME, troviamo il nome dell’attributo seguito, nella terza colonna, dal suo flag identificativo, di seguito vengono le informazioni interessanti: nella colonna VALUE trovate il valore attuale per l’attributo, seguito poi dal valore più basso mai registrato nella vita del disco. Una precisazione per quanto riguarda i valori VALUE, WORST e THRESH è necessaria: si tratta di valori normalizzati secondo formule che i produttori stessi del materiale hanno fatto, possono essere completamente diversi tra dischi di marche diverse e anche tra modelli diversi della stessa marca. Per calcolare questo valore viene generalmente preso RAW_VALUE, che corrisponde al valore reale per quell’attributo, e usato come argomento per una funzione che si occuperà di calcolare appunto il valore normalizzato per permettere all’utente di controllare facilmente lo stato dell’attributo. Per fare questo basta comparare il valore attuale con (se diverso da 0) il valore indicato dalla colonna THRESH (threshold). Se il valore è uguale o inferiore salvate i vostri dati e affrettatevi a cambiare disco perchè stà per lasciarvi. Invece gli attributi che hanno un THRESH uguale a 0 (zero) sono quelli realtivi all’invecchiamento normale del dispositivo e non devono allarmare troppo almeno che non siano estremamente vicini allo 0. Potete diversificare gli attributi critici con quelli dati dall’invecchiamento grazie alla colonna TYPE: i nomi Old_age e Pre-fail sono autoesplicativi. Per terminare questa rapida carrellata sugli attributi è probabile che ne troviate alcuni che hanno un interesse altro rispetto alla manutenzione: ad esempio il numero di volte che è stato acceso il disco, la sua temperatura attuale è le ore che è stato acceso. Questi attributi vengono aggiornati sempre, senza bisogno dell’offline test. Infine è giunto il momento di far partire un self-test per essere completamente (meglio quasi completamente forse) sicuri dello stato di salute del disco. A seconda di quello che volete fare eseguite: smartctl -t short /dev/hdX per un test corto o smartctl -t long /dev/hdX per uno lungo. Anche qui sarà smartctl a dirvi l’ora esatta del termine del test. Una volta terminato (usate il comando date per assicurarvi dell’ora esatta usata dal vostro computer) smartctl -l selftest /dev/hdX vi assicurerà che tutto è andato bene. Nel caso invece di errori potete avere più informazioni a riguardo con: smartcl -l error /dev/hdX CAPITOLO 1. ARTICOLI 20 Se con quest’ultimo comando apparissero degli errori loggati controllate prima di tutto la riga che vi informa dell’età del disco alla quale l’errore si è verificato; se si tratta di alcune ore solamente potete stare tranquilli sono cose abbastanza comuni, se invece le ore rispecchiano la durata di vita attuale del disco potete iniziare a preoccuparvi e a salvare i vostri dati in posto sicuro. Un paio di altri comandi utili sono: smartctl -a /dev/hdX che vi dirà tutte le informazioni sul vostro disco: attributi, informazioni generali ed eventuali errori; e: smartctl -H /dev/hdX per un rapidissimo test sulla salute generale del disco, meno approfondito degli altri ma sempre rassicurante. Trovate tutte le informazioni che vi servono consultando il sito di smartmontools e la sua pagina di manuale molto ben fatta. Magari prossimamente scriverò qualcosa su come settare bene smartd per un controllo continuo dei dischi con la capacità di avvertire l’utente in caso di problemi. Ciao, stonedz CAPITOLO 1. ARTICOLI 21 1.7 Creare uno script di backup per un server Parte prima Premessa Avendo da poco installato e configurato per esigenze personali un server FreeBSD, è sorto il problema di come effettuare il backup della configurazione del server in generale e, più in particolare, dei servizi che il server mette a disposizione. Ci sono naturalmente molte applicazioni o script di alta qualità nel mondo *nix che fanno la stessa cosa, ma ho deciso di cimentarmi nella stesura del mio proprio script così da imparare qualcosa e di essere sicuro di cosa questo potesse o non potesse fare, evitando così il sovra/sottodimensionamento dell’applicazione rispetto ai miei bisogni. È proprio per il medesimo motivo che lo script che vi presento – oltre ad altre limitazioni importanti di cui parlerò in seguito – potrebbe non essere adatto alle vostre esigenze. E questo ci porta alla motivazione della stesura di questo piccolo articolo: proporvi una introduzione e di conseguenza una soluzione almeno parziale al problema di fare il salvataggio di dati sensibili da una macchina ad un’altra, permettendovi di limitare fortemente le perdite di dati in caso di compromissione della macchina di partenza. Lo script è per la shell bash, di cui non devo fare certo le presentazioni, e che ogni distribuzione degna di questo nome ha almeno come pacchetto che è possibile installare; si tratta di una versione modificata a scopo didattico per questo articolo direttamente dalla versione che attualmente gira sul mio server – svolgendo un ottimo lavoro tra l’altro – fortemente commentata e dove ho tolto tutti i riferimenti specifici che potrebbero comprometterne il funzionamento su altri computer o distribuzioni. Lo script, tramite il passaggio di parametri da riga di comando, si occupa di fare il backup di differenti servizi/files, in particolare: • repository Subversion; • radice e sottodirectories della root del server Web; • files di configurazione specificati; • intero database MySQL; • homes pubbliche degli utenti (tipicamente /public_html). Si utilizza la forma generale backup_server comando, come vedremo in seguito, per richiamare una delle precedenti routines. Per questa sua caratteristica è facilmente utilizzabile in cronjobs che permettono così una piena automatizzazione del processo di salvataggio. È bene anche precisare che non è necessario avere sul server tutti i servizi sopra elencati, lo script verrà infatti utilizzato solo su quello che ci interessa, lasciandoci così piena autonomia, senza modificarlo affatto. Prima ho parlato di alcune limitazioni dello script, vediamo di approfondire la cosa. La prima di queste è sicuramente la qualità generale: non voglio dire che si tratti di un’applicazione non funzionante o che contenga particolari problemi di sicurezza, semplicemente esistono degli script fatti meglio, scritti meglio, che funzionano meglio etc etc. La seconda limitazione è che essendo stato derivato da uno script scritto appositamente per una macchina particolare potrebbe non essere al 100% portatile anche se mi sono impegnato a togliere tutti i riferimenti a paths, indirizzi e programmi specifici e lo abbia testato su di un altro pc (anche se non in maniera completa). L’articolo è diviso in due parti per motivi di praticità: nella prima parte, oltre a questa premessa, vi introdurrò la struttura generale dello script ed in seguito inizieremo a vederne alcune parti iniziali, nella seconda invece vedremo le routines vere e proprie e spiegherò in maniera approfondita il loro funzionamento. Mi sembra però interessante fornirvi fin da subito lo script completo perché possiate leggerlo e magari utilizzarlo come base di partenza per costruircene sopra uno vostro: troverete quindi CAPITOLO 1. ARTICOLI 22 una versione sempre aggiornata all’indirizzo http://tinyurl.com/cgtwo che vi consiglio caldamente di utilizzare e seguire nel corso di questo articolo e del suo seguito. Naturalmente per qualsiasi cosa non esitate a contattarmi all’indirizzo paolo.fagni[AT]gmail.com. Credo di aver finito le cose noiose, cominciamo quindi a vedere la struttura generale dello script ed in seguito analizzeremo in dettaglio le sue varie parti. Struttura generale Prima di continuare è doverosa una precisazione: non parlerò in questo articolo della sintassi del linguaggio di scripting della bash (anche se lo farò per alcuni casi particolari) è quindi una buona idea sapere almeno di cosa si stia parlando: conoscere i costrutti base (if/fi for/do/done case/esac : : :), e avere una infarinatura di amministrazione di sistema e networking; dal canto mio cercherò di essere il più prolisso possibile per permettere anche a coloro i quali non si siano mai cimentati nella scrittura di uno script di poterne capire il significato. Dopo alcuni commenti informativi inizia lo script vero e proprio, con la sezione delimitata da CONF VARS e che termina con /CONF VARS nella quale si devono specificare le variabili che lo script utilizzerà. Di seguito alcune variabili utili per i codici di uscita dell’applicazione. Segue la definizione delle funzioni dichiarate che sono richiamate nel corpo principale dello script: in questo caso le funzioni sono utili principalmente perché evitano di riscrivere continuamente le stesse parti di codice. Dopo le funzioni si entra nel corpo dell’applicazione eseguendo alcuni tests iniziali per assicurarci che tutto sia a posto e che si possa continuare effettuando quello che l’utilizzatore ha richiesto, il quale viene invece specificato in seguito con un costrutto case/esac (switch per gli amanti del C) dove si sceglie cosa fare rispetto ai parametri passati allo script. La struttura è abbastanza semplice e l’ho suddivisa in sezioni che verranno affrontate separatamente per una più facile comprensione; iniziamo con le variabili di configurazione. Variabili di configurazione In questa sezione devono essere specificate le variabili che lo script utilizzerà per compiere le proprie mansioni, devono quindi essere controllate e modificate dall’utente se necessario. $TEMP_DIR contiene il percorso della directory di appoggio dello script: tutti i dati che vengono elaborati prima di essere compressi e inviati ad un host remoto vengono messi qui, è quindi evidente l’importanza di settare bene questa variabile; come scritto nel commento che l’accompagna, la directory specificata deve esistere prima dell’avvio dello script e avere i permessi di scrittura e lettura per tutti, altrimenti non funzionerà nulla. $TEMP_PUBLIC_BACKUPS_DIR invece contiene il percorso della directory dove verranno salvati i backup delle Web directories pubbliche degli utenti (solitamente /̃public_html). Infatti a differenza delle altre routines di salvataggio questa, essendo eseguibile anche da utenti normali (vedremo in seguito perché), non invia il backup all’host remoto ma lo salva appunto nella directory specificata qui, lasciando all’amministratore il compito di inviare il tutto al salvo sull’altro pc. Questo compito viene appunto eseguito dalla routine save_to_remote che analizzeremo in seguito. Come la precedente variabile deve esistere prima dell’avvio ma per quanto riguarda i permessi c’è una differenza poiché possono essere settati in modo che la scrittura sia permessa solo a coloro i quali devono avere la possibilità di poter eseguire il salvataggio della propria public_html. Si può quindi decidere di concederla solo ai membri di un determinato gruppo diminuendo così la mole di lavoro. $LOG_FILE file dove vengono loggati tutti gli errori e i successi dello script. CAPITOLO 1. ARTICOLI 23 $HOST_REMOTO $USER_REMOTO e $DIR_REMOTA sono i dati necessari per il trasferimento all’host remoto utilizzando il comando scp (man scp) della suite OpenSSH. Rispettivamente: indirizzo della macchina remota, user per accedere via ssh alla macchina remota (ne parleremo quando analizzeremo la funzione save_to_remote_func) e directory nella macchina remota nella quale salvare il backup compresso. $HTTPDOCS_DIR contiene il percorso della radice del server Web (ad esempio, nel caso si utilizzi come server web Apache 2, /var/www/localhost/htdocs/) che verrà salvata ricorsivamente per permetterne un eventuale recupero. $PUBLIC_HTML_NAME invece è il nome della directory (e non il percorso) che contiene la Web directory pubblica degli utenti nella propria home (/home/utente/public_html diventerà quindi semplicemente public_html). $CONFIG_FILES è un array contenente una lista di directories o files di cui è necessario fare un backup; nel caso delle directories, il contenuto è salvato in maniera ricorsiva. $SUBVERSION_REPOSITORY contiene il percorso locale del repository Subversion del quale si vuole fare il backup. Per percorso locale intendo il path di sistema e non l’URL del repository (per intenderci /path/to/repository e non file:///path/to/repository). State bene attenti a settare queste variabili in maniera corretta, poiché, anche se nessuna preclude il corretto funzionamento dello script potrebbe non permettervi di eseguire determinate routines. Ora vedremo velocemente le restanti variabili per poi passare all’analisi delle funzioni dichiarate. Misc vars Qui vengono semplicemente definite tre variabili (che hanno il ruolo di costanti in verità): $ROOT_UID dove viene specificato l’uid che l’utente deve avere per essere l’utente root (che è sempre zero), la variabile $E_BADARGS che contiene il valore di uscita che lo script renderà al chiamante se vengono passati allo script dei parametri errati, e $E_NOTROOT che invece contiene il valore di uscita nel caso un utente diverso da root tenti di eseguire una routine riservata al superutente. Funzioni Vediamo ora quale è il ruolo delle varie funzioni definite nel codice. print_help_func è una semplicissima funzione che stampa a schermo un piccolo messaggio di aiuto sull’utilizzo del programma, verrà utilizzata quando un utente digiterà backup_server [ -h | help | help ] o quando la verifica dei parametri riporterà qualche errore. Qui verrà proprio usata $E_BADARGS per il codice di uscita. check_lock_func questa si tratta di una funzione che cerca nella directory corrente un file chiamato LOCK, se lo trova scrive un messaggio di errore ed esce dallo script loggando un errore, altrimenti non fa niente. Notate la semplice sintassi per inserire una nuova riga al file di log specificato in $LOG_FILE: prepariamo una stringa e poi con la aggiungiamo al file specificato sulla destra dell’operatore. Questo file LOCK viene creato all’inizio (con qualche eccezione come vedremo) di ogni routine di backup, e cancellato appena prima che questa si concluda. Un semplice controllo di questo tipo permette quindi di non andare a scrivere nella directory temporanea mentre un’altra istanza dello script ci sta già lavorando. Vedremo le routines dove è utilizzato e riprenderemo il discorso più avanti. CAPITOLO 1. ARTICOLI 24 save_to_remote_func con questa funzione è possibile salvare un file passato come argomento verso l’host remoto $HOST_REMOTO. Il comando utilizzato è un semplice scp che fa parte di OpenSSH che quindi dovreste avere installato per utilizzare lo script. Vediamo però di preciso come funziona la cosa: la prima riga è il comando principale che ha la forma: scp nome_file nome_utente_remoto@indirizzo_remoto:/path/to/remote/ che trasferisce nome_file verso la macchina specificata da indirizzo_remoto e nella quale esiste un utente nome_utente_remoto con il quale noi possiamo accedervi, il tutto tramite ssh naturalmente. Questo ha due importanti implicazioni: per prima cosa lo scambio di informazioni (user e password ) e la comunicazione sono criptati con un algoritmo forte, la seconda, che è quella che ci interessa per l’automatizzazione del processo, è che possiamo utilizzare l’autentificazione tramite le chiavi pubbliche/private di ssh, evitando così la richiesta di password da parte del server. Cosa significa tutto ciò? Semplicemente che se io prima dell’esecuzione dello script, creando un paio di chiavi pubblica/privata, mi assicuro l’accesso verso $HOST_REMOTO senza bisogno di fornire password potrò mettere il mio script in un cronjob (vedremo in seguito come fare) e non preoccuparmi più di nulla. La domanda che sorge spontanea per coloro i quali non conoscono questo metodo è come possono fare per creare queste chiavi; il procedimento è semplicissimo e vi potrà essere molto utile se usate spesso connessioni ssh. La prima cosa da capire è che l’utente che lancia lo script dovrà creare le chiavi e che quella pubblica dovrà essere inserita in un particolare file nella home di $USER_REMOTO in $HOST_REMOTO. Prendiamo in considerazione la situazione nella quale lo script viene eseguito sul mio server: root esegue lo script sulla macchina A e trasferisce i backups sulla macchina B loggandosi come un ipotetico utente chiamato xyz. Creiamo quindi la coppia di chiavi di root sulla macchina A con il comando: ssh-keygen -t rsa che vi chiederà dove salvare la chiave privata (la proposta di default va benissimo), ed in seguito la password che per i nostri scopi è inutile, premiamo quindi tre volte enter et voilà, abbiamo le nostre chiavi. Prendete nota di dove ha salvato la chiave pubblica e trasferitela verso l’host remoto usando ad esempio scp stesso, con un comando del tipo: scp /root/.ssh/id_rsa.pub xyz@macchina_B:/home/xyz per il momento come vedete la password ve la chiede ancora. Copiate il contenuto della chiave pubblica nel pc B dentro il file /.ssh/authorized_keys con il comando: cat /home/xyz/id_rsa.pub >> /home/xyz/.ssh/authorized_keys l’operatore è necessario per non sovrascrivere il contenuto di authorized_keys e appendere a questo la nostra nuova chiave autorizzata. Ora l’utente root dalla macchina A che si identifichi come xyz@macchina_B per la connessione ssh a macchina_B non sarà obbligato a fornire una password ma verrà autentificato automaticamente tramite la sua chiave privata2 . Dopo questa divagazione sulla creazione ed installazione delle chiavi ssh finiamo la descrizione della funzione save_to_remote_func. Al termine del comando scp qualche cosa potrebbe essere andato storto, ci vuole quindi un controllo sul successo del trasferimento per essere sicuri che i nostri dati siano al sicuro; compito svolto dal costrutto if/fi successivo che controlla il codice di uscita dell’ultimo comando eseguito (proprio scp nel nostro caso), e se fosse diverso da 0 (exit status che di default significa successo) stampa un messaggio di errore, logga una stringa informativa e pulisce al directory temporanea per non lasciarsi dietro files che potrebbero intralciare un successivo backup. 2 http://new.linuxjournal.com/article/8600 CAPITOLO 1. ARTICOLI 25 quit_success_func è una funzione che pulisce la dir temporanea, logga un avvenuto backup ed esce in maniera pulita dallo script notificandone il successo; prende un argomento che sarà un nome specifico relativo ad una routine di backup come ad esempio DATABASE o SVN. Queste stringhe che vengono loggate conterranno delle informazioni utili per un filtraggio efficace delle informazioni: data, routine di backup e stato (ad esempio errore o successo), con l’aggiunta di una breve descrizione. Sarà poi facile anche con un semplice grep trovare le informazioni utili alla risoluzione dei problemi più comuni. quit_success_public_html_func è una funzione con lo stesso obiettivo di quella sopra ma specificatamente scritta per la routine di backup delle Web directories pubbliche degli utenti; l’unica differenza è che il successo viene loggato in un file dentro la home dell’utente che ha lanciato lo script. check_root_func controlla invece l’identità di chi lancia lo script: se il suo uid è diverso da 0 non si tratta di root, stampa un messaggio e esce utilizzando come codice di uscita $E_NOTROOT Check iniziali Qui vengono effettuati alcuni controlli iniziali prima di passare al cuore dello script. Il primo verifica se esista almeno un parametro passato allo script, altrimenti stampa l’help ed esce. Il secondo controlla se per caso l’utente abbia passato come primo parametro -h o -help o help, in questo caso i suoi intenti sono chiari, stampiamo quindi l’help anche qui ed usciamo. Da notare che nei due costrutti if/fi ho usato due diversi tipi di parentesi (per chi non lo sapesse quelle non sono vere parentesi ma semplicemente degli “alias” per dei comandi) nella prima verifica ho usato lo standard [...] ovvero il comando test (man test per vedere tutte le possibili opzioni), mentre nel secondo ho usato [[...]], introdotto nelle nuove versioni della bash e che si avvicinano molto di più ai costrutti if di altri linguaggi tipo il C. Il terzo check è quello che più ci interessa in quanto controlla che l’host specificato in $HOST_REMOTO sia attivo e risponda ad un ping o meno: se risponde si continua nell’esecuzione dello script, altrimenti si esce e si logga l’errore. A questo punto il controllo viene passato a un case/esac (switch) che gestisce il cuore dell’applicazione: a seconda del parametro passato infatti verrà eseguita una certa parte di codice che eseguirà il backup di un diverso servizio o di un diverso insieme di files; nel caso non ci sia corrispondenza verrà utilizzato il case di default (vedi ultime righe di codice) che non fa altro che stampare a schermo l’help ed uscire. Conclusioni Per il momento è tutto, la divisione in sezioni del codice vi dovrebbe aver permesso di seguire le spiegazioni in maniera abbastanza semplice e dovreste ora essere in grado di capire come lo script è strutturato e quale sia il suo scopo. Nella seconda parte vedremo come funzionano le routines che eseguono i backups veri e propri. Ciao, stonedz CAPITOLO 1. ARTICOLI 26 1.8 Splittare un file Qualche tempo venne effettuata una richiesta su un forum, l’utente aveva necessità di splittare su diversi file uno unico diviso in sezioni. Ogni sezione di questo file era identificata dal simbolo “#”. L’idea di scrivere uno script che facesse proprio questa operazione mi ha allettato parecchio, e mi sono subito messo all’opera. In questo articolo spiegherò passo per passo come realizzare questo script. Iniziamo subito con lo scrivere un file di testo così composto: #sezione1: Questo file è presente nel forum DevLabs. #sezione2: Lo scopo è puramente illustrativo, mentre lo script per splittare può avere gli utilizzi più disparati. #sezione3 #Questa sezione in particolare contiene anche delle righe esplicative #Che possono tornare utili per capirne meglio il contenuto. Questa è l'ultima sezione del file di esempio. Tabella 1.1: totale.txt e i dover ottenere un file per ogni sezione contenente proprio il testo di queste ultime, e cioè come nelle tabelle 1.2-1.4: Questo file è presente nel forum DevLabs. Tabella 1.2: sezione1.txt Lo scopo è puramente illustrativo, mentre lo script per splittare può avere gli utilizzi più disparati. Tabella 1.3: sezione2.txt #Questa sezione in particolare contiene anche delle righe esplicative #Che possono tornare utili per capirne meglio il contenuto. Questa è l'ultima sezione del file di esempio. Tabella 1.4: sezione3.txt Anche se il codice è largamente commentato, spiegherò passo passo le varie righe di codice necessarie per ottenere il risultato. È buona norma commentare il codice scritto, anche se siamo stati noi a farlo. Ricordate che i commenti aiutano anche l’autore, a distanza di tempo un codice senza commenti può risultare di difficile comprensione anche per chi lo ha scritto. Quindi iniziamo con dei bei commenti: #!/bin/bash #-----------------------------# #Titolo script : splitta.sh # CAPITOLO 1. ARTICOLI 27 #Autore : lemoeb # #Data : Ottobre 2005 # #Data ult.mod. : # #-----------------------------# #Licenza : GNU/GPL # #-----------------------------# Grandi spiegazioni per le righe sopra riportate non ce ne sono a parte la prima (#!/bin/bash) che identifica il tipo di shell che vogliamo utilizzare, nel nostro caso la bash shell. Andiamo avanti. #Definzione delle variabili #-------------------------i=1; #Utilizzata per contare le righe num_righe=`cat totale.txt | wc -l`; #Numero delle righe file commento=0; #Identifica se il carattere letto è un commento num_file=0; #Numero progressivo sezione (nome File) Qui sopra troviamo la definizione di una serie di variabili che utilizzeremo più avanti; mentre tutte le variabili hanno un valore iniziale definito da noi, num_righe cambia di volta in volta a seconda del file che gli facciamo analizzare. Utilizzado il comando cat totale.txt insieme al wc -l otteniamo il numero totale delle righe che compongono il nostro file contenente le sezioni. Continuiamo: #Stampa del messaggio di avvio e informazioni generiche #-----------------------------------------------------echo "#### SPLITTA.SH ####"; echo "--------------------"; echo "Numero delle righe presenti nel file da splittare: "$num_righe; Viene stampata una piccola schermata dove è riportato il titolo dello script e il numero delle righe che compongono il file da analizzare. Fino ad ora non abbiamo fatto nulla di particolare, se non scrivere qualche commento, prepararci un minimo di ambiente e scrivere a video il titolo dello script. Entriamo ora nel cuore dello script, dove cioè effettuiamo le operazioni necessarie allo split del file. #Ciclo per analizzare tutte le righe del file #-------------------------------------------while (test $i -lt $num_righe) do Da qui inizia il ciclo di scansione di ogni riga; praticamente si leggono righe dal file finché ce ne sono. #Recupero del primo carattere della riga e recupero della riga totale #--------------------------------------------------------------------primo_carattere=`cat totale.txt|head -$i|tail -1|awk '{ print substr($0,1,1) }'`; riga_totale=`cat totale.txt | head -$i | tail -1 | awk '{ print $0 }'`; Tramite la concatenazione di diversi comandi Linux è possibile recuperare il primo carattere di una riga e la riga per intero. C’è però l’utilizzo di un programma esterno chiamato “AWK”. AWKè un processore/manipolatore di file di testo; non starò qui a spiegarne il funzionamento per intero, ci vorrebbe troppo tempo, ma mi limiterò alla spiegazione delle due righe di codice incriminate (una spiegazione più dettagliata di AWKè presente sul Numero 1 di Topolinux). Nella prima riga troviamo la seguente istruzione AWK: CAPITOLO 1. ARTICOLI 28 '{ print substr($0,1,1) }'} che letteralmente significa: recupera il primo carattere della stringa $0 (la nostra riga) e stampalo su stdout. Nella seconda riga invece troviamo quest’altra istruzione: '{ print $0 }' che letteralmente significa : recupera la stringa $0 (la nostra riga) e stampala sullo stdout. I valori recuperati dalle istruzioni sopra citate vengono inseriti rispettivamente nelle variabili: • primo_carattere; • riga_totale. Iniziamo ora ad analizzare i valori ritornati dalle istruzioni che abbiamo utilizzato. #Controllo se il primo carattere è un commento e se la riga precedente era di commento #------------------------------------------------------------------------------------if test $primo_carattere == "#" && test $commento -eq 0 then #Mi salvo un valore per ricordarmi che la riga precedente era di commento #-----------------------------------------------------------------------commento=1; #Incremento il numero del file #----------------------------num_file=`expr $num_file + 1 `; #Compongo il nome del file #------------------------nome_file="sezione_"$num_file; #creo il file >$nome_file; Utilizzando il costrutto if controllo se il primo carattere è il “#” e anche se prima di questo carattere non erano presenti altri “#”. Nel caso la condizione venga verificata: • imposto la variabile commento al valore 1, questa variabile mi servirà per verificare se è già stato incontrato un separatore di sezione; • incremento il numero progressivo del file di sezione (vi ricordo che partiva dal valore 0); • imposto il nome del file e lo scrivo nella variabile nome_file; questa sarà composta da una parte fissa sezione e da una parte variabile che è il numero progressivo delle sezioni incontrate ($num_file); • creo il file che conterrà la sezione in questione effettuando un redirect vuoto (carattere >) sulla varibile contenente il nome del file ($nome_file). CAPITOLO 1. ARTICOLI 29 #Se il primo carattere non è un commento scrivo nel file appena creato #la riga letta. #---------------------------------------------------------------------elif test $primo_carattere != "#" then #Scrittura della riga letta e settaggio del commento a 0 #-------------------------------------------------------echo $riga_totale >> $nome_file; commento=0; Se il primo carattere della riga in questione non è un commento allora significa che mi trovo già dentro la sezione e quindi mi limito ad aggiungere, tramite il carattere , la riga letta all’interno del file di sezione. Importante: la variabile commento viene poi settata a 0 in modo tale da far capire al programma che non ho incontrato un carattere “#”. #Se la riga letta è di commento come la precedente allora continuo #a scrivere sul file creato #----------------------------------------------------------------elif test $primo_carattere == "#" && test $commento -eq 1 then echo $riga_totale >> $nome_file; fi Ultima casistica: il carattere letto è un #, ma ne avevo già incontrato uno nella riga precedente. A questo punto non azzero la variabile commento e scrivo l’intera riga nel file di sezione. #Incremento della variabile per recuperare la riga dal file #---------------------------------------------------------i=`expr $i + 1`; done Come ultima cosa incremento il contatore delle righe lette e chiudo il ciclo tramite done. Il codice completo è il seguente: #!/bin/bash # #-----------------------------# #Titolo script : splitta.sh # #Autore : lemoeb # #Data : Maggio 2005 # #Data ult.mod. : # #-----------------------------# #Licenza : GNU/GPL # #-----------------------------# #Definzione delle variabili #-------------------------- CAPITOLO 1. ARTICOLI 30 i=1; #Utilizzata per contare le righe num_righe=`cat totale.txt|wc -l`; #Numero delle righe file commento=0; #Identifica se il carattere letto è un commento num_file=0; #Numero progressivo sezione (nome File) #Stampa del messaggio di avvio e informazioni generiche #-----------------------------------------------------echo "#### SPLITTA.SH ####"; echo "--------------------"; echo "Numero delle righe presenti nel file da splittare : "$num_righe; #Ciclo per analizzare tutte le righe del file #-------------------------------------------while (test $i -lt $num_righe) do #Recupero del primo carattere della riga e recupero della riga totale #--------------------------------------------------------------------primo_carattere=`cat totale.txt|head -$i|tail -1|awk '{ print substr($0,1,1) }'`; riga_totale=`cat totale.txt | head -$i | tail -1 | awk '{ print $0 }'`; #Controllo se il primo carattere è un commento e se la riga precedente era #di commento #------------------------------------------------------------------------if test $primo_carattere == "#" && test $commento -eq 0 then #Mi salvo un valore per ricordarmi che la riga precedente era di commento #-----------------------------------------------------------------------commento=1; #Incremento il numero del file #----------------------------num_file=`expr $num_file + 1 `; #Compongo il nome del file #------------------------nome_file="sezione_"$num_file; #creo il file >$nome_file; #Stampo a video la riga Totale elaborata #--------------------------------------echo $riga_totale; Il codice scritto fino ad ora presenta però un piccolo problema, e cioè nel caso il file da analizzare abbia delle righe vuote verrà visualizzato il seguente warning (anche se lo script produrrà ugualmente i file di sezione): CAPITOLO 1. ARTICOLI 31 expected unary operator. Per ovviare a questo inconveniente, basterà controllare che la riga letta non sia vuota, semplice no? Utilizzando sempre AWK, possiamo recuperare la lunghezza di una stringa che guarda caso è sempre la nostra $0. Non riscriverò tutto lo script, ma posterò soltanto le modifiche da effettuare. La prima cosa da fare è definirci una variabile che riporti la lunghezza della stringa $0. La inseriremo all’interno della sezione di definizione delle variabili in questo modo: lunghezza_riga=0; poi nella sezione in cui recuperiamo le varie info della stringa $0 aggiungeremo: lunghezza_riga=`cat totale.txt|head -$i|tail -1|awk '{ print length($0) }'`; infine aggiungeremo un if prima di tutti gli altri in questa maniera: #Controllo della lunghezza riga #-----------------------------if test $lunghezza_riga -gt 0 then ... (seguono tutte le altre righe di codice) ... ed il gioco è fatto. N.B.: ricordatevi di chiudere anche questo if, altrimenti riceverete errore; questo if va chiuso prima dell’incremento della variabile i. “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb CAPITOLO 1. ARTICOLI 32 1.9 Introduzione a CVS con SSH Premessa Questo testo è rilasciato secondo le norme della licenza Creative Commons di tipo by-nc di cui potete trovare una copia a questo indirizzo http://creativecommons.org/licenses/by-nc/2.5/. Quanto segue è una introduzione all’utilizzo sicuro del CVS per gestire un progetto con degli esempi per facilitarne l’utilizzo. Non si tratta di un documento completo, a questo scopo, alla fine dello stesso, troverete una serie di collegamenti per approfondire in maniera esaustiva l’argomento. Introduzione CVS sta per Concurrent Version System, in parole povere un sistema per monitorare e gestire un progetto mantenuto da più di una persona in maniera trasparente, evitando conflitti se due o più sviluppatori lavorano sullo stesso file allo stesso momento. Il funzionamento è semplice ma efficace: in un server viene creato un “repository”, ovvero una directory che è strutturata specificatamente per l’utilizzo del CVS, questa directory conterrà poi i vari “moduli”, che non sono altro che altre directory strutturate in maniera particolare. Un modulo può essere ad esempio l’insieme dei sorgenti di un programma, mentre il repository in cui è contenuto potrebbe rappresentare il gruppo di sviluppatori (che quindi potranno sviluppare altri programmi rappresentati da altri moduli). Preciso che dentro al modulo ci possono essere infinite sotto-directory, che faranno comunque parte integrante del modulo stesso. Ad esempio si potrebbe avere una struttura come quella di figura 1.9. repository modulo 1 dir 1 dir 2 modulo 2 sorgenti sorgenti sorgenti sorgenti Figura 1.9: Esempio di repository gestito tramite CVS Del modulo 1 fanno parte sia i sorgenti direttamente presenti in quella directory, sia i sorgenti che sono presenti nelle sue sotto-directory, al contrario del modulo 2 che non ha altri sorgenti all’infuori di quelli presenti nella sua directory. Da un punto di vista del client che vuole gestire il progetto le cose sono molto semplici. Prima però un’altra precisazione: come ho detto il CVS viene utilizzato soprattutto dagli sviluppatori per gestire un progetto, ma è anche un buon metodo per permettere agli eventuali fruitori del software di avere sempre disponibili gli ultimi sorgenti aggiornati. Questo è possibile dando accesso in sola lettura al repository a un determinato utente (che non dovrà autentificarsi come vedremo in seguito, CAPITOLO 1. ARTICOLI 33 e normalmente chiamato “anonymous”) che quindi potrà accedere al progetto senza modificarne i contenuti. Ora passiamo invece all’utilizzo del CVS dal punto di vista di uno sviluppatore. Prendiamo in considerazione un gruppo di 3 sviluppatori A, B e C che stanno lavorando su di un progetto in contemporanea, per semplicità ipotizziamo che questo sia formato da 2 files contenenti il codice sorgente dell’applicazione. Lo sviluppatore A si occupa del primo file, non deve quindi preoccuparsi che qualcuno modifichi in contemporanea le stesse parti di codice su cui sta lavorando, mentre B e C devono lavorare sullo stesso file, dovrebbero quindi continuamente stare attenti a non intralciarsi a vicenda. In più, anche se A non deve preoccuparsi di eventuali modifiche fatte da altri sul suo file, potrebbe avere bisogno delle modifiche degli altri due sviluppatori al secondo file per continuare il proprio lavoro in tempo “reale”. Utilizzando il CVS e un po’ di buon senso, tutti questi problemi sono risolti. A,B e C decidono quindi di avvalersi del CVS e creano, in un server accessibile a tutti e tre, un repository, e in questo un modulo contenente i due file sorgenti. A questo punto ogni volta che uno di loro apporterà modifiche ad uno dei file prima controlla che il file in questione non sia stato modificato da qualcun altro (update) e in seguito manda la propria versione del file al server (commit), questa non andrà a sovrascrivere la precedente, ma si aggiunge in coda; tutte le versioni precedenti, almeno che non venga deciso altrimenti, vengono tenute sul server, permettendo così un semplice ritorno indietro se si dovessero scoprire errori seri nel codice. Nel caso che durante l’update (che va sempre fatto quando si vuole inviare la propria versione di un file) si verifichino delle incongruenze (ad esempio due persone hanno modificato la stessa parte del codice), queste vengono segnalate, e, se possibile, risolte automaticamente (merging). Nel caso il programma non fosse capace di risolvere il problema automaticamente starà allo sviluppatore correggerlo manualmente. Per semplificare questa mansione la maggior parte dei client grafici per il CVS (che non sono altro che un front end per il programma cvs vero e proprio, il quale è esclusivamente da riga di comando) mettono a disposizione dei programmi che espongono in maniera chiara le differenze tra i due file in questione, permettendo una facile risoluzione dei conflitti. Naturalmente il CVS permette molte altre cose ma questa voleva essere solo una piccola introduzione a come questo strumento lavori prima di passare alla parte pratica. Vedremo quindi come sia possibile connettersi ad un repository in maniera sicura utilizzando ssh. Metodi di autenticazione Naturalmente ci vuole un qualche sistema per autentificare un client e permettergli di vedere e/o modificare i file in un repository. Due sono i metodi comunemente usati il pserver (non sicuro basandosi su un’autentificazione non criptata) che io non traetterò, e l’ext che sia appoggia ad un programma esterno per l’autentificazione sicura dell’utente e la trasmissione di dati. Molti sono i programmi che possono essere usati con questo metodo, tra cui telnet (non sicuro), rsh (obsoleto) o ssh. Negli esempi che seguiranno utilizzerò ssh (ovvero secure shell), in quanto il più sicuro in assoluto nonché il più usato. Questo programma si basa sullo scambio di certificati tra server e client, che rendono sicura l’autentificazione, e la criptazione della trasmissione dati. Nel nostro amato pinguino è molto probabile che già abbiate ssh installato (provate a dare il comando ssh -version per controllare), in caso contrario potete scaricare l’ultima versione qui: http://www.openssh.org/. Normalmente invece, per un accesso pubblico al repository, si utilizza il metodo di autentificazione pserver, che si basa sulla trasmissione in chiaro di password e dati (anche per l’accesso pubblico ci deve essere una password che è comunemente lasciata in bianco o fornita agli utenti). Nulla proibisce pero’ di utilizzare un metodo più sicuro anche per transazioni di questo genere. Come già detto, non mi dilungherò su metodi di autentificazione alternativi alla secure shell, proseguiamo quindi introducendo altri concetti importanti. CAPITOLO 1. ARTICOLI 34 CVSROOT e altri elementi di base Per connettersi e autentificarsi ad un determinato server CVS avete bisogno di conoscere la sua CVSROOT, ovvero una stringa che contenga tutte le informazioni necessarie per l’utilizzo del cvs su quella macchina. Una CVSROOT è strutturata in questo modo: :metodo_autentificazione:username@server:/percorso/del/repository (N.B. Il percorso del repository è un path locale del server). Ad esempio una CVSROOT valida potrebbe essere: :ext:[email protected]:/var/cvs/progetto sta poi a voi lo specificare con quale programma intendete effettuare la connessione, cosa che con i client grafici si fa in maniera immediata, come vedremo in seguito. Ci serve poi sapere il nome del modulo con cui vogliamo lavorare, alcuni repository permettono da remoti di conoscere quali moduli sono presenti al prorpio interno, ma questo non è sempre possibile, è meglio quindi conoscere prima la struttura del repository. Ora che conosciamo la nostra CVSROOT e il modulo, possiamo iniziare la procedura di connessione (vedere gli esempi successivi per la trattazione pratica). La prima volta che ci connettiamo ad un server CVS dobbiamo fare l’operazione chiamata “Checkout”, ovvero la creazione di una directory di lavoro locale(chiamata “sandbox” o “workcopy”) in cui verranno salvati i file dal modulo presente sul server. Saranno questi i file sui quali lavoreremo e, una volta terminate le modifiche da apportare, li rimanderemo al server come versioni aggiornate. Una volta creata la nostra sandbox le future operazioni di manutenzione saranno molto semplificate: infatti durante la fase di checkout viene creata una directory chiamata CVS dentro ogni directory del modulo, che mantiene al suo interno tutte le informazioni necessarie per le operazioni di updating e committing. L’update di un modulo (o di una directory o di un singolo file) è l’operazione più frequente che farete: consiste nel verificare se sul server ci siano versioni più nuove di ognuno dei file presenti nel modulo; la stessa operazione però, si occuperà automaticamente di aggiungere alla nostra sandbox eventuali files aggiunti da terzi, o cancellerà i files locali che sono stati eliminati dal server. Quando invece vorrete inviare le vostre modifiche verso il server, dovrete fare un commit. Prima di ogni commit, dovete assolutamente fare un update, per evitare di ignorare le modifiche apportate da altri a files che potreste avere modificato anche voi. Quando inviate un file vi sarà richiesto di scrivere un commento per le vostre modifiche, soprattutto non siate avari di parole, questo aiuterà gli altri a coordinarsi meglio con le vostre modifiche. Questo commento prende nome di “log” e accompagnerà il file anche nelle prossime versioni, così che sia facile ricostruirne la storia dei cambiamenti. Esistono naturalmente altre operazioni possibili come ad esempio inserire nuovi moduli in un repository (Insert) o cancellare moduli, argomenti che qui non tratterò (vedi sezione 1.9 per maggiori informazioni). Con queste informazioni siamo pronti per passare alla pratica scaricatevi o installatevi il software necessario se non lo avete già e poi passate all’esempio pratico che segue. Software necessario Una rapida panoramica dei programmi che potete usare per gestire un progetto utilizzando il CVS: • Cervisia – http://cervisia.sourceforge.net/ • lincvs – http://www.lincvs.org/ • gcvs – http://www.wincvs.org/ CAPITOLO 1. ARTICOLI 35 Personalmente uso Cervisia che fa parte di KDE (su cui si baserà l’esempio a seguire), se utilizzate un altro Desktop Environment potete scegliere tra gli altri due (non ho mai usato gcvs, lincvs è un po’ più grezzo di Cervisia ma funziona benssimo). Naturalmente dovete avere cvs installato, la maggior parte delle distribuzioni lo include di default nell’installazione, se non lo avete potete scaricarlo da http://www.cvshome.org dove troverete anche tutta la documentazione per un utilizzo più avanzato di questo strumento. Utilizzo pratico Per questo esempio prenderò in considerazione il tool Cervisia che fa parte di KDE, se, pur avendo KDE installato, non riuscite a trovarlo vi manca verosimilmente il pacchetto kdesdk, non in tutte le distribuzioni viene installato di default. Le istruzioni che seguono si riferiscono alla versione 2.3.x su KDE 3.4.x, ma dovrebbero essere valide per qualunque versione di KDE recente. Appena aperto il programma si presenterà come in fig. 1.10. Figura 1.10: Schermata iniziale di Cervisia. Nella sezione Help troverete informazioni utili su come funziona l’applicazione, mentre tramite il menu Settings->Configure Cervisia, potete settare alcune preferenze (non molte, né tanto meno necessarie al momento). Aprite invece la sezione Repository-> Repositories: : : dove potrete settare varie CVSROOT per gestire differenti progetti allo stesso tempo, selezionate quindi Add per aggiungere una nuova CVSROOT come in fig. 1.11. come vedete ho inserito una CVSROOT e il programma da usare per l’autentificazione e la trasmissione dati, in questo caso ssh, le restanti opzioni non le cambiate almeno che non sappiate cosa stiate CAPITOLO 1. ARTICOLI 36 Figura 1.11: Finestra di dialogo per l’impostazione della CVSROOT. facendo. Diamo l’OK e ci ritroviamo con il nostro repository registrato e pronto per essere usato. Diamo quindi l’OK anche alla finestra con la lista dei repository e torniamo alla finestra principale. Ora, come ho detto sopra, dobbiamo fare il checkout di un modulo per poterlo poi gestire tramite CVS. Sempre dal menu Repository scegliamo questa volta Checkout, ci apparirà una finestra come questa in cui inserire vari dati: Figura 1.12: Finestra di dialogo per checkout dei moduli. scegliamo dalla lista il repository su cui lavorare (quello che abbiamo appena creato nell’esempio), e indichiamo il nome del modulo che vogliamo scaricare. L’attributo branch tag è per un utilizzo avanzato che qui non traettero, mentre Working folder è molto importante in quanto indica la directory locale in cui verrà creato il sandbox con il nome identico al modulo remoto (la directory deve esistere prima di utilizzarla). Una volta dato l’OK vi apparirà dopo qualche istante un box dove richiede la CAPITOLO 1. ARTICOLI 37 password per l’utente da voi indicato (vedi sezione 1.9 per maggiori informazioni): Figura 1.13: Finestra di dialogo per l’inserimento della password di accesso al modulo. dopo aver inserito la password il processo di checkout comincia; in fig. 1.14 potete vedere un esempio dei messaggi che vengono dati durante questa fase. Figura 1.14: Cervisia durante il processo di checkout. Finito questo passaggio dovreste avere i sorgenti del progetto nella directory che avete specificato come Working folder. Da questo momento non dovrete più usare questo metodo per controllare un progetto remoto tramite CVS, infatti Cervisia si integra perfettamente con il file-browser predefinito di KDE, ovvero Konqueror; andate quindi nella directory dove avete scaricato precedentemente i sorgenti, cliccate sul bottone indicato per passare in modalità cvs, la visualizzazione della directory Figura 1.15: Integrazione di Cervisia in Konqueror. cambierà in quella che potete vedere nell’immagine in fig. 1.16 (nel caso non abbiate il pulsante andate in View->View Mode e dovreste trovarlo nella lista): qui avete per ogni file incluso nel CVS lo stato (dopo un checkout è normale che sia “Unknown”), la versione del file e la data dell’ultima revisione; cliccando col bottone sinistro del mouse potete editare normalmente il file, mente col bottone destro vi verranno proposte le opzioni specifiche del CVS, come potete vedere dalla precedente immagine. Le due operazioni che ci interessano per il momento sono Update e Commit. Come già detto Update serve per scaricare l’eventuale ultima versione dal repository, mentre Commit per inviare una propria versione modificata (ricordatevi sempre di fare un update prima di un commit!). Potete inoltre, selezionando Browse Log: : :, vedere con un supporto grafico chi ha apportato le ultime modifiche, e quali sono stati i suoi commenti alla modifica stessa. CAPITOLO 1. ARTICOLI 38 Figura 1.16: Modalità visualizzazione directory. Cervisia mette a disposizione un metodo per riconoscere semplicemente i files da voi modificati e che quindi sono in attesa di essere sincronizzati con il server, nell’immagine di fig. 1.17 il file accounts.cpp è stato modificato da me, dopo avere fatto un update su questo file sono pronto per “committare” i miei cambiamenti (N.B. Potete utilizzare l’opzione Difference to repository (HEAD) per controllare le differenze tra il vostro file e la versione presente sul server). Figura 1.17: Modalità visualizzazione directory. Selezionando l’opzione commit vi verrà chiesto di inserire un commento per i cambiamenti apportati, dopo averlo fatto date l’OK, vi verrà di nuovo chiesta la password e quindi potrete vedere se tutto CAPITOLO 1. ARTICOLI 39 va a buon fine nella parte inferiore della finestra. A questo punto il vostro file è stato aggiunto al repository con un numero di versione incrementato rispetto all’ultimo file con quel nome presente sul server. Per controllare ancora che tutto sia andato a buon fine potete vedere tramite l’opzione Browse Log... che la vostra operazione sia riuscita. Un’altra cosa che sicuramente sarete portati a fare è aggiungere un file o una directory al modulo su cui state lavorando così da aggiungerlo al progetto. Con Cervisia queste operazioni sono immediate: salvate il nuovo file o directory nel sandbox ed entrate nella modalità di visualizzazione CVS con Konqueror, Cervisia vi informerà che questi files non sono presenti nel repository remoto (mentre le nuove directory non sono immediatamente riconoscibili, ma avendole create voi dovreste sapere come si chiamano ), nell’immagine di fig 1.18 ho creato dentro la sandbox di un modulo due nuove directory Figura 1.18: Aggiunta di un file o una directory al modulo. nuova_directory/ e proviamo/, un nuovo file dentro la directory nuova_directory/ e un altro nuovo file nella directory radice del sandbox chiamato nuovo_file. Vedrete che Cervisia vi informa che il file nuovo_file e nuovo_file2 non sono presenti nel repository con la dicitura “Not in CVS”. Iniziamo con l’aggiungere il file nella directory radice al repository. Clicchiamo con il bottone destro sul file e nel menù che comparirà scegliamo l’opzione Add to repository. A questo punto, dopo una finestra che ci chiede la conferma del file che vogliamo aggiungere al repository, ci verrà richiesta la solita password. Dopo questo non abbiamo ancora finito, infatti il precedente processo termina (se riesce) nel modo illustrato in fig. 1.19. Figura 1.19: Aggiunta di un file al repository terminata con successo. A questo punto, come ci viene indicato, facciamo un commit per aggiungere in maniera definitiva il file nuovo_file al repository remoto. L’operazione è identica al commit descritto precedentemente nel paragrafo, ovvero click bottone destro->Commit...->commento->password. Et voilà, il file è stato aggiunto al repository ed è pronto per essere utilizzato dagli altri sviluppatori. Infine per quanto riguarda il nuovo_file2 dentro la directory nuova_directory il processo è molto simile: prima di tutto dovete CAPITOLO 1. ARTICOLI 40 aggiungere la directory al repository, click destro sulla directory->Add to repository->password (per le directories non c’è bisogno del commit dopo questa operazione!); dopodiché l’aggiunta di nuovo_file2 è identica a quella del precedente file. Queste informazioni dovrebbero bastarvi per gestire in maniera basilare un progetto utilizzando Cervisia. Ssh-askpass Se durante l’operazione di Checkout non dovesse apparire la finestra che vi chiede la password e l’operazione termina dopo qualche secondo con un errore, non avete installato sul vostro sistema ssh-askpass, normalmente lo trovate nei CD della vostra distribuzione o su internet come pacchetto per varie distribuzioni (.deb .rpm .tgz), una volta installato tutto si svolgerà normalmente. Cervisia non dovrebbe avere bisogno di installarlo in quanto al suo interno è già compresa un’applicazione che svolge questo compito (nelle ultime versioni, per le versioni precedenti dovete installarlo comunque). Links utili CVS • http://www.cvshome.org home del progetto cvs • http://cvsbook.red-bean.com libro sul cvs • http://www.gnu.org/software/cvs/ pagina del progetto gnu sul cvs ssh • http://www.openssh.org/ porting libero di ssh • http://www.rz.uni-karlsruhe.de/~ig25/ssh-faq/ FAQ su ssh Ciao, stonedz 2 Pillole 2.1 Colorare la shell Vi siete mai imbattuti in quegli script che presentano scritte di diverso colore a seconda delle righe che appaiono in video? No? sicuri? L’esempio molto lampante è il lancio del comando ls sotto alcune distro, o ancora i messaggi che si possono leggere in avvio, sempre su alcune distro. Realizzare la cosa è molto semplice: facciamo un esempio evitando troppe parole :-P Apriamo il nostro editor preferito e scriviamo al suo interno il seguente codice: #!/bin/bash #variabili export WHITE="\e[1;37m" export LGRAY="\e[0;37m" export GRAY="\e[1;30m" export BLACK="\e[0;30m" export RED="\e[0;31m" export LRED="\e[1;31m" export GREEN="\e[0;32m" export LGREEN="\e[1;32m" export BROWN="\e[0;33m" export YELLOW="\e[1;33m" export BLUE="\e[0;34m" export LBLUE="\e[1;34m" export PURPLE="\e[0;35m" export PINK="\e[1;35m" export CYAN="\e[0;36m" export LCYAN="\e[1;36m" export Z="\e[0m" #stampa echo Utilizzo: echo echo -e \" \$VARIABILE_DEL_COLORE testo \" echo echo Questa e\' la lista delle variabili rappresentative dei colori 41 CAPITOLO 2. PILLOLE echo echo echo echo echo echo echo echo echo echo echo echo echo echo echo echo echo echo echo -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e -e " " " " " " " " " " " " " " " " " 42 $WHITE \$WHITE $Z Bianco" $LGRAY \$LGRAY $Z Grigio chiaro" $GRAY \$GRAY $Z Grigio" $BLACK \$BLACK $Z Nero" $RED \$RED $Z Rosso" $LRED \$LRED $Z Rosso chiaro" $GREEN \$GREEN $Z Verde" $LGREEN \$LGREEN $Z Verde chiaro" $BROWN \$BROWN $Z Marrone" $YELLOW \$YELLOW $Z Giallo" $BLUE \$BLUE $Z Blu" $LBLUE \$LBUE $Z Blu chiaro" $PURPLE \$PURPLE $Z Viola" $PINK \$PINK $Z Rosa" $CYAN \$CYAN $Z Cyano" $LCYAN \$LCYAN $Z Cyano chiaro" $Z \$Z Colore di default della shell" salviamo il tutto con il nome colore.sh (la fantasia non manca eh?) e lanciamolo con: sh colore.sh avremo la stampa dei colori e la rispettiva variabile, simpatico no? Se volessimo avere i colori sempre disponibili ci basterà inserire nel file bashrc il seguente codice: export export export export export export export export export export export export export export export export export WHITE="\e[1;37m" LGRAY="\e[0;37m" GRAY="\e[1;30m" BLACK="\e[0;30m" RED="\e[0;31m" LRED="\e[1;31m" GREEN="\e[0;32m" LGREEN="\e[1;32m" BROWN="\e[0;33m" YELLOW="\e[1;33m" BLUE="\e[0;34m" LBLUE="\e[1;34m" PURPLE="\e[0;35m" PINK="\e[1;35m" CYAN="\e[0;36m" LCYAN="\e[1;36m" Z="\e[0m" Ovviamente portando lo script su una macchina differente perderemmo i colori, quindi ogni qualvolta vogliate usare i colori nel vostro script bash, vi consiglio di inserire in testa le varie export. Ciao, MGS CAPITOLO 2. PILLOLE 43 2.2 Terminale confuso Vi sarà capitato sicuramente almeno una volta, o vi capiterà prima o poi di fare un cat di un file binario, e ricevere a video una serie di caratteri insensati, una marea di bip e il cambio colore del testo. Bene! Anzi male, visto che i caratteri del vostro bel terminale, vengono rimpiazzati da altri di difficile / impossibile lettura e da molti beep! Non andiamo in panico però, visto che comunque il terminale continua a funzionare correttamente, digitiamo: reset [invio] e il gioco è fatto, come per magia leggiamo nuovamente tutto! “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb 2.3 A proposito di... Vi scrivo quì una piccola perla, molto utile per i newbie, per ritrovare nei meandri del man di linux le informazioni che ci servono. Utilizzando il comando apropos, si può effettuare una ricerca all’interno del manuale. Quindi per portare un esempio pratico, digitando: apropos floppy avremo il seguente risultato: fd (4) - floppy disk device fdformat (Cool - Low-level formats a floppy disk fdmount (1) - Floppy disk mount utility fdrawcmd (1) - send raw commands to the floppy disk controller floppycontrol (1) - floppy driver configuration utility floppyd (1) - floppy daemon for remote access to floppy drive floppyd_installtest - tests whether floppyd is installed and running floppyd_installtest (1) - tests whether floppyd is installed and running floppymeter (1) - measure raw capacity and exact rotation speed of floppy drive gfloppy (1) - a simple floppy formatter for the GNOME mbadblocks (1) - tests a floppy disk, and marks the bad blocks in the FAT mformat (1) - add an MSDOS filesystem to a low-level formatted floppy disk mkrescue (Cool - make rescue floppy setfdprm (1) - sets user-provided floppy disk parameters setfdprm (Cool - sets user-provided floppy disk parameters a questo punto volendo creare un rescue disk, per sapere il funzionamento digiteremo: man mkrescue Usatelo senza limiti quando avete bisogno di qualcosa con linux ma non sapete che “pesci di manuale” pigliare. “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb 3 GNU Free Documentation License Version 1.1, March 2000 Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. 0. PREAMBLE The purpose of this License is to make a manual, textbook, or other written document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of copyleft, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. 1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The Document, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as you. A Modified Version of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A Secondary Section is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with 44 CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 45 the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The Invariant Sections are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. The Cover Texts are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Transparent copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not Transparent is called Opaque. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standardconforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only. The Title Page means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, Title Page means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text. 2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. 3. COPYING IN QUANTITY If you publish printed copies of the Document numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 46 If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. 4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s license notice. H. Include an unaltered copy of this License. I. Preserve the section entitled History, and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled History in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the History section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled Acknowledgements or Dedications, preserve the section’s title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section entitled Endorsements. Such a section may not be included in the Modified Version. N. Do not retitle any existing section as Endorsements or to conflict in title with any Invariant Section. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 47 or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles. You may add a section entitled Endorsements, provided it contains nothing but endorsements of your Modified Version by various parties–for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. 5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled History in the various original documents, forming one section entitled History; likewise combine any sections entitled Acknowledgements, and any sections entitled Dedications. You must delete all sections entitled Endorsements. 6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. 7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an aggregate, and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document. CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 48 If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document’s Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. 8. TRANSLATION Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. 9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. 10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License or any later version applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. ADDENDUM: How to use this License for your documents To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled GNU Free Documentation License. If you have no Invariant Sections, write with no Invariant Sections instead of saying which ones are invariant. If you have no Front-Cover Texts, write no Front-Cover Texts instead of Front-Cover Texts being LIST; likewise for Back-Cover Texts. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 49 3.1 GNU Free Documentation License - Italiano Questo documento è la traduzione non ufficiale (e quindi senza alcun valore legale) della GNU FDL. E’ stata inserita al solo scopo di aiutare il lettore italiano nella comprensione del contenuto. Eventuali controversie legali saranno risolte esclusivamente in base alla versione originale di questo documento. Versione 1.1, Marzo 2000 Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Chiunque può copiare e distribuire copie letterali di questo documento di licenza, ma non ne è permessa la modifica. 0 PREAMBOLO Lo scopo di questa licenza è di rendere un manuale, un testo o altri documenti scritti liberi nel senso di assicurare a tutti la libertà effettiva di copiarli e redistribuirli, con o senza modifiche, a fini di lucro ono. In secondo luogo questa licenza prevede per autori ed editori il modo per ottenere il giusto riconoscimento del proprio lavoro, preservandoli dall’essere considerati responsabili per modifiche apportate da altri. Questa licenza è un copyleft: ciò vuol dire che i lavori che derivano dal documento originale devono essere ugualmente liberi. È il complemento alla GNU General Public License, che è una licenza di tipo copyleft pensata per il software libero. Abbiamo progettato questa licenza al fine di applicarla alla documentazione del software libero, perché il software libero ha bisogno di documentazione libera: un programma libero dovrebbe accompagnarsi a manuali che forniscano la stessa libertà del software. Ma questa licenza non è limitata alla documentazione del software; può essere utilizzata per ogni testo che tratti un qualsiasi argomento e al di là dell’avvenuta pubblicazione cartacea. Raccomandiamo principalmente questa licenza per opere che abbiano fini didattici o per manuali di consultazione. 1 APPLICABILITÀ E DEFINIZIONI Questa licenza si applica a qualsiasi manuale o altra opera che contenga una nota messa dal detentore del copyright che dica che si può distribuire nei termini di questa licenza. Con Documento, in seguito ci si riferisce a qualsiasi manuale o opera. Ogni fruitore è un destinatario della licenza e viene indicato con voi. Una versione modificata di un documento è ogni opera contenente il documento stesso o parte di esso, sia riprodotto alla lettera che con modifiche, oppure traduzioni in un’altra lingua. Una sezione secondaria è un’appendice cui si fa riferimento o una premessa del documento e riguarda esclusivamente il rapporto dell’editore o dell’autore del documento con l’argomento generale del documento stesso (o argomenti affini) e non contiene nulla che possa essere compreso nell’argomento principale. (Per esempio, se il documento è in parte un manuale di matematica, una sezione secondaria non può contenere spiegazioni di matematica). Il rapporto con l’argomento può essere un tema collegato storicamente con il soggetto principale o con soggetti affini, o essere costituito da argomentazioni legali, commerciali, filosofiche, etiche o politiche pertinenti. Le sezioni non modificabili sono alcune sezioni secondarie i cui titoli sono esplicitamente dichiarati essere sezioni non modificabili, nella nota che indica che il documento è realizzato sotto questa licenza. I testi copertina sono dei brevi brani di testo che sono elencati nella nota che indica che il documento è realizzato sotto questa licenza. Una copia trasparente del documento indica una copia leggibile da un calcolatore, codificata in un formato le cui specifiche sono disponibili pubblicamente, i cui contenuti possono essere visti e modificati direttamente, ora e in futuro, con generici editor di testi o (per immagini composte da pixel) con generici editor di immagini o (per i disegni) con qualche editor di disegni ampiamente diffuso, e la copia deve essere adatta al trattamento per la formattazione o per la conversione in una varietà di formati atti alla CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 50 successiva formattazione. Una copia fatta in un altro formato di file trasparente il cui markup è stato progettato per intralciare o scoraggiare modifiche future da parte dei lettori non è trasparente. Una copia che non è trasparente è opaca. Esempi di formati adatti per copie trasparenti sono l’ASCII puro senza markup, il formato di input per Texinfo, il formato di input per LaTex, SGML o XML accoppiati ad una DTD pubblica e disponibile, e semplice HTML conforme agli standard e progettato per essere modificato manualmente. Formati opachi sono PostScript, PDF, formati proprietari che possono essere letti e modificati solo con word processor proprietari, SGML o XML per cui non è in genere disponibile la DTD o gli strumenti per il trattamento, e HTML generato automaticamente da qualche word processor per il solo output. La pagina del titolo di un libro stampato indica la pagina del titolo stessa, più qualche pagina seguente per quanto necessario a contenere in modo leggibile, il materiale che la licenza prevede che compaia nella pagina del titolo. Per opere in formati in cui non sia contemplata esplicitamente la pagina del titolo, con pagina del titolo si intende il testo prossimo al titolo dell’opera, precedente l’inizio del corpo del testo. 2 COPIE ALLA LETTERA Si può copiare e distribuire il documento con l’ausilio di qualsiasi mezzo, per fini di lucro e non, fornendo per tutte le copie questa licenza, le note sul copyright e l’avviso che questa licenza si applica al documento, e che non si aggiungono altre condizioni al di fuori di quelle della licenza stessa. Non si possono usare misure tecniche per impedire o controllare la lettura o la produzione di copie successive alle copie che si producono o distribuiscono. Però si possono ricavare compensi per le copie fornite. Se si distribuiscono un numero sufficiente di copie si devono seguire anche le condizioni della sezione 3. Si possono anche prestare copie e con le stesse condizioni sopra menzionate possono essere utilizzate in pubblico. 3 COPIARE IN NOTEVOLI QUANTITÀ Se si pubblicano a mezzo stampa più di 100 copie del documento, e la nota della licenza indica che esistono uno o più testi copertina, si devono includere nelle copie, in modo chiaro e leggibile, tutti i testi copertina indicati: il testo della prima di copertina in prima di copertina e il testo di quarta di copertina in quarta di copertina. Ambedue devono identificare l’editore che pubblica il documento. La prima di copertina deve presentare il titolo completo con tutte le parole che lo compongono egualmente visibili ed evidenti. Si può aggiungere altro materiale alle copertine. Il copiare con modifiche limitate alle sole copertine, purché si preservino il titolo e le altre condizioni viste in precedenza, è considerato alla stregua di copiare alla lettera. Se il testo richiesto per le copertine è troppo voluminoso per essere riprodotto in modo leggibile, se ne può mettere una prima parte per quanto ragionevolmente può stare in copertina, e continuare nelle pagine immediatamente seguenti. Se si pubblicano o distribuiscono copie opache del documento in numero superiore a 100, si deve anche includere una copia trasparente leggibile da un calcolatore per ogni copia o menzionare per ogni copia opaca un indirizzo di una rete di calcolatori pubblicamente accessibile in cui vi sia una copia trasparente completa del documento, spogliato di materiale aggiuntivo, e a cui si possa accedere anonimamente e gratuitamente per scaricare il documento usando i protocolli standard e pubblici generalmente usati. Se si adotta l’ultima opzione, si deve prestare la giusta attenzione, nel momento in cui si inizia la distribuzione in quantità elevata di copie opache, ad assicurarsi che la copia trasparente rimanga accessibile all’indirizzo stabilito fino ad almeno un anno di distanza dall’ultima distribuzione (direttamente o attraverso rivenditori) di quell’edizione al pubblico. È caldamente consigliato, benché non obbligatorio, contattare l’autore del documento prima di distribuirne un numero considerevole di copie, per metterlo in grado di fornire una versione aggiornata del documento. CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 51 4 MODIFICHE Si possono copiare e distribuire versioni modificate del documento rispettando le condizioni delle precedenti sezioni 2 e 3, purché la versione modificata sia realizzata seguendo scrupolosamente questa stessa licenza, con la versione modificata che svolga il ruolo del documento, così da estendere la licenza sulla distribuzione e la modifica a chiunque ne possieda una copia. Inoltre nelle versioni modificate si deve: A. Usare nella pagina del titolo (e nelle copertine se ce ne sono) un titolo diverso da quello del documento, e da quelli di versioni precedenti (che devono essere elencati nella sezione storia del documento ove presenti). Si può usare lo stesso titolo di una versione precedente se l’editore di quella versione originale ne ha dato il permesso. B. Elencare nella pagina del titolo, come autori, una o più persone o gruppi responsabili in qualità di autori delle modifiche nella versione modificata, insieme ad almeno cinque fra i principali autori del documento (tutti gli autori principali se sono meno di cinque). C. Dichiarare nella pagina del titolo il nome dell’editore della versione modificata in qualità di editore. D. Conservare tutte le note sul copyright del documento originale. E. Aggiungere un’appropriata licenza per le modifiche di seguito alle altre licenze sui copyright. F. Includere immediatamente dopo la nota di copyright, un avviso di licenza che dia pubblicamente il permesso di usare la versione modificata nei termini di questa licenza, nella forma mostrata nell’addendum alla fine di questo testo. G. Preservare in questo avviso di licenza l’intera lista di sezioni non modificabili e testi copertina richieste come previsto dalla licenza del documento. H. Includere una copia non modificata di questa licenza. I. Conservare la sezione intitolata Storia, e il suo titolo, e aggiungere a questa un elemento che riporti al minimo il titolo, l’anno, i nuovi autori, e gli editori della versione modificata come figurano nella pagina del titolo. Se non ci sono sezioni intitolate Storia nel documento, createne una che riporti il titolo, gli autori, gli editori del documento come figurano nella pagina del titolo, quindi aggiungete un elemento che descriva la versione modificata come detto in precedenza. J. Conservare l’indirizzo in rete riportato nel documento, se c’è, al fine del pubblico accesso ad una copia trasparente, e possibilmente l’indirizzo in rete per le precedenti versioni su cui ci si è basati. Questi possono essere collocati nella sezione Storia. Si può omettere un indirizzo di rete per un’opera pubblicata almeno quattro anni prima del documento stesso, o se l’originario editore della versione cui ci si riferisce ne dà il permesso. K. In ogni sezione di Ringraziamenti o Dediche, si conservino il titolo, il senso, il tono della sezione stessa. L. Si conservino inalterate le sezioni non modificabili del documento, nei propri testi e nei propri titoli. I numeri della sezione o equivalenti non sono considerati parte del titolo della sezione. M. Si cancelli ogni sezione intitolata Riconoscimenti. Solo questa sezione può non essere inclusa nella versione modificata. N. Non si modifichi il titolo di sezioni esistenti come miglioria o per creare confusione con i titoli di sezioni non modificabili. Se la versione modificata comprende nuove sezioni di primaria importanza o appendici che ricadono in sezioni secondarie, e non contengono materiale copiato dal documento, si ha facoltà di rendere non modificabili quante sezioni si voglia. Per fare ciò si aggiunga il loro titolo alla lista delle sezioni immutabili nella nota di copyright della versione modificata. Questi titoli devono essere diversi dai titoli di ogni altra sezione. Si può aggiungere una sezione intitolata Riconoscimenti, a patto che non contenga altro che le approvazioni alla versione modificata prodotte da vari soggetti–per esempio, affermazioni di revisione o che il testo è stato approvato da una organizzazione come la definizione normativa di uno standard. Si può aggiungere un brano fino a cinque parole come Testo Copertina, e un brano fino a 25 parole come Testo di Retro Copertina, alla fine dell’elenco dei Testi Copertina nella versione modificata. Solamente un brano del Testo Copertina e uno del Testo di Retro Copertina possono essere aggiunti (anche con adattamenti) da ciascuna persona o organizzazione. Se il documento include già un testo copertina per la stessa copertina, precedentemente aggiunto o adattato da voi o dalla stessa organizzazione nel nome della quale si agisce, non se ne può aggiungere un altro, ma si può rimpiazzare il vecchio ottenendo l’esplicita autorizzazione dall’editore precedente che aveva ag- CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 52 giunto il testo copertina. L’autore/i e l’editore/i del documento non ottengono da questa licenza il permesso di usare i propri nomi per pubblicizzare la versione modificata o rivendicare l’approvazione di ogni versione modificata. 5 UNIONE DI DOCUMENTI Si può unire il documento con altri realizzati sotto questa licenza, seguendo i termini definiti nella precedente sezione 4 per le versioni modificate, a patto che si includa l’insieme di tutte le Sezioni Invarianti di tutti i documenti originali, senza modifiche, e si elenchino tutte come Sezioni Invarianti della sintesi di documenti nella licenza della stessa. Nella sintesi è necessaria una sola copia di questa licenza, e multiple sezioni invarianti possono essere rimpiazzate da una singola copia se identiche. Se ci sono multiple Sezioni Invarianti con lo stesso nome ma contenuti differenti, si renda unico il titolo di ciascuna sezione aggiungendovi alla fine e fra parentesi, il nome dell’autore o editore della sezione, se noti, o altrimenti un numero distintivo. Si facciano gli stessi aggiustamenti ai titoli delle sezioni nell’elenco delle Sezioni Invarianti nella nota di copyright della sintesi. Nella sintesi si devono unire le varie sezioni intitolate storia nei vari documenti originali di partenza per formare una unica sezione intitolata storia; allo stesso modo si unisca ogni sezione intitolata Ringraziamenti, e ogni sezione intitolata Dediche. Si devono eliminare tutte le sezioni intitolate Riconoscimenti. 6 RACCOLTE DI DOCUMENTI Si può produrre una raccolta che consista del documento e di altri realizzati sotto questa licenza; e rimpiazzare le singole copie di questa licenza nei vari documenti con una sola inclusa nella raccolta, solamente se si seguono le regole fissate da questa licenza per le copie alla lettera come se si applicassero a ciascun documento. Si può estrarre un singolo documento da una raccolta e distribuirlo individualmente sotto questa licenza, solo se si inserisce una copia di questa licenza nel documento estratto e se si seguono tutte le altre regole fissate da questa licenza per le copie alla lettera del documento. 7 RACCOGLIERE INSIEME A LAVORI INDIPENDENTI Una raccolta del documento o sue derivazioni con altri documenti o lavori separati o indipendenti, all’interno di o a formare un archivio o un supporto per la distribuzione, non è una versione modificata del documento nella sua interezza, se non ci sono copyright per l’intera raccolta. Ciascuna raccolta si chiama allora aggregato e questa licenza non si applica agli altri lavori contenuti in essa che ne sono parte, per il solo fatto di essere raccolti insieme, qualora non siano però loro stessi lavori derivati dal documento. Se le esigenze del Testo Copertina della sezione 3 sono applicabili a queste copie del documento allora, se il documento è inferiore ad un quarto dell’intero aggregato i Testi Copertina del documento possono essere piazzati in copertine che delimitano solo il documento all’interno dell’aggregato. Altrimenti devono apparire nella copertina dell’intero aggregato. 8 TRADUZIONI La traduzione è considerata un tipo di modifica, e di conseguenza si possono distribuire traduzioni del documento seguendo i termini della sezione 4. Rimpiazzare sezioni non modificabili con traduzioni richiede un particolare permesso da parte dei detentori del diritto d’autore, ma si possono includere traduzioni di una o più sezioni non modificabili in aggiunta alle versioni originali di queste sezioni immutabili. Si può fornire una traduzione della presente licenza a patto che si includa anche l’originale versione inglese di questa licenza. In caso di discordanza fra la traduzione e l’originale inglese di questa licenza la versione originale inglese prevale sempre. CAPITOLO 3. GNU FREE DOCUMENTATION LICENSE 53 9 TERMINI Non si può applicare un’altra licenza al documento, copiarlo, modificarlo, o distribuirlo al di fuori dei termini espressamente previsti da questa licenza. Ogni altro tentativo di applicare un’altra licenza al documento, copiarlo, modificarlo, o distribuirlo è deprecato e pone fine automaticamente ai diritti previsti da questa licenza. Comunque, per quanti abbiano ricevuto copie o abbiano diritti coperti da questa licenza, essi non ne cessano se si rimane perfettamente coerenti con quanto previsto dalla stessa. 10 REVISIONI FUTURE DI QUESTA LICENZA La Free Software Foundation può pubblicare nuove, rivedute versioni della Gnu Free Documentation License volta per volta. Qualche nuova versione potrebbe essere simile nello spirito alla versione attuale ma differire in dettagli per affrontare nuovi problemi e concetti. Si veda a questo proposito la pagina web http://www.gnu.org/copyleft. Ad ogni versione della licenza viene dato un numero che distingue la versione stessa. Se il documento specifica che si riferisce ad una versione particolare della licenza contraddistinta dal numero o ogni versione successiva, si ha la possibilità di seguire termini e condizioni sia della versione specificata che di ogni versione successiva pubblicata (non come bozza) dalla Free Software Foundation. Se il documento non specifica un numero di versione particolare di questa licenza, si può scegliere ogni versione pubblicata (non come bozza) dalla Free Software Foundation. Come usare questa licenza per i vostri documenti Per applicare questa licenza ad un documento che si è scritto, si includa una copia della licenza nel documento e si inserisca il seguente avviso di copiright appena dopo la pagina del titolo: Copyright (c) ANNO VOSTRO NOME. È garantito il permesso di copiare, distribuire e/o modificare questo documento seguendo i termini della GNU Free Documentation License, Versione 1.1 o ogni versione successiva pubblicata dalla Free Software Foundation; con le Sezioni Non Modificabili ELENCARNE I TITOLI, con i Testi Copertina ELENCO, e con i Testi di Retro Copertina ELENCO. Una copia della licenza è acclusa nella sezione intitolata GNU Free Documentation License. Se non ci sono Sezioni non Modificabili, si scriva senza Sezioni non Modificabili invece di dire quali sono non modificabili. Se non c’è Testo Copertina, si scriva nessun Testo Copertina invece di il testo Copertina è ELENCO; e allo stesso modo si operi per il Testo di Retro Copertina. Se il vostro documento contiene esempi non banali di programma in codice sorgente si raccomanda di realizzare gli esempi contemporaneamente applicandovi anche una licenza di software libero di vostra scelta, come ad esempio la GNU General Public License, al fine di permetterne l’uso come software libero. La copia letterale e la distribuzione di questo articolo nella sua integrità sono permesse con qualsiasi mezzo, a condizione che questa nota sia riprodotta. Aggiornato: 20 Settembre 2000 Andrea Ferro, Leandro Noferini e Franco Vite. Prossimamente su Topolinux Prossimamente su Topolinux potrete trovare moltissime altre informazioni sul nostro amico Pinguino, ed in particolare: • un semplice monitor di sistema; • gestione pacchetti .tgz; • personalizzare KDE; • compilare il kernel; • scegliere un file system; • macchine virtuali. e molto altro ancora! Vi consiglio quindi di non mancare l’appuntamento con i prossimi numeri. “Il calabrone non ha una struttura alare adatta al volo, ma lui non lo sa e continua a volare”, Lemoeb 54