Template variables
Updated 5 November 2026
Templates configure the system because they rely on variables: the host name, disk, graphics card, language, domain, user. The utilities compute the variable values themselves - from the hardware, from configuration files, and from the parameters of the command that invoked them.
Viewing variables
The full list of variables with their mode and current value:
cl-core-variables-show
To quickly read specific variables (including as a regular user), run:
/usr/libexec/calculate/cl-variable --value cl_template_data os_net_hostname
Useful filtering: --filter writable for writable variables, --filter userset for those set in calculate.env files, --filter [HTML_REMOVED] to filter by name.
The output has three columns, and they explain almost all of the behavior:
- Mode - two letters: access (
rread-only,wcan be changed) and type (sstring,bboolean on/off,llist,ttable,cstring with a choice); - Location - which calculate.env the default value is set in (
system,local,remote); - Value - the current one; it depends on which command is run, so different actions give different values for the same set of variables.
Variable name: module and type
The name is built as module.name, where the module is a utilities package (main, install, update, desktop, client, core). In templates you can usually omit the module - then the default module set by the env= parameter in the header is used:
Модуль по умолчанию в заголовке
# Calculate env=install Modes "#-os_install_x11_resolution-#"
To address another module explicitly, write it with a dot: #-install.os_install_root_dev-#.
The purpose of a variable is visible from its name prefix:
- ac_* - variables of the action being run: they indicate which set of templates is currently being merged (ac_install_merge, ac_desktop_profile, ac_update_sync, …);
- cl_* - settings of the utilities themselves;
- hr_* - hardware;
- os_* - the system;
- ur_* - the user;
- ld_* - LDAP attributes;
- sr_* - services.
Where values are stored
Two different files - do not confuse them:
calculate.env - default values of variables. Layers, in increasing order of priority:
/etc/calculate/calculate.env (system) /var/calculate/calculate.env (local) /var/calculate/remote/calculate.env (remote)
A value from a later layer overrides the earlier ones. The section of the file is the module name:
calculate.env
[install] os_install_ntp = ntp0.zenon.net
You can edit them by hand, but going through the utility is more reliable - it validates whether the value is acceptable:
Write to the default file:
cl-core-variables --set install.cl_autologin=guest
The same, but in the local layer (/var/calculate/calculate.env):
cl-core-variables --set install.cl_autologin=guest:local
Remove the value:
cl-core-variables --set install.cl_autologin
The utility rejects an invalid variable name explicitly (Error in parameter --set. Variable <name> not found), so this way is safer than editing the file by hand. The utility also validates the value: for example, --set install.cl_autologin=root or a value with invalid characters gives Error in parameter --set. without stating the reason, and the variable keeps its previous value. If the command printed nothing but the value did not change - it means the value validation failed; check it against cl-core-variables-show.
Отдельные обёртки
On some builds you may find separate cl-core-variables and cl-core-variables-show wrappers. If running them reports No module named 'calculate.console', work through cl-core --method=… - it is the very same interface.
Priority: command-line parameters > calculate.env.
ini.env - template function variables: the templates themselves create (#-ini(name,value)-#) and read them (#-ini(name)-#). This is user state: what is configured in which layer, and whether migrations are needed. It is read as a stack of several layers - /var/lib/calculate/ini.env, /etc/calculate/ini.env, /var/calculate/ini.env, /var/calculate/remote/ini.env and the repository profile files; when configuring the system, the system location is used; when configuring a profile, ~/.calculate/ini.env.
That is exactly why a condition like ini(package.enabled)==on means "off by default until the administrator turns it on": if none of the layers in the stack has the section, the condition is false and the template is not applied.
Changing values from a template
A template variable value (os_*, hr_*, cl_* from calculate.env) cannot be changed in a template - they are read-only. You can change the function variables, through ini():
Запись переменной функции
#-ini(overlay-calculate.remerge,20261103)-#
To pass a value between templates there is a stack: push() in one, pop() in the other.
Typical mistakes
- The variable is "empty" although it is set in calculate.env: the section is specified incorrectly (it must be the module name, for example
[install], not the package name). - A condition on ini(...) does not trigger: check exactly which ini.env the value is in - the layers override one another, and different actions (
core_setupvsdesktop_profile) read different files. - The variable appeared only after a package was installed: some variables belong to modules that must be available; if the env= module is not in the system, the template is simply omitted - without an error.
See also
- Who and when merges templates - what ac_* are in practice.
- The template did not take effect - how to check the value of a specific variable.