I. Документы для alt linux Team



Скачать 363.41 Kb.
Pdf просмотр
страница2/3
Дата04.11.2016
Размер363.41 Kb.
Просмотров444
Скачиваний0
1   2   3
%strip_shared, %strip_static.
Синтаксис этих макросов подробно изложен в /usr/lib/rpm/brp-strip --help.
Автоматическая перекомпиляция python-модулей
Как известно, python-модули обычно компилируют в байтовую фор- му для увеличения быстродействия при последующей работе с ними.
Каждый такой модуль, помимо всего прочего, хранит время своего со- здания и полное имя файла, в котором должен находиться. В связи с последним обстоятельством скомпилированные модули, созданные в результате работы секции
%install
, непригодны, ибо не могут быть использованы после установки пакета.
По этой причине теперь по окончании работы секции
%install производится перекомпиляция всех python-модулей таким образом, чтобы их можно было использовать после установки пакета. В качестве байт-компилятора будет исполь- зоваться программа, имя которой хранится в макросе %__python.
Обычно это /usr/bin/python, однако в некоторых случаях может потребоваться изменить это значение на другое (например, в случае сборки пакета python или если по какой-то причине перекомпиляция не нужна).
Автоматический поиск требуемых и предоставляемых зависимостей
В дополнение к стандартному поиску зависимостей от/для разделя- емых библиотек, реализована поддержка поиска требуемых зависимо- стей для shell- и perl-скриптов, поиска зависимостей, определяемых наличием специальных файлов в пакете, а также поддержка поиска предоставляемых зависимостей для perl-скриптов.

22
Изменение семантики тэгов, управляющих поиском зависимостей
Новые возможности RPM по автоматическому поиску зависимостей при сборке пакетов управляются, как и прежде, значениями тэгов
AutoReq, AutoProv и AutoReqProv. К стандартным значениям yes
/
no
(
true
/
false
), таким образом, добавлены новые возможные значения,
являющиеся именами методов поиска зависимостей:
lib/nolib включение/выключение поиска зависимостей от/для разделяемых библиотек;
shell/noshell включение/выключение поиска зависимостей в shell-скриптах;
perl/noperl включение/выключение поиска зависимостей в perl-скриптах;
files/nofiles включение/выключение поиска зависимостей, определяемых нали- чием специальных файлов в пакете;
default то же, что и yes
;
none, off то же, что и no
;
all включение всех возможных методов поиска зависимостей.
Значением тэга может являться как один метод, так и перечисление методов. По умолчанию, для каждого подпакета собираемого пакета
AutoReq = AutoProv =
yes
, что на практике означает использование макросов %_findreq_default_method и %_findprov_default_method для определения методов поиска зависимостей.
Автоматическая очистка BuildRoot
Перед выполнением секции
%install и по окончании выполнения сек- ции
%clean
RPM автоматически очищает BuildRoot с помощью макро- са %clean_buildroot. Это значит, что больше не нужно использовать

