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

Пилотная миграция

В этой главе будут подробно обсуждаться примеры организации рабочих мест под Linux, эти примеры могут оказаться полезны при планировании любой пилотной миграции. Мы будем обсуждать среду KDE Kiosk, пользовательскую настройку GNOME и создание полноценного самоуправляющегося Linux-клиента на базе Red Hat. Близкие к этим темам вопросы, связанные с автоматизацией, будут обсуждаться также в Прил. C.

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

• Разд. 9.1 Среда KDE Kiosk

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

• Разд. 9.2 Конфигурирование GNOME

  Обсуждаются способы конфигурирования рабочей среды GNOME и возможности утилиты gconftool-2

• Разд. 9.3 Инструменты удаленного доступа

  Обсуждаются методы установки полноценных самоуправляющихся Linux-клиентов на всем предприятии

9.1 Среда KDE Kiosk

В этом разделе будет продемонстрировано, как с помощью пакета KDE Kiosk framework, который включен в KDE3, можно ограничить и зафиксировать функциональность рабочего стола. Мы покажем, каким образом можно приписать те или иные профили пользователям или группам пользователей, пометить элементы конфигурации как неизменяемые, ограничить выбор функций и доступ к ресурсам сети. Это можно выполнить прямым редактированием конфигурационных файлов или используя удобный инструмент с графическим интерфейсом пользователя Kiosk Admin Tool, дополнительную информацию о котором можно найти в сети по адресу:

http://extragear.kde.org/apps/kiosktool

Подробности о том, как в KDE организовано хранение данных пользовательского профиля, можно найти также в Разд. B.3.

9.1.1 Пользовательские профили

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

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

Вы должны сообщить KDE в основном конфигурационном файле /etc/kderc (другим вариантом может быть /usr/share/config/kdeglobals), какие определены профили, и где будет расположен файл, приписывающий профили определенным пользователям. Ниже приведен пример конфигурационного файла, в котором определены два различных пользовательских профиля, содержащие интернационализацию (Английскую и Немецкую[de]), и оба они принадлежат суперпользователю root (ProfileInstallUser=root). Остальные три профиля идентичны.

Пример 9.1.1: Профили и файлы соответствия, заданные в /etc/kderc

[Directories] kioskAdmin=root: profileDirsPrefix=/etc/kde-profile/ userProfileMapFile=/etc/kde-user-profile [Directories-default] ProfileDescription=Default profile ProfileDescription[de]=Standard Profil ProfileInstallUser=root prefixes=/etc/kde-profile/default/ [Directories-ITSO] ProfileDescription=ITSO Test Profile ProfileDescription[de]=ITSO Standard Profil ProfileInstallUser=root prefixes=/etc/kde-profile/ITSO/

Для миграции внутри своей организации IBM Technical Support Organization (ITSO) с использованием KDE Kiosk мы определили пять различных профилей и приписали им имена default, Redbook, ITSO, Designer, Administrator и соответствующие каталоги для конфигураций /etc/kde— prof ile/ [имя профиля ] . Ниже в Табл. 9.1 можно видеть эти профили, которые мы создали для своего тестового варианта миграции, и приписанную каждому профилю роль.

Таблица 9.1: Профили и расшифровка ролей

Профиль	Роль
default	Обычный пользователь, никакой специфической роли
Redbook	Один из авторов Redbook
ITSO	Сотрудник ITSO
Designer	Сотрудник ITSO, выполняющий дизайнерские функции
Administrator	Имеет неограниченный доступ

Следующим шагом мы должны были приписать профили нашим пользователям и группам пользователей. Для этого можно использовать KDE Kiosk Admin Tool с графическим интерфейсом, как показано на Рис. 9.1, редактировать конфигурационный файл (см. Прим. 9.1.2). Дополнительную информацию о KDE Kiosk Admin Tool можно найти в сети по адресу

http://extragear.kde.org/apps/kiosktool

Рис. 9.1: Профили пользователей в окне KDE Kiosk Admin Tool

Пользователю в KDE Kiosk можно приписать более, чем одну роль, например, можно приписать

amelie=Administrator,Designer

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

partner=Partner,Redbook

для группы partner, при этом профиль Partner будет иметь больший приоритет.

Пример 9.1.2: Установка соответствия между профилями и пользователями в файле /etc/kde-user-profile

[General] groups=itso,redbook,users [Groups] itso=ITSO redbook=Redbook users=default [Users] anette=Designer root=Administrator

Другой интересный случай — когда пользователь, не включенный в раздел Пользователи (Users), входит в состав различных UNIX-групп, внесенных в различные профили в разделе Группы (Groups). В этом случае ранее зарегистрированные профили будут иметь более высокий приоритет. Последнее, но не менее важное: если пользователь включен в раздел Пользователи (Users), только профили этой записи принимаются во внимание (то есть пользователи, являющиеся членами UNIX-групп и включенные в профайл в этом случае роли не играют).

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

