EDACerton

"No one did it yet" is completely false. The "initial purchase + annual support" licensing model has been common for server OSes for a long time. OEM-distributed desktop OSes are a different thing altogether. Those licenses are tied to specific computers, and so when the device is no longer useful, the license goes with it (and you just pay for a new one when you buy a new computer). The Unraid equivalent to "desktop licensing" would be having to buy a new license if you ever replaced your motherboard/CPU/etc. I like the "server" licensing approach better.

You seem to have had a bunch of issues connecting to the control servers from Unraid. Some examples (there's more than this in the log, but you get the idea): There's also what might be problems with your client: Everything on the Unraid configuration seems to be OK, though.

I’m used to enterprise software support contracts too… I’ve dealt with them for a long time. The renewal cost is what I found interesting from the podcast — 50% is a lot for a software renewal. 20% is closer to the industry norm. Not backdating/charging reinstatement penalties is interesting too. I’d rather see a less expensive renewal, but have the support backdate if I let it lapse and then renew.

Everything is a Trust Us™️ scenario. Limetech does nothing? Trust Us™️ to not make changes in the future. Trust Us™️ to be able to bring in sufficient revenue to keep the product going (after all, if they go under then a promise of lifetime updates isn't worth much). Limetech makes licensing changes, and honors the existing licenses? Trust Us™️ to not make changes in the future. I'm not afraid to push when I think it's required (ref: my questions about privacy posted earlier in this topic). Portraying the licensing change as a breach of trust is excessive, though -- they're honoring exactly what they offered. They never promised to sell a forever license for forever.

This isn't a switch on people that have purchased the software, in reality it's the exact opposite. When we all purchased Unraid, Limetech made the claim that we would get lifetime updates. They are honoring that claim. The only difference now is that some licenses will be sold that don't include an offer of lifetime updates.

This seems like you're running into the same bug that others have. There are a few ideas I can recommend (pick one, any will work if this is right): Reboot your server Switch to the preview branch of the plugin Wait for a few days, when I push the next update to the main branch it will have the fix for this issue.

That'll make all of the drama over licensing feel like nothing 🤣 (Disclaimer: I've been binge watching Voyager lately. 🤓)

I appreciate the response regarding the licensing situation. The other concern that I would like some explanation for is the privacy issue related to the new update mechanism. I was finally able to coax some debug logs out of my browser, and I discovered that there's a lot of information being sent with every click of the "Update OS" button: apiVersion caseModel connectPluginVersion description expireTime flashProduct flashVendor guid inIframe keyfile lanIp name osVersion osVersionBranch registered regGuid regExp regTy regUpdatesExpired site state wanFQDN Some of these make sense as part of a license check (guid, keyfile, flash information). Some, though, seem to be quite extraneous: caseModel (does Limetech really need what kind of case my server is in?), LAN IP, hostname, description... none of these are needed to validate a license. The privacy policy (https://unraid.net/policies) says nothing about collecting this kind of information: What is the primary purpose for collecting all of this information? Is the information used for other purposes? If so, what? Is this information stored? If so: Is it stored in identifiable form? How long is it retained?

I knew that something didn't smell right when I saw the encrypted data being sent as part of the update process. It felt like there was some motive beyond what the blog post stated. That makes more sense now. This situation has (at least temporarily) damaged my faith in Unraid. Not because of the potential changes, but because of how it's being done. I hope to see more up-front communication soon.

You don’t need to do anything except log in on the settings page. After you log in, use the Tailscale IP for the server to access it.

I do think there are some questions that ought to be answered on this... The new update process is transmitting around 1KB of data about the system to unraid.net every time the "Update" button is clicked. This data has been deliberately encrypted in such a way that even the end user can't see what's being transmitted. (Also, noteworthy -- this is using a very unusual method of encrypting data between a client and server... the data is already being sent over HTTPS, additional encryption isn't required for data-in-transit protection.) The blog post says "When checking for an update the server's license information, flash information (vendor, model, GUID), and basic server details (like name, description, IP, version) are used to validate your license and help us provide a better customer experience." I have a hard time believing that such information creates a total of 1KB of data. This leaves me with several questions: Is there a comprehensive list which describes all data that is being transmitted to unraid.net? Why is this communication obfuscated so that end users cannot see what data their server is communicating? Is there a way to revert to the "Old" update method which does not require sending system-specific information just to receive updates? How does this follow the Unraid privacy policy, which says nothing about collecting server name/description/etc, and in fact states: "We only collect the minimum information needed to do business with you, provide better security, and collect feedback to improve our products and services." How does sending a server's private IP address meet these conditions?

There seems to have been a glitch with Community Applications (my Tailscale plugin got blacklisted too), Squid is working on it. You shouldn't need to do anything.

@Squid ?? Edit: it looks like Squid is working on something weird with Community Applications, I'd assume that this is related to that, it will hopefully be fixed soon.

2024.02.15 (Preview) Update Tailscale to 1.60.0

It sounds like you did encounter that, now that you're logged in you shouldn't see that again.

Everything on the Unraid side seems fine. The version of the plugin that you have checks to see if the WebGUI has applied the configuration correctly, and it has: 2024/02/09 12:23:45 tailscale-watcher.php: WebGUI listening on 100.x.y.121:5000 I do see a bunch of messages in your Tailscale log that make me think there's something going on with your Mac, possibly that it can't connect to the Tailscale relay servers (this is just a sample, there's a *lot* of these): 2024/02/09 12:26:52 [unexpected] magicsock: derp-2 does not know about peer [P7Vj3], removing route 2024/02/09 12:26:57 [unexpected] magicsock: derp-2 does not know about peer [P7Vj3], removing route 2024/02/09 12:27:02 [unexpected] magicsock: derp-2 does not know about peer [P7Vj3], removing route 2024/02/09 12:27:08 [unexpected] magicsock: derp-2 does not know about peer [P7Vj3], removing route 2024/02/09 12:27:14 [unexpected] magicsock: derp-2 does not know about peer [P7Vj3], removing route I would recommend checking the logs on your Mac to see if that gives any hints. You could also try posting in r/Tailscale over on Reddit if you can't figure anything out there.

To connect using the local IPs via the subnet routers, you'd have to enable "Use Tailscale Subnets" in the advanced Tailscale settings on both nodes. I don't generally recommend that though unless it's really the only viable option (like trying to connect to a remote device that can't run Tailscale). Since both nodes are running Tailscale, there's a better/simpler option -- use the 100.x.y.z Tailscale IPs for the connection. That will skip the subnet routers, and can also give you better performance.

Have you turned on "Host access to custom networks" in Docker settings?

I've released some tweaks on the preview branch that might help: 2024.02.04 (Preview) Detect if nginx does not reload correctly after Tailscale comes up Add diagnostic information: ip routing and open ports

Have you rebooted since you removed the Docker plugin? Some folks have had weird issues when switching that only cleared up after rebooting.

Have either of you tried restarting your server? I think this is related to a problem I've been chasing related to when Tailscale is initially logged in, but if that's the case a reboot should fix it.

Tailscale0 is for the docker container, not the plugin. The plugin adds “tailscale1” to extra interfaces.

Yes, you’ll have to use the CLI to connect (tailscale up --login-server)

Please download diagnostics from inside the plugin settings.