FIDO Device Onboarding (FDO) - Lab

In this lab you are going to:

Deploy and configured the FDO servers in one (Option 1) or multiple nodes (Option 2).
Customize the FDO onboarding automation with your own use case (Option A) or with the example automation provided in the lab (Option B).

Recently, a new Ansible collection that helps configuring FDO has been released but in this lab you will perform the steps manually to better understand the details.

FDO services

FDO is a specification that has been implemented by multiple vendors. In this tutorial, we are going to use Red Hat development which is published upstream in this GitHub repository.

In this source code repository, you will find the implementation of the core FDO elements that we reviewed in the second article of the series along with the protocols that are used to exchange information between them.

As explained in the introduction to FDO, you will need at least three different servers: Manufacturing, Rendezvous and Owner server, but as mentioned in the Lab prerequisites, for lab proposes you can choose between deploying those servers in a single system, or split them into dedicated servers, depending on your system resources. If you have enough CPU and RAM I suggest trying to split the services. Remember that multiple people could be involved in FDO server preparation. Maybe there is someone that will prepare the manufacturing server, another one, who could be in charge of the platform (or a 3rd party public cloud), will configure the Rendezvous Server, and someone else who will configure the boot automation steps on the owner server, so following this architecture you will be closer to what you could find in production.

Once you deployed your FDO services, you will also need to configure them to provide the onboarding automation. You could use your own automation or you can just deploy the provided example.

Choose your option ( Option 1 or Option 2) and go ahead with the lab steps!

Option 1: All-in-one FDO server installation

In order to minimize the number of servers used, you can install the FDO services in the same RHEL 8/9 server where you will install the Image builder which is needed to create the RHEL for Edge images.

As part of the FDO development in Fedora/RHEL, a Systemd (fdo-aio) service that manages all the FDO servers has been created for lab proposes so it’s easy to deploy and manage the all-in-one option for the FDO services.

Preparing the FDO services

FDO is distributed as RPM packages, you can double check the names running this command in your RHEL VM:

input
output

dnf search fdo

===================================================================================== Name & Summary Matched: fdo ====================================================================
fdo-admin-cli.x86_64 : FDO admin tools implementation
fdo-client.x86_64 : FDO Client implementation
fdo-manufacturing-server.x86_64 : FDO Manufacturing Server
fdo-owner-cli.x86_64 : FDO Owner tools implementation
fdo-owner-onboarding-server.x86_64 : FDO Owner Onboarding Server
fdo-rendezvous-server.x86_64 : FDO Rendezvous Server implementation

In order to install FDO services and the associated CLI, you can run the following command (this will install not only the manufacturing server, but also the fdo-aio service that you will be using in this section)

sudo dnf install -y fdo-admin-cli fdo-manufacturing-server

Once you have installed the packages, you can enable and run the fdo-aio Systemd service.

sudo systemctl enable --now fdo-aio

Now you are using the default keys and configuration (that we will modify later in the next section) but your FDO services should be already running in your VM:

NOTE: In the example below, you will need to scroll to the right in order see the whole output of the command.

input
output

sudo ss -ltnp | grep -E '^State|:808[0-3]'

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8080      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8081      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8082      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8083      0.0.0.0:*

As you can see, you have services running in ports 8080-8081, so if you are running a firewall you should open those port too:

sudo firewall-cmd --add-port=8080-8083/tcp --permanent
sudo firewall-cmd --reload

The fdo-aio service create a directory (/etc/fdo/aio) and a file (/etc/fdo/aio/aio_configuration) where all the manufacturing, rendezvous and owner server parameters are specified

Below you can find an example of this configuration file generated by fdo-aio, probably similar to the one that you have in your server but with different IP addresses and Tokens.

---
cert_organization: FDO AIO
cert_country: US
listen_ip_address: 0.0.0.0
listen_port_manufacturing_server: 8080
listen_port_owner_onboarding_server: 8081
listen_port_rendezvous_server: 8082
listen_port_serviceinfo_api_server: 8083
separate_manufacturing_and_owner_voucher_store: false
manufacturing_enable_plain_di: false
manufacturing_disable_key_storage_filesystem: false
manufacturing_disable_key_storage_tpm: false
manufacturing_use_secp256r1: false
contact_hostname: ~
contact_addresses:
  - IpAddr: 192.168.122.187
  - IpAddr: "fe80::5054:ff:fe26:13c3"
serviceinfo_api_auth_token: dnEXugA+KXFpIDs7f0XFhn/hQ5FBcr+9d/MsMDfH7TM=
serviceinfo_api_admin_token: XWNzbEwQ6EWF+PWZrqa7d68mQFHG1NtGX9yklCNtMa8=

Under the directory /etc/fdo/aio you will also find the configuration files generated for the FDO servers along with the default certificates and keys.

You can now proceed with the FDO Service API configuration.

Option 2: Dedicated FDO servers

In this option, you will have the Image Builder server and 3 additional FDO VMs (Manufacturing, Rendezvous and Owner). If you find that architecture requires too many resources but you still want to test the FDO split into different servers, you could install one of those (maybe the manufacturing server) in the same VM as the Image Builder in order to save some CPU and Memory.

Manufacturing server

Start by installing the required RPMs:

sudo dnf install -y fdo-admin-cli fdo-manufacturing-server

If you remember, during the manufacturing phase you have to “inject” certain certificates and keys into your device. When using the All-in-One FDO server model those are generated automatically, but if you split the services you need to create them manually.

Create a directory where to place the certs and keys:

sudo mkdir /etc/fdo/keys

You can use the fdo-admin-tool that you have installed to create those secrets. There are four groups: “manufacturer”, “owner”, “device-ca”, and “diun” (Device Initialize over Untrusted Networks certs and keys for communication):

for i in manufacturer owner device-ca diun
do
  sudo fdo-admin-tool generate-key-and-cert --destination-dir /etc/fdo/keys $i
done

Check that the certificates and keys have been created in the correct directory:

input
output

ls /etc/fdo/keys/

device_ca_cert.pem  device_ca_key.der  diun_cert.pem  diun_key.der  manufacturer_cert.pem  manufacturer_key.der  owner_cert.pem  owner_key.der

The manufacturer service also stores other components, such as the owner vouchers, the manufacturer keys, and information about the manufacturing sessions. Create a dedicated directory for each:

sudo mkdir -p /etc/fdo/stores/manufacturer_keys
sudo mkdir -p /etc/fdo/stores/manufacturing_sessions
sudo mkdir -p /etc/fdo/stores/owner_vouchers

It’s time to configure the Manufacturing server. You can find an example configuration in /usr/share/doc/fdo/manufacturing-server.yml. Create your own configuration in the /etc/fdo/manufacturing-server.yml file using that template.

Here you can find another configuration example, if you change the Rendezvous IP address (example IP 192.168.122.99 under rendezvous_info) to your actual Rendezvous server IP it would be everything that you need to do if you use this file and follow the lab steps:

---
session_store_driver:
  Directory:
    path: /etc/fdo/stores/manufacturing_sessions/
ownership_voucher_store_driver:
  Directory:
    path: /etc/fdo/stores/owner_vouchers
public_key_store_driver:
  Directory:
    path: /etc/fdo/stores/manufacturer_keys
bind: "0.0.0.0:8080"
protocols:
  plain_di: false
  diun:
    mfg_string_type: SerialNumber
    key_type: SECP384R1
    allowed_key_storage_types:
      - Tpm
      - FileSystem
    key_path: /etc/fdo/keys/diun_key.der
    cert_path: /etc/fdo/keys/diun_cert.pem
rendezvous_info:
  - deviceport: 8082
    ip_address: 192.168.122.99
    ownerport: 8082
    protocol: http
manufacturing:
  manufacturer_cert_path: /etc/fdo/keys/manufacturer_cert.pem
  device_cert_ca_private_key: /etc/fdo/keys/device_ca_key.der
  device_cert_ca_chain: /etc/fdo/keys/device_ca_cert.pem
  owner_cert_path: /etc/fdo/keys/owner_cert.pem
  manufacturer_private_key: /etc/fdo/keys/manufacturer_key.der

This configuration contains the paths to the directories, certificates, and keys you created, along with the Rendezvous server IP address and port (the default is 8082). I configured one Rendezvous server, but you can include more.

Once /etc/fdo/manufacturing-server.yml is prepared, you can start the Manufacturing server. First, check that you have the systemd unit file in the server:

input
output

sudo systemctl list-unit-files | grep fdo | grep manufac

fdo-manufacturing-server.service disabled disabled

Enable and start it:

sudo systemctl enable --now fdo-manufacturing-server.service

And check that the service is listening on port 8080 (default)

NOTE: In the example below, you will need to scroll to the right in order see the whole output of the command.

input
output

