BMC redundancy

[Ratan Gupta]

On Saturday 03 February 2018 01:38 PM, Deepak Kodihalli wrote:
> On 03/02/18 2:40 am, Vernon Mauery wrote:
>> On 02-Feb-2018 11:18 AM, Andrew Jeffery wrote:
>>> Hi Deepak,
>>>
>>>> So several of the existing OpenBMC apps implement specific D-Bus
>>>> services. What does it take to make remote D-Bus calls to such apps?
>>>> - It doesn't look like the D-Bus spec or libdbus officially has 
>>>> anything
>>>> for D-Bus across computers. There are some good notes at
>>>> https://www.freedesktop.org/wiki/Software/DBusRemote/.
>>>
>>> Applications can cannect to remote dbus servers; the --address 
>>> option to dbus-daemon allows it to listen on a TCP socket and 
>>> setting DBUS_SESSION_BUS_ADDRESS will point applications in the 
>>> right direction. So there are probably two ways we could do this:
>>
>> Putting DBus on an externally-available TCP socket is a security 
>> architect's nightmare. All command and control of the entire BMC is 
>> done over DBus; we cannot put that on an externally-available 
>> address. I suppose if you have an internal connection and switching 
>> fabric between the nodes, this would be possible.
>
> This shouldn't be a problem though with SSH forwarding, with a proxy 
> D-Bus daemon for example. 
> https://www.freedesktop.org/wiki/Software/DBusRemote/ talks about 
> another issue with SSH forwarding D-Bus, which I haven't fully 
> understood. I know that the Gabriel project took the SSH forwarding 
> route.
Forwarding D-Bus packet over SSH will be having bottle neck as we need 
to check whether libssh is threadsafe or not.In the following link for 
Gabriel,it is mentioned that libssh is not thread safe so multiple 
clients can not connect.
http://gabriel.sourceforge.net/README.
However in other link it is mentioned that how can we make the libssh 
threadsafe.
http://api.libssh.org/master/libssh_tutor_threads.html.

On other note,Do we really need to concern for the security for 
internal(private network) BMC communication?

>
> Regards,
> Deepak
>
>> --Vernon
>>
>>> 1. Slave BMCs connect to the master's DBus daemon, and applications 
>>> namespace their objects appropriately. Multi-BMC aware applications 
>>> on the master access the namespaced objects as required
>>> 2. Slave BMCs are willfully ignorant of their role, with the master 
>>> connecting to the slaves' DBus daemons to form a coherent global 
>>> view of the bus for its multi-BMC aware applications, which access 
>>> the remote objects as required.
>>>
>>> Given the support DBus has today it might be easier to go for 1 than 
>>> for 2, if we go down this path at all.
>>>
>>> [1] https://dbus.freedesktop.org/doc/dbus-daemon.1.html
>>>
>>>> - There are ways to achieve this via Qt D-Bus, but it would involve 
>>>> some
>>>> amount tweaking with the D-Bus configs.
>>>> - I'm not aware of any open/active project implementing remote D-Bus.
>>>
>>> Here is someone's attempt at making it easier: 
>>> http://gabriel.sourceforge.net/howto.html though you would struggle 
>>> to say it's active given the last contribution was 2013-05-14.
>>>
>>>> - Thoughts on doing remote D-Bus over WebSockets?
>>>
>>> How do websockets come into the picture? Why do we need the extra 
>>> complication vs normal sockets?
>>>
>>> Cheers,
>>>
>>> Andrew
>>
>