TopoLinux - Vecchiomago

Transcript

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 !
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
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.
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!
Lemoeb
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.
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
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
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!
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.
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!
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.
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
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.
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
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:
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.
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).
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
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:
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
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
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
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.
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.
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
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
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.
#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.
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
#
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:
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=èxpr $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).
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=èxpr $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
#--------------------------
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=èxpr $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):
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.
Lemoeb
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,
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.
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/
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
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
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.
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
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
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!
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.
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.
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
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.
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.
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
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.
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-
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.
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.
Lemoeb
54

TopoLinux - Vecchiomago

Transcript

Documenti analoghi

Come Attivare una Licenza di Rete (Mac)

Come Attivare una Licenza di Rete (Windows)

modulo di iscrizione - Comune di Roccagorga

Richard Stallman

Scarica le slides di Daniele Mazzocchi dell`Istituto Superiore Mario

Scale 3 - Brigantaggio.net

Scriba - indice - Palestra della scrittura