[Plug-In] Community Applications


Recommended Posts

I notice that if you want CA to search dockerHub you have to both enable that option in the Settings, and also press a button from the initial search results.  Is there a reason that it is a two stage process or is it historical?  The reason I was asking was that earlier today I could not initially determine why my brother could not see the official ownCloud docker on his unRAID system whereas I had no problem seeing it.  Perhaps the Settings option which makes the button appear to search dockerHub appear is now superfluous?

Two step because:

 

1 - I don't want everyone randomly installing any container off of dockerHub because I (and the community here at large) do not have the ability to support why doesn't it work, why won't it install, why doesn't it always create a template correctly.  Purely an advanced feature

 

2- To force the user to pick and choose from a community supported app before going to dockerHub at large, and to make it obvious that that's what happening.

 

If it wasn't a two step procedure, then the following could happen:

 

Search for couch potato.  The community apps appear and also the dockerHub results appear.  ok.  There's CP from linuxserver.  I think I'll install that.  User chooses the lsio version from dockerHub instead of from the community apps.  Now there's going to be a whack of permission issues, etc because the environment variables in the template are going to be missing.

 

I don't see this operation changing unless I get more requests, because I just don't want to have to deal with the potential issues that could result in the forums.

Link to comment

I went into console and killed the community repository script that was hung. WebGUI came back and community repo came online. All is good in the universe thanks Squid!

 

What process did you kill?  Also, I have to highly recommend that you reboot your server because there has to be remnants of Community Repositories still kicking around that are causing issues.

 

Also, I recommend that you enable notifications on your server so that you can tell when updates are available.  IIRC I pumped out an update for CR that basically told you to uninstall it and switch to CA.

 

 

Link to comment

I notice that if you want CA to search dockerHub you have to both enable that option in the Settings, and also press a button from the initial search results.  Is there a reason that it is a two stage process or is it historical?  The reason I was asking was that earlier today I could not initially determine why my brother could not see the official ownCloud docker on his unRAID system whereas I had no problem seeing it.  Perhaps the Settings option which makes the button appear to search dockerHub appear is now superfluous?

Two step because:

 

1 - I don't want everyone randomly installing any container off of dockerHub because I (and the community here at large) do not have the ability to support why doesn't it work, why won't it install, why doesn't it always create a template correctly.  Purely an advanced feature

 

2- To force the user to pick and choose from a community supported app before going to dockerHub at large, and to make it obvious that that's what happening.

 

If it wasn't a two step procedure, then the following could happen:

 

Search for couch potato.  The community apps appear and also the dockerHub results appear.  ok.  There's CP from linuxserver.  I think I'll install that.  User chooses the lsio version from dockerHub instead of from the community apps.  Now there's going to be a whack of permission issues, etc because the environment variables in the template are going to be missing.

 

I don't see this operation changing unless I get more requests, because I just don't want to have to deal with the potential issues that could result in the forums.

I was not saying it should not be a two step operation!    Currently it is 3 step operation:
  • Enable option to retrieve from dockerHub Settings->CA->General
  • Search for an option in CA
  • Get the additional candidates by pressing the button on the search results to get more from dockerHub

I was just thinking of eliminating the first one to leave it as a 2-step process.  However if you want to leave it as a 3-step operation then I am personally quite happy as I have done the fist step in my environment leaving only the last two when looking for any specific docker.  In the case I mentioned it was for ownCloud and it seemed sensible to use the one that is being maintained by the ownCloud development team rather than relying on an unRAID specific version.

 

I do agree that going to a 1-step process that did not present the unRAID ones first would be a mistake.

Link to comment

Yet Another UpdateTM

 

Should hopefully be the last for a while (but on this my track record is extremely poor)

 

Fixed: Display Abnormality with Firefox

Enhanced: Better D/L count determination

Enhanced: Table Mode

Enhanced: Location of extra information display icons

Added: Option to display installed Apps within Available Apps

 

As an aside, I got a little retrospective with the question about CR a couple of posts back and started tearing through the ancient versions of the plugin.

 

What started out on Mar 22, 2015 as a concept of 500 lines (300 in bash, 200 in php), has now grown to almost 4000 (3200 php and 800 html/javascript) (Not including the coding for the appFeed)  And I still wonder why my wife gets annoyed when I'm in front of the computer 

Link to comment

Yet Another UpdateTM

 

Should hopefully be the last for a while (but on this my track record is extremely poor)

 

Fixed: Display Abnormality with Firefox

Enhanced: Better D/L count determination

Enhanced: Table Mode

Enhanced: Location of extra information display icons

Added: Option to display installed Apps within Available Apps

 

As an aside, I got a little retrospective with the question about CR a couple of posts back and started tearing through the ancient versions of the plugin.

 

What started out on Mar 22, 2015 as a concept of 500 lines (300 in bash, 200 in php), has now grown to almost 4000 (3200 php and 800 html/javascript) (Not including the coding for the appFeed)  And I still wonder why my wife gets annoyed when I'm in front of the computer

 

Your sacrifice is truly appreciated :)

Link to comment

Yet Another UpdateTM

 

Should hopefully be the last for a while (but on this my track record is extremely poor)

 

Fixed: Display Abnormality with Firefox

Enhanced: Better D/L count determination

Enhanced: Table Mode

Enhanced: Location of extra information display icons

Added: Option to display installed Apps within Available Apps

 

As an aside, I got a little retrospective with the question about CR a couple of posts back and started tearing through the ancient versions of the plugin.

 

What started out on Mar 22, 2015 as a concept of 500 lines (300 in bash, 200 in php), has now grown to almost 4000 (3200 php and 800 html/javascript) (Not including the coding for the appFeed)  And I still wonder why my wife gets annoyed when I'm in front of the computer

 

Your sacrifice is truly appreciated :)

And wouldn't you know that an hour after posting that, I started actually playing around with CA, and found a few small but annoying little bugs that have been kicking around for a bit.  Now just biding my time before releasing an update so that I don't look like a complete idiot.
Link to comment

Yet Another UpdateTM

 

Should hopefully be the last for a while (but on this my track record is extremely poor)

 

Fixed: Display Abnormality with Firefox

Enhanced: Better D/L count determination

Enhanced: Table Mode

Enhanced: Location of extra information display icons

Added: Option to display installed Apps within Available Apps

 

As an aside, I got a little retrospective with the question about CR a couple of posts back and started tearing through the ancient versions of the plugin.

 

What started out on Mar 22, 2015 as a concept of 500 lines (300 in bash, 200 in php), has now grown to almost 4000 (3200 php and 800 html/javascript) (Not including the coding for the appFeed)  And I still wonder why my wife gets annoyed when I'm in front of the computer

 

Your sacrifice is truly appreciated :)

And wouldn't you know that an hour after posting that, I started actually playing around with CA, and found a few small but annoying little bugs that have been kicking around for a bit.  Now just biding my time before releasing an update so that I don't look like a complete idiot.

The Neverending Story....  ::)  ;D

Link to comment

Yet Another UpdateTM

 

Should hopefully be the last for a while (but on this my track record is extremely poor)

 

Fixed: Display Abnormality with Firefox

Enhanced: Better D/L count determination

Enhanced: Table Mode

Enhanced: Location of extra information display icons

Added: Option to display installed Apps within Available Apps

 

As an aside, I got a little retrospective with the question about CR a couple of posts back and started tearing through the ancient versions of the plugin.

 

What started out on Mar 22, 2015 as a concept of 500 lines (300 in bash, 200 in php), has now grown to almost 4000 (3200 php and 800 html/javascript) (Not including the coding for the appFeed)  And I still wonder why my wife gets annoyed when I'm in front of the computer

 

Your sacrifice is truly appreciated :)

And wouldn't you know that an hour after posting that, I started actually playing around with CA, and found a few small but annoying little bugs that have been kicking around for a bit.  Now just biding my time before releasing an update so that I don't look like a complete idiot.

The Neverending Story....  ::)  ;D

I've tried other projects and they just don't have the same allure that CA has

Link to comment

Yet Another Yet Another UpdateTM

 

So that I can make some time to help out a buddy, releasing this a couple of days early

 

Fixed: Issue when going from dockerHub searches to installed / previously installed apps

Fixed: Disallow dockerHub searches if docker not enabled

Fixed: Disallow adding a previously installed docker app if docker not enabled

Removed: Legacy Code

Removed: dockerHub guess at Icons (api I was using seems to be broken, and the results at best were not the best.  System will still use an existing icon from the community supported apps if searching for the same name)

Fixed: Suppress an error message if error in template, and template was the only one in a repository

Fixed: Remove some extra temp files once they were no longer needed

Enhanced:  A back-to-the-top that doesn't look like it was from the 80's

 

Link to comment

Just updated to the latest version and I am receiving this error:

 

sh: /usr/local/emhttp/plugins/community.applications/scripts/stars.sh: No such file or directory

 

I also see it on the console.

Harmless message from when I removed the legacy code.  Obviously I missed a reference somewhere in the code.  Will get rid of it tonight

 

Link to comment

If anyone has any good ideas of what else to incorporate into CA, the floor is now open to the peanut gallery...

 

Well since you asked...  I've been thinking about something I think is important, part of the maturation of the unRAID community and its many development partners.  I brought it up first over here.  unRAID and the numerous addon options have come a long way, and it's time to think about risk management, not just for our data but also for the tools.  The community is growing, and depending more and more on so many plugins and containers.  Yet for the most part, these plugins and containers have a single author, and that's a single failure point.  Think of what would happen to so many users if something happened to PhAzE, binhex, bungy, etc, with so many plugins and containers and so many dependent users.  As we're all reminded now and then, life happens, and it rarely comes with advance notifications.  Businesses have to have disaster plans, for hurricanes, earthquakes, tornadoes, fires, etc, and so do we.  Rudimentary perhaps, but something that users can count on.  It's important that users be able to select tools with a known backup plan, a succession plan if something happens to the original author.

 

In a way, I'm an outsider in the addon development world here, so I don't want to say what should happen.  Perhaps as simple as a field in CA for 'Backup author/group'?  But I'm hoping this can get the ball rolling, and you Squid and the many authors can decide on a mechanism, that provides at least a minimum of a succession plan.  I know you have already worked out blacklisting processes, and that's good, but we really need a way to make sure important plugins and containers are carried on, not lost and blacklisted.  Once something is set up, then we can all nudge the authors to make sure they have someone they can get to cover for them, if the unexpected happens...  However, I can imagine some authors being resistant.  That's fine, it's their right.

 

What is a backup author?  Basically someone that is able and willing.  At a minimum, they need to be able to manage a repository, the original or their own; they need to be able to access the source, and make needed corrections; and they need to be able to package up an update.  More than that is gravy.

Link to comment

If anyone has any good ideas of what else to incorporate into CA, the floor is now open to the peanut gallery...

 

Well since you asked...  I've been thinking about something I think is important, part of the maturation of the unRAID community and its many development partners.  I brought it up first over here.  unRAID and the numerous addon options have come a long way, and it's time to think about risk management, not just for our data but also for the tools.  The community is growing, and depending more and more on so many plugins and containers.  Yet for the most part, these plugins and containers have a single author, and that's a single failure point.  Think of what would happen to so many users if something happened to PhAzE, binhex, bungy, etc, with so many plugins and containers and so many dependent users.  As we're all reminded now and then, life happens, and it rarely comes with advance notifications.  Businesses have to have disaster plans, for hurricanes, earthquakes, tornadoes, fires, etc, and so do we.  Rudimentary perhaps, but something that users can count on.  It's important that users be able to select tools with a known backup plan, a succession plan if something happens to the original author.

 

In a way, I'm an outsider in the addon development world here, so I don't want to say what should happen.  Perhaps as simple as a field in CA for 'Backup author/group'?  But I'm hoping this can get the ball rolling, and you Squid and the many authors can decide on a mechanism, that provides at least a minimum of a succession plan.  I know you have already worked out blacklisting processes, and that's good, but we really need a way to make sure important plugins and containers are carried on, not lost and blacklisted.  Once something is set up, then we can all nudge the authors to make sure they have someone they can get to cover for them, if the unexpected happens...  However, I can imagine some authors being resistant.  That's fine, it's their right.

 

What is a backup author?  Basically someone that is able and willing.  At a minimum, they need to be able to manage a repository, the original or their own; they need to be able to access the source, and make needed corrections; and they need to be able to package up an update.  More than that is gravy.

Two things. . .

 

Linuxserver is a team so all their containers have multiple devs

 

And docker containers are simple and streamlined enough that in a lot of cases you can just replace an existing one with a different author's version, point it to the same configuration folder and you're good to go. Many containers have multiple versions already. Plex has more than 3 well supported ones and I believe they are interchangeable

Link to comment

I'm wondering if github can help with this?  If I'm reading the help files correctly, someone could create an "unRAID collaborators" organization and invite people to join.  Each plugin or docker would have a "team" assigned to it, and only the team members would be able to commit to that project. 

 

Initially the teams might only have one person in them, but if that person isn't available, an administrator could add someone else to the team and the project could continue on.  We would also want to enforce a license policy on all code so there are no legal issues.

 

As long as we don't need private repositories, it looks like this would be free:

  https://github.com/pricing

Link to comment

If anyone has any good ideas of what else to incorporate into CA, the floor is now open to the peanut gallery...

 

Well since you asked...  I've been thinking about something I think is important, part of the maturation of the unRAID community and its many development partners.  I brought it up first over here.  unRAID and the numerous addon options have come a long way, and it's time to think about risk management, not just for our data but also for the tools.  The community is growing, and depending more and more on so many plugins and containers.  Yet for the most part, these plugins and containers have a single author, and that's a single failure point.  Think of what would happen to so many users if something happened to PhAzE, binhex, bungy, etc, with so many plugins and containers and so many dependent users.  As we're all reminded now and then, life happens, and it rarely comes with advance notifications.  Businesses have to have disaster plans, for hurricanes, earthquakes, tornadoes, fires, etc, and so do we.  Rudimentary perhaps, but something that users can count on.  It's important that users be able to select tools with a known backup plan, a succession plan if something happens to the original author.

 

In a way, I'm an outsider in the addon development world here, so I don't want to say what should happen.  Perhaps as simple as a field in CA for 'Backup author/group'?  But I'm hoping this can get the ball rolling, and you Squid and the many authors can decide on a mechanism, that provides at least a minimum of a succession plan.  I know you have already worked out blacklisting processes, and that's good, but we really need a way to make sure important plugins and containers are carried on, not lost and blacklisted.  Once something is set up, then we can all nudge the authors to make sure they have someone they can get to cover for them, if the unexpected happens...  However, I can imagine some authors being resistant.  That's fine, it's their right.

 

What is a backup author?  Basically someone that is able and willing.  At a minimum, they need to be able to manage a repository, the original or their own; they need to be able to access the source, and make needed corrections; and they need to be able to package up an update.  More than that is gravy.

Two things. . .

 

Linuxserver is a team so all their containers have multiple devs

 

And docker containers are simple and streamlined enough that in a lot of cases you can just replace an existing one with a different author's version, point it to the same configuration folder and you're good to go. Many containers have multiple versions already. Plex has more than 3 well supported ones and I believe they are interchangeable

 

I believe that the issue with this is more with plugins than Dockers.  As a start I would like to suggest we add a field to the app xml files concerning the author's license on their plugin.  If their license is GPL or an individual copyright.  If the source is not GPL licensed, there is a roadblock to anyone even willing to take over a project when the original author becomes unable or unwilling to support their plugin.  The original author might not be available to grant permission for a fork, or unwilling to do so and the plugin becomes unsupportable.

 

Those that want to install a particular plugin can see how it is licensed and decide to risk the loss of support if it is not GPL licensed.  The default for CA should be an individual license if the author does not specify.

 

As a developer that has taken over several plugins that were abandoned, I find the licensing more of an issue than my willingness to work on the abandoned plugin.  I have run into this situation more than once and the latest was with the UD plugin.  This was resolved amicably because the author was available to GPL his source and grant permission for my fork.

 

I think we would find those willing to take over if necessary but it might be difficult to pre-arrange a back up author.  I would not be opposed to a backup, but I believe it would be hard to find someone willing to commit.  I would be reluctant to commit myself as a backup.

Link to comment

I don't see having "backup plans", etc being very viable for numerous reasons (most of which have already been stated).  And in the eventuality of a similar situation to what happened with UD (copyright issues aside), I think the moderator comments / blacklist handled it ok.

 

