Rights: Copyright © 2006-2012 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.
This manual serves as a single access point to all documentation related to the Debian Live project and in particular applies to the software produced by the project for the Debian 7.0 "wheezy" release. An up-to-date version can always be found at ‹http://live.debian.net/›
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.
While we believe that everything in this manual is important to at least some of our users, we realize it is a lot of material to cover and that you may wish to experience early success using the software before delving into the details. Therefore, we suggest reading in the following order.
First, read this chapter, About this manual, from the beginning and ending with the Terms section. Next, skip to the three tutorials at the front of the Examples section designed to teach you image building and customization basics. Read Using the examples first, followed by Tutorial 1: A standard image, Tutorial 2: A web browser utility and finally Tutorial 3: A personalized image. By the end of these tutorials, you will have a taste of what can be done with Debian Live.
We encourage you to return to more in-depth study of the manual, perhaps next reading The basics, skimming or skipping Building a netboot image, and finishing by reading the Customization overview and the chapters that follow it. By this point, we hope you are thoroughly excited by what can be done with Debian Live and motivated to read the rest of the manual, cover-to-cover.
Lista degli autori (in ordine alfabetico):
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
È inoltre possibile compilare in base al tipo di documento, esempio:
$ make build FORMATS=pdf
O entrambi:
$ make build FORMATS=html LANGUAGES=it
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:
$ 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*
$ cat >> ~/.ssh/config << EOF
Host live.debian.net
Hostname live.debian.net
User git
IdentityFile ~/.ssh/identity.d/git@live.debian.net
EOF
$ git clone git@live.debian.net:/live-manual.git
$ cd live-manual && git checkout debian-next
$ git commit -a -m "Adding a section on applying patches."
$ git push
Per inviare una traduzione per una nuova lingua, seguire questi tre passi:
Nota: anche se make commit e make build rimuovono entrambi la directory di compilazione, se si compila il manuale per rivedere le modifiche come consigliato, si consiglia di pulire l'albero git prima del push; per fare ciò si puà usare il comando make clean. Grazie al file .gitignore, quest'ultimo passaggio non è obbligatorio ma è una buona abitudine che evita di fare involontariamente il commit di certi file.
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:
Debian è il Sistema Operativo Universale, ha un sistema live per mostrare e rappresentare accuratamente il sistema con i seguenti vantaggi:
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.
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 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. Queste modifiche essenziali devono essere tenute al minimo possibile e saranno eventualmente aggiunte ai repository Debian.
Per costruire immagini Debian Live i requisiti di sistema sono davvero pochi:
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.
Si può installare live-build in diversi modi:
Se si sta usando Debian, il metodo raccomandato è di installare live-build attraverso il repository Debian.
Installare live-build semplicemente come qualsiasi altro pacchetto:
# apt-get install live-build
o
# aptitude install live-build
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
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/›.
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.
Sia live-boot che live-config sono disponibili dai repository Debian come per l' installazione di live-build.
Per utilizzare i sorgenti più recenti da Git si può seguire il procedimento seguente. Assicurarsi di conoscere i termini menzionati nel Glossario.
$ 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.
È 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
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.
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
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 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.
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:
È 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.)
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.
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.
Masterizzare un'immagine ISO è semplice, basta installare wodim e utilizzarlo da riga di comando; ad esempio:
# apt-get install wodim
$ wodim binary.hybrid.iso
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}
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.
Per lo sviluppo delle immagini live, può essere un notevole risparmio di tempo eseguirle in una macchina virtuale (VM). Non senza qualche raccomandazione:
A condizione che si possa lavorare entro questi vincoli, cercare il software disponibile per la virtualizzazione e scegliere quello adatto alle proprie necessità.
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.
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.
$ echo virtualbox-ose-guest-x11 >> config/package-lists/my.list.chroot
La creazione di un'immagine HDD è simile alla ISO ibrida sotto tutti gli aspetti ad eccezione della necessità di specificare l'opzione -b 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 HDD.
# lb clean --binary
Eseguire il comando lb config come prima, questa volta specificando però il tipo di immagine HDD:
$ lb config -b 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.
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 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.
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
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.
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.
# 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 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.
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";
}
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.
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.
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.
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"
#!/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"
Questo capitolo contiene una panoramica dei tre principali strumenti utilizzati nella creazione dei sistemi Debian Live: live-build, live-boot e live-config.
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:
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:
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.
L'esecuzione di lb config senza argomenti crea una sottodirectory config/ popolata con alcune impostazioni predefinite e uno scheletro di sottodirectory in auto/.
$ lb config
[2012-03-19 15:17:14] lb_config
P: Considering defaults defined in /etc/live/build.conf
P: Creating config tree for a debian system
L'uso di lb config senza argomenti è adatto ad utenti che necessitano di un'immagine di base o che intendono fornire in seguito una configurazione più completa tramite auto/config (per i dettagli vedere Gestire una configurazione).
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 --bootappend-live "hostname=live-machine username=live-user" ...
Una lista completa delle opzioni è disponibile nel manuale di lb_config.
Il comando lb build legge la configurazione dalla directory config/ ed esegue a un livello inferiore i comandi necessari a costruire il sistema live.
È 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.
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.
All'avvio cercherà supporti in sola lettura che contengano una directory /live/ dove sia presente un filesystem root (spesso un'immagine compressa come squashfs). Se trovata, creerà un ambiente scrivibile usando aufs, per avviarsi da sistemi simili a Debian.
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/›.
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.
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.
Le configurazioni live raramente sono perfette da riuscire al primo colpo, servono una serie di revisioni prima di essere soddisfatti. Tuttavia, se non si presta attenzione, possono verificarsi delle incoerenze tra una revisione e l'altra se non si presta attenzione. Il problema principale è che una volta assegnato un valore predefinito ad una variabile, tale valore non sarà ricalcolato da altre variabili che possono cambiare in altre revisioni.
Per esempio, durante la prima configurazione della distribuzione, a molte variabili 'dipendenti' vengono dati valori predefiniti che si adattino.Per cui se in seguito si decide di cambiare distribuzione, quelle variabili continueranno a mantenere vecchi valori non più appropriati.
Un secondo problema correlato è l'eseguire lb config e aggiornare alla nuova versione di live-build il quale ha cambiato il nome di una delle variabili, lo si può scoprire solamente con una revisione manuale delle variabili nei file config/*, che sarà necessario utilizzare per impostare nuovamente le opzioni appropriate.
Tutto ciò potrebbe essere un fastidio terribile se non fosse per gli script auto/*, semplici wrapper ai comandi lb config, lb build e lb clean, designati per aiutare nella gestione della propria configurazione. Basta creare uno script auto/config che contenga il comando lb config con le opzioni desiderate e un auto/clean che rimuove i file contenenti valori delle variabili di configurazione, così ogni volta che si usano lb config e lb clean questi file saranno eseguiti. Ciò fà sì che la configurazione sia coerente da una revisione all'altra e tra i rilasci delle varie versioni di live-build (sebbene si dovrà comunque fare attenzione aggiornando live-build, leggendo la documentazione e facendo le modifiche necessarie).
Usare esempi di script automatici come il seguente come punto di partenza per una nuova configurazione di live-build. Si noti che quando si invoca il comando lb incluso nello script, si deve specificare il parametro noauto per essere certi che lo script stesso non venga richiamato ricorsivamente. Non dimenticare, inoltre, di accertarsi che gli script siano eseguibili (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 script automatico per live-build basato sugli esempi precedenti; si possono copiare come punto di partenza.
$ cp /usr/share/live/build/examples/auto/* auto/
Modificare auto/config aggiungendo o togliendo le opzioni come meglio credi. Nel precedente esempio, --package-lists standard è impostato al valore predefinito; cambiarlo in un valore appropriato per l'immagine (o cancellarlo se si desidera utilizzare un valore predefinito) e aggiungere eventuali opzioni ulteriori in continuazione delle righe che seguono.
Questo capitolo mostra una panoramica dei vari metodi con i quali è possibile personalizzare un sistema Debian Live.
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.
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.
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.
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.
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à.
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.
L'archivio Debian è replicato attraverso una vasta rete di mirror in tutto il mondo cosicché chiunque in ogni nazione può selezionare il mirror più vicino per la migliore velocità di scaricamento. Ciascuna delle opzioni --mirror-* determina quale mirror della distribuzione è usato nei vari stadi della compilazione. Ricordando dalle Fasi della creazione che la fase di avvio è quando il chroot è inizialmente popolato da debootstrap con un sistema minimale e quella di chroot è quando viene creato il chroot usato per costruire il file system del sistema live. Perciò per queste fasi vengono usati i corrispondenti cambi di mirror, e in seguito, nella fase binaria vengono usati i valori di --mirror-binary e --mirror-binary-security sostituendo qualsiasi altro mirror usato nelle fasi iniziali.
Per impostare i mirror delle distribuzioni usati in fase di compilazione ad uno locale, è sufficiente impostare --mirror-bootstrap, --mirror-chroot-security e --mirror-chroot-backports come segue.
$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/ \
--mirror-chroot-backports http://localhost/debian-backports/
Il mirror chroot, specificato da --mirror-chroot, è impostato al valore di --mirror-bootstrap.
Le opzioni --mirror-binary* determinano i mirror delle distribuzioni inseriti nell'immagine binaria. Questi possono essere usati per installare pacchetti aggiuntivi mentre il sistema live è in funzione. Le impostazioni predefinite impiegano cdn.debian.net, un servizio che sceglie un mirror geograficamente vicino basandosi sul numero IP dell'utente. Questo è una scelta conveniente quando non si può pronosticare quale sarà il mirror migliore per tutti gli utenti. Oppure si può specificare il proprio valore come mostrato nell'esempio qui sotto. Un'immagine compilata con questa configurazione sarebbe adatta solamente ad utenti di una rete dove sia raggiungibile il "mirror".
$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/
Si possono aggiungere altri repository, ampliando così la scelta dei pacchetti al di là di quelli disponibili nella distribuzione di destinazione. Questi possono essere, per esempio, pacchetti di backport, sperimentali o personalizzati. Per configurare repository aggiuntivi, creare i file config/archives/vostro-repository.list.chroot, o config/archives/vostro-repository.list.binary. Come per le opzioni --mirror-*, queste controlleranno i repository usati nella fase chroot quando si compila l'immagine, e nella fase binary, ad esempio per usarli quando il sistema live è avviato.
Per esempio, config/archives/live.list.chroot permette di installare pacchetti dal repository snapshot di debian live al momento della creazione del sistema live.
deb http://live.debian.net/ sid-snapshots main contrib non-free
Se si aggiunge la stessa riga in config/archives/live.list.binary, il repository verrà aggiunto alla directory /etc/apt/sources.list.d/ del sistema live.
Se il file esiste, saranno prelevati automaticamente.
Bisogna inoltre inserire la chiave GPG usata per firmare il repository nei file config/archives/vostro-repository.key.{binary,chroot}.
Nota: alcuni repository di pacchetti preconfigurati sono disponibili per una facile selezione attraverso l'opzione --archives, per abilitare gli snapshot live è sufficiente un semplice comando:
$ lb config --archives live.debian.net
Ci sono diversi modi per scegliere quali pacchetti live-build installerà nell'immagine, coprendo una gamma di esigenze diverse. Si possono richiamare i singoli pacchetti da un elenco o scegliere elenchi predefiniti di pacchetti oppure utilizzare i task di APT. E infine inserire i file dei pacchetti nell'albero config/, che ben si adatta a provare pacchetti nuovi o sperimentali prima che siano disponibili in un repository.
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.
Il modo più semplice per usare gli elenchi è di specificarne uno o più con l'opzione --package-lists. Per esempio:
$ lb config --package-lists "gnome rescue"
Il percorso predefinito per i file elenco sul sistema è /usr/share/live/build/package-lists/. Per determinare i pacchetti in un dato elenco, si legga il file corrispondente, prestando attenzione ai file inclusi e condizionali come descritto nella sezioni seguenti.
Gli elenchi predefiniti si possono integrare usando quelli locali dei pacchetti in config/package-lists/.
Per essere processati, gli elenchi dei pacchetti che si trovano in questa directory devono avere un suffisso .list e un suffisso .chroot o .binary aggiuntivo per indicare per quale fase sia l'elenco.
Nota: se non si specifica il suffisso l'elenco sarà usato per entrambe le fasi. Normalmente è preferibile specificare .list.chroot in modo che i pacchetti vengono installati solo nel filesystem live evitando di avere una copia extra del .deb sul dispositivo.
Per creare un elenco di binari inserire un file con suffisso .list.binary in config/package-lists/; questi pacchetti non sono installati nel filesystem ma inclusi sul dispositivo live sotto pool/. Solitamente questo elenco si usa con una delle varianti non-live dell'installatore; come detto sopra, se si vuole che questo sia identico all'elenco della fase chroot, usare semplicemente il suffisso .list.
Gli elenchi di pacchetti inclusi in live-build fanno un notevole uso di include. Far riferimento a questi nella directory /usr/share/live/build/package-lists/, in quanto portano ottimi esempi su come scriverne di propri.
Per esempio, per creare un elenco che includa quello predefinito di gnomepiù iceweasel, creare config/package-lists/mio.elenco.chroot con i seguenti contenuti:
#include <gnome>
iceweasel
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, ARCHITECTURES o ARCHIVE_AREAS.
Per esempio, per installare ia32-libs se è specificata --architectures amd64:
#if ARCHITECTURES amd64
ia32-libs
#endif
Si può verificare per ognuna di una serie di valori, ad esempio per installare memtest86+ specificando sia --architectures i386 sia --architectures amd64:
#if ARCHITECTURES 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 ARCHITECTURES amd64
#include <gnome-full>
#endif
Le condizioni nidificate non sono supportate.
L'installatore Debian offre all'utente la scelta di vari elenchi di pacchetti pre-selezionati, ognuno dei quali focalizzato su un particolare tipo di sistema, o il tipo di attività per cui utilizzarlo, come "Graphical desktop environment", "Mail server" o "Laptop". Questi elenchi sono chiamati "task" e sono gestiti da APT attraverso il campo"Task:". In live-build si possono specificare uno o più task inserendoli in una lista in config/task-lists/, come nell'esempio seguente.
$ 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.
I task per i desktop e la lingua sono un caso particolare che necessita di ulteriori pianificazioni e configurazioni e in questo senso le immagini live sono diverse da quelle dell'Installatore Debian. Nell'Installatore Debian, se il supporto è stato preparato per un particolare ambiente desktop, il corrispondente task verrà automaticamente installato. Perciò ci sono task gnome-desktop, kde-desktop, lxde-desktop e xfce-desktop interni, nessuno dei quali è offerto nel menu di tasksel. Allo stesso modo, non c'è nessuna voce nel menu per i task delle lingue, ma la scelta della lingua dell'utente durante l'installazione influenza la selezione dei corrispondenti task della lingua.
Sviluppando un'immagine live per desktop, questa si avvia direttamente su un'area di lavoro, le scelte del desktop e della lingua predefinita sono state fatte al momento della compilazione e non al volo come nel caso dell'installatore Debian. Questo non per dire che un'immagine live non possa essere creata con un supporto per desktop o lingue multipli per offrire all'utente una scelta, ma che non è il comportamento predefinito nella creazione di una live.
Poiché automaticamente non viene fatta alcuna preparazione sui task della lingua, i quali includono cose come caratteri specifici per la lingua e pacchetti per i metodi di input, se li si vogliono, vanno specificati nella configurazione. Per esempio, un'immagine del desktop GNOME contenente il supporto per il giapponese può includere questi task:
$ 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
Dal momento che i task desktop sono "interni", bisogna preconfigurare ogni altro desktop da includere nell'immagine e diverso dal predefinito "gnome" nella variabile debconf "tasksel/desktop", altrimenti tasksel non li installerà:
$ lb config
$ echo 'tasksel tasksel/desktop multiselect kde' >> config/preseed/my.preseed.chroot
Questo parametro supporta valori multipli, ad esempio "lxde xfce" invece di "kde".
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:
Usando packages.chroot è più semplice da ottenere e utile per una personalizzazione "una tantum" ma ha una serie di svantaggi, mentre un repository APT personalizzato è più laborioso da configurare.
Per installare un pacchetto personalizzato copiarlo nella directory config/packages.chroot/; i pacchetti al suo interno verranno installati automaticamente durante la creazione del sistema live, non è necessario specificarli altrove.
I pacchetti devono essere nominati nel modo prescritto, un metodo semplice per farlo è usare dpkg-name.
L'utilizzo di packages.chroot per l'installazione di pacchetti personalizzati presenta degli svantaggi:
A differenza di packages.chroot, quando si usa un repository APT personalizzato è necessario assicurarsi di specificare altrove i pacchetti. Per i dettagli si veda Scegliere i pacchetti da installare.
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.
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.
APT è configurabile tramite una serie di opzioni applicate solo in fase di costruzione (la configurazione di APT utilizzata nel sistema live in esecuzione può essere configurata nel solito modo, ovvero includendo le impostazioni appropriate attraverso config/includes.chroot/). Per un elenco completo, cercare nel manuale di lb_config le opzioni che iniziano con apt.
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.
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/
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.
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.
Si prega di leggere prima il manuale di apt_preferences(5). Il pinning può essere configurato sia in fase di costruzione sia di esecuzione; per la prima creare config/chroot_apt/preferences mentre per l'ultima creare 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 << END
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
Un valore negativo della priorità evita che un pacchetto venga installato, come nel caso in cui non se ne voglia uno raccomandato da un altro. Si suppone di costruire un'immagine di LXDE utilizzando l'opzione --package-lists lxde ma non si desidera che all'utente venga richiesto di salvare la password del wifi nel portachiavi. L'elenco include gdm che dipende da gksu che a sua volta raccomanda gnome-keyring, in questo caso si vorrà omettere il pacchetto gnome-keyring aggiungendo a config/chroot_apt/preferences la seguente definizione:
Package: gnome-keyring
Pin: version *
Pin-Priority: -1
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.
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:
Si consulti il Glossario per ulteriori informazioni sulla distinzione tra immagini "Live" e "binarie".
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.
Per includere i file si aggiungano semplicemente alla directory config/includes.chroot. Questa corrisponde alla directory root / del sistema live. Per esempio, per aggiungere un file /var/www/index.html nel sistema live, si usi:
$ 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.
Si possono utilizzare include locali binari per inserire sul filesystem del supporto materiale come documentazione o video affinché sia immediatamente accessibile dopo l'inserimento dello stesso senza avviare il sistema live. Ciò funziona in modo simile agli include locali del chroot; supponendo che i file ~/video_demo.* siano video dimostrativi del sistema descritti da e collegati a una pagina HTML indice, basta copiare il materiale in config/includes.binary/ come segue:
$ cp ~/video_demo.* config/includes.binary/
Questi file appariranno nella directory principale del supporto live.
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.
Gli hook permettono di eseguire comandi nel chroot e nelle fasi binarie della creazione al fine di personalizzare l'immagine.
Per eseguire comandi nella fase chroot, creare uno script hook con suffisso .chroot contenente i comandi nella directory config/hooks/. L'hook verrà eseguito nel chroot dopo che verrà applicata il resto della configurazione del chroot, ricordare quindi di garantire che la propria configurazione includa tutti i pacchetti e i file che l'hook necessita per funzionare. Vedere gli script d'esempio degli hook di chroot per i vari compiti di personalizzazione del chroot contenuti in /usr/share/live/build/examples/hooks da copiare o collegare nella propria configurazione.
Per eseguire comandi all'avvio, è possibile fornire degli hook a live-config come spiegato nella sezione "Customization" del suo manuale. Controllare gli hook di live-config in /lib/live/config/ e notare i numeri sequenziali; fornire quindi i propri hook con una sequenza numerica appropriata, sia come include locali del chroot in config/includes.chroot/lib/live/config/, sia come pacchetto personalizzato come discusso in Installare pacchetti modificati o di terze parti.
Per eseguire comandi nella fase binaria, creare uno script hook con suffisso .binary che contenga i comandi nella directory config/hooks/. L'hook verrà eseguito dopo tutti gli altri comandi binari, ma prima di binary_checksums, l'ultimo comando. I comandi nel proprio hook non vengono eseguiti nel chroot, perciò si faccia attenzione a non modificare nessun file al di fuori dell'albero di compilazione o si danneggerà il sistema! Vedere gli script d'esempio per gli hook binari per i vari compiti di personalizzazione dei binari in /usr/share/live/build/examples/hooks da copiare o collegare nella propria configurazione.
I file nella directory config/preseed/ con suffisso .preseed seguiti dalla fase (.chroot o .binary) sono considerati file di preconfigurazione di debconf e sono installati da live-build usando debconf-set-selections durante la fase corrispondente.
Per ulteriori informazioni su debconf, vedere debconf(7) nel pacchetto debconf.
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.
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.
È possibile specificare gruppi aggiuntivi ai quali l'utente live apparterrà preconfigurando il valore passwd/user-default-groups di debconf. Ad esempio, per aggiungere l'utente al gruppo fuse, inserire la seguente preconfigurazione in config/preseed/ per la fase chroot:
$ 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
È inoltre possibile modificare facilmente il nome utente "user" e la password "live" predefiniti.
Per cambiare il nome utente specificare quanto segue nella configurazione:
$ lb config --bootappend-live "username=live-user"
Un modo per cambiare la password è tramite un hook come descritto in Hook in fase di avvio. Si può usare l'hook "passwd" da /usr/share/doc/live-config/examples/hooks, anteponendolo di conseguenza (ad esempio, 200-passwd) e aggiungerlo al file config/includes.chroot/lib/live/config/
Quando il sistema live si avvia, la lingua è inserita in tre fasi:
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"
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 supporto di memorizzazione locale, 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: persistence.
Se il parametro di boot persistence è impostato (e non lo è nopersistence), i supporti di memorizzazione locali (hard disk, dispositivi USB) saranno rilevati come volumi persistenti durante l'avvio. Un volume persistente è uno dei seguenti:
È possibile limitare i tipi di volume persistenti da usare specificando certi parametri di boot descritti nella manpage di live-boot(7). Le "label identificative" di cui sopra possono essere una delle seguenti:
Con "persistenza completa" si intende l'uso di un volume persistente invece di un filesystem temporaneo (tmpfs) per salvare le modifiche al supporto in sola lettura (con il sistema COW, copy-on-write). Per questo tipo di persistenza la label deve essere full-ov, che potrebbe essere una partizione di tipo ext4 su un hard disk o una penna USB creata ad esempio con:
# mkfs.ext4 -L full-ov /dev/sdb1
Vedee 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 full-ov /dev/sdb1 # per filesystems ext2,3,4
Ecco un esempio di come creare un file immagine ext4 da utilizzare per la persistenza completa:
$ dd if=/dev/null of=full-ov bs=1G seek=1 # per un file immagine da 1GB
$ /sbin/mkfs.ext4 -F full-ov
Quindi copiare il file full-ov nella directory radice di una partizione scrivibile e riavviare.
Un volume con una label custom-ov può essere configurato per creare directory persistenti arbitrarie. Il file live-persistence.conf, situato nella directory radice del filesystem del volume, controlla quali rendere persistenti e in che modo.
Nella manpage di live-persistence.conf(5) è descritto dettagliatamente come è configurato il mount degli strati personalizzati, ma un semplice esempio dovrebbe essere sufficiente per la maggior parte degli usi. Supponendo di voler creare la directory home e quella della cache di APT in modo persistente in un filesystem ext4 sulla partizione /dev/sdb1:
$ mkfs.ext4 -L custom-ov /dev/sdb1
$ mount -t ext4 /dev/sdb1 /mnt
$ echo "/home" >> /mnt/live-persistence.conf
$ echo "/var/cache/apt" >> /mnt/live-persistence.conf
Quindi riavviare. Durante il primo avvio il contenuto di /home e /var/cache/apt saranno copiati nel volume persistente e da allora tutte le modifiche a queste directory risiederanno in modo persistente sul volume. C'è da considerare che tutti i path elencati nel file live-persistence.conf non possono contenere spazi o i caratteri speciali . e ..; inoltre, né /live (o nessuna delle sue sottodirectory) né / può essere resa persistente tramite i mount personalizzati (per l'ultimo usare la tipologia full-ov descritta prima).
Possono essere utilizzati svariati volumi di stratificazione personalizzati (con i rispettivi file live-persistence.conf) allo stesso tempo ma se questi creano la stessa directory persistente, ne verrà usata solo una. Se due directory montate sono "nidificate" (una è la sottodirectory dell'altra), la superiore sarà montata per prima, per cui nessuna operazione di mount verrà sovrastata dall'altra. I mount nidificati personalizzati sono problematici se sono elencati nello stesso file #{live-persistence.conf}. Se si ha davvero la necessità (in genere non si dovrebbe averla), consultare la manpage di live-persistence.conf(5) per sapere come gestire questo caso.
Le istantanee sono raccolte di file e directory che non vengono montate durante l'esecuzione ma copiate all'avvio da un volume persistente al sistema (tmpfs) e risincronizzate al riavvio e spegnimento. Il volume deve essere etichettato come live-sn sotto forma di un semplice archivio cpio nominato live-sn.cpio.gz. Un'interruzione di corrente durante l'esecuzione potrebbe portare ad una perdita di dati, se son state fatte modifiche importanti si può usare usare live-snapshot --refresh tante volte quanto necessario.Giacché non scrive continuamente sul dispositivo, questo tipo di persistenza è il sistema più comodo e veloce per dispositivi basati su memoria flash ma occupa tanta RAM quanta è la dimensione dell'istantanea decompressa.
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.
Se un utente avesse bisogno di archiviazioni multiple dello stesso tipo per differenti posti o per test, come full-ov-casa e full-ov-lavoro, il parametro d'avvio persistence-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: persistence persistence-subtext=sottotesto.
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.
live-build uses syslinux and some of its derivatives (depending on the image type) as bootloaders by default. You can easily customize them in a number of ways that range from providing a full theme to changing the boot timeout or simply adding a personalized splash image. Some of the following examples of customization make use of different methods, like includes or hooks.
If you want to use a full theme you can specify the --syslinux-theme option (see man lb_config). live-build will then retrieve the theme from the mirror and install it.
Imagine that you want to build a progress client but you prefer to include the server's theme because you want to have the help menu. Then you would launch lb config as follows:
$ lb config --mode progress --syslinux-theme progress-server
You can also create your own theme or modify an already existing one and if you do not have a mirror, you can add the package to config/packages.chroot. In this case it is not necessary to specify any option.
There is also the possibility of making smaller changes. For instance, syslinux derivatives are configured by default with a timeout of 0 (zero) which means that they will pause indefinitely at their splash screen until you press a key.
To modify the boot timeout of a default iso-hybrid image you can edit a default isolinux.cfg file specifying the timeout in units of seconds and add it to config/includes.binary/isolinux/
A modified isolinux.cfg to boot after five seconds would be similar to this:
include menu.cfg
default vesamenu.c32
prompt 0
timeout 50
An alternative way of achieving the same goal could be writing a hook and adding it to config/hooks/ Remember to add the .binary suffix to run in the binary stage. A proposed example:
#!/bin/sh
sed -i 's|timeout 0|timeout 50|' binary/isolinux/isolinux.cfg
Likewise, if you want to use a personalized splash.png image you can add a picture of 640x480 pixels to config/includes.binary/isolinux/
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_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.
Le immagini del sistema Debian Live possono essere integrate nell'Installatore Debian. 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 all'"Installatore Debian", quando usato ci si riferisce esclusivamente all'installatore ufficiale Debian. Spesso è abbreviato come "d-i".
I tre principali tipi dell'installer sono:
Installatore Debian "normale": un'immagine Debian Live con un kernel e un initrd separati i quali (quando viene selezionato dal bootloader appropriato) lancia un'istanza standard dell'Installatore Debian, come quando si scarica un'immagine di Debian per CD 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 i pacchetti .deb usando debootstrap o cdebootstrap, da supporti locali o dalla rete, risultante in un sistema Debian standard 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 dell'Installatore Debian. Una volta che si ha un file preimpostato funzionante, live-build può inserirlo automaticamente nell'immagine e abilitarlo.
Installatore Debian "live": un'immagine Debian Live con un kernel e un initrd separato che (quando selezionato dall'appropriato bootloader) avvia un'instanza dell'Installatore Debian.
L'installazione procederà nello stesso modo di un'installazione "Normale" come descritto sopra, ma nella fase 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, l'Installatore Debian continua normalmente, installando e configurando elementi come bootloader e utenti locali, ecc.
Nota: per supportare nel bootloader sia la voce normale che quella live dell'installatore sullo stesso supporto si deve disabilitare live-installer preconfigurando live-installer/enable=false.
Installatore Debian "Desktop": indipendentemente dal tipo di Installatore Debian incluso, d-i può essere lanciato cliccando un'icona sul desktop, in alcune situazioni più semplice per l'utente. Per poterne usufruire deve essere incluso il pacchetto debian-installer-launcher.
Si noti che live-build non include l'Installatore Debian nell'immagine in modo predefinito, necessita di essere 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 --architectures i386 --linux-flavours 486 \
--debian-installer live
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot
Come descritto nell'appendice B del manuale dell'Installatore Debian 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
Si può voler includere pacchetti udeb compilati localmente come componenti del d-i per scopi di sperimentazione o debug; per includerli nell'immagine inserirli in config/packages.binary/. I file e le directory aggiuntivi o di rimpiazzo si possono includere nell'initrd dell'installatore in maniera simile agli Include locali del Live/chroot, inserendo il materiale in config/includes.binary_debian-installer/.
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
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).
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.
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.
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:
È 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.
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.
Dove appare il bug?
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.
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.
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.
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,
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.
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.
Questo capitolo documenta lo stile usato per il codice di live-boot e gli altri.
Sbagliato:
if foo; then
bar
fi
Corretto:
if foo
then
bar
fi
Sbagliato:
Foo () {
bar
}
Corretto:
Foo ()
{
bar
}
Sbagliato:
FOO=bar
Corretto:
FOO="bar"
Sbagliato:
if [ -f "${FOO}"/foo/"${BAR}"/bar ]
then
foobar
fi
Corretto:
if [ -f "${FOO}/foo/${BAR}/bar" ]
then
foobar
fi
Questo capitolo documenta le procedure all'interno del progetto Debian Live per vari compiti che necessitano di cooperazione con altri team Debian.
Prima di effettuare dei commit di un udeb nel repository svn dell'installatore Debian va eseguito:
$ ../../scripts/l10n/output-l10n-changes . -d
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:
Remember to adjust both chroot and binary mirrors when building the last set of images for a Debian release after it has been moved away from ftp.debian.org to archive.debian.org. That way, old prebuilt live images are still useful without user modifications.
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:
<http://cdimage.debian.org/cdimage/release/current-live/>
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:
<http://lists.debian.org/debian-announce/%release_mail%>
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:
<http://cdimage.debian.org/cdimage/release/current-live/>
Debian Live project homepage:
<http://live.debian.net/>
The current stable distribution:
<http://ftp.debian.org/debian/dists/stable>
stable distribution information (release notes, errata etc.):
<http://www.debian.org/releases/stable/>
Security announcements and information:
<http://www.debian.org/security/>
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
<http://live.debian.net/> or alternatively send mail to
<debian-live@lists.debian.org>.
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.
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.
Si noti che, per brevità, in questi esempi non specifichiamo un mirror locale da usare per la costruzione. Usando un mirror locale, si possono accelerare considerevolmente i download. Si possono specificare le opzioni quando si usa lb config, come descritto in Mirror delle distribuzioni usati in fase di compilazione o, più convenientemente, impostare il predefinito per il proprio sistema in /etc/live/build.conf. Si crei semplicemente questo file e si impostino in esso le corrispondenti variabili LB_MIRROR_* per il mirror desiderato. Tutti gli altri mirror utilizzati nella costruzione avranno questi valori, ad esempio:
LB_MIRROR_BOOTSTRAP="http://mirror/debian"
LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security"
LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates"
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.
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
La scelta di LXDE per questo esempio riflette il desiderio di fornire un ambiente desktop minimale, dato che il punto focale dell'immagine è il singolo uso che abbiamo in mente, il browser web. Potremmo anche spingerci oltre e fornire una configurazione predefinita per il browser web in config/includes.chroot/etc/iceweasel/profile/, o pacchetti addizionali di supporto per la fruizione di vari tipi di contenuti web, ma lasciamo questo come esercizio per il lettore.
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.
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.
$ 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 \
--architectures i386 \
--linux-flavours 686-pae \
--package-lists lxde \
"${@}"
Popolare ora l'elenco locale dei pacchetti:
$ echo "iceweasel xchat" >> config/package-lists/my.list.chroot
Per prima cosa, --architectures i386 assicura che sul nostro sistema amd64 costruiamo una versione a 32-bit utilizzabile sulla maggior parte delle macchine. In secondo luogo, usiamo --linux-flavours 686-pae dato che non prevediamo di usare questa immagine su sistemi troppo vecchi. Terzo, abbiamo scelto la lista di pacchetti lxde per avere un desktop minimale. Infine, abbiamo aggiunto due pacchetti preferiti per cominciare: iceweasel e 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."
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
Ora inserire il pacchetto vlc all'elenco locale dei pacchetti 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.
Caso d'uso: creazione di un'immagine con live-build per avviare direttamente un server VNC.
Creare una directory con al suo interno una configurazione scheletrica costruita sulla base dell'elenco di standard-x11, tra cui gdm3, metacity e xvnc4viewer, disabilitando i raccomandati per ottenere un sistema minimale:
$ 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 << END
#!/bin/sh
/usr/bin/metacity &
/usr/bin/xvncviewer 192.168.1.2:1
exit
END
Costruire l'immagine:
# lb build
Buon divertimento.
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.
Ciò che salva più spazio, comparato alla costruzione di un'immagine standard su un sistema con architettura i386, è la selezione del solo kernel 486 invece che quello predefinito -k "486 686-pae". Lasciando fuori anche gli indici di APT con --apt-indices false si può salvare una certa quantità di spazio, il compromesso è usare apt-get update prima di usare apt nel sistema live. Scegliendo la lista minima dei pacchetti si esclude il grosso pacchetto locales e le utilità associate. Saltare i pacchetti raccomandati con --apt-recommends false salva altro spazio, a scapito di alcuni pacchetti che ci si aspetta di trovare, come firmware-linux-free che potrebbe servire a supportare un certo hardware. Le restanti opzioni limano altre piccole quantità di spazio. Sta a voi decidere se le funzionalità sacrificate con ciascuna ottimizzazione valgono la pena.
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.
Il problema iniziale è di scoprire i nomi dei task della lingua appropriati, attualmente, live-build non aiuta in questo. Si può essere fortunati o arrivarci con vari tentativi, ma c'è uno strumento grep-dctrl il quale può essere utilizzato per scavare nelle descrizioni in tasksel-data, perciò assicursi di avere entrambi questi pacchetti:
# 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
Durante l'avvio verrà generata la localizzazione pt_BR.UTF-8 e selezionato il layout di tastiera pt-latin1. Ci sarà anche bisogno di preconfigurare la nostra scelta desktop, "kde" cosicché tasksel installerà il task corretto, che differisce dal predefinito (vedere Task per desktop e lingua). È ora di mettere insieme i pezzi:
$ 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.
This section deals with some general considerations to be taken into account when writing technical documentation for live-manual. They are divided into linguistic features and recommended procedures.
Note: Authors should first read Contributing to this document
Keep in mind that a high percentage of your readers are not native speakers. So as a general rule try to use short, meaningful sentences, followed by a full stop.
This does not mean that you have to use a simplistic, naive style. It is a suggestion to try to avoid, as much as possible, complex subordinate sentences that make the text difficult to understand for non-native speakers.
The most widely spread varieties of English are British and American so it is very likely that most authors will use either one or the other. In a collaborative environment, the ideal variety would be "International English" but it is very difficult, not to say impossible, to decide on which variety among all the existing ones, is the best to use.
We expect that different varieties may mix without creating misunderstandings but in general terms you should try to be coherent and before deciding on using British, American or any other English flavour at your discretion, please take a look at how other people write and try to imitate them.
Do not be biased. Avoid including references to ideologies completely unrelated to live-manual. Technical writing should be as neutral as possible. It is in the very nature of scientific writing.
Try to avoid sexist language as much as possible. If you need to make references to the third person singular preferably use "they" rather than "he" or "she" or awkward inventions such as "s/he", "s(he)" and the like.
Go straight to the point and do not wander around aimlessly. Give as much information as necessary but do not give more information than necessary, this is to say, do not explain unnecessary details. Your readers are intelligent. Presume some previous knowledge on their part.
Keep in mind that whatever you write will have to be translated into several other languages. This implies that a number of people will have to do an extra work if you add useless or redundant information.
As suggested before, it is almost impossible to standardize a collaborative document into a perfectly unified whole. However, every effort on your side to write in a coherent way with the rest of the authors will be appreciated.
Use as many text-forming devices as necessary to make your text cohesive and unambiguous. (Text-forming devices are linguistic markers such as connectors).
It is preferable to describe the point in one or several paragraphs than merely using a number of sentences in a typical "changelog" style. Describe it! Your readers will appreciate it.
Look up the meaning of words in a dictionary or encyclopedia if you do not know how to express certain concepts in English. But keep in mind that a dictionary can either be your best friend or can turn into your worst enemy if you do not know how to use it correctly.
English has the largest vocabulary that exists (With over one million words). Many of these words are borrowings from other languages. When looking up the meaning of words in a bilingual dictionary the tendency of a non-native speaker is to choose the one that sounds more similar in their mother tongue. This often turns into an excessively formal discourse which does not sound quite natural in English.
As a general rule, if a concept can be expressed using different synonyms, it is a good advice to choose the first word proposed by the dictionary. If in doubt, choosing words of Germanic origin (Usually monosyllabic words) is often the right thing to do. Be warned that these two techniques might produce a rather informal discourse but at least your choice of words will be of wide use and generally accepted.
Using a dictionary of collocations is recommended. They are extremely helpful when it comes to know which words usually occur together.
Again it is a good practice to learn from the work of others. Using a search engine to check how other authors use certain expressions may help a lot.
Watch out for false friends. No matter how proficient you are in a foreign language you cannot help falling from time to time in the trap of the so called "false friends", words that look similar in two languages but whose meanings or uses might be completely different.
Try to avoid idioms as much as possible. "Idioms" are expressions that may convey a completely different meaning from what their individual words seem to mean. Sometimes, idioms are difficult to understand even for native speakers!
Even though you are encouraged to use plain, everyday English, technical writing belongs to the formal register of the language.
Try to avoid slang, unusual abbreviations that are difficult to understand and above all contractions that try to imitate the spoken language. Not to mention typical irc and family friendly expressions.
It is important that authors test their examples before adding them to live-manual to ensure that everything works as described. Testing on a clean chroot or VM can be a good starting point. Besides, it would be ideal if the tests were then carried out on different machines with different hardware to spot possible problems that may arise.
When providing an example try to be as specific as you can. An example is, after all, just an example.
It is often better to use a line that only applies to an specific case than using abstractions that may confuse your readers. In this case you can provide a brief explanation of the effects of the proposed example.
There may be some exceptions when the example suggests using some potentially dangerous commands that, if misused, may cause data loss or other similar undesirable effects. In this case you should provide a thorough explanation of the possible side effects.
Links to external sites should only be used when the information on those sites is crucial when it comes to understanding a special point. Even so, try to use links to external sites as sparsely as possible. Internet links are likely to change from time to time resulting in broken links and leaving your arguments in an incomplete state.
Besides, people who read the manual offline will not have the chance to follow those links.
Try to avoid branding as much as possible. Keep in mind that other downstream projects might make use of the documentation you write. So you are complicating things for them if you add certain specific material.
live-manual is licensed under the GNU GPL. This has a number of implications that apply to the distribution of the material (of any kind, including copyrighted graphics or logos) that is published with it.
- Brainstorm!. You need to organize your ideas first in a logical sequence of events.
- Once you have somehow organized those ideas in your mind write a first draft.
- Revise grammar, syntax and spelling.
- Improve your statements and redo any part if necessary.
Use the conventional numbering system for chapters and subtitles. e.g. 1, 1.1, 1.1.1, 1.1.2 ... 1.2, 1.2.1, 1.2.2 ... 2, 2.1 ... and so on. See markup below.
If you have to enumerate a series of steps or stages in your description, you can also use ordinal numbers: First, second, third ... or First, Then, After that, Finally ... Alternatively you can use bulleted items.
And last but not least, live-manual uses SiSU to process the text files and produce a multiple format output. It is recommended to take a look at SiSU's manual to get familiar with its markup, or else type:
$ sisu --help markup
Here are some markup examples that may prove useful:
- For emphasis/bold text:
*{foo}* or !{foo}!
produces: foo or foo. Use it to emphasize certain key words.
- For italics:
/{foo}/
produces: foo. Use them e.g. for the names of debian packages.
- For monospace:
#{foo}#
produces: foo. Use it e.g. for the names of commands. And also to highlight some key words or things like paths.
- For code blocks:
code{
$ foo
# bar
}code
produces:
$ foo
# bar
Use code{ to open and }code to close the tags. It is important to remember to leave a space at the beginning of each line of code.
This section deals with some general considerations to be taken into account when translating the contents of live-manual.
As a general recommendation, translators should have read and understood the translation rules that apply to their specific languages. Usually, translation groups and mailing lists provide information on how to produce translated work that complies with Debian quality standards.
Note: Translators should also read Contributing to this document. In particular the section Translation
The role of the translator is to convey as faithfully as possible the meaning of words, sentences, paragraphs and texts as written by the original authors into their target language.
So they should refrain from adding personal comments or extra bits of information of their own. If they want to add a comment for other translators working on the same documents, they can leave it in the space reserved for that. That is, the header of the strings in the po files preceded by a number sign #. Most graphical translation programs can automatically handle those types of comments.
It is perfectly acceptable however, to include a word or an expression in brackets in the translated text if, and only if, that makes the meaning of a difficult word or expression clearer to the reader. Inside the brackets the translator should make evident that the addition was theirs using the abbreviation "TN" or "Translator's Note".
Documents written in English make an extensive use of the impersonal form "you". In some other languages that do not share this characteristic, this might give the false impression that the original texts are directly addressing the reader when they are actually not doing so. Translators must be aware of that fact and reflect it in their language as accurately as possible.
The trap of "false friends" explained before especially applies to translators. Double check the meaning of suspicious false friends if in doubt.
Translators working initially with pot files and later on with po files will find many markup features in the strings. They can translate the text anyway, as long as it is translatable, but it is extremely important that they use exactly the same markup as the original English version.
Some translators decide to include the code blocks in the translated files because it is easier for them to identify what has already been translated and what has not by looking at the percentages if they use a graphical translation program.
Include the code blocks if you want to score a 100% complete translation.
On the other hand some translators prefer to leave the code blocks "untranslated" (i.e. not including them). This makes the translation easier to maintain once finished because it does not require translators intervention if the code changes.
Leave the code blocks empty (they will be automatically added then) if you want to make your translation easier to maintain.
The translated texts need to have the exact same newlines as the original texts. Be careful to press the "Enter" key or type \n if they appear in the original files. These newlines often appear, for instance, in the code blocks.
Make no mistake, this does not mean that the translated text needs to have the same length as the English version. That is nearly impossible.
Translators should never translate:
- The code names of releases
- The names of programs
- The commands given as examples
- Metadata (often between colons :metadata:)
- Links
- Paths