The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа

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 [email protected]

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



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру