Время шляп. Красных.

Пять облачных предсказаний на 2012 год

2012-01-16T11:11:00.000+04:00

По мнению специалистов Red Hat, 2012 год принесет нам больше эволюционных, чем революционных изменений в сфере облачных вычислений. И это совсем не плохо, так как означает, что наконец-то произошло слияние основных концепций и начался переход от теории к практике.

Конечно, в 2012-м будет продолжена работа по исследованию и накоплению знаний этой области из-за того, что облачными вычислениями часто называют всю сферу “ИТ нового поколения”, развитие которой не останавливается ни на секунду. И даже используя данный термин в более узком значении, мы подразумеваем различные подходы “X-as-a-Service” как для частных облаков на корпоративном уровне, так и в отношении публичных облачных вычислений. Очень важно понимать, где могут использоваться данные подходы и каковы их точки пересечения. Более того, даже “первопроходцы” всё еще ищут наилучшие способы построения облаков.

В 2012 г. будет больше внедрений облачных продуктов и их практического использования. Некоторые компании уже приступили к этому, начав с ПО, разрабатываемого по их заказу. Распространено мнение, что выгода от упрощения администрирования и автоматизации так велика, что нет смысла в ожидании более доступного облачного ПО, даже если первый шаг требует больших усилий. Однако с такими продуктами, как IaaS CloudForms от Red Hat, организации могут начать использовать облачные вычисления без существенных первоначальных затрат. Это только начало движения по пути к широкому использованию облачных вычислений, но мы надеемся, что компании уже в нынешнем году перейдут от планирования к практическому использованию облаков.

При оценке практической пользы от облачных вычислений в организациях, стали чаще обсуждать интероперабельность, мобильность и кроссплатформенность. Данные вопросы уже давно волнуют специалистов ИТ-отделов. В 2010 г. Гэри Чен (Gary Chen), менеджер IDC по изучению рынка ПО для виртуализации в корпоративном секторе, написал: “Согласно нашему исследованию, 80% предприятий ссылаются на отсутствие интероперабельности как на основную проблему в переходе на облачные вычисления. Однако Red Hat нашла решение этого вопроса: развивая интероперабельность и мобильность, она снижает зависимость компаний от продуктов и сервисов одного поставщика”. Тем не менее эти аспекты облачных вычислений всё чаще обсуждаются по мере изучения характеристик предлагаемых облачных продуктов.

Вероятней всего, в 2012 г. работа по стандартизации останется на ранней стадии. Причиной тому очень быстрое развитие технологий, что затрудняет какое-либо формальное принятие стандартов. Кроме того, де-факто стандарты, предлагаемые некоторыми вендорами по сути являются проприетарными интерфейсами для их ПО. Red Hat ведет работу по стандартизации в рамках Cloud Management Working Group (CMDG) в ассоциации DMTF. Также активно развивается интероперабельность и мобильность другими способами — например, в проекте Deltacloud под руководством Apache Software Foundation.

И наконец, еще больше внимание будет уделено крупным объемам данных. Оцифровка и мобильность приводят к увеличению объемов неструктурированных данных, для которых обычные БД и SAN-хранилища не подходят как в техническом, так и в экономическом плане, что заставляет искать новые решения. Вот почему в октябре 2011-го Red Hat приобрела частную компанию Gluster (теперь Red Hat Storage). По той же причине NoSQL-вендоры, в частности MongoDB, ориентируются на такие продукты Red Hat как, например, PaaS OpenShift.

Источник: PC Week/RE, по материалам Red Hat.

Red Hat выпускает первый релиз интегрированного продукта для масштабируемого хранения неструктурированных данных.

2012-01-11T16:05:00.000+04:00

Перевод пресс-релиза "Red Hat Releases First Integrated Scale-Out Storage Product for Unstructured Data"

Red Hat Storage Software Applianceобеспечивает гибкость, производительностьи качество для корпоративных сред.

Red Hat, ведущий мировойпоставщик решений с открытым кодом,сегодня объявил о доступности Red HatStorage Software Appliance, своём первом интегрированномпродукте, обеспечивающем масштабированиесистем хранения неструктурированныхданных.

В начале октября компанияRed Hat анонсировала приобретение Gluster,ведущего поставщика открытых имасштабируемых решений для храненияданных. Этапокупка позволила расширить линейкупродуктовRed Hat программным обеспечением для управления ведущей в отрасли системойхранения неструктурированных данных.Покупка свела вместе компаниис единым видением: предлагать открытые,надёжные, масштабируемые и экономическиэффективные технологии для предприятийвсех форм и размеров. В течение двухмесяцев с момента приобретения, новаятехническая команда в Red Hat усиленно работала над созданием своего первогорелиза Red Hat Storage Software Appliance.

Red Hat Storage Software Applianceпостроена на базе GlusterFS 3.2 и Red Hat EnterpriseLinux 6.1. Это программное обеспечениепозволяет предприятиям преобразоватьфизические системы хранения данных ввиртуализированный, стандартизированныйи масштабируемый по-требованию пул,который обеспечивает гибкость,производительность и качество, необходимыедля успешной открытой среды предприятияв физических и облачных развёртываниях.

"Возможностьпредложить нашу первую инновационнуюсистему хранения данных - волнительныймомент для RedHat"- сказал РангаРангачари, главный менеджерсистем хранения данныхв Red Hat."Мы надеемся, что анонсированныйпродукт станет одним из способовзначительного снижения расходов насистемы хранения данных для компаний,использующих большое количествонеструктурированныхданных. Мы продолжимразрабатывать новое открытое ПО для систем хранения данных, наша техническаякоманда, отвечающая за этот проект, работаетнад расширением инноваций впродуктах.

Этот релиз - отличнаяновость для организаций, которымтребуются большие системы хранения идля разнообразных рабочих нагрузок,таких как цифровые данные и сети доставкиконтента, иерархическое хранение данных,совместный доступ к файлам, резервноеи архивное копирование. Так как продолжаетувеличиваться тенденция цифривизации,будут появляться новые проблемы схранением данных, в том числе рострасходов и недостаточная масштабируемость.Red Hat Storage Software Appliance использует новыйподход для предоставления надёжной,высокопроизводительной обработкинеструктурированных данных.

Для заказа, полученияболее подробной информации или пробнойверсии Red Hat Storage SoftwareAppliance,посетите www.redhat.com/storage.

Red Hat объявляет войну VMware на «облачном» фронте

2011-12-24T13:43:00.001+04:00

Перевод статьи "Red Hat declares war against VMware on cloud front"

Анонсируя присоединение к Open Virtualization Alliance ещё 65-ти компаний, Red Hat объявила войну VMware Cloud Foundry. Вышеупомянутый альянс был создан в мае таким гигантами, как Red Hat, HP, IBM и Intel с целью продвижения системы виртуализации KVM. За месяц существования альянса более полусотни компаний присоединились к этой инициативе, а Скотт Креншоу [Scott Crenshaw], отвечающий за облачное направление Red Hat, назвал её ответом проприетарной платформе VMware.

Активное продвижение открытой виртуализации компания Red Hat начала несколько лет назад, после покупки Qumranet. Сегодня KVM имеет широкую поддержку как в RHEL, так и в новых облачных продуктах Red Hat — PaaS OpenShift и IaaS CloudForms.

Сегодня виртуализация KVM встроена в ядро linux и ей отдают предпочтение многие сторонники open source, но для этого KVM'у пришлось вступить в тяжёлую схватку с Xen. Гораздо менее известный KVM должен был убедить разработчиков в своей зрелости, чтобы завоевать доверие на корпоративном рынке.

На майском Red Hat Summit, руководители компании твёрдо заявили о том, что KVM уже готов для серьёзных задач. “Шлюзы открылись и мы видим волну всеобщей поддержки KVM и Red Hat Enterprise Virtualization” — сказал Креншоу, вице-президент и генеральный директор облачного бизнеса Red Hat — “Vendor lock-in не приносит пользу никому, кроме VMware … всё больше растёт недовольство гегемонией VMware”. По словам Креншоу, Cloud Foundry от VMware подразумевает открытость, но если рассматривать вируализацию VMware в целом, в её основе лежит проприетарная технология VMware ESX. А относительно виртуализаци Microsoft, Креншоу добавил, что открытость и бесплатность Azure весьма спорны.

Полный список компаний, входящих в OVA, включает большое число open source компаний, среди которых Abiquo, AdaptiveComputing, Afore Solutions, Arista Networks, Arkeia, autonomicresources, B1 Systems, BlueCat Networks, Brocade, Carbon 14 Software, Cfengine, CheapVPS, Cloud Cruiser, CloudSigma, CloudSwitch, CodeFutures, CohesiveFT, Collax GmbH, Convirture, Corensic, Censtratus, EnterpriseDB, Everis Inc., Fujitsu Frontech, FusionIO, Gluster, Inc., Grid Dynamics, Groundwork Open Source, HexaGrid Computing, IDT us, Infinite Technologies, Information Builders, Killer Beaver, LLC, Likewise, Mindtree Ltd, MontaVista Software, Morph Labs, nanoCloud, Neocoretech, Nicira Networks, Nimbula, novastorm, One Convergence, OpenNebula/C12G Labs, Providence Software (XVT), Proxmox Server Solutions GmbH, Qindel, RisingTide Systems, ScaleOut Software, Sep Software, Shadow Soft, Smartscale, StackOps, stepping stone GmbH, Storix, UC4, Unilogik, Univention, Usharesoft, Virtual Bridges, Vyatta, Weston Software Inc, XebiaLabs и Zmanda.

За последнее время KVM стал серьёзным соперником для Xen, а теперь его главный покровитель, Red Hat, — бросает вызов VMware.

Сможет ли Red Hat одержать ещё две победы?

2011-12-02T19:29:00.001+04:00

Ниже перевод заметки "Can Red Hat Score Two More Victories?"

Известный факт, что RHEL (Red Hat Enterprise Linux) и middleware JBoss занимают доминирующее положение (если говорить про рынок открытого ПО). Но смогут ли две новые инициативы — а именно, Red Hat Enterprise Virtualization и OpenShift стать настолько же успешными? Для этого Red Hat придётся заручится широкой поддержкой, в первую очередь, среди партнёров по облачным вычислениям.

Для тех, кто не следит за новостями, напомню, что Red Hat «на финишной прямой» к тому, чтобы стать первой 1$ млрд. компанией, специализирующейся на Open Source. Red Hat Enterprise Linux заслуженно занимает лидирующие позиции на рынке Linux для традиционных серверов, а сейчас стремиться занять место и на серверах для облачных вычислений. Что же касается JBoss, он не только продолжает набирать популярность, но и становится стандартом де-факто среди опытных IT-консультантов.

Не плохо. Но Red Hat не остановилась на этих двух направлениях, теперь она занята построением бизнеса вокруг RHEV (Red Hat Enterprise Virtualization) и OpenShift. Мы считаем, что в долгосрочной перспективе вложения в RHEV принесут хорошие дивиденды, но с уверенностью говорить о том, что и OpenShift наберёт критическую массу, ещё рано.

Вся стратегия виртуализации Red Hat основывается на KVM (kernel-based virtual machine). Он встроен в ядро, поэтому RHEV — логичное продолжение для RHEL. Без сомнения, VMware не скоро утратит лидерство на рынке виртуализации, но пользователи и партнёры Red Hat уже сейчас рассматривают RHEV как наиболее вероятную платформу для виртуализации. По мнению Джима Уайтхерста (Jim Whitehurst), CEO Red Hat, в долгосрочной перспективе VMware повторит судьбу Sun Solaris. RHEV станет вытеснять VMware, так же как дешёвые x86-сервера с Linux «съели» дорогие SPARC-сервера с Solaris.

По нашим оценкам, RHEV будет постепенно расти, а к 2013 году наберёт критическую массу. Уже сейчас Red Hat может показать несколько своих партнёров, которые успешно используют RHEV. В их числе Mainline Information Systems (крупный бизнес-партнёр IBM), Shadow-Soft (cloud соnsulting компания), Unilogik Systems (сертифицированный партнёр Oracle) и Zinc Solutions (web-дизайн и web-хостинг).

Для конкуренции с VMware, Red Hat должна заручиться поддержкой сотен новых партнёров. Но использование Open Source виртуализации и внушительная инсталляционная база Linux Red Hat, кажется, сможет стать твёрдой основой для долгосрочного успеха.

В то же время, Red Hat запускает OpenShift, PaaS-платформу (Platform as a Service), которая позволит разработчикам писать приложения, работающие на любой облачной инфраструктуре. Проект OpenShift интригующий и амбициозный. Вот что говорит отраслевой эксперт Дана Блэнкенхорн[Dana Blankenhorn]:

Над OpenShift, PaaS-платформой Red Hat, работает больше людей, чем работали над каким-либо другим продуктом Red Hat, и она напрямую конкурирует с платформами от VMWare и Microsoft. Эта платформа поддерживает много операционных систем и frameworks, не только тех, которых делает Red Hat, и у такого подхода есть хорошие перспективы.

Это похоже на правду. Но действительно ли Red Hat сможет откусить часть «пирога» у более крупных софтверных компаний (Microsoft и VMware), с намного большими командами разработчиков? Хм… Ответ может быть в community-стратегии Red Hat и растущем списке компаний, обещающих поддержать OpenShift. Но работа над OpenShift остаётся ещё не завершённой — пока доступны только Express Developer Preview и Flex Developer Preview. Red Hat обещает запуск OpenShift Power к концу текущего года.

Обычно Red Hat и её партнёры добивались хороших результатов, занимая уже сложившиеся рынки. Например, Red Hat Enterprise Linux стал наследником различных Unix-систем, а middleware JBoss потеснило BEA WebLogic и IBM WebSphere. Если эта схема повторится, Red Hat Enterprise Virtualization сможет занять часть рынка VMware.

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

Еще один звоночек

2009-05-19T22:47:00.003+04:00

На правах холивара.

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

Теперь опрос закрыт, и я с огромным удовольствием даю ссылку на результаты - http://www.computerra.ru/vote_result.php?VOTE_ID=74.

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

P.S. Похоже, назад дороги нет - Fedora / Russian Fedora 11 теперь должны получиться классными.

"Дудки, я жду Fedora 11"

2009-05-19T22:36:00.006+04:00

Зашел на днях на сайт журнала Компутерра и увидел странное. В опросе про выход RC Windows 7 лидировал, со значительным отрывом, ответ "Дудки, я жду Fedora 11". Кстати, если кто-то еще не в курсе - следующий релиз Russian Fedora 11 намечен на 26 мая. Так вот, тут надо отдельно подчеркнуть, что данный сайт IT-журнала широкого профиля, а не только для линуксойдов, и если судить по опросу, больше трети посетителей computerra.ru ждут выхода Fedora 11.Конечно, к подобным опросам можно (и нужно) относится с изрядной долей скепcиса, возможно, что этот пункт в опросе редакция добавила "в шутку", ну а люди голосуют за него, потому что нет пункта "Да не нужна мне ваша Windows 7!". Но, с другой стороны, результаты не так уж фантастичны, например, в LinuxFormat 2009/2 (115) Fedora 10 получила 10 баллов из 10 по шкале Linux Format и награду "Top Stuff".

ps: Кстати, про LinuxFormat и Fedora. На диске к 112 номеру (декабрь 2008 года) неожиданно обнаружил интервью с Максом Спеваком, бывшим руководителем проекта Fedora. Очень жаль, что оно не попало в печатный журнал, а доступно только в электронной версии (pdf-ка на диске). Мне кажется, что многие подписчики LinuxFormat, как и я, не посмотрели содержимое диска, а значит и не смогли прочитать это интервью. Надеюсь, что в ближайшее время редакция журнала разрешит опубликовать этот материал .... ну на russianfedora.ru, например. ;-)

Red Hat и патенты на AMQP

2009-03-21T00:42:00.010+03:00

Некоторое время назад, я писал о Red Hat, Novell и патентах на ПО. К сожалению, вынужден вернуться к этой теме - она достаточно актуальна сегодня (судебный иск Microsoft против TomTom) и, судя по всему, это далеко не последний пост о патентовании ПО. :-(

Так вот, я все о том же. Об отношении различных компаний к софтверным патентам. Пару дней назад появились критические замечания в адрес компании Red Hat, связанные с подачей патентной заявки на технологию основанных на XML методов маршрутизации сообщений через связующее ПО (middleware, AMQP). В ответ, Red Hat незамедлительно опубликовала пресс-релиз, который я считаю, очень показательным, комментировать его не буду, приведу полностью (это не официальный перевод, а мой пересказ :-) ):

Противодействие судебным искам о нарушении софтверных патентов.

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

Мы считаем, что сегодняшняя система софтверных патентов опасна для свободного программного обеспечения и мы сделаем все возможное, чтобы изменить её. Для этого, только за последние несколько месяцев, мы поддержали новый законопроект о реформе патентования, который стал результатом участия в деле Бильски, и заключили патентное соглашение с FireStar, защищающее интересы open source community. Кроме этого, мы гордимся участием в Open Invention Network, поддержкой программы Peer-to-Patent и разработкой Patent Promise.

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

Мы публично дали обещание, что будем использовать патенты только для обороны - ознакомится с Patent Promise можно по адресу http://www.redhat.com/legal/patent_policy.html. Это обещание свидетельствует о твердой решимости использовать наш портфель патентов только для защиты свободного программного обеспечения.

Несмотря на все это, появились некоторые вопросы по поводу одной из наших недавних патентных заявок, связанной со спецификацией AMQP. Судя по всему, единственная причина появления этих вопросов - попытки распостранения FUD, потомучто для опасений по этому поводу нет никаких объективных оснований. Соглашение AMQP Agreement, которое мы помогали составлять, предусматривает, что участники рабочей группы, включая Red Hat, предоставляют безотзывную патентную лицензию на технологии, которые использует AMQP. Иными словами, даже если бы мы вынуждены были отказаться от наших принципов (а мы не будем этого делать), AMQP Agreement не дает нам возможности судебного преследования за нарушение патентов, связанных с реализацией спецификации AMQP. Кроме того, наше Patent Promise относится ко всем, полученным нами, патентам. Патентный портфель Red Hat никогда не будет использован против AMQP, а чтобы у вас не осталось сомнений, мы обещаем поддержать любые изменения в спецификации, которые позволят исключить использование наших патентов.

У Red Hat репутация компании, которая поддерживает свободное ПО, а это, в числе прочего, и работа над устранением недостатков патентной системы. Мы намерены продолжать помогать свободному ПО и пытаться реформировать патентную систему.

Запуск программы Red Hat Academy в МГТУ им. Н.Э.Баумана

2009-02-27T13:42:00.007+03:00

26 февраля в МГТУ им. Н.Э.Баумана состоялась презентация программы Red Hat Academy.

Начиная с весеннего семестра 2008-2009 учебного года студенты МГТУ им. Н.Э.Баумана могут пройти обучение по программе Red Hat Academy.

Подробности и расписание курсов будут публиковаться на сайте программы Red Hat Academy в МГТУ им. Н.Э.Баумана - http://rha.bmstu.ru/.

Red Hat Academy - программа обучения Linux, ориентированная на получение практических навыков работы. Большую часть времени курсов слушатели выполняют практические задания на реальном оборудовании. Программа Red Hat Academy основана на стандартной программе Red Hat по подготовке IT-специалистов, которая уже давно зарекомендовала себя в IT-мире. Успешное окончание академического учебного курса приравнивается к прослушанному курсу по программе Red Hat Certified Technician, после него можно сдавать экзамен на сертификацию RHCT.

Red Hat и Microsoft объявляют о совместной технической поддержке в области серверной виртуализации

2009-02-16T19:16:00.005+03:00

Сегодня, 16 февраля 2009 года было объявлено о том, что Red Hat и Microsoft договорились о сотрудничестве в области виртуализации.

Официальный пресс-релиз Red Hat доступен на сайте компании - http://www.redhat.com/promo/svvp/?intcmp=70160000000HiHHAA0 Ниже приведён текст пресс-релиза компании VDEL, предствляющей Red Hat в России и СНГ.

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

Москва, 16 февраля 2009 г. — Microsoft и Red Hat подписали соглашения, в рамках которых компании будут обеспечивать тестирование, сертификацию и совместную техническую поддержку общих заказчиков, использующих технологии серверной виртуализации. Соглашения предусматривают участие компании Red Hat в программе Microsoft Server Virtualization Validation Program и участие Microsoft в программе Red Hat Hardware Certification List для обеспечения совместимости и поддержки виртуализации. Это позволит заказчикам уверенно внедрять серверные операционные системы Microsoft Windows Server и Red Hat Enterprise Linux, виртуализированные соответственно на гипервизорах Red Hat и Microsoft, и получать поддержку от производителя соответствующей ОС.

«Сотрудничество c Red Hat позволит обеспечить новый уровень совместимости в гетерогенных ИТ-средах. Организации во всем мире все больше внимания обращают на виртуализацию как эффективное средство сокращения затрат, что особенно важно в текущей экономической ситуации. Наши российские заказчики также смогут воспользоваться преимуществами технической поддержки технологий серверной виртуализации от Microsoft и Red Hat», — отметил Павел Егорихин, руководитель группы продвижения инфраструктурных решений Microsoft в России.

Подписание соглашений позволит обеспечить техническую поддержку почти для 80% существующих во всем мире серверных операционных систем, работающих на виртуальных машинах. Согласно условиям сотрудничества каждая компания проводит тестирование и проверку своих продуктов, после чего заказчики с соответствующими соглашениями смогут получать совместную техническую поддержку для операционной системы Windows Server, запущенной в виртуальной среде Red Hat Enterprise Linux, и для Red Hat Enterprise Linux, виртуализованной с помощью Windows Server 2008 Hyper-V.

«Мы можем только приветствовать, что Red Hat и Microsoft сосредоточились на технологическом сотрудничестве и совместном решении насущных проблем заказчиков. Сегодня, когда системы виртуализации получают все большее распространение, очень важно, чтобы заказчики были уверены в совместимости систем и в том, что они гарантированно получат поддержку, в том числе, и в случае гетерогенной инфраструктуры», - сказал Милан Прохазка, генеральный директор компании VDEL, представляющей Red Hat в России и СНГ.

«Сегодня мир IT — смесь виртуализованных и невиртуализованных сред. Цель Red Hat — помочь нашим заказчикам быстрее перейти к виртуализованным средам, в том числе в случае смешанной среды Red Hat Enterprise Linux и Windows Server», - сказал Майк Эванс(Mike Evans), вице-президент по корпоративным разработкам, Red Hat. - «Red Hat прислушивается к своим заказчикам, когда они просят нас предоставлять поддержку виртуальных сред с Red Hat Enterprise Linux как в качестве платформы виртуализации, так и в качестве гостевой системы. Мы рады представить сегодняшние соглашения как результат совместной работы с Microsoft».

Взаимная техническая поддержка технологий серверной виртуализации и улучшение совместимости продуктов — именно те направления, в которых заказчики больше всего хотели бы видеть взаимодействие компаний. Вопросы о поддержке Windows Server в качестве виртуальной системы на Red Hat Enterprise Linux поступали в Red Hat с самого выпуска Red Hat Enterprise Linux 5 в марте 2007 года. Количество запросов заметно возросло после запуска в июне 2008 года программы поддержки продуктов, работающих в виртуальных машинах на базе Windows Server.

Проникновение технологии виртуализации на рынок продолжает возрастать. Виртуализация позволяет экономить за счет снижения энергопотребления, затрат на охлаждение центров обработки данных и приобретение аппаратного обеспечения, а также благодаря централизованному развертыванию приложений, автоматизации настольных компьютеров и управлению серверами. Так, независимое исследование Gartner показало, что эффективное использование виртуализации позволяет снизить энергопотребление серверов до 82%, а занимаемые ими площади — до 85%.

Получить дополнительную информацию об инициативе Red Hat и Microsoft можно на сайте Red Hat, сайтах партнеров и сайте Microsoft.

Подробная информация о технологииях виртуализации Red Hat доступна по ссылке http://www.redhat.com/rhel/virtualization/.

Red Hat, Novell и патенты на ПО.

2008-11-13T23:58:00.003+03:00

В сентябрьском номере LinuxFormat (LXF 109) меня, мягко говоря, удивила заметка некой Сьюзен Линтон. Эта дама (в разделе "Distrowatch", колонка "Сделайте одолжение") пишет о том, что патентное соглашение RedHat c Firestar и DataTern очень сильно похоже на сделку Novell и Microsoft. Подробностей урегулирования конфликта RedHat с Firestar и DataTern не так уж много, но давайте попробуем разобраться в том, что известно. Далее несколько цитат из вышеупомянутой заметки и мои комментарии к ним.

Сьюзен пишет:

"Часть соглашения, касающаяся сообщества - то место, где Red Hat берет под крыло своих ведущих разработчиков и пользователей. О защите других дистрибутивов, их разработчиков или пользователей речи нет."

Так. А что, Red Hat должна защищать другие коммерческих компаний? Которые, строго говоря, конкуренты к тому же. Непонятно что-то, на каком основании именно Red Hat должна отдуваться за всех? А о защите своих клиентов Red Hat заявила ещё два года назад, почему именно сейчас это так встревожило госпожу Линтон? Защита своих разработчиков и пользователей - это вполне нормальные и даже необходимые действия для любой компании. Кстати, вот Canonical тоже предлагает защиту своим пользователям. Интересно, почему Сьюзен Линтон не возмущается действиями Canonical?

"Очевидно, что RedHat и Fedora содержат множество ведущих проектов, но каковы шансы что они нарушают законодательство?"

Софтверные патенты? Я думаю, что ответ очевиден. Сегодня даже самый небольшой программный продукт нарушает десятки, а то и сотни чужих патентов. Да, это угроза свободному ПО . Да, с этим нужно что-то делать. И да, RedHat насколько может, пытается изменить эту ситуацию. Как? В первую очередь, участием в Open Invention Network (OIN) и помощью OSDL в создании каталога патентов для Open Source. Но это не главное. Главное это то, что Red Hat и проект ESP (End Software Patents) фонда Free Software Foundation участвуют в судебной борьбе против патентования алгоритмов . Да-да, я имею ввиду то самое дело Бильски, которое журналисты уже назвали "сокрушительным ударом по софтверным патентам".

"Что купила Red Hat и чем поступилась DataTern?"

- спрашивает Сьюзен. Давайте подумаем. С DataTern просто - компания поступилась возможностью погрязнуть в судебных разбирательствах и нажить себе огромное количество врагов в IT-сообществе. Вспомните SCO, и вы поймете о чем я говорю. ;-) А вот с Red Hat интереснее. Red Hat купила время. Время, необходимое для реформирования патентной системы (см выше "дело Бильски"). Red Hat купила спокойствие и уверенность в правильном выборе для своих клиентов. Red Hat купила пример для сообщества, что безусловно есть возможность следовать букве и духу GPL-лицензирования в ходе разрешения патентных тяжб.

"Да и не совершила ли Red Hat тот же смертный грех, в котором два года назад обвинялась Novell?"

