Altijd up-to-date zonder één vinger uit te hoeven steken – dat is wat de automatische pakket-updates van op Debian gebaseerde Linux-distributies je beloven en waarmee je bijvoorbeeld ook Raspberry Pi bijgewerkt houdt. Om er zeker van te zijn dat er geen pakketten buiten de boot vallen, moet je de configuratie afzonderlijk aanpassen.
Automatische pakket-updates in op Debian gebaseerde Linux-distributies inclusief Raspberry
Het blijkt toch niet zo eenvoudig: het pakket unattended-upgrades, dat beschikbaar is in Debian, Ubuntu, Raspberry Pi OS en praktisch alle andere op Debian gebaseerde Linux-distributies, zou dagelijkse updates van reeds geïnstalleerde softwarepakketten moeten installeren zonder tussenkomst van de gebruiker.
Afhankelijk van de distributie zijn echter aanpassingen nodig om ervoor te zorgen dat alle updates ook daadwerkelijk worden uitgevoerd. Bij Raspberry Pi OS werkt de configuratie die is overgenomen van het Debian-project bijvoorbeeld niet.
Ontvang gratis tips voor updaten en bijhouden van je Raspberry Pi, schrijf je in voor de nieuwsbrief:
Zonder aanpassingen worden daar helemaal geen pakketten bijgewerkt. Misschien heb je die wel nodig voor je Raspberry Pi projects. Aan de andere kant zijn niet alle updates altijd gewenst – serverbeheerders zijn bijvoorbeeld alleen geïnteresseerd in beveiligingsupdates. Zij willen de stabiliteit en compatibiliteit van feature-updates eerst controleren, voor zover ze die überhaupt al overwegen.
Alle distributies hebben gemeenschappelijk dat
unattended-upgrades
alle pakketbronnen na het installeren dagelijks bijwerkt. Welke pakketupdates het programma vervolgens installeert, verschilt van distributie tot distributie. Bij Debian en Ubuntu worden pakketten en beveiligingsupdates van de standaarddistributie bijvoorbeeld automatisch geïnstalleerd. Dat wordt gespecificeerd in het centrale configuratiebestand /etc/ apt/apt.conf.d/50unattended-upgrades, maar wel op verschillende manieren.
Twee vermeldingen nodig voor standaard- en beveiligingsupdates Debian
Debian gebruikt sinds versie 10 al het huidige formaat voor het specificeren van pakketbronnen, hier als voorbeeld de regel voor de standaardpakketten van de distributie:
Unattended-Upgrade::Origins-Pattern {
“origin=Debian,codename=${distro_codename},
label=Debian”;
“origin=Debian,codename=${distro_codename},
label=Debian-Security”;
}
De origin-specificatie verwijst naar de beheerder van de repository, terwijl het label staat voor het team dat de pakketten levert. Het Debian-securityteam gebruikt bijvoorbeeld het label Debian-Security, terwijl het Debian-team de basispakketten levert.
Daarom zijn er twee vermeldingen nodig voor standaard- en beveiligingsupdates. Als je als serverbeheerder alleen de security-updates automatisch wilt installeren, kun je de andere regel naar wens gewoon verwijderen of weglaten.
Het opgeven van de codenaam zorgt ervoor dat alleen pakketten worden bijgewerkt die ook bedoeld zijn voor de huidige geïnstalleerde Debian-versie.
De variabele ${distro_codename} wordt automatisch vervangen door de codenaam bullseye bij Debian, en door focal bij Ubuntu 20.04. Er is een tweede variabele, ${distro_id}, die wordt vervangen door de naam van de distributie, oftewel ‘Debian’ voor Debian en ‘Ubuntu’ voor Ubuntu.
Ubuntu gebruikt overigens nog steeds een verouderde notatie van de upgrade-regels, hier het deel voor de standaardpakket- en security-updates:
Unattended-Upgrade::Allowed-Origins {
“${distro_id}:${distro_codename}”;
“${distro_id}:${distro_codename}-security”;
}
Dat is gelijkwaardig aan de volgende configuratie:
Unattended-Upgrade::Origins-Pattern {
“origin=${distro_id},archive=
${distro_codename}”;
“origin=${distro_id},archive=
${distro_codename}-security”;
}
Ontwarren van de velden in de verschillende Debian Linux-distributies
De velden voor codenaam en archief worden zeer verschillend gebruikt door de repository’s, zelfs binnen één distributie. In Debian is de codenaam bijvoorbeeld de naam van de distributie plus eventuele repository-achtervoegsels, zoals bullseye voor de huidige stabiele Debian-release, maar bullseye-backports voor pakketten uit de backports-repository.
De Debian-securityrepository gebruikt daarentegen niet de distributienaam, maar oldstable, stable en unstable voor Debian Buster, Bullseye en Sid. Voor Ubuntu 20.04 is het archiefveld voor beveiligingsupdates focal-security en voor backports focal-backports, maar het codenaamveld bevat altijd alleen de naam van de release, oftewel focal.
Bij Raspberry Pi OS staat in het archiefveld alleen stable of unstable, zonder verdere toevoegingen, en de codenaam is de naam van de Debian-release waarvan Raspberry Pi OS is afgeleid, momenteel buster en binnenkort bullseye. En de Docker-repository gebruikt buster voor het archiefveld en stable voor de codenaam, oftewel precies het tegenovergestelde van het Debian-project.
Het componentveld wordt ook niet altijd uniform gebruikt. Debian-pakketten van software met licentieproblemen moeten non-free vermelden, terwijl Ubuntu multiverse gebruikt. Kortom: zoals zo vaak is er geen regel zonder uitzonderingen. Er is echter een eenvoudige manier om meteen de juiste regel te formuleren.
De sleutel tot je eigen upgrade-regel is het
apt policy
commando, dat een lijst geeft van alle pakketbronnen die ingesteld zijn met de gegevens die nodig zijn voor de regels. De afbeelding rechtsboven toont een deel van die lijst van Debian 10 Buster, waar de officiële pakketbronnen voor Google Chrome en Docker aan zijn toegevoegd.
De tweede regel van elke archiefingang bevat alle relevante informatie voor
unattended-upgrades – waarbij de veldnamen zoals
origin
of
label
zijn afgekort tot respectievelijk
0
o en
1
wat unattended-upgrades ook ondersteunt. Het enige struikelblok is
c
dat staat voor
component
component, maar codenaam wordt afgekort tot n. Verder is de korte vorm altijd de eerste letter van de lange vorm.
Daarbij ondersteunt
unattended-upgrades echter niet alle velden die apt policy opsomt, je moet je beperken tot de vijf velden
a
c
l
n
o
in upgrade-regels. Om ervoor te zorgen dat Docker in de toekomst ook automatisch wordt geüpgraded, reduceer je de uitvoerregel
release o=Docker,a=buster,l=Docker CE,c=stable,b=amd64
van
apt policy
tot de volgende regel:
“o=Docker,a=buster,l=Docker CE,c=stable”;
Het is cruciaal dat je geen extra spaties invoegt – de spatie in het Docker CE-label is de enige spatie die is toegestaan binnen de aanhalingstekens van deze regel.
In welke velden de pakketbronnen informatie over de distributienaam of de repository’s zetten varieert sterk. De uitvoer van het commando apt policy maakt het echter makkelijk om alle nodige informatie te te kunnen lezen.
Raspberry Pi ook te repareren met automatische pakket-updates voor Debian
Met die kennis moet je er ook in kunnen slagen om de regels in Raspberry Pi OS te repareren, dat standaard alleen de twee regels bevat die overgenomen zijn van het Debian-project.
De pakketten van de Raspberry Pi Foundation hebben echter
Raspberry Pi Foundation
of
Raspbian
als hun oorsprong en label. Daarom worden de twee standaardregels nooit toegepast. Je kunt de juiste informatie in dat geval krijgen met het commando apt policy. Daaruit kun je de juiste upgrade-regels destilleren:
“o=Raspberry Pi Foundation,a=testing,n=buster,l=Raspberry Pi Foundation”;
“o=Raspbian,a=stable,n=buster,l=Raspbian”;
Als je de regels hebt ingesteld in de sectie
Unattended-Upgrade::Origins-Pattern
van het bestand /etc/apt/apt.conf.d/50unattendedupgrades, dan kun je een testrun starten door het volgende commando uit te voeren:
sudo unattended-upgrades –dry-run.
Je kunt het resultaat vinden aan het eind van het logbestand /var/log/unattended-upgrades/unattended-upgrades.log – indien succesvol, zullen alle pakketten die ook met het commando
sudo apt upgrade –dryrun
geüpgraded zouden worden, daar genoemd worden. De parameter
–dry-run
zorgt ervoor dat beide commando’s de upgrade niet daadwerkelijk uitvoeren. Je hoeft dan dus niet te wachten tot er nieuwe updates zijn om wijzigingen in je configuratie te testen.
Logbestand regelmatig controleren op bijgewerkte paketten
Na het installeren is unattended-upgrades meteen ingeschakeld. Als je de volgende dag of zelfs later aan de configuratie verder wilt werken, moet je de automatische update eerst uitschakelen met het commando
sudo dpkg-reconfigure unattended-upgrades
tot je tevreden bent met de configuratie en je de automatische update op dezelfde manier weer inschakelt. Daarna moet je het logbestand van unattended-upgrades van tijd tot tijd controleren op bijgewerkte pakketten. Zo voorkom je dat je het slachtoffer wordt van een aanval via een beveiligingslek dat allang gedicht had moeten zijn – bijvoorbeeld omdat er geen updates automatisch geïnstalleerd werden als gevolg van een verkeerde spatie of een typfout, ook al heb je speciaal voor dat doel
unattended-upgrades geïnstalleerd en dacht je dus veilig te zijn.
(Deze informatie is afkomstig uit het artikel van Mirko Dölle en Noud van Kruysbergen, en verscheen eerder in c’t 12, 2021, p120)
Ik wil net NIET dat mijn Linux PC automatisch bijgewerkt wordt. Ik beslis wanneer ik een update installeer. Ik wil geen Windows toestanden waar je s avonds je PC uitschakelt maar nog een half uur moet wachten omdat ie nog updates wil installeren. Of nog slechter > updates die je systeem om zeep helpen. Nee, dank je wel. Als ik lees dat een Linux update goed is, pas dan installeer ik hem.