obmc-console design for multi host support

[Andrew Jeffery]

Hi Kumar,

On Thu, 27 Feb 2020, at 02:29, Kumar Thangavel wrote:
> Hi Andrew,
> 
>              Could you please suggest how to add configs for multiple host ?

Sure. So the root problem is mapping a given obmc-console-client to
the correct obmc-console-server instance. We do this by giving the
unix domain socket created by the server a unique name in the
abstract socket namespace. The client is associated with a unique
network port and the server a unique tty device (e.g. ttyVUART0),
but neither the port nor the tty should be associated with the abstract
socket's name as to do so means the port or tty name becomes a
mapping that's hard to break (port X always implies tty Y). The route
the patches take is to pair a client with a server via a socket-id value
read from a configuration file (one patch enables the client to read a
configuration file [1]).

[1] https://gerrit.openbmc-project.xyz/c/openbmc/obmc-console/+/29457

All connections to the client a given port should map to one associated
server. Given that the port is unique for the client and the tty for the
server, we can define which configuration they should use in terms of
the port or tty, which leads to the following configuration structure:

```
$ ls -1 /etc/obmc-console
client.2200.conf
server.ttyVUART0.conf
```

So to map the client associated with port 2200 to the server associated
with ttyVUART0 we set the same socket-id value in both files:

```
$ grep socket-id /etc/obmc-console/*.conf
client.2200.conf:socket-id = host
server.ttyVUART0.conf:socket-id = host
```

You can add further instances to the system by adding e.g.
client.2201.conf and server.ttyVUART1.conf and set the same socket-id
value in each. This brings us to the issue of getting the client and
server up and running - they are integrated into the running system
via the two template systemd service units: obmc-console at .service
and obmc-console-ssh at .service:

```
$ cat /lib/systemd/system/obmc-console at .service
[Unit]
Description=%i Console Server
ConditionPathExists=/etc/obmc-console/server.%i.conf

[Service]
# Instance ID is the VUART basename
ExecStart=/usr/sbin/obmc-console-server --config /etc/obmc-console/server.%i.conf %i
SyslogIdentifier=%i-console-server
Restart=always
```

```
$ cat obmc-console-ssh at .service
[Unit]
Description=Console Client on %i
Wants=dropbearkey.service
After=dropbearkey.service

[Service]
# Unit defaults to a templated service
Environment="DROPBEAR_RSAKEY_DIR=/etc/dropbear"
EnvironmentFile=/etc/default/dropbear
EnvironmentFile=-/etc/default/obmc-console-client
ExecStart=/usr/sbin/dropbear -r ${DROPBEAR_RSAKEY_DIR}/dropbear_rsa_host_key -c "/usr/bin/obmc-console-client -c /etc/obmc-console/client.%i.conf" -p %i -F $DROPBEAR_EXTRA_ARGS
SyslogIdentifier=console-client-%i
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
```

We realise the obmc-console-ssh at .service template by installing a
obmc-console-ssh at 2200.service symlink and adding it to the default
target. We realise the obmc-console at .service template by installing
a custom udev rule to trigger the start of the server on the appearance
of the associated tty device (the `ENV{SYSTEMD_WANTS}=` attributes):

```
$ cat /lib/udev/rules.d/61-aspeed-vuart.rules
SUBSYSTEM=="tty", ATTRS{iomem_base}=="0x1E787000", ENV{SYSTEMD_WANTS}="obmc-console at ttyVUART0" SYMLINK+="ttyVUART0", TAG+="systemd"
SUBSYSTEM=="tty", ATTRS{iomem_base}=="0x1E788000", ENV{SYSTEMD_WANTS}="obmc-console at ttyVUART1" SYMLINK+="ttyVUART1", TAG+="systemd"
```

This set of udev rules can be used generally, as due to the
`ConditionPathExists=/etc/obmc-console/server.%i.conf` directive in
obmc-console at .service we won't attempt to run obmc-console-server
unless the associated configuration file is installed.

You may want to review the following patches to understand how to
integrate the configurations into your machine's configuration in
bitbake:

https://gerrit.openbmc-project.xyz/q/topic:%22concurrent-consoles%22+(status:open%20OR%20status:merged)

You'll need a .bbappend file with a do_install_append() in your machine
layer to install the rest of your configuration files.

More work needs to be done to handle the case where your BMC image
caters to multiple platform configurations, but this is at least a start to
handling multiple console servers.

Hope that helps!

Andrew