Features/Specific

К вам в руки попал дистрибутив ALT: что с ним делать и на что в первую очередь обращать внимание

Для умеренно грамотного пользователя Linux (например, DevOps-а) часть инструментов окружения, предоставляемого дистрибутивами и сборками ALT, покажутся вполне знакомыми, а часть — совершенно неизвестными, или похожими — но с важными отличиями.

На данной странице предполагается создать развёрнутый план лекции (или нескольких) на тему «Что нужно знать девопсу про ALT»

Родительская страница на эту тему есть, она невелика (преследует несколько иные — более общие цели) и сильно устарела. Может так случится, что содержание этой страницы заменит родительскую; но пока она в разработке.

Источники информации

• ALTLinux.org — выделенные страницы. Довольно много информации можно найти на страница-сборниках:
  • Первая_помощь
  • ответы на часто задаваемые вопросы
  • Сборка_пакетов
  • …и т. п.
• ALTLinux.org — категории. Сайт работает на движке MediaWiki и поддерживает объединение страниц по категориям. Большая часть общей информации содержится в
  • Документации
  • HOWTO
  • Справочниках
  • Руководствах
• ALTLinux.org — поиск. Сайт поддерживается сообществом, представления об «очевидности» информации у всех разные. Время от времени нужные сведения находится на странице с непредсказуемым именем. Помогает поиск по содержимому.
• docs.ALTLinux.org — Официальная документация по продуктам BaseALT и некоторым важным компонентам
• Списки рассылки сообщества ALT Lunux Team с поиском по ним (вот тут подробнее про то, что это такое)
• Группа в Telegram

Общий инструмент поиска по ресурсам ALT: http://search.altlinux.org

Документация внутри дистрибутива лежит там, где и ожидается — c, man, info и т. п.

Сообщения об ошибках и запросы на изменение

Основной инструмент взаимодействия с сообществом разработчиков — система отслеживания ошибок Bugzilla.

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

Отдельно имеет смысл почитать документы «как правильно сообщать об ошибках» (примеры есть по ссылке выше).

Это же правило относится и к другим средствам связи с разработчиками и сообществом — спискам рассылок, форуму, каналу Telegram и т. п.

Условия и способ взаимодействия со службой технической поддержки должны быть в сопроводительной документации приобретённого вами дистрибутива.

Какие бывают дистрибутивы?

Замечание. В разных сообществах термин «дистрибутив» может означать разное. В ALT Linux Team приняты такие термины

• Репозиторий — хранилище пакетов Linux, протестированное на совместимость и цельность
• Дистрибутив — комплект ПО из этого хранилища, предназначенный для развёртывания операционной системы с определёнными свойствами (рабочая станция, сервер и т. д.) в определённых условиях (аппаратные платформы различных архитектур, виртуализованные окружения и т. п.)

• Штатные дистрибутивы. Дистрибутивы линейки «Альт» разрабатываются компанией Базальт СПО в активном взаимодействии с сообществом ALT Linux Team. Список и краткое описание дистрибутивов можно посмотреть на сайте компании.
  • Дистрибутивы во многом состоят из доработанных сборок свободного программного обеспечения, сделанных сообществом и разработчиками компании, однако как составные произведения могут распространяться под несвободными лицензиями. Эти лицензии не меняют условия распространения свободных компонентов, но на дистрибутив в целом обычно накладываются дополнительные коммерческие ограничения. Более подробно см. в Лицензионной политике Базальт СПО.
  • Большая часть штатных дистрибутивов Альт доступна к скачиванию и бесплатна для физических лиц. Для юридических лиц требуется приобретение коммерческой лицензии.
  • Дистрибутив Simply Linux полностью бесплатен
  • Дистрибутив Альт Платформа имеет вариант выбора лицензии: в зависимости от того, будете ли вы с его помощью изготавливать свободное или же несвободное ПО, может потребоваться коммерческая лицензия
  • Лицензия и доступ к дистрибутиву Альт СП дополнительно ограничены требованиями сертификации ФСТЭК
• Стартовые наборы. Сборки операционных систем на базе стабильного среза репозитория.
  • Они не являются полноценными дистрибутивами
  • По ним не осуществляется техническая поддержка
  • Полностью бесплатны, распространяются под свободной лицензией (GPL)
  • Имеют множество вариантов под разные платформы
  • Стартовые наборы создаются на основе того же самого среза репозитория (ветки), что и штатные дистрибутивы.