sudo ss -ltnp | grep -E '^State|:808[0-3]'

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8080      0.0.0.0:*

Remember to open the required ports in your firewall (if you are using any):

sudo firewall-cmd --add-port=8080/tcp --permanent
sudo systemctl restart firewalld

Let’s move to the next server, the Rendezvous server.

Rendezvous server

Connect to the RHEL VM where you want to install the Rendezvous server and, as you did with the Manufacturing server, install the required RPM packages:

sudo dnf install -y fdo-rendezvous-server

Create a directory for the required certificates:

sudo mkdir -p /etc/fdo/keys

The Rendezvous server needs the manufacturer_cert.pem certificate you created in the Manufacturing server, so copy it from the Manufacturing server into the /etc/fdo/keys directory in this Rendezvous server.

sudo scp <user>@<manufacturing IP>:/etc/fdo/keys/manufacturer_cert.pem /etc/fdo/keys

As you did with the Manufacturing server, create the directories needed by the Rendezvous server, including the registered directory (where the registered device owner vouchers will be hosted) and the sessions directory:

sudo mkdir -p /etc/fdo/stores/rendezvous_registered
sudo mkdir -p /etc/fdo/stores/rendezvous_sessions

Next, create the configuration file in /etc/fdo/rendezvous-server.yml. You can find an example in /usr/share/doc/fdo/rendezvous-server.yml. If you followed the steps shown above, the path to the manufacturer_cert.pem certificate should be in the /etc/fdo/keys directory, as shown in below.

---
storage_driver:
  Directory:
    path: /etc/fdo/stores/rendezvous_registered
session_store_driver:
  Directory:
    path: /etc/fdo/stores/rendezvous_sessions
trusted_manufacturer_keys_path: /etc/fdo/keys/manufacturer_cert.pem
max_wait_seconds: ~
bind: "0.0.0.0:8082"

Check the status of the Rendezvous server service:

input
output

sudo systemctl list-unit-files | grep fdo | grep rende

fdo-rendezvous-server.service disabled disabled

Since it’s probably stopped and disabled, enable and start it:

sudo systemctl enable --now fdo-rendezvous-server.service

Check that the server is listening on the configured port (default 8082):

NOTE: In the example below, you will need to scroll to the right in order see the whole output of the command.

input
output

sudo ss -ltn

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8082      0.0.0.0:*

And remember to open the port if you have a firewall configured on this server:

sudo firewall-cmd --add-port=8082/tcp --permanent
sudo systemctl restart firewalld

Move to the third and last FDO server: the Owner server.

Owner server

Connect to the dedicated RHEL VM and install the required RPMs in this server:

sudo dnf install -y fdo-owner-cli fdo-owner-onboarding-server

Create the certificate and keys directory:

sudo mkdir -p /etc/fdo/keys/

Copy the device_ca_cert.pem, owner_key.der, and owner_cert.pem certificates from the Manufacturing server into that new directory.

for i in device_ca_cert.pem owner_key.der owner_cert.pem
do
  sudo scp <user>@<manufacturing IP>:/etc/fdo/keys/$i /etc/fdo/keys
done

Create the additional directories needed by the owner service:

sudo mkdir -p /etc/fdo/stores/owner_vouchers
sudo mkdir -p /etc/fdo/stores/owner_onboarding_sessions

Prepare a configuration file in /etc/fdo/owner-onboarding-server.yml based on the example found in /usr/share/doc/fdo/owner-onboarding-server.yml. If you are following the lab steps, changing the Owner IP address would be enough:

---
ownership_voucher_store_driver:
  Directory:
    path: /etc/fdo/stores/owner_vouchers
session_store_driver:
  Directory:
    path: /etc/fdo/stores/owner_onboarding_sessions
trusted_device_keys_path: /etc/fdo/keys/device_ca_cert.pem
owner_private_key_path: /etc/fdo/keys/owner_key.der
owner_public_key_path: /etc/fdo/keys/owner_cert.pem
bind: "0.0.0.0:8081"
service_info_api_url: "http://localhost:8083/device_info"
service_info_api_authentication:
  BearerToken:
    token: Kpt5P/5flBkaiNSvDYS3cEdBQXJn2Zv9n1D50431/lo=
owner_addresses:
  - transport: http
    addresses:
      - ip_address: 192.168.122.149
    port: 8081
report_to_rendezvous_endpoint_enabled: true

