commit | 078aa6a4ff8dfe99bd0e42f71df81cf73483f87e | [log] [tgz] |
---|---|---|
author | Khang D Nguyen <khangng@os.amperecomputing.com> | Thu Mar 06 00:03:42 2025 +0700 |
committer | khangng <khangng@os.amperecomputing.com> | Thu Mar 27 02:05:44 2025 +0000 |
tree | 049f5e082a4887590d9b68bd0716f12908403942 | |
parent | 8c974f76411cb40f2c9c25cddd86814087d0eddf [diff] |
user_channel: use hardcoded user manager service name Current user list fetching scheme relies on this D-Bus idiom: 1. Register InterfaceAdded/Removed signals on /xyz/openbmc_project/user 2. Call GetManagedObjects on /xyz/openbmc_project/user However, taking ObjectMapper into account, this scheme becomes: 1. Register InterfaceAdded/Removed signals on /xyz/openbmc_project/user 2. Call GetObject on /xyz/openbmc_project/user (to get service name) 3. Call GetManagedObjects on /xyz/openbmc_project/user If step 2 of the latter scheme fails because ObjectMapper has not finished introspecting yet, we basically lose the initial user list. This is what happened in our system. Do we expect some arbitrary services to be able to provide user management apart from xyz.openbmc_project.User.Manager? According to OpenBMC User Management design docs [1], user management is documented to be handled by one common service. bmcweb is also using the hardcoded user manager name [2]. I also saw Ed had some comments regarding some usage of ObjectMapper on discord [3]. [1] https://github.com/openbmc/docs/blob/9168592c88de40c802823ba9ed6267f1b54a4002/architecture/user-management.md [2] https://github.com/openbmc/bmcweb/blob/1940677a35870b51eaffc50406609124668743d0/redfish-core/lib/roles.hpp#L130-L133 [3] https://discord.com/channels/775381525260664832/867820390406422538/1343372176547643432 This removes the dependency on ObjectMapper inside user management code and uses the user manager service name directly. Tested: IPMI user management features work normally Change-Id: Id0000000d2a84234fc6c61044d7a55e48561b36f Signed-off-by: Khang D Nguyen <khangng@os.amperecomputing.com>
meson builddir ninja -C builddir
meson builddir -Dbuildtype=minsize -Db_lto=true -Dtests=disabled ninja -C builddir
If any of the dependencies are not found on the host system during configuration, meson automatically gets them via its wrap dependencies mentioned in ipmid/subprojects
.
meson builddir -Dwrap_mode=nofallback ninja -C builddir
meson builddir -Dbuildtype=debug ninja -C builddir
meson builddir -Db_coverage=true -Dtests=enabled ninja -C builddir test ninja -C builddir coverage