Зміни у Fedora 41 для системних адміністраторів

Типовим менеджером пакунків у Fedora 41 є DNF 5. Це велике оновлення, яке принесло багато покращень, зокрема:

Інформацію про цей випуск можна знайти за посиланням:https://dnf5.readthedocs.io/en/latest/[попередня документація DNF5], зокрема за посиланням:https://dnf5.readthedocs.io/en/latest/changes_from_dnf4.7.html[список змін між DNF та DNF5]. Розробникам також слід перевірити посилання:https://dnf5.readthedocs.io/en/latest/dnf_daemon/dnf5daemon_dbus_api.8.html[прив’язки DBus API для dnfdaemon].

RPM у Fedora 41 було оновлено до версії 4.20, яка надає ряд покращень, зокрема:

Детальніше за посиланням:https://rpm.org/wiki/Releases/4.20.0[upstream release notes].

Починаючи з Fedora 41, Fedora Atomic Desktops, Fedora CoreOS і Fedora IOT постачатимуться з bootc і DNF5 як частина образу. Тепер ви можете використовувати команди dnf у складі контейнерних збірок, які використовують ці варіанти Fedora як базовий образ. Хоча rpm-ostree все ще доступний, тепер ви можете використовувати bootc для керування встановленням та оновленнями у режимі образу.

Під час запуску dnf на завантаженій системі у режимі образу, DNF видаватиме кращі повідомлення про помилки, вказуючи на доступні у завантаженій системі інструменти для виконання вашого завдання. Це початок процесу увімкнення DNF з можливостями rpm-ostree і переорієнтації на bootc для керування встановленням у режимі образу.

Пакунки RPM використовують ідентифікатори SPDX як стандарт для ліцензій. 90 % пакунків було перенесено на ідентифікатори SPDX. Решту пакунків буде перенесено на SPDX у Fedora 42. Список усіх ліцензій, дозволених (і використовуваних) у Fedora Linux, можна знайти за посиланням:https://docs.fedoraproject.org/en-US/legal/all-allowed/[Юридична сторінка Fedora]. З 90% дев’ять відсотків пакунків мають тимчасову ліцензію LicenseRef-Callaway-*, яка відповідає вимогам SPDX, але потребує присвоєння правильного ідентифікатора ліцензії від організації SPDX.

У NetworkManager вилучено підтримку профілів з’єднань, збережених у форматі ifcfg. Він є застарілим, а власний формат Keyfile є прийнятним і є кращою заміною. Вилучено такі пакунки. NetworkManager-initscripts-ifcfg-rh, NetworkManager-dispatcher-routing-rules і NetworkManager-initscripts-updown.

Для підтримки загального зміцнення системи (запуск програмного забезпечення з мінімально можливими привілеями) службу SSSD тепер налаштовано на запуск від імені користувача sssd або root за допомогою файлів конфігурації служби ystemd. Типовим користувачем цієї служби є sssd, і незалежно від того, якого користувача налаштовано, root або sssd, усі привілеї користувача root буде вилучено, за винятком кількох привілейованих допоміжних процесів.

Інструмент sss_ssh_knownhostsproxy був застарілим у попередньому випуску і тепер вилучений. Його замінено інструментом sss_ssh_knownhosts. Див. розділ man sss_ssh_knownhosts(1), щоб дізнатися, як ним користуватися.

Раніше у хмарному випуску Fedora використовувався параметр командного рядка ядра net.ifnames=0 під час процесу кікстарту. Це вимикало узгоджене іменування мережевих пристроїв і гарантувало, що пристрої Ethernet зберігатимуть свої традиційні імена, такі як eth0, eth1 і так далі. У цьому оновленні net.ifnames=0 було вилучено з kickstart-файлу Fedora Cloud, щоб забезпечити узгодженість іменування мережевих пристроїв і узгодження з іншими версіями Fedora.

З цим оновленням буде вилучено давно застарілий пакет network-scripts. Пакет надавав застарілі утиліти ifup та ifdown, а також network.service. Мережеві скрипти значною мірою залежать від клієнта Dynamic Host Configuration Protocol (DHCP), і без активної розробки немає можливості оновити їх для використання альтернативного клієнта.

Пакунки, які певною мірою залежать від network-scripts:

Зауважте, що ця зміна також впливає на всіх користувачів з локальними користувацькими мережевими скриптами, які потребують функціональності з пакунка network-scripts.

Починаючи з Fedora 41, усі підтримувані версії Kubernetes, CRI-O та CRI-Tools будуть доступні одночасно. Для прикладу, Fedora 41 має наступні RPM Kubernetes на момент випуску:

