Live manual

Live Systems


<< previous toc next >>

Manual de Live Systems

Sobre aquest manual

Sobre aquest manual

1. Sobre aquest manual

1.1 Per als impacients
1.2 Termes
1.3 Autors
1.4 Contribuir a aquest document
1.4.1 Aplicar canvis
1.4.2 Traducció

Sobre el Live Systems Project

2. Sobre el Live Systems Project

2.1 Motivació
2.1.1 Què passa amb els sistemes vius actuals
2.1.2 Per què crear el nostre pròpi sistema viu?
2.2 Filosofia
2.2.1 Només paquets Debian sense modificacions de la secció "main"
2.2.2 Paquets del sistema viu sense cap configuració
2.3 Contacte

Usuari

Instal·lació

3. Instal·lació

3.1 Requisits
3.2 Instal·lació de live-build
3.2.1 Des del repositori de Debian
3.2.2 A partir del codi font
3.2.3 A partir d'instantànies
3.3 Instal.lació de live-boot i live-config
3.3.1 Des del repositori de Debian
3.3.2 A partir del codi font
3.3.3 A partir d'instantànies

Conceptes bàsics

4. Conceptes bàsics

4.1 Què és un sistema viu?
4.2 Descàrrega d'imatges prefabricades
4.3 Ús del servei de construcció d'imatges en viu web
4.3.1 Ús i advertències sobre el servei web
4.4 Primers passos: construcció d'una imatge ISO híbrida
4.5 Usar una imatge ISO híbrida en viu
4.5.1 Gravar una imatge ISO en un medi físic
4.5.2 Copiar una imatge ISO híbrida en un dispositiu USB
4.5.3 Utilitzar l'espai lliure en una memòria USB
4.5.4 Arrencar el medi en viu
4.6 Utilitzar una màquina virtual per a fer proves
4.6.1 Provar una imatge ISO amb QEMU
4.6.2 Provar una imatge ISO amb VirtualBox
4.7 Construir i utilitzar una imatge HDD
4.8 Construir una imatge netboot
4.8.1 Servidor DHCP
4.8.2 Servidor TFTP
4.8.3 Servidor NFS
4.8.4 Com provar l'arrencada en xarxa
4.8.5 Qemu
4.9 Webbooting
4.9.1 Obtenir els fitxers webboot
4.9.2 Arrencar imatges webboot

Descripció general de les eines

5. Descripció general de les eines

5.1 El paquet live-build
5.1.1 L'ordre lb config
5.1.2 L'ordre lb build
5.1.3 L'ordre lb clean
5.2 El paquet live-boot
5.3 El paquet live-config

Gestió d'una configuració

6. Gestió d'una configuració

6.1 Gestionar canvis en la configuració
6.1.1 Per què utilitzar scripts auto? Què fan?
6.1.2 Utilitzar scripts auto d'exemple
6.2 Clonar una configuració publicada via Git

Personalització dels continguts

7. Visió general de la personalització

7.1 Configuració durant la construcció vs. durant l'arrencada
7.2 Etapes de la construcció
7.3 Suplementar lb config amb fitxers
7.4 Tasques de personalització

Personalització de la instal·lació de paquets

8. Personalització de la instal·lació de paquets

8.1 Fonts dels paquets
8.1.1 Distribució, àrees d'arxiu i mode
8.1.2 Miralls de distribució
8.1.3 Miralls de distribució utilitzats en temps de construcció
8.1.4 Miralls de distribució utilitzats en temps d'execució
8.1.5 Repositoris addicionals
8.2 Selecció dels paquets a instal·lar
8.2.1 Llistes de paquets
8.2.2 Ús dels metapaquets
8.2.3 Llistes locals de paquets
8.2.4 Llistes locals de paquets per a l'etapa binary
8.2.5 Generar llistes de paquets
8.2.6 Ús de condicionals dins de les llistes de paquets
8.2.7 Eliminar paquets durant la instal·lació
8.2.8 Tasques d'escriptori i llenguatge
8.2.9 Tipus i versió del nucli
8.2.10 Nuclis personalitzats
8.3 Instal·lació de paquets modificats o de tercers
8.3.1 Fer servir packages.chroot per a instaŀar paquets personalitzats
8.3.2 Fer servir un repositori APT per a instal·lar paquets personalitzats
8.3.3 Paquets personalitzats i APT
8.4 Configurar APT en temps de construcció
8.4.1 Elegir apt o aptitude
8.4.2 L'ús d'un proxy amb APT
8.4.3 Afinar APT per a estalviar espai
8.4.4 Passar opcions per a apt o aptitude
8.4.5 APT pinning

Personalització dels continguts

9. Personalització dels continguts

9.1 Includes
9.1.1 Live/chroot local includes
9.1.2 Binary local includes
9.2 Scripts ganxo (Hooks)
9.2.1 Live/chroot local hooks
9.2.2 Scripts ganxo durant l'arrencada
9.2.3 Binary local hooks
9.3 Preconfiguració de les preguntes de Debconf

