Pantavisor needs store some artifacts on disk. These are the elements on the root of the /storage space:
- boot: information written by Pantavisor so bootloader can run the proper revision after boot up.
- cache: to store metadata and other stuff that is not fixed to revisions.
- config: to store part of the configuration.
- disks: permanent and revision disks.
- logs: Pantavisor and container logs.
- objects: binary artifacts that are part of revisions.
- trails: list of revisions.
Pantavisor offers a way to define the physical storage medium. Disks are just storage volumes that have permanent or revision persistence.
There are currently 4 disks types supported:
- Non-encrypted directory
- Device Mapper crypt using without hardware acceleration (versatile)
- Device Mapper crypt using i.Mx CAAM
- Device Mapper crypt using i.Mx DCP
It does so by running a small server which offers a socket (pv-ctrl-log) where containers can direct their logs into.
There is a number of parameters that can be tweaked from the configuration, such as log.capture, log.maxsize, log.level, etc.
Trails and objects¶
Pantavisor trails, with their state JSONs are stored for each installed revision. The rest of artifacts that can be shared between revisions, are called objects and stored separately.
The Pantavisor garbage collector is in charge of cleaning up the /storage by automatically removing unused Pantavisor artifacts.
The garbage collector will not affect any of the files related to the running revision, the revision that is being updated or the latest DONE revision. These revisions that are not affected by the garbage collector can be expanded to the factory revision using the storage.gc.keep_factory configuration parameter.
Currently, it can be triggered by three different events:
- by a remote update that requires more disk space than available
- if a threshold of disk usage is surpassed
- with a command
NOTE: this type of trigger will not work with local updates. For those, you will need to use one of the following two options.
Disk usage will be checked periodically and garbage collector will be activated if that threshold is reached. By default it is disabled. This can be changed with the storage.gc.threshold parameter.
If an object is put using the objects endpoint, the threshold will be disabled temporarily, which is done to avoid removing objects that could be linked to the upcoming new revision. This parameter can be changed from the configuration.
Finally, our garbage collector can be triggered on demand issuing a command through Pantavisor control socket.
Pantavisor offers secureboot, a security mechanism to ensure integrity of the artifacts that are part of a revision. This system allows to sign one or more artifacts in you host computer and validate them in Pantavisor using a cryptographic hash algorithm. It can be configured in one of these three levels of severity:
- disabled: no signature validation will be performed.
- audit: all validations from lenient and strict will be performed, errors will be reflected in logs but nothing will fail.
- lenient: only the signed artifacts in the revision will be validated. Enabled by default.
- strict: all artifacts in the revision must be signed and will be validated.
Right now, RS256, ES256, ES384 and ES512 algorithms are supported and Pantavisor must know the public key either by storing it on disk directly or by using a certificate chain.
Validation is performed in Pantavisor in two places:
- when booting up, right after Pantavisor is initialized and before the current revision is loaded. In case of failure, the update will be reported as ERROR if possible and the device will either rollback or just reset.
- when a new remote update is received or a new local update is run. In case of failure, the update will be reported as WONTGO.
On-disk public key¶
In this option, Pantavisor will need the RSA public key to be stored on disk. To do so, it is necessary to add it during compiling time.
It will need the signature and information about how to generate it in the revision checkout.
Certificate chain of trust¶
In this case, the public key will travel in the revision checkout in a x509 certificate. The rest of the chain can be added to the checkout, but the root certificate have to be stored on disk during compiling time.
It will also need the signature and information about how to generate it in the revision checkout.