Руководство по миграции на Linux для региональных администраций

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

Уровень сложности: простой

IBM developerWorks, IBM developerWorks, IBM

05.2007

Планирование пилотной миграции

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

Данная глава содержит следующие разделы:

• Разд. 6.1 Изучение паттернов использования компьютеров

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

• Разд. 6.2 Обеспечение функциональной преемственности

  О том, что понимается под термином «функциональная преемственность», и какие существуют способы ее обеспечения в процессе миграции

• Разд. 6.3 Человеческий фактор

  Как правильно спланировать работу с персоналом в переходный период

• Разд. 6.4 Вопросы переобучения

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

6.1 Изучение паттернов использования компьютеров

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

6.1.1 Разделение рабочих мест на функциональные группы

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

Опишем каждую из групп подробнее:

Рабочее место с фиксированными функциями

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

Техническая рабочая станция

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

Рабочая станция делопроизводителя

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

Базовый офис

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

Стандартный офис

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

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

6.1.2 Описание профилей рабочих мест

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

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

6.1.3 Опрос конечных пользователей

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

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

В начало

6.2 Обеспечение функциональной преемственности

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

6.2.1 Приложения, работающие на обеих платформах

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

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

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

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

Сетевые ресурсы, связанные с проектами:

• OpenOffice.org: http://www.openoffice.org
• The GIMP: http: //www.gimp.org
• GAIM: http://gaim.sourceforge.net
• IBM Lotus Sametime® 7.5: http://www-142.ibm.com/software/sw-lotus/products/product3.nsf/wdocs/st75home
• IBM Lotus Notes 7.x http://www.ibm.com/software/sw-lotus/products/product4.nsf/wdocs/linux

Замечание IBM Lotus Sametime и IBM Lotus Notes будут поддерживать родные версии и для Windows, и для Linux, начиная с версий IBM Lotus Sametime 7.5 и IBM Lotus Notes 7.x.

6.2.2 Функциональные эквиваленты служебных приложений

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

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

6.2.3 Веб-приложения

К сожалению, не для всех необходимых приложений можно найти близкие по функциям или переносимые варианты. Приложения для ERP (планирование и управление ресурсами предприятия), CRM (управление взаимоотношениями с клиентами) или средства для организации совместной работы, как правило, имеют Толстую клиентскую часть и не имеют кросс-платформенных вариантов, работающих и под Windows, и под Linux. Как мы можем видеть, производители промышленного ПО не пытаются решить эту проблему путем создания отдельных клиентов для каждой операционной системы, они переходят на использование клиентов, работающих посредством веб-броузеров, ориентируясь на платформо-независимые броузеры.

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

Хорошим примером подобного подхода является пакет Domino Web Access, ранее известный как iNotes. До версии 6.5 iNotes работал только с Internet Explorer и поэтому был доступен только под управлением Windows. Более поздние версии работают с броузером Mozilla, благодаря чему приложение стало кросс-платформенным. Продукты компании SAP являются еще одним примером подобного подхода. Они обеспечивают полнофункциональную клиентскую часть на основе веб-интерфейса и написанных на Java Толстых клиентов, работающих с платформо-независимыми броузерами.

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

6.2.4 Сервер-ориентированная обработка данных

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

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

Можно использовать Windows Terminal Server или Citrix Metaframe, выбирая для них те клиенты, которые работают одновременно и под Windows, и под Linux. Для доступа к собственному терминальному серверу MS Windows из-под Linux можно использовать rdesktop, клиент с открытым кодом, использующий протокол RDP (remote desktop protocol). Найти этот весьма полезный инструмент вы можете по адресу:

http://sourceforge.net/projects/rdesktop/

Citrix поставляет вместе с пакетом MetaFrame Suite ICA клиенты для ряда операционных систем, включая ICA Client для Linux.

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

Новый подход к сервер-ориентированной обработке данных использован фирмой NoMachine при создании сервера NX. Использование этого сервера значительно снижает сетевой трафик как при работе с X-Window, так и при использовании RDP. Сервер NX выпущен под лицензией GPL, и в ближайшее время ожидается появление реализаций клиентов для различных платформ. Дополнительную информацию по NX можно найти на веб-странице по адресу:

http://en.wikipedia.org/wiki/NX_technology

http://www.nomachine.com

В начало

6.3 Человеческий фактор

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

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

Рис. 6.2 демонстрирует один из вариантов изменения отношения персонала к миграции.

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

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

Таким образом, прежде чем начинать миграцию, необходимо сосредоточить внимание на двух важных аспектах:

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