Нет, не совершила. Сделка RH не противоречит GPL3 и вообще духу свободного ПО. Мне кажется очень важным умение найти компромисс между интересами сообщества и финансовыми интересами своих акционеров. Напомню, что именно несоответствие сделки Novell-MS принципам OpenSource вызвало бурю негодования в сообществе и даже побудило внести определённые правки в GPL3 . RedHat же "освободила" необходимые патенты на условиях, наиболее благоприятных для разработчиков свободного ПО и это, на мой взгляд, самое важное.

"Если Red Hat отвергла любые обвинения, но обошлась без суда, следует ли думать, что они виновны? ... Из-за этой кулуарной сделки о виновности задумается любой, как в случае с Novell, узаконевшей претензии Microsoft."

Ну виновность, по-моему устанавливает суд. А раз не было суда, значит нет и вины. Все логично. Novell узаконила претензии, подписав договор с MS, т.е. она фактически признались в "использовании интеллектуальной собственности MS". А Red Hat не признала нарушение патентов, по крайней мере ни о каких документах, хотябы намекающих на нарушение патентов, не известно. В этом ключевое отличие.

"Радуйся, коли охота, дорогое сообщество, но я разочарована. Выигрыш в суде был бы победой всего Открытого Кода, а не только кода Red Hat"

И проигрыш тоже, был бы не только для Red Hat. Я понимаю, что очень многие, в числе которых, видимо и Линтон, "жаждут крови" и хотят преподать урок "патентным троллям". Но во-первых, Red Hat хочет тратить деньги на разработку свободного ПО, а не на адвокатов. А во-вторых воевать на чужой территории было бы сейчас глупо. Не нужно забывать, что создатели коммерческого ПО уже не раз становились жертвами в судебных делах по нарушению патентного законодательства. Где гарантия того, что разработчикам свободного ПО удастся избежать похожего развития событий?

В последнее время есть ряд положительных сдвигов в области законов о патентовании ПО, в частности недавнее Изменение трактовки патентного законодательства США ставит вопрос о правомерности патентов на ПО. Да и в Европе к этому вопросу стали подходить намного оcмотрительнее. Так давайте же будем судиться, когда станем уверены в победе - а сейчас нужно сделать все, чтобы изменить законы. Бороться нужно с причиной, а не со следствием.

О чем вообще я тут писал? Да просто о том, что у RedHat и Novell есть отличия во взглядах на патентование ПО, а вот какой из этих взглядов принесет больше пользы - пускай решает сообщество. Но, нужно признаться, что в конечном счете и Novell и Red Hat способствуют распространению свободного ПО, а значит все мы останемся в выигрыше.

ps: О сделке Novell-Microsoft и её последствиях мы уже писали тут и тут .

Готов ли linux для HPC?

2008-10-20T23:56:00.002+04:00

Вопрос в заголовке, конечно же, риторический. Linux для HPC (High Performance Computing) готов однозначно, стопроцентно и уже давно. Если вы посмотрите на TOP500 (проект по составлению рейтинга и описаний 500 самых мощных общественно известных компьютерных систем мира) то заметите, что linux там уверенно и заслуженно занимает лидирующие позиции.

Но ... подождите ка, если нишу HPC практически безоговорочно занимает линукс .... где компании, которое это обеспечивают? Где многочисленные предложения местных поставщиков и производителей софта? Почему очередной дистрибутив linux появляется для десктопов, где доля линукса 1-2%, а не для кластеров,, на 98% которых устанавливают Linux и Unix? Я знаю, что вы ответите: "Это слишком узкая и слишком специализированная область, там не заработаешь денег!"

И у меня уже готовы возражения. Рынок HPC действительно значительно меньше, чем, к примеру, рынок десктопов. И заработать там намного труднее. Но разве кто-то обещал, что будет легко? Бизнес на свободном ПО - это бизнес на сервисе, ну так и предложите то, что будет востребовано. Да, это сложнее, чем просто штамповать коробки. И я не уверен, что на HPC можно заработать миллионы, но всетаки заработать "на хлеб с маслом" можно и, что на мой взгляд намного ценнее, сделать себе имя! Кстати, в последнее время Microsoft все чаще поглядывает в сторону высокопроизводительных вычислений - а это верный признак того, что там запахло деньгами. ;-)

Вы скажете: "Хе, да кластера делают IBM, SGI, HP! Куда нам до них?!". И будете правы. Но есть нюансы. IBM, SGI и HP делают очень большие и очень дорогие кластера, не каждая организация может позволить себе быть клиентом IBM. Вот как раз эта ниша, ниша средних предприятий, ВУЗов и научных центров, практически и не охвачена. Кроме того, в том что крупные компании заинтересованы в HPC есть и положительные стороны - у вас есть возможность "встать на плечи гигантов". Например, недавно IBM представила HPC Open Software Stack - пакет программного обеспечения с открытым исходным кодом для суперкомпьютеров под управлением ОС Linux.

Вот и HPC Solution от Red Hat - готовое решение, предназначенное именно для быстрого развёртывания HPC-систем. Напишу об этом немного подробнее. Чуть меньше месяца назад Red Hat представила то, что она называет первой полностью интегрированной платформой высокопроизводительных вычислений на основе Linux. В Red Hat уверяют, что эту платформу можно развернуть меньше чем за час. Система Red Hat HPC построена на Red Hat Enterprise Linux 5.2 и содержит, кластерную программную среду Platform Open Cluster Stack (OCS) 5 от Platform Computing. Она включает драйверы устройств, инсталлятор, инструменты управления, монитор выделяемых приложениям ресурсов, поддержку интерфейса и планировщик заданий Platform Lava. Ну и остается добавить, что по цене, Red Hat HPC конечно-же выгодней, чем предложения конкурентов.

Итак, рыночная ниша есть. Готовая программная платформа есть. Дешёвые x86 сервера - предложений более чем достаточно. Так когда же ждать Вашу HPC-систему, ну если не в TOP500, то в Российском TOP50 хотя бы? ;-)

И биржи держат рубежи...

2008-10-11T22:42:00.004+04:00

Недавно Чикагская товарная биржа (The Chicago Mercantile Exchange, CME) объявила о присоединении к Linux Foundation. В настоящее время CME Group является крупнейшей в США биржей по торговле валютными фьючерсами и опционами и одной из самых больших организаций, оказывающих финансовые услуги на базе операционной системы Linux. Так вот, что интересно ... в комментариях к этой новости обсуждали не столько CME Group и Linux Fundation, сколько Лондонскую биржу и Get The Facts от Microsoft.

Если кто-то не в курсе, вот краткое содержание предыдущих серий:
1) На сайте Get The Facts публикуют информацию, о том что Лондонская биржа (LSE) выбрала Windows.
2) Во многих бумажных журналах, связанных с IT, печатают про это красивую рекламу на всю страницу.
3) На основных новостных IT-сайтах вешают большой баннер.
4) Появляется новость о том, что на Лондонской фондовой бирже произошёл сбой в компьютерной системе.
Эта новость отлично смотрится на сайтах рядом с баннером "лондонская биржа выбирает windows". Занавес. :-)

На самом деле, радость Microsoft по поводу того, что хотя бы на Лондонской бирже выбрали Windows понять можно. За последнее время, например, Дубайская международная финансовая биржа (DIFX) и Новозеландская фондовая биржа (NZX) перешли на Linux. Но особенно хотелось бы отметить холдинг NYSE Euronext, он объединяет крупные биржевые площадки в США и Евросоюзе, включая Нью-йоркскую фондовую биржу (NYSE), европейскую Euronext, международную биржу финансовых фьючерсов и опционов Liffe и др. Там в качестве базового дистрибутива для серверов, по итогам всестороннего тестирования, включающего тестирование технической поддержки, был выбран Red Hat Enterprise Linux.

Так почему биржи используют Linux? Я думаю, что ответ все мы знаем. Финансовые службы очень требовательны к надёжности и отказоустойчивости используемых ОС, ведь каждая минута простоя в таких компаниях обходится в миллионы долларов.

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

Fedora в России

2008-10-08T23:40:00.004+04:00

Сегодня появился достойный повод для оживления блога. На СПО-Саммите (www.ross-ru.ru) объявлено о программе Russian Fedora. Итак, официальный пресс-релиз и человеческие комментарии к нему.

Пресс-релиз

VDEL и ВНИИНС им. В.В. Соломатина объявляют о начале совместно с Red Hat программы Russian Fedora, направленной на поддержку СПО-сообщества.

Цели программы Russian Fedora:

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

Red Hat в рамках проекта Russian Fedora предоставит необходимую базу, передаст свои технологии и наработки по организации разработки СПО и интеграции разработки в мировое сообщество. Также Red Hat обеспечит взаимодействие российских разработчиков со своими центрами разработки.

VDEL будет отвечать за взаимодействие с российским сообществом и за организацию проекта.

На базе ВНИИНС им. Соломатина будет создан центр разработки, которых станет технологическим ядром проекта.

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

А теперь о том же, но простыми словами

Есть:

Желание и политическая воля VDEL, ВНИИНС, Red Hat вложиться в развитие и популяризацию СПО в России
Договоренность выделить на это ресурсы
Понимание того, что такие задачи нельзя решать методами "сверху". Большие компании могут поддержать процесс и стать "точкой кристаллизации", но основная роль принадлежит сообществу.

Мы (VDEL) хотим:

Сделать популярнее идею СПО как таковую. Да, это маркетинг пополам с просветительской деятельностью. Ориентированы они в первую очередь на тех, кто в свете всех последних событий и заявлений "сверху" о свободном ПО начал смотреть и пробовать понять для себя, что же такое на самом деле СПО и Linux.
Сделать Linux проще для пользователей. Чтобы человеку, которые впервые взял в руки диск с Linux, не требовались советы ближайшего гуру при первых же шагах в новой системе. Да, такая цель декларируется далеко не впервые. Да, очень многое уже сделано. Но на сегодняшний день задача еще не решена. Значит надо по возможности вносить свой вклад в нее.
Помочь российскому сообществу влиять на апстрим, используя каналы Fedora / Red Hat. И речь здесь в первую очередь даже не о разработчиках, хотя в официальном пресс-релизе акцент сделан именно на них. Речь о сообществе в целом, о всех тех, кто использует СПО в России. Цель - постараться направить развитие апстрима с учетом их интересов. Простой пример - чтобы не приходилось раз за разом делать одни и те же кастомизации в каждом новом пришедшем из апстрима релизе.

Упреждая вопросы и комментарии - мы НЕ собираемся:

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

Конкретные шаги и действия:

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

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

Управление разделами при использовании Xen.

2008-02-18T10:26:00.004+03:00

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

Варианты использования

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

Выделение отдельного диска или массива под каждую виртуальную машину.
Выделение одной или нескольких партиций диска под виртуальную машину.
Выделение одного или нескольких логических томов (LVM) под каждую виртуальную машину.
Хранение фалов-образов виртуальных машин на файловой системе Dom0.

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

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

Отдельный диск под каждую виртуальную машину

Хотя этот способ многим покажется оптимальным, в реальной жизни не все получается гладко. Недостаток номер один - во многих существующих системах просто невозможно выделить отдельный массив (скажем Raid1) под каждую виртуальную машину. Причем невозможно просто физически, например в 2U корпус просто зачастую не влезает более 6 HDD. В этом случае количество виртуальных систем было бы ограничено тремя.
При проведении резервного копирования виртуальных систем мы можем получить доступ к LVM гостевой системы, причем этот доступ мы будем получать каждый раз при загрузке Dom0. При резервном копировании нам придется использовать эксключивную блокировку snapshot логического тома.
Расширение дискового пространства виртуальных машин, по описанным выше причинам, не позволит вам сохранить парадигму уравления хранением данных. Потребности виртуальных систем в дисковом пространстве могут сильно отличаться, в то время как объемы и количество дисков остаются неизменными.
Перемещение работающей виртуальной машины между дисками - операция достаточно рутинная, заключающаяся в подсоединении нового жесткого диска коммандой


[root@dom0 ~]# xm block-attach domu phy:/dev/sdXY xvdb w

После чего перемещением Расширением LVM и переносом physical extents на новый физический том.


[root@domu ~]# pvcreate /dev/xvdb
[root@domu ~]# vgextend vg00 /dev/xvdb
[root@domu ~]# pvmove vgo0 /dev/xvda /dev/xvdb
[root@domu ~]# vgreduce vgo0 /dev/xvda

За чем следут отсоединение старого блочного устройства из Dom0.


[root@dom0 ~]# xm block-list domu
xm Vdev  BE handle state evt-ch ring-ref BE-path
51712    0    0     4      8      8     /local/domain/0/backend/tap/5/51712
....
[root@dom0 ~]# xm block-detach domu 51712

Выделение одной или нескольких партиций диска под DomU

Этот способ по сути повторяет предыдущий. Исключение:

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

Из этого напрямую следуют недостатки этого метода:

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

Выделение нескольких LV под DomU

В этом сценарии при установке DomU создается LVM. Несколько LV из этого LVM экспортируются в DomU. DomU размечает предоставленные ему устройства и создает на них свой LVM. Для того, чтобы их различать, далее будет обозначать LVM0 - LVM в Dom0, а LVMU - LVM в DomU.
В случае увеличения объема дискового простанства, мы не можем просто увеличить объем логического тома в LVM0. В DomU не будет сгенерировано событие Hotplug, и DomU будет по прежнему использовать старую геометрию виртуального диска. Вместо этого мы выделим еще один логический том в Domo, экспортируем его в DomU и "растянем" LVMU.


[root@dom0 ~]# lvcreate -n domu-newlv -L 10G hostvg
[root@dom0 ~]# xm block-attach domu  phy:/dev/hostvg/domu-newlv xvdb w

