obmc-console design for multi host support

obmc-console design for multi host support

[Kumar Thangavel]

[-- Attachment #1.1: Type: text/plain, Size: 1475 bytes --]

Hi All,

         Obmc-console application current design may not support multi host or multiple console. So, we proposed the design to handle multi host/multiple console in obmc-console client and server applications.
         Please find the attached design document.

         Could you please review and provide your comments on this.

Thanks,
Kumar.
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

[-- Attachment #1.2: Type: text/html, Size: 3569 bytes --]

[-- Attachment #2: SOL_DESIGN_v1_0.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 219895 bytes --]

Re: obmc-console design for multi host support

[Andrew Jeffery]

Hi Kumar,

On Wed, 19 Feb 2020, at 18:24, Kumar Thangavel wrote:
>  
> Hi All,
> 
> 
>  Obmc-console application current design may not support multi host or 
> multiple console. So, we proposed the design to handle multi 
> host/multiple console in obmc-console client and server applications. 

Thanks for writing a proposal.

> 
>  Please find the attached design document. 
> 
> 
>  Could you please review and provide your comments on this. 

Interesting timing, because I've actually just solved this problem. Please
review this series in Gerrit:

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

Regarding the proposal, I have a few thoughts:

1. Please try to keep it to plain-text
2. If you have code it's best to post it straight away (rather than lead with
a proposal and no code)

On point 1, this is an open-source community and sending documents in
formats like docx might mean that some people can't access them. Plain-
text always works, especially as emails are generally composed that way,
which means you can put your proposal directly in an email and people
can respond to it with ease.

On point 2, it seems that you've included screenshots of code changes
that you have made locally - a few sub-points there:

a. Code is text - you can include snippets of it in your document directly,
which removes the need for rich media formats, which removes the need
for something like docx.

b. If you've got code, push it to github or gerrit and we can look at it
directly!

On point b, given that this proposal largely deals with implementation
details, it's much more effective if you lead with code and then drive a
discussion on the list if necessary. At least this way we have something
concrete to point at and argue about, or in the happy case we can just
merge it and you've avoided the effort of driving redundant discussion.

Finally, these thoughts are about helping you help us help you to get
your code merged with the least amount of effort/friction. Hopefully
they are useful to you :)

Cheers,

Andrew

RE: obmc-console design for multi host support

[Kumar Thangavel]

Hi Andrew,

       Thanks for your response and information.

       Please find my response inline below.

Thanks,
Kumar.

-----Original Message-----
From: Andrew Jeffery <andrew@aj.id.au>
Sent: Thursday, February 20, 2020 5:38 AM
To: Kumar Thangavel <thangavel.k@hcl.com>; openbmc@lists.ozlabs.org
Cc: Jeremy Kerr <jk@ozlabs.org>; Joel Stanley <joel@jms.id.au>; Velumani T-ERS,HCLTech <velumanit@hcl.com>
Subject: Re: obmc-console design for multi host support

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Hi Kumar,

On Wed, 19 Feb 2020, at 18:24, Kumar Thangavel wrote:
>
> Hi All,
>
>
>  Obmc-console application current design may not support multi host or
> multiple console. So, we proposed the design to handle multi
> host/multiple console in obmc-console client and server applications.

Thanks for writing a proposal.

>
>  Please find the attached design document.
>
>
>  Could you please review and provide your comments on this.

Interesting timing, because I've actually just solved this problem. Please review this series in Gerrit:

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fq%2Ftopic%3A%2522concurrent-servers%2522%2B(status%3Aopen%2520OR%2520status%3Amerged&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7Cc3bc8632eb5b4b538a3508d7b59904ba%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637177541130921053&amp;sdata=HIYcn2Cd6tgCrAJCUwTaT5AqUkXfrB25HR0ncpsejdg%3D&amp;reserved=0)

Regarding the proposal, I have a few thoughts:

1. Please try to keep it to plain-text
2. If you have code it's best to post it straight away (rather than lead with a proposal and no code)

Kumar : Sure. Will Keep plain text for posting proposals/code.

On point 1, this is an open-source community and sending documents in formats like docx might mean that some people can't access them. Plain- text always works, especially as emails are generally composed that way, which means you can put your proposal directly in an email and people can respond to it with ease.

On point 2, it seems that you've included screenshots of code changes that you have made locally - a few sub-points there:

a. Code is text - you can include snippets of it in your document directly, which removes the need for rich media formats, which removes the need for something like docx.

b. If you've got code, push it to github or gerrit and we can look at it directly!

Kumar : Sure, Will keep code snippets in the plain text or will push it to github or gerrit.

On point b, given that this proposal largely deals with implementation details, it's much more effective if you lead with code and then drive a discussion on the list if necessary. At least this way we have something concrete to point at and argue about, or in the happy case we can just merge it and you've avoided the effort of driving redundant discussion.

Finally, these thoughts are about helping you help us help you to get your code merged with the least amount of effort/friction. Hopefully they are useful to you :)