В начало

6.4 Вопросы переобучения

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

6.4.1 Кросс-платформенные приложения помогут отделить переобучение от миграции

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

6.4.2 Сохраняем визуальный интерфейс

Еще один подход, позволяющий облегчить переход на новую систему и, соответственно, минимизировать затраты на переобучение персонала, состоит в том, чтобы максимально сохранить визуальный интерфейс пользовательских приложений и рабочего стола. Вполне можно так настроить Gnome или KDE, что различия в визуальном интерфейсе рабочего стола и в способе запуска приложений по сравнению с рабочим столом Windows Desktop будут минимальными. Существует множество соответствующих свободно распространяемых профилей, которые можно загрузить и донастроить для своих нужд.

Примеры таких профилей можно найти на страницах:

http://www.kde-look.org

http://art.gnome.org

6.4.3 Привычные действия

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

6.4.4 Файловая система: сохранить структуру подкаталогов

Пользователи Windows привыкли к тому, что на верхнем уровне иерархической файловой системы находятся точки монтирования разделов, такие как C:\, D:\ и т.д. В Linux применяются несколько иные соглашения об организации файловой системы. Общепринятые точки монтирования в файловых системах под Linux включают /usr, /home и т.п. После миграции у конечных пользователей могут возникнуть трудности с поиском файлов в новой файловой системе. Чтобы облегчить пользователям процесс перехода к новой иерархии, имеет смысл перенести все содержимое пользовательского каталога My Documents в каталог с таким же названием в домашнем каталоге пользователя /home/user в системе Linux. В каталоге /home/user/My Documents следует сохранить существовавшую в Windows структуру подкаталогов и их содержимое.

6.4.5 До миграции: просто попробуем поработать с Linux

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

http://www.knoppix.com

Что такое живой дистрибутив? Приведем описание со страницы Knoppix:

KNOPPIX представляет собой загрузочный компакт-диск, содержащий набор программного обеспечения GNU/Linux, инструменты для автоматического распознавания аппаратных средств, поддержку большого числа видеокарт и звуковых карт, SCSI и USB устройств и другой периферии. KNOPPIX можно использовать для демонстрации возможностей Linux, как средство обучения, в качестве мощной «аварийной дискеты» или как платформу для запуска демо-версий коммерческого программного обеспечения. Нет необходимости устанавливать что-либо на жесткий диск, примерно 2 ГБ данных находятся на CD в сжатом виде, при этом разархивирование происходит оперативно во время исполнения.

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

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

Теперь пора спуститься с неба на землю и обсудить технические детали процесса перехода от Windows-клиента к Linux-клиенту.

Эта глава содержит следующие разделы:

• Разд. 7.1 Изучение имеющейся информационной среды
• Разд. 7.2 Взаимодействие с имеющимися сетевыми службами
• Разд. 7.3 Стандартизация рабочего стола
• Разд. 7.4 Планирование миграции приложений
• Разд. 7.5 Планирование управления Linux-клиентом
• Разд. 7.6 Сравнение процедуры миграции настольных машин и ноутбуков
• Разд. 7.7 Приложения, не допускающие переноса под Linux
• Разд. 7.8 Развертывание новых клиентов
• Разд. 7.9 Выявление неисправностей и техническая поддержка после миграции

В начало

7.1 Изучение имеющейся информационной среды

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

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

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

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

7.1.1 Оценка общей ситуации

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

Вопросы, которые полезно задать для уточнения общей ситуации:

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

7.1.2 Инвентаризация оборудования

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

В идеальном варианте подобное описание должно делаться автоматически, регулярно. Это позволит иметь историю обновлений оборудования и осуществить единовременный прогон при составлении описания перед миграцией. Технология eGather и Asset Depot, предлагаемые фирмой IBM, могут помочь в этом деле. Их подробное описание содержится в документе IBM Redpaper Using Asset Depot for Inventory Management, который можно найти интернете по адресу:

http://www.redbooks.ibm.com/abstracts/redp3763.html?Open

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

