July 7, 201015 yr Fork from unRAID 5.0 http://lime-technology.com/forum/index.php?topic=6872.0 This discussion is for the topic of unRAID Plugin management. Suggestions about management the collection of cool plugins/addons. How to consolidate ways of finding and working as a collective community. Discuss.
July 7, 201015 yr Author Some of the plugins are using Google Code. A quick search brought up. http://code.google.com/p/unraid-unmenu/ http://code.google.com/p/unraid-powercontrol/ http://code.google.com/p/untorrent/ http://code.google.com/p/unmenu-bsm/ http://code.google.com/p/gfjardim/ There have been suggestions for this to also be incorporated into a limtech sponsored bug tracking/feature tracking environment. There have been suggestions as to either consolidating all plugins to be managed from one google code location. Or use a jump page on the Wiki or Google Code. Discuss.
July 7, 201015 yr How about a centralized repository-type system (ala apt, yum, portage, etc) that would allow plugins to be installed/updated rather easily either from the CLI or from the new WebGui. For ease-of-use, this would probably be the best type of system and allow plugins to be quickly added or removed on demand.
July 8, 201015 yr Author That's a good idea, Where would the repository be? Who will manage it? I think we could also accomplish that with google code areas, wget, a centralized config file and using the slackware package methodology. I've dealt with yum, rpms, and apt-get/.deb packages. I'm familiar with making rpms and slackware packages. I'm not familiar with creating .deb packages. Making slackware packages is pretty straightforward.
July 8, 201015 yr All of this could be discussed. I think the most important thing for the plugin management is that whatever is used is officially sanctioned by Tom. He doesn't have to take care of it, but it has to be clear that when someone inquires about plugins/addons, they get directed to one, and only one, place. This will create a cohesion within the community. You're right though, a set of scripts could be devised using wget and slackware package manager.. essentially checking the "official" repository, install/uninstall plugins, update plugins and keep a running tally of all installed plugins. Management could be done by a few people to make sure there's always someone available in case issues occur, torches could be passed if those people are no longer interested, etc.
July 8, 201015 yr I really like the NMT community add-in system. What I see for unRAID is: Master Config - A centralized config file, that in its simplest form, is one line per application and description, with the application name, and a link to the application-specific config file. The add-in management retrieves this file, in order to know how to retrieve any particular add-in. Theoretically, this can even be done with a parseable wiki entry. This has to be maintained by the community, or a group of admins. Eventually, a web interface could be done so a developer can add, edit, and delete his own app's entry in the master config without being able to hose other developers' entries. It would be real easy to implement something like this in php, and use a flat-file backend. Application-specific config - An ini-type file or xml with defined sections and information about the version, author, name, description, as well as how to install it. Each developer maintains the application-specific config file for each application, on whatever host he wants. Application Package - this can be a Slackware package or whatever convenient form make sense.... since the install script will be in the Application-specific config file. The Add-in manager It 1) reads the master config, 2) reads your local system to determine what is already installed, 3) checks and recommends updates to installed programs, 4) provides the UI for adding, deleting, start, stop, and invoking config programs for applications
July 8, 201015 yr Author BubbaQ Excellent. I was thinking along the same line, but couldn't bring it out as well as you. For those who want a quick peek to gain ideas. http://www.networkedmediatank.com/wiki/index.php/Community_Software_Installer I'm sure there is more information around, this is what I found at the current moment to wet the whistle.
July 8, 201015 yr Needs mac support It'll be in php, running on unRIAD itself, so the client won't matter.
July 8, 201015 yr It was an offhanded comment based on an internal discussion I had with myself thinking this would be a good idea for a few other things I have on the go...Anyway, back on topic..
July 8, 201015 yr I really love this idea i deal a lot with yum and rpm's at work using redhat if this got implemented into unRaid that would be great I hope Tom likes this idea but that does bring up a question as far as where will the files be hosted at i'm not sure if it's possible but what about a sourceforge account not sure if we could use them to host the files or not or even possibly using dropbox? i'm not to familiar with the whole repositores side of things
July 8, 201015 yr Other than the master config, the files can be hosted anywhere... each developer can host his apps wherever he wants. The master config -- which is just a list of each known application and the URL to where it is hosted -- is the only thing that needs to be hosted in a known/fixed location.
July 8, 201015 yr The master config -- which is just a list of each known application and the URL to where it is hosted -- is the only thing that needs to be hosted in a known/fixed location. Exactly, and even that should be a configurable option, since it is almost certain to change over time.
July 8, 201015 yr Author This is the main part which should be centralized. Now where to put it, Google Code? Wiki? Format? (What Fields are required?) If it's on googlecode someone needs to create it, Then assign others to be project owners or participants. Now where do you get the source, from svn or from the downloads area. If downloads then someone has to update this every now and then when a new package/addon/plugin is submitted.
July 8, 201015 yr One problem with the wiki is that there are 3 permission levels, Limetech > me (historical thing) > regular signups. I cannot change permissions meaning that anyone can alter any page after free signup or i can lock it some no one except myself and limetech can. Potential devastation could be caused by someone with half a brain linking in something nasty. The other alternative is i make changes on a master page after others have finalised a "working" page. Food for thought
July 8, 201015 yr Author After some thought, I'm really leaning towards developers having their own svn googlecode (or other) repository. I'm no svn expert, I've found it's easy enough to create extraneous files or clobber something. I'm leaning towards the centralized configuration file. But decentralized code. As far as packages for install, It can be centralized if there is consensus where to put it. It can still be decentralized with URLS to access it. The configuration file should be able to access it either way. http://unraid-powercontrol.googlecode.com/files/powerdown-1.02-noarch-unRAID.tgz can be accessed anywhere and any time. With the way googlecode works, you can have someone submit a request for package add view the issues and a custom template.
July 8, 201015 yr Author One problem with the wiki is that there are 3 permission levels, Limetech > me (historical thing) > regular signups. I cannot change permissions meaning that anyone can alter any page after free signup or i can lock it some no one except myself and limetech can. Potential devastation could be caused by someone with half a brain linking in something nasty. The other alternative is i make changes on a master page after others have finalised a "working" page. Food for thought Considering the potential for abuse, It needs community access with some form of review before deployment.
July 8, 201015 yr The master config -- which is just a list of each known application and the URL to where it is hosted -- is the only thing that needs to be hosted in a known/fixed location. Exactly, and even that should be a configurable option, since it is almost certain to change over time. Of course, but it has to have some default. And there is no reason there can't be mirrors.
July 8, 201015 yr After some thought, I'm really leaning towards developers having their own svn googlecode (or other) repository. I'm no svn expert, I've found it's easy enough to create extraneous files or clobber something. I'm leaning towards the centralized configuration file. But decentralized code. That's the way I plan for it to work. Say you develop plugin XYZ. You want to make it available to the world. You need: 1) a host location for your package file. 2) a host location for your info file The location for the package file needs to be added to the master config so other users are aware of your new plugin. Example: http://www.myhost.com/bubba/XYZ-0.01.info '>http://www.myhost.com/bubba/XYZ-0.01.info <-- info file http://www.myhost.com/bubba/XYZ-0.01.tgz <-- package file The .info file will have the path to the package file, the author, version, description, install command(s), all in the .info file. The master config is stored at: http://www.unraid-plugins.com/downloads/master.conf You need to add your new plugin to the master.conf So you go to unraid-plugins.com, where you register as a developer. After registering, you can add a new plugin, and give the path to your .info file as: http://www.myhost.com/bubba/XYZ-0.01.info Unraid-plugins.com will then retrieve your .info file, parse it, and add it to the database.... so the next time someone downloads the master.conf, a reference to your new XYZ plugin will be there. Unraid-plugins.com can once a day spider each plugin's .info file to check for updates, and update the master.conf as needed. We can limit visibility of pulgins until they have been vetted for malware, and MD5 hash them and sandbox a previously approved adding if the package changes. We can even have a review system where people rate plugins. End users only need to point their local unRAID system to http://www.unraid-plugins.com/downloads/master.conf.... they don't need to know anything else about any plugins. The master.conf file can obviously be mirrored too.
July 8, 201015 yr I'd suggest that the web-site code for the master.conf repository all be self-contained php and use flat files rather than a database like mySQL. That will greatly facilitate mirroring, and relocating it to another server if needed. I don't see there being hundreds of developers or thousands of plugins.... so a flat-file should be fine. Plus, the master.conf will be static, and generated from the sources once a day or upon an update from a developer. There can also be a few web pages, generated from the info files too.... so people can browse the available plugins on the web rather than in the plug-in management client on unRAID.
July 8, 201015 yr What about SQLite ? That is usually embedded in php. Unnecessary IMHO. And it still requires creating databases and configuration issues. You can't just tar up the directory tree and untar it somewehre else and expect it to work. Small databases like this work fine as flat files, and it makes them portable and super easy to mirror.
July 8, 201015 yr Example: http://www.myhost.com/bubba/XYZ-0.01.info <-- info file http://www.myhost.com/bubba/XYZ-0.01.tgz <-- package file The .info file will have the path to the package file, the author, version, description, install command(s), all in the .info file. The master config is stored at: http://www.unraid-plugins.com/downloads/master.conf You need to add your new plugin to the master.conf So you go to unraid-plugins.com, where you register as a developer. After registering, you can add a new plugin, and give the path to your .info file as: http://www.myhost.com/bubba/XYZ-0.01.info I'm sure you meant: Example: http://www.myhost.com/bubba/XYZ.info <-- info file http://www.myhost.com/bubba/XYZ-0.01.tgz <-- package file The .info file will have the path to the package file, the author, version, description, install command(s), all in the .info file. The master config is stored at: http://www.unraid-plugins.com/downloads/master.conf You need to add your new plugin to the master.conf So you go to unraid-plugins.com, where you register as a developer. After registering, you can add a new plugin, and give the path to your .info file as: http://www.myhost.com/bubba/XYZ.info
July 8, 201015 yr just fyi, I noticed how virtualbox uses two "info" files: http://download.virtualbox.org/virtualbox/LATEST.TXT http://download.virtualbox.org/virtualbox/LATEST-BETA.TXT Of course ours will have some more information in them as bubbaQ wrote above.
Archived
This topic is now archived and is closed to further replies.