(As an aside, CA does have a backup plan in place with regards to getting the lists of applications.  Should lsio ever up and close up shop (extremely unlikely) (they supply the hosting for the appFeed), CA automatically downgrades itself to a legacy mode and grabs the lists itself (far slower however)

 

Licensing:

 

If any / all of the template authors (plugin or docker) want to start adding to their templates

 

<License>what ever suits here</License>

 

then next week's update for CA will support it when displaying the full information on any particular app.  Completely 100% optional field to populate.  I however don't think that it should default to any particular value if not present, as its probably reasonable to conclude that what ever CA picks as a default will be wrong half the time.

 

 

Link to comment

I don't see having "backup plans", etc being very viable for numerous reasons (most of which have already been stated).  And in the eventuality of a similar situation to what happened with UD (copyright issues aside), I think the moderator comments / blacklist handled it ok.

 

(As an aside, CA does have a backup plan in place with regards to getting the lists of applications.  Should lsio ever up and close up shop (extremely unlikely) (they supply the hosting for the appFeed), CA automatically downgrades itself to a legacy mode and grabs the lists itself (far slower however)

 

Licensing:

 

If any / all of the template authors (plugin or docker) want to start adding to their templates

 

<License>what ever suits here</License>

 

then next week's update for CA will support it when displaying the full information on any particular app.  Completely 100% optional field to populate.  I however don't think that it should default to any particular value if not present, as its probably reasonable to conclude that what ever CA picks as a default will be wrong half the time.

 

I agree about the backup plan. Maybe a good idea but not practical.

 

I will add the license information to all my plugins.  I think that is a start.  As far as the default, that's fine.  Whatever you feel is best.

Link to comment

Two things. . .

 

Linuxserver is a team so all their containers have multiple devs

 

And docker containers are simple and streamlined enough that in a lot of cases you can just replace an existing one with a different author's version, point it to the same configuration folder and you're good to go. Many containers have multiple versions already. Plex has more than 3 well supported ones and I believe they are interchangeable

Both very good points.  Rather than repeat myself then, I just linked to my first post, but I probably should have quoted myself.

This brings up something I've been thinking about for awhile - the real need (a critical need in my opinion) for a stated succession plan or backup author for ALL plugins and Docker containers.  The backup person does not have to be as gifted, just capable and willing to carry on in a limited way at least, if something should happen to the original author.  Right now, the Linuxserver.io group have an important advantage over others, a built-in succession plan.  I find it worrying to consider what would happen if something happened to PhAzE or binhex or a few other authors, with the number of plugins and containers and so many users depending on them.  I hope they will consider finding someone they can assign, 'just in case'.  I hope that Squid will consider the possibility of adding another field for this, so that when users evaluate equivalent options, the one with a backup plan has a significant advantage.

 

I understand not every plugin or container needs a backup person or plan.  In some cases, you should be able to remove one container, load a similar one, and carry on with little change, and no loss.  But that's certainly not true in many cases, especially important plugins like this one [referring to Unassigned Devices].

 

Dan's points are quite valid, something I didn't think of.  Hopefully someone like Dan will step up again when this happens next.  We have to remember though that in this case he stepped up because this plugin was very important to him.  This problem isn't going away, and I suspect it will take time, but there are going to be more unfortunate situations, without easy resolutions.  After a bad loss, some users may become 'gun shy', and begin rightly or wrongly flocking more toward linuxserver.io options over binhex options (to give one example), without at least an informal statement up front that *someone* is willing to take over if needed.  Perhaps the most concerning are all the PhAzE plugins.  At the same time, I do recognize it's possible it may *never* become a serious problem.  Shutting up now, that's as far as I'll push on this.

Link to comment

Perhaps the most concerning are all the PhAzE plugins.

More than PhAzE, is all the dynamix.  But, there is no easy solution, and the situation is no different than if any particular organization or company or author for any piece of software for any platform closes up shop.
Link to comment

Getting the following error since the latest update under General Settings:

Warning: file_get_contents(/tmp/community.applications/tempFiles/Repositories.json): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 32 Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 34 Warning: natcasesort() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 38 Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 42

Is anyone else getting this, or is something off with my setup?

 

I agree about the backup plan. Maybe a good idea but not practical.

 

I will add the license information to all my plugins.  I think that is a start.  As far as the default, that's fine.  Whatever you feel is best.

 

Impeccable timing, I wanted to add a feature to your recycle.bin plugin to modify the default ".Recycle.Bin" path, so I forked it and am currently in the process of (possibly) adding a bunch more features I've thought up ;D,

Link to comment

Getting the following error since the latest update under General Settings:

Warning: file_get_contents(/tmp/community.applications/tempFiles/Repositories.json): failed to open stream: No such file or directory in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 32 Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 34 Warning: natcasesort() expects parameter 1 to be array, null given in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 38 Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/dynamix/include/DefaultPageLayout.php(292) : eval()'d code on line 42

Is anyone else getting this, or is something off with my setup?

 

I agree about the backup plan. Maybe a good idea but not practical.

 

I will add the license information to all my plugins.  I think that is a start.  As far as the default, that's fine.  Whatever you feel is best.

 

Impeccable timing, I wanted to add a feature to your recycle.bin plugin to modify the default ".Recycle.Bin" path, so I forked it and am currently in the process of (possibly) adding a bunch more features I've thought up ;D,

Its because you loaded the general settings before you went into the apps section after a reboot.  (Which is perfectly valid)  There's just a directory being referenced that doesn't exist under that circumstance. 

 

Hard for me to hit every possibility of usage.  Already fixed and will pump out the update this weekend sometime after I finish up with QC on my other update.

Link to comment

Leaner, Meaner, Greener (and hopefully not buggier)

 

- Big code clean up.

- Don't display stars from dockerHub if app not starred

- Hide search dockerHub if in previous / installed apps

- Fix error in settings if a temp directory didn't exist

- Add support for <Licence> in xml files

Link to comment

Leaner, Meaner, Greener (and hopefully not buggier)

 

- Big code clean up.

- Don't display stars from dockerHub if app not starred

- Hide search dockerHub if in previous / installed apps

- Fix error in settings if a temp directory didn't exist

- Add support for <Licence> in xml files

 

Is it License or Licence?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.