This commit enables the existing gRPC and HTTP API from remote locations
as long as the user can provide a valid API key. This allows users to
control their headscale with the CLI from a workstation. 🎉
We dont seem to need the wireguard key anymore, we generate a key on
startup based on the new library and the users fetch it from /key.
Clean up app.go and update docs
This commit adds a sentral cache to keep track of clients whom has
requested an expiry time, but were we need to keep hold of it until the
second request comes in.
This commit is trying to DRY up the initiation of the gRPC client in
each command:
It renames the function to CLI instead of GRPC as it actually set up a
CLI client, not a generic grpc client
It also moves the configuration of address, timeout (which is now
consistent) and api to use Viper, allowing users to set it via env vars
and configuration file
This commit changes the way CLI and grpc-gateway communicates with the
gRPC backend to socket, instead of localhost. Unauthenticated access now
goes on the socket, while the network interface will require API key (in
the future).
This commit sets up the API and gRPC endpoints and adds authentication
to them. Currently there is no actual authentication implemented but it
has been prepared for API keys.
In addition, there is a allow put in place for gRPC traffic over
localhost. This has two purposes:
1. grpc-gateway, which is the base of the API, connects to the gRPC
service over localhost.
2. We do not want to break current "on server" behaviour which allows
users to use the cli on the server without any fuzz
This commit moves the TLS configuration into a seperate function.
It also wires up the gRPC interface and prepares handing the API
endpoints to the grpc gateway.
This commit adds some Prometheus metrics to /metrics in headscale.
It will add the standard go metrics, some automatic gin metrics and some
initial headscale specific ones.
Some of them has been added to aid debugging #97 (loop bug)
In the future, we can use the metrics to get rid of the sleep in the
integration tests by checking that our expected number of nodes has been
registered:
```
headscale_machine_registrations_total
```
Golangs built in HTTP server does not allow different HTTP timeout for
different types of handlers, so we cannot have a write timeout as we
attempt to do long polling (my bad).
See linked article.
Also removed redundant server declaration
This commit tries to address the possible raceondition that can happen
if a client closes its connection after we have fetched it from the
syncmap before sending the message.
To try to avoid introducing new dead lock conditions, all messages sent
to updateChannel has been moved into a function, which handles the
locking (instead of calling it all over the place)
The same lock is used around the delete/close function.
This commit makes two reasonably major changes:
Set a default timeout for the go HTTP server (which gin uses), which
allows us to actually have broken long poll sessions fail so we can have
the client re-establish them.
The current 10s number is chosen randomly and we need more testing to
ensure that the feature work as intended.
The second is adding a last updated field to keep track of the last time
we had an update that needs to be propagated to all of our
clients/nodes. This will be used to keep track of our machines and if
they are up to date or need us to push an update.
