8. Репозиторий NFS netgroup на основе OpenLDAP для autofs

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

ВНИМАНИЕ! Прежде чем переходить к следующему разделу и добавлять группы oracle и itdept, ознакомьтесь с проблемой, описанной в разделе 8.4. Для того, чтобы она у Вас не появилась, можете прямо сейчас выполнить инструкции раздела 8.4.2 и потом вернуться сюда. А можете и не выполнять. Зависит от того, является ли это проблемой в Вашем конкретном случае.

8.1 Настройка сервера OpenLDAP

Где работаем: ldap-srv

Нам понадобится схема наборов данных Network Information Service (NIS). В разделе 2.5 мы уже добавили её в конфигурацию сервера каталогов. Проверим, что она на месте:

$  ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=schema,cn=config dn | grep nis
Enter LDAP Password:
dn: cn={10}nis,cn=schema,cn=config

Проверим, содержит ли эта схема атрибуты для netgroup:

$ sudo ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn={10}nis,cn=schema,cn=config | grep NAME | cut -d' ' -f5 | grep -i netgroup
Enter LDAP Password:
'memberNisNetgroup'
'nisNetgroupTriple'
'nisNetgroup'

Хорошо. Но у нас пока нет никаких записей, которые используют эти атрибуты. Создадим LDIF-файл 8.1-netgroup.ldif, который добавит в службу каталогов контейнер для конфигураций netgroup и несколько примеров групп netgroup:

# Контейнер для конфигураций netgroup
dn: ou=netgroup,ou=services,dc=example,dc=com
ou: netgroup
objectClass: top
objectClass: organizationalUnit
description: NFS Netgroups

# Первый пример группы netgroup
dn: cn=oracle,ou=netgroup,ou=services,dc=example,dc=com
objectClass: top
objectClass: nisNetgroup
cn: oracle
nisNetgroupTriple: (oracle.example.com,,)
description: All Oracle machines

# Второй пример группы netgroup
dn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=com
objectClass: top
objectClass: nisNetgroup
cn: itdept
nisNetgroupTriple: (ldap-client.example.com,,)
description: IT department machines

Будьте осторожны с использованием FQDN в наборах netgroup!

Если Вы сделаете это неверно, ничего не заработает. Например, такая запись ошибочна:

nisNetgroupTriple: (ldap-client.example.com,,example.com)

А такая запись — верная:

nisNetgroupTriple: (ldap-client.example.com,,)

Такой вариант записи тоже допускается:

nisNetgroupTriple: (ldap-client,,example.com)

Выберите синтаксис, который больше по душе, и придерживайтесь его.

Добавим новые записи в службу каталогов:

$  ldapadd -xZZWD cn=admin,dc=example,dc=com -f 8.1-netgroup.ldif
Enter LDAP Password:
adding new entry "ou=netgroup,ou=services,dc=example,dc=com"
adding new entry "cn=oracle,ou=netgroup,ou=services,dc=example,dc=com"
adding new entry "cn=itdept,ou=netgroup,ou=services,dc=example,dc=com"

8.2 Настройка сервера NFS

Где работаем: nfs-srv

Наш сервер NFS уже интегрирован с сервером каталогов в соответствии с разделом 7. Нижеследующие манипуляции без этого не заработают.

Измените значение конфигурации netgroup в файле /etc/nsswitch.conf, чтобы информация о группах netgroup запрашивалась только у сервера каталогов:

netgroup: ldap

Проверим, что возвращает запрос конфигурации netgroup к нашему серверу каталогов:

$ getent netgroup
Перечисление не поддерживается для netgroup

Хм, интересно. Так как netgroup, в сущности, — механизм безопасности, у нас не получится просмотреть весь их список сразу. Значит, надо проверить их по-отдельности:

$ getent netgroup oracle
oracle                (oracle.example.com,,)
$ getent netgroup itdept
itdept                (ldap-client.example.com,,)

Вот так выглядит запись о событии запроса getent netgroup itdept в журнале slapd.log на сервере каталогов:

