Примечание редактора: это третья часть из пяти в серии статей. См. другие статьи developerWorks из этой серии: «Клиентское решение IBM Open Collaboration: обзор», «Клиентское решение IBM Open Collaboration: организационное планирование и сегментация пользователей для миграции настольных систем», а также о переводе приложений для бизнеса на настольные Linux-системы (часть 4) и об архитектурных решениях и вариантах выполнения для открытого виртуального клиента IBM (часть 5).

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

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

Эта статья отчасти опирается на раздел по организационному планированию публикации «Linux Client Migration Cookbook, Version 2: A Practical Planning and Implementation Guide for Migration to Desktop Linux» из серии IBM® Redbooks® и дополнена многими примерами из реальной жизни. Если вы хотите более подробно рассмотреть процесс клиентской миграции, мы рекомендуем эту публикацию IBM Redbooks.

Оценка инфраструктуры

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

• Как выглядит топология сетевой инфраструктуры? (Ответ на этот вопрос включает архитектурный обзор локальных и удаленных соединений, в том числе трафика и используемых протоколов.)
• К какой сетевой инфраструктуре подключены клиентские системы?
• Какой тип сети установлен на клиентской стороне для доступа к инфраструктуре?
• Какие сервисы используются на серверной стороне клиентскими системами и как они подключаются к этим сервисам? (Сервис может быть связан с файлами, печатью, DHCP, веб-контентом, динамическим контентом, и т. д.)
• К каким базам данных подключаются клиенты? Подключаются ли они к базам данных через «родное» клиентское ПО, через API, очереди сообщений, прямой доступ к приложению?
• Наконец, какие мэйнфреймы обеспечивают клиентский доступ? Какой тип соединений они используют? Среди различных способов доступа к мэйнфреймам — «родное» клиентское ПО, веб-интерфейсы, соединения через API.

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

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

Подготовка среды

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

1. Домен NT4 с основными контроллерами домена (PrimaryDomainControllers, PDCs) [а также резервными контроллерами домена (BackupDomainControllers, BDCs)] под Microsoft Windows NT® 4.0.
2. Домен Active Directory с серверами Microsoft Windows 2000 или 2003.
3. Домен NT4 с PDC и BDC Samba под Linux.
4. Другие доменные среды, основанные не на Windows.

В современных сетях широко используется третий вариант, в котором Linux с Samba сочетается с NT4. Существуют весомые причины для перехода с первого варианта на другие среды, так как система Microsoft Windows NT 4.0 уже вышла из употребления. В целом следующие факторы вынуждают нас сконцентрироваться на первых двух вариантах:

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

Наиболее широко используемый протокол/средство для интеграции Linux-клиентов с Microsoft Windows — Samba. Это проработанное приложение UNIX®, основанное на протоколе ServerMessageBlock, используемом в Microsoft Windows для обеспечения сетевых сервисов, связанных с файлами и печатью.

Аутентификация в домене Microsoft Windows

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

• Единый доступ к сетевым сервисам (single sign-on, SSO), при котором у пользователя имеется только одна пара имя-пароль.
• Доступ к совместно используемым файлам или принтерам после аутентификации.
• Общее окно управления пользователями для упрощения администрирования.

В настоящее время существует несколько способов аутентификации в доменах Microsoft Windows. Рассмотрим преимущества и недостатки трех следующих подходов:

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

  Использование разделителя winbind может затронуть большинство приложений, работающих в клиентской системе. Разделитель — это символ, отделяющий имя домена от имени пользователя в имени пользователя Linux. Так, AD1234+Administrator — имя пользователя Linux для пользователя administrator из домена AD1234, а символ «+» используется как разделитель winbind.

• LDAP, подключенный к измененному Active Directory.Преимущества этого подхода — LDAP является общим протоколом для соединения с Active Directory, а идентификаторы пользователей (uid) и групп (gid) присваиваются централизованно, и эта задача решается в Active Directory. Недостаток — приходится изменять схему Active Directory, чтобы разместить в ней информацию UNIX-систем, такую как идентификаторы пользователей и групп.
• LDAP, подключенный к синхронизированному Active Directory. Преимущества этого подхода — LDAP служит общим протоколом для соединения с Active Directory, а идентификаторы пользователей (uid) и групп (gid) присваиваются централизованно. Недостаток — необходимость синхронизации двух различных каталогов.

Обратите внимание на свободное ПО Kerberos, предоставляющее функциональность Samba и «родную» аутентификацию в Active Directory.

Таким образом, Samba, Kerberos, winbind и LDAP — приложения, позволяющие нам осуществлять аутентификацию в домене Microsoft Windows.

Обмен файлами через доменные имена

Доступ к общим папкам из клиентской системы Linux может осуществляться при помощи команды mount, либо при помощи команды smbmount/mount -t cif. Однако ручное монтирование общего ресурса требует информации для входа, что приводит к проблемам:

• Пользователи не привыкли осуществлять монтирование вручную, так как в Microsoft Windows оно происходит автоматически при входе в систему.
• Для автоматического монтирования общих ресурсов при входе в систему требуется вручную редактировать файл /etc/fstab.

