Москва октябрь 2007 Убить Билла, вторая попытка, или Novell OES 2.

В октябре 2007 года компания Novell, Inc. начала продажи продукта с завлекающим названием Open Enterprise Server 2. Тем самым был завершен перенос специфичных сервисов Novell для рабочих групп на платформу Linux. А сам OES 2 фактически занял место флагманского продукта, сместив вниз по шкале ценностей SUSE Linux Enterprise Server.

В конце прошлого века невозможно было встретить системного администратора, не знакомого с продукцией компании Novell, Inc. Многие тогда начинали карьеру с получения профессионального сертификата CNA (Certified Novell Administrator), а красный значок с золотым треугольником в среде сисадминов по статусу соответствовал медали За боевые заслуги. Я свой значок храню до сих пор. За прошедшие годы имидж компании ничем не омрачился, но заметно поистерся, так как в силу разных причин Novell, Inc. покинула группу технологических лидеров, а рыженький зайчик, еще недавно многих радовавший хаотичными перемещениями по экрану монитора в серверной, даже в Красной книге редко встречаемых программ вот-вот попадет в черный список исчезнувших экземпляров.

Но сказать, что о компании забыли за малозначимостью, невозможно. Более того, Novell, Inc.

оказалась в самом центре событий, еще недавно будораживших не только среду специалистов по информатике [1]. И нельзя воспринимать движение Novell в сторону продуктов с открытым кодом, как спонтанное действие. Это весьма продуманный план, претворяемый в жизнь с тщательностью и упорством. Очередным этапом этого плана стал выпуск второго релиза Open Enterprise Server (OES 2).

Первое знакомство.

Не скрою, загадочный продукт! Как и следует, общественность была подготовлена к правильному восприятию официальным пресс-релизом [2]. Многочисленные кросс публикации анонсов и цитат речей руководителей Novell прочно занимают первые страницы поисковых систем. Не буду их повторять. Кто хочет, легко найдет. Но там нет технических подробностей и уж очень много повторов. Попробуем взглянуть на последнее детище софтверного гиганта глазами, не зашоренными официальной пресс-конференцией с традиционным фуршетом. Для тестовой установки я воспользовался дисками, любезно предоставленными редакцией журнала Системный администратор, но проверил, что все желающие легко могут загрузить их с сайта компании [3] после регистрации. В моем распоряжении оказались SUSE Linux Enterprise Server 10 SP1 64-bit DVD 1 (SLES 10 SP1) и Novell Open Enterprise Server 2 64-bit CD 1 (OES 2). Этого достаточно для установки OES 2 на компьютер с архитектурой x86_64. Итак, приступим.

Из двух указанных дисков лишь носитель SLES 10 SP1 имел возможность загрузки. Затем, это был не какой-то особенный SLES-дистрибутив, а самый что ни на есть стандартный. То есть, его установка могла производиться совершенно независимым образом, как самостоятельного продукта. А для того чтобы получить обещанный OES 2, надо подключить его дистрибутивный диск или в процессе установки, или потом, как добавочный продукт.

Можно и вообще обойти данную процедуру, и подключить этот диск, как добавочный репозиторий, или просто слить оба диска в один, согласно рецепту [4]. Следовательно, в процедуре установки никак не отражается тот факт, что эти диски объединены в продукт Open Enterprise Serever 2. Иначе говоря, это опровергает навязываемую пресс-релизом [1] мысль о том, что OES 2 включает в себя SLES 10. На самом деле все с точностью до наоборот. И это не мое гениальное открытие - в руководство по установке [5] на странице 25, так написано. Хотя, никто не мешает даже концерну VAG продавать автомобиль Bora, как приложение к фирменным салонным коврикам.

Описывать установку SLES 10, да еще иллюстрировать её скриншотами нет никакого смысла, это совершенно очевидная процедура, незначительно отличающаяся, от установки openSUSE, описанной в статье [6]. В SLES как и в openSUSE повторяются те же ляпы и огрехи перевода, например, Порядок жесткоих дисков на странице параметров установки (Рисунок 1). Есть и небольшие отличия, например, по умолчанию предполагается ReiserFS для корневого раздела. Вспомним, что поддержку ReiserFS как рекомендованной для использования в качестве корневой файловой системы, изъяли еще в версии 10.2 дистрибутива openSUSE из-за технических проблем и сложностей с поддержкой [7]. Неужели могучая команда, разрабатывающая SLES, смогла вдруг преодолеть все трудности? Верить этому или смеяться? Но есть и одно специфичное для OES замечание. В процессе установки SLES необходимо отказаться от настройки и запуска OpenLDAP, так как он будет конфликтовать с Novell eDirectory, служащим базой учетных записей в OES 2. Если этого не сделать, то ничего страшного, YaST2 предложит устранить его путем деинсталляции OpenLDAP самостоятельно.

