Release Roundup Information
https://www.youtube.com/watch?v=HyiBrjeTNLI
- RPS
- RPC
In the case of RPS in regards to certificates, we wanted to provide a way to track if the provisioning certificates being used are on the border of expiring or not. In terms of local activation, due to the potential inconvenience of passing that much information to the command line, we have added more ways to use the "-local" flag for activation.
- The first change we look at is in RPS and the domains, . It is a new field stored as "expirationDate". In the demo we show the UI and in the domain there is now a field called "Expiration Date" which will show the date of expiration and a countdown of how many days are left till that date.
- The second change in this release has to do with the "Device Info" which is passed up to RPC. Now things like firmware version, firmware build, SKU, current mode, etc. are now stored and accessible. This comes in the form of a new rpc-go command called, shown in the demo as rpc maintenance syncdeviceinfo -u wss://192.168.4.23/maintenance -n. Once the password is provided it will sync up any new changes to the few key fields we have highlighted.
- The last change is another RPC based change. It is in the form of local activation, which removes the use of going through RPS. In the demo the command looks like this: rpc activate -local -acm -config \192.168.4.23\vproShare\config.yaml. This now can activate the device in ACM. The change here is being able to locally activate by pointing to a remote share with a config file.
- The goal is to keep capturing more and more data for the "Device Info" field and store it for offline use in case the device loses connection.
- Next step for local activation is planned to come in the form of local TLS configuration.
https://www.youtube.com/watch?v=CoRHvUu2-eE
- NoSQL feature added in MPS
- Quality of Life RPC/Sample Web UI
We wanted to go with the NoSQL mongo database in order to save device details. Instead of changing the schema every time, we would just store the device information in the mongo database in order to be able to retrieve device info regardless of if it was connected or not.
- For rpc, there is a now an expansion on amtinfo. In the video the command is rpc amtinfo -userCert with that leading to a password prompt. Once the password is inputted, a list of various public key certs will be printed out. This could include TLS certs, CIRA certs, 802.1x certs, etc. Furthermore if we now provide a -password flag to the existing -cert flag it will print the hashes of system certs and the devices public key certs as well. The command looks like this: rpc amtinfo -cert -password P@ssw0rd.
- In our .env file there is now a MPS_DB_PROIVDER=mongo line at the bottom of the mps configuration. Note that users can use other database options that utilize the mongo API calls. Furthermore, in the docker-compose.yml file there is now mongo section containing the mongo image. The mps and mps-router connection string in this file have been updated from postgres to mongo. In the demo in the video, mongo is being run as a docker container. Then using a UI like mongo compass the user can see the devices collection that are in the mps database.
- In the Sample Web UI we have added in the ability to edit tags. As the demo in the video shows, if we are in the device tab in the UI, we can go to the tags column and click on the ones we want to edit. We can delete tags and add new ones. Furthermore, a bulk edit allows users to now edit tags that are shared across the devices in the bulk selection.
- Planning on adding more AMT device data such as firmware versioning, provisioning state, and more information to the database.
https://www.youtube.com/watch?v=6C0seUYS3ss
- RPC Local ACM Activation
- RPC Local Wifi Configuration
Originally we had only supported local configuration for 802.1x profiles, however with this release we fully encompass local wireless, wired, and 802.1x configurations along with the addition of our local ACM activation feature being fully implemented.
- Local ACM activation is now supported along with local CCM activation. The command entered is rpc.exe activate -local -acm -config ./config.yml. Within in the config.yml file contain the values for amtPassword, provisioningCert, and provisioningCertPwd, which can also be passed in normally as flags for the command used above. For local ACM activation it is important to trust your operating system as you are passing secrets in. More information can be found on our doc site regarding the local ACM activation feature
- We now support all wifi profile types for local configuration. The command being used in the demo is rpc.exe configure addwifisettings -password P@ssw0rd -config ./config.yaml. Once run it should show profiles that are added and which ones failed to add. Again everything can be passed through the command line with flags instead of the config.yaml file. Once again there are passwords and certificates being passed through, so ensure the operating system is trusted and these are being passed down in a secure manner. If security is a concern, RPS remains the best option. Finally ensure that if a secret file is being used, then whatever is being given in that file should match with the config.yaml file. More information can be found on our doc site regarding local wifi configuration
- Future of APIs (revamping API's to be technologically agnostic, more human readable terms to send in)
https://www.youtube.com/watch?v=02CyrED5YJs
**Note: There was an issue with the recording at some point in the video so there is some voiceover summary taking place during the video.
- RPC-Go features
- Consul
Features that have been implemented in this release include local deactivation of ACM, local CCM activation, and Move to ACM (upgrade from CCM activated device straight to Admin Control Mode). The main focus of this release was to give our customers more options when working with the toolkit.
-
The first demo shows off the new feature of being able to deactivate locally through RPC. The command used is rpc deactivate -local -password P@ssw0rd. The -local is the main change here and allows the deactivation to run faster.
-
The second part of the demo shows a local activation into Client Control Mode. The command used rpc activate -local -password P@ssw0rd. Note to actual configure CIRA the user will still need to go through RPS.
-
The third part of the demo allows shows off the ability to take an already activated Client Control Mode device and pass in an activation command such as rpc activate -u "wss://192.168.88.201/activate" -password P@ssw0rd -profile acm -n -v to upgrade the device directly from Client Control Mode to Admin Control Mode without having to deactivate to a pre-provisioning state in between. There will be a new message in the status section once the command is done running that says "Upgraded to Admin Control Mode".
-
The final demo surrounds Consul. One way to deploy it is setting CONSUL_ENABLED in the .env file to true and then go and deploy the docker containers. From there you can see the web UI on localhost:8500 and where MPS and RPS are storing their configs. Consul is currently primarily being used for centralized configuration. It allows scalability, so updating a config will be able to populate throughout the instances instead of having to go to each individual .env file.
- Consul will hopefully allow the ability for live updates for changes to configuration
- Continue to give customers more options and paths to enable ISV's and use it how they want (local CIRA configurations, local profile configurations, and more).
https://www.youtube.com/watch?v=Fnef-nnvdsQ
- 802.1x Wireless
- Enhancements for RPC-go
Currently we have implemented one off protocol EAP TLS and wired 802.1x so naturally the focus was moving to implement wireless 802.1x. Wireless 802.1x protocol uses same user interface as the wired protocol. API implementation should also be a familiar, however there are slight differences, wiredInterface should be set to false, pixie timeout isn't used, and you can provide the OFF protocol depending on which one is being used. Another change is that once the wireless 802.1x is created you can then provide that as part of your wireless configuration.
For WSMAN messages, the packages we have today it is written in TypeScript, this release covers the new Go-WSMAN messages. Plan is to use this functionality to configure AMT in a local capacity. There is more communication with AMT in this package.
Documentation ability to create a general settings message
- message := amtClass.GeneralSettings.Get()
Then create a new WSMAN client
- client := wsman.NewClient("http://localhost:16992/"wsman, username, password, true)
- response, err := client.Post(message)
Starting in the user interface, the demo begins with the going to the tab "IEEE 802.1x". From there a new profile is created and there are two options presented: Wired and Wireless. It is important to note that whatever profile is created in this tab has to be associated with a wireless config profile. When creating a wireless config, under "Authentication Method", choosing WPA IEEE 802.1x or WPA2 IEEE 802.1x gives the option to then use the "802.1x Configuration" category in order to allow association with IEEE 802.1x profile. For the sake of the demo, an ACM profile was already created and under the section "Associated Wireless Profiles" the wireless profiles that were created earlier in the demo are then added to that section. From there the profile is activated on an AMT 12 machine.
The demo then shifts to RPC-Go which shows the new Go-WSMAN Messages repository. A PowerShell command is run: go run ./cmd/main.go local -configpath .\ieee8021xconfig.yaml. Can check MeshCommander and refresh certificates to see if appropriate certificates were added.
Plans going forward is to continue to provide more flexibility to ISP's. Looking to June release we want to make the features available for customers, end of May the goal is for at least a preview feature.
https://www.youtube.com/watch?v=TO1c9JaIYOM
- Wired 802.1x for AMT devices
- Enterprise Assistant
Enterprise Assistant is a C# application that can be built and run as a standalone desktop app or a background service. Functions as a relay between RPS and other microservices.
When a call gets made from RPC to configure 802.1x, it passes through RPS which talks to the Enterprise Assistant, which can then make the certificate request, TLS request, etc.
Sample Web UI has new section "IEEE 802.1x". For each AMT profile, there can only be one 802.1x profile. As of right now, can only create one IEEE 802.1x profile.
Demo is run on a docker compose stack with all the Open AMT Cloud Toolkit Components. The Enterprise Assistant is run on a Windows Server, which is configured with the domain services and certificate authority.
Command: .\rpc.exe activate -u "wss//[ip address]/activate" -n profile acm -v
Functions the same as other device management functionality.
- Enable wireless 802.1x configurations
- Giving more control to ISV's