Вы можете избежать этих проблем, установив Pluggable Authentication Module (pam_mount), помогающий реализовать автоматическое монтирование при входе в систему. Однако помните, что модуль pam_mount еще не совсем стабилен, так что при его внедрении следует выделить дополнительное время на тестирование.

Сервисы печати в домене

Почти все дистрибутивы Linux включают Общую систему печати UNIX (CUPS). Поэтому для печати файлов на имеющихся в домене принтерах можно использовать на клиентской стороне CUPS совместно с Samba. Однако следует внимательно рассмотреть следующие вопросы, если вы хотите использовать CUPS в клиентских системах Linux для работы с имеющимися принтерами:

• Интеграция CUPS и Samba. Наиболее важно проверить, входит ли Samba в сервер CUPS.
• Принтеры и аутентификация. Иногда принтеры в домене могут требовать аутентификации до того, как на них можно будет печатать, так как они могут являться общими ресурсами. Однако эта аутентификация приводит к указанию паролей в нескольких файлах конфигурации CUPS. Вы можете избежать этой уязвимости, либо отключив аутентификацию на принтере, либо создав отдельного пользователя только для печати.
• Печать через сервер и напрямую.При помощи CUPS можно использовать серверы печати в домене либо печатать напрямую через сетевой интерфейс принтера. Как правило, если все клиенты в домене используют серверы печати, следует использовать этот подход и для клиентских систем Linux.
• Драйверы CUPS.При выборе принтеров необходимо определить желаемый баланс между поиском подходящих драйверов для устаревших устройств и выбором новых, которые без проблем работают с клиентскими системами Linux.

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

Одно из главных преимуществ Linux — гибкость и свобода выбора. Linux распространяется бесплатно и с открытым исходным кодом, и его можно настраивать — начиная со смены фонового изображения и вплоть до изменений в коде — гораздо шире, чем закрытые операционные системы, подобные Microsoft Windows или Apple Mac OS. Кроме того, Linux предлагает множество возможностей по фиксации функциональности системы для установления и поддержания стандарта.

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

Дистрибутив Linux

Самая важная часть стандартизации — выбор дистрибутива Linux. Если вы выбрали корпоративный дистрибутив Linux от Novell SUSE или Red Hat, то можете выбирать и соответствующие настольные дистрибутивы: Novell SUSE Linux Enterprise Desktop (SLED) 10 и Red Hat Enterprise Linux (RHEL) 5 Desktop (и Novell, и Red Hat являются важнейшими бизнес-партнерами IBM).

При выборе дистрибутива Linux следует учесть следующие критерии:

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

Среда рабочего стола, ее вид и функции

В отличие от других операционных систем, в Linux имеется несколько сред рабочего стола или оконных менеджеров, самые популярные из которых — GNOME и KDE, хотя имеется и ряд других.

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

GNOME и KDE — зрелые продукты, предлагающие все необходимые возможности по настройке настольной системы в плане пиктограмм, наборов приложений, меню; они поддерживают

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

Защита и скрытие ненужных функций

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

Низкоуровневая стандартизация

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

Важно рассмотреть типы файловых систем, такие как ext2, ext3, ext4 и reiserfs, так как они имеют различные характеристики в отношении:

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

Также имеются специальные файловые системы, такие как crypts, которые позволяют шифровать весь раздел для хранения конфиденциальной или личной информации.

Стандартизация на уровне аппаратного обеспечения

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

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

• Тонкий клиент.Это постоянно подключенный мини-ПК с ограниченными возможностями, использующий только базовую операционную систему и пару компонентов отображения, таких как браузер или терминал-серверное клиентское приложение. Бизнес-приложения не выполняются локально. Мини-ПК часто интегрируются в блок с монитором.
• Функциональный клиент.Это по крайней мере периодически подключающаяся к сети клиентская система, на которой размещаются локально установленные приложения, не требующие постоянного сетевого соединения, но время от времени обращающиеся к серверной части для синхронизации и обновления. Хорошие примеры таких клиентских систем — IBM Lotus® Notes® и IBM Lotus Expeditor.
• «Толстый» клиент.Эта клиентская система может длительное время работать отключенной от сети. Часто предусматривается функциональность по получению данных и обновлений по сети.

На рисунке 2 представлено сравнение возможностей различных видов клиентских систем.

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

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

Добавление и замена клиентских систем в сети

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

• Имя хоста.Если новая клиентская система имеет новое имя хоста, то старое имя необходимо удалить из серверных систем. Если новые клиентские системы используют прежнее имя хоста, оцените возможные проблемы — например, в плане управления ресурсами.
• Данные о конфигурации.Конфигурационные файлы необходимо перемещать из старых клиентских систем в новые.
• Персональная деловая информация.Необходимо переносить персональную деловую информацию на новую клиентскую систему.

Обновление операционной системы

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

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

Другой аспект подхода к обновлению — управление сервером обновления клиентских систем. В целом имеется два варианта:

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

Большинство дистрибутивов предлагают средства для упрощения обновления клиентских систем. Примеры среди корпоративных дистрибутивов—Novell ZENworks Linux Management и YaST. В Red Hat можно использовать архитектуру Red Hat Network's satellite architecture и kickstart.

