Открытое письмо Мэтью Шулика

Неофициальный перевод. Не является дословным переводом оригинала. Оригинал доступен по адресу:
http://www.press.redhat.com/2007/12/20/a-message-from-matthew/

«Я ценю только безумных людей. Людей, что живут ярко, говорят ярко и не боятся сгореть. Людей, что хотят всего и сразу. Людей, что никогда не зевают от скуки и не говорят банальностей, а вместо этого — горят, горят, горят как сказочные римские свечи, разбрасывая среди звезд огни, вспышки и звук разрывов — и в воздухе висит многоголосое «урааааа!!!».» - Джек Керуак (Jack Kerouac).

После почти десяти лет в роли главы Red Hat я решил оставить свои посты CEO и президента по личным причинам, которые я уже объяснял. Я продолжу служить этой великой компании в качестве председателя совета директоров. Red Hat будет в руках великолепной команды менеджеров мирового уровня, возглавляемой Джимом Вайтхёрстом как президентом и CEO.

Когда я только начинал работать в Red Hat, мы сидели в маленьком офисе в Дюрхеме, причем я сидел напротив автомата, продавшего газировку. Люди подходили и тыкали в кнопки, выбирая Mountain Dew или колу. Моей главной задачей на тот момент было привлечь крупных инвесторов в open source. И во время телефонного разговора, посреди моих рассуждений и аргументов, представители Dell, IBM, HP и других корпораций подобного масштаба слышали постоянный стук падающих банок газировки. Они спрашивали, в чем дело, и не дерется ли кто-то неподалеку. В итоге через некоторое время я стал говорить предполагаемым инвесторам, что ДА, действительно идет драка. Причем эти драки идут часто. Именно так в Red Hat разбираются с проблемами, такими как старые баги и неработающие новые фичи. Да, Red Hat — жесткое компания. Dell, HP и IBM стали инвесторами, потому что им понравился позитивно-агрессивный дух Red Hat.

Больше девяти лет — долгий срок. Антимонопольные иски к Microsoft. Гарри Поттер. Клинтон, Буш, Буш. «Дот-комы». 2000 год. 11 сентября. Вступление Китая в ВТО. Ирак. Цунами. ENRON. Sarbanes Oxley. BRIC (Brasil, Russia, India, China). Дарфур. Италия и кубки мира. Boston Red Sox. iPod. Взрывы в Испании. Глобальное потепление. Обама и Хиллари.

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

Много лет я всматриваюсь в ветровое стекло, пытаясь разглядеть будущее. Учась и приспосабливаясь к возникающему сообществу Red Hat, его культуре и месту на рынке. Прошлые и нынешние сторонники Red Hat, члены сообщества open source, наши заказчики и партнеры — все они добавили свои штрихи и краски к тому образу, который носит имя Red Hat. Я чувствую гордость, когда представители различных компаний говорят мне, что люди Red Hat «особенные». Не такие, как те, кто ставит целью захватить индустрию. Своей работой сообщество open source и Red Hat в частности создают новую модель взаимоотношений разработчика и заказчика. Совместная работа. Открытость и ориентированность на задачи заказчика. Наши заказчики и рынок в целом это понимают, что подтверждает наш потенциал. То, что в 1998 году считалось несерьезным, теперь изменилось. Сегодня государственные и индустриальные компании разделяют ценности и подходы open source, доказательством этому — их поддержка OLPC и инициатив open source сообщества в области образования в Индии, Южной Америке и Африке (и в России! - прим. переводчика).

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

/MJS

Неофициальный перевод. Не является дословным переводом оригинала. Оригинал доступен по адресу:
http://www.press.redhat.com/2007/12/20/a-message-from-matthew/

Новым CEO Red Hat стал Джим Вайтхёрст

20 декабря 2007 года компания Red Hat объявила, что совет директоров принял кандидатуру Джима Вайтхёрста (Jim Whitehurst) в качестве нового президента и CEO компании, а также нового члена совета директоров. Решение вступает в силу с 1 января 2008 года. Вайтхёрст сменит на посту президента и CEO Мэтью Шулика (Matthew J. Szulik). Шулик продолжит работу в компании в качестве председателя совета директоров.

Со стороны совета директоров Red Hat Вильям Кайзер (William S. Kaiser) заявил: «Уже около десяти лет благодаря проницательности и лидерским качествам Мэтью Шулика бизнес-модель, основанная на open source, показывает свою эффективность и инновационность. Шулик превратил Red Hat из маленькой частной компании в бренд мирового масштаба, а подход компании к развитию технологий и предоставлению сервисов клиентам во многом изменил индустрию программного обеспечения.»

Также Кайзер добавил: «Совет директоров рад приветствовать Джима Вайтхёрста в качестве нового CEO. Мы уверены, что он привнесет в компанию сочетание стратегического видения и эффективного управления, необходимое, чтобы продолжать рост компании и при этом и в дальнейшем предоставлять заказчикам самый высокий уровень сервиса в индустрии. Его опыт работы в больших международных компаниях будет крайне ценен на этапе, когда Red Hat приближается к выручке в миллиард долларов и продолжает расти.»

«После активного поиска Red Hat выбрал талантливого директора, который успешно возглавлял международную технически-ориентированную организацию во время его работы в Delta», - добавил Шулик, - «Джим — человек с активный позицией, и ему очень близка культура, существующая в Red Hat».

«Red Hat изменил отношение людей к технологии. Это выдающаяся компания, и я рад присоединиться к ней», - сказал Вайтхёрст, - «У нас великолепные перспективы — высококлассные технологии, великолепные люди, четкое управление и бренд мирового масштаба. Red Hat — ведущий поставщик программного обеспечения, больше всех оправдывающий ожидания заказчиков. Я ряд, что у меня есть возможность вести эту компанию в будущее».

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

До Delta Вайтхёрст занимал должность вице-президента и директора в Boston Consulting Group (BCG) и различные руководящие посты в офисах компании в Чикаго, Гонконге, Шанхае и Атланте.

Оригинальный пресс-релиз на английском доступен по адресу: http://investors.redhat.com/phoenix.zhtml?c=67156&p=irol-newsArticle&ID=1089406

Ноутбуки с Linux. Экзотика или тенденция?

