WWW.DISSERS.RU

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

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


Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |

• модульная поддержка протоколов • модульная поддержка различных видов аппаратного обеспечения • обработка зависимостей • поддержка профилей конфигурации • устойчивость к аппаратным переконфигурациям 3 Подробности 3.1 Модульность Скелет системы образуют несколько сценариев, выполняющих самые основные функции в общем виде. В зависимости от контекста какие-то стадии конфигурации окажутся востребованы, а какие-то нет. Поддержка каждого протокола и вида интерфейса выделена в отдельные файлы. Это значительно уменьшает дублирование кода и облегчает его сопровождение. В настоящее время поддерживаются следующие протоколы: IPv4, IPv6, IPX.

3.2 Строгая типизация интерфейсов Одно из требований к конфигурационной базе --каждый обслуживаемый интерфейс должен относиться к какому-либо из 5 предусмотренных типов. Тип интерфейса играет роль в порядке запуска и останова интерфейсов. Каждый из обрабатываемых системой видов интерфейсов принадлежит к какомулибо типу. Распределение видов интерфейсов по типам следующее:

• локальная петля и dummy: виртуальные • Ethernet, Pent@NET, USB, PLIP, WiFi:

полноценные физические • VLAN, мосты Ethernet, bonding, TEQL:

производные физические • туннели IPv4 и IPv6, туннели IPSec: независимые логические • PPP: зависимые логические 3.3 Ориентировка на шаблоны Основу конфигурационной базы составляет набор системных опций и интерфейс default. Другие интерфейсы наследуют его конфигурацию и дополняют её своими опциями. Таким образом, нет необходимости для каждого интерфейса определять весь набор поддерживаемых опций, появляется возможность изменять конфигурацию нескольких интерфейсов за раз. Наследование опций в /etc/net двухуровневое: сначала общие для всех интерфейсов опции шаблона default, затем опции, специфические для текущего типа интерфейса, затем опции конкретного взятого интерфейса.

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

Это позволяет оперировать опциями сразу на уровне интерфейсов.

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

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

3.6 Встроенная поддержка QoS /etc/net реализует встроенную поддержку QoS путём предоставления интерфейса к утилите tc. Интерфейс представляет собой дерево каталогов и файлов специального вида, располагающееся в конфигурационном каталоге интерфейса. Структура спланирована таким образом, чтобы максимально исключить дублирование параметров.

3.7 Дополнительные удобства:

• автодополнение переменных sysctl • быстрая конфигурация VLAN через vlantab • конфигурация нескольких систем из одной конфигурационной базы • поддержка QoS • поддержка сетевого экрана (в разработке) • поддержка ifplugd • автоматическая верификация конфигурационной базы 4 Планы • завершение внедрения в ALT Linux 3.• внедрение в другие дистрибутивы • поддержка сетевого экрана • разработка собственного GUI-конфигуратора 16.50 – 17.10: Кофе Вечернее заседание.

17.10 – 19.Круглый стол "Сообщество и корпорации". Ведущий Александр Боковой (IBM LTC, Samba project).

27 июля Утреннее заседание (9.30 - 13.40) 9.30 – 9.Вадим Машков ЕМТ, Киев Проект migration.osdn.org.ua Рекомендации по миграции на свободное ПО Вспомните те времена, когда DOS доминировала на большинстве персональных компьютерах. Затем появилась графическая надстройка – Windows 3.1, которая потребовала смены подходов к решению проблем офисной автоматизации.

Подобные эволюционные процессы являются естественными для любого типа программного обеспечения.

В настоящий момент при принятии решении о миграции на новую программную платформу у пользователей появился выбор. Одним из них является использование СПО.

Останавливаться подробно на вопросе “почему именно свободное ПО” не будем, об этом написано много материала, например www.emt.com.ua/boss.html.

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

Пример последнего - ситуация не такого далекого прошлого, когда к Вам, использующим Office 95, попал документ в формате Office 97. Сколько проблем возникло из-за несовместимости форматов.

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

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

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



Зачастую на этом этапе производится расчет и сравнение совокупной стоимости владения как действующей так и проектируемой информационной системы.

Для примера возьмём типичное подразделение в организации или небольшую фирму.

Как правило это один выделенный сервер и несколько рабочих станций. Сервер обеспечивает коммуникационные сервисы, файловое хранилище, авторизацию, управление печатью.

Рабочие станции используются для выполнения стандартных офисных задач.

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

Итак, возникла необходимость в смене используемых программных решений. Выбор остановился на свободном ПО.

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

• Технических специалистов, которые решают технические вопросы;

• Руководителя для решения вопросов нетехнического характера. Это избавит технических специалистов от решения вопросов не входящих в их компетенцию;

• Разумно включить в состав группы независимого Эксперта. Это специалист, который хорошо знаком с аспектами использования свободного ПО. Если такого специалиста нет в компании, найдите его среди компаний предоставляющие поддержку свободных решений.