• • В жизненном цикле репозитория они появляются первыми, почти сразу после создания стабильного среза, и по пакетам совпадают с будущими официальными дистрибутивами
• Регулярные сборки. Сборки операционных систем на базе роллинг-репозитория Sisyphus.
  • Точно так же не являются дистрибутивами, распространяются под свободной лицензией
  • Предназначены для тестирования новых технологий и пакетов во время развития Sisyphus
  • Не предназначены для эксплуатации без существенного объёма опыта (примерно в рамках всех ссылок с данной страницы ☺)

Если у вас есть время и возможность выбора, можно заглянуть сюда. Все дистрибутивы можно обновлять и дополнять пакетами из соответствующей ветки, то есть технически в рамках одного репозитория из любого дистрибутива можно сделать любой. Однако обязательства и услуги компании распространяются только на её продукты; более того — коммерческие лицензии и сертификация могут накладывать дополнительные ограничения на их использование.

Репозитории ALT

Основное хранилище программного обеспечения сообщества — репозиторий Sisyphus. Каждый пакет, прежде чем попасть в дистрибутив, должен был появиться в Сизифе.

«Сизиф»

Sisyphus — инфраструктура разработки дистрибутивов сообщества ALT, репозиторий — это только его часть. Оформление пакета для Sisyphus требует соблюдения разработанных сообществом дисциплин. Сам пакет должен быть подписан сопровождающим, пересобран сборочницей и проверен разнообразными тестами — на предмет цельности репозитория, который будет этот пакет содержать, соответствия дисциплинам, безопасности и т. п. Описание Sisyphus и принципов работы его компонентов выходит за рамки данной статьи ☺.

Пакеты в Sisyphus появляются ежедневно. С учётом Sisyphus_check, состояние репозтория всегда остаётся технически цельным, а пакеты в нём всегда отвечают всем автоматическим тестам. Таким образом Сизиф аналогичен роллинг-релизам со следующими особенностями:

• Не тестируется возможность обновления ОС с произвольного состояния Сизифа на произвольное — нельзя предсказать, в какой момент кто-то сделает apt-get dist-upgrade. Строго говоря, кто запустил dist-upgrade — тот и протестировал ☺.
• Не тестируются эксплуатационные показатели систем на базе Сизифа. Можно скачать регулярную сборку и посмотреть.
• Не тестируется логическая совместимость подсистем. Типичный случай: опять Леннарт напридумывал чего-то нового в Systemd, не все апстримы и сопровождающие адаптировали своё ПО. Снова — кто обновил, тот и тестирует ☺.
• Не гарантируется пересобираемость старых пакетов в новом окружении. Следить за этим и обновлять пакеты — и есть труд сопровождающих.

В целом, систему под управлением Сизифа можно эксплуатировать, если:

• Вы отслеживаете информационное пространство, связанное с изменениями в репозитории (в первую очередь списки рассылки Devel и Sisyphus) и аккуратно выбираете время для обновления системы
• Вы готовы самостоятельно решать проблемы, которые всё-таки могут после этого возникнуть
• Вам не нужны услуги техподдержки

«Платформы»

Официальные дистрибутивы компании и стартовые наборы выпускаются на базе т. н. веток — стабильных срезов Сизифа. Решение о создании очередной ветки принимается по согласованию с сообществом — после доведения основного ПО до более-менее актуального и работоспособного состояния и компанией «Базальт СПО», когда предыдущая платформа начинает устаревать.

Текущая платформа — p11.

Особенности стабильной платформы:

• Пакеты обновляются по запросу со стороны компании или сообщества — как правило это обновления по безопасности и сборка актуальных версий популярного ПО
• Пакеты проходят процедуру тестирования в составе штатных дистрибутивов (когда попадают туда)
• Платформа поддерживается компанией несколько лет — до момента стабилизации следующей платформы
• Для дистрибутивов разрабатывается методика обновления и/или миграции операционных систем на базе предыдущей платформы
• Компания может предоставлять дополнительные обязательства по дистрибутивам на базе платформы (в первую очередь — техническую поддержку различных уровней)

Пакеты в платформе как правило слегка устаревшие, и обновляются существенно реже. Нередко в состав платформы входит т. н. LTS-версия ПО — это снижает количество потенциальных ошибок и позволяет отчасти надеяться на поддержку со стороны «апстрима» — компании-разработчика.

Другие репозитории

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

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

Обновление ПО из репозиториев

