NFSv4 User Mapping


12

Этот вопрос, кажется, уже задавался много раз, но другие ответы как-то не относились ко мне.

По сути, я просто настроил новый сервер NFSv4 и столкнулся с классической проблемой, когда UID и GID не совпадают между сервером и клиентом. Однако в моем сценарии синхронизация файлов / etc / passwd и / etc / group невозможна. Обратите внимание, что у меня есть одни и те же пользователи на обеих машинах (в отличие от этого вопроса ).

Поэтому я изучал idmap: согласно некоторым источникам, кажется, что NFSv4 отправляет имена пользователей (в отличие от поведения NFSv3 для отправки UID / GID), и роль idmap заключается в том, чтобы переводить эти имена пользователей на сервер UID / GID.

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

Я что-то упускаю? Есть ли способ заставить это работать без настройки LDAP или Kerberos?


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

На сервере Ubuntu 16.04установлено и два пользователя.

user1@server:~$ id user1
uid=1000(user1) gid=1000(user1) groups=1000(user1),27(sudo)
user1@server:~$ id user2
uid=1001(user2) gid=1001(user2) groups=1001(user2)

NFS была установлена ​​из репозитория и настроена на экспорт тестовой папки.

user1@server:~$ sudo apt-get install nfs-kernel-server

user1@server:~$ sudo cat /proc/fs/nfsd/versions 
+2 +3 +4 +4.1 +4.2

user1@server:~$ ls -ld /srv/nfs/test/
drwxrwxrwx 2 nobody nogroup 4096 nov  2 17:34 /srv/nfs/test/

user1@server:~$ cat /etc/exports 
"/srv/nfs/test" 192.168.x.x(rw,sync,no_subtree_check)

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

user1@server:~$ cat /etc/idmapd.conf
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

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

У клиента также есть Ubuntu 16.04и два пользователя, которые, однако, имеют одинаковые имена пользователей, но разные UID / GID .

user1@client:~$ id user1
uid=1001(user1) gid=1002(user1) groups=1002(user1),27(sudo)
user1@client:~$ id user2
uid=1000(user2) gid=1000(user2) groups=1000(user2),27(sudo)

NFS была установлена ​​из репозитория, а контрольный ресурс был смонтирован.

user1@client:~$ sudo apt-get install nfs-common

user1@client:~$ mkdir ./test
user1@client:~$ sudo mount -t nfs4 192.168.x.x:/srv/nfs/test ./test

тестирование

Сначала я создаю файл на клиенте, и это выглядит нормально:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l ./test
total 0
-rw-rw-r-- 1 user1 user1 0 nov  2 17:24 testfile

Но когда я просматриваю файл с сервера, я замечаю, что владелец не тот, а группа не существует.

user1@server:~$ ls -l /srv/nfs/test
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 17:24 testfile

Эксперименты

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

user1@server:~$ sudo tee /sys/module/nfsd/parameters/nfs4_disable_idmapping <<< "N"
user1@server:~$ sudo nfsidmap -c
nfsidmap: 'id_resolver' keyring was not found.
user1@server:~$ sudo service rpcidmapd restart
Failed to restart rpcidmapd.service: Unit rpcidmapd.service not found.
user1@server:~$ sudo service nfs-kernel-server restart

Пока на клиенте (обратите внимание на отсутствие ошибок):

user1@client:~$ sudo tee /sys/module/nfs/parameters/nfs4_disable_idmapping <<< "N"
user1@client:~$ sudo nfsidmap -c

Но результаты странные:

user1@client:~$ touch test/testfile
user1@client:~$ ls -l test
total 0
-rw-rw-r-- 1 user2 4294967294 0 nov  2 19:16 testfile
user1@server:~$ ls -l /srv/nfs/project/
total 0
-rw-rw-r-- 1 user2 1002 0 nov  2 19:16 prova

Другой ответ предлагает изменить конфигурацию idmapd следующим образом (содержимое одинаково на обеих машинах):

user1@server:~$ cat /etc/idmapd.conf 
[General]

Verbosity = 0
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if id differs from FQDN minus hostname
Domain = mydomain

[Translation]
   Method=static
[Static]
   user1@mydomain = user1

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

Но это, похоже, не имеет никакого значения.

Ответы:


6

NFSv4 не будет переводить UID и GID, как вы можете подумать, если не используете Kerberos и систему безопасности. Но это именно так, как вы описали. Причина в том, что NFSv4 будет использовать AUTH_SYSбезопасность. Более подробное описание можно найти здесь .


2
Спасибо за ваш ответ и ссылку, очень информативно. Но все еще не может вписаться в контекст ... так какова цель idmapping? Почему он называется "rpcidmapd", если он не работает с rpc? И каков эффект этих команд?
Созрев

Кстати, представляется возможным включить сопоставление идентификаторов NFSv4 даже при использовании AUTH_SYSпо этому вопросу: unix.stackexchange.com/q/438939/111905
sxc731

@ sxc731: по моему опыту, и сегодня я провел тест, используя idmapwith AUTH_SYS, правильно ли переводит UID и GID. Но действующие права не переводятся, и даже если lsони показывают ваши собственные каталоги или файлы, вы не сможете вносить изменения, поскольку числовые идентификаторы не совпадают, а AUTH_SYSчисловые идентификаторы используются для прав доступа.
Томас

1
@ Томас правильный. Когда сопоставление идентификаторов включено sec=sys, файлы отображаются в соответствии с сопоставлением идентификаторов, но запись работает так, как будто сопоставление идентификаторов вообще не происходит. Еще одна ссылка : «Хотя числа uid / gid больше не используются в протоколе NFSv4, за исключением необязательных строк, указанных выше, они все равно будут находиться в полях аутентификации RPC при использовании AUTH_SYS (sec = sys), который используется по умолчанию. Таким образом, в этом случае и имя пользователя / группы, и
Ирфан Латиф
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.