На протяжении месяцев меня преследовал странный баг на моём основном компьютере: иногда система не могла корректно выйти из режима сна и входила в такой состояние, что мне приходилось выключать её кнопкой на блоке питания. При этом, данная ситуация возникала не всегда и как будто случайно — примерно в половине случаев пробуждение ото сна происходило корректно. У меня вполне обычная конфигурация на Intel Core 9-го поколения со встроенной графикой (т.е. Nvidia у меня и близко нет) и двумя ОС на борту: openSUSE Leap и Fedora. Мне удалось выяснить, что дело, скорее всего, было не в железе, так как в Fedora данный баг не проявлялся никогда. Значит, что-то не так было именно в Leap. Анализ логов journalctl ничего не выявил, и я решил заняться диагностикой методом проб и ошибок. Первый подозреваемый — ядро, а точнее набор патчей к нему от openSUSE. Я скачал ванильное ядро и собрал его по старинке через make all, установил и загрузился в него. Проблема не ушла. Ну, и чтобы вы понимали — каждый этап такой диагностики требует пары-тройки дней наблюдений за тем, как себя ведёт спящий режим, иначе можно ничего и не заметить.

Короче говоря, после многих дней размышлений, гугления и изучения профильных тем на Reddit и openSUSE Forums, я почти случайно обнаружил виновника моих бед. Это оказалась системная служба power-profiles-daemon, которая управляет профилями энергопотребления и позволяет переключать их, в том числе, в панели Plasma. Я решил отключить её и на всякий случай задействовать вместо неё tuned. Службы, кстати, между собой конфликтуют, поэтому в один момент времени может выполняться только одна из них. Не то чтобы они особо полезны на десктопе, но я решил всё же оставить tuned включённым. В итоге, нужный набор команд получился таким:

sudo systemctl disable power-profiles-daemon --now
sudo systemctl mask power-profiles-daemon.service
sudo systemctl enable tuned --now

Всё, после этого проблема ушла. У меня сейчас уже несколько дней аптайма и как минимум дюжина циклов сон-пробуждение, без каких-либо зависаний в openSUSE Leap. Если у вас была подобная проблема, попробуйте мой способ решения!

Уже около месяца я ежедневно использую дома свежий релиз Leap 15.4, и он мне очень нравится. В этой заметке я хочу перечислить несколько небольших доработок, которые я сделал в системе. Некоторые я уже ранее упоминал, но настало время собрать их все в одной записи. Итак:

Доработка загрузки

Если у вас установлена только одна ОС, то загрузчик GRUB2, собственно говоря, не нужен. На UEFI-системах можно загружать ядро Linux сразу, о чём я писал в своё время. Нынче этот приём называется systemd-boot, но самой технике уже сто лет в обед. Например, мой предыдущий компьютер с материнской платой DH67BL-B3 из 2011 года уже умел это делать. Команды ниже добавят в ПЗУ загрузочную запись и заодно отключат вывод системных сообщений при запуске и выключении ОС (всё равно, на десктопе это не нужно):

NB: Замените /dev/nvme0n1 на адрес своего жёсткого диска

Результат этих действий такой: включение ПК теперь напоминает включение смарт-ТВ или какого-либо бытового прибора: на экране появляется логотип производителя материнской платы, а за тем, через несколько секунд — без мерцаний или чего-либо ещё — сразу рабочий стол. При выключении, опять же, в верхнем левом углу не отображается ничего, экран просто гаснет. Это красиво и изящно, к тому же довольно удобно именно на openSUSE Leap, где ядро почти не меняется, а значит файлы vmlinuz.efi и initrd.img можно обновлять нечасто. Если нужен журнал загрузки, то под рукой всегда есть команда journalctl -b. Также, не будем забывать о том, что обычная запись для GRUB2 в EFI никуда не делась, и можно всегда вернуться к ней. Очень удобно прямо из ОС перезагрузиться в системный интерфейс EFI setup utility следующей командой:

systemctl reboot --firmware-setup

Заодно, я хочу порекомендовать графическую утилиту для управления EFI-записями. Выглядит изящно, умеет многое:

Добавление прав на управление принтерами

Тут мне особо нечего добавить, см. мою прошлогоднюю заметку. Время идёт, а мейнтейнеры openSUSE по-прежнему считают, что у пользователя не должно быть прав на управление печатью. Ну такое…

Исправление работы Packagekit и Discover

Изначально, Packagekit преследовал благородную цель унифицировать управление пакетами в разных дистрибутивах Linux. Не важно, что вы используете — Debian/Ubuntu, Fedora, openSUSE или Manjaro — вы всегда можете обновиться командой pkcon update или установить локальный пакет командой pkcon install-local <файл>. Удобство достигается различными бэкэндами к Packagakit, среди которых есть и Zypp для Zypper в openSUSE. Проблема, однако, в том, что если вы в openSUSE Leap попробуете открыть скачанный RPM-файл в Discover (интерфейсе к Packagekit), то установка гарантированно завершится ошибкой. Всё дело в неспособности бэкэнда Zypp обрабатывать некоторые события от Zypper, например проверку подписи пакетов. Я выяснил, что если проверку подписей отключить, то Discover начинает работать как надо. Следует в конец файла /etc/zypper/zypp.conf добавить gpgcheck=0, этого достаточно. Формально, вы понижаете безопасность, но фактически на десктопе от подписей GPG толку особо нет.