In this file, we include the path to the certificates that we already copied, along with information about where to publish the owner server service, but you will also find references to “Info API Service”, such as the URL or the authentication token.

This service will be configured in the Owner sever, but since that’s a step that is needed also when you install all FDO services on the same node, it will be explained more in detail in the next section.

Also, as you can see, we have configured the Serviceinfo API authentication by providing a Bearer Token. This Token will be needed in the Serviceinfo API configuration below.

Before moving into the FDO Serviceinfo API configuration, check the status of the Owner server and the serviceinfo API service:

input
output

sudo systemctl list-unit-files | grep fdo

fdo-owner-onboarding-server.service        disabled        disabled
fdo-serviceinfo-api-server.service         disabled        disabled

Enable them if necessary:

sudo systemctl enable fdo-owner-onboarding-server.service
sudo systemctl enable fdo-serviceinfo-api-server.service

And start the Owner server (you will start the Serviceinfo API once you configured it in the next section)

sudo systemctl start fdo-owner-onboarding-server.service

Check that the Owner server is listening in the configured port (TCP/8081 is the default port for the Owner server):

NOTE: In the example below, you will need to scroll to the right in order see the whole output of the command.

input
output

sudo ss -ltnp | grep -E '^State|:808[0-3]'

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8081      0.0.0.0:*                                                    [::]:*

And remember to open the ports if you have a firewall configured in that server (both the TCP/8081 for the Owner server and the TCP/8083 for the Serviceinfo API):

sudo firewall-cmd --add-port=8081/tcp --permanent
sudo firewall-cmd --add-port=8083/tcp --permanent
sudo systemctl restart firewalld

Now it’s time for the Serviceinfo API configuration.

FDO Service API configuration

What is this Info API Service?

In the FDO RHEL implementation, you find this “Service Info API” which we will be using to introduce the “automation” needed as part of the onboarding, by including the ssh key, files to be copied/created, commands to be executed, disk to be encrypted, etc.

The service is configured using a YAML file located under in /etc/fdo/aio/configs/serviceinfo_api_server.yml if you used the all-in-one approach or /etc/fdo/serviceinfo-api-server.yml if you splitted the FDO services.

There is an example of this located in /usr/share/doc/fdo/serviceinfo-api-server.yml that can be used as a template to create your own configuration file. You can also review the default configuration (in this case is for the all-in-one setup, you can know it by taking a look at the stores path):

---
service_info:
  initial_user: ~
  files: ~
  commands: ~
  diskencryption_clevis: ~
  additional_serviceinfo: ~
bind: "0.0.0.0:8083"
service_info_auth_token: dnEXugA+KXFpIDs7f0XFhn/hQ5FBcr+9d/MsMDfH7TM=
admin_auth_token: XWNzbEwQ6EWF+PWZrqa7d68mQFHG1NtGX9yklCNtMa8=
device_specific_store_driver:
  Directory:
    path: /etc/fdo/aio/stores/serviceinfo_api_devices

It’s time to configure your own automation use case, so prepare your files and scripts before moving on! … or jump into the section where it is explained how to use the provided onboarding automation example.

Option A: Creating your own use case

In the serviceinfo_api_server.yml file you find the following sections that you can use to build your own onboarding experience.

initial_user

We start with the initial user. The RHEL image only has configured the root user, and it has no password by default so you need to include an additional user that you can use to access the device by using a public SSH key.

In our specific case, where we are using a combination of FDO and OSTree RHEL, there is something more that you should take into account. As you will see in the following modules, when you create an OSTree RHEL image, you use a blueprint file where you can also include a "initial user" so, what’s the one that should be used?

The answer is the one that you create with the RHEL for Edge blueprint, so if you configure a user in your serviceinfo_api_server.yml (I do) be sure that you use the same username and SSH key.

Here you can find a configuration example:

  initial_user:
    username: admin
    sshkeys:
    - "ssh-rsa AAAA...."

files

The next section in the configuration is files, which can be used to transfer files to the devices. You need to include the source and destination paths along with the permissions to be setup in the device.

There is something more to bear in mind with this configuration. At this moment you cannot copy files to a destination path that is not already created in the destination image, for example, you can not copy file example.txt to` /etc/newdir/other` since that destination directory is not present in the RHEL for Edge image.

If you need to copy files at the same time that you need to create directories, an option would be to copy a tar file with the definitive directory tree, and use the commands (explained later) to untar that file in the destination. By doing so, when you uncompress the file the same directory tree will be created in the destination.

