config ini - zwettemaan/TightenerDocs GitHub Wiki
config.ini
Preamble
Monolithic config.ini
Tightener is driven by a monolithic config.ini
file.
- Windows:
%APPDATA%\net.tightener\SysConfig\config.ini
- Mac:
~/Library/Application Support/net.tightener/SysConfig/config.ini
- Linux:
~/.net.tightener/net.tightener/SysConfig/config.ini
Sharing a config.ini
You can install Tightener on multiple networked computers, and use Tightener to handle the interactions between multi-computer systems, creating a Tightener 'swarm'.
It is not required, but it will often make sense to use the same config.ini
file on all nodes involved in the Tightener swarm.
If you want to have a centrally maintained config.ini
you could use some file server or something like DropBox, OneDrive, NextCloud... to distribute and auto-update the shared config.ini amongst the computers involved.
config.ini Cascading Defaults
A Tightener config.ini
is a cascade of default values.
You would set global defaults, then override some of these values for specific environments (e.g. Mac vs. Win vs Lin), then override some of these values for specific nodes (e.g. node-specific settings)...
The idea is that you set the global default to what most nodes in the swarm will need, and then override only particular settings on nodes that deviate from the most common value.
Understanding the config.ini
The Tightener config.ini
will look familiar, like any .ini
file.
However, there is more to them than meets the eye.
Comments can be added
A config.ini
can have comment lines. These are lines that start with a pound sign #
Sections can be split
Section names appear in square brackets, e.g. [placeholders]
.
Sections can be split into multiple segments - you might find the same section name more than once. Tightener will collate all these separate section segments into a single whole.
For large sections, this allows us to move important entries to the front of the file, and less important entries to the end of the file, without fear of 'breaking up' the section.
Placeholders can refer to other placeholders
The [placeholders]
section is used to define placeholders.
You can add your own placeholders as desired.
Any placeholder can refer to other placeholders, and placeholders do not need to be in any particular order. Something like
[placeholders]
MY_OWN_PLACEHOLDER=test test
A=${B}
B=Test
is valid: A
can refer to B
even though B
is defined later on.
Placeholder values do not need to be quoted
It's OK to leave off the double quotes around placeholder values if there is no room for confusion - e.g.
[placeholders]
A=B
C="D"
${A}
stands for B
and ${C}
stands for D
Leading and trailing spaces are ignored
Leading and trailing spaces in values are ignored. If you want to add such spaces, you need to quote the value.
[placeholders]
A = B
C = " B "
${A}
stands for B
and ${C}
stands for B
Section names and entry names are case-sensitive
For example, this
[config]
LOGLEVEL=2
will NOT set the log level to 2 - the correct entry name is logLevel
The global [config] section
The [config]
section sets the global defaults. These are the values used by all nodes in the Tightener swarm on this computer unless the value is overridden by a more specific setting in another section.
For example,
[config]
...
logLevel = 0
...
sets the logLevel
to 0 for all nodes in the swarm, except for those nodes that have their own logLevel
setting.
Coordinator sections
Individual coordinator nodes are identified by a reverse domain name (RDN) - e.g. net.tightener.coordinator.main
.
Coordinator-specific sections can be added. They have the prefix config.
followed by either a coordinator RDN or a wildcard expression to match a coordinator RDN.
For example, a section like
[config.net.tightener.coordinator.indesign*]
will match all kinds of InDesign coordinators - net.tightener.coordinator.indesign.16.2
, net.tightener.coordinator.indesign.17.0
, net.tightener.coordinator.indesignserver.17.0.configuration_noport
...
If a particular coordinator matches more than one section (e.g. it might match a wildcard section name as well as a fully qualified section name) then the sections are all taken into account.
The less specific section will be interpreted first, and then overridden by the more specific section.
Platform-specific entries
Individual entries within the sections can be made platform specific (.mac
, .windows
, .linux
).
For example,
[config]
A=B
A.mac=X
will make ${A}
stand for B
, except on Macintosh, where ${A}
stands for X
.
Node-specific entries
Individual entries within the sections can be made node-specific. If your environment contains an environment variable TIGHTENER_CONFIG_NODE_NAME
then that can be used to trigger node-specific entries.
For example, if the computer's environment has
TIGHTENER_CONFIG_NODE_NAME=holly
and the config contains
[config]
A=B
A.mac=X
A.holly=Y
will make ${A}
stand for B
, except on the computer whose environment TIGHTENER_CONFIG_NODE_NAME
says it is holly
, where ${A}
stands for Y
.
This is the case even if holly
is a Macintosh. Node-specific entries take precedence over platform-specific entries.