Squid

I suspect you're not going to get a massive queue of people for that task.. It was a nudge to two people in particular. They'll know who they are... Personally, I don't expect it to happen

Went through all the thought processes on this, and its going to wind up on the back burner for a bit. The issue is that #1 - Sure, Plex would only show up once in CA. Clicking on it would then bring up the list of all the different Plex's to let the user choose. Now we've just made the user do an extra click for no real fundamental reason. They are still going to have to choose from which Plex to install. While it would clean up the display a hair, the confusion for the user still exists. Which one to use. #2 - It looks like previous to August 6, you could get the number of downloads for a container for docker.cloudbrain.io However since August 6, I don't believe that is working anymore, as every query I try keeps telling me that it can't find the container. (As part of the reorganization of dockerHub, the urls of the containers switched from ...../u/reponame/containername to .../r/reponame/containername. No idea if/when cloudbrain will fix this issue. So # of trackings on downloads is out as a metric. (Not particularily useful anyways since it would assign greater weight to the older containers vs the new ones) So that now brings us down to two other options. DockerHub's star ratings. Easy to implement. (And in hindsight should have been included with CA since the get-go) Will be on the next release of CA. After that release, I will further look into whether the star ratings are useful enough to use to differentiate containers, and may implement only displaying Plex once at that time. The absolute ideal solution would be someone (read that as "not me") setting up a SQL server on their public webserver so that a user generated feedback / ratings system could be introduced.

Yup. Who do I have to thank for that one?

Good summary of why I started Community Repositories / Applications in the first place. One of my biggest problems in every post of mine here is referring to everything as an application not a container. I'm forever typing container and then having to correct myself...

Small price to pay to rule the world.... My quick and dirty experiment with filling out of the host paths proved that schema changes were required to do it correctly. I'm sure that LT / gfjardim will post the official changes once they are finalized so that authors can get a head start on the modifications. Even seeing a quick peek at the changes, I haven't yet updated CA to pass them through to dockerMan until something is announced.

Already saw the tentative changes to the templates (when the test templates caused havoc with the appfeed, which Kode then had to account for). Put two and two together and figured out the rest. I was impressed and think that it will be a huge boon for unRaid as a whole, and a welcome relief for everyone using containers that continually has those same problems.

As long as the OT banter doesn't have to stop Saves me from continually talking to myself in here. Sorry about that. All because I'm not quite done yet on this... And this is why I'm never quite done Always another good idea. I have a thought of how to accomplish this without imposing another schema change upon the authors, at least initially. (And maybe my thought will work well enough that it won't be necessary either) The original version of the appFeed actually had total downloads included in it per container. So it was at least possible (Not sure if it still is since the revamp of dockerHub however - Kode would know). But, personally I'm not a big fan of total downloads as a rating system as it would unfairly rate the older containers higher than the newer ones (ie: needo's / binhex's plex would blow away linuxserver's / LT's out of the water, and for all I know linuxserver / LT has the better implementation). Couple of threads buried within Docker Categorize, Community Repositories about this topic) My personal preference is for a rating system of sorts, but open to suggestions on everything. Either way, give me a week and I'll get the situation with Plex, CP, Sab, etc sorted out.

Strange. Because of the new help file included I did both updates and new installs on 6.0.1 and 6.1 rc5 and never saw anything amiss. Glad you got it going though

Edit the script with Notepad++ Replace all occurrances of /root/mdcmd with /usr/local/sbin/mdcmd

Updated to 2015.08.20 Primarily a maintenance update. Many coding improvements, minor bug fixes (that nobody noticed yet ), better popup "searching / updating graphics when using 6.1 RC 4+) unRaid template applications now show up as "Recommended Applications" to encourage their use over dockerHub applications Better search results on icons when searching dockerHub... (But, depending upon what you were searching for before, you may have to restart your server to clear the icon cache to display the better icons) Added ability with the recommended applications to search for other applications from the same author (unification of the UI between templates and dockerHub) Completely removed the help lines within the main plugin. Before anyone jumps down my throat, since just about everything is clickable or does something, and I am a fan of context aware help files, the addition of dockerHub search results made the displays / coding a nightmare. So instead of the inline help lines, pressing help within the plugin will display a link to a full manual for the plugin. This allows me far more flexibility with the help (and tbh its actually something that I'm surprised that LT doesn't include within unRaid proper)

+1. A lot easier than what RobJ volunteered me for Yeah, sorry! But it's a good idea, although not particularly brilliant or even that new! It could help with container management for the future. Maybe when you have an itch to program, and nothing better to do, you might think about a deprecation process. But yes, I guess I am creating work for others! * It would allow container authors to not feel trapped by first version design limitations. They can redesign it the way they want, using everything they have learned since the first version. * It would help in the situation where there are multiple containers for the same application. One or more of the authors could decide to discontinue theirs and mark it as 'Deprecated in favor of ___'. * It would help where containers appear to be abandoned. If let's say no one is able to contact anyone responsible for container X for a month, and it has serious shortcomings, and there is a suitable replacement, then several container authors could vote to 'Deprecate in favor of _Y_'. Actually i am beginning to run out of ideas for CA. Not quite but getting to the end of my list. I'm sure my wife will thank you however - she already complains about the amount of time i spend on the "store" But, dockerMan already supports something like that (just not pretty) it automatically appends :latest as a tag to the repository it pulls. No idea how much work is involved for authors to support different versions but if a version is appended to the repository when you add the container, dockerMan will grab that version instead of latest