Решение проблемы с korner bug

Korner bug — это просторечное название очень раздражающего визуального дефекта, который проявляется последние пару лет в Plasma. Чтобы его увидеть, нужно включить эффект «Размытие» и установить декорации окон со скруглением углов. Вы быстро заметите, что уголки окон не имеют прозрачности и на некоторых фонах выглядят ужасно.

Этот баг пробовали решать и так, и эдак, но в каждом случае были оговорки, и проблема полностью не исчезала.

Я нашёл надёжное решение, которое наконец-то всё исправляет. Если вы будете использовать эту версию LightlyShaders, то скругление окон будет происходить корректно.

Более того, в настройках эффекта есть возможность использовать «сквиркл» — квадратоокружность, которая, например, используется в macOS. Как обычно, в Plasma вам даётся больше функций, чем вы просили: LightlyShaders содержит ползунок, регулирующий степень похожести круга на квадрат. В яблочном саду занервничали…

Решение проблемы с «дёргающимися» значками на рабочем столе

Наконец, последним в моём списке идёт баг со странным поведением значков на рабочем столе Plasma. По умолчанию, они выровнены горизонтально относительно верхнего левого угла. Но если тип выравнивания изменить, то вы вскоре заметите неприятный дефект: при загрузке рабочего стола значки как будто снова выровнены по-умолчанию, но стоит щёлкнуть по рабочему столу, как они «улетят» согласно вашим настройкам.

Мне стоило большого труда откопать в переписке разработчиков Plasma обсуждение этого бага, который время от времени всплывал снова и снова. Оказалось, что решение существует. Влад Загородний предложил патч, который исправляет ошибку. Патч отключает функцию прокрутки значков на рабочем столе: если у вас их запредельно много, и они не влезают на рабочий стол, то это патч вам навредит. Но, на мой взгляд, так много значков не бывает почти ни у кого, так что всё в порядке! Скопируйте патч в директорию и примените его:

sudo cp 0001-foobar.patch /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/

cd /usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/

sudo patch -p6 <0001-foobar.patch

Да, при следующем обновлении пакета plasma5-desktop всё вернётся обратно, и так до тех пор, пока проблема не будет решена в апстриме. Но, какое-никакое решение есть уже сейчас.

На этом всё, спасибо за внимание!

Я всё таки собрался с силами и освоил Open Build Service (OBS), на котором собираются сторонние пакеты для openSUSE (и не только). Необходимость в этом была у меня давно, особенно в свете того, что мой предыдущий репозиторий для Rosa Fresh стремительно терял актуальность вместе с актуальностью самого дистрибутива. Пришло время перенести наработки в новый «домашний» репозиторий для openSUSE. С этой системой я уже давно на «ты». Я начал пользоваться ею с самых первых версий, когда Novell переименовала SUSE в openSUSE в 2006 году. Версиями 10.3-13.1 я пользовался непостоянно, меняя их время от времени на что-то ещё, начиная с 13.1 openSUSE стояла у меня второй системой, а с 15.1— первой. Пока полёт нормальный).

Мой новый репозиторий живёт по следующему адресу:
https://download.opensuse.org/repositories/home:/linuxphoto

Пока что там немного ПО, но уже есть кое-что интересное! Я начал со сборки тем оформления для KDE Plasma 5. На данный момент для версий openSUSE Leap 15.2 и 15.3 собраны:

1. KDE2 Decoration. Это порт классической темы из KDE2 для современного компонента KDecoration2, используемого в Kwin5.

2. Breeze Enhanced. Это форк темы Breeze для декораций окон. Здесь можно настраивать очень много параметров, включая прозрачность заголовка. По это причине Breeze Enhanced хорошо сочетается с полупрозрачными темами Kvantum: вместе с эффектом Blur можно делать полностью «стеклянные» окна.

Первая из двух картинок моя, вторая — из Интернета (я сейчас под ВМ, так что прозрачность толком не показать). Тут нужно заметить, что Breeze Enhanced имеет изъян в виде «треугольников» в местах скругления окон. Это особенность данной темы.

3. Hello Decoration. Это ещё одна тема в стиле macOS. Здесь нет поддержки прозрачности, зато в остальном исполнение просто великолепное! Тема поставляется только для Kwin (не для виджетов Qt5), но зато тут в комплекте идут шейдеры для скругления окон.

4. Skulpture-Qt5. Это очень красивый и незаслуженно забытый стиль оформления для Qt4/5. Изначально в нём была также и тема декорации окон, и развитый конфигуратор, и даже пакет для openSUSE 12. Но теперь всё это изрядно поросло мхом времени. К счастью, автор Skulpture успел портировать этот стиль на Qt5, и именно этот порт я и опакетил.

5. Styleproject-Qt5. На мой взгляд, это самый развитый, сложный и интересный стиль для Qt4/5. Достаточно сказать, что с его помощью в KDE4 какое-то время назад были реализованы Client-Side Decorations (CSD), текстуры, имитировавшие дерево и металл, и многое другое. В моём пакете присутствует версия только версия для Qt5, хотя в теории можно было бы собрать и для Qt4 тоже (разве что в 15.3 это сделать уже сложнее). На снимке ниже показан файловый менеджер KDFM в оформлении Styleproject.

