August 15, 201114 yr Right, should have happened a long time ago, but, yeah, here it is now. My overall "vision" for plugins is this: There needs to be a central repository of plugins. For now this is a page on the wiki. What's nice about the wiki is that it's accessible by forum members. My goal is to be able to reference the plugin depository from within the webGui and have it display a list of installed plugins and available plugins, in a table sortable by column. With appropriate controls for the user to install/remove/change plugins - something like the Add-ons manager of FireFox. The first piece of this is the plugin installer. This is a PHP script called "installplg" that will interpret an XML "plugin" file. The XML file may be used to define all the files necessary to install the plugin. Some of these files may be downloaded from some URL, others may be created "inline" via the XML file. Ok.. so instead of writing all the documentation in this post, please take a look a the first plugin called "slimserver": http://lime-technology.com/wiki/images/b/b5/Slimserver-7.6.0-noarch-1lt.plg In meantime, I'll be writing documentation and putting it on the wiki....
August 15, 201114 yr Nice Job! Is there a reason the xml configuration is called .plg instead of just .xml?
August 15, 201114 yr Author Nice Job! Is there a reason the xml configuration is called .plg instead of just .xml? It didn't start out as XML until I discovered PHP's "simpleXML". I'm not opposed to changing it to .xml if that make sense. There needs to be a way to distinguish between plugins that are simply downloaded, vs those that are downloaded and also enabled to be installed. (unMenu does this via the existence of the "manual_install" and "auto_install" extensions I believe.) I think I want to accomplish similar by using the extension: name.plg = plugin to be installed upon system restart name.plg- = plugin to not be installed upon system restart Also, if you look at /etc/rc.d/rc.local, the sequence is this: a) install slack packages from /boot/extra b) install all /boot/plugins/*.plg files (ie, "system" plugins) c) install all /boot/config/plugins/.plg files (ie, "user" plugins) d) invoke 'go' script At present time there are no "system" plugins (though the webGui itself and the simple file browser, called indexer, are "pre-installed" plugins). But in future, when one upgrades the release by copying bzimage and bzroot, might also require to copy contents of "/boot/plugins" as well. Step a) may be used to install a slack package that installs a new plugin installer.
August 15, 201114 yr Some problems with the new plugin installer: I used my open-vm-tools plugin for testing: http://marvin.zeron.ca/unraid/open-vm-tools/open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.plg 1) If I put the file in /boot/config/plugins and reboot I see the following error: wget: unable to resolve host address 'marvin.zeron.ca' 2) When I attempt to install the plugin manually via installplg open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.plg : the installer downloads, verifies the .tgz file, installs it then hangs. My test server used DHCP - I assume that the installer script does not have any login in it to wait for the network interface to be configured when it installs plugins on boot.
August 15, 201114 yr Author Some problems with the new plugin installer: I used my open-vm-tools plugin for testing: http://marvin.zeron.ca/unraid/open-vm-tools/open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.plg 1) If I put the file in /boot/config/plugins and reboot I see the following error: wget: unable to resolve host address 'marvin.zeron.ca' Yes this might be an issue with race condition between network coming up and plugins being installed. On my test system (atom based) it's slow enough that it's not an issue, but I'll look into this. 2) When I attempt to install the plugin manually via installplg open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.plg : the installer downloads, verifies the .tgz file, installs it then hangs. It tried a manual install and it seemed to work for me. A nice 'Open VM Tools' logo in green appeared and everything seemed to work ok, hmm. What does this plugin do? Is it just an "ordinary" slack package? Looking inside /boot/config/plugins/open-vm-tools just shows the tgz file. If this is the case, your plugin file could look like this: <?xml version='1.0' standalone='yes'?> <PLUGIN> <!-- The open-vm-tools package. --> <FILE Name="/boot/packages/open-vm-tools/open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.tgz" Run="upgradepkg --install-new"> <URL>http://marvin.zeron.ca/unraid/open-vm-tools/open-vm-tools-2011.07.19-450511-unRaid5.0-beta11-Zeron1.01.tgz</URL> <MD5>9057f4d093527508a8333206f158c1eb</MD5> </FILE> </PLUGIN> Also, if you want to use 'upgradepkg' I would highly suggest you adhere to slack package file naming convention: http://www.linuxpackages.net/howto.php?page=perfect-package&title=Perfect+Package For example, you might rename your package to: open_vm_tools-2011.07.19_140511_unraid5.0beta11-i486-1.01_Zeron.tgz Not a big deal, but upgradepkg will try to 'parse' the package file name into it's components: name-version-arch-build.tgz where the components are separated by dashes. It will compare version-build of what it's installing to same-named package (if exist) of what's already there and possibly replace it. The convention for the 'build' string is a number followed by alpha. So for example, from slack builds website you see builds like "-1_SBo". What I'm doing is using "lt" (for lime-tech) as a suffix, hence the slimserver package is "-1lt". If I modify the package file I'll bump the build to "-2lt". Make sense?
August 16, 201114 yr Also, if you look at /etc/rc.d/rc.local, the sequence is this: a) install slack packages from /boot/extra b) install all /boot/plugins/*.plg files (ie, "system" plugins) c) install all /boot/config/plugins/.plg files (ie, "user" plugins) d) invoke 'go' script is there a way to control, in which order user plugins are installed/executed? i.e. if i have a drive, which is not part of the array, and i want to have the plugin installer look at that drive, i need to mount it first. so i need a second plugin to mount this drive. but this has to be executed, before the other plugin is installed. currently i'm mounting the drive in my go script. if i use the plugin installer, this won't work anymore would it be sufficient to number the plg files? or should i move the mounting plugin to the system plugin folder?
August 17, 201114 yr Nice Job! Is there a reason the xml configuration is called .plg instead of just .xml? It didn't start out as XML until I discovered PHP's "simpleXML". I'm not opposed to changing it to .xml if that make sense. There needs to be a way to distinguish between plugins that are simply downloaded, vs those that are downloaded and also enabled to be installed. (unMenu does this via the existence of the "manual_install" and "auto_install" extensions I believe.) I think I want to accomplish similar by using the extension: name.plg = plugin to be installed upon system restart name.plg- = plugin to not be installed upon system restart I would suggest using the .xml extension since it is an xml file and other internal functions are using xml tools to parse it. It makes sense to me. Even Solaris 10's service manager uses .xml for the definitions. It's common to use .xml for application configuration files. Naming plugin.xml to plugin.xml- works to denote install/don't install. It may lead to one of those oofa moments. I.E. Where you cannot figure out why it's not installing until the extra - catches your eye. it could also look like one of those backup extensions and get accidentally removed. I liked BubbaQ's naming it to file.ext.disabled It's obvious. Or even moving it to another disabled directory. Actually it could be named to anything other then .xml for it to be disabled. Just my opinion in that .xml- is a close match and someone may miss it. Also, if you look at /etc/rc.d/rc.local, the sequence is this: a) install slack packages from /boot/extra b) install all /boot/plugins/*.plg files (ie, "system" plugins) c) install all /boot/config/plugins/.plg files (ie, "user" plugins) d) invoke 'go' script At present time there are no "system" plugins (though the webGui itself and the simple file browser, called indexer, are "pre-installed" plugins). But in future, when one upgrades the release by copying bzimage and bzroot, might also require to copy contents of "/boot/plugins" as well. Step a) may be used to install a slack package that installs a new plugin installer. Will you sort these in name order? if so they can be named accordingly to provide some semblance of order control.
August 17, 201114 yr .xml and .xml- do keep it simple but I think it may be a little to similar, as mentioned above by WeeboTech. unMenu's package manager has the .conf files to install, .manual_install for a one time install, and .auto_install for an install that will persist across a reboot. If you were to do something similar it would probably be something like: .conf <==> .xml (.plg) .manual_install <==> .xml.installed (.plg.installed) .auto_install <==> .xml.enabled (.plg.enabled) I don't really know if we really need a .xml.disabled or not, unless we want to be able to search on it. Then again anything with a .xml ending will be the plugins that are available for install but NOT installed. I guess I am use to unMenus naming convention and it is kind of hard to get away from that. I like the the naming convention of: .conf <==> .xml (.plg) .manual_install <==> .xml.installed (.plg.installed) .auto_install <==> .xml.auto_install (.plg.auto_install) And in "maintenance mode" none of the .xml.auto_install files would be loaded.
August 18, 201114 yr If .xml files are always auto installed upon startup, then renaming it by some convention to .xml.installed or .xml.disabled or anything other then .xml will defeat the automatic installation. I'm not fond of having to name a config file .auto_install I'm pro for the standard .xml definition inside the plugin directory meaning automatically install. What ever naming convention to defeat the auto install is open for debate. My biggest desire is to have .xml being the plugin extension standard for the definitions if it uses standard XML specs and uses the basic PHP XML routines.
August 18, 201114 yr .xml.disabled sounds like a nicer naming convention. I can't test Beta 11 until a kernel oops has been fixed, but liking the activity already!
August 19, 201114 yr My biggest desire is to have .xml being the plugin extension standard for the definitions if it uses standard XML specs and uses the basic PHP XML routines. I'm going to be a voice of dissent on this. .xml doesn't really tell a person anything about what the file is. It just describes how it is structured. .plg tells a person that this is an UnRaid plugin. Most people don't need to know and probably don't care how it works internally. Just my 2 cents.
August 19, 201114 yr My biggest desire is to have .xml being the plugin extension standard for the definitions if it uses standard XML specs and uses the basic PHP XML routines. I'm going to be a voice of dissent on this. .xml doesn't really tell a person anything about what the file is. It just describes how it is structured. .plg tells a person that this is an UnRaid plugin. Most people don't need to know and probably don't care how it works internally. Just my 2 cents. I agree. .plg is much better.
August 19, 201114 yr Anyway yet for plugins to tie into emhttp event hooks to auto-start/auto-stop/do X action on various array activities? If not, is this out of scope or simply not implemented yet?
August 19, 201114 yr Anyway yet for plugins to tie into emhttp event hooks to auto-start/auto-stop/do X action on various array activities? I'm not sure whether there is a comprehensive list anywhere, but the slimserver plugin does use 'disks_mounted' and 'unmounting_disks' to start and stop slimserver. Oh, and another vote here to retain .plg
August 19, 201114 yr My biggest desire is to have .xml being the plugin extension standard for the definitions if it uses standard XML specs and uses the basic PHP XML routines. I'm going to be a voice of dissent on this. .xml doesn't really tell a person anything about what the file is. It just describes how it is structured. .plg tells a person that this is an UnRaid plugin. Most people don't need to know and probably don't care how it works internally. Just my 2 cents. It's in a plugin directory. That tells what it's for, an XML configuration file for plugins. Most people won't care,. but new people to unraid who begin to develop plugins would know right away that it's a plugin configuration XML file and can use whatever tools that may have at their disposal to generate and/or update them. Also in the future there may be command line tools to update these in place. Where the files are located denote what application uses them It makes sense to me that an XML structured file in a plugin directory is an unRAID plugin configuration file.
August 19, 201114 yr Let's not forget that although it may seem important to software developers, no-one else gives a monkeys if the plugins have an extension of .plg, .xml or .cotton We'll drop the files in to a config/plugins folder and never see them again. Let's not end up like this dude, where http://byuu.org/bsnes/legacy-formats ended up with: http://byuu.org/articles/bsnes-future Not that I don't agree with his main points, but it shouldn't take over your life and matter too much. The important thing is to make the plugin architecture work and make some plugins!
August 19, 201114 yr I think it's more of using the conventional standard in a conventional way so that it is obvious to new developers and admins. A file named .xml could be loaded into notepad++ or the microsoft xml editor without anyone needing to ask questions. For most seasoned veterans this probably does not matter. Yet look at how many new people come to unraid and do not have linux experience and try or want to write plugins. From what I've seen of the xml plugin file, they may be able to load it into an xml editor and fill in the blanks pretty easily.
August 19, 201114 yr +1 for .plg XML file naming is pretty generic and to a point too generic have a defined name like .plg gives that body of xml some meaning as to what it's used for. like web.config although it's XML it really defines what exactly that file will be used and where.
August 19, 201114 yr i have a little feature request. when downloading a file and it exist already exists, please check the md5 of the existing file, and if the hash doesn't match the one in the plg-file, start the download. this way, an old version with the same name could be replaced. and maybe give the possibility to overwrite a file created via inline. so these could also be replaced, when updating a plugin, without rebooting the server
August 19, 201114 yr Although .xml is generic, it's in the plugin directory. That defines something right there. Download one of the neat little windows XML editors, Then try editing the file by clicking on it. Microsoft has a free xml editor. In addition notepad++ allows viewing and editing right away. By double clicking the file on a windows machine you can bring the file up very rapidly. If you do not have an editor, it will show up formatted in an IE or your favorite browser. If it's named .plg, a person will need to set an association or load it into notepad manually. if it's .xml and there is an editor or any question of the file a double click will bring it up to an easily visual mode.
September 2, 201114 yr would it not be better to make a Plugin page in the Unraid GUI ? somewhere were all plugins that are installed are shown.. with start/stop buttons for each plugin and on the bottom a searchbox for where you dlded the new plugin... select it and press install button... to make it easy for the non Linux savvy people .... seems a bit messy like it is now ....
September 2, 201114 yr would it not be better to make a Plugin page in the Unraid GUI ? somewhere were all plugins that are installed are shown.. with start/stop buttons for each plugin and on the bottom a searchbox for where you dlded the new plugin... select it and press install button... to make it easy for the non Linux savvy people .... seems a bit messy like it is now .... Did you read through some of the threads? Lime-Tech mentioned that there would eventually be an "interface" in the unRAID webGUI that is pretty much what you describe.
September 2, 201114 yr well so far i tried to install the ssh plugin just for the fun of it and i was dissapointed about the info available on how to install a plugin even the wiki is not clear on how to install the plugins ..... might be because i always had issues with the unraid wiki to find what i am looking for .... but anyway if there is a plugin page planned then i am happy i keep for the moment using unmenu and the proggies that i installed manually and with the nice unmenu userscript buttons just wanted to be sure this is not going to be left like it is now .... would it not be better to make a Plugin page in the Unraid GUI ? somewhere were all plugins that are installed are shown.. with start/stop buttons for each plugin and on the bottom a searchbox for where you dlded the new plugin... select it and press install button... to make it easy for the non Linux savvy people .... seems a bit messy like it is now .... Did you read through some of the threads? Lime-Tech mentioned that there would eventually be an "interface" in the unRAID webGUI that is pretty much what you describe.
September 2, 201114 yr well so far i tried to install the ssh plugin just for the fun of it and i was dissapointed about the info available on how to install a plugin even the wiki is not clear on how to install the plugins ..... might be because i always had issues with the unraid wiki to find what i am looking for .... but anyway if there is a plugin page planned then i am happy i keep for the moment using unmenu and the proggies that i installed manually and with the nice unmenu userscript buttons just wanted to be sure this is not going to be left like it is now .... Please read the original post. It directly addresses what you are talking about. There needs to be a central repository of plugins. For now this is a page on the wiki. What's nice about the wiki is that it's accessible by forum members. My goal is to be able to reference the plugin depository from within the webGui and have it display a list of installed plugins and available plugins, in a table sortable by column. With appropriate controls for the user to install/remove/change plugins - something like the Add-ons manager of FireFox. The first piece of this is the plugin installer. This is a PHP script called "installplg" that will interpret an XML "plugin" file. The XML file may be used to define all the files necessary to install the plugin. Some of these files may be downloaded from some URL, others may be created "inline" via the XML file. In meantime, I'll be writing documentation and putting it on the wiki....
Archived
This topic is now archived and is closed to further replies.