Samba-3 в примерах. Часть I. Примеры сетевых конфигураций. Глава 6. Распределенная сеть на 2000 пользователей

Глава 6. Распределенная сеть на 2000 пользователей
Часть I. Примеры сетевых конфигураций

Дальше

Глава 6. Распределенная сеть на 2000 пользователей

6.1. Введение

6.1.1. Условия задачи

6.2. Обсуждение и анализ

6.2.1. Технические аспекты

6.2.1.1. Потребности пользователей

6.2.1.2. Природа сетевых протоколов Windows

6.2.1.3. Требования к управлению авторизацией

6.2.2. Политические аспекты

6.3. Внедрение

6.3.1. Основные моменты изученного

6.4. Вопросы и ответы

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

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

В этой главе планируется охватить вопросы, которые являются основополагающими при проектировании и внедрении постепенно увеличивающейся сети. Вы готовы? Хорошо, потому что самое время начинать.

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

6.1. Введение

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

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

6.1.1. Условия задачи

Начав с конфигурационных файлов сервера MASSIVE из Главы 5, «Делаем пользователей довольными», теперь вы имеете дело со сложностями, специфичными для большой распределенной сети. Ваша задача проста — оконтурить проблемы, рассмотреть альтернативы, и затем спроектировать и внедрить свое решение. Помните, ваши пользователи находятся в Лондоне, Лос-Анджелесе, Вашингтоне, и трех зданиях в Нью-Йорке. Значительная часть сотрудников имеют ноутбуки и перемещаются по всему миру. Некоторые звонят в офис, кое-кто использует VPN, и есть такие, которые просто перемещаются из здания в здание.

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

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

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

6.2. Обсуждение и анализ

В Главе 5, «Делаем пользователей довольными», вы применили сервер LDAP, который предоставлял бэкенд passdb для серверов Samba. Вы исследовали пути по ускорению оперированием профилями рабочих станций Windows и взяли под свой контроль производительность сети.

Внедрение бэкенда passdb, основанного на LDAP (в терминах Samba известного как ldapsam) или некоторых видов баз данных, которые могут быть расширены, это важнейшая мера для того, чтобы позволить развернуть первичный и вторичные (резервные, дополнительные) контроллеры домена на Samba (PDC/BDCs). Как вы видели, проблема бэкенда passdb в стиле tdbsam в том, что она не может реплицировать сама себя. Старый бэкенд паролей passdb в стиле smbpasswd, по сути представляющий из себя обычный текст, мог быть реплицирован посредством rsync, но smbpasswd неудобен тем, что он не поддерживает ряд свойств учетных записей, требующихся современным сетевым администраторам.

Новые свойства tdbsam поддерживают функциональность, которая схожа с ldapsam, но недостаточная инфраструктурная расширяемость крайне ограничивает область его применения. Это вызывает следующие вопросы: почему я не могу использовать только бэкенд, основанный на XML, почему не использовать бэкенд, основанный на SQL? Нет поддержки для этих инструментов? Чтобы ответить на эти вопросы, требуется сделать некоторое отступление.

Что такое Каталог? Каталог это хранилище сведений о взаимосвязанных объектах, которое доступно для быстрого поиска в нем информации, и он (поиск) осуществляется в специальной последовательной манере. Каталог отличается от базы данных тем, что из него чаще происходит чтение, а не запись/добавление/изменение информации. Как результат, информация размещена так, чтобы эффективнее осуществлялось чтение, а не поддержка транзакционных процессов.

Легковесный протокол доступа к сервису Каталога (Lightweight Directory Access Protocol (LDAP)) существенно отличается от традиционной базы данных. Он имеет простые поисковые средства, в которых реализован высоко совершенный механизм для управления авторизацией пользователей. LDAP предоставляет шасштабируемое средство для распределения хранилища данных, а также для хранения всех копий (slave) в синхронизированном состоянии с основным (master) хранилищем.

Samba это гибкая и мощная технология для управления общим доступом к файлам и принтерам. Она может использовать много внешних аутентификационных ресурсов и может быть частью общей инфраструктуры по управлению аутентификацией и авторизацией. Два наиболее важных внешних ресурса для больших сетей это Microsoft Active Directory и LDAP. В частности сети, которые желают избежать проприетарного решения от Microsoft Active Directory, конечно смотрят в сторону OpenLDAP.

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

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

6.2.1. Технические аспекты

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

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

(к началу страницы)

6.2.1.1. Потребности пользователей

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

Задача так скажем, не пустяковая. В некоторых частях света плохо даже с dial-up-соединениями, в то время как в других регионах политические запреты крайне ограничивают удовлетворение потребностей пользователей. Части мировой Интернет-инфраструктуры остаются заблокированными по причинам, которые не обсуждаются в этой книге.

