April 29, 201511 yr don't know whether this would be useful or not, but i was thinking that there could me be some kind of password type tag that gets it's entered contents obscured in dockerman. Not that I have any say on this, but for what purpose? if a container requires a password for email or database or anything else that requires a password to be passed as a variable. I think the question is, for what purpose should it be obscured?
April 29, 201511 yr don't know whether this would be useful or not, but i was thinking that there could me be some kind of password type tag that gets it's entered contents obscured in dockerman. Not that I have any say on this, but for what purpose? if a container requires a password for email or database or anything else that requires a password to be passed as a variable. I think the question is, for what purpose should it be obscured? prying eyes, lol
May 3, 201511 yr Author Updated to 2015.05.03 This update includes a feature for adding in display support for so-called "private" repositories. Note that probably 99.9% of users will not utilitize this feature, but it adds in the only remaining item that the repositories tab could do that this plug-in couldn't. Some users / developers may have "private" repositories that they have which are not generally available to the unRaid community at large. Previously, this plugin could not display the contents or manage the containers of them. Now, they will appear just like any other repository. To add a private repository, create a file called private.repositories.json in the /boot/config/plugins/community.repositories folder The contents will be something like: [ { "name": "Squid's private repository", "url": "the full URL to the repository" }, { "name": "Squid's Test Repository", "url": "the full URL to the test repository" } ] Optionally, you can also add a "forum": entry to each repository to display a support link for containers which do not have the <Support> tag present. Currently, there is no error checking on the formatting of the json file (and probably never will be due to the limited number of users which will take advantage of this feature). Any errors in formatting will result in errors being displayed by the plugin.
May 3, 201511 yr Updated to 2015.05.03 This update includes a feature for adding in display support for so-called "private" repositories. Note that probably 99.9% of users will not utilitize this feature, but it adds in the only remaining item that the repositories tab could do that this plug-in couldn't. Some users / developers may have "private" repositories that they have which are not generally available to the unRaid community at large. Previously, this plugin could not display the contents or manage the containers of them. Now, they will appear just like any other repository. To add a private repository, create a file called private.repositories.json in the /boot/config/plugins/community.repositories folder The contents will be something like: [ { "name": "Squid's private repository", "url": "the full URL to the repository" }, { "name": "Squid's Test Repository", "url": "the full URL to the test repository" } ] Optionally, you can also add a "forum": entry to each repository to display a support link for containers which do not have the <Support> tag present. Currently, there is no error checking on the formatting of the json file (and probably never will be due to the limited number of users which will take advantage of this feature). Any errors in formatting will result in errors being displayed by the plugin. i can finally get top of the list......
May 3, 201511 yr Updated to 2015.05.03 This update includes a feature for adding in display support for so-called "private" repositories. Note that probably 99.9% of users will not utilitize this feature, but it adds in the only remaining item that the repositories tab could do that this plug-in couldn't. Some users / developers may have "private" repositories that they have which are not generally available to the unRaid community at large. Previously, this plugin could not display the contents or manage the containers of them. Now, they will appear just like any other repository. To add a private repository, create a file called private.repositories.json in the /boot/config/plugins/community.repositories folder The contents will be something like: [ { "name": "Squid's private repository", "url": "the full URL to the repository" }, { "name": "Squid's Test Repository", "url": "the full URL to the test repository" } ] Optionally, you can also add a "forum": entry to each repository to display a support link for containers which do not have the <Support> tag present. Currently, there is no error checking on the formatting of the json file (and probably never will be due to the limited number of users which will take advantage of this feature). Any errors in formatting will result in errors being displayed by the plugin. i can finally get top of the list...... ^^ first steps to world domination, lol.
May 3, 201511 yr Just updated this and got: Verifying package community.repositories-2015.05.03.txz. expr: syntax error /sbin/installpkg: line 432: [: -lt: unary operator expected /sbin/installpkg: line 434: [: -lt: unary operator expected expr: syntax error /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 469: echo: write error: No space left on device cat: write error: No space left on device Installing package community.repositories-2015.05.03.txz: PACKAGE DESCRIPTION: /sbin/installpkg: line 537: echo: write error: No space left on device /sbin/installpkg: line 538: echo: write error: No space left on device /sbin/installpkg: line 539: echo: write error: No space left on device /sbin/installpkg: line 540: echo: write error: No space left on device /sbin/installpkg: line 545: echo: write error: No space left on device /sbin/installpkg: line 550: echo: write error: No space left on device WARNING: Package has not been created with 'makepkg' /sbin/installpkg: line 559: echo: write error: No space left on device Package community.repositories-2015.05.03.txz installed. Over 7G free on flash Myk
May 3, 201511 yr Just updated this and got: Verifying package community.repositories-2015.05.03.txz. expr: syntax error /sbin/installpkg: line 432: [: -lt: unary operator expected /sbin/installpkg: line 434: [: -lt: unary operator expected expr: syntax error /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 469: echo: write error: No space left on device cat: write error: No space left on device Installing package community.repositories-2015.05.03.txz: PACKAGE DESCRIPTION: /sbin/installpkg: line 537: echo: write error: No space left on device /sbin/installpkg: line 538: echo: write error: No space left on device /sbin/installpkg: line 539: echo: write error: No space left on device /sbin/installpkg: line 540: echo: write error: No space left on device /sbin/installpkg: line 545: echo: write error: No space left on device /sbin/installpkg: line 550: echo: write error: No space left on device WARNING: Package has not been created with 'makepkg' /sbin/installpkg: line 559: echo: write error: No space left on device Package community.repositories-2015.05.03.txz installed. Over 7G free on flash Myk try this from a prompt. cd /var/log du -h
May 3, 201511 yr Just updated this and got: Verifying package community.repositories-2015.05.03.txz. expr: syntax error /sbin/installpkg: line 432: [: -lt: unary operator expected /sbin/installpkg: line 434: [: -lt: unary operator expected expr: syntax error /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 469: echo: write error: No space left on device cat: write error: No space left on device Installing package community.repositories-2015.05.03.txz: PACKAGE DESCRIPTION: /sbin/installpkg: line 537: echo: write error: No space left on device /sbin/installpkg: line 538: echo: write error: No space left on device /sbin/installpkg: line 539: echo: write error: No space left on device /sbin/installpkg: line 540: echo: write error: No space left on device /sbin/installpkg: line 545: echo: write error: No space left on device /sbin/installpkg: line 550: echo: write error: No space left on device WARNING: Package has not been created with 'makepkg' /sbin/installpkg: line 559: echo: write error: No space left on device Package community.repositories-2015.05.03.txz installed. Over 7G free on flash Myk This isn't related to the flash but to your tmpfs, and likely it is full. Check wih the command df -h /var/log It is possible to increase the size of the file system on the fly, provided that you have enough RAM memory. Use this command for example to double to size from default 128M to 256M. mount -o remount,size=256m /var/log
May 3, 201511 yr Author Just updated this and got: Verifying package community.repositories-2015.05.03.txz. expr: syntax error /sbin/installpkg: line 432: [: -lt: unary operator expected /sbin/installpkg: line 434: [: -lt: unary operator expected expr: syntax error /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 466: echo: write error: No space left on device /sbin/installpkg: line 469: echo: write error: No space left on device cat: write error: No space left on device Installing package community.repositories-2015.05.03.txz: PACKAGE DESCRIPTION: /sbin/installpkg: line 537: echo: write error: No space left on device /sbin/installpkg: line 538: echo: write error: No space left on device /sbin/installpkg: line 539: echo: write error: No space left on device /sbin/installpkg: line 540: echo: write error: No space left on device /sbin/installpkg: line 545: echo: write error: No space left on device /sbin/installpkg: line 550: echo: write error: No space left on device WARNING: Package has not been created with 'makepkg' /sbin/installpkg: line 559: echo: write error: No space left on device Package community.repositories-2015.05.03.txz installed. Over 7G free on flash Myk This isn't related to the flash but to your tmpfs, and likely it is full. Check wih the command df -h /var/log It is possible to increase the size of the file system on the fly, provided that you have enough RAM memory. Use this command for example to double to size from default 128M to 256M. mount -o remount,size=256m /var/log I also recall seeing something about the logging for libvirt being too verbose because of a typo that was the root cause of this (6.0b14b). Don't recall if this got fixed in 15.
May 9, 201511 yr Author Updated to 2015.05.09 Running / installed (but not running) containers will now have a wrench next to their icons. Previously, clicking the container would load the defaults for the container on the add/container page. Now, the container is edited. Also, the add/edit a container no longer opens a separate tab.
May 10, 201511 yr just spent the last hour wrestling apache configs, now i remember why i used to hate doing that stuff. lol. making pydio ssl.
May 10, 201511 yr Author just spent the last hour wrestling apache configs, now i remember why i used to hate doing that stuff. lol. making pydio ssl. And soon I'm going to be asking you to update all of your containers again. (I hear a tiny violin playing somewhere)
May 10, 201511 yr just spent the last hour wrestling apache configs, now i remember why i used to hate doing that stuff. lol. making pydio ssl. And soon I'm going to be asking you to update all of your containers again. (I hear a tiny violin playing somewhere) you can ask............ that's no guarantee i'll do it, lol. ( i probably will though, seeing as i'm the idiot that asked for categories in the first place )
May 10, 201511 yr I'm going to throw an idea out, and you are welcome to shoot it down! There are a lot of containers, more every day, and a little duplication of service among them. I think that's great, as it looks like a friendly competition sometimes here, with new ideas flying around, and each new Docker container trying to be the best. This is obviously tremendous for us, the users! But it creates a bit of a problem for a new user, what to pick, which one is best, and why, etc. Although it IS an option we could take, I don't think we need a rating system, eg. polling for one to five stars for containers. But it WOULD be useful to know what's working for other users, what the majority of users end up using. The Community Repositories plugin just happens to be the one tool that might be in a position to know what users are using. If it created its own UID at each plugin installation, then whenever it 'calls home' to update the lists, it could report that UID and the containers installed. From the aggregate of the reports, the Repo home could add the current total installation count to each container listing. The UID of course would be randomly generated, and contain no personally identifiable info, to head off any concerns about 'tracking', etc, with a promise from Squid there won't be any unusual usage. Obviously, this depends mainly on whether Squid wants to do it, and it depends on whether the community agrees to a little aggregate data collection. It does seem useful to me though. There's other ways to go about this, but it would be nice to know what I can recommend to new users. This whole idea came from wishing I could add a recommendation to the upgrade guide for a well-tested, widely used, well featured graphical file manager, much better than MC. There isn't one yet, but it looks like Dolphin and Krusader are in the running currently, just need feature and installation and help completion, and lots of testing, has to be bullet-proof.
May 10, 201511 yr I'm going to throw an idea out, and you are welcome to shoot it down! There are a lot of containers, more every day, and a little duplication of service among them. I think that's great, as it looks like a friendly competition sometimes here, with new ideas flying around, and each new Docker container trying to be the best. This is obviously tremendous for us, the users! But it creates a bit of a problem for a new user, what to pick, which one is best, and why, etc. Although it IS an option we could take, I don't think we need a rating system, eg. polling for one to five stars for containers. But it WOULD be useful to know what's working for other users, what the majority of users end up using. The Community Repositories plugin just happens to be the one tool that might be in a position to know what users are using. If it created its own UID at each plugin installation, then whenever it 'calls home' to update the lists, it could report that UID and the containers installed. From the aggregate of the reports, the Repo home could add the current total installation count to each container listing. The UID of course would be randomly generated, and contain no personally identifiable info, to head off any concerns about 'tracking', etc, with a promise from Squid there won't be any unusual usage. Obviously, this depends mainly on whether Squid wants to do it, and it depends on whether the community agrees to a little aggregate data collection. It does seem useful to me though. There's other ways to go about this, but it would be nice to know what I can recommend to new users. This whole idea came from wishing I could add a recommendation to the upgrade guide for a well-tested, widely used, well featured graphical file manager, much better than MC. There isn't one yet, but it looks like Dolphin and Krusader are in the running currently, just need feature and installation and help completion, and lots of testing, has to be bullet-proof. "best" is at best subjective, popularity can be a good measure of something's value to the community but doesn't neccesarily mean it's going to fit every user. choice can only be good, but i do agree that it can be overwhelming.
May 10, 201511 yr perhaps a different approach to your idea of rating would be a more opt in idea than a blind polling of usage, you alluded to it somewhere in your post.
May 10, 201511 yr Author I'm going to throw an idea out, and you are welcome to shoot it down! There are a lot of containers, more every day, and a little duplication of service among them. I think that's great, as it looks like a friendly competition sometimes here, with new ideas flying around, and each new Docker container trying to be the best. This is obviously tremendous for us, the users! But it creates a bit of a problem for a new user, what to pick, which one is best, and why, etc. Although it IS an option we could take, I don't think we need a rating system, eg. polling for one to five stars for containers. But it WOULD be useful to know what's working for other users, what the majority of users end up using. The Community Repositories plugin just happens to be the one tool that might be in a position to know what users are using. If it created its own UID at each plugin installation, then whenever it 'calls home' to update the lists, it could report that UID and the containers installed. From the aggregate of the reports, the Repo home could add the current total installation count to each container listing. The UID of course would be randomly generated, and contain no personally identifiable info, to head off any concerns about 'tracking', etc, with a promise from Squid there won't be any unusual usage. Obviously, this depends mainly on whether Squid wants to do it, and it depends on whether the community agrees to a little aggregate data collection. It does seem useful to me though. There's other ways to go about this, but it would be nice to know what I can recommend to new users. This whole idea came from wishing I could add a recommendation to the upgrade guide for a well-tested, widely used, well featured graphical file manager, much better than MC. There isn't one yet, but it looks like Dolphin and Krusader are in the running currently, just need feature and installation and help completion, and lots of testing, has to be bullet-proof. I'm not going to shoot any idea down just yet without fully thinking through all of the pros and cons of it. But, some sort of rating system (or total downloads) is something that I have up on my whiteboard as an idea for the future. But, there's definitely other items also on that board which are going to come before that. And, as Sparkly has already stated "best" is entirely subjective.
May 10, 201511 yr I'm not going to shoot any idea down I think this is one of the things that makes this a good community, is the openmindness to different approaches amongst the userbase.
May 10, 201511 yr pure silliness now, hee hee. perhaps the rating system could be some shiny orbs of some kind ? they could have a catchy name like glittery spheres or something similar
May 10, 201511 yr Author pure silliness now, hee hee. perhaps the rating system could be some shiny orbs of some kind ? they could have a catchy name like glittery spheres or something similar http://en.wikipedia.org/wiki/Megalomania
May 10, 201511 yr pure silliness now, hee hee. perhaps the rating system could be some shiny orbs of some kind ? they could have a catchy name like glittery spheres or something similar http://en.wikipedia.org/wiki/Megalomania i prefer the term NPD , sounds more important, lol.
May 10, 201511 yr Author I need everyone's input (most specifically repository maintainers) on the use of categories for containers. Discussion over here: http://lime-technology.com/forum/index.php?topic=39843.0
May 16, 201511 yr Hi Squid, I see that the latest update allows editing of the existing container's xml when clicking on the template repo container icon. Well, one issue I'm observing is that when the dev makes a change to the template xml, like add a new variable, the only way it shows up is if the user removes the container and reinstalls? Before, an update would also update the xml and add the variables. I updated my rdp-calibre container and added self updating through an EDGE variable. I also added Height and Width variables for the rdp resolution. None of them show up unless I remove and reinstall. What is the best way for the dev to go about updating the xml? Thanks
May 16, 201511 yr Author Hi Squid, I see that the latest update allows editing of the existing container's xml when clicking on the template repo container icon. Well, one issue I'm observing is that when the dev makes a change to the template xml, like add a new variable, the only way it shows up is if the user removes the container and reinstalls? Before, an update would also update the xml and add the variables. I updated my rdp-calibre container and added self updating through an EDGE variable. I also added Height and Width variables for the rdp resolution. None of them show up unless I remove and reinstall. What is the best way for the dev to go about updating the xml? Thanks Oh. That's an unintended consequence of a change we made in the last update. Previously clicking on a container that was already running would load the defaults and force the user to reenter them. Since I figured that this necessarily wasn't a good thing we changed running containers to instead edit their existing values. I didn't anticipate your use case. I will address this and push out and update to allow you to do either. (Probably tomorrow)
Archived
This topic is now archived and is closed to further replies.