Publicat în

Fedora Linux 45 Release Party: Noile caracteristici enterprise și ce înseamnă pentru infrastructura ta

Comunitatea Fedora se pregătește să sărbătorească lansarea Fedora Linux 45, o versiune care aduce schimbări semnificative pentru administratori de servere, ingineri DevOps și arhitecți de infrastructură. Cu disponibilitatea generală programată pentru 30 octombrie 2026, Fedora 45 intră în faza de release candidate aducând un installer web modern pentru edițiile Atomic, kmscon în locul consolii kernel vechi, DRM Panic pentru ecrane de crash clare și aplicarea obligatorie a verificării semnăturilor RPM. Pentru echipele care gestionează flețe de servere sau pipeline-uri CI/CD, aceste schimbări nu sunt doar cosmétique — ele impactează direct modul în care provizionezi, monitorizezi și securizezi infrastructura. Dacă folosești Fedora ca imagine de bază pentru containere, mașini virtuale sau bare-metal, articolele de mai jos îți explică ce trebuie să testezi acum, înainte ca versiunea finală să ajungă în producție.

Installerul web Anaconda ajunge pe Silverblue și Kinoite

Până acum, edițiile Atomic ale Fedora (Silverblue, Kinoite, Sericea, Onyx) foloseau installerul text-mode clasic sau varianta grafică GTK, ceea ce complica automatizarea la scară largă. Fedora 45 aduce installerul web bazat pe Anaconda — același backend folosit de variantele Workstation și Server — expus printr-o interfață HTTP pe portul 8080 în timpul boot-ului mediului de instalare. Practic, poți porni instalarea de pe un stick USB, accesa http://<ip-installer>:8080 din browserul stației de lucru și completa o interfață React care scrie direct un fișier Kickstart sau Ignition, apoi declanșează instalarea unattended.

Aceasta este o schimbare majoră pentru infrastructura GitOps: poți genera configurații Ignition din pipeline-ul tău CI, să le servești printr-un server HTTP simplu, și mașinile target să se instaleze singure fără intervenție umană. Pentru medii air-gapped, installerul web funcționează și offline, deoarece toate asset-urile sunt embeduite în imaginea ISO. Diferența față de Cockpit (care rulează după instalare) este că Anaconda Web rulează în timpul instalării, având acces la partitionare, selecție de pachete, configurare de rețea și creare de utilizatori înainte de first-boot.

Un exemplu concret: dacă provizionezi 50 de noduri Kubernetes cu Fedora CoreOS (succesorul spiritual al Silverblue pentru server), poți folosi Anaconda Web pentru a scrie configurația Ignition care include chei SSH, configurare de rețea statică, disk encryption cu TPM2 și enrolment automată în cluster — totul înainte de primul reboot. Documentația tehnică pentru API-ul installerului web este disponibilă în repositoriul anaconda-installer/anaconda-web-ui pe GitHub, iar imaginea de test poate fi descărcată de pe alt.fedoraproject.org sub directorul releases/45_Beta/Atomic/.

Pentru echipele care gestionează servere dedicate la scară largă, această capacitate de instalare remote, guidată de API, reduce timpul de provisioning de la ore la minute. Dacă ești în căutarea de hardware compatibil pentru teste, poți verifica ofertele de servere dedicate configurabile care suportă boot PXE și management IPMI — esențiale pentru rollout-uri automate.

kmscon înlocuiește consola kernel veche: ce înseamnă pentru debugging și serial console

Consola kernel tradițională (VGACON) a fost înlocuită cu kmscon, un emulator de terminal userspace care rulează atop KMS/DRM. Schimbarea este transparentă pentru majoritatea workload-urilor, dar are implicații concrete pentru accesul la consolă serială, logging-ul de boot și debugging-ul kernel panic.

kmscon suportă Unicode complet, fonturi TrueType, scrolling istoric și multiple virtual terminals (VT-uri) pe un singur framebuffer, fără a necesita framebuffer-ul kernel. Pentru servere headless accesate prin SOL (Serial-over-LAN) sau consoale iDRAC/iLO/IPMI, kmscon expune un terminal mult mai capabil decât VGACON: redă corect caractere UTF-8, suportă mouse reporting (DECSET 1006) și permite copy-paste prin bracketed paste mode. În practică, când te conectezi prin ipmitool sol activate sau prin consola web a furnizorului de cloud, vezi un terminal modern, nu unul limitat la 80×25 ASCII.

Impactul operațional: dacă ai scripturi de automatizare care parsează output-ul de boot (de exemplu, pentru a detecta erori de montare sau timeout-uri de rețea), kmscon poate emite secvențe ANSI diferite. Testează-ți runbook-urile de incident response pe o imagine RC înainte de GA. De asemenea, kmscon necesită un driver KMS funcțional (amdgpu, i915, nouveau, virtio-gpu); pe hardware server vechi fără KMS (de exemplu, Matrox G200e pe BMC-uri vechi), sistemul va fallback la VGACON sau la consola serială clasică.

Pentru medii virtualizate (KVM, VMware, Hyper-V), kmscon funcționează out-of-the-box cu virtio-gpu/virtio-vga. Pe bare-metal, asigură-te că firmware-ul serverului expune un framebuffer UEFI GOP compatibil — majoritatea serverelor din generația actuală (Dell 14G+/15G, HPE Gen10+/Gen11, Lenovo ThinkSystem V2/V3) lo fac. Dacă planifici achiziții de hardware nou pentru cluster, verifică specificațiile de consola management pentru a evita surprize la comisionare.

DRM Panic: ecrane de crash kernel ușor de citit, direct pe GPU

Kernel panic-ul tradițional scrie un mesaj text în framebuffer-ul de boot sau pe consola serială — adesea trunchiat, greu de fotografiat, imposibil de citit pe un monitor fizic conectat la un server în rack. Fedora 45 activează DRM Panic (introduit în kernel 6.12, backportat în 6.11.x pentru Fedora), care rendează un ecran de panic grafic, colorat, cu QR code care conține hash-ul crash-ului, trace-ul stivei și identificatorul commit-ului kernel.

Avantajul operational: un operator de datacenter poate fotografia ecranul cu telefonul, scana QR code-ul și obține un link direct către bugzilla.kernel.org sau fedoraproject.org cu contextul complet al crash-ului. Nu mai e nevoie de acces la consolă serială, de netconsole sau de kdump configurat corect (deși kdump rămâne necesar pentru analiza profundă a memoriei). DRM Panic funcționează pe orice driver DRM/KMS: amdgpu, i915, nouveau, virtio-gpu, simpledrm.

Configurarea este simplă: drm_panic=1 pe linia de comandă kernel (activat implicit în Fedora 45). Poți personaliza comportamentul cu drm_panic=timeout:N (secunde până la reboot automat) sau drm_panic=disable dacă preferi comportamentul vechi. Pentru servere fără monitor fizic (headless), DRM Panic scrie totuși în framebuffer-ul virtual; dacă accesezi consola prin KVM-over-IP sau BMC, vezi ecranul grafic. Dacă folosești doar consola serială, mesajul text clasic rămâne disponibil pe /dev/ttyS0.

O limitare cunoscută: pe sisteme cu GPU-uri discrete multiple (de exemplu, servere GPU pentru AI/ML), DRM Panic se afișează pe primul driver DRM inițializat. Asigură-te că driverul GPU-ului principal (cel conectat la monitorul de management sau la BMC) este cel care inițializează primul, sau configurează drm.edid_firmware pentru a forța afișarea pe portul dorit.

Verificarea semnăturilor RPM devine obligatorie: impact pe supply chain security

Fedora 45 aplică rpmkeys --verify implicit la toate operațiunile de instalare, actualizare și downgrade. Orice pachet fără semnătură validă (semnată de cheia Fedora corespunzătoare pentru versiune) este refuzat. Aceasta elimină o clasă întregă de atacuri supply chain: un mirror compromis, un MITM pe rețea, sau un pachet modificat manual nu mai poate fi instalat „din greșeală”.

Pentru administratori, schimbarea are două implicații practice. Prima: dacă folosești repositorii terți (COPR, EPEL, repo-uri interne private), trebuie să le semnezi pachetele și să distribui cheile publice în /etc/pki/rpm-gpg/ sau prin pachetul fedora-repos / epel-release actualizat. dnf config-manager --setopt=repo_gpgcheck=1 --save devine default; nu mai poți face --nogpgcheck fără avertisment explicit. A doua: imaginile container bazate pe Fedora 45 (UBI, Fedora Base, Fedora Minimal) vor include doar pachete semnate. Dacă construiești imagini custom cu dnf install în Dockerfile/Containerfile, build-ul va eșua pentru pachete nesemnate.