Рисунок 1. Страница параметров установки SLES 10 SP1.

Как видно на рисунке 1, установка производится внутри Xen. Замечу, мне для этого не пришлось пересобирать установочный диск для даунгрейда Grub. То есть, разработчики openSUSE и SLES так и не пообщались на эту тему за прошедший год с появления такой проблемы. И возможно это не и ошибка вовсе, а, как сейчас говорят, фича!

Как только установка SLES 10 SP1 завершилась, я подключил OES 2 в качестве дополнительного продукта, что дало возможность установки новых дистрибутивных профилей из OES 2 (Рисунок 2). Для проверки выбрал все! Как и следовало ожидать, установилось так же все, и в результате в меню YaST2 появились новые иконки (Рисунок 3).

И вот тут еще один сюрприз. Посмотрите на рисунок 3 внимательно - 7 из 10 новых иконок в разделе OES отвечают за разные формы миграции. Предлагаю запомнить это важное наблюдение.

Рисунок 2. Дополнительные наборы пакетов из OES 2.

Новый функционал.

Но, конечно, изменилось не только меню YaST2. Согласно пресс-релизу в системе появились многочисленные и чрезвычайно важные службы. Самое интересное это управление через веб-портал. Тема эта бесконечная. И на самом деле способна сильно удивить тех, кто не знаком с проектом Webmin [8] (чтобы не конкурировать с YaST, этот веб-администратор был предусмотрительно удален несколько лет назад из SuSE Linux, как тогда назывался предок openSUSE). Можно отметить продвинутую манеру подключения этой возможности: на основном сетевом адресе создается http-ресурс, содержащий ссылки на другие веб-панели управления, что позволяет не запоминать их порты и адреса. Опять же, это так очевидно, что, предполагаю, входит в стандартный перечень настроек не только у меня, но и у многих других системных администраторов. Но ведь, чем-то должен отличаться SLES от openSUSE, кроме нормальной версии Grub? Чтобы завершить тему веб-панелей приведу скриншот, содержащий основную панель управления сервером, и названия нескольких других в области вкладок броузера (Рисунок 4). Первая из вкладок соответствует основной странице созданного сервера, а остальные открыты по ссылкам. Функциональность основной панели позволяет контролировать выполнение ключевых сервисов, изменять параметры многих подсистем и перезапускать сам сервер. Можно утверждать, что веб-портал позволит системным администраторам во многих случаях не замечать в OES 2 того, что он выполняется в среде GNU/Linux. Что тоже важный фактор, облегчающий миграцию и позволяющий снизить нагрузку на системного администратора, если GNU/Linux для него является чуждой средой.

Рисунок 3. Раздел Open Enterprise Server в меню YaST2.

В тех случаях, когда миграция контента затруднена, OES 2 поддерживает выполнение кода NetWare 6.5 в Xen в режиме паравиртуализации. Чтобы это было правильно понято, объясню, именно запуск в режиме паравиртуализации позволяет до минимума сократить системные затраты на обслуживание слоя инкапсуляции виртуальной среды. То есть, это надо понимать не как недостаток, а как серьезное достижение, позволяющее не только увеличить производительность виртуальных машин, но и одновременно воспользоваться такими благами Xen, как онлайновая миграция доменов для обеспечения балансировки нагрузки и повышения отказоустойчивости. С другой стороны, существование подобной возможности свидетельствует о том что, скорее всего, достичь полной взаимозаменяемости NetWare и OES 2 не получилось. Возможно, пока.

Еще одним заявленным новшеством является служба Domain Service for Windows (DSFW).

Согласно пресс-релизу [2] дословно - лэта технология позволит Linux-серверам вести себя так, как если бы это были серверы Active Directory. Увы, в представленной версии этого нет.

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

Not shown: 1683 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 389/tcp open ldap 443/tcp open https 445/tcp open microsoft-ds 524/tcp open ncp 631/tcp open ipp 636/tcp open ldapssl 5801/tcp open vnc-http- 5901/tcp open vnc- 8009/tcp open ajp MAC Address: 00:16:3E:53:57:5D (Xensource) Device type: general purpose Running: Linux 2.6.X OS details: Linux 2.6.13 - 2.6. Uptime: 0.068 days (since Sat Oct 27 18:43:55 2007) Network Distance: 1 hop Рисунок 4.Веб-портал управления OES.

Сравните приведенное со списком открытых портов реального сервера с функцией AD PDC, найдите л15 отличий и сделайте вывод сами. То есть, наиболее ожидаемое функциональное расширение отсутствует. И как следствие, скорее всего не получится полностью избавиться от установки специализированного пакета Novell Client на рабочие станции. Приятно лишь то, что клиент есть и для Windows Vista.

Завершить перечень знакомых и, теперь, портированных на SLES 10 сетевых служб, можно традиционным, точнее сказать фирменным, Novell NCP (NetWare Core Protocol). Далее начинаются сплошные новшества. Самое значительное Novell Dynamic Storage Technology. В двух словах, средство, ранжирующее хранимые данные по степени важности и частоте использования, и организующее перераспределение их согласно произведенному подсчету в иерархической системе хранения и резервирования. Проверить в тестовых условиях это невозможно. Верим на слово, что работает.

Закулисье.

Конечно, можно описывать все закрыженные опции на рисунке 2 в подробностях, но снова воспользуюсь акцентами из пресс-релиза [2] - лосуществляет окончательный перевод всех служб [...] в число ключевых компонентов входят серверы DNS/DHCP с поддержкой службы каталога. Вот, никогда бы не подумал, что bind и dhcpd, настроенные на использование LDAP, могут играть такую важную роль! Это повод присмотреться к ним повнимательнее.

Начнем с dhcpd. Единственный пакет подходящий на роль dhcpd сервера это novell-oes-dhcp conf. Посмотрим содержимое:

> rpm -qpl novell-oes-dhcp-conf-1.0.0-41.x86_64.rpm /etc/apparmor.d/usr.sbin.dhcpd /opt/novell /opt/novell/dhcp /opt/novell/dhcp/bin /opt/novell/dhcp/bin/create_default_object /opt/novell/dhcp/bin/dhcp_config.sh /opt/novell/dhcp/bin/ncs_dir.sh /opt/novell/dhcp/bin/uninstall.sh /opt/novell/sch /opt/novell/sch/dhcpschema.sch /var/opt/novell/schema /var/opt/novell/schema/ldif /var/opt/novell/schema/ldif/dhcpschema.ldif Внутри нет бинарных файлов представляющих сервер dhcpd. Сервер берется из SLES. Так в чем заключался перевод? В создании бинарника create_defauit_object? Далее проверм DNS.

Здесь повезло:

> rpm -qpl novell-bind-9.3.2-50.x86_64.rpm /etc/apparmor.d/opt.novell.named.bin.novell-named /etc/init.d/novell-named /etc/opt/novell/named /etc/opt/novell/named/root.hint /opt/novell/man /opt/novell/man/man /opt/novell/man/man8/novell-named.8.gz /opt/novell/named /opt/novell/named/bin /opt/novell/named/bin/dns-inst /opt/novell/named/bin/ncs_dir.sh /opt/novell/named/bin/novell-named /opt/novell/named/schema /opt/novell/named/schema/DNIP.SCH /usr/sbin/rcnovell-named /usr/share/omc /usr/share/omc/svcinfo.d /usr/share/omc/svcinfo.d/novell-named.xml /var/opt/novell/log/named /var/opt/novell/run/named В пакет входит и исполняемый бинарный файл и новый скрипт для sysinit. И вот, что внутри исполняемого файла:

> strings $(which novell-named) | grep "named version" named version: BIND 9.3.2 (Sep 23 2007) Иначе говоря, это модернизированный Bind от ISC Software, в оригинале распространяемый по лицензии BSD, что дает право не размещать исходные тексты на дистрибутивных носителях, а всем тем, кто использует этот пакет, основания задуматься над причинами их сокрытия. Подобное было бы невозможно, если в качестве прототипа использовалось бы GPL-ПО.

Кто виноват,Е Теперь, когда основные особенности OES 2 рассмотрены, можно проанализировать перспективы этого продукта в целом и то место, которое он может занять на рынке сетевых платформ. Попробуем представить взаимосвязь архитектур Unix/Linux, MS Windows и NetWare в графическом виде до появления OES 2 и после (рисунок 5).

Рисунок 5.Изменение взаимосвязи архитектур.