Хорошим свойством Kiosk Admin Tool является возможность его удаленной конфигурации. На Рис. 9.2 показано, как можно сопоставить локальные каталоги и удаленные (при этом вы имеете возможность изменить базовый URL). Файлы пересылаются при помощи протокола SSH с обычной семантикой типа [fish://] или каким-либо другим сетевым протоколом, поддерживаемым KDE.

Рис. 9.2: Удаленное конфигурирование при помощи KDE Kiosk Admin Tool

9.1.2 Опции блокировки

Рассмотрим, какие опции доступны для настройки в среде KDE Kiosk. Опции общей конфигурации:

• Отключить контекстное меню оконного менеджера (Disable Window Manager context menu) (Alt-F3)
• Отключить закладки (Disable Bookmarks)
• Отключить все задачи и приложения, которые требуют права суперпользователя (Disable all tasks and applications that require root access)
• Отключить доступ к командной строке (Disable access to a command shell)
• Отключить возможность завершения сеанса (Disable Logout option)
• Отключить возможность блокировки экрана (Disable Lock Screen option)
• Отключить пункт «Выполнить» (Disable «Run Command» option) (Alt-F2)
• Отключить перемещение панелей инструментов (Disable toolbar moving)
• Отключить запуск произвольных .desktop файлов (Disable execution of arbitrary .desktop files)
• Отключить запуск второго сеанса X (Disable starting of a second X session)
• Отключить историю строки ввода (Disable input line history)

Рис. 9.3: Настройка опций общей конфигурации в Kiosk Admin Tool

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

• Опции конфигурации значков на рабочем столе
  • Заблокировать настойки Рабочего стола (Lock down Desktop Settings)
  • Отключить контекстные меню (Disable context menus)
  • Заблокировать все значки Рабочего стола (Lock down all Desktop icons)
• Опции конфигурации фона рабочего стола
  • Заблокировать фон рабочего стола (Lock down Desktop Background Settings)
• Опции конфигурации хранителя экрана
  • Заблокировать хранитель экрана (Lock down Screen Saver Settings)
  • Отключить хранители экрана, использующие OpenGL (Disable OpenGL-based Screen Savers)
  • Только безопасные хранители экрана (Discreet Screen Savers Only)
• Опции конфигурации меню KDE
  • Отключить все задачи и приложения, которые требуют права суперпользователя (Disable all tasks and applications that require root access)
  • Отключить возможность изменения меню (Disable menu editing)
• Настройка конфигурации темы рабочего стола
  • Заблокировать настройку стиля (Lock down Style Settings)
  • Заблокировать настройку цветов (Lock down Color Settings)
  • Заблокировать настройки шрифтов (Lock down Font Settings)
  • Заблокировать настройки оформления окон (Lock down Window Decoration Settings)

Рис. 9.4: Настройка конфигурации темы рабочего стола в Kiosk Admin Tool

• Настройка конфигурации KDE-панели
  • Заблокировать панель (Lock down panel)
  • Отключить контекстные меню (Disable Context Menus)
• Настройка прокси-сервера
  • Заблокировать настойки прокси-сервера (Lock down Proxy Settings)

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

• Настройка конфигурации Konqueror
  • Отключить «Свойства» в контекстном меню (Disable Properties in context menu)
  • Отключить «Открыть с помощью» (Disable Open With action)
  • Отключить «Открыть в новой вкладке» (Open in New Tab action)
  • Отключить просмотр файлов вне домашнего каталога (Disable file browsing outside home directory)
• Настройка пунктов меню
  • Отключить Файл —> Создать (Disable File —> New)
  • Отключить Файл —> Открыть (Disable File —> Open)
  • Отключить Файл —> Открыть недавние (Disable File —> Open Recent)
  • Отключить Справка —> О <Имя программы> (Help —> About )
  • Отключить Справка —> О KDE (Help —> About KDE)

Рис. 9.5: Настройка ограничений на действия с помощью Kiosk Admin Tool

9.1.3 Неизменяемые элементы конфигурационных файлов

Как мы видели выше, создать профиль, ограничивающий действия пользователя, с помощью Kiosk Admin Tool достаточно просто. Но как будет работать механизм ограничения? Начиная с KDE3, конфигурационные опции могут быть помечены как неизменяемые. Это означает, что после того как значение такой опции установлено, оно не может быть изменено ни посредством KConfig, ни при помощи пользовательских настроек в $KDEHOME (обычно файл $HOME/.kde).

Как неизменяемые могут быть помечены отдельные элементы конфигурационного файла, группы элементов или все элементы, начиная с какого-то и до конца файла. Для этого перед элементом должен быть добавлен знак [$i] в подходящем месте (см. Прим. 9.1.3). Если KDE не имеет прав на запись по отношению к пользовательским конфигурационным файлам, они автоматически будут рассматриваться как неизменяемые, и пользователь получит предупреждение об этом факте. Если вы не хотите, чтобы предупреждение выводилось, добавьте опцию warn unwritable config=false в секцию ограничений на действия в KDE в файле /etc/kderc (или в файле kdeglobals на глобальном или пользовательском уровне, либо на уровне профиля). Как мы уже отмечали выше, просто запрет на запись в пользовательские конфигурационные файлы является недостаточным механизмом блокирования изменений, так как пользователь теоретически может переименовать эти файлы и создать новые с возможностью записи. Однако, ограничения, заложенные в операционную систему, дополняют более сложный и изощренный механизм блокирования, присущий среде KDE Kiosk.

9.1.4 Ограничения на действия

Рассматривая возможности Kiosk Admin Tool, мы уже перечислили те ограничения на действия, которые можно определить на уровне профиля. Эти изменения будут записаны в файле kdeglobals в секции KDE Action Restrictions. Ниже можно видеть, какого рода записи появились в конфигурационном файле после введения ограничений на действия для нашей ITSO группы.

Существует множество опций, которые можно добавить в эту секцию, в дальнейшем их число увеличится по мере увеличения числа приложений, использующих механизм KDE Kiosk. Вы можете использовать опции глобального уровня для ограничения действий меню и панели инструментов (например, action/file new), а также для ограничения действий:

• Системы печати (print/options)

Пример 9.1.3: Блокирование элементов конфигурационного файла с использованием знака [$i]

[ScreenSaver] Enabled[$i]=true [Desktop0][$i] Wallpaper=/usr/share/backgrounds/images/default.png WallpaperMode=Scaled [$i] [Applet_1] ConfigFile=kminipagerappletrc DesktopFile=minipagerapplet.desktop FreeSpace=0 WidthForHeightHint=92

Пример 9.1.4: Ограничения на действия в файле /etc/kde-profile/itso/share/config/kdeglobals

[KDE Action Restrictions][$i] action/kdesktop_rmb=false action/kicker_rmb=false action/menuedit=false editable_desktop_icons=false editable_system_desktop_icons=false movable_toolbars=false run_command=fals user/root=false

• Заставки экрана (opengl_screensavers)
• Рабочего окружения (logout, lock_screen, movable_toolbars, start_new_session)

Существуют также опции для ограничения действий стандартных KDE-программ:

• Konqueror (action/openintab) и KDesktop
• KWin (action/kwin rmb)
• Kicker (action/kicker rmb)
• Konsole (action/show_menubar)

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

% dcop kmail qt objects | grep KActionCollection | cut -d '/' -f 3 % dcop kmail kmail-mainwindow actions

Существуют опции, запрещающие запуск приложений, требующих определенных полномочий пользователя, например, опция user/root=false запрещает запуск всех приложений, которые требуют полномочий суперпользователя. Если вы интересуетесь тонкостями настройки ограничений на действия, обратитесь к руководству по KDE Kiosk на странице:

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdelibs/kdecore/README.kiosk

9.1.5 Ограничения на URL

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

Пример 9.1.5: Ограничения на URL: полный синтаксис

[KDE URL Restrictions] rule_count= rule_1=,,,,,/ ,, ... rule_N=,,,,,/ ,,

Конкретные варианты использования этого механизмы вы можете видеть ниже. В первой части показано, как с помощью ограничения на действия запретить диалогу выбора файлов KDE выходить за пределы домашнего каталога. Первая строка запрещает просмотр каких-либо каталогов локальной файловой системы, вторая разрешает просмотр домашнего ($HOME) каталога. Вы могли заметить, что KDE раскрывает значение переменной окружения $HOME. Обычно мы должны помещать знак [$e] после имени переменной, или даже [$ei], для того чтобы предотвратить замену имени переменной окружения на ее актуальное значение, но в данном случае этого не требуется. Во второй части показано, как позволить пользователю открывать файлы в каталогах $HOME и $TMP, но запретить доступ к другим каталогам локальной файловой системы (файлы в интернете, тем не менее, остаются доступны).

Пример 9.1.6: Ограничения на URL: простые примеры

[KDE URL Restrictions][$i] rule_count=2 rule_1=list,,,,file,,,false rule_2=list,,,,file,,$HOME,true [KDE URL Restrictions][$i] rule_count=3 rule_1=open,,,,file,,,false rule_2=open,,,,file,,$HOME,true rule_3=open,,,,file,,$TMP,true

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

9.1.6 Ограничения на ресурсы

Последний вид ограничений, которые мы будем обсуждать — это ограничения на ресурсы KDE. Такое ограничение делает для пользователя невозможным подменить файлы, расположенные в каталоге $KDEHOME/share (где большинство приложений KDE держат свои ресурсы типа HTML-документации, звуковых файлов и т.д.) файлами, расположенными вне этого каталога. В первой части приведенного ниже примера мы запрещаем это для всех ресурсов, во второй вводится более тонкое ограничение: запрещается подмена звуковых файлов, фона и файлов локализации.

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

• date (share/data)
• html (share/doc/HTML)

Пример 9.1.7: Общие ограничения на KDE-ресурсы

[KDE Resource Restrictions][$i] all=fals [KDE Resource Restrictions][$i] sound=false locale=false wallpaper=false

• icon (share/icon)
• config (share/config)
• pixmap (share/pixmaps)
• apps (share/applnk)
• xdgdata-apps (share/applications)
• sound (share/sound)
• locale (share/locale)
• services (share/services)
• servicetypes (share/servicetypes)
• mime (share/mimelnk)
• wallpaper (share/wallpaper)
• templates (share/templates)
• exe (share/bin)
• lib (share/lib)
• all (share/)
• data_<приложения> (share/apps/<имя_приложения>)

Следует заметить, что имя каталога не всегда совпадает с именем элемента в конфигурационном файле, иногда из-за этого возникают ошибки. Ниже приведен пример, в котором показано, как использовать секции Control Module и Custom Restriction в файле kdeglobals.

Пример 9.1.8: Дополнительные опции ограничения на ресурсы KDE

[KDE Control Module Restrictions] kde-background.desktop=false kde-colors.desktop=false kde-fonts.desktop=false kde-kwindecoration.desktop=false kde-proxy.desktop=false kde-style.desktop=false [KDE Custom Restrictions] 9.2 Конфигурирование GNOME В этом разделе мы покажем, как настроить рабочий стол GNOME для нужд работника, функции которого относятся к группе «Базовый Офис». Будет обеспечена работы приложений x3270 Mozilla Подробности того, как в GNOME организовано хранение данных пользовательского профиля можно найти также в Прил. B. Структура каталогов будет соответствовать папкам, каталоги не будут размещены централизованно в одном месте, поскольку Linux — система многопользовательская, и каждый имеет свой домашний каталог. Каталог рабочего стола GNOME скрыт и имеет имя $HOME/.gnome2. Мы будем работать со структурой рабочего стола, сохраняя данные в подкаталоге $HOME/.gnome2/Business Applications Работа с иконками организована также, как и в KDE. Это означает, что вы имеете дела с текстовыми файлами в формате ASCII. Вы можете сохранить их в каталоге $HOME/. gnome2 для дальнейшего использования на рабочем столе. 9.2.1 Конфигурация в GNOME Настройка конфигурации в GNOME — дело значительно более сложное по сравнению с настройкой конфигурации KDE, где для хранения конфигурации используются простые текстовые файлы в формате ASCII. Рабочий стол под управлением GNOME использует специальную базу данных, элементы которой хранятся в файлах в формате XML (Extensible Markup Language). Таких файлов множество и все они хранятся в каталоге /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/, если мы рассматриваем Novell Linux Desktop (для Red Hat Workstation в этом пути нужно заменить /etc/opt/gnome на /etc). Ниже приведен список подкаталогов этого каталога, содержащих различные элементы настроек рабочего окружения GNOME: /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/accessibility /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/applications /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/background /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/file_views /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/font_rendering /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/interface /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/lockdown /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/peripherals /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/sound /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/thumbnailers /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/typing_break /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/url-handlers Внутри каждого из этих подкаталогов находится файл с именем %gconf.xml. Ниже приведен пример такого файла Пример 9.2.1: Файл %gconf.xml /etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/lockdown schema="/schemas/desktop/gnome/lockdown/disable_print_setup"/> schema="/schemas/desktop/gnome/lockdown/disable_printing"/> schema="/schemas/desktop/gnome/lockdown/disable_save_to_disk"/> schema="/schemas/desktop/gnome/lockdown/disable_command_line"/> 9.2.2 Инструмент конфигурирования gconftool-2 Менеджер рабочего стола GNOME снабжен инструментом, который называется gconftool-2. Вы можете вызывать его из командной строки, для того, чтобы вручную вносить соответствующие изменения в XML-файлы. Вы можете объявить некоторые значения обязательными (mandatory), тогда пользователи не смогут их изменить и именно эти значения будут использоваться при создании новых пользователей в системе. Замечание Каждый из приведенных ниже примеров представляет собой командную строку. Эти примеры работают с GNOME2.6. Эта команда меняет цвет фона на принятый по умолчанию и делает это значение обязательным: gconftool-2 —-direct -—config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory —-type string —-set /desktop/gnome/background/picture_filename /usr/share/backgrounds/images/corporate_logo.jpg Второй пример ограничивает до двух число рабочих областей пользователя, таким образом пользователь может обновременно запускать только два приложения. В каждой рабочей области работает только одно приложение: gconftool-2 -—direct —-config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory -—type int -—set /apps/metacity/general/num_workspaces 2 Число конфигурационных опций, которые контролирует gconftool-2, очень велико и мы не можем их все привести в этой книге, но вы можете набрать приведенную ниже команду и увидеть все параметры, установленные для текущего рабочего стола: gconftool-2 -R /desktop Хотя мы не можем охватить все опции gconftool-2, мы перечислим все опции, которые мы использовали для настроек своего рабочего стола и дадим пояснения по их настройке. Чтобы увидеть список всех опций, определенных для рабочего стола по умолчанию, наберите команду: gconftool-2 -R /apps/panel Можно вывести не все значения настроек, а только те, которые относятся к определенной области. Следующая команда выводит только значения глобальных для панели GNOME переменных: gconftool-2 -R /apps/panel/global Ниже приведен листинг, котороый выдает эта команда: screenshot_key = Print panel_hide_delay = 500 enable_animations = true drawer_autoclose = true keep_menus_in_memory = true window_screenshot_key = Print panel_minimized_size = 3 tooltips_enabled = true menu_key = F1 confirm_panel_remove = true panel_animation_speed = panel-speed-medium highlight_launchers_on_mouseover = true run_key = F2 enable_key_bindings = true panel_show_delay = 300 Эти значения можно редактировать при помощи gconftool-2. Например, приведенная ниже команда отключает run_key: gconftool-2 -—direct -—config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory —-type bool -—set /apps/panel/global/run_key false Если мы заново просмотрим значения глобальных параметров, то увидим, что run key отключен. Команда gconftool-2 -R /apps/panel/global выдает листинг: screenshot_key = Print panel_hide_delay = 500 enable_animations = true drawer_autoclose = true keep_menus_in_memory = true window_screenshot_key = Print panel_minimized_size = 3 tooltips_enabled = true menu_key = F1 confirm_panel_remove = true panel_animation_speed = panel-speed-medium run_key = false highlight_launchers_on_mouseover = true enable_key_bindings = true panel_show_delay = 300 Тепрь run_key не доступен для всех пользователей, и они не могут изменить эту установку. Причина этого в том, что мы использовали каталог gconf.xml.mandatory. Можно вместо mandatory-каталога использовать каталог gconf.xml.default, тогда значение будет приписываться всем новым пользователям, но его можно будет впоследствии изменить. Безусловно, gconftool-2 весьма полезный и удобный инструмент, однако существует инструмент с графическим интерфейсом, который называется gconf-editor. Этот инструмент обеспечивает графический интерфейс пользователя для доступа к GNOME XML-файлам, позволяет просматривать и изменять настройки. Он полезен, особенно при ознакомлении с содержанием различных XML-схем, которые используются при конфигурировании GNOME. 9.2.3 Ограничения в рабочем окружении пользователя Работа с иконками в GNOME организована также, как и в KDE. Единственное отличие — это структура каталогов рабочего стола GNOME. Когда создается новый пользователь, то каталоги рабочего стола не создаются автоматически до того момента, пока он в первый раз не зарегистрируется в системе. Если же создавать эти каталоги вручную, то к ним не будут применены установки по умолчанию. mkdir /home/fiona/.gnome2 mkdir /home/fiona/.gnome2/Business Applications Структура каталогов для пользователя fiona должна быть следующая: /home/fiona/.gnome2 /home/fiona/.gnome2/Business Applications/x3270 /home/fiona/.gnome2/Business Applications/mozilla Мы хотим, чтобы пользователь имел такие права доступа, чтобы мог запускать приложения, но не мог изменять их. Также мы хотим, чтобы он не имел возможности делать изменения на рабочем столе. Для этого изменим принадлежность каталога и права доступа: chown -R /home//.gnome2 chmod -R 755 /home//.gnome2 Такая установка позволяет пользователю запускать приложения, связанные с иконками на рабочем столе, но не позволяет делать в них изменения. Это не слишком надежный способ защиты, поскольку он не помешает пользователю fiona переименовать каталог /home/fiona/.gnome2 и создать другой рабочий каталог со своими свойствами. 9.2.4 Настройка внешнего вида рабочего стола В этом разделе мы рассмотрим методы настройки внешнего вида рабочего стола GNOME с использованием графической программы Центр Управления GNOME. Замечание В процессе создания персонализированного окружения для GNOME с использованием графического интерфейса в домашнем каталоге пользователя создается подмножество базы данных Gconf. Чтобы открыть диалог для настроек, используйте в Nautilus URL preferences:// Рис. 9.6: Настройка Thinkpad в Центре управления GNOME Другой путь — выбрать пункт Параметры в Главном меню или набрать команду gnome-control-center в командной строке. Центр управления GNOME позволяет просматривать огромное число настроек. Например, на самом верхнем уровне будет предложен следующий список установок: Дополнительные параметры Специальные возможности Фон рабочего стола Мышь Клавиатура Комбинации клавиш клавиатуры Меню и панели инструментов Шрифт Хранитель экрана Звук Тема Окна Разрешение экрана Удаленный рабочий стол Смена пароля Сменные накопители Сервис Прокси Центр управления GNOME допускает расширение своих функций, то есть, в него можно добавить окно, которое будет отвечать за настойки внешнего вида нового приложения. На Рис. 9.6 вы можете видеть окно настойки программы Thinkpad, которое было добавлено в центр управления. Для этого был использован пакет configure-thinkpad, который можно загрузить со страницы в интернете по адресу: http://tpctl.sourceforge.net/ restrict_file_browsing=true

9.1.7 Ограничения в среде KDE Kiosk

Запрет запуска команды и доступа к командной оболочке могут быть весьма полезны, если речь идет об общедоступном терминале. Однако получить доступ к командному интерпретатору shell можно и при помощи броузера Mozilla, который не учитывает настройки среды Kiosk. Отключая возможность завершения сеанса, не забудьте также отключить возможность остановки X-сервера при помощи комбинации клавиш Ctrl+Alt+Backspace или перезагрузки машины при помощи комбинации Ctrl+Alt+Delete (отредактировав файл /etc/inittab), в противном случае ваши настройки окажутся совершенно бесполезны. Существует множество нюансов, которые необходимо учесть, чтобы обезопасить систему от несанкционированных действий, поскольку многие приложения и подсистемы Linux не учитывают настройки среды KDE Kiosk.

9.1.8 Подведем итоги

Мы надеемся, что после ознакомления с предыдущими разделами у вас появилось понимание того, какими возможностями обладает среда KDE Kiosk, и вы сможете эффективно использовать ее в предстоящей миграции на Linux-клиенты. Однако мы хотим предостеречь вас от излишнего увлечения конфигурированием KDE Kiosk. Чем больше вы меняете настройки, тем больше усилий вам потребуется для того, чтобы поддерживать их в дальнейшем. Если у вас есть опыт работы с консолью управления Microsoft (Microsoft Management Console, MMC), вам должно быть понятно, о чем идет речь. Профили Windows отличаются одной неприятной особенностью, их нельзя переносить покомпонентно, то есть вам придется полностью воспроизводить старые установки в новом окружении; KDE (и GNOME) предлагают очень широкие (и постоянно расширяющиеся) возможности выбора конфигурационных параметров.

9.3 Инструменты удаленного доступа

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

9.3.1 Удаленный доступ

Базовый удаленный доступ состоит в том, что вся логика приложения запускается на сервере, а на рабочей станции остается только интерфейс пользователя. Примерами реализации такого подхода могут служить Virtual Network Computing (VNC), NoMachine NX и даже rdesktop, Linux-клиент для серверов RDP фирмы Microsof. Надо иметь в виду, что такой способ доступа требует значительных сетевых ресурсов, и поэтому его не используют в качестве стандартного для текущей работы, он применяется для удаленной диагностики, удаленной поддержки пользователя, при необходимости доступа на рабочую станцию с удаленного рабочего места.

9.3.2 Тонкий клиент

Если функции, выполняемые на рабочей станции, соответствуют типу Тонкий клиент, такая рабочая станция (это может быть бездисковая или обычная станция) допускает загрузку с удаленного сервера. В этом случае основные приложения запускаются на сервере, что облегчает их обновление и сопровождение. Пользовательские данные также хранятся на сервере, работа с ними происходит однотипно со всех рабочих станций. В зависимости от реализации этот тип доступа может требовать больше или меньше сетевых ресурсов, но в целом от сети требуется хорошая пропускная способность. Примерами Тонких клиентов могут служить Linux Terminal Server Project (http://www.ltsp.org) и различные варианты Тонких клиентов фирмы Neoware, Inc. (http://www.neoware.com).

9.3.3 Перемещение приложений

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

Подобный механизм удаленного выполнения может применяться и для Windows-приложений, для этого используются такие пакеты как Sun Secure Global Desktop Software (ранее известный как Tarantella) или Microsoft Terminal Server. Эти пакеты полезны в том случае, когда существуют приложения, не допускающие миграции на Linux.

9.3.4 Мультитерминальная обработка данных

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

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

Практика использования мультитерминальной обработки данных сравнительно новая, но она перспективна, более подробно о ней можно прочитать, например, в издании Linux Client Migration Cookbook, Practical Planning and Implementation Guide for Migrating to Desktop Linux:

http://www.redbooks.ibm.com/redpieces/abstracts/sg246380.html

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

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

• Разд. 10.1 Пример миграции клиента
• Разд. 10.2 Детальный план миграции
• Разд. 10.3 Процесс миграции

10.1 Пример миграции клиента

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

10.1.1 Описание паттернов использования клиента

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

• Это была рабочая станция в домене NT4
• Доступ к локальной сети и интернету осуществлялся с использованием Microsoft Internet Explorer
• Как средство создания форматированного текста применялся Adobe FrameMaker
• Для создания и редактирования образов экрана использовался Paint Shop Pro
• Печать шла через сетевой принтер
• Для обмена почтовыми сообщениями использовался Outlook в сочетании с Microsoft Exchange

На клиентской машине была установлена операционная система Windows 2000 с Service Pack 4. При миграции на Linux-клиент использовался дистрибутив Red Hat Desktop.

10.1.2 Определение наиболее существенных приложений и потребностей в интеграции

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

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

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

10.2 Детальный план миграции

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

Выше мы описали рабочее место сотрудника ITSO. Теперь составим план работы по переводу этого рабочего места под управление Linux.

10.2.1 Какого типа этот клиент?

Рабочая станция сотрудника ITSO может быть отнесена к функциональной группе «Базовый офис» или «Стандартный офис», определенных в Разд. 6.1.1. Так как пользователь в основном занимается разработкой технической документации с использованием FrameMaker и при этом интенсивно пользуется веб-броузером для поиска необходимой информации в интернете, то по весу он принадлежит скорее к Толстым клиентам, если пользоваться терминологией Разд. 7.4.2.

10.2.2 Какое выбрать графическое окружение?

Важным вопросом является выбор графического окружения для нашего клиента. Варианты выбора обсуждались в Разд. 7.3.2.

Оба рассмотренных там варианта в целом удовлетворяют требованиям. Но в дистрибутивах Red Hat менеджером рабочего стола по умолчанию является GNOME, поэтому мы остановились на нем с целью упростить процедуру миграции. В дистрибутив Red Hat Desktop 4 включена версия GNOME 2.8.

10.2.3 Какое аппаратное обеспечение используется?

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

В нашем случае к компьютеру не подключено никакой периферии, печать и другие ресурсы доступны посредством локальной сети.

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

10.2.4 План замены программного обеспечения

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

Таблица 10.1: Описание аппаратного обеспечения

Компоненты	Описание
Модель PC	IBM Netvista Type 6759
Процессор	Intel Pentium® III 866 MHz
Чипсет	i810 integrated
Видео-карта	i810
Звуковая карта	i810
Устройство чтения CD	CD-ROM 24x IDE
Флоппи-дисковод	3,5"floppy drive
Жесткий диск	IDE Harddisk 40 GB

Таблица 10.2: Схема замены приложений при миграции клиента

Приложение под Windows	Приложение под Linux
Microsoft Internet Explorer	Mozilla Firefox
Microsoft Outlook	Novell Evolution с Novell Connector для Exchange
Windows Explorer	Nautilus
WinZip	FileRoller
ICQ	Gaim
Microsoft Word	OpenOffice.org Writer
Microsoft Excel	OpenOffice.org Calc
Microsoft Powerpoint	OpenOffice.org Impress
Adobe Reader	Acrobat Reader для Linux
Adobe FrameMaker	Adobe FrameMaker (на Windows Terminal Services)
Jasc Paint Shop Pro	GIMP

10.2.5 Подключение к сети Windows

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

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

В нашем случае использовались имена:

• Domain name = ITSOAUSNT
• Primary domain controller = ITSONT00
• Backup domain controllers = ITSONT01,ITSONT02,ITSONT03
• User name(s) for residents = ausresxx

Далее для интеграции Linux-клиента в локальную сеть были использованы методы, подробно описанные в Разд. 7.2 и Гл. 11.

10.3 Процесс миграции

В этом разделе обсуждается процедура выполнения миграции.

10.3.1 Выполнение базовой инсталляции

Первым шагом является базовая установка операционной системы с дистрибутива. В нашем случае использовался дистрибутив Red Hat Desktop, представляющий собой набор из четырех CD. Некоторые специальные пакеты были получены из интернета с использованием RHN. А именно, мы скачали пакеты, содержащие ПО независимых производителей, такое как Acrobat Reader и Real Player, а также набор высококачественных шрифтов truetype производства фирмы AGFA.

Во время установки мы приняли предложенный по умолчанию инсталляционной программой выбор пакетов прикладных программ. Программа установки Anaconda фирмы Red Hat отработала на нашем оборудовании без каких-либо проблем. Программа тестирования аппаратного обеспечения, kudzu, также отработала успешно, все компоненты были определены правильно. Нужные модули для видео и звуковой карты были загружены. Также был загружен драйвер сетевой карты и в конце установки был подключен доступ к сети, при этом система успешно получила необходимую информацию от DHCP-сервера в сети ITSO. Сервис разрешения имен отработал нормально, без каких-либо дополнительных настроек.

10.3.1.1 Установление удаленного доступа администратора с использованием VNC

После того как установка была завершена, мы изменили настройки на нашем клиенте, чтобы иметь возможность удаленного администрирования с использованием VNC. Сначала следует проверить, что ssh демон запущен, и что посредством VNC будет доступно полноценное рабочее окружение. Для этого, войдя с полномочиями суперпользователя, надо внести изменения в файл $HOME/ . vnc/xstartup как показано в примере приведенном ниже.

Пример 10.3.1: Подключение VNC-соединения

#!/bin/sh # Uncomment the following two lines for normal desktop: unset SESSION_MANAGER exec /etc/X11/xinit/xinitrc .....

Также необходимо включить Xdmcp в файле /etc/X11/gdm/gdm.conf и задать установки сессии в файле /etc/sysconfig/vncservers. VNC-сервер запускается командой

service vncserver start

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

Важно VNC — это мощное средство, его надо использовать с осторожностью. Оно позволяет использовать локальный X-сервер практически из любого места локальной сети. Можно ограничить доступ к рабочей станции, внеся соответствующие изменения в файлы /etc/hosts.allow или /etc/hosts.deny.

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

Следующим шагом нашей миграции будет подключение к сетевым сервисам Windows. В нашем случае имеются серверы под управлением Windows NT и Windows 2000, поэтому мы может следовать инструкциям, изложенным в Гл. 11.

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

Ниже показано, какие изменения для этого надо внести в файл /etc/samba/smb.conf.

Пример 10.3.2: Изменения, вносимые в файл smb.conf для запуска winbind

[global] workgroup = ITSOAUSNT security = domain password server = ITSONT00,ITSONT01,ITSONT02,ITSONT03 ... ... winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%D+%U template shell = /bin/bash

10.3.2 Интеграция с существующими сетевыми сервисами

Итак, на стадии подготовки мы запустили на клиентской стороне демон winbind, поэтому набрав команду wbinfo -u, мы должны увидеть список пользователей домена Windows. Но для того чтобы это сработало, наш Linux-клиент должен быть зарегистрирован в домене Windows, поскольку до тех пор пока для клиента нет учетной записи, он не может получить доступ через winbind. Для того чтобы зарегистрироваться в домене, нужно выполнить команду:

net join -a ITSOAUSNT -U administrator

Важно He забудьте зарегистрироваться в домене, общий формат команды net join -a . Эта команда создает учетную запись на контроллере домена и обеспечивает Linux-клиенту SID для авторизации.

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

Сначала внесем изменения в файл nsswitch . conf, что позволит установить соответствие между пользователями и группами Windows и пользователями Linux (подробнее см. в Разд. 11.2).

Пример 10.3.3: Изменения в фйле etc/nsswitch.conf

passwd: files winbind group: files winbind

Для проверки можно набрать команду getent passwd, должен появиться список всех пользователей с корректными идентификаторами uid и gid.

Теперь для того чтобы процесс авторизации заработал, необходимо задействовать два PAM-модуля (подробнее об этом в Разд. 11.4.1).

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

Мы должны включить модули pam_winbind и pam_smb_auth, которые обеспечат пользователям возможность авторизации в домене ITSOAUSNT. Для этого отредактируем файл /etc/pam.d/system_auth, как показано ниже

Пример 10.3.4: Изменения в файле /etc/pam.d/system_auth

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_winbind.so ........................

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

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

Итак, добавляем следующие строки в файл /etc/pam.d/system_auth:
Пример 10.3.5: Добавление модуля pam_mkhomedir в файл /etc/pam.d/system-auth

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_winbind.so .................. session optional /lib/security/$ISA/pam_mkhomedir skel=/etc/skel umask=0022

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

Для входа в систему мы использовали ID:

ITSOAUSNT+AUSRES06

В общем виде формат имени для регистрации выглядит так:

<имя_домена:разделитель:имя_пользователя>

В нашем случае в качестве разделителя был использован знак <+>.

К сожалению, в стандартной установке GNOME нет возможности ссылаться на ID пользователя без доменного имени, например, иконка домашнего каталога пользователя будет иметь название ITSOAUSNT+AUSRES06.

10.3.2.1 Монтирование общедоступных каталогов Windows

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

Пример 10.3.6: Файл /root/.credentials с параметрами пользователя для монтирования удаленных каталогов

username = ausres06 password = password domain = itsoausnt

Правильным подходом будет включить процедуру монтирования удаленных каталогов в /etc/fstab, с тем чтобы удаленные каталоги монтировались одновременно с монтированием локальных файловых систем. Ниже приведен пример монтирования каталогов с файловой системой типа smbfs в файле /etc/fstab.

Пример 10.3.7: Монтирование удаленых каталогов в /etc/fstab

/dev/hda1 / reiserfs acl,user_xattr 11 /dev/hda5 /scr auto noauto,user 00 /dev/hda2 swap swap pri=42 00 ...... /dev/fd0 /media/floppy subfs fs=floppyfss,procuid,nodev,nosuid,sync 0 0 //itsont05/data /shares/data_g smbfs credentials=/root/.credentials 0 0

Этот прием хорошо работает во всех случаях, кроме тех, когда в именах общедоступных каталогов Windows используются специальные символы. В противоположность UNIX-подобным системам, Windows позволяет использовать в именах разделяемых файловых ресурсов пробельные символы и символы, не входящие в стандартный набор ASCII. Например, имя каталога может содержать умляут, в подобных случаях при удаленном монтировании возникнут проблемы. Проблему также представляют собой пробелы в именах каталогов. В файле /etc/fstab пробелы воспринимаются как разделители, поэтому попытка смонтировать каталог с именем «project data» вызовет несколько сообщений об ошибке в файле /etc/fstab, поскольку «date» будет воспринята как точка монтирования.

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

Поскольку нам обязательно надо было смонтировать каталог с именем «project data», мы воспользовались другим приемом, а именно, включили команду smbmount в файл /etc/rc.local, как показано ниже.

Пример 10.3.8: Пример монтирования удаленных каталогов в файле /etc/rc.local

#!/bin/sh # # This script will be executed *after* all the other init scripts. # You can put your own initialization stuff in here if you don't # want to do the full Sys V style init stuff, touch /var/lock/subsys/local #mounting windows file shares smbmount //itsont05/data /shares/data_g -o credentials=/root/.credentials, \ gid=ITSOAUSNT+Domain\ Users,dmask=0775 smbmount //itsont02/"project data" /shares/projectdata_e \ -o credentials=/root/.credentials,gid=ITSOAUSNT+Domain\ Users,dmask=0775

Как показано в последней строчке примера, имя каталога с пробелом помещено в кавычки, так же следует поступать и со специальными символами. Опции gid и dmask команды smbmount использованы для того, чтобы Linux-каталоги, которые являются точками монтирования удаленных каталогов, имели соответствующие права доступа. Если бы они были пропущены, то пользователи не имели бы прав на запись, так как каталоги были бы смонтированы со стандартными параметрами для каталога пользователя root. Права доступа к каталогу на стороне Windows-сервера контролируются средствами Windows после того, как каталоги смонтированы. Ясно, что права, установленные на серверной стороне, имеют приоритет по сравнению с правами, прописанными в smbmount.

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

10.3.2.2 Организация печати

Сетевую печать можно организовать также с использованием протокола smb, но мы выбрали использование системы печати CUPS, поскольку это более простой путь.

Подсказка Если драйвер к принтеру, который вы собираетесь использовать, отсутствует в стандартном наборе, попытайтесь найти файл с драйвером в сети. Если он обнаружится, то поместите нужный ppd-файл (Postscript Printer Description) в каталог /usr/share/cups/model. Затем нужно перезапустить CUPS и добавить принтер. Искать драйвер имеет смысл в следующем порядке:

• Обратитесь к веб-станице производителя принтера
• Посмотрите, нет ли нужного файла на странице ПО печати под Linux: http://www.easysw.com/printpro
• Попробуйте использовать фалы PPD, поставляемые фирмой Adobe: http://www.adobe.com/products/printerdrivers/winppd.html
• На домашней странице CUPS можно найти много полезных ссылок: http://www.cups.org

Подключение принтеров с использование системы печати CUPS — очень простая процедура, она описана Разд. 11.7.2.

10.3.3 Установка и настройка приложений

Как уже было отмечено выше, одним из основных приложений на выбранной рабочей станции является Adobe FrameMaker. Некоторое время назад Adobe предлагала версию этого продукта для Linux, но эта практика прекратилась после выхода версии 6.0. Так как нашему сотруднику нужны были специфические плагины, то требовалось работать именно с Adobe FrameMaker 7.0. Таким образом, данное приложение оказалось немигрируемым.

Для обеспечения работы Linux-пользователей, которым необходим Adobe FrameMaker, было решено установить приложение на Windows-сервере и организовать удаленный доступ посредством WTS (Windows Terminal Server). Эта технология позволяет Linux-клиентам соединяться по протоколу RDP (Remote Display Protocol) с приложениями, запущенными на WTS-сервере. Существуют и другие терминальные сервисы для доступа к приложениям, запущенным на удаленном сервере, но мы предположили, что для наших нужд будет достаточно WTS.

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

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

Соединение с терминальным сервером обеспечивается приложением-клиентом с графическим интерфейсом tsclient. Для хранения конфигурационных данных tsclient используются файлы $HOME/*.tc. Синтаксис для запуска сессии tsclient будет следующий:

tsclient -x $HOME/framemaker.tc

Файл framemaker.tc содержит всю необходимую информацию для соединения: IP-адрес сервера, имя пользователя и т.д.

В следующем разделе на Рис. 10.1 показан пример экрана, на котором FrameMaker запущен в терминальной сессии с Linux-клиента.

10.3.3.1 Работа с изображениями

На Winows-клиенте для работы с изображениями и создания образов экрана использовалась программа Jasc Paint Shop Pro. Для этой программы нет версии, работающей под Linux, но есть функциональный аналог GIMP. GIMP — это мощная программа с открытым кодом, в нашем случае ее функциональные возможности полностью покрывали все нужды пользователей. Подробную информацию о GIMP можно найти в сети по адресу: http://www.gimp.org.

GIMP включен как стандартный пакет в дистрибутив Red Hat Desktop, таким образом специально устанавливать и настраивать его не требуется.

В следующем разделе на Рис. 10.2 показан пример экрана, на котором запущен GIMP.

10.3.3.2 Броузер

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

Следует иметь в виду, что некоторые веб-сайты требуют специальных возможностей броузера (например, сайты, использующие ActiveX® controls или специальные функции JavaScript™) и могут быть просмотрены только с использованием броузера Microsoft Internet Explorer. Проверьте список важных для пользователя адресов, прежде чем выбирать веб-клиента. В нашем случае доступ к подобным сайтам не требовался, поэтому не было никаких препятствий для использования в качестве броузера Mozilla Firefox.

10.3.3.3 Почтовый клиент

Чтобы сделать наш сценарий миграции более реалистичным, добавим требование, что существующие клиенты используют Microsoft Outlook, который соединяется с сервером Microsoft Exchange 2000. Таким образом, необходимо выполнить замену Windows-клиента Outlook на функционально аналогичный Linux-клиент и обеспечить его интеграцию в существующую систему обмена сообщениями на базе сервера Exchange 2000.

Использование Novell Evolution в сочетании с Novell Connector for Exchange. Для решения этой задачи был использован почтовый клиент Novell Evolution вместе с Novell Connector в качестве инструмента доступа к серверу Microsoft Exchange. Почтовый клиент Evolution построен таким образом, что допускает использование специальных способов соединения с различными программными средствами коллективной работы. Коннектор для Microsoft Exchange 2000 и 2003 был выпущен под лицензией GPL в мае 2004 года. Ключевым фактором для возможности его разработки было включение фирмой Microsoft в сервер Exchange веб-интерфейса, котрый был назван OWA (Outlook Web Acces). В OWA используется WebDAV для доступа к месту хранения сообщений на сервере. Соответственно, стало возможно обмениваться сообщениями с Exchange, используя интерфейс WebDAV, вместо того чтобы заниматься обратным инжинирингом протокола MAPI.

Внимание Сервер Exchange поддерживает интерфейс WebDAV только в версиях 2000 и 2003. В момент написания этой книги не существовало коннектора, обеспечивающего связь Linux-клиента с сервером Exchange версии 5.5.

Мы установили необходимые для работы Novell Connector for Microsoft Exchange Server пакеты RPM дистрибутива Red Hat Desktop и убедились, что с их помощью можно легко установить соединение с сервером Exchange. Чтобы это работало, должны быть выполнены некоторые условия. Главное, на сервере должен быть присутствовать Outlook Web Access.

Внимание Для того, чтобы можно было использовать коннектор Novell Connector для сервера Exchange, нужно проделать некоторые предварительные действия. Во-первых, должен быть запущен виртуальный сервер Exchange в HTTP-секции менеджера системы Exchange. Во-вторых, для пользователей должен быть доступен протокол HTTP, для этого надо сделать соответствующие настройки посредством консоли ADU (Active Directory Users).

Дополнительную информацию о Novell Connector for Microsoft Exchange Server можно найти в сети по адресу: http://www.novell.com/products/evolution

10.3.3.4 Перенос пользовательских настроек

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

Перенос пользовательских настроек вручную. Сначала рассмотрим, как перенести все эти пользовательские данные вручную. Windows-версия броузера Firefox умеет импортировать такие пользовательские данные, как закладки и стартовые страницы из настроек Microsoft Internet Explorer, а Linux-версия этой опцией не обладает. Поэтому мы установили Firefox на машине с ОС Windows и выполнили импорт настроек Microsoft Internet Explorer в Firefox. Затем мы открыли общий доступ к папкам My Documents и Desktop, а также к папке, в которой хранятся настройки Firefox (обычно это папка Application Data\Mozilla). В нашем случае настройки хранились в файле

C:\Documents and Settings\AUSRES06\Application Data \Mozilla\Firefox\Profiles\xyjib4ms.default

Затем мы запустили почтовую программу Microsoft Outlook и убедились, что все почтовые сообщения хранятся на сервере. Если бы обнаружилось, что некоторые почтовые папки размещены локально, то мы создали бы каталог на сервере и скопировали бы их. Этот шаг был последним на машине под Windows.

На Linux-клиенте мы запустили Nautilus и получили доступ к общим ресурсам Windows. Мы скопировали содержимое каталога My Documents в подкаталог Documents домашнего каталога пользователя. Все файлы каталога Desktop (исключая файлы ярлыков) были скопированы на рабочий стол. Затем мы запустили Firefox, чтобы создать новый профиль пользователя. Файлы профиля хранятся в подкаталоге .mozilla домашнего каталога пользователя. На нашей машине полный путь к каталогу профиля был такой:

/home/ITSOAUSNT+AUSRES06/.mozilla/firefox/xdch2a44.default

Затем мы скопировали все файлы старого профиля с Windows-машины в этот каталог поверх тех фалов, которые в нем были. И, наконец, мы запустили Evolution и создали новую учетную запись пользователя на Exchange Server.

Автоматизированный перенос пользовательских настроек. Поскольку у нас было несколько рабочих станций с однотипным рабочим окружением, мы решили автоматизировать процесс переноса пользовательских данных. Для этого использовался инструмент Progression Desktop. Подробную информации о Progression Desktop можно найти на странице http://www.versora.com. В наши планы входило выполнить миграцию более чем на 10-ти рабочих станциях, поэтому мы решили использовать для автоматизации всех процессов интерфейс командной строки. Мы написали скрипты, которые позволили нам свести всю процедуру переноса пользовательских данных к двум простым шагам.

Во-первых, мы создали шаблон, в который включили все данные, которые предполагалось переносить, и сохранили его в общедоступном каталоге в сети. Затем, мы написали .bat-файл для автоматической установки .NET framework и Progression Desktop и сохранения настроек в пакете PNP (Platform Neutral Package) на общедоступном каталоге в сети.

Пример 10.3.9: Пакетный файл для установки и запуска Progression Desktop под Windows

cmd /c \\itsont05\data\ProgressionDesktop\Windows\dotnetfx.exe /q:a /c:"install /q /l" cmd /c msiexec /quiet /i \\itsont05\data\ProgressionDesktop\Windows\zf7fg42j9.msi "c:\Program Files\Versora\Progression Desktop\ProgressionDesktopCore.exe" —-store -—file=\\itsont05\data\%UserDomain%+%UserName%.pnp -—template=\\itsont05\data\ITSOtemplate.xml

Затем мы написали shell-скрипт для машины под Linux, который временно устанавливал на компьютере Mono (наш дистрибутив не включал Mono), запускал Progression Desktop для импорта пользовательских настроек из PNP-пакета (Platform Neutral Package) с сетевого каталога и после окончания работы удалял пакет Mono.

Пример 10.3.10: Скрипт для установки и запуска Progression Desktop под Linux

#! /bin/bash /shares/data_g/monoinstaller/mono-1.1.8.2_1-installer.bin \ -—mode unattended —-prefix /var/tmp/mono -—AddMonoToPath 0 /var/tmp/mono/bin/mono \ /shares/data_g/ProgressionDesktop/Linux/ProgressionDesktopCore.exe \ -—apply —-file=/shares/data_g/$USER.pnp \ -—template=/shares/data_g/ITSOtemplate.xml rm -rf /var/tmp/mono rm -f ~/Desktop/Mono.desktop

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

10.3.3.5 Пользовательские настройки GNOME

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

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

Более подробное описание процедуры конфигурирования GNOME и использования gconftool-2 вы найдете в Разд. 9.2.

Пример 10.3.11: Использование gconftool-2 для настройки фона экрана

# gconftool-2 —direct —config-source \ xml:readwrite:/etc/gconf/gconf.xml.mandatory —type string —set \ /desktop/gnome/background/picture_filename itso-logo.png

Кроме того, можно использовать другой логотип для кнопки главного меню. Red Hat заменяет логотип GNOME своим специально созданным изображением. Мы заменили его на другое, отредактировав файл

/usr/share/pixmaps/redhat-main-menu.png

Имя этого файла прописано в GConf. Мы избрали самый простой путь и просто переименовали файл, содержащий логотип группы ITSO, в redhat—main— menu. png. Естественно, этот файл должен иметь подходящий размер и разрешение, в нашем случае он был 48x48 пикселов и при помощи GIMP был сделан прозрачным.

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

Результат наших настроек можно увидеть ниже на Рис. 10.5.

10.3.4 Образы экранов: миграция клиента на Linux

Ниже мы собрали вместе образы экранов, демонстрирующие работу основных приложений на Linux-клиенте.

Рис. 10.1: Работа FrameMaker на Windows-сервере в терминальной сессии, запущенной с Linux-клиента (образ экрана публикуется с разрешения корпорации Adobe Systems)


Рис. 10.2: Использование Gimp для получения образа экрана с сессией FrameMaker


Рис. 10.3: Novell Evolution, установлено соединение с сервером Microsoft Exchange 2000


Рис. 10.4: Mozilla Firefox на Linux-клиенте


Рис. 10.5: Новый вид рабочего стола GNOME с произведенными для группы ITSO настройками

В этой главе описываются дополнительные методы интеграции Linux клиентов в существующие Windows домены (NT4 или Active Directory). Излагаются различные механизмы, включая подключение домашних каталогов для SMB ресурсов и аутентификация. Существуют два различных пути аутентификации пользователей в Windows домене:

• Используя winbind, входящий в Samba
• Используя прямое LDAP-соединение с Active Directory (это потребует изменений в схеме Active Directory)

Разделы этой главы:

• Разд. 11.1 Подключение к домену Windows
• Разд. 11.2 Как использовать winbind для подключения локальных пользователей
• Разд. 11.3 Как использовать LDAP для подключения к Active Directory
• Разд. 11.4 Pluggable Authentication Modules и домен
• Разд. 11.5 Как подключать файловые ресурсы к Linux-клиенту
• Разд. 11.6 Автоматическое монтирование домашних каталогов при входе в систему
• Разд. 11.7 Использование сетевых принтеров домена

Все примеры и рекомендации, приведенные в данной главе, соответствуют Samba версии не менее 3.0. Некоторая функциональность в более ранних версиях или отсутствует вовсе, или еще несовершенна.

11.1 Подключение к домену Windows

Многие how-to детально излагают рекомендации по добавлению к домену Linux серверов. Это how-to описывает технологию подключения к домену Linux-клиента. Добавление клиента к домену NT4 отличается от добавления клиента к Active Directory. Далее мы рассматриваем оба случая.

В большинстве примеров, приведенных в данном разделе, мы используем домен AD6380 как Primary Domain Controller SMB3LAB26 и Backup Domain Controller SMB3LAB27. В некоторых примерах (с использованием Windows 2003 Active Directory) мы используем домен AD6380 с контроллером домена W2K3AD.

11.1.1 Подключение к домену NT4

Для подключения к домену мы будем использовать Samba. Минимальный smb. conf приведен в Прим. 11.1.1.

Пример 11.1.1: smb.conf для подсоединения к домену NT4

[global] workgroup = AD6380 security = domain password server = SMB3LAB26,SMB3LAB27

Замените приведенные в примере домен и пароль на имя домена, используемое в вашей сети, и подправьте имена и адреса primary (и backup) домен-контроллеров.

Подключиться к домену вы можете следующим образом:

net join -S SMB3LAB26 -U administrator

Замените SMB3LAB26 на имя (или IP) вашего primary домен-контроллера и используйте любую учетную запись домена, имеющую права на добавление машины к домену. Команда запросит пароль пользователя «administrator» данного домена.

Другие детали подключения к домену NT4 можно найти в Samba-HOWTO-Collection Samba-3. Подборку можно найти по адресу:

http://samba.org/samba/docs

11.1.2 Подключение к домену Active Directory

В этом случае необходимо использование Samba совместно с Kerberos. Kerberos нам понадобится для проведения аутентификации в Windows 200x KDC.

В примере мы будем использовать домен AD6380.LOCAL на AD сервере SMB3LAB26. Необходимые для добавления в smb.conf строки приведены в Прим. 11.1.2.

Пример 11.1.2: smb.conf для подсоединения к домену Active Directory

[global] realm = AD6380.LOCAL workgroup = AD6380 security = ads password server = SMB3LAB26

Убедитесь в том, что используете правильный регистр букв для realm, поскольку Kerberos к регистру чувствителен. Используйте полностью специфицированное имя (напр. AD6380.LOCAL) для realm и короткое имя для workgroup, в противном случае могут быть выданы предупреждения.

Минимальный krb5.conf может выглядеть как в Прим. 11.1.3.

Пример 11.1.3: krb5.conf для подсоединения к Windows 200x Kerberos realm

[libdefaults] default_realm = AD6380.LOCAL [realms] AD6380.LOCAL = { kdc = SMB3LAB26:88 admin_server = SMB3LAB26 } [domain_realm] .kerberos.server = AD6380.LOCAL

Убедитесь в том, что Kerberos сервер прописан в обратной зоне DNS как NetBIOS-имя KDC или NetBIOS-имя realm. Имя домена не должно подсоединяться к имени хоста. Простейший способ — внести соответствующую запись в /etc/hosts.

Поскольку Kerberos tickets крайне чувствительны к временным меткам, очень важно засинхронизировать AD-сервер и клиентов. Как Windows-клиенты получают время от домен-контроллера, так и Linux-клиент может использовать средства, предоставляемые Samba для синхронизации времени. Для этого можно воспользоваться командой net time set. Она запрашивает время у AD-сервера и соответственно устанавливает местные часы.

Внимание Убедитесь в том, что вы используете правильную версию Kerberos (MIT или Heimdal). Для AD на Windows Server® 2003 версия Heimdal должна быть не ниже 0 .6, a MIT - 1.3.1. Убедитесь также в корректности команд kinit и klist и в том, что они не из поставки Java. Java kinit не работает.

В Novell Linux Desktop пакеты heimdal и heimdal-tools по умолчанию могут быть не установлены, но для подсоединения к AD в Windows 2003 они необходимы.

Важно Убедитесь в том, что клиенты и сервер Active Directory (или Kerberos) имеют одно и тоже время, в рамках разрешенного разброса (skew).

Серверы Microsoft Windows используют Simple Network Time Protocol (SNTP), который является упрощенной версией (UNIX/Linux) Network Time Protocol (NTP). Форматы пакетов у них одинаковы и могут использоваться совместно. Это означает, что Linux-клиенты могут синхронизироваться с AD-серверами через ntp.

Конфигурацию Kerberos можно протестировать через kinit USERNAME@REALM, для того чтобы убедиться, что пароль принимается Windows 200x KDC.

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

Для того, чтобы действительно подсоединиться к домену AD, необходимо выполнить следующую команду:

net ads join -U administrator

Будет запрошен пароль администратора, например, для подключения клиентской машины client1 к домену AD6380 используется пользователь idsadmin, имеющий права администратора (см. Прим. 11.1.4).

Пример 11.1.4: Пример подсоединения машины client1 к домену AD6380

[root@client1 root]# net ads join -U idsadmin idsadmin password:******* Using short domain name -- AD638 0 Joined 'CLIENT1' to realm 'AD6380.LOCAL'

Для подсоединения к необходимой организационной единице в первую очередь понадобится правильная комбинация имя-пароль. К примеру, если вы хотите подключиться к домену (то есть внести запись о компьютере) в контейнер Clients в организационном каталоге Computers/ITSO, вы должны выполнить:

kinit Administrator@AD638 0.LOCAL net ads join "Computers\ITSO\Clients"

Внимание Поскольку Windows 2003 использует подписи SMB, при подключении Windows 2003 ADS вы можете добавить в файл smb.conf следующую строчку:

client use spnego =

Для проверки подключения к AD-домену (во всех случаях) используйте команду:

net ads testjoin

Дополнительные детали о подключении к домену Active Directory можно найти в разделе 6.4 Samba HOWTO collection:

http://samba.org/samba/docs/Samba-HOWTO-Collection.pdf

11.2 Как использовать winbind для подключения локальных пользователей

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

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

11.2.1 Стандартный winbind

Демон winbind пользуется установками прописанными в файле smb.conf. В Прим. 11.2.1 приведены строки, которые надо добавить в smb.conf, для подключения winbind.

Пример 11.2.1: Добавления в smb.conf для winbind

[global] winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%D+%U template shell = /bin/bash

Данный разделитель (separator) означает, что учетная запись для пользователя Administrator в домене AD6380 будет записываться в виде: «AD6380+Administrator». Остальные записи задают диапазоны uid и gid для учетных записей домена, какие домашние каталоги и интерпретаторы будут использоваться при входе пользователя в систему. Как показывает практика, знак плюса (+) в качестве winbind-разделителя в Linux-окружении наиболее удобен.

Как альтернатива, разделитель и имя домена могут и вовсе не использоваться. Это означает, что используется домен по умолчанию. Для этого добавьте в smb.conf следующую строку:

winbind use default domain = yes

и возможно заменить template homedir на:

template homedir = /home/%U

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

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

Записи idmap uid и gid указывают winbind в каких диапазонах следует порождать пользовательские и групповые идентификаторы для учетных записей домена. Выбирайте диапазоны, не пресекающиеся с локальными пользователями.

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

После внесения указанных изменений, надо запустить winbind-демон. Обычно это выполняется командой:

/etc/init.d/winbind start

Убедитесь в том, что демон стартует при загрузке системы. В большинстве дистрибутивов (в первую очередь в Red Hat Enterprise Linux и Novell Linux Desktop) это достигается выполнением команды:

chkconfig winbind on

Работоспособность winbind может быть проверена командой wbinfo. Запустив ее с опцией -u, вы увидите все учетные записи домена, а с опцией -g — все группы.

Важно Сервис nscd (name service caching daemon) конфликтует с winbind. Никогда не запускайте nscd на системе, где функционирует winbind.

Пример 11.2.2: Пример вывода команды wbinfo

[root@client1 root]# wbinfo -u AD6380+Administrator AD6380+Guest AD6380+TsInternetUser AD6380+idsadmin AD6380+krbtgt AD6380+HOST/client1 AD6380+SMB3LAB26$

С такими установками winbind сможет транслировать доменные учетные записи в локальных пользователей. Для того, что бы сообщить системе о необходимости использования winbind, следует внести соответствующие указания в конфигурацию Name Service Switch (NSS).

Конфигурационным файлом для NSS является /etc/nsswitch.conf. Он содержит записи вида:

passwd: files example

Это означает, что при проверке пароля запрос отправляется вначале на /lib/libnss_files.so, где производится поиск, а затем на /lib/libnss_example.so. Как только соответствующая запись будет найдена, результат возвращается приложению. Для того, что бы добавить поиск через winbind, необходимо добавить в /etc/nsswitch.conf следующие строки:

passwd: files winbind group: files winbind

Для проверки введите следующую команду:

getent passwd

Она возвратит не только записи из файла /etc/passwd, но и те, что были оттранслированы winbind.

Пример 11.2.3: Часть вывода getent passwd с подключенным в NSS winbind

[root@client1 root]# getent passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin ....................... AD6380+Administrator:x:10000:10000:Administrator:/home/AD6380+Administrator :/bin/bash AD6380+Guest:x:10001:10000:Guest:/home/AD6380+Guest:/bin/bash AD6380+TsInternetUser:x:10002:10000:TsInternetUser:/home/AD6380+TsInternetU ser:/bin/bash AD6380+idsadmin:x:10003:10000:idsadmin:/home/AD6380+idsadmin:/bin/bash AD6380+krbtgt:x:10004:10000:krbtgt:/home/AD6380+krbtgt:/bin/bash AD6380+HOST/client1:x:10005:10001:client1:/home/AD6380+HOST/client1:/bin/ba sh AD6380+SMB3LAB26$:x:10006:10002:SMB3LAB26:/home/AD6380+SMB3LAB26_:/bin/bash

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

Важно В том случае, если исполнение winbind аварийно завершилось вследствие потери Kerberos-соединения из-за превышения time skew, демон перезапустится после его обновления.

Демон winbind занимается отображением пользователей, привязкой домашних каталогов и интерпретаторов. Сами домашние каталоги winbind не создаются. Как добиться такого создания, описано в Разд. 11.4.3.

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

11.2.2 Альтернативы winbind

Главное отличие предлагаемых далее решений от изложенных выше, состоит в механизме генерации uid и gid. В предыдущем разделе winbind выбирал uid и gid для каждого пользователя из указанного диапазона. Очевидное следствие — их разный порядок на разных клиентах домена.

В этом разделе описываются два различных пути для решения этой проблемы:

• idmap_rid backend для генерации информации Active Directory
• idmap_ad backend для получения uid и gid из AD с расширенной схемой (Services for Unix)

Это относительно новые idmap backend'ы, и пока они являются экспериментальными. Но любой из них позволяет избавиться от недостатков, присущих winbind, при использовании в промышленных масштабах.

11.2.2.1 idmap_rid backend

Этот backend формирует uid для gid для пользователей домена, основываясь на доменных SID. Для включения этой опции, включите в smb.conf строки, приведенные в Прим. 11.2.4.

Пример 11.2.4: Пример smb.conf для использования idmap_rid backend

idmap uid = 10000-20000 idmap gid = 10000-20000 idmap backend = idmap_rid:AD6380=15000-20000 allow trusted domains = no

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

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

Пример 11.2.5: Частичный вывод getent passwd при использовании idmap rid

root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash .................................. AD6380+administrator:x:15500:15513:Administrator:/home/administrator:/bin/ bash AD6380+guest:x:15501:15514:Guest:/home/guest:/bin/bash AD6380+w2k3ad$:x:16003:15516:W2K3AD:/home/w2k3ad_:/bin/bash AD6380+krbtgt:x:15502:15513:krbtgt:/home/krbtgt:/bin/bash AD6380+testuser:x:16108:16121:Test User:/home/testuser:/bin/bash AD6380+rhdt4$:x:16112:15515:rhdt4:/home/rhdt4_:/bin/bash AD6380+rhdt4a$:x:16113:15515:rhdt4a:/home/rhdt4a_:/bin/bash AD6380+ldapbind:x:16117:15513:ldapbind:/home/ldapbind:/bin/bash AD6380+nld9$:x:16120:15515:nld9:/home/nld9_:/bin/bash

11.2.2.2 idmap_ad backend

В этом разделе излагается концепция LDAP, применяемая в Microsoft Services for Unix (SFU). Используемая в SFU схема для Active Directory расширена на uid и gid. Использование idmap ad backend'а позволяет получать эту информацию и передавать ее winbind'у.

Это позволяет всем клиентам использовать одну и ту же информацию, поскольку отображением в данном случае занимается Active Directory.

Поддержка idmap_ad backend'а включается добавлением следующей строки в файл smb.conf:

idmap backend = idmap_ad

11.3 Как использовать LDAP для подключения к Active Directory

Active Directory реализует Lightwight Directory Access Protocol (LDAP). Вы можете использовать LDAP-клиент для подключения к AD для получения информации о пользователях. Однако, поскольку хранение данных о пользователях Unix/Linux в AD не предусматривалось, некоторые необходимые объекты в стандартной схеме отсутствуют. Одним из первых шагов по расширению схемы является добавление необходимых классов объектов.

Простейший путь — установка "Services for Unix"(SFU) от Microsoft. Данный продукт включает в себя все необходимые расширения для хранения таких данных.

Установка SFU с использованием параметров по умолчанию включает в себя следующее:

1. Распаковать файлы в каталог, иной чем C:\SFU, например, в C:\Temp\SFU
2. Запустить setup.exe
3. Выбрать Standard Installation
4. На экране Security Settings оставить обе опции пустыми
5. Выбрать «Local Username Mapping Server» и «Network Information Services»
6. Выбрать имя домена
7. Перезагрузить AD-сервер

В результате мы расширяем схему AD, включая в нее такие поля как uid и gid.

Следующим шагом мы создаем пользователя в Active Directory, используя LDAP-клиента для подключения к каталогу. Установите секретный пароль и пометьте его как «not expire».

Установленные к схеме дополнения позволяют теперь задавать gid у групп и uid, shell и домашний каталог для пользователей, см. Рис. 11.1.

Рис. 11.1: Окно Active Directory User Properties с Unix Attributes

В этом примере создан пользователь testuser с uid 5000, shell'ом и домашним каталогом. Также мы создали группу linuxusers с gid 5000.

Дополнительную информацию о Services for Unix и интеграции Active Directory с каталогами для Linux/UNIX-клиентов можно найти в документе Solution Guide for Windows Security and Directory Services for UNIX от Microsoft.

Для того чтобы система использовала LDAP-подключение к Active Directory, надо задать соответствующую конфигурацию в файле /etc/ldap.conf. Эта конфигурация должна включать в себя следующую информацию:

• IP адрес сервера Active Directory (разделяются пробелами, если их несколько)
• Базовый узел (bind node) в дереве каталога для начала поиска
• Пользователь (bind user), через которого осуществляется подсоединение к AD
• Пароль этого пользователя (открытым текстом, так что берегите свой конфигурационный файл)
• Границы поиска
• SSL подключение
• Записи, описывающие отображение объектов доменной схемы, необходимых для NSS Пример конфигурационного файла см. на Прим. 11.3.1.

Пример 11.3.1: Фрагмент файла /etc/ldap.conf

host 192.168.100.110 base cn=Users,dc=AD6380,dc=LOCAL binddn cn=ldapbind,cn=Users, dc=AD6380,dc=LOCAL bindpw Welcome2006 scope sub ssl no nss_base_passwd cn=Users,dc=AD6380,dc=LOCAL?sub nss_base_shadow cn=Users,dc=AD6380,dc=LOCAL?sub nss_base_group cn=Users,dc=AD6380,dc=LOCAL?sub nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute gecos name nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_objectclass posixGroup Group nss_map_attribute uniqueMember msSFU30PosixMember nss_map_attribute cn cn

Следующие записи в NSS-конфигурации изменены для включения возможности входа в систему через LDAP:

passwd: files ldap group: files ldap

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

getent passwd

Теперь покажем, как выглядит запись пользователя testuser при выводе passwd, см. Прим. 11.3.2.

Внимание Заметьте, что пользователи отображаются без имени домена и символа-разделителя. Это так же означает, что перекрытие имен исключено, так как пользователь один и тот же и в локальных файлах, и в домене.

Пример 11.3.2: Фрагмент вывода getent passwd при включенном ldap в NSS

root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin ................................ testuser:ABCD!efgh12345$67890:5000:5000:Test User:/home/testuser:/bin/bash

Таким образом, вместо генерации записей с uid и gid на каждом клиенте мы при помощи такого метода получаем эти записи из Active Directory. Однако это означает, что эти записи должны быть заведены именно там с самого сначала.

Различия, достоинства и недостатки обоих методов, winbind и LDAP, мы уже обсуждали в Разд. 7.2. Часть информации данного раздела базируется на: http://enterprise.linux.com/enterprise/04/12/09/2318244.shtml?tid=102&tid=101&tid=100

11.4 Pluggable Authentication Modules и домен

Подсоединив Linux-клиент к домену (согласно Разд. 11.1) и зная, как воспользоваться доменными учетными записями с использованием winbind (Разд. 11.2) или LDAP (Разд. 11.3), вы можете сконфигурировать систему для входа через доменные записи.

Pluggable Authentication Modules (PAM) представляет определенный уровень абстракции для процедур аутентификации и авторизации. Используя PAM-модули можно менять методы аутентификации и авторизации без перекомпиляции приложений.

В большинстве дистрибутивов конфигурация PAM задается в файлах /etc/pam. d/. Таким образом, изменение режима аутентификации достигается простым добавлением соответствующего модуля в конфигурационный файл.

11.4.1 Аутентификация пользователей с использованием winbind и PAM

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

11.4.1.1 Winbind и PAM в Red Hat Desktop

В Red Hat реализован модуль pam stack. Это означает, что конфигурационные файлы из /etc/pam.d/ могут использовать установки из других файлов, включая вложенные конфигурации. Для этих целей в Red Hat используются установки в конфигурационном файле /etc/pam.d/system—auth. Это означает, что едва мы только добавим PAM модули winbind в этот файл, как все приложения использующие PAM получат winbind поддержку.

Поскольку файл /etc/pam.d/system—auth генерируется автоматически через authconfig, будьте осторожны при запуске этой команды после того, как внесете в него изменения вручную.

Пример файла system-auth, содержащего необходимые строки, приведен в Прим. 11.4.1.

Пример 11.4.1: Фрагмент файла /etc/pam.d/system-auth с добавлениями для winbind-аутентификации

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_winbind.so ........................

Поскольку pam_winbind.so был включен в файл system-auth, все приложения, использующие этот файл через pam_stack.so, получают поддержку winbind. Это означает, что вы сможете входить на Linux-клиента, используя доменные учетные записи следующей нотации:

Так, например, в нашем тестовом домене это будет выглядеть как AD6380+Administrator.

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

11.4.1.2 Winbind и PAM в Novell Linux Desktop

В Novell Linux Desktop (NLD) не используется модуль pam_stack для получения установок из центрального файла. Это означает, что для каждого приложения понадобится добавление модуля winbind аутентификации в его конфигурационный файл в /etc/pam.d/.

В качестве примера мы приводим конфигурационный файл sshd. После включения модуля pam_winbind.so он будет выглядеть как в Прим. 11.4.2

Пример 11.4.2: Конфигурационный файл /etc/pam.d/sshd после подключения winbind

#%PAM-1.0 auth sufficient pam_winbind.so auth required pam_unix2.so use_first_pass # set_secrpc auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account sufficient pam_winbind.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.souse_first_pass use_authtok session required pam_unix2.sonone # trace or debug session required pam_limits.so

Для каждого поддерживающего PAM приложения, которое вы хотите сделать доступным для пользователей домена, необходимо добавить строки auth и account для pam winbind.so (до строк nologin). Для предотвращения двойного запроса пароля ко всем модулям, запрашивающим пароль, в конфигурационный файл должен быть добавлен параметр use_first_pass кроме модуля pam_winbind.so.

11.4.2 Как производить аутентификацию пользователй через LDAP и PAM

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

Поскольку объекты SFU-расширения схемы Active Directory имеют иные названия, чем требуется для PAM, нам понадобится настроить отображение. См. Прим. 11.4.3

Пример 11.4.3: Отображение для файла /etc/ldap.conf

pam_login_attribute sAMAccountName pam_filter objectclass=user pam_member_attribute msSFU30PosixMember pam_groupdn cn=unixusergroup,dc=AD6380,dc=LOCAL pam_password ad

Выделенные в Прим. 11.4.3 строки ограничивают набор пользователей AD, которым разрешен вход на Linux-клиент. PAM разрешит вход только членам группы unixusergroup в AD.

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

11.4.2.1 LDAP и PAM в Red Hat Desktop

В Red Hat используется модуль pam_stack. Это означает, что конфигурационные файлы в /etc/pam.d/ могут использовать установки из других файлов. По этой причине, в Red Hat многие установки делаются в конфигурационном файле /etc/pam.d/system—auth. Это означает, что нам достаточно добавить LDAP РАМ модули в этот файл и все приложения, использующие PAM, тотчас получают доступ к LDAP. PAM-модуль носит название pam ldap.

Поскольку /etc/pam.d/system-auth генерируется authconfig, будьте внимательны, запуская эту команду после того, как изменили этот файл вручную.

Пример файла system-auth, содержащего эти строки, см. в Прим. 11.4.4.

Пример 11.4.4: Часть файла /etc/pam.d/system-auth с включением LDAP аутентификации

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.solikeauthnullok auth sufficient /lib/security/$ISA/pam_ldap.souse_first_pass auth sufficient /lib/security/$ISA/pam_krb5.souse_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account required /lib/security/$ISA/pam_ldap.so ........................

После включения pam_ldap.so в system-auth все приложения, использующие этот файл через pam_stack.so, становятся способными работать с LDAP. Это означает, что мы можем входить на Linux-клиента через учетные записи домена.

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

Внимание Убедитесь, что вь поместили pam_ldap, как это требуется в раздел account, иначе даже пользователь, не входящий в группу, указанную в /etc/ldap.conf, сможет осуществить вход.

В Прим. 11.4.5 показан вывод команды ssh при входе пользователя из домена, который не входит в группу unixusergroup (как описано в Прим. 11.4.4), но поля account для pam_ldap оказывается достаточно.

Пример 11.4.5: Успешный вход через ssh пользователя, не входящего в правильную группу

[root@RHDT4a ~]# ssh testuser@localhost testuser@localhost's password: You must be a msSFU30PosixMember of cn=unixusergroup,dc=AD6380,dc=LOCAL to login. Last login: Fri Jan 13 10:09:34 2006 from rhdt4a -bash-3.00$

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

Пример 11.4.6: Неуспешный вход через ssh, вследствие неправильного членства в группе

[root@RHDT4a ~]# ssh testuser@localhost testuser@localhost's password: Permission denied, please try again.

11.4.2.2 LDAP и PAM в Novell Linux Desktop

Novell Linux Desktop (NLD) не использует модуль pam stack для получения установок из центрального файла. Это значит, что для каждого приложения, которому понадобится использовать модуль LDAP-аутентификации, потребуется добавить его в соответствующий конфигурационный файл в /etc/pam.d.

В качестве примера мы возьмем конфигурационный файл sshd. После добавления в него модуля pam_ldap.so он выглядит как в Прим. 11.4.7.

Пример 11.4.7: Конфигурационный файл /etc/pam.d/sshd после добавления LDAP

#%PAM-1.0 auth sufficient pam_ldap.so auth required pam_unix2.so use_first_pass # set_secrpc auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account required pam_ldap.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.souse_first_pass use_authtok session required pam_unix2.sonone # trace or debug session required pam_limits.so

Для каждого приложения, поддерживающего PAM, для которого вы хотите открыть доступ пользователям домена, необходимо добавить строки auth и account для pam ldap.so. Для того чтобы не надо было вводить пароль дважды, в конфигурационный файл для каждого PAM-модуля должен быть добавлен параметр use first pass, за исключением модуля pam_ldap.so.

Внимание Убедитесь , что вы поместили pam_ldap в разделе account, иначе группа, указанная в /etc/ldap.conf, не будет действовать.

11.4.3 PAM и домашние каталоги

Пользователи, входящие в домен на клиенте, локально не существуют. Через SFU-расширение схемы AD или winbind конфигурацию /etc/samba/smb.conf мы сообщаем системе, какую командную оболочку следует использовать и где находится домашний каталог пользователя (для локальных пользователей эта информация располагается в файле /etc/passwd). Однако, домашний каталог ни winbind, ни LDAP не создает.

Эта проблема может быть решена разными путями:

• Создать все возможные домашние каталоги (пустые) на всех клиентах.
• Создать все домашние каталоги на файловой системе сервера, которая монтируется всеми клиентами (по SMB или NFS).
• Использовать модуль pam mkhomedir.so, который создает домашний каталог при первым входе пользователя в систему.

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

11.4.3.1 Red Hat Desktop

В системах Red Hat модуль pam mkhomedir добавляется в /etc/pam.d/system—auth. После этого домашний каталог будет создаваться при входе пользователя в систему, например, через терминальный вход, secure shell session или графическую сессию.

Строки, которые надо добавить в этот файл, представлены в Прим. 11.4.8.

Пример 11.4.8: Фрагмент файла /etc/pam.d/system-auth, включающий pam_mkhomedir

#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_winbind.so ........................ session optional /lib/security/$ISA/pam_mkhomedir skel=/etc/skel umask=0022

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

11.4.3.2 Novell Linux Desktop

Поскольку NLD не использует system-auth и pam_stack.so, pam_mkhomedir.so следует добавить в каждый конфигурационный файл приложений, которые осуществляют вход пользователя в систему. Примерами таких приложений могут являться ssh, telnet, gdm, xdm и login. Первый вход каждого пользователя домена через любое из этих приложений будет приводить к созданию домашнего каталога.

Строка, которую следует добавить в файл, выглядит следующим образом:

session optional pam_mkhomedir skel=/etc/skell umask=0022

Пример для ssh см. в Прим. 11.4.9.

Пример 11.4.9: Пример файла /etc/pam.d/sshd с включенным pam mkhomedir.so

#%PAM-1.0 auth sufficient pam_ldap.so auth required pam_unix2.so use_first_pass auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account required pam_ldap.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session optional pam_mkhomedir.so skel=/etc/skel umask=0022 session required pam_unix2.so none # trace or debug session required pam_limits.so

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

В Прим. 11.4.10 показано, как создается домашний каталог, когда доменный пользователь testuser впервые входит в систему.

Пример 11.4.10: Ввод при первом входе пользователя домена в систему

nld9:~ # ssh testuser@localhost Password: Creating directory '/home/testuser'. Creating directory '/home/testuser/bin'. Creating directory '/home/testuser/Documents'. Creating directory '/home/testuser/public_html'. Creating directory '/home/testuser/.xemacs'. Creating directory '/home/testuser/.fonts'. Last login: Fri Jan 13 16:09:47 2006 from localhost testuser@nld9:~> pwd /home/testuser

11.5 Как подключать файловые ресурсы к Linux-клиенту

Этот раздел описывает различные пути подключения Windows-ресурсов.

Один вариант заключается в постоянном подсоединении к ресурсу путем монтирования куда-то в файловую систему. Эти ресурсы могут подключаться через smb mount CIFS mount'а.

Если монтирование невозможно, можно воспользоваться командой smbclient. Smbclient работает как ftp-клиент и может использоваться для получения и загрузки файлов на Windows-ресурсах.

11.5.1 Подключение ресурсов через smbfs

Ресурс может быть подключен при помощи команды mount следующим образом:

mount -t smbfs //servername/sharename /mountpoint -o user=domainuser

Команда mount вызывает smbmount для монтирования ресурса sharename на сервере servername в точку монтирования mountpoint. При подключении используется пользователь domainuser и в ходе исполнения команды запрашивается его пароль.

Это наиболее распространенный способ подключения Windows-ресурсов к не Windows операционным системам при помощи Samba.

Однако, если ресурс помещен на сервере, который выполняет SMB signing (а многие Windows делают это), исполнение команды прервется, выдав сообщение об ошибке. Это следствие того, что Samba-клиент не поддерживает SMB signing и не может подмонтировать ресурс.

11.5.2 Подключение ресурсов через CIFS

Common Internet File System (CIFS) это платформо-независимая система разделения файловых ресурсов, построенная по принципам SMB файловых систем Microsoft. В новых версиях 2.6 ядра Linux CIFS встроен. Подключение ресурсов как файловых систем CIFS позволяет избежать описанных выше проблем с SMB signing для Linux-клиентов.

Кроме того, CIFS mount может использоваться для подключения файловых систем Microsoft DFSTM , smbmount для которых не работает.

Синтаксис использования mount для CIFS очень похож на монтирование при помощи smbfs:

mount -t cifs //servername/sharename /mountpoint -o user=domainuser

Подсказка Ориентируясь на будущее, старайтесь использовать CIFS везде, где это возможно

11.5.3 Использование smbclient

Команда smbclient, по сути дела, превращает Windows-ресурс в ftp-сервер. Работает она следующим образом:

smbclient //servername/sharename -U domainuser -W domainname

Команда запрашивает пароль и соединяется с ресурсом. Вот некоторые из команд, которые можно использовать в smbclient:

• get — выкачивает файл, расположенный на ресурсе, в локальную файловую систему
• put — копирует локальный файл на ресурс
• cd — смена рабочего каталога на ресурсе
• lcd — смена рабочего каталога в локальной файловой системе
• help — показать все доступные команды
• quit — выход из smbclient

В Прим. 11.5.1 показано подключение к ресурсу и получение подсказки по использованию команды smbclient.

Пример 11.5.1: Пример использования smbclient для подключения к Windows-ресурсу

nld9:~ # smbclient //w2k3ad.ad6380.local/share1 -U administrator Password: Domain=[AD6380] OS=[Windows Server 2003 3790] Server=[Windows Server 2003 5.2] smb: \> help get HELP get: [local name] get a file smb: \>

11.6 Автоматическое монтирование домашних каталогов при входе в систему

Одной из замечательных возможностей Windows является функция Single Sign On (SSO). При входе в ОС Windows у вас запрашивается пароль и в дальнейшем этот пароль используется при подключении ресурсов, помеченных как подсоединяемые при входе.

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

Внимание С сентября 2005 pam_mount'у уделяется заметно больше внимания. Новые версии выходят чаще. Несмотря на это, еще не во всех дистрибутивах он работает.

Файловые системы SMB и CIFS не позволяют создавать символьные ссылки или сокеты. Это следствие того, что Windows-ресурсы, к которым они подсоединяются, таких возможностей не поддерживают. Это означает, что приложения, которым необходимо такие объекты создавать, не смогут работать на этих файловых системах.

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

Подсказка Монтирование пользовательского доменного ресурса в качестве подкаталога домашнего каталога позволяет избежать всех проблем с графическими окружениями.

Модуль pam_mount монтирует не только файловые системы SMB и CIFS, но еще и NCP, шифрованные loop файловые системы и практически любые файловые системы, поддерживаемые командой mount.

11.6.1 pam_mount на Red Hat Desktop

Модуль, добавляемый в /etc/pam.d/system-auth, включает автоматическое монтирование для всех вариантов входа в систему. Модуль включает в себя часть «auth», которая получает пароль через PAM; и часть «session», которая собственно и занимается монтированием. Также этот сессионный модуль занимается отключением ресурсов при выходе из сессии.

Подсказка Убедитесь в том, что вам действительно необходимо автоматическое монтирование при всех видах входа в систему. Например, su от пользователя root на какого-то пользователя может не сработать, так как пароль при этом не запрашивается.

Строки, которые следует добавить:

auth required pam_mount.so

и:

session optional pam_mount.so

Строка auth должна предшествовать строкам pam unix и pam winbind. Строка session должна присутствовать в соответствующем разделе. Не забудьте добавить аргумент use_first_auth для строки, не имеющей перед собой pam_mount, иначе пароль будет запрашиваться дважды.

Модуль pam_mount имеет свой собственный конфигурационный файл /etc/security/pam_mount.conf. Этот файл содержит установки, касающиеся того, как выполнить команды mount и umount, установки режима отладки и указания какие файловые системы должны подключаться при входе тех или иных пользователей.

Минимальный pam_mount.conf только для монтирования SMB-ресурсов выглядит следующим образом, см. Прим. 11.6.1.

Пример 11.6.1: Минимальный pam mount.conf

debug 1 mkmountpoint 1 options_require nosuid,nodev lsof /usr/sbin/lsof fsck /sbin/fsck losetup /sbin/losetup unlosetup /sbin/losetup -d smbmount /usr/bin/smbmount umount /usr/bin/smbumount volume * smb smb3lab26 & /home/&/domainshare uid=&,dmask=0750 - -

Таким образом включается режим отладки для pam_mount. Точки монтирования создаются в том случае, если они не существуют, и ресурс подключается согласно описанию, представленному в последней строке. Звездочка в начале последней строки в примере, приведенном выше показывает, что данный ресурс монтируется любым пользователем. Амперсанд (&) в определении расширяется до имени пользователя. Так строка volume в Прим. 11.6.1 сообщает pam _mount'у о необходимости подключить сетевой ресурс, прописанный после имени пользователя, с сервера smb3lab26 в точку монтирования /home//domainshare. Опции, указанные в строке options говорят о том, что владельцем подмонтированного ресурса будет uid, и права доступа будут определяться dmask.

Внимание В некоторых случаях модуль pam_mount не будет отрабатывать при попытке выполнить setuid root, что означает, что нормальные команды монтирования будут прерываться с сообщением, что только суперпользователь root может выполнять такие операции. Однако это явление не частое.

Возможная проблема при монтировании ресурсов домена заключается в том, что в файле pam_mount.conf амперсанд (&) расширяется в полное имя пользователя, включая имя домена и разделитель. Это великолепно работает с pam_mount в том случае, когда у winbind установлена опция «default domain = yes» в smb.conf, для получения имен пользователей домена без домена и разделителя. В ином случае понадобятся дополнительные скрипты для их удаления из имени пользователя перед выполнением монтирования.

Подсказка При работе с pam_mount рекомендуется использование простых имен пользователей для доменных записей. Это означает, что следует сделать установки для default domain. См. Разд. 11.2.1

11.6.2 pam_mount в Novell Linux Desktop

Ситуация при использовании Novell Linux Desktop и pam_mount несколько отличается от Red Hat Desktop. На Novell Linux Desktop собраны последние версии pam_mount. Однако использование pam_mount с sshd гораздо сложнее.

Pam_mount добавляется во все файлы /etc/pam.d для всех сервисов, требующих автоматического монтирования. Модуль включает в себя как часть «auth», получающую пароль через PAM; так и часть «session», собственно и осуществляющую монтирование. Сессионный модуль так же занимается отключением ресурсов при выходе из сессии.

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

Строки, которые надо добавить, будут иметь вид:

auth required pam_mount.so

и:

session optional pam_mount.so

Строка auth должна предшествовать строкам pam_unix и pam_winbind. Строка session должна располагаться в соответствующем разделе. Помните, что необходимо добавление аргумента use_first_auth для строки, не имеющей перед собой pam_mount, иначе пароль будет запрашиваться дважды.

Модуль pam mount имеет свой собственный конфигурационный файл /etc/security/pam_mount.conf. Этот файл содержит установки команд монтирования, режимы отладки, точки монтирования, которые надо создавать, и указания, какие файловые системы должны подключаться при входе тех или иных пользователей.

Минимальный pam_mount.conf только для монтирования SMB-ресурсов выглядит так же как и в Прим. 11.6.1.

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

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

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

• Печать непосредственно на принтер, используя его сетевой интерфейс.
• Печать на принтере через Windows print server и его SMB-интерфейс.

Оба варианта доступны при использовании CUPS на Linux-клиенте. Мы рекомендуем использовать второй вариант, однако это возможно только в том случае, если все системы печати в домене (и пользовательские окружения) построены на одной базе. Это означает, что речь идет только о Windows и Linux системах печати.

На Linux-клиенте должен работать CUPS. Это можно проверить так:

/etc/init.d/cups status

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

/etc/init.d/cups start

Убедитесь в том, что он запустится после следующей перезагрузки:

chkconfig cups on

Вы также должны убедиться в том, что присутствует ссылка на smbspool в каталоге backend'ов CUPS:

# ls -l /usr/lib/cups/backend/smb lrwxrwxrwx 1 root root 21 Mar 1 12:34 /usr/lib/cups/backend/smb -> ../../../bin/smbspool

Вы можете проверить, поддерживает ли CUPS smb, при помощи команды:

# lpinfo -v | grep smb network smb

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

• Используя команду lpadmin
• Через веб-интерфейс CUPS

Мы опишем оба варианта детальнее.

11.7.1 Создание принтера при помощи команды lpadmin

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

Для создания принтера задайте следующую команду:

lpadmin -p printer1 -E -v smb://Administrator:*****@SMB3LAB26/printer1 \ -D "printer1 in AD638 0 example domain"

Параметры, конечно, надо будет заменить на имена в вашем домене. Первое вхождение printer1, это название локального принтера, а второе — название ресурса. Сервер SMB3LAB26 — это сервер печати. Если принтер доступен всем, можете оставить имя пользователя и пароль в smb: URL. Поскольку использование привязанных к пользователю ресурсов печати может привести к раскрытию паролей через скрипты или login-профайлы, лучшей практикой является открытие принтерных ресурсов для всех.

Кроме того, вы можете добавить опцию -m для указания модели, или опцию -l для указания места расположения.

11.7.2 Создание принтера через веб-интерфейс CUPS

Все то же самое можно проделать через веб-интерфейс CUPS. Для этого нам нужно выполнить следующие шаги:

1. В броузере загрузите административный интерфейс CUPS, используя URL: http://localhost:631/.

Рис. 11.2: Стартовая страница веб-интерфейса CUPS

2. Нажмите Manage Printers (Управление принтерами)

Рис. 11.3: Страница управления веб-интерфейса CUPS

3. Нажмите Add (Добавить)

   Вы получите страницу, на которой вы сможете ввести Name (Имя), Location (Местоположение) и Description (Описание) принтера. Теперь нажмите Continue (Продолжить).

Рис. 11.4: Страница добавления принтера веб-интерфейса CUPS

4. На следующей странице вы выберете устройство, к которому подключен принтер. Выберите «Windows Printer via SAMBA» и нажмите Continue (Продолжить).

Рис. 11.5: Страница Модель/Драйвер веб-интерфейса CUPS

5. На следующей странице у вас запросят URI устройства. Введите:

smb://:@/

Или :

smb:///

Рис. 11.6: Ввод URI устройства веб-интерфейса CUPS

А затем нажмите Continue (Продолжить).

6. На следующей странице выберите модель и драйвер принтера и нажмите Continue (Продолжить).

Рис. 11.7: Страница Модель/Драйвер веб-интерфейса CUPS

На следующей странице вы можете сделать более детальный выбор на основе модели, выбранной на предыдущем экране. Выберите нужный и нажмите Continue (Продолжить).

Рис. 11.8: Вторая страница Модель/Драйвер веб-интерфейса CUPS

7. Вы добавили принтер в CUPS.

Рис. 11.9: Страница Принтер добавлен веб-интерфейса CUPS

Скриншоты, показанные в этом разделе, созданы с использованием клиента Red Hat Desktop, подсоединенного к домену Active Directory AD6380, с домен-контроллером smb3lab26.

Для тестирования добавленного вами через lpadmin или через веб-интерфейс принтера просто напечатайте файл или воспользуйтесь кнопкой Print Test Page (Напечатать Тестовую Страницу) веб-интерфейса.

Рис. 11.10: Страница управления веб-интерфейса CUPS с добавленным принтером printer1

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