Kumar : I looked at your patches and this is really good information and very helpful. Will look more in detail and get back to you.

Cheers,

Andrew
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

RE: obmc-console design for multi host support

[Kumar Thangavel]

Hi Andrew,

             Could you please suggest how to add configs for multiple host ?

Thanks,
Kumar.

-----Original Message-----
From: Kumar Thangavel
Sent: Thursday, February 20, 2020 5:43 PM
To: Andrew Jeffery <andrew@aj.id.au>; openbmc@lists.ozlabs.org
Cc: Jeremy Kerr <jk@ozlabs.org>; Joel Stanley <joel@jms.id.au>; Velumani T-ERS,HCLTech <velumanit@hcl.com>
Subject: RE: obmc-console design for multi host support

Hi Andrew,

       Thanks for your response and information.

       Please find my response inline below.

Thanks,
Kumar.

-----Original Message-----
From: Andrew Jeffery <andrew@aj.id.au>
Sent: Thursday, February 20, 2020 5:38 AM
To: Kumar Thangavel <thangavel.k@hcl.com>; openbmc@lists.ozlabs.org
Cc: Jeremy Kerr <jk@ozlabs.org>; Joel Stanley <joel@jms.id.au>; Velumani T-ERS,HCLTech <velumanit@hcl.com>
Subject: Re: obmc-console design for multi host support

[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]

Hi Kumar,

On Wed, 19 Feb 2020, at 18:24, Kumar Thangavel wrote:
>
> Hi All,
>
>
>  Obmc-console application current design may not support multi host or
> multiple console. So, we proposed the design to handle multi
> host/multiple console in obmc-console client and server applications.

Thanks for writing a proposal.

>
>  Please find the attached design document.
>
>
>  Could you please review and provide your comments on this.

Interesting timing, because I've actually just solved this problem. Please review this series in Gerrit:

https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgerrit.openbmc-project.xyz%2Fq%2Ftopic%3A%2522concurrent-servers%2522%2B(status%3Aopen%2520OR%2520status%3Amerged&amp;data=02%7C01%7Cthangavel.k%40hcl.com%7Cc3bc8632eb5b4b538a3508d7b59904ba%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637177541130921053&amp;sdata=HIYcn2Cd6tgCrAJCUwTaT5AqUkXfrB25HR0ncpsejdg%3D&amp;reserved=0)

Regarding the proposal, I have a few thoughts:

1. Please try to keep it to plain-text
2. If you have code it's best to post it straight away (rather than lead with a proposal and no code)

Kumar : Sure. Will Keep plain text for posting proposals/code.

On point 1, this is an open-source community and sending documents in formats like docx might mean that some people can't access them. Plain- text always works, especially as emails are generally composed that way, which means you can put your proposal directly in an email and people can respond to it with ease.

On point 2, it seems that you've included screenshots of code changes that you have made locally - a few sub-points there:

a. Code is text - you can include snippets of it in your document directly, which removes the need for rich media formats, which removes the need for something like docx.

b. If you've got code, push it to github or gerrit and we can look at it directly!

Kumar : Sure, Will keep code snippets in the plain text or will push it to github or gerrit.

