July 21, 201015 yr BubbaTools-0.2.05-unraid-bubba.tgz http://www.tcpatools.com/bubba/bubbaTools-0.2.05-unraid-bubba.tgz This version is for unRAID 5.0-Beta2 Disk info includes Linux device name and a "SMART Capabilities Test" button. Got rid of popup URL (debug) in Package Manager. Includes: - DMIDecode plugin - Simple package manager for /boot/extra - MDCMD retrieval tool - Array variable query tool - Open file lister. - SMART testing (preliminary) - Adds an "alert" section to main UI page, and shows an alert if open files will block shutdown - Improved open file manager, with ability to kill processes that have open files - Adds a "Disk Info" section to individual disk configuration pages, which checks for HPA, and provides some additional disk info. This includes a "SMART Capabilities Test" button. Comments welcome.
July 21, 201015 yr I just installed it (wget, installpkg) but something strange happens on my server (where my brand new DiskUsage is also running). I don't know if it's your package or my own, but after installing yours my plugin is no longer available as a plugin on the utils page... ...but, the output of my page is now always visible on http://tower/Utils
July 21, 201015 yr Author I just installed it (wget, installpkg) but something strange happens on my server (where my brand new DiskUsage is also running). Edit your .page file and change: Menu="Utils" to Menu="Utilities"
July 21, 201015 yr Author I need to apologize.. I broke it and I shouldn't have. I redesigned the Utils tab pages so I could group icons and do a screenshot to post to Tom as a suggestion for a GUI change. Then when I built bubbaUtils, I didn't reboot in between and undo it. I will build a new bubbaUtils today, and will put everything back to stock, and put my bubbaUtils on a new, independent tab..... like I should have in the first place.
July 21, 201015 yr I quite like the current look with the grouping, and after applying your fix, it's working without problems... I'll trust your view on the matter as you're a long way ahead of understanding how everything is working, but would still ask you to look for a method of getting the grouped utils page... Maybe with dynamic fold-downs of the groups, resembling the OSX settings ?
July 21, 201015 yr Author I like the grouping too, but that doesn't change the fact it was very bad foresight on my part. I changed stock stuff that was not necessary to be changed, and should have easily forseen it would break anything someone else added to the existing Utils tab. I should not have build the package without rebooting back to a clean system.
July 21, 201015 yr Author New version posted... see the OP. mvdzwaan, your app will show up on the bubbaUtils tab, but you can move it by changing your .page file back to Menu="Utils"
July 23, 201015 yr Author New version posted. This adds the ability to download a package file from the internet directly to /boot/packages.
July 23, 201015 yr Author New version posted in the OP. bubbaUtils-0.0.6-i386-bub.tgz This version now handles filenames with a '+' sign :'(, and adds the ability to run installpkg interactively.
August 3, 201015 yr Author New version posted in the OP. bubbaUtils-0.0.7-i386-bub.tgz This version adds a dmidecode plugin, with some smarts on helping you get dmidecode if you don't have it installed.
August 6, 201015 yr Author New version posted. See OP for details. bubbaTools-0.0.9-unraid-bubba.tgz Renamed to bubbaTools, so as to not collide with the "Utils" tab in the unRAID UI. If you downloaded bubbaTools-0.0.8-unraid-bubba.tgz, please replace it with 0.0.9 or later... I left out part of the new package manager code.
August 7, 201015 yr Here's something related to this that I changed in -beta2. Previously the "document root" of emhttp was /usr/local/webGui where all the .page and .php files exist. This is changed as follows: The new emhttp "document root" is /usr/local/emhttp In addition there is a 'plugin' subdirectory: /usr/local/emhttp/plugin The 'stock' unRAID release will include one "plugin" called webGui. So now all the .page and .php files for the 'stock' webGui are in /usr/local/emhttp/plugin/webGui When emhttp gets a request for a webGui page, the templating system will search for the page in all subdirectories underneath 'plugin'. So for example, say there are these directories: /usr/local/emhttp/plugin/webGui /usr/local/emhttp/plugin/bubbaTools /usr/local/emhttp/plugin/slimserver /usr/local/emhttp/plugin/yamj Each of these plugin directories can have their own page definitions. The pages must still be unique, for example, since webGui includes a page called "DiskStatus", no other plugin can have a page named "DiskStatus". I am trying to come up with a way to lift this restriction however. The other thing I'd like to do is propose that 'events' are handled in this manner: When an event occurs, emhttp will search each plugin directory for the corresponding event handler script & then invoke that script. I guess the code to do this can either live in emhttp, or be implemented in an external "master" event script. This part doesn't really matter to me. The conceptual difference between this method, and what I think you guys have been discussing, is that instead of having different event directories into which plugins place their handlers, the handlers just exist in the plugin directories. I'm finishing up some final testing & should be able to release -beta2 this weekend.
August 7, 201015 yr Author The other thing I'd like to do is propose that 'events' are handled in this manner: When an event occurs, emhttp will search each plugin directory for the corresponding event handler script & then invoke that script. I guess the code to do this can either live in emhttp, or be implemented in an external "master" event script. This part doesn't really matter to me. The conceptual difference between this method, and what I think you guys have been discussing, is that instead of having different event directories into which plugins place their handlers, the handlers just exist in the plugin directories. One problem I see with that off the bat is that everything is not a plugin. Many additions may simply be packages that are loaded from /boot/extra, but that have code that needs to be triggered by events. Another is controlling order when you have things that need to run "first"... you can do that with the filename of the script in the /etc/emhttp/*.d framework. One positive however, is that all the files for a plugin, including the event code, can live underneath one "home" dir structure.
August 7, 201015 yr The other thing I'd like to do is propose that 'events' are handled in this manner: When an event occurs, emhttp will search each plugin directory for the corresponding event handler script & then invoke that script. I guess the code to do this can either live in emhttp, or be implemented in an external "master" event script. This part doesn't really matter to me. The conceptual difference between this method, and what I think you guys have been discussing, is that instead of having different event directories into which plugins place their handlers, the handlers just exist in the plugin directories. One problem I see with that off the bat is that everything is not a plugin. Many additions may simply be packages that are loaded from /boot/extra, but that have code that needs to be triggered by events. Another is controlling order when you have things that need to run "first"... you can do that with the filename of the script in the /etc/emhttp/*.d framework. One positive however, is that all the files for a plugin, including the event code, can live underneath one "home" dir structure. It's possible for us to do both. Maybe the event directories should be in /usr/local/emhttp/event.d/ We could also write something to scan the plugin directories. I can see both sides of the discussion here. My preference is for installed plugins to put their events into the event directory. Just like a regular environment would. The physical plugin event script can still exist in the plugin directory if it puts a symlink into the event subsystem directory. As BubbaQ mentions, not all events are plugins. Some are tweaks and preparations. On the other side of this, If we scan the plugin directory for an event script. Then we will need to be consistent on a name. Authors will need to be aware of the multiple times the script can be called for each event and handle accordingly. A point to consider. If you scan all the plugin directories for an event script. How do you disable the event? With the event.d and sub directories underneath, If the script or symlink exists and is executable, then it runs. If this plugin or event needs to be disabled, the symlink or script is removed.
August 7, 201015 yr Author On the other side of this, If we scan the plugin directory for an event script. Then we will need to be consistent on a name. Authors will need to be aware of the multiple times the script can be called for each event and handle accordingly. A point to consider. If you scan all the plugin directories for an event script. How do you disable the event? With the event.d and sub directories underneath, If the script or symlink exists and is executable, then it runs. If this plugin or event needs to be disabled, the symlink or script is removed. I would keep the +x framework.... everyone understands that. I think we need to see more about what Tom is doing with the events. For example, if he is using a single event script for the plugin, like: /usr/local/emhttp/plugin/bubbaTools/event.sh then it is hard to disable one event... it is all or nothing.... unless that event.sh scans directories itself for individual event code, and if a plugin needs that fine-grained control, the dev for that plugin can implement it.
August 7, 201015 yr I would keep the +x framework.... everyone understands that. I too would prefer this over the event scripts residing in the individual plugin folders. As already mentioned, a symlink will take care of this if the developer prefers to also keep a link to the plugin folder version for ease of access. I think we need to see more about what Tom is doing with the events. For example, if he is using a single event script for the plugin, like: /usr/local/emhttp/plugin/bubbaTools/event.sh then it is hard to disable one event... it is all or nothing.... unless that event.sh scans directories itself for individual event code, and if a plugin needs that fine-grained control, the dev for that plugin can implement it. We do not yet know what Tom will be using... but we can make suggestions. I too like the /etc/emhttp/eventname.d/* structure since we can control event order by their relative names, and enable/disable by their +x status. Joe L.
August 7, 201015 yr Author Controlling order with the script name seems really to be the only issue I can't solve under the -beta2 framework ... but I'm not sure how big an issue it is in how often it would be needed. Theoretically, plugins should be black boxes, and have no dependence on other plugins w/r/t their scripts.... but I can imagine some examples that would rebut this theory. I have no issues with using "/usr/local/emhttp/" rather that "/etc/emhttp" Perhaps instead of scanning the plugins and running the +x scripts as found, emhttp can scan the plugins for event scripts, sort them, and then execute them in the order after sort. So using the stop event as an example, will it be a call to something like this: /usr/local/emhttp/plugins/bubbaTools/events/stop.sh as the script that gets called on the "stop" event.... or will it be a call to something like this: /usr/local/emhttp/plugins/bubbaTools/events.sh with the first parameter "stop".. or get the script(s) in: /usr/local/emhttp/plugins/bubbaTools/stop.d/ ... this is the one that would allow the scripts to be sorted before executing.
August 7, 201015 yr I like this best. /usr/local/emhttp/plugins/bubbaTools/stop.d/ Easy to control on a event specific basis by +x status, and to order by name. We still need a way to hook to events for the occasional script that does not have an affiliated web-page, perhaps they will be a directory under emhttp/plugins, and just not have any .php scripts. Joe L.
August 7, 201015 yr I like this best. /usr/local/emhttp/plugins/bubbaTools/stop.d/ Easy to control on a event specific basis by +x status, and to order by name. I was thinking: /usr/local/emhttp/plugins/bubbaTools/event_stop.sh The plugin author can decide if an 'event_stop.sh' script exists, or whether x bit is set, and of course what the contents are. If the plugin requires multiple other scripts to be run, then that logic can be put into the script. What I'm trying to avoid if possible is the notion of "registering" stuff. The idea of "registration" is preferred especially for performance reasons, but I don't see performance as a big issue. If there is a global events directory somewhere into which plugins copy their script, then there are issues like name space collision & it's just been my experience that it's more error prone, especially when authors are less familiar with how the overall system works & it is indeed unreasonable to expect authors to be complete experts in how everything works. Just seems intuitively better to "isolate" all plugin code to a single directory. We still need a way to hook to events for the occasional script that does not have an affiliated web-page, perhaps they will be a directory under emhttp/plugins, and just not have any .php scripts. Exactly what I was thinking. This is why the dir structure is: /usr/local/emhttp/plugin/... and not /usr/local/webGui/plugin/... If fact, the webGui is just another plugin of the 'emhttp' process. The fact that the templating system searches all the plugin directories for .page files is a recognition that probably most plugins will in fact have some kind of webGui control, but they don't have to. Joe, I really like the work you did with unmenu & how it handles packages/addons. There's no reason the package manager can't be written in sed
August 7, 201015 yr I like this best. /usr/local/emhttp/plugins/bubbaTools/stop.d/ Easy to control on a event specific basis by +x status, and to order by name. We still need a way to hook to events for the occasional script that does not have an affiliated web-page, perhaps they will be a directory under emhttp/plugins, and just not have any .php scripts. Joe L. This becomes more difficult to program. It requires a loop within a loop. consider: find /usr/local/emhttp/plugins -type f -name eventhandler.sh -perm /0110 -exec {} $1 \; Nice and simple. This method expects the eventhandler to handle stop/start/eventname... as arg 1. Like a "normal" rc d script should. Then for those who want to use the "drop in architecture" find /usr/local/emhttp/event.d/$1.d -type f -perm /0110 -exec {} $1 \; In order to maintain an order, we would need to change this line to be sorted. Or it would be a for loop/while loop using some sorted name. I think we need to consider how many people write plugins and just how complex of a structure that needs to be there. The whole stop.d start.d within each plugin could be cumbersome. The other thought is that you are then catering to those who do not know the standard way of doing this type scripting instead of teaching and providing the examples. Would this be accepted in any other distribution? EDIT: find /usr/local/emhttp/plugins -type f -name eventhandler.sh -perm /u+x -exec {} stop \; also works and the numeric modes would not be there to confuse anyone.
August 7, 201015 yr Screen examples of event.d execution via find. This is without sort order management. Just some food for thought. rcotrone@hercules: /usr/local/emhttp > find /usr/local/emhttp/event.d -type f -follow -perm /u+x -ls 131088 4 -rwxr----- 1 rcotrone rcotrone 58 Aug 7 13:27 /usr/local/emhttp/event.d/start.d/weebotech.sh 131088 4 -rwxr----- 1 rcotrone rcotrone 58 Aug 7 13:27 /usr/local/emhttp/event.d/stop.d/weebotech.sh rcotrone@hercules: /usr/local/emhttp/event.d > find /usr/local/emhttp/event.d/stop.d -type f -follow -perm /u+x -exec {} stop \; /usr/local/emhttp/event.d/stop.d/weebotech.sh[12906]: Running /usr/local/emhttp/event.d/stop.d/weebotech.sh stop rcotrone@hercules: /usr/local/emhttp/event.d > find /usr/local/emhttp/event.d/start.d -type f -follow -perm /u+x -exec {} start \; /usr/local/emhttp/event.d/start.d/weebotech.sh[12909]: Running /usr/local/emhttp/event.d/start.d/weebotech.sh start and more. find /usr/local/emhttp/event.d/start.d -type f -follow -perm /u+x -printf "%p start\n" /usr/local/emhttp/event.d/start.d/W99weebotech.sh start /usr/local/emhttp/event.d/start.d/weebotech.sh start /usr/local/emhttp/event.d/start.d/S01weebotech.sh start /usr/local/emhttp/event.d/start.d/S99weebotech.sh start Running via sort and xargs. find /usr/local/emhttp/event.d/start.d -type f -follow -perm /u+x -printf "%p start\n" | sort | xargs -L1 /bin/sh -c rcotrone@hercules: /usr/local/emhttp/event.d/start.d > find /usr/local/emhttp/event.d/start.d -type f -follow -perm /u+x -printf "%p start\n" | sort | xargs -L1 /bin/sh -c /usr/local/emhttp/event.d/start.d/S01weebotech.sh[13156]: Running /usr/local/emhttp/event.d/start.d/S01weebotech.sh /usr/local/emhttp/event.d/start.d/S99weebotech.sh[13158]: Running /usr/local/emhttp/event.d/start.d/S99weebotech.sh /usr/local/emhttp/event.d/start.d/W99weebotech.sh[13160]: Running /usr/local/emhttp/event.d/start.d/W99weebotech.sh /usr/local/emhttp/event.d/start.d/weebotech.sh[13162]: Running /usr/local/emhttp/event.d/start.d/weebotech.sh Now do we need to have a doscrlf handler/exec'er in there?
August 7, 201015 yr Not sure what you are advocating... If this: find /usr/local/emhttp/plugins -type f -name eventhandler.sh -perm /u+x -exec {} stop \; Then I agree this is good. What does that 'stop' do at the end?
Archived
This topic is now archived and is closed to further replies.