Единое окно доступа к образовательным ресурсам

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

Голосов: 0

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

Приведенный ниже текст получен путем автоматического извлечения из оригинального PDF-документа и предназначен для предварительного просмотра.
Изображения (картинки, формулы, графики) отсутствуют.
        Новые alternatives также имеют более надёжный подход к орга-
низации базы данных. Простые shell-скрипты как результат удачного
формата конфигурационных файлов. Кроме того, вместо «группового»
подхода к альтернативам, применяется «покомпонентный». Благодаря
этому снялись ограничения на отношения master/slave и значительно
упростились алгоритмы обработки.

csed vs. color-gcc
      Упрощение концепции, пример когда использование стандартного
конвейера наделяет приложение новой функциональностью. Если color-
gcc был пригоден только для gcc, то csed может уже применяться сов-
местно любым приложением командной строки, например, ps, tail, cat,
и т. д.



16:15–16:40
Алексей Гладков                                      Москва, ALT Linux

       Новые технологии проекта Sisyphus:
            жизненный цикл пакета

    Аннотация:
    В докладе рассказывается о текущей схеме приёма пакетов, о про-
    блемах, с которыми сталкиваются люди, следящие за приходящими
    пакетами. Предлагаются возможные решения этих проблем на приме-
    ре новой системы проверки входящих пакетов — проекте incominger.

    Проверка пакетов, поступающих в репозиторий Sisyphus, являет-
ся одной из важнейших задач. С момента создания проекта Sisyphus
был предпринят ряд шагов по автоматизации проверки поступающих
пакетов на соответствие общим требованиям, предъявляемым к паке-
там Sisyphus. В частности, была создана программа sisyphus_check.
Для гарантии пересобираемости пакета была создана система hasher,
позволяющая осуществить пересборку пакета в «чистом» окружении,
созданном из текущего состояния Sisyphus. Следующим шагом в авто-
матизации прохождения пакета в репозиторий стало создание системы
автоматизированной проверки входящих пакетов — проекта incominger.

                                  101


    Целью этой системы является выполнение стандартных действий
над пакетами для осуществления входного контроля. Incominger осно-
вывается на трёх других проектах: osec, hasher и sisyphus_check.
    На вход этой системы подаются пакет(или пакеты). На выходе из
неё эти пакеты сортируются по двум директориям:
   • директория для пакетов, проходящих в Sisyphus;
   • директория для не проходящих.
В целом работу программы можно разбить на 3 стадии:
   • получение пакетов;
   • предварительная проверка пакетов;
   • пересборка (если она нужна);
   • последующая проверка;
   • формирование отчёта.
    Получение пакетов может производится из одного или нескольких
мест. Также поддерживается несколько разных способов получения па-
кетов, на текущий момент поддерживаются:
   • local folder — возможность забирать пакеты из локальной
     директории;
   • package list — возможность задать файл со списком файлов;
   • folder over ssh — возможность получать пакеты через ssh;
   • rsync — возможность получать пакеты через rsync.
    На следующей стадии производятся быстрые проверки, которые
позволяют заключить, что пакет содержит грубые ошибки и дальнейшие
проверки проводить не следует (например, можно даже не пробовать
пересобирать пакет, если у поступившего исходного пакета отсутству-
ет gpg подпись). Так как любой из приходящих пакетов может нести
угрозу безопасности системы, то работа с ними не должна проводится
в реальой (рабочей) системе. Для обеспечения безопасности проверка
пакетов имеет следующий порядок:

  1. Создается «путой» chroot.

                                 102


  2. В chroot устанавливаются пакеты необходимые для
     осуществления проверки на этой стадии.
  3. В chroot копируется первый из очереди и проверяется. Далее
     копируется и проверяется следующий пакет. Этот этап
     повторяется для всех поступвших пакетов.

     Любой не нормальный код возврата программ в chroot считается
ошибкой и пакет — не прошедшим проверку. В идеале для каждого па-
кета должен создаваться новый chroot, но на данный момент этого не
делается.
     После того, как пакеты пройдут предварительные проверки, их
можно попытаться пересобрать. Эта стадия не является обязательной
и может быть пропущена. Необходимость этой стадии определяется в
конфигурационном файле для каждого места, куда выкладываютя паке-
ты, предназначенные для репозитория Sisyphus.
     Пересборка пакетов производится с помощью hasher. К сожалению,
очень трудно выяснить, в каком порядке нужно пересобирать пакеты,
потому что в исходном пакете не содержится явного списка бинарных
пакетов, которые могут быть из него собраны. Поэтому все пакеты вы-
страиваются в единую очередь. На данный момент она формируется по
дате сборки исходных пакетов. Пакеты, имена которых начинаются с
префикса ’lib*’ переносятся в начало очереди. Пакеты в очереди пересо-
бираются циклически. Удачно пересобравшиеся и не пересобравшиеся
пакеты удаляются из очереди. Каждый удачно собравшийся пакет поме-
щается во временный репозиторий. Этот репозиторий используется при
каждой новой попытке сборки из очереди. Если пакет не пересобрался
по причине того, что для его сборки не хватает каких-либо пакетов или
не хватает пакетов определённой версии, то пересборка пакета не счи-
тается неудачной и откладывается. После того как достигается конец
очереди, процесс пересборки начинается сначала. Пересборка останав-
ливается тогда, когда на очередном цикле очередь не уменьшится ни на
один пакет.
     После стадии пересборки в hasher становится не важно, откуда был
получен пакет. И можно считать, что все пакеты, попавшие в систему
incominger, правильно пересобираются.
    Далее выполняется последующая проверка удачно пересобравших-
ся пакетов. В неё входит проверка с помощью sisyphus_check и проверка
на корректную устанавливаемость. Для этого создаётся новый chroot,
в нем устанавливаются все необходимое для установки проверяемого


                                 103


пакета. После этого запускается программа osec, затем в chroot уста-
навливается проверяемый пакет и снова запускается osec. Затем пакет
удаляется и опять запускается osec. Таким образом можно узнать, ка-
кие файлы были созданы и изменены после установки бинарного пакета
и какие были удалены после его удаления. Если после установки пакета
меняются права у файлов, ему не принадлежащих, или после удаления
пакета остаются какие-нибудь принадлежащие ему файлы, то считает-
ся, что пакет содержит ошибки и он не пропускается в репозиторий
Sisyphus.
     На последнем этапе формируется детальный отчёт о проверке па-
кетов. По этому отчёту можно вынести решение, пропускать или нет
пакеты в Sisyphus и если не пропускать, то по какой причине.
     17:00–17:30: Кофе
     17:30–18:00: Закрытие конференции
     19:00–19:30: Отъезд на Linux Fest (по желанию)




                                104



    
Яндекс цитирования Яндекс.Метрика