I think Joe wants one script to each event, and WeeboTech want one script with multiple event calls, like the rc.d scripts.

I'd prefer the single script approach where the first parameter is the event that occurred (start, stop, boot, readfailure, writefailure, startfailed), and after the event name the rest are additional parameters, like rc.d scripts.

 

I also prefer to have a central directory for the event scripts.

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?

 

One event handler per plugin.

The event handler should accept one argument which is the event.

 

init/start/stop/shutdown/diskerror/arrayerror, etc, etc.

What ever it does not want to handle is ignored.

 

Just as the rc.d scripts.

 

It's clear there are different ways to do this.

 

Having all plugin code in a single directory & having 'emhttp' simply loop over directories invoking scripts makes the plugin completely "passive" & for a lot of plugins, no plugin/package manager is needed.  Personally, I like this approach, but I can see there are limitations.

 

However, once you decide there is a package manager then the sky's the limit in terms of complexity.

 

This issue is not going to get decided today, so in the interest of getting -beta2 out, which has other features, what I'm going to do is this:  I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

With the event name as first argument, followed by additional event-specific arguments.  This will let people experiment & let me carry on with additional features.

 

Also, bubba, sorry for hi-jacking your thread.. I'll split this discussion off into a different thread later today.

I'd prefer the single script approach where the first parameter is the event that occurred (start, stop, boot, readfailure, writefailure, startfailed), and after the event name the rest are additional parameters, like rc.d scripts.

 

I also prefer to have a central directory for the event scripts.

 

How central?

 

find /usr/local/emhttp/event.d/start.d -type f -follow -perm /u+x -printf "%p start\n" | sort | xargs -L1 /bin/sh -c

 

can handle a central directory of the same event "start".

 

Actually if emhttp just runs one configurable script with one parameter (the event name).

Then people can choose how they want to architect a set up.

 

With two find s' as presented

we can have one event handler per plugin directory

or

multiple scripts installed in a set of event directories.

 

Speaking frankly, all I need is emhttp to shell out and run one script upon each event with the argument name of the event.

 

After that it's all handled in shell land.

 

I could easily have both find lines in the same script.

 

 

I.E:

 

rcotrone@hercules: /usr/local/emhttp > cat rc.event

find /usr/local/emhttp/event.d/$1.d -type f -follow -perm /u+x -printf "%p $1\n" | sort | xargs -L1 /bin/sh -c

 

find /usr/local/emhttp/plugins -type f -name eventhandler.sh -perm /u+x  -exec {} $1 \;

 

 

If we really need to get fancy we can write an undosify safeexec shell script and exec that.

 

What I'm trying to avoid if possible is the notion of "registering" stuff.

 

Agreed... no need to in this environment.

 

The whole stop.d start.d within each plugin could be cumbersome.

 

Agreed.  The only reason I can think of that militates in favor of that model is that it could permit sorting the script names, so you can influence the order.  Joe seemed to think that was important, and I can think of some hypothetical examples, but I'm OK with losing that capability.  I'm sure that is some real-world situation comes up needing it, it could be handled.

 

 

One event handler per plugin.

The event handler should accept one argument which is the event.  init/start/stop/shutdown/diskerror/arrayerror, etc, etc.

 

I suggest that there is a need for a second parameter in some cases -- at least for the diskerror event you should pass the disk ID.

I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

With the event name as first argument, followed by additional event-specific arguments.  This will let people experiment & let me carry on with additional features.

 

I would suggest rc.event which mimics a standard resource control naming as in slackware.

(or put the name of it in one of the .cfg files.)

Also, bubba, sorry for hi-jacking your thread.. I'll split this discussion off into a different thread later today.

 

Don't let it happen again... I'll report you to the mods.

 

bubba  <===  Always willing to sacrifice a thread in the name of the community as a whole.

 

 

I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

 

That's fine.  If someone needs the ordering ability to prioritize scripts, that dev can modify the main emhttp/event.sh script.

 

 

I think Joe wants one script to each event

Actually, no.  I prefer it all in one script, but then you must enable or disable the whole script at once.  For that reason,  it is easier to manage a given plugin.  One file to change mode to stop event processing rather than several.    Now, for flexibility,I think separate scripts would be better.

, and WeeboTech want one script with multiple event calls, like the rc.d scripts.

As I said, this is more flexible. But how many times will we want to disable a "start" event, but not a "stop" event?

 

