Lennart Poettering
9dcd4113d0
Followon to #37024. This implements (mostly) what was suggested there, except that only a single UUID is accepted (modifying things to support multiple is a relatively straightforward change from here) I'm not really convinced this is the right approach: * I can't really think of any cases where you'd need to query by multiple UUIDs (I guess you might want to lookup multiple users, but in that case why aren't there "usernames" or "uids" arrays?) * If I specify username "foo" and UID 1234 and UID 1234 exists and has username "bar", I get back the error `ConflictingRecordFound` * If I specify username "foo" and UUID abcdef... and username "foo" exists but has UUID 123456..., I get back the error `NonMatchingRecordFound` This makes the two ID types behave differently. Additionally, when querying by `uuid`, the multiplexer will always sends `more: true`, which is fine but a little unexpected. I do think unifying things through the `UserDBMatch` struct could make sense, but in that case I think it would make sense to unify all query types in that way (username, uid, uuid), identify when the filter is for a single or multiple records, and centralise determination of conflict vs non matching record errors. `userdb_by_name`/`userdb_by_uid` could then become helper functions for the simple case where no additional filtering is needed. Thoughts? One other thought: Should the multiplexer just pass through all parameters, even unknown ones, to the backend services? Even if it doesn't know how to filter by every property, the backends might, and it would be useful to allow them to optimise things. (I realise the disadvantage of this, ofc, is loss of error checking)
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS