WWW.DISSERS.RU

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

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


Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |

утопия и реальность Конфигуратор - это средство быстрой (типовой, автоматической, непрофессиональной и т. п.) настройки операционной системы. Подобные средства есть во всех ОС, однако способ организации дистрибутивов Linux предъявляет к конфигуратору особенные требования. Полнофункциональные конфигураторы появились в Linux не сразу, а только после того, как настройка системы и служб перестала быть разовой высокопрофессиональной работой и перешла в руки операторов, а не администраторов системы.

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

В то время, как UNIX-системы, развивающиеся по модели ПО ЗК (программное обеспечение с закрытым кодом), легко решали задачу обновления установщика с каждым выпуском дистрибутива, Linux-системы и подобные им, основанные на ПО ОК (программное обеспечение с открытым кодом), столкнулись с трудностями: работа по постоянному воссозданию конфигуратора силами одной рабочей группы очень трудоёмка. Такая работа требует усилий сразу многих специалистов: системного аналитика, системного администратора, программиста (в том числе, знакомого с программированием пользовательского интерфейса), дизайнера и т. д. Сложность конфигуратора пропорциональна сложности дистрибутива.

Следовательно, конфигуратор Linux-системы должен создаваться с активным привлечением всего сообщества, причём самостоятельное расширение функциональности должно быть доступно в первую очередь членам сообщества, системным администраторам на местах. Коротко говоря, конфигуратор будет эффективен только тогда, когда, доверя некоторую обязанность пользователю (обычному оператору), обычный системный администратор предпочтёт воспользоваться не shell/Perl, а средствами имеющегося конфигуратора, так как с их помощью задачу решить будет легче и быстрее.

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

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

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

Основное требование к конфигуратору ПО ОК возможность привлечения сообщества к его разработке. Оно распадается на три:

Простота доработки. Следует учитывать, что основные потребители конфигуратора как инструмента разработки - системные администраторы. Их рабочее время ограничено, и, вдобавок, от них нельзя требовать умения помногу и безошибочно программировать на различных языках.

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

Конфигуратор должен быть продуманно и внятно документирован. Это общее для любого ПО требование имеет здесь особую важность:

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

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

Нами было рассмотрено три с половиной дистрибутива Linux и их конфигураторы: SuSE Linux 9.1 и YaST2, Debian Sarge и DebConf, Red Hat Enterprise Linux 4 AS и system-config, а также находящийся ко времени исследования на стадии разработки ALT Linux 3.0 Compact и ALTerator.

Вкратце результаты исследования по приведённым выше критериям выглядят так.



YaST2 Наиболее "далеко ушедший" в плане возможностей конфигуратор. Многие из "готовых решений" и в самом деле уже готовы. В SuSE разработан специальный язык программирования (YCL), позволяющий быстро описать и интерфейс и логику работы отдельного модуля. Системные ресурсы, с точки зрения YCL, унифицированы, так что никакими операциями по настройке, кроме read, write и execute, программисту пользоваться не надо.

Системный уровень не только отделён от пользовательского, но и соединён с ним специальным "трубопроводом" (SCR), что позволяет запускать YaST2 на одной машине, а настраивать любую другую! YaST2 и YCL прекрасно документированы. Однако написание модуля для YaST2 остаётся делом довольно трудоёмким, так как требует одновременно всех упомянутых нами в начале знаний. Все авторы модулей YaST2 сотрудники SuSE.

DebConf Наиболее "многообещающий" конфигуратор, возможности которого до конца не осознаны. Произошёл от естественного стремления не задавать пользователю одни и те же вопросы повторно, раз уж его уже спрашивали (например, при установке системы). DebConf предоставляет кеш таких вопросов/ответов и другие возможности манипуляции ими, несколько видов автоматически оформляемого интерфейса и очень простой текстовый протокол обмена данными. В результате DebConf-ом пользуются все сопровождающие пакеты в Debian (наличие конфигурационного сценария, работающего через DebConf - часть дисциплины Debian). На самом деле это означает и горизонтальное (вопро-ответ - пользовательская модель, результат работы сценария - системная),и тем более - вертикальное модульное деление. Очень остроумно решается проблема масштабирования и автоматической настройки: используется "никакой" интерфейс, то есть настройка системы идёт только на основании данных из кеша ответов. Документация и примеры по DebConf весьма толковы. Разработка логики на верхнем, пользовательском, уровне в DebConf пока находится в зачаточном состоянии (Debian - сообщество профессионалов), но единственным "родовым" недостатком DebConf можно назвать только невозможность сочинять сложные интерфейсные модели. В этом направлении сообщество просто ещё не думало...