I do like Tom's idea that all the "event" scripts be named as "event_<eventname>"

That way, they will all group together in a directory listing.  I have no issue with

event_NNN_<eventname> if you wish to sort them by the leading "NNN"

 

As far as processing all the scripts in sorted order, that just means you can't use a single "find -exec ... " to process them all.  I would NEVER do it that way any way as you have no control if one script mis-behaves and does not return in a timely manner.    (Yes, I did it that way in unMENU... but I was specifically trying to add only one line to the go script, to keep it simple for the users who would wonder what I was doing to their server, and I only had one "event" that of the array reboot.)

 

Joe, I really like the work you did with unmenu & how it handles packages/addons.

Thanks

  There's no reason the package manager can't be written in sed

"sed" ? ? ?      Ok,..  "sed" does have labels and conditional branching, and a crude "stack" ...    I would prefer "awk" , but if you are presenting a challenge...

 

OK, here is a "sed" script that will sort the event names... 

http://sed.sourceforge.net/grabbag/scripts/sodelnum.sed

 

Are you sure you wouldn't rather we write in something a tiny bit more readable?      (even with the comments it is pretty hard to understand)

 

No... I think the package manager will probably be in "php"  now that it can be supported.    WeeboTech and BubbaQ can breath a sigh of relief...

 

Joe L.

I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

With the event name as first argument, followed by additional event-specific arguments.  This will let people experiment & let me carry on with additional features.

 

This is exactly what I wanted and what I think the dev community wanted, nothing more complicated than this.

 

Additional complexities should be handled by changing that external script, not by having C/C++ code inside of md.c / emhttp / webGui.

It's clear there are different ways to do this.

 

Having all plugin code in a single directory & having 'emhttp' simply loop over directories invoking scripts makes the plugin completely "passive" & for a lot of plugins, no plugin/package manager is needed.  Personally, I like this approach, but I can see there are limitations.

 

However, once you decide there is a package manager then the sky's the limit in terms of complexity.

Agreed

This issue is not going to get decided today, so in the interest of getting -beta2 out, which has other features, what I'm going to do is this:  I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

With the event name as first argument, followed by additional event-specific arguments.  This will let people experiment & let me carry on with additional features.

Fantastic.  It will provide the hooks we've needed, and allow for a lot of experimentation of varied approaches.  With any luck, we'll come up with an approach we can all be happy with...

 

Can I ask one more "feature" of the single script you invoke.

 

Can you post any output it might have to the bottom "i-frame" on the management web-page.  Various events might just need to communicate to the user what they are doing, and that is the easiest way for now. 

 

So you'll call

/usr/local/emhttp/event.sh "start"

 

It will then invoke the plug-in scripts (regardless of if we use a single script or multiple, we can adapt it.)

For each XYZ script that has a desire to feed back info to the user, it will print to stdout "XYZ started., etc"

The stdout will be captured by event.sh, passed to emhttp for display to the use as an informational message.

 

It will keep the guesswork to a minimum when a user installs a plugin, and it fails in their environment, but can post an error as to why.

 

I'm going to define the set of events generated by emhttp, along with arguments, and have emhttp invoke a single script, e.g.,

/usr/local/emhttp/event.sh

With the event name as first argument, followed by additional event-specific arguments.  This will let people experiment & let me carry on with additional features.

 

This is exactly what I wanted and what I think the dev community wanted, nothing more complicated than this.

 

Additional complexities should be handled by changing that external script, not by having C/C++ code inside of md.c / emhttp / webGui.

Exactly.

Now, for flexibility,I think separate scripts would be better.

, and WeeboTech want one script with multiple event calls, like the rc.d scripts.

As I said, this is more flexible. But how many times will we want to disable a "start" event, but not a "stop" event?

 

I do like Tom's idea that all the "event" scripts be named as "event_<eventname>"

That way, they will all group together in a directory listing.   I have no issue with

event_NNN_<eventname> if you wish to sort them by the leading "NNN"

 

This is why links are usually dropped in an rc runlevel.d directory.

So you can enable/disable that run level without affecting the ability to run the script.

But this means you need to register the script by inserting links or calling a service registration script that sets up the link.

 

 

Now the separate event_X##_eventname script does make it easier for newbies because they do not have to concern themselves with any form of conditional processing.

 

3 or 4 lines and you are done.

 

But then it could become difficult to manage later on and a person may never involve themselves into how it's done on other subsystems.

 

