You can disable extensions and download them in advance and load those from file path. This is how I’m pinning extensions for a self hosted version of duckdb I setup at work.
Yeah, but no needs to pay for software SaaS anymore so no-one is going to be getting a lucky 100MRR business off pure vibecoded software as anyone can just make that in house.
You can ack based on groups, and you can out users into groups. So if you auth a node, it’s now your node and the ACL for your user / group will apply.
But yes I don’t think you can ACL based o the hostname
Part of the reason that we don't (currently) let you do this is that a hostname is a user-reported field, and can change over time; it's not a durable form of identity that you can write ACLs on. One could imagine, for example:
1. Creating an ACL rule that allows hostname "webserver" to hostname "db".
2. (time passes)
3. Hostname "webserver" is deleted/changed to "web"/etc.
4. Someone can now register a user device with the system hostname set to "webserver"
Should they be allowed to inherit the pre-existing ACL rule?
However, you can accomplish something very close to what you're asking for, I think, by defining a "host" in the policy file (https://tailscale.com/docs/reference/syntax/policy-file#host...) that points to a single Tailscale IP. Since we don't allow non-admins to change their Tailscale IP, this uniquely identifies a single device even if the hostname changes, and thus you can write a policy similar to:
Yes I noticed that when designing our ACL usage. I didn’t find it all that useful unless we were inheriting some non tailscale systems with static IPs that we were going to subnet proxy to w/ tailscale.
Tags are just a better way to do this for tailscale only nodes, as now the ACL doesn’t require any change during a device key rotation.
If you’re brewing from ground you really don’t want boiling 212F water as you’ll burn the grounds. I do my pour over at 185F and get smooth ready to drink hot coffee with no/low acidity.
reply