Решения должны касаться вопросов как будут сохраняться данные, как будут реплицироваться (если будут) и какова будет пропускная способность сети. Например, одно из примененных решений может дать каждому офису свое основное файловое хранилище, которое может быть реплицировано на центральное хранилище в Нью-Йорке. Это позволит резервировать данные целиком в одном месте. Инструментом синхронизации мог бы послужить rsync, запущенный посредством cron. Мобильные пользователи могут использовать автономное файловое хранилище под Windows XP Professional. Таким образом они могут синхронизировать все файлы, которые изменялись после каждого входа в сеть.

Независимо от того, какой способ вам приглянулся, требования к пропускной способности сети для обеспечения удовлетворительной производительности являются существенными, даже если только 10 процентов штатных сотрудников будут использовать данные повсеместно. Компания включающая 3500 наемных работников, 280 из которых являются мобильными пользователями, использующие подобным образом распределенные сети, нуждаются, по крайней мере, в скорости 2 Мбит/сек для соединения между британским и американским офисами. Даже если пропускная способность больше, чем 2 Мбит/сек, эта компания отказалась от какой-либо попытки использование перемещаемых профилей для мобильных пользователей. В этот раз перемещаемый профиль занимает в среднем 480 Кб, в то время как сегодня минимальный размер перемещаемого профиля Windows XP Professional включает передачу около 750 Кб от сервера профилей и от клиента.

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

6.2.1.2. Природа сетевых протоколов Windows

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

Один из путей уменьшения влияния трафика входа в сеть пользователей на ширину полосы пропускания сети является перенаправление папок. В Главе 5, «Делаем пользователей довольными», вы внедрили это в новой конфигурации рабочих станций Windows XP Professional. Когда папки рабочей станции, такие как «Мои документы», перенаправляются на сетевой диск, они также должны быть исключены из синхронизации во время входа и выхода на или с сервера. Перенаправление папок является аналогом подключения сетевых дисков.

Разумеется, сетевые приложения должны запускаться только с локальных серверов приложений. Как правило, даже с шириной полосы пропускания до 2 Мб/сек, ни для кого из тех, кто работает в Лондонском офисе, не имело бы смысл запускать приложения с сервера, находящегося в Нью-Йорке.

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

Когда пользователь клиентского компьютера с Windows NT4/200x/XP Professional входит в сеть, должны произойти некоторые важные вещи:

клиент получает IP адрес от сервера DHCP (DHCP необходим, чтобы клиенты могли перемещаться между офисами);
клиент должен зарегистрировать себя на WINS и/или DNS сервере;
клиент должен определить ближайший контроллер домена;
клиент должен войти в контроллер домена и получить, как часть процесса входа в сеть, информацию о нахождении профиля пользователя, загрузить его, соединиться с перенаправленными папками и установить соединение со всеми сетевыми дисками и принтерами;
контроллер домена должен иметь возможность назначить все права пользователя перед тем, как процесс входа будет полностью завершен.

С учетом того, что эта книга о пакете Samba, и что он реализует семантику стиля домена Windows NT4, имеет смысл сравнивать Samba и AD лишь до той степени, пока пересекаются протоколы входа в систему и принципы, связанные с этим. Следующая информация относится исключительно к взаимодействию между рабочими станциями Windows XP Professional и сервером Samba-3.0.20. В представленном ниже обсуждении предполагается наличие DHCP и WINS.

Как только запускается рабочая станция Windows, она получает IP адрес. Непосредственно за этим следует регистрация ее имени через широковещательную рассылку (broadcast) и однонаправленную (Unicast) регистрацию, которая обращена к серверу WINS.

Затем, учитывая то, что клиент уже является членом домена, он направляет прямой (Unicast) запрос к серверу WINS о списке IP адресов контроллеров домена (NetBIOS имя типа 0x1C). Сервер WINS откликается с запрошенной информацией.

Клиент посылает два netlogon mailslot запроса в локальную сеть и каждому из IP адресов, возвращенных сервером WINS. Какими бы не были ответы на этот запрос, сначала они оказываются у того клиента Windows XP, который пытается войти в сеть. Сообщения mailslot используют широковещательную рассылку по UDP (UDP broadcast) в локальной сети и прямую однонаправленную по UDP (UDP Unicast directed) каждому компьютеру из списка-отклика сервера WINS на запрос о списке контроллеров домена.

Процесс входа в сеть начинается с согласования протоколов SMB/CIFS, которые должны использоваться; это сопровождается обменом информацией, которая в конечном счете передает клиенту права, с которыми он пытается войти в сеть. Сервер входа в систему (logon server) теперь должен одобрить дальнейшее установление подключения, но давайте пока остановимся на этом этапе. Основное внимание здесь должно находится вокруг определения потребностей сетевой инфраструктуры. Второй момент, который мы должны определить, что произойдет, если локальный контроллер домена даст будет недоступен или на нем произойдет сбой?

В большинстве случаев ближайший контроллер домена ответит через широковещательную netlogon mailslot рассылку. Исключение из этого правила происходит тогда, когда ближайший контроллер домена слишком занят (перегружен) или вышел из строя. Здесь присутствует один важный момент. Необходимо, чтобы в каждом сегменте сети были по крайней мере два контроллера домена. Так как может быть только один первичный контроллер домена PDC, все дополнительные контроллеры домена по определению являются резервными (вторичными) BDC.

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

