Jump to content
bubbaQ

unRAID-Web - complete web server w/ php for unRAID

281 posts in this topic Last Reply

Recommended Posts

Updated 7/19/2010 for compatibility with unRAID 5.0

 

Version 0.1.05 is posted.  Download link:

 

  http://www.tcpatools.com/bubba/unraidweb-0.1.05-i386-bubba.tgz

 

One-click install (Windows XP only):

 

 http://www.tcpatools.com/bubba/install_web.exe  

 

The one-click install is a wizard that will download and start unRAID-Web for you without you having to invoke telnet, run any commands, or copy files manually.  It will prompt you for the server name and other information.  It will copy and run unRAID-Web, but only once -- so that when you reboot, unRAID-Web will not automatically.  This is intended for people who want to try it out, but don't want to set it to be started ever time unRAID starts.

 

Or you can test it out like this:

 

Log into your unRAID box via telnet, and copy and paste this command:

 

wget -O /tmp/unweb.tgz http://www.tcpatools.com/bubba/unraidweb-0.1.05-i386-bubba.tgz ;  installpkg /tmp/unweb.tgz

 

That's all.

 

You access it by going to http://tower:89 or http://<serverIP>:89

 

Or you can download the tgz file and save it locally, and then install it with the "installpkg" command after each reboot.

 

 

=======================================================

 

I think that a web server is an important tool for enhanced add-in development for unRAID -- particularly for enhancing the user interface.

 

So, I have a new little project:  unRAID-Web

 

The goal is to add a complete web server with php to unRAID, with a single package that needs no script or config file editing by the user.  This can then be used by unMenu users, other developers as a package, or even by people with a complete unRAID install to the hard drive.

 

This is a single slackware package, installed with the standard installpkg.  

 

It consists of:

 - lighttpd 1.4.19 (light web server)

 - php 5.2.8

 - Gamin 0.1.9 (FAM - lighttpd dependency)

 - libxml (php dependency)

 - lighttpd and php config files on the flash (/boot/config/)

 

I was going to have it install with a script, but that will not work well for people using unMenu to add packages at every boot, so the package itself should not have an interactive script.... but I want to make it simple for a novice to implement it.  So I decided to use the web server itself, to configure the web server.

 

The trick is to have an initial default web server configuration that will load and bring up a simple interface (wizard) for the user to enter the basic parameters for the web server (like where the webserver documents are stored (document root) and which port to use).  So after the first time you install the package, you go to an address like:

 

  http://tower:89

 

And that will start the web server setup wizard.  You can go back to port 89 at any time to use the setup wizard to make changes to your web server config.  As the wizard is improved, it can be upgraded w/o needing to reapply the entire slackware package.  For example, the wizard can be enhanced to do the configuration changes for user/pw access control to the web server.

 

The files on the flash are stored as follows:

 

 /boot/config/lighttpd/   ............ web server config files

 /boot/config/lighttpd/setup/ ...... the setup wizard php code

 /boot/config/php/ ................... php config files

 

 

So, I'd like others to comment on this before I finalize everything and post the package for download.  It's easier to change stuff now than it will be later.

 

I will be migrating BubbaRaid to be based on this package rather than the current custom configuration of lighttpd and php configs that BubbaRaid uses.  That way, if others develop web-based applications, they can integrate into BubbaRaid easily.

Share this post


Link to post

Great stuff!

 

I suspect unRAID of 2009 is gonna be much different than unRAID 2008 - and this without Tom's involvement (everybody is eager for that too).

 

Very good year for unRAID modders.

 

 

Share this post


Link to post

I was going to have it install with a script, but that will not work well for people using unMenu to add packages at every boot, so the package itself should not have an interactive script.... but I want to make it simple for a novice to implement it.  So I decided to use the web server itself, to configure the web server.

 

I just wanted to point out... if you changed the PACKAGE_INSTALLATION line in the unmenu package .conf to run your script instead of using a installpkg command, you will not have the negative impact you were pointing out.  Furthermore, if you just include the script as multiple PACKAGE_INSTALLATION lines in the .conf, then you will not need to have a seperate script file at all. (it would be "migrated" to an .auto_install file and run on every boot when enabled in the pacakge manager)

 

Cheers,

Matt

 

EDIT: I missed the INTERACTIVE part.. oops

Share this post


Link to post

Because this is a foundational application, I am writing it to be completely self-sufficient, and not relying on or using any of the other package management tools except those in stock unRAID.

 

This is intended to be able to run on a stock unRAID system with no additions.... and then the web server/php can be used to install unMenu and anything else.

Share this post


Link to post

Because this is a foundational application, I am writing it to be completely self-sufficient, and not relying on or using any of the other package management tools except those in stock unRAID.

 

This is intended to be able to run on a stock unRAID system with no additions.... and then the web server/php can be used to install unMenu and anything else.

Sounds great.   I'll bet you could use unMENU to install it if it is self-sufficient. (Pulling yourself up with your own bootstraps...)

 

A "true" web-server would not be a bad thing to have available.

 

A small "php" wrapper could probably would make all the unmenu plug-ins functional without too much work.   (The concept of a plug-in works, regardless of the web-server serving up the HTML) 

 

Joe L.

Share this post


Link to post

Or... you can use this web server and php to install unMenu through a point-n-click menu system ;)

Share this post


Link to post

Or... you can use this web server and php to install unMenu through a point-n-click menu system ;)

What came first, the chicken, or the egg...  ;D

Share this post


Link to post

love to watch you guys :D

 

(erm... this didn't sound wrong, did it?)

 

 

Share this post


Link to post

Version 0.0.1 of unRAID-Web is now posted for download.

 

Now you can easily install a web server with php on unRAID.

 

Link is in the OP.   Have fun!

 

This package has not been optimized for size yet.  It includes man pages and headers that a typical unRAID user will not need.  I will strip unneeded dead wood from the package later, after some testing by users.

Share this post


Link to post
A small "php" wrapper could probably would make all the unmenu plug-ins functional without too much work.

 

Yes, you can shell execute them from within php, capture the output, and echo it back.

Share this post


Link to post

Here's a little sample of where I'm going with the graphical interface with jquery for unRAID, using the web server and php.

 

http://www.tcpatools.com/bubba/sample1.jpg

 

I've developed a neat interface that will let you do all the functions of the original unRAID interface, including adding/deleting disks, changing settings, etc.

Share this post


Link to post

Great... don't forget user shares related functions (because you don't use them).

 

 

Share this post


Link to post
don't forget user shares related functions

 

I don't use them, but I've set them up on the test system.

Share this post


Link to post

I whole heartily applaud this project.

 

I believe this one project marks the beginning of an amalgamation of all unRAID addons.

 

Installed trivially here

Share this post


Link to post
Installed trivially here.

 

Good!

 

I hope some other developers do the same, and start some web-based projects.  I'd really like to see some others develop some apps in this, and after they do, I'll put the finishing touches on an extension framework for it.

 

I will also pull together a set of common libraries, particularly if folks use jquery, so different apps can share common code and widgets.

 

 

Share this post


Link to post

I installed the initial version, but seems that only the software prerequisites are in place, not the web site itself.  (Please redirect me if there was something installed that I missed).

 

I'm going to port parts of myMain (at least the smart view) over, but feel that I need more of a structure for how plugin pages would be developed.  I understand this may morph over time, but feel that I need some starting point.  Even a relatively simple shell of a plugin / web page that will work in the overall structure would be enough to get started.

 

IMO, there would be tremendous value to allowing unmenu plugins to operate within this framework.  The package manager, syslog viewer, myMain, file editor / viewer, and many of the information pages and features are pretty strong.  Although over time they could (and should) be moved to the new framework, I think having a bridge back to the unmenu functionality is needed to bridge the gap.  I am hoping that Joe L. might be able to create that bridge - but again think he would need some starting point as well.

 

Glad to see NAS has something to support!  Let's all work together to make this great and something that get's Tom's attention!

Share this post


Link to post

I installed the initial version, but seems that only the software prerequisites are in place, not the web site itself.  (Please redirect me if there was something installed that I missed).

 

I'm going to port parts of myMain (at least the smart view) over, but feel that I need more of a structure for how plugin pages would be developed.  I understand this may morph over time, but feel that I need some starting point.  Even a relatively simple shell of a plugin / web page that will work in the overall structure would be enough to get started.

 

IMO, there would be tremendous value to allowing unmenu plugins to operate within this framework.  The package manager, syslog viewer, myMain, file editor / viewer, and many of the information pages and features are pretty strong.  Although over time they could (and should) be moved to the new framework, I think having a bridge back to the unmenu functionality is needed to bridge the gap.  I am hoping that Joe L. might be able to create that bridge - but again think he would need some starting point as well.

 

Glad to see NAS has something to support!  Let's all work together to make this great and something that get's Tom's attention!

No structure has been put into place for plug-ins, or anything else as of yet.  I'd like to build a plug-in system tied into the screen-shot "tab" interface that was posted, but do not know if that is far enough along for BubbaQ to share.  As far as I can see, a simple wrapper should allow the existing plug-ins to work as is. 

 

If BubbaQ gives me  a starting point to build off of, it can probably be done in quick order.  For now, there is just an alternate web-server, but no pages. 

 

Joe L.

Share this post


Link to post

I should have something real nice to show in a few days.  ;D ;D

 

For now, do something like this:

 

  Make a diir on the array like  /mnt/disk1/www

 

  Make a subdir for your application under www, like /mnt/disk1/www/myapp

 

  Install unRAID-Web and point it to /mnt/disk1/www  on port 81

 

 

Start coding your html.php in /mnt/disk1/www/myapp, using "http://tower:81/myapp" to test it

 

As long as you put all the files needed for your app in its home "/mnt/disk1/www/myapp" (and you can make subdirs in it too), it will be fully portable to the web interface I am developing.  Just make all your code references relative, and not absolute (i.e. src='foo.css'  and not src='/myapp/foo.css')

 

 

Share this post


Link to post

I should have something real nice to show in a few days.   ;D ;D

 