Then you have to think of how you will traverse the directory structure for a event executables, sort and exec them.

 

As far as processing all the scripts in sorted order, that just means you can't use a single "find -exec ... " to process them all.   I would NEVER do it that way any way as you have no control if one script mis-behaves and does not return in a timely manner.    (Yes, I did it that way in unMENU...

 

I diminished this down to one long script line.

As far as controlling another script's behavior.

Too much too soon, With the find or xarg exec line we can call another program that handles the timeout.

 

Joe, I really like the work you did with unmenu & how it handles packages/addons.

Thanks

 There's no reason the package manager can't be written in sed

"sed" ? ? ?      Ok,..   "sed" does have labels and conditional branching, and a crude "stack" ...    I would prefer "awk" , but if you are presenting a challenge...

 

OK, here is a "sed" script that will sort the event names...  

http://sed.sourceforge.net/grabbag/scripts/sodelnum.sed

 

Make me gag why don'tcha!  

OK, here is a "sed" script that will sort the event names...  

http://sed.sourceforge.net/grabbag/scripts/sodelnum.sed

 

Make me gag why don'tcha!  

I guess you prefer "Quick-sort" or 'Bubble-sort" over "Insertion" sort.   Each to their own...  

OK, here is a "sed" script that will sort the event names...  

http://sed.sourceforge.net/grabbag/scripts/sodelnum.sed

 

Make me gag why don'tcha!  

I guess you prefer "Quick-sort" or 'Bubble-sort" over "Insertion" sort.   Each to their own...  

 

LOL, big sed scripts and regex's are not my favorite part of unix. 

New version BubbaTools-0.2.03.  See OP for details.

 

Fixed some bugs due to the new document root in -Beta2.

Now installs in its own home (./plugins/BubbaTools/).

Package Manager is a bit better.

New version BubbaTools-0.2.04.  See OP for details.

 

 

New version BubbaTools-0.2.05.  See OP for details.

 

This version adds a button to the disk info page, that lets you test if that drive can return SMART info when spun down.  This will be a necessary piece of information for some future monitoring utilities, to know if a disk can return SMART info if spun down.

 

Please try it, and report back the make/model of drives that do/donot return SMART without spinning up.

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.

I think I stumbled upon a bug ... or a feature ...

 

I was attempting to port some of the unMENU utilities to unRAID 5.0 and ran into a bug/feature that caused the loss of a few more hairs.

 

To duplicate what I found execute the following few lines:

# create a file containing a minimal amount of html in the document "root".

echo "<h1>Got here<br>" >/usr/local/emhttp/unMENU

 

# Create a new "plugin" directory

mkdir /usr/local/emhttp/plugins/JOE

 

# Create three new .page files in that directory

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Title="unMENU1"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

 

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Title="unMENU2"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

 

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Title="unMENU3"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

 

 

Now, browse to the main page on the 5.0 server.

 

You'll see three new tabs.  One labeled as "unMENU", one as "noMENU", the third as "UNMENU"

 

Click on the "UNMENU" tab.   It will render the standard lime-technology header and tabs, but no content (since we did not define any)  This works as expected.

 

Click on the "unMENU" tab.   It will render "Got Here"   (this is not expected at all, since I did not expect emhttp to attempt to render anything at the document root named like basename of the .page file) Clicking this tab sent the contents of  /usr/local/emhttp/unMENU to the browser. 

 

Click on the "noMENU" tab.  It will render a completely blank screen, since no file exists in the document root as /usr/local/emhttp/noMENU.   This completely blank screen really threw me, since I was attempting to migrate a few of the unMENU utilities under a new tab.  It was not an error in any log, nor is it going through the template.php under webGui.

 

Apparently, .page file with a leading lower case letter in its name gets rendered as the "basename" html only as a file in the document root. i.e.

/usr/local/emhttp/unMENU is sent to the browser when the unMENU.page file "tab" is clicked.  (and not interpreted as ".php").  In addition (and why I think it is a bug) it does not use any of the normal document suffixes such as .htm, etc.

 

Comments Tom??   bug??? or undocumented feature???

 

As I said, I was attempting to migrate some unMENU utilities and had named my tab as "unMENU" and all I got was a completely blank screen.   (Then the hair-pulling started... and I have so little to spare)  Took me a while to figure out what was happening.

 

Joe L.

I needed a newer version [for a private tracker] so I was able to get 2.04 running by simple installing these two packages on top of the original.

 

http://dropa-public.s3.amazonaws.com/libevent-1412-i486-1.txz

http://dropa-public.s3.amazonaws.com/transmission-2.04-i486-1mfb.txz

Hey bubba,

 

Any plan to update your tools to support "txz" extensions in the package manager?

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.

I think I stumbled upon a bug ... or a feature ...

 

I was attempting to port some of the unMENU utilities to unRAID 5.0 and ran into a bug/feature that caused the loss of a few more hairs.

 

To duplicate what I found execute the following few lines:

# create a file containing a minimal amount of html in the document "root".

echo "<h1>Got here<br>" >/usr/local/emhttp/unMENU

 

# Create a new "plugin" directory

mkdir /usr/local/emhttp/plugins/JOE

 

# Create three new .page files in that directory

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Title="unMENU1"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/unMENU.page

 

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Title="unMENU2"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/UNMENU.page

 

echo 'Author="Joe"' >/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Version="1.0.0"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Title="unMENU3"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Menu="Tasks"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

echo 'Type="xmenu"' >>/usr/local/emhttp/plugins/JOE/noMENU.page

 

 

Now, browse to the main page on the 5.0 server.

 

You'll see three new tabs.  One labeled as "unMENU", one as "noMENU", the third as "UNMENU"

 

Click on the "UNMENU" tab.   It will render the standard lime-technology header and tabs, but no content (since we did not define any)  This works as expected.

 

Click on the "unMENU" tab.   It will render "Got Here"   (this is not expected at all, since I did not expect emhttp to attempt to render anything at the document root named like basename of the .page file) Clicking this tab sent the contents of  /usr/local/emhttp/unMENU to the browser. 

 

Click on the "noMENU" tab.  It will render a completely blank screen, since no file exists in the document root as /usr/local/emhttp/noMENU.   This completely blank screen really threw me, since I was attempting to migrate a few of the unMENU utilities under a new tab.  It was not an error in any log, nor is it going through the template.php under webGui.

 

Apparently, .page file with a leading lower case letter in its name gets rendered as the "basename" html only as a file in the document root. i.e.

/usr/local/emhttp/unMENU is sent to the browser when the unMENU.page file "tab" is clicked.  (and not interpreted as ".php").  In addition (and why I think it is a bug) it does not use any of the normal document suffixes such as .htm, etc.

 

Comments Tom??   bug??? or undocumented feature???

 

As I said, I was attempting to migrate some unMENU utilities and had named my tab as "unMENU" and all I got was a completely blank screen.   (Then the hair-pulling started... and I have so little to spare)  Took me a while to figure out what was happening.

 

Joe L.

 

LOL, ok I should maybe document what's going on sometime...

 

There are two things at work here: the 'emhttp' server and the templating system as implemented by the file webGui/template.php.

 

First emhttp.  When emhttp receives a GET request it takes a look at the resource being requested.  The resource is the part after the domain, e.g., http://tower/UNMENU the resource is "UNMENU".  If the first character of the resource starts with a capital letter and there is no file extension, then emhttp assumes this is a "page" request to be handled by the webGui template system.  So it ends up invoking php like this:

 

cd /usr/local/emhttp; /usr/bin/php plugins/webGui/template.php?path=UNMENU&prev=<previous page>

 

If you specified a querystring on the original request, eg,

 

http://tower/UNMENU?myvar1=avalue

then emhttp appends the path & prev vars to the end:

 

cd /usr/local/emhttp; /usr/bin/php plugins/webGui/template.php?myvar1=avalue&path=UNMENU&prev=<previous page>

 

So when you click on UNMENU tab it's treated like a page correctly.

 

When you click on unMENU, since it does not start with a capital letter, emhttp looks for it in the document root, and it finds a file named unMENU so it sends it to your browser.

 

When you click on noMENU, again, no starting with a capital, so emhttp looks for "noMENU" in the document root, but it's not found so it returns a 404 HTTP response.

 

Now for the templating system: when it generates the task bar during page rendering, it just looks for any page files that have a

Menu="Tasks" line.  This tells template that this page should be included on the "Tasks" menu (ie, the main menu bar).

 

Make sense?

 

I probably should have emhttp search through all the plugin directories looking for the exact page file instead of the heuristic "starts with a capital and has no extension", but this is simple and fast and good 'nuff.    Also maybe should  have the taskbar rendering part of template.php check that the page file adheres to the heuristic, and then you might not have been confused.