В сообщении от [4 марта 2015 Gleb Kulikov] написал:
> Пытаюсь воспользоваться nfs4 в домене Kerberos/ldap,
>
> Домен настраивался штатными средствами.
>
> Ничерта не получается и очевидно, моего слабого понимания механизма
> недостаточно :(
Отвечаю сам себе. Возможно, имеет смысл отразить результат раскопок на вики:
1. После ввода машины -- клиента в домен kerberos/ldap средствами альтератора нужно НА КЛИЕНТЕ исправить два косяка:
а) дописать в /etc/krb5.conf:
+++++++++++++++++++++++++++
[libdefaults]
default_realm = НАШЕ.ORG
allow_weak_crypto = true # очень похоже, что принципиальный момент для текущей nfs!
[dbmodules]
нашдомен.org = {
db_library = kldap
ldap_kdc_dn = cn=kdc,ou=kdcroot,dc=домен,dc=org
ldap_kadmind_dn = cn=kadmin,ou=kdcroot,dc=домен,dc=org
ldap_servers = ldaps://сервер.нашдомен.org/
ldap_conns_per_server = 5
}
[realms]
НАШДОМЕН.ORG = {
kdc = сервер.нашдомен.org
admin_server = сервер.нашдомен.org
default_domain = нашдомен.org
}
[domain_realm]
нашдомен.org = НАШДОМЕН.ORG
.нашдомен.org = НАШДОМЕН.ORG
+++++++++++++++++++++++++++++
б) заполнить /etc/idmapd.conf
[General]
Domain = домен.org
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = nsswitch
2. Идём НА СЕРВЕР (KDC) и создаём принципал для КЛИЕНТА (если клиентов много, то для каждого клиента):
kadmin.local:
addprinc -randkey nfs/клиент.нашдомен.org@НАШЕЦАРСТВО.ORG
после ввода всех клиентов
ktadd -k /etc/krb5.keytab
именно так, без указания типа шифрования (будут записаны все дефолтные)
теперь копируем /etc/krb5.keytab С СЕРВЕРА в /etc на КЛИЕНТАХ.
Именно копируем полный keytab с сервера, а не экспортируем отдельную запись. В противном случае, KVNO записи изменится и аутентичность устанавливаться не будет!
(Этот момент мне кажется крайне сомнительным, хотелось бы услышать комментарий гуру).
Без копирования keytab на клиента, gssd установление аутентичности не отрабатывает (почему?!)
3. [БАГ!!!!] На клиенте тем или иным способом заставляем запуститься rpc.gssd, rpc.idmapd --- в p7 работает service gssd старт, а вот для старта rpc.idmapd нужно или создавать новый сервис, или стартовать вручную. Аналогично, на сервере нужно ДОПОЛНИТЕЛЬНО стартовать rpc.svgssd
4. /etc/sysconfig/nfs на севере И КЛИЕНТЕ, нужно прописать
SECURE_NFS=yes
5. в /etc/exports:
а) корень ОБЯЗАТЕЛЬНО должен быть прописан с sec=krb5 И ЭТА СТРОЧКА ДОЛЖНА БЫТЬ ПЕРВОЙ!
/export gss/krb5(ro,nohide,no_subtree_check,fsid=0,crossmnt,sec=krb5)
б) если есть необходимость, чтобы кроме керберезированных экспортов была возможность анонимного подключения, следует:
б.1) прописывать анонимные шары ОБЯЗАТЕЛЬНО в другое дерево. Хотя будем требовать, чтобы анонимные шары разделялись по nfs3, указание fsid= ОБЯЗАТЕЛЬНО, причём номер fsid НЕ ДОЛЖЕН ПЕРЕСЕКАТЬСЯ С fsid керберезированного раздела (для анонимных шар начинаем нумерацию заведомо ПОСЛЕ керберезированных каталогов).
/nfs/Film 192.168.1.0/24(ro,nohide,no_subtree_check,crossmnt,fsid=10)
б.2) керберезированные каталоги прописываем с sec=krb5
/export/Archive gss/krb5(insecure,rw,sync,no_subtree_check,crossmnt,fsid=3)
NB!: анонимная шара монтируется по nfs3 с использованием полного синтаксиса:
mount -t nfs сервер:/nfs/Film /mnt/F -o intr,vers=3,nolock,sec=sys
(здесь nolock или, что правильнее, запускать lockd).
Монтирование из autofs также работает, но версию протокола и sec= нужно прописывать в файлы конфигурации autofs явно!
Непонятный косяк: первая запись файла на керберизированный ресурс длится неприлично долго, но затем работа идёт без замираний и на полной скорости.
Заключение: слов нет, одни мысли, и те неприличные.