For now, do something like this:

 

   Make a diir on the array like  /mnt/disk1/www

 

   Make a subdir for your application under www, like /mnt/disk1/www/myapp

 

   Install unRAID-Web and point it to /mnt/disk1/www  on port 81

 

 

Start coding your html.php in /mnt/disk1/www/myapp, using "http://tower:81/myapp" to test it

 

As long as you put all the files needed for your app in its home "/mnt/disk1/www/myapp" (and you can make subdirs in it too), it will be fully portable to the web interface I am developing.  Just make all your code references relative, and not absolute (i.e. src='foo.css'  and not src='/myapp/foo.css')

 

Could you give us an idea of the folder structure you would be looking at using within the www folder, especially for plugins?  For instance, will the plugins be placed in a subdirectory (or in their own folder, or even in their own folder within a subdirectory), how about a central location for plugin configuration files?  Maybe we should talk about some of these details before other people start programming... Just to keep things moving quickly and in the same direction.

 

Cheers,

Matt

Share this post


Link to post
Could you give us an idea of the folder structure you would be looking at using within the www folder

 

It is irrelevant.... your code lives in its home, and that home could be ANYWHERE.  Access all your file relatively, and you can create any structure you want under www/myapp/.  If you want to access any standard unRAID files, the standard system paths are avaialble to php such as "/booot/config" etc.

 

You develop in any folder you want.  Then you tar/zip up that single folder and its subfolders, and that will be a distributable and fully portable extension.

 

The only constraint is that your apps need to be "black boxes" and don't assume anything other than unRAID stock.  If you are calling something like bwm-ng to get stats, you need to TEST for the EXISTENCE of bwm-ng before calling it, and gracefully handle the fact that it may not exist on the target machine.

 

I will have you a sample little extension to play with soon.  Below is a little more developed prototype (and yes, I know the total disk space calc is off by 1TB, because I forgot to leave out the parity disk  ;)  ).

 

 

Share this post


Link to post

 

It is irrelevant.... your code lives in its home, and that home could be ANYWHERE.  Access all your file relatively, and you can create any structure you want under www/myapp/.  If you want to access any standard unRAID files, the standard system paths are avaialble to php such as "/booot/config" etc.

 

I understand this, but what about shared variables that would be used by multiple plugins (for instance a package directory, or the location of the custom rc.d directory).  A user would have to edit the same variable over and over again in multiple configuration files, when only one would be needed.  if we are to call everything relatively, then we need to know folder structure and the location of that centralized configuration file.

 

Maybe I don't know enough about php yet, but if we need user configured global variables, we need a place to find them and possibly even add to them.

 

Cheers,

Matt

Share this post


Link to post

One correction....

 

There will be a shared library of code that you can use.  But it should also be accessed relatively.

 

The structure I am tentatively using is this:

 

Call "www" the home for the web portal.  That could be "/boot/config/lighttpd" or "/mnt/disk1/www" or "/mnt/disk13/stuff/mystuff/hthome" or anywhere else.

 

    www/  - my management interface and config files.

 

    www/extensions  -  extensions home, and each extenions will have its own home dir in here.

 

    www/extensions/app1  - home for extension "app1"

 

    www/extensions/app2  - home for extension "app2"

 

    www/shared    - location for shared files so we can reuse common php code, images, CSS, widgets, etc.

 

So to use the green checkmark I use, you should access shared code as "src='../shared/green-ok.png'"

 

I'm thinking about adding subdirs to the shared code, for "php", "images", "css", and "widgets".  Any votes on that?

 

Share this post


Link to post
the location of that centralized configuration file.

 

You won't need to access the portal config files.... my portal management will take of that for you!

 

As for variables, I have a unRAID disk class created in php, with the code that populates it.  So you just use one php include statement, and then you have compelte access to a fully populated class:

 

  class DriveData {

    public $rawData;

    public $diskNumber;

    public $diskName;

    public $diskState;

    public $diskSize;

    public $diskModel;

    public $diskSerial;

    public $diskNumReads;

    public $diskNumWrites;

    public $diskNumErrors;

    public $diskId;

    public $rdevNumber;

    public $rdevStatus;

    public $rdevName;

    public $rdevSize;

    public $rdevModel;

    public $rdevSerial;

    public $rdevId;

   

    public $spinstat;

    public $freespace;

    public $smartstat;

    public $device;

   

    public $temp;

    public $read_temp_if_idle;

 

I'm still developing this, so I haven't got it commented yet.  But after you call it, you then have complete access to all the unRAID array data in php like this:

 

  disk[$i]->diskModel

 

will return the string for the disk model for disk $i (and $i can be 0-16).  Can also include the cache disk if you want.

Share this post


Link to post

I'm thinking about adding subdirs to the shared code, for "php", "images", "css", and "widgets".  Any votes on that?

 

Granted i do not do any php programming but i would have to vote yes for the above structure.  Separating what is what will make the images, etc easier to find if need be.

Share this post


Link to post
i would have to vote yes for the above structure.

 

I agree.  Except for images used by css, that need to be in the same location as the css.  That will allow easier skinning.

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.