6. LightlyShaders. Как несложно догадаться, это ещё одна реализация Shape Corners, т.е. по сути клон того самого эффекта, который уже и так есть в составе Hello. Их можно держать в системе рядом, они друг друг не мещают. Разница в том, что LightlyShaders развиваются и нормально работают с Qt 5.15 (актуально, если вы захотите обновить Plasma в Leap), а Hello Shaders не развиваются и с новой Qt не собираются. Само по себе, скругление окон выглядит волшебно!

Пока это всё. В ближайших планах у меня перетащить в openSUSE программу для растягивания изображений без потерь (почти). Это Waifu2x-cpp и графический интерфейс к ней. Не переключайтесь))

Данная запись дополняет мою прошлую заметку про загрузку Linux без экранных сообщений. В этот раз я покажу, как можно организовать загрузку в обход Grub2, т.е. обойтись без стороннего загрузчика вообще. Нам понадобится система с поддержкой UEFI и примерно 5 минут времени.

Современных компьютеров без UEFI днём с огнём не сыщешь, и даже моя рабочая лошадка родом из 2011 года прекрасно поддерживает эту технологию. В Linux имеется замечательная утилита efibootmgr, управляющая загрузочными записями прямо в ПЗУ материнской платы. С помощью Efibootmgr можно добавлять, удалять и менять приоритет загрузки этих записей. Efibootmgr может добавить запись, ссылающуюся на grub2-efi — в этом случае вы увидите меню Grub вашего дистрибутива. Но можно сразу указать путь к vmlinuz и initrd, а также произвольный набор параметров ядра, и тогда Linux будет загружаться безо всякого Grub. Если у вас на ПК установлена только одна ОС, то это прекрасный способ сделать процесс загрузки более быстрым и плавным.

Для реализации этой идеи для начала нужно скопировать образы vmlinuz и initrd из /boot куда-нибудь внутрь EFI-раздела. В моём случае это директория efi/opensuse. Я переименовал эти файлы в initrd.img и vmlinuz.efi для удобства, но названия могут быть любыми. Далее следует ввести команду примерно такого вида:
efibootmgr --create --disk /dev/sda --part 1 --label "opensuse" -u --loader '\efi\opensuse\vmlinuz.efi'
"root=/dev/sda2 initrd=/efi/opensuse/initrd.img resume=/dev/sda2 splash=silent plymouth.enable=0 quiet elevator=noop logo.nologo acpi_osi=Linux acpi_backlight=vendor audit=0 rd.timeout=120 scsi_mod.use_blk_mq=1 dm_mod.use_blk_mq=1 systemd.show_status=0 rd.udev.log-priority=3 ipv6.disable=1 loglevel=3 vt.global_cursor_default=0 systemd.log_target=null systemd.journald.forward_to_console=0 systemd.default_standard_output=null systemd.default_standard_error=null init=/bin/systemd"
На что нужно обратить внимание:

• У меня EFI-раздел находится на /dev/sda1, а корневой — на /dev/sda2 (у вас может быть иначе);
• Я отключил заставку Plymouth, указал планировщик ввода/вывода Noop, отключил IPv6 и убрал вывод сообщений на экран (тут довольно много опций, с избытком);
• Нужно не забыть передать UEFI-загрузчику путь до Systemd. В openSUSE это /bin/systemd, но в других системах может быть иначе, например в Росе это /lib/systemd/systemd.

Далее нужно указать приоритет записей:

efibootmgr -o <номер 1>,<номер 2>...

Можно просто удалить все остальные записи кроме нашей:

efibootmgr -b <номер записи> -B

Дополнительно имеет смыл залезть в UEFI BIOS и включить там быструю загрузку, когда система не показывает логотип производителя, не пытается опрашивать USB-устройства и т.д.

Мой результат: от нажатия кнопки питания на системном блоке до полной прогрузки KDE Plasma проходит 25 секунд, причём половина этого времени проходит ещё до загрузки Linux.

Вот и всё. Если ваш дистрибутив всё равно загружается слишком долго, посмотрите вывод команды systemd-analyze blame. Скорее всего, какой-то сервис инициализируется слишком долго — иногда его проще отключить.

P.S.

Для отключения неопрятных сообщений в консоли, которые мигают, например, перед выключением/перезагрузкой системы, существует простой хак:
sudo systemctl disable getty@tty1.service
Теперь у вас нет консольного терминала, но зато выглядит всё просто отлично!

Принято считать, что openSUSE нынче уже не тот. Ошибок, мол, много. Но вот показательный пример.

В декабре все три используемых мною дистрибутива — Rosa, OpenMandiva и openSUSE — собрали KDE Applications 18.12. Я являюсь активным пользователем почтового клиента KMail, который использует для доступа к данным подсистему Akonadi. На данный момент результаты забега следующие:

Rosa. Akonadi работает и даёт настроить почтовый ящик Gmail. Но, при попытке скачать письма валится ошибка akonadi_imap_resource. Работать нельзя.

OpenMandriva. Akonadi не работает и даже не запускается. Кое-как я смог его запустить, но настроить почтовый ящик не вышло: всё падает и отваливается ещё на этапе авторизации в Google, причём падает всё тот же akonadi_imap_resource.

Обе системы ещё не довели до ума KDE Applications 18.12. В Росе сейчас внутреннее тестирование и QA (напомню, что релиза Rosa R11 пока не было), да и OpenMandriva 4.0 всё ещё находится в состоянии Alpha 1. Вроде как и нельзя никаких претензий предъявить.