В Сизифе и дистрибутивах ALT используется довольно редкая связка:

• Установщик пакетов (программа для установки и удаления отдельных пакетов, часто называется также «пакетный менеджер») — RPM, модифицированная версия RPM Package Manager.
• Пакетный диспетчер (программа для создания деревьев зависимостей и массовой установки / удаления / обновления пакетов на основании индексов из нескольких репозиториев) — APT, модифицированная версия Advanced Packaging Tool.

Обе этих утилиты немного отличаются по функциональностям от апстримных аналогов — для поддержки самой связки APT/RPM и для дополнительных инструментов, которые есть только в ALT, например, set-version.

• В ALT-APT не произведено слияние apt-get и apt-cache: команды, работающие с репозиториями и пакетам непосредственно, начинаются на apt-get, например, apt-get install …, а команды работающие с кешами индексов индексами — на apt-cache, например, apt-cache search …

Это означает, что на уровне установки отдельных пакетов с помощью RPM дистрибутивы ALT частично совместимы с RPM-based дистрибутивами (такими, как Fedora). Однако различия в названиях пакетов и форматах зависимостей могут привести к тому, что пакет из Fedora не установится или не заработает, поэтому такая установка не рекомендуется (см. далее относительно установки стороннего софта в дистрибутивы).

Несмотря на наличие APT (и установщика dpkg в качестве редкой опции), совместимость с Debian-based дистрибутивами не рассматривается — конфликты с имеющимися репозиториями и общей структурой дистрибутива неизбежны.

Как следствие, в настройке APT могут фигурировать только репозитории:

• со структурой ALT Linux Team Sisyphus,
• …основанные на базе одной платформы

Примеры настройки под конкретный репозиторий приведены на странице Репозитории_ALT_Linux. Там же упоминаются дополнительные репозитории, которые формируются автоматически:

• Debuginfo — репозиторий с пакетами, которые содержат отладочную информацию. Для бинарных пакетов. Не нужны для эксплуатации, но помогают при отладке.
  • Этот репозиторий генерируется полностью автоматически на этапе сборки отдельного пакета сборочницей
  •   Добавление этого репозитория не нарушает цельности дистрибутива (все зависимости должны быть удовлетворены, битых пакетов не ожидается)
• Autoimports — «пожиратель дистрибутивов». В этом репозитории находятся пакеты, которые собирают гигантские человекоподобные роботы под руководством отдельных людей. Пакеты берутся из других дистрибутивов (например, Fedora) или из собственных пакетных репозиториев больших проектов (в первую очередь CPAN).
  • Этот репозиторий обновляется автоматически: спецификация пакета из пожираемого дистрибутива превращается в spec-файл, после чего собирается пакет.
  • Сценарий и правила преобразования spec-файла задаются человеком, иногда они довольно сложные.
  •   У пакетов репозитория нет живого майнтейнера. Гарантируется только прохождение всех тестов и адаптированные к правилам ALT зависимости. Имеет смысл только в качестве относительно безопасного дополнения к основным репозиториям.
  • Если идентичный пакет появился в основном репозитории ALT, значит, какой-то участник ALT Linux Team решил его сопровождать, но оказалось, что к трудам робота прибавить нечего — роль майнтейнера свелась к тому, чтобы протестировать эксплуатацию.

Настройка репозиториев и обновление системы

