Primary remote connection¶
When a test device does not have support at all for a primary serial connection, there is another, more limited way of using it in LAVA - the Primary Remote Connection. For this to work, the test device must boot automatically and start a remote login daemon (e.g. sshd) with configured authentication. The TestJob for a primary remote connection then skips the deploy stage and uses a simple boot method which just establishes the connection. A device providing a primary remote connection in LAVA only provides access to that connection via a single submitted TestJob at a time. A MultiNode job can make multiple connections, but other jobs will see the device as busy and not be able to start their connections.
Primary remote connections can raise issues of
Persistence - the test writer is solely responsible for
deleting any sensitive data copied, prepared or downloaded using a
primary remote connection. Do not leave sensitive data for the next
TestJob to find. Wherever possible, use primary remote connections
schroot support so that each job is kept within a
temporary chroot, thereby also allowing
more than one primary (schroot) remote connection on a single
It is not necessarily required that a device offering a primary remote connection is permanently powered on. The only connections being made to the device are done via the scheduler, which ensures that only one TestJob can use any one device at a time. Depending on how long it takes to boot the device, it is feasible to have a device offering primary remote connections which is powered down between jobs.
A Primary Remote Connection is established by the dispatcher, and is therefore constrained in the options which are available to the client requesting the connection, The TestJob has no control over the arguments passed to the connection.
Primary remote connections are affected by Security issues due to the requirements of automation.