Den andra prototypen av plattformen ALP, som ersätter SUSE Linux Enterprise.

SUSE har offentliggjort den andra prototypen av plattformen ALP "Punta Baretti" (Adaptable Linux Platform), som positioneras som en fortsättning på utvecklingen av SUSE Linux Enterprise-distributionen. Den mest framträdande skillnaden i ALP är uppdelningen av distributionens grundstruktur i två delar: en nedskuren "host OS" för att fungera ovanpå hårdvaran och ett lager för applikationssupport, inriktat på körning i containrar och virtuella maskiner. Byggnaderna är förberedda för x86_64-arkitekturen. ALP utvecklas ursprungligen med hjälp av en öppen utvecklingsprocess där mellanliggande byggnader och testresultat är offentligt tillgängliga för alla intresserade.

ALP-arkitekturen bygger på utveckling i "host OS"-miljön, vilket är minimalt nödvändigt för att stödja och hantera hårdvaran. Alla applikationer och användarrumskomponenter föreslås köras inte i en blandad miljö, utan i separata containrar eller i virtuella maskiner, som körs ovanpå "host OS" och är isolerade från varandra. En sådan organisation kommer att möjliggöra för användare att fokusera på applikationerna och abstrahera arbetsflöden, separera dem från den låg nivå systemmiljön och hårdvaran.

Som grund för "host OS" används produkten SLE Micro, som bygger på prototyperna från projektet MicroOS. För centraliserad hantering erbjuds konfigurationshanteringssystemen Salt (förinstallerad) och Ansible (alternativ). För att köra isolerade containrar finns verktygen Podman och K3s (Kubernetes). Bland de systemkomponenter som har flyttats till containrarna finns yast2, podman, k3s, cockpit, GDM (GNOME Display Manager) och KVM.

Bland funktionerna i systemmiljön nämns användningen av diskryptering som standard (FDE, Full Disk Encryption) med möjlighet att lagra nycklar i TPM. Rotpartitionen monteras i skrivskyddat läge och förändras inte under drift. Det finns en mekanism för atomära uppdateringar i miljön. Till skillnad från atomära uppdateringar baserade på ostree och snap, som används i Fedora och Ubuntu, används i ALP standardpakethanteraren och snapshots i Btrfs-filsystemet istället för att bygga separata atomära bilder och distribuera ytterligare infrastruktur för leverans.

Det finns en anpassningsbar automatisk uppdateringsinställning (till exempel kan man aktivera automatisk installation av endast kritiska sårbarhetsfixar eller återgå till manuell bekräftelse av uppdateringar). För att uppdatera Linux-kärnan utan omstart och avbrott stödjs livsläpp (live patches). För att upprätthålla systemets livskraft (self-healing) används Btrfs-snapshots för att fastställa det senaste stabila tillståndet (om avvikelser upptäcks efter uppdateringar eller inställningsändringar återställs systemet automatiskt till det föregående tillståndet).

Plattformen använder en flerversionsprogramvarustack – genom att använda containrar kan olika versioner av verktyg och applikationer användas samtidigt. Till exempel kan applikationer som har olika versioner av Python, Java och Node.js som beroenden köras, vilket separerar inkompatibla beroenden. Grundläggande beroenden tillhandahålls i form av BCI-paket (Base Container Images). Användaren kan skapa, uppdatera och ta bort programvarustackar utan att påverka andra miljöer.

Huvudsakliga förändringar i den andra prototypen av ALP:

• Installer D-Installer har använts, där användargränssnittet är separerat från de interna komponenterna i YaST och det är möjligt att använda olika frontend:ar, inklusive en frontend för att hantera installationen via webbgränssnittet. Grundgränssnittet för installationshantering är byggt med webbteknologier och inkluderar en hanterare som ger åtkomst till D-Bus-anrop via HTTP, samt själva webbgränssnittet. Webbgränssnittet är skrivet i JavaScript med hjälp av React-ramverket och PatternFly-komponenter. För att säkerställa säkerheten stöder D-Installer installation på krypterade partitioner och möjliggör användning av TPM (Trusted Platform Module) för att dekryptera startpartitionen med nycklar som lagras i TPM-chippet istället för lösenord.
• Vissa YaST-klienter (bootloader, iSCSIClient, Kdump, brandvägg, etc.) kan köras i separata containrar. Två typer av containrar har genomförts – administrativa för att arbeta med YaST i textläge, i GUI och via webbgränssnittet, samt testcontainrar för att utföra automatiserad textning. Flera moduler har också anpassats för användning i system med transaktionsuppdateringar. För att integrera med openQA har ett bibliotek, libyui-rest-api, föreslagits med en implementering av REST API.
• Genomförde körning i containern med Cockpit-plattformen, på vilken webbgränssnittet för konfigureraren och installationsprogrammet är uppbyggt.
• Möjlighet till fullständig disk-kryptering (FDE, Full Disk Encryption) är säkerställd vid installationer ovanpå vanlig hårdvara, och inte bara i virtualiserings- och molnsystem.
• GRUB2 har använts som huvudsaklig bootloader.
• Konfigurationer har lagts till för distribution av containrar för att bygga brandväggar (firewalld-container) och centraliserad hantering av system och kluster (warewulf-container).

Källa: opennet.ru