UID/GID Mapping: Difference between revisions
Jump to navigation
Jump to search
mNo edit summary |
(→Presentations: add another nodemap presentation) |
||
Line 19: | Line 19: | ||
== 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]] |
Revision as of 11:09, 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.
You may find this 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