Кроме того, имеются альтернативы с открытым кодом, такие как apt (Advanced Packaging Tool) для Debian или yum (Yellow dog updater, modified) для дистрибутивов, основанных на менеджере пакетов RPM.

Обновление приложений

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

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

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

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

Удаленное администрирование

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

• Упреждающее.Клиентские системы отслеживаются для выявления возможных проблем до того, как они станут приносить вред. Отслеживание статуса клиентской системы может, например, сводиться к проверке свободного дискового пространства, состояния безопасности, выявлению проблем с лицензиями в плане управления ресурсами. Набор продуктов для отслеживания состояния охватывает диапазон от продуктов с открытым исходным кодом, таких как Nagios до корпоративных средств, таких как IBM Tivoli® Monitoring.
• Реагирующее.Клиентские системы администрируются в случае проявления ошибок ОС или приложений. Дистрибутивы Linux предоставляют различные готовые к использованию средства удаленного администрирования. Стандартным является механизм ssh, который гарантирует надежную аутентификацию, в отличие от rsh, rlogin или telnet. При помощи ssh администратор может легко анализировать клиентские системы и применять исправления при помощи запуска скриптов, либо собирать данные по безопасности, состоянию системы и управлению ресурсами. Другие примеры — VNC и FreeNX.

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

Резервное копирование

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

Для реализации резервного копирования существует множество инструментов, в том числе с открытым исходным кодом, такие как Partimage для сохранения и восстановления полных разделов, а также коммерческих решений, таких как IBM Tivoli Storage Manager. Рекомендуется включить реализацию выбранной схемы резервного копирования в пилотный проект.

Цель планирования пилотного проекта по переходу с определенной клиентской системы на Linux — продемонстрировать проверенные методы эффективно управляемого внедрения новых систем в оставшейся части организации. Непосредственно для внедрения клиентских систем вы должны:

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

Методы внедрения

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

• Внедрение на основе образов разделов или дисков.Такие образы можно внедрять при помощи имеющихся корпоративных инструментов или инструментов с открытым исходным кодом, таких как Partimage. Преимущество подхода, основанного на образах — требуется меньше усилий в плане самых разных индивидуальных настроек. Недостаток — все настройки должны разрабатываться после внедрения образа — например, при помощи исполнения специальных скриптов, отражающих нужды различных пользовательских сегментов.
• Внедрение на основе пакетов через инструментарий дистрибутива.Ряд дистрибутивов предлагает механизмы автоматической установки. В Red Hat применяется kickstart, который управляет инсталлятором anaconda на основе файла ответов. Novell предлагает autoyast, основанный на конфигурационном файле, автоматизирующем ответы в процессе инсталляции YaST. Оба инструмента используют пакеты RPM.
  

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

Обновление клиентских систем

Различные подходы к обновлению клиентских систем сводятся к двум методам:

• Обновление, основанное на подготовленных образах клиентских систем.Если вы выбрали процесс обновления на основе образов, то вы должны следить за тем, чтобы образы и клиентские системы своевременно обновлялись. Если всё программное обеспечение для клиентской системы оформлено в RPM, его можно обновлять при помощи методов, соответствующих конкретному дистрибутиву. Иначе вам потребуется затратить ресурсы на написание скриптов и обслуживание по установке необходимых обновлений на клиентах с учетом особенностей конкретных приложений.
• Обновление клиентских систем, основанных на RPM.Клиенты, развертываемые при помощи программ установки с использованием пакетов RPM, обновляются при помощи механизмов, соответствующих дистрибутиву.

Персонализация развернутых клиентских систем

Персонализация может распространяться на различные аспекты системы:

• имя хоста, если оно не присваивается автоматически;
• IP-адрес, если он не присваивается автоматически;
• монтирование конкретных удаленных файловых систем;
• настройку конкретных принтеров;
• настройку конкретных приложений;
• перенос персональной деловой информации.

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

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

Если вас интересуют другие инструменты автоматической миграции с Microsoft Windows на Linux, обратите внимание наVersora Progression Desktop.

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

Об авторах

		Ютта Крейсс (Jutta Kreyss, kreyss@de.ibm.com) — старший ИТ-архитектор в Центре Linux-интеграции IBM Software Group в Бёблингене, Германия (Lab Böblingen). Она занимается переводом заказчиков на клиентские системы Linux с функционально эквивалентным ПО с открытым исходным кодом, а также внедрением открытых клиентских решений на основе Linux в IBM.

		Фрэнк Хаймс — ИТ-архитектор, последние семь лет работающий в немецком отделении IBM по исследованиям и разработке в Бёблингене, Германия ("Lab Böblingen"). В течение последних шести лет он работает в Центре Linux-интеграции (LIC Europe) в IBM Software Group и занимается различными вопросами промежуточного программного обеспечения IBM, связанного с Linux, в том числе интеграцией. Также у него 12-летний опыт работы в области ИТ и электронной промышленности, охватывающий широкий ряд вопросов, от Linux на настольных системах до Linux на мэйнфреймах.