Развитие Novell NetWare и MS Windows производилось в основном за счет сервисов рабочих групп. Для того чтобы интегрировать в их среду системы на платформах Unix и GNU/Linux приходилось в последних создавать совместимые средства. Но и Novell NetWare с MS Windows не избежали внедрения подсистем, сделанных по стандартам, пришедшим из среды *NIX, так как обе эти архитектуры претендовали на самостоятельную активность в среде Глобальной Сети. Что скрывать, в настоящий момент присутствие на рынке Novell NetWare ощущается слабо. Я сужу только по своему опыту. Безусловно, предприятия использующие этот продукт исторически продолжают это делать скорее и сейчас, но вряд ли следует ожидать, что не связанная корпоративными стандартами новая организация начнет создание информационной инфраструктуры на основе Novell NetWare. Итак, признаем, что рынок в настоящее время поделен между Windows платформами и *NIX платформами. В среде GNU/Linux, а значит и в openSUSE, а также и в SLES 10 SP1, уже имеются средства интеграции и поддержки функциональности рабочих групп MS Windows. Конечно, эти реализации пока уступают оригинальным системам от Microsoft, в чем собственно и заключается интрига противостояния этих платформ. И вот, внутри открытых платформ создается OES 2, распространяемый по проприетарному принципу, и декларирующий полную совместимость как с архитектурой систем на основе Novell NetWare, так и MS Windows. Задумаемся, есть ли перспектива у такого синтетического решения? Или, говоря просто, зачем потребителям SLES 10 SP1 нужно добавлять функциональность, вносимую OES 2.

Для начала обоснуем необходимость и уместность перехода от openSUSE к SLES. Кстати сказать, эти рассуждения применимы и к взаимоотношениям Fedora Core vs RHEL. С точки зрения технологии преимущества практически несущественные. Даже напротив, жесткие ограничения на модернизацию кодов ключевых компонентов (например, ядра) делают малопривлекательным использование лицензированных версий SLES. Но Enterprise Linux может понадобиться, как способ получения сертифицированного и стандартизованного решения с гарантией преемственности предоставления услуги. И вот тогда, как правило, работодателем или владельцем бизнеса принимается решение о... модернизации открытой версии до уровня предприятия, то есть до SLES.

Еще раз обратимся к рисунку 5. OES 2 не является самостоятельным продуктом, значит, по той же логике, решение о его использовании должно приниматься в точной последовательности после перехода на SLES. И вот здесь логика перестает работать, так как OES 2 не развивает открытые решения, а ЗАМЕНЯЕТ их собственными проприетарными аналогами! То есть меняет бизнес-модель. В чем привлекательность решений OSS (Open Source Software):

- покупатель получает демонополизированную услугу поддержки;

- после внедрения OSS невозможен шантаж технологиями;

- применение OSS снижает для предприятия риск неверного решения по внедрению.

Именно в силу перечисленных выше преимуществ многие производители ПО впускают лоблегченные но полнофункциональные версии своих продуктов под открытыми лицензиями, снабжая лишь специфическими опциями коммерческие релизы. Но у функционала OES 2 нет открытых прототипов. Напротив, его внедрение закроет даже часть потенциально бесплатных и ранее открытых подсистем, таких как упомянутые DNS/DHCP. И уж совершенно безрассудным выглядит внедрение Dynamic Storage Technology, так как оно приведет к перемещению огромных массивов данных в систему, будущее которой под большим сомнением. Есть ли смысл строить корпоративное хранилище на закрытом технологическом стандарте? Ведь такое решение должно не только просуществовать приемлемое для возврата инвестиций время, но и не загнать его владельца в ловушку, сделав зависимым от производителя... примерно так, как попались владельцы Novell NetWare!

Еи кому это нужно.

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

И на платформе GNU/Linux есть такое решение, всем известный проект Samba 4 [9]. Этот продукт связывает воедино целую группу подсистем, заменяя некоторые вопреки даже принятым дистрибутивным стандартам. В частности, Samba 4 cтроится на основе кода Heimdal Kerberos, того самого, что недавно был выкинут из openSUSE и заменен на MIT Kerberos. Затем, для увеличения скорости работы и поддержки sessionless протокола работы с LDAP, внутри проекта Samba 4 создается собственная реализация LDAP-сервера. Кроме того, этот проект лицензируется по GPL 3, что, возможно, создаст трудности для интеграции его даже в SLES. Но игнорировать эту разработку невозможно, и точно также как не получилось в угоду непонятно кем в Novell, Inc. принятому решению избавиться от KDE, точно также можно утверждать, что Samba 4 обязательно будет в openSUSE. А значит, рано или поздно будет и в SUSE Enterprise Linux. Но может ли такое решение попасть в OES?

Разберемся.

В OES совместимость с Active Directory предполагается достичь путем, вероятно, на основе портирования лицензированных исключительно Novell, Inc. технологий Microsoft [10], которые никогда и никоим образом не попадут в OSS. Теперь вопрос! Если ради сохранения eDirectory позволено выкидывать OpenLDAP, то можно ли предположить, что рано или поздно, точно так же, как сейчас работа по протоколам SMB/CIFS строится на основе Samba 3, будет создано решение на основе Samba 4, сохраняющее eDirectory в качестве аутентификационной базы. Возьму на себя смелость предположить, что нет! Иначе говоря, OES уже сейчас является конкурентом SLES, а после появления Samba 4 станет конфликтовать в открытую. Вторая серия риторических вопросов: может ли в рамках одной компании развиваться два конкурентных продукта, претендующих на один сектор рынка?

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

Вот, теперь самое время поговорить о ловушках. Напомню, 7 из 10 добавочных иконок YaST посвящены вопросам миграции. Затем, как видно из самых элементарных рассуждений, приверженцам OSS мало интересны решения, лишь в дань моде названные открытыми, как OES 2, если они основаны на закрытых стандартах и исходных текстах. Тогда, задумаемся, на какую же аудиторию ориентирован этот продукт, который для платформы GNU/Linux, развиваемой в Novell, является, скорее, помехой? Ответ очевиден. Open Enterprise Server это единственная возможность не бросить на произвол тех несчастных корпоративных клиентов, которые не успели избавиться от Novell NetWare, перейдя на MS Windows. Потому-то вопросам миграции уделено столько внимания. Потому-то созданы средства скрывающие платформенные особенности GNU/Linux. Потому-то так нещадно из SLES удаляются целые подсистемы. Ясно, что в условиях спасательной операции просто некогда миндальничать.

Выход второго релиза OES, следует считать второй попыткой устранения Novell NetWare, ставшей всем в тягость. Этот Билл должен быть убит, если не с выходом OES 2, то к появлению OES 3 уже непременно! Выражу надежду, что пресловутый Билл, или, если угодно, Novell NetWare, будет ликвидирован раньше, чем успеет окончательно превратиться в неуловимого Джо, который неуловим лишь потому, что никого не интересует!

Может, еще не все потеряно?

И все-таки, попробуем завершить статью на позитивной ноте. Компания Novell, выпустив OES 2, демонстрирует все симптомы раздвоения сознания, и, фактически, ставит потребителей перед выбором: предпочесть ли пока несовершенный OSS вместе с openSUSE и SLES, или встать на путь конформизма и снова платить Microsoft за технологии, но через кассу Novell, Inc. Причем, одна часть компании агитирует за OSS, а другая так же настойчиво за Microsoft. Одна часть приобретает бизнес SUSE AG, возвращает на работу Хуберта Мантеля (Hubert Mantel), отказывается прекращать поддержку KDE, выкидывает надоедливый и кривой ZMD (ZENworks Management Daemon)... А другая увольняет Хуберта Мантеля (основателя SUSE), пытается, слепо подражая RHEL, сделать Gnome приоритетным менеджером окон, навязывает ZMD, как штатный демон обновления, создает прецедент патентного соглашения с Microsoft, и, наконец, выпускает OES 2! Я использую в своей работе SUSE Linux с версии 6.1, то есть достаточно долго, поэтому высказываю заинтересованность в той части компании Novell, что пытается строить бизнес на основе OSS. Второму же alter ego Novell не следует забывать, что Open Source по свойствам близок к легендарному восточному тигру, оседлав которого, затем очень трудно спрыгнуть обратно. И такой прыжок для одной, близкой Novell, Inc. компании, а именно SCO Group, уже закончился банкротством.

Ссылки:

1.Михаил Рамендик. Тайны Linux-сканадал: суды, кражи и самоубийства. CNews, 17.10.07.

2.Официальный пресс-релиз Novell OES2.

3.Страница загрузки дисковых имиджей Novell OES2.

4.Create an Integration OES2/SLES10SP1 DVD Image. Novell Cool Solutions. By Glen Davis.

5.Novell Open Enterprise Server. Linux Installation Guide. (c) 2005-2007 Novell, Inc. 22.10. 6.Сергей Яремчук. Обзор дистрибутива openSUSE 10.3. Системный администратор, №11(60) ноябрь 2007.

7.Письмо Джефа Махони (Jeff Mahoney) из SUSE Labs о прекращении поддержки ReiserFS.

27.09.2006.

8.Домашняя страница проекта Webmin.

9.Домашняя страница проекта Samba 10.Сенсация: Windows подружилась с Linux. CNews, 03.11.06.

   Книги, научные публикации