slapd[870]: conn=1448 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=nisNetgroup)(cn=itdept))"
slapd[870]: conn=1448 op=2 SRCH attr=cn nisNetgroupTriple memberNisNetgroup
slapd[870]: conn=1448 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=

Теперь изменим файл с записями экспортируемых каталогов /etc/exports, чтобы он выглядел так:

/export/home    @itdept(rw,no_subtree_check)
/export/install @itdept(rw,no_subtree_check)

Обратите внимание, что мы определили нашу новую группу с помощью знака @. Клиентская машина ldap-client — часть этой группы netgroup. Поэтому она должна иметь возможность монтировать указанные каталоги. Но прежде чем мы это проверим, нужно обновить конфигурацию демона NFS:

#  service nfs-kernel-server reload
$  showmount -e
Export list for nfs-srv.example.com:
/export/install @itdept
/export/home    @itdept

Теперь можем протестировать наши новые группы netgroup на клиентской машине ldap-client.

8.3 Настройка клиента NFS

Где работаем: ldap-client

Подключитесь к клиентской машине. Используйте пользователя, чей домашний каталог не находится в /nfs/home!

$  ssh pablo@ldap-client.example.com

В разделе 7 мы уже настроили эту машину в качестве клиента NFS с использованием autofs. Теперь посмотрим, можем ли мы автоматически монтировать каталог /nfs/home с новыми настройками сервера NFS. Первым делом изменим конфигурацию netgroup в /etc/nsswitch.conf, чтобы она выглядела так:

netgroup: ldap

Проверим, есть ли у нас доступ к записям netgroup на сервере каталогов:

$  getent netgroup itdept
itdept                   (ldap-client.example.com,,)

Хорошо. Теперь удостоверимся, что /nfs/home не примонтирован. ВНИМАНИЕ! Не выполняйте нижеследующую команду от имени пользователя, домашний каталог которого находится в /nfs/home!

#  umount /nfs/home

Проверим, анонсирует ли сервер NFS ресурсы, доступные для группы itdept:

$  showmount -e nfs-srv.example.com
Export list for nfs-srv.example.com:
/export/install @itdept
/export/home    @itdept

Анонсирует. Следовательно, мы должны иметь возможность примонтировать их:

$ cd /nfs/home
$ df -h .
Файл.система                     Размер Использовано  Дост Использовано% Cмонтировано в
nfs-srv.example.com:/export/home   3,6G         1,6G  1,8G           47% /nfs/home

Отлично! Работает. Но сработает ли автоматическое монтирование, если у нас нет доступа? Для этого понадобится отмонтировать каталоги /nfs/home и /nfs/install на клиенте:

#  umount /nfs/home
#  umount /nfs/install

Перейдём на сервер NFS и изменим настройки доступа к сетевым ресурсам.

Где работаем: nfs-srv

Отредактируем файл /etc/exports, изменив группу netgroup:

/export/home    @oracle(rw,no_subtree_check)
/export/install @oracle(rw,no_subtree_check)

Мы заменили группу itdept, в которую входит машина ldap-client.example.com на группу oracle, в которую эта машина не входит. Теперь машина ldap-client.example.com не сможет получить доступ к сетевым ресурсам. Но чтобы изменения вступили в силу, нужно перезагрузить сервис NFS:

#  service nfs-kernel-server reload
$  showmount -e
Export list for nfs-srv.example.com:
/export/home  @oracle

Вернёмся на клиентскую машину и попробуем получить доступ к ресурсам, анонсируемым nfs-srv. Напоминаю, надо использовать учётную запись пользователя, домашний каталог которого не лежит в /nfs/home!

Где работаем: ldap-client

Попробуем открыть каталог /nfs/home:

$ cd /nfs/home
-bash: cd: /nfs/home: Нет такого файла или каталога

Отлично! Это значит, что наши группы netgroup работают.

8.4 Добавление  новых значений атрибута nisNetgroupTriple

Этот раздел справочный. Для дальнейших экспериментов он играет роль постольку-поскольку.

8.4.1 Проблема и два варианта решения

Где работаем: ldap-srv

