[LU-13335] add name lookup for project IDs Created: 05/Mar/20 Updated: 09/Dec/23 |
|
| Status: | Open |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Andreas Dilger | Assignee: | WC Triage |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | lad23dd, lug23dd, medium | ||
| Issue Links: |
|
||||||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||||||
| Description |
|
It would be useful to allow names to be mapped to projid numbers using the /etc/projid file (projid.5), as is used by the XFS quota utility (xfs_quota.8): usera:1 userc:3 There should be a new function struct ll_project *llapi_getprjname(const char *name) function that is called by lfs and lctl to read the /etc/projid file and lookup the name and return the projid, while struct ll_project *llapi_getprjid(__u32 prjid) would lookup the numeric project ID and return the name: struct ll_project {
__u32 lp_projid;
char *lp_name;
};
Returning the struct instead of a single value (name or prjid) allows expanding this interface in the future (e.g. to list which users are allowed to use/change the group, passwords for the group, etc. as with getgrnam(), getgrgid(), getpwnam(), getpwuid()). It isn't very clear what benefit the /etc/projects file (projects.5) provides, so I'm not yet sure whether we need to implement support for this or not. |
| Comments |
| Comment by Alex Zhuravlev [ 05/Mar/20 ] |
|
shouldn't that be a part of Lustre FS, like config-log or something similar? |
| Comment by Andreas Dilger [ 07/Mar/20 ] |
|
We don't manage username->uid or groupname->gid mapping in Lustre, but rather depend on external services for mapping. The XFS filesystem is using "/etc/projid" for projname->projid mapping, so it makes sense to be compatible with this. Once the basic projname->projid mapping is handled, then we could potentially expand this to manage the configuration in Lustre, or via NIS or AD or whatever is in use at the site (as is done with getgrnam(), getgrgid(), ...), but that is a lot more work. |
| Comment by Andreas Dilger [ 11/Aug/20 ] |
|
It looks like there is already a stub lfs.c::name2projid() function used in most of the relevant code that needs to be filled in to convert the name to the numeric projid. That would need to call llapi_getprjid() for the name lookup. The one place this is not done correctly is in lfs_project(), where it only calls str2quotaid(), unlike lfs_find(), lfs_setquota() and lfs_quota() that call the respective name2*id() function first, and only fall back to str2quotaid() if they return an error. (As an aside, str2quotaid() should rename the internal "projid_tmp" variable to "tmpid" since function this is used for parsing and verifying all kinds of numeric IDs). |
| Comment by Andreas Dilger [ 13/Jun/21 ] |
|
mrb, we had briefly discussed at LUG that you might work on this improvement. Is that still on your radar? |
| Comment by Andreas Dilger [ 27/Aug/21 ] |
|
I've also thought for a while that mapping username:uid to the same projid by default would be very convenient. For example, "lfs project -p adilger -r -s /lustre/home/adilger" with uid=1000 would fall back to projid=1000 if there is no matching "adilger" entry in /etc/projid. That avoids the need to duplicate the entire /etc/passwd into /etc/projid for the common case where projid=uid, and potentially avoids the need to manage distributing /etc/projid to all of the client nodes since getpwnam() can query the configured network name database (LDAP, AD, etc) if configured in /etc/nsswitch.conf. |
| Comment by Andreas Dilger [ 14/Jan/22 ] |
|
There is also a more extensive /etc/projid format defined by Solaris, that is apparently also handled by /etc/nsswitch.conf, so we should maintain compatibility with that for extensions beyond the basic projname:projid fields, essentially just ignoring any extra fields for now:
|
| Comment by Andreas Dilger [ 14/Jan/22 ] |
|
It might potentially be useful to push a patch upstream for Linux /etc/nsswitch.conf to add the "project" as a valid database type. Since it is glibc, it may not be as obvious as one would hope (both technically and politically), but maybe just cargo-cult copying of e.g. "passwd" or "group" handling would be enough to start? Adding new getprojnam() and getprojid() calls would be needed also. |
| Comment by Gerrit Updater [ 15/Jan/22 ] |
|
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/46144 |
| Comment by Gerrit Updater [ 28/Jan/22 ] |
|
"Andreas Dilger <adilger@whamcloud.com>" uploaded a new patch: https://review.whamcloud.com/46369 |
| Comment by Gerrit Updater [ 11/Jul/22 ] |
|
"Oleg Drokin <green@whamcloud.com>" merged in patch https://review.whamcloud.com/46369/ |