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

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

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

IBM developerWorks, IBM developerWorks, IBM　

05.2007

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

В этой главе будут подробно обсуждаться примеры организации рабочих мест под 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). Остальные три профиля идентичны.

[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 можно видеть эти профили, которые мы создали для своего тестового варианта миграции, и приписанную каждому профилю роль.

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

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

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

amelie=Administrator,Designer

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

partner=Partner,Redbook

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

[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.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)

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

• Опции конфигурации значков на рабочем столе
  • Заблокировать настойки Рабочего стола (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)

• Настройка конфигурации 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 <Application>)
  • Отключить Справка —> О KDE (Help —> About KDE)

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)

[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

[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. Как можно видеть в приведенном ниже примере, полный синтаксис таких ограничений довольно длинный, но мы остановимся на более простых случаях.

[KDE URL Restrictions]
rule_count=<N->
rule_1=<act->,<ref_proto->,<ref_host->,<ref_path->,<proto->,/
<host->,<path->,<enabled->
...
rule_N=<act->,<ref_proto->,<ref_host->,<ref_path->,<proto->,/
<host->,<path->,<enabled->

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

[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)

[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.

[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] 
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.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).

/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. Ниже приведен пример такого файла

/etc/opt/gnome/gconf/gconf.xml.defaults/desktop/gnome/lockdown 
<?xml version="1.0"?>

<gconf>
   <entry name="disable_print_setup" mtime="1089888947"
          schema="/schemas/desktop/gnome/lockdown/disable_print_setup"/> 
   <entry name="disable_printing" mtime="1089888947"
          schema="/schemas/desktop/gnome/lockdown/disable_printing"/> 
   <entry name="disable_save_to_disk" mtime="1089888947"
          schema="/schemas/desktop/gnome/lockdown/disable_save_to_disk"/> 
   <entry name="disable_command_line" mtime="1089888947"
          schema="/schemas/desktop/gnome/lockdown/disable_command_line"/> 
</gconf>

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 = <Alt>Print 
panel_minimized_size = 3 
tooltips_enabled = true 
menu_key = <Alt>F1 
confirm_panel_remove = true 
panel_animation_speed = panel-speed-medium 
highlight_launchers_on_mouseover = true 
run_key = <Alt>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 = <Alt>Print 
panel_minimized_size = 3 
tooltips_enabled = true 
menu_key = <Alt>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 <adminID> /home/<username>/.gnome2 
chmod -R 755 /home/<username>/.gnome2

Такая установка позволяет пользователю запускать приложения, связанные с иконками на рабочем столе, но не позволяет делать в них изменения. Это не слишком надежный способ защиты, поскольку он не помешает пользователю fiona переименовать каталог /home/fiona/.gnome2 и создать другой рабочий каталог со своими свойствами.

9.2.4 Настройка внешнего вида рабочего стола

В этом разделе мы рассмотрим методы настройки внешнего вида рабочего стола GNOME с использованием графической программы Центр Управления GNOME.

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

Чтобы открыть диалог для настроек, используйте в Nautilus URL

preferences://

Другой путь — выбрать пункт Параметры в Главном меню или набрать команду gnome-control-center в командной строке. Центр управления GNOME позволяет просматривать огромное число настроек. Например, на самом верхнем уровне будет предложен следующий список установок:

• Дополнительные параметры
• Специальные возможности
• Фон рабочего стола
• Мышь
• Клавиатура
• Комбинации клавиш клавиатуры
• Меню и панели инструментов
• Шрифт
• Хранитель экрана
• Звук
• Тема
• Окна
• Разрешение экрана
• Удаленный рабочий стол
• Смена пароля
• Сменные накопители
• Сервис Прокси

Центр управления GNOME допускает расширение своих функций, то есть, в него можно добавить окно, которое будет отвечать за настойки внешнего вида нового приложения. На Рис. 9.6 вы можете видеть окно настойки программы Thinkpad, которое было добавлено в центр управления. Для этого был использован пакет configure-thinkpad, который можно загрузить со страницы в интернете по адресу:

http://tpctl.sourceforge.net/

В начало

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.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 как показано в примере приведенном ниже.

#!/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.

[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 <domainname>. Эта команда создает учетную запись на контроллере домена и обеспечивает Linux-клиенту SID для авторизации.

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

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

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, как показано ниже

#%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. При помощи этого модуля во время авторизации создаются домашние каталоги пользователя, если они еще не существуют.

#%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 с параметрами пользователя.

username = ausres06 
password = password 
domain = itsoausnt

Правильным подходом будет включить процедуру монтирования удаленных каталогов в /etc/fstab, с тем чтобы удаленные каталоги монтировались одновременно с монтированием локальных файловых систем. Ниже приведен пример монтирования каталогов с файловой системой типа smbfs в файле /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, как показано ниже.

#!/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, для того чтобы предотвратить доступ к этим каталогам пользователей, не являющихся членами ав