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 (r read-only, w can be changed) and type (s string, b boolean on/off, l list, t table, c string 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_setup vs desktop_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