7.1. Security¶

The RAUC bundle format consists of the images and a manifest, contained in aSquashFS image.The SquashFS is followed by a public key signature over the full image.The signature is stored (together with the signer’s certificate) in the CMS(Cryptographic Message Syntax, see RFC5652) format.Before installation, the signer certificate is verified against the keyring(s)already stored on the system and the signers pulic key is then used to verifythe bundle signature.

Mea training center // lebanon. Princess nourah university // ksa. Rabieh 622 // lebanon. Hit enter to search or esc to close. No menu assigned; let your home take care of you residential explore marine set sail for smart living explore make every guest feel special explore hotels one less thing to manage explore commercial.

We selected the CMS to avoid designing and implementing our own custom securitymechanism (which often results in vulnerabilities).CMS is well proven in S/MIME and has widely available implementations, whilesupporting simple as well as complex PKI use-cases (certificate expiry,intermediate CAs, revocation, algorithm selection, hardware security modules…)without additional complexity in RAUC itself.

This enables easy application integration but raises the issue of controlling the use and implementation of critical and sensitive business logic that is run as a Web service. Application Explorer controls the use of Web services that use adapters, using a feature called policy-based security. We make a detailed proposal with hardware and software recommendations. Our experienced engineers will draw up a set of design and cable schematics to make sure all third-party systems are integrated in one system.

RAUC uses OpenSSL as a library for signing and verification of bundles.A PKI with intermediate CAs for the unit tests is generated by thetest/openssl-ca.sh shell script available from GitHub, which may alsobe useful as an example for creating your own PKI.

In the following sections, general CA configuration, some use-cases andcorresponding PKI setups are described.

7.1.1. CA Configuration¶

OpenSSL uses an openssl.cnf file to define paths to use for signing, defaultparameters for certificates and additional parameters to be stored duringsigning.Configuring a CA correctly (and securely) is a complex topic and obviouslyexceeds the scope of this documentation.As a starting point, the OpenSSL manual pages (especially ca, req, x509, cms,verify and config) and Stefan H. Holek’s pki-tutorial are useful.

7.1.1.1. Certificate Key Usage Attributes¶

By default (for backwards compatibility reasons), RAUC does not check thecertificate’s key usage attributes.When not using a stand-alone PKI for RAUC, it can be useful to enable checkingvia the check-purpose configuration option to allow only specificcertificates for bundle installation.

When using OpenSSL to create your certificates, the key usage attributes can beconfigured in the X.509 V3 extension sections in yourOpenSSL configuration file.The extension configuration section to be used by opensslca is selectedvia the -extensions argument.For example, RAUC uses a certificate created with the following extensions totest the handling of the codeSigningextended key usage attribute:

As OpenSSL does not (yet) provide a purpose check for code signing, RAUCcontains its own implementation, which can be enabled with thecheck-purpose=codesign configuration option.For the leaf (signer) certificate, the extendedKeyUsage attribute must existand contain (at least) the codeSigning value.Also, if it has the keyUsage attribute, it must contain at least digitalSignature.For all other (issuer) certificates in the chain, the extendedKeyUsageattribute is optional, but if it is present, it must contain at least thecodeSigning value.

This means that only signatures using certificates explicitly issued for codesigning are accepted for the codesign purpose.Also, you can optionally use extendedKeyUsage attributes on intermediate CAcertificates to limit which ones are allowed to issue code signingcertificates.

7.1.2. Single Key¶

You can use opensslreq-x509-newkeyrsa:4096-keyoutkey.pem-outcert.pem-days365-nodes to create a key and a self-signed certificate.While you can use RAUC with these, you can’t:

• replace expired certificates without updating the keyring
• distinguish between development versions and releases
• revoke a compromised key

7.1.3. Simple CA¶

By using the (self-signed) root CA only for signing other keys, which are usedfor bundle signing, you can:

• create one key per developer, with limited validity periods
• revoke keys and ship the CRL (Certificate Revocation List) with an update

With this setup, you can reduce the impact of a compromised developer key.

7.1.4. Separate Development and Release CAs¶

By creating a complete separate CA and bundle signing keys, you can give onlyspecific persons (or roles) the keys necessary to sign final releases.Each device only has one of the two CAs in its keyring, allowing onlyinstallation of the corresponding updates.

While using signing also during development may seem unnecessary, the additionaltesting of the whole update system (RAUC, bootloader, migration code, …) allowsfinding problems much earlier.

7.1.5. Intermediate Certificates¶