6.2.1.3. Требования к управлению авторизацией

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

К сожалению, сетевые ресурсы имеют тенденцию иметь их собственные средства управления авторизацией, качество и управляемость которых варьируется от весьма бледного до исключительно хорошего. Корпорации, которые используют гетерогенные среды (сети с различными ОС), вскоре выясняют, что очень мало систем были спроектированы для обеспечения взаимодействия. Например, системы UNIX имеют для каждого пользователя независимую базу данных. Sun Microsystems разработала средство, называемое Yellow Pages, которое было переименовано после того, как телефонная компания возразила против использования ее торговой марки. То, что когда-то называлось Yellow Pages, теперь известно как Network Information System (NIS).

NIS добилась серьезного развития во всем пространстве UNIX/VMS за короткий промежуток времени, удержала позиции и используется последние десять лет. Проблемы безопасности и неотъемлемые ограничения стали основанием для того, чтобы не получить широкого распространения за пределами мира UNIX и не стать универсальной. Sun пересмотрела вопросы безопасности и выпустила новое решение NIS+, но даже оно стало жертвой увеличивающихся потребностей, как например интереса к службе Каталогов, которая может быть связана с другими информационными системами и завоевывает все бОльшую популярность.

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

Сегодня сетевой мир нуждается в масштабируемой, распределенной инфраструктуре управления авторизацией, обычно называемой Каталогом. В настоящий момент самые популярные технологии для этого сервис Microsoft Active Directory и ряд реализаций LDAP.

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

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

В Главе 5, «Делаем пользователей довольными» вы развернули один сервер LDAP на всю сеть. Это может работать в небольших сетях, но почти наверняка не сможет удовлетворить потребности больших и сложных сетей. Следующий раздел расскажет, как вы можете использовать один первичный (основной, master) сервер LDAP и несколько дополнительных (slave) серверов.

То, каким образом развернуть основные/дополнительные (master/slave) серверы LDAP в контексте распределенной сети на 2000 пользователей, это вопрос, на который стоит услышать ответ.

Одной из весьма привлекательных возможностей является создание одного большого распределенного домена. Практическое внедрение этого проекта (см. рисунок 6.6. ) требует размещения достаточного количества BDC в отдельно взятом месте. Также сетевые администраторы должны убедиться, что профили не перемещаются по каналам зон, за исключением абсолютно неизбежных мер (дословно network administrators must make sure that profiles are not transferred over the wide-area links, except as a totally unavoidable measure). Проект сети должен соблюдать баланс между риском потери производительности пользователей и стоимостью обслуживания и управления сетью.

Рисунок 6.6. Топология сети на 2000 пользователей, проект A

Топология сети на 2000 пользователей, проект A

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

Рисунок 6.7. Топология сети на 2000 пользователей, проект Б

Топология сети на 2000 пользователей, проект Б

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

Когда Samba-3 настроена, чтобы использовать бэкенд LDAP, она хранит информацию об учетных записях домена в записях Каталога. Эти записи включают SID домена. Непредумышленная, но используемая сторона этого эффекта заключается в том, что становится возможным работать с более, чем одним PDC в распределенной сети.

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

Эта концепция не полностью достоверна, хотя мы не можем увидеть причин, почему это не будет работать. Важный аспект состоит в следующем: имя домена должно быть одинаково во всех местах. Каждый сегмент сети должен иметь свой собственный сервер WINS. Имя PDC должно быть одинаковым во всех местах; это требует использования не NetBIOS имени PDC, а псевдонима, так, чтобы по можно было получить доступ глобально, используя псевдоним, а не основное имя PDC. Один основной сервер LDAP может размещаться в Нью-Йорке, а множество дополнительных (slave) серверов LDAP в каждом сетевом сегменте. Наконец, каждый из резервных контроллеров домена (BDC) должен перехватывать управление при отказе серверов LDAP, которые фактически являются дополнительными серверами в локальных сегментах.

С одним основным сервером LDAP все обновления производятся на одном сервере. В том случае, когда это станет чересчур ненадежным или возникнут ограничения в ширине полосы пропускания сети, можно внедрить делегирование домена LDAP. Это известно, как разделенная (partitioned) (или мультираздельная, multiple partition) база данных LDAP и как распределенный Каталог LDAP.

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

6.2.2. Политические аспекты

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

6.3. Внедрение

Samba-3 имеет возможность использовать многопарольные бэкенды (аутентификации и авторизации). Рисунок 6.1. показывает, как Samba использует winbind, LDAP и NIS в традиционной системе базы данных паролей. Эта диаграмма показывает только механизм для аутентификации и авторизации (получение UID/GID UNIX), используя специальные системы.

Рисунок 6.1. Samba и способы поиска бэкенда аутентификации

Samba и способы поиска бэкенда аутентификации