Personalització dels comportaments en temps d'execució

10. Personalització dels comportaments en temps d'execució

10.1 Personalitzar l'usuari en viu
10.2 Personalització de l'entorn local i el llenguatge
10.3 Persistència
10.3.1 El fitxer persistence.conf
10.3.2 Utilitzar diversos medis persistents
10.3.3 Persistència amb xifratge

Personalització de la imatge binària

11. Personalització de la imatge binària

11.1 Carregadors d'arrencada
11.2 metadades ISO

Personalització de l'instal·lador de debian

12. Personalització de l'instal·lador de debian

12.1 Tipus d'instal·lador de Debian
12.2 Personalització de l'instal·lador de Debian amb preconfiguració
12.3 Personalitzar el contingut de l'instal·lador de Debian

Projecte

Contribuir al projecte

13. Contribuir al projecte

13.1 Fer canvis

Informar dels errors

14. Informar dels errors

14.1 Problemes coneguts
14.2 Reconstruir des de zero
14.3 Fer servir paquets actualitzats
14.4 Recopilar informació
14.5 Aïllar el cas que falla, si és possible
14.6 Utilitzar el paquet correcte per a informar de l'error
14.6.1 A l'hora de construir mentre bootstrapping
14.6.2 A l'hora de construir, durant la instal·lació de paquets
14.6.3 En el moment d'arrencar
14.6.4 En temps d'execució
14.7 Fer la recerca
14.8 On informar dels errors

Estil de Codi

15. Estil de Codi

15.1 Compatibilitat
15.2 Indentació
15.3 Ajust de línia
15.4 Variables
15.5 Miscel·lània

Procediments

16. Procediments

16.1 Publicacions majors
16.2 Publicacions puntuals
16.2.1 Ùltima publicació puntual d'una versió de Debian
16.2.2 Plantilla per a anunciar una publicació puntual

Repositoris Git

17. Repositoris Git

17.1 Gestió de múltiples repositoris

Exemples

Exemples

18. Exemples

18.1 Ús dels exemples
18.2 Tutorial 1: Una imatge per defecte
18.3 Tutorial 2: Una utilitat de navegador web
18.4 Tutorial 3: Una imatge personalitzada
18.4.1 Primera revisió
18.4.2 Segona revisió
18.5 Un client per a un quiosc VNC
18.6 Una imatge bàsica per a un dispositiu USB de 128MB
18.7 Un escriptori GNOME localitzat i amb instal·lador

Apèndix

Style guide

19. Guia d'estil

19.1 Instruccions per als autors
19.1.1 Característiques lingüístiques
19.1.2 Procediments
19.2 Directrius per als traductors
19.2.1 Consells de traducció

Metadata

SiSU Metadata, document information

Manual de Live Systems

Personalització de la instal·lació de paquets

8. Personalització de la instal·lació de paquets

La personalització més bàsica d'un sistema en viu pot ser la selecció dels paquets que seran inclosos en la imatge. Aquest capítol explica les diverses opcions de live-build per a personalitzar la instal·lació de paquets durant la construcció. Les opcions més importants que influeixen en els paquets que estan disponibles per a ser instal·lats en la imatge són les àrees de distribució i el arxiu. Per a 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 instal·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'instal·len els paquets durant la construcció. Això pot ser útil si s'utilitza un proxy, es vol desactivar la instal·lació de paquets recomanats per a estalviar espai, o hi ha la necessitat de controlar quines versions dels paquets s'instal·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 a incloure en una imatge en viu. Només cal especificar el nom en clau, que per defecte és buster per a la versió buster de live-build. Qualsevol distribució disponible a l'arxiu pot ser especificada pel seu nom en clau aquí. (Veure Termes per a 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 a comportar-se segons sigui necessari per a construir cada distribució suportada. Per exemple, per a 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 a 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 a 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 Live Systems Project, 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 a establir els miralls de la distrubució utilitzats en temps de construcció perquè apuntin a una rèplica local, és suficient establir --mirror-bootstrap i --mirror-chroot-security de la manera següent.

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

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 a instal·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 a 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 a backports, experimentals o paquets personalitzats. Per a 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 a ser utilitzades quan s'executa el sistema en viu.

Per exemple, config/archives/live.list.chroot permet instal·lar paquets des del repositori d'instantànies de debian-live en el moment de construcció del sistema viu.

deb http://live-systems.org/ 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 a signar el repositori en fitxers config/archives/your-repository.key.{binary,chroot}.

En cas de necessitar un APT pinning personalitzat, es poden col·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/.

8.2 Selecció dels paquets a instal·lar

Hi ha una sèrie de formes de triar els paquets que live-build instal·larà en la imatge, que abasta una varietat de necessitats diferents. Es pot simplement anomenar paquets individualment per a instal·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 instal·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 a més detalls.

8.2.2 Ús dels metapaquets