RAUC allows you to include intermediate certificates in the bundle signaturethat can be used to close the trust chain during bundle signature verification.

To do this, specify the --intermediate argument during bundle creation:

Note that you can specify the --intermediate argument multiple times toinclude multiple intermediate certificates to your bundle signature.

7.1.6. Resigning Bundles¶

RAUC allows to replace the signature of a bundle.A typical use case for this is if a bundle that was generated by an autobuilderand signed with a development certificate was tested successfully on your targetand should now become a release bundle.For this it needs to be resigned with the release key without modifyingthe content of the bundle itself.

This is what the resign command of RAUC is for:

It verifies the bundle against the given keyring, strips the old signature andattaches a new one based on the key and cert files provided.If the old signature is no longer valid, you can use the --no-verifyargument to disable verification.

7.1.6.1. Switching the Keyring – SPKI hashes¶

When switching from a development to a release signature, it is typicallyrequired to also equip the rootfs with a different keyring file.

While the development system should accept both development and releasecertificates, the release system should accept only release certificates.

One option to perform this exchange without having to build a new rootfs wouldbe to include both a keyring for the development case as well as a keyring forthe release case.

Doing this would be possible in a slot’s post-install hook, for example.Depending on whether the bundle to install was signed with a development or arelease certificate, either the production or development keyring will be copiedto the location where RAUC expects it to be.

To allow comparing hashes, RAUC generates SPKI hashes (i.e. hashes over theentire public key information of a certificate) out of each signaturecontained in the bundle’s trust chain.The SPKI hashes are invariant over changes in signature meta data (such as thevalidity dates) while allowing to securely compare the certificate ownership.

A simple call of raucinfo will list the SPKI hashes for each certificatecontained in the validated trust chain:

A post-install hook instead can access the SPKI hashes via the environmentvariable RAUC_BUNDLE_SPKI_HASHES that will be set by RAUC when invoking thehook script.This variable will contain a space-separated list of the hashes in the same orderthey are listed in raucinfo.This list can be used to define a condition in the hook for either installingone or the other keyring file on the target.

Example hook shell script code for above trust chain:

7.1.7. PKCS#11 Support¶

RAUC can use certificates and keys which are stored in a PKCS#11-supportingsmart-card, USB token (such as a YubiKey) orHardware Security Module (HSM).For all commands which need create a signature bundle, convert andresign, PKCS#11 URLs can be usedinstead of filenames for the --cert and --key arguments.

For example, a bundle can be signed with a certificate and key available aspkcs11:token=rauc;object=autobuilder-1:

Note

Most PKCS#11 implementations require a PIN for signing operations.You can either enter the PIN interactively as requested by RAUC or use theRAUC_PKCS11_PIN environment variable to specify the PIN to use.

When working with PKCS#11, some tools are useful to configure and show your tokens:

p11-kit is an abstraction layer which provides access to multiple PKCS#11 modules.

It contains p11tool, which is useful to see available tokens and objects(keys and certificates) and their URLs:

OpenSC is the standard open source framework for smart card access.

It provides pkcs11-tool, which is useful to prepare a token for usagewith RAUC.It can list, read/write objects, generate keypairs and more.

libp11 is an engine plugin for OpenSSL, which allows using keys on PKCS#11tokens with OpenSSL.

It will automatically use p11-kit (if available) to access all configuredPKCS#11 modules.

Note

If you cannot use p11-kit, you can also use the RAUC_PKCS11_MODULEenvironment variable to select the PKCS#11 module.

SoftHSM2 is software implementation of a HSM with a PKCS#11 interface.

It is used in the RAUC test suite to emulate a real HSM and can also be usedto try the PKCS#11 functionality in RAUC without any hardware.The prepare_softhsm2 shell function in test/rauc.t can be used as anexample on how to initialize SoftHSM2 token.

7.1.8. Protection Against Concurrent Bundle Modification¶

As the plainbundle format consists of a squashfsimage with an appended CMS signature, RAUC must check the signature beforeaccessing the squashfs.If an unprivileged process can manipulate the squashfs part of the bundle afterthe signature has been checked, it could use this to elevate its privileges.

The verity format is not affected by this problem, as the kernel checks thesquashfs data as it is read.

To mitigate this problem when using the plain format, RAUC will check thebundle file for possible issues before accessing the squashfs:

• ownership or permissions that would allow other users to open it for writing
• storage on unsafe filesystems such as FUSE or NFS, where the data is suppliedby an untrusted source (the rootfs is explicitly trusted, though)
• storage on a filesystem mounted from a block device with a non-root owner
• existing open file descriptors (via F_SETLEASE)