Samba может использовать такие аутентификационные базы данных как smbpasswd, tdbsam, xmlsam, и mysqlsam. Также пароли, разумеется, могут быть сохранены в бэкенде LDAP ldapsam. Для LDAP при операциях в распределенной сети предпочтительнее бэкенд паролей passdb.

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

passdb backend = ldapsam:ldap://master.abmas.biz

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

Рисунок 6.2. Конфигурация Samba для использования одиночного сервера LDAP

Конфигурация Samba для использования одиночного сервера LDAP

Дополнительный сервер LDAP, перехватывающий управление при отказе, легко может быть добавлен второй записью для сервера такого типа в запись ldapsam, как показано ниже (заметьте специальное использование двойных кавычек):

...
passdb backend = ldapsam:"ldap://master.abmas.biz ldap://slave.abmas.biz"
...

Такая конфигурация укажет Samba использовать основной сервер LDAP, и, если необходимо, дополнительный (slave), перехватывающий управление при отказе, как показано на рисунке 6.3..

Рисунок 6.3. Конфигурация Samba для использования двух (наряду с перехватывающим управление при отказе, Fail-over) серверов LDAP

Конфигурация Samba для использования двух (наряду с перехватывающим управление при отказе, Fail-over) серверов LDAP

Некоторые люди пытаются это сделать без использования двойных кавычек, они создают запись такого вида:

...
passdb backend = ldapsam:ldap://master.abmas.biz ldapsam:ldap://slave.abmas.biz
...

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

Рисунок 6.4. Ошибочная конфигурация Samba для использования двойной базы данных LDAP, не используйте это!

Ошибочная конфигурация Samba для использования двойной базы данных LDAP, не используйте это!

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

Рисунок 6.5. Конфигурация Samba для использования двух баз данных LDAP, следствие дополнения

Конфигурация Samba для использования двух баз данных LDAP, следствие дополнения

Примечание: когда задано использование ldapsam дважды, как показано здесь, является обязательным то условие, что два Каталога LDAP не будут пересекаться. Если записи основного сервера LDAP, как и дополнительного, обновят всю базу данных LDAP, данные могут быть потеряны или нарушены. Это решение может безопасно использоваться в нескольких бэкендах LDAP, только если они полностью отделены друг от друга.

Предположим, что вы работаете с сетью, которая схожа с той, что была описана в Главе 5, «Делаем пользователей довольными». Следующие шаги позволят подготовить основной и дополнительный сервер OpenLDAP.

Шаги по внедрению дополнительного (вторичного, резервного, slave) сервера LDAP:

1. Войдите на основной сервер LDAP как root. Вы собираетесь изменить конфигурацию сервера LDAP, поэтому убедитесь, что он временно остановлен. На SUSE Linux остановить сервер LDAP можно так:

root#  rcldap stop

На Red Hat Linux так:

root#  service ldap stop

2. Отредактируйте файл /etc/openldap/slapd.conf так, чтобы его содержимое стало похоже на пример 6.3.1..

3. Создайте файл admin-accts.ldif следующего содержания:

dn: cn=updateuser,dc=abmas,dc=biz
objectClass: person
cn: updateuser
sn: updateuser
userPassword: not24get

dn: cn=sambaadmin,dc=abmas,dc=biz
objectClass: person
cn: sambaadmin
sn: sambaadmin
userPassword: buttercup

4. Добавьте учетную запись updateuser на основной сервер LDAP:

root#  slapadd -v -l admin-accts.ldif

5. Выберите подходящее место для папки, в которую можно выгрузить (to dump) содержимое сервера LDAP. Дамп-файл (и LDIF-файл) используется, чтобы сделать предзагрузку базы данный дополнительного (slave) сервера LDAP. Вы можете выгрузить (сделать дамп базы) базу данных таким образом:

root#  slapcat -v -l LDAP-transfer-LDIF.txt

Каждая запись будет помещена в файл.

6. Скопируйте этот файл на дополнительный (slave) сервер LDAP. Подходящей папкой будет, например, папка /etc/openldap/preload.

7. Войдите на дополнительный (slave) сервер LDAP под учетной записью root. Теперь настройте сервер, приведите файл /etc/openldap/slapd.conf к содержимому, показанному в примере 6.3.2..

8. Перейдите в папку, где находится файл LDAP-transfer-LDIF.txt (/etc/openldap/preload) и выполните команду:

root#  slapadd -v -l LDAP-transfer-LDIF.txt

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

