Mailman 3 is acceptable, imho. It's been a few years since I worked with it, but I was able to design a reliable public instance of it (https://mailman.haskell.org) with a few days of effort, including the migration from mailman v2.
Lol this makes sense. I really respect the author of mailman3's dedication, but the architecture of the system is insane. There are 3 services -- the actual mail delivery piece, the admin interface, and the archiver -- all talking over various public and local interface, configuration is a nightmare, logs are all over the place, it takes over your system with scheduled cron jobs, there's some kind of built in console that I can't figure out how to use due to virtualenv issues plus cli commands that cover only some of the necessary functionality. It's gotten better since I run the tool as two docker containers, but still ends up being the most difficult service to administer and I administer quite a few
Thank you, wasn't aware of this project, but it makes total sense!
Managing the advertised subnets manually is a bit of a pain, while the downsides of accidentally advertising a subnet are negligible, since you still have full control over them in the Tailscale console.
Khat will wreck your teeth if you chew the leaves. And it's about on par with caffeine as far as stimulants go, so personally I'd stick with coffee or tea instead of khat.
There are indeed nvidia drivers for Linux and they're reasonably good for gaming, but the feature set sometimes lags far behind windows. There is no DLSS 3 for Linux, for instance. (as of a few months ago anyway - I haven't checked recently)
I've done exactly that: headscale in production at work, a few hundred client devices, infrastructure mostly powered by nix. What would you want to hear about it?
* Does it work well?
* Do you recommend it?
* Do your users care?
* Is it difficult? Do you have to maintain it or is it basically set it and forget it?
* What was memorable about setting it up?
* Why did you go for Headscale vs Tailscale or Netbird or some other solution?
Very well! There are some limitations (see link above), but what's implemented is reliable.
> * Do you recommend it?
Yes, provided your requirements fit headscale's capabilities. If you need things like device trust attestation (e.g. Kandji MDM or Crowdstrike Falcon integration), SCIM provisioning, or various other enterprise features you may find it inadequate. If you can afford to pay for Tailscale, you should just use Tailscale because it's really good.
> * Do your users care?
They like it way better than our previous OpenVPN setup, that's for sure. I don't think they care about Headscale vs commercial Tailscale - the backend implementation is largely invisible to them.
> * Is it difficult? Do you have to maintain it or is it basically set it and forget it?
Not hard at all to set up, and it requires little maintenance attention. I have barely had to touch the control plane (other than version upgrades) since setting it up a year ago.
> * What was memorable about setting it up?
We had to do some custom coding to have automatic user offboarding when employees leave the company, and to emulate app connectors / dynamic routing (this is now OSS! https://github.com/singlestore-labs/tailscale-manager).
And I've been contributing to the headscale codebase to smooth out some quirks that affected our SSO integration. The headscale authors have been pretty flexible in welcoming outside contributors.
> * Why did you go for Headscale vs Tailscale or Netbird or some other solution?
vs Tailscale: It was way easier to build this myself than to get funding to use the commercial solution. I'm not good navigating corporate politics, but I am pretty good at building infrastructure and writing code.
vs Netbird: Mostly because I already liked Tailscale from using it at home, I like its implementation, and I like the way Tailscale (the company) have behaved. The handful of folks I know who work there are people I deeply respect.
- How much effort do you put into key management compared to plain WireGuard?
- How automated is the onboarding process; do you generate and hand over keys?
- How do you cope without the commercial Tailscale dashboard?
- Do you run some kind of dashboard or metrics system?
- How long did it take to set up?
- Were there any gotchas?
> - Do you run some kind of dashboard or metrics system?
Yes, I scrape headscale's Prometheus metrics endpoint and have put together a simple Grafana dashboard. The metrics it emits are somewhat limited, but enough to keep an eye on its health.
> - How long did it take to set up?
I had a prototype up and running on Kubernetes with OIDC integration and a web UI in about 1 day of hacking. Going into full production took a few months, but the majority of that time was about planning the migration of all the existing users from OpenVPN.
Come to think of it, maybe I should share my terraform modules for deploying it.
> - Were there any gotchas?
A few, yeah:
- Setting up mobile clients is a bit fiddly, because they hide the "connect to a non-default control plane URL" under a debug menu. The mac and windows apps are similar - it's too easy for users to accidentally try to connect to tailscale.com instead of your headscale instance. If you have the ability to deploy MDM profiles (mac) or windows registry tweaks this is easy to fix, and the headscale server will even generate the configs for you.
- The headscale control plane doesn't support any kind of HA or replication. This doesn't disqualify it since tailscale can handle brief control plane outages without breaking the network, but it's likely to be a concern for serious enterprise users. It's possible to use an external Postgres database, so you can at least replicate data that way, but only one headscale server replica can be active at a time because they don't share runtime state.
- The tailscale API is not fully implemented, so you can't use things like the tailscale Kubernetes operator.
- Some features are missing: tailscale funnel, tailscale serve, app connectors, `autogroup:self` ACLs, SCIM provisioning, SSO group membership sync, and I forget what else. These may or may not be important to you.
It's possible to implement group sync with some custom scripting - a python app to scrape your LDAP (or whatever) and generate tailscale ACLs isn't hard to write. But you do have to write it.
`autogroup:self` might be a big deal - you would need this if you want to stop users from seeing or connecting directly to each other's devices. I think there is an implementation of this coming in the next release of headscale.
Summary: headscale is great if you have relatively simple needs and can't afford to pay for Tailscale. You will probably outgrow it if you're running a serious business and need to comply with fancy audit requirements.
(Haiku developer here.) There is one hardware accelerated driver, for Radeon Southern Islands; but it's third-party, out-of-tree, and not particularly simple to set up and get running. So, not really.
Thanks for the response. Is there much hope for this to change at some point? I would love to eventually use Haiku on actual hardware, and the lack of video acceleration is the main thing that discourages me from giving it a go.
I was about to be like "surely you mean the S/390 series" but nope, you are correct! Apparently 3090 came in between the S/370 and S/390 series: https://en.wikipedia.org/wiki/IBM_3090
