A LAVA hacking session is a special lava-test-shell test that provides interactive ssh access to a LAVA device inside a defined test environment. This support differs from the normal LAVA SSH protocol support in that the job waits for a real user to log in, instead of using an ssh connection to run a test shell.
Some devices may need parameters to configure the network correctly to allow the user to log in to the hacking session. e.g. QEMU jobs need to setup a tap device:
context:
arch: amd64
netdevice: tap
There are test definitions for hacking sessions provided by the LAVA developers at https://git.linaro.org/lava-team/hacking-session.git . Currently the following definitions are supported:
There are several extra parameters to set when using these test definitions, some optional:
- test:
failure_retry: 3
name: kvm-basic-hacking-session
timeout:
minutes: 5
definitions:
- repository: https://git.linaro.org/lava-team/hacking-session.git
from: git
path: hacking-session-debian.yaml
name: hacking
parameters:
"IRC_USER": "TYPE YOUR IRC NICK HERE"
"PUB_KEY": "PASTE_PUBKEY(S) HERE"
It is possible to include multiple hacking sessions in the same job, even interleaved with other test actions.
See also
Hacking Session timeouts and Timeouts for clarification of the timeout support.
The hacking session test definition will log the ssh command line needed for connection into the LAVA log file. To access the log file, you can use a web browser; navigate to your hacking session and scroll to the end of the job to see this command line, For an example see:
If your test device is located on a remote network, you may need to gain access via an ssh tunnel. If so:
verify your SSH key is setup and configured to connect:
~# ssh -T username@example.com
Modify your SSH config to allow agent forwarding:
Host example.com
ForwardAgent yes
Once logged in to the hacking session, the lava-test-shell helper functions can be found on the test device in the directory /lava/bin
During a hacking session, LAVA listens to the primary serial connection for the duration of the hacking session. From within the test device, any text you echo to that serial connection will therefore be recorded within LAVA. You may need to work out the correct device name for this connection, for example by looking at the CONSOLE setting in /proc/cmdline.
As an example, in a QEMU test, the device name will be /dev/ttyS0. From within the hacking session:
root@kvm01:~# echo "This is a test statement" > /dev/ttyS0
will output to the LAVA log like:
This is a test statement
There is an example of this online at https://validation.linaro.org/scheduler/job/116632/log_file#L_5_12
During a hacking session, your test device can’t be used for other tasks. This will block other users who may want to run tests using the device. For that reason, your session is monitored for Hacking Session timeouts, or you can complete your session immediately:
- Log out of your session (you can avoid closing the session on logout using the Continuing a Hacking Session support).
- Cancel the job in the LAVA using the link in the job detail or job log pages.
- Stop - Use the helper function stop_hacking from the command line within the hacking session
Note
Cancel will end the entire job immediately. Use stop_hacking to close the session and complete normal job processing that may be defined after the hacking session.
Note
This behaviour changed after a session at Connect HKG15
All hacking sessions will time out after 1 hour if a login has not been detected. If an IRC_USER is specified, another IRC private messages will be sent to that user explaining the termination.
The timer is running for the lifetime of the hacking session, so if you use Continuing a Hacking Session and logout, you will still need to log back in within one hour.
The session will timeout, regardless of activity, when the top-level timeout specified in the job is reached.
This support is separate from the Timeouts handling of the test job.
If you want to be able to log out of a hacking session and log back in within the inactivity timeout, call the continue_hacking script from the command line within the hacking session. The hacking session is still monitored for Hacking Session timeouts, so do remember to log back in.