system-config Конфигуратор в "старом стиле" - не рассчитанный на сообщество, с множеством недостатков на нестандартных задачах и в нестандартных условиях, совершенно не документированный технически. Единственное достоинство: основные "операторские" задачи в самом деле решены, так что дыра залатана.

ALTerator На время исследования находился в состоянии разработки. Использует изначально модульную технологию и разделение интерфейсной, пользовательской и системной моделей. Связь между модулями может осуществляться с помощью простого текстового протокола, а сами модули можно писать на каком угодно языке программирования (в YaST2 это верно только для модулей нижнего уровня). Активно используется язык программирования Scheme, что, с одной стороны может усложнить жизнь системным администраторам, но, с другой стороны, упрощает написание интерфейсных модулей, что, учитывая горизонтальное деление, системным администраторам делать (может быть) и не придётся.

"Тёмная лошадка" среди конфигураторов: при надлежащем развитии из него может выйти почти идеальный (правда, не такой простой, как DebConf), при ненадлежащем - что угодно.

14.00 – 14.45: Обеденный перерыв Дневное заседание (14.45 - 17.00) 14.45 – 15.Алексей Федосеев ООО "Айя" Использование и модификация проекта User Mode Linux для организации хостинга на основе виртуальных выделенных серверов Основанием для данной работы явилась необходимость организации набора виртуальных серверов на одной машине. Такая задача возникает, например, в случае организации виртуального выделенного хостинга — пользователю выделяется собственный полноценный сервер, в рамках которого он обладает правами суперпользователя; для операционной системы же этот сервер является отдельным процессом или набором процессов.

К системе организации виртуальных серверов в этом случае предъявляются следующие требования:

• изолированность виртуальных серверов друг от друга;

• встроенный механизм ограничения использования ресурсов одним сервером;

• поддержка виртуальных сетевых интерфейсов;

• наличие средств администрирования.

Одним из решений, удовлетворяющих данным требованиям, является проект User Mode Linux (UML). Целью проекта, по сути представляющего собой модификацию ядра Linux, является запуск ядра операционной системы в качестве отдельного пользовательского процесса.

Запуск виртуальной машины с привилегиями простого пользователя позволяет настроить доступ виртуальной машины только к необходимым ресурсам системы. Виртуальные диски представлены в виде файлов, возможно создание Copy-on-Write образов дисков и проецирование директорий главного сервера в структуру каталогов виртуального. Виртуальные сетевые интерфейсы можно организовать несколькими способами, в том числе через TUN/TAP. Виртуальные консоли запускаемой системы могут быть связаны с файлами, файлами устройств терминалов и даже на TCPпортами.

Данная работа не претендует на роль сравнительного обзора существующих средств организации виртуальных выделенных серверов1. Однако, было бы интересно сравнить возможности UML с некоторыми широко распространенными аналогами, среди которых были выделены два: FreeBSD Jail и vserver linux.

1А таких систем, начиная от простых разработок и заканчивая серьезными коммерческими, например Virtuozzo, достаточно много.

Критерий UML vserver jail оценки Операцион ная Linux Linux FreeBSD система Виртуальн ые сетевые + + + интерфейс ы Уровень прав + + + суперпольз ователя Возможнос ть + - + перезагруз ки Возможнос ть смены + - дистрибути ва Специальн ое ядро нет да нет хостсистемы Доступ к файловой + –bind unionfs системе хоста Права суперпольз нет да нет ователя для запуска В таблице представлены результаты сравнения функциональности рассматриваемых решений.





Видно, что проект UML не уступает аналогичным существующим решениям.

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

• консоль управления — специализированная программа, взаимодействующая с виртуальным сервером и способная управлять им посредством набора команд (таких как start, stop, pause, proc — посмотреть содержимое файла в директории /proc, sysrq — отправить прерывание и т. п.);

• токены ввода-вывода — дополнительное средство ограничения виртуального сервера — подсчитывается число запросов к дискам, которое не должно привысить определенной в секунду величины.

• вывод ошибок ядра в поток stderr.

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

• добавление новых и удаление существующих виртуальных серверов;

• запуск, останов и временное прерывание работы виртуального сервера;

• мониторинг состояния исполнения и уровня загрузки системы;

• простейшая система балансировки нагрузки (nice scheduler);

• комплексный файервол (организованный на базе iptables), задающий параметры доступа к виртуальным серверам по виртуальным сетевым интерфейсам;

• система централизованного бэкапа;

• программа для входа в виртуальную систему через одну из консолей.

Комплекс скриптов написан на языке Ruby.

Разработанное решение на основе проекта User Mode Linux позволяет построить достаточно гибкую систему виртуального выделенного хостинга и успешно применяется в работе нашей компании.

Исходные тексты программ и комплект документации для администратора в настоящий момент готовятся к публикации под лицензией GPL в сентябре этого года.

15.10 – 15.Андрей Столяров МГУ им. Ломоносова, ВМК Библиотека InteLib - инструмент мультипарадигмального программирования Аннотация Доклад посвящен практическому решению проблемы интеграции выразительных механизмов языков программирования принципиально различной природы в рамках одного проекта. Дается краткая классификация существующих подходов и указываются их недостатки. В качестве решения проблемы предлагается подход, получивший название метода непосредственной интеграции, и описывается библиотека InteLib, позволяющая, не выходя за рамки языка C++, записывать выражения, семантически эквивалентные и синтаксически близкие конструкциям языка Lisp (а в перспективе – и других языков, таких как Рефал, Prolog, Datalog и др.) Все многообразие существующих в настоящее время языков программирования можно при желании классифицировать по признаку господствующих традиций осмысления программы, принятых в сообществе программистов, пишущих на данном языке. Так, традиционные императивные языки стимулируют осмысление программы как набора приказов по изменению тех или иных данных;

объектно-ориентированные языки позволяют представлять программу как набор абстрактных объектов, обменивающихся сообщениями; при работе на языках логического программирования программа представляется как система фактов и аксиом, а исполнение программы состоит в попытке опровержения заданного утверждения; наконец, функциональные языки программирования описывают программу как набор функций, вычисляющих значение по заданным аргументам, а выполнение программы представляется вычислением значения некоторого выражения.

Менее фундаментальные особенности языков программирования также накладывают определенный отпечаток на мышление программиста; прекрасный пример этого приводит Тимоти Бадд в книге [1].

Решение вопроса о "<наиболее правильном"> или "<наиболее удобном"> образе мышления существенно зависит от решаемой задачи. Так, на языке Lisp удобно обрабатывать формульные и другие слабо структурированные данные, но до крайности неудобно строить диалоговые системы на основе событийно-ориентированных оконных интерфейсов, а для языка Java дела обстоят ровно противоположным образом.

Типичной является ситуация, когда в силу тех или иных причин для реализации крупного проекта выбирается тот или иной язык программирования (чаще всего выбор падает на императивный или императивно-объектный язык), при этом в проекте возникают небольшие подзадачи, которые было бы гораздо удобнее решать на совершенно другом языке.

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

1. создание нового языка программирования (возможно, как расширения одного из существующих) 2. встраиваемые интерпретаторы 3. расширяемые интерпретаторы 4. трансляция из одного языка в другой 5. пакеты взаимосвязанных программ 6. сборка объектных модулей, полученных из разных систем программирования 7. реализация частных возможностей Эти подходы подробно анализируются в работе [2]. К сожалению, каждый из них имеет определенные недостатки, существенно ограничивающие области их применения.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |










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

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