| Каталог документации / Раздел "Сети, протоколы, сервисы" / Оглавление документа |
| |
|
В этом разделе мы настроим сервер каталогов для хранения конфигурации NFS netgroup. Это механизм разграничения доступа к сетевым ресурсам. Затем мы настроим клиента NFS, чтобы проверить, что наша конфигурация netgroup действительно работает.
ВНИМАНИЕ! Прежде чем переходить к следующему разделу и добавлять группы oracle и itdept, ознакомьтесь с проблемой, описанной в разделе 8.4. Для того, чтобы она у Вас не появилась, можете прямо сейчас выполнить инструкции раздела 8.4.2 и потом вернуться сюда. А можете и не выполнять. Зависит от того, является ли это проблемой в Вашем конкретном случае.
Где работаем: 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:
# Контейнер для конфигураций netgroupdn: ou=netgroup,ou=services,dc=example,dc=comou: netgroupobjectClass: topobjectClass: organizationalUnitdescription: NFS Netgroups# Первый пример группы netgroupdn: cn=oracle,ou=netgroup,ou=services,dc=example,dc=comobjectClass: topobjectClass: nisNetgroupcn: oraclenisNetgroupTriple: (oracle.example.com,,)description: All Oracle machines# Второй пример группы netgroupdn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=comobjectClass: topobjectClass: nisNetgroupcn: itdeptnisNetgroupTriple: (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"
Где работаем: 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.
Где работаем: 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 работают.
Этот раздел справочный. Для дальнейших экспериментов он играет роль постольку-поскольку.
Где работаем: 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=comchangetype: modifyadd: nisNetgroupTriplenisNetgroupTriple: (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. Два возможных пути в такой ситуации:
ou=netgroup,ou=services,dc=example,dc=com целиком и создать её заново с новыми наборами nisNetgroupTriple.nisNetgroupTriple, вроде такого:dn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=comchangetype: modifyreplace: nisNetgroupTriplenisNetgroupTriple: (ldap-client.example.com,,)nisNetgroupTriple: (ldap-client2.example.com,,)
Несмотря на то, что данные способы работают, использовать их повседневно может быть накладно. Вариант — написать какой-нибудь скрипт, автоматизирующий этот процесс, но лучше прибегнуть к ещё одному способу.
Где работаем: 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=configchangetype: modifydelete: olcAttributeTypesolcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup triple' SYNTAX 1.3.6.1.1.1.0.0 )-add: olcAttributeTypesolcAttributeTypes: {12}( 1.3.6.1.1.1.1.14 NAME 'nisNetgroupTriple' DESC 'Netgroup 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=comobjectClass: topobjectClass: nisNetgroupcn: oraclenisNetgroupTriple: (oracle.example.com,,)description: All Oracle machinesdn: cn=itdept,ou=netgroup,ou=services,dc=example,dc=comobjectClass: topobjectClass: nisNetgroupcn: itdeptnisNetgroupTriple: (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 на автоматическое монтирование и самого доступа к сетевым ресурсам. И много для чего ещё!
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |