When run on Linux,
ziti-edge-tunnel creates a config file in
/var/lib/ziti/config.json, but it’s not clear what is the audience or function for that file. The contents share the same schema as the
.Data object that is output by running
ziti-edge-tunnel tunnel_status, but the values are not identical.
Does this file represent the status of the most recently run tunneler on the device, or all tunnelers running on the device?
Is this file only written or also read by
ziti-edge-tunnel reads this file, then what directives can be issued by modifying the config file and what is the precedence in relation to command-line params?
For reference, I compared the output of these two commands:
ziti-edge-tunnel tunnel_status | tail -c +90 | head -c -2 | jq .Data
jq . /var/lib/ziti/config.json
Ehhh. It’s an exceedingly complicated answer, fraught with all sorts of hand-waving…
ziti-edge-tunnel is used by Windows and Linux. The file is probably “mostly” used by Windows. It is used for persistent settings to bootstrap certain settings like debug level, tun ip, etc. When the windows service starts, it uses this file for those settings. It also uses this file to identify what identities should be loaded which is not exactly how the linux version acts.
On linux, I can’t really tell you if it’s used at all. I wouldn’t expect it to be used all that much. It’s also suffering from a lot of growing pains. A lot of the json file is just utterly unnecessary. If you just want to know ‘why’ that file is there - I can’t write enough words.
I can tell you the entries that I change in that file for windows - and you can experiment to see if linux adheres to them (I don’t know off the top of my head). Those are:
Everything else in that file is best to just leave there and don’t touch
I verified I do have those five as top-level properties in my
/var/lib/ziti/config.json and the values match the corresponding properties in the
.Data object in the output of
ziti-edge-tunnel run-host, which is typically not running with root permission, does appear to ignore and not read the config file on Linux. I tested this by confirming that the runtime log level was INFO (the default) despite having the config file with
ziti-edge-tunnel run too seems to ignore the value of
LogLevel set in the config file.
Re: concurrent instances of
It’s not clear how
ziti-edge-tunnel tunnel_status decides to which running instance of
ziti-edge-tunnel run it should send IPC. With two instances I always get a response reflecting the status of the most recently-invoked instance. Additionally, the
/var/lib/ziti/config.json file is always clobbered to reflect that most recent instance’s status.