EDACerton

I have it running on 7.3.1 on my production and multiple test servers. I’ll need more details/diagnostics to be able to understand what’s happening.

Patience please. The main plugin will get updated in a day or two (once it’s had time to bake in preview). I got behind a couple versions because of real-life stuff, but there wasn’t really anything relevant in the updates for Unraid.

The preview plugin has the latest release.

@MyKroFt @ambipro This should be fixed in the latest update.

Why?

So, long story short... The author of TSDProxy disappeared for a year, then came back and suddenly dropped v2, which completely breaks every existing config. So Label Manager doesn't work with it anymore, existing labels need to be rewritten for the new format, etc. I'm not quite sure what my plan for this is going to be at this point. It might be to try to update to support TSDProxy v2. It might be to recommend tsbridge, and to add support for that to Label Manager.

It wasn't a delay... a while back, I switched the configuration from a .cfg (INI) file to a JSON file. The problem is that the scripts that run on array startup were still looking for the old config file. If that file happened to exist (you had an older version of the plugin installed previously, etc.), it worked fine, but if you didn't have that file, the activity watcher wouldn't start when the array did.

Please provide diagnostics per the instructions at the top of the page.

Nope. Everything is still going fine, maybe some connectivity issues from your server to Github?

This should be fixed in the latest update.

Thanks. I’ll dig into it more later this weekend. Sorry for the delay, had other life stuff going on.

99% of the time “local IP connectivity issues after installing Tailscale” are the result of turning on “accept routes” on the Unraid server. If turning that off doesn’t fix it, please follow the instructions in the green box at the top of this thread.

ChatGPT is wrong. You probably have TLS set to Strict in management settings.

If you install Plugin Diagnostics from CA, File Activity should show up, you can use the "Upload" button there and it will give you a code to post.

I'm not sure. I've tried doing reboots on my test systems and haven't seen that behavior. What would be helpful would be a plugin diagnostics package from a server right as it's having the problem, that way I might be able to see what about the setup might be causing the issue.

Sorry for the delay, I’ve been extra busy with real-life stuff. I’m also hoping that LT will add a new kernel flag in 7.3 that will let me do even better with what the plugin can report.

Upvote here: https://product.unraid.net/p/kernel-enable-config_debug_info_btf-y-for-full-ebpf-btf-support?b=unraid-os-feature-requests

Gotcha. There’s a known problem where you can’t set up the plugin with the array started if all of the encrypted disks are in the array. I should have a fix for that in a day or two.

Do you have any encrypted pools, or all of the encrypted drives in the array?

Yes

Yes, you can; you’ll just need to add the necessary rule to your Tailscale ACLs to grant access to the tsidp admin console.

OK, so now I have an objection: It's your plugin. You write it, not the CA team. It's your responsibility to make sure that it's done in a quality way. This expectation that someone else will do a code review for you is wrong. Every other plugin out there is open source. Look at how they work. See what patterns are repeated (because they work). Look at the files on the system that explain how the plugin system works (hint -- the plugin command is actually a script).

@johner @guyfrom7up I'm just another community developer, but I have a lot of experience writing for this platform, and I decided to take a glance at both plugins. From a policy standpoint, I would question if these need to be plugins. CA policy states that "Plugins which are better suited as a docker application are not eligible for inclusion in CA." That would seem to be the case for these tools; why do they need to be installed and run with root privileges within the operating system? There are many ways to run these tools using containers which are better from a security/safety standpoint. Setting the policy concern aside, from a design standpoint, both plugins give me a very solid sense of "this was AI-coded without a substantial human review / understanding of what it does". Now, to be clear -- I'm not against the use of AI in general. I think it can be a very helpful tool. With that said, neither plugin follows the standard conventions for Unraid plugins (e.g., building a Slackware package containing files that are expected to persist across boots, using event hooks to handle specific events). Given that the plugins run as root, and because those conventions exist for good reason (as discussed further below), that makes me concerned about the quality/safety of running either plugin. Neither plugin builds a package for its persistent files. In particular, for Unraid Tab, the "manual" method of downloading files and caching them on the flash drive lacks a crucial feature -- updating. If the file already exists on the flash drive, it looks like the only way to actually update it is to uninstall and reinstall the complete plugin so that the cache gets removed. Otherwise, the install will just keep using the cached version on disk. The conventional way to handle all of this is to have a versioned Slackware package which contains all files that are expected to persist, which is then installed on every boot by the .plg file. At minimum, you should be using <FILE> blocks with a URL and checksum so that the files can be verified and re-downloaded if they ever change. The Claude plugin makes an attempt to "cache" the binary so this won't happen, but also creates a hidden dependency on array auto-start; if your array hasn't started within 5 minutes of the system booting, the plugin will try to install anyways (it seems like), redownloading Claude, but it won't set up persistence and writes files into /mnt/user before the array starts (which can cause other confusing issues later on when the array is eventually started). The conventional way to handle this (run process after array starts) would be as an array_started event hook.

There's an "Allow Tailscale Funnel" option in the plugin "Settings" tab. If that doesn't appear, it means that you're on an older Unraid version (pre-7.2.0) where enabling funnel for the WebGUI is dangerous because the WebGUI didn't require authentication for connections from localhost (which is what traffic from funnel looks like... so if you enable funnel and funnel the WebGUI, anyone that accesses that URL would get full access to the WebGUI with no login required).

@Fragsrus This isn't a plugin issue. This is a system configuration issue. Starting NPM shouldn't cause br0 to lose its IP address. That's the root cause of your problem, and the issue that you should fix. Barring that, a much simpler workaround would probably be to just put a 30-second delay on the container auto-start, to let everything else finish before it breaks the interface.