If the check fails, RAUC will attempt to take ownership of the bundle file andremoves write permissions.This protects against processes trying to open writable file descriptors fromthis point on.Then, the checks above a repeated before setting up the loopback device andmounting the squashfs.If this second check fails, RAUC will abort the installation.

If RAUC had to take ownership of the bundle, this change is not reverted afterthe installation is completed.Note that, if the original user has write access to the containing directory,they can still delete the file.

7.2. Data Storage and Migration¶

Most systems require a location for storing configuration data such aspasswords, ssh keys or application data.When performing an update, you have to ensure that the updated system takesover or can access the data of the old system.

7.2.1. Storing Data in The Root File System¶

In case of a writable root file system, it often contains additional data,for example cryptographic material specific to the machine, or configurationfiles modified by the user.When performing the update, you have to ensure that the files you need topreserve are copied to the target slot after having writtenthe system data to it.

RAUC provides support for executing hooks from different slot installationstages.For migrating data from your old rootfs to your updated rootfs,simply specify a slot post-install hook.Read the Hooks chapter on how to create one.

7.2.2. Using Data Partitions¶

Often, there are a couple of reasons why you don’t want to or cannot storeyour data inside the root file system:

• You want to keep your rootfs read-only to reduce probability of corrupting it.
• You have a non-writable rootfs such as SquashFS.
• You want to keep your data separated from the rootfs to ease setup, reset orrecovery.

In this case you need a separate storage location for your data on a differentpartition, volume or device.

If the update concept uses full redundant root file systems,there are also good reasons for using a redundant data storage, too.Read below about the possible impact on data migration.

To let your system access the separate storage location, it has to be mountedinto your rootfs.Note that if you intend to store configurable system information on your datapartition, you have to map the default Linux paths (such as /etc/passwd) toyour data storage. You can do this by using:

It depends on the amount and type of data you want to handle which option youshould choose.

7.2.3. Application Data Migration¶

7 Advanced Integration & Application Ap Calculus College Board

Both a single and a redundant data storage have their advantages anddisadvantages.Note when storing data inside your rootfs you will have a redundant setup bydesign and cannot choose.

The decision about how to set up a configuration storage and how to handle itdepends on several aspects:

• May configuration formats change over different application versions?
• Can a new application read (and convert) old data?
• Does your infrastructure allow working on possibly obsolete data?
• Enough storage to store data redundantly?
• …

The basic advantages and disadvantages a single or a redundant setup implicateare listed below:

7.2.3.1. Managing a /dev/data Symbolic Link¶

For redundant data partitions the active rootfs slot has to mount the correctdata partition dynamically.For example with ubifs, a udev ruleset can be used for this:

This example first determines if ubiX_Y is a data slot with an active parentrootfs slot by calling the script below.Then, the current ubiX_Y partition is bound to /dev/data if the secriptretured 1 as its output.

/usr/bin/is-parent-active is a simple bash script:

With this you can always mount /dev/data and get the correct data slot.

7.3. RAUC casync Support¶

Warning

casync support is still experimental and lacks some unit tests.

When evaluating, make sure to compile a recent casync version from thegit for testing.

Using the Content-Addressable Data Synchronization tool casync for updatingembedded / IoT devices provides a couple of benefits.By splitting and chunking the update artifacts into reusable pieces, casyncallows to

• stream remote bundles to the target without occupying storage / NAND
• minimize transferred data for an update by downloading only the delta to therunning system
• reduce data storage on server side by eliminating redundancy
• good handling for CDNs due to similar chunk sizes

For a full description of the way casync works and what you can do with it,refer to theblog postby its author Lennart Poettering or visit theGitHub site.

RAUC supports using casync index files instead of complete images in its bundles.This way the real size of the bundle comes down to the size of the index filesrequired for referring to the individual chunks.The real image data contained in the individual chunks can be stored in onesingle repository, for a whole systems with multiple images as well as formultiple systems in different versions, etc.This makes the approach quite flexible.

7.3.1. Creating casync Bundles¶

Creating RAUC bundles with casync index files is a bit different from creating‘conventional’ bundles.While the bundle format remains the same and you could also mix conventionaland casync-based bundles, creating these bundles is not straight forward whenusing common embedded build systems such as Yocto, PTXdist or buildroot.

Because of this, we decided use a two-step process for creating casync RAUCbundles:

1. Create ‘conventional’ RAUC bundle
2. Convert to casync-based RAUC bundle

RAUC provides a command for creating casync-based bundles from ‘conventional’bundles.Simply call:

The conversion process will create two new artifacts:

1. The converted bundle casync-bundle.raucb with casnyc index files insteadof image files
2. A casync chunk store casync-bundle.castr/ for all bundle images.This is a directory with chunks grouped by subfolders of the first 4 digitsof their chunk ID.

7.3.2. Installing casync Bundles¶

The main difference between installing conventional bundles and bundles thatcontain casync index files is that RAUC requires access to the remote casyncchunk store during installation of the bundle.

Due to the built-in network support of both casync and RAUC, it is possible todirectly give a network URL as the source of the bundle:

By default, RAUC will assume the corresponding casync chunk store is located atthe same location as the bundle (with the .castr extension instead of.raucb), in this example athttps://server.example.com/deploy/bundle-20180112.castr.The default location can also be configured in the system config to point to ageneric location that is valid for all installations.

When installing a bundle, the casync implementation will automatically handlethe chunk download via an unprivileged helper binary.

7.3.2.1. Reducing Download Size – Seeding¶

Reducing the amount of data to be transferred over slow connections is one ofthe main goals of using casync for updating.Casync splits up the images or directory trees it handles into reusable chunksof similar size.Doing this both on the source as well as on the destination side allowscomparing the hashes of the resulting chunks to know which parts are different.

When we update a system, we usually do not change its entire file tree, butonly update a few libraries, the kernel, the application, etc.Thus, most of the data can be retrieved from the currently active system anddoes not need to be fetched via the network.

For each casync image that RAUC extracts to the target slot, it determines anappropriate seed.This is normally a redundant slot of the same class as the target slot but fromthe currently booted slot group.

Note

Depending on your targets processing and storage speed, updating slots withcasync can be a bit slower than conventional updates,because casync first has to process the entire seed slot to calculate theseed chunks.After this is done it will start writing the data and fetch missing chunksvia the network.

7.4. Handling Board Variants With a Single Bundle¶

If you have hardware variants that require installing different images(e.g. for the kernel or for an FPGA bitstream), but have other slotsthat are common (such as the rootfs) between all hardware variants,RAUC allows you to put multiple different variants of these images in thesame bundle.RAUC calls this feature ‘image variants’.

If you want to make use of image variants, you first of all need to say whichvariant your specific board is. You can do this in your system.conf bysetting exactly one of the keys variant-dtb, variant-file orvariant-name.

The variant-dtb is a boolean that allows (on device-tree based boards)to use the systems compatible string as the board variant.

A more generic alternative is the variant-file key.It allows to specify a file that will be read to obtain the variant name.Note that the content of the file should be a simple string without any linebreaks.A typical use case would be to generate this file (in /run) during systemstartup from a value you obtained from your bootloader.Another use case is to have a RAUC post-install hook that copies this file fromthe old system to the newly updated one.

A third variant to specify the systems variant is to give it directly in yoursystem.conf.This method is primary meant for testing, as this prevents having a genericrootfs image for all variants!

In your manifest, you can specify variants of an image (e.g. the kernel here) asfollows:

It is allowed to have both a specific variant as well as a default image in thesame bundle.If a specific variant of the image is available, it will be used on that system.On all other systems, the default image will be used instead.

If you have a specific image variant for one of your systems,it is mandatory to also have a default or specific variant for the same slotclass for any other system you intend to update.RAUC will report an error if for example a bootloader image is only present forvariant A when you try to install on variant B.This should prevent bricking your device by unintentional partial updates.

7.5. Manually Writing Images to Slots¶

In order to write an image to a slot without using update mechanics like hooks,slot status etc. use:

This uses the correct handler to write the image to the slot. It is useful fordevelopment scenarios as well as initial provisioning of embedded boards.

7.6. Updating the Bootloader¶

Updating the bootloader is a special case, as it is a single point of failure onmost systems:The selection of which redundant system images should be booted cannotitself be implemented in a redundant component (otherwise there would need tobe an even earlier selection component).

Some SoCs contain a fixed firmware or ROM code which already supports redundantbootloaders, possibly integrated with a HW watchdog or boot counter.On these platforms, it is possible to have the selection point before thebootloader, allowing it to be stored redundantly and updated as any othercomponent.

If redundant bootloaders with fallback is not possible (or too inflexible) onyour platform, you may instead be able to ensure that the bootloader update isatomic.This doesn’t support recovering from a buggy bootloader, but will prevent anon-bootable system caused by an error or power-loss during the update.

Whether atomic bootloader updates can be implemented depends on yourSoC/firmware and storage medium.

7.6.1. Update eMMC Boot Partitions¶

RAUC supports updating eMMC boot partitions (see the JEDEC standard JESD84-B51for details), one of which gets enabled atomically via configuration registersin the eMMC (ext_csd registers).

The required slot type is boot-emmc.The device to be specified is expected to be the root device.The boot partitions are derived automatically.A system.conf could look like this:

Important

A kernel bug may prevent consistent toggling of the eMMC ext_csd bootpartition register.Be sure your kernel is >= 4.16-rc7 (resp. >= 4.15.14, >= 4.14.31) or containsthis patch: https://www.spinics.net/lists/linux-mmc/msg48271.html

7.6.2. Update Boot Partition in MBR¶

Some SOCs (like Xilinx ZynqMP) contain a fixed ROM code, which boots from the firstpartition in the MBR partition table of a storage medium.In order to atomically update the bootloader of such systems, RAUC supports changingthe MBR partition table and thus switching between two partitions of the same size -one active boot partition (i.e. the partition is defined in the MBR partition table)and one inactive partition (i.e. there is no entry for it in the MBR partitiontable) which is used to update the bootloader.

A memory region, where the two partitions are stored has to be defined in theconfiguration (see below) and initially a boot partition has to exist at eitherthe start of the region or start + size / 2.

Consider the following example layout of a storage medium with a boot partition sizeof 33 Mbytes:

RAUC uses the start address and size defined in the first entry in the MBR partitiontable, to distinguish between active and inactive boot partition and updates thehidden, inactive partition.After the update the bootloader is switched by changing the first partition entryand writing the whole 512 bytes MBR atomically.

The required slot type is boot-mbr-switch.The device to be specified is expected to be the underlying block device.The boot partitions are derived by the definition of the values region-startand region-size.Both values have to be set in integer decimal bytes and can be post-fixed withK/M/G/T.

A system.conf section could look like this:

7.6.3. Update Boot Partition in GPT¶

Systems booting via UEFI have a special partition, called the EFI systempartition (ESP), which contains the bootloader to be started by the UEFIfirmware.Also, some newer ARM SoCs support loading the bootloader directly from a GPTpartition.

To allow atomic updates of these partitions, RAUC supports changing the GPT toswitch the first GPT partition between the lower and upper halves of a regionconfigured for that purpose.This works similarly to the handling of a MBR boot partition as described in theprevious section.It requires RAUC to be compiled with GPT support (./configure--enable-gpt)and adds a dependency on libfdisk.

The required slot type is boot-gpt-switch.The device to be specified is expected to be the underlying block device.The boot partitions are derived by the definition of the values region-startand region-size.Both values have to be set in integer decimal bytes and can be post-fixed withK/M/G/T.

7 Advanced Integration & Application Ap Calculus Frq

To ensure that the resulting GPT entries are well aligned, the region start mustbe a multiple of the grain value (as used by sfdisk), which is 1MB bydefault.Accordingly, the region size must be aligned to twice the grain value (toensure that the start of the upper half is aligned).

Note that RAUC expects that the partition table always points exactly to one ofthe halves.

A system.conf section could look like this:

7.6.4. Bootloader Update Ideas¶

The NXP i.MX6 supports up to four bootloader copies when booting from NANDflash.The ROM code will try each copy in turn until it finds one which is readablewithout uncorrectable ECC errors and has a correct header.By using the trait of NAND flash that interrupted writes cause ECC errors andwriting the first page (containing the header) last, the bootloader images canbe replaced one after the other, while ensuring that the system will boot even incase of a crash or power failure.

The slot type could be called “boot-imx6-nand” analogous to eMMC.

7.6.5. Considerations When Updating the Bootloader¶

Booting an old system with a new bootloader is usually not tested duringdevelopment, increasing the risk of problems appearing only in the field.If you want to address this issue do not add the bootloader to your bundle, butrather use an approach like this:

• Store a copy of the bootloader in the rootfs.
• Use RAUC only to update the rootfs. The combinations to testcan be reduced by limiting which old versions are supported by an update.
• Reboot into the new system.
• On boot, before starting the application, check that the current slotis ‘sane’. Then check if the installed bootloader is older than theversion shipped in the (new) rootfs. In that case:
  • Disable the old rootfs slot and update the bootloader.
  • Reboot
• Start the application.

This way you still have fallback support for the rootfs upgrade and needto test only:

• The sanity check functionality and the bootloader installation when startedfrom old bootloader and new rootfs
• Normal operation when started from new bootloader and new rootfs

The case of new bootloader with old rootfs can never happen, because youdisable the old one from the new before installing a new bootloader.

If you need to ensure that you can fall back to the secondary slot even afterperforming the bootloader update, you should check that the “other” slotcontains the same bootloader version as the currently running one during thesanity check.This means that you need to update both slots in turn before the bootloader isupdated.

7.7. Updating Sub-Devices¶

Besides the internal storage, some systems have external components orsub-devices which can be updated.For example:

• Firmware for micro-controllers on modular boards
• Firmware for a system management controller
• FPGA bitstreams (stored in a separate flash)
• Other Linux-based systems in the same enclosure
• Software for third-party hardware components

In many cases, these components have some custom interface to query thecurrently installed version and to upload an update.They may or may not have internal redundancy or recovery mechanisms as well.

Although it is possible to configure RAUC slots for these and let it call ascript to perform the installation, there are some disadvantages to thisapproach:

• After a fallback to an older version in an A/B scenario, the sub-devices may berunning an incompatible (newer) version.
• A modular sub-device may be replaced and still has an old firmware versioninstalled.
• The number of sub-devices may not be fixed, so each device would need adifferent slot configuration.

Instead, a more robust approach is to store the sub-device firmware in therootfs and (if needed) update them to the current versions during boot.This ensures that the sub-devices are always running the correct set of versionscorresponding to the version of the main application.

If the bootloader falls back to the previous version on the main system, thesame mechanism will downgrade the sub-devices as needed.During a downgrade, sub-devices which are running Linux with RAUC in an A/Bscenario will detect that the image to be installed already matches the one inthe other slot and avoid unnecessary installations.

7.8. Migrating to an Updated Bundle Version¶

As RAUC undergoes constant development, it might be extended and newfeatures or enhancements will make their way into RAUC.Thus, also the sections and options contained in the bundle manifest may beextended over time.

To assure a well-defined and controlled update procedure,RAUC is rather strict in parsing the manifest and will reject bundlescontaining unknown configuration options.

But, this does not prevent you from being able to use those new RAUC featureson your current system.All you have to do is to perform an intermediate update:

• Create a bundle containing a rootfs with the recent RAUC version,but not containing the new RAUC features in its manifest.
• Update your system and reboot
• Now you have a system with a recent RAUC version which is able tointerpret and appropriately handle a bundle with the latest options

7.9. Software Deployment¶

When designing your update infrastructure, you must think about how to deploythe updates to your device(s).In general, you have two major options:Deployment via storage media such as USB sticks or network-based deployment.

As RAUC uses signed bundles instead of e.g. trusted connections to enable updateauthor verification, RAUC fully supports both methods with the same techniqueand you may also use both of them in parallel.

Some influential factors on the method to used can be:

• Do you have network access on the device?
• How many devices have to be updated?
• Who will perform the update?

7.9.1. Deployment via Storage Media¶

This method is mainly used for decentralized updates of devices without networkaccess (either due to missing infrastructure or because of security concerns).

To handle deployment via storage media, you need a component that detects theplugged-in storage media and calls RAUC to trigger the actual installation.

When using systemd, you could use automount units for detecting plugged-inmedia and trigger an installation.

7.9.2. Deployment via Deployment Server¶

Deployment over a network is especially useful when having a larger set ofdevices to update or direct access to these devices is tricky.

As RAUC focuses on update handling on the target side, it does not provide adeployment server out of the box.But if you do not already have a deployment infrastructure, there a few OpenSource deployment server implementations available in the wilderness.

One of it worth being mentioned ishawkBit from the Eclipse IoT project, whichalso provides some strategies for rollout management for larger-scale devicefarms.

7.9.2.1. RAUC hawkBit updater (C)¶

The rauc-hawkbit-updater is a separate application project developed under therauc organization umbrella.It aims to provide a ready-to-use bridge between the hawkBit REST DDR API onone side and the RAUC D-Bus API on the other.

For more information visit it on GitHub:

7.9.2.2. The RAUC hawkBit client (python)¶

As a separate project, the RAUC development team provides a Python-basedexample application that acts as a hawkBit client via its REST DDI-API whilecontrolling RAUC via D-Bus.

7 Advanced Integration & Application Ap Calculus 2nd Edition

For more information visit it on GitHub:

7 Advanced Integration & Application Ap Calculus 14th Edition

It is also available via pypi: