UID/GID Mapping: Difference between revisions
Jump to navigation
Jump to search
m (→Introduction: reference projids) |
(→Introduction: add newer features of Nodemaps) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
=== Introduction === | === Introduction === | ||
Using Nodemap, UIDs, GIDs and PROJIDs provided by remote clients can be | Using Nodemap, UIDs, GIDs and PROJIDs provided by remote clients can be mapped onto a local set of UIDs, GIDs and PROJIDs for storage in the filesystem. Non-overlapping ranges of UID, GID, PROJID would be used from the filesystem to cater to different subsets of users. | ||
mapped onto a local set of UIDs, GIDs and PROJIDs. | |||
You may find | The Nodemap functionality also allows restricting client sub-groups to mount only a specific subdirectory tree of the filesystem, rather than the whole filesystem (Subdirectory Mount). | ||
You may find Nodemaps useful if: | |||
* You need to prevent UID, GID, and PROJID collisions between clients in different administrative domains | * You need to prevent UID, GID, and PROJID collisions between clients in different administrative domains | ||
* Two or more partner organizations would like to share data | * Two or more partner organizations would like to share data in the same filesystem | ||
* You can limit access from a partner site | * You can limit access from a partner site | ||
* You can limit administrator/root access to the filesystem | |||
* Force clients to mount the filesystem read-only | |||
* Specifying a subdirectory for clients (e.g. multi-tenancy) | |||
* Selectively enable audit logging for clients | |||
* Selectively enable client-side data encryption | |||
== Resources == | == Resources == | ||
| Line 18: | Line 24: | ||
== Presentations == | == Presentations == | ||
* [https://wiki.lustre.org/images/5/5c/LUG2018-Multitenancy-Buisson.pdf Multi-tenancy: real-life implementation (LUG 2018)] | |||
* [http://lustre.ornl.gov/ecosystem-2016/documents/tutorials/Simms-IU-NodemapSharedKey.pdf Securing Lustre with Nodemap and Shared Key (Lustre Ecosystem 2016)] | * [http://lustre.ornl.gov/ecosystem-2016/documents/tutorials/Simms-IU-NodemapSharedKey.pdf Securing Lustre with Nodemap and Shared Key (Lustre Ecosystem 2016)] | ||
* [http://cdn.opensfs.org/wp-content/uploads/2015/04/GSS-Shard-key-Update-and-Using-UID_Simms.pdf Using UID Mapping in Lustre 2.7 and GSS Shared Key Update (LUG 2015)] | * [http://cdn.opensfs.org/wp-content/uploads/2015/04/GSS-Shard-key-Update-and-Using-UID_Simms.pdf Using UID Mapping in Lustre 2.7 and GSS Shared Key Update (LUG 2015)] | ||
[[Category:Features]] | [[Category:Features]] | ||
Latest revision as of 11:15, 6 April 2023
Introduction
Using Nodemap, UIDs, GIDs and PROJIDs provided by remote clients can be mapped onto a local set of UIDs, GIDs and PROJIDs for storage in the filesystem. Non-overlapping ranges of UID, GID, PROJID would be used from the filesystem to cater to different subsets of users.
The Nodemap functionality also allows restricting client sub-groups to mount only a specific subdirectory tree of the filesystem, rather than the whole filesystem (Subdirectory Mount).
You may find Nodemaps useful if:
- You need to prevent UID, GID, and PROJID collisions between clients in different administrative domains
- Two or more partner organizations would like to share data in the same filesystem
- You can limit access from a partner site
- You can limit administrator/root access to the filesystem
- Force clients to mount the filesystem read-only
- Specifying a subdirectory for clients (e.g. multi-tenancy)
- Selectively enable audit logging for clients
- Selectively enable client-side data encryption