Це суттєва зміна порівняно з попередніми випусками Fedora, у яких у репозиторіях Fedora було доступно лише одну версію Kubernetes. CRI-O та CRI-Tools RPM також поділяють цю зміну з версіями, доступними для доповнення Kubernetes. Докладнішу інформацію наведено за цим посиланням:https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/[Fedora Quick Doc].

TuneD замінив power-profiles-daemon як демон керування профілями живлення за замовчуванням для наступних завантажень робочих станцій Fedora:

Користувачі сервера можуть налаштовувати профілі живлення для настільних комп’ютерів, редагуючи файл /etc/tuned/ppd.conf у командному рядку. Користувачі робочих станцій можуть налаштувати профіль живлення за допомогою центру керування з графічним інтерфейсом.

Пакунок tuned-ppd надає заміну для power-profiles-daemon, що дозволяє використовувати його з поточними робочими столами.

Ті застосунки, які вже використовують power-profiles-daemon, можуть отримати доступ до TuneD без зміни коду.

Netavark - це інструмент для роботи з мережею контейнерів, який використовується у Podman. Netavark керує інтерфейсами і правилами брандмауера, і з цим оновленням Fedora він за замовчуванням використовуватиме nftables для створення правил брандмауера для контейнерів.

На атомарних десктопах оновлено політику, яка контролює доступ до демона rpm-ostree:

У системах Fedora CoreOS та Fedora IoT кореневий каталог системи (/) тепер монтується за допомогою composefs, що робить його по-справжньому доступним лише для читання, підвищуючи цілісність та надійність системи. Це перший крок до повної перевірки цілісності файлової системи під час виконання.

На атомарних десктопах завантажувач тепер автоматично оновлюється за допомогою bootupd. Нові системи тепер встановлюються зі статичною конфігурацією GRUB, яка покладається лише на конфігураційні файли специфікації завантажувача і не регенерується при кожному оновленні.

Проект Kubernetes підтримує 3 паралельні версії з новим випуском кожні 4 місяці. Раніше у Fedora завжди надавалася лише одна з цих версій, яка відповідала певному випуску. Починаючи з Fedora 41, надаються всі версії Kubernetes, які наразі підтримуються, з використанням окремих пакунків, названих на честь кожної основної версії. Використовуючи rpm kubernetes-client як приклад, замість kubernetes-client-1.29.2-1.fc41, Fedora тепер пропонує kubernetes1.29-client-1.29.2-1.fc41, kubernetes1.28-client-1.28.5-1.fc41 і kubernetes1.27-client-1.27.8-1.fc41.

Оновлення до Fedora 41 на машині з Fedora 40 або Fedora 39 вимагає від користувача ручного вибору відповідної версії пакунка Kubernetes.

Для отримання додаткової інформації див. посилання:https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes-versioned/[Fedora Quick Docs].

Fedora 41 є першим випуском Fedora, який містить цільовий маппер пристроїв dm-vdo (віртуальний оптимізатор даних) разом з пакетом інструментів користувача vdo.

Ціль dm-vdo забезпечує вбудовану дедуплікацію, стиснення і тонке резервування. Ці функції можна додати до стеку сховища, сумісного з будь-якою файловою системою. Ціль dm-vdo може підтримуватися сховищем об’ємом до 256 ТБ і мати логічний розмір до 4 ПБ. Цей таргет розроблявся з 2009 року. Вперше він був випущений в 2013 році і з тих пір використовується у виробничих середовищах. У 2017 році вона стала відкритим вихідним кодом, а у 2024 році була інтегрована в ядро Linux.

Для підтримки цілей dm-vdo у пакеті інструментів користувача vdo передбачено такі інструменти:

До пакунка vdo також включено додаткові засоби діагностики. Втім, для нормальної роботи вони рідко потрібні.

Хоча це і не є обов’язковим, настійно рекомендується використовувати lvm2 для керування томами vdo. Докладнішу інформацію наведено у документації до lvm2.

Якщо у вас є том vdo, створений за допомогою модуля kvdo, обов’язково зверніться до посилання:https://github.com/dm-vdo/kvdo[документація kvdo], щоб ознайомитися з важливими міркуваннями, перш ніж намагатися оновити його до dm-vdo.

Дивіться посилання:https://github.com/dm-vdo/vdo-devel[dm-vdo] та посилання:https://github.com/dm-vdo/vdo[vdo] у попередній документації для отримання додаткової інформації.

Це оновлення містить випуски stratisd 3.7.3 та stratis-cli 3.7.0. У ньому зроблено одне значне покращення, кілька незначних покращень та низку дрібних виправлень.