Но в openSUSE Leap 15 репозитории с новыми версиями KDE, KF5 и приложений тоже считаются тестовыми и не до конца стабильными, однако в этой системе у меня KMail работает идеально. Никаких ошибок, программа безупречно запускается и корректно получает почту. Выходит, что не так уж и нестабильна openSUSE?

Наконец-то увидел свет новый движок портала https://kde.ru, посвященного русскоязычным пользователям KDE и проету KDE в частности. И хотя сам я уже давно KDE не пользуюсь, до сих пор многое связывает меня с этим проектом. Именно с разработки KDE начался мой путь в мир свободного ПО. Еще будучи студентом я познкомился с проетом GNU, Linux и Qt3, а уже после, в Германии – когда я начал работу в SUSE – занимался разработкой и портированием стека KDE4 на openSUSE (больше всего постов в этом блоге именно о KDE и openSUSE). Мы тогда еще сидели на svn, помните что это такое?
После SUSE я забросил проект KDE, опробовал и пересел на различные window managers. До тех пор, пока не устроился разработчиком LiMux (Kubuntu на основе собственной management-системы на основе LDAP) тут, в Мюнхене. И хотя занимался я в основном security-проектами,  было приятно вспомнить и почти весь KDE стек, который мы создавался более чем 10 лет назад.

Это очень интересный проект. Да, он большой, очень большой, и не всегда это хорошо, тем не менее он обладает самой на мой взгляд продуманной архитектурой. Программировать KDE всегда было здорово не только из-за мощи Qt и самым новейшим инструментам, используемым в проекте, но и благодаря идеям, заложенным в основу структуры стека его компонентов. Очень важным в проекте KDE всегда было сообщество людей, его разрабатывающих. Его окружило много молодых инженеров, открытых для новых, а порой даже и для откровенно сумасшедших идей. Это так освежало. Это так вписывалось в природу свободного ПО. Я никогда не забуду эти хиппи-тусовок по всей Европе, куда мы добирались по ночам и самыми сумасшедшими способами, доклады, подготавливаемые и читаемые друг другу просто ради удовольствия.

Я рад, что и в России есть люди, продолжающие разработку и продвигающие этот проект. Хочу пожелать вам, ребята, удачи. Постарайтесь сохранить эту атмосферу, сводящую с ума и увлекающую за собой. Я думаю, это самый большой стимул для разработки ПО. Увлечение процессом, удовольствие от наконец-то найденного решения, восхищение его элегантностью и простотой. Все это KDE, все это – сообщество людей, его продвигающих.

2 месяца назад нашел незначительный, но все же баг в ядре openSUSE Leap 15.0 (тогда еще это была Beta, build 174). Баг связан с лептопом Fujitsu U757 и воспроизводиться должен во всех дистрибутивах, т.к. проблема в upstream коде ядра.
Суть проблемы связана с поддержкой мультифункциональных клавиш, отвечающих за включение/выключение wifi.

Чтобы удостовериться, что kernel не обрабатывает нажатие клавиш, можно воспользоваться libinput. Это так называемый input device driver для X.org window system. С его помощью можно легко (в userland) отлавливать события, которые должны быть обработаны ядром. Так вот он показывал, что комбинация клавиш Fn+F5 при нажатии не давала никакого эффекта (F5 – это wifi-клавиша).
Тем не менее, при помощи rfkill wireless можно легко включить/отключить:

# rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
# rfkill block 0
# rfkill list
0: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no

Как оно обычно и бывавает, много времени уходит на то, чтобы собрать достаточно материала. Долгое время я не был уверен, что делаю все верно. С толку сбивало и то, что в других дистрибутивах проблема воспроизводилась один в один. Я отключил Bluetooth в BIOS, чтобы только одно устройство влияло на работу LED на корпусе лептопа. Таким образом, LED должен был загораться при включении wireless и наоборот – тухнуть при выключении. Этого не происходило…

Я решил опробовать другие ядра. Я ставил ядро из репозиториев Kernel:stable (на тот момент это было ядро 4.15.13) и Kernel:HEAD (4.16 rc7-1). Это не решило проблему.

Спустя какое-то время я нашел в сети описание этой проблемы и патч. Я отправил bugreport. Такаши, один из разработчиков в Kernel Team, сказал мне, что патч будет принят в upstream в 4.17-rc1. В стандартное Leap-ядро этот фикс сразу же не попал, т.к. баг не слишком критичен, НО Такаши пересобрал ядро с этим исправлением для SLE15 и Leap15. Leap пользователи могут установить его отсюда. Это исправление будет в Leap совсем скоро официально, в виде maintenance update.

После установки этого ядра libinput отлавливает events:

# libinput debug-events

 -event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) pressed
  event7  KEYBOARD_KEY   +3.51s  KEY_RFKILL (247) released

В качестве заключения я хочу сказать всем разработчикам: слушайте свою интуицию, не давайте никому сбить вас с толку. Полагайтесь в первую очередь на свой опыт. Не слушайте коллег, которые подгоняют логику под увиденный результат. К сожаленью, часто бывает, когда вы стоите в шаге от правильного решения, но все же решаете посоветоваться, коллеги начинают вас переубеждать. Защайтесь. Не ленитесь перепроверить все еще раз.

