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.