Доброго времени суток, Pavel!
22 Apr 2019 11:28:20, ты -> мне:
PZ>>>>> Посоветуйте с чего начать изучать Астра Линукс, человеку который
PZ>>>>> его в глаза не видел ни разу ?
AV>>>> С осознания того, что его и не надо видеть.
PZ>>> Все так плохо ? :)
AV>> Самый обычный дебилиан.
PZ> Я и его не видел :)
Тогда лучше не смотри.
AV>>>> От тебя что, импортозамещения требуют ?
PZ>>> Hет. В перспективе будет комплекс клиенты которого работают
PZ>>> только на линуксе.
AV>> Комплекс чего?
PZ> Для обслуживания внутренних задач. Сервак с линуксом в облаке, а
PZ> клиенты написаны только под линукс для рабочих мест.
То есть, хоть и не требуют, но ты сам дозрел... это хорошо.
PZ>>> У меня есть варианты - Астра, Альт, Роса и Рэд. Что из них лучше ?
AV>> В приведенном виде список выглядит так: дебилиан, альт, копейка и
AV>> копейка.
PZ> Честно думал, что это уже достойная конкуренция "форточкам", но судя
PZ> по сленгу это далеко не так ?
Астра - слизана с Debian практически полностью.
Альт - забавный гибрид, но развивается самостоятельно.
Роса - основательно перелопатили, но все же оно CentOS.
Ред - тот же CentOS, который даже особо не лопатили.
Все четыре считаются системами "российского производства". По факту этим
более-менее обоснованно может похвалиться только альт.
AV>> Поставь все (желательно одновременно на 4 одинаковых компутера) и
AV>> сравни.
PZ> Hет столько времени у меня для тестов.
Тогда https://www.altlinux.org/Starterkits/Download
Для рабочих станций (чтобы "взлететь" максимально быстро) рекомендую
http://nightly.altlinux.org/p8/permalink/alt-p8-icewm-latest-x86_64.iso
Для серверов (минимальная система, куда потом поставите нужное) возьми
http://nightly.altlinux.org/p8/permalink/alt-p8-jeos-latest-x86_64.iso
Чистая воспроизводимая сборка пакетов делается примерно так:
==== хрум ====
Сборка пакетов в ALT Linux.
Данный текст рассчитан на системных администраторов и devops-инженеров, у
которых уже есть как опыт работы с GNU/Linux и пакетной системой RPM, так и
навыки использования git и rpmbuild.
0. Что понадобится.
* Компьютер. Любой современный x86_64 с достаточным количеством оперативной
памяти: 8 Гб - разумный минимум, 16 Гб - номинал, 32 Гб - хватит для любого
пакета, существующего в репозитарии Sisyphus на момент написания этого текста
(лето 2018 года).
* Установленная система ALT. Если не знаете, что взять за основу, начните с
https://www.altlinux.org/Starterkits/Download (небольшие сборки на базе
стабильной ветки) или, если вы уверены в своей квалификации,
https://www.altlinux.org/Regular (сборки на базе репозитария Sisyphus; он
достаточно стабилен, но иногда (несколько раз в год) мы ухитряемся его
поломать).
* Пакеты hasher [хешер] и gear [гир]. Первый создает временную среду сборки с
полностью чистой системой и запускает в ней rpmbuild, а второй автоматизирует
сборку .src.rpm из git-репозитария. В общем, apt-get update && apt-get install
hasher gear
Да, это многих удивляет, но в ALT Linux совместно с пакетной системой RPM
используется APT. Причина этого банальна: давным-давно, когда возник вопрос о
выборе пакетной системы и средства работы с репозитариями пакетов, было принято
решение использовать лучшее из того, что тогда существовало.
1. Создаем пользователей.
Для работы hasher нужны два дополнительных непривилегированных пользователя:
первый является владельцем системных файлов внутри сборочной среды (подобно
тому, как владельцем системных файлов в обычной системе является root), а от
имени (и с правами) второго внутри сборочной среды запускается rpmbuild. В
документации по hasher они называются rooter и builder, но hasher-useradd по
умолчанию создает для пользователя vasya сателлитов vasya_a и vasya_b - то
есть, "Вася-админ" и "Вася-сборщик".
***@buildhost:~ # hasher-useradd vasya
2. Настраиваем hasher-priv
На данном этапе достаточно указать в файле /etc/hasher-priv/system всего два
параметра:
prefix=~:/tmp/.private
allowed_mountpoints=/proc,/dev/pts
3. Настраиваем hasher для пользователя
Так как hasher постоянно создает и очищает сборочную среду, для ускорения
сборки есть смысл использовать tmpfs. Да, на всякий случай: SSD мы проверяли,
на них все тоже работает, но сам накопитель очень уж быстро "запиливается", да
и по скорости доступа с оперативной памятью не сравнить.
Создаем каталоги:
mkdir -pm755 ~/.hasher/repo ~/my_repo/{,S}RPMS
Для удобства доступа к локальному репозитарию делаем симлинки:
ln -s ../../my_repo/RPMS ~/.hasher/repo/RPMS.hasher
ln -s ../../my_repo/SRPMS ~/.hasher/repo/SRPMS.hasher
ln -s . ~/.hasher/repo/x86_64
Создаем файл ~/.hasher/config такого содержания:
packager="Vasily I. Pupkin <***@example.net>"
def_repo=/home/vasya/.hasher/repo
mountpoints=/proc
no_sisyphus_check="changelog firmware gpg kernel nvr packager perms"
Здесь немного неочевидной является строчка no_sisyphus_check: дело в том, что
hasher изначально разрабатывался для сборки пакетов в репозитарий Sisyphus, и
по умолчанию проверяет, насколько собираемый пакет соответствует требованиям
этого репозитария. Большинство из этих проверок действительно необходимы, очень
многие просто полезны, но некоторые из них сборщик, который не является
участником ALT Linux Team (да, это рекурсивная аббревиатура!), пройти не сможет
в принципе, и их в такой ситуации есть смысл отключить.
И, наконец, создаем рабочий каталог для hasher, если его еще нет - например,
после перезагрузки сборочной машины. Для этого следует добавить в
конфигурационный файл shell (например, ~/.bashrc или ~/.tcshrc) такую строчку:
test -d ~/hasher || ln -sf `mktemp -d -t hasher.XXXXXXXX` ~/hasher
4. Проверяем настройку hasher
Самый простой способ - взять какой-нибудь небольшой (в том числе с не слишком
развесистыми зависимостями) пакет из репозитария Sisyphus и попробовать собрать
его локально:
wget https://mirror.yandex.ru/altlinux/Sisyphus/x86_64/SRPMS.classic/nbd-3.2-al
t1.sr c.rpm
NBD - это технология, позволяющее предоставить доступ к блочному устройству по
сети; в данном случае нам этот пакет интересен лишь тем, что даже на совсем
скромном ноутбуке полностью пересобирается за пару минут одной командой:
time hsh -v nbd-3.2-alt1.src.rpm
Загляните в ~/my_repo/RPMS - там должны появиться файлы nbd-*.x86_64.rpm
5. Сборка из git-репозитария с помощью gear
Как известно, практически вся разработка ПО ведется с использованием git. Для
того, чтобы выполнить сборку пакета, нужно как минимум создать архив с
исходниками командой git archive, завернуть его в .src.rpm посредством
rpmbuild, а потом отдать результат в hasher. Этот набор операций приходится
выполнять при каждой тестовой пересборке, и совершенно неудивительно, что для
него появилось средство автоматизации.
Это средство называется gear, и здесь мы рассмотрим только самый типовой способ
его применения.
Допустим, того же nbd в репозитарии нет, или же нам не нравится, как он собран
(в частности, многие сборщики грешат тем, что даже не пытаются минимизировать
установочные зависимости собираемых ими пакетов), или, как в данном случае, он
просто устарел (официальный сайт гласит, что сейчас самой свежей стабильной
версией является 3.17, а в Сизифе, как мы видели выше, еще только 3.2).
Вытягиваем его из внешнего git-репозитария:
git clone https://github.com/NetworkBlockDevice/nbd
Теперь создаем новую ветку на базе нужного нам тега и переключаемся на нее -
просто для того, чтобы все наши изменения были отделены от апстрима:
git checkout -b sisyphus nbd-3.17
Теперь создаем .spec-файл примерно такого содержания:
Name: nbd
Version: 3.17
Release: vp1
Summary: NBD utilities
License: GPL
Source0: %name-%version.tar.xz
URL: https://github.com/NetworkBlockDevice/nbd
Provides: %name-server = %version, %name-client = %version
BuildRequires: docbook-utils
BuildRequires: glib2-devel
BuildRoot: %_tmppath/%name-%version-root
Group: System/Base
%description
Network Block Device (CONFIG_BLK_DEV_NBD) management utilities
%prep
%setup -q -n %name-%version
%build
./autogen.sh
%configure \
--enable-syslog \
;
%make
%install
rm -rf %buildroot
make DESTDIR=%buildroot install
mv %buildroot%_bindir/* %buildroot%_sbindir/ \
&& rm -rf %buildroot%_bindir
%clean
rm -rf %buildroot %_builddir/%name-%version
%files
%defattr(-,root,root)
%_sbindir/*
%_man1dir/*
%_man5dir/*
%_man8dir/*
%changelog
* Sun Apr 01 2018 Vasily Pupkin <***@example.net> 3.17-vp1
- updated to 3.17
Обратите внимание на параметры Release: и BuildRoot: - в первом используются
инициалы нашего сборщика, что позволяет отличать его пакеты от апстримных altN,
а второй на самом-то деле не особо и нужен, так как сборочная среда внутри
hasher все равно его переопределяет, но мы на всякий случай оставляем
возможность собрать наш пакет и для любой другой системы, использующей RPM.
Аналогично можно было бы обойтись и без секции %clean, так как hasher после
успешной сборки удалит не только эти каталоги, но и весь сборочный контейнер.
И в качестве финального штриха создаем простейший конфигурационный файл для
gear:
echo 'tar.xz: .' > .gear-rules
Дальше все стандартно:
git add --all .
git commit -m 'prepare for automated build'
Все, можно запускать сборку:
time gear-hsh --commit --verbose
Автор данного описания настолько часто использует эту команду, что создал для
нее алиас, который называется просто gh - то есть, "gear-hsh с моими любимыми
параметрами".
P.S.: автор считает необходимым еще раз напомнить, что данный текст адресован
прежде всего системным администраторам и devops-инженерам, которые занимаются
сопровождением разработки ПО для ALT Linux. К сожалению, приведенной здесь
информации заведомо недостаточно для выполнения работы мейнтейнера пакета, а
некоторые из рекомендаций (особенно про отключение проверок Sisyphus) способны
вызвать у участников проекта реакцию в диапазоне от презрительного фыркания до
сердитого рычания, но создание полного руководства мейнтейнера заняло бы
существенно больше времени, так как это уже была бы не короткая статья, а
полноценный учебник.
==== тьфу ====
--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii
... В этой строке не содержится ничего, достойного внимания