WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 |   ...   | 9 | 10 ||

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

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

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

ncursesxx/ndk++ vs. ncurses++ curses — отличный пример неудачно спроектированной библиотеки.

C++ bindings к ncurses отражают всю громоздкость и неразбериху этой библиотеки, пытаясь охватить сразу всё, что только возможно. Мы предлагаем свой вариант. Это пример правильного разделения библиотеки на слои, ncurses++ предоставляет только базовую функциональность: работа с окнами (изменение размера, перемещение, рисование) и терминалами (ввод/вывод, изменение атрибутов). ndk++ — поддержка событий и сложных виджетов. Что ещё в самом ncurses планируется переделать в том же ключе: terminfo — пример смешения вывода и получение информации из базы, ncurses — смешение ввода и вывода данных в окна.

osec vs. AIDE, tripwire, mtree Задача проекта состояла в однократном отчёте об изменениях в файловой системе с обращением особого внимания на security-sensitive файлы. Чем не устраивают уже существующие средства контроля целостности Перегруженной функциональностью, а также использованием собственных версий функций для обхода файловой системы и создания/ведения базы данных. Более того, все эти приложения работают с избыточными полномочиями в системе, что нежелательно с точки зрения безопасности.

Новый проект osec — пример превращения в конвейер: сборка данных, генерация отчёта, рассылка отчёта. Для работы используются готовые системные функции: fts — для быстрого и безопасного обхода файловой системы, cdb — быстрая и удобная библиотека для создания read-only баз данных. Все составные части osec устроены относительно просто.

alternatives vs. update-alternatives Изначально в Sisyphus использовалась система альтернатив, взятая от Debian, однако в ходе эксплуатации был выявлен ряд проблем и недостатков функциональности. Новый проект alternatives призван решить эти проблемы. Это пример «комбайн вместо набора утилит».

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

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

16:15–16:Алексей Гладков Москва, ALT Linux Новые технологии проекта Sisyphus:

жизненный цикл пакета Аннотация:

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

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

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

Целью этой системы является выполнение стандартных действий над пакетами для осуществления входного контроля. Incominger основывается на трёх других проектах: osec, hasher и sisyphus_check.

На вход этой системы подаются пакет(или пакеты). На выходе из неё эти пакеты сортируются по двум директориям:

• директория для пакетов, проходящих в Sisyphus;

• директория для не проходящих.

В целом работу программы можно разбить на 3 стадии:

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

• предварительная проверка пакетов;

• пересборка (если она нужна);

• последующая проверка;

• формирование отчёта.

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

• local folder — возможность забирать пакеты из локальной директории;

• package list — возможность задать файл со списком файлов;

• folder over ssh — возможность получать пакеты через ssh;

• rsync — возможность получать пакеты через rsync.

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

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

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

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

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

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

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

После стадии пересборки в hasher становится не важно, откуда был получен пакет. И можно считать, что все пакеты, попавшие в систему incominger, правильно пересобираются.

Далее выполняется последующая проверка удачно пересобравшихся пакетов. В неё входит проверка с помощью sisyphus_check и проверка на корректную устанавливаемость. Для этого создаётся новый chroot, в нем устанавливаются все необходимое для установки проверяемого пакета. После этого запускается программа osec, затем в chroot устанавливается проверяемый пакет и снова запускается osec. Затем пакет удаляется и опять запускается osec. Таким образом можно узнать, какие файлы были созданы и изменены после установки бинарного пакета и какие были удалены после его удаления. Если после установки пакета меняются права у файлов, ему не принадлежащих, или после удаления пакета остаются какие-нибудь принадлежащие ему файлы, то считается, что пакет содержит ошибки и он не пропускается в репозиторий Sisyphus.

На последнем этапе формируется детальный отчёт о проверке пакетов. По этому отчёту можно вынести решение, пропускать или нет пакеты в Sisyphus и если не пропускать, то по какой причине.

17:00–17:30: Кофе 17:30–18:00: Закрытие конференции 19:00–19:30: Отъезд на Linux Fest (по желанию)

Pages:     | 1 |   ...   | 9 | 10 ||






















© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.