Jump to content
Squid

[Plug-In] Community Applications

2200 posts in this topic Last Reply

Recommended Posts

So I feel like a bit of an idiot since I can't find anybody else mentioning the same problem. I can't get the plugin to install. I keep getting this error: Warning: mkdir(): Read-only file system in /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin on line 235, and I don't know what to do. I'm definitely a NOOB when it comes to working with anything other than the GUI, how do I get around this? My system was upgraded to the official 6.0 after running the beta, and I have everything else I need working, including VM's and several Docker applications. Any help to get Community Applications installed would be greatly appreciated, sorry for the NOOB trouble, and TYIA!

Share this post


Link to post

So I feel like a bit of an idiot since I can't find anybody else mentioning the same problem. I can't get the plugin to install. I keep getting this error: Warning: mkdir(): Read-only file system in /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugin on line 235, and I don't know what to do. I'm definitely a NOOB when it comes to working with anything other than the GUI, how do I get around this? My system was upgraded to the official 6.0 after running the beta, and I have everything else I need working, including VM's and several Docker applications. Any help to get Community Applications installed would be greatly appreciated, sorry for the NOOB trouble, and TYIA!

Any chance your flashdrive somehow is set to be read-only?  Shut down the server and toss it into your desktop (it should automatically try and fix any errors on it)

Share this post


Link to post

Thatswhy i installed dropbox. (i have a cache disk aswell)

But now what?

How do i set it up?

It doesnt direct me to my dropbox account, cause i did not have to set up my account settings

Hit the Log button for the Dropbox container.  In the log is given the URL that needs to be run to authenticate the Dropbox container against the account it has been set up for.  You can copy paste that URL and run it on a different system - it does not need to be run from the unRAID server (which does not have a browser installed).

 

Note that this is mentioned in the configuration instructions for the Dropbox container shown when you select the Edit option for the container.

Share this post


Link to post

Updated to 2015.07.01a

 

This update is for an experimental new feature.  Namely, an attempt to make mapping host paths a little bit easier to new users.

 

This feature is completely optional and defaults to being disabled.  To enable it you must go into the settings, tell it to use it, and then update the applications.  If after using it you prefer to have it disabled again, turn it off in the settings and update the applications again.

 

With it enabled, CA will modify the template files:

 

  • Any host paths which are not already set will be set to /mnt/user
  • Any container path which contains "config" will have its host path set to /mnt/user/appdata/$templateName (note that this will overwrite any path already set in the template
  • If there is a cache drive present and the appdata share does NOT already exist, then the plugin will create a cache-only appdata share.  Note:  the share will not be able to be managed through the shares tab unless you stop and start the array
  • If there is no cache drive present, the appdata share which it creates will use the default split level / allocation method. While this will work, your appdata folder may wind up being split across several harddrives, and performance may suffer.

 

Unfortunately, there is no way that I'm going to go and test all of the applications out there to see if this works with all of them, hence why its still experimental.  I do not forsee any ill effects from it however.

 

Currently the /mnt/user/appdata folder is hardcoded into the plugin.  If feedback is positive on this concept as a whole then I could add a setting where the user has the option to choose a folder for it.

 

Ideally, this concept really should be incorporated directly into dockerMan and not into CA.  But, it is a lot easier to play with ideas in a plugin rather than in a base OS component

 

As an aside, I personally do not advocate passing /mnt or /mnt/user to containers.  There is a big debate about this in the Docker FAQ feedback (http://lime-technology.com/forum/index.php?topic=40983.0), but I cannot deny the simplicity and ease of implementation for new users in setting their system up like this.

Share this post


Link to post

I think it's a good idea to leave the host path blank. In all of my templates I leave it blank, so the user has to input the correct location before they can install.

 

I notice that a lot of users just hit the create button without even reviewing the settings. A lot of issues arise when the default settings don't mesh with a user's specific setup. If the fields are blank, then the user is given an error message and they realize they have to select something. Then they pay attention to it.

 

I think we should not only "let" the users select the host path, but we should "force" them to select it for themselves. It would create less support work for the devs.

 

In all honesty, 80% of the support requests I get for my containers is because the user didn't read the description and they didn't use the correct settings.

 

EDIT: I didn't at first see the note about having the user set a base path and use that for all future templates. I like that idea as long as the users are somehow forced to set it and not rely on whatever default value there is.

Share this post


Link to post

Updated to 2015.07.01a

 

This update is for an experimental new feature.  Namely, an attempt to make mapping host paths a little bit easier to new users.

 

This feature is completely optional and defaults to being disabled.  To enable it you must go into the settings, tell it to use it, and then update the applications.  If after using it you prefer to have it disabled again, turn it off in the settings and update the applications again.

 

With it enabled, CA will modify the template files:

 

  • Any host paths which are not already set will be set to /mnt/user
  • Any container path which contains "config" will have its host path set to /mnt/appdata/$templateName (note that this will overwrite any path already set in the template
  • If there is a cache drive present and the appdata share does NOT already exist, then the plugin will create a cache-only appdata share.  Note:  the share will not be able to be managed through the shares tab unless you stop and start the array

 

Unfortunately, there is no way that I'm going to go and test all of the applications out there to see if this works with all of them, hence why its still experimental.  I do not forsee any ill effects from it however.

 

Currently the /mnt/user/appdata folder is hardcoded into the plugin.  If feedback is positive on this concept as a whole then I could add a setting where the user has the option to choose a folder for it.

 

Ideally, this concept really should be incorporated directly into dockerMan and not into CA.  But, it is a lot easier to play with ideas in a plugin rather than in a base OS component

 

As an aside, I personally do not advocate passing /mnt or /mnt/user to containers.  There is a big debate about this in the Docker FAQ feedback (http://lime-technology.com/forum/index.php?topic=40983.0), but I cannot deny the simplicity and ease of implementation for new users in setting their system up like this.

 

i'll give it a whirl in a bit....

 

 

Share this post


Link to post

Tried it out with that container we've been working on and here are the first results....

 

VhO5Zrl.png

Share this post


Link to post

I think it's a good idea to leave the host path blank. In all of my templates I leave it blank, so the user has to input the correct location before they can install.

 

I notice that a lot of users just hit the create button without even reviewing the settings. A lot of issues arise when the default settings don't mesh with a user's specific setup. If the fields are blank, then the user is given an error message and they realize they have to select something. Then they pay attention to it.

 

I think we should not only "let" the users select the host path, but we should "force" them to select it for themselves. It would create less support work for the devs.

 

In all honesty, 80% of the support requests I get for my containers is because the user didn't read the description and they didn't use the correct settings.

 

EDIT: I didn't at first see the note about having the user set a base path and use that for all future templates. I like that idea as long as the users are somehow forced to set it and not rely on whatever default value there is.

I personally do NOT agree with setting up paths like this.  At this point in this experiment, I wouldn't even recommend a new user to turn the feature on. 

 

Its merely a starting point for one of the two big support problems with containers right now.  Paths and Ports.  Both of which are not the easiest subjects to explain to new users.  This is merely one option for the problem of paths.  No one can deny the ease of setting up host paths of /mnt/user.  The appdata and cache only thing was really an after thought since I was modifying the template anyways.

 

That being said, its feedback like yours that is necessary and wanted on anything like this.

 

 

EDIT: I should clarify my first sentence.  I personally do not agree with setting up paths of /mnt/user

Share this post


Link to post

I think it's a good idea to leave the host path blank. In all of my templates I leave it blank, so the user has to input the correct location before they can install.

 

I notice that a lot of users just hit the create button without even reviewing the settings. A lot of issues arise when the default settings don't mesh with a user's specific setup. If the fields are blank, then the user is given an error message and they realize they have to select something. Then they pay attention to it.

 

I think we should not only "let" the users select the host path, but we should "force" them to select it for themselves. It would create less support work for the devs.

 

In all honesty, 80% of the support requests I get for my containers is because the user didn't read the description and they didn't use the correct settings.

 

EDIT: I didn't at first see the note about having the user set a base path and use that for all future templates. I like that idea as long as the users are somehow forced to set it and not rely on whatever default value there is.

I personally do NOT agree with setting up paths like this.  At this point in this experiment, I wouldn't even recommend a new user to turn the feature on. 

 

Its merely a starting point for one of the two big support problems with containers right now.  Paths and Ports.  Both of which are not the easiest subjects to explain to new users.  This is merely one option for the problem of paths.  No one can deny the ease of setting up host paths of /mnt/user.  The appdata and cache only thing was really an after thought since I was modifying the template anyways.

 

That being said, its feedback like yours that is necessary and wanted on anything like this.

 

hear hear..

feedback is crucial..

Share this post


Link to post

EDIT: I didn't at first see the note about having the user set a base path and use that for all future templates. I like that idea as long as the users are somehow forced to set it and not rely on whatever default value there is.

Truth be told, the closer I can get using dockers to be more of an appstore experience, the better off the whole thing will be.  Support questions shouldn't really be on the most basic items involved in setup.

Share this post


Link to post

EDIT: I didn't at first see the note about having the user set a base path and use that for all future templates. I like that idea as long as the users are somehow forced to set it and not rely on whatever default value there is.

Truth be told, the closer I can get using dockers to be more of an appstore experience, the better off the whole thing will be.  Support questions shouldn't really be on the most basic items involved in setup.

 

If LT wants to get into the less tech savvy customers field of view, then anything that can ease them into the environment is good.

 

Share this post


Link to post

I think we should not only "let" the users select the host path, but we should "force" them to select it for themselves. It would create less support work for the devs.

In this initial experiment, I did leave provisions for the author to outright force a mapping to have to be manually mapped.  Any mapping which outright requires user input (and will not possibly work using /mnt/user) can have in the template:
<HostDir> </HostDir>

(notice the space).  Or you can do as Binhex does and leave instructions in there.

 

It's only mapping <HostDir></HostDir> (where there is nothing at all inside). 

Share this post


Link to post

Some minor updates / tweaks

 

- Ability to select large or small icons in icon mode

- Option to overwrite all author selected host paths in the experimental path overwrite mode (disabled by default)

 

Few notes on the overwrite mode:  Still experimental (but works for the vast majority of applications.  One notable exception is MariaDB.  While it works, the paths MUST be changed inorder to not have the container create a whack of new shares (mariaDB  doesn't have a /config folder so this experiment maps the /db folder to /mnt/user)

 

Also, I found a vague reference by gfjardim about simplifying docker:

 

Guys, I'm working on another project right now, so I will slow down this a bit, but any major bugfixes will be addressed, ok?

 

When I come back, I'll modularize the code, so NFS/IMG/ISO/DVD mounts will be possible, alright?

 

Thanks a lot for understanding.

 

Another Project - anything interesting?

 

Simplify Docker .

I'm going to cease development on this experimental mode until I see what he's trying to accomplish.  No sense in duplicating efforts, and I'm not happy with blindly taking a guess at what mappings should be mapped to /mnt/user/appdata and which should be merely to /mnt/user.  And, none of these hacks I'm playing with really belong within Community Applications anyways.

 

Share this post


Link to post

It would be a way to start fresh, creating a new 'official' post (for Announcements board) and a new Support topic, and rename the old one as an archive.  First post in each would cross-link, and Community Applications would also have both links (if Squid is willing).  Just a crazy idea, probably too hard to make it happen ...

My part of the above is done.  Now clicking on the repository will take you to the repository announcement thread.  Clicking on [support] will take you to the appropriate support link for that particular application.  (Whether or not RobJ's complete crazy idea comes to fruition or not it actually made sense to add support for it to this plugin)

 

If you want support for a container, make sure that you click support so that your postings will wind up in the correct thread.

 

Also some minor coding improvements I'd been holding off on releasing.

 

Updated to 2015.07.08

Share this post


Link to post

Updated to 2015.07.15

 

Removed the experimental option for having this plugin automatically fill out host paths.  This option was an experiment to determine the feasibility of such a feature.  And, while it did work for much of the applications out there, there were still a fair number out there where this option would actually make the application fail.  Any support for something like this really belongs within dockerMan, and there are also going to have to be some template changes to fully support it.

 

 

Added the option to automatically update the application lists whenever entering the docker tab.  Defaults to disabled

 

And the big change with this update is to support either the traditional method of parsing the templates, or supporting Kode's application feed.  This feed (http://tools.linuxserver.io/unraid-docker-templates.json) is currently updated every two hours with any and all changes to the applications, additional repositories, etc.  I would recommend turning on the automatic updates when enabling this feed. 

 

Because I no longer have to download 199 templates and then parse them, updates are very fast.  (If you are using dynamix in tabbed mode, odds are good that by the time you select the Community Applications tab, the update will already be done)  In most of my testing, the updates were all done in less than a second.

 

The one caveat with this mode is that if you have a private repository, the system automatically downgrade itself to downloading all of the individual templates from all of the repositories.  A future update (couple of days) will address this.

 

 

Because this feature is new, the default setting for it (and automatic updates) is disabled.  However I would encourage everyone to actually enable this and try it out.

 

One thing to note is that the Update Applications button in the app feed mode only grabs the latest feed.  In other words, if the latest and greatest application has just been released, in the App Feed mode it will take up to two hours for the application to appear in the plugin.  If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

Also, because this feed contains some extra information about the application that is not present in the template, I will also shortly be issuing an update to display some of the more technical info about the app.

Share this post


Link to post
If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

damn it, that's me pretty much stuck in legacy mode then, can't wait two hours (or until next cycle) to test new builds and how they load from CA.

Share this post


Link to post

If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

damn it, that's me pretty much stuck in legacy mode then, can't wait two hours (or until next cycle) to test new builds and how they load from CA.

 

Do you push your changes to github?  I could add an API endpoint that you could use a webhook to hit which in turn forces the rebuild to start if that would be any help?  It currently takes 3 to 5 minutes to rebuild the feed.

 

If this is something you would be interested in feel free to hit me up in #linuxserver.io on freenode (you can use this webchat if you dont have an irc client) and we can hash out the details

 

*edit* forgot to say, if the interest is there for me to do the webhook integration, I will probably move the feed into a database and load from that, this will enable me to only update if there have been changes and will mean when an author hits the webhook it will only update their list making it a MUCH faster update process, then the full update will run every 2 hours (as it does now) to pick up any stragglers that haven't integrated a webhook.

Share this post


Link to post

If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

damn it, that's me pretty much stuck in legacy mode then, can't wait two hours (or until next cycle) to test new builds and how they load from CA.

Already started the revamp to address much of this.  Should be ready sometime this weekend.  Or, you could do the gentlemanly thing and share.

Share this post


Link to post

If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

damn it, that's me pretty much stuck in legacy mode then, can't wait two hours (or until next cycle) to test new builds and how they load from CA.

Already started the revamp to address much of this.  Should be ready sometime this weekend.  Or, you could do the gentlemanly thing and share.

 

not putting my private repo out there, lol...

there's stuff in there that breaks things.

Share this post


Link to post

If you can't wait to install a newly released application, then you will have to switch the mode back to the legacy mode.

 

damn it, that's me pretty much stuck in legacy mode then, can't wait two hours (or until next cycle) to test new builds and how they load from CA.

Already started the revamp to address much of this.  Should be ready sometime this weekend.  Or, you could do the gentlemanly thing and share.

 

also i run builds on my beta repo too, sometimes needing template updates too.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now