+1. A lot easier than what RobJ volunteered me for

Appfeed fixed... BTsync and Crashplan available again... Thanks Kode

I have some thoughts on the icon issue. But ultimately, no automated search is ever going to be 100% correct. I think I did pretty good getting a single search term to get ~80% accuracy for relevant icons. If you don't like the feature, turn it off. Support issues, sure that will be an issue. Ultimately why you have to opt-in for this feature, and why search results are always the templates first. But, once again I do have some thoughts on having the plugin "encourage" people to use templates. But, the net result is that this does fulfill a need, and ultimately I would think that this is no different than say Kitematic.

TLDR - Enable docker search within settings and have fun Before I get down to the details of today's CA update, as an FYI there are some changes coming to dockerMan. gfjardim has been adding some extra information to a few of his containers (namely BTSync and Crashplan). Unfortunately, those changes are at the moment incompatible with Kode's application feed. I'm sure that a fix will shortly be made however in the meantime, those two applications are unavailable within CA if you are using the application feed. If you want to install those applications, all you have to do is press the Update Applications button (which temporarily forces CA back to template mode), and they will be available. And now the fun stuff: Updated to 2015.08.15 A couple of minor bug fixes, and now fully compliant with unRaid's new emphasis on security and arbitrary code execution. The big change however, is a full GUI for searching and adding containers which do not have an unRaid template created. http://i46.photobucket.com/albums/f109/squidaz/Untitled_zps26aepdhw.png[/img] As I would consider this to be an advanced feature, the default is for this feature to be disabled. In the settings for CA, you will find two new options: Enable additional search results from dockerHub and Guess at icons for docker containers (more on this later) With the additional search results enabled, you will have a couple of powerful options to find and convert any container to be easily loaded to your server. #1 - Any search for an application will display the usual search results from the repository author's. An additional button will appear that will then display the search results from dockerHub. #2 - On any display of applications with templates (ie: categorized), clicking on the name of the application will perform a dockerHub search for that name #3 - On any dockerHub search, clicking the author's name will do a search on the author's name - IE: bring up all containers he has written. #4 - On any dockerHub search, clicking the name of the container will do a search on the container - IE: bring up all similar containers. #5 - Clicking on a container's icon will bring up the website from dockerHub for that container. (This is also used as the <Support> entry for the container. #6 - When adding a new container, a new repository called "DockerHub Repository" will be automatically created and the container added into it so that the plugin can manage the container at a later time (ie: restore to default, edit it, etc) #7 - At any time when displaying dockerHub search results, you can press Search Templates to search the unRaid templates for the currently displayed search term. Icons for containers When enabling this option in settings, the plugin will attempt to figure out an appropriate icon for the container. I actually spent about 8 hours trying to come up with an appropriate google search term that's fairly accurate. I figure that right now about 80% of the time it comes up with an icon that's relevant. Most of the time spent in gathering the search results together is actually spent doing the searches for the icons. Because of this, the plugin will cache the search results (not the icons, but only the results). What this means is that the more you search, the faster the plugin will become. Results The docker API as far as I can tell limits you to 25 results at a time. Because some of the search terms can come up with an insane number of results (mySql for example has 1744 results), everything is organized into pages of 25 results. If there is an "official" container for the search term, it will always be displayed on page #1 (and be tagged as an official container). Because of the limit on 25 results at a time, the sorting options are no longer available (pointless since all of the containers are not available to be sorted) - (As an aside, early on in development, I was displaying all of the possible results... It took this plugin around 20 minutes to catalog and render the results for mySql - The plugin actually only took about 5 minutes to gather the results and the icons. It took Chrome around 15 minutes to churn through all of the table entries, etc before it even displayed the results) Conversion Process Automated, non-Automated, and Official builds are all supported. With automated builds (the vast majority of containers on dockerHub), the plugin scrapes the webpage for the dockerfile. This file has the details on the container itself. Namely, the ports and the volumes exposed. These entries will be added to the template created. However, there is no rule in creating dockerfiles that states that the ports and the volumes MUST be exposed. In other words, if the port / volume is not explicitly exposed in the docker file, then it will not show up within the template. Luckily, the majority of automated builds do expose the ports and volumes correctly. With Official and non-Automated builds, there is no dockerfile to scrape. The templates created by this plugin for those types of containers will be basically just enough for dockerMan to actually download the container. Regardless of the type of container being converted, it is highly recommended to read the full description of the container (press it's icon) so that you are aware of what ports / volumes / environment variables (which cannot be scraped at all) need to be set within the container. Template Assumptions A few assumptions are made by the conversion process which cannot be determined at all from the dockerfile. Namely: Network type is set to Bridge, Privileged is disabled, Bind time is enabled. WebUI If there is only a single port exposed, CA will assume that the port is the WebUI port. If there are multiple ports exposed, any port beginning with "8" will be assumed to be the WebUI port. These assumptions may not be accurate, and once again you should read the directions on the container's dockerHub page. Popups The docker conversion process (or more to the point, the passing of the created template to dockerMan to add the container) requires popups to be enabled within your browser. However even with popups disabled, the process still works. The container will be available within the DockerHub repository (uncategorized), and will be available to be added by selecting it from there (you will have to either Update Applications or exit and enter the docker tab for it to be displayed. Popups are NOT required to be enabled once a container has been converted, nor to add an unRaid (categorized) template. Also, this thread has a big tendency to go OT all the time. While this doesn't bother me in the least, (and I rather do enjoy that fact about it), I am very curious as to everyone's thoughts on this update. There still are a couple of rough edges in the UI to smooth out but hopefully there are no bugs contained within the plugin itself.

Only thing I'd say is to add the URL for the container to the doc.. This was the biggest missing piece from your doc as far as I was concerned.. Thanks for doing that for everyone! -Steve All the correct URL's for every repository is listed here: http://lime-technology.com/forum/index.php?topic=37958.0

lol. Why is it that of all the threads on the forums here, mine is the only one where ~80% of the posts are OT? Not that I mind (I actually find it refreshing), but just curious as to why its only mine... Also thought about it and added back in RC-2 compatibility.

We keep them

Think that would annoy my pets though.. http://www.wallpapersonview.com/wallpapers/4/animals_wild_bear_polar_checking_igloo_background_picture-4.jpg[/img]

Ah now its confirmed... CHBMB and Sparklyballs are the only two users of this plugin... Guess I can stop development now....

Updated to 2015.08.12 Hot fix for 6.1 RC-3 Note: Certain aspects of this plugin are now no longer compatible with 6.1RC-2 (6.0, 6.01, 6.1RC-1, and 6.1RC-3 are fully compatible). This is namely the popup descriptions, changelogs, and credits. Everything else is still compatible. 6.1RC-2 was a bit of an aberration in that some of the dynamix routines that I utilize no longer allowed code execution from my scripts folder. Instead they had to be situation within a system folder (/usr/sbin). 6.1RC-3 has removed that restriction. Due to the rather extensive testing required to support to test this plugin with the latest stable releases (namely 6.01) and all of the release candidates (not to mention the actual code to adjust the plugin's operation to the version of unRaid being used), going forward I am only going to test and fix errors on this plugin for the latest stable version and the latest release candidates / beta versions. I don't think that this is going to be a big deal, as I don't think that Tom is going to be making anymore adjustments to code execution that will be affecting me. Unless of course someone can give me a good reason as to why I should support RC-2. Just some history here: 6.1RC-1 - Reorganized some of the underlying docker files that I rely upon for a dependency. Update required. 6.1RC-2 - Was the beginning of the security enhancements for the unRaid UI to prevent arbitrary code execution. Because of the restrictions placed upon where certain dynamix functions could execute from, an update was required. 6.1RC-3 - Relaxed the security restrictions for certain dynamix functions such that it was easier for plugins to operate. Because the method used to have this plugin operate under 6.1RC-2 now violates best practice (rightfully so), today's update is required. (As an aside, today's update basically undoes the changes I was required to make in RC-2) EDIT: Thought about it, and added back in RC-2 Compatibility

Your group has helped me out just as much or more. Thanks guys...

Updated to 2015.08.09 - Hotfix for malformed templates - Removed requirement for popups to be enabled when in appFeed mode - Removed dockerSearch and Convert due to changes on docker Hub's website. A replacement full GUI is currently in progress

If you are using those IP addresses which are in my file, that might be the issue. They are the DNS servers for my local ISP provider (Time-Warner), You might try using the Google DNS service which provides world wide service. They are 8.8.8.8 and 8.8.4.4 BTW, most people have good luck with using getting the DNS servers automatically setting. Perhaps, you should try that first. I've definitely got the DNS information setup correctly. I'm absolutely sure of that now. I've attached another Diagnostics check since fixing the DNS... maybe that will help more now. It doesn't make sense, I seem to be the only person having this specific problem I've looked through a lot of this thread and no one else seems to be having any similar problem... what the? Should I try restarting the server... I don't expect that to work though. I believe that under certain circumstances, the dynamix plugin manager will cache a bad downloaded file, and regardless of what it actually says on the screen, it does not attempt to download it again. A reboot certainly can't hurt.

sensors-detect comes with unRAID, it is a perl script and you need to install perl to run it. after seeing dozens of posts about needing to install perl; why doesn't limetech just put it back into unRAID? What is the benefit of not having it vs. the countless problems its removal has created? Because unRaid itself doesn't require it. A plugin requires it. http://lime-technology.com/forum/index.php?topic=39506.0