Debian -->
[ document manifest ]
 

Manuale di Debian Live

Debian Live Project

Rights: Copyright ©  2006-2011 Debian Live Project;
License: Questo programma è software libero: è possibile ridistribuirlo e modificarlo secondo i termini della GNU General Public License come pubblicata dalla Free Software Foundation, sia la versione 3 della licenza o (a scelta) una versione successiva.

Questo programma è distribuito nella speranza che possa essere utile, ma SENZA ALCUNA GARANZIA, nemmeno la garanzia implicita di COMMERCIABILITÀ o IDONEITÀ PER UN PARTICOLARE SCOPO. Vedere la GNU General Public License per ulteriori dettagli.

Si dovrebbe aver ricevuto una copia della GNU General Public License con questo programma. In caso contrario, vedere http://www.gnu.org/licenses/.

Il testo completo della GNU General Public License può essere trovato nel file /usr/share/common-licenses/GPL-3.


Manuale di Debian Live

A proposito

1. A proposito di questo manuale

1.1 Per gli impazienti
1.2 Glossario
1.3 Autori
1.4 Contribuire a questo documento
1.4.1 Applicare le patch
1.4.2 Traduzione

2. A proposito del progetto Debian Live

2.1 Motivazioni
2.1.1 Cosa c'è di sbagliato con gli attuali sistemi live
2.1.2 Perché creare il proprio sistema live?
2.2 Filosofia
2.2.1 Solamente pacchetti da Debian "main", inalterati.
2.2.2 Nessun pacchetto di configurazione per il sistema live
2.3 Contatti

Utente

3. Installazione

3.1 Requisiti
3.2 Installare live-build
3.2.1 Dal repository Debian
3.2.2 Da sorgenti
3.2.3 Da "istantanee"
3.3 live-boot e live-config
3.3.1 Dal repository Debian
3.3.2 Da sorgenti
3.3.3 Da "istantanee"

4. Nozioni di base

4.1 Che cos'è un sistema live?
4.2 Primi passi: creare un'immagine ISO ibrida
4.3 Utilizzare un'immagine ISO live ibrida
4.3.1 Masterizzare un'immagine ISO su un supporto fisico
4.3.2 Copiare un'immagine ISO ibrida su una penna USB
4.3.3 Avviare il supporto live
4.4 Utilizzare una macchina virtuale per le prove
4.4.1 Provare un'immagine ISO con QEMU
4.4.2 Provare un'immagine ISO con virtualbox-ose
4.5 Creare un'immagine USB/HDD
4.6 Utilizzare un'immagine USB/HDD
4.6.1 Provare un'immagine USB/HDD con Qemu
4.6.2 Usare lo spazio rimanente su una penna USB
4.7 Creare un'immagine netboot
4.7.1 Server DHCP
4.7.2 Server TFTP
4.7.3 Server NFS
4.7.4 Come provare una netboot
4.7.5 Qemu
4.7.6 VMWare Player

5. Panoramica degli strumenti

5.1 live-build
5.1.1 Il comando lb config
5.1.2 Il comando lb build
5.1.3 Il comando lb clean
5.2 Il pacchetto live-boot
5.3 Il pacchetto live-config

6. Gestire una configurazione

6.1 Utilizzare auto per gestire i cambiamenti di configurazione
6.2 Esempi di auto script

7. Panoramica sulla personalizzazione

7.1 Configurazione in fase di compilazione e di avvio
7.2 Fasi della creazione
7.3 Integrare la configurazione di lb con dei file
7.4 Personalizzazione dei compiti

8. Personalizzare l'installazione dei pacchetti

8.1 Sorgenti dei pacchetti
8.1.1 Distribuzione, le aree di archivio e le modalità
8.1.2 Mirror delle distribuzioni
8.1.3 Mirror delle distribuzioni usati in fase di compilazione
8.1.4 Mirror delle distribuzioni usate durante l'esecuzione
8.1.5 Repository addizionali
8.2 Scegliere i pacchetti da installare
8.2.1 Elenchi di pacchetti
8.2.2 Elenchi predefiniti di pacchetti
8.2.3 Elenchi locali dei pacchetti
8.2.4 Elenchi locali di pacchetti binari
8.2.5 Estendere un'elenco di pacchetti usando gli include
8.2.6 Usare condizioni all'interno degli elenchi di pacchetti
8.2.7 Task
8.2.8 Task per desktop e lingua
8.3 Installare pacchetti modificati o di terze parti
8.3.1 Using packages.chroot to install custom packages
8.3.2 Utilizzare un repository APT per installare pacchetti personalizzati
8.3.3 Pacchetti personalizzati e APT
8.4 Configurare APT in fase di costruzione
8.4.1 Scegliere apt o aptitude
8.4.2 Utilizzare un proxy con APT
8.4.3 Modificare APT per risparmiare spazio
8.4.4 Passare opzioni ad apt o aptitude
8.4.5 APT pinning

9. Personalizzazione dei contenuti

9.1 Include
9.1.1 Live/chroot include locali
9.1.2 Include locali binari
9.1.3 Include binari
9.2 Hook
9.2.1 Live/chroot hook locali
9.2.2 Hook in fase di avvio
9.2.3 Hook binari locali
9.3 Preconfigurare le domande di Debconf

10. Personalizzare i comportamenti durante l'esecuzione

10.1 Personalizzare l'utente live
10.2 Personalizzare la localizzazione e la lingua
10.3 Persistenza
10.3.1 Persistenza completa
10.3.2 Mount automatico della home
10.3.3 Istantanee
10.3.4 Sottotesto persistente
10.3.5 Rimasterizzazione parziale

11. Personalizzare l'immagine binaria

11.1 Bootloader
11.2 Metadati ISO

12. Personalizzare il Debian Installer

12.1 Tipologie del Debian Installer
12.2 Personalizzare il Debian Installer con la preconfigurazione
12.3 Personalizzare il contenuto del Debian Installer

Progetto

13. Segnalare bug

13.1 Problemi noti
13.2 Ricostruire da zero
13.3 Usare pacchetti aggiornati
13.4 Raccogliere informazioni
13.5 Se possibile isolare il caso non andato a buon fine
13.6 Segnalare il bug del pacchetto giusto
13.6.1 Durante la compilazione mentre esegue il bootstrap
13.6.2 Durante la compilazione mentre installa i pacchetti
13.6.3 In fase di avvio
13.6.4 In fase di esecuzione
13.7 Fare la ricerca
13.8 Dove segnalare i bug

14. Lo stile nello scrivere codice

14.1 Compatibilità
14.2 Rientri
14.3 Ritorno a capo
14.4 Variabili
14.5 Varie

15. Procedure

15.1 Aggiornamenti degli udeb
15.2 Rilasci importanti
15.3 Rilasci minori
15.3.1 Modello per l'annuncio di un rilascio minore.

Esempi

16. Esempi

16.1 Usare gli esempi
16.2 Tutorial 1: un'immagine standard
16.3 Tutorial 2: servizio browser web
16.4 Tutorial 3: un'immagine personalizzata
16.4.1 Prima revisione
16.4.2 Seconda revisione
16.5 Un client Kiosk VNC
16.6 Un'immagine base per una chiavetta USB da 128M
16.7 Un desktop KDE localizzato e l'installer

Manuale di Debian Live

A proposito

1. A proposito di questo manuale

L'obiettivo principale di questo manuale è quello di servire come unico punto d'accesso per tutta la documentazione relativa al progetto Debian Live. Sebbene sia principalmente focalizzato nell'aiutare a costruire un sistema live e non su argomenti per l'utente finale, è comunque possibile trovare alcune informazioni utili in queste sezioni: le Nozioni di base coprono la preparazione delle immagini da avviare da un supporto o dalla rete, mentre Personalizzare i comportamenti durante l'esecuzione descrive alcune opzioni specificabili al prompt d'avvio, come la scelta di un layout di tastiera e una lingua, e l'utilizzo della persistenza.

Alcuni dei comandi menzionati nel testo devono essere eseguiti con i privilegi di super-utente che possono essere ottenuti diventando utente root tramite su oppure usando sudo. Per distinguere i comandi che possono essere eseguiti come utente normale da quelli che necessitano dei privilegi di super-utente, i comandi sono preceduti rispettivamente da $ o #. Questi simboli non fanno parte del comando.

1.1 Per gli impazienti

Sebbene crediamo che ogni cosa in questo manuale sia importante almeno per alcuni dei nostri utenti, ci rendiamo conto che c'è tanto materiale da trattare e che si potrebbe voler provare il software prima di entrare nei dettagli. Pertanto, abbiamo messo a disposizione nella sezione Esempi tre tutorial progettati per insegnarvi le basi della costruzione e della personalizzazione delle immagini. Si legga innanzitutto Usare gli esempi, seguito da Tutorial 1: un'immagine standard, Tutorial 2: un programma di utilità web browser e, infine, Tutorial 3: un'immagine personalizzata. Alla fine di queste esercitazioni, si avrà un assaggio di ciò che si può fare con Debian Live. Ti invitiamo ad uno studio più approfondito del manuale, magari leggendo in seguito le Nozioni di base, sfogliando o saltando Creare un'immagine netboot, e finendo con la lettura di Panoramica sulla personalizzazione e dei capitoli che lo seguono. A questo punto, ci auguriamo che tu sia davvero eccitato da ciò che si può fare con Debian Live e motivato a leggere il resto del manuale, da cima a fondo.

