UNИX, осень 2009, 05 лекция (от 28 октября)

Материал из eSyr's wiki.

• Аудиозапись: http://esyr.org/lections/audio/uneex_2009_winter/uneex_09_10_28.ogg

Что лектор хотел напомнить: план на ближайшие n-1 занятие: лектор писал те действия, те виды работ, которые необх. вып. ментейнеру, там были пункты:

1. Средства сборки
2. Добыча ups
3. Составление spec
4. Правка
5. Тестирование
6. Помещ. в хранилище
7. Сопровождение

Лектору осталось прочитать 7 лекций, следующкю лекцию прочитает gq про дебиан.

Сейчас лектор решил сосред. на среде сборки. Почему это важно? Если собирается на собственной, боевой машине, то возн. две проблемы:

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

Сегодня лектор начал с того, что он собрал фаерфокс так, что он печатает только в формате Letter.

Есть ещё две проблемы, которые хотело сь бы преодолеть:

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

Лектор недавно наткнулся на статью, где написано про то, как решают эти проблемы в федоре и дебиане. В дебиане есть pbuilder(?), в федоре есть moc(?). Лектору показалось, что им до хэшера далеко. Лектор не отрицает, что с появлением виртуализации, возможности, предост. hasher'ом, не такую сильную выгоду предст. пользователю. Тем не менее, с т. з. юзабилити хэшер тем не менее довольно много даёт.

На сайте есть ссылка на руководство по хэшеру.

Лектор сейчас расскажет, что это такой за зверь.

1. Используется chroot. Идея в том, чтобы окр. собирать в чруте, а не на хосте. Если есть соотв. инстр., то можно сразу решить проблему номер 3, а именно, указав вашему пакетному дисп. ставить пакеты из опр. хранилища. Если внимательно посм. на этот процесс и посм., как устр. работа хэшера, то можно увидеть, что не всё так просто. ... Тем не менее, использование чрута решает сразу три проблемы. На самом деле, чтобы обесп. большую безопасность, дост. одного шага. Есть такая технология, называемая fakeroot. Все файловые операции, которые вып. программа, проходят через спец. библиотеку, которая подм. uid, и все прогр., которые выполн. в fakeroot, думают, что они вып. от рута. На самом деле, действий, которые польз. может выполн. вместо рута, в чруте гораздо больше, нарпимер, уст. пакета (копир. файлов). Есть ряд действий, которые тем не менее, нужен рут. ... Например, есть ряд устройств, которые нужны (/dev/null, /dev/zero), их создают из под рута. Всевозм. другие действ., которые происх. от рута, как то, создание всевозможных устройств, они вообще не произв., а запис. fakeroot в спец. журнал. И когда одна рпогр. из под фейкрута созд. устр., а другая из под него читает, то fakeroot подменяет сист. вызовы с исп. этого файла. Таким обр., можно вып. действия, которые вып. рут, не нарушая безопасности. Поэтому можно всё делать, ничего не ломая. Будут два обычных пользователя.

Есть список из 8 пунктов, как именно хэшер работает пошагово. Чтобыб ыло понятно, как это делать. Леткор просит заметить, что в процедуре учас. три пакета: U (вы), C (сборка), R (как бы рут). Эта процедура, длиннее, чем могла бы быьт, чтобы более-менее надёжно доказать отсутствие побочных эффектов:

1. C порождает aptbox. Это набор конфигов и всяких штук, чтобы apt нормально работал.
2. Удаление предыдущей среды
3. Скелет сборочной среды. Речь идёт о дереве каталогов и буквально трёх программах — shell, cpio, find, которые притом собраны статически. С помощью этих трёх программ можно сделать минимальные вещи.
4. R — установка базовой установочной среды.
5. R — установка базовой сборочной среды
6. Проверка исх. пакета. В этот момент расп. src.rpm, расп. спект, спек анализир. на соот. полиси. Если что, он начинается ругаться, вот здесь выглядывает sisyphus-check. Если этот src.rpm качественный, то он просто уст. туда же от лица пользователя С. (Когда уст. src.rpm, он раскладывается в каталоге пользователя)
7. Порождается сборочная среда пакета. Список сборочных зависимостей определяется пользователем U. Запускает apt и лезет в apt-box пользователь C, наконец, пользователь R эти пакеты ставим.
8. Собственно, всё. U делает сборку.

Что призвана эта схема обеспечить? Этасхема призвана обеспечить передачу инф. в обратную сторону. Не смотря на то, что ни один польз. не явл. привилегированным, всё нацелено на то, чтобы вы не могли пострадать. Идея в том, что все процессы сборки запускаются от других пользователей. Как следствие, даже если они вылезут из-под рута, то они всё равно не смогут модифицировать ваши файлы.