Найбільш важливим є те, що Stratis 3.7.3 розширює функціональність, дозволяючи користувачеві повертати знімок, тобто перезаписувати файлову систему Stratis попередньо зробленим знімком цієї файлової системи. Процес відновлення складається з двох кроків. По-перше, необхідно запланувати створення знімка для відновлення. Однак, повернення може відбутися лише тоді, коли запущено пул. Це можна зробити під час роботи stratisd, зупинивши і перезапустивши пул. Повернення також може бути спричинено перезавантаженням системи, на якій запущено stratisd. Перезапуск stratisd також призведе до запланованого повернення, якщо пул, який містить файлову систему, що підлягає поверненню, вже було зупинено. Для підтримки цієї функціональності до stratis-cli додано дві нові підкоманди файлової системи: chedule-revert і cancel-revert.

Для підтримки можливості повернення до початкового стану було додано деякі додаткові можливості. По-перше, до властивостей D-Bus тепер додано поле походження файлової системи, яке оновлюється за потреби. stratis-cli показує значення походження у нещодавно введеному перегляді детальної інформації про файлову систему. stratisd також підтримує новий метод D-Bus файлової системи, який повертає метадані файлової системи. Команди налагодження файлової системи у stratis-cli тепер містять опцію get-metadata, яка показує метадані файлової системи для заданого пулу або файлової системи. Еквівалентну функціональність також було введено для метаданих пулу.

До stratisd також включено значну кількість виправлень версій залежностей, незначні виправлення та додаткове тестування, а до `stratis-cli - покращення реалізації синтаксичного розбору командного рядка.

Будь ласка, зверніться до журналів змін за посиланням:https://github.com/stratis-storage/stratisd/blob/rebase-3.6.0/CHANGES.txt[stratisd] та посиланням:https://github.com/stratis-storage/stratis-cli/blob/rebase-3.6.0/CHANGES.txt[stratis-cli] для отримання додаткової інформації про цей випуск.

У Fedora 41 з’явився новий інструмент для запитів до сховищ, fedora-repoquery, невеликий інструмент командного рядка для виконання запитів до сховищ пакунків Fedora, EPEL, eln і Centos Stream. Він обгортає dnf-запит, відокремлюючи кешовані дані репозиторіїв під окремими іменами репозиторіїв для пришвидшення кешованих запитів.

Приклади використання див. за посиланням:https://github.com/juhp/fedora-repoquery#readme[upstream readme] або скористайтеся fedora-request --help після встановлення.

OpenSSL у Fedora 41 більше не довіряє підписам SHA-1 за замовчуванням, а також блокує їх створення. Цю зміну було впроваджено через те, що атаки на SHA-1 з використанням обраного префікса стають все більш можливими. Це наближає налаштування безпеки Fedora за замовчуванням до того, що вважається безпечним у сучасному криптографічному ландшафті.

Ви можете повернути попередні значення за замовчуванням або для всієї системи за допомогою update-crypto-policies --set FEDORA40, або для кожного процесу за допомогою runcp FEDORA40 command args, використовуючи інструмент crypto-policies-extra, доступний за посиланням:https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras[Copr]. Ці старі політики буде збережено у Fedora у кількох наступних випусках. Однак, їх використання не рекомендується.

Збірки пакунків Fedora тепер більш детерміновані, що наближає дистрибутив до мети створення повністю відтворюваних збірок для всіх його пакунків.

Докладнішу інформацію наведено за посиланням:https://docs.fedoraproject.org/en-US/reproducible-builds/[Документація про відтворювані збірки Fedora].

Віртуальну мережу libvirt змінено так, щоб надавати перевагу використанню внутрішньої частини брандмауера nftables замість iptables.

Ця зміна має певний потенційний вплив на сумісність; див. посилання:https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables#Upgrade/compatibility_impact++[Сторінка змін] для отримання детальної інформації та обхідних шляхів.

Redis було замінено на Valkey у Fedora 41 через зміну ліцензії Redis на RASLv2/SSPL, що зробило його несумісним з принципами вільного та відкритого коду. Valkey є повною заміною Redis, яка зберігає оригінальне ліцензування BSD.

Під час оновлення до Fedora Linux 41 системи зі встановленим redis буде переведено на valkey за допомогою пакунка valkey-compat. Зміна має бути максимально прозорою для користувачів, оскільки пакунок valkey-compat забезпечує перенесення конфігурації та даних для найпоширеніших конфігурацій. Системні одиниці valkey матимуть псевдоніми для redis, щоб полегшити міграцію для користувачів.

У Fedora 41 припинено підтримку рушіїв OpenSSL. Рушії не сумісні з FIPS, а відповідний API застарів починаючи із OpenSSL 3.0. Користувачам, які наразі використовують механізми OpenSSL, слід перейти на використання провайдерів.