• Какое оборудование используется (производитель, тип, модель)? Если в результате возникает большой, неупорядоченный список, то стоит подумать об объединении части пунктов по какому-либо признаку, который может зависеть от используемой платформы.
• Стандартизовано ли оборудование? Если все машины имеют один и тот же тип, то обеспечение поддержки периферии и переустановка дистрибутивов значительно упрощаются, как в текущей ситуации, так и при переходе на Linux.
• Какие внешние устройства локально подключены к каждому компьютеру, учитывая только те, которые реально используются? Этот список должен включать все принтеры, сканеры, специальные типы клавиатур, необходимые для делового обмена данными и т.п. Он не должен включать оборудование, установленное просто для забавы или потому, что пользователь является важной персоной, и на его столе из-за этого должно стоять что-нибудь особенное.
• Было ли включено требование поддержки Linux в заявку при покупке оборудования?
• Все ли аппаратные средства, установленные на рабочем месте, реально используются в работе? Например, на компьютере может быть установлена звуковая карта, но при этом не установлен драйвер для управления ею, так как на данном рабочем месте не предусмотрено использование звука. В таком случае при установке другой операционной системы поддержка звуковой карты также не потребуется.

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

http://www-306.ibm.com/pc/support/site.wss/MIGR-48NT8D.html

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

7.1.3 Инвентаризация программного обеспечения

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

Вот список ключевых вопросов:

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

7.1.4 Описание форматов данных и их взаимозависимостей

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

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

В эту категорию приложений попадают некоторые почтовые клиенты (например, Lotus Notes) или офисные пакеты (Lotus Smartsuite или Microsoft Office). В процессе сбора информации о текущем положении дел не стоит обсуждать технические детали миграции, следует просто учесть, какие из подобных приложений используются.

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

• Используется ли Microsoft Office? Если да, то какие компоненты и как часто?
• Используются ли макросы в Microsoft Office? Если да, то какие типы макросов и как часто?
• Используется ли Microsoft Outlook? Если да, то какие компоненты и как часто?
• Используется ли Lotus Smartsuite? Если да, то какие компоненты и как часто?
• Используется ли Lotus Notes? Если да, то какие компоненты и как часто?
• Используется ли Microsoft Project? Если да, то какие компоненты и как часто?
• Используется ли Visual Basic для автоматизации действий внутри отдельных приложений или при обмене данными между приложениями?
• Есть ли обмен файлами с внешними организациями? Если да, то как часто и каковы форматы файлов обмена?

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

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

7.1.5 Описание сетевой инфраструктуры

При описании сетевой инфраструктуры следует обратить внимание на следующие моменты:

• Каков тип сетевой инфраструктуры, к которой подключены клиенты?
• Какова топология сети? Следует описать архитектуру сети, включая все виды локальных и удаленных соединений, пропускную способность различных участков и преобразования протоколов.
• Какие типы протоколов установлены и сконфигурированы на машинах клиентов с целью обеспечения доступа к различным компонентам сетевой инфраструктуры.
• Какие серверы функционируют в сети и какие сервисы обеспечивает каждый из них? В результате ответа на этот вопрос должен возникнуть список серверов, как физических, так и логических, и сервисов, которые каждый из них предоставляет клиентам. К сервисам в этом контексте относятся доступ к файлам, печати, DHCP, к веб-данным, приложениям и т.п.
• К каким базам данных должен быть обеспечен доступ и каким образом? Соответственно, должен возникнуть список всех серверов баз данных и типов доступа к ним, таких как собственные клиенты (например, клиент DB2® UDB от IBM), доступ посредством API (например, именованные каналы), очереди сообщений (например, Websphere MQ от IBM) и приложений, обеспечивающих доступ (например, SAP-клиент).
• Используется ли доступ к мэйнфреймам с данного рабочего места и если да, то каким образом? Доступ к мэйнфреймам различного типа может быть обеспечен как специфическими клиентами (например, Personal Communications), так и через веб-интерфейс (например, Host on Demand или Host Publisher) или подключение через соответствующие API (например, HLLAPI).

7.1.6 Описание функций конечных пользователей

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

Вот примерный список вопросов, которые полезно задать:

• Каковы основные функции, выполняемые данным пользователем или группой пользователей?
• Существует ли распределение пользователей «по ролям»? Если существует, то каково определение каждой роли?
• Существуют ли и для каких групп пользователей набор правил, в соответствии с которыми они должны действовать?
• Существуют ли исключения из этих правил и какие?
• Существуют ли специфические пользовательские настройки, которые необходимо перенести в новую систему (например, список ссылок для броузера или фоновые изображения)?
• Требуют ли текущие приложения для своей работы плагинов или cookies?
• Участвуют ли пользователи в выборе программных средств и если участвуют, то как?
• Есть ли у пользователей возможность самостоятельно устанавливать программное обеспечение, размещенное в общем хранилище?
• Существует ли определенная процедура запроса, установки и удаления программного обеспечения?
• Как часто пользователи обращаются в службу технической поддержки, и каковы стандартные параметры предоставления помощи, такие как время отклика, реакция на повторяющиеся запросы, уровень поддержки и т.д.
• Каков уровень подготовки конечных пользователей, имея в виду базовые функции операционной системы?
• Каков уровень подготовки конечных пользователей, использующих более сложные средства, например, офисные приложения?
• Каков уровень подготовки конечных пользователей, работающих с бизнес-приложениями?
• Какие типы внешних устройств (локальных и удаленных) непосредственно используются на данном рабочем месте?