Soluția pentru repo-uri interne: folosește rpmsign --addsign cu o cheie GPG dedicată (RSA 4096 sau Ed25519), apoi distribuie cheia publică printr-un pachet mycorp-repo-keys instalat de toate mașinile la provisioning. Pentru COPR, cheile sunt gestionate automat de infrastructura Fedora — activează gpgcheck=1 în .repo file. Pentru EPEL 10 (care va fi bazat pe RHEL 10 / Fedora 45+), cheile noi sunt deja publicate pe https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-10.

Un caz edge: pachetele instalate înainte de upgrade la Fedora 45 (de exemplu, pachete locale .rpm instalate manual) nu sunt re-verificate la upgrade. Rulează rpm -Va --nodigest --nosignature pentru a audita pachetele existente, apoi reinstalează-cele din repo-uri verificate. Pentru medii high-security (FIPS, Common Criteria), această enforcere implicită aliniază Fedora cu cerințele de compliance fără configurare suplimentară.

Dacă gestionezi o fermă de servere și ai nevoie de un partener de încredere pentru hardware-ul care rulează aceste workload-uri securizate, îți recomandăm să explorezi soluțiile de infrastructură dedicată care oferă control total pe hardware și chain-of-custody pentru supply chain.

Pași practici de pregătire pentru Fedora 45 în producție

  1. Descarcă imaginea RC de pe alt.fedoraproject.org și rulează-o în staging: testează installerul web Anaconda pe o mașină virtuală și pe bare-metal cu IPMI; validează generarea Ignition/Kickstart din pipeline-ul tău CI.
  2. Verifică compatibilitatea consolei: conectează-te prin SOL/IPMI/KVM-over-IP la un nod de test cu Fedora 45 RC; confirmă că kmscon redă corect UTF-8, că scrolling-ul funcționează și că scripturile de monitoring ale log-urilor de boot nu se strică.
  3. Simulează un kernel panic (Magic SysRq c sau echo c > /proc/sysrq-trigger) și confirmă că DRM Panic afișează ecranul grafic cu QR code scaneazăbil; testează atât pe monitor fizic, cât și prin consola BMC.
  4. Auditează repo-urile interne: semnează toate pachetele custom cu rpmsign, actualizează pachetele -repo-keys distribuite la provisioning, și rulează dnf upgrade --refresh pe un nod de test pentru a confirma că nicio eroare GPG nu apare.
  5. Actualizează imaginile container de bază: reconstruiește Dockerfile-urile/Containerfile-urile folosind fedora:45 sau fedora-minimal:45 ca base; confirmă că build-urile trec fără --nogpgcheck și că sbom-urile generate includ pachete semnate.
  6. Revizuiește runbook-urile de incident response: actualizează procedurile de captură a kernel panic-ului să includă fotografierea QR code-ului DRM Panic și trimiterea automată către sistemul de ticketing.

Concluzie

Fedora Linux 45 nu este o lansare incrementală — este un punct de inflexiune pentru modul în care administrezi infrastructura Linux la scară. Installerul web Anaconda pe Atomic editions transformă provisioning-ul dintr-un proces manual, predat erorilor, într-un flow declarativ, GitOps-native. kmscon modernizează accesul la consolă pentru o eră de operatori care lucrează remote, prin BMC-uri și KVM-over-IP, nu în fața rack-ului. DRM Panic transformă kernel panic-ul dintr-un moment de panică într-un incident documentabil, acționabil, cu context tehnic instantaneu. Și enforcerea semnăturilor RPM ridică linia de bază a supply chain security la un nivel pe care alte distribuții încă nu l-au atins implicit.

Pentru echipele care folosesc Fedora ca fundament al platformelor lor — fie că vorbim de Kubernetes clusters, de flețe de edge servers, de workstations pentru dezvoltatori sau de build farms — timpul de testat este acum, în faza RC. Nu aștepta GA pentru a descoperi că scriptul tău de provisioning nu parsează output-ul kmscon, sau că repo-ul intern nu are pachete semnate. Clonează imaginea RC, rulează matricea ta de teste, raportează bug-urile upstream (Fedora QA acceptă și încurajează feedback-ul la această etapă), și pregătește rollout-ul pentru noiembrie.

Infrastructura ta merită un sistem de operare care evoluează la fel de repede cum evoluează cerințele tale. Fedora 45 este acel sistem.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *