enoperm
enoperm
Wouldn't just removing the default IPv4 range from the config file do the trick?
Last time checked (read: about half a year ago) derper with `--verify-clients` only cares for the machine keys returned by the peer API, so if we provide an "alternative" `tailscaled.sock`...
See https://github.com/enoperm/derpyhead, if you do not mind refactoring it a bit to suit your current usecases.
For what it's worth, I have had some time to dust off the aforementioned derper nodekey provider, it does not depend on sqlite3 anymore and can now return keys from...
Also, it is now tested and compatible with the latest derper.
I have not tried it, but I *suppose* if you have a central database, sharing it across control servers may be possible. The downside is, doing that bypasses any application...
* What consequences would nodes being shared across control servers have on ACLs and security in general? I *think* it can be done safely as long as the servers can...
Though even if the database could be shared, one also needs to ensure the ACLs and the DERP map remain consistent across control servers.
This may sound crazy, but how about removing hard dependencies on exact config files and datastores/schemas, and letting users write their own *behaviour* in some glue/scripting language? As long as...
> @enoperm Could you try the latest release `v0.10.1`, please? I fixed all the syntax bugs known so far including the ones regarding operators. The problem you're seeing here might...