postRun should not restore static settings
put back validInterface check
better debug logs for os resolver init, use mutex to prevent duplicate initializations
use WMI instead of registry keys for static DNS data on Windows
use WMI instead of registry keys for static DNS data on Windows
use winipcfg DNS method
use WMI with registry fallback
go back to registry method
restore saved static configs on stop and uninstall
restore ipv6 DHCP if no saved static ipv6 addresses
do not save loopback IPs for static configs
handle watchdog interface changed for new interfaces
dont overwrite static file on start when staticdns is set to loopback
dont overwrite static file on start when staticdns is set to loopback
dont overwrite static file on start when staticdns is set to loopback
no need to resetDNS on start, uninstall already takes care of this
Config fetching/generating in cd mode is currently weird, error prone,
and easy for user to break ctrld when using custom config.
This commit reworks the flow:
- Fetching config from Control D API.
- No custom config, use the current default config.
- If custom config presents, but there's no listener, use 0.0.0.0:53.
- Try listening on current ip+port config, if ok, ctrld could be a
direct listener with current setup, moving on.
- If failed, trying 127.0.0.1:53.
- If failed, trying current ip + port 5354
- If still failed, pick a random ip:port pair, retry until listening ok.
With this flow, thing is more predictable/stable, and help removing the
Config interface for router.
When reading base64 config, either via command line or via custom config
from Control D API, we do want new config entirely instead of mixing
with old config. So new viper instance should be re-recreated before
reading in new config.
That also helps simplifying self-check process, because the config is
now always set correctly, instead of watching change made by "ctrld run"
command.
However, log file and listener config need a special handling, because
they could be changed/unset from Control D API:
- Log file can change dynamically each time ctrld runs, so init logging
process need to take care of re-initializing if log setup changed.
- For listener setup, users could leave ip and port empty, and ctrld
will pick a random loopback 127.0.0.x:53. However, on Linux systems
which use systemd-resolved, the stub listener won't forward queries
from its address 127.0.0.53 to 127.0.0.x, so ctrld will use the
default router interface address instead.
This reverts commit 00fe7f59d13774f2ea6c325bdbb8165be58a1edd.
The purpose is disable cd mode for already installed service, which is
a hard problem than we thought. So leave it out of v1.2 cycle.
- Include version/OS information when logging
- Make time field human readable in log file
- Force root privilege when running status command on darwin
Updates #34
Currently, when reset DNS, ctrld always find the net.Interface by
interface name. This may produce unexpected error because the interface
table may be cleared at the time ctrld is being stopped.
Instead, we can get the net interface only once, and use that interface
for restoring the DNS before shutting down.
While at it, also making logging message clearer.
On windows, the SYSTEM user is used to run ctrld service. This user has
different environment with the user that run the `ctrld` binary via CLI.
That causes the mismatch issue in config file path, log path, or more
generally, everything that involve with home directory.
To circumvent this pain, just always passing the config path and the
original home dir in start mode. So `ctrld run` command can setup things
correctly.
Supported actions:
- start: install and start ctrld as a system service
- stop: stop the ctrld service
- restart: restart ctrld service
- status: show status of ctrld service
- uninstall: remove ctrld from system service
This commit adds the ability to start `ctrld` without config file. All
necessary information can be provided via command line flags, either in
base64 encoded config or launch arguments.
This commit changes "verbose" flag from boolean to count flag, so we can
specify the flag multiple times to indicate different logging output:
- No "-v": no query logging except startup/listeners
- "-v" : query logging enabled
- "-vv" : debug level logging enabled