Hoppa till innehåll 
Canonical Livepatch åtgärdar kritiska säkerhetsbrister i kärnan Ubuntu LTS under drift och skjuter upp omstarter till planerade underhållsfönster. I det här inlägget visar jag tydligt hur livepatching av kärnan fungerar i Ubuntu, vilka fördelar Canonicals Livepatch har och hur det står sig i en direkt jämförelse med alternativen.
Centrala punkter
- Realtidspatchar utan omstart för kritiska CVE-problem i kärnan
- Ubuntu LTS-Fokus med integration i Ubuntu Pro
- Begränsad Underhållsfönster per kärnversion
- Ingen Livepatching i användarmiljön
- Jämförelse om Ksplice, kpatch, kgraft
Varför livepatching är viktigt i Ubuntu
Jag åtgärdar säkerhetsbrister i kärnan med Livepatching omedelbart, istället för att vänta till nästa underhållsperiod. På så sätt minskar Exploit-fönster, där en känd sårbarhet fortfarande är aktiv. Onödiga omstarter undviks, tjänsterna förblir tillgängliga och SLA-målen kan uppfyllas bättre. Särskilt produktiva servrar, databaser och container-värdar gynnas av detta, eftersom en omstart ofta utlöser kedjereaktioner. För mig står det klart: säkerhetsuppdateringar utan omstart sparar tid, minskar riskerna och gör att fokus kan ligga på driften istället för på att släcka bränder.
Hur Livepatch från Canonical fungerar rent tekniskt
Canonical Livepatch laddar ner binärfiler Patchmoduler i den aktiva kärnan och ersätter specifika felaktiga funktioner. En lokal tjänst bygger upp Anslutning ansluter till Livepatch-servrarna, kontrollerar intervall och hämtar signerade moduler. Kärnan i sig byter inte huvudversion, utan får precisa korrigeringar på definierade ställen. I det dagliga arbetet ser jag att denna metod upprätthåller stabiliteten, eftersom den endast påverkar nödvändiga delar. Problemområden åtgärdas samtidigt som arbetsbelastningarna fortsätter oförändrat och ingen applikation slutar fungera på grund av en omstart.
Ubuntu-versioner och kärnor som stöds
Jag använder Livepatch på LTS-versioner t.ex. 18.04, 20.04, 22.04 och 24.04 med officiella kärnvarianter som generic, lowlatency eller molnspecifika varianter. Det viktiga är fortfarande Omslag: Canonical tillhandahåller vanligtvis endast patchar för en kärnversion under en begränsad tidsperiod, oftast cirka nio till tretton månader från lanseringen. Därefter planerar jag en regelbunden kärnuppgradering och en omstart för att få ytterligare live-patchar. Detta gäller för x86_64 och ARM64, förutsatt att kärnan kommer från Canonicals källkod. Denna guide ger mig en bra översikt över livscykler: Kärnversioner och LTS.
Aktivera Livepatch: steg för steg
Inredningen sköter jag med Snap och ett Ubuntu Pro-token på bara några minuter. Först kontrollerar jag om snapd körs, sedan installerar jag paketet och aktiverar tjänsten med mitt Token. För att säkerställa reproducerbara processer dokumenterar jag kommandona och lagrar dem i konfigurationshanteringen. Statusövervakningen ingår i min övervakning, så att jag hela tiden kan se uppdateringar och anslutningar. Den som vill lära sig mer om konceptet i allmänhet hittar bakgrundsinformation om Patcha kärnan utan omstart till hjälp.
sudo snap install canonical-livepatch
sudo canonical-livepatch enable
sudo canonical-livepatch status --verbose
Gränser och tillämpningsområde för Canonical Livepatch
Jag behåller Gränser Att tänka på: Livepatch hanterar uteslutande kärnan, inte användarutrymmespaket som OpenSSL eller glibc. Individuellt kompilerade kärnor, exotiska buildar eller varianter som inte stöds omfattas inte, vilket är anledningen till att jag använder officiella källor. Dessutom fokuserar tjänsten på kritiska och höga CVE:er, medan lägre klassificeringar normalt hanteras via uppdatering och omstart. En tidsperiod gäller per kärnversion; därefter krävs en regelbunden uppgradering för att åter vara uppdaterad. I praktiken täcker Canonical ofta bara en del av Ubuntus CVE:er via Livepatch, ofta i storleksordningen fem till tio procent, vilket jag tar med i beräkningen vid säkerhetsplaneringen.
Canonical Livepatch jämfört med alternativ
Jag bedömer alternativen utifrån Omslag, distributionsstöd, återställning och eventuell patchning i användarmiljön. Leverantörer som Ksplice, kpatch eller kgraft lovar ofta bredare stöd och i vissa fall live-patchar för medelstora säkerhetsproblem. Vissa lösningar erbjuder en direkt återställning utan omstart, vilket kan spara tid vid inkompatibiliteter. För rena Ubuntu LTS-miljöer förblir Canonicals Livepatch attraktivt, eftersom integration, supportcykler och användning passar ihop. Den som kör flera distributioner bör ta en titt på detta Översikt över live-kärnuppdatering och ställer tydliga krav.
| Kriterium | Canonical Livepatch | Alternativa lösningar |
|---|---|---|
| Distributionsstöd | Fokus på Ubuntu LTS | Ofta flera distributioner |
| CVE-täckning | Kritisk/hög, delmängd av luckorna | Delvis bredare, inklusive medelhöga trappsteg |
| Patchning i användarutrymmet | Endast kärnan | Vissa täcker även användarutrymmet |
| Rollback | Oftast genom att byta kärna och starta om | Kan i vissa fall göras utan omstart |
| Integration | Nära Ubuntu Pro och Snap | Egna agenter/repos |
Bästa praxis för drift
Jag kombinerar Livepatch med planerade kärnuppgraderingar och dokumenterade omstarter, så att skyddet inte upphör att gälla. Jag integrerar statuskontroller i min övervakning och skapar larm vid anslutningsproblem eller saknade patchar. Förändringshantering är fortfarande obligatoriskt: Jag planerar tidsfönster, testar i staging-miljön och rullar sedan ut uppdateringarna på ett kontrollerat sätt i produktionsmiljön. För uppdateringar av användarutrymmet har jag en tydlig patchplan och satsar på snabba, spårbara återställningar. Säkerhetskopiering, härdning och loggning kompletterar säkerhetsstrategin så att ingen enskild komponent behöver stå ensam.
Säkerhetsmodell och förtroendekedja
Jag litar på Livepatch eftersom de Kedja av förtroende förblir sluten från kompilering till leverans. Patchar signeras av Canonical, klienten verifierar signaturerna och laddar endast moduler som passar kärnversionen och arkitekturen. Kärnan tillämpar ändringar via uppströms Livepatch-undersystem an: Kritiska funktioner avbryts atomärt vid inträde, så att ingen tråd hamnar i ett halvfärdigt tillstånd. Kontrollera innan omkoppling Konsistenskontroller, om den aktuella kodvägen kan patchas utan risk. Om en kontroll misslyckas tillämpas inte patchen och statusen visar detta – för mig är det ett viktigt säkerhetsnät mot instabila mellanlägen.
Ur ett driftsperspektiv innebär det att jag håller mina system i drift Stödda kärnversioner, aktivera Secure Boot endast med korrekta signaturer och förhindra lokala ingrepp i Livepatch-katalogen. Tjänsten körs med systemrättigheter; därför begränsar jag åtkomst och insyn i loggarna enligt Behöver veta-principen och dokumentera godkännanden i Change-Board.
Prestandaförlust och stabilitet i praktiken
I den dagliga användningen har jag lagt märke till försumbar overhead. Det extra indirektionshoppet vid patchade funktioner är i regel inte mätbart och märks inte ens i latenskänsliga arbetsbelastningar. För mig är det snarare Patchkvalitet: Små, riktade korrigeringar minimerar risken. Därför planerar jag också med staging-servrar, där jag övervakar nya Livepatch-versioner under några timmar till dagar med realistiska belastningar. Om avvikelser uppstår dokumenterar jag dem, avbryter utrullningen och planerar vid behov en påskyndad kärnuppgradering med omstart.
Viktigt: Livepatch ersätter inte Funktionsuppdateringar. Så snart det krävs kärnfunktioner, ABI-ändringar eller drivrutinsuppdateringar går det inte att undvika den klassiska uppdateringen följd av omstart. Jag har därför avsatt specifika tidsfönster och reservkapacitet för detta.
Drift i Kubernetes, OpenStack och container-värdar
På Kubernetes- och OpenStack-noder installerar Livepatch direkt på Tillgänglighet . I kluster undviker jag spänningsfall eftersom jag installerar kritiska korrigeringar utan att starta om noderna. Min arbetsgång: Livepatch håller noderna säkra, och regelbundna kärnuppgraderingar genomför jag samlat under underhållsfönster. Inför planerade omstarter avlastar jag arbetsbelastningarna på ett systematiskt sätt och ser till att ha en smidig återgångsplan klar.
# Förbereda Kubernetes-noder för omstart
kubectl drain --ignore-daemonsets --delete-emptydir-data --grace-period=60
# Återuppta driften efter omstart och kontroller
kubectl uncordon
På container-värdar (Docker/Containerd) uppskattar jag att aktiva containrar orörd förblir oförändrade så länge endast kärnfunktionerna korrigeras. För särskilt känsliga hyresgäster anser jag dessutom att ett Canary-Host-Mönster klart: Först uppdateras en enskild värd till den nya Livepatch-versionen, och först därefter följer resten av gruppen.
Automatisering och massinförande
I större flottor automatiserar jag aktiveringen. Förutom Snap använder jag alternativt Ubuntu Pro-klienten om den redan finns i bruk. Jag dokumenterar båda metoderna och ser till att de går att reproducera.
# Alternativ A: Snap-klient
sudo snap install canonical-livepatch
sudo canonical-livepatch enable
# Alternativ B: Ubuntu Pro-klient
sudo pro attach
sudo pro enable livepatch
pro status
För molninstanser använder jag cloud-init, så att systemen ansluts korrekt redan vid uppstarten:
#cloud-config
paket:
- snapd
runcmd:
- snap install canonical-livepatch
- canonical-livepatch enable
- canonical-livepatch status --verbose || true
Konfigurationshantering (t.ex. Ansible, Puppet) ser till att jag får Idempotens: Jag definierar tokens, servicestatus och övervakningshooks i koden. På så sätt förblir Livepatch konsekvent även efter ombyggnader, och avvikelser syns omedelbart i drift-rapporten.
Nätverk, proxy och begränsade miljöer
För att Livepatch ska fungera krävs att tjänsten utgående HTTPS-trafik. I reglerade nätverk ansluter jag till en företagsproxy. Jag kan konfigurera Snap centralt för detta, och Livepatch-tjänsten ärver inställningarna eller använder miljövariabler. Så här gör jag:
# Ställa in systemomfattande proxy för Snap
sudo snap set system proxy.http=http://proxy.local:3128
sudo snap set system proxy.https=http://proxy.local:3128
Kontrollera #-tjänstens loggar för att se om hämtningen fungerar
journalctl -u snap.canonical-livepatch.canonical-livepatchd -n 100 --no-pager
Miljöer med luftisolering utan någon som helst extern åtkomst är avsedda för Livepatch svårt, eftersom modulerna måste laddas om regelbundet. I sådana fall planerar jag strängare Underhållsintervall med proaktiva kärnuppgraderingar och se till att ha en noggrann sårbarhetsskanning på plats för att snabbt kunna åtgärda kända sårbarheter genom omstart.
Felsökning och felsökning
I praktiken stöter jag på återkommande felmönster som jag hanterar på ett strukturerat sätt:
- “Kärnan stöds inte”: Kernelvarianten eller -versionen ligger utanför underhållsperioden. Jag planerar att uppgradera till en version som stöds och sedan starta om systemet.
- “Ogiltigt/utgånget token”: Jag kontrollerar om Ubuntu Pro-tokenet fortfarande är giltigt, förnyar det och aktiverar tjänsten på nytt.
- Anslutningsproblem: Testa DNS/proxy- och brandväggsreglerna. Gå sedan igenom tjänstens loggar och starta en manuell uppdatering.
- Patch har inte installerats: Jag kontrollerar om patchen finns tillgänglig för just mitt kernel-build-nummer och om konsistenskontroller blockerar processen. Om jag är osäker väntar jag på en uppföljande uppdatering eller planerar en kerneluppgradering.
# Kontrollera tjänstens status och senaste aktiviteter
sudo canonical-livepatch status --verbose
sudo canonical-livepatch refresh
systemctl status snap.canonical-livepatch.canonical-livepatchd.service
journalctl -u snap.canonical-livepatch.canonical-livepatchd -S -1h
Vid revisioner kontrollerar jag regelbundet statusen:
sudo canonical-livepatch status --verbose | sudo tee -a /var/log/livepatch/status.log
Beslutsguide: När en livepatch räcker – och när en omstart är nödvändig
Jag ser Livepatch som Säkerhetsaccelerator för kritiska säkerhetsbrister i kärnan mellan två ordinarie uppgraderingar. Omstart krävs när:
- en lösning ABI-/Strukturförändringar kräver, som Livepatch inte kan återge,
- Drivrutiner, Hårdvarustöd eller om nya kärnfunktioner behövs,
- en säkerhetsbrist kan användas på många olika sätt och det inte finns någon Livepatch tillgänglig inom en snar framtid för min kärnversion,
- Det uppstår stabilitetsproblem som kan åtgärdas genom ett vanligt kärnbyte.
Min strategi är fortfarande pragmatisk: Livepatch omedelbart aktivera för att stänga exploit-fönstret; samtidigt en ordnad omstart planera inför kommande funktionsuppdateringar eller när ett underhållsfönster löper ut. På så sätt balanserar jag tillgänglighet och säkerhet utan att hamna i blind handlingsiver.
Uppföljning, rapportering och styrning
Jag kontrollerar Livepatch-statusen med canonical-livepatch och sparar resultaten centralt inför revisioner. Genom att jämföra med CVE-flöden och ändringsloggar kan jag se om systemen reagerar som förväntat. För större systemflottor använder jag konfigurationshantering och säkra policyer för att säkerställa att token, Snap-uppdateringar och kärnkällor förblir konsekventa. Varningar vid saknade patchar eller utgångna underhållsfönster hjälper till att planera ett omstartsfönster i god tid. På så sätt behåller teamen överblicken, minskar antalet supportärenden och dokumenterar säkerhetsframstegen på ett transparent sätt.
Utvärdera kostnadsmodell och licensiering
För privat bruk finns ett begränsat antal System utan extra kostnader, vilket underlättar tester och hemmalabb. I företag ingår Livepatch i Ubuntu Pro, som jag tecknar beroende på flottans storlek och behoven. Jag planerar budgeten i Euro och tar dessutom hänsyn till interna kostnader för drift, övervakning och efterlevnad. Besparingar uppstår genom minskad driftstoppstid, mindre nattarbete och lägre planeringsbehov för omstarter. Jag fattar beslutet utifrån driftsrisk, servicefönster och nödvändig täckning över flera distributioner.
Praktiska aspekter av webbhotell och molntjänster: kort driftstopp, högre tillgänglighet
På värddatorer med många Virtuella datorer eller containerteknik hjälper Livepatch att samordna omstarter och upprätthålla hög tillgänglighet för klienterna. En enda omstart av kärnan kan påverka dussintals tjänster, vilket är anledningen till att jag föredrar att installera patchar under drift. På så sätt blir det enklare att hantera SLA-krav, nattliga distributioner och tidsfönster för omfattande uppgraderingar. Även på edge- eller fjärrsystem sparar jag resor och undviker manuella ingrepp. Effekten märks tydligt: färre avbrott, mer förutsägbart underhåll och en stabilare driftsmiljö för kritiska system.
Kort sammanfattning: Använda Canonical Livepatch på ett målinriktat sätt
Jag ställer in Kanonisk Livepatch är till för situationer där tillgänglighet är avgörande och omstarter kan planeras. Tjänsten åtgärdar kritiska säkerhetsluckor i kärnan snabbt, håller tjänsterna online och kompletterar min uppdateringsprocess på ett meningsfullt sätt. Jag tar medvetet hänsyn till begränsningar som kärnfokus, tidsfönster per version och partiell täckning av CVE:er. I homogena Ubuntu LTS-miljöer övertygar den täta integrationen mig, medan miljöer med flera distributioner drar nytta av bredare Livepatch-portföljer. Den som har tydliga underhållsplaner och tar övervakning på allvar får ut mest möjligt av Livepatch Förmån.