Я столкнулся со следующей проблемой. При попытке добавить новое значение атрибута nisNetgroupTriple в запись cn=itdept,ou=netgroup,ou=services,dc=example,dc=com появляется ошибка. Возьмём в качестве примера вот такой LDIF файл 8.4.1-ldap-client2-netgroup.ldif:

dn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=com
changetype: modify
add: nisNetgroupTriple
nisNetgroupTriple: (ldap-client2.example.com,,)

При попытке его загрузить в сервер каталогов мы увидим ошибку:

$  ldapadd -xZZWD cn=admin,dc=example,dc=com -f 8.4.1-ldap-client2-netgroup.ldif
Enter LDAP Password:
modifying entry "cn=itdept,ou=netgroup,ou=services,dc=example,dc=com"
ldap_modify: Inappropriate matching (18)
        additional info: modify/add: nisNetgroupTriple: no equality matching rule

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

  1. Длинный путь. Удалить ветку с определеним группы в контейнере ou=netgroup,ou=services,dc=example,dc=com целиком и создать её заново с новыми наборами nisNetgroupTriple.
  2. Короткий путь. Создать и загрузить в сервер каталогов файл LDIF, переопределяющий все наборы nisNetgroupTriple, вроде такого:
dn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=com
changetype: modify
replace: nisNetgroupTriple
nisNetgroupTriple: (ldap-client.example.com,,)
nisNetgroupTriple: (ldap-client2.example.com,,)

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

8.4.2 Третий вариант решения

Где работаем: ldap-srv

Есть третий путь, который позволит нам добавлять/удалять наборы nisNetgroupTriple. Он требует модификации схемы данных nis. Однако тут мы вновь сталкиваемся с неудобством. Перед изменением схемы придётся удалить все записи, в которых есть атрибут nisNetgroupTriple, потому что мы собираемся изменить определение этого атрибута.

Вот diff оригинальной и модифицированной схемы с парой строк контекста (-C 1), чтобы было видно, где были произведены изменения:

#  diff -C 1 cn\=\{10\}nis.ldif.original cn\=\{10\}nis.ldif.modified
*** cn={10}nis.ldif.original 2012-05-17 17:26:18.479629651 -0400
--- cn={10}nis.ldif.modified 2012-05-17 17:28:46.289627851 -0400
***************
*** 33,35 ****
  olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
!  oup triple' SYNTAX 1.3.6.1.1.1.0.0 )
  olcAttributeTypes: {13}( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' EQUALITY intege
--- 33,35 ----
  olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
!  oup triple' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
  olcAttributeTypes: {13}( 1.3.6.1.1.1.1.15 NAME 'ipServicePort' EQUALITY intege

Как мы можем видеть, изменение объекта nisNetgroupTriple довольно тривиальное.

Но произвести это изменение — задача не очень тривиальная.

Для начала удалим все дочерние записи у ou=netgroup,ou=services,dc=example,dc=com:

$  ldapdelete -xZZWD cn=admin,dc=example,dc=com  cn=oracle,ou=netgroup,ou=services,dc=example,dc=com
$  ldapdelete -xZZWD cn=admin,dc=example,dc=com  cn=itdept,ou=netgroup,ou=services,dc=example,dc=com

Посмотрим, какой порядковый номер у схемы данных nis в нашем каталоге:

$  ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=schema,cn=config dn |grep nis
Enter LDAP Password:
dn: cn={10}nis,cn=schema,cn=config

Так, номер 10. Теперь посмотрим, какой порядковый номер у атрибута nisNetgroupTriple в схеме данных nis:

$  ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=schema,cn=config | grep nisNetgroupTriple
Enter LDAP Password:
olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
  a netgroup' SUP top STRUCTURAL MUST cn MAY ( nisNetgroupTriple $ memberNisNe

Номер 12. Замечательно. Сформируем новый LDIF под названием 8.4.2-nis-schema-change.ldif для изменения схемы. Если два последних номера у Вас отличаются — подставьте свои значения:

dn: cn={10}nis,cn=schema,cn=config
changetype: modify
delete: olcAttributeTypes
olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
 oup triple' SYNTAX 1.3.6.1.1.1.0.0 )
-
add: olcAttributeTypes
olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
 oup triple' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Загрузим его в наш сервер каталогов:

$  ldapadd -xZZWD cn=admin,dc=example,dc=com  -f nis-schema-change.ldif

И проверим результат:

$ ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn={10}nis,cn=schema,cn=config olcAttributeTypes |grep -A 1 nisNetgroupTriple
Enter LDAP Password:
olcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgr
 oup triple' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Отлично! Схема данных обновлена. Теперь можем добавлять новые записи в группы netgroup по одной без каких-либо проблем. Это особенно удобно при работе с каталогом из GUI какого-нибудь LDAP-браузера (пример — Apache Directory Studio). Если Вы пришли в этот раздел прямиком из начала раздела 8, то можете продолжить в 8.1. Если Вы уже проделывали все предыдущие пункты, то остаётся только вернуть на место группы netgroup. Следуя нашим примерам, вернуть их  можно с помощью такого нехитрого файла LDIF (8.4.2-netgroup-addentryonly.ldif):

dn: cn=oracle,ou=netgroup,ou=services,dc=example,dc=com
objectClass: top
objectClass: nisNetgroup
cn: oracle
nisNetgroupTriple: (oracle.example.com,,)
description: All Oracle machines

dn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=com
objectClass: top
objectClass: nisNetgroup
cn: itdept
nisNetgroupTriple: (ldap-client.example.com,,)
description: IT department machines

Загрузим его в наш сервер каталогов:

$  ldapadd -xZZWD cn=admin,dc=example,dc=com  -f netgroup-addentryonly.ldif

Следующий раздел опишет, как развернуть область (realm) Kerberos с использованием OpenLDAP в качестве хранилища принципалов (principal). Это будет очень весело! Потому что как только у нас есть область Kerberos, мы можем использовать её для безопасной аутентификации в ssh, для защиты соединений с OpenLDAP с помощью SASL GSSAPI, для защиты запросов NFS на автоматическое монтирование и самого доступа к сетевым ресурсам. И много для чего ещё!

Pro-LDAP.ru 2015 г. Последнее изменение страницы — 3 мая 2015 г. Вопросы и предложения принимаются на форуме проекта.
Эта страница

Содержание

8.1 Настройка сервера OpenLDAP8.2 Настройка сервера NFS8.3 Настройка клиента NFS8.4 Добавление  новых значений атрибута nisNetgroupTriple
8. Репозиторий NFS netgroup на основе OpenLDAP для autofs
OpenLDAP 2.4 Руководство

Содержание

Введение в службы каталогов OpenLDAPБыстрое развёртывание и начало работыОбщая картина - варианты конфигурацииСборка и установка OpenLDAPНастройка slapd

 

Конфигурационный файл slapdЗапуск slapdКонтроль доступаОграниченияИнструментыМеханизмы манипуляции даннымиНаложенияСпецификация схемы

 

БезопасностьSASLTLSРаспределённая служба каталоговРепликацияОбслуживаниеМониторингПроизводительностьУстранение неполадок
Перевод официального руководства OpenLDAP 2.4 Admin Guide
Полное содержание здесь
LDAP для учёных-ракетчиков

Содержание

О книгеКонцепции LDAPОбъекты LDAPУстановка LDAPПримерыНастройкаРепликация и отсылкиLDIF и DSMLПротоколLDAP API

 

HOWTOНеполадкиПроизводительностьИнструменты LDAPБезопасностьЗаметкиРесурсы LDAPRFC и X.500ГлоссарийОбъекты
Перевод "LDAP for Rocket Scientists"
Полное содержание здесь
Ресурсы

Книги

Руководство OpenLDAP 2.4LDAP для учёных-ракетчиков

Другие

СтатьиТермины LDAPman-страницы OpenLDAP 2.4Список RFCКлиенты LDAPФайлы наборов схемы
Полезные ресурсы
Форум

 

Разделы форумаНепрочитанные сообщенияПоследние сообщения
Форум проекта
Главная

Pro-LDAP.ru

О проектеНовости проектаУчастникиСтаньте участником!Сообщите об ошибке!Об авторских правахСоглашения проекта
Присоединяйсь!