Настройка делается стандартно — в файлах /etc/apt/sources.list и /etc/apt/sources.list.d/* (файлы в этом каталоге — заранее подготовленные примеры настройки для различных зеркал текущей платформы).

Большинство пользовательских инструментов (synaptic, Discover и т. п.) умеют менять отдельные строки или секции этих файлов, называя их как заблагорассудится. Чтобы не запутаться, лучше всегда смотреть, что именно они туда записали.

Несколько упростить работу поможет утилита apt-repo

Формат sources.list см. тут и в документации man sources.list.

Пример обновления системы описан на странице Обновление_ОС. Переход с одной ветки на другую — процесс более сложный и может сопровождаться некоторой дополнительной работой (см. например, Update/p11).

• В ALT-APT есть команда upgrade, но скорее всего вам её не понадобится использовать никогда, обновление системы делается с помощью apt-get dist-upgrade

Установка стороннего ПО

Если нужного продукта нет в пакетах, или его состояние вас категорически не устраивает, можно попробовать поставить его не из репозитория.

Установка сторонних RPM

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

• Преобразование SRPM-пакетов из других дистрибутивов
• Добавление hasher-репозитория

Осторожно! Вызывает привыкание! Вы рискуете стать сопровождающим этот пакет, возможно, навсегда!

Затем стоит поискать пакет в репозитории Autoimports. Возможно, его будет достаточно. Иначе придётся устанавливать RPM, собранный для другой операционной системы.

Это наиболее неприятный способ — скорее всего, в конце концов обновление ПО в системе сделается невозможным или (что в каком-то смысле даже хуже) — фрагментарным: часть пакетов будет свободно обновляться, а часть может застрять на определённой версии, требуемой установленным сторонним пакетом, и всё их дерево зависимости окажется замороженным.

Зато этот способ гарантирует более или менее цельное состояние системы. Более того, сам факт остановки обновления будет свидетельствовать о том, что надо с этим сторонним пакетом что-то делать: тоже обновлять, удалять, искать альтернативы и т. д.

Сторонние RPM-пакеты бывают, условно, двух видов:

1. Взятые непосредственно из некоторого RPM-based репозитория. Такой пакет, как правило, содержит большое количество аккуратно прописанных зависимостей на другие пакеты этого репозитория. Если удалось их удовлетворить (что случается далеко не всегда) — скорее всего он заработает.
2. Взятые с сайта апстрима. В зависимости от интеграции апстрима в разработку того или иного дистрибутива, такой пакет может содержать в себе только некоторые зависимости, ещё часть предполагается «всегда установленными», и ещё часть (в основном, библиотеки) — распространяется в составе самого пакета. Вот эта третья часть может разительно не совпадать по версиям с аналогичными пакетами системы, и даже вступать с ними в конфликт. С другой стороны, такой пакет менее чувствителен к обновлениям системы.

• Если вы видите, что апстримный RPM ставится не в стандартное место (/usr/bin, /usr/lib64 и т. д.), а в выделенный подкаталог (например, в /opt/google/chrome) — это значит, что с ним приедет достаточное количество дублирующих компонентов, но они, скорее всего, не будут конфликтовать с ПО из репозитория.
• Иногда апстрим добавляет в установочный сценарий своего пакета регистрацию нового репозитория для обновления этого пакета, и даже само обновление по расписанию с правами суперпользователя. Эти опасные операции в дистрибутивах ALT не работают. Такой пакет лучше попробовать установить с помощью EPM (см. ниже).

Устанавливать rpm-пакет лучше не командой rpm, а непосредственно apt-get install url-или-файл.rpm — APT в ALT это позволяет. Такая команда заодно подсчитает дерево зависимостей, и если оно несовместимо с основным репозиторием, не даст совершить непоправимое (а если сторонний пакет вместе с зависимостями установится — велик шанс, что и заработает).

Домен-специфичная установка и сборка

Многие современные языки программирования используют собственную систему пакетирования, распространения и установки ПО. В первую очередь это интерпретируемые ЯП — Python, Ruby, JS и т. п.: пакет достаточно скачать из хранилища и развернуть в определённом каталоге, этим обычно занимается соответствующий инструмент для работы с конкретным хранилищем (Pip и Conda для Python, Gem для Ruby, NodeJS и его аналоги для JS и т. д.).

Таких пакетов немало и в репозиториях ALT, но туда они попадают после переупаковки конкретным сопровождающим для конкретной цели (в первую очередь — как сборочные зависимости на другие пакеты). Поэтому практика использования софта, написанного на этих языках, включает в себя создание отдельного каталога (т. н. «виртуального» окружения; причём слово «виртуальный» не означает ровно ничего, это и правда просто отдельный каталог), и установку туда всех необходимых пакетов.

Для Pythоn рекомендуется использовать Pipx — надстройку над Pip.

Примерно так же устроены экосистемы некоторых современных компилируемых языков программирования — Rust, Go, Zig и др. В системе должен присутствовать «тулчейн» (компилятор и стандартная библиотека), а приложение собирается из целиком скачанных исходных модулей с помощью инструмента работы с хранилищем этих модулей; для Rust это cargo.

Недостатки домен-специфичной установки:

• Установленное ПО как правило предполагает наличие тех или иных компонентов системы; есть они или нет, и совместимы ли они с ALT — неизвестно.
• Установленное ПО никак не отслеживает обновления системы. Если оно использует системные библиотеки, со временем возникнут существенные расхождения.
• Если в процессе установки происходила сборка — вы первый (и, возможно, последний) человек, который тестирует работоспособность её результатов.

EPM

Epm (Etersoft Package Manager) — инструмент, в числе функций которого есть установка пакетов, предназначенных для другой ОС на базе Linux (и RPM, и DEB, и некоторых других). Эта задача решается путём распаковки пакета как архива и переупаковки его в RPM-пакет, совместимый с ALT. В большинстве случаев при этом преобразовании автоматически редактируется список зависимостей, подменяются или удаляются установочные сценарии, вносятся, возможно, ещё более жестокие правки (вплоть до редактирования бинарного файла, если иначе его невозможно заставить работать).

С одной стороны, никакой гарантии работоспособности полученного вторичного пакета не даётся. С другой стороны, вокруг EPM есть достаточно активное сообщество, и наиболее востребованные задачи и изменения вносятся в соответствующие профили довольно быстро.

Посмотреть список поддерживаемых пакетов можно командой epm play

Изолированные сборки (flatpak, snap, appimage)

В дистрибутивах ALT поддерживаются основные инструменты распространения приложений в виде изолированных сборок

• Appimage — самый простой из трёх, достаточно скачать приложение и обеспечить возможность его запуска
• Flatpak — более сложный, требующий развёртывания инфраструктуры хранения и запуска приложений; поддерживается, например, в Discover
• Snap — самый сложный инструмент с фокусом на безопасность, требует запуска и настройки службы SnapD

Инсталляторы vs «скачать и распаковать»

По возможности избегайте ПО, распространяемого в виде «инсталляторов». В лучшем случае это просто самораспаковывающийся архив, в худшем — инсталлятор потребует прав суперпользователя и модифицирует систему самым непредсказуемым образом. Довольно часто такие модификации и другие действия инсталлятора основаны на свойствах одной конкретной версии дистрибутива (например, Ubuntu), и не совместимы с остальными.

Вариант «скачать и распаковать» существенно надёжнее: скорее всего, ПО, рассчитанное на такую установку, заработает из любого каталога и не будет требовать каких-то особенных свойств от системы. Вполне вероятно, что таким образом не удастся установить одну копию продукта для всех пользователей (в тот же /opt): нередко авторы имеют обыкновение использовать для записи каталог установки.

Если установленное таки образом ПО имеет зависимости на какие-то дополнительные компоненты системы, вы узнаете об этом только попытавшись запустить его.

Контейнеры

Если у вас уже есть готовое решение под определённую ОС, и нет необходимости её избегать, проще всего развернуть Docker-контейнер

Настройка системы

Для дистрибутивов ALT в целом верно общее правило всех Linux-дистибутивов:

Чем выше уровень настройки, тем сильнее она отличается от других Linux-систем

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

Частичный /etc/sysconfig

Пращур дистрибутивов ALT — Mandrake_7.0_RE был основан на тогдашнем Red Hat, и имел особенные для этого семейства инструменты запуска и настройки. В частности, система запуска стартовых сценариев и другая shell-обвязка использовали единый формат конфигурационных файлов — в виде части shell-сценария с определением переменных. Такие файлы складывались в каталог /etc/sysconfig и служили как бы «профилем системы». Несмотря на то, что при переходе на systemd многие сервисы перестали запускать shell-сценарии вообще, в этом каталоге всё ещё хранится довольно много актуальных параметров системы. Как правило, параметры в sysconfig имеют более высокий приоритет и не отражены в man-страницах, потому что являются дополнением к стандартной настройке.

Например, в /etc/sysconfig/rpcbind по умолчанию содержится строка CONTROL_ARGS="-l". Это приводит к запуску rpcbind с управляющим сокетом только на loopback-интерфейсе — такая система не может работать NFS-сервером!

Control

Control — инструмент для пакетного изменения настроек различных компонентов системы. Например, для того, чтобы дать произвольному пользователю права на монтирование файловых систем посредством Fuse, нужно:

• Добавить бит запуска для всех пользователей утилитам fusermount и fusermount3
• Выставить права доступа 0666 к устройству /dev/fuse (а для верности — изменить соответствующее правило udev и пересканировать это устройство)

Каждая из этих операций в отдельности имеет мало смысла. Поэтому в состав пакета fuse входит соответствующая политика control (файл /etc/control.d/facilities/fusermount), которая позволяет выполнить такое изменение одной командой control fusermount public.

Имеет смысл поизучать, что умеют модули control в установленной системе, а после её обновления / дополнения — не появилось ли там новых пакетных настроек.

Этот проект развивается совместно с сообществом Openwall Linux.

Alterator и инсталлятор

Процесс установки дистрибутива ALT подробно описан в его документации (вот, например, описание установки ALT Workstation).

Большая часть пользовательского интерфейса инсталлятора — это оформленный в виде Wizard-а последовательной запуск различных модулей «Центра управления системой» — в сообществе он имеет название Alterator.

Alterator имеет два интерфейса — приложение, собственно Центр управления системой, и веб-интерфейс. Часть модулей доступна в одном интерфейсе, часть — в другом (это зависит от использованного фронтенда), но в целом веб-интерфейс поддерживает почти все модули. См. таблицу модулей и их описания.

Альтератор — инструмент высокоуровневой настройки системы. Разумеется, он вносит изменения в конфигурационные файлы, но значительную часть параметров хранит в собственной базе. Редактирование config-файлов на этих параметрах не отражается, и в лучшем случае Альтератор перезапишет их при следующей активации, а худшем — откажется разбирать модифицированный файл вовсе.

Внимание: Настраивайте некоторую подсистему либо только с помощью Альтератора, либо только вручную!

Система хранения паролей TCB

(Разумеется, хранятся не пароли, а их хеши!). Классическая модель хранения хешей от пользовательских паролей и иной важной информации в файле /etc/shadow имеет существенный недостаток: неоправданное совмещение критичных данных в одном файле. В самом деле: если пользователь хочет изменить себе пароль, ему не нужны никакие другие строки из этого файла, кроме той, что содержит его собственные учётные данные. Shadow доступен на чтение и запись только суперпользователю, следовательно, программы и модули, работающие с shadow, должны получать его права. Это создаёт разнообразные векторы атак — можно, например, исхитриться получить дамп памяти запущенной программы passwd — в нём будут хеши всех паролей, включая root.

А между тем достаточно модифицировать эту логику так, чтобы у каждого пользователя был собственный файл shadow. Тогда для доступа к нему вообще не понадобится прав root — а защита такого файла от доступа со стороны других пользователей может быть реализована с помощью трюка SETGID directory traversal. Такой вариант был разработан сообществом Openwall Linux как часть проекта TCB (от «Trusted Computing Base»).

Если ваш или какой-то иной софт намерен обходить стандартное POSIX API и читать/писать прямо в файл /etc/shadow, в дистрибутивах ALT это не возымеет эффекта.

Не такая уж и важная особенность, но нужно упомянуть ещё один проект OWL — passwdqc. Это библиотека проверки надёжности пароля (по умолчанию задействованная в дистрибутивах ALT) и сопутствующие ей утилиты. Документацию можно почитать с помощью man passwdqc.conf, а здесь мы вспомним ещё утилиту pwqgen, которая генерирует криптостойкие и запоминающиеся парольные словосочетания (пассфразы). Подробный анализ стойкости оставим специалистам, а сами сошлёмся на популярный веб-комикс XKCD № 936:

Статическая настройка сети

Пункт, в котором все дистрибутивы отличаются друг от друга — это статическая настройка сетевых параметров. Дело в том, что какая-то настройка сети требовалась UNIX-подобным системам задолго до зарождения дистрибутивов Linux как явления, и всё это время настройки были весьма простыми: задать адрес сетевого интерфейса, задать маршрут по умолчанию и указать DNS-сервер. Более сложные задачи были делом специализированных сетевых устройств и обслуживались специализированным же ПО. Вполне можно было обойтись одним shell-сценарием настройки, в котором администратор задавал IP-адреса и имена интерфейсов.

В начале 2000-х стало понятно, что Linux-система может решать весьма сложные сетевые задачи, и «скрипты для настройки сети» стали активно развиваться и усложняться, продолжая оставаться именно что набором shell-сценариев и конфигурационных файлов к ним.

В сообществе ALT Linux Team была разработана, пожалуй, самая «прозрачная» из таких систем настройки — EtcNet. По сути это тот же склад скриптов с конфигами, но концептуально эти конфиги по возможности как можно ближе воссоздают синтаксис команд настройки сети, которые привык давать сетевой администратор, настраивая сеть вручную. Грубо говоря сетевые устройства обозначаются каталогами, команды, их настраивающие — подкаталогами, подкоманды — файлами, а ключи этих подкоманд и их значения — содержимым файлов.

Например, команде

ip address add dev eth0 10.0.0.20/24

отвечает файл /etc/net/ifaces/eth0/ipv4address с содержимым

10.0.0.20/24

Такая концепция оказалась довольно удачной: EtcNet развивается до сих пор, используется как система настройки сети по умолчанию для серверных дистрибутивов ALT; настройка сети через Альтератор в качестве бэкенда тоже использует EtcNet.

Главный недостаток всех подобных инструментов — их статичность. Сеть настраивается один раз системным администратором, а затем работает без изменений неопределённо долгое время. WiFi, VPN и некоторые другие способы эксплуатации сети требуют, во-первых, участия «обычного пользователя» в процессе настройки, во-вторых, могут требовать несколько раз перенастраивать сеть в течение одного сеанса работы, и как следствие, в-третьих, касаются не только собственно настройки сети, а работы многих системных служб, начиная от загрузки модулей и создания новых сетевых устройств и заканчивая работой со «связкой ключей», в которой пользователь хранит пароли.

Потребность в динамической перенастройке и взаимодействии с другими сервисами породили несколько инструментов сетевой настройки «нового поколения»: например, Netplan и Systemd-networkd для серверных конфигураций, NetworkManager — для десктопных.

Эти инструменты поддерживаются дистрибутивами ALT; следует убедиться, что они не конфликтуют друг с другом. Возможно, хорошее решение — удалить все такие инструменты, кроме одного, который в одиночку будет решать ваши сетевые задачи.

Сервисы в chroot

Ещё одна инициатива OWL — запуск недостаточно защищённых подсистем в выделенном Chroot. Разумеется, процессы этой подсистемы запускаются не с правами root. Если необходимо, для этого на исходный код подсистемы накладывается патч: процесс запускается от root-а, открывает нужные файлы, выполняет системный вызов chroot() и сбрасывает себе привилегии до уровня специального системного пользователя, выделенного для этой подсистемы.

Дополнительную информации можно найти тут и по ссылкам с этой страницы.

Ядра

Коротко:

• В системе можно иметь несколько установленных ядер (выбор происходит при включении компьютера)
• Ядра в дистрибутивах ALT не обновляются и не удаляются автоматически, нужно использовать утилиту update-kernel или соответствующий Alterator-модуль
• Ядра в репозитории бывают нескольких типов (flavours):
  • Базовая (новая) номенклатура: тип ядра — это мажорная часть версии. Например, пакет имеет имя kernel-image-6.13 и версию+релиз 6.13.0-alt1, полное имя пакета с версией — kernel-image-6.13-6.13.0-alt1. В репозитории есть одно стабильное и два longterm ядра (см. классификацию на http://kernel.org) как минимум
  • Целевая (старая) номенклатура: тип ядра — ключевое слово, указывающее на особенные свойства / назначение (например, ядро с поддержкой реального времени kernel-image-rt)

Просмотр доступных в репозитории ядер:

update-kernel -l

Обновление текущего ядра на более новое того же типа:

update-kernel

Обновление текущего ядра на новое другого типа:

update-kernel -t 6.12

Удаление всех старых ядер текущего типа:

remove-old-kernels

Подробнее см:

* О ядрах в ALT Linux
* Разновидности ядер в ALT Linux
* Обновление ядра

Про сборку ПО под ALT

Это весьма обширная тема. Даже если исходить из того, что вы уже обладаете опытом разработки ПО под Linux, остаётся какое-то количество ALT-специфики, которая местами сильно облегчает, а местами осложняет процесс.

Сборка «на месте»

Стандартная процедура сборки ПО под ALT в целом такая же, как и под другие Linux-дистрибутивы. Образно говоря, вы устанавливаете инструменты сборки, devel-версии библиотек, произносите «крибле! крабле! бумс!./configure; make; make install» — и… конечно же, make install без прав администратора не срабатывает.

• Смотрите, как именно называются соответствующие инструменты и devel-версии библиотеки, в именовании всегда могут быть отличия.
• Никогда не запускайте сборку с правами root! Собирайте всё от обычного пользователя, и только установку делайте от root-а, если этого нельзя избежать
  • Честно говоря, нам кажется, что это общее правило разработки, но приходится отдельно это упоминать, с учётом популярности комады sudo в методичках по Linux
• Будьте готовы к тому, что система, в которой вы активно занимаетесь сборкой различных проектов, стремительно наполнится программными инструментами, в том числе конфликтующими друг с другом (различные версии компиляторов, альтернативные реализации библиотек и прочее)

Изолированная сборка в hasher

Cборочное окружение можно организовать при помощи ещё одной особенности ALT: инструмента изолированной сборки Hasher.

Подробно см. на упомянутой странице и по ссылкам оттуда.

Hasher

• Позволяет развернуть сборочное окружение на базе и для заданного репозитория / платформы (Например, Sisyphus или p11), независимо от того, на каком репозитории в данный момент основана ваша операционная система, и как давно вы её обновляли
• Позволяет манипулировать объёмом доступных сборочной среде возможностей. Например, по умолчанию отключена сеть и содержимое /proc / /sys — сборочное окружение не сможет получить сведения о хостовой ОС
  • Таким образом, если репозиторий не изменился, сборка окажется воспроизводимой (с точностью до времени)
• Позволяет (ограничено) запускать команды суперпользователя с имитацией прав root, но без получения соответствующих привилегий (с помощью fakeroot)
• Можно использовать в качестве легковесного изолированного контейнера для запуска недоверенных приложений (поддерживается проброс X-протокола для графических клиентов Xorg).

Сборка RPM-пакета

Следующий шаг в освоении сборки под ALT — сборка RPM-пакета, соответствующего дисциплине формирования пакета в ALT Linux Team.

• Сборник руководств и статей о сборке пакетов
• Более подробно о специфике написания spec-файлов: Spec и Особенности_написания_спек_файлов_в_ALT_Linux
  • Spec-файлы в ALT как правило существенно короче и читаемее, чем в других RPM-based дистрибутивах — за счёт большого количества удобных умолчаний и специализированных макросов, а также предопределённых действий при установке/удалении (которые тоже не надо включать в спек)

Более или менее удобная практика:

1. Развернуть hasher-окружение с разрешением сети и `/proc` / `/sys`
2. Понаставить туда всевозможных devel-пакетов без разбора с помощью `hsh-install`
3. Сделать `hsh-shell` — запустить в это окружении интерактивный шелл
4. Скачать исходник, попытаться его собрать
   • Если не хватает каких-то сборочных зависимостей — выйти из hasher, доставить их и войти обратно и повторить сборку
5. После успешной сборки в каталоге исходников написать spec-файл и добиться сборки пакета, следя за тем, чтобы все устанавливаемые файлы, а также документация, попали в пакет
6. После успешной сборки пакета внутри hasher стоит запустить Buildreq. Эта утилита модифицирует написанный вами spec, добавив туда актуальные сборочные зависимости. Результаты работы buildreq имеет смысл отредактировать — иногда он добавляет лишнее.
7. В результате в каталоге RPM/SRPMS окажется .src.rpm файл, пригодный к повторной сборке
8. Выйдите из hasher (только сейчас!) и заберите полученный .src.rpm из каталога <путь-к-каталогу-hasher>/chroot/usr/src/RPM/SRPMS

Сопровождение пакета в Сизифе

Если вы научились собирать пакеты и/или исправлять уже существующие (и, возможно, даже завели репозиторий собственных пакетов), довольно непрактично останавливаться на этом. Вам прямая дорога в ALT Linux Team! После вступления в команду ваши пакеты и правки будут попадать в Сизиф и дистрибутивы, всю инфраструктуру поддержки сборки, включая проверку совместимости Sisyphus check, возьмёт на себя сборочница. Пакеты в Сизифе проще сопровождать, а их доступность и интеграционные свойства существенно выше, чем в собственном репозитории — при условии, конечно, что лицензия на исходный текст ПО и ваш пакет свободная.

Более удобную, чем по старинке, SRPM-ом, сборку пакета можно организовать при помощи gear:

• Сборка сразу из git-репозиторя
• Поддержка нескольких стилей сопровождения пакета
• Автоматическое развёртывание сборочного окружения со всеми зависимостями
• Приближенная к «жизненной правде» среда: например, последний пункт из предыдущего раздела можно дополнить двумя

такими:

• • Создать gear-совместимый репозиторий с помощью gear-srpmimport (или обновить имеющийся с помощью gear-update)
  • Выполнить тестовыю сборку с нуля с помощью gear
• После подписывания сборочного тега и публикации полученного репозитория на git.altlinux.org пакет собирается в Сизиф одной командой ssh gear.alt build <пакет> <тег>

Остальное

Данная статья, по всей видимости, не является полной заменой Features, так что стоит поискать продолжение там.