В начало

7.2 Взаимодействие с имеющимися сетевыми службами

Этот раздел посвящен вопросам интеграции Linux-клиента в существующую сетевую инфраструктуру. Естественно, мы рассматриваем тот случай, когда сетевая инфраструктура базируется главным образом на продуктах Microsoft Windows.

7.2.1 Различные типы сетевого окружения

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

В процессе миграции Linux-клиент может оказаться в следующих вариантах сетевого окружения:

• Домен NT4 с Microsoft Windows NT4 PDC (и, возможно, BDC)
• Домен Active Directory с серверами Microsoft Windows 200x AD
• Домен NT4 с Linux/Samba PDC и BDC
• Другие домены, не базирующиеся на продуктах Microsoft Windows

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

Итак, сосредоточимся на двух первых типах окружения (то есть, на чисто Windows-окружении), на это есть по крайней мере две причины:

• Довольно много доменов соответствуют этой модели
• Количество документов, описывающих подключение Linux-клиента к домену Samba и так огромно.

Подсказка Если существует план перевода домена на Samba или AD, следует принять это во внимание, планируя миграцию клиентов. Не стоит дважды переделывать одно и то же.

Samba является самым распространенным инструментом интеграции Linux-клиента в сети Windows. Изначально Samba была UNIX-приложением. Samba обеспечивает обмен данными в сети на основе протокола SMB (Server Message Block). Операционная система Microsoft Windows использует тот же протокол для обеспечения доступа к разделяемым файлам и принтерам. Благодаря этому Linux-клиент, на котором запущены компоненты Samba, интегрируется без каких-либо проблем в домен Windows и получает доступ к общим файлам, службам печати, просмотру сетевых каталогов и т.п.

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

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

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

Аутентификация Linux-клиента в домене Windows нужна по нескольким причинам:

• Linux-клиент должен иметь доступ к сетевым ресурсам, требующим авторизации (сетевые файл-серверы, принтеры и т.п.)
• Пользователям не нужен будет дополнительный пароль для входа в сеть, они будут пользоваться одной комбинацией «имя/пароль»
• Администратору надо будет управлять только одним набором свойств пользователей

Планируя аутентификацию Linux-клиентов в Windows-домене, надо рассмотреть следующие вопросы:

• Для каждого ли клиента будет создан отдельный вход в Windows-домен, или можно использовать утилиту winbind с целью унификации стартового окружения? (Вы можете настроить winbind так, что вход пользователя в Linux-клиент будет автоматически вызывать авторизацию в Windows-домене. В результате этого Linux-клиент становится полноправным членом Windows-домена.)
• Утилита winbind требует аккуратной настойки, есть некоторые особенности, связанные с разделителями.
• Будем ли мы входить в домен NT4 или в домен Active Directory? В последнем случае требуется также использование Kerberos.

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

Используя winbind надо выбрать разумный winbind-разделитель, а именно, символ, который будет отделять имя домена от имени пользователя, поскольку при использовании winbind к учетной записи добавляется еще наименование домена. Например, пользователь Administrator в домене AD6380 под Linux будет иметь имя AD6380+Administrator, в этом случае в качестве winbind-разделителя выбран знак плюс. Следует проверить, не вызовет ли каких-либо проблем в работе приложений появление знака плюс (+) в имени пользователя. Выбор знака плюс в качестве разделителя является лучшим вариантом в большинстве случаев.

Подсказка Как следует протестируйте winbind и winbind-разделитель, убедитесь в правильности настроек до того, как начинать миграцию.

Если аутентификация происходит в домене Active Directory, то кроме Samba должен быть настроен также и Kerberos.

Итак, аутентификацию Linux-клиента в домен Windows обеспечит следующий набор приложений: Samba, Kerberos и winbind.

7.2.3 Использование средств домена для совместного доступа к файлам

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

Монтирование общих каталогов на Linux-клиентах с использованием smbmount или mount -t cifs обеспечивает пользователям других файловых систем свободный доступ к ресурсам. Однако, если ресурс открыт не для всех, то для доступа к нему потребуется имя пользователя и пароль, аналогично тому, как это происходит под Windows. Если ресурс монтируется вручную, то в этом нет проблемы, имя и пароль надо просто ввести. Однако, заметим что:

