| OSTREE.REPO-CONFI(5) | ostree.repo-config | OSTREE.REPO-CONFI(5) |
.SH "NAME" ostree.repo-config - OSTree repository configuration
.SH "DESCRIPTION"
.PP The config file in an OSTree repository is a "keyfile" in the
XDG Desktop Entry Specification[1] format. It has several global
flags, as well as zero or more remote entries which describe how to access
remote repositories.
.PP See ostree.repo(5) for more information about OSTree
repositories.
.SH "[CORE] SECTION OPTIONS"
.PP Repository-global options. The following entries are defined:
.PP mode
One of bare, bare-user, bare-user-only, or archive-z2 (note that archive is
used everywhere else.)
.RE
.PP repo_version
Currently, this must be set to 1.
.RE
.PP auto-update-summary
Boolean value controlling whether or not to automatically update the summary
file after any ref is added, removed, or updated. Other modifications which
may render a summary file stale (like static deltas, or collection IDs) do
not currently trigger an auto-update.
.RE
.PP commit-update-summary
This option is deprecated. Use auto-update-summary instead, for which this
option is now an alias.
.RE
.PP fsync
Boolean value controlling whether or not to ensure files are on stable
storage when performing operations such as commits, pulls, and checkouts.
Defaults to true.
If you disable fsync, OSTree will no longer be robust against kernel crashes
or power loss.
You might choose to disable this for local development repositories, under
the assumption they can be recreated from source. Similarly, you could
disable for a mirror where you could re-pull.
For the system repository, you might choose to disable fsync if you have
uninterruptable power supplies and a well tested kernel.
.RE
.PP per-object-fsync
By default, OSTree will batch fsync() after writing everything; however, this
can cause latency spikes for other processes which are also invoking
fsync(). Turn on this boolean to reduce potential latency spikes, at the
cost of slowing down OSTree updates. You most likely want this on by default
for "background" OS updates.
.RE
.PP min-free-space-percent
Integer percentage value (0-99) that specifies a minimum percentage of total
space (in blocks) in the underlying filesystem to keep free. The default
value is 3, which is used when neither this option nor
min-free-space-size are set (together with a default
min-free-space-size of 1GB; the smaller of the two is enforced).
If min-free-space-size is set to a non-zero value, the smaller of the
two limits is used. Note that, min-free-space-percent is not enforced
on metadata objects. It is assumed that metadata objects are relatively
small in size compared to content objects and thus kept outside the scope of
this option.
.RE
.PP min-free-space-size
Value (in power-of-2 MB, GB or TB) that specifies a minimum space in the
underlying filesystem to keep free. Examples of acceptable values: 500MB
(524 288 000 bytes), 1GB (1 073 741 824
bytes), 1TB (1 099 511 627 776 bytes).
If this option is set to a non-zero value, and min-free-space-percent
is also set, the smaller of the two limits is used. When neither option is
set, the default is 1GB (capped at 3% of total filesystem size). Note that,
min-free-space-size is not enforced on metadata objects. It is
assumed that metadata objects are relatively small in size compared to
content objects and thus kept outside the scope of this option.
.RE
.PP add-remotes-config-dir
Boolean value controlling whether new remotes will be added in the remotes
configuration directory. Defaults to true for system ostree repositories.
When this is false, remotes will be added in the repository's config
file.
This only applies to repositories that use a remotes configuration directory
such as system ostree repositories, which use /etc/ostree/remotes.d.
Non-system repositories do not use a remotes configuration directory unless
one is specified when the repository is opened.
.RE
.PP payload-link-threshold
An integer value that specifies a minimum file size for creating a payload
link. By default it is disabled.
.RE
.PP collection-id
A reverse DNS domain name under your control, which enables peer to peer
distribution of refs in this repository. See the --collection-id section in
ostree-init(1)
.RE
.PP locking
Boolean value controlling whether or not OSTree does repository locking
internally. This uses file locks and is hence for multiple process exclusion
(e.g. Flatpak and OSTree writing to the same repository separately). This is
enabled by default since 2018.5.
.RE
.PP lock-timeout-secs
Integer value controlling the number of seconds to block while attempting to
acquire a lock (see above). A value of -1 means block indefinitely. The
default value is 300. This timeout is now regarded as a mistake; because
it's likely to cause flakes. It's recommended to set it to -1, and have
timeouts at a higher application level if desired.
.RE
.PP default-repo-finders
Semicolon separated default list of finders (sources for refs) to use when
pulling. This can be used to disable pulling from mounted filesystems, peers
on the local network, or the Internet. However note that it only applies
when a set of finders isn't explicitly specified, either by a consumer of
libostree API or on the command line. Possible values: config, lan, and
mount (or any combination thereof). If unset, this defaults to config;mount;
(since the LAN finder is costly).
.RE
.PP no-deltas-in-summary
Boolean value controlling whether OSTree should skip putting an index of
available deltas in the summary file. Defaults to false.
Since 2020.7 OSTree can use delta indexes outside the summary file, making
the summary file smaller (especially for larger repositories). However by
default we still create the index in the summary file to make older clients
work. If you know all clients will be 2020.7 later you can enable this to
save network bandwidth.
.RE
.PP sign-verify-deltas
A boolean value, defaults to false. When true, applying a signed
static delta with ostree static-delta apply-offline requires a key to
be supplied, and fails with Key is mandatory to check delta signature when
none is.
This option cannot require a delta to be signed. It is consulted only after a
delta has been found to carry a signature, so an unsigned delta is applied
whatever this is set to. It also has no effect on ostree pull, which
cannot consume signed deltas at all; see ostree-static-delta(1).
.RE
.SH "[REMOTE "NAME"] SECTION OPTIONS"
.PP Describes a remote repository location.
.PP url
Must be present; declares URL for accessing metadata and content for remote.
See also contenturl. The supported schemes are documented below.
.RE
.PP contenturl
Declares URL for accessing content (filez, static delta parts). When
specified, url is used just for metadata: summary, static delta
"superblocks".
.RE
.PP branches
A list of strings. Represents the default configured branches to fetch from
the remote when no specific branches are requested during a pull
operation.
.RE
.PP proxy
A string value, if given should be a URL for a HTTP proxy to use for access
to this repository.
.RE
.PP gpg-verify
A boolean value, defaults to true. Controls whether or not OSTree will
require commits to be signed by a known GPG key. For more information, see
the ostree(1) manual under GPG.
.RE
.PP gpg-verify-summary
A boolean value, defaults to false. Controls whether or not OSTree will check
if the summary is signed by a known GPG key. For more information, see the
ostree(1) manual under GPG.
.RE
.PP sign-verify
Controls whether OSTree will require commits to be signed by a known key
using one of the non-GPG signature engines (currently ed25519). If unset,
empty, or set to a boolean-false value (false or 0), no such verification is
performed.
A boolean-true value enables every compiled-in signature engine. Keys are
optional in this case: an engine with no verification-<engine>
option set for the remote is still enabled, and falls back to the
system-wide key storage. Any other value is read as a semicolon-delimited
list of engine names. Keys for each named engine then become mandatory
rather than optional, and a commit is accepted if any one of the named
engines finds a valid signature for it.
Public keys are supplied by the companion options
verification-<engine>-key, holding an inline key, and
verification-<engine>-file, holding a path to a file of keys,
for example verification-ed25519-file. ostree remote add
--sign-verify=ed25519=file:/path/to/key writes this option and the
matching companion together.
This setting is independent of gpg-verify, which defaults to true.
Enabling only sign-verify therefore leaves GPG verification enabled
as well, and a pull against a remote with no GPG signatures fails with GPG
verification enabled, but no signatures found until gpg-verify is
also set to false.
.RE
.PP sign-verify-summary
As sign-verify, but controls whether the summary must carry a valid
signature. If unset or empty the summary is not verified.
.RE
.PP tls-permissive
A boolean value, defaults to false. By default, server TLS certificates will
be checked against the system certificate store. If this variable is set,
any certificate will be accepted.
.RE
.PP tls-client-cert-path
Path to file for client-side certificate, to present when making requests to
this repository.
.RE
.PP tls-client-key-path
Path to file containing client-side certificate key, to present when making
requests to this repository.
.RE
.PP tls-ca-path
Path to file containing trusted anchors instead of the system CA
database.
.RE
.PP http2
A boolean value, defaults to true. By default, libostree will use HTTP2;
setting this to false will disable it. May be useful to work around broken
servers.
.RE
.PP unconfigured-state
If set, pulls from this remote will fail with the configured text. This is
intended for OS vendors which have a subscription process to access
content.
.RE
.PP custom-backend
If set, pulls from this remote via libostree will fail with an error that
mentions the value. It is recommended to make this a software identifier
token (e.g. "examplecorp-fetcher"), not freeform text
("ExampleCorp Fetcher"). This is intended to be used by higher
level software that wants to fetch ostree commits via some other mechanism,
while still reusing the core libostree infrastructure around e.g.
signatures.
.RE
.SH "[SYSROOT] SECTION OPTIONS"
.PP Options for the sysroot, which contains the OSTree repository,
deployments, and stateroots. The following entries are defined:
.PP readonly
A boolean value. If this is set to true, then the /sysroot mount point is
mounted read-only. This is configured a legacy repository configuration and
the equivalent option in ostree/prepare-root.conf should be used instead -
see ostree-prepare-root(1).
.RE
.PP bootloader
Configure the bootloader that OSTree uses when deploying the sysroot. This
may take the values bootloader=none, bootloader=auto, bootloader=grub2,
bootloader=syslinux, bootloader=uboot or bootloader=zipl. Default is
auto.
If none, then OSTree will generate only BLS (Boot Loader Specification)
fragments in sysroot/boot/loader/entries/ for the deployment.
If auto, then in addition to generating BLS fragments, OSTree will
dynamically check for the existence of grub2, uboot, and syslinux
bootloaders. If one of the bootloaders is found, then OSTree will generate a
config for the bootloader found. For example, grub2-mkconfig is run for the
grub2 case.
A specific bootloader type may also be explicitly requested by choosing
grub2, syslinux, uboot or zipl.
.RE
.PP boot-counting-tries
Integer value controlling the number of maximum boot attempts. The boot
counting data is stored in the name of the boot loader entry. A boot loader
entry file name may contain a plus (+) followed by a number. This may
optionally be followed by a minus (-) followed by a second number. The dot
(.) and file name suffix (conf or efi) must immediately follow. More details
in the The Boot Loader Specification[2]
.RE
.PP bls-append-except-default
A semicolon separated string list of key-value pairs. For example:
bls-append-except-default=key1=value1;key2=value2. These key-value pairs
will be injected into the generated BLS fragments of the non-default
deployments. In other words, the BLS fragment of the default deployment will
be unaffected by bls-append-except-default.
.RE
.PP bootprefix
A boolean value; defaults to false. If set to true, the bootloader entries
generated will include /boot as a prefix. This will likely be turned on by
default in the future.
.RE
.SH "[EX-INTEGRITY] SECTION OPTIONS"
.PP The "ex-" prefix here signifies experimental options. The
ex-integrity section contains options related to system integrity.
Information about experimental options is canonically found in upstream
tracking issues.
.SH "/ETC/OSTREE/REMOTES.D"
.PP In addition to the /ostree/repo/config file, remotes may also be
specified in /etc/ostree/remotes.d. The remote configuration file must end
in .conf; files whose name does not end in .conf will be ignored.
.SH "REPOSITORY URL/CONTENTURL"
.PP Originally, OSTree had just a url option for remotes. Since then, the
contenturl option was introduced. Both of these support file, http, and
https schemes.
.PP Additionally, both of these can be prefixed with the string mirrorlist=,
which instructs the client that the target url is a "mirrorlist"
format, which is a plain text file of newline-separated URLs. Earlier URLs
will be given precedence.
.PP Note that currently, the tls-ca-path and tls-client-cert-path options
apply to every HTTP request, even when contenturl and/or mirrorlist are in
use. This may change in the future to only apply to metadata (i.e. url, not
contenturl) fetches.
.SH "PER-REMOTE GPG KEYRINGS AND VERIFICATION"
.PP OSTree supports a per-remote GPG keyring, as well as a gpgkeypath option.
For more information see ostree(1). in the section GPG
verification.
.SH "PER-REMOTE HTTP COOKIES"
.PP Some content providers may want to control access to remote repositories
via HTTP cookies. The ostree remote add-cookie and ostree remote
delete-cookie commands will update a per-remote lookaside cookie jar,
named $remotename.cookies.txt.
.SH "SEE ALSO"
.PP ostree(1), ostree.repo(5)
NOTES
- 1.
- XDG Desktop Entry Specification
- 2.
- The Boot Loader Specification
| OSTree |