User Tools

Site Tools


soft:server-apps-firmware

Firmware Application

This pluggable app enables firmware image generation for research devices.

Build info available in JSON format at /admin/nodes/node/<node_id>/firmware/build_info/

Settings

  • FIRMWARE_BASE_IMAGE_STORAGE storage object, which handles the storage and retrieval of your base image files, use django file system storage by default.
  • FIRMWARE_BASE_IMAGE_PATH directory where store the uploaded base images, relative to PRIVATE_MEDIA_ROOT, 'firmwares/' by default.
  • FIRMWARE_BUILD_IMAGE_STORAGE storage object, which handles the storage and retrieval of your built image files, use django file system storage by default.
  • FIRMWARE_BUILD_IMAGE_PATH directory where store the generated fimware, relative to PRIVATE_MEDIA_ROOT, 'firmwares/' by default.

Plugins Settings

  • FIRMWARE_PLUGINS_USB_IMAGE path to the usb image used to put the firmware in, '%(site_root)s/confine-install.img.gz' by default.
  • FIRMWARE_PLUGINS_PASSWORD_DEFAULT Default root password set while building the firmware, 'confine' by default.
  • FIRMWARE_PLUGINS_INITIAL_AUTH_KEYS_PATH path to authorized SSH public key(s) for remote management. It defaults to maintenance app pub key in case it is installed, empty otherwise.

Workflow

  1. The node owner clicks on generate research device firmware
  2. The firmware generation process performs asynchronous from the request-response cycle. This is achieved using Django-Celery Message queue with RabbitMQ
  3. Once the firmware is cooked the system should inform the user that the firmware is ready for download. It can be done via email or an ajax message or using django.contrib.messages(but we should avoid this last one because is synchronous), or in more than one way.

Keys issue

If the server generates a “self-contained” RD images it has to know in advance what are the RD cryptographic keys, so the pv_key has to be stored somewhere. Add priv key to ResearchDevice ?? or impose to the researcher the need to upload a pubkey afterwards?

This problem can be reduced into two approaches:

  1. Server handles key generation:
    • Advantage: Transparent for node owner (he doesn't need to know anything about keys, just download the image and flash on their device)
    • Disvantage: Security design is not best practice put anyway it doesn't have any practical disvantage
  2. Node Owner handles the keys:
    • Advantage: Security design is correct
    • Disvantage: Node owner needs to manually upload the pubkey

REST API (controller)

Firmware can be managed using the controller API. Here you can found some use case examples:

Firmware not available

GET /api/nodes/3/ctl/firmware/
 
HTTP 404 NOT FOUND
Vary: Accept
Content-Type: text/html; charset=utf-8
Allow: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
 
{
    "detail": "Not found"
}

Firmware available

GET /api/nodes/2/ctl/firmware/
 
HTTP 200 OK
Link: <http://vct:8888/api/>; rel="http://confine-project.eu/rel/server/base"
Content-Type: text/html; charset=utf-8
Allow: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
Vary: Accept
 
{
    "state": "AVAILABLE", 
    "progress": 100, 
    "next": null, 
    "description": "Building process finished", 
    "content_message": "Firmware available for download.", 
    "image_url": "http://vct:8888/private/firmware/build/image/2/confine-firmware-2-i686.img.gz", 
    "date": "2014-02-24T10:28:33.306Z"
}

Request firmware build

You can configure node firmware build by passing the following optional parameters:

  • base_image_id: base image ID for building the firmware (check /api/baseimages/ for a list of available base images).
  • registry_base_uri: a URI where an endpoint of the registry API can be accessed.
  • registry_cert: An X.509 PEM-encoded certificate for the API endpoint. Required for HTTPS and other encrypted connections.
  • tinc_default_gateway: host name used as default gateway for tinc.

Related to node admins authentication:

  • allow_node_admins: enable this option to permanently allow the current group and node administrators' SSH keys to log into the node as root.
  • ssh_auth: enter additional SSH keys (in “authorized_keys” format) permanently allowed to log into the node as root.
  • sync_node_admins: enable this option to also allow current or future group and node administrators' SSH keys (as configured in the registry) to log into the node as root. Please note that this may expose your node to an attack if the testbed registry is compromised.
  • disable_password: disable root authentiation using password method.
  • password: enter a password to be set for the root user.

Other options related to plugins:

  • usb_image: Select this option if you want to install the node image from a USB stick.
# ALL the fields are OPTIONAL.
POST /api/nodes/3/ctl/firmware/
{
    "base_image_id": 1,
    "registry_base_uri": "https://[fd65:fc41:c50f::2]/api/",
    "registry_cert": "-----BEGIN CERTIFICATE-----...",
    "tinc_default_gateway": "server",
    "allow_node_admins": true,
    "ssh_auth": "",
    "sync_node_admins": false,
    "disable_password": false,
    "password": "secret",
    "usb_image": true
}
 
HTTP 202 ACCEPTED
Vary: Accept
Content-Type: text/html; charset=utf-8
Allow: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
 
{
    "state": "REQUESTED", 
    "progress": null, 
    "next": null, 
    "description": "Waiting for your building task to begin. ...", 
    "content_message": "Building task received.", 
    "image_url": null, 
    "date": "2014-02-25T09:11:08.317Z"
}
 
# NOTE: you can get build progress making GET requests until state == AVAILABLE

Request firmware build but NO base image compatible available

POST /api/nodes/1/ctl/firmware/
HTTP 404 NOT FOUND
Vary: Accept
Content-Type: text/html; charset=utf-8
Allow: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS
 
{
    "detail": "No base image compatible with the architecture of this node."
}
soft/server-apps-firmware.txt · Last modified: 2015/04/01 11:56 by santiago