Microsoft har publisert distribusjonen Azure Linux 3.0

Microsoft har publisert den første stabile oppdateringen av den nye versjonen av Azure Linux 3.0, som tidligere ble distribuert under navnet CBL-Mariner. Distribusjonen utvikles som en universell grunnplattform for Linux-miljøer brukt i skyinfrastruktur, edge-systemer og diverse tjenester fra Microsoft. Prosjektet har som mål å forene de Linux-løsningene som brukes av Microsoft og å forenkle vedlikehold av Linux-systemer for ulike formål. Arbeidene fra prosjektet distribueres under MIT-lisensen. Pakkeoppbygginger lages for aarch64 og x86_64-arkitekturer. Størrelsen på installasjonsbildet er 740 MB.

Blant endringene i den nye versjonen:

• Linux-kjernen er oppdatert til versjon 6.6 (tidligere ble versjon 5.15 brukt). Støtte for live patching er lagt til, noe som tillater fiksing av sårbarheter i kjernen uten omstart.
• Nye versjoner av pakker er foreslått, inkludert systemd 255, glibc 2.38, GCC 13.2, clang 18.1, OpenSSL 3.3, rpm 4.18.2, ruby 3.3.0, BIND 9.20, containerd 1.7.13, kunc 1.1.12, ostree 2024.5, rust 1.75, Perl 5.38, Python 3.12.3, QEMU 8.2.0.
• Systemet for påbudt tilgangskontroll, SELinux, er som standard satt til 'enforcing' modus.
• Som standard er den forente hierarkiet cgroups v2 aktivert. Den viktigste forskjellen mellom cgroups v2 og v1 er bruken av et felles hierarki for alle typer ressurser, i stedet for separate hierarkier for tildeling av CPU-ressurser, regulering av minneforbruk og for inn-/utdrag.
• Verktøy er lagt til for å erstatte andre distribusjoner (OSsku In-Place Migration) på noder i Microsoft Azure-skyen, for eksempel kan Ubuntu som er installert, erstattes med Azure Linux.
• Støtte for nye NVIDIA GPU-er, som NVIDIA A100 og H100, er lagt til, samt NVIDIA GPU Operator for automatisering av styring av NVIDIA-drivere på noder med Azure Linux.

Distribusjonen Azure Linux tilbyr et lite standardsett av grunnleggende pakker, som utgjør en universell basis for å bygge innholdet i containere, vertsmiljøer og tjenester som kjører i skyinfrastrukturer og på edge-enheter. Mer komplekse og spesialiserte løsninger kan opprettes ved å legge til ekstra pakker over Azure Linux, men grunnlaget for alle slike systemer forblir uendret, noe som forenkler vedlikehold og forberedelse av oppdateringer.

For eksempel brukes Azure Linux som grunnlag for den mini-distribusjonen WSLg, som gir komponentene i grafikkstakken for å kjøre GUI-applikasjoner for Linux i WSL2 (Windows Subsystem for Linux) miljøer. Den utvidede funksjonaliteten i WSLg oppnås ved å inkludere ekstra pakker med kompositt. serveren Weston, XWayland, PulseAudio og FreeRDP.

For managing services and load, the system manager systemd is used. Package managers RPM and DNF are provided for package management. The SSH server is not enabled by default. To install the distribution, an installer is provided that can operate in both text and graphical modes. The installer offers the option to install with either a full or basic set of packages, and provides an interface for selecting the disk partition, choosing a hostname, and creating users.

The Azure Linux build system allows for generating both individual RPM packages based on SPEC files and source texts, as well as monolithic system images constructed with the rpm-ostree tool and updated atomically without breaking into individual packages. Consequently, two models of update delivery are supported: through individual package updates and through the reconstruction and update of the entire system image. A repository containing about 3000 already compiled RPM packages is available, which can be used to assemble custom images based on a configuration file.

The basic platform includes only the most essential components and is optimized for minimal memory and disk space usage, as well as fast boot times. The project employs a 'maximum security by default' approach, which implies the inclusion of various additional mechanisms to enhance protection:

• Filtering system calls using the seccomp mechanism.
• Disk partition encryption.
• Package verification via digital signatures.
• Address space randomization.
• Protection against attacks related to symbolic links, mmap, /dev/mem, and /dev/kmem.
• Read-only mode and prohibition of code execution in memory areas where kernel and module data segments are located.
• An option to prohibit kernel module loading after system initialization.
• Use of iptables for network packet filtering.
• Enabling protection modes against stack overflows, buffer overflows, and string format issues during compilation (_FORTIFY_SOURCE, -fstack-protector, -Wformat-security, relro).

Kilde: opennet.ru