When preparing a device for shipping and subsequent updates are to be delivered via OTA, you first need to enable this feature in the sysroot: OTA is a component of a system and not a security framework.
If handled correctly (GPG and TLS are used properly, the keys are generated and handled properly and the servers in question are secure to known vulnerabilies and exploits) OTA is considered secure against realistic attacks.
This is where user and application data should be stored.
Note: OSTree does not update the contents of /var, it is the responsibility of the OS to manage and upgrade /var if required.
You can use the dhcp command to configure these variables from your DHCP server.
You probably will have to adjust the serverip variable manually.
For the APF51 and U-Boot versions 2013.04 or later you can also use files with the U-Boot command: Warning: Before setting the firmware_autoload variable, be sure that your FPGA binary file is correct.
If not, your board will hang up at U-Boot start and you will need to cancel the fpga download to take control of the board.
System administrators use this to restrict the access to the server (client authentication) and client devices use this to verify the identitiy of an update server (server authentication). It is advised to use both GPG and TLS in hostile environments.
The advantage of having read-only /usr/etc is that you always have access to system defaults.
Then OSTree takes /etc of the OTA update, which is a separate copy from your running /etc (each tree has its own writable copy of the /etc) as a base and applies your local changes on top.
This includes OTA updates for linux kernel, system libraries, user space applications, translation fixes, anything that is part of the sysroot.
The offering includes Qt/C and QML APIs to make integration with your Qt-based application a breeze. If you would like to learn more about OSTree workings refer to the OSTree Documentation.
To learn more about the security topics from the above list, consult dedicated resources.