Создадим на диске единственную партицию (можно обойтись и без этого) и "растянем" vg00, логический том и фаловую систему. Напомним, что уже довольно давно ext3 поддерживает online-resize.


[root@dom0 ~]# pvcreate /dev/xvdb1
[root@dom0 ~]# vgextend vg00 /dev/xvdb1
[root@dom0 ~]# lvextend -l+100%FREE /dev/vg00/lv
[root@dom0 ~]# resize2fs /dev/vg00/lv

Для резервного копирования виртуальных машин можно сделать snapshot логических томов LVM0, на которых распогалаются данные domu. После чего можно получить средствами device-mapper доступ к вложенным партициям, собрать из них в Dom0 копию LVM гостевой машины и получить доступ к "снимку" данных виртуальной системы без боязни его повредить.
Делается следующим образом.


[root@dom0 ~]# lvcreate -s -n domulv-snapshot -L 5G /dev/hostlv/domulv
[root@dom0 ~]# kpartx /dev/hostlv/domulv-snapshot
[root@dom0 ~]# pvs; vgs; vgchange -ay

При этом мы получаем моментальный снимок даных, формируем из него копию LVMU, делаем с ней что хотим, после чего уничтожаем snapshot.
Осуществление перемещения между дисками осуществляется аналогично расширению пространства, за исключением того, что мы отключаем старый LV от DomU. При этом мы можем уничтожить LV в LVM0, не чтрадая при этом от фрагментирования.
Количество логических томов, которые мы можем выделить виртуальным машинам ограничено только здравым смыслом. =)

Файлы-образы

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

Резюме

В любом случае найдется достаточно людей с разнями воззрениями, чтобы реализовать все описанные методы. Тем не менее, о результатам лично я буду польоваться способом №3, когда содается "двухслойный" LVM.

Производительность открытых LDAP серверов

2008-02-05T23:39:00.000+03:00

В январе этого года состоялся релиз Fedora Directory Server 1.1. Буквально на следующий день был выпущен аналогичный поддерживаемый продукт Red Hat Directory Server 8.0. Это, а также реакция на наши завления о том, что Red Hat Directory Server производительнее OpenLDAP сподвигли нас на проведение теста.

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

Мы сосредоточились на задачах, которые занимают 90+% всех операций, выполняемых с LDAP-серверами, а именно - операциях одиночного чтения. Под одиночным чтением подразумевается соединение клиента и сервера, аутентификация клиента на сервере, считывание одной записи о отсоединение.
Для этого были сгенерировано плоское дерево, моделирующее простую структуру с большим количеством "пользователей" Иначе говоря, мы сделали N записей вида

dn: uid=user00000,ou=People,dc=example,dc=com
objectClass: account
objectClass: posixAccount
uid: user00000
cn:User User
loginShell: /bin/bash
uidNumber: 100000
gidNumber: 100000
homeDirectory: /home/user00000
gecos: User Userovich 00000

После этого мы измеряли на одной и той же системе, в которой запущен только LDAP-сервер время выполнения 1000 последовательных единичных чтений. При этом мы использовали чтения по RDN (аналог primary key в DBMS), по атрибуту, по которому построен индекс, а также по атрибуту, по которому индекс не построен. При этом оба сервера были настроены использовать одинаковую структуру индексов и одинаковый backend (LDBM).

Для произведения 1000 случайных чтений мы предварительно генерировали последовательность псевдослучайных чисел в необходимом диапазоне, после чего утилитой time измеряли время произведения 1000 вызовов ldapsearch по заданному файлу с последовательностью.

Поскольку мы меняли сервера на одной системе, а также для увеличения репрезантативности тестов, тесты прогонялись 20 раз подряд на разных последовательностях, после чего усреднялись результаты последних 10. Первые 10 прогонов симулировали "разогрев" сервера после перезапуска.

Результаты тестов приведены ниже.

Результаты тестов

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

1000 чтений по RDN/индексу
## записей	FDS	OpenLDAP
1000	4,39	4,8
5000	4,46	4,85
10000	4,54	4,89
50000	4,65	4,91

Теперб результаты 1000 чтений по атрибуту, индекс по которому не построен. В нашем случае мы использовали атрибут homeDirectory. Предвидя скептические возгласы, скажу, что подобные вещи (поиск по атрибуту без индекса) не должны встречаться в хорошо спланированном LDAP-дереве. Тем не менее результаты вполне имеют право на жизнь, а также наглядно иллюстрируют пользу индексов.

1000 чтений без индекса
## записей	FDS	OpenLDAP
1000	11,82	25,25
5000	92,99	124,63
10000	232	303
50000	340	1047

Ну и наконец, тест времени заполнения базы. Это есть непосредственно время выполнения ldapadd для файла, содержавшего нашу базу переменного размера. Если помните, LDAP не гарантирует транзакционности, а также неэффективен при операциях на запись. Некоторые люди поэтому предпочитают иметь DBMS (например PostgreSQL) для хранения данных, а LDAP используют для создания копии, которая работает только на чтение.

Добавление записей
## записей	FDS	OpenLDAP
1000	2,09	20,96
5000	10,9	216,08
10000	23,56	440
50000	183	1181

Ну и наконец мы провели еще один тест. Дождавшись таки пока OpenLDAP импортирует базу в 100 000 записей, мы провели тест на 1000 произвольных чтений по индексу при 200 параллеьно работающих потоках. Для этого мы запустили 200 потоков предыдущих тестов, измеряя прохождение одного из них. Результаты получились следующие:
Red Hat Directory Server - 772 секунды
OpenLDAP - 996 секунд

Выводы

Выводы из этих тестов достаточно очевидны. На небольших базах (до 50 000 записей) и при небольшом количестве параллельных запросов FDS/RHDS и OpenLDAP ведут себя очень схоже. Разница в производительности не дает о себе знать, если грамотно использовать индексы. Однако, OpenLDAP начинает серьезно отставать от конкурента по времени добавления записей, при неструктурированном поиске, а также при увеличении параллелизма. Именно поэтому мы остановились на 50 000 записей - OpenLDAP о-о-очень долго их импортировал.

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

Возможность поддержания нескольких партиций LDAP-каталога на одном сервере
Мультимастеринг (говорят, в devel ветке openldap он тоже есть, тем не менее мы используем стабильную версию)
Более гибкие возможности репликации
Репликацию с AD

Вышел Red Hat Directory Server 8.0

2008-01-14T19:07:00.000+03:00

Вскоре после приобретения Netscape Directory Server в 2005 году Red Hat открыл весь его исходный код, который было возможно открыть, не нарушив лицензий, и выпустил его под маркой Red Hat Directory Server. Одновременно с этим под эгидой Red Hat стартовал проект Fedora Directory Server, направленный на то, чтобы переписать все компоненты, который нельзя было открыть, и таким образом создать полностью открытый Directory Server корпоративного уровня. Также Fedora Directory Server стал основой проекта freeIPA (www.freeipa.org), цель которого — создать решение для централизованного управления информацией о пользователях, политиками и аудитом.

На настоящий момент проект Fedora Directory Server достиг своей первоначальной цели — весь код, который было невозможно открыть, заменен. Вышедший сегодня Red Hat Directory Server 8.0 собран полностью из открытых исходных текстов. В RHDS 8.0 вошли все улучшения, разработанные в рамках проекта Fedora Directory Server.

Многие организации на сегодняшний день используют Red Hat Directory Server как ключевой компонент инфраструктуры для управления аутентификацией и авторизацией. Примеры внедрений можно найти на http://customers.press.redhat.com/category/solutions/red-hat-directory-server/. Одним из них является университет Базеля, которому было необходимо создать надежное решение для более чем 15000 студентов и сотрудников университета.

Red Hat Directory Server 8.0 предоставляет ряд новых возможностей, в том числе:

Поддержка платформ: Red Hat Enterprise Linux 4 и 5 (32-bit и 64-bit), HP-UX 11i (Itanium, 64-bit) и Solaris 9 SPARC 64 bit.
Безопасность: улучшенные политики паролей, наличие профиля SELinux по умолчанию, поддержка SHA-256, SHA-384, SHA-512 и MD5 для хеширования паролей, улучшение поддержки SASL/Kerberos.
Поддержка протоколов: возможность подключений IPv6-клиентов и поддержка IPv6 в SDK. На данный момент не поддерживается IPv6 в ACL и IPv6-соединения для таких операций как репликация и делегирование.

Работа над проектом продолжается, так что оставайтесь на связи!

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

2007-12-29T14:19:00.000+03:00

Неофициальный перевод. Не является дословным переводом оригинала. Оригинал доступен по адресу:
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

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

2007-12-29T14:17:00.000+03:00

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-12-11T12:21:00.001+03:00

Ни для кого не секрет, что рынок ноутбуков сейчас растет гораздо быстрее рынка десктопов. Прогноз, что в 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 год

2007-12-11T11:44:00.000+03:00

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

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

Appliance Operating System

2007-12-11T11:43:00.000+03:00

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

В качестве ответа на это 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. Все новое – это хорошо забытое старое.

2007-12-11T11:41:00.002+03:00

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

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.

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

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

2007-12-11T11:41:00.001+03:00

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

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

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

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

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

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

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

2007-12-04T12:52:00.000+03:00

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

С тех пор, как компьютерные сети получили широкое распространение, использовать файлы, такие как /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.

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

2007-11-11T13:39:00.000+03:00

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

12 октября 2007

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

25 октября 2007

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

25 октября 2007

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

28 октября 2007

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

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

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

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

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

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

2007-11-10T11:35:00.000+03:00

Зачем нужна 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, то они всегда готовы обсудить честные предложения.

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

2007-11-07T01:02:00.000+03:00

Введение

Идея сетевых файловых систем далеко не нова. Далеко не нова - это значит, что первые реализации файловых систем, внешних по отношению к физическим ЭВМ, появилась в начале 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 слаба и незащищена.

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

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

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

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

NFSv3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме.

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

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

2007-10-08T10:54:00.000+04:00

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

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

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

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

В течении уже многих лет инженеры 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 проиграла иск в Евросоюзе

2007-10-08T10:50:00.000+04:00

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

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. Управление Логическими Томами

2007-10-02T11:22:00.000+04:00

Введение

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

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

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

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

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

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

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

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

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

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

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