On point b, given that this proposal largely deals with implementation details, it's much more effective if you lead with code and then drive a discussion on the list if necessary. At least this way we have something concrete to point at and argue about, or in the happy case we can just merge it and you've avoided the effort of driving redundant discussion.

Finally, these thoughts are about helping you help us help you to get your code merged with the least amount of effort/friction. Hopefully they are useful to you :)

Kumar : I looked at your patches and this is really good information and very helpful. Will look more in detail and get back to you.

Cheers,

Andrew
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects.
________________________________

Re: 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@.service
and obmc-console-ssh@.service:

```
$ cat /lib/systemd/system/obmc-console@.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@.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@.service template by installing a
obmc-console-ssh@2200.service symlink and adding it to the default
target. We realise the obmc-console@.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@ttyVUART0" SYMLINK+="ttyVUART0", TAG+="systemd"
SUBSYSTEM=="tty", ATTRS{iomem_base}=="0x1E788000", ENV{SYSTEMD_WANTS}="obmc-console@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@.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

Re: obmc-console design for multi host support

[Vijay Khemka]

On 2/27/20, 2:05 AM, "openbmc on behalf of Andrew Jeffery" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of andrew@aj.id.au> wrote:

    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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_obmc-2Dconsole_-2B_29457&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=4KsAgtpglM3uy-zQNrLetDsAK0tWYa6jrJBrPPRer1A&s=UUdti96_TjtKfCwszTKoPFd1nqrxfUY7_9iSYdG80Tc&e= 
    
    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
    ```
What are other contents of client and server conf file other than socket-id?
    
    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:

Can this socket-id be any random word and can this be same across multiple
Host (client/server) configuration. I mean, do we need different socket-id for
client.2200 and client.2201 or it can be same.
    
    ```
    $ 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@.service
    and obmc-console-ssh@.service:
    
    ```
    $ cat /lib/systemd/system/obmc-console@.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@.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@.service template by installing a
    obmc-console-ssh@2200.service symlink and adding it to the default
    target. We realise the obmc-console@.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@ttyVUART0" SYMLINK+="ttyVUART0", TAG+="systemd"
    SUBSYSTEM=="tty", ATTRS{iomem_base}=="0x1E788000", ENV{SYSTEMD_WANTS}="obmc-console@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@.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://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_q_topic-3A-2522concurrent-2Dconsoles-2522-2B-28status-3Aopen-2520OR-2520status-3Amerged-29&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=4KsAgtpglM3uy-zQNrLetDsAK0tWYa6jrJBrPPRer1A&s=LRpDvGH-Ed553168urLDLuEpA5ZGYX89pDwsbvrGDOU&e= 
    
    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
    

Re: obmc-console design for multi host support

[Andrew Jeffery]

On Fri, 28 Feb 2020, at 18:00, Vijay Khemka wrote:
> On 2/27/20, 2:05 AM, "openbmc on behalf of Andrew Jeffery" 
>     
>     ```
>     $ ls -1 /etc/obmc-console
>     client.2200.conf
>     server.ttyVUART0.conf
>     ```
> What are other contents of client and server conf file other than socket-id?

Whatever else you were previously specifying for the server.

>     
>     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:
> 
> Can this socket-id be any random word and can this be same across multiple
> Host (client/server) configuration. I mean, do we need different socket-id for
> client.2200 and client.2201 or it can be same.

The socket-id is a unique portion for the unix domain socket created by the
obmc-console-server instance. The server needs to know this because it needs
to know what to name the pipe; the client needs to know it as it needs to form
the abstract socket name to which to connect.

In general unless you're looking to expose the same console on _different_
network ports, you want to pair each client with a unique server.

Here's an ASCII diagram:

               +--------------------------------------------------------------------------------------------+
               |                                                                                            |
               |       obmc-console-client      unix domain socket         obmc-console-server              |
               |                                                                                            |
               |     +---------------------+                           +------------------------+           |
               |     | client.2201.conf    |  +---------------------+  | server.ttyVUART1.conf  |           |
           +---+--+  +---------------------+  |                     |  +------------------------+  +--------+-------+