Удачи! Have a lot of fun =)

Прочитав заметку Кая Уве о глобальном меню в Plasma 5.13, я уже приготовился было ждать июня, когда эта версия официально выйдет, однако меня ждала хорошая новость! В новой версии openSUSE Leap 15.0, которая тоже ещё не вышла, но уже довольно давно доступна как бета-версия, уже давно всё сделано и работает! Напомню, что речь идёт о поддержке глобального меню не только для Qt-приложений, но и для GTK-программ. Это значит, что в Plasma теперь можно добиться гораздо лучшей интеграции чужеродных приложений (не основанных на Qt5) и наслаждаться отличным и единообразным видом программ, использующтх разные графические библиотеки.

Картинки покажут всё лучше слов, поэтому смотрим:

Для начала — список установленных пакетов, без которых ничего получится

Затем нужно просто добавить на рабочий стол верхнюю панель с меню приложений. В Plasma 5.12 это стало проще, так как больше не нужно идти в настройки стиля и выбирать там расположение меню. Теперь вы просто добавляете стандартную панель с меню и всё происходит автоматически. Так, к примеру выглядит у меня Gimp:

А так — Inkscape:

C Libreoffice нужно немного повозиться. Во-первых, потребуется установить VCL-плагины для интеграции пакета c GTK2 и GTK3 (увы, VCL-плагин для KF5 разрабатывается, но пока не готов). В openSUSE это пакеты libreoffice-gtk2 и libreoffice-gtk3. Затем нужно запустить любой из нужных вам компонентов, предварительно объявив переменную SAL_USE_VCLPLUGIN, например так:

SAL_USE_VCLPLUGIN=gtk oowriter

Результат:

Это просто кра-со-та! Теперь в моём любимом KDE глобальное меню почти так же универсально как и в macOS, и уже явно не хуже чем vala-appmenu, которое работает в XFCE и Mate.

UPD.

Среди Linux-блогеров, которых я читаю, есть некий Alex285, являющийся большим фанатом Gnome. Он ведёт интересный блог World of Gnome (WOGUE), откуда удобно узнавать о самых свежих новостях, связанных с Gnome. Я слежу за этой темой для того, чтобы знать, что из себя представляет современный Gnome Shell и мир GTK3-приложений. Вдруг, в какой-нибудь параллельной вселенной или мире розовых пони так случится, что Gnome станет быстрее, удобнее и надёжнее чем KDE Plasma, и тогда мне придётся перейти в стан гномолюбов — хотя бы для того, чтобы оставаться честным с самим собой. К счастью, в реальном мире  всё происходит ровно наоборот: последние версии Gnome (3.22-3.28) работают в моём VirtualBox заметно медленнее чем Plasma, а про убогий набор функций Gnome можно говорить бесконечно.

Так вот, этот самый блогер внезапно очень нервно и агрессивно отреагировал на новость про глобальное меню в KDE. Дескать, это всё не нужно и вообще, вместо меню разработчикам нужно работать над стандартным API приложений, чтобы их функции были доступны из HUD (это такая вываливающаяся сверху область уведомлений со строкой поиска). На это мне есть что сказать: я прекрасно понимаю природу гнева гномовода по поводу глобального меню в KDE. Причина здесь в зависти и бессильной злобе от того, что в конкурирующем настольном окружении хорошо работают штуки, которых в Gnome нет и в ближайшее время точно не будет. У нас есть KRunner (лучшая в своём классе реализация HUD), но самое главное — в KDE меню приложений можно настраивать. Его можно оставить в окне самого приложения, можно закинуть в кнопку в заголовке окна, можно вынести в отдельный плазмоид на панель, можно вообще отключить. Любой, кто пытался освоиться в Gnome Shell, может подтвердить убогость, бедность и малую информативность как оболочки в целом, так и отдельных GTK3-программ. Пользователь Gnome не видит какие программы у него запущены, но он также не видит функций по управлению документом, открытым в GTK3-программе до тех пор, пока не перейдёт к этой программе. Эта «слепота» приводит к тому, что в Gnome нужно тратить дополнительное время на то чтобы постоянно переключаться между обзором запущенных программ и рабочим приложением, а потом отдельно искать, где у приложения меню (и есть ли оно там вообще). Современные тенденции в развитии GTK3 приводят также к тому, что цельность таких рабочих окружений как XFCE и Mate размывается и становится эклектичной. Говоря по-русски, вместо продуманного рабочего стола вы рискуете получить помойку, щедро сдобренную фантазиями дизайнеров Gnome. По этой, и по многим другим причинам, KDE Plasma — лучший рабочий стол на сегодняшний день.

В этом посте я попытаюсь рассказать как настроить IEEE 802.1x в openSUSE. Сейчас Leap 15.0 в активной стадии бета-тестирования, поэтому возьмем её и для клиента и для сервера, чтобы убедиться, что все работает как надо, и никаких неприятных сюрпризов в финально-официальном релизе нам ждать не придется.

Если в двух словах, 802.1x это стандарт сетевой аутентификации. Работает на втором OSI уровне и определяет механизм контроля доступа к сети на основе принадлежности к порту и проверки x509-сертификатов. Доступ к сети получают только клиенты прошедшие аутентификацию. В качестве “системы, проверяющей подлинность” или просто аутентификатора я буду использовать CISCO SG300-28 28-Port Gigabit Managed Switch. Для проверки он будет обмениваться сертификатами с authentication server, который мы попытаемся развернуть на отдельной машине и который будет колдовать для нас x509 TLS-сертификаты.

