primeval_god

Binhex is the template maintainer, Pihole is both the image and application maintainer. If there is something wrong with the template you have to ask Binhex (or just fix it yourself). If there is something wrong with the image or application you have to ask Pihole. Of the 3 components of a docker application on unRAID, template, image, and application, the template is the simplest to tweak/fix. There are vanishingly few application maintainers who maintain their own templates for unRAID. I can see the case for clarifying its meaning, but i still think the underlying information is valuable. It should be made clear that template maintainers should be the first stop for support for CA applications.

I have got to disagree here. I will concede that the concept is rather cryptic for those not deeply versed in applications on unRAID and the Docker ecosystem but it still is an important piece of information. The key is to understand that for any "application" available via docker through the Community Applications (CA) "appstore" there are possibly 3 separate entities acting as "providers/maintainers". The template maintainer is the one who created the Dockerman Template for the container. Generally speaking they are the only ones with explicit knowledge that the application is going to be installed on unRAID, and they are typically expected to provide some manner of support for their templates as a prerequisite for being included in CA. That said the template is really little more than a convenience mechanism for specifying the proper docker run command. Users can easily override any part of the template (or even just make their own). The image maintainer is the one who created the Docker image. A docker image consists of an application and all the dependencies and environment it requires to run. There is a lot of stuff that goes into an image in addition to its main application. Two images that contain an application (say plex) could have wildly different environments and configurations, as well as any number of additional applications, customizations and scripts. When it comes to choosing an specific image to use you have to trust that the provider of the image understands how to properly setup the application within the chosen environment, is committed to keeping the application/environment up to date (containers that install updates within themselves are not the norm). In a lot of ways an image maintainer is like a package maintainer for a distro in that they may not be the developer of the application but they are responsible for maintaining it for that particular environment. Additionally most docker images are mostly host agnostic the maintainers dont know or care what os the container runs on. The fact that image maintainers are not necessarily affiliated with the unRAID community means support is not a guarantee. Finally the application maintainer is the one who actually develops and maintains the application. They generally have a number of installation methods / environments / distros that they officially support, which may or may not include containers. In general they reserve the right to provide support only for officially supported installations. What the official icon tells us is that the image maintainer and application maintainer are one and the same. It means that this specific container image is one of the officially supported installation methods (on any platform). It essentially means that there is one less entity in the chain of support. Generally this is a good thing, though there are some cases where the official image is less featureful or well build than a third party image. Finally its also worth noting that the "App Store" is called "Community Applications" for a reason. Limetech is rarely if ever the maintainer of a template, image, or application. In that regard there are very few unRAID "applications" that are "officially supported" by Limetech.

These issues should be posted in https://product.unraid.net/b/unraid-os-bugs

Ah see I didnt catch that from your initial post, I read it as just a webui component for borg. That said all of my above points still stand. Putting everything in a plugin will require more maintenance effort long term.

Dont quote me on this but the original unBalance plugin may actually predate the inclusion of docker in unRAID. That said these days it probably could be done within a container, though it does make use of one of the under-the-hood details of unRAID which might make path configuration confusing for users (that being the need to access both user and disk shares). I understand your thinking but i would disagree. I personally handle backup using a containerized version of urBackup. I map the parts of my array that require backup into it via read only mount points (including disk shares). It has dedicated rw mappings for is config, storage, and tmp locations. This ensures during normal operations it only has access to the parts of the system that it needs. The only complication is on restore at which point I have to either change the ro mapping to rw to do an inplace restore, or restore to rw directory and move the files. I am not certain there are many if any examples of an architecture like this with a plugin front end and a container backend, however I think it is a great idea. Perhaps you can set the standard for split plugin/docker services.

Forgive my bluntness, but this should not be a plugin. Docker containers are the preferred way of adding services to an unRAID server, and plugins should only be considered for things that cannot be containerized because they require direct access to the host os. Docker containers (on the unRAID platform) provide crucial benefits to both end users and developers. For end users they provide a means for controlling file access and resource allocation for service that is not available for bare metal plugins. Additionally they protect the stability of the core NAS functionality of unRAID by insulating services in containers. For the developer they address many of your questions above by allowing your service to run in its preferred environment without relying on the stripped down distro that unRAID runs on or having to handle the many versions of unRAID that are currently still in wide use (being essentially a network appliance many users rarely if ever update their systems). In the specific case of you proposed app, the fact that it runs its own webserver, interacts with borg (which i have long said also belongs in a container), and is python based (which does not belong directly on the host system) it is the perfect example of something which would be better served as a container. If the reason for making this a plugin is the want to directly integrate the ui with the unRAID webgui then something link this https://forums.unraid.net/topic/57109-plugin-custom-tab/ is a better solution.

