Redfish: Disable/enable out of band IPMI
Thomaiyar, Richard Marian
richard.marian.thomaiyar at linux.intel.com
Sun May 17 14:36:12 AEST 2020
Hi Tom,
Answers inline.
Regards,
Richard
On 5/15/2020 5:35 PM, TOM JOSEPH wrote:
>
> Hello AppaRao/Richard,
>
> I took a stab at service-config-manager. Got it running on one of our
> systems. Thanks for upstreaming it. Few questions i had:
>
> 1) Are the Redfish changes yet to be upstreamed?
> https://github.com/openbmc/bmcweb/commit/ec4974dd6a419b7f5556d4dcf4b8b836b5efbbd9
> Why did we not leverage service-config-manager for the Get method?
>
[Richard]: In order to make use of Get method which is applicable to
community, directly used the systemd query implementation, instead of
service-config-manager as it was not used by all.
> 2) For the Patch method, do you have code yet to be upstreamed? If so
> I will be interested in consuming it. Otherwise I can pick it up (This
> is something which I am pursuing
> https://github.com/ibm-openbmc/dev/issues/513).
>
[Richard]: bmcweb code is fully up-streamed. We don't have a code to do
the patch method call. Please go ahead.
> 3) Are there plans to upstream the recipe file for service-config-manager?
>
[Richard]: Yes, need to. It is here
https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-common/recipes-phosphor/srvcfg-manager/srvcfg-manager_git.bb
(Don't mind if you can add the same).
> 4) The interface exposed by the application looked different from this
> (https://github.com/openbmc/phosphor-dbus-interfaces/blob/master/xyz/openbmc_project/Control/Service/Attributes.interface.yaml)
>
[Richard]: Yes, it got updated, as the plan was to allow the temporary
disable of service, and similarly permanent blocking of service using
mask functionality exposed by systemd1. Interface needs to be updated.
> 5) For disabling out of band IPMI, there could be multiple instances
> of phosphor-ipmi-net that needs to be disabled/masked. How do we plan
> to achieve that? I had couple of options in mind. Let me know your
> thoughts.
> a) Get all object paths of the service-config-manager which match
> phosphor-ipmi-net( phosphor_2dipmi_2dnet) and then disable each interface.
> b) Use the "ListUnits" method on "/org/freedesktop/systemd1" and
> get the object paths of phosphor-ipmi-net instances.
>
[Richard]: Internally service-config-manager does ListUnits, and adds
all the phosphor-ipmi-net instances in it's tree. From application
level, querying all the objects exposed by service-config-manager itself
is enough. This is done already in order to disable RMCP+ in one of our
oem IPMI command -
https://github.com/openbmc/intel-ipmi-oem/blob/master/src/bmccontrolservices.cpp#L141
> Regards,
> Tom
> On 17-12-2019 08:29, Carol Wang wrote:
>> Ok, I got it. Thank you!
>> Waiting for the change then. :-)
>>
>> On Mon, Dec 16, 2019 at 9:48 PM Thomaiyar, Richard Marian
>> <richard.marian.thomaiyar at linux.intel.com> wrote:
>>> This came a month back, and i wanted to push the changes in intel repo
>>> to the OpenBMC community repo, due to other priority missed to push the
>>> same.
>>>
>>> https://github.com/Intel-BMC/provingground/tree/master/srvcfg-manager
>>>
>>> Will push the document in few day and the changes for the same.
>>>
>>> Regards,
>>>
>>> Richard
>>>
>>> On 12/16/2019 11:38 AM, Carol Wang wrote:
>>>> rface in phosphor-dbus-interface to indicate the status
>>>> of net IPMI.
>>>> Have a daemon to monitor the status, if the status is changed, then
>>>> enable or
>>>> disable the net IPMI service and socket.
>>>> 2. Check the net IPMI socket state by getData()[1] in bmcweb. If the
>>>> state is
>>>> "running" or "listening", the net IPMI status is true, otherwise, the
>>>> status is
>>>> false. Then bmcweb can enable or disable the service and socket.
>>>>
>>>> Wondering if anyone has any thoughts on this feature, which way is
>>>> better.
>>>> If add interface, in which daemon this interface should be implemented?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200517/1d32de73/attachment.htm>
More information about the openbmc
mailing list