• Монтирование ресурсов вручную с использованием команды mount может быть неудобно для пользователей. Работая под Windows они привыкли, что все ресурсы монтируются автоматически при входе пользователя в систему.
• Монтирование ресурсов вручную вовсе не является обязательным, существуют пути автоматизировать процедуру и выполнить монтирование при входе в систему, подобно тому, как это делается под Windows. Автоматическое монтирование SMB-разделов можно организовать, включив соответствующие строки в файл /etc/fstab.

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

Существует PAM-модуль (Pluggable Authentication Module) pam mount, который обеспечивает автоматическое монтирование при регистрации. Включая этот модуль в планы миграции, помните, что он еще недостаточно хорошо проработан. Однако других средств автоматического подключения общих ресурсов пока не существует.

Выделите дополнительное время, чтобы всесторонне протестировать работу модуля pam mount на Linux-клиентах, намеченных к миграции. Если все будет работать хорошо, автоматическое монтирование общих ресурсов значительно облегчит вам жизнь.

Подсказка Тщательно протестируйте работу модуля pam_mount, запланируйте время на эту работу.

7.2.3.1 Домашние каталоги и разделяемые ресурсы

При планировании миграции встает вопрос о том, где разместить домашние каталоги пользователей. Весьма соблазнительной кажется возможность создать домашние каталоги в общедоступном разделе, работающем под управлением Windows. Это позволит сделать клиентов более «тонкими».

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

Однако, следует соблюдать осторожность. Некоторые графические системы (главным образом, KDE) создают символьные ссылки или сокеты в домашнем каталоге пользователя. Между тем, одним из известных недостатков файловых систем SMB, работающих под управлением Samba, является невозможность создавать символьные ссылки и сокеты в рамках этих файловых систем. Это означает, что приложения KDE не смогут корректно работать при удаленном монтировании домашних каталогов на ресурсах SMB.

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

7.2.4 Использование сетевых принтеров

Конечно, вполне возможно подключить дополнительные принтеры локально к Linux-клиентам. Однако, это может вызвать неудобства и дополнительные организационные сложности в том случае, если ранее использовались сетевые принтеры. Практически все дистрибутивы Linux сейчас включают систему печати CUPS (Common Unix Printing System), позволяющую при условии, что на клиентской машине установлена Samba, организовать печать на доступные по сети принтеры.

Если планируется, что Linux-клиент будет использовать CUPS для выхода на сетевые принтеры, подключенные внутри Windows-домена, полезно будет рассмотреть следующие вопросы:

• Корректно ли взаимодействуют CUPS и Samba?
• Требует ли доступ к принтеру авторизации? Если да, то пароль должен быть доступен.
• Каковы преимущества использования сервера печати по сравнению с прямой печатью через сетевой интерфейс?
• Поддерживаются ли системой CUPS ваши модели принтеров?

7.2.4.1 Взаимодействие CUPS и Samba

В большинстве дистрибутивов Linux CUPS и Samba взаимодействуют без каких-либо проблем. Тем не менее, это необходимо проверить и, соответственно, при планировании отвести время на проверку.

Наиболее важный момент такой проверки — убедиться, что в CUPS включена поддержка Samba. Информацию о том, как это проверить, можно найти в Разд. 11.7.

7.2.4.2 Принтеры и аутентификация

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

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

7.2.4.3 Принт-сервер или прямая печать?

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

Печать через принт-сервер дает известные преимущества:

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

7.2.4.4 Поддерживает ли CUPS модель/драйвер вашего принтера?

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

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

7.2.5 DHCP и DNS-конфигурация

В большинстве случаев DHCP и DNS домена Windows будут работать безо всяких проблем и с Linux-клиентом. Оба протокола надо один раз правильно настроить, после чего они будут работать, не создавая никаких сложностей для пользователей.

Однако следует соблюдать некоторую осторожность при совместном использовании DHCP и X11. Linux-клиент обычно принимает имя хоста от DHCP. Если X11 стартует до этого, и пользователь зарегистрирован в системе, при запуске графических приложений могут возникнуть проблемы с Xauth.

Подсказка Убедитесь, что имя хоста от DHCP принято Linux-клиентом до старта X11, или используйте графический вход в систему.

7.2.6 Доступ через прокси-сервер

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

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

В начало

7.3 Стандартизация рабочего стола

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

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

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

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

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

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