Отображение UID для NFS
У меня есть файловый сервер Mac OS X, который работает через SMB/CIFS и AFP. Сервер является клиентом домена посредством подхода золотого треугольника, но это приводит к очень большому UID для пользователей. Это хорошо для моей текущей настройки, но я бы хотел, чтобы NFS также работала. Очевидно, мне нужно сделать какое-то отображение UID, но я не уверен, как это сделать. Любой совет?
4 ответа
В большинстве реализаций NFSv3, в частности, на серверах уровня ядра, это невозможно, за исключением некоторых ограниченных отображений, таких как root, никому. В NFS v4 у вас есть rpc.idmapd, который выполняет сопоставление UID NFSv4 ID <-> на сервере и позволяет вам стать более гибким.
Если вы не можете использовать NFSv4, рекомендуемый способ справиться с ним для NFSv3 состоит в том, чтобы ваши пользователи приходили из службы каталогов, такой как LDAP, или из другой общей базы данных. Обычно все пользователи системы для демонов и т. Д. /etc/passwd в то время как все люди-пользователи приходят из внешнего источника. Это обеспечит согласованность UID по всем направлениям и устранит необходимость в любом виде сопоставления.
Что ж, после дальнейших исследований я обнаружил, что nfs-user-server позволит вам выполнять такое отображение. Это немного обидно, потому что основной причиной, по которой я хотел использовать NFS поверх CIFS, была скорость. nfs-user-server работает в пользовательском пространстве, поэтому он не так быстр, как nfs-kernel-server. Не кажется оптимальным решением.
Я хочу добавить, что в подходе к отображению UID в NFSv4 есть важный момент (см. Комментарий Камиля): он не работает для AUTH_SYS / AUTH_UNIX проверка подлинности - это то, что у вас есть, если на разных компьютерах не используется LDAP, Kerberos или какая-либо другая система управления общим доступом.
Суть в следующем: NFSv4 будет использовать текстовые (то есть не числовые) идентификаторы при описании владения файлами по сети, что, как вы думаете, вам нужно, но слой RPC по-прежнему использует числовые значения UID и GID. просто AUTH_SYS аутентификация возвращается к RPC, и вы снова застряли. Вот пример того, как это выглядит (захват tshark пакета client->server, захваченного на стороне сервера):
Frame 26 (306 bytes on wire, 306 bytes captured)
...
Remote Procedure Call, Type:Call XID:0x2790a46d
...
Credentials
Flavor: AUTH_UNIX (1)
Length: 48
Stamp: 0x00419c55
Machine Name: localhost.localdomain
length: 21
contents: localhost.localdomain
fill bytes: opaque data
UID: 500
GID: 500
Auxiliary GIDs
GID: 500
Verifier
Flavor: AUTH_NULL (0)
Length: 0
Network File System
...
Я не настроил его на OSX, но то, что вы ищете, называется idmapd. В операционной системе OSX демон фактически называется rpc.idmapd. (Примечание: НЕ imapd.)