Linux / Линукс 👨‍🔬

Обсуждение будущего Open Source. И, судя по составу, оно будет интегрировано с Active Directory и мониториться через Performance Monitor 😮

Linux / Линукс 🥸

Linux / Линукс 🥸

Когда ты одновременно компилируешь ядро, настраиваешь dwm, пишешь скрипт на Perl и холиваришь про systemd.

Linux / Линукс 🥸

Linux / Линукс 🥸

Коллега поделился по-настоящему странной проблемой, с которой столкнулся после обновления нескольких виртуальных машин Ubuntu Server. Эта история – отличный пример того, какими непредсказуемыми могут быть трудовые будни, и как важно иногда просто сравнить конфиги.

Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов do-release-upgrade. Однако после второго апгрейда, до версии 22.04, обе эти виртуальные машины наотрез отказались нормально загружаться, просто зависая на старте. Логи намекали на проблемы с монтированием корневого раздела /dev/vda1.

Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.

В ходе поисков решения были отброшены различные гипотезы: нехватка места на /boot, проблемы с fstab или udev (хотя и пробовались разные варианты монтирования), ошибки файловой системы. Kernel panic при обычной загрузке указывал на невозможность найти корневой раздел, который, тем не менее, прекрасно находился при старте через rescue-режим.

Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (diff) XML-файл конфигурации проблемной виртуальной машины (/etc/libvirt/qemu/server.xml) с аналогичным файлом работающей ВМ. И вот оно! В секции <video> у проблемных машин был указан тип модели vmvga. Простое изменение `vmvga` на `qxl` немедленно решило проблему! Виртуальные машины стали загружаться штатно.

Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.

Linux / Линукс 🥸

Linux / Линукс 🥸

Linux / Линукс 🥸

И жили они долго и счастливо, компилируя Arch ядро вместе 🌚

IT-Мемасы от Эникея 🤔

Kubuntu прекращает поставку сеанса X11 в установочных сборках

Разработчики Kubuntu сообщили о прекращении предоставления сеанса KDE на основе X-сервера в базовом окружении. Начиная с выпуска Kubuntu 25.10 в предоставляемых сборках будет оставлен только сеанс на базе Wayland, а для использования сеанса, использующего X-сервер, потребуется вручную установить из репозитория пакет plasma-session-x11. Поддержка запуска x11-приложений при помощи XWayland оставлена без изменений. Ранее похожее решение по прекращении поставки сеанса GNOME на базе X11 было принято для основной сборки Ubuntu Desktop.

Linux / Линукс 🥸

Linux / Линукс 🥸

Сопровождающий libxml2 отказался от приоритетного исправления уязвимостей

Ник Велнхофер (Nick Wellnhofer), единственный мейнтейнер библиотек libxml2 и libxslt, объявил радикальные изменения:

— Уязвимости теперь — обычные баги. Информация о них публикуется сразу в публичном трекере без эмбарго или спецпатчей.

— Приоритет исправлений отменён — Ник будет заниматься проблемами по мере сил и времени.

— Отказ от поддержки libxslt — проект ищет нового сопровождающего.

Причины решения:
— Выгорание.
— Жёсткая критика корпораций: Apple, Google и Microsoft используют libxml2 в ОС и браузерах, хотя в документации чётко указано:
"Библиотека плохо протестирована, содержит уязвимости и не должна использоваться для обработки ненадёжных данных".
— Протест против лицемерия: "Требования в духе OpenSSF Scorecard — попытка вызвать чувство вины у бесплатных разработчиков".

Последствия для экосистемы:
— Патчи для критических дыр могут задерживаться на месяцы;
— Злоумышленники получат данные об уязвимостях раньше исправлений;
— Под угрозой macOS, Android, Chrome, Safari и тысячи приложений, зависящих от libxml2.

Linux / Линукс 🥸

Linux / Линукс 🥸

Когда ты потратил выходные на кастомизацию своего awesome wm, а потом случайно удалил конфиг.

Linux / Линукс 🥸

Linux / Линукс 👨‍🔬

В Fedora планируют полностью прекратить поддержку 32-разрядной архитектуры x86 (i686) в версии 44, которая выйдет весной 2026 года. Это означает, что больше не будет сборки 32-битных пакетов и библиотек multilib, необходимых для запуска старых приложений на 64-битных системах.

Решение затронет пользователей, которые до сих пор пользуются 32-битным софтом, например, Steam или некоторыми играми через Wine. Официальный клиент Steam остаётся 32-битным, поэтому его уберут из репозиториев RPM Fusion. Вместо него предлагается использовать Flatpak-версию, где все зависимости уже включены.

Для Wine разработчики Fedora планируют перейти на 64-битные сборки с поддержкой 32-битных Windows-программ через технологию Wow64. Это должно снизить зависимость от multilib.

Отказ от i686 обусловлен несколькими причинами: ускорение работы пакетного менеджера, снижение нагрузки на сопровождающих, упрощение сборки дистрибутива и экономия ресурсов инфраструктуры.

Процесс будет поэтапным: сначала уберут multilib из репозиториев, а затем полностью прекратят поддержку i686. Если возникнут серьёзные проблемы, изменения могут временно откатить.

Linux / Линукс 🥸

Linux / Линукс 🥸

Обновление дистрибутива OpenWrt 24.10.2

— Добавлена поддержка устройств:
bcm27xx: Raspberry Pi 5, Raspberry P 500 и Raspberry P CM5.
mediatek: ASUS RT-AX52, Cudy WR3000/WR3000H, Mercusys MR80X v3, Routerich AX3000 v1, TP-Link Archer AX80v1, WAVLINK WL-WN573HX3.
ramips: Arcadyan WE410443 и Xiaomi MiWiFi 3A.
ath79: TP-Link Archer C6 v2.
— Для устройств Teltonika RUTX50 (ipq40xx) включён по умолчанию модем.
— Для платформы bcm27xx (Raspberry Pi) реализован драйвер BRCMSTB I2C и задействован существующий драйвер SDHOST.
— Решены проблемы с устройствами: Extreme Networks AP3935, Genexis EX40, NanoPi R6C/R6S.
— Устранены проблемы при сборке с использованием GCC 15.
— В базовое ядро (generic) добавлены драйверы для Broadcom NetXtreme-C/E, DesignWare I2C, DesignWare SPI, Huawei HINIC, Microchip ENC28J60 SPI Ethernet.
— При загрузке системы обеспечена загрузка модулей ядра kmod-r8101, kmod-r8125, kmod-r8126, kmod-r8127 и kmod-r8168. В модулях kmod-r8125, kmod-r8126 и kmod-r8127 включена опция ENABLE_MULTIPLE_TX_QUEUE.
— Пакет с ядром обновлён до версии 6.6.93 (была 6.6.86). Актуализирована кодовая база ucode и netifd.
— Из ядра Linux 6.16 бэкпортированы драйверы kmod-phy-realtek и kmod-r8169. Драйвер kmod-r8125 обновлён до версии 9.016.00, а пакет bcm27xx-gpu-fw до версии 1.20250430.
— Остаётся нерешённой проблема с работой Wi-Fi диапазона 5GHz на некоторых устройствах с чипами ath10k, таких как TP-Link Archer C60 v1.

Linux / Линукс 🥸

Если бы Open Source можно было построить, он бы выглядел как этот забор 🌚

Linux / Линукс 🥸

Уязвимости в пакетных менеджерах Nix, Lix и Guix

В пакетных менеджерах GNU Guix, Nix и Lix выявлены уязвимости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям.

Уязвимости вызваны тем, что при выполнении некоторых операций для доступа к временным сборочным каталогам использовались не дескрипторы dirfd, а полные файловые пути, что позволяло подменить сборочный каталог, размещаемый в иерархии /tmp (например, "/tmp/guix-build-PACKAGE-X.Y.drv-0"). Неверное использование dirfd в функции рекурсивного удаления приводило к состоянию гонки, из-за которого атакующий мог подставить символическую ссылку в момент между созданием и изменением владельца сборочного каталога. При успешной атаке guix-daemon/nix-daemon вместо смены пользователя для сборочного каталога менял владельца для файла, адресуемого символической ссылкой.

Уязвимости устранены в обновлениях Lix 2.93, Nix 2.29 и Guix 1.4.0-38.0e79d5b. Для эксплуатации уязвимостей атакующий должен иметь возможность запуска произвольных сборочных работ. Для атаки с использованием уязвимости CVE-2025-46415 достаточно возможности создания файлов в каталоге /tmp на сборочной машине, а для уязвимости CVE-2025-46416 необходимо иметь возможность запуска кода в контексте основного пространств имён идентификаторов пользователей (pid namespace) и сети (network namespace).

Linux / Линукс 🥸