(http://migration.osdn.org.ua/index.phpid=158) Миграция состоит из нескольких логически целостных этапов.

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

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

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

Зачастую на этом этапе производится расчет и сравнение совокупной стоимости владения как действующей так и проектируемой информационной системы.

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

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

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

ПО на сервере заменяется свободными программными продуктами. При этом данный процесс протекает незаметно для пользователя.

Стоит отметить, что всё представленное ПО, входит в состав любого дистрибутива Linux.

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

Для принятия решения о внедрении новой информационной системы на базе свободного ПО, мы рекомендуем провести Пилотный проект.

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

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

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

В качестве примера рассмотрим Пилотный проект, целью которого является использование свободного офисного пакета OpenOffice.org. Объектом выполняемых работ являются макросы MS Excel, которые используются для вычислений. В результате выполненных работ получаем макросы, работающие в OpenOffice.org и реализующие требуемую функциональность. В процессе замены офисного пакета, необходимо проверить правильность работы макросов и выяснить как пользователи оценивают работу офисных пакетов “до” и “после”.

Тщательное планирование – залог успеха миграции.

При планировании учитывайте особые случаи. Это может быть: сложное-специализированное ПО;

недостаточная подготовка персонала, что может потребовать его обучения; особые требования со стороны руководства; и т.п.

Составьте подробный план, учитывая необходимость создания резервных копий существующих данных, их переносу в новую систему; развёртывания системы; сроки обучения пользователей.

На этапе обучения пользователей уделите особое внимание тем, кто является приверженцем старой системы.





На основании дополнительных данных после проведения пилотного проекта уточните окончательную стоимость проекта миграции.

Определите ответственных и составьте подробный календарный план, установив в нём промежуточные контрольные точки.

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

http://www.linuxrsp.ru/win-lin-soft/table-rus.html http://tech.stolica.ru/article.phpid=После перехода на использование решений на базе СПО мы:

• повышаем безопасность системы в целом;

• улучшаем управляемость рабочими станциями;

• снижаем зависимость от разработчика ПО;

а также снижаем стоимость внедрения и эксплуатации системы.

Данный ресурс предназначен, для обмена опытом внедрения свободного ПО. Это позволит снизить риск принятия ошибочных решений. Здесь вы сможете найти поддерживаемые свободные решения компаний СНГ.

9.55 – 10.Виталий Липатов Etersoft 10.20 – 10.Петр Новодворский Москва, IBM LTC Компонентная сборочная система Samba 4.Аннотация Доклад посвящен новой системе сборки, которая будет использоваться в новой версии Samba. Новая система сборки может быть адаптирована для любого сложного проекта, который состоит из значительного количества библиотек, модулей и программ и должен собираться на большом количестве платформ и операционных систем.

При проектировании Samba 4 были представлены следующие требования к новой версии:

• полнота реализации протокола;

• возможность автоматического тестирования;

• полностью асинхронная модель работы сервера;

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

• реализация различных не POSIX "backend", т. е.

возможность работы сервера на самых разных платформах.

В прошлых версиях Samba протокол CIFS/SMB был реализован не полностью, а возможности добавлялись по надобности. Новая версия Samba ориентируется на полную реализацию CIFS/SMB.

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

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

Существующие системы сборки неполностью обеспечивают нужды проекта Samba. Новые системы не работают на требуемом количестве платформ, а существующая программа automake не обеспечивает возможности ввести требуемый уровень абстракции.

Samba4 состоит из большого количества компонентов: библиотек, модулей и исполняемых программ, более 50% кода в Samba генерируется автоматически. Разработчик, при добавлении новой возможности в программный код должен внести соответствующие обновления и в файлы сборки, но из-за общей сложности и разветвленности системы, без нужного уровня абстракции это станет сложной задачей.

Система сборки Samba определяет 4 обычных компонента: MODULE, EXT_LIB, BINARY и LIBRARY, а так же специальные BUILDVAR и SUBSYSTEM. Весь исходный код Samba4 разбит на подсистемы, в каждом компоненте SUBSYSTEM указывается какие объектные файлы входят в каждую подсистему. После того, как файлы распределены по подсистемам, можно узнать, с помощью определения недостающих символов в объектных файлах, как подсистемы зависят друг от друга.

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

Самым высоким уровнем среди компонентов является BUILDVAR. В этих компонентах описывается то, каким образом будет собран тот или иной компонент: модуль, программа или библиотека.

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

Процесс сборки с помощью сборочной системы Samba4 разделен на три этапа. На первом этапе используется система configure для выяснения параметров системы, на которой будет осуществляться сборка. Далее в работу вступают собственные сценарии, написанные на perl, которые из файлов описания компонент создают обычные файлы сборки на языке GNU Make. После этого GNU Make обрабатывает эти файлы и компилирует программу. Таким образом, в сборочной системе задействовано три средства: GNU Make, Autoconf и Perl, а они присутствуют почти на всех операционных системах и платформах существующих сегодня.

Pages:     | 1 |   ...   | 4 | 5 || 7 | 8 |   ...   | 9 |










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

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