Ни для кого не секрет, что рынок ноутбуков сейчас растет гораздо быстрее рынка десктопов. Прогноз, что в 2007 году ноутбуки принесут производителям оборудования больше прибыли, чем стационарные десктопы (http://www.eweek.com/article2/0,1895,2074541,00.asp), похоже, сбывается. А для некоторых компаний, например, для Hewlett-Packard (http://www.eweek.com/article2/0,1895,2219669,00.asp), это уже очевидный факт.

При этом рост обеспечивается большей частью за счет бюджетных моделей (менее $1000). Это выглядит вполне логичным, так как число людей, готовых покупать дорогие престижные модели, изменяется мало. В то же время все более распространенным становится wi-fi и все большую популярность обретает идея «мобильного офиса». В итоге, когда цена ноутбука падает ниже психологического барьера в $1000, все большее количество покупателей, в том числе корпоративных, переходят со стационарных десктопов на ноутбуки.

Но на этом этапе возникает одна проблема. Имя этой проблеме – Vista. Ну не приспособлены ноутбуки с 1 Gb оперативной памяти и встроенным видео для полноценной работы с Vista! Кроме того, стоимость Vista для этого ноутбуков этого ценового диапазона составляет заметную часть итоговой цены.

В итоге у компаний-сборщиков остается три пути. Первый путь – наращивать мощность ноутбуков и тем самым уйти из притягательного ценового диапазона. Второй путь – использовать версию Vista Home Basic, которую ненавидят даже самые ярые сторонники Vista. Третий путь – отказаться от Vista.

Первый путь рассматривать просто неинтересно. Те компании, которые его выбирают, автоматически отказываются от борьбы за большую нишу рынка. Второй путь выглядит вполне реальным и некоторые компании поставляют ноутбуки с Vista Home Basic. Но здесь возникает одно «но» – с точки зрения пользователя Vista Home Basic ничем не лучше XP. Можно долго рассуждать о ее технических нововведениях, но попробуйте объяснить их обычному пользователю. Для него она останется системой с множеством минусов относительно XP (непривычность, отсутствие многих нужных программ, медленность работы) и при этом без единого плюса. Наверняка Вы и сами неоднократно слышали подобные мнения.

В итоге, как показывает практика, ноутбуков с Vista Home Basic в продаже все меньше. И все большее количество сборщиков выбирают третий путь – отказ от Vista. Многие из них сейчас продолжают предлагать XP как вариант предустановленной системы. Но этот путь ведет в никуда – срок жизни XP на исходе, тем более в ситуации, когда Microsoft активно продвигает Vista.

Поэтому не удивительно, что многие компании смотрят на Linux как на наиболее перспективную альтернативу Vista. На сегодняшний день ноутбуки с тем или иным Linux уже предлагают Dell, HP, Lenovo, Asus. Их мотивы вполне понятны – используя Linux они получают возможность предложить работоспособный ноутбук для любых задач, используя при этом недорогие процессоры, всего 512 Mb оперативной памяти и встроенное видео. В конечном итоге это дает большую гибкость – можно снижать цены и захватывать рынок, а можно не менять цены и увеличивать свою прибыль с одного ноутбука.

Вряд ли остальные сборщики захотят упустить свою долю рынка. Поэтому появление большего количества ноутбуков с Linux – исключительно вопрос времени.

При подготовке обзора использован материал Steven J. Vaughan-Nichols (http://www.eweek.com/category2/0,2662,1586243,00.asp).

Итоги опроса CIO Insight за 2007 год

Подведены итоги очередного исследования CIO Insight. Red Hat в очередной раз был назван лучшим поставщиком решений для корпоративного сектора и возглавил итоговый общий рейтинг. Так как хвастаться нехорошо, не будем распространяться дальше о деталях. Те, кому они интересны, могут прочитать полное исследование на http://www.cioinsight.com/article2/0,1540,2217106,00.asp.

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

Appliance Operating System

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

В качестве ответа на это Red Hat предлагает Appliance Operating System (AOS), основанную на Red Hat Enterprise Linux. В рамках этого проекта Red Hat предлагает разработчикам программного обеспечения Virtual Appliance Development Kit (vADK) – набор средств для создания образов системы, пригодных для развертывания на разнообразных платформах. На данный момент проект находится в состоянии закрытой беты, релиз намечен на первую половину 2008 года.

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

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

Образы, создаваемые vADK, могут быть развернуты на следующих платформах:

• Red Hat Enterprise Linux 5

• VMware ESX 3

• Amazon EC2

• Microsoft Viridian (после официального релиза)

• Sun xVM

Amazon EC2. Все новое – это хорошо забытое старое.

Когда-то всем пользователям ЭВМ было хорошо знакомо понятие «машинное время». Именно его они получали в свое распоряжение – некоторое время работы на некоторой машине. Потом, когда компьютеры стали персональными, «машинное время» забылось, речь шла уже о получении нужного количества компьютеров, а не часов. И вот «машинное время» возвращается, но уже в новом качестве.

Amazon запустил новый веб-сервис – Elastic Computing Cloud или сокращенно EC2. Подробный анонс можно найти по адресу http://www.amazon.com/ec2.

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

Ориентировочная стоимость сервиса – 10 центов за один час аренды сервера вида 1.7 Gb RAM, 1.7 GHz Xeon, 160 Gb места на диске. При этом клиент может выбирать конфигурацию необходимого ему оборудования и оплачивает его почасовую аренду, трафик оплачивается отдельно.

В примерном пересчете получается, что если арендованный сервер работает 24х7, то он обходится в $72/месяц плюс стоимость трафика. Это сопоставимо со стоимостью выделенного сервера у крупных хостинговых компаний. И это значительно больше, чем стоимость VPS. Поэтому у многих возник вопрос, так что же нового предлагает Amazon?

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

Еще один простой пример. Допустим, перед компанией время от времени встает необходимость решать задачи, требующие 100 часов машинного времени. Неважно, что это за задачи – численное моделирование, сложный анализ данных, рендеринг или что-либо еще. Компания может приобрести свой кластер из, скажем, 20 машин, что позволит решать такие задачи за 1 рабочий день. Обойдется такой кластер примерно в $25000, кроме того, его придется где-то разместить и в дальнейшем обслуживать. Или же можно воспользоваться Amazon EC2, не вставая со своего рабочего места выделить 100 серверов, решить задачу за час и заплатить за все это $10.

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

«Электронная Россия» и открытые форматы

Мы уже неоднократно писали о важности открытых форматов как таковых и о разработанном консорциумом OASIS формате Open Document Format (ODF) в частности.

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

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

Однако, при том, что необходимость использования открытых форматов документов очевидна, конкретных шагов в этом направлении в России до последнего времени сделано не было. Но ситуация начинает меняться. В ноябре были подведены итоги конкурса «Электронной России» по теме «Исследование механизмов, направленных на создание в государственных учреждениях Российской Федерации условий для использования международного стандарта электронного документа ISO/IEC 26300:2006». (Напомним, что стандарт ISO/IEC 26300:2006 – это формат ODF.)

Конкурс выиграл альянс, в который вошли ЭОС, «Инфра-Ресурс», «ПроСофт-М» и ассоциация ЕВРААС. Именно они теперь займутся исследованием вопросов перехода государственных учреждений на ODF. Кроме того, что очень важно, будет разработана русифицированная версия стандарта ISO/IEC 26300:2006, которую в дальнейшем предполагается принять как национальный стандарт.

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

Централизованное управление аутентификацией и информацией о пользователях.

Экскурс в историю

С тех пор, как компьютерные сети получили широкое распространение, использовать файлы, такие как /etc/hosts, /etc/networks, /etc/group, /etc/gpasswd, /etc/passwd, /etc/shadow и им подобные для хранения соответственно информации о хостах, сетях, группах, паролях групп, пользовательской информации, паролей пользователей и прочей подобной информации, которая должна быть целостной на всех узлах сети стало неэффективно. Неэффективно в первую очередь из-за проблем синхронизации. Встал ребром вопрос о разработке технологий централицозанного управления и хранения информации из вышеуказаных файлов. И если для читабельных имен узлов и сетей выбор пал (сейчас уже практически эксклюзивно) на DNS (отщепенцы с NIS и им подобные не рассматриваются), то с пользовательской информацией и механизмами аутентификации не все так просто как кажется. В данной статье мы постараемся описать различные методы вместе с их преимуществами и недостатками.

Итак, поехали.

Для начала важно понимать принципиальное различие трех следующих ключевых терминов:

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


• Аутентификация - процесс удостоверения подлинности пользователя. Иначе говоря успешная аутентификация говорит только о том, что "Ты дейстительно тот, за кого себя выдаешь". Этот процесс может осуществляться огромным количеством способов.


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

Итак, немного прояснив ситуацию с терминологией определимся, о чем мы сегодня поговорим. Мы постараемся осветить первые 2 пункта. Третий пункт стоит особняком и не является темой сегодняшнего разговора. Начнем с предметного "разноса" устаревшим технологиям. Заметим, что мы рассматриваем все технологии в первую очередь как средство выполнения описанных выше задач, побочные их возможности при этом рассматривать не будем.

NIS

NIS является классическим RPC сервисом, придуманным компание SUN Microsystems
довольно давно. Суть - предоставление сервиса "хранения" пользовательской
информации на центральном сервере домена. Опционально там же хранятся хэши
пользовательских паролей. Как сервис аутентификации NIS крайне несовременен, в
силу того, что в герерогенной среде часто приходится "возвращаться" к
DES-алгоритму шифрования паролей, который был признан небезопасным. Как
хранилище пользовательской информации все еще ограниченно пригоден, а иногда
это вынужденный вариант, так как многие старые Solaris (в частности) системы
не умеют получать пользовательскую информацию с LDAP-сервера.

Принципиально NIS не предоставляет никаких механизмов аутентификации. Для
получения пользовательской информации достаточно знать IP-адрес сервера домена
и название домена. Обычно это легко выясняется с помощью nmap, rpcinfo или
паяльника ( :) ). После этого "неправильная" машина может получить дамп
локальной информации (о боже, в некоторых конфигурациях с паролями шифроваными
DES) для оффлайн-исследования. Резюмируем.

Плюсы:

• Просто и быстро развертывается.


• Простая система миграции информации из файлов /etc/passwd и /etc/shadow

Минусы:

• По умолчанию размещается на динамических RPC портах (плохо файлволлится)


• Не поддерживает шифрование


• Не предоставляет механизмов аутентичикации клиентских машин


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


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

Применимость:

Аутентификация: rрайне слабое средство. Применять рекомендуется только после вывода о неприменимости других систем.

Пользовательская информация: Ограниченное применение в физически изолированных сетях, обычно вызванное необходимостью совместимости со старыми Solaris

Некоторые недостатки первоначальной NIS были исправлены в NISPLUS (http://en.wikipedia.org/wiki/Nisplus). Тем не менее, бытует мнение, что NISPLUS - это ugly hack и его использовать (особенно в новых системах) не рекомендуется.

DBMS

Многие люди почему-то любят хранить информацию о пользователях в реляционных базах данных. Это решение не имеет на наш вгляд плюсов и является неверным с точки зрения безопасности и скорости. Причина кроется в том, что задачи получения пользовательской информации сводятся обычно к чтению одной-единственной (ну нескольких) записей. Задача аутентификации требует чтения одной записи. При этом, используя реляционные СУБД, мы вынуждены "оборачивать" простой запрос на чтение в сложную и громоздкую обертку, иногда даже транзакционную. Подобные решения особенно плохо себя показывают при лавинообразном росте числа клиентов. Кроме того доступ к СУБД должен быть открыт по сети для любого хоста, желающего получить доступ к пользовательской информации и информации для аутентификации. Отметим также, что описываемая нами информация редко изменяется. То есть наиболее частой операцией являет операция одиночного чтения, для которой транзакционная нагрузка просто излишня

Помимо прочего большинство широко используемых СУБД не позволяют достаточно гранулированно управлять правами (например невозможно запретить пользователю СУБД читать колонку с чужими паролями). Иначе говоря, как и в случае с NIS, злоумышленник часто может просто получить копию базы данных пользователей (а то и паролей).

Плюсы:

• На первый взгляд дотаточно просто

Минусы:

• Нестандартное решение, требующее внешних средств для работы


• Плохая гранулированность аутентификации пользователей в СУБД


• Низкая производительность и плохая масштабируемость

Применимость:

Аутентификация: крайне слабое средство. Don't use that.

Пользовательская информация: ограниченно применимо, если вы сможете ввиду вышеуказанных аргументов ответить на вопрос "А зачем?"

LDAP

История развития LDAP терниста и неоднозначна. В 1988 году коммитеты по стандартам ITU-T (консорциум телекоммуникационных компаний) и ISO сформулировали стандарт для хранения древовидной информации, известный как X.500 или DAP. Вспомните модель OSI, которой все учат, но мало где используют. Стандарт получился "мертворожденным" и получил крайне ограниченное распространение. Из минусов исходного стандарта можно отметить переусложенность, наличие непонятной в мире Internet иерархии, основанной на географических терминах.

Тем не менее ряд остроймных людей отпрофилировал систему, реализующую DAP и, переложив "понятия" телекоммуникационных компаний на интернет, а также разбавив изначальную спецификацию здравым смыслом, разработали протокол LDAP (Lightweight Directory Access Protocol). Кстати говоря "облегченный" этот протокол как раз в сравнении с оригинальным DAP.

В настоящее время существует несколько инкарнаций LDAP, такие как OpenLDAP, Red Hat Directory Server ( в девичестве Netscape Directory Server ) а также другие (например M$ Active Directory). В настоящее время LDAP является сдандартом де-факто для хранения пользовательской информации. При этом, правда, некоторые ошибочно воспринимают LDAP как "святой грааль", коим он не является. LDAP - не более чем концепт специальной нетранзакционной древовидной БД для хранения различных данных, грамотное использование которого возможно только при правильной "проекции" этого концепта на конкретную ситуацию.

LDAP, используемый для хранения пользовательской информации, а, возможно, и аутентифиакции имеет следующие отличительные черты:

Плюсы:

• Стандарт


• Высокая производительнось операций чтения (особенно одиночных)


• Достаточно хорошая масштабируемость, низкие "накладные расходы"


• Достаточно четкий и гранулированный механизм разграничения доступа к данным, хранящимся в директории


• Поддержка SSL/TLS - шифрования


• Наличие механизмов аутентификации клиентских машин при получении пользовательской информации

Минусы:

• Сложность в освоении в силу "непохожести" на другие технологии

Применимость:

Аутентификация: применимо. Отсутсвует фукнциональность Single Sign on. (как впрочем и в предыдущих решениях)

Пользовательская информация: о, да!

Принципиальные различия между OpenLDAP и, например, Red Hat Directory Server лежат в границах применимости и доп. возможностях. Например OpenLDAP вполне неплохо подходит для хранения небольшой директории (до 5000 записей). Начиная примерно с этого объема RHDS масштабируется заметно лучше. Помимо этого RHDS имеет следующие основные и принципиальные преимущества:

• Multi-master репликация. До четырех мастеров могут обслуживать одно дерево.


• Поддержка двунаправленной репликации с Active Directory.

Kerberos.

Kerberos был создан в стенах небезызвестного MIT и является на сегодняшний день стандартом технологии аутентификации. Хотя Kerberos и использует шифрование симметричными ключами, ключи никогда не передаются по сети. При этом достаточно сложная система аутентификации позволяет строить домены аутентификации "Authentication Realm", внутри которых действует Single Sign On, тоесть пользователю достаточно аутентифицироваться на KDC, чтобы аутентифицироваться в дальнейшем на любом из сервисов домена без необходимости ввода пароля.
Именно Kerberos для аутентификации и LDAP для хранения пользовательской информации в настоящее время считаются "референсным" решением. Подобная схема (хоть и совершенно несоответствующая общепринятым тандартам) используется в так называемых Windows-доменах.

Kerberos - исключительно механизм аутентификации. Основные действующие лица:

• KDC, он же Центр Дистрибьюции Билетиков (Ticket), он же Key Distribution Cetner. Знает секретные ключи всех остальных участников, поэтому его надо ревностно охранять.


• Client Principal, он же клиент - биологический объект, желающий аутентифицироваться


• Service Principal, он же сервис - небиологический объект (сервис), который поддерживает аутентификацию Kerberos.


• Client-Service Ticket - кратковременное "разрешение на временную аутентификацию"


• TGT, он же Ticket Granting Ticket - долговременное разрешение получать Ticket'ы

Механизм аутентификации следующий:

Сценарий 1. Клинет аутентифицируется на KDC.

1. Клиент изъявляет желание аутентифицироваться и сообщает об этом серверу. Сервер в ответ отправляет 2 ообщения:
   
   
   
   1. Ключ сессии зашифрованный секретным ключем пользователя
      
   2. TGT, зашифрованный секретным ключем KDC
      
   
   
2. Получив оба сообщения и расшифровав первое клиент обладает достаточной информацией для аутентификации на KDC
   
3. TGT (второе сообщение) не может быть расшифрован клиентом. Он кэшируется и доступен для использования всему поддереву дочерних процессов,
   

Сценарий 2. Клиент хочет получить доступ к сервису.

1. Клиент отправляет запрос на сервер аутентификации, содержащий следующие данные:
   
   
   
   1. Составное сообщение, состоящее из ID сервиса и зашифрованного секретным ключем KDC TGT из предыдущего сценария.
      
   2. Аутентификатор, сотоящий из ID клиента метки времени (timestamp), зашифрованный ключем сессии.
      
   
   
2. Расшифровав эти сообщения, сервер может принять решение о "разрешении"доступа клиента к сервису. Это есть элемент авторизации. В случае положительного решения KDC отвечает клиенту также двумя сообщениями:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а. Client-Service Ticket включает ключ сессии клиент-сервис, а также прочую информацию. Клиент не может его расшифровать.
      
   2. Ключ сессии клиент-сервис, зашифрованный ключем сессии клиент-KDC.
      
   
   
3. Довольный клиент имеет теперь достаточно информации для аутентификации "на сервисе".
   

Сценарий 3. Аутентификация клиента с сервисом.

1. Клиент пересылает сервису следующие сообщения:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а из предыдущего сценария.
      
   2. Аутентификатор, содержащий ID клиента и метку времени, зашифрованные ключем сессии клиент-сервис.
      
   
   
2. Сервис расшифровывает первое сообщение. Из него он получает ключ сесии клиент-сервис. Расшифровывает полученным ключем второе сообщение и аутентифицирует клиента, если метка времени находится в доверительном интервале. Отправляет клиенту подтверждение, содержащее
   
   
   
   1. Метку времени, зашифрованную ключем сессии клиент-сервис.
      
   
   
3. Клиент расшифровывает сообщение и проверяет корректность метки времени. В случае если метка обновлена корректно аутентификация прошла успешно, клиент и сервис начинают "общаться".
   

Преимущества:

• Секретные ключи не пересылаются по сети
  
• Single Sign On.
  
• Простой механизм борьбы с перехваченными ключами сессии: они истекают раньше, чем их удается расшифовать.
  

Недостатки

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

Применимость:

Аутентификация: о, да! Помимо прочего архитектурно является механизмом авторизации.

Пользовательская информация: Нет в силу другого предназначения.

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

Oracle и BEA. Несостоявшаяся сделка.

Хроника событий:

1. 12 октября 2007

Oracle заявляет о том, что 9 октября 2007 сделал предложение совету директоров BEA, в котором предлагает приобрести компанию по цене $17.00 за акцию при рыночной цене акций $13.62. По заявлениям руководства Oracle, предлагаемое поглощение будет исключительно дружественным. Oracle обязуется обеспечить поддержку существующих на сегодняшний день внедрений BEA, точно так как же, как ранее в случае с PeopleSoft и Siebel.

2. 25 октября 2007

Совет директоров BEA заявляет, что предложение Oracle явно занижено. BEA после консультаций с независимыми аналитиками пришла к мнению, что объективная стоимость компании составляет $21.00 за акцию. Письмо, излагающее позицию BEA, направлено в Oracle.

3. 25 октября 2007

Буквально через несколько часов Oracle заявляет, что $21.00 за акцию неприемлемо высокая цена и для Oracle, и для любых других претендентов. Поэтому компания остается при своем первоначальном мнении и предлагает $17.00 за акцию. Кроме того, Oracle устанавливает срок действия своего предложения до 28 октября.

4. 28 октября 2007

Oracle заявляет, что срок действия его предложения истек. По заявлению компании, «если держатели акций BEA недовольны решением совета директоров, то это их задача – предпринять соответственные действия, никак не задача Oracle».

Итого, сделка не состоялась.

Oracle сделал очередную попытку приобрести разработчика middleware, но сделка опять не удалась. Напомним, что до этого Oracle пытался приобрести JBoss, но JBoss предпочел объединиться с Red Hat вместо того, чтобы быть купленным Oracle.

Собственно говоря, ничего удивительного в том, что разработчики middleware не торопятся продать свои компании, нет. Направление SOA сейчас популярно, и нет никакого резона продавать свой бизнес в этой области. Гораздо более интересны мотивы Oracle. Ведь у компании есть свое направление middleware, в котором активно ведутся разработки. С чем связаны такие активные попытки приобрести его аналоги? Это способ устранить конкурентов или компания не удовлетворена темпом и качеством своих разработок и хочет сменить платформу?

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

Novell уволила разработчиков AppArmor

Зачем нужна AppArmor?

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

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

История и нынешнее состояние AppArmor

Технологическая основа AppArmor была создана небольшой компанией Immunix, специализировавшейся на разработке решений для обеспечения безопасности Linux-систем.

В 2005 году Immunix была куплена Novell, после чего продукт был переименован в Novell AppArmor, а ключевые разработчики продолжили работу над ним уже как сотрудники Novell. Этот факт позволил Novell включить AppArmor в свой дистрибутив SuSe Linux и обеспечить его поддержку.

Смогла ли бы Novell обеспечить поддержку AppArmor, не имея его разработчиков в штате? Вряд ли. Мандатный контроль доступа – не только очень мощная технология, но и достаточно сложная. AppArmor всегда позиционировался как простая в использовании система мандатного контроля доступа. Но относительно простая она лишь для пользователя, в разработке и поддержке она ничуть не проще любой другой.

На сегодняшний день AppArmor стал достаточно популярен. В частности, Canonical включила его в новую версию дистрибутива Ubuntu, а Mandriva – в Mandriva Linux 2008. Казалось бы, решение пользуется популярностью, и логично развивать и продвигать его дальше.

Но тут Novell увольняет пятерых ключевых разработчиков, включая лидера проекта (подробнее - http://www.news.com/8301-13580_3-9796140-39.html).

Войдет ли AppArmor в следующие версии SuSe?

Novell заявляет о том, что продолжит поддерживать и обновлять AppArmor. По заявлениям компании, делать это она планирует, сотрудничая с сообществом, образовавшимся вокруг AppArmor.

Возможно ли это? Включать обновленный AppArmor в дистрибутив – конечно да. А вот обеспечить адекватную поддержку комплексной технологии, не имея ее разработчиков в штате, крайне сложно.

Главный вопрос. Почему Novell так поступила? В чем смысл происходящего?

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

Дело в том, что на сегодняшний день существует две системы мандатного контроля доступа – SELinux и AppArmor. Первая из них рассчитана на предельную строгость. Вторая – на простоту настройки. Но простота настройки – явно не первоочередная задача, когда речь идет о системе мандатного контроля доступа. Поэтому подавляющее большинство серьезных внедрений основано на SELinux. AppArmor же используется, как правило, для тестирования и изучения поведения приложений.

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

Какое будущее ждет AppArmor?

Уволенные разработчики заявляют о том, что не собираются бросать проект. На сегодняшний день они создали компанию Mercenary Linux (http://www.mercenarylinux.com/), которая будет разрабатывать AppArmor и оказывать консультации по его использованию. Так как именно эти люди создали AppArmor и координировали его разработку все последние годы, их позиция абсолютно логична и понятна. Если они сейчас перестанут поддерживать проект, велик риск того, что пока вокруг него будет формироваться новая команда, он отстанет в своем развитии от аналогов и будет забыт.

Кроме того, разработчики заявили, что если какая-либо компания заинтересована в развитии AppArmor и хочет приобрести Mercenary Linux, то они всегда готовы обсудить честные предложения.

Сетевые файловый системы

Введение

Идея сетевых файловых систем далеко не нова. Далеко не нова - это значит, что первые реализации файловых систем, внешних по отношению к физическим ЭВМ, появилась в начале 80х - это файловые системы для VAX-VMS кластеров. Эту идею развивали многие компании, в результате чего мы по сути имеем несколько фундаментальных концептов разделяемых файловых систем, не говоря уже о количестве конкретных реализаций данных концептов. Фундаментальные концепты включают сетевые файловые системы (NFS), параллельные файловые системы (Lustre) и симметричные блочно-разделяемые файловые системы (GFS и иже с ними).

Сетевые файловые системы (NFS)

Сетевая файловая система (NFS) - достаточно простое, дешевое и привычное в мире Unix решение для организации разделяемых данных. Спецификации (как и многие реализации) NFS имеют прямое отношение к SUN Microsystems. Всего существует 4 различных спецификации протокола NFS, хотя первая его версия так и не вышла в свет, оставшись навсегда во внутренних тестовых лабораториях SUN. Поэтому наш обзор мы начнем с NFSv2. Напомним, что это концепт удаленной файловой системы, предоставляющей доступ на файловом уровне.

NFSv2

Спецификация NFSv2, выпущенная в далеком 1989 году, полагалась исключительно на UDP в качестве транспортного протокола. Это позволяло создать достаточно простой сервер, который не имел внутреннего состояния (Stateless), что, соответственно, не давало никаких гарантий транзакционности файловых операций (например потому, что файловые операции могли выполняться сервером в порядке дохождения пакетов, который, вообще говоря, может отличаться от порядка операций, задуманного клиентом). Файловые блокировки также были реализованы вне основного протокола, что существенно ограничивало производительность. В частности, многие реализации просто начинали poll'ить заблокированный файл, создавая паразитный трафик и ненужную нагрузку на сервер. Добавим сюда абсолютное отсутствие аутентификации клиента на сервере (мы же не полагаемся на IP-адрес, как на данные аутентификации, правда?) и предположение об однородном пространстве соответствий пользователей и их идентификаторов, что принято было обеспечивать с помощью, мягко говоря, не самого безопасного протокола - NIS, и мы поймем, насколько эта версия NFS слаба и незащищена.

Итого, из плюсов системы можно отметить только:

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

Зато из недостатков:

1. Фактическое отсутствие контроля доступа и шифрования информации.
2. Необходимость использования в "доверенной сети".
3. Необходимость централизации пользовательской информации.
4. Отсутствие транзакционности.
5. Отсутствие поддержки блокировок.
6. Поддержка исключительно синхронных операций записи.
   

NFSv3

Спецификация NFSv3 вышла в чуть менее далеком 95м, хотя, наверное, это знаменательное событие было несколько оттенено запуском Windows 95 =). В новой (по тем временам) спецификации было 4 фундаментальных преимущества перед версией v2. Вот они:

1. Возможность использовать TCP в качестве транспортного протокола.
2. Возможность использовать 64-битные размеры и смещения в файлах, что позволяло использовать большие файлы (более 4Гб).
3. Поддержка асинхронного ввода-вывода.
   
4. Реализация файловых блокировок в протоколе.
   

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

NFSv4 aka текущая версия

Данная спецификация была разработана в 2000 году и пересмотрена в 2003. В то время спецификация уже вышла из-под контроля SUN (как в свое время сделали немало других спецификаций, например, спецификации Java). Из принципиальных улучшений стоит отметить:

1. Поддержку аутентификации хостов и пользователей (например, средствами Kerberos).
2. Поддержку шифрования информации.
   
3. Поддержку "продвинутых" методов клиентского кэширования.

В спецификации есть дополнительно много мелких улучшений (со списком можно ознакомиться в RFC3530).

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

Параллельные файловые системы (Lustre)

Авторы утверждают, что название этой файловой системы произошло от смешения слов Linux и cluster, хотя лично нам аналогия с люстрой кажется несколько более очевидной. Это файловая система обладает максимальной производительностью, масштабируемостью и является наиболее успешным примером файловой системы, которая, например, используется в MPP-системах, таких как вычислительные кластера. Это байт-ориентированная файловая система. Принцип устройства файловой системы достаточно комплексен, так что рекомендую читать более одного раза =). Базовых компонент три:

1. Сервер метаданных (возможно с активным/пассивным резервированием). Данный сервис отвечает за метаданные, такие как структура директорий, атрибуты и имена файлов, а также указывает на положение "объектов", составляющих файл, на экземплярах следующей компоненты.
2. Сервер хранения. Это сервер, к которому может быть подключено несколько "целей хранения", или, если по простому, блочных устройств. В настоящее время на этих блочных устройствах используется несколько видоизмененная файловая система ext3 для хранения объектов. Типичная конфигурация сервера хранения предусматривает наличие от 2-х до 8-ми "целей", каждая объемом до 8 Тб. Общий объем файловой системы равен сумме объемов целей, ее составляющих.
3. Клиент. Без особых комментариев. Клиент находит необходимый ему файл (а точнее, объекты его составляющие), пользуясь сервером метаданных. Затем блокирует определенный диапазон смещений внутри файла и обращается к серверам хранения, которые непосредственно модифицируют данные на своих "дисках".

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

Подобный концепт обеспечивает наилучшую масштабируемость и производительность, за что Lustre снискала немалую популярность в научном мире (Lustre используется в 30 из top 50 суперкомпьютеров). Однако для бизнеса это решение не очень подходит, потому что требует солидного количества аппаратуры для работы, а значит - излишне громоздко для типичных бизнес-задач, вроде кластера СУБД. Для подобных задач остроумные люди придумали симметричные разделяемые (кластерные) файловые системы с доступом к устройству хранения на блочном уровне.

Симметричные ФС с разделяемым диском (GFS, GFS2...)

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

• Могут использоваться любые протоколы доступа к разделяемому блочному устройству, будь то стандартные (FC, iSCSI) или софтверные линуксоспецифичные (GNBD). Естественно, каждый из методов обладает своими преимуществами и недостатками.
• Должны использоваться кластерные службы, в частности, cman (задача - обеспечение функционирования распределенного менеджера блокировок), fence (задача - "отсечение" некорректно работающих узлов от данных и восстановление).
• Для управления хранилищем данных обычно используется CLVM, кластерный вариант управления логическими томами от Red Hat. Принцип действия, за исключением блокировок, тот же самый, что был описан в предыдущих постах для LVM.
• Используется журналирование метаданных и данных, что обеспечивает, соответственно, целостность файловой системы/даных.
  

Общий алгоритм работы выглядит следующим образом:

• Каждый узел занимает свой индивидуальный журнал.
• Информация о блокировках распределена между узлами. В нормальном положении все узлы в курсе всех блокировок.
• Узлы открывают файлы и работают с данными. При этом клиенты осуществляют прямой параллельный доступ к ФС, работая с данными на блочном уровне.
• ФС поддерживает изменение размеров (только в большую сторону) без отключения.
  

В случае отказа одного из услов происходит горячее восстановление по следующему алгоритму:

1. Узел "убивается" (fence). Обычно это осуществляется физическим отключением питания, используя какие-либо сетевые устройства (APC, HP iLO,...).
2. Один из узлов в кластере завершает свои операции и освобождает свой журнал, забирая себе журнал сбойного узла.
3. Операции по журналу сбойного узла откатываются/завершаются и система продолжает функционировать как ни в чем ни бывало.

При всем при этом производительность решения с параллельной симметричной блочной ФС выше, чем у NFS, не требуя при этом того колчества доп. аппаратуры, которое используется в Lustre. GFS давно стала привычной технологией для решения бизнес-задач, вроде организации кластеров СУБД, благодаря некоторым расширениям POSIX, которые предоставляет GFS, как-то:

• Direct I/O - синхронный режим записи на диск для определенных файлов.
• Freeze/Unfreeze - возможность приостановить работу с FS (корректно "подвесив" системные вызовы на прочих узлав) с одного узла (например, для нужд обслуживания).
• CDPN (Context Depending Path Names - контекстно-зависимые пути к файлам), позволяющий хранить данные, специфичные для узла, на общей файловой системе.

К сожалению, первая версия GFS не была лишена недостатков. К числу их можно отнести:

1. Хранение журналов "рядом" с файловой системой, а не на ней. Это приводило к ситуации, в которой нельзя было увеличить количество журналов, не уменьшив объем файловой системы (что, напомним, делать онлайн нельзя), либо не увеличив размер логического тома.
2. Отсутствие поддержки хранения информации SELinux (контекстов файлов).
3. Падение производительности при работе с большим количеством мелких файлов.

Эти недостатки были исправлены в этом году с выпуском версии GFS2.

Резюме.

В Linux наблюдается огромное разнообразие (многие считают его избытком) поддерживаемых файловых систем, локальных и сетевых. Причем в отношении сетевых ФС в полной мере справедливо правило UNIX: каждый инструмент решает свою четко очерченную задачу. В этом плане сетевые файловые системы (NFS) удобно использовать для небольшого количества клиентов и интенсивного ввода/вывода, GFS - для интенсивных задач ввода/вывода в масштабах типичного бизнес-кластера, а Lustre - для MPP-систем.

Области применения виртуализации. Часть 1.

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

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

На самом деле в некоторых ситуациях виртуализация позволяет увеличить производительность приложений. Не торопитесь кричать «Бред!», дочитайте сначала до конца.

Подход к увеличению производительности

В течении уже многих лет инженеры Red Hat и Intel совместно работают над оптимизацией работы Red Hat Enterprise Linux на оборудовании Intel. В последнее время они работали над поддержкой новейших платформ Intel Caneland на базе четырехядерных процессоров Tigerton. В результате эти системы будут полностью поддерживаться в Red Hat Enterprise Linux 5.1, выходящем в октябре 2007г. Предварительные тесты показывают просто фантастическую производительность.

Кроме того, в Red Hat Enterprise Linux 5.1 войдут паравиртуализованные драйвера для полностью виртуализованных гостевых систем. Эти драйвера позволяют полностью виртуализованным гостевым системам практически достичь производительности паравиртуализованных. На сегодняшний день готовы драйвера для Red Hat Enterprise Linux 3 и решается вопрос о драйверах для операционных систем других производителей.

Таким образом, возможно развернуть весь стек приложений, основанный на Red Hat Enterprise Linux 3, в гостевой системе на новейшей платформе Caneland и таким образом добиться значительного прироста производительности.

Зачем здесь вообще виртуализация? Дело в том, что старые системы не поддерживают новое оборудование. А для переноса полного стека приложений на Red Hat Enterprise Linux 5 время и ресурсы есть не всегда.

Тесты производительности

Разумеется, мало сформулировать подход, надо еще и доказать его состоятельность. По запросу Red Hat и Intel независимая лаборатория Principled Technologies провела тесты производительности изложенного выше подхода.

Полный отчет о тестах SPECjbb2005, SPECcpu2006 и Linpack Вы можете найти на http://www.principledtechnologies.com/clients/reports/Red%20Hat/RHEL51_VirtReps.htm

Если же в двух словах, то, например, тест SPECjbb2005 показал следующее:

• Система на процессорах Xeon и Red Hat Enterprise Linux 3 показала результат 210,000 операций в секунду (4 двухядерных процессора, гипертрединг, в итоге 16 исполняемых нитей).

• Система на основе Caneland и Red Hat Enterprise Linux 5 показала результат 380,000 операций в секунду (4 четырехядерных процессора, также 16 нитей).

• Гостевая система Red Hat Enterprise Linux 3 на хост-системе на основе Caneland и Red Hat Enterprise Linux 5 показала результат 340,000 операций в секунду.

Таким образом, использование виртуализованного Red Hat Enterprise Linux 3 на Caneland-системе позволило получить прирост производительности более 50%.

Комментарии

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

Отдельно стоит отметить, что при решении подобных задач решения на основе Xen оказываются гораздо эффективнее, чем на основе VMware. Дело в том, что VMware не поддерживает для одной гостевой системы более 4 исполняемых нитей. То есть VMware может использовать не более четверти мощности Caneland-систем. Xen же позволяет использовать мощность нового оборудования на 100%.

Где это будет востребовано

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

Яркий пример – САПР. В этой области отладка программ и введение в промышленную эксплуатацию вычислительного комплекса может занимать до нескольких лет. Поэтому возможности быстро перенести приложения на новую систему нет. При этом вопросы производительности в задачах САПР стоят очень остро.

Крайне похоже обстоит дело с корпоративными системами на базе Oracle или SAP – их внедрение процесс длительный и дорогостоящий, поэтому любая миграция оказывается крайне болезненной.

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

Microsoft проиграла иск в Евросоюзе

О чем вообще речь?

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

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

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

Но на самом деле основной вопрос разбирательства – информация о интерфейсах сетевого взаимодействия Windows-систем и о протоколах CIFS. Эта информация критична для нормального взаимодействия Linux и Windows-систем. А актуальность этой проблемы очевидна всякому, кто пробовал, например, интегрировать Linux-системы с Active Directory. На сегодняшний день это достаточно трудоемкая задача, требующая немалого объема знаний.

Казалось бы – откуда вообще возникает проблема? А дело именно в том, что Microsoft не раскрывает протоколов взаимодействия. Более того, она регулярно их меняет. И до тех пор пока команда проекта Samba (цель которого – как раз организация взаимодействия Linux и Windows-миров) вынуждена получать информацию о протоколах взаимодействия методами reverse engineering и постоянно отслеживать их изменения, проблема окончательно решена не будет.

Учитывая то, что Samba используется в серверах рабочих групп Sun, Novell, IBM, Apple, в подавляющем большинстве NAS дешевле $5000, становится ясен истинный масштаб вопроса – и он гораздо серьезнее, чем интеграция медиаплеера в операционную систему. По сути, вопрос предоставления или не предоставления информации о протоколах взаимодействия – это вопрос того, сможет ли хоть одна компания работать с любыми сетевыми решениями, не заплатив предварительно Misrosoft.

Что решил суд?

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

Это победа?

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

Что самое интересное, по сути против корпорации боролись всего несколько человек – команда проекта Samba, которую юридически в суде представляли FSF Europe и итальянский юрист Carlo Piana. И они победили.

И никаких проблем больше не предвидится?

А вот этого никто не обещал. Мало выиграть дело в суде, теперь надо реально получить от Microsoft информацию.

Основная проблема в том, что несколько лет назад, после решения еврокомиссии 2004 года, Microsoft пыталась предоставить требуемую документацию. И не смогла – участники программы MCPP (программа лицензирования протоколов) заявили, что в рамках программы они не получить никакой новой информации по сравнению с тем, что знали до вступления в программу. Получается, что у Microsoft просто нет полноценной документации собственной реализации протоколов взаимодействия даже для избранных партнеров.

Ощущение такое, что Microsoft может собрать требуемую информацию только путем reverse engineering`а собственного кода.

Что в итоге?

Борьба не закончена, но пройден крайне важный этап. Если Microsoft хочет остаться на рынке Евросоюза, ей придется пойти на компромисс и все же предоставить требуемую информацию. И это крайне важный прецедент. Впервые компанию-монополиста (будем называть вещи своими именами) обязали предоставить информацию, необходимую для появления честной конкуренции.

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

Дополнительная информация

Пресс-релиз Samba и FSFE:

http://mail.fsfeurope.org/pipermail/press-release/2007q3/000186.html

Интервью с людьми, внесшими основной вклад в победу:

http://www.groklaw.net/article.php?story=20070919214307459

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

LVM. Управление Логическими Томами

Введение

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

1. Размер создаваемой единицы хранения данных ограничен размером физического диска. (или RAID-массива, что немногим лучше)


2. Ограничены возможности управления хранилищем.
   


3. Отсутствует возможность он-лайн увеличения хранилища.
   


4. Отсутствуют встроенные возможности обеспечения избыточности (здесь мы имеем ввиду средства разбиения, а не Linux software RAID).
   


5. Отсутствует гибкость проведения он-лайн архивирования системы с динамично меняющимися данными.
   


6. Сложности с динамическим именованием устройств, хотя они и несколько обходятся с помощью UDEV и монтирования по меткам.
   

Все эти (а на самом деле не только эти) проблемы решены в системе, получившей название LVM (Logical Volume Management), которая уже давно является частью "Ванильного" ядра Linux. Эта система делает управление данными под Linux "просто сказкой". Если вы еще не знакомы с ней - самое время. Как обычно, все примеры приведены для системы RHEL5, но, скорее всего, с минимальными изменениями будут работать в других дистрибутивах.

Условные обозначения

1. Физический том (Physical Volume, или PV) - специальным образом отформатированное блочное устройство. Может быть как диском целиком, так и партицией, MD-устройством и т.д.
   


2. Логическая группа (Volume Group, или VG) - по сути "пул ресурсов". Имеет логическое и физическое представление. С физической точки зрения является объединением физических томов, с логической точки зрения является "емкостью", из которой "разливаются" логические тома.
   


3. Логический том (Logical Volume, или LV) - собственно логическая "партиция", расположенная на логической группе.
   

Основы практической работы

Работает все это следующим образом. Физические партиции форматируются в физические тома, например вот так:

 # pvcreate /dev/sda

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

 # vgcreate -s 32M vg0 /dev/sda

По сути, единственный актуальный параметр - это так называемый Physical Extent Size. Он определяет "квант" места, то есть единицу, до которой округляются все размеры логических томов. По сути Extent - это "клеточка", в которую "разлинована" ваша логическая группа.
После того, как мы сделали логическую группу, время создать логические тома:

 # lvcreate -L10G -n lvol vg

Последняя команда создает логический том в группе vg0. Она имеет множество опций, самые важные, впрочем, это -L РАЗМЕР -n ИМЯ. Возможно также задать политику расположения (аллокации) логических экстентов на физических, сделать LV "зеркалируемым" или "черезполосным" (Stripped - аналог RAID0).
Теперь самое время отформатировать логический том нашей любимой файловой системой EXT3:

 # mkfs.ext3 /dev/vg0/lvol

Обычно в Red Hat Enterprise Linux симлинки на логические тома доступны по пути /dev/[лог. группа]/[лог. том].
Допустим, что позднее мы добавляем в систему еще одно блочное устройство /dev/sdb. Причем хотим не просто добавить, а использовать его как "расширение" уже имеющегося хранилища, желательно в рамках той же файловой системы и без остановки приложений. Делается это следующим образом: форматируем новое устройство как физизческий том:

 # pvcreate /dev/sdb

Расширяем имеющуюся логическую группу, вводя в нее новорожденный физический том:

 # vgextend vg0 /dev/sdb

Расширяем логический том, добавляя, например, еще 10Gb места:

 # lvextend -L +10G /dev/vg0/lvol

После чего осталось лишь расширить файловую систему на устройстве. К счастью для нас файловая система Ext3 (как впрочем и GFS) поддерживает online resize в большую сторону.

 # resize2fs /dev/vg0/lvol.

вполне могут располагаться на разных физических дисках. В итоге размер физического устройства не является причиной не иметь разделы большего размера. =) И при этом оставаться чрезвычайно гибким в управлении хранением данных.

Принципы устройства и прочие возможности

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

Допустим, каждому выделяемому логическому экстенту ставятся в соответствие 2 физических, убеждаясь при этом, что они расположены на разных физических томах. Получается естественный метод "зеркалирования", то есть функциональность RAID1. Это все просто и интересно, но не самое оригинальное и не это самое прекрасное в LVM.

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

Прекрасно то, что LVM "собирается" каждый раз по UUID-идентификаторам, которые расположены на самих разделах. LVM не зависит от порядка обнаружения SCSI-устройств, моделей именования устройств и прочих мелочей.

Наконец, LVM поддерживает технологию Snapshots. Эта технология крайне напоминает технологию COW (Copy-on-Write, копирования при записи), используемую в linux при создании новых процессов. При создании Snapshot'а логического тома все логические "клеточки" созданного тома-снапшота ссылаются на те же самые физические "клеточки" блочных устройств, что и «клеточки» исходного тома. Это означает, что одни и те же данные доступны по двум логическим именам. Это же, кстати, делает процесс создания снапшота любого размера практически мгновенным. При изменении одной из "копий" данных логические ячейки разносятся. Это позволяет двум логическим томам использовать совместно неизменяемую часть данных, поддерживая независимо только различающуюся часть.

Такой подход значительно экономит ресурсы диска, но это не главное. Главное – что со снапшота очень удобно производить резервное копирование файловых систем, содержащих динамично изменяющиеся данные (например, данные СУБД). Алгоритм прост:

1. Создаем снапшот, "замораживая" состояние логического тома для резервного копирования. При этом мы не блокируем исходный LV, приложения могут продолжать работать и изменять данные на нем.
   
2. Спокойно делаем резервную копию со снапшота.
   
3. Уничтожаем снапшот и продолжаем работу как ни в чем ни бывало.
   

Заключение

Тут и сказочке конец. Можно еще добавить, что Red Hat предоставляет довольно удобный графический инструмент для управления LVM (system-config-lvm), который позволяет делать все описанное несколько быстрее. А самое интересное - большинство возможностей LVM уже давно доступно и в кластерном варианте (CLVM - Cluster Logical Voume Management). Но об этом в другой раз.

Создание дистрибутива Linux

Текст обновлен 27.09.07.

За последние годы многие страны делали громкие заявления о создании национальных операционных систем на основе Linux. Прошли годы, но никто из них так и не преуспел. Самую громкую неудачу потерпел Китай. Цель данного документа – дать обзор основных «компонентов», из которых создается дистрибутив Linux, сделать некоторые оценки насчет стоимости подобного проекта и выгоды от него, описать основные подходы к его реализации.

Часть 1. Что такое "Мой Личный Linux"?

Итак, если говорить о типичном дистрибутиве Linux, то что лежит в его основе? Какие основные “компоненты” делают архив программных пакетов дистрибутивом?

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

2. ПОЛИТИКА. Исходя из целевой аудитории необходимо определить политику развития и выбрать те версии программ, которые отвечают вашим потребностям. Включать ли в дистрибутив «новейшие» программы или «проверенные временем» - это полностью зависит от вашей аудитории. Например, Red Hat Enterprise Linux ориентирован на корпоративный сектор, поэтому его политика - «новейшие из стабильных»; Ubuntu ориентирован на домашние компьютеры и его политика - «новейшие» пакеты и т.д..

3. СИСТЕМА СБОРКИ. Основой для превращения разрозненных программ в дистрибутив служит система управления пакетами. После того, как политика определила, что включать в дистрибутив, система сборки определит, как это сделать. Стандартом LSB (Linux Standard Base) является система RPM. Тем не менее, DPKG или еще какие-либо системы также могут быть вариантами.

4. ПРАВИЛА. Необходимо сформулировать правила и четко следовать им. “Чистый” open source очень гибок. Это означает, что все правила, которым будет подчиняться ПО с составе дистрибутива, необходимо определить самостоятельно. В частности, это относится к тому, куда устанавливать ПО и библиотеки, где и в каком виде хранятся файлы настроек и т.д.

Часть 2. Пятый элемент.

Таким образом, все выглядит несложно. Необходимо только сделать некоторое количество рутинной работы – выбрать “нужные” версии “нужного” программного обеспечения, “нужным” образом его собрать в “нужные” пакеты. Технически это очень просто, и именно по этой причине многие создают свои дистрибутивы.

Однако, для создания успешного дистрибутива необходимо задуматься еще о ряде вопросов. И именно по этой причине ведущие дистрибутивы Linux можно пересчитать по пальцам одной руки. Что же мешает всем остальным? Ответ на этот вопрос следует из основного подхода к бизнесу вокруг open source:

«В open source нет ни лицензионных отчислений, ни интеллектуальной собственности – все держится на полезных для пользователя дополнениях к технологии».

Отсюда возникает «пятый элемент», о котором большинство забывают:

5. ДОПОЛНЕНИЕ К ТЕХНОЛОГИИ. Ключевой вопрос при создании эффективной Linux-компании – каково ВАШЕ дополнение? Что вы предлагаете своим клиентам? Чем вы отличаетесь от всех остальных?

Ведь если компания не предлагает ничего своего, то зачем с ней вообще работать, если все те же компоненты дистрибутива можно взять самостоятельно?

Часть 3. Информация к размышлению.

1. НЕУПРАВЛЯЕМЫЕ ПАКЕТЫ. Вы можете включить в дистрибутив ПО, на развитие которого никак не влияете. Давайте возьмем для примера типичный дистрибутив, состоящий из примерно 3000 пакетов. Сколько разработчиков работают над ними? Тысячи, а скорее даже десятки тысяч. А теперь задайтесь вопросом – сколько из них будут работать для вас? Если ответ меньше чем хотя бы «сотни» - вы явно не лидер. Вы не определяете развитие «своего» продукта. Вы, конечно, можете изобрести велосипед еще раз, создать неплохой «Еще один дистрибутив», но кому это надо? Кто будет заинтересован в продукте, который не может определить свою собственную стратегию развития?

2. ПОДДЕРЖКА 3-ГО УРОВНЯ. Для обеспечения адекватной поддержки вам необходимо наладить постоянный контакт с сообществом разработчиков. А сделать это можно только активно участвуя в разработке и тем самым зарабатывая себе авторитет. Без этого ваша поддержка будет крайне ограниченной. Разумеется, можно нанять десяток человек и организовать call-центр. Но такая служба поддержки не сможет решить хоть сколько-нибудь сложную проблему, требующую вмешательства в код. В этом случае ваш дистрибутив никто никогда не установит на важные системы, потому что ему нельзя доверять.

3. ЧЕЛОВЕЧЕСКИЕ РЕСУРСЫ. Для того, чтобы создать ведущий дистрибутив, недостаточно как-нибудь участвовать в разработке. Невозможно нанять 500 любых разработчиков и стать лидером, потому что эти люди до данного момента не участвовали в каких-либо проектах. Для того, чтобы определять развитие продуктов, необходимо иметь с своем штате «ключевых» разработчиков. Но большинство этих людей уже работают в крупных корпорациях, таких как Google и Red Hat. Таким образом, после того как вы наймете несколько сотен разработчиков, вам придется очень постараться, чтобы они вошли в команды разработки ключевых проектов хотя бы в ближайшие 3 года. Мы сейчас не говорим о том, чтобы возглавить эти проекты, неплохо будет, если они хотя бы войдут в число основных разработчиков. Особая история – разработчики ядра. Они необходимы в команде, если мы говорим о серьезном дистрибутиве, и их сложнее всего найти. И не забывайте – вам придется платить им все эти годы.

4. СЕРТИФИКАЦИИ. До тех пор, пока вы не подниметесь на определенный уровень, вы не станете частью «экосистемы». Дело в том, что операционная система сама по себе – одна из наименее привлекательных вещей в мире. Без ПО под нее она не стоит вообще ничего. А так как вы не являетесь ведущей компанией, то назовите хотя бы одну причину, по которой независимым разработчикам, таким как Oracle, IBM, SAP и т.д. стоит прикладывать усилия и поддерживать свои приложения на вашем дистрибутиве? Для них гораздо рациональнее работать с признанным корпоративным стандартом, таким как, например, Red Hat. Точно так же обстоит дело с поставщиками оборудования. Вам потребуется как завоевать определенную техническую репутацию, так и занять заметную часть рынка, прежде чем станет возможным сотрудничать с ведущими компаниями.

Часть 4. Создание дистрибутива «революционным» способом.

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

Давайте оценим, во сколько минимально обойдется этот процесс, если выполнять его «революционно», в одну стадию. В качестве примера успешной Linux-компании мы возьмем Red Hat. Относится к Red Hat можно по разному, но Red Hat – это признанный мировой стандарт в области корпоративного Linux. Также мы сделаем оптимистичное предположение, что вы успешно пройдете все этапы, уложившись в намеченные сроки.

В Red Hat около 700 разработчиков, которые создают около 10% кода, входящего в итоге дистрибутив. Так как мы ставим цель стать сильным дистрибутивом, но не обязательно лидером, то мы можем ограничиться 500. Ниже опускаться уже просто опасно – можно потерять контроль над продуктом.

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

Как упоминалось выше, потребуется некоторый срок, прежде чем разработчики начнут в достаточной степени влиять на проекты, в которых они участвуют. Таким образом мы получаем некоторое «мертвое время», в которое компания уже работает и требует денег на содержание, но еще не является значимым игроком на рынке. Оптимистичная оценка этого времени – 3 года. Таки образом, это «мертвое время» обойдется как минимум в $54 000 000. При этом нет, вообще говоря, никакой гарантии, что после этого компания заработает.

На этой стадии, пожалуй, стоит задать себе вопрос – готовы ли вы потратить $55 000 000 на работу, которая УЖЕ сделана, не имея при этом НИКАКИХ гарантий, что в итоге получится хоть что-то новое и значимое?

Кроме того, существует множество рисков, которые невозможно строго учесть – в конце концов, сообщество может не принять ваш дистрибутив лишь потому, что им не понравится ваша политика или логотип. К тому же, мир появление еще одного дистрибутива явно не изменит. Таким образом, затраты на то, чтобы стать «вторым лучшим» оказываются велики, а выгода весьма сомнительна.

План действий.

Основные этапы создания дистрибутива «революционным» способом:

1. Определить, что же будет вашим дополнением к технологии – лучший сервис, более удобный интерфейс, поддержка решений? На этом этапе важно не сделать типичной ошибки – не делать основной особенностью дистрибутива лишь его “национальность”. Этим вы ничего не добавите, а лишь отнимете. Основное преимущество open source – его открытость, порождающая очень быстрый темп инноваций. Постановка любых границ лишит ваш продукт этого преимущества.

2. Создать команду, пользуясь опытом одной из ведущих компаний. Для этого обучить сначала техническую поддержку, затем программистов (вплоть до разработчиков ядра). В лучшем случае это займет около 3 лет (см. выше).

3. Имея готовую команду должного уровня, можно либо создавать свой дистрибутив с нуля, либо сотрудничать с ведущими разработчиками.

Основные проблемы.

Хотя описанный выше подход и может привести к успеху в конечном итоге, он имеет два существенных недостатка:

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

2. Необходимость больших вложений уже на первом этапе. Как оценено выше, «революционный» подход требует вложения десятков миллионов долларов на долгий срок. При этом неоправданно высок риск, что итоговый продукт окажется актуален лишь для очень узкого круга заказчиков, и в итоге вложения окажутся непропорционально большими.

Часть 5. Создание дистрибутива «эволюционным» способом.

Альтернативой описанному выше подходу может быть другой – «эволюционный», лишенный указанных недостатков.

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

План действий.

Основные этапы создания дистрибутива «эволюционным» способом:

1. Достигнуть договоренности о сотрудничестве с одной из ведущих компаний, имеющей налаженные схемы взаимодействия со всеми участниками рынками. Цель – получить доступ к “закрытой” части их работы и к каналам взаимодействия.

2. Создать команду для включения поддержки дополнительных языков в «базовый» дистрибутив. Дело в том, что мировые дистрибутивы поддерживают только основные языки (русский, английский и т.д.) и не поддерживают локальные языки, которые могут быть нужны для использования дистрибутива в отдельных республиках. Оценочный размер команды – 5-10 человек.

3. Создать команду для внедрений и последующей поддержки. Инженеры этой команды решают типовые вопросы, а в сложных ситуациях, требующих взаимодействия с разработчиками или третьими компаниями, используют налаженные каналы сотрудничающей компании. Оценочный размер команды – 20-40 человек.

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

5. При достижении «критической массы» знаний и опыта можно создавать свой дистрибутив, продолжая сотрудничество. В этом случае дистрибутив имеет множество «точек опоры» (собственная команда разработки и поддержки, сотрудничество с командой «дружественного» дистрибутива, взаимодействие с независимыми разработчиками), и за счет этого никакие локальные проблемы не ведут к провалу проекта в целом. В конечном итоге такой подход порождает УСТОЙЧИВЫЙ дистрибутив.

Комментарии.

Такой «эволюционный» подход практически устраняет риск провала проекта на начальной стадии, так как использует всю инфраструктуру и возможности компании, которая УЖЕ успешно работает в области серьезных внедрений и поддержки Linux.

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

Вывод

Создание “Моего Личного Linux” - крайне сложный и дорогой проект с весьма сомнительными коммерческими перспективами. Единственными разумными причинами создания такого дистрибутива могут быть безопасность и независимость.

Следовательно, компания-разработчик не может быть просто “сборщиком пакетов”. Компания, ставящая своей целью обеспечить высочайшую безопасность, должна быть активным участником сообщества разработчиков, причем ее сотрудники должны быть вовлечены в работу над основными компонентами системы.

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

ODF - Очень Доступный Формат.

В 1999г ученому потребовались данные об образцах марсианского грунта, взятых аппаратом «Викинг» в 1975г. Он хотел проверить теорию о существовании марсианских бактерий и микробов – иными словами, о наличии на Марсе жизни. Ученый рассчитывал найти нужную информацию на сайте NASA, но это оказалось не так-то просто. После долгих поисков наконец были найдены старые кассеты с данными, но они были в «формате настолько старом, что его разработчики уже умерли». А ведь у кого-то была теория, позволяющая узнать чуть больше о жизни и о вселенной. Потеря этого знания перекликается с гибелью Александрийской библиотеки. А то, каким образом оно было потеряно, чем-то напоминает сожжение книг – за уничтожение знания полностью ответственны люди.

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

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

Если говорить об электронных документах, то способ защититься от потери информации из-за проблем форматов ее хранения уже существует. Причем эта технология уже достаточно широко используется и распространяется все шире. Имя ей – Open Document Format (ODF). Если вы не пользуетесь ей сегодня, значит вам еще предстоит открыть ее для себя.

ODF – это формат хранения документов, основанный на XML. ODF был изначально разработан в 1999г Stardivision и затем развивался в рамках проекта Openoffice.org компанией Sun Microsystems. Формат был создан как открытая и свободная альтернатива коммерческим закрытым форматам хранения документов, которые доминируют на сегодняшний день. Цель создания ODF – получить формат, не зависящий ни от конкретной компании, ни от конкретного приложения. Формат, который будет доступен для чтения и записи всем без каких-либо ограничений, связанных с лицензиями или интеллектуальной собственностью.

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

В 2002г был создан консорциум OASIS (Organization for the Advancement of Structured Information Standards), который работал над стандартизацией формата и его подробным документированием. В итоге в 2006г формат ODF был принят как международный стандарт ISO представления электронных документов. В 2007г он был принят и как стандарт ANSI.

В марте 2006г был образован «ODF-альянс». Цель альянса – способствовать распространению ODF, разъяснять преимущества открытых форматов, особенно для государственных и общественных организаций.

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

Противники ODF активно препятствуют его внедрению. При этом никто из них не спорит с самой необходимостью внедрения новых форматов. Атаке подвергаются открытые стандарты, на которых основан ODF. С точки зрения противников ODF сейчас все идет более чем хорошо. «Стандарты» принадлежат им. «Рынок» документооборота полностью зависит от них, они считают его своей «территорией», которую они «заняли» плотно и надолго. Они не могут представить будущее иначе (это не входит в их бизнес-план). Нынешняя ситуация их устраивает, все зависят от их приложений и форматов, так зачем им что-то менять? Противники ODF тратят значительные усилия, стараясь создать мнение, что ODF вреден и создает дополнительные сложности (в первую очередь для них самих). Они говорят, что переход на новый формат потребует значительных средств. Иногда они даже говорят, что введение ODF затруднит доступ к информации из-за того, что возникнет слишком много различных форматов. В конце-концов, кому вообще нужна открытость форматов?

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

С точки зрения ODF-альянса, введение открытого формата как стандарта стимулирует здоровую конкуренцию поставщиков. Открытость формата ставит всех в равные условия – все разработчики могут свободно реализовать поддержку открытого формата в своих приложениях. В ситуации, когда формат не принадлежит никому, выигрывает тот, кто создает лучшие приложения, наиболее удобные для пользователей. Стоимость перехода на ODF при этом не выше, чем стоимость перехода с одной версии закрытого формата на другую. А если учесть, что закрытые форматы изменяются регулярно и переходить на новые версии приходится также регулярно, то оказывается, что разовый переход на открытый стандарт на деле дешевле. Что касается возможности работы с ODF, то OpenOffice (и другие приложения, поддерживающие ODF) можно уже сегодня скачать свободно и бесплатно и начать использовать. Ни технических проблем, ни проблем с совместимостью на сегодняшний день не существует. Есть только проблемы, связанные с непониманием.

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

Основной аргумент в пользу ODF – если государство использует закрытый коммерческий формат в качестве стандарта, оно тем самым вынуждает всех граждан пользоваться тем же форматом, что создает режим наибольшего благоприятствования одной компании (по сути создавая монополиста).

Несмотря на все препятствия, по мере того, как люди понимают, что означает открытость стандарта, ODF завоевывает все новых сторонников. На сегодняшний день в Японии для всех государственных учреждений обязательна работа только с теми приложениями, которые основаны на открытых стандартах. Заявления о готовности перейти на ODF сделали Бразилия, Польша, Малайзия, Италия, Корея, Норвегия, Франция, Голландия, Дания, Бельгия, часть государственных органов США и Индии. И что даже более важно, все эти страны заявили о том, что каким бы ни был итоговый стандарт, он обязательно должен быть открытым.

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

Люди, принимающие решения о подобных переходах, загружены огромным количеством других важных дел (здравоохранение, образование, транспорт и т.д.), поэтому технологические вопросы для них не приоритетны. В распространении ODF уже заметен заметный прогресс. Некоторые государства уже приняли его, но работы еще предстоит много.

Ниже приведены ссылки на логотипы и постеры кампании в поддержку ODF. Что вы можете сделать? Скачать их, распространять, печатать на постерах и футболках. А главное - нести информацию дальше. Разъяснять необходимость использования открытых форматов.

• Логотип в формате .png


• Логотип в формате .sla


• Логотип в формате .svg


• Постер в формате .sla


• Постер в формате .svg


• Постер в формате .pdf