Authentication server

Когда я только задумывал этот пост, я представлял это себе как “пустяковое дело на 20 минут”. Сразу же после установки я понял, что “приключение начинается”. Инсталлер разучился отключать firewall и включать OpenSSH. Фича? Аха щас… BUG! Первый баг. Попался Пытался сначала достучаться до людей в IRC, все бестолку. Три дня думал, что я что-то пропустил и искал информацию. Так ничего и не найдя, я заглянул в ML, где меня ждал успех.

Очень не приятно после установки заходить в систему и отключать firewalld и включать sshd… но на сейчашний момент это именно то, что мы имеем:

# systemctl stop firewalld
# systemctl disable firewalld
# systemctl start sshd
# systemctl enable sshd

Напомню, что мы тут просто тестируем 802.1x. На практике отключать firewall конечно же не обязательно, достаточно открыть UDP/1812 и UDP/1813 порты.

Приступаем к установке authentication server. Мы будем использовать freeradius. Последняя стабильная версия – 3.0.16 – вышла два месяца назад. В openSUSE пакет называется freeradius-server. Устанавливаем его:

> sudo zypper in freeradius-server
> rpm -qa freeradius-server
freeradius-server-3.0.16-lp150.1.3.x86_64

После установки переходим в /etc/raddb/certs. Тут все будем делать от root.

# ll /etc/raddb/certs
total 48
-rw-r----- 1 root radiusd 6155 Feb 20 06:18 Makefile
-rw-r----- 1 root radiusd 8714 Feb 20 06:18 README
-rwxr-x--- 1 root radiusd 2706 Feb 20 06:18 bootstrap
-rw-r----- 1 root radiusd 1432 Feb 20 06:18 ca.cnf
-rw-r----- 1 root radiusd 1103 Feb 20 06:18 client.cnf
-rw-r----- 1 root radiusd 1131 Feb 20 06:18 inner-server.cnf
-rw-r--r-- 1 root radiusd  166 Feb 20 06:18 passwords.mk
-rw-r----- 1 root radiusd 1125 Feb 20 06:18 server.cnf
-rw-r----- 1 root radiusd  708 Feb 20 06:18 xpextensions

Документация о том, как сгенерировать сертификаты (самый минимум) находится в файле README. 3 шага: генерация root-сертификата (ca.pem), генерация сертификата сервера (server.pem) и клиента (client.pem). Необходимые параметры нужно указать в конфиг файлах: ca.cnf, server.cnf и client.cnf соответственно.

Несмотря на то, что все кажется простым и логичным, генерация TLS/SSL сертификатов может быть оказаться достаточно запарным процессом. Особенно если вы нечасто этим занимаетесь. Дело в том, что сообщения об ошибках не всегда понятны. Давайте рассмотрим пару примеров.