Логический том (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'а логического тома все логические "клеточки" созданного тома-снапшота ссылаются на те же самые физические "клеточки" блочных устройств, что и «клеточки» исходного тома. Это означает, что одни и те же данные доступны по двум логическим именам. Это же, кстати, делает процесс создания снапшота любого размера практически мгновенным. При изменении одной из "копий" данных логические ячейки разносятся. Это позволяет двум логическим томам использовать совместно неизменяемую часть данных, поддерживая независимо только различающуюся часть.

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

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

Заключение

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

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

2007-08-29T15:17:00.000+04:00

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

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

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

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

ОГРАНИЧЕНИЯ. Никогда и никаким образом невозможно включить в дистрибутив все открытое ПО, существующее на свете. Поэтому при создании дистрибутива необходимо ориентироваться на определенную аудиторию и на определенные задачи. Отталкиваясь от этого, можно определить, что должно войти в дистрибутив, а что останется за его рамками.
ПОЛИТИКА. Исходя из целевой аудитории необходимо определить политику развития и выбрать те версии программ, которые отвечают вашим потребностям. Включать ли в дистрибутив «новейшие» программы или «проверенные временем» - это полностью зависит от вашей аудитории. Например, Red Hat Enterprise Linux ориентирован на корпоративный сектор, поэтому его политика - «новейшие из стабильных»; Ubuntu ориентирован на домашние компьютеры и его политика - «новейшие» пакеты и т.д..
СИСТЕМА СБОРКИ. Основой для превращения разрозненных программ в дистрибутив служит система управления пакетами. После того, как политика определила, что включать в дистрибутив, система сборки определит, как это сделать. Стандартом LSB (Linux Standard Base) является система RPM. Тем не менее, DPKG или еще какие-либо системы также могут быть вариантами.
ПРАВИЛА. Необходимо сформулировать правила и четко следовать им. “Чистый” open source очень гибок. Это означает, что все правила, которым будет подчиняться ПО с составе дистрибутива, необходимо определить самостоятельно. В частности, это относится к тому, куда устанавливать ПО и библиотеки, где и в каком виде хранятся файлы настроек и т.д.

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

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

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

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

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

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

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

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

НЕУПРАВЛЯЕМЫЕ ПАКЕТЫ. Вы можете включить в дистрибутив ПО, на развитие которого никак не влияете. Давайте возьмем для примера типичный дистрибутив, состоящий из примерно 3000 пакетов. Сколько разработчиков работают над ними? Тысячи, а скорее даже десятки тысяч. А теперь задайтесь вопросом – сколько из них будут работать для вас? Если ответ меньше чем хотя бы «сотни» - вы явно не лидер. Вы не определяете развитие «своего» продукта. Вы, конечно, можете изобрести велосипед еще раз, создать неплохой «Еще один дистрибутив», но кому это надо? Кто будет заинтересован в продукте, который не может определить свою собственную стратегию развития?
ПОДДЕРЖКА 3-ГО УРОВНЯ. Для обеспечения адекватной поддержки вам необходимо наладить постоянный контакт с сообществом разработчиков. А сделать это можно только активно участвуя в разработке и тем самым зарабатывая себе авторитет. Без этого ваша поддержка будет крайне ограниченной. Разумеется, можно нанять десяток человек и организовать call-центр. Но такая служба поддержки не сможет решить хоть сколько-нибудь сложную проблему, требующую вмешательства в код. В этом случае ваш дистрибутив никто никогда не установит на важные системы, потому что ему нельзя доверять.
ЧЕЛОВЕЧЕСКИЕ РЕСУРСЫ. Для того, чтобы создать ведущий дистрибутив, недостаточно как-нибудь участвовать в разработке. Невозможно нанять 500 любых разработчиков и стать лидером, потому что эти люди до данного момента не участвовали в каких-либо проектах. Для того, чтобы определять развитие продуктов, необходимо иметь с своем штате «ключевых» разработчиков. Но большинство этих людей уже работают в крупных корпорациях, таких как Google и Red Hat. Таким образом, после того как вы наймете несколько сотен разработчиков, вам придется очень постараться, чтобы они вошли в команды разработки ключевых проектов хотя бы в ближайшие 3 года. Мы сейчас не говорим о том, чтобы возглавить эти проекты, неплохо будет, если они хотя бы войдут в число основных разработчиков. Особая история – разработчики ядра. Они необходимы в команде, если мы говорим о серьезном дистрибутиве, и их сложнее всего найти. И не забывайте – вам придется платить им все эти годы.
СЕРТИФИКАЦИИ. До тех пор, пока вы не подниметесь на определенный уровень, вы не станете частью «экосистемы». Дело в том, что операционная система сама по себе – одна из наименее привлекательных вещей в мире. Без ПО под нее она не стоит вообще ничего. А так как вы не являетесь ведущей компанией, то назовите хотя бы одну причину, по которой независимым разработчикам, таким как 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 на работу, которая УЖЕ сделана, не имея при этом НИКАКИХ гарантий, что в итоге получится хоть что-то новое и значимое?

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

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

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

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

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

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

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

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

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

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

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

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

Достигнуть договоренности о сотрудничестве с одной из ведущих компаний, имеющей налаженные схемы взаимодействия со всеми участниками рынками. Цель – получить доступ к “закрытой” части их работы и к каналам взаимодействия.
Создать команду для включения поддержки дополнительных языков в «базовый» дистрибутив. Дело в том, что мировые дистрибутивы поддерживают только основные языки (русский, английский и т.д.) и не поддерживают локальные языки, которые могут быть нужны для использования дистрибутива в отдельных республиках. Оценочный размер команды – 5-10 человек.
Создать команду для внедрений и последующей поддержки. Инженеры этой команды решают типовые вопросы, а в сложных ситуациях, требующих взаимодействия с разработчиками или третьими компаниями, используют налаженные каналы сотрудничающей компании. Оценочный размер команды – 20-40 человек.
По мере того, как растет количество внедрений, инженеры перенимают опыт и налаживаются собственные каналы взаимодействия, можно брать на себя все больше функций, расширять команду, начинать участвовать в разработке.
При достижении «критической массы» знаний и опыта можно создавать свой дистрибутив, продолжая сотрудничество. В этом случае дистрибутив имеет множество «точек опоры» (собственная команда разработки и поддержки, сотрудничество с командой «дружественного» дистрибутива, взаимодействие с независимыми разработчиками), и за счет этого никакие локальные проблемы не ведут к провалу проекта в целом. В конечном итоге такой подход порождает УСТОЙЧИВЫЙ дистрибутив.

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

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

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

Вывод

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

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

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

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

2007-08-16T11:11:00.001+04:00

В 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

Управление ПО. Создание собственных репозитариев

2007-08-10T12:12:00.000+04:00

Ранее мы уже рассказывали о необходимости упаковывать собственное ПО и ПО третьих поставщиков в RPM. Помимо непосредственно сборки пакетов, в крупной инфраструктуре необходимо обеспечить верификацию подлинности RPM-пакета и безопасное распространение пакетов. Все примеры абсолютно работоспособны и проверены в RHEL5. Если вы пытаетесь использовать эти примеры в отличающейся системе – позаботьтесь об адаптации. =)

GPG-подпись пакетов

GPG-подпись – стандартный механизм подписи пакетов RPM. Для его использования необходимо сделать следующее:

Сгенерировать пару GPG-ключей.
Добавить данные желательной подписи в конфиг RPM
Подписать пакет.
Экспортировать публичный ключ и выложить его в общедоступное место.

Пойдем по порядку.

Генерация пары GPG-ключей

Сначала сгенерируем ключ, для чего выполним команду gpg –gen-key. После ответов на ряд простых вопросов наш ключ будет сгенерирован. Ответы могут быть довольно произвольными, единственное – запомните имя, адрес электронной почты и пассфразу. Я например скромно назвался Albert Einstein <a.einstein@example.com> и записал пассфразу на бумажке. =)

После окончания генерации вы увидите в конце вывода утилиты GPG строки наподобие

gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u

pub 1024D/AE49A408 2007-08-10

Key fingerprint = 4734 6DB2 6078 EAFE 4B3F 8346 8FD7 F01C AE49 A408

uid Albert Einstein

Note that this key cannot be used for encryption. You may want to use

the command "--edit-key" to generate a subkey for this purpose.

Важно запомнить части, выделенные жирным шрифтом. В нашем случае AE49A408– идентификатор моего ключа, а более длинный фрагмент, выделенный полужирным курсивом – это «отпечаток» (fingerprint) моего ключа.

Если вы не послушали меня и не запомнили выделенные жирным данные – вы всегда можете их «подсмотреть», выполнив команду

gpg --fingerprint

Конфигурирование RPM для использования ключа

Конфигурирование RPM в данном (как в прочем и в любом другом) случае сводится к добавлению двух строк в файл ~/.rpmmacros

%_signature gpg

%_gpg_name Albert Einstein <a.einstein@example.com>

Единственным «критичным» моментом является совпадение имени и e-mail адреса в выводе команды gpg –fingerprint с адресом, указанным в файле .rpmmacros.

Подпись пакетов

Задача важная, требующая интерактива и внимания. Хотя бы потому, что вам придется вспомнить пассфразу, введенную ранее. =)
Для подписи RPM-пакетов у утилиты rpm есть два параметра.

--addsign – начальная подпись. Используется в случае, если пакет не подписывался ранее.
--resign – как очевидно из названия «переподписать». (не верьте переводу Lingvo, сдаваться мы не собираемся).

Формат вызова и использование параметров довольно очевидно:

rpm –addsign hello-1.0-1.i386.rpm

и после введения пассфразы мы получаем «помеченный» пакет. Если пакет уже был кем-то «помечен» до вас, то

rpm –resign kernel-2.6.18-8.1.8.el5.i686.rpm

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

Экспорт ключа

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

gpg --export --armor AE49A408 > /tmp/gpg-key

После этого «объявление» должно быть донесено до каждой системы. Для локальной системы можно тут же, не отходя от кассы, выполнить команду

rpm –import /tmp/gpg-key

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

cp /tmp/gpg-key /var/www/html/

После этого на прочих системах достаточно выполнить команду

rpm –import http://192.168.0.1/gpg-key

где 192.168.0.1 – IP-адрес вашей системы. После этого вы можете проверить подлинность пакета вызвав rpm с ключом -Kv

rpm -Kv hello-1.0-1.i386.rpm

Создание репозитория

Для создания репозитария вам потребуется:

Набор пакетов для репозитария. Если пакеты, которые вы хотите включить в свой репозитарий зависят от пакетов, не входящих в стандартный репозитарий дистрибутива – хорошей практикой будет включение подобных зависимостей в ваш репозитарий. Разумеется, удаленный доступ к пакетам с клиентских систем должен быть обеспечен. Наиболее простой способ – обеспечение доступа по HTTP или анонимному FTP. Мы надеемся, что с этим читатель справится. В нашем примере мы просто создали директорию /var/www/html/repository/5/i386/ и переместили наши RPM-пакеты туда.
GPG-ключ. Мы уже обеспечили свободный доступ к нему; уровень «свободности» доступа может ограничиваться вашей организацией, а может быть глобальным – это совершенно безопасно.
Метаданные для пакетов. Это данные, которые необходимы утилите yum для разрешения зависимостей. Процесс создания прост. Нам потребуется установить пакет createrepo. Найти ее можно в стандартной поставке RHEL5. Простейший вариант использования:

cd [директория-с-пакетами]; createrepo .
Файл описания репозитория, Этот файл необходимо «донести» до широких масс систем, которые будут пользоваться вашим репозитарием. Способ оставляем на ваше усмотрение. Содержание файла может быть примерно следующим

[user@fortice ~]$ cat /etc/yum.repos.d/packages.repo

[epel]

name=Extra Packages for Enterprise Linux 5 - $basearch

baseurl=http://192.168.0.1/repository/5/$basearch

enabled=1

gpgcheck=1

gpgkey=http://192.168.0.1/gpg-key

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

Заключение.

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

Существуют решения для управления ПО, позволяющие использовать также метод PUSH и иметь централизованный источник информации и пульт управления ПО в вашей инфраструктуре. Имя ему Red Hat Satellite Server и его возможности этим не ограничиваются.

Управление пакетами. Создание собственных RPM.

2007-08-09T11:46:00.000+04:00

Несколько лет назад, когда Linux использовали на инфраструктурных серверах и компьютерах энтузиастов, было «модно» собирать ПО из исходных текстов. Плох тот линуксоид, который не может пройти книжку LFS и собрать свой дистрибутив.

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

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

RPM – что это такое?

Что такое пакет? Прежде всего пакет – это единица управление ПО. Пакет состоит из:

Файлов, исполняемых и конфигурационных
Предустановочных действий.
Постустановочных действий
Действий, необходимых для удаления ПО.
Различной служебной информации (списки и контрольные суммы файлов и т.д.)

Соответственно, пакет – это несколько больше, чем просто архив файлов. RPM-пакеты – основной способ управления ПО во многих дистрибутивах Linux. Разумно использовать его и для управления собственным ПО / ПО третьих лиц, которое не распространяется в виде RPM по умолчанию. Именно этим мы и займемся. Примеры из данной статьи разобраны и протестированы на RHEL5, хотя по аналогии будут работать и во многих других дистрибутивах.

Подготовка окружения для сборки RPM

В любой системе существует стандартная инфраструктура для сборки RPM. По умолчанию она расположена в /usr/src/redhat/. Если подобного каталога нет, установите пакет rpm-build. Его наличие позволяет собирать пакеты, имея административные привилегии, что не всегда безопасно. Мы будем использовать сборку под непривилегированным пользователем, которого назовем brewbuilder.

Для демонстрации нам потребуется пакет hello-1.0.tar.gz, который можно взять с сервера ftp://62.205.185.52/765591143807cc23efcfb4f1b436ebbc/hello-1.0.tar.gz

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

$ mkdir -p ~/workspace/redhat/{RPMS,SRPMS,SPECS,SOURCES,BUILD}
$ echo '%_topdir /home/brewbuilder/workspace/redhat' > ~/.rpmmacros

Теперь мы готовы к сборке. Для сборки нам необходим единственный файл hello-1.0.tar.gz, который надо разместить в ~/workspace/redhat/SOURCES.

Часть основная – содержательная. SPEC-файл.

SPEC-файл – центральная часть процесса сборки. Написание корректного SPEC-файла и является целью нашей сегодняшней работы. Итак приступим.

Есть простой способ обеспечить себе шаблон для сборки – запустите emacs. =) Сложный – сделайте себе шаблон в вашем любимом редакторе (читай VIM) или запомните необходимые стадии. Мы приведем сразу весь SPEC-файл, позже разобрав его построчно. (Нумерация строк приведена только для удобства, в реальном SPEC-файле нумерация не нужна.)

Name: hello
Version: 1.0
Release: 1
Summary: A sample package, saying hello, world
Group: Applications/Productivity
License: GPL
Source0: hello-1.0.tar.gz
BuildArch: i386
BuildRoot: %{_tmppath}/hello-root
%description
This package basically does nothing, but it potentially could
do something useful.
%prep
%setup -q -n %{name}-%{version}
%build
make
%install
mkdir -p $RPM_BUILD_ROOT/usr/local/{bin,lib,share}
mkdir -p $RPM_BUILD_ROOT/usr/local/share/man/man1
install libhello.so.1.0 $RPM_BUILD_ROOT/usr/local/lib
install hello $RPM_BUILD_ROOT/usr/local/bin
gzip -9c hello.1 > hello.1.gz &&
install hello.1.gz $RPM_BUILD_ROOT/usr/local/share/man/man1
%files
%defattr(-,root,root)
/usr/local/lib/libhello.so.1.0
/usr/local/bin/hello
/usr/local/share/man/man1/hello.1.gz
%clean
make clean
rm -rf $RPM_BUILD_ROOT
%post
echo "/usr/local/lib" >> /etc/ld.so.conf
ldconfig
%changelog
* Tue Jul 17 2007 Andrey Meganov
- Initial build

Итак, начнем. В строчках [1-6] находится стандартное описание пакета. Эти поля необходимы, но назначение их чисто описательное за исключением поля Source0, в котором указано имя архива с исходными текстами. Помимо поля Source0, могут быть и Source1, Patch0 и далее по аналогии.

Строчки [11-13] (секция %description) задают описание пакета. Это стандартное многострочное описание, выводимое командой rpm -qi.

Строки [16-17] (секция %prep) отвечаю за подготовку пакета к сборке. Единственная строчка в нашем случае – макрос %setup отвечает за «тихую» (флаг -q) распаковку исходников Source0 в каталог %{name}-%{version}. В этой секции полагается размещать подготовку исходников с сборке, применение патчей и т.п.

Строки [19-20] (секция %build) отвечают за сборку исходников. В нашем случае это делается просто командой make. В общем случае это почти всегда комманды ./configure –prefix=$RPM_BUILD_ROOT/usr; make.

Секция %install [22-28] отвечает за установку файлов в окружении сборки. В нашем случае стандартной цели make install нет, поэтому мы устанавливаем все вручную. В общем случае make install в этой секции почти всегда решит ваши проблемы. Заметьте, что все пути начинаются с $RPM_BUILD_ROOT. Это достаточно важно и это главная причина не собирать пакеты под пользователем root. В случае если вы – root и вы забудете $RPM_BUILD_ROOT в начале пути, то вместо установки в «песочнице» ваш файл будет установлен на вашей рабочей системе, чего вы вряд ли хотите. =)

Секция %files [30-34] – одна из наиболее важных частей нашего SPEC-файла. Она описывает файлы, входящие в RPM-пакет. В этой секции желательно определить макросом %defattr(-,root,root) атрибуты по умолчанию (владелец – root, группа root, доп. атрибутов нет.), иначе при установке RPM-пакета пользователь увидит жалобы на то, что пользователь brewbuilder не существует. При создании списка файлов можно использовать шаблоны с символами '*' и '?', но делать это следует осмотрительно, так как указание списка файлов как /* приведет к включению лишних файлов в пакет. Специально можно пометить конфигурационные файлы (%config), что приведет к специальному обращению с ними, например при обновлении пакета, документацию (%doc) и пустые директории, принадлежащие пакету (%dir). Подробнее об использовании этих и других опций вы сможете прочитать в отдельных статьях.

Секция %clean [36-38] описывает очистку временного окружения сборки и обычно ничего кроме двух указанных команд не содержит.

Секция %post [40-42] описывает постинсталляционный скрипт. В нашем случае мы добавляем /usr/local/lib к пути, по которым доступны разделяемые библиотеки и успокаиваемся на этом. При написании данной секции мы сделали очевидную ошибку. Ошибка заключается в том, что мы не выдержали транзакционность. При удалении пакета мы не можем просто убрать строчку /usr/local/lib из файла /etc/ld.so.conf, потому что мы не можем рассчитывать, что никто другой не проверял наличие там этой строчки. С другой стороны, если мы – последний пакет, которому эта строчка нужна – неплохо было бы все таки иметь возможность удалить ее – для чистоты процесса. Для этого придумали директории, вроде /etc/ld.so.conf.d/. Чтобы добавить путь к библиотекам корректно, нам просто необходимо создать свой файл со строчкой /usr/local/lib в этой директории, а при удалении пакета (например, в неописанной в данной статье секции %preun) удалить этот файл.

И последняя секция %changelog содержит историю пакета. История пишется записями с фиксированным форматом даты, имени и адреса электронной почты. Формат дальнейших заметок произволен. Рекомендуется серьезно отнестись к changelog'ам, дабы избежать проблем в будущем.

Сборка пакета

Сборка пакета осуществляется одной командой

rpmbuild -ba [путь к SPEC-файлу]

После чего вы можете исследовать директории %_topdir/RPMS и %_topdir/SRPMS, найти там собранные пакеты и исследовать их командами rpm -q ...., установить и удалить соответственно.

Заключение

Вот мы и собрали наш первый RPM-пакет. Если вы хотите узнать более тонкие моменты сборки RPM, то рекомендуем прочесть книгу RPM Guide, доступную по адресу http://docs.fedoraproject.org/drafts/rpm-guide-en/. В дальнейшем мы обязательно расскажем о подписи RPM-пакетов и создании собственных репозитариев для yum.

Стратегии относительно Open Source

2007-07-15T16:43:00.000+04:00

Если внимательно присмотреться, то оказывается, что компании по их отношению к open source можно разделить на 7 основных категорий:

Приверженцы
Со смешанной базой кода
Прагматики
Со стратегией «анти»
«Обезглавленные цыплята»
Отрицающие
Противники

Первая категория - «приверженцы» - это компании, которые считают open source своей основной стратегией. Они делают свои продукты открытыми, строят свои решения на open source.

Подход таких компаний – open source дает принципиальные преимущества (разумеется, для разных компаний разные), поэтому они принципиально ориентируются на него. Примеры успешных компаний с такой стратегией – Red Hat, JBoss, MySQL. В последнее время появляется довольно большое количество новых компаний с подобной стратегией. Причина, по которой они становятся приверженцами open source, очень проста – такая стратегия позволяет им очень быстро стартовать и занимать новые ниши.

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

Наиболее ярким примером такой компании является Novell. С одной стороны, компания создает дистрибутив SuSe и участвует во многих других open source проектах. Но, с другой стороны, основную прибыль компания получает от продажи своих проприетарных продуктов, из-за чего нельзя гарантировать постоянство ее интереса к Linux.

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

Третья категория - «прагматики» - делают много заявлений о своей приверженности open source, хотя при этом вносят крайне малый вклад в открытые проекты (если вносят хотя бы какой-то).

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

Четвертая категория – компании со стратегией «анти». Эти компании крайне похожи на компании «со смешанной базой кода» - и те, и другие участвуют в открытых проектах и поддерживают open source. Но между ними есть одна принципиальная разница. Компании «со смешанной базой кода» рассматривают open source как средство развития компании (ускорение разработки, более простой выход на рынок и т.д.), в то время как компании «со стратегией анти» рассматривают open source в первую очередь как средство борьбы со своими конкурентами. То есть open source для них средство борьбы за рынок, но не более того, внутренней ценности для таких компаний open source не представляет. Изначально именно к этой категории можно было отнести IBM (использование Linux против Windows), хотя сейчас это уже не столь очевидно.

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

Как правило, это бывшие компании-«отрицающие» (см. ниже), которые внезапно обнаружили, что конкуренты, опирающиеся на open source, крайне быстро и эффективно вытесняют их с рынка. В такой ситуации компании начинают метаться между различными стратегиями в отношении open source, не имея при этом четкого понимания целей. Типичные действия таких компаний – открытие кода никого не интересующих продуктов, создание «open source версий» для образовательных учреждений, присоединение к случайным open source проектам из исключительно маркетинговых соображений. Основная цель при этом – заполнить чем-то «стратегический вакуум» и вернуть себе место на рынке. В отличие от куриц, компании при должном управлении вполне могут оправиться.

Шестая категория - «отрицающие» - компании, предпочитающие не замечать open source, и упоминать его как можно меньше. Как правило, если в разговоре с представителями такой компании возникает тема open source, они предпочитают отделывать общими фразами. Эту стратегию, как и стратегию «со смешанной базой кода», скорее всего, стоит рассматривать лишь как временную. Если компания слишком долго не предпринимает никаких шагов по смене стратегии, то рано или поздно она попадает в предыдущую категорию.

Седьмая и последняя категория - «противники». На самом деле, не так много компаний принадлежат к этой категории, ведь, учитывая растущую популярность open source, такой подход может выйти боком. Наиболее заметной компанией с такой стратегией является Microsoft. Честно говоря, их приверженностью непопулярной стратегии можно даже восхищаться. Но и они понимают, что слишком явно высказывать такую позицию не стоит, и пытаются смягчить ее. Например, указывая на примеры кода из MSDN (библиотека для разработчиков) как на «open source».

В целом, стабильны в долговременной перспективе лишь стратегии 1, 3 и 7. Также при некоторых условиях могут быть стабильны стратегии 2 и 4. Стратегии 5 и 6 не жизненны, так как open source стало слишком заметным явлением, чтобы его просто игнорировать.

А к какой категории принадлежит Ваша компания? ;-)

Автоматизация развертывания RHEL. Неинтерактивная инсталляция.

2007-07-01T11:39:00.000+04:00

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

Такая технология давно существует в стенах Red Hat и имя ей KickStart. Сегодня мы рассмотрим эту технологию и ее применений на примере сетевой инсталляции RHEL5. Операционная система сервера в примере – RHEL4, но может быть произвольной.

Итак, создаем kickstart-файл.

Что такое kickstart-файл? Kickstart-файл – это сценарий установки. «У меня все ходы записаны». То есть сценарий установки подразумевает заранее записанные в определенном формате ответы на вопросы инсталлятора. Добавьте возможность выполнять собственные скрипты до и после установки и вы получите более-менее полное представление о возможностях kickstart. Приведем простой пример ks-файла

install
url --url ftp://192.168.0.2/redhat/disk1
key [installation number]
lang en_US.UTF-8
keyboard us
xconfig --startxonboot --defaultdesktop kde --resolution 1400x1050 --depth 32
network --device eth0 --bootproto dhcp --onboot=on
rootpw --iscrypted $1$vFt/3HTE$N16kauXMVOmNHurppHAo0/
firewall --disabled
authconfig --useshadow --enablemd5
selinux --disabled
timezone --utc Europe/Moscow
bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
#
clearpart --all --initlabel
part /boot --fstype ext3 --size=100 --asprimary
part pv.100001 --size=20000 --asprimary
part pv.100000 --size=20000 --asprimary
part pv.100002 --size=1 --grow --asprimary
volgroup sysvg --pesize=32768 pv.100000 pv.100001 pv.100002
logvol swap --fstype swap --name=swap --vgname=sysvg --size=2000
logvol /home --fstype ext3 --name=home --vgname=sysvg --size=1 --grow
logvol / --fstype ext3 --name=root --vgname=sysvg –size=20000
firstboot --disable
reboot
#
%packages
@admin-tools
@base
@core
@system-tools
@text-internet
@web-server
#
%post
#!/bin/bash
useradd -m -s /bin/bash -G wheel vpupkin

А теперь разберем его. Для удобства строки пронумерованы и я буду просто ссылаться на номера. В строчках [1-3] мы определяем, что это будет чистая инсталляция (не обновление) , местоположение дистрибутива (если быть точным – первого диска дистрибутива) и задаем инсталляционный номер.

Далее [4-5] мы указываем язык системы и тип клавиатуры. Нотация стандартная, то есть чтобы установить русский язык системы надо исправить en_US.UTF-8 на ru_RU.UTF-8.

В [6] мы конфигурируем X.org сервер, задавая рабочий стол по умолчанию (KDE), разрешение и глубину цвета, а также определяем, что X.org должен стартовать при загрузке.

В [7] находится простая сетевая конфигурация, определяющая, что у нас единственная сетевая карта, которая использует DHCP для получения сетевых настроек. Это рекомендованный вариант, так как в случае, если вы устанавливаете много систем с одного kickstart-файла, вы не можете использовать одни и те же сетевые настройки. Кроме того, DHCP-сервер в любом случае является необходимым для сетевой инсталляции.

В [8] мы устанавливаем административный пароль (он заранее зашифрован).

В [9] и [11] мы отключаем брандмауэр и мандатный контроль доступа соответственно (не будем забывать, что мы рассматриваем простой пример).

В [10] мы конфигурируем стандартную аутентификацию через /etc/passwd и /etc/shadow с шифрованными паролями. В этой строке возможно заранее сконфигурировать аутентификацию с использованием Kerberos, LDAP, NIS, или Windows-домена.

В [12] мы задаем временную зону, а в [13] задаем положение загрузчика, опции передаваемые ядру и, если у вас более одного жесткого диска – порядок следования их в BIOS системы.

Строки [13-21] задают разметку диска. В нашем случае создается одна 100Мб ext3-партиция /boot для ядра, initrd и загрузчика, остальное место размечается на 3 партиции, поверх которых располагается LVM, на котором выделяется 20Гб том под основную систему (/), 2Гб под место для подкачки, а остальное место монтируется как /home для данных пользователей.

Строки [24-25] отключают агент настройки системы при первой загрузке и указывают, что системы должна перезагрузиться после установки.

Строки [27-31], как это видно, находятся в области %packages, и определяют пакеты и группы пакетов, которые должны быть установлены. Синтаксис простой: имя пакета, чтобы установить один пакет (например dhcp) и @имя_группы, чтобы установить определенную группу пакетов.

Оставшиеся строки (секция %post) – постинсталляционный скрипт. В нашем случае он просто добавляет пользователя vpupkin. Вообще говоря, это может быть произвольный скрипт, который обновляет систему, скачивает и устанавливает конфигурацию или выполняет прочие произвольные действия.

Использование ks-файла

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

Сохраните ваш kickstart-файл куда-нибудь на сервер. Я разместил его в /var/ftp/rhel-ks.cfg и, соответственно, он стал доступен по сети по адресу ftp://192.168.0.2/rhel-ks.cfg. Осталось «сообщить» об этом примечательном факте загружающимся по PXE системам. Для этого изменим файл '/tftpboot/prelinux.cfg/default' так, чтобы он содержал следующую информацию:
label linux
kernel vmlinuz
append initrd=initrd.img ramdisk_size=9216 noapic acpi=offo ks=ftp://192.168.0.2/ks.cfg

На этом конфигурация заканчивается. Если вам необходимо установить 1000 типовых рабочих станций за день – это не более трудная задача, чем нажать кнопку «Power» на 1000 компьютерах.

Удобности и вкусности.

Естественно, механизм kickstart чрезвычайно удобен для проведения типовых инсталляций. Однако писать сценарий установки не всегда удобно вручную. Для этого существует инструмент system-config-kickstart (входит в поставку RHEL), который в окошке, похожем на этапы инсталляции позволит сформировать костяк конфигурационного файла. Фактически ручного редактирования требует только секция разметки диска и постинсталляционные действия.

Инструментарий kickstart очень удобно интегрирован в RHN. Вы можете сгенерировать сценарий по установленной ранее системе, а также пользоваться каналами конфигурации для приведения типовых систем в боевую готовность непосредственно от состояния «голое железо» (Bare HW).

Полную информацию о синтаксисе kickstart-файлов вы можете почерпнуть по адресу
http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Installation...

Безопасность. В чем ее мерить?

2007-06-20T09:23:00.000+04:00

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

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

Одним из основных источников информации об уязвимостях служит база NVD (National Vulnerability Database), поддерживаемая комитетом при правительстве США. Эта база содержит полный список всех известных уязвимостей во всех программных продуктах и их рейтинги критичности. Рейтинги могут иметь значение «Высокий», «Средний» и «Низкий» в зависимости от того, насколько опасной признана уязвимость.

Инженеры Red Hat провели сравнение уязвимостей, относящихся к Red Hat Enterprise Linux 4 за последние 12 месяцев, по данным NVD и по данным Red Hat.

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

Теперь посмотрим на результаты сравнения. NVD присвоила рейтинг «Высокий» 90 уязвимостям, относящимся к Red Hat Enterprise Linux 4. Рейтинги Red Hat для этих уязвимостей:

23 - «Критичная»
24 - «Важная»
35 - «Средняя»
8 - «Второстепенная»

NVD присвоила рейтинг «Средний» 61 уязвимости. Рейтинги Red Hat для этих уязвимостей:

9 - «Критичная»
18 - «Важная»
22 - «Средняя»
12 - «Второстепенная»

NVD присвоила рейтинг «Низкий» 152 уязвимостям. Рейтинги Red Hat для этих уязвимостей:

7 - «Критичная»
32 - «Важная»
62 - «Средняя»
51 - «Второстепенная»

Таким образом, мы видим, что среди уязвимостей, которым NVD присвоила высший рейтинг, меньше четверти были критичными для Red Hat Enterprise Linux. При этом среди неопасных по мнению NVD уязвимостей были критичные для RHEL.

Почему же так происходит? На самом деле, ничего странного в этом нет. Дело в том, что NVD содержит один рейтинг для каждой уязвимости вне зависимости от платформы, на которой работает приложение.

Рассмотрим популярный web-сервер Apache. Он работает на множестве платформ (Linux, Windows, FreeBSD и т.д.), многие компании включают его в свои продукты. При этом, например, одна и та же уязвимость в нем приводила к исполнению произвольного кода под FreeBSD, вызывала отказ в обслуживании под Windows, но ей нельзя было воспользоваться под Linux. При этом в базе NVD у нее был один рейтинг, на зависящий от платформы.

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

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

Linux реального времени

2007-06-14T16:32:00.001+04:00

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

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

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

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

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

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

Но, тем не менее, есть области, где системы реального времени необходимы. Это управление производственными процессами на заводах, управление на транспорте и подобные задачи. В этих областях подход «достаточно быстро» неприемлем, здесь нужны гарантированные сроки. Кроме того, системы реального времени становятся все более актуальными в финансовом секторе. В этой области «время – деньги» в буквальном смысле слова. И по мере распространения автоматизированных торговых систем и электронных платежных систем работа банковских систем в реальном времени становится все более актуальной.

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

Red Hat выбрал иной подход. Инженеры Red Hat в течение долгого времени работали над включением поддержки работы в реальном времени в основную ветку ядра. Их успехи вдохновили других разработчиков ядра присоединиться к проекту. Сейчас силами инженеров Red Hat, IBM и независимых разработчиков уже проделан большой объем работ.

Разработка продолжается, в ближайшем будущем Red Hat представит Red Hat Enterprise Linux реального времени. Как было указано выше, работа в реальном времени принесет пользу далеко не всем пользователям, поэтому Red Hat будет предлагать две версии дистрибутива – систему общего назначения и систему реального времени.

Если Вы заинтересованы в Linux реального времени, Вы всегда можете присоединиться к проекту.

Построение инфраструктуры для масштабного развертывания RHEL

2007-06-01T11:23:00.000+04:00

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

Это хорошо, когда вся ваша инфраструктура представляет из себя один-два сервера. При большем количестве систем или в ситуации, когда типовую установку ОС приходится выполнять достаточно часто, такой подход становится неудобным. Ниже мы приводим сценарий подготовки развертывания Red Hat Enterprise Linux по сети. Все примеры будут приводиться для установки Red Hat Enterprise Linux 5. Операционная система сервера – RHEL4/5.

PXE-загрузка

Данный этап является наиболее сложным и плохо документированным. А между тем грамотная настройка PXE-окружения является наиболее важным компонентом работающей инфраструктуры развертывания.

Необходимые компоненты:

DHCP сервер.
TFTP сервер.
Созданные нами файлы и настройки.

Итак, по-порядку. TFTP-сервер.

Сначала настроим TFTP-сервер. (TFTP – Trivial File Transfer Protocol, простой протокол передачи файлов, работающий через UDP.)

Убедитесь, что в системе, которая будет TFTP-сервером, установлены пакеты tftp-server и xinetd. Проверяется это так:
$ rpm -qi tftp-server
$ rpm -qi xinetd
Если вы получили информацию по этим пакетам, то они у вас установлены. В противном случае их необходимо установить.
# yum -y install xinetd tftp-server (RHEL5)
# up2date install xinetd tftp-server (RHEL4)
Разрешите в конфигурации xinetd запуск tftp в качестве сервиса по требованию. Для этого откройте файл /etc/xinet.d/tftp
И исправьте там строчку
disable = yes
на
disable = no
В конфигурации по умолчанию корневой директорией для tftp-сервера является директория /tftpboot/
Туда нам необходимо перенести файлы, необходимые для начала инсталляции. Установите пакет syslinux и перенесите PXE-загрузчик в директорию /tftpboot/
# yum install syslinux
# cp /usr/lib/syslinux/pxelinux.0 /tftpboot/
Далее нам необходимо поместить в /tftpboot/ ядро и initrd для системы, которую мы желаем устанавливать по сети. Обычно такая возможность предусмотрена и нужные файлы есть на образах инсталляционных дисков. Итак, смонтируйте образ диска:
# mount -o loop /[путь к директории с образами]/rhel-5-server-i386-disc1.iso /mnt
# cp /mnt/images/pxeboot/{vmlinuz,initrd.img} /tftpboot/
Осталось сделать конфигурацию для загрузчика. Отредактируйте файл
/tftpboot/pxelinux.cfg/default
Содержимое этого файла для рассматриваемого случая будет следующим:
default linux
prompt 1
timeout 100

label linux
kernel vmlinuz
append initrd=initrd.img ramdisk_size=9216

Для тех, кто сталкивался с конфигурированием lilo, конфигурация, должно быть, выглядит знакомо. Для тех, кто не имел подобного опыта, краткое описание:
default– метка записи, загружаемой по умолчанию
prompt – надо ли давать возможность выбора
timeout – время, после которого default запись будет загружена
label – метка, название конфигурации. Может быть произвольной.
kernel – путь к файлу ядра. Путь задается относительно директории /tftpboot/
append – различные опции, передаваемые ядру, в том числе и файл initrd
На этом базовая конфигурация TFTP-сервера закончилась. Запустите сервис xinetd и (опционально) добавьте его в автозагрузку.
# service xinetd start
# chkconfig xinetd on

DHCP-сервер

DHCP-сервер нужен для того чтобы при PXE загрузке сообщить новой системе параметры сети и передать информацию, необходимую для сетевой установки. Желательно, чтобы DHCP-сервер и TFTP-сервер находились в пределах одной сети. Если у вас уже есть работающий вариант DHCP-сервера, то вам достаточно просто добавить несколько опция для нужных IP-адресов. Ниже приведем простейшую конфигурацию с комментариями

ddns-update-style interim;
ignore client-updates;

subnet 192.168.0.0 netmask 255.255.255.0 {
option routers 192.168.0.1;
option subnet-mask 255.255.255.0;
option domain-name "example.com";
option domain-name-servers 192.168.0.2;
option time-offset 10800; # GMT+3
range dynamic-bootp 192.168.0.4 192.168.2.254;
default-lease-time 21600;
max-lease-time 43200;
next-server 192.168.0.2;
filename "pxelinux.0";
}

Итак, по порядку. Опции routers, subnet-mask, domain-name, domain-name-servers аналогичны сетевым настройкам Default Gateway, Network Mask, DNS Domain name и DNS Servers. Адаптируйте их в соответствии со своими параметрами. Опция time-offset – разница во времени с Гринвичем в секундах. range dynamic-bootp – диапазон выдаваемых адресов, default-lease-time и max-lease time – времена в секундах аренды адреса по умолчанию и максимальное время аренды соответственно. Наиболее интересующие нас параметры:

next-server – IP-адрес TFTP-сервера
filename – путь к файлу PXE-загрузчика (относительно каталога /tftpboot/)

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

Установочный репозитарий

В процессе установки установочный репозитарий необходим для того, чтобы предоставить инсталляторам, которые могут работать параллельно, доступ к дистрибутиву и избавить пользователя от необходимости создания нескольких копий (например записывать диски). Репозитарий можно располагать на FTP, HTTP и NFS серверах. Мы рассмотрим одну из этих конфигураций, остальные выполняются аналогично.

FTP-сервер

Конфигурация проста. Пример ниже приведен для установки RHEL5. Если у вас другая версия – обратитесь к документации по дистрибутиву. Предполагается что у вас есть 5 образов, скачанных c RHN. Для некоторых версий и архитектур количество может отличаться.

Создайте директории для монтирования этих образов.
# for i in $(seq 1 5); do mkdir -p /var/ftp/rhel5-server-x68/disk${i}; done
Смонтируйте образы в созданные директории. Обратите внимание, что из-за внутренних ограничений ядра Linux число одновременно смонтированных образов не может превышать 8. Таким образом, если вы хотите обеспечить окружения для инсталляции более чем одной версии, лучшим выбором будет скопировать содержимое образов в эти директории. В нашем случае монтирование быстрее и не требует дополнительного дискового пространства.
# for i in $(seq 1 5); do mount -o loop [путь к директории с образами]/rhel-5-server-i386-disc${i}.iso /var/ftp/rhel5-server-x68/disk${i}; done
Проверьте, что у вас включен анонимный ftp и корневой директорией для vsftpd является /var/ftp (В RHEL это настроено по умолчанию). Запустите сервис FTP и (опционально) добавьте его в автозагрузку.
# service vsftpd start
# chkconfig vsftp on
Проверьте доступность ресурса, напрмимер с помощью браузера по URL
ftp://[ваш FTP-сервер]/rhel5-server-x86/disk1
Вы должны увидеть содержимое инсталляционного образа CD #1. Если этого не произошло, проверьте выполнение предыдущих пунктов еще раз.

Конец

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

Конец войны форматов?

2007-05-28T15:07:00.000+04:00

Microsoft опубликовала пресс-релиз, в котором заявила, что проголосовала за включение Open Document Format в перечень стандартов ANSI. Полный пресс-релиз можно найти здесь: http://www.microsoft.com/presspass/press/2007/may07/05-16ANSIVotePR.mspx

О чем вообще речь? Почему это важно?

Сегодня одно из основных применений компьютера – работа с офисными программами. Все офисные программы работают с некоторыми документами, будь это текстовые документы, электронные таблицы, презентации или что-либо еще. Все документы при этом хранятся в своих форматах. До недавнего времени фактическими стандартами были форматы, разработанные компанией Microsoft (.doc, .xls, .ppt и т.д.)

Сегодняшним требованиям эти форматы уже не удовлетворяют, и явно назрела необходимость их замены. С этим согласны все. Кандидатов на роль нового стандарта два – Open XML, разработанный Microsoft, и Open Document, разработанный консорциумом OASIS.

Подавляющее большинство крупных компаний (IBM, Sun, Red Hat, Novell и т.д.) поддерживают ODF. И причиной этому далеко не только то, что Open XML разработан Microsoft.

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

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

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

Какова ситуация сегодня?

Open Document уже сейчас принят как стандарт ISO, и его поддержка реализована во многих офисных пакетах. Основной из них – OpenOffice, который существует как для Linux, так и для Windows. Фактически, Open Document уже становится стандартом. Например, правительство штата Массачусетс объявило о полном переводе документооборота на Open Document.

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

Что наиболее интересно – позиция Microsoft. Компания проголосовала за формат-конкурент. Очевидно, что сделано это с целью сохранить лицо в проигрышной ситуации – Open Document в любом случае был бы принят как международный стандарт, с Microsoft или без нее.

Но теперь важно, будет ли Microsoft реализовывать поддержку Open Document в своих продуктах в полном объеме. Microsoft давно известна своим вольным отношением к стандартам, что регулярно приводит к проблемам при длительной эксплуатации ее продуктов. В частности, совместимость собственных офисных форматов Microsoft между разными версиями MS Office оставляет желать лучшего – форматирование искажается практически всегда.

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

Шоу «Очень страшные патенты»

2007-05-22T11:20:00.000+04:00

Microsoft в очередной раз заявила, что Linux и сопутствующее открытое ПО нарушают патенты, принадлежащие Microsoft. На этот раз прозвучала цифра – 235 патентов, из них 42 касаются ядра Linux, 65 графической подсистемы, 45 офисных программ, 15 e-mail клиентов и 68 относятся к другим программам.

Но ни один патент не был назван. Почему? Чего добивается корпорация?

На этот вопрос очень хорошо ответил Эбен Моглен в своей речи на саммите Red Hat. Оригинал речи можно найти по адресу http://en.wikisource.org/wiki/The_%E2%80%9CBe_very_afraid%E2%80%9D_tour. Мы же изложим основную идею.

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

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

Но можно ведь просто ходить вокруг, приговаривая: «А у нас есть патенты... Много патентов... И кое-кто кое-какие из них нарушает... И однажды кому-то из-за этого будет плохо... Лучше не используйте эти программы.»

Это ведь гораздо проще и эффективнее, чем судиться, не правда ли? Кроме того, если судиться, то ведь придется на самом деле показать, к каким патентам вы апеллируете.

Итак, запугивание гораздо эффективнее, чем предметные претензии, так?

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

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

Получается очень простая схема. Крупным корпорациям можно ответить: «Просто используйте вот эту сборку вместо той, что используете сейчас». И в то же время можно продолжать запугивать сообщество разработчиков, выбивая тем самым почву из-под ног конкурентов. Удобно, не правда ли?

Что самое интересное (вот это сюрприз!), Microsoft начала очередное шоу «Очень страшные патенты» ровно после заключения соглашения с Novell. Интересно, не правда ли?

Open source для создания web 2.0 приложений и web-сервисов

2007-04-28T15:23:00.000+04:00

В марте Red Hat и Exadel объявили о сотрудничестве. Основные продукты компании Exadel – Exadel Studio Pro, Rich Faces и Ajax4jsf. Все это – инструменты для создания Web 2.0 приложений и web-сервисов, основанные на открытой среде разработки Eclipse.

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

На основе Exadel Studio Pro планируется выпустить полностью интегрированную с продуктами JBoss и готовую к использованию среду разработки – Red Hat Developer Studio. Выпуск запланирован на середину лета.

Что это дает? Потенциально это открывает для open source новый рынок.

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

Создание законченной среды разработки Red Hat Developer Studio, ориентированной именно на приложения бизнес-логики, интеграция продуктов MetaMatrix – эти факты позволяют говорить о том, что open source все увереннее выходит на новый для себя рынок и имеет достаточно неплохую основу для того, чтобы преуспеть на нем.

Red Hat приобретает MetaMatrix

2007-04-25T11:15:00.000+04:00

Что такое MetaMatrix?

MetaMatrix – компания-пионер в области интеграции источников данных и управления метаданными. Компания работает в этой области с 1999 года, является одним из старейших участников рынка.

Чем занимается MetaMatrix? Зачем нужны ее продукты?

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

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

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

Какие возможности дают продукты MetaMatrix?

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

Каковы планы Red Hat в отношении MetaMatrix?

После завершения сделки команда MetaMatrix вольется в подразделение Red Hat, которое занимается продуктами JBoss. Объединенная команда будет работать над интеграцией продуктов JBoss и MetaMatrix с тем, чтобы предоставить клиентам лучшее ПО промежуточного уровня.

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

Где можно найти дополнительную информацию?

По этой ссылке: http://www.redhat.com/promo/next/faq.html

Виртуализация с Xen. Живая миграция

2007-03-31T11:21:00.000+04:00

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

Для демонстрации использовались 2 сервера и 2 клиента. Виртуальная машина, с которой велась трансляция, мигрировала между серверами. Один клиент использовался в качестве управляющей станции, со второго собственно демонстрировалась трансляция. Клиентов, в принципе, можно объединить в одного. Соединены все машины были через обычный 100 Mbit Ethernet.

Далее используются следующие имена машин:

xen_host_1 - первый физический сервер
xen_host_2 - второй физический сервер
virt_server - виртуальный сервер

Подготовка демонстрации

Установите на xen_host_1 и xen_host_2 Red Hat Enterprise Linux 5 с поддержкой виртуализации.
Установите на xen_host_1 в виртуальную машину virt_server паравиртуализованный Red Hat Enterprise Linux 5.
После установки отредактируйте /etc/xen/virt_server, приведите его к следующему вид:
#vnc=1
#vncunused=1
sdl=1
Это необходимо, чтобы можно было осуществить живую миграцию данной виртуальной машины.
Теперь необходимо настроить xen на xen_host_1 и xen_host_2 таким образом, чтобы он позволял осуществить миграцию между двумя физическими серверами. Для этого внесите следующие изменения в /etc/xen/xend-config.sxp на обоих машинах:
#(xend-unix-server yes)
(xend-relocation-server yes)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '')
#(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$')
После этого перезапустите xen
service xend restart
Теперь нам необходимо, чтобы оба физические сервера видели общее хранилище, на котором находятся данные виртуальной машины. Кроме того, необходимо, чтобы оно было смонтировано по одинаковому пути. Это требуется потому, что при миграции виртуальной машины ее файловая система не копируется, так как это требовало бы слишком много времени даже в случае быстрой сети.
В нашем распоряжении не было внешнего накопителя, но это не стало препятствием. Мы использовали NFS.
На xen_host_1 (на котором установлен virt_server) в /etc/exports добавьте строку:
/xen *(rw,sync,no_root_squash)
После этого перезапустите NFS и убедитесь, что сервис стартует автоматически:
service nfs restart
chkconfig nfs on
Смонтируйте созданную папку на xen_host_2:
mount xen_host_1:/xen /xen
Запустите виртуальный сервер на xen_host_1
xm create -c virt_server
Установите сервер потокового видео на virt_server. Мы использовали gnump3d. Для установки скачайте с http://www.gnump3d.org/ архив gnump3d-2.9.9.9.tar.bz2 (620k), распакуйте и скомпилируйте его.
tar xjvf gnump3d-2.9.9.9.tar.bz2
cd gnump3d-2.9.9.9/
make install
Включите трансляцию. По умолчанию сервер настроен на трансляцию содержимого директории /home/mp3/.
mkdir /home/mp3
cd /home/mp3
wget -c http://www.redhat.com/v/ogg/TruthHappens.ogg
gnump3d &

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

Демонстрация

Запустите просмотр трансляции на клиенте. В случае totem для этого нажмите 'Movie', затем 'Open Location' и введите http://virt_server:8888/TruthHappens.ogg
Остановите виртуальный сервер. Для этого на xen_host_1 выполните
xm pause virt_server
В течение некоторого времени после остановки виртуальной машины (как правило, нескольких секунд) клиент будет продолжать показывать ролик из буфера плеера. После того, как буфер закончится, трансляция прервется. Теперь Вы знаете размер буфера в секундах. :)
Снимите виртуальный сервер с паузы. Для этого на xen_host_1 выполните
xm unpause virt_server
Вновь запустите трансляцию на клиенте.
Выполните живую миграцию сервера без остановки трансляции. Для этого на xen_host_1 выполните
xm migrate -l virt_server xen_host_2
Процесс занимает несколько десятков секунд. Следить за миграцией можно с помощью команды xm list на обоих физических серверах. Трансляция при миграции не рвется. Клиент никак не замечает, что виртуальная машина переносится на другой физический сервер. Так как Вы только что измерили размер буфера плеера, можете быть уверены, что все честно. :)

3D-рабочий стол, Compiz & Beryl.

2007-03-31T11:16:00.000+04:00

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

X-сервер. Xgl и AIGLX

Xgl – это новая архитектура X-сервера, использующая OpenGL. AIGLX – это расширение стандартного X.org для использования в нем OpenGL. Функциональность их примерно одинакова. Принципиальное отличие в архитектуре – Xgl заменяет стандартный X.org, в то время как AIGLX расширяет его функциональность.

На наш взгляд, второй подход гораздо более разумен и перспективен, так как позволяет разрабатывать AIGLX и X.org параллельно и не дублировать при этом код.

Менеджер окон. Compiz и Beryl

Обновленные X-серверы являются только основой, а непосредственно эффектами рабочего стола (3D-рабочий стол, гибкие окна, прозрачность и т.д) занимается композитный менеджер окон. На сегодняшний день их существует два – Compiz и Beryl. Они очень похожи между собой, по сути, второй является производным от первого. Основная разница в том, что у Beryl больше возможностей, больше эффектов, но при этом он работает медленнее. Кроме того, на наш взгляд, он менее стабилен, но это лишь наше мнение.

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

Описание живых демонстраций

Для живых демонстраций мы использовали AIGLX и Compiz, входящие в стандартный комплект дистрибутива Red Hat Enterprise Desktop 5. Демонстрации показывали под Gnome, потому что в нем есть графическая утилита для управления эффектами. Под KDE запустить Compiz также не составляет труда, но делать это нужно из консоли. :)

Требования к оборудованию

Мы тестировали работу AIGLX и Compiz на видеокартах от NVIDIA, ATI и Intel.

На Intel (встроенное видео ноутбуков) никаких проблем замечено не было.

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

Хуже всего на сегодняшний дело обстоит с чипсетами ATI. В бинарном драйвере производителя (fglrx) есть ошибка, в результате чего он не поддерживает все необходимые расширения, и AIGLX с ним не работает. ATI признала наличие ошибки и пообещала ее устранить в следующей версии драйвера (9.x). На сегодняшний же день запустить AIGLX с видеокартой ATI можно используя open source драйвер (radeon). Этот драйвер входит в состав дистрибутива и устанавливается по умолчанию, если определена видеокарта ATI. Драйвер поддерживает все необходимые расширения, но так как ATI не раскрывает спецификацию своих карт, он работает не слишком быстро.

Ян Мердок переходит в Sun

2007-03-25T13:14:00.000+04:00

Ян Мердок, основатель проекта Debian, переходит в Sun на должность руководителя направления операционных платформ (систем). При этом он фактически уходит из Linux Foundation, хотя формально и сохраняет свой пост. Любые активные действия человека подобного масштаба не могут остаться незамеченными. Мы не будем обсуждать мотивы этого шага и его идейную сторону. На эту тему уже было множество дискуссий в сообществе open source, а истины в данном случае все равно не существует. Вместо этого мы кратко рассмотрим, какие последствия это событие может иметь.

Для самого Яна:

Судя по его блогу (http://ianmurdock.com/2007/03/19/joining-sun/), Ян искренне рад возможности присоединиться к команде Sun. У него есть ряд идей, как улучшить Solaris, и он горит желанием воплотить их в жизнь. На этом посту у него есть возможность реализовать свой потенциал.

Для Sun:

Solaris долгое время была одной из наиболее технологически совершенных и популярных операционных систем. С появлением Linux, с массовым переходом на стандартные системы на базе процессоров Intel и AMD Solaris заметно сдала свои позиции. На сегодняшний день Sun сделала многое, чтобы вернуть ему популярность – выпустила версию для x86, создала OpenSolaris. Но, тем не менее, требуется еще большой объем работы, чтобы Solaris вновь стала одной из ведущих платформ как среди пользователей, так и среди компаний-разработчиков. Авторитет и репутация Яна могут быть в этом очень и очень полезны.

Для Linux Foundation:

Именно Linux Foundation выглядит наиболее пострадавшей стороной, ведь именно из нее Ян ушел. Но так ли все плохо? Ян всегда был активным поборником принципов open source и стандартов LSB. Вряд ли он резко изменится после этого назначения. Наоборот, скорее всего, он будет пытаться изменить Sun, заменить лицензию OpenSolaris на GPL, привести Solaris к стандартам, и тем самым улучшить ее совместимость с Linux. Честно говоря, далеко не факт, что это ему удастся, но в любом случае подобные шаги способствуют укреплению стандартов. Так что, очень может быть, что Linux Foundation только выиграла, ведь ее активный участник теперь является одним из руководителей крупной корпорации.

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

Сделка Novell – Microsoft. Первые заметные результаты.

2007-03-16T12:13:00.000+03:00

Пресс-релиз от 13 марта (http://www.microsoft.com/presspass/press/2007/mar07/03-13HSBCPR.mspx) на сайте Microsoft сообщает, что HSBC, одна из крупнейших в мире финансовых организаций, собирается использовать продукты Novell, которые будет поставлять Microsoft.

HSBC очень крупная компания. Ее головной офис находится в Лондоне, компания имеет более 9500 офисов в 76 странах, в которых работают более 284000 сотрудников. Если такая крупная компания верит в перспективы союза Novell и Microsoft, то, видимо, у него большое будущее. Ведь так?

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

Происходящее несколько напоминает историю сотрудничества Microsoft и IBM и развития Windows и OS/2. Как известно, закончилась история тем, что пользователи воспринимают Windows как синоним слова «компьютер», а об OS/2 большинство даже не слышало. Возникает такое ощущение, что происходящее – попытка Microsoft приручить пингвина и удушить опасного конкурента (Linux) в дружеских объятиях.

Еще информация к размышлению: почему Novell согласилась на пресс-релиз в таком виде? Брюс Лоури, директор Novell по связям с общественностью, опубликовал краткое разъяснение в блоге (http://www.novell.com/prblogs/?p=303#comments). Лоури говорит о том, что для пресс-релиза неаккуратно были выбраны цитаты, и первоначальный смысл был искажен. Это вся реакция, которая последовала со стороны Novell, и выглядит она при этом скорее как оправдание. Похоже, Novell не может повлиять на происходящее.

Но если это так, то зачем Novell это неравное партнерство, портящее имидж компании в глазах Linux-сообщества? На этот вопрос уже ответил Брент Вильямс в своей презентации на EclipseCon (http://stephesblog.blogs.com/presentations/BrentWilliamsEclipseConV02.pd...).

Во-первых, Novell видит своим главным конкурентом Red Hat (слайд 14).
Во-вторых, Novell не верит в возможность переиграть Red Hat в одиночку (слайд 15).

Сможет ли Novell потеснить Red Hat, имея в союзниках Microsoft? Сложно сказать. Окончательный ответ даст только время. Но предположения сделать все же можно.

Novell ставит своей целью снижение стоимости решений. Red Hat основной задачей считает предоставление более качественного сервиса своим клиентам. Доля IT в полном бюджете компании составляет, как правило, не более 10%. Допустим, бюджет компании составляет $1.000.000. Тогда из них $100.000 – расходы на IT, $900.000 – расходы на бизнес – задачи. Novell стремится снизить расходы на IT. Если решения Novell будут на 10% дешевле, то выгода для клиента - $10.000. Red Hat стремится решать насущные проблемы клиентов. Если у него это получится на 10% лучше, то выгода для клиента - $90.000.

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

Решение, как всегда, остается за клиентом.