r4d means 'Remote For Device-under-test' and is an infrastructure for power-control and console access for multiple Linux Boards that should be controlled by a test-infrastructure like jenkins.

r4dd (Remote For Device-under-test Daemon) acts as controlling server for test racks. Each Rack contains a serial device server and a power control switch. A rack can host several DUTs (device-under-test). r4d connects to the serial device server and the power switch to perform actions on user request. A user connects to r4d through a SOAP interface.

All available boards, racks, power-controls and serial servers are represented in a sqlite database. To show/create or modify the database the 'r4dcfg' tool can be used. If the tooling is to limited for your needs we recommend to use the 'SQLite Manager Plugin for Firefox' to manually alter the database.

Have also a look at 'https://github.com/ci-rt/libvirt-debian'. This project provides a r4d_driver for libvirt. So you can poweron/off the boards managed in r4d via libvirt. You can even access the serial console of your boards with a command like 'virsh -c r4d://localhost:8008 console juno64'

On Debian systems you can simply run: "sudo apt install python3-sqlalchemy python3-pysimplesoap python3-snimpy snmp-mibs-downloader" to satisfy all runtime dependencies.

Note, that the 'snmp-mibs-downloader' package is in the non-free section of Debian.

Use 'python3 setup.py install' to build and install r4d. The so installed systemd service file can be used to control the daemon:

$ systemctl enable r4dd # start it automatically during system boot $ systemctl start r4dd # start it manually (once) $ systemctl stop r4dd # stop it now

Simply start "./r4dd"

The listen interface and port and the used database backend can be altered via config file that can be passed to r4dd with the -c parameter:

$ r4dd -c /etc/r4d.cfg

The format of /etc/r4d.cfg looks like this:

[r4dd]
listen=0.0.0.0
port=8008
[db]
echo=0
uri=sqlite:////var/lib/r4d/r4d.sqlite
user=None
password=None

If no file is given, the above config reflects the defaults.

To add a new power switch, serial console server or a testsystem the commandline tool "r4dcfg" can be used. This tool should be executed as the same user who runs the daemon. The daemon creates the database.

Please call "r4dcfg --add-rack NAME LOCATION" where NAME is a unique human readable name of the testrack, e.g. 'ci-linux-rack3'. LOCATION describes the physical location, e.g. a room number 'SRV07-OU21'.

$ r4dcfg --add-rack ci-linux-rack3 SRV07-OU21

Please call "r4dcfg --add-power RACK MODEL HOST" where RACK is the human-readable name of the rack the switch is installed in, e.g. 'ci-linux-rack3', MODEL is the power switch model, e.g. 'pc8210' and HOST the hostname or IP of the new power switch, e.g. 'ci-linux-rack3-power.tec.company.example'

The following models are supported:

• net8x (Gude Expert Power Control NET 8x)

• pc8210 (Gude Expert Power Control 8210 / 8211)

  $ r4dcfg --add-power ci-linux-rack3 pc8210 ci-linux-rack3-power.tec.company.example

If you get the error "No SNMP response received before timeout" you need to activate enable SNMP get for public and set for private in the config / SNMP section of the webinterface of the power control switch.

Please call "r4dcfg --add-serial RACK MODEL HOST" where RACK is the human-readable name of the rack the serial server is installed in, e.g. 'ci-linux-rack3', MODEL is the serial server model, e.g. 'PS810' and HOST the hostname or IP of the new serial server, e.g. 'ci-linux-rack3-serial.tec.company.example'

The following model is supported: - ps810 (Sena Pro Series PS810)

$ r4dcfg --add-serial ci-linux-rack3 PS810 ci-linux-rack3-serial.tec.company.example

Please call "r4dcfg --add-board RACK SLOT NAME" where RACK is the human-readable name of the rack the 'device under test'is installed in, e.g. 'ci-linux-rack3', SLOT is the position inside the rack, e.g. '5' for slot number 5. Slot 5 should be connected with port 5 of the powercontrol switch and port 5 of the serial server. NAME is the name of the new device under test, e.g. 'juno64'

$ r4dcfg --add-board ci-linux-rack3 5 juno64

Use

$ r4dcfg --show-db

to get an overview of the configured infrastructure.

$ r4dcfg --list-boards

ID[1]: el9jyJpAN1aZNTGiuQpB6g==
Name: juno64      Rack: ci-linux-rack3     Port: 5 serial: ci-linux-rack3-serial.tec.company.example:7005

The 'ID[1]' means board is powered, 'ID[0]' board is poweroff and 'ID[-1]' power state of bard is unknown.

To switch the powerstate off a board, the following commands can be used:

$ r4dcfg --poweron juno64 $ r4dcfg --poweroff juno64 $ r4dcfg --powercycle juno64

This commands are for testing the infrastructure! To control the boards from e.g. jenkins or other systems in your LAN please use libvirt as described in the intro!

To move a board to a different rack and/or slot use "r4dcfg --move-board DST_RACK DST_SLOT NAME" where DST_RACK is the name of the new rack the board should be placed in, DST_SLOT is the number of the new slot it should be placed and NAME is the name of the board that should be moved. If DST_RACK is the same as the current rack the board is placed in the command can be used to move the board to a different slot in the same rack. E.g. to move the juno64 board into slot 8 use the following command:

$ r4dcfg --move-board ci-linux-rack3 8 juno64

To delete a board from the infrastructure you should use "r4dcfg --delete-board NAME" where NAME is the name of the board to be removed. E.g. to remove the juno64 board from the infrastructure use:

$ r4dcfg --delete-board juno64