MANUAL DEBIAN LIVE
******************
SOBRE AQUEST MANUAL
===================
1. SOBRE AQUEST MANUAL
----------------------
Aquest manual serveix com a punt d'accés únic a tota la documentació
relacionada amb el projecte Debian Live i en particular s'aplica al programari
produït pel projecte per la versió Debian 7.0 "*wheezy*". Una versió
actualitzada es pot trobar sempre a
Si bé /live-manual/ es centra principalment en ajudar a construir un sistema
viu i no en temes dels usuaris finals, un usuari final pot trobar informació
útil en aquestes seccions: Conceptes bàsics abasta la descàrrega d'imatges
prefabricades i la preparació de les imatges per ser arrencades des dels
dispositius o la xarxa, ja sigui utilitzant el servei de construcció d'imatges
web o executant /live-build/ directament en el sistema. Personalització dels
comportaments en temps d'execució descriu algunes de les opcions que es poden
especificar durant l'arrencada del sistema, com ara la selecció de la
disposició del teclat, la configuració regional i l'ús de la persistència.
Algunes de les ordres esmentades en el text s'han d'executar amb privilegis de
superusuari que es poden obtenir esdevenint l'usuari root amb su o mitjançant
l'ús de sudo. Per distingir entre les ordres que poden ser executades per un
usuari sense privilegis i aquelles que requereixen privilegis de superusuari,
s'anteposa $ o # respectivament. Aquest símbol no és part de l'ordre.
1.1 PER ALS IMPACIENTS
......................
Si bé creiem que tot el que hi ha en aquest manual és important, si més no, per
alguns dels nostres usuaris, ens adonem que hi ha una gran quantitat de
material per cobrir i que és possible que es vulgui experimentar l'èxit amb el
programari aviat, abans d'aprofundir en els detalls. Per tant, us recomanem
llegir en el següent ordre.
En primer lloc, llegir aquest capítol, Sobre aquest manual, des del principi i
acabant amb els Termes. A continuació, saltar als tres tutorials abans dels
Exemples, secció pensada per ensenyar com fer la construcció d'una imatge i
alguns aspectes bàsics de la personalització. Llegir en primer lloc Ús dels
exemples seguit per Tutorial 1: Una imatge per defecte, Tutorial 2: Una
utilitat de navegador web i finalment, Tutorial 3: Una image personalitzada. Al
final d'aquests tutorials, es tindrà una idea del que es pot fer amb Debian
Live.
Us animem a tornar i a fer un estudi del manual en profunditat, la propera
lectura pot ser Conceptes bàsics, fregant o saltant Construir una imatge
netboot, i acabant per la lectura de la Visió general de la personalització i
els capítols que segueixen. En aquest punt, esperem que estigueu ben emocionats
pel que es pot fer amb Debian Live i motivats per llegir la resta del manual,
de principi a fi.
1.2 TERMES
..........
* *Sistema viu*: Un sistema operatiu que pot arrencar sense necessitat
d'instaŀlació en un disc dur. Els sistemes vius no alteren el sistema operatiu
local(s) o els fitxer(s) ja instaŀlats al disc dur de l'ordinador a menys que
així se'ls ho indiqui. Els sistemes vius normalment s'inician des de
dispositius, com ara CD, DVD o memòries USB. Alguns també poden arrencar des de
la xarxa.
* *Medi en viu*: A diferència de sistema en viu, el medi en viu es refereix al
CD, DVD o memòria USB on es copia el fitxer binari produït per /live-build/ i
utilitzat per arrencar el sistema en viu. Més àmpliament, el terme també es
refereix a qualsevol lloc on resideix el fitxer binari als efectes d'iniciar el
sistema en viu, com ara la ubicació dels fitxers per arrencar en xarxa.
* *Debian Live*: Un subprojecte de Debian, que manté, entre altres, els paquets
/live-boot/, /live-build/, /live-config/, /live-tools/ i /live-manual/.
* *Sistema Debian Live*: Un sistema viu que utilitza el programari del sistema
operatiu Debian que es pot arrencar des d'un CD, DVD, memòries USB, o la xarxa
(utilitzant imatges netboot) i a través d'Internet (mitjançant el paràmetre
d'arrencada fetch=URL).
* *Sistema amfitrió*: L'entorn utilitzat per crear el sistema en viu.
* *Sistema objectiu*: L'entorn que s'utilitza per executar el sistema en viu.
* */live-boot/*: Una coŀlecció de scripts per arrencar els sistemes vius.
* */live-build/*: Una coŀlecció d'scripts utilitzats per construir sistemes
Debian Live personalitzats.
* */live-config/*: Una coŀlecció de scripts utilitzats per configurar un
sistema en viu durant el procés d'arrencada.
* */live-tools/*: Una coŀlecció d'scripts addicionals que s'utilitzen per
realitzar tasques útils en un sistema viu en execució.
* */live-manual/*: Aquest document és mantingut en un paquet anomenat
/live-manual/
* *Instaŀlador de Debian (d-i)*: El sistema oficial d'instaŀlació de la
distribució Debian.
* *Paràmeters d'arrencada*: Els paràmetres que es poden introduir a l'indicador
del carregador d'arrencada per influir en el nucli o /live-config/
* *chroot*: El programa /chroot/, chroot(8), ens permet executar diferentes
instàncies d'un entorn GNU/Linux a la vegada en un sol sistema sense reiniciar.
* *Imatge binaria*: Un fitxer que conté el sistema en viu, com ara binary.iso o
binary.img.
* *Distribució objectiu*: La distribució en què es basa el sistema en viu. Que
pot diferir de la distribució del sistema amfitrió.
* *stable/testing/unstable*: La distribució *stable* conté l'última distribució
de Debian llençada oficialment. La distribució *testing* és l'àrea d'assaig per
a la pròxima versió *stable*. Un avantatge important de l'ús d'aquesta
distribució és que té versions més recents del programari en relació amb
l'edició *stable*. La distribució *unstable* és on es produeix el
desenvolupament actiu de Debian. En general, aquesta distribució és utilitzada
pels desenvolupadors i els que els agrada viure en risc. Al llarg del manual,
es tendeix a utilitzar els seus noms en clau, com ara *wheezy* o *sid*, ja que
és el que fan servir les pròpies eines.
1.3 AUTORS
..........
Llistat d'autors (en ordre alfabètic)
* Ben Armstrong
* Brendan Sleight
* Carlos Zuferri
* Chris Lamb
* Daniel Baumann
* Franklin Piat
* Jonas Stein
* Kai Hendry
* Marco Amadori
* Mathieu Geli
* Matthias Kirschner
* Richard Nelson
* Trent W. Buck
1.4 CONTRIBUIR A AQUEST DOCUMENT
................................
Aquest manual està pensat com un projecte comunitari i totes les propostes per
millorar-lo i les contribucions són molt benvingudes. Veure la secció
Contribuir al projecte per obtenir informació detallada sobre com obtenir la
clau i fer bons commits.
1.4.1 APLICAR CANVIS
....................
Per tal de realitzar canvis en el manual anglès s'ha d'editar els fitxers
adequats a manual/en/ però abans de presentar una contribució, s'ha de
previsualitzar el treball. Per previsualitzar el /live-manual/, assegurar-se
que s'han instaŀlat els paquets necessaris per a la seva construcció mitjançant
l'execució de:
# apt-get install make po4a ruby ruby-nokogiri sisu-complete texlive-generic-recommended
Es pot crear el /live-manual/ des del directori de nivell superior del arbre
Git mitjançant l'execució de:
$ make build
Com es necessita un cert temps per construir el manual en tots els idiomes
suportats, potser resulti convenient quan es fa una prova construir un sol
idioma, per exemple, mitjançant l'execució de:
$ make build LANGUAGES=en
També es possible crear per tipus de document, per exemple:
$ make build FORMATS=pdf
O combinar tot dos, per exemple:
$ make build LANGUAGES=de FORMATS=html
Després de revisar el treball i assegurar-se que tot està bé, no fer un make
commit a menys que s'actualitzin les traduccions al mateix temps, i en aquest
cas, no barrejar els canvis al manual anglès i les traduccions en el mateix
commit, fer-ne un altre separat per cada canvi. Veure la secció Traducció per a
més detalls.
1.4.2 TRADUCCIó
...............
Per començar la traducció d'un idioma nou, seguir aquests passos:
* Traduir els fitxers *about_manual.ssi.pot*, *about_project.ssi.pot* i
*index.html.in.pot* a la vostra llengua amb el vostre editor favorit (per
exemple /poedit/) . Enviar els fitxers .po traduïts a la llista de correu
perquè l'equip de traducció pugui comprovar la seva integritat.
* Per activar una nova llengua al autobuild, només cal afegir els fitxers
inicials traduïts a manual/po/${LANGUAGE}/ i executar make commit. I llavors
editar manual/_sisu/home/index.html.
* Una vegada que s'ha afegit la nova llengua, es pot continuar traduint la
resta de fitxers dins de manual/po/ a l'atzar.
* No oblidar que es necessari fer un make commit per garantir que els manuals
traduïts s'actualitzin a partir dels fitxers po i llavors es poden revisar els
canvis executant make build abans de git add ., git commit -m "Translating..."
i git push.
Després d'executar make commit es podrà veure bastant text a la pantalla.
Bàsicament són missatges informatius sobre l'estat del procés i també algunes
pistes sobre el que es pot fer per millorar /live-manual/. Si no es veu cap
error fatal, generalment es pot procedir i enviar la contribució.
/live-manual/ ve amb dues utilitats que poden ser de gran ajuda pels traductors
a l'hora de trobar missatges sense traduir i difusos. La primera és "make
translate". Aquesta activa un script que diu en detall quants missatges sense
traduir hi ha a cada fitxer po. La segona, "make fixfuzzy", només actua sobre
els missatges difusos però ajuda a trobar-los i corregir-los un per un.
Tenir en compte que tot i que aquestes utilitats poden ser molt útils per fer
traduccions en la línia d'ordres, l'ús d'una eina especialitzada com /poedit/
és la manera recomanada de fer la tasca. També és una bona idea llegir la
documentació de localització de debian (l10n) i, específicament dins
/live-manual/, les Directrius per a traductors.
*Nota:* Es pot utilitzar make clean per netejar l'arbre git abans de fer un
push. Aquest pas no és obligatori, gràcies al fitxer .gitignore, però és una
bona pràctica per evitar enviar fitxers de forma involuntària.
2. SOBRE EL PROJECTE DEBIAN LIVE
--------------------------------
2.1 MOTIVACIó
.............
2.1.1 QUè PASSA AMB ELS SISTEMES VIUS ACTUALS
.............................................
Quan Debian Live va començar, ja hi havia diversos sistemes vius basats en
Debian disponibles i que estaven fent una gran feina. Des de la perspectiva de
Debian la majoria d'ells tenien un o més dels desavantatges següents:
* No són projectes de Debian i per tant no tenen suport des de Debian.
* Es barregen diferents distribucions, per exemple *testing* i *unstable*.
* Només donen suport a i386.
* Es modifique el comportament i/o l'aparença dels paquets, per estalviar
espai.
* S'inclouen paquets de fora de l'arxiu de Debian.
* Inclouen nuclis personalitzats amb pedaços addicionals que no són part de
Debian.
* Són grans i lents pel seu gran tamany i per tant no aptes com a sistemes de
rescat.
* No estan disponibles en diferents formats, per exemple, CD, DVD, memòries USB
i imatges netboot.
2.1.2 PER QUè CREAR EL NOSTRE PRòPI SISTEMA VIU?
................................................
Debian és el sistema operatiu universal: Debian té un sistema viu per mostrar
arreu i per representar acuradament el sistema Debian amb els següents
avantatges:
* Es tracta d'un subprojecte de Debian.
* Reflecteix l'estat (actual) d'una distribució.
* Funciona en tantes arquitectures com és possible.
* Es tracta només de paquets Debian sense modificacions.
* No conté paquets que no són a l'arxiu de Debian.
* S'utilitza un nucli Debian sense alteracions i sense pedaços addicionals.
2.2 FILOSOFIA
.............
2.2.1 NOMéS PAQUETS DEBIAN SENSE MODIFICACIONS DE LA SECCIó "MAIN"
..................................................................
Només farem servir els paquets del repositori de Debian de la secció "main". La
secció non-free no és part de Debian i per tant no es pot utilitzar per les
imatges oficials del sistema viu.
No canviarem cap paquet. Cada vegada que hàgim de canviar alguna cosa, ho farem
en coordinació amb el mantenidor del paquet a Debian.
Com a excepció, els nostres propis paquets, com ara /live-boot/, /live-build/ o
/live-config/ poden ser utilitzats temporalment des del nostre propi repositori
per raons de desenvolupament (per exemple, per crear instantànies de
desenvolupament). Aquests paquets es pujaran a Debian de forma regular.
2.2.2 PAQUETS DEL SISTEMA VIU SENSE CAP CONFIGURACIó
....................................................
En aquesta fase no es publicarà o s'instaŀlarà cap configuració alternativa o
d'exemple. Tots els paquets són utilitzats en la seva configuració per defecte,
tal com són després d'una instaŀlació normal de Debian.
Cada vegada que ens calgui una configuració per defecte diferent, ho farem en
coordinació amb el mantenidor del paquet Debian.
S'hi inclou un sistema per configurar paquets mitjançant debconf que permet
instaŀlar paquets configurats de forma personalitzada dins d'una imatge Debian
Live, però per a les imatges en viu prefabricades només utilitzarem una
configuració per defecte, a menys que sigui absolutament necessari per poder
treballar en l'entorn en viu. Sempre que sigui possible, preferim adaptar els
paquets a l'arxiu de Debian perquè funcionin en un sistema en viu abans que
realitzar canvis en la cadena d'eines en viu o en les configuracions de les
imatges prefabricades. Per obtenir més informació, veure Visió general de la
personalització.
2.3 CONTACTE
............
* *Llista de correu*: El contacte principal del projecte és la llista de correu
a . Es pot enviar un correu directament a
Els arxius de la llista són a
.
* *IRC*: Un nombre d'usuaris i desenvolupadors estan presents al canal
#debian-live a irc.debian.org (OFTC). Quan es pregunta al IRC, s'ha de tenir
paciència esperant una resposta, si no hi ha cap resposta, es pot enviar un
correu a la llista.
* *BTS*: ElSistema de seguiment d'errors de
Debian⌡ (BTS) conté detalls d'errors notificats
per usuaris i desenvolupadors. A cada error se li assigna un número i es manté
a l'arxiu fins que es marca com tractat. Per obtenir més informació, vegeu
⌠Informar dels errors.
USUARI
======
3. INSTAŀLACIó
--------------
3.1 REQUISITS
.............
La construcció d'imatges Debian Live té molts pocs requisits.
* Accés de superusuari (root)
* Una versió actualitzada de /live-build/
* Una shell compatible amb POSIX, com ara /bash/ o /dash/
* /debootstrap/ o /cdebootstrap/
* Linux 2.6.x o superior.
Tenir en compte que no cal usar Debian o una distribució derivada de Debian ja
que /live-build/ funcionarà en gairebé qualsevol distribució amb els requisits
anteriors.
3.2 INSTAŀLACIó DE LIVE-BUILD
.............................
Es pot instaŀlar /live-build/ en un nombre de maneres diferentes:
* Des del repositori Debian
* A partir del codi font
* A partir d'instantànies
Si s'utilitza Debian, la manera recomanada és instaŀlar /live-build/ des del
repositori de Debian.
3.2.1 DES DEL REPOSITORI DE DEBIAN
..................................
Només cal instaŀlar /live-build/ com qualsevol altre paquet:
# apt-get install live-build
3.2.2 A PARTIR DEL CODI FONT
............................
/live-build/ es desenvolupa utilitzant el sistema de control de versions Git.
En els sistemes basats en Debian, això és proporcionat pel paquet git. Per
comprovar l'últim codi, executar:
$ git clone git://live.debian.net/git/live-build.git
Es pot construir i instaŀlar un paquet Debian pròpi mitjançant l'execució de:
$ cd live-build
$ dpkg-buildpackage -b -uc -us
$ cd ..
Ara instaŀlar qualsevol dels fitxers .deb recent construïts que ens interessen,
per exemple,
# dpkg -i live-build_3.0-1_all.deb
Es pot instaŀlar /live-build/ directament al sistema mitjançant l'execució de:
# make install
i desinstaŀlar amb:
# make uninstall
3.2.3 A PARTIR D'INSTANTàNIES
.............................
Si no es desitja construir o instaŀlar /live-build/ a partir de les fonts, es
pot utilitzar les instantànies. Aquestes es construeixen automàticament a
partir de l'última versió del Git, i estan disponibles a
.
3.3 INSTAL.LACIó DE LIVE-BOOT I LIVE-CONFIG
...........................................
*Nota:* No cal instaŀlar /live-boot/ o /live-config/ en el sistema per crear
sistemes personalitzats de Debian Live. No obstant, això no farà cap mal i és
útil per a fins de referència. Si només es vol la documentació, ara es poden
instaŀlar els paquets /live-boot-doc/ i /live-config-doc/ per separat.
3.3.1 DES DEL REPOSITORI DE DEBIAN
..................................
Tots dos, /live-boot/ i /live-config/, estan disponibles al arxiu de Debian,
d'una manera similar a Instaŀlació de live-build.
3.3.2 A PARTIR DEL CODI FONT
............................
Per utilitzar les darreres fonts del git, es pot seguir el procés seguent.
Assegurar-se d'estar familiaritzat amb els termes esmentats a Termes.
* Clonar les fonts de /live-boot/ i /live-config/
$ git clone git://live.debian.net/git/live-boot.git
$ git clone git://live.debian.net/git/live-config.git
Consultar les pàgines del manual de /live-boot/ i /live-config/ per més detalls
sobre la seva personalització si aquesta és la raó per construir aquests
paquets a partir de les fonts.
* Crear els fitxers .deb de /live-boot/ i /live-config/
S'ha de crear ja sigui en la distribució de destinació o en un chroot que
contingui la plataforma de destinació: és a dir, si el objectiu és *wheezy*
llavors s'ha de construir contra *wheezy*.
Es pot utilitzar un constructor personal, com ara /pbuilder/ o /sbuild/ si es
necessita crear /live-boot/ per a una distribució de destinació diferenta del
sistema de construcció. Per exemple, per a les imatges en viu de *wheezy*,
crear /live-boot/ en un chroot *wheezy*. Si la distribució de destinació per
casualitat coincideix amb la distribució del sistema de construcció, es pot
construir directament en el sistema de construcció amb dpkg-buildpackage
(proporcionat pel paquet /dpkg-dev/) :
$ cd live-boot
$ dpkg-buildpackage -b -uc -us
$ cd ../live-config
$ dpkg-buildpackage -b -uc -us
* Utilitzar tots el fitxers .deb generats que calguin
Com /live-boot/ y /live-config/ són instaŀlats per el sistema de construcció
/live-build/, la instaŀlació dels paquets en el sistema amfitrió no és
suficient: s'ha de tractar els .deb generats com si fossin uns paquets
personalitzats. Ja que el propòsit per construir aquests paquets a partir del
codi font és per provar coses noves a curt termini abans del llançament
oficial, seguir els pasos de Instaŀlació de paquets modificats o de tercers per
incloure temporalment els paquets rellevants en la configuració. En particular,
cal observar que ambdós paquets es divideixen en una part genèrica, una part de
documentació i un o més back-ends. Incloure la part genèrica, només un dels
back-ends que coincideixi amb la configuració, i, opcionalment, la
documentació. Suposant que s'està construint una imatge en viu en el directori
actual i que s'han generat tots els .deb per a una única versió dels dos
paquets al directori superior, aquestes ordres de bash són per copiar tots els
paquets importants, incloent-hi els back-ends per defecte:
$ cp ../live-boot{_,-initramfs-tools,-doc}*.deb config/packages.chroot/
$ cp ../live-config{_,-sysvinit,-doc}*.deb config/packages.chroot/
3.3.3 A PARTIR D'INSTANTàNIES
.............................
Es pot deixar que /live-build/ utilitzi les darreres instantànies de
/live-boot/ i /live-config/ configurant un repositori de tercers en el
directori de configuració de /live-build/. Suposant que ja s'ha creat un arbre
de configuració del directori actual amb lb config:
$ lb config --archives live.debian.net
4. CONCEPTES BàSICS
-------------------
Aquest capítol conté una breu descripció del procés de construcció i les
instruccions per a l'utilització dels tres tipus d'imatge més comunes. El tipus
d'imatge més versàtil iso-hybrid es pot utilitzar en una màquina virtual, en un
medi òptic o qualsevol altre dispositiu d'emmagatzematge USB. En certs casos
especials, com s'explica més endavant, el tipus hdd pot ser el més adequat. El
capítol acaba amb instruccions per a la construcció d'una imatge tipus netboot,
que és una mica més complicat a causa de la configuració necessària en el
servidor. Aquest és un tema una mica avançat per a algú que no està
familiaritzat ja amb l'arrencada en xarxa, però s'inclou aquí perquè un cop que
la configuració es porta a terme, es tracta d'una forma molt convenient per
provar i desplegar imatges per a l'arrencada en xarxa local sense la molèstia
de tractar amb els dispositius de les imatges.
Al llarg del capítol, sovint es fa referència als noms dels fitxers produïts
per defecte per /live-build/. Si es descarrega una imatge prefabricada, els
noms dels fitxers poden ser direrents.
4.1 QUè éS UN SISTEMA VIU?
..........................
Un sistema viu és un sistema operatiu que arrenca en un equip des d'un
dispositiu extraïble, com un CD-ROM o una memòria USB o des d'una xarxa, a punt
per fer servir sense cap tipus d'instaŀlació en la unitat(s) habitual(s), amb
una configuració automàtica feta en temps d'execució (veure Termes).
Amb Debian Live, és un sistema operatiu Debian GNU/Linux, construït per una de
les arquitectures suportades (actualment amd64 i i386). Conté les següents
parts:
* *Imatge del nucli Linux*, generalment s'anomena vmlinuz*
* *Imatge del disc RAM inicial (initrd)*: un disc RAM configurat per a
l'arrencada de Linux, que conté els mòduls que possiblement es necessitaran per
muntar la imatge del sistema i algunes seqüències d'ordres per fer-ho.
* *Imatge del sistema*: Imatge del sistema de fitxers del sistema operatiu.
Normalment, s'utilitza un sistema de fitxers comprimit SquashFS per minimitzar
la mida de la imatge Debian Live. Tenir en compte que és de només lectura.
Així, durant l'arrencada, el sistema Debian Live utilitzarà el disc RAM i un
mecanisme de "unió" per permetre l'escriptura de fitxers en el sistema en
funcionament. No obstant això, totes les modificacions es perdran al apagar
l'equip si no és que s'utilitza la persistència opcional (vegeu Persistència).
* *Carregador d'arrencada *: Una petita peça de codi dissenyat per arrencar des
del medi triat, possiblement presentant un indicador d'arrencada o un menú per
permetre la selecció d'opcions/configuració. Carrega el nucli de Linux i el seu
initrd per funcionar amb un sistema de fitxers del sistema associat. Es poden
utilitzar diverses solucions, en funció del medi de destinació i el format del
sistema de fitxers que conté els components esmentats anteriorment: isolinux
per arrencar des de CD o DVD en format ISO9660, syslinux per una unitat USB o
HDD que s'iniciarà des de particions VFAT, extlinux per particions ext2/3/4 i
btrfs, pxelinux per PXE netboot, GRUB per particions ext2/3/4, etc.
Es pot utilitzar /live-build/ per construir la imatge del sistema amb
especificacions pròpies, configurar un nucli de Linux, el initrd, i un
carregador d'arrencada per executar-los, tot això en un format depenent del
medi (imatge ISO9660, imatge de disc, etc.).
4.2 DESCàRREGA D'IMATGES PREFABRICADES
......................................
Si bé l'objectiu d'aquest manual és el desenvolupament i la construcció
d'imatges en viu pròpies, es pot simplement voler provar una de les nostres
imatges prefabricades, ja sigui com una introducció al seu ús o a la
construcció d'imatges personalitzades. Aquestes imatges estan construïdes
utilitzant el nostre repositori git live-images i les versions oficials
estables es publiquen a . A més, les versions
antigues i les futures, i les imatges no oficials que contenen microprogramari
i controladors no lliures estan disponibles a
.
4.3 ÚS DEL SERVEI DE CONSTRUCCIó D'IMATGES EN VIU WEB
.....................................................
Com un servei a la comunitat, oferim un servei web capaç de construïr imatges
en viu a . Aquest lloc es mantingut sobre una
base del millor esforç. És a dir, encara que ens esforcem per mantenir-lo al
dia i que estigui operatiu en tot moment, i de fer anuncis d'interrupcions
importants del servei, no podem garantir una disponibilitat del 100% o una
creació d'imatges ràpida. Tanmateix, el servei pot tenir, de tant en tant,
problemes que triguin algun temps en resoldre's. Si es té problemes o preguntes
sobre aquest servei, posar-se en contacte amb nosaltres, proporcionant l'enllaç
a la pàgina web de la imatge construïda.
4.3.1 ÚS I ADVERTèNCIES SOBRE EL SERVEI WEB
...........................................
La interfície web actualment no pot prevenir l'ús de combinacions d'opcions no
vàlides, i en particular, quan el canvi d'una opció que normalment (és a dir,
utilitzant /live-build/ directament) canviaria els valors predeterminats
d'altres opcions que figuren en el formulari de la web, el constructor web no
canvia aquests valors predeterminats. En particular, si es canvia
--architectures del valor per defecte i386 a amd64, s'ha de canviar l'opció
corresponent --linux-flavours del valor per defecte 486 a amd64. Veure la
pàgina del manual lb_config per a la versió de /live-build/ instaŀlada al
constructor web per més detalls. El nombre de la versió de /live-build/ apareix
a la part inferior de la pàgina web.
El càlcul de temps donat pel constructor web és només una estimació aproximada
i pot no reflectir acuradament el temps que realment es necessita per
finalitzar la construcció d'una imatge. Tenir en compte que aquesta estimació
tampoc s'actualitza tal i com va passant el temps. Cal tenir una mica de
paciència. No tornar a carregar la pàgina després de enviar la proposta de
construcció, ja que això pot tornar a reenviar una nova petició amb els
mateixos paràmetres. Posar-se en contacte amb nosaltres si no es rep la
notificació de la construcció un cop que s'estigui segur que s'ha esperat prou
i verificat que la notificació per correu electrònic no ha anat a parar al
spam.
El servei web està limitat en el tipus d'imatges que es poden construir. Això
el manté simple i eficient d'utilitzar i mantenir. Si es desitja realitzar
personalitzacions que no es contemplen en la interfície web, a la resta
d'aquest manual s'explica com crear imatges pròpies amb /live-build/.
4.4 PRIMERS PASSOS: CONSTRUCCIó D'UNA IMATGE ISO HíBRIDA
........................................................
Independentment del tipus d'imatge, s'haurà de fer els mateixos passos bàsics
per construir una imatge cada vegada. Com a primer exemple, crear un directori
de treball, canviar a aquest directori i executar la següent seqüència d'ordres
/live-build/ per crear una imatge ISO híbrida de base que conté només el
sistema per defecte de Debian sense X.org. És adequat per gravar en un CD o
DVD, i també per copiar en una memòria USB.
El nom del directori de treball és absolutament indiferent, però si es fa un
cop d'ull als exemples utilitzats a /live-manual/, és una bona idea utilitzar
un nom que ajudi a identificar la imatge amb que s'està treballant en cada
directori, especialment si s'està treballant o experimentant amb diferents
tipus d'imatges. En aquest cas, anem a construir un sistema per defecte així
que l'anomenarem, per exemple, live-default.
$ mkdir live-default && cd live-default
Aleshores, executar l'ordre lb config. Això crearà una jerarquia «config/» en
el directori actual per ser utilitzada per altres ordres:
$ lb config
Aquí no es passa cap paràmetre a lb config, per tant s'utilitzaran les opcions
per defecte. Veure L'ordre lb config per més detalls.
Ara que la jerarquia «config/» ja existeix, crear la imatge amb l'ordre lb
build:
# lb build
Aquest procés tardarà una mica, depenent de la velocitat del ordinador i de la
connexió de la xarxa. Quan hagi acabat, ha d'haver un fitxer imatge
binary.hybrid.iso, a punt per ser utilitzar, en el directori actual.
4.5 USAR UNA IMATGE ISO HíBRIDA EN VIU
......................................
Després de la construcció o la descàrrega d'una imatge ISO híbrida, que pot ser
obtinguda a , el següent pas habitual és
preparar el dispositiu per a l'arrencada, ja sigui medis òptics com un CD-R(W)
o DVD-R(W) o una memòria USB.
4.5.1 GRAVAR UNA IMATGE ISO EN UN MEDI FíSIC
............................................
Gravar una imatge ISO és fàcil. Simplement cal instaŀlar /xorriso/ i
utilitzar-lo des de la línia d'ordres per gravar la imatge. Per exemple:
# apt-get install xorriso
$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed binary.hybrid.iso
4.5.2 CòPIAR UNA IMATGE ISO HíBRIDA EN UN DISPOSITIU USB
........................................................
Les imatges ISO preparades amb xorriso, és poden copiar directament a una
memòria USB utilitzant el programa dd o un altre d'equivalent. Connectar una
memòria USB amb una mida prou gran per al fitxer de la imatge i determinar quin
dispositiu és, que d'ara endavant anomenarem ${USBSTICK}. Aquest és el
dispositiu de la memòria com per exemple /dev/sdb, no una partició, com ara
/dev/sdb1! Es pot trobar el nom del dispositiu correcte mirant la sortida de
dmesg després de connectar la memòria usb o encara millor, ls -l
/dev/disk/by-id.
Quan s'estigui segur de tenir el nom del dispositiu correcte, utilitzar l'ordre
dd per a copiar la imatge a la memòria. *Fent això es perdran definitivament
tots els continguts anteriors de la memòria usb!*
$ dd if=binary.hybrid.iso of=${USBSTICK}
4.5.3 UTILITZAR L'ESPAI LLIURE EN UNA MEMòRIA USB
.................................................
Per poder utilitzar l'espai que queda lliure després de copiar
binary.hybrid.iso en un dispositiu USB, utilitzar una eina de particionament
com /gparted/ o /parted/ per crear una nova partició. La primera partició serà
utilitzada pel sistema Debian Live.
# gparted ${USBSTICK}
Després de crear la partició, on ${PARTITION} és el nom de la partició, com ara
/dev/sdb2, s'ha de crear un sistema de fitxers. Una opció possible seria ext4.
# mkfs.ext4 ${PARTITION}
*Nota:* Si es vol utilitzar l'espai addicional amb Windows, pel que sembla,
aquest sistema operatiu normalment no pot accedir a altres particions més que a
la primera. Algunes solucions a aquest problema han estat discutides a la
nostra llista de correu, però sembla que no hi ha respostes fàcils.
*Recordar: Cada vegada que s'instaŀli una nova binary.hybrid.iso al dispositiu,
es perdran totes les dades perquè la taula de particions se sobreescriu amb el
contingut de la imatge, de manera que es assenyat fer una còpia de seguretat de
la partició addicional per restaurar les dades de nou després d'actualitzar la
imatge en viu.*
4.5.4 ARRENCAR EL MEDI EN VIU
.............................
La primera vegada que s'arrenqui el medi en viu, ja sigui des de CD, DVD,
memòria USB, o PXE, pot ser necessaria alguna petita configuració al BIOS del
ordinador en primer lloc. Atès que les BIOS varien molt en les seves funcions i
dreceres de teclat, no podem entrar en el tema en profunditat aquí. Algunes
BIOS proporcionen una tecla per obrir un menú de dispositius d'arrencada, que
és la manera més fàcil si es troba disponible al sistema. En cas contrari, cal
entrar al menú de configuració del BIOS i canviar l'ordre d'arrencada per
situar el dispositiu del sistema en viu abans que el dispositiu d'arrencada
normal.
Després d'arrencar des del dispositiu, es veurà un menu d'inici. Si es prem
«entrer» el sistema s'iniciarà amb l'entrada Live i les seves opcions per
defecte. Per obtenir més informació sobre les opcions d'arrencada, llegir
«l'ajuda» (help) al menú i també les pàgines del manual de /live-boot/ i
/live-config/ que es troben dins del sistema en viu.
Suposant que s'ha seleccionat Live i s'ha arrencat una imatge d'escriptori per
defecte, després que els missatges d'arrencada hagin passat s'haurà iniciat una
sessió com a usuari user i es veurà un escriptori, a punt per ser utilitzat. Si
s'ha arrencat una imatge de només consola, com les imatges prefabricades,
standard o rescue s'iniciarà una sessió com a usuari user i es veurà el
indicador de la shell, a punt per ser utilitzat.
4.6 UTILITZAR UNA MàQUINA VIRTUAL PER FER PROVES
................................................
Pot ser un gran estalvi de temps per al desenvolupament d'imatges en viu
executar-les en una màquina virtual (VM). Això no està exempt d'advertiments:
* L'execució d'una màquina virtual requereix de suficient memòria RAM, tant per
al sistema operatiu convidat i l'amfitrió i es recomana una CPU amb suport de
maquinari per a la virtualització.
* Hi ha algunes limitacions inherents a l'execució en una màquina virtual, per
exemple, rendiment de vídeo pobre, opcions limitadades de maquinari emulat.
* En el desenvolupament per a un maquinari específic, no hi ha cap substitut
millor que el propi maquinari.
* De tant en tant hi ha errors que només sorgeixen durant l'execució en una
màquina virtual. En cas de dubte, comprovar la imatge directament al maquinari.
Sempre que es pugui treballar dins d'aquestes limitacions, examinar el
programari de màquina virtual disponible i triar un que sigui adequat per a les
necessitats pròpies.
4.6.1 PROVAR UNA IMATGE ISO AMB QEMU
....................................
La màquina virtual més versàtil dins Debian és QEMU. Si el processador té
suport de maquinari per a la virtualització, utilitzar el paquet /qemu-kvm/; la
descripció del paquet /qemu-kvm/ enumera breument els requisits.
Primer, instaŀlar /qemu-kvm/ si el processador ho suporta. Si no, instaŀlar
/qemu/, en aquest cas el nom del programa és qemu en lloc de kvm en els
exemples següents. El paquet /qemu-utils/ també és valuós per a la creació
d'imatges de disc virtuals amb qemu-img.
# apt-get install qemu-kvm qemu-utils
Arrencar una imatge ISO és senzill:
$ kvm -cdrom binary.hybrid.iso
Veure les pàgines del manual per a més detalls
4.6.2 PROVAR UNA IMATGE ISO AMB VIRTUALBOX
..........................................
Per provar la ISO amb /virtualbox/:
# apt-get install virtualbox virtualbox-qt virtualbox-dkms
$ virtualbox
Crear una nova màquina virtual, canviar els paràmetres d'emmagatzematge per
utilitzar binary.hybrid.iso com unitat de CD/DVD i arrencar la màquina.
*Nota:* Per provar sistemes vius que contenen X.org amb /virtualbox/,
segurament es assenyat incloure el paquet del driver VirtualBox X.org,
/virtualbox-guest-dkms/ i /virtualbox-guest-x11/, en la configuració de
/live-build/. En cas contrari, la resolució es limita a 800x600.
$ echo "virtualbox-guest-dkms virtualbox-guest-x11" >> config/package-lists/my.list.chroot
Per tal de fer que el paquet dkms funcioni, s'han d'instaŀlar també les
capçaleres del nucli per la variant del nucli de la imatge. En lloc d'enumerar
manualment el paquet /linux-headers/ correcte en la llista de paquets creat
anteriorment, la selecció del paquet adequat es pot fer automàticament amb
/live-build/.
$ lb config --linux-packages "linux-image linux-header"
4.7 CONSTRUIR I UTILITZAR UNA IMATGE HDD
........................................
Construir una imatge HDD és similar a una ISO híbrida en tots els aspectes,
excepte que s'especifica -b hdd, que el nom del fitxer resultant és binary.img
i que no es pot gravar en medis òptics. És adequada per arrencar des de
dispositius USB, discs durs USB, i altres dispositius d'emmagatzematge
portàtils. Normalment, una imatge ISO híbrida es pot utilitzar per aquest
propòsit en el seu lloc, però si el BIOS no maneja adequadament les imatges
híbrides, cal utilitzar una imatge HDD.
*Nota:* si s'ha creat una imatge ISO híbrida amb l'exemple anterior, s'haurà de
netejar el directori de treball amb l'ordre lb clean (veure L'ordre lb clean):
# lb clean --binary
Executar l'ordre lb config com abans, excepte que aquesta vegada especificant
el tipus d'imatge HDD:
$ lb config -b hdd
Ara construir la imatge amb l'ordre lb build:
# lb build
Quan la construcció acabi, hauria d'haver un fitxer binary.img al directori
actual.
La imatge binària generada conté una partició VFAT i el carregador d'arrencada
syslinux, llestos per ser escrits directament a una memòria USB. Un cop més,
donat que l'ús d'una imatge HDD és com utilitzar una imatge ISO híbrida en un
USB, seguir les instruccions de Usar una imatge ISO híbrida en viu, però amb el
nom de fitxer binary.img en lloc de binary.hybrid.iso.
Igualment, per provar una imatge HDD amb Qemu, instaŀlar /qemu/ com s'ha
descrit anteriorment a Provar una imatge ISO amb QEMU. A continuació, executar
kvm o qemu, segons la versió instaŀlada al sistema amfitrió, especificant
binary.img com a primer disc dur.
$ kvm -hda binary.img
4.8 CONSTRUIR UNA IMATGE NETBOOT
................................
La següent seqüència d'ordres crearà una imatge netboot bàsica que conté el
sistema per defecte de Debian sense X.org. És adequada per a l'arrencada en
xarxa.
*Nota:* si s'ha realitzat algun dels exemples anteriors, s'haurà de netejar el
directori de treball amb l'ordre lb clean:
# lb clean
En aquest cas concret, un lb clean --binary no seria insuficient per netejar
les etapes necessàries. La causa d'això és que en les configuracions
d'arrencada en xarxa, es necessita una configuració initramfs diferent que
/live-build/ realitza automàticament quan es construeixen imatges netboot. Ja
que la creació del initramfs pertany a l'etapa chroot, fer el canvi a netboot
en un directori de construcció existent significa reconstruir l'etapa chroot
també. Per tant, s'ha de fer un lb clean (que eliminarà l'etapa chroot, també).
Executar l'ordre següent per configurar la imatge per arrencar en xarxa:
$ lb config -b netboot --net-root-path "/srv/debian-live" --net-root-server "192.168.0.1"
A diferència de les imatges ISO i HDD, l'arrencada en xarxa no serveix el
sistema de fitxers al client, per tant els fitxers han de ser servits a través
de NFS. Amb lb config es poden elegir diferents sistemes de fitxers de xarxa.
Les opcions --net-root-path i --net-root-server especifiquen la ubicació i el
servidor, respectivament, del servidor NFS on es troba la imatge del sistema de
fitxers a l'hora d'arrencar. Assegurar-se que aquests s'ajusten als valors
adequats per la xarxa i el servidor.
Ara construir la imatge amb l'ordre lb build:
# lb build
En l'arrencada en xarxa, el client executa una petita peça de programari que
normalment es troba a la EPROM de la targeta Ethernet. Aquest programa envia
una petició DHCP per obtenir una adreça IP i la informació sobre què fer a
continuació. Per regla general, el següent pas és aconseguir un carregador
d'arrencada de més alt nivell a través del protocol TFTP. Podria ser GRUB,
pxelinux o fins i tot arrencar directament a un sistema operatiu com Linux.
Per exemple, si es descomprimeix el arxiu binary.netboot.tar generat al
directori /srv/debian-live, es trobarà la imatge del sistema de fitxers a
live/filesystem.squashfs i el nucli, initrd i carregador d'arrencada pxelinux a
tftpboot/debian-live/i386.
Ara hem de configurar els tres serveis al servidor per l'arrencada en xarxa: el
servidor DHCP, servidor TFTP i el servidor NFS.
4.8.1 SERVIDOR DHCP
...................
S'ha de configurar el servidor DHCP de la xarxa per assegurar-se que dona una
adreça IP per al client del sistema d'arrencada en xarxa, i per anunciar la
ubicació del carregador d'arrencada PXE.
Heus aquí un exemple per servir d'inspiració, escrit per al servidor ISC DHCP
isc-dhcp-server al fitxer de configuració /etc/dhcp/dhcpd.conf:
# /etc/dhcp/dhcpd.conf - configuration file for isc-dhcp-server
ddns-update-style none;
option domain-name "example.org";
option domain-name-servers ns1.example.org, ns2.example.org;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.1 192.168.0.254;
next-server servername;
filename "pxelinux.0";
}
4.8.2 SERVIDOR TFTP
...................
Aquest serveix el nucli i el disc ram inicial per al sistema en temps
d'execució.
S'ha d'instaŀlar el paquet /tftpd-hpa/. Aquest pot servir tots els fitxers
continguts dins d'un directori arrel, per regla general /srv/tftp. Per tal que
es serveixin els fitxers dins de /srv/debian-live/tftpboot, s'ha d'executar com
a superusuari la següent ordre:
# dpkg-reconfigure -plow tftpd-hpa
i omplir el nou directori del servidor tftp quan ho hàgim de fer.
4.8.3 SERVIDOR NFS
..................
Un cop l'ordinador ha descarregat, ha arrencat el nucli de Linux i ha carregat
el initrd, intentarà muntar la imatge del sistema de fitxers en viu a través
d'un servidor NFS.
S'ha d'instaŀlar el paquet /nfs-kernel-server/
Llavors, fer que la imatge del sistema de fitxers estigui disponible a través
de NFS afegint una línia com la següent a /etc/exports:
/srv/debian-live *(ro,async,no_root_squash,no_subtree_check)
i informar al servidor NFS sobre aquesta nova exportació amb la següent ordre:
# exportfs -rv
La configuració d'aquests tres serveis pot ser una mica difícil. És possible
que es necessiti una mica de paciència per aconseguir que tots tres funcionin
plegats. Per obtenir més informació, veure el wiki de syslinux a
o la secció TFTP Net Booting
al Manual del Instaŀlador de Debian a
. Això pot ajudar, ja
que els seus processos són molt similars.
4.8.4 COM PROVAR L'ARRENCADA EN XARXA
.....................................
La creació d'imatges d'arrencada en xarxa es senzilla amb /live-build/, però
provar les imatges en màquines físiques pot costar molt de temps.
Per fer la nostra vida més fàcil, podem utilitzar la virtualització.
4.8.5 QEMU
..........
* Instaŀlar /qemu/, /bridge-utils/, /sudo/.
Editar /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
Descarregar o crear un grub-floppy-netboot.
Llançar qemu amb "-net nic,vlan=0 -net tap,vlan=0,ifname=tun0"
5. DESCRIPCIó GENERAL DE LES EINES
----------------------------------
Aquest capítol conté un resum de les tres eines principals utilitzades en la
construcció dels sistemes Debian Live: /live-build/, /live-boot/ i
/live-config/.
5.1 EL PAQUET LIVE-BUILD
........................
/live-build/ és un conjunt de scripts per crear sistemes Debian Live. Aquests
scripts també s'anomenen «ordres».
La idea darrere de /live-build/ és ser un marc que utilitza un directori de
configuració per automatitzar completament i personalitzar tots els aspectes de
la construcció d'una imatge en viu.
Molts conceptes són similars als utilitzats per crear paquets Debian amb
/debhelper/:
* Els scripts tenen una ubicació central per a la configuració del seu
funcionament. Amb /debhelper/ aquest és el subdirectori debian/ d'un arbre de
paquets. Per exemple, dh_install buscarà, entre altres, un fitxer anomenat
debian/install per determinar quins fitxers han d'existir en un paquet binari
en particular. De la mateixa manera, /live-build/ emmagatzema la seva
configuració per complet sota un subdirectori config/.
* Els scripts són independents - és a dir, sempre és segur executar cada ordre.
A diferència de /debhelper/, /live-build/ conté una eina per generar un
directori de configuració en esquelet, lb config. Això podria ser considerat
similar a eines com ara /dh-make/. Per obtenir més informació sobre lb config,
veure L'ordre lb config.
La resta d'aquesta secció descriu les tres ordres més importants:
* *lb config*: Responsable de crear un directori de configuració per al sistema
en viu. Consultar L'ordre lb config per més informació.
* *lb build*: Responsable d'iniciar la creació d'un sistema en viu. Consultar
L'ordre lb build per a més informació.
* *lb clean*: Responsable d'eliminar parts de la construcció d'un sistema viu.
Consultar L'ordre lb clean per a més informació.
5.1.1 L'ORDRE LB CONFIG
.......................
Com s'ha dit a live-build, les seqüències d'ordres que formen part de
/live-build/ llegeixen la seva configuració amb l'ordre source d'un únic
directori anomenat config/. Com la construcció d'aquest directori a mà, seria
molt costós i propens a errors, es pot utilitzar l'ordre lb config per crear
carpetes de configuració en esquelet.
Executar lb config sense arguments crea un subdirectori config/ que s'omple amb
alguns paràmetres per defecte, i un arbre en esquelet de subdirectoris auto/.
$ lb config
[2013-01-01 09:14:22] lb_config
P: Considering defaults defined in /etc/live/build.conf
P: Creating config tree for a debian/i386 system
Utilitzar lb config sense cap tipus d'arguments seria convenient per als
usuaris que necessiten una imatge molt bàsica, o que tinguin la intenció de
proporcionar una configuració més completa més tard mitjançant auto/config
(Veure Gestió d'una configuració per més detalls).
Normalment, s'haurà d'especificar algunes opcions. Per exemple, per especificar
quina distribució es vol construir mitjançant el seu nom en clau:
$ lb config --distribution sid
És possible especificar diverses opcions, com ara:
$ lb config --binary-images netboot --bootappend-live "boot=live config hostname=live-host username=live-user" ...
Una llista completa d'opcions està disponible a la pàgina del manual lb_config.
5.1.2 L'ORDRE LB BUILD
......................
L'ordre lb build llegeix la configuració del directori config/. A continuació,
executa les ordres de nivell inferior necessàries per construir el sistema en
viu.
5.1.3 L'ORDRE LB CLEAN
......................
L'ordre lb clean s'encarrega d'eliminar diverses parts d'una construcció per
que altres construccions posteriors puguin començar des d'un estat net. Per
defecte, es netegen les etapes chroot, binary i source, però la caché es manté
intacta. A més, es poden netejar etapes individuals. Per exemple, si s'han fet
canvis que només afecten a la fase binary, utilitzar lb clean --binary abans de
construir un nou binary. Veure la pàgina del manual de lb_clean per a una
llista completa d'opcions.
5.2 EL PAQUET LIVE-BOOT
.......................
/live-boot/ és un conjunt de scripts per proporcionar hooks a
/initramfs-tools/, que s'utilitzen per generar un initramfs capaç d'arrencar
sistemes vius, com ara els creats per /live-build/. Això inclou les ISOs de
Debian Live, netboot tarballs i imatges per a memòries USB.
En el moment d'arrencar, buscarà medis de només lectura que continguin un
directori /live/ on s'emmagatzema un sistema de fitxers arrel (sovint una
imatge de un sistema de fitxers comprimit squashfs). Si el troba, crearà un
entorn d'escriptura, utilitzant aufs, per que puguin arrencar sistemes com
Debian o similars.
Més informació sobre ramfs inicial a Debian es pot trobar al Debian Linux
Kernel Handbook al capítol sobre
initramfs.
5.3 EL PAQUET LIVE-CONFIG
.........................
/live-config/ consta dels scripts que s'executen durant l'arrencada després de
/live-boot/ per a configurar el sistema en viu de forma automàtica. S'ocupa de
tasques com ara l'establiment de les locales, el nom d'amfitrió, la zona
horària, crear l'usuari en viu, l'inhibició de tasques de cron i l'inici
automàtic de sessió per l'usuari en viu.
6. GESTIó D'UNA CONFIGURACIó
----------------------------
En aquest capítol s'explica com gestionar una configuració d'un sistema en viu
des de la seva creació inicial, a través de revisions i versions successives de
tant el programari /live-build/ com de la imatge en viu en si mateixa.
6.1 GESTIONAR CANVIS EN LA CONFIGURACIó
.......................................
Les configuracions de sistemes en viu poques vegades són perfectes al primer
intent. Passar opcions a lb config des de la línea d'ordres pot estar be per
construir una imatge una vegada, però és més típic revisar aquestes opcions i
construir de nou fins que se'n estigui satisfet. Per donar suport a aquests
canvis, es poden utilitzar scripts auto que assegurin que la configuració es
manté en un estat consistent.
6.1.1 PER QUè UTILITZAR SCRIPTS AUTO? QUè FAN?
..............................................
L'ordre lb config emmagatzema les opcions que se li passen als fitxers de
config/*, juntament amb moltes altres opcions que estan establertes als valors
per defecte. Si s'executa un cop més, lb config no es restablirà cap de les
opcios dependents basades en les opcions inicials. Així, per exemple, si
s'executa lb config de nou amb un nou valor per --distribution, totes les
opcions que en depenen que es van omplir per a la distribució per defecte ja no
poden funcionar amb la nova. Aquests fitxers no estan destinats a ser llegits o
editats. S'emmagatzemen els valors de més de cent opcions, i ningú pot veure
les opcions que s'han especificat realment. I finalment, si s'executa lb config
i a continuació s'actualitza /live-build/ i el nom d'una opció canvia, config/*
encara contindrà les variables de l'opció vella que ja no són vàlides.
Per totes aquestes raons, els scripts auto/* ens fan la vida més fàcil. Són
simples embolcalls per les ordres lb config, lb build i lb clean dissenyats per
ajudar a gestionar una configuració. Només cal crear un script auto/config que
contingui totes les opcions que es desitgin per a lb config, i un auto/clean
que elimini els fitxers que continguin diversos valors de variables de
configuració, i el script auto/build guarda un build.log de cada construcció.
Cada vegada que s'executi l'ordre lb corresponent, aquests fitxers seran
executats automàticament. L'ús d'aquests scripts assegurarà que la configuració
sigui més senzilla de llegir i que guardi una coherència interna d'una reversió
a una altra. A més a més serà més fàcil identificar i solucionar les opcions
que s'han de canviar al actualitzar d'una versió de /live-build/ a la següent
després de llegir la documentació.
6.1.2 UTILITZAR SCRIPTS AUTO D'EXEMPLE
......................................
Per a més comoditat, /live-build/ ve amb uns scripts d'exemple per copiar i
editar. Iniciar una nova configuració per defecte, i a continuació, copiar els
exemples:
$ mkdir mylive && cd mylive && lb config
$ cp /usr/share/doc/live-build/examples/auto/* auto/
Editar auto/config, afegint les opcions més adients. Per exemple:
#!/bin/sh
lb config noauto \
--architectures i386 \
--linux-flavours 686-pae \
--binary-images hdd \
--mirror-bootstrap http://ftp.ch.debian.org/debian/ \
--mirror-binary http://ftp.ch.debian.org/debian/ \
"${@}"
Ara, cada vegada que s'utilitzi lb config, auto/config restablirà la
configuració basada en aquestes opcions. Quan es vulgui fer canvis, editar les
opcions d'aquest fitxer en lloc de passar-les a lb config. Quan s'utilitza lb
clean, auto/clean netejarà els fitxers de config/* juntament amb els altres
productes de construcció. I, finalment, quan s'utilitza lb build, es crea un
log de la construcció mitjançant auto/build anomenat build.log.
*Nota:* Aquí s'utilitza un paràmetre especial noauto per suprimir un altra
crida a auto/config, la qual cosa impedeix la recursivitat infinita.
Assegurar-se de no eliminarlo accidentalment fent canvis. També, tenir cura de
que quan es divideix l'ordre lb config a través de diverses línies per
facilitar la lectura, com es mostra en l'exemple anterior, no s'oblidi la barra
invertida (\) al final de cada línia que segueix a la següent.
6.2 CLONAR UNA CONFIGURACIó PUBLICADA VIA GIT
.............................................
Utilitzar l'opció lb config --config per clonar un repositori Git que contingui
una configuració de Debian Live. Si es vol basar la configuració en un
repositori mantingut pel projecte Debian Live, mirar el repositori a
amb el nom live-images sota el títol Packages.
Aquest repositori conté les configuracions per les imatges prefabricades de
Debian Live.
Per exemple, per construir una imatge de rescat, utilitzar el repositori
live-images de la manera següent:
$ mkdir live-images && cd live-images
$ lb config --config git://live.debian.net/git/live-images.git
$ cd images/rescue
Editar auto/config i qualsevol altra cosa necessària dins l'arbre config per
satisfer les necessitats pròpies. Per exemple, per fer les imatges
prefabricades no oficials que contenen paquets de la secció non-free simplement
s'afegeix --archive-areas "main contrib non-free".
Si es desitja, es pot definir una drecera en la configuració de Git, afegint el
següent a ${HOME}/.gitconfig:
[url "git://live.debian.net/git/"]
insteadOf = ldn:
Això permet utilitzar ldn: en qualsevol lloc on cal especificar la direcció
d'un repositori git. També es pot omitir el sufix .git, i així, començar una
nova imatge amb aquesta configuració és tan fàcil com:
$ lb config --config ldn:live-images
Clonar tot el repositori live-images còpia les configuracions utilitzades per
diverses imatges. Si es vol construir una imatge diferent després d'haver
acabat amb la primera, canviar a un altre directori i un altre cop i,
opcionalment, fer els canvis per adaptar-les a les necessitats pròpies.
En qualsevol cas, recordar que cada vegada que s'ha de construir una imatge,
s'ha de fer com a superusuari: lb build
7. VISIó GENERAL DE LA PERSONALITZACIó
--------------------------------------
En aquest capítol s'ofereix una visió general de les diverses formes en què es
pot personalitzar un sistema Debian Live.
7.1 CONFIGURACIó DURANT LA CONSTRUCCIó VS. DURANT L'ARRENCADA
.............................................................
La configuració de un sistema en viu es divideix en opcions en temps de
construcció que són les opcions que s'apliquen durant la seva creació i les
opcions d'arrencada del sistema que s'apliquen durant l'arrencada. Les opcions
d'arrencada es divideixen en les què ocorren al principi de l'arrencada,
aplicades pel paquet /live-boot/, i les que ocorren més tard en l'arrencada,
aplicades per /live-config/. Qualsevol opció durant l'arrencada pot ser
modificada per l'usuari, especificant-la a l'indicador d'arrencada. La imatge
també pot ser construïda amb els paràmetres d'arrencada per defecte perquè els
usuaris puguin simplement arrencar el sistema en viu sense especificar cap
altra opció, ja que tots els valors per defecte són adequats. En particular,
l'argument lb --bootappend-live consta de les opcions de línia d'ordres per
defecte del nucli per al sistema en viu, com ara la persistència, la
distribució del teclat o la zona horària. Veure Personalització de l'entorn
local i el llenguatge, per exemple.
Les opcions de configuració durant la construcció es descriuen a la pàgina del
manual de lb config. Les opcions durant l'arrencada es descriuen a les pàgines
del manual de /live-boot/ i /live-config/. Malgrat que els paquets /live-boot/
i /live-config/ s'instaŀlen en el sistema en viu que s'està construint, és
recomana instaŀlar-los en el sistema de construcció per tenir una referència
fàcil quan s'està treballant en la configuració. És segur fer-ho, ja que cap
dels scripts continguts en ells s'executen a menys que el sistema s'hagi
configurat com a sistema viu.
7.2 ETAPES DE LA CONSTRUCCIó
............................
El procés de construcció es divideix en etapes, amb personalitzacions
diferentes aplicades successivament en cada una. La primera etapa que s'executa
es la fase *bootstrap*. Aquesta és la fase inicial de poblar el directori
chroot amb paquets per fer un sistema Debian bàsic. Això és seguit per l'etapa
*chroot*, que completa la construcció del directori chroot, omplint-lo amb tots
els paquets que s'indiquen en la configuració, juntament amb qualsevol altre
material. La majoria de personalitzacions dels continguts es produeixen en
aquesta etapa. L'etapa final de preparació de la imatge en viu és l'etapa
*binary*, quan es construeix una imatge capaç d'arrencar, amb el contingut del
directori chroot per construir el sistema de fitxers arrel per al sistema en
viu, i que inclou el programa de instaŀlació i qualsevol altre material
addicional en el medi de destinació fora del sistema de fitxers del sistema en
viu. Després de construir la imatge en viu, si està habilitat, s'inclou el codi
font original a l'etapa *source*.
Dins de cadascuna d'aquestes etapes, hi ha una seqüència particular en la qual
s'apliquen les ordres. Això es fa de manera que es garanteixi que les
personalitzacions es poden superposar de manera raonable. Per exemple, dins
l'etapa *chroot*, les preconfiguracions (preseeds) s'apliquen abans que
s'instaŀlin els paquets, els paquets s'instaŀlen abans que es copiïn els
fitxers locals, i els ganxos s'executen més tard, després que tots els
materials estiguin al seu lloc.
7.3 SUPLEMENTAR LB CONFIG AMB FITXERS
.....................................
Encara que lb config crea una configuració en esquelet al directori config/,
per aconseguir els objectius, pot ser necessari proporcionar fitxers
addicionals en els subdirectoris de config/. Depenent d'on s'emmagatzemen els
fitxers en la configuració, poden ser copiats en el sistema de fitxers del
sistema en viu o en el sistema de fitxers de la imatge binària, o es pot
proporcionar configuracions en temps de construcció del sistema que serien
engorroses de passar com opcions de línia d'ordres. Es pot incloure coses com
ara llistes personalitzades de paquets, art personalitzat o scripts ganxo per
ser executats ja sigui en temps de construcció o en temps d'arrencada,
augmentant la flexibilitat ja considerable de debian-live amb codi propi.
7.4 TASQUES DE PERSONALITZACIó
..............................
Els següents capítols s'organitzen pel tipus de tasques de personalització que
els usuaris solen realitzar: Personalització de la instaŀlació de paquets,
Personalització dels continguts i Personalització de l'entorn local i el
llenguatge cobreixen només algunes de les coses que es poden fer.
8. PERSONALITZACIó DE LA INSTAŀLACIó DE PAQUETS
-----------------------------------------------
La personalització més bàsica d'un sistema Debian live pot ser la selecció dels
paquets que seran inclosos en la imatge. Aquest capítol explica les diverses
opcions de /live-build/ per personalitzar la instaŀlació de paquets durant la
construcció. Les opcions més importants que influeixen en els paquets que estan
disponibles per ser instaŀlats en la imatge són les àrees de distribució i el
arxiu. Per garantir velocitats de descàrrega decents, s'ha de triar un mirall
de distribució proper. També es pot incloure repositoris de backports, paquets
experimentals o personalitzats, o incloure paquets directament com si fossin
fitxers. Es poden definir llistes de paquets, incloent-hi els metapaquets que
instaŀlaran diversos paquets relacionats alhora, com ara paquets per a un
ordinador d'escriptori o un llenguatge en particular. Finalment, una sèrie
d'opcions donen un cert control sobre /apt/ o si es prefereix /aptitude/, quan
s'instaŀlen els paquets durant la construcció. Això pot ser útil si s'utilitza
un proxy, es vol desactivar la instaŀlació de paquets recomanats per estalviar
espai, o hi ha la necessitat de controlar quines versions dels paquets
s'instaŀlen mitjançant la tècnica pinning d'APT, per nomenar algunes
possibilitats.
8.1 FONTS DELS PAQUETS
......................
8.1.1 DISTRIBUCIó, àREES D'ARXIU I MODE
.......................................
La distribució que es tria té una gran importància en els paquets que estan
disponibles per incloure en una imatge en viu. Només cal especificar el nom en
clau, que per defecte és *wheezy* per a la versió *wheezy* de /live-build/.
Qualsevol distribució disponible a l'arxiu de Debian pot ser especificada pel
seu nom en clau aquí. (Veure Termes per més detalls.) L'opció --distribution no
només influeix en l'origen dels paquets dins l'arxiu, sinó que també instrueix
a /live-build/ per comportar-se segons sigui necessari per a construir cada
distribució suportada. Per exemple, per construir la distribució *unstable*,
*sid*, s'ha d'especificar:
$ lb config --distribution sid
A l'arxiu de la distribució, les àrees són les divisions principals de l'arxiu.
A Debian, es tracta de main, contrib i non-free. Només main conté el programari
que és part de la distribució Debian, per tant és el valor per defecte. Es
poden especificar un o més valors, per exemple:
$ lb config --archive-areas "main contrib non-free"
És dona suport experimental a alguns derivats de Debian a través de l'opció
--mode. Per defecte, aquesta opció és debian però només si s'està construint en
un sistema Debian o en un sistema desconegut. Si s'especifica amb lb config que
es vol construir un dels derivats suportats alehores es modificaran les opcions
per crear aquest derivat. Si per exemple s'utilitza lb config amb el mode
ubuntu, s'utilitzarà el nom de la distribució i les àrees dels arxius del
derivat especificat en lloc dels de Debian. El «mode» també modifica el
comportament de /live-build/ per adaptar-lo als derivats.
*Nota:* Els projectes per als quals s'han afegit aquests modes són els
principals responsables de donar suport als usuaris d'aquestes opcions. El
projecte Debian Live, al seu torn, dona suport de desenvolupament només sobre
una base de millor esforç, basada en les informacions proporcionades pels
projectes derivats ja que nosaltres no desenvolupem ni donem suport a aquests
derivats.
8.1.2 MIRALLS DE DISTRIBUCIó
............................
L'arxiu de Debian es replica a través d'una àmplia xarxa de miralls a tot el
món perquè la gent de cada regió pugui triar un mirall proper amb la millor
velocitat de descàrrega. Cadascuna de les opcions --mirror-* governa quin
mirall de distribució s'utilitzarà en les diverses etapes de la construcció.
Recordar de Etapes de la construcció que l'etapa *bootstrap* es quan el chroot
s'omple inicialment per /debootstrap/ amb un sistema mínim i l'etapa *chroot*
és quan s'utilitza el chroot per a la construcció del sistema de fitxers del
sistema en viu. D'aquesta manera, s'utilitzen els miralls corresponents per a
aquestes etapes, i més tard, durant l'etapa *binary* s'utilitzen els valors
--mirror-binary i --mirror-binary-security substituint qualsevol mirall
utilitzat en una etapa anterior.
8.1.3 MIRALLS DE DISTRIBUCIó UTILITZATS EN TEMPS DE CONSTRUCCIó
...............................................................
Per establir els miralls de la distrubució utilitzats en temps de construcció
perquè apuntin a una rèplica local, és suficient establir --mirror-bootstrap,
--mirror-chroot-security i --mirror-chroot-backports de la manera següent.
$ lb config --mirror-bootstrap http://localhost/debian/ \
--mirror-chroot-security http://localhost/debian-security/ \
--mirror-chroot-backports http://localhost/debian-backports/
El mirall per al chroot, especificat per l'opció --mirror-chroot, per defecte
pren el mateix valor que --mirror-bootstrap
8.1.4 MIRALLS DE DISTRIBUCIó UTILITZATS EN TEMPS D'EXECUCIó
...........................................................
Les opcions --mirror-binary* governen els miralls de distribució que acaben a
la imatge binària. Aquestes poden ser utilitzades per instaŀlar paquets
addicionals mentre s'executa el sistema en viu. Els valors per defecte fan
servir http.debian.net, un servei que tria un mirall geogràficament a prop en
funció, entre altres coses, de la familia de la IP de l'usuari i de la
disponibilitat del mirall. Aquesta és una opció adequada quan no es pot predir
quin serà el millor mirall per tots els usuaris. O es pot especificar els
valors propis com es mostra en l'exemple següent. Una imatge construïda a
partir d'aquesta configuració només seria convenient per als usuaris en una
xarxa on "mirror" és abastable.
$ lb config --mirror-binary http://mirror/debian/ \
--mirror-binary-security http://mirror/debian-security/ \
--mirror-binary-backports http://mirror/debian-backports/
8.1.5 REPOSITORIS ADDICIONALS
.............................
És possible afegir més repositoris, ampliant les opcions de paquets més enllà
dels disponibles en la pròpia distribució de destinació. Aquests poden ser, per
exemple, per backports, experimentals o paquets personalitzats. Per configurar
repositoris addicionals, crear els fitxers
config/archives/your-repository.list.chroot, i/o
config/archives/your-repository.list.binary. Igual que amb les opcions
--mirror-* aquest regeix els repositoris utilitzats en l'étapa *chroot* durant
la construcció de la imatge, i a l'étapa *binary*, és a dir, per ser
utilitzades quan s'executa el sistema en viu.
Per exemple, config/archives/live.list.chroot permet instaŀlar paquets des del
repositori d'instantànies de debian-live en el moment de construcció del
sistema viu.
deb http://live.debian.net/ sid-snapshots main contrib non-free
Si s'afegeix la mateixa línia a config/archives/live.list.binary, el repositori
sera afegit al directori /etc/apt/sources.list.d/ del sistema viu.
Si aquests fitxers existeixen, són utilitzats de forma automàtica.
També s'ha de posar la clau GPG utilitzada per signar el repositori en fitxers
config/archives/your-repository.key.{binary,chroot}.
En cas de necessitar un APT pinning personalitzat, es poden coŀlocar les
preferències APT en fitxers
config/archives/your-repository.pref.{binary,chroot}, que seran afegits
automàticament al sistema en viu al directori /etc/apt/preferences.d/.
*Nota:* Hi ha alguns repositoris de paquets preconfigurats que estan
disponibles per facilitar la seva selecció a través de l'opció --archives, per
exemple, per habilitar instantànies en viu, una simple ordre és suficient:
$ lb config --archives live.debian.net
8.2 SELECCIó DELS PAQUETS A INSTAŀLAR
.....................................
Hi ha una sèrie de formes de triar els paquets que /live-build/ instaŀlarà en
la imatge, que abasta una varietat de necessitats diferents. Es pot simplement
anomenar paquets individualment per instaŀlar en una llista de paquets. També
es pot optar per utilitzar metapaquets a les llistes, o seleccionar-los
utilitzant camps de control de fitxers de paquets. I, finalment, es poden
copiar paquets com si fossin fitxers dins del arbre config/, que és un mètode
que s'adapta perfectament a fer proves amb paquets nous o experimentals abans
de afegirlos a un repositori.
8.2.1 LLISTES DE PAQUETS
........................
Les llistes de paquets són una forma eficaç d'expressar quins paquets han de
ser instaŀlats. La sintaxi de la llista suporta seccions condicionals que fa
que sigui fàcil construir llistes i adaptar-les per al propi ús en múltiples
configuracions. Els noms dels paquets també poden ser injectats a la llista amb
ajudants de l'intèrpret d'ordres en temps de construcció.
*Nota:* El comportament de /live-build/ a l'hora d'especificar un paquet que no
existeix està determinat per la elecció que es faci de l'eina APT. Veure Elegir
apt or aptitude per més detalls.
8.2.2 ÚS DELS METAPAQUETS
.........................
La forma més senzilla per omplir la llista de paquets és utilitzar una tasca
metapaquet mantinguda per una distribució. Per exemple:
$ lb config
$ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
Això reemplaça l'antic mètode de llistes predefinides de live-build 2.x. A
diferència de les llistes predefinides, els metapaquets no són específics del
projecte Debian Live. Per contra, són mantinguts per grups d'especialistes que
treballen dins la distribució i per tant, reflecteixen el consens de cada grup
sobre els paquets que serviran millor a les necessitats dels usuaris. A més,
abasten una gamma molt més àmplia de casos d'ús que les llistes predefinides
que substitueixen.
Tots els metapaquets tenen el prefix task-, de manera que una forma ràpida de
determinar quins estan disponibles (encara que pot contenir un grapat
d'entrades falses que coincideixin amb el nom, però que no són metapaquets) és
fer coincidir el nom del paquet amb:
$ apt-cache search --names-only ^task-
A més d'aquests, es troben altres metapaquets amb diverses finalitats. Alguns
són subconjunts de paquets de tasques més àmplies, com gnome-core, mentre que
altres són parts individuals especialitzades de un Debian Pure Blend, com els
metapaquets education-*. Per obtenir una llista de tots els metapaquets que hi
ha a l'arxiu, instaŀlar el paquet debtags i llistar tots els paquets amb
l'etiqueta role::metapackage de la següent manera:
$ debtags search role::metapackage
8.2.3 LLISTES LOCALS DE PAQUETS
...............................
Ja sigui afegint metapaquets a una llista, paquets individuals, o una
combinació d'ambdós, totes les llistes de paquets locals s'emmagatzemen a
config/package-lists/. Es pot utilitzar més d'una llista i això es presta molt
bé als dissenys modulars. Per exemple, es pot decidir dedicar una llista a una
elecció particular d'escriptori, l'altra a una coŀlecció de paquets relacionats
que puguin ser fàcilment utilitzats al damunt d'un escriptori diferent. Això
permet experimentar amb diferents combinacions de conjunts de paquets amb un
mínim d'esforç, intercanviant llistes comunes entre els diferents projectes
d'imatges en viu.
Les llistes de paquets que es troben en aquest directori han de tenir el sufix
.list per ser processades, i a més a més un sufix d'etapa adicional .chroot o
.binary per indicar per a quina etapa és la llista.
*Nota:* Si no s'especifica el sufix d'etapa, la llista s'utilitzarà per a
ambdues etapes. Normalment, s'especifica .list.chroot de manera que els paquets
només s'instaŀlaran al sistema de fitxers en viu i no hi haura una còpia extra
del .deb en el medi.
8.2.4 LLISTES LOCALS DE PAQUETS PER L'ETAPA BINARY
..................................................
Per crear una llista per a l'etapa binary, crear un fitxer amb el sufix
.list.binary a config/package-lists/. Aquests paquets no s'instaŀlen al sistema
de fitxers en viu però s'inclouen en el medi en viu al directori pool/. Un ús
típic d'aquesta llista seria amb una de les variants del instaŀlador non-live.
Com s'ha esmentat anteriorment, si es vol que aquesta llista sigui la mateixa
que la llista de l'etapa chroot, simplement utilitzar el sufix .list.
8.2.5 GENERAR LLISTES DE PAQUETS
................................
De vegades passa que la millor manera de crear una llista és generar-la amb un
script. Qualsevol línia que comença amb un signe d'exclamació indica una ordre
que s'executarà dins del chroot quan la imatge es construeix. Per exemple, es
podria incloure la línia ! grep-aptavail -n -sPackage -FPriority standard |
sort en una llista de paquets per produir una llista ordenada de paquets
disponibles amb Priority: standard.
De fet, la selecció de paquets amb l'ordre grep-aptavail (del paquet
dctrl-tools) és tan útil que live-build proporciona un script Packages d'ajuda
per motius de comoditat. Aquest script accepta dos arguments: field i pattern.
Per tant, es pot crear una llista amb els següents continguts:
$ lb config
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
8.2.6 ÚS DE CONDICIONALS DINS DE LES LLISTES DE PAQUETS
.......................................................
Qualsevol de les variables de configuració de /live-build/ emmagatzemades a
config/* (menys el prefix LB_) poden ser utilitzades en sentències condicionals
en les llistes de paquets. En general, això significa qualsevol opció lb config
en lletres majuscules i amb guions canviats a guions baixos. Però a la
pràctica, només tenen sentit les que influeixen en la selecció de paquets, com
ara DISTRIBUTION, ARCHITECTURES o ARCHIVE_AREAS.
Per exemple, per instaŀlar ia32-libs si s'especifica --architectures amd64:
#if ARCHITECTURES amd64
ia32-libs
#endif
És possible fer un test d'un nombre de valors, per exemple per instaŀlar
/memtest86+/ si s'especifica --architectures i386 o --architectures amd64:
#if ARCHITECTURES i386 amd64
memtest86+
#endif
També es pot provar amb variables que poden contenir més d'un valor, per
exemple, per instaŀlar /vrms/ si s'especifica o contrib o non-free a través de
l'opció --archive-areas:
#if ARCHIVE_AREAS contrib non-free
vrms
#endif
No és possible el anidament dels condicionals.
8.2.7 TASQUES D'ESCRIPTORI I LLENGUATGE
.......................................
Les tasques d'escriptori i el llenguatge són casos especials que necessiten una
mica de planificació i configuració extra. Les imatges en viu són diferentes de
les imatges de l'instaŀlador de Debian en aquest sentit. A l'instaŀlador de
Debian, si el medi es va preparar per obtenir un tipus d'entorn d'escriptori en
particular, la tasca corresponent s'instaŀlarà automàticament. Per tant hi ha
tasques internes gnome-desktop, kde-desktop, lxde-desktop i xfce-desktop, cap
de les quals s'ofereixen al menú de tasksel. De la mateixa manera, no hi ha cap
entrada de menú per a tasques de llengües, però l'elecció del idioma de
l'usuari durant la instaŀlació influeix en la selecció de les tasques de les
llengües corresponents.
En el desenvolupament d'una imatge en viu d'escriptori, la imatge sol arrencar
directament a un escriptori de treball, les opcions d'escriptori i de llengua
han estat fetes en temps de construcció, no en temps d'execució com en el cas
del instaŀlador de Debian. Això no vol dir que una imatge en viu no es pugui
construir per donar suport a diversos equips d'escriptori o diversos idiomes i
oferir a l'usuari una opció, però això no és el comportament de /live-build/
per defecte.
Com que no hi ha cap ajust automàtic per les tasques de llengua que incloguin
coses com ara fonts específiques per a una llengua o paquets de mètode
d'entrada, si es vol, cal especificar-ho en la configuració. Per exemple, una
imatge d'escriptori GNOME que contingui suport per al alemany podrie incloure
les següents tasques metapaquets:
$ lb config
$ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
$ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot
8.2.8 TIPUS I VERSIó DEL NUCLI
..............................
Depenent de l'arquitectura, s'inclouran per defecte en la imatge un o més tipus
de nuclis. Es pot triar diferents tipus a través de l'opció --linux-flavours.
Cada tipus té un sufix per l'arrel per defecte linux-image per formar el nom de
cada metapaquet que al seu torn depèn d'un paquet del nucli exacte que s'ha
d'incloure en la imatge.
Així, per defecte, una imatge per l'arquitectura amd64 inclourà el metapaquet
linux-image-amd64 i una imatge per l'arquitectura i386 inclourà els metapaquets
linux-image-486 i linux-image-686-pae. Al moment d'escriure, aquests paquets
depenen de linux-image-3.2.0-4-amd64, linux-image-3.2.0-4-486 i
linux-image-3.2.0-4-686-pae, respectivament.
Quan hi ha més d'una versió del nucli disponible en els arxius configurats, es
pot especificar el nom d'un paquet del nucli amb l'opció --linux-packages. Per
exemple, suposem que s'està construint una imatge d'arquitectura amd64 i es vol
afegir l'arxiu experimental amb propòsits de fer proves perquè es pugui
instaŀlar el nucli linux-image-3.7-trunk-amd64. Es podria configurar la imatge
de la següent manera:
$ lb config --linux-packages linux-image-3.7-trunk
$ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
8.2.9 NUCLIS PERSONALITZATS
...........................
Es pot construir i incloure nuclis propis personalitzats, sempre que s'integrin
en el sistema de gestió de paquets de Debian. El sistema de /live-build/ no és
compatible amb nuclis no construïts com paquets .deb.
La manera apropiada i recomanable d'implementar els propis paquets del nucli és
seguir les instruccions del kernel-handbook. Recordar que s'ha de modificar
l'ABI i els sufixos del tipus apropiadament, i a continuació, incloure un
conjunt complet dels packets que corresponen amb linux i linux-latest al
repositori.
Si s'opta per construir els paquets del nucli sense els metapaquets a joc, cal
especificar una arrel --linux-packages apropiada com s'indica a Tipus i versió
del nucli. Com expliquem a Instaŀlació de paquets modificats o de tercers, és
millor si s'inclouen els paquets del nucli personalitzat en un repositori
propi, tot i que les alternatives discutides en aquella secció també funcionen.
Està més enllà de l'abast d'aquest document donar consells sobre com
personalitzar un nucli. No obstant això, cal, almenys, assegurar-se que la
configuració compleix els següents requisits mínims:
* Utilitzar una ramdisk inicial.
* Incloure el mòdul d'unió del sistema de fitxers (normalment aufs).
* Incloure tots els mòduls del sistema d'arxius requerits per la configuració
(normalment squashfs).
8.3 INSTAŀLACIó DE PAQUETS MODIFICATS O DE TERCERS
..................................................
Si bé està en contra de la filosofia de Debian Live, de vegades pot ser
necessària la construcció d'un sistema en viu amb versions modificades dels
paquets que es troben al arxiu de Debian. Pot ser per modificar o donar suport
a funcions addicionals, les llengües o les marques, o fins i tot per eliminar
elements dels paquets existents que són indesitjables. De la mateixa manera, es
poden utilitzar paquets de tercers per afegir alguna funcionalitat
personalitzada i/o propietària.
Aquesta secció no cobreix l'assessorament en matèria de construcció o
manteniment de paquets modificats. Però el métode de Joachim Breitner's 'How to
fork privately' a
pot ser d'interès. La creació de paquets personalitzats es tracta a Debian New
Maintainers' Guide at i en altres
llocs.
Hi ha dues formes d'instaŀlar paquets personalitzats modificats:
* packages.chroot
* L'ús d'un repositori APT personalitzat
Utilitzar packages.chroot és més fàcil d'aconseguir i útil per a
personalitzacions "ràpides", però té una sèrie d'inconvenients, mentre que l'ús
d'un repositori APT personalitzat és més costós en la quantitat de temps
necessari per posar-lo en marxa.
8.3.1 FER SERVIR PACKAGES.CHROOT PER INSTAŀAR PAQUETS PERSONALITZATS
....................................................................
Per instaŀar un paquet personalitzat, només s'ha de copiar al directori
config/packages.chroot/. Els paquets que es troben dins d'aquest directori
s'instaŀlaran automàticament en el sistema en viu durant la construcció - no
cal especificar res més en cap altre lloc.
Els paquets *han de* ser nomenats en la forma prescrita. Una manera simple de
fer això és utilitzar dpkg-name.
Utilitzar packages.chroot per a la instaŀlació de paquets personalitzats té els
seus desavantatges:
* No és possible utilitzar APT segur.
* Cal posar tots els paquets apropiats al directori config/packages.chroot/.
* No es presta per a l'emmagatzematge de configuracions de Debian Live en el
control de revisió.
8.3.2 FER SERVIR UN REPOSITORI APT PER INSTAŀLAR PAQUETS PERSONALITZATS
.......................................................................
A diferència de packages.chroot, quan s'utilitza un repositori APT
personalitzat s'ha d'assegurar que s'especifiquen els paquets en un altre lloc.
Veure Selecció dels paquets a instaŀlar per més detalls.
Si bé crear un repositori APT per instaŀlar paquets personalitzats pot semblar
un esforç innecessari, la infraestructura pot ser fàcilment reutilitzada en una
data posterior per oferir actualitzacions dels paquets modificats.
8.3.3 PAQUETS PERSONALITZATS I APT
..................................
/live-build/ utilitza APT per instaŀlar tots els paquets al sistema en viu, per
tant, heretarà els comportaments d'aquest programa. Un exemple rellevant és que
(assumint una configuració per defecte) si es dóna el cas que un paquet està
disponible en dos repositoris diferents, amb diferents números de versió, APT
triarà per instaŀlar el paquet amb la versió més alta.
A causa d'això, s'aconsella augmentar el nombre de la versió dels paquets
personalitzats als fixers debian/changelog per assegurar-se que la versió
modificada és la que s'instaŀla en lloc d'una dels repositoris oficials de
Debian. Això també es pot aconseguir mitjançant l'alteració de les preferències
d'APT del sistema en viu - veure APT pinning per més informació.
8.4 CONFIGURAR APT EN TEMPS DE CONSTRUCCIó
..........................................
Es pot configurar APT a través d'una sèrie d'opcions que només s'apliquen en
temps de construcció. (La configuració d'APT al sistema en funcionament en viu
es pot fer de forma normal per als continguts del sistema en viu, és a dir,
mitjançant la inclusió de les configuracions adequades a través de
config/includes.chroot/.) Per obtenir una llista completa, buscar les opcions
que comencen amb apt a la pàgina del manual de lb_config.
8.4.1 ELEGIR APT O APTITUDE
...........................
Es pot optar per utilitzar /apt/ o /aptitude/ a l'hora d'instaŀlar paquets en
temps de construcció. Quina utilitat s'usa es configura gràcies al argument
--apt de lb config. Escollir el mètode d'implementació per al comportament
preferit durant la instaŀlació de paquets, la diferència notable és la forma en
que es manegen els paquets que falten.
* apt: Amb aquest mètode, si un paquet que s'especifica falta, l'instaŀlació de
paquets fallarà. Aquesta és la configuració per defecte.
* aptitude: Amb aquest mètode, si s'especifica un paquet que falta,
l'instaŀlació de paquets tindrà èxit.
8.4.2 L'úS D'UN PROXY AMB APT
.............................
Una configuració típica d'APT és per fer front a la construcció d'una imatge
darrere d'un proxy. Es pot especificar el proxy per APT amb les opcions
--apt-ftp-proxy o --apt-http-proxy segons sigui necessari, per exemple,
$ lb config --apt-http-proxy http://proxy/
8.4.3 AFINAR APT PER ESTALVIAR ESPAI
....................................
Pot ser necessari estalviar espai en el medi destinat a la imatge, en aquest
cas una o altra o ambdós de les següentes opcions poden ser d'interès.
Si no es vol incloure els índexs d'APT en la imatge, es poden omitir amb:
$ lb config --apt-indices false
Això no influirà en les entrades de /etc/apt/sources.list, sinó simplement si
/var/lib/apt conté els fitxers dels índexs o no. El desavantatge és que APT
necessita aquests índexs per tal d'operar en el sistema en viu, així que abans
d'executar per exemple apt-cache search o apt-get install, l'usuari primer ha
fer un apt-get update per crear aquests índexs.
Si es considera que la instaŀlació de tots els paquets recomanats infla massa
la imatge, sempre que s'estigui preparat per fer front a les conseqüències que
s'analitzen a continuació, es pot desactivar aquesta opció per defecte d'APT
amb:
$ lb config --apt-recommends false
La conseqüència més important de desactivar els «recommends» és que live-boot i
live-config recomanen alguns paquets que proporcionen una funcionalitat
important utilitzada per la majoria de configuracions Live, com per exemple
user-setup recomanat per live-config i que s'utilitza per crear l'usuari en
viu. En tots menys en els casos més excepcionals es necessita tornar a afexir
almenys alguns dels recommends a les llistes de paquets o en cas contrari la
imatge no funcionarà com s'espera, si és que funciona. Mirar els paquets
recomanats per cada un dels paquets inclosos en la construcció i si no s'està
segur que es poden ometre, tornar a afegir-los a les llistes de paquets.
La conseqüència més general aquí és que si no s'instaŀlen els paquets
recomanats per un paquet determinat, és a dir, "els paquets que es troben junts
amb aquest en totes les instaŀlacions a menys que siguin inusuals" (Debian
Policy Manual, secció 7.2), alguns paquets que en realitat són necessaris per
als usuaris del sistema Live poden ser omesos. Per tant, suggerim revisar la
diferència que desactivar els paquets recomanats té en la llista de paquets
(veure el fitxer binary.packages generat per lb build) i tornar a incloure a la
llista els paquets que falten que haurien de ser instaŀlats. Si només es vol
deixar de banda un petit nombre de paquets recomanats, es pot deixar els
«recommends» activats i establir una prioritat pin d'APT negativa en els
paquets seleccionats per impedir la seva instaŀlació, com s'explica a APT
pinning.
8.4.4 PASSAR OPCIONS PER A APT O APTITUDE
.........................................
Si no hi ha cap opció lb config per modificar el comportament d'APT de la
manera què es necessita, es pot utilitzar --apt-options o --aptitude-options
per passar opcions a l'eina APT configurada. Consultar les pàgines dels manual
apt i aptitude per més detalls. Tenir en compte que ambdues opcions tenen
valors per defecte que s'hauran de mantenir, a més de les opcions que es
proporcionen. Així, per exemple, suposant que s'ha inclòs algun paquet de
snapshot.debian.org per fer proves i es vol especificar
Acquire::Check-Valid-Until=false perquè APT no es queixe de que el fitxer
Release ja ha caducat es podria fer com en el exemple següent, afegint la nova
opció després del valor per defecte --yes:
$ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
Consultar les págines del manual per entendre completament aquestes opcions i
quan utilitzar-les. Això és només un exemple i no s'ha d'interpretar com un
consell per configurar la imatge. Aquesta opció no seria adequada, per exemple,
per una versió final d'una imatge en viu.
Per configuracions més complicades que impliquen opcions apt.conf pot ser
adequat crear un fitxer config/apt/apt.conf. Consultar també les altres opcions
apt-* per tenir algunes dreceres convenients per les opcions que es necessiten
amb freqüència.
8.4.5 APT PINNING
.................
Com a referència, llegir primer la pàgina del manual apt_preferences(5). Es pot
configurar APT pinning durant la construcció, o bé durant l'execució. En el
primer cas, crear config/archives/*.pref, config/archives/*.pref.chroot, i
config/apt/preferences. Per al segon cas, crear
config/includes.chroot/etc/apt/preferences.
Suposem que s'està construint un sistema en viu *wheezy* però es necessita que
tots els paquets «live-» que acaben dins de la imatge binària s'instaŀlin desde
*sid* en temps de construcció. Cal afegir *sid* a les fonts d'APT i fer un pin
dels paquets live amb una prioritat més alta, però tots els altres paquets amb
una prioritat més baixa que la prioritat per defecte de manera que només els
paquets que es vol s'instaŀlin desde *sid* en el moment de la construcció i
tots els altres es prenguin de la distribució de destinació, *wheezy*. Això es
pot aconseguir de la manera següent:
$ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
$ cat >> config/archives/sid.pref.chroot << EOF
Package: live-*
Pin: release n=sid
Pin-Priority: 600
Package: *
Pin: release n=sid
Pin-Priority: 1
EOF
Una prioritat pin negativa evitarà que un paquet s'instaŀli, com en el cas que
no es vulgui un paquet que és recomanat per un altre paquet. Suposem que s'està
construint una imatge LXDE afegint task-lxde-desktop a
config/package-lists/desktop.list.chroot però no es desitja que al usuari se li
demani que guardi les contrasenyes wifi al keyring. Aquesta llista depèn de
/lxde-core/, que recomana /gksu/, que al seu torn recomana /gnome-keyring/. Si
es vol omitir el paquet recomanat /gnome-keyring/, es pot fer mitjançant
l'addició de les següents línies a config/apt/preferences:
Package: gnome-keyring
Pin: version *
Pin-Priority: -1
9. PERSONALITZACIó DELS CONTINGUTS
----------------------------------
Aquest capítol tracta d'afinar la personalització dels continguts del sistema
en viu més enllà de simplement triar els paquets que es desitja incloure. Els
«includes» permeten afegir o reemplaçar fitxers arbitraris en la imatge Debian
Live, els scripts ganxo (hooks) permeten executar ordres arbitràries en
diferents etapes de la construcció i en el moment d'arrencar, i la
preconfiguració (preseeding) permet configurar els paquets quan s'instaŀlen
proporcionant respostes a les preguntes de debconf .
9.1 INCLUDES
............
Tot i que l'ideal seria un sistema Debian Live que inclogués només fitxers
proporcionats per paquets Debian sense modificació, de vegades és convenient
proporcionar o modificar part del contingut a través de fitxers. Amb els
includes, és possible afegir (o substituir) fitxers arbitraris en la imatge
Debian Live. /live-build/ ofereix dos mecanismes per al seu ús:
* Chroot local includes: Aquests permeten afegir o substituir fitxers dintre de
chroot/Live en el sistema de fitxers. Consultar Live/chroot local includes per
a més informació.
* Binary local includes: Aquests permeten afegir o substituir fitxers dins la
imatge binària. Consultar Binary local includes per a més informació.
Consultar Termes per a més informació sobre la distinció entre les imatges
"Live" and "binary".
9.1.1 LIVE/CHROOT LOCAL INCLUDES
................................
Es poden utilitzar els chroot local includes per afegir o reemplaçar fitxers en
el sistema de fitxers chroot/Live perquè puguin ser utilitzats en el sistema en
viu. Un ús típic és per omplir l'esquelet del directori de l'usuari (/etc/skel)
utilitzat pel sistema en viu per crear el directori home de l'usuari en viu. Un
altre és el de subministrar fitxers de configuració que poden ser simplement
afegits o reemplaçats en la imatge sense processar; veureLive/chroot local
hooks si es necessita processar-los.
Per incloure fitxers, només s'han d'afegir al directori config/includes.chroot.
Aquest directori es correspon amb el directori arrel / del sistema en viu. Per
exemple, per afegir un fitxer /var/www/index.html en el sistema en viu, fer:
$ mkdir -p config/includes.chroot/var/www
$ cp /path/to/my/index.html config/includes.chroot/var/www
La configuració tindrà llavors l'estructura següent:
-- config
[...]
|-- includes.chroot
| `-- var
| `-- www
| `-- index.html
[...]
Els chroot local includes s'instaŀlen després de la instaŀlació del paquets de
tal manera que es sobreescriuen els fitxers instaŀlats pels paquets.
9.1.2 BINARY LOCAL INCLUDES
...........................
Per incloure material com documentació o vídeos en el sistema de fitxers del
medi en viu de manera que sigui accessible immediatament després de la inserció
del medi sense haver de arrencar el sistema en viu, es pot utilitzar els binary
local includes. Això funciona de manera similar als chroot local includes. Per
exemple, si els fitxers ~/video_demo.* són vídeos de demostració del sistema en
viu descrits i lligats per una pàgina d'índex HTML. Només cal copiar el
material a config/includes.binary/ de la següent manera:
$ cp ~/video_demo.* config/includes.binary/
Aquests fitxers apareixeran ara en el directori arrel del medi en viu.
9.2 SCRIPTS GANXO (HOOKS)
.........................
Els scripts ganxo permeten executar ordres en les etapes de la construcció
chroot i binary per tal de personalitzar la imatge.
9.2.1 LIVE/CHROOT LOCAL HOOKS
.............................
Per executar ordres durant l'etapa chroot, crear un script ganxo que contingui
les ordres amb el sufix .chroot i afegir-lo al directori config/hooks/. El
ganxo s'executarà en el chroot després que la resta de la configuració del
chroot s'hagi aplicat, assegurar-se que la configuració inclou tots els paquets
i els fitxers que el ganxo necessita per funcionar. Veure els scripts chroot
d'exemple per a diverses tasques comunes de personalització que es poden trovar
a /usr/share/doc/live-build/examples/hooks que es poden copiar o fer un enllaç
simbòlic per utilitzar-los en la pròpia configuració.
9.2.2 SCRIPTS GANXO DURANT L'ARRENCADA
......................................
Per executar ordres durant l'arrencada, es pot proporcionar scripts ganxo per
/live-config/ com s'explica a la secció "Personalització" de la seva pàgina del
manual. Es poden afegir els ganxos de /live-config/ a /lib/live/config/, tenint
en compte la seqüència dels números. A continuació, afegir el script ganxo
propi amb un número de seqüència apropiat com a prefix, ja sigui com a un
chroot local include a config/includes.chroot/lib/live/config/, o com un paquet
personalitzat com es va discutir a Instaŀlació de paquets modificats o de
tercers.
9.2.3 BINARY LOCAL HOOKS
........................
Per executar ordres durant l'etapa binary, crear un script ganxo que contingui
les ordres amb un sufix .binary i afegir-lo al directori config/hooks/. El
ganxo s'executarà després que s'executin totes les ordres de l'etapa binary
però abans dels binary_checksums, la darrera ordre de l'etapa binary. Les
ordres del ganxo no s'executen al chroot, per tant tenir cura de no modificar
cap fitxer de fora del arbre de construcció, o es pot fer malbé el sistema de
construcció! Veure els scripts ganxo binary d'exemple per a diverses tasques
comunes de personalització a /usr/share/doc/live-build/examples/hooks que es
poden copiar o fer un enllaç simbòlic per utilitzar-los en la pròpia
configuració.
9.3 PRECONFIGURACIó DE LES PREGUNTES DE DEBCONF
...............................................
Els fitxers del directory config/preseed/ amb el sufix .cfg seguits del sufix
de l'etapa (.chroot o .binary) son considerats fitxers de preconfiguració de
debconf i són instaŀlats per /live-build/ utilitzant debconf-set-selections
durant l'etapa corresponent.
Per a més informació sobre debconf, veure debconf(7) del paquet /debconf/.
10. PERSONALITZACIó DELS COMPORTAMENTS EN TEMPS D'EXECUCIó
----------------------------------------------------------
Tota la configuració que es fa durant l'execució es feta per /live-config/.
Aquestes són algunes de les opcions més comunes de /live-config/ en que els
usuaris estan interessats. Una llista completa de totes les possibilitats es
poden trobar a la pàgina del manual de /live-config/.
10.1 PERSONALITZAR L'USUARI EN VIU
..................................
Una consideració important és que l'usuari en viu es creat per /live-boot/
durant l'arrencada i no per /live-build/ en temps de construcció. Això influeix
no només en on s'han de introduir els materials relacionats amb l'usuari durant
la construcció, tal i com es va explicar a Live/chroot local includes, sinó
també en els grups i els permisos associats amb l'usuari.
Es poden especificar grups addicionals als que pertanyerà l'usuari en viu
mitjançant l'ús de qualsevol de les possibilitats de configuraciò de
/live-config/. Per exemple, per afegir l'usuari en viu al grup fuse, es pot
afegir el següent fitxer a
config/includes.chroot/etc/live/config/user-setup.conf:
LIVE_USER_DEFAULT_GROUPS="audio cdrom dip floppy video plugdev netdev powerdev scanner bluetooth fuse"
o utilitzar
live-config.user-default-groups=audio,cdrom,dip,floppy,video,plugdev,netdev,powerdev,scanner,bluetooth,fuse
com paràmetre d'arrencada.
També és possible canviar el nom de l'usuari per defecte "user" i la
contrasenya per defecte "live". Si es vol fer això per alguna raó, es pot
aconseguir fàcilment de la següent manera:
Per canviar el nom de l'usuari per defecte només s'ha d'especificar en la
configuració:
$ lb config --bootappend-live "boot=live config username=live-user"
Una forma possible de canviar la contrasenya per defecte és per mitjà d'un
ganxo com s'explica a Scripts ganxo durant l'arrencada. Per fer això, es pot
utilitzar el script ganxo "passwd" de
/usr/share/doc/live-config/examples/hooks, posar-li un prefix adequat (per
exemple 2000-passwd) i afegir-lo a config/includes.chroot/lib/live/config/
10.2 PERSONALITZACIó DE L'ENTORN LOCAL I EL LLENGUATGE
......................................................
Quan el sistema en viu arrenca, el llenguatge està implicat en dos passos:
* la generació de locales
* establir la configuració del teclat
La configuració local per defecte en la construcció d'un sistema viu és
locales=en_US.UTF-8. Per definir la locale que s'ha de generar, utilitzar el
paràmetre locales de la opció --bootappend-live de lb config, per exemple.
$ lb config --bootappend-live "boot=live config locales=de_CH.UTF-8"
Es poden especificar diverses locales en una llista separada per comes.
Aquest paràmetre, així com els paràmetres de configuració del teclat que
s'indiquen a continuació, també es pot utilitzar en la línia d'ordres del
nucli. Es pot especificar una configuració regional mitjançant language_country
(en aquest cas s'utilitza la codificació per defecte) o la forma completa
language_country.encoding. Una llista de locales suportades i la codificació
per a cadascuna es poden trobar a /usr/share/i18n/SUPPORTED.
live-config s'encarrega de la configuració del teclat per X i per la consola
utilitzant el paquet console-setup. Per la seva configuració es por fer servir
els paràmetres d'arrencada keyboard-layouts, keyboard-variants,
keyboard-options i keyboard-model mitjançant l'opció --bootappend-live. Es
poden trobar opcions vàlides per a aquests a /usr/share/X11/xkb/rules/base.lst.
Per trobar distribucions de teclat i variants per a un idioma determinat, s'ha
d'intentar cercar el nom en anglès de la llengua i/o el país on es parla
l'idioma, per exemple:
$ egrep -i '(^!|german.*switzerland)' /usr/share/X11/xkb/rules/base.lst
! model
! layout
ch German (Switzerland)
! variant
legacy ch: German (Switzerland, legacy)
de_nodeadkeys ch: German (Switzerland, eliminate dead keys)
de_sundeadkeys ch: German (Switzerland, Sun dead keys)
de_mac ch: German (Switzerland, Macintosh)
! option
Tinir en compte que cada variant mostra la distribució que s'aplica en la
descripció.
Sovint, només la distribució necessita ser configurada. Per exemple, per
obtenir els fitxers de configuració regional per a la distribució del teclat
alemany i suís-alemany per l'entorn gràfic X:
$ lb config --bootappend-live "boot=live config locales=de_CH.UTF-8 keyboard-layouts=ch"
No obstant això, per als casos d'ús molt específics, potser es vol incloure
altres paràmetres. Per exemple, per establir un sistema francès, amb una
distribució de teclat French-Dvorak (anomenat Bepo) en un teclat USB TypeMatrix
EZ-Reach 2030, utilitzar:
$ lb config --bootappend-live \
"boot=live config locales=fr_FR.UTF-8 keyboard-layouts=fr keyboard-variants=bepo keyboard-model=tm2030usb"
Es poden especificar diversos valors per a cada una de les opcions keyboard-*
en una llista separada per comes amb l'excepció de keyboard-model, que només
accepta un valor. Veure la pàgina del manual keyboard(5) per a més detalls i
exemples de les variables XKBMODEL, XKBLAYOUT, XKBVARIANT i XKBOPTIONS. Si
s'especifiquen diversos valors de keyboard-variants es correspondran un a un
amb els valors keyboard-layouts (veure setxkbmap(1) opció -variant). Es poden
utilitzar valors buits, per exemple, per definir dos dissenys, el valor
predeterminat US QWERTY i l'altre US Dvorak:
$ lb config --bootappend-live \
"boot=live config keyboard-layouts=us,us keyboard-variants=,dvorak"
10.3 PERSISTèNCIA
.................
Un paradigma d'un live cd és ser un sistema pre-instaŀlat, que arrenca desde
medis de només lectura, com un cdrom, on les modificacions no sobreviuen als
reinicis del maquinari que l'executa.
Un sistema Debian Live és una generalització d'aquest paradigma i per tant,
compatible amb altres medis, a més dels CDs, però tot i així, en el seu
comportament per defecte, s'ha de considerar de només lectura i totes les
evolucions en temps d'execució del sistema es perden al apagar l'equip.
La "Persistència" és un nom comú per nomenar els diferents tipus de solucions
per guardar després de reiniciar algunes, o totes, les dades d'aquesta evolució
en temps d'execució del sistema. Per entendre com funciona, seria útil saber
que, encara que el sistema s'inicia i s'executa des de medis de només lectura,
les modificacions als fitxers i directoris s'escriuen ens medis d'escriptura,
en general un ramdisk (tmpfs) i les dades dels discos ram no sobreviuen als
reinicis.
Les dades emmagatzemades en aquest disc ram han de ser guardades en un suport
d'escriptura persistent com medis d'emmagatzematge locals, un recurs compartit
de xarxa o fins i tot una sessió d'una multisessió de un CD/DVD (re)grabable.
Tots aquests medis són compatibles amb Debian Live de diferents maneres, i tots
menys l'últim, requereixen un paràmetre especial que s'especifica en
l'arrencada: persistence.
Si s'utilitza el paràmetre d'arrencada persistence (i no s'utilitza
nopersistence) es proven els medis locals d'emmagatzematge (per exemple, discs
durs, unitats USB) buscant volums amb persistència durant l'arrencada. És
possible restringir els tipus de volums amb persistència que s'utilitzarà
mitjançant l'especificació de certs paràmetres d'arrencada que es descriuen a
la pàgina del manual de /live-boot/(7). Un volum amb persistència és qualsevol
dels següents:
* una partició, identificada pel seu nom GPT.
* un sistema de fitxers, identificat per la seva etiqueta de sistema de
fitxers.
* un fitxer imatge situat en l'arrel de qualsevol sistema de fitxers llegibles
(fins i tot una partició NTFS d'un altre SO), identificat pel seu nom de
fitxer.
L'etiqueta de volum per als overlays ha de ser persistence però serà passat per
alt a menys que contingui un fitxer anomenat persistence.conf que s'utilitza
per personalitzar completament la persistència del volum, és a dir, especificar
els directoris que es volen conservar en el volum de persistència després de
reiniciar. Veure El fitxer persistence.conf per més detalls.
Aquests són alguns exemples de com preparar un volum que s'utilitzarà per a la
persistència. Pot ser, per exemple, una partició ext4 en un disc dur o en una
clau USB creat amb, per exemple:
# mkfs.ext4 -L persistence /dev/sdb1
Veure també Utilitzar l'espai lliure en una memòria USB.
Si ja hi ha una partició al dispositiu, és pot canviar l'etiqueta amb un dels
següents:
# tune2fs -L persistence /dev/sdb1 # for ext2,3,4 filesystems
Heus aquí un exemple de com crear un fitxer imatge basat en ext4 per ser
utilitzat per a la persistència:
$ dd if=/dev/null of=persistence bs=1 count=0 seek=1G # for a 1GB sized image file
$ /sbin/mkfs.ext4 -F persistence
Un cop s'ha creat el fitxer imatge, per exemple, per fer /usr persistent però
només guardant els canvis que es fan en aquest directori i no tots els
continguts de /usr, es pot utilitzar l'opció "union". Si el fitxer imatge es
troba en el directori home, copiar-lo a l'arrel del sistema de fitxers del disc
dur i muntar-lo a /mnt de la següent manera:
# cp persistence /
# mount -t ext4 /persistence /mnt
A continuació, crear el fitxer persistence.conf afegint contingut i desmuntar
el fitxer imatge.
# echo "/usr union" >> /mnt/persistence.conf
# umount /mnt
Ara, reiniciar el sistema i arrencar el medi en viu amb el paràmetre
d'arrencada "persistence".
10.3.1 EL FITXER PERSISTENCE.CONF
.................................
Un volum amb l'etiqueta persistence ha de ser configurat mitjançant un fitxer
persistence.conf per fer directoris arbitraris persistents. Aquest fitxer,
ubicat a l'arrel del sistema de fitxers del volum, controla els directoris que
fa persistents, i de quina manera.
A la pàgina del manual de persistence.conf(5) s'explica en detall com es
configuran els muntatges de les overlays, però un simple exemple hauria de ser
suficient per la majoria d'usos. Si es vol fer el directori home i el directori
del cache d'APT persistents en un sistema de fitxers ext4 a la partició
/dev/sdb1:
# mkfs.ext4 -L persistence /dev/sdb1
# mount -t ext4 /dev/sdb1 /mnt
# echo "/home" >> /mnt/persistence.conf
# echo "/var/cache/apt" >> /mnt/persistence.conf
# umount /mnt
Després es reinicia el sistema. Durant la primera arrencada els continguts de
/home i /var/cache/apt es copiaran en el volum de la persistència, i d'aquí en
endavant tots els canvis en aquests directoris es guardaran en aquest volum.
Tenir en compte que les rutes que apareixen en el fitxer persistence.conf no
poden contenir espais en blanc o els components especials . i ... A més, ni
/lib, /lib/live (o qualsevol dels seus subdirectoris) ni / es poden fer
persistents utilitzant muntatges personalitzats. Com a solució per aquesta
limitació es pot afegir / union al fitxer persistence.conf per aconseguir una
persistència completa.
10.3.2 UTILITZAR DIVERSOS MEDIS PERSISTENTS
...........................................
Hi ha diferents mètodes per utilitzar múltiples volums de persistència per a
diferents casos d'ús. Per exemple, utilitzar diversos volums al mateix temps o
seleccionar-ne només un, entre varis, per a fins molt específics.
Es poden utilitzar diversos volums diferents de muntatges personalitzats (amb
els seus propis fitxers persistence.conf però si diversos volums fan que el
mateix directori sigui persistent, només s'utilitzarà un d'ells. Si qualsevol
dels dos muntatges són "imbricats" (és a dir, un és un sub-directori de
l'altre) el directori pare es muntarà abans que el directori fill per evitar
que amb el muntatge un directori no sigui ocultat per l'altre. Els muntatges
personalitzats imbricats són problemàtics si estan enumerats en el mateix
fitxer persistence.conf. Veure la pàgina del manual persistence.conf(5) per
saber com manejar aquest cas, si realment es necessita (una pista: en general
no cal fer-ho).
Un possible cas d'ús: Per a guardar les dades de l'usuari, és a dir /home i les
dades del superusuari, és a dir /root en diferents particions, crear dues
particions amb l'etiqueta persistence i afegir un fitxer persistence.conf en
cadascuna d'aquesta manera # echo "/home" > persistence.conf per a la primera
partició que guardarà els fitxers de l'usuari i # echo "/root" >
persistence.conf per a la segona partició que emmagatzemarà els fitxers del
superusuari. Finalment utilitzar el paràmetre d'arrencada persistence.
Si un usuari necessita múltiples volums de persistència del mateix tipus per a
diferents ubicacions o proves, com private i work, el paràmetre d'arrencada
persistence-label utilitzat juntament amb el paràmetre d'arrencada persistence
permetrà tenir diversos dispositius amb la mateixa, però única, persistència.
Un exemple seria si un usuari vol utilitzar una partició amb persistència amb
l'etiqueta private per a dades personals com els marcadors d'un navegador,
utilitzaria els paràmetres d'arrencada: persistence persistence-label=private.
I per emmagatzemar dades relacionades amb el treball, com a documents,
projectes de recerca o d'un altre tipus, utilitzaria els paràmetres
d'arrencada: persistence persistence-label=work.
És important recordar que aquests volums, private i work, també necessiten
tenir un fitxer persistence.conf en la seva arrel. La pàgina de manual de
/live-boot/ conté més informació sobre com utilitzar aquestes etiquetes amb els
noms més antics.
11. PERSONALITZACIó DE LA IMATGE BINàRIA
----------------------------------------
11.1 CARREGADOR D'ARRENCADA
...........................
/live-build/ utilitza /syslinux/ i alguns dels seus derivats (depenent del
tipus d'imatge) com carregadors d'arrencada per defecte. Es poden personalitzar
fàcilment de dues maneres.
Per utilitzar un tema complet, copiar /usr/share/live/build/bootloaders a
config/bootloaders i editar els fitxers allí. Si no es vol modificar totes les
configuracions del gestor d'arrencada disponibles, només cal utilitzar una
còpia local personalitzada d'un dels gestors d'arrencada, per exemple, copiar
la configuració d'*isolinux* a config/bootloaders/isolinux ja és suficient,
depenent del cas d'ús.
També hi ha la possibilitat de fer petits canvis. Per exemple, els derivats de
syslinux estan configurats per defecte amb un temps d'espera de 0 (zero) el que
significa que faran una pausa indefinida en la seva pantalla inicial fins que
es premi una tecla.
Per modificar el temps d'espera d'arrencada d'una imatge iso-hybrid es pot
editar el fitxer *isolinux.cfg* per defecte especificant el temps d'espera en
segons i afegir-lo a config/includes.binary/isolinux/
Un *isolinux.cfg* modificat per arrencar després de cinc segons seria semblant
a aquest:
include menu.cfg
default vesamenu.c32
prompt 0
timeout 50
Una forma alternativa d'aconseguir el mateix objectiu podria ser escriure un
script ganxo i afegir-lo a config/hooks/. Recordar afegir el sufix .binary per
tal que s'executi durant l'etapa binary. Un exemple proposat:
#!/bin/sh
sed -i -e 's|timeout 0|timeout 50|' binary/isolinux/isolinux.cfg
De la mateixa manera, si es vol utilitzar una imatge personalitzada splash.png
es pot afegir una imatge de 640x480 píxels a config/includes.binary/isolinux/
11.2 METADADES ISO
..................
Quan es crea una imatge binària ISO9660, es poden utilitzar les següents
opcions per afegir diverses metadades textuals. Això pot ajudar a identificar
fàcilment la versió o la configuració d'una imatge sense arrencar-la.
* LB_ISO_APPLICATION/--iso-application NAME: Ha de descriure l'aplicació que
serà a la imatge. La longitud màxima per aquest camp és de 128 caràcters.
* LB_ISO_PREPARER/--iso-preparer NAME: Ha de descriure al preparador de la
imatge, en general amb algunes dades de contacte. El valor per defecte per a
aquesta opció és la versió de /live-build/ utilitzada, la qual cosa pot ajudar
amb la depuració d'errors posterior. La longitud màxima per aquest camp és de
128 caràcters.
* LB_ISO_PUBLISHER/--iso-publisher NAME: Ha de descriure l'editor de la imatge,
en general amb algunes dades de contacte. La longitud màxima per aquest camp és
de 128 caràcters.
* LB_ISO_VOLUME/--iso-volume NAME: Això ha d'especificar l'ID de volum de la
imatge. Això s'utilitza com una etiqueta visible per l'usuari en algunes
plataformes com Windows i Apple Mac OS. La longitud màxima per aquest camp és
de 32 caràcters.
12. PERSONALITZACIó DE L'INSTAŀLADOR DE DEBIAN
----------------------------------------------
Les imatges del sistema Debian Live es poden integrar amb l'instaŀlador de
Debian. Hi ha un nombre de diferents tipus d'instaŀlació, que varien en el que
s'inclou i en com opera l'instaŀlador.
Tenir en compte l'ús acurat de les lletres majúscules quan es refereix a
"l'instaŀlador de Debian" en aquesta secció - quan s'utilitza així ens referim
explícitament a l'instaŀlador normal del sistema Debian, i no a una altra cosa.
Es veu sovint abreujat com "d-i".
12.1 TIPUS D'INSTAŀLADOR DE DEBIAN
..................................
Els tres principals tipus d'instaŀlador són els següents:
*Instaŀlador de Debian "Normal"*: Aquesta és una imatge normal de Debian Live
amb un nucli i initrd independents que (quan es seleccionen des del carregador
d'arrencada adequat) realitzen una instaŀlació estàndard de Debian, igual que
si s'hagués descarregat i arrencat una imatge de Debian des d'un CD. Les
imatges que contenen un sistema viu i aquest tipus d'instaŀlador independent
s'anomenen sovint "imatges combinades".
Amb aquest tipus d'imatges, Debian s'instaŀla descarregant i instaŀlant paquets
.deb mitjançant /debootstrap/, des dels medis locals o alguna xarxa, aixó
resulta en un sistema Debian per defecte instaŀlat al disc dur.
Tot aquest procés pot ser preconfigurat i personalitzadat de moltes formes,
veure les pàgines corresponents al manual de l'instaŀlador de Debian per a més
informació. Quan es té un fitxer de preconfiguració que funcioni, /live-build/
pot posar-lo automàticament a la imatge i activar-lo.
*Instaŀlador de Debian "Live"*: Aquesta és una imatge Debian Live amb un nucli
i initrd independents que (quan es seleccionen des del carregador d'arrencada
adequat) llancen un instaŀlador de Debian.
La instaŀlació continuarà de forma idèntica a l'instaŀlació que s'ha descrit
anteriorment, però en la fase d'instaŀlació dels paquets, en lloc d'utilitzar
/debootstrap/ per buscar-los i instalar-los, es copia el sistema de fitxers viu
a la destinació. Això s'aconsegueix amb un udeb especial anomenat
/live-installer/.
Després d'aquesta etapa, l'instaŀlador de Debian continua de forma normal,
instaŀlant i configurant elements com ara els gestors d'arrencada i els usuaris
locals, etc
*Nota:* per donar suport a les entrades de l'instaŀlador normal i live en el
gestor d'arrencada del mateix medi s'ha de desactivar el /live-installer/
mitjançant la preconfiguració live-installer/enable=false.
*Instaŀlador de Debian "d'escriptori"*: Independentment del tipus d'instaŀlador
de Debian inclòs, es pot iniciar el d-i des de l'escriptori fent clic damunt
una icona. Aixó és senzill per l'usuari però perquè funcioni s'ha d'afegir el
paquet /debian-installer-launcher/.
Tenir en compte que, per defecte, /live-build/ no inclou imatges de
l'instaŀlador de Debian en les imatges, ha de ser específicament activat amb lb
config. A més, tenir en compte que per que funcioni l'instaŀlador
"d'escriptori" el nucli del sistema viu ha de coincidir amb el nucli que el d-i
utilitza per a l'arquitectura especificada. Per exemple:
$ lb config --architectures i386 --linux-flavours 486 \
--debian-installer live
$ echo debian-installer-launcher >> config/package-lists/my.list.chroot
12.2 PERSONALITZACIó DE L'INSTAŀLADOR DE DEBIAN AMB PRECONFIGURACIó
...................................................................
Com es descriu en el Manual de l'instaŀlador de Debian, a l'apèndix B a
, "la preconfiguració
proporciona una manera de respondre a les preguntes durant la instaŀlació,
sense haver d'introduir les respostes manualment mentre la instaŀlació està en
curs. Això permet automatitzar completament la majoria dels tipus
d'instaŀlacions i fins i tot ofereix algunes característiques no disponibles
durant les instaŀlacions normals." Aquest tipus de personalització
s'aconsegueix millor amb /live-build/ coŀlocant la configuració en un fitxer
preseed.cfg a config/debian-installer/. Per exemple, per preconfigurar la
variant local en_US:
$ echo "d-i debian-installer/locale string en_US" \
>> config/debian-installer/preseed.cfg
12.3 PERSONALITZAR EL CONTINGUT DE L'INSTAŀLADOR DE DEBIAN
..........................................................
Per a fins experimentals o de depuració d'errors, és possible que es vulgui
incloure paquets udeb creats localment per al d-i. Per afegir-los a la imatge
posar-los a config/packages.binary/. Es poden incloure fitxers addicionals o de
substitució i alguns directoris a l'initrd de l'instaŀlador d'una manera
similar a Live/chroot local includes, posant el material a
config/includes.debian-installer/.
PROJECTE
========
13. CONTRIBUIR AL PROJECTE
--------------------------
Quan es presenta una contribució, identificar clarament el titular dels drets
d'autor i s'ha d'incloure la declaració de concessió de llicències. Recordar
que per ser acceptada, la contribució ha de tenir una llicencia igual que la
resta del document, a saber, la versió de la GPL 3 o superior.
Les contribucions al projecte, com ara traduccions i pegats, són molt
benvingudes. Qualsevol persona pot fer un lliurament directe al repositori. No
obstant això, demanem que s'enviïn els canvis grans a la llista de correu per
parlar-ne en primer lloc. Veure la secció Contacte per més informació.
El projecte Debian Live utilitza Git com a sistema de control de versions i
gestió de codi font. Com s'explica en Repositoris Git hi ha dues branques
principals de desenvolupament: *debian* i *debian-next*. Tothom pot fer
lliuraments a les branques debian-next dels repositoris /live-boot/,
/live-build/, /live-config/, /live-images/, /live-manual/ i /live-tools/.
No obstant això, hi ha certes restriccions. El servidor rebutja:
* Push que no són fast-forward.
* Commits merge.
* Afegir o eliminar etiquetes o branques.
Tot i que tots els lliuraments poden ser revisats, demanem que s'utilitzi el
sentit comú i es facin bons lliuraments amb bons missatges.
* Escriure missatges de lliurament que consisteixen en oracions completes i
significatives en anglès, començant amb una lletra majúscula i acabant amb un
punt. En general, aquests començaran amb la forma
'Fixing/Adding/Removing/Correcting/Translating/...'.
* Escriure bons missatges de lliurament. La primera línia ha de ser un resum
exacte dels continguts del lliurament, que s'inclourà en la llista de canvis.
Si es necessita fer algunes explicacions més, escriure a sota deixant una línia
en blanc després de la primera línea i després una altra línia en blanc després
de cada paràgraf. Les línies dels paràgrafs no han de superar els 80 caràcters
de longitud.
* Fer lliuraments de manera atòmica, és a dir, no barrejar coses no
relacionades en el mateix lliurament. Fer un lliurament diferent per a cada
canvi que es faci.
13.1 FER CANVIS
...............
Per tal de fer un push als repositoris, s'ha de seguir el següent procediment.
Aquí s'utilitza /live-manual/ com a exemple, per tant, cal substituir-lo pel
nom del repositori amb que es desitja treballar. Per obtenir informació
detallada sobre com editar /live-manual/ veure Contribuir a aquest document.
* Obtenir la clau pública:
$ mkdir -p ~/.ssh/keys
$ wget http://live.debian.net/other/keys/git@live.debian.net -O ~/.ssh/keys/git@live.debian.net
$ wget http://live.debian.net/other/keys/git@live.debian.net.pub -O ~/.ssh/keys/git@live.debian.net.pub
$ chmod 0600 ~/.ssh/keys/git@live.debian.net*
* Afegir la següent secció a la configuració del vostre openssh-client:
$ cat >> ~/.ssh/config << EOF
Host live.debian.net
Hostname live.debian.net
User git
IdentityFile ~/.ssh/keys/git@live.debian.net
EOF
* Fer una còpia del manual a través de ssh:
$ git clone git@live.debian.net:/live-manual.git
$ cd live-manual && git checkout debian-next
* Assegurar-se de tenir el autor i el correu electrònic configurats al Git:
$ git config user.name "John Doe"
$ git config user.email john@example.org
*Important:* Tenir en compte que s'han d'enviar els canvis a la branca
*debian-next*.
* Fer els canvis. En aquest exemple s'hauria d'escriure primer una nova secció
sobre aplicar pegats i després preparar-se per afegir els fitxers i escriure el
missatge de la següent manera:
$ git commit -a -m "Adding a section on applying patches."
* Fer un push al servidor:
$ git push
14. INFORMAR DELS ERRORS
------------------------
Debian Live està lluny de ser perfecte, però volem que sigui el més perfecte
possible - amb la vostra ajuda. No dubtar d'informar sobre un error. És millor
omplir un informe dues vegades que mai. No obstant això, aquest capítol inclou
recomanacions sobre com presentar bons informes d'errors.
Per als impacients
* Sempre consultar primer les actualitzacions del estat de la imatge a la
nostra pàgina web a per veure els problemes coneguts.
* Sempre tractar de reproduir l'error amb *les versions més recents* de
/live-build/, /live-boot/, /live-config/ i /live-tools/ abans d'enviar un
informe d'errors.
* Intentar donar *la informació més específica possible* sobre l'error. Això
inclou (almenys) la versió de /live-build/, /live-boot/, /live-config/ i
/live-tools/ i la distribució del sistema en viu que s'està construint.
14.1 PROBLEMES CONEGUTS
.......................
Ja que les distribucions Debian *testing* i Debian *unstable* són blancs
mòbils, quan s'especifica una d'elles com sistema de destinació, no sempre és
possible construir amb èxit.
Si això és massa difícil, no construir un sistema basat en *testing* o
*unstable*, sinó més aviat, utilitzar *stable*. /live-build/ sempre construeix
la versió *stable* per defecte.
El problemes coneguts es mostren sota la secció 'status' a la nostra pàgina web
a .
Està fora de l'abast d'aquest manual ensenyar a identificar correctament i
solucionar els problemes dels paquets de les distribucions en desenvolupament,
però, hi ha dues coses que sempre es pot provar: Si la construcció falla quan
la distribució de destinació és *testing*, provar *unstable*. Si *unstable*
tampoc funciona, tornar a *testing* i fer un pin de la versió més recent del
paquet que falla de *unstable* (veure APT pinning per més detalls).
14.2 RECONSTRUIR DES DE ZERO
............................
Per assegurar-se que un error en particular no és causat per un sistema mal
construït, reconstruir sempre tot el sistema en viu a partir de zero per veure
si l'error és reproduïble.
14.3 FER SERVIR PAQUETS ACTUALITZATS
....................................
La utilització de paquets obsolets pot causar problemes significatius al
tractar de reproduir (i en última instància, arreglar) el problema. Comprovar
que el sistema de construcció està actualitzat i tots els paquets inclosos en
la imatge estan també actualitzats.
14.4 RECOPILAR INFORMACIó
.........................
Proporcionar informació suficient amb l'informe. Incloure, com a mínim, la
versió exacta de /live-build/ i els passos per a reproduir-lo. Utilitzar el
sentit comú i proporcionar tota altra informació pertinent si es pensa que aixó
pot ajudar a resoldre el problema.
Per treure el màxim profit del informe d'errors, es requereix com a mínim la
informació següent:
* Arquitectura del sistema amfitrió
* Versió de /live-build/ al sistema amfitrió
* Versió de /debootstrap/ i/o /cdebootstrap/ al sistema amfitrió
* Arquitectura del sistema en viu
* Distribució del sistema en viu
* Versió de /live-boot/ al sistema amfitrió
* Versió de /live-config/ al sistema amfitrió
* Versió de /live-tools/ al sistema amfitrió
Es pot generar un log del procés de construcció mitjançant l'ordre tee.
Recomanem fer-ho automàticament amb un script auto/build (veure Gestió d'una
configuració per més detalls).
# lb build 2>&1 | tee build.log
Durant l'arrencada, /live-boot/ i /live-config/ emmagatzemen els seus logs a
/var/log/live/. Comprovar aquest fitxers per detectar missatges d'error.
A més, per descartar altres errors, sempre és una bona idea comprimir el
directori config/ i pujar-lo a algun lloc (*no* enviar-lo com arxiu adjunt a la
llista de correu), perquè puguem tractar de reproduir els errors que s'han
trobat. Si això és difícil (per exemple, a causa del tamany del arxiu) es pot
utilitzar la sortida de lb config --dump que produeix un resum del arbre de
configuració (és a dir, fa un llistat dels fitxers dins els subdirectoris de
config/, però no els inclou).
Recordar que s'ha d'enviar qualsevol log que es produeixi amb la configuració
regional en anglès, per exemple, executar les ordres de /live-build/ començant
per LC_ALL=C o LC_ALL=en_US.
14.5 AïLLAR EL CAS QUE FALLA, SI éS POSSIBLE
............................................
Si pot ser, aïllar el cas que falla al canvi més petit possible que fa que no
funcioni. No sempre és fàcil fer això, per tant, si no es possible fer-ho pel
informe, no preocupar-se. No obstant això, si es planeja bé el cicle de
desenvolupament, i s'utilitzen petits conjunts de canvis suficients per
iteració, es pot ser capaç d'aïllar el problema mitjançant la construcció d'una
configuració 'base' més senzilla que s'ajusti a la configuració desitjada més
el conjunt de canvis que fa que no funcioni. Si es dificil classificar quins
canvis fan que falli, pot ser que s'inclogui massa en cada conjunt de canvis i
s'ha de desenvolupar en petits increments.
14.6 UTILITZAR EL PAQUET CORRECTE PER INFORMAR DE L'ERROR
.........................................................
Si no és clar quin component és el responsable de l'error o si l'error és
general pel que fa als sistemes vius, es pot omplir un informe d'errors sobre
el pseudopaquet debian-live.
No obstant això, estarem molt agraïts si s'intenta limitar la recerca segons el
lloc on apareix l'error.
14.6.1 A L'HORA DE CONSTRUIR MENTRE BOOTSTRAPPING
.................................................
/live-build/ crea primer un sistema Debian bàsic amb /debootstrap/ o
/cdebootstrap/. Depenent de l'eina utilitzada i la distribució Debian que
s'està creant mitjançant el bootstrapping, pot fallar. Si un error apareix
aquí, comprovar si l'error està relacionat amb un paquet específic de Debian
(el més probable), o si està relacionat a l'eina bootstraping en si mateixa.
En ambdós casos, això no és un error de Debian Live, sinó de Debian en si
mateix i, probablement, no ho podem arreglar directament. Informar del error
sobre l'eina de debootstrapping o el paquet que falla.
14.6.2 A L'HORA DE CONSTRUIR, DURANT LA INSTAŀLACIó DE PAQUETS
..............................................................
/live-build/ instaŀla paquets addicionals del arxiu de Debian i en funció de la
distribució Debian utilitzada i de l'estat diari de l'arxiu, pot fallar. Si un
error apareix aquí, comprovar si l'error és també reproduïble en un sistema
normal.
Si aquest és el cas, no es tracta d'un error de Debian Live, sinó de Debian -
Informar d'això sobre el paquet que falla. Executar /debootstrap/ per separat
de la construcció del sistema en viu o executar lb bootstrap --debug per tenir
més informació.
A més, si es fa servir un mirall local i/o qualsevol tipus de proxy i s'està
experimentant algun problema, sempre s'ha de mirar de reproduir-lo fent un
bootstrapping a partir d'un mirall oficial.
14.6.3 EN EL MOMENT D'ARRENCAR
..............................
Si la imatge no arrenca, informar a la llista de correu, juntament amb la
informació soŀlicitada a Recopilar informació. No oblidar-se d'esmentar,
com/quan la imatge falla, ja sigui amb virtualització o maquinari real. Si
s'utilitza una tecnologia de virtualització d'algun tipus, sempre fer la prova
amb maquinari real abans d'informar d'un error. Proporcionar una captura de
pantalla de l'error és també molt útil.
14.6.4 EN TEMPS D'EXECUCIó
..........................
Si un paquet s'ha instaŀlat correctament, però falla quan s'executa el sistema
en viu, això és probablement un error a Debian Live. No obstant això:
14.7 FER LA RECERCA
...................
Abans de presentar l'informe d'errors, cercar a la web el missatge d'error o
símptoma que s'està rebent. Ja que és molt poc probable que sigui l'única
persona que té un problema en particular. Sempre hi ha una possibilitat que
hagi estat discutit en un altre lloc i hi hagi una possible solució, pegat o
s'hagi proposat una solució alternativa.
S'ha de prestar especial atenció a la llista de correu de Debian Live, així com
a la pàgina web, ja que és probable que continguin la informació més
actualitzada. Si aquesta informació existeix, incloure una referènca a aquesta
en l'informe d'errors.
A més, s'hauria de comprovar les llistes d'errors actuals de /live-build/,
/live-boot/, /live-config/ i /live-tools/ per veure si ja s'ha informat sobre
alguna cosa semblant .
14.8 ON INFORMAR DELS ERRORS
............................
El projecte Debian Live manté un registre de tots els errors en el sistema de
seguiment d'errors de Debian (BTS). Per obtenir informació sobre la utilització
del sistema, es pot consultar . També es poden enviar
els informes dels errors mitjançant l'ordre reportbug del paquet amb el mateix
nom.
En general, s'ha d'informar dels errors en temps de construcció contra el
paquet /live-build/, dels errors durant l'arrencada contra /live-boot/ i dels
errors de temps d'execució contra /live-config/. Si no s'està segur de quin
paquet és l'adequat o es necessita més ajuda abans d'enviar un informe
d'errors, informar contra el pseudopaquet debian-live. Nosaltres ens farem
càrrec d'ell i el reassignarem on sigui procedent.
Tenir en compte que els errors trobats en les distribucions derivades de Debian
(com Ubuntu i altres) no han de ser enviats al BTS de Debian tret que puguin
ser reproduïts també en sistemes Debian utilitzant paquets oficials de Debian.
15. ESTIL DE CODI
-----------------
En aquest capítol es documenta l'estil de codi utilitzat a Debian Live.
15.1 COMPATIBILITAT
...................
* No utilitzar una sintaxi o semàntica que sigui exclusiva de l'intèrpret
d'ordres Bash. Per exemple, l'ús dels arrays.
* Utilitzar només el subconjunt POSIX - per exemple, utilitzar $(foo) en lloc
de `foo`.
* Es pot comprovar els scripts amb 'sh -n' i 'checkbashisms'.
* Assegurar-se que tot el codi funciona amb 'set -e'.
15.2 INDENTACIó
...............
* Utilitzar sempre tabuladors en lloc d'espais.
15.3 AJUST DE LíNIA
...................
* En general, les línies són de 80 caràcters com a màxim.
* Utilitzar "l'estil Linux" de salts de línia:
Mal:
if foo; then
bar
fi
Bé:
if foo
then
bar
fi
* El mateix val per a les funcions:
Mal:
Foo () {
bar
}
Bé:
Foo ()
{
bar
}
15.4 VARIABLES
..............
* Les variables van sempre en majúscules.
* Les variables que s'utilitzen a /live-build/ sempre comencen amb el prefix
LB_
* Les variables temporals internes de /live-build/ comencen amb el prefix _LB_
* Les variables locals comencen amb el prefix /live-build/ __LB_
* Les variables en relació a un paràmetre d'arrencada de /live-config/ comencen
amb LIVE_.
* Totes les altres variables de /live-config/ comencen amb el prefix _
* Utilitzar claus al voltant de les variables, per exemple, escriure ${FOO} en
lloc de $FOO.
* Protegir sempre les variables amb cometes per respectar els espais en blanc
potencials: escriure "${FOO}" no ${FOO}.
* Per raons de coherència, utilitzar sempre cometes al assignar valors a les
variables:
Mal:
FOO=bar
Bé:
FOO="bar"
* Si s'utilitzen múltiples variables, posar cometes a l'expressió completa:
Mal:
if [ -f "${FOO}"/foo/"${BAR}"/bar ]
then
foobar
fi
Bé:
if [ -f "${FOO}/foo/${BAR}/bar" ]
then
foobar
fi
15.5 MISCEŀLàNIA
................
* Utilitzar "|" (sense les cometes) com separador en l'ús de sed, per exemple,
"sed -e 's|foo|bar|'" (sense "").
* No utilitzar l'ordre test per fer comparacions o tests, utilitzar "[" "]"
(sense ""); per exemple, "if [ -x /bin/foo ]; ..." i no "if test -x /bin/foo;
...".
* Utilitzar case sempre que sigui possible en lloc de test, ja que és més fàcil
de llegir i més ràpid en l'execució.
* Fer servir noms en majúscula per les funcions per evitar conflictes amb
l'entorn dels usuaris.
16. PROCEDIMENTS
----------------
Aquest capítol documenta els procediments dins del projecte Debian Live per les
diferents tasques que necessiten la cooperació amb altres equips de Debian.
16.1 PUBLICACIONS MAJORS
........................
El llançament d'una nova versió de Debian inclou una gran quantitat de
diferents equips que treballen junts per fer que aixó succeeixi. En algun
moment, l'equip Live arriba i construeix imatges en viu del sistema. Els
requisits per fer això són:
* Un mirall que contingui les versions publicades dels arxius de debian i
debian-security on pugui accedir el buildd de debian-live.
* S'ha de conèixer el nom de la imatge (per exemple,
debian-live-VERSION-ARCH-FLAVOUR.iso).
* S'han de sincronitzar les dades de debian-cd (udeb exclude lists).
* S'han de sincronitzar els includes de debian-cd (README.*, doc/*, etc.).
* Les imatges es construeixen i s'en fa una rèplica a cdimage.debian.org.
16.2 PUBLICACIONS PUNTUALS
..........................
* Un cop més, necessitem miralls actualitzats de debian i debian-security.
* Les imatges es construeixen i s'en fa una rèplica a cdimage.debian.org.
* Enviar un anunci per correu electrònic.
16.2.1 ÙLTIMA PUBLICACIó PUNTUAL D'UNA VERSIó DE DEBIAN
.......................................................
Recordar que s'han d'ajustar els miralls chroot i binary en la construcció de
l'última sèrie d'imatges per a una versió de Debian després de canviar-les de
ftp.debian.org a archive.debian.org. D'aquesta manera, les imatges
prefabricades ja velles continuaran sent útils sense modificacions per part
dels usuaris.
16.2.2 PLANTILLA PER ANUNCIAR UNA PUBLICACIó PUNTUAL
....................................................
Es pot generar un correu per anunciar una publicació puntual mitjançant la
plantilla següent i l'ordre:
$ sed \
-e 's|@MAJOR@|7.0|g' \
-e 's|@MINOR@|7.0.1|g' \
-e 's|@CODENAME@|wheezy|g' \
-e 's|@ANNOUNCE@|2013/msgXXXXX.html|g'
Llegir el correu acuradament abans d'enviar-lo i passar-lo als altres per a la
correcció d'errades.
Updated Debian Live @MAJOR@: @MINOR@ released
The Debian Live project is pleased to announce the @MINOR@ update of the
Live images for the stable distribution Debian @MAJOR@ (codename "@CODENAME@").
The images are available for download at:
and later at:
This update includes the changes of the Debian @MINOR@ release:
Additionally it includes the following Live-specific changes:
* [INSERT LIVE-SPECIFIC CHANGE HERE]
* [INSERT LIVE-SPECIFIC CHANGE HERE]
* [LARGER ISSUES MAY DESERVE THEIR OWN SECTION]
About Debian Live
-----------------
The Debian Live project produces the tools used to build official
Debian Live systems and the official Debian Live images themselves.
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.
Contact Information
-------------------
For further information, please visit the Debian Live web pages at
, or contact the Debian Live team at
.
17. REPOSITORIS GIT
-------------------
La llista de tots els repositoris del Projecte Debian Live és a
. Les URLs git del projecte tenen la forma:
protocol://live.debian.net/git/repositori. Per tant, per tal de clonar
/live-manual/ en només lectura, llançar:
$ git clone git://live.debian.net/git/live-manual.git
O,
$ git clone https://live.debian.net/git/live-manual.git
O,
$ git clone http://live.debian.net/git/live-manual.git
Les adreces per clonar amb permís d'escriptura tenen la forma:
git@live.debian.net:/repositori.
Així que, de nou, per clonar /live-manual/ a través de ssh escriure:
$ git clone git@live.debian.net:live-manual.git
L'arbre git es compon de diverses branques diferents. Les branques *debian* i
*debian-next* són particularment notables perquè contenen el treball real que,
amb el temps, serà inclòs en cada nova versió.
Després de clonar qualsevol dels repositoris existents, estarem a la branca
*debian*. Això és apropiat per fer una ullada a l'estat de l'última versió del
projecte, però abans de començar a treballar és fonamental canviar a la branca
*debian-next*. Per fer això:
$ git checkout debian-next
La branca *debian-next*, que no sempre és fast-forward, és on es realitzen tots
els canvis abans de fusionar-los amb la branca *debian*. Per fer una analogia,
és com un camp de proves. Si s'està treballant en aquesta branca i es necessari
fer un pull, s'haurà de fer un git pull --rebase perquè les modificacions
locals es guardin mentre s'actualitza des del servidor i llavors els canvis
locals es posaran al damunt de tot.
17.1 GESTIó DE MúLTIPLES REPOSITORIS
....................................
Si es té la intenció de clonar diversos repositoris de Debian Live i canviar a
la branca *debian-next* immediatament per comprovar l'últim codi, escriure un
pegat o contribuir amb una traducció, s'ha de saber que el servidor git
proporciona un fitxer mrconfig per facilitar el maneig de múltiples
repositoris. Per utilitzar-lo cal instaŀlar el paquet /mr/ i després d'això,
fer:
$ mr bootstrap http://live.debian.net/other/mr/mrconfig
Aquesta ordre automàticament clonarà i canviarà a la branca *debian-next* els
repositoris de desenvolupament dels paquets debian produïts pel projecte.
Aquests inclouen, entre d'altres, el repositori /live-images/, que conté les
configuracions utilitzades per construir les imatges prefabricades que el
projecte publica per a l'ús general. Per obtenir més informació sobre com
utilitzar aquest repositori, consultar Clonar una configuració publicada via
Git
EXEMPLES
========
18. EXEMPLES
------------
En aquest capítol s'inclouen exemples de construccions per a casos d'ús
específics amb Debian Live. Si s'és nou en la construcció d'imatges de Debian
Live pròpies, us suggerim mirar els tres tutorials en seqüència, ja que cada un
ensenya noves tècniques que ajuden a utilitzar i entendre els exemples
restants.
18.1 ÚS DELS EXEMPLES
.....................
Per utilitzar aquests exemples es necessita un sistema de construcció que
compleixi les exigències enumerades a Requisits y que tingui /live-build/
instaŀlat com es descriu a Instaŀlació de live-build.
Cal notar que, per abreujar, en aquests exemples no s'especifica un mirall
local per utilitzar en la construcció. Es poden accelerar les descàrregues
considerablement si s'utilitza un mirall local. Es pot especificar les opcions
quan s'utilitza lb config, com es descriu a Miralls de distribució utilitzats
en temps de construcció, o per a major comoditat, establir el valor
predeterminat per al sistema de construcció en el fitxer /etc/live/build.conf.
Només cal crear aquest fitxer i establir a les variables al mirall preferit.
Tots els altres miralls que s'utilitzin en la construcció adoptaran valors per
defecte segons aquests valors. Per exemple:
LB_MIRROR_BOOTSTRAP="http://mirror/debian/"
LB_MIRROR_CHROOT_SECURITY="http://mirror/debian-security/"
LB_MIRROR_CHROOT_BACKPORTS="http://mirror/debian-updates/"
18.2 TUTORIAL 1: UNA IMATGE PER DEFECTE
.......................................
*Cas d'ús:* Crear una primera imatge senzilla, aprenent els conceptes bàsics de
/live-build/.
En aquest tutorial, anem a construir una imatge ISO híbrida per defecte de
Debian Live que contingui només els paquets de base (no té Xorg) i altres
paquets de suport de Debian Live, com un primer exercici en l'ús de
/live-build/.
No pot ser més senzill que això:
$ mkdir tutorial1 ; cd tutorial1 ; lb config
Examinar el contingut del directori config/ si es vol. Es veurà emmagatzemada
aquí una configuració en esquelet, a punt per ser personalitzada o, en aquest
cas, per ser utilitzada immediatament per construir una imatge per defecte.
Ara, com a superusuari, construir la imatge, guardant un log del que es
construeix amb tee.
# lb build 2>&1 | tee build.log
Suposant que tot va bé, després d'una estona, el directori actual contindrà una
binary.hybrid.iso. Aquesta imatge ISO híbrida es pot arrencar en una màquina
virtual tal com s'explica a Provar una imatge ISO amb Qemu i Provar una imatge
ISO amb virtualbox, o bé copiada a un dispositiu USB com es descriu a Gravar
una imatge ISO en un medi físic i Còpiar una imatge ISO híbrida en un
dispositiu USB, respectivament.
18.3 TUTORIAL 2: UNA UTILITAT DE NAVEGADOR WEB
..............................................
*Cas d'ús:* Crear una imatge d'una utilitat de navegador web, aprenent a
aplicar personalitzacions.
En aquest tutorial, anem a crear una imatge adequada per al seu ús com a una
utilitat de navegador web, que serveix com introducció a la personalització de
les imatges de Debian Live.
$ mkdir tutorial2
$ cd tutorial2
$ echo "task-lxde-desktop iceweasel" >> config/package-lists/my.list.chroot
La nostra elecció de LXDE per a aquest exemple reflecteix el nostre desig
d'oferir un entorn d'escriptori mínim, ja que l'objectiu de la imatge és l'únic
ús que tenim al cap, el navegador web. Podríem anar encara més lluny i oferir
una configuració per defecte per al navegador web a
config/includes.chroot/etc/iceweasel/profile/, o paquets addicionals de suport
per a la visualització de diversos tipus de contingut web, però deixem això com
a un exercici per al lector.
Construir la imatge, de nou com a superusuari, guardant un log com al Tutorial
1:
# lb build 2>&1 | tee build.log
Un cop més, verificar que la imatge està bé i provar-la, com al Tutorial 1.
18.4 TUTORIAL 3: UNA IMATGE PERSONALITZADA
..........................................
*Cas d'ús:* Crear un projecte per construir una imatge personalitzada, que
contingui el programari favorit per portar en una memòria USB allà on es vagi i
que evolucionarà en revisions successives tal i com les necessitats i les
preferències canvien.
Com la nostra imatge personalitzada canviarà durant un nombre de revisions i
volem fer un seguiment d'aquests canvis, provar coses experimentals i
possiblement revertir-les si les coses no surten bé, anem a mantenir la nostra
configuració en el popular sistema de control de versions git. També
utilitzarem les millors pràctiques de configuració automàtica mitjançant
scripts auto com s'explica a Gestió d'una configuració.
18.4.1 PRIMERA REVISIó
......................
$ mkdir -p tutorial3/auto
$ cp /usr/share/doc/live-build/examples/auto/* tutorial3/auto/
$ cd tutorial3
Editar auto/config de la manera següent:
#!/bin/sh
lb config noauto \
--architectures i386 \
--linux-flavours 686-pae \
"${@}"
Executar lb config per crear l'arbre de configuració, utilitzant el script
auto/config que s'acaba de crear:
$ lb config
Ara, omplir la llista local de paquets:
$ echo "task-lxde-desktop iceweasel xchat" >> config/package-lists/my.list.chroot
En primer lloc, amb --architectures i386 s'assegura que al nostre sistema de
construcció amd64 podem construir una versió de 32 bits adequada per al seu ús
en la majoria de màquines. En segon lloc, fem servir --linux-flavours 686-pae
perquè no creiem que utilitzarem aquesta imatge en sistemes molt més vells. En
tercer lloc, hem triat la tasca metapaquet /lxde/ per donar-nos un escriptori
mínim. I, finalment, hem afegit dos paquets inicials favorits: /iceweasel/ i
/xchat/.
Ara, construir la imatge:
# lb build
Tenir en compte que a diferència dels dos primers tutorials, ja no s'ha
d'escriure 2>&1 | tee build.log ja que ara s'inclou al script auto/build.
Quan s'ha provat la imatge (com al Tutorial 1) i s'està satisfet del seu
funcionament, és el moment d'iniciar el repositòri git, afegint només els
scripts auto que s'han creat, i llavors fer el primer lliurament:
$ git init
$ cp /usr/share/doc/live-build/examples/gitignore .gitignore
$ git add .
$ git commit -a -m "Initial import."
18.4.2 SEGONA REVISIó
.....................
En aquesta revisió, anem a netejar després de la primera construcció, afegir el
paquet /vlc/ a la nostra configuració, reconstruir, provar i fer el lliurament.
L'ordre lb clean netejarà tots els fitxers generats en la construcció anterior
a excepció del cache, el que estalvia haver de tornar a descarregar els
paquets. Això assegura que el lb build següent tornarà a executar totes les
etapes per regenerar els fitxers de la nostra nova configuració.
# lb clean
Ara afegim el paquet /vlc/ al llistat de paquets local a
config/package-lists/my.list.chroot:
$ echo vlc >> config/package-lists/my.list.chroot
Construir de nou:
# lb build
Provar, i quan s'estigui satisfet, fer el lliurament de la propera revisió:
$ git commit -a -m "Adding vlc media player."
Per descomptat, es possible fer canvis més complicats en la configuració,
potser afegint fitxers en els subdirectoris de config/. Quan es fa un
lliurament de les noves revisions, s'ha de tenir cura de no editar a mà o
incloure en el lliurament els fitxers de nivell superior de config que contenen
variables LB_*, ja que són productes de construcció també, i sempre són
netejats per lb clean i tornats a crear per lb config a través dels seus
respectius scripts auto.
Hem arribat al final de la nostra sèrie de tutorials. Molts més tipus de
personalització són possibles, amb les poques característiques explorades en
aquests senzills exemples, es poden crear una varietat gairebé infinita
d'imatges diferents. Els exemples que queden d'aquesta secció tracten diferents
casos d'ús extrets de les experiències recollides dels usuaris de Debian Live.
18.5 UN CLIENT PER A UN QUIOSC VNC
..................................
*Cas d'ús:* Crear una imatge amb /live-build/ per connectar-se directament a un
servidor VNC al arrencar.
Fer un directori de treball i crear una configuració d'esquelet en el seu
interior, desactivant els «recommends» per fer un sistema mínim. I a
continuació, crear dues llistes inicials de paquets: La primera generada per un
script proporcionat per /live-build/ anomenat Packages (veure Generar llistes
de paquets), i la segona incloent-hi /xorg/, /gdm3/, /metacity/ i
/xvnc4viewer/.
$ mkdir vnc-kiosk-client
$ cd vnc-kiosk-client
$ lb config -a i386 -k 686-pae --apt-recommends false
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
$ echo "xorg gdm3 metacity xvnc4viewer" > config/package-lists/my.list.chroot
Com s'explica a Afinar APT per estalviar espai pot ser que s'hagi de tornar a
afegir alguns paquets recomanats per fer que la imatge funcioni correctament.
Una manera fàcil d'enumerar els recommends és utilitzar /apt-cache/. Per
exemple:
$ apt-cache depends live-config live-boot
En aquest exemple, ens vam assabentar que havíem de tornar a incloure diversos
paquets recomanats per /live-config/ i /live-boot/: user-setup perquè funcioni
l'autologin i sudo com a programa essencial per apagar el sistema. A més,
podria ser útil afegir live-tools per poder copiar la imatge en la memòria RAM
i eject per expulsar, finalment, el medi en viu. Per tant:
$ echo "live-tools user-setup sudo eject" > config/package-lists/recommends.list.chroot
Després, crear el directori /etc/skel a config/includes.chroot i posar un
fitxer .xsession personalitzat per a l'usuari per defecte que posarà en marxa
/metacity/ i iniciarà /xvncviewer/, connectant al port 5901 d'un servidor
ubicat a 192.168.1.2:
$ mkdir -p config/includes.chroot/etc/skel
$ cat > config/includes.chroot/etc/skel/.xsession << EOF
#!/bin/sh
/usr/bin/metacity &
/usr/bin/xvncviewer 192.168.1.2:1
exit
EOF
Construir la imatge:
# lb build
Gaudir-ne.
18.6 UNA IMATGE BàSICA PER A UN DISPOSITIU USB DE 128MB
.......................................................
*Cas d'ús:* Crear una imatge per defecte amb alguns components eliminats per
tal que càpiga en una clau USB de 128MB amb un petit espai de sobres per
utilitzar com millor us sembli.
Al optimitzar una imatge per adaptar-la a una mida determinada, cal comprendre
la compensació que s'estan fent entre la mida i la funcionalitat. En aquest
exemple, retallem tant només per donar cabuda a material addicional dins d'una
mida de 128MB, però sense fer res per destruir la integritat dels paquets
continguts, com la depuració de les dades de localització a través del paquet
/localepurge/ o altres optimitzacions "intrusives". De particular interès,
utilitzem --debootstrap-options per crear un sistema mínim des de zero.
$ lb config -k 486 --apt-indices false --apt-recommends false --debootstrap-options "--variant=minbase" --firmware-chroot false --memtest none
Per fer que la imatge funcioni correctament, hem de tornar a afegir, com a
mínim, dos paquets recomanats, que es queden fora per l'opció --apt-recommends
false. Veure Afinar APT per estalviar espai
$ echo "user-setup sudo" > config/package-lists/recommends.list.chroot
Ara, crear la imatge de la forma habitual:
# lb build 2>&1 | tee build.log
En el sistema de l'autor en el moment d'escriure això, la configuració anterior
produeix una imatge de 77MB. Això es compara favorablement amb la imatge de
177MB produïda per la configuració per defecte del Tutorial 1.
El estalvi d'espai més gran aquí, en comparació amb la construcció d'una imatge
per defecte en un sistema d'arquitectura i386, és seleccionar només la variant
del nucli 486 en comptes del predeterminat -k "486 686-pae". Deixar els índexs
d'APT amb --apt-indices false també permet estalviar una bona quantitat
d'espai, el desavantatge és que es necessita fer apt-get update abans
d'utilitzar apt en el sistema en viu. Deixar els paquets recomanats amb
--apt-recommends false estalvia una mica d'espai addicional, a costa d'ometre
alguns paquets que d'una altra manera es podria esperar que hi fossin.
--debootstrap-options "--variant=minbase" preinstaŀla un sistema mínim des del
principi. Al no incloure automàticament paquets de firmware amb
--firmware-chroot false també es guanya una mica d'espai. I finalment,
--memtest none impedeix la instaŀlació d'un comprovador de memòria.
*Nota:* Un sistema mínim es pot aconseguir també fent servir un script ganxo,
com ara el stripped.chroot de /usr/share/doc/live-build/examples/hooks. Es pot
guanyar petites quantitats addicionals d'espai i produir una imatge de 62MB. No
obstant, el script ganxo aconsegueix això eliminant documentació i altres
fitxers dels paquets instaŀlats al sistema. Això viola la integritat dels
paquets i com és comenta a l'encapçalament del script, pot tenir conseqüències
imprevistes. És per això que l'ús d'un /debootstrap/ mínim és el mètode
recomanat per aconseguir aquest objectiu.
18.7 UN ESCRIPTORI GNOME LOCALITZAT I AMB INSTAŀLADOR
.....................................................
*Cas d'ús:* Crear una imatge amb l'escriptori GNOME, localitzat per Suïssa i
que inclogui un instaŀlador.
Volem fer una imatge ISO híbrida per l'arquitectura i386 fent servir el nostre
escriptori preferit, en aquest cas GNOME, que conté tots els mateixos paquets
que serien instaŀlats per l'instaŀlador estàndard de Debian per a GNOME.
El nostre primer problema és descobrir els noms de les tasques del llenguatge
apropiades. En l'actualitat, /live-build/ no ens pot ajudar amb això. Tot i que
es podria tenir sort i trobar-ho per assaig i error, hi ha una eina,
grep-dctrl, per extreure les descripcions de les tasques de tasksel-data. Per
preparar-ho tot, assegurar-se de tenir totes dues coses:
# apt-get install dctrl-tools tasksel-data
Ara podem buscar les tasques apropiades, primer amb:
$ grep-dctrl -FTest-lang de /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german
Mitjançant aquesta ordre, es descobreix que la tasca s'anomena, amb suficient
claredat, german. Ara, per trobar les tasques relacionades:
$ grep-dctrl -FEnhances german /usr/share/tasksel/descs/debian-tasks.desc -sTask
Task: german-desktop
Task: german-kde-desktop
En el moment d'arrencar es generarà la variant regional *de_CH.UTF-8* i es
seleccionarà la disposició del teclat *ch*. Ara posarem les peces juntes.
Recordant de Ús dels metapaquets que els metapaquets tenen el prefix task-,
simplement especificar aquests paràmetres del llenguatge a l'arrencada, i
després afegir els paquets de prioritat estàndard i tots els metapaquets
descoberts a la nostra llista de paquets de la següent manera:
$ mkdir live-gnome-ch
$ cd live-gnome-ch
$ lb config \
-a i386 \
-k 486 \
--bootappend-live "boot=live config locales=de_CH.UTF-8 keyboard-layouts=ch" \
--debian-installer live
$ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
$ echo task-gnome-desktop task-german task-german-desktop >> config/package-lists/desktop.list.chroot
$ echo debian-installer-launcher >> config/package-lists/installer.list.chroot
Tenir en compte que s'ha inclòs el paquet /debian-installer-launcher/ per
llançar l'instaŀlador des de l'escriptori en viu, i també s'especifica el nucli
486, ja que actualment és necessari que l'instaŀlador i el nucli del sistema
viu coincideixin perquè el llançador funcioni correctament.
APèNDIX
=======
18.8 GUIDELINES FOR AUTHORS
...........................
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
18.8.1 LINGUISTIC FEATURES
..........................
* /Use plain English/
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.
* /Variety of English/
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.
* /Be balanced/
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.
* /Be politically correct/
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.
* /Be concise/
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.
* /Minimize translation work/
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.
* /Be coherent/
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.
* /Be cohesive/
Use as many text-forming devices as necessary to make your text cohesive and
unambiguous. (Text-forming devices are linguistic markers such as connectors).
* /Be descriptive/
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.
* /Dictionary/
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.
* /False friends, idioms and other idiomatic expressions/
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!
* /Avoid slang, abbreviations, contractions.../
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.
18.8.2 PROCEDURES
.................
* /Test before write/
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.
* /Examples/
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 a 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.
* /External links/
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.
* /Avoid branding and things that violate the license under which the manual is
published/
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.
* /Write a first draft, revise, edit, improve, redo if necessary/
- 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. Keep in mind that the proper names of
the releases, such as *wheezy* or *sid*, should not be capitalized when
referred to as code names.
- Improve your statements and redo any part if necessary.
* /Chapters/
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.
* /Markup/
And last but not least, /live-manual/ uses SiSU [link:
] to process the text files and produce a multiple
format output. It is recommended to take a look at SiSU's manual [link:
] 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.
18.9 GUIDELINES FOR TRANSLATORS
...............................
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
18.9.1 TRANSLATION HINTS
........................
* /Comments/
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.
* /TN, Translator's Note/
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".
* /Impersonal sentences/
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.
* /False friends/
The trap of "false friends" explained before especially applies to translators.
Double check the meaning of suspicious false friends if in doubt.
* /Markup/
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.
* /Code blocks/
Even though the code blocks are usually untranslatable, including them in the
translation is the only way to score a 100% complete translation. And even
though it means more work at first because it requires the intervention of the
translators if the code changes, it is the best way, in the long run, to
identify what has already been translated and what has not when checking the
integrity of the .po files.
* /Newlines/
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.
* /Untranslatable strings/
Translators should never translate:
- The code names of releases (which should be written in lowercase)
- The names of programs
- The commands given as examples
- Metadata (often between colons *:metadata:*)
- Links
- Paths
----------------------------------------
==============================================================================
Title: Manual Debian Live
Creator: Projecte Debian Live
Rights: Copyright (C) 2006-2013 Debian Live Project; License: Aquest
programa és un programari lliure: es pot redistribuir i/o
modificar sota els termes de la Llicència Pública General de la
GNU com és publicada per la Free Software Foundation, ja sigui
la versió 3 de la Llicència, o (si ho preferiu) qualsevol versió
posterior. Aquest programa es distribueix amb l'esperança que
sigui útil, però sense cap garantia, fins i tot sense la
garantia implícita de COMERCIALITZACIÓ o ADEQUACIÓ PER A
PROPÒSITS DETERMINATS. Vegeu la Llicència General Pública de la
GNU per a més detalls. Haurieu de rebre una còpia de la
Llicència Pública General de la GNU amb aquest programa. Si no
és així, consulteu http://www.gnu.org/licenses/. El text complet
de la Llicència Pública General de la GNU es pot trobar a
/usr/share/common-licenses/GPL-3.
Publisher: Projecte Debian Live
Date: 30.04.2013
Sourcefile: live-manual.ssm.sst
Filetype: SiSU text 2.0,
Source digest: SHA256(live-manual.ssm.sst)=
9978e8188d759d86e0809fd65fb237e2f733b535123325523b390a04b78cbc69
Skin digest: SHA256(skin_debian-live.rb)=
be92275c5ee3367edeed653901c34601c545c50acecc23ab65594d8e2f4df9af
Generated by: Generated by: SiSU 3.3.2 of 2012w26/6 (2012-06-30)
Ruby version: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
Document (dal) last generated: 2013-05-07 08:45:01 +0000
==============================================================================
plaintext (plain text):
http://live.debian.net/manual/manual/txt/live-manual.ca.txt
Other versions of this document:
manifest:
http://live.debian.net/manual/manual/manifest/live-manual.ca.html
at:
http://live.debian.net/manual/manual
* Generated by: SiSU 3.3.2 of 2012w26/6 (2012-06-30)
* Ruby version: ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
* Last Generated on: 2013-05-07 08:45:10 +0000
* SiSU http://www.sisudoc.org/