Во-первых, нигде не сказано, что пароль в /etc/raddb/certs/server.cnf и /etc/raddb/mods-enabled/eap должен быть один и тот же. Вот в этом месте файла /etc/raddb/mods-enabled/eap надо быть осторожней:

        tls-config tls-common {
                private_key_password = myTEST1eap
                private_key_file = ${certdir}/server.pem

Вот так выглядит часть /etc/raddb/certs/server.cnf файла, где нужно быть чуточку внимательней:

[ req ]
prompt                  = no
distinguished_name      = certificate_authority
default_bits            = 2048
input_password          = myTEST1eap
output_password         = myTEST1eap
x509_extensions         = v3_ca

Если пароли окажутся разными, то при запуске cервера мы получим в логах вот это:

Wed Mar  7 17:08:15 2018 : Info: Debugger not attached
Wed Mar  7 17:08:15 2018 : Error: tls: Failed reading private key file "/etc/raddb/certs/server.pem"
Wed Mar  7 17:08:15 2018 : Error: tls: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt
Wed Mar  7 17:08:15 2018 : Error: tls: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal error
Wed Mar  7 17:08:15 2018 : Error: tls: error:2306A075:PKCS12 routines:PKCS12_item_decrypt_d2i:pkcs12 pbe crypt
error
Wed Mar  7 17:08:15 2018 : Error: tls: error:0907B00D:PEM routines:PEM_read_bio_PrivateKey:ASN1 lib
Wed Mar  7 17:08:15 2018 : Error: tls: error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib
Wed Mar  7 17:08:15 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 17:08:15 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 17:08:15 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Согласитесь, с ходу не ясно в чем тут может быть проблема.
Остальные пароли могут быть (должны быть) разными.

Во-вторых, можно забыть про команду:

# openssl dhparam -out dh 2048

В bootstrap скрипте она есть, но если вы решите сгенерировать сертификаты дважды и отчистите все командой

# make destroycerts

то make удалит и файл /etc/raddb/certs/dh, а при make ca.pem или make server.pem файл dh снова создан не будет. При запуске сервера это приведет к следующему сообщению в логах:

Wed Mar  7 16:18:44 2018 : Info: Debugger not attached
Wed Mar  7 16:18:44 2018 : Error: Unable to check file "/etc/raddb/certs/dh": No such file or directory
Wed Mar  7 16:18:44 2018 : Error: rlm_eap_tls: Failed initializing SSL context
Wed Mar  7 16:18:44 2018 : Error: rlm_eap (EAP): Failed to initialise rlm_eap_tls
Wed Mar  7 16:18:44 2018 : Error: /etc/raddb/mods-enabled/eap[14]: Instantiation failed for module "eap"

Обратите внимание, что в README файле написано, что удалять старые сертификаты нужно вот так:

# rm -f *.pem *.der *.csr *.crt *.key *.p12 serial* index.txt*

т.е. без dh файла. Это, пожалуй, единственная проблема, суть которой ясна из сообщения об ошибке.

И вот еще одина проблема, с которой, я надеюсь, никому не придется столкнуться:

failed to update database
TXT_DB error number 2

Она возникает по причине того, что CN (Common Name) для генерируемого сертификата такое же как и для CA-сертификата.

Последний шаг настройки RADIUS – прописываем имя, ip и secret клиента (остальное можно оставить как есть) в /etc/raddb/clients.conf. Клиент в данном случае – наш cisco-коммутатор. Шаг простой, но очень важный. Без него RADIUS не будет отвечать коммутатору. Secret тут должен быть как можно сложнее.

После того как все сертификаты созданы, для уверености их можно сверить:

# openssl verify -CAfile ca.pem client.crt client.pem
client.crt: OK
client.pem: OK

Если все в порядке, запускаем сервер, проверяем созданные им сокеты:

# systemctl start radiusd

# lsof -i :1812
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
radiusd 4811 root    7u  IPv4 179990      0t0  UDP *:radius 
radiusd 4811 root    9u  IPv6 179994      0t0  UDP *:radius 

# lsof -i :1813
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
radiusd 4811 root    8u  IPv4 179993      0t0  UDP *:radius-acct 
radiusd 4811 root   10u  IPv6 179995      0t0  UDP *:radius-acct

# tcpdump -vv -n -i eth0 -S port 1812 -l -A -X

Последняя команда может помочь при отладке. Вы видете, что именно ушло в сеть. Даже если вы подробно не знакомы с EAP, можно заметить отличие удачных попыток авторизации и не очень удачных Если по той или иной причине возникли проблемы, log radius-сервера находится в /var/log/radius/radius.log.
Если все же возникнет какая-то новая проблема, которая тут не описана, и вы начнете искать информацию в инете и найдете примеры программы radtest(1) и попытаетесь ее запусить… в openSUSE она лежит в отдельном пакете:

> rpm -qf $(which radtest) 
freeradius-server-utils-3.0.16-lp150.1.3.x86_64

Я не стал описывать ВСЕ, что мне пришлось пережить за эти пару дней… и так этот пост разбух и стал походить на статью. Возможно я напишу еще что-то о самой openssl в отдельной статье. Тема PKI очень интересная и нужная. Ее понимание требуют многие работадатели.

Но вернемся к нашему тестированию. Переходим к настройке нашего коммутатора. Пока новых жуков не обнаружено

Authenticator

Настройка аутентификатора (или “системы, проверяющей подлинность”) сводится к простому добавлению в список RADIUS-серверов только что настроенной машины. Security => RADIUS => Add:

В появившемся окне просто добавляем IP-адрес и secret, который мы указывали /etc/raddb/clients.conf на RADIUS-сервере. Secret – это фактически единственный механизм аутентификации между cisco-коммутатором и сервером проверки подлинности (RADIUS). Эта часть сети в 802.1x-схеме подразумевает достаточно доверительные отношения между хостами, т.е. остается практически не защищенной. Поэтому повторюсь – secret должен быть как можно сложнее.

Client

Переходим к последнему шагу – настройке клиента.
Да, друзья мои, в качестве клиента openSUSE сейчас использовать увы, не получится. Для тестирования 802.1x мне пришлось взять какой-то другой GNU-дистрибутив. Но обо всем по порядку.

Сначала я поставил Leap 15.0 Beta с Plasma 5.12 LTS. networkmanagement отказался создавать соединение, и я сначала подумал, что проблема в созданных мной сертификатах. Я потратил несколько дней на проверку и перегенерацию сертификатов. Я устанавливал Leap с GNOME… с Xfce… и вообще без X. Паралельно я проверял все в Tumbleweed, и это меня и сбило с толку. Там соединение тоже не работало и я подумал, что проблема на 8 OSI уровне
Через несколько дней я попробовал другие GNU-дистрибутивы и оказалось, что, используя те же самые сертификаты и конфиги, там соеднинение удается создать одной командой…

BUUUUG! Да, черт побери, и сидит он так глубоко, что ни одним NM-апплетом его не достать. Он воспроизводится и через nmcli(1):

# cat /etc/NetworkManager/system-connections/LEAP_8021x
[connection]
id=LEAP_8021x
uuid=de2f2a7c-33cc-4d92-ae3b-785575dffddc
type=ethernet
permissions=user:alex:;

[ethernet]
auto-negotiate=true
mac-address-blacklist=

[802-1x]
ca-cert=/home/alex/ca.pem
client-cert=/home/alex/client.crt
eap=tls;
identity=GNOME
private-key=/home/alex/client.pem
private-key-password=GNOME

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

# nmcli con reload

# nmcli con up LEAP_8021x

Secrets are required to access the wired network 'LEAP_8021x'
Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli
cannot ask without '--ask' option.
Error: Connection activation failed: Secrets were required, but not provided

Secret я использую и в конфиге и прописывал его и в апплетах GNOME и KDE. Не принимает ни в какую.
Пробовал испльзовать ‘–ask’, результат тот же: спашивает, вводишь пароль… снова спрашивает, снова вводишь… снова спрашивает…

# nmcli con up LEAP_8021x --ask
Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****

Secrets are required to access the wired network 'LEAP_8021x'
Identity (802-1x.identity): GNOME
Secrets are required to access the wired network 'LEAP_8021x'
Private key password (802-1x.private-key-password): *****

Я использовал и wpa_supplicant(1). Результат такой же. Он просто повисает.

Чтобы довести дело до конца я взял Kubuntu 17.10. Выбор был не случайным, т.е. это не был “первый дистрибутив, который попался под руку”. Пока я искал инфу по поводу проблем с 802.1x, я нашел этот BUG. Я не уверен, что это именно то, но повеселил меня не тот факт, что проблема в upstream’е, а то, КАК это решили в Ubuntu Ребятами из RedHat (хотя там ссылка на GNOME, а оттуда на Debian…) было предложено и другое решение. Следить за изменениями я уже не стал. Хотя разобраться до конца все же стоило бы.

В Kubuntu 17.10 просто кидаешь конфиг в /etc/NetworkManager/system-connections/802.1x и перезапускаешь сеть (без ‘–ask’), как я показал выше. Понадобятся 3 сертификата: клиентские сертификаты client.pem и client.crt (к ним надо знать secret) и root-сертификат CA.pem. При генерировании новых клиентских сертификатов нужно лишь обновить client.cnf (имя и secret) и сделать

# make client.pem

Помните, что в случае повторной генерации root-сертификата придется перенастраивать уже настроенные клиенты.

Итак, ситуация Leap 15.0 пока очень и очень не классная. BUG’ов в beta хватает. О них знают, и можете быть уверенными, друзья мои, их исправят.
Оставайтесь на светлой стороне. И да прибудет с вами удовольствие от работы с openSUSE

Самый разгар тестирования следующей major-версии openSUSE – Leap 15.0. Beta доступна уже без малого месяц. Как и обычно, качество системы зависит от нас с вами, друзья. Для тех, кто никогда не принимал участия в разработке openSUSE, но хотел бы наконец-то помочь, самое время скачать Leap 15.0, установить и погонять его по самые не балуй на своей машине (хотя бы виртуальной) или машине своего коллеги Помните, что beta-версия нестабильна и может сломаться в самом непредсказуемом месте.
О всех найденных ошибках надо сообщить нам в bugzilla.

Важно понимать, что система разрабатывается силами сообщества, и ее качество в большей мере зависит он нас с вами. Ошибается тот, кто думает, что в Нюрнберге все и так сделают как надо и даже лучше. Там ребята работают главным образом над SLE – тем, что приносит SUSE деньги. Дистрибутив openSUSE отдан сообществу: энтузиастам, дизайнерам, программистам… и простым пользователям. У нас есть права менять его как мы захотим. Более того – от нас этого ожидают. Не будем же делать вид, что это не так.

Итак, что мы имеем на сейчашний момент? На момент написания этого поста актуальным является build139. Второй и третьей официальной beta, как это было когда-то, не будет. Теперь beta меняется по принципу rolling release. Уже где-то через месяц, в апреле/мае, мы перейдем на фазу release candidate. Было бы здорово найти как можно больше и начать работать над исправлениями ДО начала этой фазы.
Так как следующий Leap получится мажором, поддерживаться он будет не 12 (в отличии от минорных релизов, привязанных к SUSE Linux Enterprise Service Packs), а 36 месяцев.

Так что же собственно тестировать? Для каждого из нас есть свои use cases. Кто-то админит самый обычный web- и mail-сервер, кто-то не может представить свою жизнь без какой-то хитроумной конфигурации Kerberos, кто-то в Leap видит исключительно desktop-систему и захочет посмотреть на сколько стабильна в ней работает Plasma 5.12 LTS. Я, к примеру, планирую протестировать sddm c PAM, а так же freeradius сервер со своим 802.1x L3-свитчем. Также будет интересно посмотреть, получится ли обновить свой Leap до нового Leap 15.0.
Кстати, в Leap 15.0 используется новый rpm из Tumbleweed – версии 4.14.1 (с целым вагоном и маленькой тялежкой SUSE-патчей). Возможно там получится что-то найти.

Я оставлю ссылку на эту таблицу. Туда вы можете добавить себя и добавить комментарий, если что-то сломано и не заработало (если заработало, тоже можете оставить комментарий). Помните только, что если что-то не заработало, и вы написали там об этом, мы будем ожидать, что вы откроете report в bugzilla, где и будет проходить дальнейшее обсуждение проблемы.
Возможно вам будет также интересно узнать о состоянии автотестирования.

Актуальное состояние пакетной базы Leap 15.0 можно посмотреть вот тут.
Там же есть ссылка на изменения, которые ожидают Leap 15.0.

Если у вас возникли вопросы, я всегда буду рад помочь вам. Оставляйте комментарии или просто пишите на alexander_naumov @openSUSE.org. Меня так же можно найти на freenode IRC-сервере. Мой ник там – anaumov. Удачи!