Network    | 2201 +-->                     +->+ @obmc-console.host1 +<-+                        <--+ /dev/ttyVUART1 |   UARTs
           +---+--+  | socket-id = "host1" |  |                     |  | socket-id = "host1"    |  +--------+-------+
               |     |                     |  +---------------------+  |                        |           |
               |     +---------------------+                           +------------------------+           |
               |                                                                                            |
               |                                                                                            |
               |                                                                                            |
               +--------------------------------------------------------------------------------------------+

Does that help?

Andrew

Re: obmc-console design for multi host support

[Andrew Jeffery]

On Thu, 27 Feb 2020, at 20:34, Andrew Jeffery wrote:

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

Just following up on the .bbappend - the change for the base recipe is here:

https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/29747/1/recipes-phosphor/console/obmc-console_git.bb

In that context, .bbappends for enabling concurrent console servers should
look something like this for an example machine called 'foo':

```
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://server.ttyVUART0.conf"
SRC_URI_append_foo = " file://client.2201.conf"
SRC_URI_append_foo = " file://server.ttyVUART1.conf"

SRC_URI_remove = "file://${BPN}.conf"

REGISTERED_SERVICES_${PN}_append_foo = " obmc_console_guests:tcp:2201:"

SYSTEMD_SERVICE_${PN}_append_foo = " obmc-console-ssh@2200.service \
		obmc-console-ssh@2201.service \
                "
SYSTEMD_SERVICE_${PN}_remove_foo = "obmc-console-ssh.socket"

FILES_${PN}_remove_foo = "/lib/systemd/system/obmc-console-ssh@.service.d/use-socket.conf"

EXTRA_OECONF_append_foo = " --enable-concurrent-servers"

do_install_append_foo() {
        # Install configuration for the servers and clients. Keep commandline
        # compatibility with previous configurations by defaulting to not
        # specifying a socket-id for VUART0/2200
        install -m 0755 -d ${D}${sysconfdir}/${BPN}

        # Remove the default client configuration as we don't to define a
        # socket-id for the 2200 console
        rm -f ${D}${sysconfdir}/${BPN}/client.2200.conf

        # However, now link to /dev/null as a way of not specifying a
        # socket-id while having a configuration file present. We need to
        # provide a configuration path to meet the requirements of the packaged
        # unit file.
        ln -sr ${D}/dev/null ${D}${sysconfdir}/${BPN}/client.2200.conf

        # We need to populate socket-id for remaining consoles
        install -m 0644 ${WORKDIR}/client.2201.conf ${D}${sysconfdir}/${BPN}/

        # Install configuration for remaining servers - the base recipe
        # installs the configuration for the first.
        install -m 0644 ${WORKDIR}/server.ttyVUART1.conf ${D}${sysconfdir}/${BPN}/
}
```

Hope that helps.

Andrew

Re: obmc-console design for multi host support

[Joseph Reynolds]

On 3/2/20 10:03 PM, Andrew Jeffery wrote:
> On Fri, 28 Feb 2020, at 18:00, Vijay Khemka wrote:
>> On 2/27/20, 2:05 AM, "openbmc on behalf of Andrew Jeffery"
>>      
>>      ```
>>      $ ls -1 /etc/obmc-console
>>      client.2200.conf
>>      server.ttyVUART0.conf
>>      ```
>> What are other contents of client and server conf file other than socket-id?
> Whatever else you were previously specifying for the server.
>
>>      
>>      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:
>>
>> Can this socket-id be any random word and can this be same across multiple
>> Host (client/server) configuration. I mean, do we need different socket-id for
>> client.2200 and client.2201 or it can be same.
> The socket-id is a unique portion for the unix domain socket created by the
> obmc-console-server instance. The server needs to know this because it needs
> to know what to name the pipe; the client needs to know it as it needs to form
> the abstract socket name to which to connect.
>
> In general unless you're looking to expose the same console on _different_
> network ports, you want to pair each client with a unique server.
>
> Here's an ASCII diagram:
>
>                 +--------------------------------------------------------------------------------------------+
>                 |                                                                                            |
>                 |       obmc-console-client      unix domain socket         obmc-console-server              |
>                 |                                                                                            |
>                 |     +---------------------+                           +------------------------+           |
>                 |     | client.2201.conf    |  +---------------------+  | server.ttyVUART1.conf  |           |
>             +---+--+  +---------------------+  |                     |  +------------------------+  +--------+-------+
> Network    | 2201 +-->                     +->+ @obmc-console.host1 +<-+                        <--+ /dev/ttyVUART1 |   UARTs
>             +---+--+  | socket-id = "host1" |  |                     |  | socket-id = "host1"    |  +--------+-------+
>                 |     |                     |  +---------------------+  |                        |           |
>                 |     +---------------------+                           +------------------------+           |
>                 |                                                                                            |
>                 |                                                                                            |
>                 |                                                                                            |
>                 +--------------------------------------------------------------------------------------------+
>
> Does that help?

Nice diagram!  Can this be added to
https://github.com/openbmc/obmc-console/blob/master/README.md

I tried to capture this network interface in an architecture review here:
https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/27969/3/architecture/interface-overview.md#130
which also includes 'ipmi sol activate' and hostlogger.

Please let me know the best way to document this in the project?  I 
would be happy to remove details from the doc-under-review and point to 
the obmc-console README.  Does that sound right?

- Joseph

>
> Andrew

Re: obmc-console design for multi host support

[Andrew Jeffery]

On Wed, 4 Mar 2020, at 03:53, Joseph Reynolds wrote:
> 
> 
> On 3/2/20 10:03 PM, Andrew Jeffery wrote:
> > On Fri, 28 Feb 2020, at 18:00, Vijay Khemka wrote:
> >> On 2/27/20, 2:05 AM, "openbmc on behalf of Andrew Jeffery"
> >>      
> >>      ```
> >>      $ ls -1 /etc/obmc-console
> >>      client.2200.conf
> >>      server.ttyVUART0.conf
> >>      ```
> >> What are other contents of client and server conf file other than socket-id?
> > Whatever else you were previously specifying for the server.
> >
> >>      
> >>      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:
> >>
> >> Can this socket-id be any random word and can this be same across multiple
> >> Host (client/server) configuration. I mean, do we need different socket-id for
> >> client.2200 and client.2201 or it can be same.
> > The socket-id is a unique portion for the unix domain socket created by the
> > obmc-console-server instance. The server needs to know this because it needs
> > to know what to name the pipe; the client needs to know it as it needs to form
> > the abstract socket name to which to connect.
> >
> > In general unless you're looking to expose the same console on _different_
> > network ports, you want to pair each client with a unique server.
> >
> > Here's an ASCII diagram:
> >
> >                 +--------------------------------------------------------------------------------------------+
> >                 |                                                                                            |
> >                 |       obmc-console-client      unix domain socket         obmc-console-server              |
> >                 |                                                                                            |
> >                 |     +---------------------+                           +------------------------+           |
> >                 |     | client.2201.conf    |  +---------------------+  | server.ttyVUART1.conf  |           |
> >             +---+--+  +---------------------+  |                     |  +------------------------+  +--------+-------+
> > Network    | 2201 +-->                     +->+ @obmc-console.host1 +<-+                        <--+ /dev/ttyVUART1 |   UARTs
> >             +---+--+  | socket-id = "host1" |  |                     |  | socket-id = "host1"    |  +--------+-------+
> >                 |     |                     |  +---------------------+  |                        |           |
> >                 |     +---------------------+                           +------------------------+           |
> >                 |                                                                                            |
> >                 |                                                                                            |
> >                 |                                                                                            |
> >                 +--------------------------------------------------------------------------------------------+
> >
> > Does that help?
> 
> Nice diagram!  Can this be added to
> https://github.com/openbmc/obmc-console/blob/master/README.md
> 
> I tried to capture this network interface in an architecture review 
> here:
> https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/27969/3/architecture/interface-overview.md#130
> which also includes 'ipmi sol activate' and hostlogger.
> 
> Please let me know the best way to document this in the project?  I 
> would be happy to remove details from the doc-under-review and point to 
> the obmc-console README.  Does that sound right?

Sure, if the diagram was useful for you then it's probably useful for
others too.

For what it's worth, I drew it using http://asciiflow.com/

Andrew

Re: obmc-console design for multi host support

[Vijay Khemka]

Perfect, It is working for all four server for me.

On 3/2/20, 8:03 PM, "Andrew Jeffery" <andrew@aj.id.au> wrote:

    On Fri, 28 Feb 2020, at 18:00, Vijay Khemka wrote:
    > On 2/27/20, 2:05 AM, "openbmc on behalf of Andrew Jeffery" 
    >     
    >     ```
    >     $ ls -1 /etc/obmc-console
    >     client.2200.conf
    >     server.ttyVUART0.conf
    >     ```
    > What are other contents of client and server conf file other than socket-id?
    
    Whatever else you were previously specifying for the server.
    
    >     
    >     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:
    > 
    > Can this socket-id be any random word and can this be same across multiple
    > Host (client/server) configuration. I mean, do we need different socket-id for
    > client.2200 and client.2201 or it can be same.
    
    The socket-id is a unique portion for the unix domain socket created by the
    obmc-console-server instance. The server needs to know this because it needs
    to know what to name the pipe; the client needs to know it as it needs to form
    the abstract socket name to which to connect.
    
    In general unless you're looking to expose the same console on _different_
    network ports, you want to pair each client with a unique server.
    
    Here's an ASCII diagram:
    
                   +--------------------------------------------------------------------------------------------+
                   |                                                                                            |
                   |       obmc-console-client      unix domain socket         obmc-console-server              |
                   |                                                                                            |
                   |     +---------------------+                           +------------------------+           |
                   |     | client.2201.conf    |  +---------------------+  | server.ttyVUART1.conf  |           |
               +---+--+  +---------------------+  |                     |  +------------------------+  +--------+-------+
    Network    | 2201 +-->                     +->+ @obmc-console.host1 +<-+                        <--+ /dev/ttyVUART1 |   UARTs
               +---+--+  | socket-id = "host1" |  |                     |  | socket-id = "host1"    |  +--------+-------+
                   |     |                     |  +---------------------+  |                        |           |
                   |     +---------------------+                           +------------------------+           |
                   |                                                                                            |
                   |                                                                                            |
                   |                                                                                            |
                   +--------------------------------------------------------------------------------------------+
    
    Does that help?
    
    Andrew
    

Re: obmc-console design for multi host support

[Vijay Khemka]

Hi Andrew,
I have a question as why do we need obmc-console-ssh.socket and obmc-console-ssh@.service. 
Especially when using in concurrent servers do we need to create these for each client/server socket?

This may be a basic question but I want to understand this more.

Regards
-Vijay

On 3/2/20, 8:19 PM, "openbmc on behalf of Andrew Jeffery" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of andrew@aj.id.au> wrote:

    
    
    On Thu, 27 Feb 2020, at 20:34, Andrew Jeffery wrote:
    
    > 
    > You'll need a .bbappend file with a do_install_append() in your machine
    > layer to install the rest of your configuration files.
    > 
    
    Just following up on the .bbappend - the change for the base recipe is here:
    
    https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_meta-2Dphosphor_-2B_29747_1_recipes-2Dphosphor_console_obmc-2Dconsole-5Fgit.bb&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=1-CxtAkTLEtpmrw0zNxaJWDWKC1n3zMEPSWErzgz6Ow&s=4F0YCLIwY_2nNtoNQ3nhkPlN1iU1d8O2EX3cOhtz8no&e= 
    
    In that context, .bbappends for enabling concurrent console servers should
    look something like this for an example machine called 'foo':
    
    ```
    FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
    
    SRC_URI += "file://server.ttyVUART0.conf"
    SRC_URI_append_foo = " file://client.2201.conf"
    SRC_URI_append_foo = " file://server.ttyVUART1.conf"
    
    SRC_URI_remove = "file://$%7BBPN%7D.conf"
    
    REGISTERED_SERVICES_${PN}_append_foo = " obmc_console_guests:tcp:2201:"
    
    SYSTEMD_SERVICE_${PN}_append_foo = " obmc-console-ssh@2200.service \
    		obmc-console-ssh@2201.service \
                    "
    SYSTEMD_SERVICE_${PN}_remove_foo = "obmc-console-ssh.socket"
    
    FILES_${PN}_remove_foo = "/lib/systemd/system/obmc-console-ssh@.service.d/use-socket.conf"
    
    EXTRA_OECONF_append_foo = " --enable-concurrent-servers"
    
    do_install_append_foo() {
            # Install configuration for the servers and clients. Keep commandline
            # compatibility with previous configurations by defaulting to not
            # specifying a socket-id for VUART0/2200
            install -m 0755 -d ${D}${sysconfdir}/${BPN}
    
            # Remove the default client configuration as we don't to define a
            # socket-id for the 2200 console
            rm -f ${D}${sysconfdir}/${BPN}/client.2200.conf
    
            # However, now link to /dev/null as a way of not specifying a
            # socket-id while having a configuration file present. We need to
            # provide a configuration path to meet the requirements of the packaged
            # unit file.
            ln -sr ${D}/dev/null ${D}${sysconfdir}/${BPN}/client.2200.conf
    
            # We need to populate socket-id for remaining consoles
            install -m 0644 ${WORKDIR}/client.2201.conf ${D}${sysconfdir}/${BPN}/
    
            # Install configuration for remaining servers - the base recipe
            # installs the configuration for the first.
            install -m 0644 ${WORKDIR}/server.ttyVUART1.conf ${D}${sysconfdir}/${BPN}/
    }
    ```
    
    Hope that helps.
    
    Andrew
    

Re: obmc-console design for multi host support

[Andrew Jeffery]

Hi Vijay,

On Fri, 6 Mar 2020, at 08:28, Vijay Khemka wrote:
> Hi Andrew,
> I have a question as why do we need obmc-console-ssh.socket and 
> obmc-console-ssh@.service. 

obmc-console-ssh.socket is not used in the concurrent-server context.
It can't be, for reasons outlined below.

obmc-console-ssh@.service is always required, but how it works changes
based on whether obmc-console-ssh.socket is used or not. The behaviour
is changed by the presence or absence of
obmc-console-ssh@.service.d/use-socket.conf which overrides the
ExecStart property of obmc-console-ssh@.service and requires the
presence of obmc-console-ssh.socket.

Prior to implementing concurrent server support in obmc-console, the
dropbear instance that launches the clients was itself launched using
systemd socket-activation:

https://www.freedesktop.org/software/systemd/man/systemd.socket.html

This has the benefit of minimising memory consumed in the system by not
starting dropbear until the first connection is received. The updates to the
obmc-console recipe that pull in the upstream concurrent-server support
maintain this behaviour for systems that do not require concurrent-server
support (all platforms supported upstream), however due to systemd
constraints on the interaction between socket and service units it's not 
possible to use socket-activation and support concurrent servers in a
generic fashion.*

So to clarify,  the changes to the obmc-console.bb recipe assumes by
default that the system it's being installed on does _not_  require
concurrent-server support, and as a consequence configures the package
to install obmc-console-ssh.socket and
obmc-console-ssh@.service.d/use-socket.conf. It is necessary to opt-in to
enabling concurrent-server support in a bbappend, and doing so requires
changes similar to those outlined in my previous email. Configuring the
package with --enable-concurrent-servers will install _neither_
obmc-console-ssh.socket _nor_
obmc-console-ssh@.service.d/use-socket.conf (in-fact, this is all the
--enable-concurrent-servers configure switch controls). The declarations
needed in the .bbappend enabling concurrent-servers roughly fall into
two categories:

1. Telling bitbake about the extra server/client configuration files
2. Modifying bitbake variables to remove the units that won't be installed
(i.e. obmc-console-ssh.socket and
obmc-console-ssh@.service.d/use-socket.conf)

Hope that helps.

Andrew

* Specifically, when systemd starts the service associated with a socket unit
the parameter for the service template unit is a unique integer that has no
association with the template parameter for the socket unit. This means
we can't have the port number passed from the socket unit to the service
unit as a template parameter and therefore don't know which configuration
to choose in the service unit. The only way to make this work is to define
pairs of socket and service units that have the port baked into the service
name (as the service unit still must be a template to support the connection
number). That's quite awkward, so I just chose to instantiate the dropbear
instances directly and avoid socket-activation.


> Especially when using in concurrent servers do we need to create these 
> for each client/server socket?
> 
> This may be a basic question but I want to understand this more.
> 
> Regards
> -Vijay
> 
> On 3/2/20, 8:19 PM, "openbmc on behalf of Andrew Jeffery" 
> <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of 
> andrew@aj.id.au> wrote:
> 
>     
>     
>     On Thu, 27 Feb 2020, at 20:34, Andrew Jeffery wrote:
>     
>     > 
>     > You'll need a .bbappend file with a do_install_append() in your machine
>     > layer to install the rest of your configuration files.
>     > 
>     
>     Just following up on the .bbappend - the change for the base recipe is here:
>     
>     
> https://urldefense.proofpoint.com/v2/url?u=https-3A__gerrit.openbmc-2Dproject.xyz_c_openbmc_meta-2Dphosphor_-2B_29747_1_recipes-2Dphosphor_console_obmc-2Dconsole-5Fgit.bb&d=DwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=v9MU0Ki9pWnTXCWwjHPVgpnCR80vXkkcrIaqU7USl5g&m=1-CxtAkTLEtpmrw0zNxaJWDWKC1n3zMEPSWErzgz6Ow&s=4F0YCLIwY_2nNtoNQ3nhkPlN1iU1d8O2EX3cOhtz8no&e= 
>     
>     In that context, .bbappends for enabling concurrent console servers should
>     look something like this for an example machine called 'foo':
>     
>     ```
>     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>     
>     SRC_URI += "file://server.ttyVUART0.conf"
>     SRC_URI_append_foo = " file://client.2201.conf"
>     SRC_URI_append_foo = " file://server.ttyVUART1.conf"
>     
>     SRC_URI_remove = "file://$%7BBPN%7D.conf"
>     
>     REGISTERED_SERVICES_${PN}_append_foo = " obmc_console_guests:tcp:2201:"
>     
>     SYSTEMD_SERVICE_${PN}_append_foo = " obmc-console-ssh@2200.service \
>     		obmc-console-ssh@2201.service \
>                     "
>     SYSTEMD_SERVICE_${PN}_remove_foo = "obmc-console-ssh.socket"
>     
>     FILES_${PN}_remove_foo = 
> "/lib/systemd/system/obmc-console-ssh@.service.d/use-socket.conf"
>     
>     EXTRA_OECONF_append_foo = " --enable-concurrent-servers"
>     
>     do_install_append_foo() {
>             # Install configuration for the servers and clients. Keep 
> commandline
>             # compatibility with previous configurations by defaulting 
> to not
>             # specifying a socket-id for VUART0/2200
>             install -m 0755 -d ${D}${sysconfdir}/${BPN}
>     
>             # Remove the default client configuration as we don't to define a
>             # socket-id for the 2200 console
>             rm -f ${D}${sysconfdir}/${BPN}/client.2200.conf
>     
>             # However, now link to /dev/null as a way of not specifying 
> a
>             # socket-id while having a configuration file present. We 
> need to
>             # provide a configuration path to meet the requirements of 
> the packaged
>             # unit file.
>             ln -sr ${D}/dev/null 
> ${D}${sysconfdir}/${BPN}/client.2200.conf
>     
>             # We need to populate socket-id for remaining consoles
>             install -m 0644 ${WORKDIR}/client.2201.conf 
> ${D}${sysconfdir}/${BPN}/
>     
>             # Install configuration for remaining servers - the base 
> recipe
>             # installs the configuration for the first.
>             install -m 0644 ${WORKDIR}/server.ttyVUART1.conf 
> ${D}${sysconfdir}/${BPN}/
>     }
>     ```
>     
>     Hope that helps.
>     
>     Andrew
>     
> 
>