For os resolver, ctrld queries against all servers concurrently, and get
the first success result back. However, if all server failed, the result
channel is not closed, causing ctrld hang.
Fixing this by closing the result channel once getting back all response
from servers.
While at it, also shorten the backoff time when waiting for network up,
ctrld should serve as fast as possible after network is available.
Updates #34
- 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
When startup, ctrld waits for network up before calling s.Run to starts
its logic. However, if network is down on startup, ctrld will hang on
waiting for network up. That causes OS service manager unhappy, as ctrld
do not response to it, marking ctrld as failure service and never start
ctrld again.
To fix this, we should call s.Run as soon as possible, and use a channel
for waiting a signal that we can actual do our logic after network up.
Update #34
Avoiding reading/writing global config, causing a data race. While at
it, also guarding read/write access to cfg.Service.AllocateIP field,
since when it is read/write by multiple goroutines.
Instead of re-query DNS record for upstream when re-bootstrapping, just
query all records on startup, then selecting the next bootstrap ip
depends on the current network stack.
For better recovery and dealing with network stack changes, this commit
change the request flow to:
failure of any kind -> recreate transport/re-bootstrap -> retry once
That would make ctrld recover from all scenarios in theory.
At startup, ctrld gathers bootstrap IP information and use this
bootstrap IP for connecting to upstream. However, in case the network
stack changed, for example, dues to VPN connection, ctrld will still use
this old (maybe invalid) bootstrap IP for the current network stack.
This commit rework the discovering process, and re-initializing the
bootstrap IP if connecting to upstream failed.
This commit add support for ctrld to run on freebsd, supported platforms
are amd64/arm64/armv6/armv7,386.
Supporting freebsd also requires adding debian and openresolv resolvconf.
Updates #47
After telling service manager to start ctrld, performing self check
status by sending DNS query to ctrld listener. So if ctrld could not
start for any reason, an error message will be reported to user instead
of simply telling service started.
Updates #56
For interface managed by systemd-networkd, systemd-resolved can not
reset DNS. To fix this, attempting to check before the run loop and set
the suitable manager for the system.
Updates #55
For address already in use error when listening, we have a workaround to
spawn a new listener on different port. However, if that case does not
match, we must fatal to notice the error to user.
Currently, ctrld force NetworkManager ignore auto DNS setup from DHCP
per connection. This does not work well, because an interface can be
attached to many connections. So if `ctrld` started with a connection,
then user connect to new one, the DNS configured by ctrld will be
override.
Instead, we can force NetworkManager not to manage DNS by:
- Using dns=none
- Set systemd-resolved=false
So NetworkManager won't attempt to send DNS setup to systemd-resolved,
leaving what ctrld set as-is.
On some Ubuntu systems, we experiment with DNS is not set even though
systemd-resolved log indicates that it set them. To ensure the DNS will
be set, after setting them, double check the current DNS for interface
is actually the value was set, if not, attempting to set again.
While at it, also make sure the DNS is set when ctrld start on Linux.