La forma més senzilla per a 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 Live Systems. 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 a obtenir una llista de tots els metapaquets que hi ha a l'arxiu, instal·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 col·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 a ser processades, i a més a més un sufix d'etapa adicional .chroot o .binary per a 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'instal·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 a l'etapa binary

Per a crear una llista per a l'etapa binary, crear un fitxer amb el sufix .list.binary a config/package-lists/. Aquests paquets no s'instal·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 instal·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 a 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 a instal·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 a instal·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 a instal·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 Eliminar paquets durant la instal·lació

Es pot crear llistes de paquets en fitxers amb els sufixos .list.chroot_live i .list.chroot_install dins del directori config/package-lists. Si hi ha una llista «live» i una llista «install» els paquets de la llista .list.chroot_live s'eliminaran amb un script ganxo després de la instal·lació (si l'usuari utilitza l'instal·lador). Els paquets de la llista .list.chroot_install seran presents tant en el sistema en viu com en el sistema instal·lat. Aquest és un cas especial per al programa d'instal·lació i pot ser útil si es té --debian-installer live establert en la configuració i es desitja eliminar paquets específics del sistema en viu durant la instal·lació.

8.2.8 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'instal·lador de Debian en aquest sentit. A l'instal·lador de Debian, si el medi es va preparar per a obtenir un tipus d'entorn d'escriptori en particular, la tasca corresponent s'instal·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 instal·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 instal·lador de Debian. Això no vol dir que una imatge en viu no es pugui construir per a 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 a les tasques de llengua que incloguin coses com ara tipus de lletres específics 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.9 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 a l'arrel per defecte linux-image per a 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 a l'arquitectura amd64 inclourà el metapaquet linux-image-amd64 i una imatge per a l'arquitectura i386 inclourà el metapaquet linux-image-586.

Quan hi ha més d'una versió del paquet 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 instal·lar el nucli linux-image-3.18.0-trunk-amd64 es podria configurar la imatge de la següent manera:

$ lb config --linux-packages linux-image-3.18.0-trunk
$ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

8.2.10 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 Instal·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:

8.3 Instal·lació de paquets modificats o de tercers

Si bé està en contra de la filosofia d'un sistema en viu, de vegades pot ser necessària la construcció d'un sistema amb versions modificades dels paquets que es troben al arxiu de Debian. Pot ser per a modificar o donar suport a funcions addicionals, les llengües o les marques, o fins i tot per a eliminar elements dels paquets existents que són indesitjables. De la mateixa manera, es poden utilitzar paquets de tercers per a 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 ‹http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html› pot ser d'interès. La creació de paquets personalitzats es tracta a Debian New Maintainers' Guide at ‹https://www.debian.org/doc/maint-guide/› i en altres llocs.

Hi ha dues formes d'instal·lar paquets personalitzats modificats:

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 a posar-lo en marxa.

8.3.1 Fer servir packages.chroot per a instaŀar paquets personalitzats

Per a 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'instal·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 instal·lació de paquets personalitzats té els seus desavantatges:

8.3.2 Fer servir un repositori APT per a instal·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 instal·lar per a més detalls.

Si bé crear un repositori APT per a instal·lar paquets personalitzats pot semblar un esforç innecessari, la infraestructura pot ser fàcilment reutilitzada en una data posterior per a oferir actualitzacions dels paquets modificats.

8.3.3 Paquets personalitzats i APT

live-build utilitza APT per a instal·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 a instal·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 a assegurar-se que la versió modificada és la que s'instal·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 a 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 a 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'instal·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 instal·lació de paquets, la diferència notable és la forma en que es manegen els paquets que falten.

8.4.2 L'ús d'un proxy amb APT

Una configuració típica d'APT és per a fer front a la construcció d'una imatge darrere d'un proxy. Es pot especificar el proxy per a 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 a 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 a crear aquests índexs.

Si es considera que la instal·lació de tots els paquets recomanats infla massa la imatge, sempre que s'estigui preparat per a 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 a 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 a 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'instal·len els paquets recomanats per un paquet determinat, és a dir, "els paquets que es troben junts amb aquest en totes les instal·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 instal·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 a impedir la seva instal·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 a modificar el comportament d'APT de la manera què es necessita, es pot utilitzar --apt-options o --aptitude-options per a passar opcions a l'eina APT configurada. Consultar les pàgines dels manual apt i aptitude per a 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 a 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 a entendre completament aquestes opcions i quan utilitzar-les. Això és només un exemple i no s'ha d'interpretar com un consell per a configurar la imatge. Aquesta opció no seria adequada, per exemple, per a una versió final d'una imatge en viu.

Per a 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 a tenir algunes dreceres convenients per a 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 buster però es necessita que tots els paquets «live-» que acaben dins de la imatge binària s'instal·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'instal·lin desde sid en el moment de la construcció i tots els altres es prenguin de la distribució de destinació, buster. 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'instal·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



<< previous toc next >>