This is a configuration example:

  - path: /etc/greenboot/check/required.d/01_check_demo_file.sh
    permissions: 644
    source_path: /etc/fdo-configs/device0/etc/greenboot/check/required.d/01_check_demo_file.sh

commands

Thanks to the commands section you can configure commands that will be run as part of the onboarding process (after copying the files of the previous section).

Just remember that at this moment you cannot use constructs such as >> or && in the commands. If you "need" to use constructs you can create a bash script file, copy and make it executable using the files section and then run that script (commands section).

In order to configure the section, you will need to include the command followed by the args each on one line. You can also include optional boolean variables:

may_fail: makes it possible to continue with the onboarding even if this command fails (default is false)
return_stdout: the command will return the standard output (default is false).
return_stderr: has the same effect as return_stdout but with the errors (default is false).

This would be an example with all the variables, including the optional:

  - command: systemctl
    args:
    - enable
    - --now
    - rpm-ostreed-automatic.timer
    may_fail: true
    return_stdout: true
    return_stderr: true

diskencryption_clevis

If configured, it will perform a disk encryption using Clevis.

You need to include at least which disk or partition you want to encrypt (disk_label), and the encryption method (pin).

You can use either a file to save the encryption keys (which is not secure) or a Trusted Platform Module (TPM) in your device. Be sure that if you select TPM your device or virtual machine will need to have a TPM module, or you will get an error like this one when booting the edge device:

 2022-11-30T11:33:32.516Z INFO  fdo_client_linuxapp::serviceinfo > Initiating disk re-encryption, disk-label: /dev/vda>
 2022-11-30T11:33:32.945Z INFO  fdo_client_linuxapp              > ServiceInfo failed, error: Error processing returne>
Caused by:
    0: Error executing clevis
    1: Error executing disk encryption for disk label /dev/vda4
    2: Error rebinding clevis
    3: Error binding clevis
    4: Failed to bind clevis: ExitStatus(unix_wait_status(256)), stdout: , stderr:
       A TPM2 device with the in-kernel resource manager is needed!
       Invalid input!

There is an additional boolean variable, reencrypt, that is needed to decide if Clevis has to reecrypt a disk if it has been already encrypted. As mentioned before, in this tutorial we are using OSTree RHEL, which by default encrypts the OS partition, so if you want to test this feature be sure that you set this boolean variable to true.

This is a configuration example where TPM is used to reencrypt the /dev/vda4 which is the default partition where the OS is mounted RHEL for Edge devices with a small disk.

  diskencryption_clevis:
  - disk_label: /dev/vda4
    binding:
      pin: tpm2
      config: "{}"
    reencrypt: true

NOTE: If you are using ARM you default device will be vda3 instead of vda4

Option B: Using the example use case

Download the example serviceinfo_api_server.yml file:

curl -o ~/serviceinfo_api_server.yml https://raw.githubusercontent.com/luisarizmendi/tutorial-secure-onboarding/master/documentation/modules/ROOT/examples/serviceinfo_api_server.yml

Download and extract the files required by the onboarding automation:

NOTE: If you are using ARM you default device will be vda3 instead of vda4 so you would need to change it in the downloaded serviceinfo_api_server.yml file

curl -o ~/fdo-configs.tar.gz https://raw.githubusercontent.com/luisarizmendi/tutorial-secure-onboarding/master/documentation/modules/ROOT/examples/fdo-configs.tar.gz
tar xvf ~/fdo-configs.tar.gz -C ~

Probably you don’t want to use your home directory, so copy the files into another definitive location, for example /etc:

sudo cp -r ~/fdo-configs/ /etc

If you don’t want to type that directory, create a variable that you can use in the commands proposed below in this section (do not include the last /)

PATH_FILES="/etc/fdo-configs"

You now have both the configuration and the required files, but you still need to customize the former to make it work in your environment.

Starting for including your own public SSH key that will be used to SSH into the edge devices. For the same reason that you created a variable with the file config directory path, you can create a new variable with your SSH public key, so you can use the sed commands shown below in this section. Another different option would be to type those parameters directly on the Serviceinfo API file.

SSH_PUB_KEY="ssh-rsa AAAAB3......am8= user@machine"

The onboarding automation will register your system in the Red Hat Hybrid Console so the file will need your Red Hat account credentials. In order to not include the user and password directly in plain text, the script that I created accepts the inputs as base64 (for a production environment you should write a script that accepts encrypted passwords, not just with base64).

RED_HAT_USER=$(echo "<YOUR RED HAT USER>" | base64 )
RED_HAT_PASSWORD=$(echo "<YOUR RED HAT PASSWORD>" | base64 )

The example Serviceinfo API file doesn’t have the right tokens, so update it with the ones on your system. There are two tokens, service_info_auth_token is the authorization token configured in the Owner server (you can use None if no authentication is needed) and the admin_auth_token that is the admins authorization token (this variable is optional but since it’s configured when following the All-in-One approach, here we also configure it for the distributed method for consistency.)

NOTE: Be sure that you use the commands for the FDO deployment option that you selected (all-in-one versus dedicated servers) since the directory where you find serviceinfo_api_server.yml file is different

All-in-one server
Dedicated servers

SERVICE_TOKEN=$(grep service_info_auth_token /etc/fdo/aio/configs/serviceinfo_api_server.yml | awk '{print $2}')
ADMIN_TOKEN=$(grep admin_auth_token /etc/fdo/aio/configs/serviceinfo_api_server.yml | awk '{print $2}')

SERVICE_TOKEN=$(grep token /etc/fdo/owner-onboarding-server.yml  | awk '{print $2}')
ADMIN_TOKEN=$(grep token /etc/fdo/owner-onboarding-server.yml  | awk '{print $2}')

Finally, use these variables to update the example serviceinfo-api-server.yml file that you downloaded:

sed -i "s|<SSH PUB KEY>|$(echo ${SSH_PUB_KEY})|g" ~/serviceinfo_api_server.yml
sed -i "s|<PATH FILES>|${PATH_FILES}|g" ~/serviceinfo_api_server.yml
sed -i "s|<RED HAT USER>|${RED_HAT_USER}|g" ~/serviceinfo_api_server.yml
sed -i "s|<RED HAT PASSWORD>|${RED_HAT_PASSWORD}|g" ~/serviceinfo_api_server.yml
sed -i "s|<SERVICE TOKEN>|${SERVICE_TOKEN}|g" ~/serviceinfo_api_server.yml
sed -i "s|<ADMIN TOKEN>|${ADMIN_TOKEN}|g" ~/serviceinfo_api_server.yml

and then copy this file into the final directory (choose your FDO deployment option).

All-in-one server
Dedicated servers

sudo cp -f ~/serviceinfo_api_server.yml  /etc/fdo/aio/configs/serviceinfo_api_server.yml

sudo cp -f ~/serviceinfo_api_server.yml /etc/fdo/serviceinfo-api-server.yml

Now that you have the configuration in plase, start or restart the service

NOTE: Every time you change the configuration files, remember to restart the systemd services.

All-in-one server
Dedicated servers

sudo systemctl restart fdo-aio

sudo systemctl restart fdo-serviceinfo-api-server.service

If everything is ok, you will find that the FDO servers are up and running. Check if the services are listening in their ports, if the port 8083 is not up, probably there is something wrong in your serviceinfo_api_server configuration. Most of the time the logs don’t not help, so try to remove some parts of the serviceinfo_api_server.yml file and restart the service until you find the port listening, then try to figure out the error (files are not in the path?, malformed command?, etc ).

NOTE: In the example below, you will need to scroll to the right in order see the whole output of the command.

input
output (in All-in-one)
output (Dedicated servers)

sudo ss -ltnp | grep -E '^State|:808[0-3]'

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8080      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8081      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8082      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8083      0.0.0.0:*

State  Recv-Q Send-Q                    Local Address:Port Peer Address:PortProcess
LISTEN 0      128                             0.0.0.0:8081      0.0.0.0:*
LISTEN 0      128                             0.0.0.0:8083      0.0.0.0:*

If you find a message on the Serviceinfo logs that says that there is a missing field service_info, that could mean that the path to your serviceinfo_api_server.yml file is not the right one (remember that it is different depending if you are using the All-in-One FDO server or not).

FDO Lab summary

In this lab you have:

Deployed and configured the FDO servers in one or multiple nodes.
Configured the FDO Service API which will enforce the onboarding automation in the edge device with your own use case or with the example automation provided in the lab.

Now that you have the FDO services ready, you need to use them. You could get a standard RHEL and install the fdo-client package and configure it to use the servers that you deployed, but in this tutorial we are going to use OSTree RHEL which already includes the fdo-client and all required configurations by default when you create one of these OSTree images with the Red Hat Image builder.