15.07.2007

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

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

  1. Приверженцы
  2. Со смешанной базой кода
  3. Прагматики
  4. Со стратегией «анти»
  5. «Обезглавленные цыплята»
  6. Отрицающие
  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 стало слишком заметным явлением, чтобы его просто игнорировать.

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

01.07.2007

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

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

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

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

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

  1. install
  2. url --url ftp://192.168.0.2/redhat/disk1
  3. key [installation number]
  4. lang en_US.UTF-8
  5. keyboard us
  6. xconfig --startxonboot --defaultdesktop kde --resolution 1400x1050 --depth 32
  7. network --device eth0 --bootproto dhcp --onboot=on
  8. rootpw --iscrypted $1$vFt/3HTE$N16kauXMVOmNHurppHAo0/
  9. firewall --disabled
  10. authconfig --useshadow --enablemd5
  11. selinux --disabled
  12. timezone --utc Europe/Moscow
  13. bootloader --location=mbr --driveorder=sda --append="rhgb quiet"
  14. #
  15. clearpart --all --initlabel
  16. part /boot --fstype ext3 --size=100 --asprimary
  17. part pv.100001 --size=20000 --asprimary
  18. part pv.100000 --size=20000 --asprimary
  19. part pv.100002 --size=1 --grow --asprimary
  20. volgroup sysvg --pesize=32768 pv.100000 pv.100001 pv.100002
  21. logvol swap --fstype swap --name=swap --vgname=sysvg --size=2000
  22. logvol /home --fstype ext3 --name=home --vgname=sysvg --size=1 --grow
  23. logvol / --fstype ext3 --name=root --vgname=sysvg –size=20000
  24. firstboot --disable
  25. reboot
  26. #
  27. %packages
  28. @admin-tools
  29. @base
  30. @core
  31. @system-tools
  32. @text-internet
  33. @web-server
  34. #
  35. %post
  36. #!/bin/bash
  37. 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...