I've been thinking about this for a while in that we could use an easy way to support user plugins into the http interface.

 

My thought is to add regular HTML and CGI support to the emhttp interface so we can create user interface enhancements to unRAID.

 

If for example

 

We had directory of /usr/local/emhttp

and subdirectories under that for each user plugin.

 

Then for each subdirectory (expecting either index.html or index.cgi)

add a line item to the menu bar across the top of the management page.

 

For example right now we have

Main | Users | Shares | Settings | Devices

 

I would like to add some of my own tools as in

 

Locate (as an interface to locate to help me find files)

Browse (An http interface to navigate down the tree interactively and perform file operations)

Manage (More advanced Device Management (NOTES,SMART,TEST,reiserfsck(of course the raid has to be stopped).

Syslog (To dump the dam syslog to the browser and/or allow downloading it  )

Help (Help notes and links for debugging problems).

 

So the tree might look like.

 

/usr/local/empttp/Manage

/usr/local/emhttp/Locate

/usr/local/emhttp/Browse

/usr/local/emhttp/Bittorrent

/usr/local/emhttp/Syslogs

/usr/local/emhttp/Help

 

and the menu would resolve to

 

Main | Users | Shares | Settings | Devices | Manage | Locate | Browse | Bittorrent| Syslogs | Help

 

I think it would be a good framework for allowing people to create drop in tools for enhancing the management of the environment.

 

The only other alternative is installing another additional http server and I think this complicates it more for the end user.

 

Thoughts?

Weebo my thoughts are to take this to Tom directly (PM or mail).

You have many good ideas and an idea on HOW to implement those things.

 

There is a thin line between what should be a user customization and what should be base functionality.

Maybe in private you can make this line bolder (and move it a little too )...

 

 

I figure I would post it here first to see what the community thinks.

I have to figure, Tom's a busy guy, so if there is enough interest and the thread has enough traffic, I'm sure it will be considered.

I assume features (and priority level) are going to be handled based on user interest.

I don't think it'll happen.  Until we hear otherwise we need to figure out if we can do it ourselves.  It wouldn't be too hard to have another web server (apache, lighttpd, whatever) as the front-end, have emhttp respond to a different port, then filter all requests through the main web server.  So when you go to administer unRAID you see your other webserver (i.e. apache).  If you click to see the status of the array, it passes on that request to the emhttp server, sees what is returned, and passes it on to you.  You can then create scripts for the main webserver (which would interact with emhttp).

 

In case someone doesn't see the potential, here's an example.  I had suggested that we run certain commands whenever the array is started or stopped.  If we stop the array via apache, it can call certain scripts, including ones to stop any programs from running that would keep files open on the array (and thus, keep it from being stopped).  Once that's done it will send the command to emhttp to stop the array.  When you tell apache to start the array, it will call start the array and then restart the same programs that were previously stopped.

It wouldn't be too hard to have another web server (apache, lighttpd, whatever) as the front-end, have emhttp respond to a different port, then filter all requests through the main web server.

 

This is true, I do it on my own network using apache's proxy module.

I was trying to keep the unraid distribution as lightweight as possible. CGI via emhttp would accomplish that.

 

Creating a secondary package to first install apache, then install a custom config, then modify go to run emhttp custom becomes allot of work    Doable.. just allot of it.

It wouldn't be too hard to have another web server (apache, lighttpd, whatever) as the front-end, have emhttp respond to a different port, then filter all requests through the main web server.

 

This is true, I do it on my own network using apache's proxy module.

I was trying to keep the unraid distribution as lightweight as possible. CGI via emhttp would accomplish that.

 

Creating a secondary package to first install apache, then install a custom config, then modify go to run emhttp custom becomes allot of work     Doable.. just allot of it.

 

Not really.  I tend to think along the lines of doing this on a regular Slackware install, but it'd still work off of a flash drive.  installpkg is pretty powerful.  I could easily package up something that would install a web server customized the way you want, and edit the go script to invoke itself just before emhttp (and of course edit the emhttp line to start it on another port).

 

For a flash drive install, I'd look into alternatives to apache.  Could lighttpd fit the bill?  Something lightweight that could do the proxy thing, and run standard scripts would be idea.

 

Edit:  I should clarify the above, it'd be easy to have installpkg set everything up for us, but of course we still need a way to copy it into the root filesystem on each boot.  If we go with your idea of a /boot/custom.sync, then we're in a bit of a quandry (sp?).  We need to install with /boot/custom.sync as the root, but still edit the go script which is outside of that.  As long as I can clear that hurdle, then it'll be a piece of cake to create a package that can be installed on unRAID or on a standard drive.  I know I'm not making perfect sense, just let me know if you can't decipher my ramblings.

We need to install with /boot/custom.sync as the root, but still edit the go script which is outside of that.

 

Anything can be programmed.

The synchronization script would have to sync the directories/files.

Then know enough to run a custom rc plugin which would do secondary level modifications where needed.

 

 

I tend to always think in terms of using installpkg to use the virgin pacakges for slackware.

Then I have custom install scripts which put the package in place and make all the secondary modifications to the system as needed.

 

It's a bit of work but I always know what I am starting with.

 

If the synchronization is always done first, then the static rc.d scripts can modify things as needed.

I haven't gotten that far into the process of synchronization yet. but that's how I would do it.