Какие бонусы получает разработчик:

1. ТАкая схема полностью удовлетворяет всем 4 требованиям. В числе прочего. Если нужно пакет просто пересобрать (например, в случае изменения soname библиотеки), то такая пересборка делается одной командой: hsh package.src.rpm. После чего происх всё, что тут написано, после чего в спец. хранилище, ~/hasher/repo/..., появл. собранный пакет. Помимо того, что сбр. среда что-то собирает не глядя, она офрм. репозиторий, она содерж. все те пакеты, который вы через hasher собирали, и можно прямо оттуда обновляться. Лектор понимает, что любой человек, имеющий дело с дистр., может руками сделать репозиторий из пакетов (при помощь genbasedir), но коли эта среда сборки, то она и репо делает. Кроме того, в случае сборки библиотеки и прилож., от них зависящих, то других вариантов нет.
2. Можно собирать пакеты, не имея рута на машине. Для того, чтобы уст. пакет в окр., исп. hsh-install package. Типичный пример — когда вы собираете пакет, то сначала накидываете всех зависимостей, потом запускаете buildreq. Вы можете составить какое угодно сборочное окружение, лишь бы Вы имели право запускать хэшер. Для этого вам должны быть созданы два пользователя, прописаны соотв. группы, после чего можно всё делать.

Собственно, по болшому счёту, всё.

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

Тут надо заметить две вещи: при каждой новой сборке всё удалёется. Хорошо это или плохо? Разумеется, хорошо, поск. именно с засорением окружения боролись. Это неудобно, если Вы исп. окружение как полигон для сборки. Чтобы это предоствратить, можно говорить hsh --lazy-cleanup, тогда, чистка среды не будет производиться (в слдучае усп. сборки без --lazy сборочная среда удаляется)

Вообще, пользование hsh-shell не есть изолир. сборочное окруж. от начала до конца, это инстр. пользования средой сорки.

Лектор показывает, как с помощью hsh-shell делается удобнее, а не более громоздким.

Недостатки:

• Если вы начинаете чинить пакет в сбор. окр. То важно не забыть две вещи: если вы что-то меняли, особенно, что-то доставляли, то важно не забыть запустить buildreq, иначе получится, что пакет опять в след. раз не заберётся. Второе --- не забыть забрать спеку. Лежит она в ~/hasher/chroot/usr/src. Рекомендуется после удачной сборки таки делать чистый запуск. --- отголоски уникальной сборки

Можно иметь неск. конф. айлов для apt, где будет лежать правильный sources.list, и запуская hsh с соотв. ключом, то можно собирать пакеты под разные архитектуры, если под них пожно созд. сбороч. окружения. Есдинст. реально исп. пример: сборка x86 на x86-64.

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

Вжная вещь: всё-таки, как ни крути, даже с учётом исп. apt-box, даже не смотря на то, что есть некая возм. не ставить пакеты, вс-таки процесс сборки пакета гораздо более резурсоёмкий процесс в плане количества дисковых операций. Фактически, это полные уст., запуск и удаление небольшого дистрибутива. Поэтому рек. исп. файловые системы в памяти. Но даже если памяти не так много, но большой своп, то линуксовый tmpfs позв. сделать 6-гиговый tmp, это норм. ситуация. Даже в этом случае работа в хэшере намного быстрее.

(спор с gq по поводу райзера и кэшей)

Есть один момент: если ~/hasher лежит в tmpfs, то не очень хорошо добавлять repo в sources.list, поск. после перезагрузки он исчезнет. Благо, у хэшера есть соотв. натср., которая позв. положить реп. в статическое место.

В реальности метнейнер не польз. hsh напрямуй, это ничего не меняет в рпоцессе, но добавляет некую гибкость. Исп. несколько иное окружение, с настройками для gear, и процесс сборки для него прозрачен. Фактически, происх. можиф. спеки, далее запускаете gear, он соберёт src.rpm, одаст hsh и так далее.

На сегодняшний момент сизиф --- репозиторий не исходников, а того, над чем идёт работа. В качестве vcs исп. git.

В частности, многие разработчики держат два бранча, с апстримом и своими хаками, после чего gear собирает srpm с тарболлом апстрима и патчами разр.

...

hsh-rebuild ...

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

На сегодняшний день в bsd есть easyjail. Там вместо создания сбор. окр. делается хардлинк на шаблон, кроме того, благодаря снапшротам, изменения обратно не проходят. Видимо, с помощью этого легко автоматизировать сборку пакетов.

Чего лектор сегодня не рассказал: про изолир. окр. в fedora.

В след. раз дебиан.

Чрез неделю занимаемся пунктами 1 и 2.