It not no protection, but its not nearly as secure as some would hope. Particularly in unRAID (which is not designed to be an enterprise container host) where many of the container hardening features like rootless containers, container secrets, seccomp profiles are unused, and many standard linux security features on the host (like non-root users) are also unused.

From the website ```"Copy Fail requires only an unprivileged local user account"``` unRAID does not have unprivileged local user accounts.

As an aside I had always hoped that the need/want to pull stacks from github would become irrelevant. I had hoped that at some point my plugin would be superseded by Limetech re-writing dockerman to use compose files instead of their custom xml format (and making use of labels for storing and finding custom metadata about containers). Then compose stacks could become the standard for community supported docker apps and there would be less need to pull third party stacks not designed with the unraid use case in mind. Less need for the beginner and intermediate user that is. Dont get me wrong, I am glad to see you pickup the torch of compose.manager and I am very impressed with the changes your are making. I just always hoped that unRAID would see the light and move away from their custom docker tooling (though to be fair they put a lot of effort into dockerman as it is now and I believe it predates the standardization on compose).

I found the above post very confusing so just in case others are unclear about the git features being discussed let me provide a breakdown based on my understanding. Essentially there are 3 potential interrelated designs/use cases being discussed. 1. Using git to clone existing stacks from github. There are a number of apps out there that recommend compose as the installation method and provide a recommended setup in their git repo. Their instructions for use are essentially clone the repo, add a couple of .env files based on their examples, and then run compose up at the root of the repo. Support for these repos is something that was asked for, and i considered supporting the in the original compose plugin. I eventually decided not to support it for a few reasons. Firstly I did not want to encourage users to pull compose stacks from random sources without understanding how they work. Secondly the kind of apps that I saw recommending this installation method were typically quite complex with multiple (linked or override) compose files, build directories, and environment files. That kind of complexity was not something I intended to support via the ui, which was designed for 1 compose file, 1 env file. Additionally i didnt want to invite the support requests that would come with people trying to use complex stacks that they didnt fully understand. 2. Using per stack git repos to control changes made through the ui. With this idea essentially each stack directory created with the plugin would be a git repo. Every time the user modified the stack via the webui it would make a commit to the repo to allow users to track their changes to the stack and roll back. While very useful for some this could add considerable complexity to the plugin. Also this invites some of the same usage pattern as #1. Personally I wouldnt use the feature as i store my stack in a snapshotted btrfs share. 3. Tracking the top level compose manager projects directory as a git repo. This has the same basic benefit as #2 with slightly simpler management on the plugin side, but potentially more edge cases involving stacks not stored in the projects directory. This could allow for a more granular form of the backup/restore already in this plugin. If combined with #1 it would add considerable complexity with nested git repos. As a side note one point to consider with all of these git based features is the potential for accidentally enabling security issues. With git repos the natural instinct is to mirror them to github as an offsite backup. Of course with compose stacks there is potential for sensitive keys, passwords, urls, etc. being stored along with the stack (not best practice but common and likely not understood by many unfamiliar with the technology like new unraid users). Making it to easy to push personal compose stacks to a public git repo may unintendedly encourage users to make poor security decisions.

This is likely better served as a docker container, there are several jdupes containers out on the web.

Let me start off with why I am not convinced this is a good idea. One of the big use cases people want this for is that some projects host complete compose stacks on github with the idea that you would just clone the repo and run compose up in it. Putting aside the dangers of running a stack off the internet without understanding it, this conflicts with the way the original compose manager stored project files. The ability to specify a project not in the main folder was a step in the direction of supporting this feature, but a further complication was the diversity of structure of these type of projects. Many of the projects hosted this way do so because they are quite complicated with multiple linked compose files, which makes the parsing for building the override file for applying labels even more complicated. In the end to keep the plugin simple and avoid support requests and for complex compose stacks that stretch my understanding of compose I chose to only explicitly support a simple project layout. The above said maybe you could do something with git submodules to support for nesting git repos in a git based project folder.

What on earth are you talking about? unRAID is a consumer focused home NAS OS. Its not designed for self hosting public facing services.

Let me get this straight, you want Limetech to self host some sort of alternative place where users can go to get help, talk with each other and the developers, and access an archive of discussion and knowledge from years of interaction. Some place that is not tied to a centralized platform, like discord or reddit. Some place that can be accessed without an account and can be indexed and searched from the wider web. Yeah that sounds pretty useful...if only a place like that already existed.../S