Azure Device OS Configuration (OSConfig) is a modular services stack running on a Linux IoT Edge device that facilitates remote device management over Azure as well from local management authorities.

OSConfig contains a PnP Agent, a Management Platform (Modules Manager) and several Management Modules that in the current version are all running inside a single process, osconfig.service.

For more information on OSConfig see OSConfig North Star Architecture, OSConfig Roadmap and OSConfig Management Modules.

For our code of conduct and contributing instructions see CONTRIBUTING. For our approach to security see SECURITY.

OSConfig's C/C++ code currently targets compliance with C11.

Make sure all dependencies are installed. For example, on Ubuntu:

sudo apt-get update
sudo apt-get install -y git cmake build-essential curl libcurl4-openssl-dev libssl-dev uuid-dev libgtest-dev libgmock-dev rapidjson-dev

Verify that CMake is at least version 3.2.0 and gcc is at least version 4.4.7.

cmake --version
gcc --version

Add the dependencies necessary to build TraceLogging as described at github.com/microsoft/tracelogging/.

Install and configure the Azure IoT Identity Service (AIS) package as described at azure.github.io/iot-identity-service/.

Create a folder build folder under the repo root /build

mkdir build && cd build

Build with the following commands issued from under the build subfolder:

cmake ../src -DCMAKE_BUILD_TYPE=Release|Debug -Duse_prov_client=ON -Dhsm_type_symm_key=ON -DBUILD_TESTS=ON|OFF
cmake --build . --config Release|Debug  --target install

The following OSConfig files are binplaced at build time:

Enable and start OSConfig for the first time:

sudo systemctl daemon-reload
sudo systemctl enable osconfig.service
sudo systemctl start osconfig.service

The OSConfig service is configured to be allowed to be restarted (automatically by systemd or manually by user) for a maximum number of 3 times at 5 minutes intervals. There is a total delay of 16 minutes before the OSConfig service could be restarted again by the user unless the user reboots the device.

Other daemon control operations:

sudo systemctl status osconfig.service
sudo systemctl disable osconfig.service
sudo systemctl stop osconfig.service

To replace the binary while the daemon is running: stop the daemon, rebuild, start the daemon. To replace the service unit while the daemon is running: stop the daemon, disable the daemon, rebuild, reload all daemons, start and enable the daemon.

OSConfig logs to its own logs at /var/log/osconfig*.log*:

sudo cat /var/log/osconfig_pnp_agent.log
sudo cat /var/log/osconfig_platform.log
sudo cat /var/log/osconfig_commandrunner.log
sudo cat /var/log/osconfig_networking.log
sudo cat /var/log/osconfig_firewall.log
sudo cat /var/log/osconfig_tpm.log
...

Each of these log files when it reaches maximum size (128 KB) gets rolled over to a file with the same name and a .bak extension (osconfig_agent.bak, for example).

When OSConfig exists prematurely (crashes) the Agent's log (osconfig_pnp_agent.log) at the very end may contain an indication of that. For example:

[ERROR] OSConfig crash due to segmentation fault (SIGSEGV) during MpiGet to Firewall.FirewallRules

OSConfig uses two local files as local digital twins in MIM JSON format:

/etc/osconfig/osconfig_desired.json contains desired configuration (to be applied to the device)

/etc/osconfig/osconfig_reported.json contains reported configuration (to be reported from the device)

OSConfig has a general configuration file at /etc/osconfig/osconfig.json that can be used to configure how it runs. After changing this configuration file, to make OSConfig apply the change, restart or refresh OSConfig with the command:

sudo systemctl kill -s SIGHUP osconfig.service

OSConfig periodically reports device data at a default time period of 30 seconds. This interval period can be adjusted between 1 second and 86,400 seconds (24 hours) via the OSConfig general configuration file at /etc/osconfig/osconfig.json. Edit there the integer value named "ReportingIntervalSeconds" to a value between 1 and 86400:

{
    "ReportingIntervalSeconds": 30
}

Full logging means that OSConfig will log all input and output from and to IoT Hub, AIS and system commands.

Generally it is not recommended to run OSConfig with full logging enabled.

To enable full logging for debugging purposes, edit the OSConfig general configuration file /etc/osconfig/osconfig.json and set there (or add if needed) a integer value named "FullLogging" to a non zero value:

{
    "FullLogging": 1
}

To disable full logging, set "FullLogging" to 0.

By default the reported configuration is not saved locally to /etc/osconfig/osconfig_reported.json (local reporting is disabled) and desired configuration is not picked-up from /etc/osconfig/osconfig_desired.json.

To enable local management, edit the OSConfig general configuration file /etc/osconfig/osconfig.json and set there (or add if needed) a integer value named "LocalManagement" to a non zero value:

{
    "LocalManagement": 1
}

To disable local management, set "LocalManagement" to 0.

By default the remote management has priority over local management which means desired settings from /etc/osconfig/osconfig_desired.json are applied only when changed (set new) and then only once. When priority is set for local management, the desired settings from /etc/osconfig/osconfig_desired.json overwrite any desired configuration from the remote management.

To enable local priority, edit the OSConfig general configuration file /etc/osconfig/osconfig.json and set there (or add if needed) a integer value named "LocalPriority" to a non zero value:

{
    "LocalPriority": 1
}

To configure for remote priority, set "LocalPriority" to 0.

The networking protocol that OSConfig uses to connect to the IoT Hub is configured in the OSConfig general configuration file /etc/osconfig/osconfig.json:

{
    "Protocol": 2
}

OSConfig currently supports the following protocol values:

When the configured protocol is set to value 2 (MQTT over Web Socket) OSConfig attempts to use the HTTP proxy information configured in one of the following environment variables, the first such variable that is locally present:

1. http_proxy
2. https_proxy
3. HTTP_PROXY
4. HTTPS_PROXY

OSConfig supports the HTTP proxy configuration to be in one of the following formats:

• http://server:port
• http://username:password@server:port
• http://domain\username:password@server:port

Where the prefix is either lowercase http or uppercase HTTP and the username and password can contain @ characters escaped as \@.

For example: http://username\@mail.foo:p\@ssw\@[email protected]:100 where username is [email protected], password is p@ssw@rd, the proxy server is www.foo.org and the port is 100.

The environment variable needs to be set for the root user account. For example, for a fictive proxy server, user and password, the environment variable http_proxy can be set for the root user manually via console with:

sudo -E su
export http_proxy=http://user:[email protected]:100//

The environment variable can also be set in the OSConfig service unit file by uncommenting and editing the following line in src/agents/pnp/daemon/osconfig.service:

# Uncomment and edit next line to configure OSConfig with a proxy to connect to the IoT Hub
# Environment="http_proxy=http://user:[email protected]:100//"

After editing the service unit file, stop and disable osconfig.service, rebuild OSConfig, then enable and start osconfig.service:

sudo systemctl stop osconfig.service
sudo systemctl disable osconfig.service
cd build
cmake ../src -DCMAKE_BUILD_TYPE=Release|Debug -Duse_prov_client=ON -Dhsm_type_symm_key=ON -DBUILD_TESTS=ON|OFF
cmake --build . --config Release|Debug  --target install
sudo systemctl enable osconfig.service
sudo systemctl start osconfig.service

OSConfig emits device health telemetry via TraceLogging calls for the events configured in OsConfigAgentTelemetry.conf. This telemetry can be configured via OSConfig's Settings module. The service responsible of collecting these local TraceLogging calls (azure-device-telemetryd.service) is not currently available for Ubuntu and Debian and there is no emitted telemetry in that case.

Microsoft may collect performance and usage information which may be used to provide and improve Microsoft products and services and enhance users experience. To learn more, review the privacy statement.