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>
1 file changed
tree: 049f5e082a4887590d9b68bd0716f12908403942
  1. app/
  2. dbus-sdr/
  3. docs/
  4. include/
  5. libipmid/
  6. scripts/
  7. softoff/
  8. subprojects/
  9. test/
  10. transport/
  11. user_channel/
  12. xyz/
  13. .build.sh
  14. .clang-format
  15. .clang-tidy
  16. .gitignore
  17. .shellcheck
  18. .travis.yml
  19. apphandler.cpp
  20. apphandler.hpp
  21. chassishandler.cpp
  22. chassishandler.hpp
  23. dcmihandler.cpp
  24. dcmihandler.hpp
  25. error-HostEvent.hpp
  26. fruread.hpp
  27. generate_whitelist.sh
  28. generate_whitelist_create.sh
  29. globalhandler.cpp
  30. groupext.cpp
  31. host-cmd-manager.cpp
  32. host-cmd-manager.hpp
  33. host-interface.cpp
  34. host-interface.hpp
  35. host-ipmid-whitelist.conf
  36. ipmi_fru_info_area.cpp
  37. ipmi_fru_info_area.hpp
  38. ipmiallowlist.hpp
  39. ipmid-new.cpp
  40. ipmisensor.cpp
  41. LICENSE
  42. meson.build
  43. meson.options
  44. OWNERS
  45. read_fru_data.cpp
  46. read_fru_data.hpp
  47. README.md
  48. selutility.cpp
  49. selutility.hpp
  50. sensordatahandler.cpp
  51. sensordatahandler.hpp
  52. sensorhandler.cpp
  53. sensorhandler.hpp
  54. settings.cpp
  55. settings.hpp
  56. storageaddsel.cpp
  57. storageaddsel.hpp
  58. storagehandler.cpp
  59. sys_info_param.cpp
  60. sys_info_param.hpp
  61. systemintfcmds.cpp
  62. systemintfcmds.hpp
  63. transportconstants.hpp
  64. transporthandler.cpp
  65. transporthandler.hpp
  66. whitelist-filter.cpp
README.md

phosphor-host-ipmid

Compile ipmid with default options

meson builddir
ninja -C builddir

Compile ipmid with yocto defaults

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.

Enable/Disable meson wrap feature

meson builddir -Dwrap_mode=nofallback
ninja -C builddir

Enable debug traces

meson builddir -Dbuildtype=debug
ninja -C builddir

Generate test coverage report

meson builddir -Db_coverage=true -Dtests=enabled
ninja -C builddir test
ninja -C builddir coverage