Глава 1. ALT Packaging
23
эти ужасные rm -rf $RPM_BUILD_ROOT. Секция
%clean вообще может (и должна) быть опущена, если в ней не содержится ничего,
кроме этого «rm». В тех редких случаях, когда в spec-файле произ- водится заполнение BuildRoot не в секции
%install
, как это должно быть, а в секции
%build
, что в принципе неправильно, можно перенести точку очистки BuildRoot из начала секции
%install в начало секции
%build
, если заменить директиву
%build на макрос
%buildmulti
Упрощение секции %files
Ранее в начале каждой секции
%files было необходимо указывать атрибуты файлов и каталогов создаваемых пакетов с помощью доволь- но однообразно используемой директивы %defattr. Теперь это проис- ходит автоматически в начале каждой секции
%files
, а также в начале каждого файла, включаемого в секцию
%files с помощью опции
-f
Точнее говоря, в качестве этой директивы используется значение ма- кроса %_defattr. Таким образом, прежнее использование директивы
%defattr в начале секций и файлов следует считать упразднённым.
Сборка пакетов привилегированным пользователем
То, что когда-то было необходимостью, со временем стало излиш- ним, а порой и просто опасным. Теперь, когда все без исключения пакеты можно (и нужно) собирать непривилегированным пользовате- лем во избежание риска разрушения системы и некорректной сборки,
сборка пакетов привилегированным пользователем по умолчанию за- прещена. Этот запрет можно снять путём изменения значения макро- са %_allow_root_build.
Литература
[wwwrpm] Официальный web-сайт rpm: http://www.rpm.org/ .
[mailrpm]
Список рассылки для разработчиков rpm:
rpm- list{@}redhat.com .
[maxrpm]
Edward
Bailey.
February
17,
1997.
Maximum
RPM,
(доступна также online-версия по адресу http://www.rpm.org/max-rpm/ и в формате PostScript по адресу http://www.rpm.org/local/maximum-rpm.ps.gz).
ALT Secure Packaging Policy
Дмитрий Левин
Преобразование оригинального текста в DocBook : Юрий Зотов

24

Массовые операции над файлами и каталогами (секции: %setup, %build,
%install, %pre*, %post*, %trigger*)
При массовой обработке файлов и каталогов (glob expansion, find и др.) НЕОБХОДИМО отделять команду с параметрами от списка аргументов разделителем «
--
» везде, где это поддерживается.
Обоснование: Массовые операции над файлами, имена которых на- чинаются на «
-
», могут давать неверный результат в случае неисполь- зования «
--
».
При использовании утилиты find для изменения файлов и катало- гов НЕОБХОДИМО использовать параметр
-print0
; соответствующие ему параметры других утилит:
xargs: -r0
grep: -Z
sort: -z
Обоснование: Использование find при работе с каталогами, содер- жащими объекты с нестандартными именами (пробелами и др.), без использования
-print0
приводит к неправильному результату.
Пример 1.1. Правильное использование find find -type f -print0 |
xargs -r0 %__grep -FZl ’mawk gawk’ -- |
xargs -r0 %__perl -pi -e ’s/mawk gawk/gawk mawk/g’ --
Операции с временными файлами
При необходимости создания временных файлов и/или каталогов следует использовать утилиту mktemp(1) совместно с командой trap,
например:
TMPFILE="‘mktemp -t somename.XXXXXXXXXX‘" || exit 1
exit_handler()
{
local rc=$?
trap ” EXIT
rm -f -- "$TMPFILE"
exit $rc

Глава 1. ALT Packaging
25
}
trap exit_handler EXIT HUP INT PIPE TERM QUIT
Не следует пользоваться фиксированными либо предсказуемыми именами для создания временных файлов в общедоступных каталогах,
таких как
/tmp
Не следует оставлять временные файлы в случае успешного окончания текущей стадии сборки пакета.
Чужие и системные каталоги и файлы
(секции: %install, %files)
Пакеты НЕ ДОЛЖНЫ включать в свой состав чужие каталоги и файлы, в частности, системные объекты файловой системы, а также файлы устройств (последнее — прерогатива пакета dev
).
Обоснование: У каждого объекта файловой системы, имеющего от- ношение к дистрибутиву, должен и может быть только один владелец
(или группа родственных владельцев в случае, когда несколько подпа- кетов одного пакета совместно используют общий каталог). Это лучше обеспечивает управление атрибутами объектов файловой системы, а также решает многие проблемы определения сборочных зависимостей между пакетами.
Атрибуты файлов и каталогов (секции:
%install, %files)
Права доступа на привилегированные исполняемые файлы
Привилегированные исполняемые файлы, т.е. исполняемые файлы с установленными битами suid и/или sgid, НЕ ДОЛЖНЫ быть доступ- ны по чтению (и тем более по записи) кому-либо, кроме процессов с uid==0
Разделы, предназначенные для использования readonly
Пакеты НЕ ДОЛЖНЫ содержать файлы и каталоги в поддереве
/usr
, разрешающие доступ по записи кому-либо, кроме процессов с uid==0
. Более того, программам, входящим в пакет, во время своей работы НЕ СЛЕДУЕТ полагаться на то, что файловые объекты,
находящиеся в
/usr
, доступны по записи.

26
Файлы и каталоги, доступные для записи
Пакеты НЕ ДОЛЖНЫ содержать файлы и каталоги, доступные для записи всем пользователям. Должны быть предусмотрены меры по разграничению доступа, например, путём предоставления доступа по записи определённой группе(ам).
Владельцы файлов
Пакеты НЕ ДОЛЖНЫ содержать файлы, принадлежащие псевдо- пользователям, если в процессе работы к этим файлам осуществля- ется доступ процессов с другим uid либо с более широкими правами доступа. К таким файлам, в частности, относятся исполняемые, кон- фигурационные и неизменяемые файлы.
Обоснование: Псевдо-пользователь не должен иметь право изменять эти файлы; нарушение этого правила, как правило приводит к оче- видной возможности осуществления pseudouser/root compromise.
Владельцы каталогов
Пакеты НЕ ДОЛЖНЫ содержать каталоги, принадлежащие псевдо- пользователям. Вместо этого следует использовать каталоги, принад- лежащие root, с установленным sticky bit и доступом группы по запи- си.
Обоснование: Псевдо-пользователь не должен иметь право изменять атрибуты каталогов, а также файлы и каталоги, созданные другими пользователями; нарушение этого правила, как правило приводит к возможности осуществления pseudouser/root compromise.
Блокировки (секции: %build, %install,
%files)
Разные пакеты, использующие блокировки для работы с общими файловыми объектами, такими как mbox’ы, во избежание потери данных ДОЛЖНЫ придерживаться единого механизма блокировки.
Например, для блокировки mbox’ов НЕОБХОДИМО использовать метод, за которым закрепилось имя fcntl. Не допускается использова- ние привилегированных программ для dotlocking’а.
Обоснование: Каждая привилегированная программа

это до- полнительная степень риска для системы, в которой такая программа установлена. Поэтому следует минимизировать потребность в подоб- ных средствах. Метод блокировки fcntl опирается на системный вызов fcntl(2)
, удовлетворяющий стандарту POSIX, и, следовательно, более широко распространённый, чем его аналог flock(2)

Глава 2. ALT Linux Maintainer HOWTO
27
Глава 2. ALT Linux
Maintainer HOWTO
Перевод в формат DocBook : Юрий Зотов

Об этом документе
Этот документ предназначен в помощь тем, кто решил присоеди- ниться к команде ALT Linux Team. Здесь вы не найдете полной инфор- мации о том, что такое проект ALT, что такое Sisyphus
2
, как следует правильно собирать пакеты — это удел соответствующих HOWTO.
Команда разработчиков ALT Linux
Team
Вот несколько основных положений об ALT Linux Team:
• ALT Linux Team (в дальнейшем просто ALT) — международная команда разработчиков;
• ALT не занимается противозаконной деятельностью. Это не поли- тическая организация, а сообщество творческих людей;
• ALT занимается любыми проектами, не противоречащими ее идео- логии. На данный момент предпочтение отдается программным проектам; Open Source, однако, если у кого-либо возникнет какая- нибудь новая, интересная и не противоречащая уголовному кодексу идея, то милости просим;
• Участие в ALT не накладывает на участников никаких ограниче- ний и обязательств, разве что кроме диктуемых собственной сове- стью каждого. Можно параллельно участвовать в других проек- тах/организациях/партиях;
• Присоединиться или покинуть ALT может любой человек по соб- ственному желанию и в любой момент времени. Когда будут от- крыты новые заселенные разумом планеты, то инопланетяне также смогут участвовать в этом проекте;
Среди участников особо выделяются:
2
http://www.altlinux.ru/index.php?module=sisyphus

28
Принимающие занимаются процедурами регистрации и отмены оной участников
ALT;
Security Officer занимаются вопросами безопасности основного репозитория. Следят за ошибками, связанными с безопасностью в пакетах и оповещают о них всех пользователей и участников ALT;
Sisyphus gate-keeper стоят перед входом в Sisyphus, так называемым Incoming, и прове- ряют пакеты на соответствие правилам, принятым внутри ALT;
Более подробная информация об ALT Linux Team находится в соот- ветствующем HOWTO.
Sisyphus — основной репозиторий пакетов ALT Linux Team
Sisyphus — это основной репозиторий пакетов ALT Linux Team
3
. Все наработки участников ALT хранятся здесь.
Минимальная единица хранения — пакет. Пакет может быть бинар- ным (содержать исполняемые модули) или с исходным кодом.
Формат пакета един для всего репозитория
• На данный момент основным форматом является RPM;
• Бинарные пакеты собираются под архитектуру i586
;
• Поле
Vendor должно содержать "ALT Linux Team"
;
• Обязательно должен быть Changelog с заголовком в формате
<дата> <мантейнер> <его e-mail> <номер версии и сборки (release)>
• Обозначение сборки должно быть в формате alt<номер>
для новых пакетов и ipl<номер>mdk для старых, переименование со стандарта ipl*mdk на alt*
может происходить только при увеличении версии пакета или при переписывании программы заново;
3
http://www.altlinux.ru

Глава 2. ALT Linux Maintainer HOWTO
29
Для каждого пакета определен один или несколько мантейнеров —
участники ALT, которые следят за его актуальностью и работоспособ- ностью (об обязанностях мантейнеров см. соответствующий раздел данного HOWTO). В каждом пакете есть поле, указывающее на его мантейнера.
Замечание
На данный момент поле
Packager в формате RPM указывает либо на мантейнера (в случае, когда он один), либо на послед- него собиравшего пакет (в случае групповой разработки).
Sisyphus может подразделяться на несколько репозиториев.
На данный момент существуют:
• Основной репозиторий, собственно Sisyphus;
• репозиторий contrib
— сюда попадают все новые и не проверенные пакеты;
• репозиторий classic

объединяет все пакеты, имеющиеся как в основном репозитории, так и в contrib
. Создан для обратной совместимости со старой схемой Sisyphus (до 1 июня 2002);
• Собрание устаревших пакетов (
obsoletes
) — сюда попадают паке- ты с исходным кодом программ, которые морально устарели и в силу этого уже не пересобираются в современном окружении, или которые вытеснены другими (более современными пакетами). По- следнее возможно только по личному пожеланию мантейнера (об этом чуть позже);
• Собрание неподдерживаемых пакетов (
unsupported
) —
пакеты,
которые в силу каких-либо причин (чаще всего это лицензионные ограничения) ALT Linux Team не может поддерживать в полном объеме. Пакеты могут присутствовать как в виде бинарных, так и в виде пакетов с исходным кодом. В отдельных случаях исходный код может отсутствовать в пакете —
это готовая заготовка, из которой вы можете собрать бинарный пакет;
• Собрание заброшенных пакетов (
orphaned
) — пакеты с исходными текстами, которые на данный момент не поддерживаются. Если вы не знаете, за какой пакет взяться, то посмотрите прежде всего в этот каталог;
ALT Linux Team не гарантирует работоспособности входящих в
Sisyphus пакетов. Это полет мысли, текущая разработка, а не готовый к употреблению дистрибутив.
Если мантейнер совершенно не уверен в качестве своей программы и опасается класть ее в Sisyphus, то существует отдельный репозиторий

30
для таких «экстремальных» пакетов — Daedalus. На данный момент туда зачастую попадают нестабильные сборки и alpha-версии пакетов.
Для каждого пакета существует четко определенная схема попада- ния в репозиторий. Исходной точкой является incoming
, конечной —
репозиторий Sisyphus. Маршрут определяется используемой на дан- ный момент технологией.
Перед тем, как попасть в Sisyphus
4
, пакет обязательно проходит руч- ную проверку специально выделенными для этого участниками ALT
(incominger). Пакет проверяется на качество и соответствие правилам сборки и ему может быть отказано в доступе в репозиторий. Если пакет не прошел какой-либо из участков маршрута в репозиторий, то мантейнеру посылается уведомление об этом с указанием причины.
Для каждого репозитория Sisyphus может существовать отдельный incominger.
Пакет может поменять своего мантейнера по одной из следующих схем:
• Если он находится в orphaned более одной недели, то пакет можно взять без чьего-либо разрешения. Перед тем, как положить этот пакет в incoming
, его необходимо пересобрать с увеличением номера версии или релиза;
• Если пакет не находится в orphaned
, то пакет можно взять, получив разрешение у текущего (последнего) мантейнера или группы оных
(определяется по полю
Packager
);
• Если мантейнер не откликается после 5 запросов, то пакет автома- тически переходит в orphaned
;
Все репозитории Sisyphus имеют разный уровень надежности. Далее перечислены текущие репозитории в порядке убывания надежности:
• Основной

contrib

orphaned

unsupported

obsoletes
Перемещение пакета из менее надежного репозитория в более надеж- ный может происходить только после ручной проверки проверяющим
(incominger) более надежного репозитория.
Перемещение из более надежного репозитория в менее надежный может происходить автоматически.
4
http://www.altlinux.ru/index.php?module=sisyphus

Глава 2. ALT Linux Maintainer HOWTO
31
Прием новых участников в ALT
Linux Team
Прием производят специально выделенные участники ALT — при- нимающие.
Претендент посылает к одному из этих принимающих запрос на включение пакета в Sisyphus или Daedalus, с указанием причины,
побудившей его сделать это.
Принимающий подтверждает получение уведомления, возможно,
после совещания с остальными участниками.
Претендент высылает принимающему первичную информацию о себе. Информация посылается по e-mail на адрес

На данный момент это:
• Псевдоним (имя пользователя) участника, выбирается им самим,
если еще не принадлежит существующему участнику. Его длина должна быть по возможности минимальной и он не должен содер- жать цифры;
• Создается новый OpenSSH ключ (DSA,
2048
бит). Принимающему высылается публичная часть ключа. Этот ключ будет необходим для выкладывания пакетов в incoming
(точка входа в репозиторий
Sisyphus);
Замечание
Ключ настоятельно рекомендуется сделать с паролем. В против- ном случае нет никакой гарантии в том, что никто не испортит ваш пакет, действуя от вашего имени.
• Создается/модифицируется существующий GPG/PGP ключ (DSA
and ElGamal,
2048
бит).
В ключе должен быть uid вида
<псевдоним>@altlinux.ru
. Принимающему высылается его публич- ная часть
Ключ высылается в ASCII виде. Экспортирование выполняется следующей командой:
gpg --export --armor [имя ключа] >[файл с экспортированным в←
ASCII ключом]
• Указывается адрес, на который будет пересылаться почта с адреса
<псевдоним>@altlinux.ru

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

).
На первый период принимающий назначает одного из существую- щих мантейнеров в помощь новому участнику.
Обязанности мантейнера
Что должен делать мантейнер:
• Следить за современностью и актуальностью поддерживаемых им пакетов. Регулярно пользоваться этим пакетом (мантейнер должен чувствовать пакет «изнутри», без этого нарушается цикл тестиро- вания и пакет становится неполноценным);
• Быть в курсе разработки софта, входящего в пакет. Это, как минимум, подразумевает участие в списке рассылки типа XXX- announce. Общение с разработчиками софта, входящего в пакет,
желательно, но не обязательно. Участие в разработке софта, вхо- дящего в пакет, желательно, но не обязательно. (это дает возмож- ность иметь в дистрибутиве самую свежую, но при этом рабочую версию софта, а также повышает оперативность исправления оши- бок);
• Незамедлительно исправлять ошибки, связанные с безопасностью по первому запросу Security Officer;
• По мере возможности исправлять ошибки, связанные с некоррект- ным функционированием программ;
• Помогать прикрепленным к нему новым участникам;

Глава 2. ALT Linux Maintainer HOWTO
33
• По возможности активно участвовать в списках рассылок ALT;
Работа с ключами
При приеме участник создает два ключа (на данный момент это
OpenSSH и GPG ключи).
При утере одного из ключей, он может быть восстановлен заверени- ем вторым. Берегите свои приватные ключи!
При утере обоих ключей участник извещает об этом принимающих.
Его доступ в incoming прекращается до восстановления ключей.
Два ключа могут быть восстановлены либо посредством личной встречи с одним из принимающих, либо посылкой их письмом, заве- ренным ключом одного из участников ALT Linux Team. В последнем случае всю ответственность за дальнейшую безопасность репозитория несет участник, заверивший ключи.
Устройство incoming
Возможно существование иерархии incoming для Sisyphus, но основ- ной каталог только один. Структура его четко определена и мантейне- ры обязаны класть пакеты в определенные каталоги, предназначенные для этого.
Достаточно класть только пакеты с исходными текстами, так как они всегда проходят пересборку перед тем, как попасть в основной репозиторий.
Итак,
incoming подразделяется на следующие составляющие:

Sisyphus
— здесь должны появляться пакеты с исходными текста- ми, предназначенные для репозитория. Бинарные пакеты кладутся в подкаталог bin
;

Daedalus
— здесь должны появляться пакеты с исходными текстами и бинарные пакеты, предназначенные для репозитория Daedalus;

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

34
Пожалуйста, придерживайтесь этой структуры каталогов, не созда- вайте своих подкаталогов. Sisyphus gate-keeper оставляет за собой пра- во не брать пакет, если он лежит в неправильном месте.
В помощь начинающему разработчику
Возможные причины отказа в доступе к
Sisyphus для пакета
Вот несколько причин, по которым пакету может быть отказано в доступе в репозиторий (более подробные сведения находятся в ALT-
Packaging-HOWTO):
• Несоответствие требованиям репозитория (см. выше);
• Пакет не подписан GPG-ключом мантейнера;
• В пакете недопустимые
%post
,
%preun
,
%pre скрипты. Например:
• нельзя изменять на этапе установки/удаления какие-либо си- стемные файлы;
• не допускается доустанавливать дополнительные программы,
производить их перемещения из одного места в другое;
• Недопустимые права на файлы (немотивированный SUID/SGID,
World-writeable файлы);
• Ложные или недопустимые зависимости пакета (Requires);
• Ложные или недопустимые зависимости сборки (BuildReqs);



Поделитесь с Вашими друзьями:
1   2   3


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал