Альт Платформа 10.1

Документация

Руководство пользователя

Редакция март, 2025

Аннотация

Названия компаний и продуктов, встречающихся в руководстве, могут являться торговыми знаками соответствующих компаний.

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

⁠Глава 1. Что такое Альт Платформа?

В этой главе рассматривается что такое Linux и Альт Платформа.

⁠1.1. Что такое Альт Платформа

Альт Платформа (ALT Platform) — технологический комплекс для сборки прикладного программного обеспечения и выпуска продуктов ООО «Базальт СПО».

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

Альт Платформа позволяет обеспечить интеграцию и поддержку программных продуктов различных разработчиков в окружение операционных систем «Альт».

Состав Альт Платформа:

дистрибутив ALT Platform Builder, содержащий следующие компоненты:

hasher — средство воспроизводимой сборки пакетов в изолированном окружении;

gear — инструмент для хранения исходных текстов в git и извлечения заданной версии;

mkimage — набор утилит для создания образов (в основном ISO);

mkimage-profiles — метапрофиль со множеством готовых «кирпичиков» и конфигураций образов;

alternator-mirror — модуль центра управления системой для зеркалирования репозиториев;

репозиторий «Альт Платформа».

⁠1.2. Что такое системы Альт

⁠1.2.1. ALT Linux Team

Команда ALT Linux (http://www.altlinux.org/ALT_Linux_Team) — это интернациональное сообщество, насчитывающее более 200 разработчиков свободного программного обеспечения.

⁠1.2.2. Сизиф

Sisyphus (https://packages.altlinux.org) — наш ежедневно обновляемый банк программ (часто называемый репозиторий). Поддерживаемая ALT Linux Team целостность Sisyphus, оригинальная технология сборки программ, утилита apt-get и её графическая оболочка synaptic позволяют пользователям легко обновлять свои системы и быть в курсе актуальных новостей мира свободных программ.

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

Ежедневно изменяющийся репозиторий содержит самое новое программное обеспечение со всеми его преимуществами и недостатками (иногда ещё неизвестными). Поэтому, перед обновлением вашей системы из Sisyphus, мы советуем взвесить преимущества новых возможностей, реализованных в последних версиях программ, и вероятность возникновения неожиданностей в работе с ними (http://www.altlinux.org/Sisyphus_changes).

Разработка Sisyphus полностью доступна. У нас нет секретных изменений кода и закрытого тестирования с подписками о неразглашении. То, что мы сделали сегодня, завтра вы найдёте в сети. По сравнению с другими аналогичными банками программ (Debian unstable, Mandriva Cooker, PLD, Fedora), в Sisyphus есть немало самобытного. Особое внимание уделяется защите системы, локализации на русский язык, полноте и корректности зависимостей.

Название Sisyphus (Сизиф) заимствовано из греческой мифологии. С кропотливым Сизифом, непрерывно закатывающим в гору камни, команду ALT Linux Team объединяет постоянная работа над усовершенствованием технологий, заложенных в репозиторий.

Sisyphus, в первую очередь, — открытая лаборатория решений. Если вам это интересно, если вы хотите дополнить Sisyphus новыми решениями, если вы считаете, что можете собрать какую-то программу лучше — присоединяйтесь к проекту ALT Linux Team (http://www.altlinux.org/Join).

⁠1.2.3. Что такое десятая платформа

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

Десятая платформа (p10) была создана в июле 2021 года и её поддержка продлится до июля 2025.

⁠Глава 2. Установка дистрибутива

В этой главе рассматривается процесс установки дистрибутива ALT Platform Builder.

⁠2.1. Создание загрузочного flash-диска

Предупреждение

Запись образа дистрибутива на flash-диск приведёт к изменению таблицы разделов на носителе, таким образом, если flash-диск выполнил функцию загрузочного\установочного устройства и требуется вернуть ему функцию переносного накопителя данных, то необходимо удалить все имеющиеся разделы на flash-диске и создать нужное их количество заново.

Для восстановления совместимости flash-диска с операционными системами семейства Windows может понадобиться также пересоздание таблицы разделов (например, при помощи parted). Нужно удалить таблицу GPT и создать таблицу типа msdos. Кроме того, должен быть только один раздел с FAT или NTFS.

Для создания загрузочного flash-диска понадобится файл ISO-образа установочного диска с дистрибутивом. ISO-образы установочных дисков являются гибридными (Hybrid ISO/IMG), что позволяет записать их на flash-накопитель.

⁠2.1.1. В операционной системе Windows

Для создания загрузочного flash-диска под операционной системой MS Windows используйте специальные программы: ALT Media Writer, Win32 Disk Imager, HDD Raw Copy Tool и другие.

ALT Media Writer — это инструмент, который помогает записывать образы ALT на портативные накопители, такие как flash-диски. Он может автоматически загружать образы из интернета и записывать их. Для записи образа на flash-диск необходимо:

скачать и установить ALT Media Writer;

скачать образ дистрибутива;

вставить flash-диск в USB-разъем (размер flash-диска должен быть не меньше размера скачанного образа диска);

запустить ALT Media Writer;

выбрать пункт Другой образ и в появившимся окне выбрать ISO-образ дистрибутива;

выбрать устройство (flash-диск);

нажать кнопку Записать на диск:

Инструкция для записи образа в программе Win32 Disk Imager:

скачать и установить программу Win32 Disk Imager;

скачать образ дистрибутива;

вставить flash-диск в USB-разъем (размер flash-диска должен быть не меньше размера скачанного образа диска);

запустить Win32 Disk Imager;

в появившимся окне выбрать ISO-образ дистрибутива, выбрать устройство (flash-диск):

нажать кнопку Write для записи образа на flash-диск.

Для записи образа на flash-диск подойдёт и утилита HDD Raw Copy Tool. На первом шаге нужно выбрать файл с образом диска:

На втором шаге нужно выбрать flash-диск, на который будет записан образ:

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

После проверки правильности выбранных параметров и нажатия кнопки Continue можно приступать к записи, нажав кнопку START. По успешному завершению записи окно с индикацией процесса записи закроется, после чего можно закрыть и окно самой программы.

⁠2.1.2. В операционной системе Linux

Для записи образа на flash-диск можно воспользоваться одной из программ с графическим интерфейсом:

ALT Media Writer (altmediawriter):

ALT Media Writer может автоматически загружать образы из интернета и записывать их, при необходимости извлекая сжатые образы (img.xz).

SUSE Studio Imagewriter (imagewriter):

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

Предупреждение

Не добавляйте номер раздела, образ пишется на flash-диск с самого начала!

Для записи установочного образа можно воспользоваться утилитой командной строки dd:

# dd oflag=direct if=<файл-образа.iso> of=/dev/sdX bs=1M status=progress;sync

где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.

Для удобства показа прогресса записи можно установить пакет pv и использовать команду:

# pv <файл-образа.iso> | dd oflag=direct of=/dev/sdX bs=1M;sync

где <файл-образа.iso> — образ диска ISO, а /dev/sdX — устройство, соответствующее flash-диску.

Просмотреть список доступных устройств можно командой lsblk или (если такой команды нет) blkid.

Например, так можно определить имя flash-диска:

$ lsblk | grep disk
sda      8:0    0 931,5G  0 disk
sdb      8:16   0 931,5G  0 disk
sdc      8:32   1   7,4G  0 disk

flash-диск имеет имя устройства sdc.

Затем записать:

# dd oflag=direct if=/home/iso/alt-platform-builder-11.0-x86_64.iso of=/dev/sdc bs=1M status=progress; sync

или, например, так:

# pv /home/iso/alt-platform-builder-11.0-x86_64.iso | dd oflag=direct of=/dev/sdc bs=1M;sync
dd: warning: partial read (524288 bytes); suggest iflag=fullblock
3GiB 0:10:28 [4,61MiB/s] [===================================>  ] 72% ETA 0:04:07

Предупреждение

Не извлекайте flash-диск, пока образ не запишется до конца! Определить финал процесса можно по прекращению моргания индикатора flash-диска либо посредством виджета Безопасное извлечение съемных устройств.

⁠2.1.3. В операционной системе OS X

В операционной системе OS X для создания загрузочного flash-диска можно использовать команду:

sudo dd if=alt-platform-builder-11.0-x86_64.iso of=/dev/rdiskX bs=10M
sync

где alt-platform-builder-11.0-x86_64.iso — образ диска ISO, а /dev/rdiskX — flash-диск.

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

diskutil list

Предупреждение

Будьте внимательны при указании имени usb-устройства — запись образа по ошибке на свой жёсткий диск приведёт к почти гарантированной потере данных на нём!

⁠2.1.4. Проверка целостности записанного образа

Для проверки целостности записанного образа необходимо выполнить следующие шаги:

определить длину образа в байтах:

$ du -b alt-platform-builder-1f1.0-x86_64.iso | cut -f1
2228344832

посчитать контрольную сумму образа (или просмотреть контрольную сумму образа из файла MD5SUM на сервере FTP):

$ md5sum alt-platform-builder-11.0-x86_64.iso
1044e5aa9ecf6ee5a87fb990c8123af8  alt-platform-builder-11.0-x86_64.iso

подсчитать контрольную сумму записанного образа на DVD или USB Flash (выполняется под правами пользователя root):

# head -c 2228344832 /dev/sdd | md5sum
1044e5aa9ecf6ee5a87fb990c8123af8

где размер после -c — вывод в п.1, а /dev/sdd — устройство DVD или USB Flash, на которое производилась запись.

⁠2.2. Сохранение данных и меры предосторожности

Если необходимо установить ОС Альт Платформа и при этом сохранить уже установленную на компьютере операционную систему (например, другую версию GNU/Linux или Microsoft Windows), то нужно обязательно позаботиться о подготовке компьютера к установке второй системы и о сохранении ценных для вас данных.

Если у вас нет загрузочного диска для уже установленной системы, создайте его. В случае прерванной установки ОС Альт Платформа или неправильной настройки загрузчика, вы можете потерять возможность загрузиться в вашу предыдущую ОС.

Если на диске, выбранном для установки ОС Альт Платформа, не осталось свободного раздела, то программа установки должна будет изменить размер существующего раздела. От этой операции могут пострадать ваши данные, поэтому предварительно надо сделать следующие действия:

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

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

Предупреждение

Полной гарантией от проблем, связанных с потерей данных, является резервное копирование!

⁠2.3. Начало установки: загрузка системы

Примечание

В данной инструкции рассмотрена установка системы в режиме UEFI. Особенности установки в режиме legacy отображены в примечаниях.

⁠2.3.1. Загрузка с установочного носителя

Для того чтобы начать установку ОС Альт Платформа, достаточно загрузиться с носителя, на котором записан дистрибутив.

Примечание

Предварительно следует включить в BIOS опцию загрузки с оптического привода или с USB-устройства.

В большинстве случаев указание способа входа в BIOS отображается на вашем мониторе непосредственно после включения компьютера. Способ входа в меню BIOS и информация о расположении настроек определяется производителем используемого оборудования. За информацией можно обратиться к документации на ваше оборудование.

Загрузка с установочного диска или специально подготовленного USB-flash-накопителя начинается с меню, в котором перечислено несколько вариантов загрузки:

Install ALT Platform Builder 11.0 — установка операционной системы;

VNC install ALT Platform Builder 11.0 (edit to set password and connect here) — установка по VNC с соединением в сторону устанавливаемой машины. Параметры установки по VNC передаются как параметры ядра. Нажатие клавиши E позволяет задать пароль (по умолчанию — VNCPWD):

Change serial console — позволяет выбрать последовательный порт для консольного подключения (например, COM1/ttyS0):

и задать скорость передачи данных:

Memory Test (may not work with Secure Boot) — проверка целостности оперативной памяти. Процесс диагностики заключается в проведении нескольких этапов тестирования каждого отдельного модуля ОЗУ (данный процесс будет выполняться бесконечно, пока его не остановят, необходимо дождаться окончания хотя бы одного цикла проверки).

UEFI Firmware Settings — позволяет получить доступ к настройкам UEFI.

Примечание

Начальный загрузчик в режиме Legacy:

Примечание

Мышь на этом этапе установки не поддерживается. Для выбора опций установки и различных вариантов необходимо использовать клавиатуру.

Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, то редактировать их нет необходимости.

Чтобы начать процесс установки, нужно клавишами перемещения курсора вверх и вниз выбрать пункт меню Install ALT Platform Builder и нажать Enter.

Начальный этап установки не требует вмешательства пользователя: происходит автоматическое определение оборудования и запуск компонентов программы установки. Сообщения о происходящем на данном этапе можно просмотреть, нажав клавишу ESC.

Примечание

В начальном загрузчике установлено небольшое время ожидания: если в этот момент не предпринимать никаких действий, то будет загружена та система, которая уже установлена на жестком диске. Если вы пропустили нужный момент, перезагрузите компьютер и вовремя выберите пункт Install ALT Platform Builder.

⁠2.4. Последовательность установки

До того как будет произведена установка базовой системы на жёсткий диск, программа установки работает с образом системы, загруженным в оперативную память компьютера.

Если инициализация оборудования завершилась успешно, будет запущен графический интерфейс программы-установщика. Процесс установки разделён на шаги. Каждый шаг посвящён настройке или установке определённого свойства системы. Шаги нужно проходить последовательно. Переход к следующему шагу происходит по нажатию кнопки Далее. При помощи кнопки Назад, при необходимости, можно вернуться к уже пройденному шагу и изменить настройки. Однако возможность перехода к предыдущему шагу ограничена теми шагами, в которых нет зависимости от данных, введённых ранее.

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

Примечание

Совершенно безопасно выполнить отмену установки только до шага Подготовка диска, поскольку до этого момента не производится никаких изменений на жёстком диске. Если прервать установку между шагами Подготовка диска и Установка загрузчика, существует вероятность, что после этого с жёсткого диска не сможет загрузиться ни одна из установленных систем (если такие имеются).

Технические сведения о ходе установки можно посмотреть, нажав Ctrl+Alt+F1, вернуться к программе установки — Ctrl+Alt+F7. По нажатию Ctrl+Alt+F2 откроется отладочная виртуальная консоль.

Каждый шаг сопровождается краткой справкой, которую можно вызвать, щёлкнув кнопку Справка или нажав клавишу F1.

Нажатие на кнопку Последовательность установки позволяет показать/скрыть панель со списком шагов установки:

Во время установки системы выполняются следующие шаги:

Язык;

Лицензионное соглашение;

Дата и время;

Подготовка диска;

Установка системы;

Сохранение настроек;

Установка загрузчика;

Настройка сети;

Администратор системы;

Системный пользователь;

Установка пароля на шифрованные разделы;

Завершение установки.

⁠2.5. Язык

Установка ALT Platform Builder начинается с выбора основного языка — языка интерфейса программы установки и устанавливаемой системы. В списке, помимо доступных языков региона (выбранного на этапе начальной загрузки), указан и английский язык.

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

клавиши Alt и Shift одновременно;

клавиша CapsLock;

клавиши Control и Shift одновременно;

клавиша Control;

клавиша Alt.

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

⁠2.6. Лицензионное соглашение

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

эксплуатацию программ на любом количестве компьютеров и в любых целях;

распространение программ (сопровождая их копией авторского договора);

получение исходных текстов программ.

Если вы приобрели дистрибутив, то данное лицензионное соглашение прилагается в печатном виде к вашей копии дистрибутива. Лицензия относится ко всему дистрибутиву Альт Платформа. Если вы согласны с условиями лицензии, отметьте пункт Да, я согласен с условиями и нажмите кнопку Далее.

⁠2.7. Дата и время

На данном этапе выполняется выбор региона и города, по которым будет определен часовой пояс и установлены системные часы.

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

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

Пункт Хранить время в BIOS по Гринвичу выставляет настройки даты и времени в соответствии с часовыми поясами, установленными по Гринвичу, и добавляет к местному времени часовую поправку для выбранного региона.

После выбора часового пояса будут предложены системные дата и время по умолчанию.

Для ручной установки текущих даты и времени нужно нажать кнопку Изменить…. Откроется окно ручной настройки системных параметров даты и времени.

Для сохранения настроек и продолжения установки системы в окне ручной установки даты и времени необходимо нажать кнопку ОК и затем в окне Дата и время нажать кнопку Далее.

Примечание

В случае если ОС Альт Платформа устанавливается как вторая ОС, необходимо снять отметку с пункта Хранить время в BIOS по Гринвичу, иначе время в уже установленной ОС может отображаться некорректно.

⁠2.8. Подготовка диска

На этом этапе подготавливается площадка для установки ALT Platform Builder, в первую очередь — выделяется свободное место на диске.

Переход к этому шагу может занять некоторое время. Время ожидания зависит от производительности компьютера, объёма жёсткого диска, количества разделов на нём и других параметров.

⁠2.8.1. Выбор профиля разбиения диска

После завершения первичной конфигурации загрузочного носителя откроется окно Подготовка диска. В списке разделов перечислены уже существующие на жёстких дисках разделы (в том числе здесь могут оказаться съёмные flash-диски, подключённые к компьютеру в момент установки).

В списке Выберите профиль перечислены доступные профили разбиения диска. Профиль — это шаблон распределения места на диске для установки ОС. Можно выбрать один из профилей:

Установка сервера;

Вручную.

⁠2.8.2. Автоматический профиль разбиения диска

Профиль Установка сервера предполагает автоматическое разбиение диска. При выборе этого профиля будет создан раздел под корень (swap и раздел под efi автоматически). Если размер диска больше 130 ГБ, будет также создан раздел /var.

Примечание

Если при применении профиля автоматического разбиения диска доступного места на диске окажется недостаточно, то на монитор будет выведено сообщение об ошибке: Невозможно применить профиль, недостаточно места на диске.

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

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

Предупреждение

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

Для продолжения установки следует нажать кнопку Далее. Появится окно со списком настроенных разделов и их точек монтирования. Если вы уверены в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки ОК.

⁠2.8.3. Ручной профиль разбиения диска

При необходимости освободить часть дискового пространства следует воспользоваться профилем разбиения Вручную. В этом случае можно удалить некоторые из существующих разделов или содержащиеся в них файловые системы. После этого можно создать необходимые разделы самостоятельно или вернуться к шагу выбора профиля и применить автоматический профиль. Выбор этой возможности требует знаний об устройстве диска и технологиях его разметки.

По нажатию кнопки Далее будет произведена запись новой таблицы разделов на диск и форматирование разделов. Только что созданные на диске программой установки разделы пока не содержат данных и поэтому форматируются без предупреждения. Уже существовавшие, но изменённые разделы, которые будут отформатированы, помечаются специальным значком в колонке Файловая система слева от названия. При уверенности в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки Далее.

Не следует форматировать разделы с теми данными, которые вы хотите сохранить, например, со старыми пользовательскими данными (/home) или с другими операционными системами. С другой стороны, отформатировать можно любой раздел, который вы хотите «очистить» (удалить все данные).

Предупреждение

Не уменьшайте NTFS-раздел с установленной Microsoft Windows Vista/Windows 7 средствами программы установки. В противном случае вы не сможете загрузить Microsoft Windows Vista/Windows 7 после установки Альт Платформа. Для выделения места под установку Альт Платформа воспользуйтесь средствами, предоставляемыми самой Microsoft Windows Vista/Windows 7: Управление дисками → Сжать.

Для того чтобы система правильно работала (в частности могла загрузиться) с UEFI, при ручном разбиении диска надо обязательно сделать точку монтирования /boot/efi, в которую нужно смонтировать vfat раздел с загрузочными записями. Если такого раздела нет, то его надо создать вручную. При разбивке жёсткого диска в автоматическом режиме такой раздел создаёт сам установщик. Особенности разбиения диска в UEFI-режиме:

требуется создать новый или подключить существующий FAT32-раздел с GPT-типом ESP (efi system partition) размером ~100—500 Мб (будет смонтирован в /boot/efi);

может понадобиться раздел типа bios boot partition минимального размера, никуда не подключенный и предназначенный для встраивания grub2-efi;

остальные разделы — и файловая система, и swap — имеют GPT-тип basic data; актуальный тип раздела задаётся отдельно.

Для сохранения всех внесенных настроек и продолжения установки в окне Подготовка диска нужно нажать кнопку Далее. Появится окно со списком настроенных разделов и их точек монтирования. Если вы уверены в том, что подготовка диска завершена, подтвердите переход к следующему шагу нажатием кнопки ОК.

⁠2.8.4. Дополнительные возможности разбиения диска

Ручной профиль разбиения диска позволяет установить ОС на программный RAID-массив, разместить разделы в томах LVM и использовать шифрование на разделах. Данные возможности требуют от пользователя понимания принципов функционирования указанных технологий.

⁠2.8.4.1. Создание программного RAID-массива

Избыточный массив независимых дисков RAID (redundant array of independent disks) — технология виртуализации данных, которая объединяет несколько жёстких дисков в логический элемент для избыточности и повышения производительности.

Примечание

Для создания программного RAID-массива потребуется минимум два жёстких диска.

Программа установки поддерживает создание программных RAID-массивов следующих типов:

RAID 1;

RAID 0;

RAID 4/5/6;

RAID 10.

Процесс подготовки к установке на RAID условно можно разбить на следующие шаги:

создание разделов на жёстких дисках;

создание RAID-массивов на разделах жёсткого диска;

создание файловых систем на RAID-массиве.

Важно

Для создания программного RAID-массива может потребоваться предварительно удалить существующую таблицу разделов с жёсткого диска.

Важно

Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска.

Для настройки параметров нового раздела из состава RAID-массива необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Вручную и нажать кнопку Создать раздел.

Для создания программного массива на GPT-разделах следует сначала создать разделы типа basic data и не создавать на них том (снять отметку с пункта Создать том):

В этом окне необходимо настроить следующие параметры:

Размер — в поле необходимо указать размер будущего раздела в Мбайт;

Смещение — в поле необходимо указать смещение начала данных на диске в Мбайт;

Тип раздела — в выпадающем поле нужно выбрать значение basic data для последующего включения раздела в RAID-массив.

Примечание

В режиме Legacy при создании разделов на жёстких дисках для последующего включения их в RAID-массивы следует указать Тип раздела для них равным Linux RAID:

На втором диске создать два раздела с типом basic data без создания на них томов. При этом разделы на разных дисках должны совпадать по размеру.

Примечание

При создании разделов следует учесть, что объём результирующего массива может зависеть от размера, включённых в него разделов жёсткого диска. Например, при создании RAID 1 результирующий размер массива будет равен размеру минимального участника.

После создания разделов на дисках можно переходить к организации самих RAID-массивов. Для этого в списке следует выбрать пункт RAID, после чего нажать кнопку Создать RAID:

Далее мастер предложит выбрать тип массива:

И указать участников RAID-массива (по умолчанию выбираются все разделы, поэтому необходимо снять отметку с раздела sdb1):

Результат создания RAID-массива:

После того, как RAID-массив создан, его можно использовать как обычный раздел на жёстких дисках, то есть на нём можно создавать файловые системы или же, например, включать в LVM-тома.

Примечание

После установки системы можно будет создать ещё один RAID-массив и добавить в него загрузочный раздел (/boot/efi).

⁠2.8.4.2. Создание LVM-томов

Менеджер логических дисков LVM (Logical Volume Manager) — средство гибкого управления дисковым пространством, позволяющее создавать поверх физических разделов (либо неразбитых дисков) логические тома, которые в самой системе будут видны как обычные блочные устройства с данными (обычные разделы).

Процесс подготовки к установке на LVM условно можно разбить на следующие шаги:

создание разделов на жёстких дисках;

создание группы томов LVM;

создание томов LVM;

создание файловых систем на томах LVM.

Важно

Для создания группы томов LVM может потребоваться предварительно удалить существующую таблицу разделов с жёсткого диска.

Важно

Системный раздел EFI должен быть физическим разделом в основной таблице разделов диска, не под LVM.

Для настройки параметров нового раздела необходимо выбрать неразмеченный диск в окне профиля разбивки пространства Вручную и нажать кнопку Создать раздел:

При создании разделов на жёстких дисках для последующего включения их в LVM-тома следует указать Тип раздела для них равным basic data и не создавать на них том (снять отметку с пункта Создать том):

Примечание

В режиме Legacy при создании разделов на жёстких дисках для последующего включения их в LVM-тома следует указать Тип раздела для них равным Linux LVM:

После создания разделов на дисках можно переходить к созданию группы томов LVM. Для этого в списке следует выбрать пункт LVM, после чего нажать кнопку Создать группу томов:

В открывшемся окне необходимо выбрать разделы, которые будут входить в группу томов, указать название группы томов и выбрать размер экстента:

Примечание

Размер экстента представляет собой наименьший объем пространства, который может быть выделен тому. Размер экстента по умолчанию 65536 (65536*512 байт = 32 Мб, где 512 байт — размер сектора).

После того, как группа томов LVM создана, её можно использовать как обычный жёсткий диск, то есть внутри группы томов можно создавать тома (аналог раздела на физическом жёстком диске) и файловые системы внутри томов.

⁠2.8.4.3. Создание шифрованных разделов

Программа установки Альт Платформа позволяет создавать шифрованные разделы.

Процесс создания шифрованного раздела ничем не отличается от процесса создания обычного раздела и инициируется нажатием на кнопку Создать шифруемый раздел:

После создания шифрованного раздела мастер, как и при создании обычного раздела, предложит создать на нём файловую систему и при необходимости потребует указать точку монтирования:

Предупреждение

Установка загрузчика на шифрованный раздел не поддерживается.

⁠2.9. Установка системы

На данном этапе происходит распаковка ядра и установка набора программ, необходимых для работы дистрибутива ALT Platform Builder.

Установка происходит автоматически в два этапа:

получение пакетов;

установка пакетов.

Получение пакетов осуществляется из источника, выбранного на этапе начальной загрузки. При сетевой установке (по протоколу FTP или HTTP) время выполнения этого шага будет зависеть от скорости соединения.

⁠2.10. Сохранение настроек

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

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

На этом шаге производится перенос настроек, выполненных на первых шагах установки, в только что установленную базовую систему. Производится также запись информации о соответствии разделов жесткого диска смонтированным на них файловым системам (заполняется конфигурационный файл /etc/fstab).

После сохранения настроек осуществляется автоматический переход к следующему шагу.

⁠2.11. Установка загрузчика

Загрузчик ОС — это программа, которая позволяет загружать ALT Platform Builder и другие ОС, если они установлены на данной машине.

При установке на EFI модуль установки загрузчика предложит вариант установить загрузчик в специальный раздел «EFI» (рекомендуется выбрать автоматическое разбиение на этапе разметки диска для создания необходимых разделов для загрузки с EFI):

Варианты установки загрузчика при установке в режиме EFI:

EFI (рекомендуемый) — при установке загрузчика в NVRAM будет добавлена запись, без которой большинство компьютеров не смогут загрузиться во вновь установленную ОС;

EFI (сначала очистить NVRAM) — перед добавлением записи в NVRAM её содержимое будет сохранено в /root/.install-log, после чего из неё будут удалены все загрузочные записи, что приведёт к восстановлению полностью заполненной NVRAM и гарантирует загрузку вновь установленной ОС;

EFI (запретить запись в NVRAM) — этот вариант следует выбрать, только если инсталлятор не может создать запись в NVRAM или если заведомо известно, что запись в NVRAM может вывести компьютер из строя (вероятно, запись в NVRAM придётся создать после установки ОС средствами BIOS Setup);

EFI (для съёмных устройств) — этот вариант следует выбрать, только если ОС устанавливается на съёмный накопитель. Этот вариант также можно использовать вместо варианта EFI (запретить запись в NVRAM) при условии, что это будет единственная ОС на данном накопителе. Создавать запись в NVRAM не потребуется.

Выбор варианта установки загрузчика, зависит от вашего оборудования. Если не работает один вариант, попробуйте другие.

Примечание

Установка загрузчика при установке в режиме Legacy:

Программа установки автоматически определяет, в каком разделе жёсткого диска следует располагать загрузчик для возможности корректного запуска ОС ALT Platform Builder. Положение загрузчика, в случае необходимости, можно изменить в списке Устройство, выбрав другой раздел.

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

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

Примечание

При необходимости изменения опций загрузки при старте компьютера потребуется ввести имя пользователя «boot» и заданный на этом шаге пароль.

Для подтверждения выбора и продолжения работы программы установки необходимо нажать кнопку Далее.

⁠2.12. Настройка сети

На этом этапе необходимо задать параметры работы сетевой карты и настройки сети: IP-адреса сетевых интерфейсов, DNS-сервер, шлюз и т.п. Конкретные значения будут зависеть от используемого вами сетевого окружения. Ручного введения настроек можно избежать при наличии в сети настроенного DHCP-сервера. В этом случае все необходимые сетевые настройки будут получены автоматически.

В окне Настройка сети доступны следующие поля:

Имя компьютера — сетевое имя компьютера (это общий сетевой параметр, не привязанный к какому-либо конкретному интерфейсу);

Интерфейсы — список доступных сетевых интерфейсов;

Версия протокола IP — версия используемого протокола IP (IPv4, IPv6);

Конфигурация — способ назначения IP-адресов (Использовать DHCP, Использовать Zeroconf, Вручную);

IP-адреса — пул назначенных IP-адресов из поля Добавить ↑ IP, выбранные адреса можно удалить нажатием кнопки Удалить;

Добавить ↑ IP — позволяет ввести IP-адрес вручную и выбрать в выпадающем поле предпочтительную маску сети. Для переноса адреса в пул поля IP-адреса необходимо нажать кнопку Добавить;

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

DNS-серверы — список предпочтительных DNS-серверов, которые будут получать информацию о доменах, выполнять маршрутизацию почты и управлять обслуживающими узлами для протоколов в домене;

Домены поиска — список предпочтительных доменов, по которым будет выполняться поиск.

Для сохранения настроек сети и продолжения работы программы установки необходимо нажать кнопку Далее.

⁠2.13. Администратор системы

На данном этапе загрузчик создает учетную запись администратора. В открывшемся окне необходимо ввести пароль учетной записи администратора (root). Чтобы исключить опечатки при вводе пароля, пароль учетной записи вводится дважды.

Примечание

Чтобы избежать последствий неверной раскладки клавиатуры можно просмотреть пароль, который будет сохранен. Для этого нажмите на значок глаза в поле ввода:

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

В любой системе Linux всегда присутствует один специальный пользователь — администратор системы, он же суперпользователь. Для него зарезервировано стандартное системное имя — root.

Администратор системы отличается от всех прочих пользователей тем, что ему позволено производить любые, в том числе самые разрушительные изменения в системе. Поэтому выбор пароля администратора системы — очень важный момент для безопасности. Любой, кто сможет ввести его правильно (узнать или подобрать), получит неограниченный доступ к системе. Даже ваши собственные неосторожные действия от имени root могут иметь катастрофические последствия для всей системы.

Подтверждение введенного (или сгенерированного) пароля учетной записи администратора (root) и продолжение работы программы установки выполняется нажатием кнопки Далее.

⁠2.14. Системный пользователь

На данном этапе программа установки создает учетную запись системного пользователя (пользователя) Альт Платформа.

Помимо администратора (root) в систему необходимо добавить, по меньшей мере, одного обычного системного пользователя. Работа от имени администратора системы считается опасной, поэтому повседневную работу в Linux следует выполнять от имени ограниченного в полномочиях системного пользователя.

При добавлении системного пользователя предлагается ввести имя учётной записи пользователя. Имя учётной записи всегда представляет собой одно слово, состоящее только из строчных латинских букв (заглавные запрещены), цифр и символа подчёркивания «_» (причём цифра и символ «_» не могут стоять в начале слова).

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

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

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

Подтверждение введенного (или сгенерированного) пароля учетной записи системного пользователя и продолжение работы программы установки выполняется нажатием кнопки Далее.

⁠2.15. Установка пароля на шифрованные разделы

Примечание

Если вы не создавали шифруемые разделы, то этот шаг пропускается автоматически. В этом случае сразу переходите к главе Завершение установки.

На этом этапе требуется ввести пароль для шифруемых разделов. Этот пароль потребуется вводить для того, чтобы получать доступ к информации на данных разделах.

Например, если вы зашифровали /home, то во время загрузки системы будет необходимо ввести пароль для этого раздела, иначе вы не сможете получить доступ в систему под своим именем пользователя.

⁠2.16. Завершение установки

На экране последнего шага установки отображается информация о завершении установки ALT Platform Builder.

После нажатия кнопки Завершить автоматически начнется перезагрузка системы.

Не забудьте извлечь установочный DVD (если это не происходит автоматически). Далее можно загружать установленную систему в обычном режиме.

⁠2.17. Обновление системы до актуального состояния

После установки системы, её лучше сразу обновить до актуального состояния. Можно не обновлять систему и сразу приступать к работе только в том случае, если вы не планируете подключаться к сети или Интернету, не собираетесь устанавливать дополнительных программ.

Для обновления системы необходимо выполнить команды (с правами администратора):

# apt-get update
# apt-get dist-upgrade
# update-kernel
# apt-get clean
# reboot

Примечание

Получить права администратора можно, выполнив в терминале команду:

$ su -

или зарегистрировавшись в системе под именем root.

⁠2.18. Первая помощь

Важно

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

⁠2.18.1. Проблемы при установке системы

Важно

При возникновении проблем с UEFI или Legacy/CSM рекомендуется изменить выбор используемого вида прошивки на другой. Не следует выбирать режим смешанной загрузки Legacy/UEFI! Рекомендуется отключить всевозможные оптимизации и ускорение UEFI-загрузки, а также отключить на время установки SecureBoot.

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

Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. В открывшемся редакторе следует найти строку, начинающуюся с linux /boot/vmlinuz, в её конец дописать требуемые параметры, отделив пробелом и нажать F10.

Примеры параметров пункта загрузки:

nomodeset — не использовать modeset-драйверы для видеокарты;

vga=normal — отключить графический экран загрузки установщика;

xdriver=vesa — явно использовать видеодрайвер vesa. Данным параметром можно явно указать нужный вариант драйвера;

acpi=off noapic — отключение ACPI (управление питанием), если система не поддерживает ACPI полностью.

Если вы вообще не смогли установить систему (не произошла или не завершилась стадия установки пакетов), то сначала попробуйте повторить попытку в безопасном режиме (apm=off acpi=off mce=off barrier=off vga=normal). В безопасном режиме отключаются все параметры ядра, которые могут вызвать проблемы при загрузке. В этом режиме установка будет произведена без поддержки APIC. Возможно, у вас какое-то новое или нестандартное оборудование, но может оказаться, что оно отлично настраивается со старыми драйверами.

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

⁠2.18.2. Проблемы с загрузкой системы

Если не загружается ни одна из установленных операционных систем, то значит, есть проблема в начальном загрузчике. Такие проблемы могут возникнуть после установки системы, в случае если загрузчик все-таки не установлен или установлен с ошибкой. При установке или переустановке Windows на вашем компьютере загрузчик Linux будет перезаписан в принудительном порядке, и станет невозможно запускать Linux.

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

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

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

Загрузка восстановительного режима заканчивается приглашением командной строки: [root@localhost /]#. Начиная с этого момента, система готова к вводу команд.

В большинстве случаев для восстановления загрузчика можно просто воспользоваться командой fixmbr без параметров. Программа попытается переустановить загрузчик в автоматическом режиме.

⁠2.18.3. Полезные ссылки

Если у вас что-то не получается, вы всегда можете поискать решение на ресурсах, указанных в разделе Техническая поддержка продуктов «Базальт СПО».

⁠Глава 3. Начало использования Альт Платформа

В этой главе рассматривается загрузка установленной операционной системы.

⁠3.1. Загрузка системы

Запуск ALT Platform Builder выполняется автоматически после запуска компьютера и отработки набора программ BIOS.

На экране появляется меню, в котором перечислены возможные варианты загрузки операционной системы.

Важно

При первом старте, в условиях установки нескольких ОС на один компьютер, возможно отсутствие в загрузочном меню пункта/пунктов с другой/другими операционными системами, они будут добавлены в список при последующей перезагрузке. Все перечисленные в меню после перезагрузки варианты могут быть загружены загрузчиком Linux.

Стрелками клавиатуры Вверх и Вниз выберите нужную операционную систему. Дополнительно к основным вариантам запуска ОС из этого меню можно загрузить Linux в безопасном режиме или запустить проверку памяти.

Загрузка операционной системы по умолчанию (первая в списке) начинается автоматически после небольшого времени ожидания (обычно несколько секунд). Нажав клавишу Enter, можно начать загрузку немедленно.

Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, то редактировать их нет необходимости.

Примечание

Если при установке системы на этапе был установлен пароль на загрузчик, потребуется ввести имя пользователя «boot» и заданный на шаге Установка загрузчика пароль.

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

⁠3.2. Получение доступа к зашифрованным разделам

В случае, если вы создали шифрованный раздел, вам потребуется вводить пароль при обращении к этому разделу.

Например, если был зашифрован домашний раздел /home, то для того, чтобы войти в систему под своим именем пользователя, вам потребуется ввести пароль этого раздела и затем нажать Enter.

Важно

Если не ввести пароль за отведенный промежуток времени, то загрузка системы завершится ошибкой. В этом случае вам следует перезагрузить систему, нажав для этого два раза Enter, а затем клавиши Ctrl+Alt+Delete.

⁠3.3. Вход в систему

⁠3.3.1. Вход и работа в консольном режиме

Стандартная установка ALT Platform Builder включает базовую систему, работающую в консольном режиме.

При загрузке в консольном режиме работа загрузчика Альт Платформа завершается запросом на ввод логина и пароля учетной записи. В случае необходимости на другую консоль можно перейти, нажав Ctrl+Alt+F2.

Для дальнейшего входа в систему необходимо ввести логин и пароль учетной записи пользователя.

В случае успешного прохождения процедуры аутентификации и идентификации будет выполнен вход в систему. ОС ALT Platform Builder перейдет к штатному режиму работы и предоставит дальнейший доступ к консоли.

Примечание

Сразу после загрузки в консоли будут показаны имя и IP-адрес компьютера. К узлу можно подключиться по SSH, например (потребуется ввести пароль пользователя):

$ ssh user@192.168.0.160

⁠3.3.2. Виртуальная консоль

В процессе работы ОС ALT Platform Builder активно несколько виртуальных консолей. Каждая виртуальная консоль доступна по одновременному нажатию клавиш Ctrl, Alt и функциональной клавиши с номером этой консоли от F1 до F6.

При установке системы в профиле по умолчанию на первой виртуальной консоли пользователь может зарегистрироваться и работать в графическом режиме. При нажатии Ctrl+Alt+F1 осуществляется переход на первую виртуальную консоль в графический режим.

Двенадцатая виртуальная консоль (Ctrl+Alt+F12) выполняет функцию системной консоли — на неё выводятся сообщения о происходящих в системе событиях.

⁠Глава 4. Настройка модуля Сервер обновлений

⁠4.1. Центр управления системой

Центр управления системой (ЦУС) представляет собой удобный интерфейс для выполнения наиболее востребованных административных задач: добавление и удаление пользователей, настройка сетевых подключений, просмотр информации о состоянии системы и т.п.

Центр управления системой состоит из нескольких независимых диалогов-модулей. Каждый модуль отвечает за настройку определённой функции или свойства системы. Модули ЦУС имеют справочную информацию.

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

Работа с ЦУС может происходить из любого веб-браузера. Для начала работы необходимо перейти по адресу https://ip-адрес:8080/.

При запуске центра управления системой необходимо ввести в соответствующие поля имя пользователя (root) и пароль пользователя:

После этого будут доступны все возможности ЦУС на той машине, к которой было произведено подключение через веб-интерфейс.

⁠4.2. Модуль ЦУС Сервер обновлений

Сервер обновлений — технология, позволяющая настроить автоматическое обновление программного обеспечения, установленного на клиентских машинах (рабочих местах), работающих под управлением ОС Альт.

Кроме того, сервер обновлений предоставляет локальный доступ ко всем пакетам репозитория Альт Платформа, используемым для разработки и/или сборки ПО.

Модуль ЦУС Сервер обновлений (пакет alterator-mirror) из раздела Серверы предназначен для зеркалирования репозиториев и их публикации.

Модуль позволяет:

просмотреть информацию о зеркалируемых репозиториях;

выбрать репозитории для зеркалирования из предложенного списка;

настроить периодичность зеркалирования;

задать параметры каждого зеркалируемого репозитория: источник, архитектуру, параметры публикации;

создать собственный дополнительный репозиторий.

При нажатии на название репозитория отображаются его настройки:

Необходимо выбрать:

источник — URL-адрес, откуда будет скачиваться репозиторий;

архитектуру процессора (если доступно несколько, то стоит выбрать нужные).

Примечание

При выборе любой архитектуры автоматически добавляется также источник noarch.

Сервер обновлений позволяет автоматически настроить обновление клиентских машин в нужном режиме:

⁠

Локальное зеркало репозитория

В этом режиме на сервере создаётся копия удалённого репозитория. Клиентские машины могут загружать ПО с локального сервера по протоколам HTTP, HTTPS, FTP или rsync (для каждого протокола требуется отдельная настройка соответствующей службы). Наличие локального зеркала особенно выгодно при большом количестве клиентов — это существенно экономит внешний трафик.

Важно

Зеркалирование требует значительного объёма дискового пространства.

Чтобы уменьшить объём скачиваемых данных и занимаемое место, можно указать файлы и каталоги, которые следует исключить из синхронизации. Например, исключить пакеты с исходным кодом и отладочной информацией:

SRPMS
*-debuginfo-*

Шаблоны указываются по одному на строку. Символ «*» означает подстановку любого количества символов.

⁠

Публикация репозитория

В этом случае публикуется или URL внешнего сервера, содержащего репозиторий или, если включено локальное зеркало репозитория, адрес этого сервера. Такая публикация позволяет клиентским машинам автоматически настроить свои менеджеры пакетов на использование указанного репозитория.

На стороне клиентов, в этом случае, необходимо настроить модуль Обновление системы, отметив в нём Обновление системы, управляемое сервером.

Создание собственного репозитория:

На странице модуля нажать ссылку Дополнительный репозиторий.

В окне настройки дополнительного репозитория добавить в репозиторий rpm-пакет. Для этого нажать кнопку Обзор, указать путь к RPM-пакету и нажать кнопку Загрузить:

Повторить шаг 2 для всех пакетов, которые нужно добавить в репозиторий.

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

Нажать кнопку Применить.

На странице модуля можно также задать:

частоту загрузки пакетов;

время начала зеркалирования.

Настройка локального репозитория заканчивается нажатием кнопки Применить.

Примечание

По умолчанию локальное зеркало репозитория находится в /srv/public/mirror. Для того чтобы зеркалирование происходило в другую папку, необходимо эту папку примонтировать в папку /srv/public/mirror. Для этого в файл /etc/fstab следует вписать строку:

/media/disk/localrepo /srv/public/mirror none rw,bind,auto 0 0

где /media/disk/localrepo — папка-хранилище локального репозитория.

Примечание

Если в каталогах /srv/public/mirror/<репозиторий>/branch/<архитектура>/base/. нет файлов pkglist.*, значит зеркалирование ещё не завершено (т.е. не все файлы загружены на ваш сервер).

⁠4.3. Настройка списка репозиториев APT

По окончании первой синхронизации репозиторий готов к использованию.

Непосредственно после установки дистрибутива ALT Platform Builder в файлах /etc/apt/sources.list.d/*.list указан интернет-репозиторий:

$ apt-repo
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic

Для того чтобы указать локальный репозиторий вместо интернет-репозитория необходимо выполнить следующие действия:

удалить все текущие источники:

# apt-repo rm all

добавить источник типа file для зеркалированного репозитория p10:

# apt-repo add file:/srv/public/mirror/p10/branch

добавить источник типа file для дополнительного репозитория:

# apt-repo add 'rpm file:/srv/public/mirror/additional x86_64 classic'

вывести список доступных репозиториев:

# apt-repo
rpm file:/srv/public mirror/additional/x86_64 classic
rpm file:/srv/public/mirror p10/branch/x86_64 classic
rpm file:/srv/public/mirror p10/branch/noarch classic

Примечание

В команде apt-repo add необходимо указать URL с обязательным указанием протокола и необязательным указанием архитектуры и одним или несколькими компонентами. Если при добавлении источника в конце строки отсутствуют архитектура и компонент, будут добавлены две строки (текущая архитектура системы и «noarch») с компонентом «classic».

⁠Глава 5. Работа с пакетами

⁠5.1. RPM-пакет

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

Различают два вида пакетов RPM:

пакет с исходным кодом — SRPM-пакет (имеет расширение .src.rpm). Такой пакет содержит архив (один или несколько) с исходным кодом, spec-файл и, возможно, разнообразные патчи и дополнения. Пакет src.rpm можно использовать только для сборки двоичных пакетов, но не для установки. Сборка осуществляется командой:

rpmbuild --rebuild package...src.rpm

собранный двоичный пакет — RPM-пакет (имеет расширение вида <архитектура>.rpm). Такие пакеты можно устанавливать командой:

rpm -Uvh package...rpm

Однако для сборки через rpmbuild возникают очевидные сложности:

необходимо вручную удовлетворить сборочные зависимости для сборки (поставить компилятор, включаемые файлы, библиотеки). При большом количестве собираемых пакетов система засоряется;

для сборки пакета нужно сформировать .src.rpm из файлов, разбросанных по разным каталогам (по умолчанию, это подкаталоги SOURCE, SPECS и подкаталоги для сборки в ~/RPM);

файлы с исходным кодом должны лежать в упакованном виде, что делает трудоемким процесс изготовления патчей;

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

Чтобы избежать этих сложностей, в Альт Платформа используется две технологии:

Hasher — для сборки в изолированном окружении. В chroot ставится базовый комплект пакетов и пакеты, необходимые для сборки (поле BuildRequires в спеке). Если какой-то пакет для сборки не указан в спеке, то появится ошибка. Так обеспечивается чистота сборки. Обратной стороной является необходимость иметь доступ к репозиторию, так как пакеты ставятся при каждой сборке в Hasher;

Gear — для сборки пакетов из репозитория Git. В этом случае все файлы лежат в распакованном виде и в .src.rpm упаковываются по правилам, определённым в .gear/rules. Это позволяет работать сразу с содержимым, быстро делать патчи, вести историю изменений и обмениваться изменениями при коллективной разработке.

⁠5.2. SPEC-файл

Spec-файл можно рассматривать как «инструкцию», которую утилита rpmbuild использует для фактической сборки RPM-пакета. Spec-файл определяет все действия, которые должны быть выполнены при сборке RPM-пакета, а также все действия, необходимые при установке/удалении пакета. Каждый src.rpm-пакет имеет в своем составе spec-файл.

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

Текст внутри spec-файла имеет специальный синтаксис. Синтаксические определения имеют значения, задающие порядок сборки, номер версии, информацию о зависимостях и вообще всю информацию о пакете, которая может быть впоследствии запрошена из БД RPM.

⁠5.2.1. Пример spec-файла

Пример spec-файла:

Name: sampleprog
Version: 1.0
Release: alt1

Summary: Sample program specfile
Summary(ru_RU.UTF-8): Пример спек-файла для программы

License: GPLv2+
Group: Development/Other
Url: http://www.altlinux.org/SampleSpecs/program

Packager: Sample Packager <sample@altlinux.org>

Source: %name-%version.tar
Patch0: %name-1.0-alt-makefile-fixes.patch

%description
This specfile is provided as sample specfile for packages with programs.
It contains most of usual tags and constructions used in such specfiles.

%description -l ru_RU.UTF-8
Этот спек-файл является примером спек-файла для пакета с программой. Он содержит
основные теги и конструкции, используемые в подобных спек-файлах.

%prep
%setup
%patch0 -p1

%build
%configure
%make_build

%install
%makeinstall_std
%find_lang %name

%files -f %name.lang
%doc AUTHORS ChangeLog NEWS README THANKS TODO contrib/ manual/
%_bindir/*
%_man1dir/*

%changelog
* Sat Sep 12 3001 Sample Packager <sample@altlinux.org> 1.0-alt1
- initial build

⁠5.2.2. Директивы преамбулы

В Директивы преамбулы spec-файла перечислены директивы, используемые в разделе преамбулы файла спецификации RPM.

⁠

Таблица 5.1. Директивы преамбулы spec-файла

SPEC Директива

Определение

Name

Базовое имя пакета, которое должно совпадать с именем spec-файла.

Version

Версия upstream-кода.

Release

Релиз пакета используется для указания номера сборки пакета при данной версии upstream-кода.

Для пакетов Sisyphus поле Release должно иметь вид в простых случаях — altN, а в сложных — altN[суффикс]. N начинается с 1 для каждой новой upstream-версии и увеличивается на 1 для каждой новой сборки:

1.0-alt1

1.0-alt2

Epoch

Поле Epoch используется тогда, когда по какой-то причине требуется уменьшить версию или релиз пакета по сравнению с имеющимся в репозитории. При этом значение поля Epoch увеличивается на единицу по сравнению с предыдущим (отсутствие поля Epoch эквивалентно значению 0), версия и релиз устанавливаются в нужное значение.

В имя RPM-файлов Epoch не входит, и поэтому необходимо избегать RPM с одинаковыми Version и Release и разными Epoch.

Summary

Краткое, однострочное описание пакета. Значение тэга Summary должно начинаться с заглавной буквы. В конце Summary не должно быть точки.

License

Лицензия на собираемое программное обеспечение. Лицензия должна быть указана в точности так, как сформулировано в upstream-пакете. При указании лицензии рекомендуется пользоваться макросами из пакета rpm-build-licenses, добавив его в список BuildRequires.

Сам текст лицензии упаковывать в пакет нужно только в том случае, если соответствующий текст отсутствует в /usr/share/license (пакет common-licenses). Если же таковой файл присутствует, то достаточно указать название лицензии в тэге пакета.

Group

Используется для указания категории, к которой относится пакет. Указанная группа должна находиться в списке групп, известном RPM. Этот список располагается в файле /usr/lib/rpm/GROUPS, находящемся в пакете rpm.

URL

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

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

Для директивы URL можно использовать утилиту rpmurl, например, проверка доступности URL:

$ rpmurl -c пакет.spec

Source0

Путь или URL-адрес к сжатому архиву исходного кода (не исправленный, исправления обрабатываются в другом месте). Этот раздел должен указывать на доступное и надежное хранилище архива, например, на upstream-страницу, а не на локальное хранилище сборщика. При необходимости можно добавить дополнительные исходные директивы, каждый раз увеличивая их номер, например: Source1, Source2, Source3 и так далее.

Patch0

Название первого патча, который при необходимости будет применен к исходному коду. При необходимости можно добавить дополнительные директивы PatchX, увеличивая их номер каждый раз, например: Patch1, Patch2, Patch3 и так далее.

BuildArch

Явное указание архитектуры, под которую собирается двоичный пакет. Если параметр не задан, то пакет автоматически наследует архитектуру машины, на которой он собран, например, x86_64.

Если пакет не зависит от архитектуры, например, если он полностью написан на интерпретируемом языке программирования, следует установить для этой директивы значение noarch.

BuildRequires, BuildPreReq, BuildRequires(pre)

Разделенный запятыми или пробелами список пакетов, необходимых для сборки программы. Может быть несколько записей BuildRequires, каждая в отдельной строке.

Тэг BuildRequires используется для хранения результатов работы утилиты buildreq. По этой причине дополнительные сборочные зависимости, не находящиеся buildreq, рекомендуется хранить в тэге BuildPreReq.

Requires, PreReq

Разделенный запятыми или пробелами список пакетов, необходимых программному обеспечению для запуска после установки. Это его зависимости. Может быть несколько записей Requires, каждая в отдельной строке.

ExcludeArch

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

Conflicts

Разделенный запятыми или пробелами список пакетов, с которыми конфликтует данный пакет.

Применяется для указания наличия конфликта (обязательно в случае файлового/RPC и желательно в случае существенного смыслового) между данным пакетом и указываемым.

Provides

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

Provides: something = %version-%release

При переименовании пакета обязательно сочетается с Obsoletes.

Obsoletes

Перечисляет пакеты/версии, объявленные устаревшими. Обычно применяется при переименовании пакета в сочетании с Provides и с указанием версии, меньшей или равной последней известной версии пакета под старым названием.

Каждая директива разделяется от ее значения символом «:». Между директивой и двоеточием не должно быть пробелов!

Директивы Name, Version и Release содержат имя RPM-пакета. Эти три директивы часто называют N-V-R или NVR, поскольку имена RPM-пакетов имеют формат NAME-VERSION-RELEASE.

Увидеть пример NAME-VERSION-RELEASE можно, выполнив запрос с использованием rpm для конкретного пакета:

$ rpm -q rpmdevtools
rpmdevtools-8.10-alt2.noarch

Здесь rpmdevtools — это имя пакета, 8.10 — версия, а alt2 — релиз. Последний маркер noarch — сведения об архитектуре. В отличие от NVR, маркер архитектуры не находится под прямым управлением сборщика, а определяется средой сборки. Исключением из этого правила является архитектурно-независимый пакет noarch.

⁠5.2.3. Директивы основной части

В Директивы основной части spec-файла перечислены директивы, используемые в основной части spec-файла, причем все они, кроме %check, являются обязательными.

⁠

Таблица 5.2. Директивы основной части spec-файла

SPEC Директива

Определение

%description

Полное описание программного обеспечения, входящего в комплект поставки RPM. Это описание может занимать несколько строк и может быть разбито на абзацы. Длина каждой строки не должна превышать 72 символа.

Данное описание учитывается при поиске пакета через apt-cache search и полностью выводится во время просмотра информации о пакете при помощи apt-cache show имя_пакета.

%prep

Команда или серия команд для подготовки программного обеспечения к сборке, например, распаковка архива, указанного в Source0. Эта директива может содержать сценарий оболочки (shell скрипт).

%build

Команда или серия команд для фактической сборки программного обеспечения в машинный код (для компилируемых языков) или байт-код (для некоторых интерпретируемых языков).

%install

Команды установки/копирования файлов из сборочного каталога в псевдо-корневой каталог. Во время сборки пакета этот раздел эмулирует конечные пути установки файлов в систему. Команда или серия команд для копирования требуемых артефактов сборки из %builddir (где происходит сборка) в %buildroot каталог (который содержит структуру каталогов с файлами, подлежащими сборке).

%check

Команда или серия команд для тестирования программного обеспечения. Обычно включает в себя модульные тесты.

%files

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

%changelog

Запись изменений, произошедших в пакете между сборками разных версий или релизов.

Сколько бы двоичных пакетов не было описано в spec-файле, все директивы, кроме %files, должны быть указаны только один раз — разделение на разные двоичные RPM происходит именно в блоках %files согласно преамбуле.

⁠5.3. Система управления пакетами APT

Утилита RPM делает атомарными (одношаговыми) операции с отдельными пакетами: вместо копирования множества файлов и запуска нескольких сценариев пользователь вводит одну команду «установить/удалить пакет». Однако атомарная с точки зрения пользователя операция — добавление в систему одного нового компонента может состоять из нескольких (и даже многих) операций над пакетами. Чтобы сделать процедуру установки, удаления и обновления компонента системы атомарной, были разработаны системы управления пакетами.

Используемая в «Альт» усовершенствованная система управления программными пакетами APT, является системой управления пакетами с простым пользовательским интерфейсом, позволяющим производить установку, обновление и повседневные «хозяйственные» работы с установленными на машине программами без необходимости изучения тонкостей используемого в дистрибутиве менеджера программных пакетов.

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

Система APT состоит из нескольких утилит. Чаще всего используется утилита управления пакетами apt-get: она автоматически определяет зависимости между пакетами и строго следит за их соблюдением при выполнении любой из следующих операций: установка, удаление или обновление пакетов.

APT хранит кэш скачанных из сети пакетов в /var/cache/apt/archives. Кэш скачанных индексов можно найти в /var/lib/apt/lists. Вся конфигурация APT хранится в /etc/apt, главный конфигурационный файл: /etc/apt/apt.conf, списки подключенных репозиториев хранятся в каталогах /etc/apt/sources.list и /etc/apt/sources.list.d/*. Посмотреть текущую конфигурацию APT можно командой:

$ apt-config dump

⁠5.3.1. Репозитории

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

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

Примечание

Подключая одновременно несколько репозиториев, нужно следить за тем, чтобы они были совместимы друг с другом по пакетной базе, т. е. отражали один определенный этап разработки. Например, совместимыми являются основной репозиторий дистрибутива и репозиторий обновлений по безопасности к данному дистрибутиву. В то же время смешение среди источников APT репозиториев, относящихся к разным дистрибутивам, или смешение стабильного репозитория с нестабильной веткой разработки (Sisyphus) чревато различными неожиданными трудностями при обновлении пакетов.

APT позволяет взаимодействовать с репозиторием с помощью различных протоколов доступа. Наиболее популярные — HTTP и FTP, однако существуют и некоторые дополнительные методы.

Для того чтобы APT мог использовать тот или иной репозиторий, информацию о нём необходимо поместить в файл /etc/apt/sources.list, либо в любой файл *.list (например, mysources.list) в каталоге /etc/apt/sources.list.d. Описания репозиториев заносятся в эти файлы в следующем виде:

rpm [подпись] метод: путь база название
rpm-src [подпись] метод: путь база название

Здесь:

rpm или rpm-src — тип репозитория (скомпилированные программы или исходные тексты);

[подпись] — необязательная строка-указатель на электронную подпись разработчиков. Наличие этого поля подразумевает, что каждый пакет из данного репозитория должен быть подписан соответствующей электронной подписью. Подписи описываются в файле /etc/apt/vendor.list;

метод — способ доступа к репозиторию: ftp, http, file, cdrom, copy;

путь — путь к репозиторию в терминах выбранного метода;

база — относительный путь к базе данных репозитория;

название — название репозитория.

Непосредственно после установки ОС «Альт» в файлах /etc/apt/sources.list.d/*.list обычно указывается интернет-репозиторий, совместимый с установленным дистрибутивом.

После редактирования списка репозиториев в sources.list, необходимо обновлять локальную базу данных APT о доступных пакетах. Это делается командой apt-get update.

Если в sources.list присутствует репозиторий, содержимое которого может изменяться (как происходит с любым постоянно разрабатываемым репозиторием, в частности, обновлений по безопасности), то прежде чем работать с APT, необходимо синхронизировать локальную базу данных с удаленным сервером командой apt-get update. Локальная база данных создается заново каждый раз, когда в репозитории происходит изменение: добавление, удаление или переименование пакета. Для репозиториев, находящихся на компакт-дисках и подключенных командой apt-cdrom add, синхронизация производится единожды в момент подключения.

При выборе пакетов для установки, APT руководствуется всеми доступными репозиториями вне зависимости от способа доступа к ним. Так, если в репозитории, доступном по сети Интернет, обнаружена более новая версия программы, чем на компакт-диске, то APT начнет загружать данный пакет из Интернет. Поэтому если подключение к Интернет отсутствует или ограничено низкой пропускной способностью канала или высокой стоимостью, то следует закомментировать те строчки в /etc/apt/sources.list, в которых говорится о ресурсах, доступных по Интернет.

⁠5.3.1.1. Утилита apt-repo для работы с репозиториями

Для редактирования репозиториев можно воспользоваться скриптом apt-repo:

просмотреть список активных репозиториев:

$ apt-repo

показать все доступные репозитории (неактивные будут закомментированы «#»):

$ apt-repo -a

добавить репозиторий в список активных репозиториев:

# apt-repo add репозиторий

удалить или выключить репозиторий:

# apt-repo rm репозиторий

удалить все существующие источники и добавить новый репозиторий:

# apt-repo set репозиторий

удалить все источники типа cdrom и все хранилища задач (task):

# apt-repo clean

обновить информацию о репозиториях (запустить команду apt-get update):

# apt-repo update

вывести справку о команде apt-repo:

$ man apt-repo

или

$ apt-repo --help

Примечание

Для выполнения большинства команд необходимы права администратора.

Типичный пример использования команды apt-repo: удалить все источники и добавить стандартный репозиторий P10 (архитектура выбирается автоматически):

# apt-repo rm all
# apt-repo add p10

Или то же самое одной командой:

# apt-repo set p10

Источник может быть указан в формате sources.list(5):

# apt-repo add "rpm http://git.altlinux.org/repo/39115/ i586 task"

Допустимы следующие типы репозиториев: rpm, rpm-dir и rpm-src. APT поддерживает протоколы file://, copy://, http://, ftp://, rsync:// и cdrom://. URL с обязательным указанием протокола может сопровождаться необязательным указанием архитектуры и одним или несколькими компонентами. Если в конце строки отсутствуют архитектура и компонент, будут добавлены две строки (текущая архитектура системы и noarch) с компонентом classic.

Пример добавления локального репозитория:

# apt-repo add file:/srv/public/mirror/p10/branch

⁠5.3.1.2. Добавление репозитория на CD/DVD-носителе

Для добавления в sources.list репозитория на компакт-диске в APT предусмотрена специальная утилита — apt-cdrom. Чтобы добавить запись о репозитории на компакт-диске, достаточно вставить диск в привод и выполнить команду apt-cdrom add. После этого в sources.list появится запись о подключенном диске.

Примечание

Если при выполнении команды apt-cdrom add, получена ошибка:

Не найдена точка монтирования /media/ALTLinux/ диска

Необходимо:

в файл /etc/fstab добавить строку:

/dev/sr0 /media/ALTLinux udf,iso9660     ro,noauto,user,utf8,nofail,comment=x-gvfs-show  0 0

создать каталог для монтирования:

# mkdir /media/ALTLinux

затем использовать команду добавления носителя:

# apt-cdrom add

⁠5.3.1.3. Добавление репозиториев вручную

Для изменения списка репозиториев можно отредактировать в любом текстовом редакторе файлы из каталога /etc/apt/sources.list.d/.

Примечание

Для изменения этих файлов необходимы права администратора.

В файле alt.list может содержаться такая информация:

# ftp.altlinux.org (ALT Linux, Moscow)

# ALT Platform 10
#rpm [p10] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic
#rpm [p10] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic
#rpm [p10] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic

rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic
rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic

#rpm [p10] rsync://ftp.altlinux.org/ALTLinux p10/branch/x86_64 classic
#rpm [p10] rsync://ftp.altlinux.org/ALTLinux p10/branch/x86_64-i586 classic
#rpm [p10] rsync://ftp.altlinux.org/ALTLinux p10/branch/noarch classic

По сути, каждая строчка соответствует некому репозиторию. Не активные репозитории — строки, начинающиеся со знака «#». Для добавления нового репозитория, достаточно дописать его в этот или другой файл.

После обновления списка репозиториев следует обновить информацию о них (выполнить команду apt-get update или apt-repo update).

⁠5.3.2. Поиск пакетов

Если точное название пакета неизвестно, то для его поиска можно воспользоваться утилитой apt-cache, которая позволяет искать не только по имени пакета, но и по его описанию.

Команда apt-cache search позволяет найти все пакеты, в именах или описании которых присутствует указанная подстрока. Например:

$ apt-cache search ^gimp
gimp - The GNU Image Manipulation Program
libgimp - GIMP libraries
libgimp-devel - GIMP plugin and extension development kit
gimp-help-en - English help files for the GIMP
gimp-help-ru - Russian help files for the GIMP
gimp-plugin-separateplus - Improved version of the CMYK Separation plug-in [...]
gimp-script-ISONoiseReduction - Gimp script for reducing sensor noise [...]
gimp-plugin-gutenprint - GIMP plug-in for gutenprint
gimp-plugin-ufraw - GIMP plugin for opening and converting RAW files [...]

Следует обратить внимание, что в данном примере в поисковом выражении используется символ «^», указывающий на то, что необходимо найти совпадения только в начале строки (в данном случае — в начале имени пакета).

Для того чтобы подробнее узнать о каждом из найденных пакетов и прочитать его описание, можно воспользоваться командой apt-cache show, которая покажет информацию о пакете из репозитория:

$ apt-cache show gimp-help-ru
Package: gimp-help-ru
Section: Graphics
Installed Size: 37095561
Maintainer: Alexey Tourbin <at@altlinux.ru>
Version: 2.6.1-alt2
Pre-Depends: rpmlib(PayloadIsLzma)
Provides: gimp-help-ru (= 2.6.1-alt2)
Obsoletes: gimp-help-common (<screen 2.6.1-alt2)
Architecture: noarch
Size: 28561160
MD5Sum: 0802d8f5ec1f78af6a4a19005af4e37d
Filename: gimp-help-ru-2.6.1-alt2.noarch.rpm
Description: Russian help files for the GIMP
Russian help files for the GIMP.

Утилита apt-cache позволяет осуществлять поиск и по русскому слову, однако в этом случае будут найдены только те пакеты, у которых есть описание на русском языке. К сожалению, русское описание на настоящий момент есть не у всех пакетов, хотя описания наиболее актуальных для пользователя пакетов переведены.

⁠5.3.3. Установка или обновление пакета

Установка пакета с помощью APT выполняется командой:

# apt-get install имя_пакета

Примечание

Для установки пакетов требуются привилегии администратора.

Утилита apt-get позволяет устанавливать в систему пакеты, требующие для работы другие, пока еще не установленные. В этом случае он определяет, какие пакеты необходимо установить, и устанавливает их, пользуясь всеми доступными репозиториями.

Установка пакета gimp командой apt-get install gimp приведет к следующему диалогу с APT:

# apt-get install gimp
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие дополнительные пакеты будут установлены:
icc-profiles libbabl libgegl libgimp libjavascriptcoregtk2 libopenraw libspiro libwebkitgtk2 libwmf
Следующие НОВЫЕ пакеты будут установлены:
gimp icc-profiles libbabl libgegl libgimp libjavascriptcoregtk2 libopenraw libspiro libweb-kitgtk2 libwmf
0 будет обновлено, 10 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B/24,6MB архивов.
После распаковки потребуется дополнительно 105MB дискового пространства.
Продолжить? [Y/n] y
. . .
Получено 24,6MB за 0s (44,1MB/s).
Совершаем изменения...
Preparing... ####################################### [100%]
1: libbabl ####################################### [10%]
2: libwmf ####################################### [20%]
3: libjavascriptcoregtk2 ####################################### [30%]
4: libwebkitgtk2 ####################################### [40%]
5: icc-profiles ####################################### [50%]
6: libspiro ####################################### [60%]
7: libopenraw ####################################### [70%]
8: libgegl ####################################### [80%]
9: libgimp ####################################### [90%]
10: gimp ####################################### [100%]
Running /usr/lib/rpm/posttrans-filetriggers
Завершено.

Команда apt-get install имя_пакета используется и для обновления уже установленного пакета или группы пакетов. В этом случае apt-get дополнительно проверяет, не обновилась ли версия пакета в репозитории по сравнению с установленным в системе.

При помощи APT можно установить и отдельный бинарный rpm-пакет, не входящий ни в один из репозиториев (например, полученный из Интернет). Для этого достаточно выполнить команду apt-get install путь_к_файлу.rpm. При этом APT проведет стандартную процедуру проверки зависимостей и конфликтов с уже установленными пакетами.

Иногда, в результате операций с пакетами без использования APT, целостность системы нарушается, и apt-get отказывается выполнять операции установки, удаления или обновления. В этом случае необходимо повторить операцию, задав опцию -f, заставляющую apt-get исправить нарушенные зависимости, удалить или заменить конфликтующие пакеты. В этом случае необходимо внимательно следить за сообщениями, выдаваемыми apt-get. Любые действия в этом режиме обязательно требуют подтверждения со стороны пользователя.

⁠5.3.4. Удаление установленного пакета

Для удаления пакета используется команда apt-get remove имя_пакета. Для того чтобы не нарушать целостность системы, будут удалены и все пакеты, зависящие от удаляемого: если отсутствует необходимый для работы приложения компонент (например, библиотека), то само приложение становится бесполезным. В случае удаления пакета, который относится к базовым компонентам системы, apt-get потребует дополнительного подтверждения производимой операции с целью предотвратить возможную случайную ошибку.

Примечание

Для удаления пакетов требуются привилегии администратора.

При попытке с помощью apt-get удалить базовый компонент системы, вы увидите следующий запрос на подтверждение операции:

# apt-get remove filesystem
Обработка файловых зависимостей... Завершено
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
basesystem filesystem ppp sudo
Внимание: следующие базовые пакеты будут удалены:
В обычных условиях этого не должно было произойти, надеемся, вы точно
представляете, чего требуете!
basesystem filesystem (по причине basesystem)
0 пакетов будет обновлено, 0 будет добавлено новых, 4 будет
удалено(заменено) и 0 не будет обновлено.
Необходимо получить 0B архивов. После распаковки 588kБ будет
освобождено.
Вы делаете нечто потенциально опасное!
Введите фразу 'Yes, do as I say!' чтобы продолжить.

Каждую ситуацию, в которой APT выдает такое сообщение, необходимо рассматривать отдельно. Однако, вероятность того, что после выполнения этой команды система окажется неработоспособной, очень велика.

⁠5.3.5. Обновление всех установленных пакетов

Для обновления всех установленных пакетов используется команда apt-get upgrade. Она позволяет обновить те, и только те установленные пакеты, для которых в репозиториях, перечисленных в /etc/apt/sources.list, имеются новые версии; при этом из системы не будут удалены никакие другие пакеты. Этот способ полезен при работе со стабильными пакетами приложений, относительно которых известно, что они при смене версии изменяются несущественно.

Иногда, однако, происходит изменение в именовании пакетов или изменение их зависимостей. Такие ситуации не обрабатываются командой apt-get upgrade, в результате чего происходит нарушение целостности системы: появляются неудовлетворенные зависимости. Например, переименование пакета MySQL-shared, содержащего динамически загружаемые библиотеки для работы с системой управления базами данных MySQL, в libmysqlclient (отражающая общую тенденцию к наименованию библиотек в дистрибутиве) не приводит к тому, что установка обновленной версии libmysqlclient требует удаления старой версии MySQL-shared. Для разрешения этой проблемы существует режим обновления в масштабе дистрибутива — apt-get dist-upgrade.

Для обновления всех установленных пакетов необходимо выполнить команды:

# apt-get update
# apt-get dist-upgrade

Первая команда (apt-get update) обновит индексы пакетов. Вторая команда (apt-get dist-upgrade) позволяет обновить только те установленные пакеты, для которых в репозиториях, перечисленных в /etc/apt/sources.list, имеются новые версии.

В случае обновления всего дистрибутива APT проведет сравнение системы с репозиторием и удалит устаревшие пакеты, установит новые версии присутствующих в системе пакетов, а также отследит ситуации с переименованиями пакетов или изменения зависимостей между старыми и новыми версиями программ. Все, что потребуется поставить (или удалить) дополнительно к уже имеющемуся в системе, будет указано в отчете apt-get, которым APT предварит само обновление.

Примечание

Команда apt-get dist-upgrade обновит систему, но ядро ОС не будет обновлено.

⁠5.3.6. Обновление ядра

APT в дистрибутивах «Альт» автоматом не обновляет ядра вместе с обновлением системы (см. настройки hold в apt.conf), поскольку обновление такого критичного компонента системы может привести к нежелательным последствиям. Вместо этого в систему могут быть поставлены пакеты нескольких ядер и модулей к разным ядрам одновременно.

Для обновления ядра ОС необходимо выполнить команду:

# update-kernel

Примечание

Если индексы сегодня еще не обновлялись перед выполнением команды update-kernel необходимо выполнить команду apt-get update.

Команда update-kernel обновляет и модули ядра, если в репозитории обновилось что-то из модулей без обновления ядра.

Новое ядро загрузится только после перезагрузки системы.

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

После успешной загрузки на обновленном ядре можно удалить старое, выполнив команду:

# remove-old-kernels

⁠Глава 6. Основы сборки RPM-пакетов

⁠6.1. Пакетный менеджер RPM

Все пакеты в Альт Платформа собираются в формате RPM.

RPM (RPM Package Manager) — это семейство пакетных менеджеров, применяемых в различных дистрибутивах GNU/Linux, в том числе и в проекте Sisyphus (Сизиф) и в дистрибутивах «Альт». Практически каждый крупный проект, использующий RPM, имеет свою версию пакетного менеджера, отличающуюся от остальных.

Между представителями семейства RPM могут иметься следующие различия:

наборы макросов, используемых в spec-файлах;

различное поведение RPM при сборке «по умолчанию» — при отсутствии каких-либо указаний в spec-файлах;

формат строк зависимостей;

мелкие отличия в семантике операций (например, в операциях сравнения версий пакетов);

мелкие отличия в формате файлов.

Для пользователя различия чаще всего заключаются в невозможности поставить «неродной» пакет из-за проблем с зависимостями или из-за формата пакета.

RPM в проекте Сизиф также не является исключением. Основные отличия RPM в «Альт» и Сизиф от RPM других крупных проектов:

обширный набор макросов для сборки различных типов пакетов;

отличающееся поведение «по умолчанию» для уменьшения количества шаблонного кода в spec-файлах;

наличие механизмов для автоматического поиска межпакетных зависимостей;

наличие так называемых set-version зависимостей (начиная с 4.0.4-alt98.46), обеспечивающих дополнительный контроль над изменением ABI-библиотек;

до p8 и выпусков 8.x включительно — очень древняя версия «базового» RPM (4.0.4), от которого началось развитие ветки RPM в Sisyphus (в Sisyphus и p9 осуществлен частичный переход на rpm 4.13).

⁠6.2. Утилита командной строки RPM

RPM — это низкоуровневая утилита командной строки, используемая для установки, удаления, обновления, выполнения запросов и проверки целостности пакетов программного обеспечения. Все остальные утилиты управления пакетами в конечном итоге работают через RPM. RPM ничего не знает о репозиториях и оперирует только файлами, пакетами и их зависимостями, для чего использует собственную базу данных (БД). Информация, хранимая в этой БД, в идеале должна соответствовать фактической картине внутри файловой системы. В дистрибутивах «Альт» RPM хранит свою БД в /var/lib/rpm. В один момент времени в системе должен быть запущен лишь один процесс, обращающийся к БД RPM, другие запросы блокируются.

Пакеты могут предоставлять (провайдить) что-либо, требовать (запрашивать) что-либо и конфликтовать с чем-либо, образуя, таким образом, систему межпакетных зависимостей (dependencies). В дистрибутивах «Альт» можно установить пакет, если удовлетворены все его зависимости и нет конфликтов с другими уже установленными пакетами и объектами файловой системы. Из этого следует, что никакими системными файлами нельзя манипулировать непосредственно (вручную), никакое программное обеспечение не стоит устанавливать в обход штатного пакетного менеджера.

Пакеты всегда содержат определенную мета-информацию, на которую ориентируется утилита rpm. Пакеты также могут содержать какие-то файлы, каталоги и символические ссылки. Так называемые мета-пакеты никогда не содержат объектов файловой системы, в них перечисляются только зависимости на другие пакеты.

Основные режимы работы утилиты rpm:

Install: установка пакетов;

Remove: удаление пакетов;

Upgrade: обновление пакетов;

Query: выполнение запросов;

Verify: проверка целостности пакетов.

Примечание

Справку по ключам команды rpm можно получить, выполнив команду

rpm --help

В качестве примера в данной главе используется пакет Yodl-docs (файл yodl-docs-4.03.00-alt2.noarch.rpm).

⁠6.2.1. Вывод информации о пакете

Для вывода информации о пакете, который еще не установлен в систему, используется ключ -qip (Query|Install|Package):

$ rpm -qip package.rpm

где package.rpm — файл пакета.

Например:

$ rpm -qip yodl-docs-4.03.00-alt2.noarch.rpm
Name        : yodl-docs
Epoch       : 1
Version     : 4.03.00
Release     : alt2
DistTag     : sisyphus+271589.100.1.2
Architecture: noarch
Install Date: (not installed)
Group       : Documentation
Size        : 3701571
License     : GPL
Signature   : DSA/SHA1, Чт 13 мая 2021 05:44:49, Key ID 95c584d5ae4ae412
Source RPM  : yodl-4.03.00-alt2.src.rpm
Build Date  : Чт 13 мая 2021 05:44:44
Build Host  : darktemplar-sisyphus.hasher.altlinux.org
Relocations : (not relocatable)
Packager    : Aleksei Nikiforov <darktemplar@altlinux.org>
Vendor      : ALT Linux Team
URL         : https://gitlab.com/fbb-git/yodl
Summary     : Documentation for Yodl
Description :
Yodl is a package that implements a pre-document language and tools to
process it.  The idea of Yodl is that you write up a document in a
pre-language, then use the tools (eg. yodl2html) to convert it to some
final document language.  Current converters are for HTML, ms, man, LaTeX
SGML and texinfo, plus a poor-man's text converter.  Main document types
are "article", "report", "book" and "manpage".  The Yodl document
language is designed to be easy to use and extensible.

This package contais documentation for Yodl.

Примечание

Ключ -p (Рackage) работает не с базой RPM-пакетов, а с конкретным пакетом.

Для вывода информации об установленном в систему пакете используется команда:

$ rpm -qi package

где package — установленный пакет.

Например:

$ rpm -qi bash
Name        : bash
Version     : 4.4.23
Release     : alt1
DistTag     : sisyphus+221902.500.4.1
Architecture: noarch
Install Date: Ср 29 ноя 2023 11:03:45
Group       : Shells
Size        : 0
License     : None
Signature   : DSA/SHA1, Вт 19 фев 2019 16:40:44, Key ID 95c584d5ae4ae412
Source RPM  : bash-defaults-4.4.23-alt1.src.rpm
Build Date  : Вт 19 фев 2019 16:40:42
Build Host  : ldv-sisyphus.hasher.altlinux.org
Relocations : (not relocatable)
Packager    : Dmitry V. Levin <ldv@altlinux.org>
Vendor      : ALT Linux Team
Summary     : The GNU Bourne Again SHell (/bin/bash)
Description :
This package provides default setup for the GNU Bourne Again SHell (/bin/bash).

⁠6.2.2. Установка пакета из файла

Примечание

В команде должен быть указан файл пакета или полный путь к нему.

Для установки RPM-пакета используется ключ -i (Install):

# rpm -i package.rpm

где package.rpm — файл пакета.

Пример выполнения команды:

# rpm -i yodl-docs-4.03.00-alt2.noarch.rpm

В команде можно указать дополнительные ключи -vh (Verbose|Hash). Ключи -v и -h не влияют на установку, а служат для вывода наглядного процесса сборки в консоль. Ключ -v выводит детальные значения. Ключ -h выводит символ «#» по мере установки пакета. Пример выполнения команды:

# rpm -ivh yodl-docs-4.03.00-alt2.noarch.rpm
Подготовка...                 ################################# [100%]
Обновление / установка...
1: yodl-docs-1:4.03.00-alt2   ################################# [100%]
Running /usr/lib/rpm/posttrans-filetriggers

⁠6.2.3. Обновление пакета

Для обновления пакета используется ключ -U (если пакет не установлен, то будет установлен):

$ rpm -Uvh yodl-docs-4.03.00-alt2.noarch.rpm
Подготовка...             ############################################################ [100%]
    пакет yodl-docs-1:4.03.00-alt2.noarch уже установлен

⁠6.2.4. Просмотр файлов пакета

Чтобы получить список файлов, находящихся в пакете, который не установлен в систему, используются ключи -qpl (Query|Package|List):

$ rpm -qpl package.rpm

где package.rpm — файл пакета.

Например:

$ rpm -qpl yodl-docs-4.03.00-alt2.noarch.rpm
/usr/share/doc/yodl
/usr/share/doc/yodl-doc
/usr/share/doc/yodl-doc/AUTHORS.txt
/usr/share/doc/yodl-doc/CHANGES
/usr/share/doc/yodl-doc/changelog
/usr/share/doc/yodl-doc/yodl.dvi
/usr/share/doc/yodl-doc/yodl.html
/usr/share/doc/yodl-doc/yodl.latex
/usr/share/doc/yodl-doc/yodl.pdf
/usr/share/doc/yodl-doc/yodl.ps
/usr/share/doc/yodl-doc/yodl.txt
/usr/share/doc/yodl-doc/yodl01.html
/usr/share/doc/yodl-doc/yodl02.html
/usr/share/doc/yodl-doc/yodl03.html
/usr/share/doc/yodl-doc/yodl04.html
/usr/share/doc/yodl-doc/yodl05.html
/usr/share/doc/yodl-doc/yodl06.html
/usr/share/doc/yodl/AUTHORS.txt
/usr/share/doc/yodl/CHANGES

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

$ rpm -ql package

Например:

$ rpm -qpl yodl-docs

⁠6.2.5. Поиск пакета в системе

Проверить установлен ли пакет в систему можно, выполнив команду:

$ rpm -q пакет

Например:

$ rpm -q yodl-docs

Вывод:

yodl-docs-4.03.00-alt2.noarch

или:

пакет yodl-docs не установлен

Вывести список всех установленных пакетов можно, выполнив команду:

$ rpm -qa

Определить, установлен ли пакет в системе или нет, также можно, выполнив следующую команду:

$ rpm -qa | grep yodl-docs
yodl-docs-4.03.00-alt2.noarch

⁠6.2.6. Список недавно установленных пакетов

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

$ rpm -qa -last

Пример вывода:

usbids-20231116-alt1.noarch                   Ср 29 ноя 2023 20:45:28
pciids-20231116-alt1.noarch                   Ср 29 ноя 2023 20:45:28
ethtool-6.5-alt3.x86_64                       Ср 29 ноя 2023 20:45:28
tree-2.0.2-alt1.x86_64                        Ср 29 ноя 2023 11:04:32
shim-signed-15.4-alt2.x86_64                  Ср 29 ноя 2023 11:04:32
pv-1.6.6-alt1.x86_64                          Ср 29 ноя 2023 11:04:32
mailx-8.1.2-alt8.x86_64                       Ср 29 ноя 2023 11:04:32
lsof-4.93.2-alt1.x86_64                       Ср 29 ноя 2023 11:04:32
…

Чтобы список прокручивался можно указать параметр less:

# rpm -qa -last | less

⁠6.2.7. Узнать пакет по файлу

Узнать к какому пакету относится файл можно, выполнив команду:

$ rpm –qf /путь/к/файлу

Например:

$ rpm -qf /usr/share/doc/yodl-doc
yodl-docs-4.03.00-alt2.noarc

⁠6.2.8. Зависимости пакетов

Чтобы узнать от каких пакетов зависит указанный пакет, используется конструкция:

$ rpm -q --requires пакет

Например:

$ rpm -q --requires yodl-doc
rpmlib(PayloadIsLzma)

Узнать, какие установленные пакеты зависят от указанного можно, выполнив команду:

$ rpm -q --whatrequires пакет

Пример:

$ rpm -q --whatrequires yodl-docs
ни один из пакетов не требует yodl-docs eepm-3.28.1-alt1.noarch

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

$ rpm -q --whatprovides пакет

Пример:

$ rpm -q --whatprovides yodl-docs
yodl-docs-4.03.00-alt2.noarch

⁠6.3. RPM Макросы

Макросы RPM — это прямые текстовые подстановки, которые происходят путем замены определенных выражений и условий на соответствующий текст во время процесса сборки пакета. Иными словами, макросы являются псевдонимами для часто используемых фрагментов текста, применение которых сокращает не только объем ввода, но и делает спецификацию легче читаемой и воспринимаемой. Имена макросов начинаются с символа «%».

Список пакетов, содержащих макросы можно получить, выполнив команду:

$ apt-cache search rpm | grep '^rpm-[bm]' | sort -n
rpm-build-apache2 - Набор утилит для автоматической Web серверов и приложений
rpm-build-browser-plugins - Netscape Gecko Plug-in API common packaging files
rpm-build-compat - ALT Linux compatibility macros for backport purposes
rpm-build-dmd - RPM build enviroment to build D lang(dmd) packages
rpm-build-emacs - Helper scripts and RPM macros to build GNU Emacs extensions
rpm-build-erlang - RPM helper scripts to calculate Erlang dependencies
rpm-build-extra-targets - Build packages for other platforms
rpm-build-fedora-compat-fonts - Build-stage rpm automation for fonts packages
rpm-build-file - Утилита для определения типов файлов
rpm-build-firefox - RPM helper macros to rebuild firefox packages
rpm-build-fonts - RPM helper scripts for building font packages
…

Для использования данных макросов, необходимо добавить в spec-файл строку:

BuildRequires(pre): имя-пакета-с-макросами

Например:

BuildRequires(pre): rpm-build-java

Списки макросов находятся в каталоге /usr/lib/rpm/macros.d/.

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

$ rpm --showrc

Получить значение, раскрываемое макросом можно, выполнив команду:

$ rpm --eval <имя_макроса>

Например:

$ rpm --eval %_sysconfdir
/etc

Макросы можно использовать внутри других макросов. Так, например, если название архива исходных текстов проекта формируется из его имени и версии (директивы «Name» и «Version» транслируются в определенные макросы), то директива задания пути к файлу может выглядеть следующим образом:

Source0: %{name}-%{version}.tar.gz

Примечание

Не следует использовать в спеках внутренние макросы RPM, которые начинаются с двух подчеркиваний (например, %__install или %__mkdir_p).

В Макросы путей системных каталогов перечислены некоторые макросы.

⁠

Таблица 6.1. Макросы путей системных каталогов

Макрос

Описание

%homedir

Домашний каталог пользователя, вызывающего этот макрос

%_licensedir

Каталог лицензий (/usr/share/license)

%_controldir

Каталог control (/etc/control.d/facilities)

%_defaultdocdir

Каталог документации (/usr/share/doc)

%_defattr

Атрибуты файлов и каталогов по умолчанию для каждой секции %files и для каждого файла, включаемого в таких секциях (-,root,root,755)

%_man1dir, %_man2dir, %_man3dir, %_man4dir, %_man5dir, %_man6dir, %_man7dir, %_man8dir, %_man9dir

Каталог man-файлов (/usr/share/man/manX)

%java_dir %_javadir

Каталог для некоторых jar-файлов (/usr/share/java)

%_rpmmacrosdir

Каталог для установки сторонних макросов (/usr/lib/rpm/macros.d)

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

Макрос %setup — используется в блоке %prep. Этот макрос распаковывает архив с исходным кодом (с ключом -q подавляет подробный вывод при распаковке архива). По умолчанию распаковывается первый архив с исходным кодом (т. е. который имеет номер 0), для любых других необходимо использовать дополнительный параметр -a X, где X — номер, совпадающий с таковым у Source.

%prep
%setup -a1 -a100 -a101 -a102 -a103 -a104 -a105
%patch1 -p1

Макрос %setup в Sisyphus RPM использует ключ –q (подавляет подробный вывод при распаковке архива) по умолчанию. Запись %setup -q и %setup — полностью идентичны. Для включения отладочной информации следует использовать конструкцию с ключом -v.

%patch[X] — используется в блоке %prep и выполняет применение указанного патча (X — номер патча, такой же, как и при их описании в преамбуле, если патчей несколько). Применение патчей производится от текущего сборочного каталога, при необходимости обрезать часть пути к изменяемому файлу, можно использовать ключ –p (как и у самой утилиты patch). Например:

%patch3 -p1

Макрос %autopatch позволяет применить все патчи, описанные в основной секции spec-файла, в порядке возрастания их номера в имени. Макрос поддерживает использование ключей -p и -F, аналогичные таким же опциям директивы %patch.

Макрос %configure — применяется в блоке %build и используется для упрощения выполнения ./configure с соответствующими параметрами данной платформы. Почти всегда вполне достаточно выполнить %configure без параметров.

%build
%configure
%make_build

Если скрипта configure в архиве исходных текстов нет (обычное явление для исходников из git или иных SCM), но есть configure.ac — следует добавить перед вызовом %configure макрос %autoreconf.

Макрос %make_build — используется в блоке %build для выполнения команды make. По умолчанию поддерживает при сборке использование нескольких процессоров/ядер.

Макрос %makeinstall_std — применяется в блоке %install. Этот макрос рекомендуется применять вместо макроса %make_install с ключами install и DESTDIR=%buildroot:

%make_install DESTDIR=%buildroot install

Макрос %make_install — применяется в блоке %install. Используется для упрощения установки ПО и представляет собой запуск утилиты make с ключом install, и указанием каталога для установки (DESTDIR=%buildroot) и рядом других ключей:

%make_install DESTDIR=%buildroot install

или

%make_install DESTDIR=%buildroot %_make_install_target

Макрос %makeinstall — применяется в блоке %install. Это редко используемый макрос, предназначенный для установки ПО, Makefile которого не умеет использовать параметр DESTDIR.

Макрос %dir — макрос, используемый в блоке %files, указывающий, что путь является каталогом, который должен принадлежать этому RPM. Это указание важно для того, чтобы RPM точно знал, какие каталоги нужно очистить при удалении пакета.

Макрос %doc — макрос, используемый в блоке %files, обеспечивающий создание каталога документации (%_defaultdocdir/%name-%version) и копирование в него указанных в качестве аргументов файлов. Пути к файлам строятся относительно каталога сборки проекта, например:

%doc Examples

⁠Глава 7. Инструмент GEAR

Gear (Get Every Archive from git package Repository) — система для работы с произвольными архивами программ. В качестве хранилища данных gear использует git, что позволяет работать с полной историей проекта.

Gear поддерживает полный цикл организации репозиториев:

создание репозитория или импорт существующих src.rpm-пакетов;

обновление upstream-кода в репозиториях;

наложение патчей и пакетирование;

экспорт pkg.tar и src.rpm, сборка бинарных RPM-пакетов.

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

Идея gear заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно sed и git) можно было бы собирать пакеты из произвольно устроенного git-репозитория, по аналогии с hasher, который был задуман как средство для сборки пакетов из произвольных «srpm-пакетов».

⁠7.1. Структура репозитория

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

⁠

Одна сущность—один репозиторий

Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакет-предок.

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

Минусы: Несколько сложнее выполнять операции fetch и push в случае, когда репозиториев, которые надо обработать, много. Впрочем, fetch/push в цикле выручает.

⁠

Несжатый исходный код

Сжатый разными средствами (gzip, bzip2 и т.п.) исходный код лучше хранить в git-репозитории в несжатом виде.

Плюсы: Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами (git diff). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, более эффективен на несжатых данных.

Минусы: Поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.

⁠

Распакованный исходный код

Исходный код, запакованный архиваторами (tar, cpio, zip и т.п.), лучше хранить в git-репозитории в распакованном виде.

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

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

⁠

Форматированный changelog

В changelog релизного commit’а имеет смысл включать соответствующий текст из changelog’а пакета, как это делают утилиты gear-commit (обёртка к git commit, специально предназначенная для этих целей) и gear-srpmimport. В результате можно будет получить представление об изменениях в очередном релизе пакета, не заглядывая в spec-файл самого пакета.

⁠7.2. Правила экспорта

С одной стороны, для того, чтобы srpm-пакет мог быть импортирован в git-репозиторий наиболее удобным для пользователя способом, язык правил, согласно которым производится экспорт из коммита репозитория (в форму, из которой можно однозначно изготовить srpm-пакет или запустить сборку), должен быть достаточно выразительным.

С другой стороны, для того, чтобы можно было относительно безбоязненно собирать пакеты из чужих gear-репозиториев, этот язык правил должен быть достаточно простым.

Файл правил экспорта (по умолчанию в .gear/rules) состоит из строк формата:

директива: параметры

Параметры разделяются пробельными символами.

Директивы позволяют экспортировать:

любой файл из дерева, соответствующего коммиту;

любой каталог из дерева, соответствующего коммиту в виде tar- или zip-архива;

nified diff между любыми каталогами, соответствующими коммитам.

Файлы на выходе могут быть сжаты разными средствами (gzip, bzip2 и т.п.). В качестве коммита может быть указан как целевой коммит (значение параметра -t утилиты gear), так и любой из его предков при соблюдении условий, гарантирующих однозначное вычисление полного имени коммита-предка по целевому коммиту.

Правила экспорта из gear-репозитория описаны детально в gear-rules.

⁠7.3. Основные типы устройства gear-репозитория

Правила экспорта реализуют основные типы устройства gear-репозитория следующим образом:

⁠

Архив с модифицированным исходным кодом

С помощью простого правила

tar: .

Все дерево исходного кода экспортируется в один tar-архив. Если у проекта есть upstream, публикующий tar-архивы, то добавление релиза в имя tar-архива, например, с помощью следующего правила позволяет избежать коллизий:

tar: . name=@name@-@version@-@release@

⁠

Архив с немодифицированным исходным кодом и патчем, содержащем локальные изменения

Если дерево с немодифицированным исходным кодом хранится в отдельном подкаталоге, а локальные изменения хранятся в gear-репозитории в виде отдельных патч-файлов, то правила экспорта могут выглядеть следующим образом:

tar: package_name
copy: *.patch

Такое устройство репозитория получается при использовании утилиты gear-srpmimport, предназначенной для быстрой миграции от srpm-файла к gear-репозиторию.

⁠

Смешанные типы

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

⁠7.4. Быстрый старт Gear

⁠7.4.1. Создание gear-репозитория путем импорта созданного ранее srpm-пакета

Исходные данные: srpm-пакет foobar-1.0-alt1.src.rpm со следующим содержимым:

$ rpm -qpl foobar-1.0-alt1.src.rpm
foobar-1-fix.patch
foobar-2-fix.patch
foobar.icon.png
foobar-1.0.tar.bz2
foobar-plugins.tar.gz

Для того чтобы сделать из этого srpm-пакета gear-репозиторий необходимо:

создать каталог, в котором будет располагаться архив:

$ mkdir foobar
$ cd foobar

создать новый git-репозиторий:

$ git init
Initialized empty Git repository in .git/

Получившийся пустой git-репозиторий будет выглядеть примерно следующим образом:

$ ls -dlog .*
drwxr-xr-x 4 4096 Aug 12 34:56 .
drwxr-xr-x 6 4096 Aug 12 34:56 ..
drwxr-xr-x 8 4096 Aug 12 34:56 .git

Таким образом, git-репозиторий готов для импорта srpm-пакета.

импортировать srpm-пакет в git-репозиторий, воспользовавшись утилитой gear srpmimport:

$ gear-srpmimport foobar-1.0-alt1.src.rpm
Committing initial tree deadbeefdeadbeefdeadbeefdeadbeefdeadbeef
gear-srpmimport: Imported foobar-1.0-alt1.src.rpm
gear-srpmimport: Created master branch

После выполнения импорта git-репозиторий будет выглядеть следующим образом:

$ ls -Alog
drwxr-xr-x 1 4096 Aug 12 34:56 .gear
drwxr-xr-x 1 4096 Aug 12 34:56 .git
-rw-r--r-- 1 6637 Aug 12 34:56 foobar.spec
drwxr-xr-x 3 4096 Aug 12 34:56 foobar
drwxr-xr-x 3 4096 Aug 12 34:56 foobar-plugins
-rw-r--r-- 1  791 Aug 12 34:56 foobar-1-fix.patch
-rw-r--r-- 1 3115 Aug 12 34:56 foobar-2-fix.patch
-rw-r--r-- 1  842 Aug 12 34:56 foobar.icon.png

при необходимости в файл правил можно вносить изменения. Например, можно убрать сжатие исходников (соответствующие изменения следует вносить и в .gear/rules).

⁠7.4.2. Создание gear-репозитория на основе готового git-репозитория

Для того чтобы создать gear-репозиторий на основе git-репозитория необходимо:

создать и добавить в git-репозиторий spec-файл;

создать и добавить в git-репозиторий файл с правилами .gear/rules.

⁠7.4.3. Сборка пакета из gear-репозитория

Сборка пакета при помощи hasher осуществляется командой gear-hsh:

$ gear-hsh

Чтобы собрать пакет, который не содержит определения тега Packager в spec-файле, следует отключить соответствующую проверку:

$ gear-hsh --no-sisyphus-check=gpg,packager

Сборка пакета при помощи rpmbuild(8) осуществляется командой gear-rpm:

$ gear-rpm -ba

⁠7.5. Фиксация изменений в репозитории

Для того чтобы сделать коммит очередной сборки пакета, имеет смысл воспользоваться утилитой gear-commit, которая помогает сформировать список изменений на основе записи в spec-файле:

$ gear-commit -a

Прежде чем сделать первый коммит, необходимо сконфигурировать адрес. Это можно сделать глобально, например, прописав соответствующие значения в ~/.gitconfig:

$ git config --global user.name 'Your Name'
$ git config --global user.email '<login>@altlinux.org'

Для отдельно взятого git-репозитория можно сконфигурировать адрес, прописав соответствующие значения в .git/config этого git-репозитория::

$ git config user.name 'Your Name'
$ git config user.email '<login>@altlinux.org'

⁠Глава 8. Инструмент Hasher

Hasher — это инструмент безопасной и воспроизводимой сборки пакетов. Все пакеты репозитория Сизиф собираются с его помощью.

⁠8.1. Принцип действия

Hasher — инструмент для сборки пакетов в «чистой» и контролируемой среде. Это достигается с помощью создания в chroot минимальной сборочной среды, установки туда указанных в source-пакете сборочных зависимостей и сборке пакета в свежесозданной среде. Для сборки каждого пакета сборочная среда создается заново.

Такой принцип сборки имеет несколько следствий:

все необходимые для сборки зависимости должны быть указаны в пакете. Для облегчения поддержания сборочных зависимостей в актуальном состоянии в Sisyphus используется инструмент buildreq;

сборка не зависит от конфигурации компьютера пользователя, собирающего пакет, и может быть повторена на другом компьютере;

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

⁠8.2. Пакеты hasher

hasher в дистрибутиве ALT Platform Builder располагается в пакетах hasher, hasher-priv, которые установлены по умолчанию.

⁠8.3. Справочная информация по hasher

Для получения подробной справки по hasher можно воспользоваться командой:

$ man hsh

⁠8.4. Настройка Hasher

⁠8.4.1. Добавление пользователя

hasher использует специальных вспомогательных пользователей и группу hashman для своей работы, поэтому каждого пользователя, который будет использовать hasher, перед началом работы нужно зарегистрировать:

# hasher-useradd <имя_пользователя>

Эта команда создает вспомогательных пользователей имя_пользователя_a и имя_пользователя_b и добавляет пользователя в группы hashman, имя_пользователя_a и имя_пользователя_b.

Поскольку hasher-useradd изменяет список групп, в которых состоит пользователь, пользователю перед началом работы с hasher необходимо перелогиниться.

⁠8.4.2. Настройка сборочной среды

Для работы hasher требуется создать каталог, в котором будет строиться сборочная среда:

$ mkdir ~/.hasher

Рабочий каталог (в данном случае ~/.hasher) должен быть доступен на запись пользователю, запускающему сборку. Кроме того, его нельзя располагать на файловой системе, которая смонтирована с опциями noexec или nodev — в таких условиях hasher не сможет создать корректное сборочное окружение.

Команда создания сборочного окружения:

$ hsh --initroot-only ~/.hasher

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

hasher берет пакеты для установки из APT-источников. По умолчанию в сборочную среду копируется список источников, указанный в конфигурации APT хост-системы; также можно явно задать дополнительные репозитории, указав альтернативный файл конфигурации APT, например:

$ hsh --apt-config=.hasher/p10-apt.conf --initroot-only ~/.hasher

В таком файле конфигурации (в примере p10-apt.conf) необходимо указать расположение файла с APT-источниками, например:

Dir::Etc::SourceList "/home/user/.hasher/sources_p10.list";

Если необходимо создать сборочную среду, независимую по источникам от основной операционной системы, в вышеуказанный файл помимо строки с источником следует добавить следующую строку во избежание включения /etc/apt/sources.list.d/*.list:

Dir::Etc::SourceParts "/var/empty";

По умолчанию (без указания в команде ключа --apt-config) задействуется общесистемная конфигурация репозитория из /etc/apt/. Чтобы не указывать каждый раз ключ --apt config можно указать его в файле конфигурации ~/.hasher/config, например:

apt_config=/home/user/.hasher/p10-apt.conf

Пример файла ~/.hasher/p10-apt.conf:

Dir::Etc::SourceList "/home/user/.hasher/sources_p10.list";
Dir::Etc::SourceParts "/var/empty";

Пример файла ~/.hasher/sources_p10.list с локальным репозиторием:

rpm file:/srv/public/mirror p10/branch/x86_64 classic
rpm file:/srv/public/mirror p10/branch/ x86_64-i586classic
rpm file:/srv/public/mirror p10/branch/noarch classic

⁠8.5. Сборка в hasher

Сборка происходит от обычного пользователя, добавленного с помощью hasher-useradd:

$ hsh ~/.hasher path/to/package-0.0-alt0.src.rpm

При удачной сборке полученные пакеты будут находиться в каталоге ~/.hasher/repo/<платформа>/RPMS.hasher/, в противном случае на stdout будет выведена информация об ошибках сборки.

Для наблюдения за процессом сборки следует использовать ключ -v.

Создаваемый hasher репозиторий является обычным APT-репозиторием и может быть использован в sources.list[3]. Он также будет использован при дальнейшей сборке пакетов (это поведение можно регулировать ключом --without-stuff).

Если сборочная среда создана в tmpfs (см. ниже), каталог ~/.hasher/repo, вероятно, не переживет перезагрузку системы. Репозиторий можно переместить в постоянное место, указав в файле конфигурации hasher (~/.hasher/config) параметр def_repo=постоянное_хранилище (или вызвав hasher с ключом --repo).

⁠8.6. Сборочные зависимости

Сборочные зависимости RPM делятся на два вида:

необходимые для корректного создания src.rpm из spec-файла (содержащие определения RPM-макросов, используемых в spec-файле);

все остальные (необходимые для непосредственной сборки).

Поскольку hasher собирает пакеты из src.rpm (не считая поддержки gear), то для сборки в хост-системе необходимо иметь установленные сборочные зависимости первого типа. Большинство таких зависимостей (но пока не все) содержатся в пакетах с названием rpm-build-*.

Сборка src.rpm либо завершается неудачно (при отсутствии сборочной зависимости первого типа), либо корректно, поэтому собирать src.rpm-пакеты в хост системе можно с помощью параметра --nodeps:

$ rpm -bs --nodeps package.spec

hasher, в отличие от gear, не предъявляет никаких требований к разделению сборочных зависимостей на первый и второй тип. Однако для совместимости с gear и для улучшения документируемости spec-файла рекомендуется распределять их так:

в поле BuildRequires(pre) помещать сборочные зависимости, требуемые для сборки src.rpm;

в поле BuildRequires — все остальные.

Примечание

В поле BuildRequires(pre) нельзя использовать макросы.

⁠8.7. Монтирование файловых систем внутри hasher

Некоторым приложениям для сборки требуется смонтированная файловая система (например, /proc). hasher поддерживает монтирование дополнительных файловых систем в сборочную среду.

Монтирование происходит при одновременном выполнении следующих четырех условий:

файловая система описана в файле /etc/hasher-priv/fstab, либо является одной из предопределенных: /proc, /dev/pts, /sys;

файловая система указана в опции allowed_mountpoints в конфигурации hasher-priv (/etc/hasher-priv/system);

файловая система указана при запуске hasher в опции --mountpoints, либо указана в ключе known_mountpoints конфигурационного файла hasher (~/.hasher/config);

файловая система указана сборочной зависимостью (например, BuildReq: /proc) собираемого пакета, прямой или косвенной (через зависимости сборочных зависимостей пакета).

Для монтирования /proc необходимо:

в /etc/hasher-priv/system добавить строку:

allowed_mountpoints=/proc

в ~/.hasher/config добавить строку (либо указывать опцию --mountpoints=/proc при сборке пакета):

known_mountpoints=/proc

в spec-файле пакета указать:

BuildRequires: /proc

⁠8.8. Использование нескольких сборочных окружений

hasher не ограничивает пользователей одним сборочным окружением. Первый параметр, передаваемый hsh, указывает на конкретную сборочницу, в которой необходимо производить работу:

$ hsh --apt-conf=.hasher-p10/apt.conf.p10 ~/.hasher-p10 package 0.0 alt0.src.rpm
…
$ hsh --apt-conf=.hasher-test/apt.conf.test ~/.hasher-test package 1.0 alt0.src.rpm
…

По умолчанию используется каталог ~/hasher.

⁠8.9. Сборка пакетов на tmpfs

При наличии достаточного количества памяти на сборочной машине сборку пакетов можно производить на tmpfs — такая конфигурация заметно ускоряет сборку.

Можно взять уже смонтированный /tmp:

$ mkdir -p /tmp/.private/$USER/hasher
$ hsh --repo=$HOME/hasher-repo /tmp/.private/$USER/hasher package 0.0 alt0.src.rpm

Каталог /tmp/.private/$USER/hasher нужно будет создавать после каждой перезагрузки (это можно сделать в файле ~/.hasher/config, воспользовавшись тем, что это shell-скрипт). Указывать --repo нужно для каждой сборки (либо следует указать в .hasher/config параметр def_repo=постоянное_хранилище).

⁠8.10. Отключение проверок sisyphus_check

По умолчанию hasher запускает утилиту sisyphus_check с полным набором тестов. sisyphus_check проверяет не только технические требования репозитория Sisyphus, но и организационные: сборочный хост, подпись PGP-ключом члена ALT Linux Team и т.д., так что в случае сборки пакета не для репозитория Sisyphus возникает необходимость отключить часть проверок.

Для отключения части или всех проверок используется ключ --no-sisyphus-check[=LIST] или, что эквивалентно, опция конфигурационного файла no_sisyphus_check.

Без аргумента этот ключ отключает запуск sisyphus_check вообще:

$ hsh --no-sisyphus-check ~/.hasher package 0.0 alt0.src.rpm

С аргументом, списком отключаемых тестов, отключает только эти тесты:

$ hsh --no-sisyphus-check=packager,gpg ~/.hasher package 0.0 alt0.src.rpm

Cписок тестов можно увидеть в справке sisyphus_check:

$ sisyphus_check --help
…
Valid options are:
…
--[no-]check-buildhost
--[no-]check-buildtime
--[no-]check-changelog
…

Более тонко запуск тестов можно настроить с помощью опций --no-sisyphus-check-in и --no-sisyphus-check-out, с описанием которых можно ознакомиться в man-странице hsh(1).

⁠8.11. Отладка в сборочном chroot

Для отладки сборки иногда полезно запустить shell в сборочном chroot. Для этого используется утилита hsh-shell(1):

$ hsh-shell ~/.hasher

Можно запустить программу и с правами псевдо-root:

$ hsh-shell --rooter

⁠8.12. Ограничение ресурсов

hasher позволяет ограничить ресурсы, выделяемые на сборку: CPU, память, общее время исполнения и другие. Ограничения указываются в конфигурационном файле hasher-priv.

Полный список ограничиваемых ресурсов можно найти в man-странице hasher priv.conf(5).

⁠8.13. Пересборка пакета без пересоздания всего chroot

Развертывание всей сборочной среды и зависимостей идет небыстро.

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

⁠8.13.1. Многократная сборка пакета в одном hasher

Если пакет не собрался можно воспользоваться hsh-shell (предварительно, установив текстовый редактор, shell и прочие инструменты разработчика):

$ hsh-install ~/.hasher vim-console less rpm-utils patchutils zsh
$ mkdir -p ~/.hasher/chroot/.in/src
$ cp -a .vim* .zprofile .zsh_aliases .zshenv .zsh_bind .zshrc .dircolors ~/.hasher/chroot/.in/src
$ hsh-run -- cp -r /.in/src /usr
$ hsh-shell --shell=/bin/zsh

В дереве каталогов hasher есть каталог ~/hasher/chroot/.in, в которой может писать сам пользователь.

Отсутствующие сборочные зависимости можно доставлять с помощью hsh-install (выйдя из chroot).

⁠8.13.2. Многократная сборка пакета при работе с gear

Если используется gear и разработка ведется в базовой системе, вместо hsh можно использовать hsh-rebuild — программу, работающую с уже сформированным сборочным окружением.

Первоначальная сборка (даже если прошла успешно, окружение не удаляется):

$ gear --hasher -- hsh --lazy-cleanup

Повторная сборка:

$ gear --hasher -- hsh-rebuild

Примечание

По окончании работы необходимо выполнить buildreq и забрать spec:

$ hsh-install rpm-utils
$ echo buildreq '/usr/src/RPM/SPECS/*.spec' | hsh-shell
$ cp ~/hasher/chroot/usr/src/RPM/SPECS/*.spec .

⁠Глава 9. Примеры сборки пакетов

Для примера сборки пакета используется программа для вывода системных уведомлений о текущей дате и времени. Ссылки на github-репозитории с исходными текстами программ:

C++: Notification — https://github.com/MakDaffi/notification;

Python: DBusTimer_Example — https://github.com/danila-Skachedubov/DBusTimer_example.

Структура репозиториев для программ Notification и DBusTimer_Example идентична: главный файл (.cpp или .py) и два юнита systemd (.service и .timer):

файл .timer — юнит systemd, который при истечении заданного времени вызывает скрипт .py, выводящий уведомление о дате и времени. После срабатывания таймер снова начинает отсчет времени до запуска скрипта;

файл .service — содержит описание, расположение скрипта .py и интерпретатора, который будет обрабатывать скрипт.

⁠9.1. Пакет с исходными текстами на Python

⁠9.1.1. Подготовка пространства

В первую очередь необходимо склонировать репозиторий в рабочий каталог, используя команду git clone:

$ git clone https://github.com/danila-Skachedubov/DBusTimer_example.git

remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 1), reused 8 (delta 1), pack-reused 0
Receiving objects: 100% (9/9), done.
Resolving deltas: 100% (1/1), done

В рабочем каталоге появится каталог с названием проекта: DBusTimer_Example.

Перейти в каталог DBusTimer_Example и создать в нем каталог .gear:

$ cd DBusTimer_example
$ mkdir .gear

В каталоге .gear создать два файла: файл правила для gear — rules и spec-файл — dbustimer.spec:

$ touch .gear/rules .gear/dbustimer.spec

Содержимое каталога DBusTimer_Example в результате проделанных действий:

$ ls -a1
.
..
.gear
.git
script_dbus.py
script_dbus.service
script_dbus.timer

⁠9.1.2. Написание spec-файла и правил Gear

Следующий этап сборки — это написание spec-файла и правил для gear.

Заполнить файл .gear/rules следующим содержимым:

tar: .
spec: .gear/dbustimer.spec

Первая строка указывает, что проект будет упакован в .tar архив. Вторая строка указывает путь к расположению spec-файла.

Далее необходимо заполнить spec-файл.

В заголовке spec-файла находятся секции Name, Version, Release, Summary, License, Group, BuildArch, BuildRequires, Source0.

Для данного примера можно заполнить секции заголовка следующим образом:

Name: dbustimer
Version: 0.4
Release: alt1

Summary: Display system time
License: GPLv3+
Group: Other
BuildArch: noarch

BuildRequires: rpm-build-python3

Стандартная схема Name-Version-Release, содержит имя пакета, его версию и релиз сборки. Поле Summary включает в себя краткое описание пакета. License — лицензия, под которой выпускается данное ПО. В данном случае — GPLv3. Group — категория, к которой относится пакет. Так как это тестовый пакет, можно указать группу «Other». BuildRequires — пакеты, необходимые для сборки. Так как исходный код написан на python3, необходимо указать пакет rpm-build-python3, который содержит макросы для сборки скриптов Python. Source0 — путь к архиву с исходниками (%name-%version.tar).

В теле, или основной части spec-файла, описываются процесс сборки и инструкции к преобразованию исходных файлов.

В секции %description находится краткое описание программы.

Секция %prep отвечает за подготовку программы к сборке. Макрос %setup распаковывает исходный код перед компиляцией. Пример заполнения полей %description и %prep:

%description
This program displays notifications about the system time with a frequency of one hour.

%prep
%setup -q

В секции %install описываются инструкции, куда в систему конечного пользователя будут скопированы файлы пакета. Чтобы не указывать пути установки файлов вручную, можно использовать предопределенные макросы: %python3_sitelibdir_noarch — раскрывается в путь /usr/lib/python3/site-packages. По этому пути будет создан каталог с именем пакета, в который будет помещен файл script_dbus.py с правами доступа 755. Аналогичная операция будет проведена с файлами script_dbus.timer и script_dbus.service. Они должны быть скопированы в каталог /etc/xdg/systemd/user. Так как макроса, раскрывающегося в данный каталог нет, можно использовать макрос %_sysconfdir, который раскрывается в путь /etc. Пример заполнения секции %install:

%install

mkdir -p \
    %buildroot%python3_sitelibdir_noarch/%name/
install -Dm0755 script_dbus.py \
    %buildroot%python3_sitelibdir_noarch/%name/

mkdir -p \
    %buildroot%_sysconfdir/xdg/systemd/user/
cp script_dbus.timer script_dbus.service \
    %buildroot%_sysconfdir/xdg/systemd/user/

Команда mkdir -p \ %buildroot%python3_sitelibdir_noarch/%name/ создает каталог dbustimer в окружении buildroot по пути /usr/lib/python3/site-packages.

Следующим действием происходит копирование файла script_dbus.py с правами 755 в каталог /usr/lib/python3/site-packages/dbustimer/ в окружении buildroot.

Аналогично создается каталог %buildroot%_sysconfdir/xdg/systemd/user/, в который копируются файлы .service и .timer.

В секции %files описывается, какие файлы и каталоги с соответствующими атрибутами должны быть скопированы из дерева сборки в rpm-пакет, а затем будут копироваться в целевую систему при установке этого пакета. Все три файла из пакета будут распакованы по путям, описанным в секции %install. Пример заполнения секции %files:

%files
%python3_sitelibdir_noarch/%name/script_dbus.py
/etc/xdg/systemd/user/script_dbus.service
/etc/xdg/systemd/user/script_dbus.timer

В секции %changelog описываются изменения, внесенные в ПО, патчи, изменения методологии сборки. Пример секции %changelog:

%changelog
* Thu Apr 13 2023 Danila Skachedubov <dan@altlinux.org> 0.4-alt1
- Update system
- Changed access rights

Итоговый spec-файл может выглядеть следующим образом:

Name: dbustimer
Version: 0.4
Release: alt1

Summary: Display system time
License: GPLv3+
Group: Other
BuildArch: noarch

BuildRequires: rpm-build-python3

Source0: %name-%version.tar

%description
This program displays notifications about the system time with a frequency of one hour.

%prep
%setup

%install

mkdir -p \
    %buildroot%python3_sitelibdir_noarch/%name/
install -Dm0755 script_dbus.py \
    %buildroot%python3_sitelibdir_noarch/%name/

mkdir -p \
    %buildroot%_sysconfdir/xdg/systemd/user/
cp script_dbus.timer script_dbus.service \
    %buildroot%_sysconfdir/xdg/systemd/user/

%files
%python3_sitelibdir_noarch/%name/script_dbus.py
/etc/xdg/systemd/user/script_dbus.service
/etc/xdg/systemd/user/script_dbus.timer

%changelog
* Thu Apr 13 2023 Danila Skachedubov <dan@altlinux.org> 0.4-alt1
- Update system
- Changed access rights

После заполнения файлов данными необходимо добавить эти файлы на отслеживание git. Сделать это можно с помощью команды:

$ git add .gear/rules .gear/dbustimer.spec

После добавление файлов на отслеживание, необходимо запустить сборку с помощью инструментов gear и hasher:

$ gear-hsh ~/.hasher --no-sisyphus-check --commit –v

Примечание

Hasher и git должны быть предварительно настроены.

Если сборка прошла успешно, собранный пакет dbustimer-0.4-alt1.noarch.rpm будет находиться в каталоге ~/.hasher/repo/x86_64/RPMS.hasher/.

⁠9.2. Пакет с исходными текстами на C++

Программа Notification выводит системное уведомление о текущей дате и времени в формате: День недели, месяц, число, чч:мм:сс, год.

В репозитории находятся следующие файлы:

.gear — каталог с правилами gear и spec-файлом;

Makefile — набор инструкций для программы make, которая собирает данный проект;

notify.cpp — исходный код программы;

notify.service — юнит данной программы для systemd;

notify.timer — юнит systemd, запускающий вывод уведомления о дате и времени с периодичностью в один час.

В каталоге .gear находятся два файла:

rules — правила для упаковки архива для gear;

notify.spec — файл спецификации для сборки пакета.

Содержимое файла rules:

tar: .
spec: .gear/notify.spec

Первая строка — указания для gear, в какой формат упаковать файлы для последующей сборки. В данном проекте архив будет иметь вид name-version.tar. Вторая строка — путь к spec-файлу с инструкциями по сборке текущего пакета.

Содержимое файла notify.spec:

Name: notify
Version: 0.1
Release: alt1

Summary: Display system time every hour
License: GPLv3+
Group: Other

BuildRequires: make
BuildRequires: gcc-c++
BuildRequires: libsystemd-devel

Source0: %name-%version.tar

%description
This test program displays system date and time every hour via notification

%prep
%setup -q

%build
%make_build

%install

mkdir -p \
    %buildroot/bin/
install -Dm0644 %name %buildroot/bin/

mkdir -p \
    %buildroot%_sysconfdir/xdg/systemd/user/
cp %name.timer %name.service \
    %buildroot%_sysconfdir/xdg/systemd/user/

%files
/bin/%name
/etc/xdg/systemd/user/%name.service
/etc/xdg/systemd/user/%name.timer

%changelog
* Thu Apr 13 2023 Sergey Okunkov <sok@altlinux.org> 0.1-alt1
- Finished my task

В заголовке spec-файла описаны следующие поля:

Name, Version, Release — стандартная схема Name-Version-Release, содержащая в себе имя пакета, его версию и релиз сборки;

Summary — краткое описание пакета;

License — лицензия, под которой выпускается данное ПО. В данном случае — GPLv3;

Group — категория, к которой относится пакет. В примере указана группа «Other»;

BuildRequires — пакеты, необходимые для сборки. Так как исходный код написан на c++, необходим компилятор g++, система сборки программы — make и библиотека для работы с модулями systemd — libsystemd-devel;

Source0 — путь к архиву с исходниками (%name-%version.tar).

В теле spec-файла описываются процесс сборки и инструкции к преобразованию исходных файлов:

секция %description содержит описание того, что делает программа. В данном примере — вывод системного уведомления с датой и временем;

секция %prep отвечает за подготовку программы к сборке. Макрос %setup с флагом –q распаковывает архив, описанный в секции Source0;

секция %build описывает сборку исходного кода. Так как в примере присутствует Makefile для автоматизации процесса сборки, то в секции указан макрос %make_build, использующий Makefile для сборки программы;

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

notify — скомпилированный бинарный файл. В Unix-подобных системах бинарные файлы располагаются в каталоге /bin. mkdir -p %buildroot/bin — строка, в которой создается каталог bin в окружении buildroot. Следующая строка — install -Dm0644 %name %buildroot/bin/ — установка бинарного файла notify в каталог %buildroot/bin/ с правами 644;

%name.timer, %name.service — юниты systemd. Это пользовательские юниты, которые должны находиться в каталоге /etc/xdg/systemd/user/. В окружении buildroot создается каталог: mkdir –p %buildroot%_sysconfdir/xdg/systemd/user/. В пути использован макрос %_sysconfdir, который заменяется путем /etc. Следующая строка: cp %name.timer %name.service %buildroot%_sysconfdir/xdg/systemd/user/ — переносит данные файлы по заданному пути в окружении buildroot;

секция %files — описывает файлы и каталоги, которые будут скопированы в систему при установке пакета.

⁠Глава 10. Сборка образов с помощью mkimage-profiles

Система генерации дистрибутивов использует все преимущества банка пакетов и позволяет получить установочные образы. Для сборки образа используется утилита mkimage, которая использует для сборки «профиль», представляющий из себя набор файлов Makefile. В результате из пакетов репозитория создается установочный диск CD/DVD. Целостность репозитория и его непротиворечивость позволяют с легкостью генерировать новые образы при необходимости.

mkimage-profiles (m-p) — система управления конфигурацией семейств дистрибутивов свободного программного обеспечения из репозиториев ALT для различных платформ. Целостность репозитория и его непротиворечивость позволяют с легкостью генерировать новые образы.

Концепция:

конфигурация, как и образ — объект постадийной сборки;

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

Особенности:

метапрофиль при сборке может быть доступен только на чтение;

для сборки выбирается предпочтительно tmpfs;

в профиль копируются только нужные объекты (он автономен относительно метапрофиля).

Стадии работы:

инициализация сборочного профиля;

сборка конфигурации образа;

наполнение сборочного профиля;

сборка образа.

Примечание

Сборка образов может занимать большой объем дискового пространства (например, порядка 100 Гб).

Предварительные настройки:

пользователь с правом запуска hasher и подключения /proc к нему (см. Настройка Hasher);

смонтированный tmpfs на несколько гигабайт (можно указать в переменной BUILDDIR):

например, в /tmp или /home/USER/hasher;

каталог из prefix в /etc/hasher-priv/system;

настроенный ~/.gitconfig.

Объекты:

дистрибутивы и виртуальные среды/машины:

описываются в conf.d/*.mk;

могут основываться на предшественниках, расширяя их;

дистрибутивы могут включать один или более субпрофилей;

следует избегать множественного наследования;

субпрофили:

список собирается в $(SUBPROFILES);

базовые комплекты помещены в подкаталоги sub.in/;

наборы скриптов базовых комплектов могут расширяться фичами (features);

фичи (features):

законченные блоки функциональности (или наборы таковых);

описываются в индивидуальных features.in/*/config.mk;

могут требовать другие фичи, а также субпрофили;

накопительный список собирается в $(FEATURES);

при сборке $(BUILDDIR) содержимое фич добавляется в профиль;

списки пакетов (*_LISTS):

не следует создавать фичу, если достаточно списка пакетов;

следует по возможности избегать дублирования (см. bin/pkgdups.);

индивидуальные пакеты (*_PACKAGES): см. conf.d/README.

Результат:

при успешном завершении сборки образ называется по имени цели и укладывается в $(IMAGEDIR):

указанный явно;

~/out/ (если возможно);

$(BUILDDIR)/out/;

формируются отчеты, если запрошены (REPORT).

При запуске на сборку принимается ряд переменных (см. profiles.mk.sample). Переменные могут быть заданы, как в команде сборки в качестве аргументов, так и в файле настроек $HOME/.mkimage/profiles.mk. Список переменных приведен в Переменные, принимаемые при сборке.

⁠

Таблица 10.1. Переменные, принимаемые при сборке

Переменная

Описание

Значение

APTCONF

Задает путь к apt.conf

Пусто (по умолчанию системный) либо строка

ARCH

Задает целевую архитектуру образов

Пусто (по умолчанию авто) либо строка

ARCHES

Задает набор целевых архитектур при параметрическом задании APTCONF

Пусто (по умолчанию авто) либо список через пробел

AUTOCLEAN

Включает уборку (distclean) после успешной сборки образа

Пусто (по умолчанию нет) либо любая строка

BELL

Подает сигнал после завершения сборки

Пусто (по умолчанию нет) либо любая строка

BRANCH

Указывает, для какого бранча производится сборка

не определено — пытается определиться автоматически;

пусто — присваивается значение sisyphus;

имя бранча (sisyphus, p10)

BUILDDIR

Задает каталог генерируемого профиля и сборки

Пусто (по умолчанию авто) либо строка

BUILDDIR_PREFIX

Задает префикс каталога генерируемого профиля и сборки

Строка; по умолчанию выбирается алгоритмически

BUILDLOG

Задает путь к файлу журнала сборки/очистки

$(BUILDDIR)/build.log (по умолчанию) либо строка

CHECK

Включает режим проверки сборки конфигурации (без сборки образа)

пусто (по умолчанию) — проверка не осуществляется

0 — проверяется только конфигурация, списки пакетов не проверяются

другое значение — полная проверка

CLEAN

Экономия RAM+swap при сборке в tmpfs. Очистка рабочего каталога после успешной сборки очередной стадии

Пусто, 0, 1, 2; по умолчанию пусто при DEBUG, иначе 1

DEBUG

Включает средства отладки, может отключить зачистку после сборки

Пусто (по умолчанию), 1 или 2

DISTRO_VERSION

Задает версию дистрибутива, если применимо

Пусто (по умолчанию) либо любая строка

HOMEPAGE, HOMENAME, HOMEWAIT

Указывают адрес, название и таймаут перехода для домашней страницы

Корректный URL, строка, целое неотрицательное число

IMAGEDIR

Указывает путь для сохранения собранного образа

Равно $HOME/out, если существует, иначе $(BUILDDIR)/out (по умолчанию), либо другой путь

ISOHYBRID

Включает создание гибридного ISO-образа

Пусто (по умолчанию) либо любая строка

LOGDIR

Указывает путь для сохранения логов сборки

Равно $(IMAGEDIR) (по умолчанию), либо другой путь

MKIMAGE_PREFIX

Указывает путь до mkimage. Если параметр не указан, то используется системный mkimage

NICE

Понижает нагрузку системы сборочной задачей

Пусто (по умолчанию) либо любая строка

NO_SYMLINK

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

Пусто (по умолчанию) либо любая строка

QUIET

Отключает поясняющие сообщения при сборке (например, под cron)

Пусто (по умолчанию) либо любая строка

REPORT

Запрашивает создание отчетов о собранном образе. Требует включения DEBUG и отключения CHECK

пусто (по умолчанию) — создание отчета выключено

2 — создать архив из каталога отчета

любое другое непустое значение — создать отчет в виде каталога

ROOTPW

Устанавливает пароль root по умолчанию для образов виртуальных машин

Пусто (по умолчанию root) либо строка

SAVE_PROFILE

Сохраняет архив сгенерированного профиля в .disk/

Пусто (по умолчанию) либо любая строка

SORTDIR

Дополнительно структурирует каталог собранных образов

Пусто (по умолчанию) либо строка (например, $(IMAGE_NAME)/$(DATE))

SQUASHFS

Определяет характер сжатия squashfs для stage2

пусто (по умолчанию) либо normal: xz

tight: xz с -Xbcj по платформе (лучше, но дольше — подбор в два прохода)

fast: gzip/lzo (быстрее запаковывается и распаковывается, меньше степень)

STATUS

Добавляет в имя образа указанный префикс

Пусто (по умолчанию) либо строка (например, «alpha», «beta»)

STDOUT

Выводит сообщения, при включенном DEBUG, одновременно в лог и на экран

1 — включить вывод на экран, если включен DEBUG

USE_QEMU

Использовать qemu, если архитектура не совпадает

1 (по умолчанию), для отключения любое другое значение

VM_SAVE_TARBALL

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

tar tar.gz tar.xz

VM_SIZE

Задает размер несжатого образа виртуальной машины в байтах

Пусто (по умолчанию двойной размер чрута) или целое

Примечание

Для того чтобы при указании переменной BRANCH сборка осуществлялась для целевого бранча, требуется:

прописать в ~/.mkimage/profiles.mk:

APTCONF = ~/apt/apt.conf.$(BRANCH).$(ARCH)

создать целевые конфигурационные файлы apt по указанным путям.

Помимо этого переменная BRANCH, если определена, заменяет в имени собираемой цели слово «regular» на «alt-$BRANCH». Таким образом, достигается сборка стартеркитов из профиля регулярок под заданный бранч.

Список доступных целей:

$ make -C /usr/share/mkimage-profiles help

Список доступных образов:

$ make -C /usr/share/mkimage-profiles help/distro

Пример команды сборки образа:

$ make -C /usr/share/mkimage-profiles syslinux.iso

Пример команды сборки образа с указанием переменных:

$ make -C /usr/share/mkimage-profiles DEBUG=1 BRANCH=p10 APTCONF=/etc/apt/apt.conf.local alt-server.iso

Содержимое apt.conf.local может выглядеть так:

Dir::Etc::main "/dev/null";
Dir::Etc::parts "/ver/empty";
Dir::Etc::SourceParts "/var/empty";
Dir::Etc::sourcelist "/etc/apt/sources.list.d/alt-local.list";
APT::Acquire::Retries "3";
APT::Cache-Limit 201326592;
//Acquire::http::AllowRedirect "true";

RPM
{
        Allow-Duplicated {
                // Old-style kernels.
                "^(NVIDIA_)?(kernel|alsa)[0-9]*(-adv|-linus)?($|-up|-smp|-secure|-custom|-enterprise|-BOOT|-tape|-aureal)";
                // New-style kernels.
                "^kernel-(image|modules)-.*";
        };
        Hold {
                // Old-style kernels.
                "^(kernel|alsa)[0-9]+-source";
        };
};

⁠Глава 11. JOIN

⁠11.1. Разработка в ALT Linux Team

ALT Linux Team — команда независимых разработчиков свободного программного обеспечения, которые совместно работают над поддержкой наборов программ в репозитории Сизиф (Sisyphus).

У каждого пакета в Sisyphus есть один или несколько мейнтейнеров. Мейнтейнер — это человек, который собирает пакет для установки программы из централизованного репозитория, исправляет обнаруженные в программе ошибки, общается с разработчиками программы, старается реагировать на нужды пользователей (багрепорты, вопросы). Мейнтейнер должен быть членом ALT Linux Team (команды ALT).

Join — это процесс вступления в ALT Linux Team, результатом которого является возможность непосредственно участвовать в разработке репозитория Сизиф. После прохождения Join кандидат (человек, вступающий в ALT Linux Team) становится мейнтенером.

Для принятия человека в Team создается небольшая команда:

Секретарь команды. Секретарь — это административная должность в ALT Linux Team. В его обязанность входит отслеживать стадии принятия и выполнять административные действия.

Ментор вступающего. Задача ментора — способствовать кандидату со вступлением в Team. Он помогает кандидату со вступлением, отвечает на его вопросы и принимает решение о готовности кандидата.

Рецензент работы вступающего. Задача рецензента — оценить готовность кандидата к вступлению в Team. Рецензент проводит независимую оценку готовности вступающего по результатам его работы и подтверждает его готовность.

Кандидат — вступающий в ALT Linux Team человек.

При взаимодействии друг с другом можно использовать определенный номер стадии, до которой дошел кандидат. Например, секретарь регистрирует ключ кандидата и переводит процесс на стадию 2.2; или ментор решает, что его подопечный готов отправлять пакеты в Сизиф, и переводит процесс на стадию 4.0.

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

⁠11.2. Создание заявки на вступление в ALT Linux Team

Для принятия в Team необходима следующая информация:

имя ментора — участника команды, имеющего желание помогать в процессе приема в Team. Менторов можно искать в списках рассылки или канале Telegram;

псевдоним (имя пользователя) участника. Псевдоним выбирается самим участником. Имя должно начинаться с буквы, содержать только строчные латинские буквы и цифры, быть не короче трех символов;

адрес почты, на который будет производиться пересылка с адреса псевдоним@altlinux.org;

SSH-ключ (ED25519 или RSA с размером не менее 4096 бит). Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для SSH-доступа на ресурсы Sisyphus (git.alt и другие);

GPG-ключ (RSA с размером не менее 4096 бит). В ключе должны быть указаны имя в формате <First name> <Last name> и uid вида псевдоним@altlinux.org. Принимающему нужна публичная часть ключа. Этот ключ будет использоваться для подписи пакетов и для удостоверения личности в почте.

Создание SSH и GPG-ключей описано в разделе Работа с ключами разработчика.

Примечание

Псевдоним — это фактически второе имя человека в команде. Псевдоним лучше выбирать короткий, запоминающийся и не отягощенный мусором. Например, yoda — удобный псевдоним, а travellingwilburys1998 — неудобный. Список уже занятых имен можно посмотреть в пакете alt-gpgkeys.

Заявка на принятие в ALT Linux Team создается кандидатом в Bugzilla (https://bugzilla.altlinux.org/). В данном случае Bugzilla выступает площадкой для вступления в ALT Linux Team. Здесь ведется официальный диалог с кандидатами. Посмотреть прогресс других кандидатов и узнать, какие задачи они взяли можно, по ключевому слову «join».

Примечание

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

Регистрация заявки происходит следующим образом:

на главной странице ALT Bugzilla выбрать ссылку «Зарегистрировать ошибку» или «Новая ошибка»;

выбрать раздел «Team Accounts: ALT Linux Team: присоединение»;

зарегистрировать заявку.

Заявка (баг) должна быть оформлена следующим образом:

в поле «Компонент» необходимо выбрать «join» (в поле «Продукт» должен быть указан «Team Accounts»);

поле «Аннотация» предназначено для краткого описания сути ошибки, здесь можно указать ключевое слово «join» с указанием предполагаемой почты: join user@;

значение поля «Серьезность» можно оставить со значением по умолчанию: «normal»;

платформа определяется автоматически, ее можно изменить, если планируется собирать пакеты для другой платформы в том числе указать «all» — все платформы);

в теле заявки (поле «Подробности») нужно указать псевдоним (имя пользователя) нового участника, адрес пересылки почты, имя ментора, а также несколько слов о том, чем кандидат намерен заняться в ALT Linux Team на момент подачи заявки на вступление (например, «собрать для начала такой-то пакет, а потом пакеты из такой-то области», «помочь со сборкой чего-нибудь», «научиться собирать пакеты» и т. п.). От заявленной кандидатом цели могут зависеть, в частности, требования ментора и рецензента к обретаемым кандидатом навыкам и их пристрастие. Пример комментария к открытой заявке на вступление в ALT Linux Team:

Псевдоним: sova
Почта: Valentin Sokolov <sova@altlinux.org>
Адрес пересылки почты: mail@mail.com
Имя ментора: Grigory Ustinov
Почта ментора: grenka@altlinux.org

Хочу научиться собирать пакеты.

приложить к заявке публичный SSH-ключ и публичный GPG-ключ в виде отдельных приложений (attachments) обычными файлами. GPG-ключ необходимо приложить в экспортированном виде (gpg --export --armor <id ключа>). Файлы можно прикладывать уже после создания заяки. Необходимо убедиться, что экспортирован единственный ключ (gpg %путь-до-файла%);

после создания заявки следует добавить e-mail ментора в поле «Подписчики», чтобы он мог должным образом подтвердить свое менторство.

⁠11.3. Обработка заявки

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

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

После успешного завершения процедуры «Join» секретарь выдает полный доступ в git.alt. Начиная с этого момента, кандидат становится полноправным членом команды.

⁠11.4. Работа с ключами разработчика

При приеме в Team участник предоставляет два криптографических ключа, по которым он идентифицируется в дальнейшем. Необходимо хранить ключи подписи в недоступном для других людей месте.

При утере одного из ключей участник может заменить его, заверив вторым. При утрате обоих ключей участник обязан незамедлительно известить об этом принимающих. Его доступ в git.alt прекращается до восстановления ключей.

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

⁠11.4.1. Создание SSH-ключа

Создать SSH-ключа можно, например, следующей командой:

$ ssh-keygen [-t <тип ключа>] [-b <размер ключа (для RSA)>]

Рекомендуется указывать тип ключа ED25519 или RSA с размером не менее 4096 бит. Ключ настоятельно рекомендуется сделать с паролем.

Пример создания SSH-ключа:

$ ssh-keygen –t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_ed25519.
Your public key has been saved in /home/user/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:7gUUwuricYRlF2mQxl4429Y5Dl2xECRSxcX67yPJrdU user@platform
The key's randomart image is:
+--[ED25519 256]--+
|   .o*=**+o.     |
|    O.*o.oo.     |
|   * O o.+.      |
|  . = +.*        |
|   o . oSo       |
|  o o  ....  .   |
| . +    ...+. E  |
|  .    . .+.+    |
|        . .+..   |
+----[SHA256]-----+

На вопрос о файле сохранения ключа можно ничего не отвечать а принять путь файла ключа по умолчанию, нажав Enter. В этом случае публичная часть ключа — файл ~/.ssh/id_ed25519.pub для ED25519-ключа или ~/.ssh/id_rsa.pub для RSA-ключа.

Примечание

Файлы ~/.ssh/id_ed25519 и ~/.ssh/id_rsa — это секретные (закрытые) ключи. Никогда и никому не следует пересылать секретный ключ.

Для упрощения работы с ключами с паролями можно воспользоваться SSH-агентом.

⁠11.4.2. Создание GPG-ключа

Создать новый GPG-ключ можно, выполнив команду:

$ gpg --gen-key

В процессе ответа на вопросы следует выбрать:

тип ключа — RSA и RSA;

размер — не менее 4096 бит;

срок действия ключа — без ограничения срока действия;

имя — имя в формате <Имя> <Фамилия>;

email — псевдоним@altlinux.org (желательно только латинские буквы нижнего регистра);

комментарий — лучше оставить пустым.

Все входные данные для gpg --gen-key должны быть указаны в ASCII.

Пример создания GPG-ключа:

$ gpg --gen-key
Выберите тип ключа:
(1) RSA и RSA (по умолчанию)
(2) DSA и Elgamal
(3) DSA (только для подписи)
(4) RSA (только для подписи)
Ваш выбор? 1
длина ключей RSA может быть от 1024 до 4096 бит.
Какой размер ключа Вам необходим? (2048) 4096
Запрошенный размер ключа - 4096 бит
Выберите срок действия ключа.
        0 = без ограничения срока действия
    <n>  = срок действия - n дней
    <n>w = срок действия - n недель
    <n>m = срок действия - n месяцев
    <n>y = срок действия - n лет
Срок действия ключа? (0) 0
Срок действия ключа не ограничен
Все верно? (y/N) y

Для идентификации Вашего ключа необходим ID пользователя. Программа создаст его
из Вашего имени, комментария и адреса электронной почты в виде:
"Baba Yaga (pensioner) <yaga@deepforest.ru>"

Ваше настоящее имя: Valentin Sokolov
Адрес электронной почты: sova@altlinux.org
Комментарий:
Вы выбрали следующий ID пользователя:
"Valentin Sokolov <sova@altlinux.org>"

Сменить (N)Имя, (C)Комментарий, (E)адрес или (O)Принять/(Q)Выход? O
Для защиты секретного ключа необходима фраза-пароль.

Экспорт публичной части ключа из связки выполнятся командой:

$ gpg --armor --export псевдоним@altlinux.org

Примечание

Может быть экспортировано несколько ключей с одним uid (email), а требуется один ключ. В подобном случае (например, после редактирования) следует удалить лишние ключи из связки перед экспортом:

$ gpg --delete-key старый/ключ

Для копирования публичной части ключа в файл можно использовать следующую команду:

$ gpg --armor --export псевдоним@altlinux.org > public.key

⁠11.4.3. Модификация GPG-ключа

Необходимо убедиться, что тип ключа — RSA, а размер не менее 4096 бит. Добавить идентификатор в ключ можно с помощью команд:

$ gpg --edit-key псевдоним@altlinux.org
gpg> adduid

Далее следует указать имя (в формате <Имя> <Фамилия>) и uid (email) вида псевдоним@altlinux.org, после чего сохранить изменения:

$ gpg --edit-key псевдоним@altlinux.org
gpg> save

⁠11.4.4. Обновление GPG-ключа в пакете alt-gpgkeys

Для замены просроченного или недействительного ключа, используемого для подписи пакетов, необходимо клонировать последнюю актуальную сборку пакета alt-gpgkeys.git, обновить в нем свой ключ и выложить модифицированную версию на git.alt в свое личное пространство (private repo) — этим подтверждается аутентичность модификации. Далее необходимо (пере )открыть заявку на пакет (компонент) alt-gpgkeys для продукта Sisyphus в Bugzilla и ждать реакции мэйнтейнера.

Можно также приложить новый ключ, экспортированный в текстовый файл, к заявке.

⁠Глава 12. Техническая поддержка продуктов «Базальт СПО»

⁠12.1. Покупателям нашей продукции

«Базальт СПО» предоставляет следующие виды технической поддержки:

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

Поддержка пользователей обеспечивает качественную эксплуатацию продукта. Техническая поддержка эксплуатации продуктов «Базальт СПО» оказывается в объеме SLA. Доступны три уровня SLA («Базовый», «Стандартный» и «Расширенный»).

Право на получение консультационной и технической поддержки вы приобретаете при покупке большинства продуктов торговой марки Альт. Сроки и объём помощи указаны в сертификате технической поддержки.

Условия технической поддержки можно найти на странице сайта «Базальт СПО»: http://www.basealt.ru/support.

⁠12.2. Пользователям нашей продукции

Вне зависимости от того, скачали вы или же приобрели наш дистрибутив, задавать вопросы или обсуждать их с сообществом пользователей дистрибутивов «Альт» вы можете на форуме или в списках рассылки.

Помощь сообщества:

Документация сообщества: https://altlinux.org

Форум: https://forum.altlinux.org

Списки рассылки: https://lists.altlinux.org

Сообщить об ошибке: https://bugs.altlinux.org

Репозиторий: https://packages.altlinux.org

Сборочная среда: https://git.altlinux.org

Telegram-канал сообщества: https://telegram.me/alt_linux

Ресурсы компании «Базальт СПО»:

Сайт компании: https://www.basealt.ru

Контакты: https://basealt.ru/contacts

Новости обновлений безопасности: https://cve.basealt.ru

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