1.2 Glossario
  • Live system: Un sistema operativo che può partire senza installazione su disco rigido. I sistemi live non alterano né il sistema operativo locale (o i sistemi operativi locali) né i file già installati sul disco rigido del computer a meno che lo si faccia volontariamente. I sistemi live vengono solitamente avviati da supporti quali CD, DVD o penne USB; alcuni possono anche avviarsi via rete.
  • Debian Live: Il sotto-progetto Debian che mantiene i pacchetti live-boot, live-build, live-config e live-manual.
  • Debian Live system: Un sistema live che usa software proveniente dal sistema operativo Debian e che può essere lanciato da CD, DVD, supporti USB, via rete (tramite immagini netboot) e via internet (tramite il parametro di boot fetch=URL).
  • Host system: L'ambiente utilizzato per creare il sistema live.
  • Target system: L'ambiente usato per eseguire il sistema live.
  • live-boot: Una raccolta di script usati per avviare sistemi live. live-boot era una parte di live-initramfs.
  • live-build: Una raccolta di script usati per creare sistemi Debian Live personalizzati. live-build era conosciuto come live-helper, ed ancora prima come live-package.
  • live-config: Una raccolta di script usati per configurare un sistema live durante il processo di inizializzazione. live-config era una parte di live-initramfs.
  • live-manual: Questo documento è inserito nel pacchetto chiamato live-manual.
  • Debian Installer (d-i): Il sistema d'installazione ufficiale per la distribuzione Debian.
  • Boot parameters: Parametri che possono essere immessi nel prompt del boot loader per modificare il comportamento del kernel o di live-config.
  • chroot: Il programma chroot, chroot(8), rende possibile eseguire diverse istanze dell'ambiente GNU/Linux su un singolo sistema simultaneamente senza riavviare.
  • Binary image: Un file che contiene il sistema live, come binary.iso o binary.img.
  • Target distribution: La distribuzione su cui sarà basato il sistema live. Può differire dalla distribuzione presente sul proprio computer.
  • Squeeze/Wheezy/Sid (stable/testing/unstable): Nomi in codice per i rilasci Debian; al momento Squeeze è l'attuale stable e Wheezy l'attuale testing. Sid sarà sempre il sinonimo della unstable. In tutto il manuale si tende ad usare i nomi in codice dei rilasci, in quanto questo è ciò che è previsto dagli strumenti stessi.
  • La distribuzione stable contiene l'ultima distribuzione ufficialmente rilasciata da Debian; la testing è il punto di raccolta per i pacchetti della prossima stable. Uno dei principali vantaggi nell'uso di questa distribuzione sta nell'avere software più recente rispetto alla stable. La distribuzione unstable è dove avviene lo sviluppo attivo di Debian; viene generalmente usata dagli sviluppatori o da coloro che amano l'azzardo.

    1.3 Autori

    Lista degli autori (in ordine alfabetico):

  • Ben Armstrong
  • Brendan Sleight
  • Chris Lamb
  • Daniel Baumann
  • Franklin Piat
  • Jonas Stein
  • Kai Hendry
  • Marco Amadori
  • Mathieu Geli
  • Matthias Kirschner
  • Richard Nelson
  • Trent W. Buck
  • 1.4 Contribuire a questo documento

    Questo manuale è pensato come un progetto comunitario e ogni suggerimento e contributo è benvenuto. Il modo migliore per apportare un contributo è di inviarlo alla mailing list. Per maggiori informazioni si veda la sezione Contatti.

    Quando si sottopone un contributo, si prega di indicare chiaramente il detentore del copyright e di includere la licenza. Si noti che, per essere accettato, il contributo deve essere distribuito con la stessa licenza del resto del documento, ovvero la GPL versione 3 o successiva.

    I sorgenti di questo manuale sono mantenuti utilizzando il sistema di controllo Git. Si può visionare la copia più recente eseguendo:

    $ git clone git://live.debian.net/git/live-manual.git

    Prima di sottoporre un contributo, si prega di visionare l'anteprima del proprio lavoro. Per ottenere l'anteprima di live-manual, assicurarsi di avere installati i pacchetti necessari per la sua compilazione eseguendo:

    # apt-get install make po4a sisu-complete libnokogiri-ruby

    Si può compilare il live-manual dalla directory superiore del checkout di Git eseguendo:

    $ make build

    Dato che occorre del tempo per compilare il manuale in tutte le lingue supportate, può risultare conveniente farlo per una sola lingua, ad esempio eseguendo:

    $ make build LANGUAGES=en

    1.4.1 Applicare le patch

    Chiunque può eseguire il commit direttamente sul repository; tuttavia chiediamo di inviare le modifiche più corpose in mailing list, per poterne prima discuterne. Per eseguire il push sul repository, si deve seguire questa procedura:

  • Prelevare la chiave pubblica:
  • $ mkdir -p ~/.ssh/identity.d
    $ wget http://live.debian.net/other/keys/git@live.debian.net \
         -O ~/.ssh/identity.d/git@live.debian.net
    $ wget http://live.debian.net/other/keys/git@live.debian.net.pub \
         -O ~/.ssh/identity.d/git@live.debian.net.pub
    $ chmod 0600 ~/.ssh/identity.d/git@live.debian.net*

  • Aggiungere la seguente sezione alla propria configurazione di openssh-client:
  • $ cat >> ~/.ssh/config << EOF
    Host live.debian.net
         Hostname live.debian.net
         User git
         IdentityFile ~/.ssh/identity.d/git@live.debian.net
    EOF

  • Scaricare tramite ssh un clone del manuale:
  • $ git clone git@live.debian.net:/live-manual.git
    $ cd live-manual && git checkout debian-next

  • Si noti che tutte le modifiche vanno eseguite sul ramo debian-next e non su quello debian.
  • Dopo aver modificato i file in manual/en/, chiamare il target "commit" nella directory superiore per bonificare i file ed aggiornare i file di traduzione:
  • $ make commit

  • Dopo la pulizia è possibile eseguire il commit delle modifiche. Si scrivano messaggi costituiti da frasi in inglese esaurienti ed utili, inizianti con una lettera maiuscola e terminanti con un punto. Solitamente cominceranno con la forma "Fixing/Adding/Removing/Correcting/Translating", ad esempio.
  • $ git commit -a -m "Adding a section on applying patches."

  • Inviare il commit al server:
  • $ git push

    1.4.2 Traduzione

    Per inviare una traduzione per una nuova lingua, seguire questi tre passi:

  • Tradurre i file about_manual.ssi.pot, about_project.ssi.pot e index.html.in.pot nella propria lingua con il proprio editor preferito (tipo poedit). Inviare i file tradotti alla mailing list. Una volta che abbiamo ricevuto il contributo, aggiungeremo la nuova lingua al manuale (fornendo i file po) e la attiveremo per la procedura di compilazione automatica.
  • Una volta che la nuova lingua è stata aggiunta, si può iniziare a tradurre tutti i file po situati in manual/po/, nell'ordine che si preferisce.
  • Non si dimentichi che è necessario dare un make commit per assicurarsi che i manuali tradotti siano aggiornati partendo dai file po, prima di git commit -a e git push.
  • 2. A proposito del progetto Debian Live

    2.1 Motivazioni
    2.1.1 Cosa c'è di sbagliato con gli attuali sistemi live

    Quando Debian Live iniziò erano disponibili svariati sistemi live basati su Debian che tuttora stanno facendo un buon lavoro. Dal punto di vista di Debian molti di essi hanno uno o più dei seguenti svantaggi:

  • Non sono progetti Debian, per cui non sono supportati da Debian.
  • Mischiano differenti distribuzioni come ad esempio: testing e unstable.
  • Supportano solamente i386.
  • Modificano l'aspetto e il comportamento dei pacchetti snellendoli per risparmiare spazio.
  • They include packages from outside of the Debian archive.
  • Forniscono un kernel con patch addizionali che non appartengono a Debian.
  • Sono grandi e lenti a causa delle loro dimensioni e non adatti per operazioni di salvataggio.
  • Non sono disponibili in diversi formati come CD, DVD, penne USB e immagini netboot.
  • 2.1.2 Perché creare il proprio sistema live?

    Debian è il Sistema Operativo Universale: ha un sistema live per mostraree rappresentare accuratamente il sistema con i seguenti vantaggi:

  • Sarebbe un sottoprogetto di Debian.
  • Riflette lo stato (attuale) di una distribuzione.
  • Gira su più architetture possibili.
  • È costituito solo da pacchetti Debian non modificati.
  • Non contiene nessun pacchetto che non sia presente nell'archivio di Debian.
  • Usa un kernel Debian inalterato senza patch addizionali.
  • 2.2 Filosofia
    2.2.1 Solamente pacchetti da Debian "main", inalterati.

    Verranno usati solo pacchetti dal repository Debian della sezione "main".La sezione non-free non è parte di Debian perciò non possono essere affattousati per le immagini ufficiali del sistema live.

    Non verrà cambiato nessun pacchetto. Nel caso in cui sarà necessario cambiare qualcosa sarà fatto in coordinazione con il maintainer del pacchetto Debian.

    In via eccezionale i nostri pacchetti come live-boot, live-build o live-config possono temporaneamente essere usati dal nostro repository per ragioni di sviluppo (ad esempio per creare istantanee). Verranno caricati regolarmente in Debian.

    2.2.2 Nessun pacchetto di configurazione per il sistema live

    In questa fase non saranno disponibili né esempi di installazione né configurazioni alternative. Tutti i pacchetti vengono usati con la loro configurazione predefinita così come accade con una regolare installazione di Debian.

    Nel caso in cui serva una configurazione predefinita differente, sarà fatto in coordinazione con il maintainer del pacchetto in Debian.

    Viene fornito un sistema per configurare i pacchetti tramite debconf nel lb config (use --preseed FILE) consentendo di installare pacchetti configurati secondo le proprie preferenze nell'immagine Debian Live personalizzata, ma per le immagini ufficiali verrà usata la configurazione predefinita. Per ulteriori informazioni si veda Panoramica sulla personalizzazione.

    Eccezione: ci sono alcuni cambiamenti essenziali per far nascere un sistema live (ad esempio configurare pam per permettere le password vuote). Queste modifiche essenziali devono essere tenute al minimo possibile e saranno eventualmente aggiunte ai repository Debian.

    2.3 Contatti
  • Mailing list: Il principale contatto del progetto è la mailing list ‹http://lists.debian.org/debian-live/›, si possono inviare email alla lista direttamente a ‹debian-live@lists.debian.org.› Gli archivi sono disponibili presso ‹http://lists.debian.org/debian-live/›.
  • IRC: Molti utenti e sviluppatori sono presenti sul canale #debian-live su irc.debian.org (OFTC). Quando si pone una domanda su IRC, si prega di essere pazienti nell'ottenere una risposta; se non si riceve risposta scrivere alla mailing list.
  • BTS : Il Debian Bug Tracking System (BTS) contiene i dettagli dei bug riportati dagli utenti e dagli sviluppatori. A ciascun bug viene assegnato un numero, e viene mantenuto finché non è segnato come risolto. Per ulteriori informazioni si veda Segnalare bug.
  • Wiki: Il wiki di Debian Live all'indirizzo ‹http://wiki.debian.org/DebianLive› è un posto dove raccogliere informazioni, discutere di tecnologie applicate e documenti sull'infrastruttura dei sistemi Debian Live che vanno oltre lo scopo di questo manuale.
  • Utente

    3. Installazione

    3.1 Requisiti

    Per costruire immagini Debian Live i requisiti di sistema sono davvero pochi:

  • Accesso come super-utente (root)
  • Una versione aggiornata di live-build
  • Una shell POSIX-compliant, come bash o dash.
  • debootstrap o cdebootstrap
  • Linux 2.6.x
  • Si noti che usare Debian o una distribuzione derivata Debian non è richiesto - live-build funzionerà sostanzialmente su qualsiasi distribuzione che soddisfi i requisiti di cui sopra.

    3.2 Installare live-build

    Si può installare live-build in diversi modi:

  • Dal repository Debian
  • Da sorgenti
  • Da istantanee
  • Se si sta usando Debian, il metodo raccomandato è di installare live-build attraverso il repository Debian.

    3.2.1 Dal repository Debian

    Installare live-build semplicemente come qualsiasi altro pacchetto:

    # apt-get install live-build

    o

    # aptitude install live-build

    3.2.2 Da sorgenti

    live-build è sviluppato usando il sistema di controllo versione Git. Sui sistemi basati su Debian è fornito dal pacchetto git. Per scaricare il codice aggiornato, eseguire:

    $ git clone git://live.debian.net/git/live-build.git

    È possibile costruirsi ed installarsi il proprio pacchetto Debian eseguendo:

    $ cd live-build
    $ dpkg-buildpackage -rfakeroot -b -uc -us
    $ cd ..

    Si installino ora i file .deb appena generati ai quali si è interessati, ad esempio:

    # dpkg -i live-build_2.0.8-1_all.deb

    Si può anche installare live-build direttamente sul proprio sistema eseguendo:

    # make install

    e disinstallarlo con:

    # make uninstall

    3.2.3 Da "istantanee"

    Se non si desidera generare o installare live-build da sorgenti, è possibile usare le istantanee. Sono costruite automaticamente dall'ultima versione presente su Git e disponibili su ‹http://live.debian.net/debian/›.

    3.3 live-boot e live-config

    Nota: non è necessario installare live-boot o live-config sul proprio sistema per creare sistemi Debian Live personalizzati. Tuttavia, farlo non nuoce. Se si vuole la documentazione è possibile installare i pacchetti live-boot-doc e live-config-doc separatamente.

    3.3.1 Dal repository Debian

    Sia live-boot che live-config sono disponibili dai repository Debian come per l' installazione di live-build.

    3.3.2 Da sorgenti

    Per utilizzare i sorgenti più recenti da Git si può seguire il procedimento seguente. Assicurarsi di conoscere i termini menzionati nel Glossario.

  • Scaricare i sorgenti di live-boot e live-config
  • $ git clone git://live.debian.net/git/live-boot.git
    $ git clone git://live.debian.net/git/live-config.git

    Consultare la pagine man di live-boot e live-config per i dettagli sulla personalizzazione se questa è il motivo per compilare questi pacchetti dai sorgenti.

  • Costruire un .deb di live-boot e live-config
  • È necessario compilare sulla distribuzione di destinazione, oppure in un chroot contenente la piattaforma di destinazione: significa che se l'obiettivo è Wheezy allora bisogna compilare su Wheezy.

    Se si deve compilare live-boot per una distribuzione di destinazione diversa dal proprio sistema, utilizzare un compilatore tipo pbuilder o sbuild. Ad esempio, per immagini live Wheezy, si generi live-boot in un chroot Wheezy. Se la distribuzione di destinazione corrisponde con la distribuzione del proprio sistema, si può costruire direttamente sul sistema usando dpkg-buildpackage (fornito dal pacchetto dpkg-dev) :

    $ cd live-boot
    $ dpkg-buildpackage -b -uc -us
    $ cd ../live-config
    $ dpkg-buildpackage -b -uc -us

  • Usare il .deb di live-boot generato
  • Siccome live-boot e live-config sono installati dal sistema live-build, installare il pacchetto nel sistema host non è sufficiente: occorre trattare il .deb generato come un qualsiasi altro pacchetto creato su misura. Per maggiori informazioni si veda Personalizzare l'installazione dei pacchetti. Si presti particolare attenzione a Repository aggiuntivi.

    3.3.3 Da "istantanee"

    Si può lasciare che live-build usi automaticamente l'ultima istantanea di live-boot e live-config configurando un repository esterno nella directory di configurazione di live-build. Assumendo che si sia già creato un albero di configurazione nell'attuale directory con lb config:

    $ lb config --archives live.debian.net

    4. Nozioni di base

    Questo capitolo contiene una breve panoramica del processo di generazione e le istruzioni per utilizzare i tre tipi di immagine più comunemente utilizzati. La tipologia di immagine più versatile, iso-hybrid, può essere usata su una macchina virtuale, supporto ottico o dispositivo di archiviazione portatile USB. In alcuni casi particolari, come l'utilizzo della persistenza, la usb-hdd potrebbe essere più adatta per i dispositivi USB. Il capitolo termina con le istruzioni per costruire e usare un'immagine di tipo net, che è un poco più complessa a causa del setup richiesto sul server. Si tratta di un argomento leggermente avanzato per chi non ha familiarità con l'avvio da rete, ma è incluso qui perché, una volta che il setup è stato fatto, è un modo molto comodo per collaudare e distribuire immagini facendo il boot nella rete locale senza la seccatura di doversi occupare dei mezzi di divulgazione dell'immagine.

    Throughout the chapter, we will often refer to the default filenames produced by live-build. If you are downloading a prebuilt image instead, the actual filenames may vary.

    4.1 Che cos'è un sistema live?

    Per sistema live generalmente si intende un sistema operativo che può essere avviato da un supporto rimovibile, come un CD-ROM o una chiavetta USB oppure da una rete, pronto per l'uso senza alcuna installazione su hard disk con una configurazione automatica fatta durante l'esecuzione (vedere Glossario).

    Con Debian Live, si tratta di un sistema operativo Debian GNU/Linux, generato per una delle architetture previste (attualmente amd64, i386, powerpc e sparc). È costituito dalle seguenti parti:

  • Immagine del kernel Linux, comunemente chiamata vmlinuz*
  • Initial RAM disk image (initrd): un disco RAM creato per il boot di Linux, contenente i moduli potenzialmente necessari per montare l'immagine di sistema e alcuni script per farlo.
  • Immagine di sistema: l'immagine del filesystem del sistema operativo. Normalmente è usato un filesystem compresso SquashFS, per minimizzare le dimensioni dell'immagine Debian Live. Si noti che è in sola lettura. Dunque, durante il boot il sistema Debian Live userà un disco RAM e il meccanismo 'unione' per attivare i file in scrittura all'interno del sistema in esecuzione. Ad ogni modo, tutte le modifiche verranno perse con lo spegnimento a meno che non si usi la persistenza opzionale (si veda Persistenza).
  • Bootloader: una piccola porzione di codice predisposto per l'avvio dal supporto scelto, che presenta un prompt o un menu per la selezione di opzioni/configurazioni. Carica il kernel Linux ed il suo initrd da eseguire con un filesystem associato. Possono essere usate diverse soluzioni, in base al supporto di destinazione ed al formato del filesystem contenenti le componenti precedentemente citate: isolinux per il boot da CD o DVD nel formato ISO9660, syslinux per supporti HDD o USB che si avviano da una partizione VFAT, extlinux per le partizioni ext/2/3/4 e btrfs, pxelinux per il netboot PXE, GRUB per partizioni ext2/3/4, ecc.
  • È possibile usare live-build per creare l'immagine di sistema secondo le proprie specifiche, scegliere un kernel Linux, il suo initrd ed un bootloader per avviarli, tutto in un unico formato che dipende dal mezzo (immagini ISO9660, immagine disco, ecc.)

    4.2 Primi passi: creare un'immagine ISO ibrida

    Indipendentemente dal tipo di immagine, per crearne una è necessario eseguire ogni volta la stessa procedura. Come primo esempio si eseguirà la seguente sequenza di comandi di live-build per creare un'immagine ISO ibrida di base contenente soltanto il sistema Debian standard senza X.org. È adatta per essere masterizzata su CD o DVD e anche per essere copiata su una penna USB.

    In primo luogo eseguire il comando lb config, il quale creerà una gerarchia "config/" nella directory corrente e che verrà utilizzata da altri comandi:

    $ lb config

    Non viene passato alcun parametro a lb config, in modo da utilizzare le impostazioni predefinite per le varie opzioni, vedere Il comando lb config) per maggiori dettagli.

    Ora che si ha una gerarchia "config/" si può generare l'immagine con il comando lb build:

    # lb build

    Questo processo può richiedere tempo, a seconda della velocità della connessione di rete. Una volta completato, nell'attuale directory ci sarà un file immagine binary-hybrid.iso pronto da usare.

    4.3 Utilizzare un'immagine ISO live ibrida

    Dopo aver costruito o scaricato un'immagine ISO ibrida, ottenibile all'indirizzo ‹http://www.debian.org/CD/live/›, il passo successivo è preparare il supporto per l'avvio, che sia esso un CD-R(W), un DVD-R(W) o una penna USB.

    4.3.1 Masterizzare un'immagine ISO su un supporto fisico

    Burning an ISO image is easy. Just install wodim and use it from the command-line to burn the image. For instance:

    # apt-get install wodim

    $ wodim binary-hybrid.iso

    4.3.2 Copiare un'immagine ISO ibrida su una penna USB

    Le immagini ISO preparate con il comando isohybrid, come quelle prodotte in modo predefinito da iso-hybrid, possono essere semplicemente copiate su una penna USB con il programma dd o suo equivalente. Inserire una penna USB con una dimensione sufficiente a contenere l'immagine e determinare quale device sia, al quale in seguito si farà riferimento come ${USBSTICK}.Questo è il device della penna, ad esempio /dev/sdb, non una partizione come /dev/sdb1! È possibile trovare il nome corretto controllando l'output di dmesg una volta inserita, o meglio ancora con il comando ls -l /dev/disk/by-id.

    Una volta che si è certi sul nome del device, usare il comando dd per copiare l'immagine sulla penna. Questo sovrascriverà qualsiasi dato presente su di essa!

    $ dd if=binary-hybrid.iso of=${USBSTICK}

    4.3.3 Avviare il supporto live

    La prima volta che si avvia il supporto live, CD, DVD, penna USB o PXE, può essere necessario impostare il BIOS del computer, ma giacché questi variano parecchio in opzioni e scorciatoie, non siamo in grado di descriverli. Alcuni BIOS offrono un menu per selezionare il device in fase di boot, in caso sia disponibile nel vostro sistema è il modo più semplice. Altrimenti è necessario accedere alla sua configurazione e modificare l'ordine di avvio per posizionare la periferica di boot del sistema live prima di quella usuale.

    Avviando il supporto si otterrà un menu, premendo il tasto enter il sistema partirà utilizzando la voce Live e le opzioni predefinite. Per ulteriori informazioni sulle opzioni di boot, si veda la voce "help" nel menu e le pagine di manuale di live-boot e live-config all'interno del sistema.

    Supponendo di aver selezionato Live e avviato l'immagine desktop predefinita, dopo i messaggi di avvio si dovrebbe automaticamente accedere all'account user e avere il desktop pronto all'uso. Se invece si è avviata un'immagine per la sola console, come le preconfezionate standard o rescue, si accederà alla console dell'account user ed avere un prompt di shell pronto da usare.

    4.4 Utilizzare una macchina virtuale per le prove

    Per lo sviluppo delle immagini live, può essere un notevole risparmio di tempo eseguirle in una macchina virtuale (VM). Non senza qualche raccomandazione:

  • Eseguire una VM richiede un quantitativo sufficiente di RAM sia per il sistema ospitato che per quello ospitante; è consigliato un processore che gestisca la virtualizzazione a livello hardware.
  • Ci sono alcune limitazioni inerenti, quali uno scarso rendimento video e una scelta limitata di hardware emulato.
  • Quando si sviluppa per un hardware specifico non vi è alcun sostituto migliore del proprio hardware.
  • Occasionalmente possono esserci dei bug relativi al solo utilizzo di una VM. Nel dubbio si provi l'immagine direttamente sul proprio hardware.
  • A condizione che si possa lavorare entro questi vincoli, cercare il software disponibile per la virtualizzazione e scegliere quello adatto alle proprie necessità.

    4.4.1 Provare un'immagine ISO con QEMU

    Il programma più versatile in Debian è QEMU. Se il processore gestisce la virtualizzazione hardware utilizzare il pacchetto qemu-kvm; la descrizione elenca brevemente i requisiti.

    Per prima cosa installare qemu-kvm o altrimenti qemu, nel qual caso il nome del programma nei successivi sarà qemu invece di kvm. Il pacchetto qemu-utils è inoltre utile per creare immagini di dischi virtuali con qemu-img.

    # apt-get install qemu-kvm qemu-utils

    Avviare un'immagine ISO è semplice:

    $ kvm -cdrom binary-hybrid.iso

    Per maggiori dettagli si vedano le pagine di manuale.

    4.4.2 Provare un'immagine ISO con virtualbox-ose

    Per provare la ISO con virtualbox-ose:

    # apt-get install virtualbox-ose virtualbox-ose-dkms

    $ virtualbox

    Creare una nuova macchina virtuale, modificare le impostazione di archiviazione in modo da usare binary-hybrid.iso come dispositivo CD/DVD, e avviare la macchina.

    Nota: per sistemi live contenenti X.org che si vogliono provare con virtualbox-ose, si può voler includere il pacchetto dei driver per X.org di VirtualBox, virtualbox-ose-guest-x11, nella configurazione di live-build. In caso contrario la risoluzione è limitata a 800x600.

    $ echo virtualbox-ose-guest-x11 >> config/package-lists/my.list.chroot

    4.5 Creare un'immagine USB/HDD

    La creazione di un'immagine USB/HDD è simile alla ISO ibrida sotto tutti gli aspetti ad eccezione della necessità di specificare l'opzione -b usb-hdd e che il nome del file risultante è binary.img e non può essere masterizzato. È adatta per avviarsi da chiavette USB, dischi rigidi USB, e da svariati altri dispositivi di archiviazione portatili. In genere per questo scopo può essere usata un'immagine ISO ibrida, ma se si ha un BIOS che non supporta le immagini ibride, o si vuole usare lo spazio rimanente sul supporto per altri scopi, come una partizione persistente, allora occorre un'immagine USB/HDD.

    Nota: se si è creata un'immagine ISO ibrida con gli esempi precedenti, occorre pulire la directory di lavoro con il comando lb clean (vedere Il comando lb clean):

    # lb clean --binary

    Eseguire il comando lb config come prima, questa volta specificando però il tipo di immagine USB/HDD:

    $ lb config -b usb-hdd

    Si crei ora l'immagine con il comando lb build:

    # lb build

    Quando la costruzione è terminata dovrebbe essere presente un file binary.img nella directory corrente.

    4.6 Utilizzare un'immagine USB/HDD

    L'immagine binaria generata contiene una partizione VFAT e il bootloader syslinux, pronti per essere scritti direttamente su una penna USB. Dal momento che utilizzare un'immagine USB/HDD è come utilizzare un'immagine ISO ibrida via USB, seguire le istruzioni contenute in Utilizzare un'immagine live ISO ibrida tenendo però conto che il nome del file sarà binary.img invece di binary-hybrid.iso.

    4.6.1 Provare un'immagine USB/HDD con Qemu

    Installare QEMU come descritto in Provare un'immagine ISO con QEMU; quindi eseguire kvm o qemu, a seconda di quale versione è necessaria al sistema ospitante, specificando binary.img come disco rigido principale.

    $ kvm -hda binary.img

    4.6.2 Usare lo spazio rimanente su una penna USB

    Per utilizzare lo spazio libero che rimane dopo aver copiato il file binary.img su una penna USB, usare uno strumento di partizionamento come gparted o parted per creare una nuova partizione. La prima partizione verrà utilizzata dal sistema Debian Live.

    # gparted ${USBSTICK}

    Dopo aver creato la partizione, dove ${PARTITION} è il nome della partizione, ad esempio /dev/sdb2, si deve creare su di essa un filesystem. Una scelta possibile potrebbe essere ext4.

    # mkfs.ext4 ${PARTITION}

    Nota: se si desidera utilizzare lo spazio extra con Windows pare che questo sistema operativo non possa accedere a nessuna partizione eccetto la prima. Alcune soluzioni a questo problema sono state discusse sulla nostra mailing list, ma non sembrano esserci risposte semplici.

    Ricorda: ogni volta che si installa un nuovo file binary.img sulla penna, tutti i dati sulla chiavetta saranno persi perché la tabella delle partizioni viene sovrascritta con i contenuti dell'immagine, per cui salvare prima la propria partizione extra in modo da ripristinarla dopo l'aggiornamento dell'immagine live.

    4.7 Creare un'immagine netboot

    La seguente sequenza di comandi creerà un'immagine netboot di base contenente il sistema Debian standard senza X.org. È adatta per il boot tramite rete.

    Nota: se qualcuno tra gli esempi precedenti è stato seguito, bisogna pulire la directory di lavoro con il comando lb clean:

    # lb clean --binary

    Per configurare l'immagine per l'avvio da rete, eseguire il comando lb config come segue:

    $ lb config -b net --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"

    Diversamente dalle immagini ISO e USB/HDD, il boot via rete non fornisce un'immagine del filesytem al client, perciò i file devono essere forniti via NFS. Le opzioni net-root-path e net-root-server specificano, rispettivamente, il percorso e il server del server NFS dove l'immagine del filesystem sarà situata all'avvio. Accertarsi che questi siano impostati su valori adeguati alla propria rete.

    Si crei ora l'immagine con il comando lb build:

    # lb build

    In un avvio tramite rete, il client esegue una piccola parte di software che normalmente risiede sulla EPROM della scheda Ethernet. Questo programma invia una richiesta DHCP per ottenere un indirizzo IP e le informazioni su cosa fare in seguito. In genere il passo successivo è ottenere un bootloader di di livello superiore attraverso il protocollo TFTP. Questi potrebbe essere pxelinux, GRUB, o anche avviare direttamente un sistema operativo come Linux.

    Per esempio, estraendo l'archivio generato binary-net.tar.gz nella directory /srv/debian-live, si troverà l'immagine del filesystem in live/filesystem.squashfs mentre il kernel, initrd ed il bootloader pxelinux in tftpboot/debian-live/i386.

    Per abilitare l'avvio tramite rete vanno ora configurati tre servizi:i server DHCP, TFTP e NFS.

    4.7.1 Server DHCP

    Si deve configurare il server DHCP della rete per essere sicuri di fornire un indirizzo IP al sistema client che si avvia tramite rete, e notificare la posizione del bootloader PXE.

    Ecco un esempio, scritto per un server DHCP ISC isc-dhcp-server nel file di configurazione /etc/dhcp/dhcpd.conf:

    # /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server

    ddns-update-style none;

    option domain-name "example.org";
    option domain-name-servers ns1.example.org, ns2.example.org;

    default-lease-time 600;
    max-lease-time 7200;

    log-facility local7;

    subnet 192.168.0.0 netmask 255.255.255.0 {
       range 192.168.0.1 192.168.0.254;
       next-server servername;
       filename "pxelinux.0";
    }

    4.7.2 Server TFTP

    Fornisce al sistema il kernel e il ramdisk iniziale in fase di esecuzione.

    Si installi il pacchetto tftpd-hpa, che mette a disposizione tutti i file contenuti in una directory root, di solito /srv/tftp. Affinché si possa disporre dei file contenuti in /srv/debian-live/tftpboot, eseguire il seguente comando come utente root:

    # dpkg-reconfigure -plow tftpd-hpa

    e inserire la nuova directory del server tftp quando viene richiesto.

    4.7.3 Server NFS

    Una volta che il computer ospite ha scaricato e avviato un kernel Linux e caricato il suo initrd, cercherà di montare l'immagine del filesystem Live tramite un server NFS.

    Bisogna installare il pacchetto nfs-kernel-server.

    Quindi, rendere disponibile l'immagine del filesystem via NFS aggiungendo una riga come la seguente in /etc/exports:

    /srv/debian-live *(ro,async,no_root_squash,no_subtree_check)

    e comunicare il nuovo export al server NFS con il seguente comando:

    # exportfs -rv

    Configurare questi tre servizi può essere un po' problematico. Serve un po' di pazienza per farli funzionare assieme. Per ulteriori informazioni, si veda il wiki syslinux ‹http://syslinux.zytor.com/wiki/index.php/PXELINUX› o il manuale del Debian Installer alla sezione per l'avvio TFTP da rete ‹http://d-i.alioth.debian.org/manual/en.i386/ch04s05.html›. Ciò può essere d'aiuto, considerato che il procedimento è molto simile.

    4.7.4 Come provare una netboot

    La creazione di immagini netboot è resa semplice dal potere di live-build, ma provare le immagini su una macchina reale può essere davvero dispendioso in termini di tempo.

    Per semplificarsi la vita, si può usare la virtualizzazione. Ci sono due soluzioni.

    4.7.5 Qemu
  • Installare qemu, bridge-utils, sudo.
  • Modificare /etc/qemu-ifup:

    #!/bin/sh
    sudo -p "Password for $0:" /sbin/ifconfig $1 172.20.0.1
    echo "Executing /etc/qemu-ifup"
    echo "Bringing up $1 for bridged mode..."
    sudo /sbin/ifconfig $1 0.0.0.0 promisc up
    echo "Adding $1 to br0..."
    sudo /usr/sbin/brctl addif br0 $1
    sleep 2

    Procurarsi o compilare grub-floppy-netboot (su svn).

    Lanciare qemu con "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"

    4.7.6 VMWare Player
  • Installare VMWare Player (edizione "free as in beer")
  • Creare una directory PXETester, e crearvi all'interno un file di testo chiamato pxe.vwx
  • Vi si copi dentro questo testo:
  • #!/usr/bin/vmware
    config.version = "8"
    virtualHW.version = "4"
    memsize = "512"
    MemAllowAutoScaleDown = "FALSE"

    ide0:0.present = "FALSE"
    ide1:0.present = "FALSE"
    floppy0.present = "FALSE"
    sound.present = "FALSE"
    tools.remindInstall = "FALSE"

    ethernet0.present = "TRUE"
    ethernet0.addressType = "generated"

    displayName = "Test Boot PXE"
    guestOS = "other"

    ethernet0.generatedAddress = "00:0c:29:8d:71:3b"
    uuid.location = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
    uuid.bios = "56 4d 83 72 5c c4 de 3f-ae 9e 07 91 1d 8d 71 3b"
    ethernet0.generatedAddressOffset = "0"

  • Si può modificare a piacimento questo file di configurazione (ad esempio portando a 256 il limite della memoria)
  • Fare doppio click su questo file (o avviare il player VMWare e selezionare questo file).
  • Se viene posta qualche strana domanda durante l'esecuzione premere il tasto spazio...
  • 5. Panoramica degli strumenti

    Questo capitolo contiene una panoramica dei tre principali strumenti utilizzati nella creazione dei sistemi Debian Live: live-build, live-boot e live-config.

    5.1 live-build

    live-build è una raccolta di script, chiamati anche "comandi", usati per creare sistemi Debian Live.

    L'idea dietro live-build è di essere un'infrastruttura che utilizza una directory di configurazione per automatizzare totalmente e personalizzare tutti gli aspetti della creazione di un'immagine live.

    Molti concetti sono simili a quelli negli strumenti del pacchetto Debian debhelper scritto da Joey Hess:

  • Gli script hanno una locazione centrale per configurare le loro operazioni, in debhelper questa è la sottodirectory debian/ dell'albero di un pacchetto. Ad esempio dh_install cercherà, tra gli altri, un file chiamato debian/install per determinare quali file dovrebbero esistere in un certo pacchetto binario. Allo stesso modo, live-build salva la sua configurazione interamente in una sottodirectory config/.
  • Gli script sono indipendenti, vale a dire che è sempre sicuro eseguire ogni comando.
  • Al contrario di debhelper, live-build contiene uno strumento per generare una directory scheletro di configurazione, lb config, che può essere considerato simile a utilità come dh-make. Per maggiori informazioni su lb config si veda Il comando lb config.

    Il resto di questa sezione tratta i tre comandi più importanti:

  • lb config: responsabile dell'inizializzazione di una directory di configurazione del sistema live. Si veda Il comando lb config per maggiori informazioni.
  • lb build: responsabile di iniziare la creazione di un sistema live. Si veda Il comando lb per maggiori informazioni.
  • lb clean: responsabile della rimozione di parti della creazione di un sistema live. Si veda Il comando lb clean per maggiori informazioni.
  • 5.1.1 Il comando lb config

    Come discusso in live-build, gli script che compongono live-build attingono la loro configurazione con il comando source da una singola directory chiamata config/. Dal momento che crearla a mano sarebbe dispendioso in termini di tempo e soggetto a errori, si può usare il comando lb config per creare la directory scheletro di configurazione.

    Issuing lb config without any arguments creates a config/ subdirectory which it populates with some default settings, and a skeleton auto/ subdirectory tree.

    $ lb config
    P: Considering defaults defined in /etc/live/build.conf
    P: Creating config tree

    Using lb config without any arguments would be suitable for users who need a very basic image, or who intend to later provide a more complete configuration via auto/config (see Managing a configuration for details).

    Normalmente si vorranno specificare delle opzioni, ad esempio per includere nella propria configurazione l'elenco del pacchetto "gnome":

    $ lb config -p gnome

    È possibile specificare molte opzioni, come:

    $ lb config --binary-images net --hostname live-machine --username live-user ...

    Una lista completa delle opzioni è disponibile nel manuale di lb_config.

    5.1.2 Il comando lb build

    The lb build command reads in your configuration from the config/ directory. It then runs the lower level commands needed to build your Live system.

    5.1.3 Il comando lb clean

    È compito del comando lb clean rimuovere le varie parti di una compilazione in modo che le successive possano iniziare da uno stato pulito. Per impostazione predefinita, vengono pulite le fasi chroot, binary e source ma la cache viene lasciatta intatta. Le fasi possono inoltre essere pulite singolarmente; ad esempio se sono state fatte modifiche alla sola fase binaria, si usi lb clean --binary prima di compilare un nuovo binario. Per la lista completa delle opzioni vedere la pagina di manuale di lb_clean.

    5.2 Il pacchetto live-boot

    live-boot è una raccolta di script che forniscono hook per initramfs-tools, utilizzato per generare un initramfs in grado di avviare sistemi live, come quelli creati da live-build. Questo include le ISO di Debian Live, archivi per l'avvio da rete e immagini per penne USB.

    At boot time it will look for read-only media containing a /live/ directory where a root filesystem (often a compressed filesystem image like squashfs) is stored. If found, it will create a writable environment, using aufs, for Debian like systems to boot from.

    Si possono trovare maggiori informazioni sui ramfs iniziali nel capitolo su initramfs del Debian Linux Kernel Handbook all'indirizzo ‹http://kernel-handbook.alioth.debian.org/›.

    5.3 Il pacchetto live-config

    live-config è costituito da script eseguiti all'avvio dopo live-boot per configurare automaticamente il sistema live. Gestisce attività quali impostare l'hostname, localizzazione e fuso orario, creare l'utente live, inibire compiti automatizzati tramite cron ed eseguire il login automatico dell'utente live.

    6. Gestire una configurazione

    Questo capitolo spiega come gestire una configurazione per una live sin dalla creazione iniziale, attraverso le successive revisioni e rilasci sia del software live-build che della stessa immagine live.

    6.1 Utilizzare auto per gestire i cambiamenti di configurazione

    Le configurazioni live raramente sono perfette da riuscire al primo colpo. Servono una serie di revisioni prima di essere soddisfatti. Comunque, possono verificarsi delle incoerenze tra una revisione ed un'altra se non si presta attenzione. Il problema principale è, una volta che ad una variabile è assegnato un valore predefinito, tale valore non sarà ricalcolato da altre variabili che possono cambiare in altre revisioni.

    Per esempio, durante la messa a punto della prima distribuzione, molte variabili 'dependent' sono date dalle caratteristiche della distribuzione. Quindi, se in seguito si decide di cambiare distribuzione, quelle variabili dipendenti continueranno a mantenere i vecchi valori i quali non sono più appropriati

    Un secondo relativo problema è che se si lancia lb config e si è aggiornato live-build ad una nuova versione il quale ha cambiato il nome di una o più variabili, si può scoprire ciò solamente con una revisione manuale delle variabili nei file config/*, bisogna che vengano risistemate, di nuovo, le appropriate opzioni.

    Tutto ciò potrebbe essere un fastidio terribile se non fosse per lo script auto/*, una semplice alternativa ai comandi lb config, lb build e lb clean che sono disegnati per aiutare nella gestione della configurazione. Basta creare un semplice script auto/config che contenga il comando lb config con le opzioni desiderate, e un auot/clean che rimuova i file contenenti i valori variabili di configurazione, cosi ogni volta saranno eseguiti lb config lb clean. Questo farà si che la configurazione sia sempre coerente da una revisione all'altra o dal rilascio delle varie versioni del live-build.

    6.2 Esempi di auto script

    Usare esempi di auto script come il seguente come punto di partenza per una nuova configurazione di live-build. Prendere nota che quando si chiama il comando lb che l'auto script wraps, si deve specificare il parametro noauto per essere sicuri che l'auto script chiamato di nuovo ricorsivamente. Non dimenticare, inoltre, di rendere lo script eseguibile (es. chmod 755 auto/*).

    auto/config

    #!/bin/sh
    lb config noauto \
         --package-lists "standard" \
         "${@}"

    auto/clean

    #!/bin/sh
    lb clean noauto "${@}"
    rm -f config/binary config/bootstrap \
         config/chroot config/common config/source
    rm -f binary.log

    auto/build

    #!/bin/sh
    lb build noauto "${@}" 2>&1 | tee binary.log

    Facciamo un esempio di auto script per live-build basato sull'esempio precedente. Si possono copiare come punto di partenza.

    $ cp /usr/share/live/build/examples/auto/* auto/

    Edit auto/config, changing or adding any options as you see fit. In the example above, --package-lists standard is set to the default value. Change this to an appropriate value for your image (or delete it if you want to use the default) and add any additional options in continuation lines that follow.

    7. Panoramica sulla personalizzazione

    Questo capitolo mostra una panoramica dei vari metodi con i quali è possibile personalizzare un sistema Debian Live.

    7.1 Configurazione in fase di compilazione e di avvio

    La configurazione del sistema live è divisa in opzioni applicate in fase di compilazione e al momento dell'avvio. Le opzioni di compilazione sono ulteriormente divise in quelle che si verificano prima dell'avvio, applicate dal pacchetto live-boot, e quelle dopo l'avvio, applicate da live-config. Qualsiasi opzione in fase di avvio può essere modificata dall'utente specificandola al prompt di avvio. L'immagine può inoltre essere costruita con i parametri di avvio predefiniti in modo che quando tutti i valori predefiniti sono adatti gli utenti possano avviare direttamente il sistema senza specificare alcuna opzione. In particolare, l'argomento di lb --bootappend-live è costituito da tutte le opzioni da riga di comando del kernel predefinite in un sistema live, come persistenza dei dati, layout di tastiera o fuso orario. Per gli esempi si veda Personalizzare localizzazione e lingua.

    Le opzioni di configurazione in fase di compilazione sono descritte nel manuale di lb config, mentre quelle in fase di avvio nel manuale di live-boot e live-config. Sebbene i pacchetti live-boot e live-config siano installati nel sistema live che si sta costruendo si raccomanda, per un comodo riferimento quando si lavora alla propria configurazione, di installarli anche sul sistema che lo crea. Fare ciò risulta sicuro in quanto nessuno degli script contenuti viene eseguito, a meno che il sistema sia configurato come sistema live.

    7.2 Fasi della creazione

    Il processo di creazione è diviso in due fasi, con varie personalizzazioni applicate in sequenza a ciascuna di esse. La prima consiste nell'avvio, questa è la fase iniziale di popolamento della directory di chroot con i pacchetti atti a creare un sistema Debian di base. Viene quindi seguita dalla fase chroot che completa la costruzione della directory chroot e la popola con tutti i pacchetti elencati nella configurazione insieme a qualsiasi altro materiale; la maggior parte della personalizzazione dei contenuti avviene in questa tappa. La parte finale della preparazione dell'immagine è la fase binaria che genera un'immagine avviabile utilizzando i contenuti della directory chroot per costruire il file system pricipale per il sistema live, includere l'installatore e ogni altro materiale aggiuntivo sul supporto di destinazione al di fuori del file system del sistema live. Una volta che l'immagine è pronta viene creato, se abilitato, l'archivio dei sorgenti nella fase sorgenti.

    All'interno di ciascuna di queste fasi c'è una sequenza particolare in cui vengono applicati i comandi, sono organizzati in modo da assicurare che le personalizzazioni siano ragionevolmente stratificate. Ad esempio, nella fase chroot i preseed vengono applicati prima che qualsiasi pacchetto sia installato, i pacchetti vengono installati prima di qualsiasi file incluso localmente o le patch sono applicate e gli hook eseguiti dopo che tutto il materiale è a posto.

    7.3 Integrare la configurazione di lb con dei file

    Anche se lb config crea una configurazione scheletrica nella directory config/, per realizzare i propri obiettivi potrebbe essere necessario fornire dei file aggiuntivi nelle sottodirectory. A seconda di dove vengono memorizzati i file nella configurazione, possono essere copiati nel file system del sistema live o nel file system dell'immagine binaria, o fornire configurazioni per la creazione del sistema che sarebbe scomodo passare come opzioni da riga di comando. Si possono includere cose come elenchi personalizzati dei pacchetti, grafica personalizzata o script hook da eseguire sia al momento della compilazione che in fase di avvio; incrementando quindi la notevole flessibilità di debian-live con il proprio codice.

    7.4 Personalizzazione dei compiti

    I capitoli seguenti sono costituiti dai tipi di compito personalizzato che gli utenti eseguono solitamente: personalizzare l'installazione dei pacchetti, personalizzare i contenuti e personalizzare localizzazione e lingua coprono solo alcune delle cose che si potrebbero desiderare.

    8. Personalizzare l'installazione dei pacchetti

    Probabilmente la personalizzazione basilare di un sistema Debian Live è la scelta dei pacchetti da includere nell'immagine. Questo capitolo vi guiderà tra le varie opzioni in fase di costruzione per personalizzare l'installazione dei pacchetti di live-build. Le ampie scelte che influenzano quali pacchetti siano disponibili da installare nell'immagine sono le aree di distribuzione e archivio. Per essere sicuri di avere una ragionevole velocità di scaricamento, dovreste usare un mirror a voi vicino. Si possono inoltre aggiungere i propri repository per pacchetti di backport, sperimentali o personalizzati, o aggiungere i pacchetti direttamente come file. È possibile definire una propria lista di pacchetti da includere, usarne una predefinita di live-build, usare task di tasksel, o una combinazione di tutti e tre. Infine una serie di opzioni fornisce un certo controllo su apt, o aptitude se si preferisce, in fase di compilazione quando i pacchetti sono installati. Ciò può tornare utile se si usa un proxy, se si vuole disabilitare l'installazione dei pacchetti raccomandati per risparmiare spazio o controllare quali versioni dei pacchetti vengono installate con il pinning, giusto per citare alcune possibilità.

    8.1 Sorgenti dei pacchetti
    8.1.1 Distribuzione, le aree di archivio e le modalità

    La distribuzione che viene scelta ha un ampio impatto su quali pacchetti siano disponibili per essere inclusi nell'immagine live. Specificare il nome in codice, il predefinito per la versione Wheezy di live-build è wheezy; qualsiasi attuale distribuzione mantenuta negli archivi Debian può essere qui specificata con il suo nome in codice. (Per ulteriori dettagli consultare il Glossario). L'opzione --distribution non solo influenza la sorgente dei pacchetti nell'archivio, ma indica a live-build di comportarsi secondo la necessità per compilare ciascuna distribuzione supportata. Ad esempio se si vuole costruire un rilascio *unstable*, Sid, specificare:

    $ lb config --distribution sid

    All'interno dell'archivio dei pacchetti, le aree sono le principali divisioni dello stesso. In Debian queste sono main, contrib e non-free; soltanto main contiene il software che è parte di Debian, perciò questa è la predefinita. Possono essere specificati uno o più valori:

    $ lb config --archive-areas "main contrib"

    Attraverso l'opzione --mode è disponibile un supporto sperimentale per alcune derivate di Debian; per impostazione predefinita, questa opzione è impostata su debian, anche se si sta costruendo un sistema diverso da Debian. Se si specifica --mode ubuntu o --mode emdebian, saranno gestiti i nomi della distribuzione e le aree di archivio per la derivata specificata e non quelli di Debian. La modalità cambia anche il comportamento di live-build per adattarlo alle derivate.

    Nota: i progetti per i quali sono state aggiunte tali modalità sono i principali responsabili nel supportare gli utenti di queste opzioni. Il progetto Debian Live, a sua volta, fornisce sostegno allo sviluppo solamente sulla base dell'impegno migliore, sui feedback dei progetti derivati così come non sviluppiamo o sosteniamo queste derivate.

    8.1.2 Mirror delle distribuzioni

    The Debian archive is replicated across a large network of mirrors around the world so that people in each region can choose a nearby mirror for best download speed. Each of the --parent-mirror-* options governs which distribution mirror is used at various stages of the build. Recall from Stages of the build that the *bootstrap* stage is when the chroot is initially populated by debootstrap with a minimal system, and the *chroot* stage is when the chroot used to construct the live system's filesystem is built. Thus, the corresponding mirror switches are used for those stages, and later, in the *binary* stage, the --parent-mirror-binary and --parent-mirror-binary-security values are used, superceding any mirrors used in an earlier stage.

    8.1.3 Mirror delle distribuzioni usati in fase di compilazione

    To set the distribution mirrors used at build time to point at a local mirror, it is sufficient to set --parent-mirror-bootstrap, --parent-mirror-chroot-security and --parent-mirror-chroot-backports as follows.

    $ lb config --parent-mirror-bootstrap http://localhost/debian/ \
                 --parent-mirror-chroot-security http://localhost/debian-security/ \
          --parent-mirror-chroot-backports http://localhost/debian-backports/

    The chroot mirror, specified by --parent-mirror-chroot, defaults to the --parent-mirror-bootstrap value.

    8.1.4 Mirror delle distribuzioni usate durante l'esecuzione

    The --parent-mirror-binary* options govern the distribution mirrors placed in the binary image. These may be used to install additional packages while running the live system. The defaults employ cdn.debian.net, a service that chooses a geographically close mirror based on the user's IP number. This is a suitable choice when you cannot predict which mirror will be best for all of your users. Or you may specify your own values as shown in the example below. An image built from this configuration would only be suitable for users on a network where "mirror" is reachable.

    $ lb config --parent-mirror-binary http://mirror/debian/ \
                 --parent-mirror-binary-security http://mirror/debian-security/

    8.1.5 Repository addizionali

    You may add more repositories, broadening your package choices beyond what is available in your target distribution. These may be, for example, for backports, experimental or custom packages. To configure additional repositories, create config/archives/your-repository.list.chroot, and/or config/archives/your-repository.list.binary files. As with the --parent-mirror-* options, these govern the repositories used in the *chroot* stage when building the image, and in the *binary* stage, i.e. for use when running the live system.

    For example, config/archives/live.list.chroot allows you to install packages from the debian live snapshot repository at live system build time.

    deb http://live.debian.net/ sid-snapshots main contrib non-free

    If you add the same line to config/archives/live.list.binary, the repository will be added to your live system's /etc/apt/sources.list.d/ directory.

    Se il file esiste, saranno prelevati automaticamente.

    You should also put the GPG key used to sign the repository into config/archives/your-repository.gpg.{binary,chroot} files.

    Note: some preconfigured package repositories are available for easy selection through the --archives option, e.g. for enabling live snapshots, a simple command is enough to enable it:

    $ lb config --archives live.debian.net

    8.2 Scegliere i pacchetti da installare

    There are a number of ways to choose which packages live-build will install in your image, covering a variety of different needs. You can simply name individual packages to install in a package list. You can also choose predefined lists of packages, or use APT tasks. And finally, you may place package files in your config/ tree, which is well suited to testing of new or experimental packages before they are available from a repository.

    8.2.1 Elenchi di pacchetti

    Gli elenchi di pacchetti sono un potente mezzo per esprimere quali pacchetti devono essere installati. La sintassi gestisce file inclusi e sezioni condizionali rendendo semplice la creazione di elenchi da altri elenchi e adattarli per l'uso in molteplici configurazioni. Si può usare un elenco predefinito fornendo una selezione modulare dei pacchetti da ciascuno dei principali ambienti desktop e alcuni elenchi per uso speciale, così come elenchi standard sui quali vi si basano altri. È inoltre possibile fornire i propri elenchi o usare una combinazione di entrambi.

    Note: The behaviour of live-build when specifying a package that does not exist is determined by your choice of APT utility. See Choosing apt or aptitude for more details.

    8.2.2 Elenchi predefiniti di pacchetti

    The simplest way to use lists is to specify one or more predefined lists with the --package-lists option. For example:

    $ lb config --package-lists "gnome rescue"

    The default location for the list files on your system is /usr/share/live/build/package-lists/. To determine the packages in a given list, read the corresponding file, paying attention to included files and conditionals as described in the following sections.

    8.2.3 Elenchi locali dei pacchetti

    You may supplement the predefined lists using local package lists stored in config/package-lists/.

    Package lists that exist in this directory need to have a .list suffix in order to be processed, and then an additional stage suffix, .chroot or .binary to indicate which stage the list is for.

    Note: If you don't specify the stage suffix, the list will be used for both stages. Normally, you want to specify .list.chroot so that the packages will only be installed in the live filesystem and not have an extra copy of the .deb placed on the media.

    8.2.4 Elenchi locali di pacchetti binari

    To make a binary stage list, place a file suffixed with .list.binary in config/package-lists/. These packages are not installed in the live filesystem, but are included on the live media under pool/. You would typically use such a list with one of the non-live installer variants. As mentioned above, if you want this list to be the same as your chroot stage list, simply use the .list suffix by itself.

    8.2.5 Estendere un'elenco di pacchetti usando gli include

    The package lists that are included with live-build make extensive use of includes. Refer to these in the /usr/share/live/build/package-lists/ directory, as they serve as good examples of how to write your own lists.

    For example, to make a list that includes the predefined gnome list plus iceweasel, create config/package-lists/my.list.chroot with the following contents:

    #include <gnome>
    iceweasel

    8.2.6 Usare condizioni all'interno degli elenchi di pacchetti

    Ognuna delle variabili di configurazione di live-build situate in config/* (senza il prefisso LB_) possono essere utilizzate per istruzioni condizionali nell'elenco dei pacchetti. In genere questo significa qualsiasi opzione di lb config in maiuscolo e con trattini cambiati in trattini bassi; ma in pratica è la sola ad influenzare la selezione dei pacchetti che abbia senso, come DISTRIBUTION, ARCHITECTURE o ARCHIVE_AREAS.

    Per esempio, per installare ia32-libs se è specificata --architecture amd64:

    #if ARCHITECTURE amd64
    ia32-libs
    #endif

    Si può verificare per ognuna di una serie di valori, ad esempio per installare memtest86+ specificando sia --architecture i386 sia --architecture amd64:

    #if ARCHITECTURE i386 amd64
    memtest86+
    #endif

    È possibile provare altre variabili che contengano più di un valore, ad esempio per installare vrms specificando sia da contrib sia da non-free tramite --archive-areas:

    #if ARCHIVE_AREAS contrib non-free
    vrms
    #endif

    Una condizione può coinvolegere una direttiva #include:

    #if ARCHITECTURE amd64
    #include
    #endif

    Le condizioni nidificate non sono supportate.

    8.2.7 Task

    The Debian Installer offers the user choices of a number of preselected lists of packages, each one focused on a particular kind of system, or task a system may be used for, such as "Graphical desktop environment", "Mail server" or "Laptop". These lists are called "tasks" and are supported by APT through the "Task:" field. You can specify one or more tasks in live-build by putting them in a list in config/task-lists/, as in the example below.

    $ lb config
    $ echo "mail-server file-server" >> config/task-lists/my.list.chroot

    I task principali disponibili nell'installatore Debian possono essere elencati nel sistema live con tasksel --list-tasks. I contenuti di ogni task, inclusi quelli non inclusi in questo elenco, possono essere esaminati con tasksel --task-packages.

    8.2.8 Task per desktop e lingua

    Desktop and language tasks are special cases that need some extra planning and configuration. Live images are different from Debian Installer images in this respect. In the Debian Installer, if the medium was prepared for a particular desktop environment flavour, the corresponding task will be automatically installed. Thus, there are internal gnome-desktop, kde-desktop, lxde-desktop and xfce-desktop tasks, none of which are offered in tasksel's menu. Likewise, there are no menu entries for tasks for languages, but the user's language choice during the install influences the selection of corresponding language tasks.

    When developing a desktop live image, the image typically boots directly to a working desktop, the choices of both desktop and default language having been made at build time, not at run time as in the case of the Debian Installer. That's not to say that a live image couldn't be built to support multiple desktops or multiple languages and offer the user a choice, but that is not live-build' s default behaviour.

    Because there is no provision made automatically for language tasks, which include such things as language-specific fonts and input-method packages, if you want them, you need to specify them in your configuration. For example, a GNOME desktop image containing support for Japanese might include these tasks:

    $ lb config
    $ echo "gnome-desktop desktop standard laptop" >> config/task-lists/my.list.chroot
    $ echo "japanese japanese-desktop japanese-gnome-desktop" >> config/task-lists/my.list.chroot

    Since desktop tasks are "internal" tasks, for every desktop flavour task included in the image, the corresponding value, if it differs from the default, "gnome", must be preseeded in the "tasksel/desktop" debconf variable or else tasksel will not recognize and install it. Thus:

    $ lb config
    $ echo 'tasksel tasksel/desktop multiselect kde' >> config/preseed/my.preseed.chroot

    This parameter can take multiple values, e.g. "lxde xfce" instead of "kde".

    8.3 Installare pacchetti modificati o di terze parti

    Nonostante sia contro la filosofia di Debian Live, a volte può essere necessario creare un sistema live con versioni modificate dei pacchetti nel repository Debian. Questo per modificare o gestire funzionalità aggiuntive, lingue e marchi, o anche rimuovere elementi non desiderati da pacchetti esistenti. Allo stesso modo, i pacchetti di "terze parti" possono essere utilizzati per aggiungere funzionalità proprietarie o su misura.

    Questa sezione non tratta la compilazione e il mantenimento di pacchetti modificati. Può comunque essere interessante leggere "How to fork privately" di Joachim Breitner: ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› La creazione di pacchetti su misura è esposta nella "Guida per il nuovo Maintainer" all'indirizzo ‹http://www.debian.org/doc/maint-guide/› e altrove.

    Ci sono due modi per installare pacchetti personalizzati:

  • packages.chroot
  • Utilizzare repository APT personalizzati
  • Using packages.chroot is simpler to achieve and useful for "one-off" customizations but has a number of drawbacks, whilst using a custom APT repository is more time-consuming to set up.

    8.3.1 Using packages.chroot to install custom packages

    To install a custom package, simply copy it to the config/packages.chroot/ directory. Packages that are inside this directory will be automatically installed into the live system during build - you do not need to specify them elsewhere.

    I pacchetti devono essere nominati nel modo prescritto, un metodo semplice per farlo è usare dpkg-name.

    Using packages.chroot for installation of custom packages has disadvantages:

  • non è possibile usare secure APT
  • You must install all appropriate packages in the config/packages.chroot/ directory.
  • non si presta a salvare le configurazioni di Debian Live nel controllo di versione.
  • 8.3.2 Utilizzare un repository APT per installare pacchetti personalizzati

    Unlike using packages.chroot, when using a custom APT repository you must ensure that you specify the packages elsewhere. See Choosing packages to install for details.

    Sebbene creare un repository APT possa sembrare uno sforzo inutile, l'infrastruttura può facilmente essere riutilizzata in un secondo momento per offrire aggiornamenti dei pacchetti modificati.

    8.3.3 Pacchetti personalizzati e APT

    live-build utilizza APT per installare tutti i pacchetti nel sistema live in modo da ereditare i comportamenti di questo programma. Un esempio rilevante è che (considerando una configurazione predefinita) dato un pacchetto disponibile in due repository differenti con numeri di versione diversi, APT sceglie di installare quello con il numero di versione più alto.

    A causa di questo si può voler incrementare il numero della versione nei file debian/changelog dei pacchetti personalizzati per accertare che la propria versione avrà la precedenza sui repository Debian ufficiali. È anche ottenibile modificando le preferenze del APT pinning del sistema live, si veda APT pinning per maggiori informazioni.

    8.4 Configurare APT in fase di costruzione

    You can configure APT through a number of options applied only at build time. (APT configuration used in the running live system may be configured in the normal way for live system contents, that is, by including the appropriate configurations through config/includes.chroot/.) For a complete list, look for options starting with apt in the lb_config man page.

    8.4.1 Scegliere apt o aptitude

    Per installare pacchetti in fase di compilazione si può optare sia per apt sia per aptitude, l'argomento --apt di lb config determina quale usare. Sceglie il metodo implementando il comportamento preferito per l'installazione dei pacchetti, la notevole differenza è come vengono gestiti quelli mancanti.

  • apt: se viene specificato un pacchetto mancante, l'installazione avrà esito negativo; questo è l'impostazine predefinita.
  • aptitude: se viene specificato un pacchetto mancante, l'installazione avrà successo.
  • 8.4.2 Utilizzare un proxy con APT

    Una configurazione di APT spesso richiesta è di amministrare la creazione di un'immagine dietro un proxy, lo si può specificare con le opzioni --apt-ftp-proxy o --apt-http-proxy secondo necessità:

    $ lb config --apt-http-proxy http://proxy/

    8.4.3 Modificare APT per risparmiare spazio

    Si può aver bisogno di risparmiare dello spazio sul supporto dell'immagine, in tal caso una o entrambe delle seguenti opzioni possono essere d'interesse.

    È possibile non includere gli indici di APT con:

    $ lb config --apt-indices false

    Questo non influenzerà le voci in /etc/apt/sources.list, determina solo se /var/lib/apt contiene o meno i file degli indici. Il compromesso è che APT necessita di quegli indici per operar enel sistema live, perciò prima di eseguire apt-cache search o apt-get install, per esempio, l'utente deve usare prima apt-get update per crearli.

    In caso si trovi che l'installazione dei pacchetti raccomandati appesantisca troppo l'immagine, si può disabilitare l'opzione predefinita di APT con:

    $ lb config --apt-recommends false

    Qui il compromesso è dato dal fatto che se non si installano i raccomandati per un certo pacchetto, ovvero "pacchetti che si trovano assieme a questo eccetto in installazioni non usuali" (Debian Policy Manual, paragrafo 7.2), saranno omessi alcuni di quelli realmente necessari. Si suggerisce pertanto di verificare la differenza ottenuta nel proprio elenco di pacchetti disabilitando i raccomandati (vedere il file binary.packages generato da lb build) e includere nuovamente in esso quelli omessi che si desiderano installare. In alternativa, se si desidera lasciare un modesto numero di raccomandati, li si lasci abilitati e si assegni ad APT un pin di priorità negativo sui pacchetti selezionati affinché non vengano installati, come spiegato in APT pinning.

    8.4.4 Passare opzioni ad apt o aptitude

    Se non c'è un'opzione di lb config per modificare il comportamento di APT nel modo desiderato, si usi --apt-options o --aptitude-options per passare opzioni tramite il proprio strumento APT. Consultare il manuale di apt e aptitude per i dettagli.

    8.4.5 APT pinning

    For background, please first read the apt_preferences(5) man page. APT pinning can be configured either for build time, or else for run time. For the former, create config/chroot_apt/preferences. For the latter, create config/includes.chroot/etc/apt/preferences.

    Nell'ipotesi di creare un sistema live Wheezy e avendo la necessità di installare da Sid tutti i pacchetti live destinati all'immagine binaria questa fase, bisogna aggiungere Sid alle fonti di APT e farne il pinning affinché verranno installati da lì solo i pacchetti voluti, mentre per tutti gli altri si attingerà dalla distribuzione principale, Wheezy. Quanto segue servirà allo scopo:

    $ echo "deb http://mirror/debian sid main" > config/archives/sid.list.chroot
    $ cat >> config/chroot_apt/preferences < Package: live-boot live-boot-initramfs-tools live-config live-config-sysvinit
    Pin: release n=sid
    Pin-Priority: 600

    Package: *
    Pin: release n=sid
    Pin-Priority: 1
    END

    Nota: con la versione 0.8.14 o superiore di Apt si possono utilizzare wildcard nei nomi dei pacchetti (Package: live-*). Ciò significa che funziona con Wheezy usando:

    $ lb config --distribution wheezy

    Negative pin priorities will prevent a package from being installed, as in the case where you do not want a package that is recommended by another package. Suppose you are building an LXDE image using --package-lists lxde option, but don't want the user prompted to store wifi passwords in the keyring. This list includes gdm, which depends on gksu, which in turn recommends gnome-keyring. So you want to omit the recommended gnome-keyring package. This can be done by adding the following stanza to config/chroot_apt/preferences:

    Package: gnome-keyring
    Pin: version *
    Pin-Priority: -1

    9. Personalizzazione dei contenuti

    Questo capitolo tratta la personalizzazione dei contenuti del sistema live che va oltre la semplice scelta dei pacchetti da includere. Gli include permettono di aggiungere o sostituire file nell'immagine di Debian Live, gli hook permettono di eseguire comandi in fasi differenti della creazione e all'avvio, e la preconfigurazione permette di configurare i pacchetti quando vengono installati fornendo risposte alle domande di debconf.

    9.1 Include

    Anche se idealmente un sistema live Debian dovrebbe includere file forniti interamente dal pacchetti Debian non modificati, a volte è conveniente fornire o modificare parte del contenuto per mezzo di file. Utilizzando gli include, si può aggiungere (o sostituire) file arbitrari nell'immagine di Debian Live. Per usarli, live-build mette a disposizione tre meccanismi:

  • Include locali del chroot: permettono di aggiungere o sostituire file al file system chroot/Live. Vedere Live/chroot include locali per maggiori informazioni.
  • Include locali binari: permettono di aggiungere o sostituire file nell'immagine binaria. Vedere Include locali binari per maggiori informazioni
  • Include binari: permettono di aggiungere o sostituire specifici file Debian nell'immagine binaria, come le directory dei template e dei tool. Vedere Include binari per maggiori informazioni.
  • Si consulti il Glossario per ulteriori informazioni sulla distinzione tra immagini "Live" e "binarie".

    9.1.1 Live/chroot include locali

    Gli include locali del chroot possono essere usati per aggiungere o sostituire file nel filesystem chroot/Live in modo che possano essere utilizzati nel sistema live. Un utilizzo tipico è popolare la directory scheletro dell'utente (/etc/skel) che il sistema impiega per creare la home dell'utente. Un altro è quello di fornire file di configurazione che possono essere semplicemente aggiunti o sostituiti nell'immagine senza elaborazione; si veda Live/chroot hook locali se è necessaria l'elaborazione.

    To include files, simply add them to your config/includes.chroot directory. This directory corresponds to the root directory (/) of the live system. For example, to add a file /var/www/index.html in the live system, use:

    $ mkdir -p config/includes.chroot/var/www
    $ cp /path/to/my/index.html config/includes.chroot/var/www

    La configurazione avrà quindi il seguente schema:

    -- config
        [...]
         |-- includes.chroot
         |   `-- var
         |       `-- www
         |           `-- index.html
        [...]
         `-- templates

    Gli include locali del chroot vengono installati dopo l'installazione dei pacchetti in modo che tali file vengano in seguito sovrascitti.

    9.1.2 Include locali binari

    To include material such as documentation or videos on the media filesystem so that it is accessible immediately upon insertion of the media without booting the Live system, you can use binary local includes. This works in a similar fashion to chroot local includes. For example, suppose the files ~/video_demo.* are demo videos of the live system described by and linked to by an HTML index page. Simply copy the material to config/includes.binary/ as follows:

    $ cp ~/video_demo.* config/includes.binary/

    Questi file appariranno nella directory principale del supporto live.

    9.1.3 Include binari

    live-build ha alcuni file standard (come la documentazione) inclusi nella configurazione predefinita di ogni supporto live. Ciò può essere disabilitato con:

    $ lb config --includes none

    In caso contrario il materiale verrà installato da live-build nella directory /includes/ del filesystem in modo predefinito, oppure è possibile specificare un percorso alternativo con --includes.

    9.2 Hook

    Gli hook permettono di eseguire comandi nel chroot e nelle fasi binarie della creazione al fine di personalizzare l'immagine.

    9.2.1 Live/chroot hook locali

    To run commands in the chroot stage, create a hook script with a .chroot suffix containing the commands in the config/hooks/ directory. The hook will run in the chroot after the rest of your chroot configuration has been applied, so remember to ensure your configuration includes all packages and files your hook needs in order to run. See the example chroot hook scripts for various common chroot customization tasks provided in /usr/share/live/build/examples/hooks which you can copy or symlink to use them in your own configuration.

    9.2.2 Hook in fase di avvio

    To execute commands at boot time, you can supply live-config hooks as explained in the "Customization" section of its man page. Examine live-config' s own hooks provided in /lib/live/config/, noting the sequence numbers. Then provide your own hook prefixed with an appropriate sequence number, either as a chroot local include in config/includes.chroot/lib/live/config/, or as a custom package as discussed in Installing modified or third-party packages.

    9.2.3 Hook binari locali

    To run commands in the binary stage, create a hook script with a .binary suffix containing the commands in the config/hooks/ directory. The hook will run after all other binary commands are run, but before binary_checksums, the very last binary command. The commands in your hook do not run in the chroot, so take care to not modify any files outside of the build tree, or you may damage your build system! See the example binary hook scripts for various common binary customization tasks provided in /usr/share/live/build/examples/hooks which you can copy or symlink to use them in your own configuration.

    9.3 Preconfigurare le domande di Debconf

    Files in the config/preseed/ directory suffixed with .preseed followed by the stage (.chroot or .binary) are considered to be debconf preseed files and are installed by live-build using debconf-set-selections during the corresponding stage.

    Per ulteriori informazioni su debconf, vedere debconf(7) nel pacchetto debconf.

    10. Personalizzare i comportamenti durante l'esecuzione

    Tutte le configurazioni durante l'esecuzione sono eseguite da live-config. Vengono qui presentate alcune delle opzioni di live-config più comuni alle quali gli utenti sono interessati; una lista completa può essere trovata nel suo manuale.

    10.1 Personalizzare l'utente live

    Un'importante considerazione è che l'utente live viene creato all'avvio da live-boot e non da live-build durante la compilazione. Questo non solo influenza dove viene introdotto il materiale relativo all'utente nella creazione, come discusso in Live/chroot include locali, ma anche ogni gruppo e permesso associato all'utente live.

    You can specify additional groups that the live user will belong to by preseeding the passwd/user-default-groups debconf value. For example, to add the live user to the fuse group, add the following preseed under config/preseed/ for the chroot stage:

    $ lb config
    $ echo user-setup passwd/user-default-groups string audio cdrom \
       dip floppy video plugdev netdev powerdev scanner bluetooth fuse \
       >> config/preseed/my.preseed.chroot

    It is also possible to change the default username "user" and the default password "live". If you want to do that for any reason, you can easily achieve it as follows:

    To change the default username you can simply specify it in your config:

    $ lb config --bootappend-live "username=live-user"

    One possible way of changing the default password is by means of a hook as described in Boot-time hooks. In order to do that you can use the "passwd" hook from /usr/share/doc/live-config/examples/hooks, prefix it accordingly (e.g. 200-passwd) and add it to config/includes.chroot/lib/live/config/

    10.2 Personalizzare la localizzazione e la lingua

    Quando il sistema live si avvia, la lingua è inserita in tre fasi:

  • generazione della localizzazione
  • impostazione del layout di tastiera per la console
  • impostazione del layout di tastiera per X

    Quando si crea un sistema live la localizzazione predefinita è "locales=en_US.UTF-8". Per definire quale generare, si usi il parametro locales nell'opzione --bootappend-live di lb config:

    $ lb config --bootappend-live "locales=de_CH.UTF-8"

    Questo parametro può inoltre essere usato dalla riga di comando del kernel, specificando una localizzazione nella forma lingua_nazione.codifica.

    Sia la configurazione della tastiera in console sia di X dipendono dal parametro keyboard-layouts dell'opzione --bootappend-live. Si possono trovare le opzioni valide per i layout di X in /usr/share/X11/xkb/rules/base.xml (piuttosto che limitate alle due lettere del codice della nazione); per trovare il valore (i due caratteri) corrispondenti alla lingua, si cerchi con il nome inglese della nazione in cui si parla tale lingua:

    $ grep -i sweden -C3 /usr/share/X11/xkb/rules/base.xml | grep name
    <name>se</name>

    Per ottenere i file di localizzazione per il layout di tastiera tedesco e svizzero-tedesco in X:

    $ lb config --bootappend-live "locales=de_CH.UTF-8 keyboard-layouts=ch"

    Si può ottenere un elenco di valori validi della tastiera per la console con il seguente comando:

    $ for i in $(find /usr/share/keymaps/ -iname "*kmap.gz"); \
         do basename $i | head -c -9; echo; done | sort | less

    In alternativa è possibile utilizzare il pacchetto console-setup, uno strumento per configurare il layout della console tramite le definizioni di X (XKB); si può dunque impostare il layout in modo più preciso con le variabili keyboard-layouts, keyboard-variant, keyboard-options e keyboard-model; live-boot userà questi parametri anche per X. Ad esempio, per impostare un layout French-Dvorak (chiamato Bepo) su un sistema francese con una tastiera TypeMatrix, sia in console sia in X11:

    $ lb config --bootappend-live \
         "locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variant=bepo keyboard-model=tm2030usb"

    10.3 Persistenza

    Uno dei paradigmi di un cd live è un sistema preinstallato eseguito da un supporto in sola lettura, come un cdrom, dove le modifiche non sopravvivono ai riavvii dell'hardware della macchina ospitante.

    Un sistema Debian Live è una generalizzazione di questo paradigma e di conseguenza oltre ai CD gestisce altri supporti; ma comunque, nel suo comportamento predefinito, deve essere considerato in sola lettura e tutte i cambiamenti fatti durante l'esecuzione del sistema verranno persi allo spegnimento.

    Persistenza è il nome comune per differenti tipi di soluzioni per salvare alcune o tutte queste modifiche con i riavii. Per capire come funziona potrebbe essere utile sapere che sebbene il sistema venga avviato ed eseguito da un dispositivo in sola lettura, le modifiche a file e directory vengono scritte su uno scrivibile, tipicamente un ram disk (tmpfs) e i dati sui ram disk non sopravvivono ai riavvii.

    I dati immagazzinati su questo ramdisk andrebbero salvati un supporto scrivibile persistente come un hard disk, una chiave USB, una condivisione di rete o anche una sessione di un CD/DVD riscrivibile multisessione. Tutti questi supporti sono gestiti in Debian Live in modi differenti, e tutti tranne l'ultimo richiedono un parametro d'avvio speciale da specificare all'avvio: persistent.

    10.3.1 Persistenza completa

    Con "persistenza completa" si intende l'uso di una partizione scrivibile invece di un filesystem temporaneo (tmpfs) per salvare le modifiche al supporto in sola lettura (con il sistema COW, copy-on-write). Per utilizzare questa caratteristica, una partizione con un filesystem scrivibile e supportato ed etichettata come "live-rw" deve essere collegata al sistema in fase di avvio e il sistema va fatto partire con il parametro "persistent". Questa partizione potrebbe essere di tipo ext2 su un hard disk o una penna usb creata ad esempio con:

    # mkfs.ext2 -L live-rw /dev/sdb1

    Si veda anche Usare lo spazio rimanente su una penna USB.

    Se si possiede già una partizione sul dispositivo basta solo cambiare l'etichetta con una delle seguenti:

    # tune2fs -L live-rw /dev/sdb1 # for ext2,3,4 filesystems

    Ma siccome gli utenti dei sistemi live non hanno sempre la possibilità di utilizzare una partizione su disco rigido, e considerando che la maggior parte delle chiavi USB hanno scarse velocità di scrittura, la persistenza "completa" può anche essere usata con dei file immagine, è possibile creare un file che rappresenta una partizione e inserire questo file immagine anche su una partizione NTFS di un sistema operativo estraneo, qualcosa come:

    $ dd if=/dev/null of=live-rw bs=1G seek=1 # for a 1GB sized image file
    $ /sbin/mkfs.ext2 -F live-rw

    Quindi copiare il file live-rw su una partizione scrivibile e riavviare con il parametro d'avvio "persistent".

    10.3.2 Mount automatico della home

    Se durante l'avvio viene trovata una partizione (filesystem) su file immagine o una partizione etichettata come home-rw, questa verrà montata direttamente come /home, permettendo quindi la persistenza dei file che appartengono ad esempio all'utente predefinito. Può essere unita alla persistenza completa.

    10.3.3 Istantanee

    Le istantanee sono raccolte di file e directory che non vengono montate durante l'esecuzione ma copiate all'avvio da un dispositivo persistente al sistema (tmpfs) e risincronizzate al riavvio e spegnimento. Il contenuto di un'istantanea può risiedere su una partizione o file immagine (come i tipi menzionati poc'anzi) etichettati come live-sn, ma sotto forma di un semplice archivio cpio nominato live-sn.cpio.gz. Come sopra, all'avvio, i device a blocchi collegati al sistema vengono analizzati alla ricerca di una partizione o file così nominati. Un'interruzione di corrente durante l'esecuzione potrebbe portare ad una perdita di dati, per cui si può usare uno strumento che richiama live-snapshot --refresh per sincronizzare i cambiamenti importanti. Giacché non scrive continuamente sul dispositivo, questo tipo di persistenza è il sistema più comodo e veloce per dispositivi basati su memoria flash.

    Esiste anche un'istantanea della /home con etichetta home-sn.*; funziona come la principale ma viene applicata solo ad /home.

    Attualmente le istantanee non possono gestire la cancellazione dei file, al contrario della persistenza completa e il mount automatico della home.

    10.3.4 Sottotesto persistente

    Se un utente avesse bisogno di archiviazioni multiple dello stesso tipo per differenti posti o per test, come live-rw-casa e live-rw-lavoro, il parametro d'avvio persistent-subtext usato in congiunzione con persistent permetterà supporti persistenti multipli ma univoci. Un esempio potrebbe essere un utente che vuole usare una partizione etichettata come live-sn-sottotesto, userebbe: persistent persistent-subtext=sottotesto.

    10.3.5 Rimasterizzazione parziale

    Le modifiche in fase di esecuzione del tmpfs possono essere incluse in uno squashfs usando live-snapshot e aggiunte al cd per rimasterizzare la iso nel caso di un cd riscrivibile o aggiunto ad una sessione di un cd/dvd(rw) multisessione; live-boot monta tutti i filesystem /live in ordine o con il modulo del parametro d'avvio.

    11. Personalizzare l'immagine binaria

    11.1 Bootloader

    live-build usa syslinux come bootloader predefinito, il quale è configurato per restare in pausa continua sulla schermata d'avvio. Per cambiare questo comportamento, si passi --syslinux-timeout TIMEOUT a lb config. Questo valore è espresso in secondi, 0 (zero) disabilita completamente il tempo di attesa. Per maggiori informazioni vedere syslinux(1).

    11.2 Metadati ISO

    Quando si crea un'immagine binaria ISO9660, si possono usare le seguenti opzioni per aggiungere vari metadati testuali. Questo può aiutare a identificare facilmente la versione o la configurazione di un'immagine senza avviarla.

  • LB_ISO_APPLICATION/--iso-application NAME: descrive l'applicazione che sarà nell'immagine. La lunghezza massima per questo campo è di 128 caratteri.
  • * LB_ISO_PREPARER/--iso-preparer NAME: descrive il costruttore dell'mmagine, solitamente con alcuni dettagli per contattarlo. L'impostazione predefinita è la versione di live-build che si sta usando, il quale potrà essere utile in seguito per il debugging. La lunghezza massima per questo campo è di 128 caratteri.

  • LB_ISO_PUBLISHER/--iso-publisher NAME: descrive l'editore dell'immagine, solitamente con qualche dettaglio per contattarlo. La lunghezza massima lunghezza per questo campo è di 128 caratteri.
  • LB_ISO_VOLUME/--iso-volume NAME: specifica l'ID del volume dell'immagine. Questa è utilizzata come etichetta visibile all'utente su alcune piattaforme, come Windows e Apple Mac OS. La lunghezza massima per questo campo è di 128 caratteri.
  • 12. Personalizzare il Debian Installer

    Le immagini del sistema Debian Live possono essere integrate nel Debian Installer. Ci sono differenti tipi d'installazione che variano in cosa viene incluso e come agisce l'installatore.

    In questa sezione si presti attenzione all'uso delle lettere maiuscole quando si fa riferimento al "Debian Installer" - quando usato ci si riferisce all'installatore ufficiale Debian, niente altro. Spesso è abbreviato come "d-i".

    12.1 Tipologie del Debian Installer

    I tre principali tipi dell'installer sono:

    Debian Installer "normale": questa è un'immagine Debian Live con un kernel e un initrd separati i quali (quando viene selezionato da un appropriato bootloader) lancia un'istanza standard del Debian Installer, così come quando si scarica un'immagine di Debian e la si avvia. Le immagini che contengono un sistema live e un installatore indipendenti sono spesso definite "immagini combinate".

    In queste immagini, Debian è installata prendendo e installando pacchetti .deb usando ⌠debootstrap⌡# o cdebootstrap da supporti locali o dalla rete, risultante in un sistema Debian standard che viene installato sul disco rigido.

    L'intero processo può essere preimpostato e personalizzato in diversi modi; per ulteriori informazioni si vedano le corrispondenti pagine del manuale del Debian Installer. Una volta che si ha un file preimpostato che funzioni, live-build può inserirlo automaticamente nell'immagine e abilitarlo.

    Debian Installer "live": Questa è un'immagine Debian Live con un kernel ed un initrd separato (quando selezionato dall'appropriato bootloader) lanciata in un'instanza del Debian Installer.

    L'installazione procederà nello stesso modo di un'installazione "Regolare" come descritto sopra, ma allo stadio attuale dell'installazione del pacchetto, invece di usare debootstrap per prelevare e installare i pacchetti, l'immagine del filesystem live viene copiata sulla destinazione. Questo si ottiene con uno speciale udeb chiamato live-installer.

    Dopo questa fase, il Debian Installer continua normalmente, installando e configurando elementi come bootloader e utenti locali, ecc.

    Si noti: per supportare entrambi le voci dell'installer live o normale nel bootloader sullo stesso media, si deve disabilitare il live-installer dalla preconfigurazione live-installer/enable=false.

    Debian Installer "Desktop": indipendentemente dal tipo del Debian Installer incluso, d-i può essere lanciato cliccando un'icona sul desktop, Questo è molto semplice in alcune situazioni. Per poterne usufruire deve essere incluso il pacchetto debian-installer-launcher.

    Si noti che live-build non include il Debian Installer nell'immagine in modo predefinito, bisogna che sia espressamente abilitato con lb config.Inoltre, affinché l'installatore "Desktop" funzioni, il kernel del sistema live deve corrispondere a quello usato dal d-i per l'architettura specificata. Per esempio:

    $ lb config --architecture i386 --linux-flavours 486 \
         --debian-installer live
    $ echo debian-installer-launcher >> config/package-lists/my.list.chroot

    12.2 Personalizzare il Debian Installer con la preconfigurazione

    Come descritto nell'appendice B del manuale del Debian Installer all'indirizzo ‹http://www.debian.org/releases/stable/i386/apb.html›, "La preconfigurazione fornisce un modo per impostare le risposte alle domande poste durante il processo d'installazione senza la necessità di inserirle manualmente. Ciò permette di automatizzare totalmente molti tipi di installazione offrendo anche alcune caratteristiche normalmente non disponibili." Questo tipo di personalizzazione è compiuta in modo ottimale con live-build mettendo la configurazione in un file preseed.cfg incluso in config/binary_debian-installer/. Ad esempio per preconfigurare l'impostazione della localizzazione su en_US:

    $ echo "d-i debian-installer/locale string en_US" \
         >> config/binary_debian-installer/preseed.cfg

    12.3 Personalizzare il contenuto del Debian Installer

    For experimental or debugging purposes, you might want to include locally built d-i component udeb packages. Place these in config/packages.binary/ to include them in the image. Additional or replacement files and directories may be included in the installer initrd as well, in a similar fashion to Live/chroot local includes, by placing the material in config/binary_debian-installer-includes/.

    Progetto

    13. Segnalare bug

    Debian Live è lungi dall'essere perfetta, ma con il vostro aiuto vogliamo avvicinarci il più possibile a questo livello. Non esitare a segnalare un bug: è meglio compilare un rapporto due volte che mai. Questo capitolo include alcune raccomandazioni su come presentare una buona segnalazione.

    Per gli impazienti

  • Per i problemi noti verificare sempre lo stato degli aggiornamenti dell'immagine sulla nostra pagina iniziale ‹http://live.debian.net/›.
  • Prima di inviare una segnalazione di bug provare a riprodurlo con le versione più recenti di live-build, live-boot e live-config.
  • Si cerchi di fornire informazioni il più dettagliate possibile riguardo il bug. Questo comprende (almeno) la versione di live-build, live-boot e live-config utilizzata e la distribuzione del sistema live che si sta costruendo.
  • 13.1 Problemi noti

    Giacché Debian testing e Debian unstable subiscono cambiamenti continui, quando si specifica l'una o l'altra come sistema di destinazione, può non essere sempre possibile una creazione che vada a buon fine.

    Se questo causa troppe difficoltà, non creare un sistema basato su testing o unstable ma usare piuttosto stable. live-build si basa su stable in modo predefinito.

    I problemi noti al momento sono elencati sotto la sezione "status" della nostra pagina iniziale ‹http://live.debian.net/

    Questo manuale non intende insegnare come identificare e risolvere correttamente i problemi dei pacchetti delle distribuzioni di sviluppo, tuttavia ci sono un paio di cose da provare: se la creazione di testing non va a buon fine provare con unstable; se non funziona nemmeno unstable tornare a testing ed effettuare il pinning da unstable alla nuova versione del pacchetto corrotto (si veda APT pinning per i dettagli).

    13.2 Ricostruire da zero

    Per essere certi che un particolare bug non sia causato dalla creazione di un sistema non pulito, ricostruire sempre l'intero sistema da zero per vedere se il bug sia riproducibile.

    13.3 Usare pacchetti aggiornati

    L'utilizzo di pacchetti datati può causare notevoli complicazioni nel tentativo di riprodurre (e alla fine risolvere) il problema. Assicurarsi che il sistema creato sia aggiornato e ogni pacchetto incluso nell'immagine lo sia a sua volta.

    13.4 Raccogliere informazioni

    Nella segnalazione si invita a fornire informazioni sufficienti. Dovrebbe almeno contenere l'esatta versione di live-build nella quale si è trovato il bug e i passi per riprodurlo. Con un po' di buon senso si può includere qualsiasi altro dettaglio rilevante che si ritiene utile per la risoluzione del problema.

    Affinché la segnalazione del bug sia migliore possibile, si richiedono almeno le seguenti informazioni:

  • Architettura del sistema ospitante
  • Versione di live-build sul sistema ospitante
  • Versione di live-boot sul sistema ospitante
  • Versione di live-config sul sistema live
  • Versione di debootstrap o cdebootstrap sul sistema ospitante
  • Architettura del sistema live
  • Distribuzione del sistema live
  • Versione del kernel sul sistema live
  • È possibile generare un registro del processo di costruzione usando il comando tee. Si raccomanda di farlo automaticamente con uno script auto/build; (si veda Gestire una configurazione per i dettagli).

    # lb build 2>&1 | tee build.log

    All'avvio, live-boot conserva un registro in /var/log/live.log (or /var/log/live-boot.log).

    Inoltre, per escludere altri errori, è sempre una buona idea creare un tar della propria directory config/ e caricarlo da qualche parte (non inviarlo come allegato alla mailing list), in modo che sia per noi possibile riprodurre gli errori incontrati. Se ciò causa problemi (ad esempio a causa della dimensione) si può utilizzare l'output di lb config --dump che produce un sommario dell'albero di configurazione (elenca i file nelle sottodirectory di config/ ma non le include).

    Ricordarsi che i file di registro da inviare vanno creati con l'impostazione della lingua inglese, ad esempio eseguendo il comando live-build preponendo LC_ALL=C oppure LC_ALL=en_US.

    13.5 Se possibile isolare il caso non andato a buon fine

    Se possibile, isolare il caso non andato a buon fine alla variazione più piccola che lo causa. Non è sempre facile da fare, perciò non preoccupatevi se non riuscite a gestirlo per la vostra segnalazione. Tuttavia, se si pianifica bene il ciclo di sviluppo adottando piccole modifiche per ogni iterazione, si riuscirà ad isolare il problema creando una configurazione semplificata che si avvicina all'attuale con l'aggiunta delle sole modifiche problematiche. Se si incontrano serie difficoltà nel trovare la causa, potrebbe essere che sono stati inseriti troppi cambiamenti in una sola volta e bisogna cambiare approccio.

    13.6 Segnalare il bug del pacchetto giusto

    Dove appare il bug?

    13.6.1 Durante la compilazione mentre esegue il bootstrap

    live-build avvia inizialmente un sistema Debian di base con debootstrap o cdebootstrap; può fallire a seconda dello strumento utilizzato e della distribuzione Debian che si sta avviando. Se il bug appare a questo punto controllare che l'errore sia relativo ad uno specifico pacchetto Debian (più probabile) o allo strumento di avvio stesso.

    In entrambi i casi non è un bug in Debian Live, ma piuttosto in Debian stessa che non può essere risolto direttamente. Si prega di inviare una segnalazione di bug riguardo l'utilità di avvio o il pacchetto che ha fallito.

    13.6.2 Durante la compilazione mentre installa i pacchetti

    live-build installa pacchetti aggiuntivi dall'archivio Debian e può fallire a seconda della distribuzione Debian e lo stato dell'archivio giornaliero.Se il bug appare a questo punto, controllare che l'errore sia riproducibile su un sistema normale.

    In questo caso non è un bug in Debian Live, ma piuttosto in Debian, inviare una segnalazione sul pacchetto che ha fallito. Si otterranno maggiori informazioni eseguendo debootstrap separatamente dal sistema live o eseguendo lb bootstrap --debug.

    Se si verifica un problema utilizzando un mirror locale o un qualsiasi tipo di proxy è bene riprodurlo avviando da un mirror ufficiale.

    13.6.3 In fase di avvio

    Se l'immagine non si avvia segnalarlo alla mailing list con le informazioni richieste in Raccogliere informazioni. Non dimenticare di menzionare come e quando l'immagine fallisce, in Qemu, VMWare o hardware reale. Se si utilizza un qualsiasi sistema di virtualizzazione provare sempre su hardware reale prima di segnalare un bug; anche fornire un'istantanea dello schermo può essere molto utile.

    13.6.4 In fase di esecuzione

    Se un pacchetto è stato installato con successo ma fallisce durante l'esecuzione del sistema live, si tratta probabilmente di un bug in Debian Live. Tuttavia,

    13.7 Fare la ricerca

    Prima di riportare il bug si prega di cercare sul web il messaggio d'errore o il sintomo ottenuti. Poiché è altamente improbabile essere l'unica persona ad incontrare un certo problema, c'è sempre la possibilità che sia stato discusso altrove e che siano stati proposte una soluzione, una patch o soluzione temporanea.

    Si dovrebbe prestare particolare attenzione alla mailing list di Debian Live così come la pagina iniziale del sito, in quanto contengono informazioni più aggiornate. Se tale informazione esiste si includa sempre un riferimento nella segnalazione del bug.

    In aggiunta bisogna controllare l'attuale elenco dei bug riguardanti live-build, live-boot e live-config per vedere se sia già stato segnalato qualcosa di simile.

    13.8 Dove segnalare i bug

    Il progetto Debian Live tiene traccia di tutti i bug sul Debian Bug Tracking System (BTS, sistema di tracciamento dei bug Debian), si veda ‹http://bugs.debian.org/› per le informazioni su come usarlo. È anche possibile utilizzare il comando reportbug dall'omonimo pacchetto.

    In genere bisogna riportare gli errori in fase di compilazione verso il pacchetto live-build, quelli di avvio verso live-boot e quelli in fase di esecuzione a live-config. Se non siete certi di quale sia il pacchetto appropriato o serve maggiore aiuto prima della segnalazione, inviate un messaggio in mailing list e vi aiuteremo a capire.

    Si noti che i bug trovati nelle distribuzioni derivate da Debian (come Ubuntu e altre) non vanno segnalati a Debian BTS a meno che non siano riproducibili anche su un sistema Debian utilizzando pacchetti ufficiali Debian.

    14. Lo stile nello scrivere codice

    Questo capitolo documenta lo stile usato per il codice di live-boot e gli altri.

    14.1 Compatibilità
  • Non usare sintassi o semantiche mirate alla shell Bash. Ad esempio, l'uso di costrutti array.
  • Utilizzare solo il sottoinsieme POSIX - ad esempio, usare $(foo) invece di `foo`.
  • È possibile verificare i propri script con "sh -n" e "checkbashisms".
  • 14.2 Rientri
  • Usare sempre i tab piuttosto che gli spazi.
  • 14.3 Ritorno a capo
  • Generalmente le righe sono composte da un massimo di 80 caratteri.
  • Utilizzare lo "stile Linux" per le interruzioni di riga:
  • Sbagliato:

    if foo; then
             bar
    fi

    Corretto:

    if foo
    then
             bar
    fi

  • Lo stesso vale per le funzioni:
  • Sbagliato:

    foo () {
             bar
    }

    Corretto:

    foo ()
    {
             bar
    }

    14.4 Variabili
  • Le variabili vanno sempre scritte in maiuscolo.
  • Le variabili usate in lb config iniziano sempre con il prefisso LB_.
  • Le variabili interne temporanee in live-build dovrebbero iniziare con il prefisso _LB_.
  • Le variabili locali iniziano con il prefisso live-build __LB_.
  • Le variabili in live-config relative ai parametri di avvio iniziano con LIVE_.
  • Tutte le altre variabili in live-config iniziano con il prefisso _.
  • Intorno alle variabili utilizzare le graffe; ad esempio scrivere ${FOO} invece di $FOO.
  • Proteggere sempre le variabili con le virgolette per rispettare potenziali spaziature: scrivere "${FOO}" e non ${FOO}.
  • Per ragioni di coerenza, usare sempre le virgolette quando si assegnano valori alle variabili:
  • Sbagliato:

    FOO=bar

    Corretto:

    FOO="bar"

  • Utilizzando variabili multiple, quotare l'intera espressione:
  • Sbagliato:

    if [ -f "${FOO}"/foo/"${BAR}"/bar ]
    then
             foobar
    fi

    Corretto:

    if [ -f "${FOO}/foo/${BAR}/bar" ]
    then
             foobar
    fi

    14.5 Varie
  • Per le chiamate a sed utilizzare "|" (senza virgolette intorno) come separatore, ad esempio "sed -e 's|foo|bar|'" (senza "").
  • Non utilizzare il comando test per prove o confronti, usare "[" "]" (senza ""); ad esempio "if [ -x /bin/foo ]; ..." e non "if test -x /bin/foo; ...".
  • Ove possibile utilizzare case invece di test, essendo più facile da leggere e più veloce in esecuzione.
  • 15. Procedure

    Questo capitolo documenta le procedure all'interno del progetto Debian Live per vari compiti che necessitano di cooperazione con altri team Debian.

    15.1 Aggiornamenti degli udeb

    Prima di effettuare dei commit di un udeb nel repository svn dell'installatore Debian va eseguito:

    $ ../../scripts/l10n/output-l10n-changes . -d

    15.2 Rilasci importanti

    Rilasciare una nuova versione stabile di Debian implica che molti team differenti lavorino insieme; ad un certo punto si inserisce il team Live che prepara le immagini del sistema live. I requisiti per fare ciò sono:

  • Un mirror contenente le versioni rilasciate per l'archivio debian, debian-security e debian-volatile al quale possa accedere il debian-live buildd.
  • Vanno resi noti i nomi dell'immagine (debian-live-VERSION-ARCH-FLAVOUR.iso).
  • Le liste dei pacchetti devono essere state aggiornate.
  • Bisogna sincronizzare i dati dal cd Debian (udeb esclude le liste).
  • Bisogna sincronizzare i file inclusi dal cd Debian (README.*, doc/*, ecc.).
  • Le immagini vengono create e ospitate su cdimage.debian.org.
  • 15.3 Rilasci minori
  • Bisogna nuovamente aggiornare i mirror di debian, debian-security e debian-volatile.
  • Le immagini vengono create e ospitate su cdimage.debian.org.
  • Inviare email di annuncio.
  • 15.3.1 Modello per l'annuncio di un rilascio minore.

    Si può generare un'email per l'annuncio dei rilasci minori usando il modello sottostante e il seguente comando:

    $ sed \
         -e 's|%major%|5.0|g' \
         -e 's|%minor%|5.0.2|g' \
         -e 's|%codename%|lenny|g' \
         -e 's|%release_mail%|2009/msg00007.html|g'

    Si prega di controllare attentamente l'email prima di inviarla e passarla ad altri per le correzioni.

    Debian Live images for Debian GNU/Linux %major% updated

    The Debian Live project is pleased to announce the availability of
    updated Live images for its stable distribution Debian GNU/Linux %major%
    (codename "%codename%").

    The images are available for download at:

         

    This update incorporates the changes made in the %minor% point release,
    which adds corrections for security problems to the stable release
    along with a few adjustments for serious problems. A full list of the
    changes may be viewed at:

         

    It also includes the following Live-specific changes:

      * [INSERT LIVE-SPECIFIC CHANGE HERE]
      * [INSERT LIVE-SPECIFIC CHANGE HERE]
      * [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]

    URLs
    ----

    Download location of updated images:

       

    Debian Live project homepage:

       

    The current stable distribution:

       

    stable distribution information (release notes, errata etc.):

       

    Security announcements and information:

       

    About Debian
    -------------

    The Debian Project is an association of Free Software developers who
    volunteer their time and effort in order to produce the completely free
    operating system Debian GNU/Linux.

    About Debian Live
    -----------------

    Debian Live is an official sub-project of Debian which produces Debian
    systems that do not require a classical installer. Images are available
    for CD/DVD discs, USB sticks and PXE netbooting as well as a bare
    filesystem images for booting directly from the internet.

    Contact Information
    -------------------

    For further information, please visit the Debian Live web pages at
    or alternatively send mail to
    .

    Esempi

    16. Esempi

    Questo capitolo affronta alcune costruzioni di esempio per specifici casi d'uso con Debian Live. Se si è nuovi nella costruzione di immagini Debian Live, raccomandiamo di dare innanzitutto un'occhiata ai tre tutorial in sequenza, dato che ciascuno insegna nuove tecniche che aiuteranno nell'uso e nella comprensione degli esempi rimanenti.

    16.1 Usare gli esempi

    Per usare questi esempi è necessario un sistema per costruirveli sopra che soddisfi i requisiti elencati in Requisiti e avere live-build installato come descritto in Installare live-build.

    Note that, for the sake of brevity, in these examples we do not specify a local mirror to use for the build. You can speed up downloads considerably if you use a local mirror. You may specify the options when you use lb config, as described in Distribution mirrors used at build time, or for more convenience, set the default for your build system in /etc/live/build.conf. Simply create this file and in it, set the corresponding LB_PARENT_MIRROR_* variables to your preferred mirror. All other mirrors used in the build will be defaulted from these values. For example:

    LB_PARENT_MIRROR_BOOTSTRAP="http://mirror/debian"
    LB_PARENT_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
    LB_PARENT_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates"

    16.2 Tutorial 1: un'immagine standard

    Caso d'uso: creazione di una prima semplice immagine, imparando i fondamenti di live-build.

    In questo tutorial genereremo un'immagine ISO ibrida di Debian Live contenente solo pacchetti base (senza Xorg) e alcuni pacchetti Debian Live di supporto, come primo esercizio sull'uso di live-build.

    Non può essere più semplice:

    $ mkdir tutorial1 ; cd tutorial1 ; lb config

    Esaminare i contenuti della directory config/; si noterà uno scheletro di configurazione pronto per essere personalizzato o, in questo caso, usato immediatamente per costruire un'immagine predefinita.

    Ora, come super-utente, si generi l'immagine, salvando un log con tee.

    # lb build 2>&1 | tee binary.log

    Presupponendo che tutto vada per il verso giusto, dopo un po' la directory corrente conterrà binary-hybrid.iso. Questa immagine ISO ibrida può essere avviata direttamente in una macchina virtuale come descritto in Provare un'immagine ISO con Qemu e Provare un'immagine ISO con virtualbox-ose, oppure masterizzata su un supporto ottico o ancora su una chiavetta USB come descritto rispettivamente in Masterizzare un'immagine ISO su un supporto fisico e Copiare un'immagine ISO ibrida su una penna USB.

    16.3 Tutorial 2: servizio browser web

    Caso d'uso: creazione di un'immagine per servizio browser web, imparando come applicare le personalizzazioni.

    In questo tutorial verrà creata un'immagine adatta all'uso come browser web, che serve come introduzione alla personalizzazione delle immagini Debian Live.

    $ mkdir tutorial2
    $ cd tutorial2
    $ lb config -p lxde
    $ echo iceweasel >> config/package-lists/my.list.chroot

    Our choice of LXDE for this example reflects our desire to provide a minimal desktop environment, since the focus of the image is the single use we have in mind, the web browser. We could go even further and provide a default configuration for the web browser in config/includes.chroot/etc/iceweasel/profile/, or additional support packages for viewing various kinds of web content, but we leave this as an exercise for the reader.

    Si generi l'immagine, ancora come super-utente, conservando un log come in Tutorial 1:

    # lb build 2>&1 | tee binary.log

    Di nuovo, si verifichi che l'immagine sia a posto e la si collaudi, come in Tutorial 1.

    16.4 Tutorial 3: un'immagine personalizzata

    Caso d'uso: creazione di un progetto per costruire un'immagine personalizzata che contiene i pacchetti preferiti da portare con sé in una chiavetta USB ovunque si vada, e che evolve in revisioni successive allorché i bisogni o le preferenze cambino.

    Dal momento che la nostra immagine personalizzata cambierà con le successive revisioni, e che vogliamo tener traccia di questi cambiamenti, andando per tentativi ed eventualmente tornando indietro se qualcosa non funziona, conserveremo la nostra configurazione nel popolare sistema di controllo di versione git. Useremo anche le migliori pratiche di auto-configurazione tramite gli script auto come descritto in Gestire una configurazione.

    16.4.1 Prima revisione

    $ mkdir -p tutorial3/auto
    $ cp /usr/share/live/build/examples/auto/* tutorial3/auto/
    $ cd tutorial3

    Modificare auto/config come segue:

    #!/bin/sh

    lb config noauto \
         --architecture i386 \
         --linux-flavours 686-pae \
         --package-lists lxde \
         "${@}"

    Now populate your local package list:

    $ echo "iceweasel xchat" >> config/package-lists/my.list.chroot

    First, --architecture i386 ensures that on our amd64 build system, we build a 32-bit version suitable for use on most machines. Second, we use --linux-flavours 686-pae because we don't anticipate using this image on much older systems. Third, we've chosen the lxde package list to give us a minimal desktop. And finally, we have added two initial favourite packages: iceweasel and xchat.

    Costruire quindi l'immagine:

    # lb build

    Si noti che diversamente dai primi due tutorial, non occorre più digitare 2>&1 | tee binary.log dato che questo è ora incluso in auto/build.

    Una volta che l'immagine è stata collaudata (come in Tutorial 1) e che si è sicuri che funzioni correttamente, è il momento di inizializzare il repository git, aggiungendo solo gli script auto appena creati, e di fare poi il primo commit:

    $ git init
    $ git add auto
    $ git commit -a -m "Initial import."

    16.4.2 Seconda revisione

    In questa revisione ripuliremo la prima compilazione, aggiungeremo il pacchetto vlc alla configurazione, dunque avverrà una ricompilazione, verifica e commit.

    Il comando lb clean ripulirà tutti i file ottenuti con la precedente generazione eccetto la cache, che ci evita un nuovo download dei pacchetti. Ciò assicura che il successivo lb build eseguirà di nuovo tutti i passaggi per rigenerare i file dalla nuova configurazione.

    # lb clean

    Now append the vlc package to our local package list in config/package-lists/my.list.chroot:

    $ echo vlc >> config/package-lists/my.list.chroot

    Rigenerare nuovamente:

    # lb build

    Verificare, e quando soddisfatti, eseguire il commit della revisione successiva:

    $ git commit -a -m "Adding vlc media player."

    Ovviamente sono possibili cambiamenti alla configurazione più complicati, magari aggiungendo file in sottodirectory di config/. Quando si esegue il commit di nuove revisioni, si faccia solo attenzione a non modificare manualmente o fare un commit dei file al livello superiore di config che contengono le variabili LB_*, giacché sono anche prodotti dell'assemblaggio, e che sono sempre ripuliti da lb clean e ricreati con lb config attraverso i loro rispettivi script auto.

    Siamo arrivati alla fine di questa serie di tutorial. Mentre sono possibili molti altri tipi di personalizzazioni, anche solo usando le poche caratteristiche esplorate in questi semplici esempi, può essere creata una varietà quasi infinita di immagini. Gli esempi rimanenti in questa sezione coprono diversi altri casi d'uso estrapolati dalle esperienze raccolte degli utenti Debian Live.

    16.5 Un client Kiosk VNC

    Caso d'uso: creazione di un'immagine con live-build per avviare direttamente un server VNC.

    Make a build directory and create a skeletal configuration in it built around the standard-x11 list, including gdm3, metacity and xvnc4viewer, disabling recommends to make a minimal system:

    $ mkdir vnc_kiosk_client
    $ cd vnc_kiosk_client
    $ lb config -a i386 -k 686-pae -p standard-x11 \
         --apt-recommends false
    $ echo "gdm3 metacity xvnc4viewer" >> config/package-lists/my.list.chroot

    Creare la directory /etc/skel e inserirvi un .xsession personalizzato per l'utente predefinito che lancerà metacity e avvierà xvncviewer, connesso alla porta 5901 su un server all'indirizzo 192.168.1.2:

    $ mkdir -p config/includes.chroot/etc/skel
    $ cat > config/includes.chroot/etc/skel/.xsession < #!/bin/sh

    /usr/bin/metacity &
    /usr/bin/xvncviewer 192.168.1.2:1

    exit
    END

    Costruire l'immagine:

    # lb build

    Buon divertimento.

    16.6 Un'immagine base per una chiavetta USB da 128M

    Caso d'uso: creazione di un'immagine standard con alcuni componenti rimossi affinché possa stare su una chiavetta USB da 128M, con lo spazio che rimane da usarsi come meglio si crede.

    Quando si cerca di ottimizzare un'immagine affinché sia contenuta in un supporto, è necessario capire il compromesso che si deve fare tra la dimensione e la funzionalità. In questo esempio, taglieremo solo quanto basta per far sì che il tutto stia in 128M, senza fare nient'altro che distrugga l'integrità dei pacchetti contenuti, come eliminare localizzazioni con il pacchetto localepurge o altre ottimizzazioni "intrusive". È da notare che non va usato --bootstrap-flavour minimal a meno che non si sappia cosa si sta facendo, come omettere la priorità dei pacchetti important che molto probabilmente produrrà un sistema live danneggiato.

    $ lb config -k 486 -p minimal --apt-indices false \
         --memtest none --apt-recommends false --includes none

    Costruire quindi l'immagine nel modo consueto:

    # lb build 2>&1 | tee binary.log

    All'autore del sistema al momento di scrivere, la seguente configurazione ha prodotto una immagine di 78Mbyte. Comparabile favorevolmente con i 166Mbyte prodotta dalla configurazione predefinita nel Tutorial 1.

    The biggest space-saver here, compared to building a standard image on an i386 architecture system, is to select only the 486 kernel flavour instead of the default -k "486 686-pae". Leaving off APT's indices with --apt-indices false also saves a fair amount of space, the tradeoff being that you need to apt-get update before using apt in the live system. Choosing the minimal package list leaves out the large locales package and associated utilities. Dropping recommended packages with --apt-recommends false saves some additional space, at the expense of omitting some packages you might otherwise expect to be there, such as firmware-linux-free which may be needed to support certain hardware. The remaining options shave off additional small amounts of space. It's up to you to decide if the functionality that is sacrificed with each optimization is worth the loss in functionality.

    16.7 Un desktop KDE localizzato e l'installer

    Caso d'uso: creazione di un'immagine con il desktop KDE, localizzato per il portoghese brasiliano e che includa l'installatore.

    Si vuole creare un'immagine iso ibrida per architettura i386 usando il nostro desktop preferito, in questo caso KDE, contenente tutti gli stessi pacchetti che verrebbero installati dall'installatore Debian standard per KDE.

    Our initial problem is the discovery of the names of the appropriate language tasks. Currently, live-build cannot help with this. While we might get lucky and find this by trial-and-error, there is a tool, grep-dctrl, which can be used to dig it out of the task descriptions in tasksel-data, so to prepare, make sure you have both of those things:

    # apt-get install dctrl-tools tasksel-data

    Ora si possono cercare i task appropriati:

    $ grep-dctrl -FTest-lang pt_BR /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese

    Con questo comando, si è scoperto che il task si chiama, abbastanza chiaramente, brazilian-portuguese. Ora per trovare i task correlati:

    $ grep-dctrl -FEnhances brazilian-portuguese /usr/share/tasksel/descs/debian-tasks.desc -sTask
    Task: brazilian-portuguese-desktop
    Task: brazilian-portuguese-kde-desktop

    At boot time we will generate the pt_BR.UTF-8 locale and select the pt-latin1 keyboard layout. We will also need to preseed our desktop choice, "kde" so that tasksel will install the correct desktop task, as it differs from the default (see Desktop and languages tasks). Now let's put the pieces together:

    $ mkdir live-pt_BR-kde
    $ cd live-pt_BR-kde
    $ lb config \
         -a i386 \
         -k 486 \
         --bootappend-live "locales=pt_BR.UTF-8 keyboard-layouts=pt-latin1" \
         --debian-installer live
    $ echo kde-desktop brazilian-portuguese brazilian-portuguese-desktop \
         brazilian-portuguese-kde-desktop >> config/task-lists/my.list.chroot
    $ echo debian-installer-launcher >> config/package-lists/my.list.chroot
    $ echo tasksel tasksel/desktop multiselect kde >> config/preseed/my.preseed.chroot

    Si noti che è stato incluso il pacchetto debian-installer-launcher in modo da poter lanciare l'installer dal desktop della live, e che è stato anche specificato il kernel 486, dato che attualmente è necessario che il kernel dell'installer e quello del sistema live coincidano affinché il launcher funzioni correttamente.




    Debian -->
    [ document manifest ]