tukit.conf — tukit configuration file
/etc/tukit.conf
This configuration file controls and defines the behaviour of tukit(8).
The tukit.conf file uses INI
style assignments, e.g. PARAMETER=value
.
A reference file (also used for reading the default values) can be found in /usr/etc/tukit.conf.
The following options are available in the
"tukit
" section:
DRACUT_SYSROOT
¶
Directory where "dracut
" will mount the
"sysroot
". The current default value is
"/sysroot
".
LOCKFILE
¶
Lock file path for tukit. By default it is
"/var/run/tukit.lock
".
OVERLAY_DIR
¶
Directory where the "/etc
" overlays are
stored. By default it is "/var/lib/overlay
".
BINDDIRS
¶Bind mount additional directories into the update environment; to add multiple directories add a separate entry with a different id between the brackets for each.
Be aware that only the root file system is managed in a transactional way, i.e. any additional mounts added here will *not* get a seperate snapshot (so their contents cannot be rolled back) and the changes will be visible to the running system immediately (breaking the transactional concept and possibly resulting in a mix between old and new files if there are also changes to the root file system until the next reboot).
By default only /opt will be bind-mounted, as this directory is often used by third-party packages, but the applications in there are usually self-contained.
Example: To mount additional directories such as
"/usr/local
" or
"/var/lib/images
" into the update
environment, add the following lines to the configuration
file:
BINDDIRS[0]="/opt" BINDDIRS[1]="/usr/local" BINDDIRS[2]="/var/lib/images"
If a directory contains submounts, these have to be
mounted separately. For example if for some reason
"/usr/local
" should contain
"/usr/local/extra
" that is located on a
different partition, both mounts will have to be listed:
BINDDIRS[0]="/opt" BINDDIRS[1]="/usr/local" BINDDIRS[2]="/usr/local/extra" BINDDIRS[3]="/var/lib/images"
Note that in some situations one may be tempted to expose
"/var/lib
" directly, but this can be
dangerous.
"/var/lib
" contains a lot of data,
including databases, docker images or sssd data. That data
is often bound to a specific version of the
software. Exposing it during an upgrade can make that an
RPM post-script will make changes in place that will touch
the live system, that will be directly visible to the
user, breaking the guarantees that transactional-update
provides.