Mapowanie użytkowników NFSv4


12

To pytanie wydaje się zadawane już wiele razy, ale inne odpowiedzi jakoś mnie nie dotyczyły.

Zasadniczo właśnie skonfigurowałem nowy serwer NFSv4 i mam do czynienia z klasycznym problemem, w którym identyfikatory UID i GID nie są zgodne między serwerem a klientem. Jednak synchronizacja / etc / passwd i / etc / group nie jest możliwa w moim scenariuszu. Zauważ, że mam tych samych użytkowników na obu komputerach (w przeciwieństwie do tego pytania ).

Dlatego szukałem idmap: według niektórych źródeł wydaje się, że NFSv4 wysyła nazwy użytkowników (w przeciwieństwie do zachowania NFSv3 do wysyłania UID / GID), a rolą idmap byłoby tłumaczenie tych nazw użytkowników na UID / GID serwera.

Wydaje się jednak, że to nie działa w moim przypadku (szczegóły konfiguracji poniżej), które uważam za bardzo standardowe (właściwie tylko NFS zainstalowany z repozytorium).

Czy coś brakuje? Czy istnieje sposób, aby to działało bez konfigurowania LDAP lub Kerberos?


Konfiguracja serwera

Serwer został Ubuntu 16.04zainstalowany i dwóch użytkowników.

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 został zainstalowany z repozytorium i skonfigurowany do eksportowania folderu testowego.

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)

Ponieważ serwer i klient mają różne nazwy hostów, zmieniłem wartość „Domena” w pliku konfiguracyjnym idmapd. W przeciwnym razie plik jest identyczny z plikiem instalowanym przez menedżera pakietów. Uwaga: zawartość tego pliku jest identyczna zarówno na serwerze, jak i na kliencie.

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

Konfiguracja klienta

Klient ma także Ubuntu 16.04dwóch użytkowników, którzy mają jednak te same nazwy użytkowników, ale różne 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 został zainstalowany z repozytorium, a udział testowy został zainstalowany.

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

Testowanie

Najpierw tworzę plik na kliencie i wydaje się to w porządku:

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

Ale kiedy przeglądam plik z serwera, zauważam, że właściciel jest niewłaściwy, podczas gdy grupa nie istnieje.

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

Eksperymenty

Zgodnie z odpowiedzią na podobne pytanie, mapowanie identyfikatora powinno być aktywowane na serwerze w następujący sposób (zauważ błędy):

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

Będąc na kliencie (zauważ brak błędów):

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

Ale wyniki są dziwne:

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

Inna odpowiedź sugeruje zmianę konfiguracji idmapd w następujący sposób (zawartość jest taka sama na obu komputerach):

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

Ale to nie wydaje się mieć znaczenia.

Odpowiedzi:


6

NFSv4 nie tłumaczy identyfikatorów UID i GID, jak mogłoby się wydawać, gdy nie używa się protokołu Kerberos i zabezpieczeń. Ale działa dokładnie tak, jak opisano. Powodem jest to, że NFSv4 użyje AUTH_SYSzabezpieczeń. Bardziej szczegółowy opis można znaleźć tutaj .


2
Dziękuję za odpowiedź i link, bardzo pouczające. Ale nadal nie można go dopasować do kontekstu ... więc jaki jest cel idmapowania? Dlaczego nazywa się „rpcidmapd”, jeśli nie działa z rpc? A jaki jest wpływ tych poleceń?
matpen

FWIW, wydaje się możliwe włączenie mapowania identyfikatora NFSv4, nawet przy użyciu AUTH_SYStego pytania: unix.stackexchange.com/q/438939/111905
sxc731

@ sxc731: z mojego doświadczenia, i zrobiłem test dzisiaj, korzystając idmapz AUTH_SYSnie przekłada UID i GID poprawnie. Ale efektywne prawa nie są tłumaczone i nawet jeśli lspokazuje się własne katalogi lub pliki, nie będzie można wprowadzać zmian, ponieważ identyfikatory numeryczne nie pasują, a AUTH_SYSidentyfikatory numeryczne są używane do praw dostępu.
Thomas

1
@ Thomas poprawnie. Gdy mapowanie identyfikatora zostanie włączone sec=sys, pliki są wyświetlane zgodnie z mappigiem ID, ale zapisywanie działa tak, jakby w ogóle nie było mapowania identyfikatora. Inne odniesienie : „Chociaż numery UID / GID nie są już używane w protokole NFSv4, z wyjątkiem opcjonalnie w powyższych ciągach, nadal będą znajdować się w polach uwierzytelniania RPC podczas używania AUTH_SYS (sec = sys), co jest wartością domyślną. w tym przypadku zarówno nazwa użytkownika / grupy, jak i spacje liczbowe muszą być spójne między klientem a serwerem.
Irfan Latif
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.