added: "dc=abmas,dc=biz" (00000001)
added: "cn=sambaadmin,dc=abmas,dc=biz" (00000002)
added: "cn=updateuser,dc=abmas,dc=biz" (00000003)
added: "ou=People,dc=abmas,dc=biz" (00000004)
added: "ou=Groups,dc=abmas,dc=biz" (00000005)
added: "ou=Computers,dc=abmas,dc=biz" (00000006)
added: "uid=Administrator,ou=People,dc=abmas,dc=biz" (00000007)
added: "uid=nobody,ou=People,dc=abmas,dc=biz" (00000008)
added: "cn=Domain Admins,ou=Groups,dc=abmas,dc=biz" (00000009)
added: "cn=Domain Users,ou=Groups,dc=abmas,dc=biz" (0000000a)
added: "cn=Domain Guests,ou=Groups,dc=abmas,dc=biz" (0000000b)
added: "uid=bobj,ou=People,dc=abmas,dc=biz" (0000000c)
added: "sambaDomainName=MEGANET2,dc=abmas,dc=biz" (0000000d)
added: "uid=stans,ou=People,dc=abmas,dc=biz" (0000000e)
added: "uid=chrisr,ou=People,dc=abmas,dc=biz" (0000000f)
added: "uid=maryv,ou=People,dc=abmas,dc=biz" (00000010)
added: "cn=Accounts,ou=Groups,dc=abmas,dc=biz" (00000011)
added: "cn=Finances,ou=Groups,dc=abmas,dc=biz" (00000012)
added: "cn=PIOps,ou=Groups,dc=abmas,dc=biz" (00000013)

9. Сейчас запустите сервер LDAP и настройте, чтобы он запускался автоматически после перезагрузки системы:

root#  rcldap start
root#  chkconfig ldap on

На Red Hat Linux сделайте это так:

root#  service ldap start
root#  chkconfig ldap on

10. Вернитесь на основной (master) сервер LDAP, запустите сервер LDAP, а также синхронизирующий демон slurpd:

root#  rcldap start
root#  chkconfig ldap on
root#  rcslurpd start
root#  chkconfig slurpd

На Red Hat Linux выполните соответствующие команды для запуска slurpd.

11. Теперь на основном сервере LDAP вы можете добавить учетную запись, чтобы проверить, работает ли репликация. С учетом конфигурации, показанной в Главе 5, «Делаем пользователей довольными», выполните:

root#  /var/lib/samba/sbin/smbldap-useradd -a fruitloop

12. На дополнительном (slave) сервере LDAP пройдите в каталог /var/lib/ldap. Здесь должен находиться файл replogfile Если репликация работает, как нужно, у этого файла должно быть такое содержимое:

time: 1072486403
dn: uid=fruitloop,ou=People,dc=abmas,dc=biz
changetype: modify
replace: sambaProfilePath
sambaProfilePath: \\MASSIVE\profiles\fruitloop
-
replace: sambaHomePath
sambaHomePath: \\MASSIVE\homes
-
replace: entryCSN
entryCSN: 2003122700:43:38Z#0x0005#0#0000
-
replace: modifiersName
modifiersName: cn=Manager,dc=abmas,dc=biz
-
replace: modifyTimestamp
modifyTimestamp: 20031227004338Z
-

13. Убедившись, что первый дополнительный сервер LDAP нормально работает, вы можете развернуть еще один дополнительный сервер LDAP.

14. На каждом компьютере (и PDC и BDC) после создания файлов из примеров 6.3.3., 6.3.4., 6.3.5.и 6.3.6., 6.3.7. соответственно, выполните следующую команду:

root# smbpasswd -w buttercup

Это установит в файл secrets.tdb пароль, который потребуется Samba для управления учетными записями основного сервера LDAP.
(к началу страницы)

6.3.1. Основные моменты изученного

При использовании Samba-3 в качестве контроллера домена, для полноценного функционирования BDC неотъемлемой частью является использование LDAP;

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

(к началу страницы)

Пример 6.3.1. Конфигурационный файл LDAP /etc/openldap/slapd.conf, основной (master) сервер

include     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/samba.schema

pidfile     /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

database    bdb
suffix      "dc=abmas,dc=biz"
rootdn      "cn=Manager,dc=abmas,dc=biz"

# rootpw = not24get
rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

replica     host=lapdc.abmas.biz:389
            suffix="dc=abmas,dc=biz"
            binddn="cn=updateuser,dc=abmas,dc=biz"
            bindmethod=simple credentials=not24get

access to attrs=sambaLMPassword,sambaNTPassword
           by dn="cn=sambaadmin,dc=abmas,dc=biz" write
           by * none

replogfile  /var/lib/ldap/replogfile

directory   /var/lib/ldap

# Indices to maintain
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub

Пример 6.3.2. Конфигурационный файл LDAP /etc/openldap/slapd.conf, дополнительный (slave) сервер

include     /etc/openldap/schema/core.schema
include     /etc/openldap/schema/cosine.schema
include     /etc/openldap/schema/inetorgperson.schema
include     /etc/openldap/schema/nis.schema
include     /etc/openldap/schema/samba.schema

pidfile     /var/run/slapd/slapd.pid
argsfile    /var/run/slapd/slapd.args

database    bdb
suffix      "dc=abmas,dc=biz"
rootdn      "cn=Manager,dc=abmas,dc=biz"

# rootpw = not24get
rootpw      {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

access to *
            by dn=cn=updateuser,dc=abmas,dc=biz write
            by * read

updatedn    cn=updateuser,dc=abmas,dc=biz
updateref   ldap://massive.abmas.biz

directory   /var/lib/ldap

# Indices to maintain
index objectClass           eq
index cn                    pres,sub,eq
index sn                    pres,sub,eq
index uid                   pres,sub,eq
index displayName           pres,sub,eq
index uidNumber             eq
index gidNumber             eq
index memberUID             eq
index sambaSID              eq
index sambaPrimaryGroupSID  eq
index sambaDomainName       eq
index default               sub

Пример 6.3.3. Файл smb.conf, основной контроллер домена, часть А

# Global parameters 
 
[global] 
unix charset = LOCALE 
workgroup = MEGANET2 
passdb backend = ldapsam:ldap://massive.abmas.biz 
username map = /etc/samba/smbusers 
log level = 1 
syslog = 0 
log file = /var/log/samba/%m 
max log size = 0 
smb ports = 139 
name resolve order = wins bcast hosts 
time server = Yes 
printcap name = CUPS 
add user script = /opt/IDEALX/sbin/smbldap-useradd -m '%u' 
delete user script = /opt/IDEALX/sbin/smbldap-userdel '%u' 
add group script = /opt/IDEALX/sbin/smbldap-groupadd -p '%g' 
delete group script = /opt/IDEALX/sbin/smbldap-groupdel '%g' 
add user to group script = /opt/IDEALX/sbin/smbldap-groupmod -m '%g' '%u' 
delete user from group script = /opt/IDEALX/sbin/smbldap-groupmod -x '%g' '%u' 
set primary group script = /opt/IDEALX/sbin/smbldap-usermod -g '%g' '%u' 
add machine script = /opt/IDEALX/sbin/smbldap-useradd -w '%u' 
shutdown script = /var/lib/samba/scripts/shutdown.sh 
abort shutdown script = /sbin/shutdown -c 
logon script = scripts\logon.bat 
logon path = \\%L\profiles\%U 
logon drive = X: 
domain logons = Yes 
domain master = Yes 
wins support = Yes 
ldap suffix = dc=abmas,dc=biz 
ldap machine suffix = ou=People 
ldap user suffix = ou=People 
ldap group suffix = ou=Groups 
ldap idmap suffix = ou=Idmap 
ldap admin dn = cn=sambaadmin,dc=abmas,dc=biz 
idmap backend = ldap://massive.abmas.biz 
idmap uid = 10000-20000 
idmap gid = 10000-20000 
printer admin = root 
printing = cups

Пример 6.3.4. Файл smb.conf, основной контроллер домена, часть Б

[IPC$] 
path = /tmp 
 
[accounts] 
comment = Accounting Files 
path = /data/accounts 
read only = No 
 
[service] 
comment = Financial Services Files 
path = /data/service 
read only = No 
 
[pidata] 
comment = Property Insurance Files 
path = /data/pidata 
read only = No 
 
[homes] 
comment = Home Directories 
valid users = %S 
read only = No 
browseable = No 
 
[printers] 
comment = SMB Print Spool 
path = /var/spool/samba 
guest ok = Yes 
printable = Yes 
browseable = No

Пример 6.3.5. Файл smb.conf, основной контроллер домена, частьВ

[apps] 
comment = Application Files 
path = /apps 
admin users = bjones 
read only = No 
 
[netlogon] 
comment = Network Logon Service 
path = /var/lib/samba/netlogon 
admin users = root, Administrator 
guest ok = Yes 
locking = No 
 
[profiles] 
comment = Profile Share 
path = /var/lib/samba/profiles 
read only = No 
profile acls = Yes 
 
[profdata] 
comment = Profile Data Share 
path = /var/lib/samba/profdata 
read only = No 
profile acls = Yes 
 
[print$] 
comment = Printer Drivers 
path = /var/lib/samba/drivers 
write list = root 
admin users = root, Administrator

Пример 6.3.6. Файл smb.conf, резервный контроллер домена, часть А

# Global parameters 
 
[global] 
unix charset = LOCALE 
workgroup = MEGANET2 
netbios name = BLDG1 
passdb backend = ldapsam:ldap://lapdc.abmas.biz 
username map = /etc/samba/smbusers 
log level = 1 
syslog = 0 
log file = /var/log/samba/%m 
max log size = 50 
smb ports = 139 
name resolve order = wins bcast hosts 
printcap name = CUPS 
show add printer wizard = No 
logon script = scripts\logon.bat 
logon path = \\%L\profiles\%U 
logon drive = X: 
domain logons = Yes 
os level = 63 
domain master = No 
wins server = 192.168.2.1 
ldap suffix = dc=abmas,dc=biz 
ldap machine suffix = ou=People 
ldap user suffix = ou=People 
ldap group suffix = ou=Groups 
ldap idmap suffix = ou=Idmap 
ldap admin dn = cn=sambaadmin,dc=abmas,dc=biz 
utmp = Yes 
idmap backend = ldap://massive.abmas.biz 
idmap uid = 10000-20000 
idmap gid = 10000-20000 
printing = cups 
 
[accounts] 
comment = Accounting Files 
path = /data/accounts 
read only = No 
 
[service] 
comment = Financial Services Files 
path = /data/service 
read only = No

Пример 6.3.7. Файл smb.conf, резервный контроллер домена, часть Б

[pidata] 
comment = Property Insurance Files 
path = /data/pidata 
read only = No 
 
[homes] 
comment = Home Directories 
valid users = %S 
read only = No 
browseable = No 
 
[printers] 
comment = SMB Print Spool 
path = /var/spool/samba 
guest ok = Yes 
printable = Yes 
browseable = No 
 
[apps] 
comment = Application Files 
path = /apps 
admin users = bjones 
read only = No 
 
[netlogon] 
comment = Network Logon Service 
path = /var/lib/samba/netlogon 
guest ok = Yes 
locking = No 
 
[profiles] 
comment = Profile Share 
path = /var/lib/samba/profiles 
read only = No 
profile acls = Yes 
 
[profdata] 
comment = Profile Data Share 
path = /var/lib/samba/profdata 
read only = No 
profile acls = Yes

(к началу страницы)

6.4. Вопросы и ответы

1. Правда ли, что DHCP использует значительную часть WAN полосы пропускания?
2. Много ли фоновых соединений проходит между основным (master) и дополнительными (slave) серверами LDAP?
3. LDAP имеет базу данных. LDAP это не только своеобразный пользовательский интерфейс базы данных?
4. Может ли Active Directory включать информацию об учетных записях сервера OpenLDAP?
5. Какие есть составляющие перемещаемого профиля? Какого размера каждая составляющая?
6. Может ли папка My Documents (Мои документы) сохраняться на сетевом диске?
7. Какое количество ширины полосы пропускания требует для себя WINS?
8. Сколько должно быть дополнительных (резервных) контроллеров домена (BDC)? Какое число клиентов MS Windows должно приходиться на один BDC?
9. Я слышал, что вы можете хранить учетные записи NIS в LDAP. Не является ли только LDAP самым разумным способом для запуска сервера NIS?
10. В чем основное преимущество использования сервера приложений?

1. Правда ли, что DHCP использует значительную часть WAN полосы пропускания?

- Разумной практикой является размещение серверов DHCP в каждом сегменте сети. Как правило, должно быть два сервера DHCP на каждый сегмент. Это означает, что если один сервер выйдет из строя, то всегда есть другой, чтобы обслужить потребности пользователей. DHCP требует использования только широковещательных протоколов UDP (UDP broadcast protocols). Возможно запускать ретрансляцию DHCP (DHCP Relay agent) на все роутеры. Это позволит запускать несколько серверов DHCP.

Сетевой адрес DHCP запрашивается и подтверждается, как правило, примерно в шести UDP пакетах. Величина пакетов от 60 до 568 байт. Давайте рассмотрим сеть, в которой есть 300 клиентов DHCP и где аренда IP адреса осуществляется на 24 часа. При этом условии все клиенты обновляют свои IP адреса каждые 24 часа. Если мы примем среднюю величину пакета за максимальную (чтобы быть уверенным), и мы обладаем сетевым соединением 128 Кбит/сек, насколько существенным будет DHCP-трафик, если при этом вдобавок используется ретрансляция DHCP (DHCP Relay)?

Мне кажется, это плохой проект, но давайте сделаем расчеты:

Пропускная способность сети в день: 128,000 (Kbits/s) / 8 (bits/byte) 
                             x 3600 (sec/hr) x 24 (hrs/day)= 2288 Mbytes/day.

DHCP трафик:          300 (clients) x 6 (packets) 
                                       x 512 (bytes/packet) = 0.9 Mbytes/day.

Из этого можно увидеть, что воздействие трафика будет минимальным.

Даже если каждый DHCP настроен на динамическое обновление DNS (DDNS), влияние этого трафика будет не более того, который требуется для обновления IP адресов и он будет незначительным в большинстве случаев.

2. Много ли фоновых соединений проходит между основным (master) и дополнительными (slave) серверами LDAP?

- Процесс, который управляет репликацией данных от основного (master) сервера LDAP к дополнительному (slave) называется slurpd. Slurpd остается «висеть в фоне» после того, как должно было быть передано обновление. Проходящий через дополнительный LDAP трафик обновления (добавление/модификация/удаление) учетных записей двух пользователей требует менее, чем 10 Кб трафика.

3. LDAP имеет базу данных. LDAP это не только своеобразный пользовательский интерфейс базы данных?

- LDAP хранит свои данные в своего рода базе данных. Фактически, бэкенд LDAP это система хранения данных специализированного применения. Этот вид базы данных индексированы так, что записи в ней могут быть быстро найдены, но такая база данных не является универсальной, и может использоваться только в особых предопределенных случаях. Общие внешние приложения не получают доступа к данным. Этот тип базы данных также используется в серверах SQL. И сервер SQL и сервер LDAP предоставляют способы доступа к данным. Сервер SQL имеет транзакционную ориентацию и обычно применяются внешними программами для выполнения специальных запросов даже «параллельно» таблицам данных. Клиентская часть LDAP это специально сконструированный инструмент поисковой ориентации, проектирующийся вокруг характерных простых запросов. Термин database (база данных) в данном случае в большой степени перегружен, и таким образом применяется не совсем правильно.

4. Может ли Active Directory включать информацию об учетных записях сервера OpenLDAP?

- Нет, по крайней мере, не напрямую. Возможно предоставить Active Directory из и/или в базу(ы) данных OpenLDAP путем использования сервера метаКаталога (metadirectory server). Microsoft MMS (сейчас называемый MIIS, Microsoft Internet Information Server, информационный интернет-сервер корпорации Microsoft (веб-сервер, интегрированный в сервер Windows NT)) может присоединяться к OpenLDAP, используя стандартные запросы и дополнения.

5. Какие есть составляющие перемещаемого профиля? Какого размера каждая составляющая?

- Перемещаемый профиль включает:

Такие папки, как Desktop (Рабочий стол), My Documents (Мои документы), My Pictures (Мои рисунки), My Music (Моя музыка), Internet Files, Cookies, Application Data, Local Settings, и другие, более подробно см. Главу 5, «Делаем пользователей довольными», рис. 5.3..

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

постоянная или перезаписываемая часть, в которой обычно несколько файлов (2-5 Кб информации).

Загружаемый файл реестра NTUSER.DAT ,который модифицирует ветку HKEY_LOCAL_USER, может быть от 0.4 до 1.5 Мб.

Файлы Microsoft Outlook PST могут храниться в папке Local Settings\Application Data, один такой файл может занимать до 2Гб.

6. Может ли папка My Documents (Мои документы) сохраняться на сетевом диске?

- Да. Более того, правильнее, если такие папки будут перенаправлены на сетевые общие ресурсы. Не требуется какое-то особенное подключение сетевого диска. Настройки реестра позволяют осуществлять перенаправление напрямую к ресурсу UNC через назначение буквы диска взамен UNC имени (UNC name, полное имя ресурса в сети). См. раздел 5.7.1..

7. Какое количество ширины полосы пропускания требует для себя WINS?

- Информация кэша клиентов MS Windows получена из WINS-запросов (WINS lookups) в локальный кэш имен NetBIOS. Это обеспечивает минимальное количество WINS-запросов. В сети с 3500 клиентами MS Windows и центральным сервером WINS, ширина полосы пропускания, где ее величина потребовала тщательного планирования, в среднем для восьмичасового рабочего дня была менее 30 Кб/сек. Анализ сетевого трафика за шестинедельный период показывает, что общий фоновый трафик отнял около 11% от доступной ширины полосы пропускания и составил 64 Kб/сек. Фоновый трафик включал доменную репликацию, запросы WINS, запросы DNS и аутентификационный трафик. Каждый из 11 офисов-филиалов имел эту долю в 64 Kб/сек, а также 1.5 Мб/сек основных соединений, объединяющих в себе соединения офисов-филиалов и Интернет-трафик.

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

8. Сколько должно быть дополнительных (резервных) контроллеров домена (BDC)? Какое число клиентов MS Windows должно приходиться на один BDC?

- Рекомендуется иметь по крайней мере один BDC в сегменте сети, который обслуживается одним PDC. Реальные требования очень варьируются в зависимости от рабочей нагрузки на каждый из дополнительных серверов и нагрузки, требующейся отдельно взятому клиенту. Я видел сети, в которых был один BDC на обслуживании у 200 клиентов, и видел сети, где 20 клиентов обслуживал один BDC. В частности, в одной компании, которая имела чертежный офис и в нем 30 CAM/CAD операторов, обслуживаемых одним файл-сервером, принт-сервером и сервером приложений. Несмотря на то, что все три были дополнительными, обычно только принт-сервер обслуживал запросы на сетевой вход сразу после того, как первые 10 пользователей начинали использовать сеть. Это являлось отражением нагрузки как на сервер приложений так и на файл-сервер.

Ответ может быть как неудовлетворительным, так и верным, что все зависит от сети и от вида нагрузки на сервер.

9. Я слышал, что вы можете хранить учетные записи NIS в LDAP. Не является ли только LDAP самым разумным способом для запуска сервера NIS?

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

10. Могу ли я использовать NIS в пространстве LDAP?

- Нет. База данных NIS не имеет средств для хранения шифрованных паролей Microsoft и не имеет дело с типами данных, необходимыми для функциональной совместимости с сетью Microsoft Windows. Использование LDAP c Samba требует ряда схем, одна из которых схема NIS, но которая является расширением схемы под Samba.
(к началу страницы)

Назад
Глава 5. Делаем пользователей довольными

Содержание

Дальше
Часть II. Включение в домен, миграция

Tutorial to Bookkeeping 101: everything you need to know. www.forumros.com