It was previously used by the MacOS client, but it now does
something different. ipnserver should never obey a client's
request to exit.
Signed-off-by: David Anderson <dave@natulte.net>
In particular, the Dup2 syscall is not defined in the syscall
package on arm64, but is defined in x/sys/unix.
Signed-off-by: David Anderson <dave@natulte.net>
The store is passed-in by callers of NewLocalBackend and
ipnserver.Run, but currently all callers are hardcoded to
an in-memory store. The store is unused.
Signed-Off-By: David Anderson <dave@natulte.net>
This is a prelude to making it truly optional, once state
management has moved into the backend. For now though, it's
still required. This change is just isolating the bubbling-up
of the pointerification into other layers.
Signed-Off-By: David Anderson <dave@natulte.net>
- It was only used in one currently-unused client.
- It's an imperative command, not a configuration setting.
- The LoginFlags stuff in controlclient feels like it needs
a refactor anyway.
I'll put this logic back once ipnd owns its state and Backend
commands reflect that.
Signed-Off-By: David Anderson <dave@natulte.net>
The MTU is currently set when creating the tun device,
elsewhere in the code. Maybe someday we'll want some kind
of per-platform MTU configuration here, but not in the
short-medium term.
Signed-off-by: David Anderson <dave@natulte.net>
OpenBSD tunnel names are prefixed with `tun`.
Controlling the port allows for deterministic configuration of firewall
rules (using `pf` in this case).
Signed-off-by: Martin Baillie <martin@baillie.email>
It seems changelog generation got broken by moving the code between
corp and OSS repos, because one of the commit SHAs doesn't have an
associated tag.
In the interest of fixing the build, and because we're not yet trying
to upstream the debian package, I fixed this by allowing hash-based
versions to show up in the changelog. This maybe wrong from a
debian standards perspective, but for our current point in life
it'll work until we learn to do it better.
Signed-Off-By: David Anderson <dave@natulte.net>
The linter is strictly correct, but the code is structured
this way to avoid variable shadowing problems in the following
for loop. The context doesn't leak.
Staticcheck is correctly pointing out that this code is hard to
follow. However, this chunk of code is in service of enforcing
one frontend <> one backend, and we want to remove that limitation.
So, we'll just ignore the lint warning until this entire piece of
code goes away.
Signed-off-by: David Anderson <dave@natulte.net>
