Table of Contents
- Introduction
- Azure® Overview
- Provisioning a Device
- Using the IoT Central Application
- Performing batch operations
- OTA Updates
- OTA Commands
- Telemetry Data
- Issues and Troubleshooting
This guide is intended for
-
Independent BIOS Vendors providing Firmware Update packages to ensure FW update binary packaging.
-
Independent Software Vendors (ISV) providing OS and Application update packages.
-
System Integrators administrating devices running the Intel® In-Band Manageability framework.
Creating an Azure® account and obtaining the connection tokens from Azure® is required for provisioning or enabling Over-the-Air updates. For reference and quick setup, you will also need to import INB’s IoT Central Application which will provide the same UI interface described in this document to monitor the device and perform OTA commands.
This section will walk through the setup steps:
-
Creating Azure® portal account
-
Setting up an Azure® IoT Central Application
-
Accessing Azure® portal account
-
Setting up the application for X509 based device enrollment
In order to setup an Azure® account, follow the steps below:
-
If not done already, an Azure® account can be created through the link below:
https://azure.microsoft.com/en-us/free/ -
Steps explained through Images as below.
-
Click Start Free as seen in the image below.
-
Fill out the necessary details as seen in the image below and click sign up.
-
At last Click Go to the Azure Portal as seen in the image below.
- To use the reference Intel® In-Band Manageability Framework IoT Central application, use the link mentioned within the following path.
/usr/share/cloudadapter-agent/azure_template_link.txt
-
Log in with an Azure® Account when prompted.
-
The following form will appear
-
Click Build -> Click Create app
-
Then after creating the app following form will appear
-
In New application select the drop down Free Trail in Azure Subscription
-
Fill out the form accordingly, then click Create.
-
After provisioning, the IoT Central application with premade device templates and dashboards will appear. As noted before, this can be accessed at https://apps.azureiotcentral.com/ under My Apps tab or through the Azure® portal.
-
Azure® portal can be accessed at:
https://portal.azure.com/#home -
If an Azure® IoT Central has already been set up, it can be accessed at:
https://apps.azureiotcentral.com -
Otherwise, follow next step to set up an IoT Central application
The following Dashboard screen appears once the application is created. The user can enroll for a X509 based enrollment group to enroll the intermediate or root CA signed certificate, to authenticate the device further by using the X509 authentication mechanism.
This step is necessary only if the user requires the X509 authentication on the devices, else this step can be ignored.
- To create an Enrollment Group, click Administration [A], Device Connection [B], Create enrollment group [C] as seen in the image below.
Upon the display of the form as seen in the above image.
-
Fill in the Enrollment group name.
-
Select Attestation type as Certificates (X509).
-
ClickSave.
Once the group is saved, the user needs to upload root or intermediate certificate as shown in Figure 5:
-
Click Manage Primary.
-
Select the folder button as show below. This opens a window where user chooses the certificate from the currently operated user device.
- After uploading the certificate, click Generate verification code as seen below.
After the verification code is populated in the text box adjacent to the Generate verification code button, the user needs to use this verification code to generate a verification certificate which will later be uploaded after clicking the Verify button in the form shown in Figure 6.
Once the verification is done by the portal, the following screen displays stating verification is successful. Next, click Close button to close the form.
To connect a device to the Azure® portal, a device needs to be created first on the portal with the template that the user wishes to associate the device with. The device created will have a name and an auto-generated device-id, device-scope-id, and a shared access primary key, which will be later used on the user’s device, while provisioning the device to Azure® cloud.
-
When accessing the dashboard for the IoT Central application, the following screen will appear. In Devices tab A, select Template (Intel Manageability) B and click New C.
-
A new device registration form appears as shown in Figure 9. Fill in the DeviceID and Device Name information and click Create.
-
The newly created device will appear on the Dashboard with the specified Device Name. Click the device created, the status will be shown as Registerer. Then, click Connect as seen below.
-
As INBM supports both SAS and X509 authentication types, the user must choose one of the Authentication types supported. If the user intends to select SAS based authentication, refer to Shared Access Signature (SAS) authentication. Else, if the user wants X509 based Authentication, refer to X509 Authentication.
-
By clicking the ‘Connect’ button shown in Figure 5, in the dialog that appears, note the Scope ID [A], Device ID [B], and Shared Access Key(SAS) [C], as these information will be used to provision the device as depicted:
Note: To authenticate a device using X509 mechanism, a X509 based enrollment group needs to be created with CA signed root or intermediate certificates. The verification of the private key possession needs to be done as shown in Setting up the application for X509 based device enrollment.
-
The user needs to generate a primary and secondary device certificates using the root or intermediate certificate used to enroll in Setting up the application for X509 based device enrollment.
-
Once the device certs are generated, visit the Azure® portal, select the device created earlier. Then click the Connect button. In the dialog that appears, note the Scope ID and Device ID [A] as the information will be used to provision the device. Next, select Authentication type as Individual Enrollment [B], Authentication Method as Certificates (X509) [A], and use the folder icons [D], to upload the device primary and secondary certificates.
Provisioning is a Device Management phase during which the Edge IoT Device is configured with credentials to ensure that it can establish a secure session with the Device Management backend. This usually involves assigning Device ID’s and Secure tokens/keys which the Device may use to identify and authenticate itself to the remote Device Management Portal.
-
The Intel® In-Band Manageability Framework is installed on the Edge IoT device.
-
The date and time on the edge device needs to be set correct
-
Device credentials (for example, Device ID, Scope ID, SAS token) that have been obtained from the Azure® portal.
- Launch the provisioning script using the command.
sudo provision-tc- If the device was previously provisioned, the following message appears. To override the previous cloud configuration, press Y.
A cloud configuration already exists: "Azure"
Replace configuration?
[Y/N] Y
- Press 2 and [ENTER] for Azure® to choose a cloud service.
Please choose a cloud service to use:
1) Azure IoT Central
2) Thingsboard
3) UCC
4) Custom
#? 1
- Next, enter the information for Scope ID, Device ID, and the Shared Access Key. Use the information collected in Creating a Device and Obtaining Device Credentials):
Please enter the device scope ID:
dEviCeScopeID1234
Please enter the Device ID:
Device-ID-1234
- Then, the user is required to select the authentication mechanism.
Please choose provision type.
1: SAS key authentication
2: X509 authentication
- When the user selects 1: SAS key authentication, a prompt to enter SAS key is seen, the SAS key information can be obtained by following the steps in Shared Access Signature (SAS) authentication:
Please enter the device SAS primary key (Hint: https://docs.microsoft.com/en-us/azure/iot-central/howto-generate-connection-string)
- If the user selects 2: X509 authentication, the following prompt appears to confirm that the user has the device certificates generated.
Configuring device to use X509 auth requires device certificate verification.
Are device certs and keys generated? [Y/N]
-
If the user selects ‘N’, the provisioning exists stating that the device certificates are required to proceed further.
-
If the device certificates are already generated, select ‘Y’ and the user is requested to upload the certificates.
Please enter a filename to import
Input path to Device certificate file (*)
- The user would be required to enter the path to the device key file:
Input Device Key from file? [Y/N] y
Please enter a filename to import
Input path to Device Key file (*key.pem):
/home/certs/device_key.pem
- Once the information is provided by the user and if the cloud provisioning is successful, the following message appears.
Successfully configured cloud service!
- A Yes/No user prompt appears requesting for a certificate verification on an OTA package. Choose ‘Y’ if FOTA or Config load packages need to be verified using signature, else choose ‘N’.
Signature checks on OTA packages cannot not be validated without provisioning a cert file. Do you wish to use a pre-provisioned cert file for signature checks for OTA packages? [Y/N]
-
The script will then start the INB services; when the script finishes, the device should be able to interact with its associated IoT Central Application. To verify whether the device is provisioned to the right device on the Azure® portal, check the status of the device created in section Creating a Device and Obtaining Device Credentials
-
The device will be shown as ‘Provisioned’ on the top-right corner. Refer to Using the IoT Central Application
-
To verify the connectivity,
-
Check to see if telemetry or events appear; refer Using the IoT Central Application
-
Alternatively, trigger a command like Reboot; see Using the IoT Central Application
-
-
If at any time the cloud service configuration needs to be changed or updated, run the provisioning script again.
Provisioning can be done with or without TPM security by setting
PROVISION_TPM. PROVISION_TPM can be set to:
-
auto: use TPM if present; disable if not present; do not prompt. -
disable: do not use TPM. -
enable: use TPM; return error code if TPM not detected. -
(unset): default behavior; use TPM if present, prompt if not.
To run provisioning that automatically detecting the present of the TPM security:
sudo PROVISION_TPM=auto provision-tcTo run without the TPM security:
sudo PROVISION_TPM=disable provision-tc- To view and manage devices, go to the Devices tab on the side panel Ⓐ
- Alternatively, to quickly view a device, use the Devices panel Ⓑ
If the device list is showing an error: Refer to Error viewing Devices on Azure Portal.
First, view a device using instructions from Viewing and Managing Devices.
-
If the device is successfully provisioned, the status of the device will be shown as Provisioned in the top-right corner.
-
Upon viewing a device, the Measurement tab Ⓐ is displayed, where the device’s telemetry and events can be seen
-
To see the device’s Attributes, click the Properties tab Ⓑ
-
To trigger methods from the cloud, click the Commands tab Ⓒ.
-
Refer to OTA Commands for additional instructions on how to trigger methods.
-
To see an overview of the device, including the Properties and the Event log, click the Dashboard tab Ⓓ
-
To perform a batch OTA operation, i.e. send the same OTA command to multiple IoT Devices at the same time, click the Jobs tab Ⓐ, then click New Ⓑ:
-
Type out a meaningful name Ⓐ, then select an Intel Manageability device set to use Ⓑ, the “Commands” Job type Ⓒ, and the devices to perform the batch operation Ⓓ.
-
The Commands header should now appear in the Create Job panel; click the adjacent plus-sign button, then select an operation to perform:
-
Fill out any necessary fields that appear after selecting the command; refer OTA Commands for more info.
-
Finally, click the Run button at the top of the panel to run the bulk operation.
-
To run the same batch command again, click Jobs tab on the left side panel. Then check box next to the batch command Ⓐ, then click Copy Ⓑ and follow step 5:
After the Intel® In-Band Manageability Framework running on the Edge IoT Device is provisioned, it will establish a secure session with the Azure® portal and the status of the device can is visible as ‘Provisioned’ – refer to Navigating the Device Interface.
Users shall be able to perform the updates listed below on the device that is provisioned:
- AOTA (Application Over the Air update)
- FOTA (Firmware-over-the-Air update)
- SOTA (Software/OS-over-the-Air update)
- POTA (Platform-over-the Air update)
- Config Update (configuration parameter update)
- Power Management (Remote Shutdown and Restart)
As part of a security measure, In-band Manageability requires the Server URL(location) of the OTA update repository be included in a “trusted repository list”, which is maintained internally. Hence, it is mandatory that the OTA URL be included in the “trusted repository list” prior to initiating an OTA command. This can be achieved via OTA configuration Append command to add a new Server URL the existing Trusted Repository list.
IMPORTANT NOTE: It is critical for the user to ensure that the OTA packages are hosted in secure repositories. This is outside the scope of INBM.
OTA Configuration Update: refer to Configuration Append for adding the Server URL in the trustedRepositories via ‘Trigger Config Update’.
NOTE: If the URL from which the package for an OTA update is being fetched doesn’t exist in the trustedRepositories list, INB would abort the update since the fetch URL is not in the trusted list.
Before updates can be dispatched to the endpoint, some preparation needs to be done at the repository server to facilitate the updates.
The FOTA package structure remains the same when signature is used. For a more secure FOTA update, users can provision a device with a PEM file containing the signing certificate to validate the downloaded file against a signature provided as part of the OTA command, refer How to Generate Signature to generate signature. Users may create a PEM file using the OpenSSL and Cryptography libraries.
With Signature:
- FOTA package structure with signature accepts a
tar(archive) file or just a binary file as a FW update package. If using atarfile, thetarfile should consist of the firmware update binary (e.g.,*.bin,*.cap, and so on) file as a capsule. Archiving the*.binfile with atararchive tool can be performed with the below command:
tar cvf ifwi_update.tar ifwi_update.bin- When a device is provisioned with a PEM file to check the signature, the expectation is that every FOTA method triggered with a firmware package is validated against the signature using the provisioned PEM file.
Note
When using the secure method, do ensure to send the signature generated for the *.tar file. Refer How to Generate Signature
Without Signature:
- FOTA package structure without signature only
accepts a single firmware update binary (e.g.,
*.bin,*.cap, and so on) file as a capsule.
SOTA on Ubuntu Operating System does not require any SOTA package.
SOTA on Yocto is handled by INB based on OS implementation:
-
Debian package manager: in does not require any SOTA package creation but instead requires the APT repositories set correctly and path included in the apt resources.
-
Mender.io: These involve OS update images, also known as mender artifacts, generated by the build infrastructure. More information on mender integration can be found at https://docs.mender.io .
AOTA Package structure for the below commands should follow the below format
| AOTA Command | AOTA Package Structure |
|---|---|
| AOTA docker-compose package (Same format for up/pull) |
Container Tag == Container Image Name Example: The container Image name and the tar file name should be the same Container Tag = CPUTar file = CPU.tar.gzNote: The tar file should contain a folder with the same name CPU. This folder CPU needs to have the docker-compose.yml file.Steps: 1. Make a folder 2. Copy the docker-compose.yml file into the folderTar the folder |
| AOTA Docker® Load/Import | Package needs to be tar.gz formatThe package needs to have a folder within the same name as the package. |
The Configuration load package structure remains unchanged when signature field is used. For a more secure OTA update, users can provision a device with a PEM file containing the certificate to validate the downloaded file against a signature provided as part of the OTA command, refer to How to Generate Signature. Users may create a PEM file using the OpenSSL and Cryptography libraries.
- With Signature: Configuration Load package structure with
signature accepts both
tarfile with theintel_manageability.conffile and just theintel_manageability.conffile alone. Archiving theintel_manageability.conffile with atararchive tool can be performed with below command:
When a device is provisioned with a PEM file to validate the downloaded config file or package, it is expected that every Config Load method triggered with a firmware package will be having a signature that is validated against the signature using the provisioned PEM file.
- Without Signature: Configuration Load package structure with no
signature only contains
intel_manageability.conffile
To generate certificate, private key and signatures, OpenSSL or Cryptography libraries can be used.
Once the above are generated, to validate the OTA package for FOTA/Config Load, we need to have the device provisioned with a certificate (cert.pem). While triggering OTA command from cloud fill the signature field in the OTA form before clicking ‘Execute’ to trigger OTA.
While creating a signature INB, use SHA-256 or SHA-384 based encryption mechanism.
Here is a sample Python 3 script that demonstrates how a signature is created. It takes in three parameters: the first is the path to the private key from which to make the signature; the second is the path to the file being signed; and the third (optional) is a password used to read the private key.
You must install the cryptography package via pip to run this script.
import hashlib
import sys
from binascii import hexlify
from cryptography.hazmat.backends import default_backend
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives.serialization import load_pem_private_key
file_name = package_name = password = None
num_params = len(sys.argv)
if num_params < 3:
print('Invalid number of params')
exit(1)
else:
file_name = sys.argv[1]
package_name = sys.argv[2]
if num_params == 4:
password = sys.argv[3].encode('utf-8')
with open(package_name, 'rb') as package:
checksum = hashlib.sha384(package.read()).hexdigest()
with open(file_name, 'rb') as f:
priv_key = load_pem_private_key(f.read(), password=password, backend=default_backend())
signature = priv_key.sign(checksum.encode('utf-8'), padding.PSS(mgf=padding.MGF1(hashes.SHA384()), salt_length=padding.PSS.MAX_LENGTH), hashes.SHA384())
print((hexlify(signature)).decode('utf-8', errors='strict'))To trigger OTA commands on the device provisioned with Azure*, navigate to the ‘Commands’ tab of the device on the portal as stated in Navigating the Device Interface.
| Command | Definition |
|---|---|
| Trigger AOTA | Remotely launch/update docker containers on the Edge IoT Device |
| Trigger FOTA | Update the BIOS firmware on the system |
| Trigger SOTA | User-friendly, parameter driven updates to OS software packages on the system |
| Trigger Config Update | Update the In-Band Manageability configurations |
| Reboot | Remotely reboot the Endpoint |
| Shutdown | Remotely shutdown the Endpoint |
| Manifest Update | Any OTA update type can be done via the Manifest Update, by entering XML text to update the Endpoint. Refer to the Developer Guide. |
To trigger Application-over the Air updates:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the Commands tab
-
Scroll the page to the text area named Trigger AOTA:
AOTA Field Details
| Field | Input description |
|---|---|
| App and its command | docker-compose supports: up, down, pull, list and remove.docker supports: list', load, import, pull, remove and statsApplication: update |
| Container Tag | Name tag for image/container. Note: Conatiner Tag can have both the Name and Version in this format Image:Version |
| Docker® Compose File | Field to specify the name of custom yaml file for docker-compose command. Example: custom.yml |
| Fetch | Server URL to download the AOTA container tar.gz fileIf the server requires username/password to download the file, you can provide in server username/ server password NOTE: Follow Creating AOTA Package |
| Server Username/ Server Password |
If server where we host the package to download AOTA file needs credentials, we need to specify the username and password |
| Docker® Registry Docker® Registry Username/Password |
Specify Docker® Registry if accessing any registry other than the default ‘index.docker.io’. Example for docker Registry: registry.hub.docker.comOptional fields Docker® Registry Username/Password can be used to when using private images in AOTA through docker pull and docker-compose up, pull commands. |
NOTE:: Following sections demonstrate what fields to fill for respective AOTA operations with required and optional fields.
For each of the AOTA functions, insert the correct parameters as described and click Run. The result log can be viewed by clicking on the Dashboard tab.
NOTE:
- The Container Tag name should be same as the file name in the fetch field. Example: Container Tag: CPU Downloaded fetch file:
CPU.tar.gz.- Docker-Compose yml file should have the correct docker version.
NOTE:
The Container Tag name should be same as the file name in the fetch field. Example: Container Tag: CPU Downloaded fetch file:
CPU.tar.gz
NOTE:
The Container Tag name should be same as the file name in the fetch field. Example: Container Tag: CPU Downloaded fetch file:
CPU.tar.gz
NOTE:
The Container Tag name should be same as the file name in the fetch field. Example: Container Tag: CPU Downloaded fetch file:
CPU.tar.gz
NOTE: The Device Reboot is an optional field.
For any Xlink driver update it is mandatory to reboot the device.
Input “yes” for Device Reboot as seen below.
You can only use signed packages to update Xlink Driver application
Refer to the Developer Guide.
To perform FOTA updates, IBVs must supply the SMBIOS or Device Tree info that is unique to each platform SKU and fulfill the vendor, version, release date, manufacturer and product name that matches the endpoint as shown below.
- The following information must match the data sent in the FOTA update command for the Intel® In-Band Manageability Framework to initiate a Firmware update process.
FOTA Update Info
| Information | Field | Checks |
|---|---|---|
| FW | Vendor | Exact string match |
| Version | Unused | |
| Release Date | Checks if the FOTA date is newer than current | |
| System | Manufacturer | Exact string match |
| Product Name | Exact string match |
To find the FW and System fields at the endpoint, run the commands below:
Intel x86 UEFI-based Products
For UEFI-based platforms, the firmware and system information can be found by running the following command.
sudo dmidecode -t bios -t systemIn order to trigger Firmware-Over the Air updates:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the ‘Commands’ tab
-
Scroll the page to the text area named Trigger FOTA
-
Populate the text fields within the ‘Trigger FOTA’ block with the parameters in the table below. NOTE:
If triggering a secure FOTA update with a
*.pemfile within thetar, a signature needs to be given in the respective field. The signature can be generated using OpenSSL, or Cryptography libraries along with the key.pem file.
Parameter Details
| Parameter | Description |
|---|---|
| BIOSVersion | Verify with BIOS Vendor (IBV) |
| Fetch | Repository URL |
| NOTE: Follow Creating FOTA Package | |
| Manufacturer | Endpoint Manufacturer Name |
| Path | FOTA path created in repository |
| Product | Product name set by Manufacturer |
| Release Date | Specify the release date of the BIOS file you are applying. Verify with BIOS Vendor (IBV) |
| IMPORTANT NOTE: Date format: yyyy-mm-dd | |
| Signature | Digital signature |
| ToolOptions | Any Tool options to be given for the Firmware Tool |
| Server Username/Password | If server where we host the package to download FOTA file needs credentials, we need to specify the username and password |
NOTE: Following sections demonstrate what fields to fill for respective FOTA operations with required and optional fields.
- After filling the correct parameters as described in the table, click Run to commission the FOTA update.
- The result log can be viewed by clicking on the Dashboard tab.
Refer to the Developer Guide.
SOTA commands vary based on OS type and update mechanisms supported by it. Ubuntu OS or Yocto based OS which include Debian package manager do not require any package preparation, while a Yocto based OS with Mender.io based solution does. This changes the interface slightly as explained below.
In order to trigger Software-Over the Air updates:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the ‘Commands’ tab.
-
Scroll the page to the text area named ‘Trigger SOTA’:
-
Populate the SOTA text fields on screen with the parameters below:
SOTA Parameters
| Command | Specifies the SOTA ‘update’ command. |
|---|---|
| Log to File | Specifies if the logs be written to a file or to the cloud. Values “Y” or “N” |
| SOTA log files can be located at the endpoint /var/cache/manageability/repository-tool/sota/ |
NOTE: Following sections demonstrate what fields to fill for respective FOTA operations with required and optional fields.
- Click Run to commission SOTA update.
In order to trigger Software-Over the Air updates:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the ‘Commands’ tab.
-
Scroll the page to the text area named ‘Trigger SOTA’:
Populate the SOTA text fields on screen with the parameters below:
Parameter Details
| Command | Specifies the SOTA ‘update’ command. |
|---|---|
| Fetch | URL patch to download the Mender artifact from |
| Log to File | Specifies if the logs be written to a file or to the cloud. Values “Y” or “N” |
SOTA log files can be located at the endpoint /var/cache/manageability/repository-tool/sota/ |
|
| Username | Mender artifact repository Username |
| Password | Mender artifact repository Password |
| Release Date | Release date of the new mender file used in fetch field |
NOTE: Following sections demonstrate what fields to fill for respective FOTA operations with required and optional fields.
- Click Run to commission SOTA update.
SOTA Manifest Parameters and Examples
Configuration update is used to change/retrieve/append/remove
configuration parameters value from the Configuration file located at
/etc/intel_manageability.conf. Refer to table to understand
the configuration tags, it’s values and the description.
Below are the configuration update commands and input field description
| Trigger Configs | Description of field |
|---|---|
| Set | Command used to update the configuration value using key:value pair. |
| Get | Retrieve a specific configuration value using key:value pair |
| Load | Replace an entire configuration file. |
| Append | Append values to a configuration parameter. |
| Remove | Remove a specific values from the configuration parameter. |
| Fetch | URL to fetch config file from in the case of a load |
| Path | Path of element to get, set, append or remove in key:value format |
| Signature | Digital signature |
In order to trigger Configuration updates:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the ‘Commands’ tab.
-
Scroll the page to the text area named ‘Trigger Configuration Update’:
-
Populate the Config Update pop-up window with required parameters.
Note:
If triggering a secure config update load with a
*.pemfile a signature needs to be given in the respective field. The signature can be generated using OpenSSL, or Cryptography libraries along with thekey.pemfile.
-
Click Run to trigger the Config update.
-
The result log can be viewed by clicking on the Dashboard tab.
NOTE: Following sections demonstrate what fields to fill for respective Config operations with required and optional fields.
Examples: To set one value:
minStorageMB:10
To set multiple values at once: minStorageMB:10;minMemoryMB:250
NOTE:
Path takes in key value pairs as an input with key as the configuration parameter tag and value to be set as the value. Also, to set multiple key:value pairs, use; to separate one pair from another as shown above in the example.
Examples: To get one value:
minStorageMB
To get multiple values at once: minStorageMB;minMemoryMB
NOTE:
Path takes in keys as an input with key as the configuration parameter tag whose value needs to be retrieved. Also, to retrieve multiple values at once use
;to separate one tag from another as shown above in the example.
NOTE:
The configuration file you provide in Fetch needs to be named as
intel_manageability.conffile. If you wish to send with signature, tar both the pem file and theintel_manageability.confin a tar file.
NOTE:
Append is only applicable to three configuration tags i.e
trustedRepositories,sotaSWandubuntuAptSourcePath takes in key value pair format, example:
trustedRepositories:https://abc.com/
NOTE:
Remove is only applicable to three configuration tags i.e
trustedRepositories,sotaSWandubuntuAptSource
-
Path takes in key value pair format, example:
trustedRepositories:https://abc.com/
Refer to the Developer Guide.
The Shutdown and Restart capabilities are supported via button click or through manifest.
In order to trigger Reboot/Shutdown:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the ‘Commands’ tab.
-
To reboot the device, click the Run button on the box titled Reboot**.**
-
To shut down the device, click the Run button on the box titled Shutdown.
Refer to the Developer Guide.
The Intel® In-Band Manageability provides a mechanism to handle the decommission request over the air.
NOTE:
Upon receiving a decommission command:
- The Intel® In-Band Manageability credentials (all user/device data which allows the device to identify and connect to cloud) will be deleted from the device.
- The device shutdowns. In order to trigger Decommission:
-
Select Edge Device by clicking on Dashboard tab and by clicking on the device name.
-
Now select the Commands tab.
-
Select Run in the Decommission section.
The Intel® In-Band Manageability provides a way to query attribute information
-
To query attributes, provide the desire option type in the text box. Then click the Trigger Query button.
For the details on Query options Refer to Query options
The query command capabilities are supported via manifest.
Refer to Query Manifest and Examples
The Intel® In-Band Manageability provides two types of telemetry data, static telemetry and dynamic telemetry. The telemetry data will indicate the health of each endpoint.
This contains the following information and can be viewed under the Properties tab for a selected Device.
- BIOS-release-date
- BIOS-vendor
- BIOS-version
- CPU-ID
- OS-information
- System-Manufacturer
- System-Product-Name
- Total-physical-memory
- System-Product-Name
Each endpoint publishes the following Dynamic Telemetry Data in 5-minute intervals.
- Available-memory
- Core-temp-Celsius
- Percent-disk-used
- System-cpu-percent
- Container-stats(cpu-usage)
- Network Information
The device must be connected in order to view the telemetry information on the Azure* portal. To view the telemetry data, navigate to the device item that is provisioned.
To view the device’s static telemetry, click the Properties tab of the device item.
To view the device’s static telemetry, click the Measurements tab of the device item.
While following the steps in Viewing and Managing Devices, if there is an error viewing device, do the following:
- Click Edit in the upper right-hand corner:
-
Hover the cursor over the Devices panel,
click the icon as shown below:
-
On the left-hand panel, click Device Set and select the option without “Copied” appended to it, then click Save:
-
Finally, click Done in the upper right-hand- corner:
Refer to the Developer Guide.